Amazon Practice Questions, Discussions & Exam Topics by our Authors
A company has created a multi-tier application for its ecommerce website. The website uses an Application Load Balancer that resides in the public subnets, a web tier in the public subnets, and a MySQL cluster hosted on Amazon EC2 instances in the private subnets. The MySQL database needs to retrieve product catalog and pricing information that is hosted on the internet by a third-party provider. A sol...
To meet the company's requirement of securely accessing product catalog and pricing information hosted by a third-party provider on the internet, the solution must ensure the MySQL database (housed in private subnets) can securely access the internet without compromising security and operational overhead. Let’s break down each option:
Option A: Deploy a NAT instance in the VPC. Route all the internet-based traffic through the NAT instance.
- Explanation: A NAT instance is a virtual machine that allows instances in private subnets to initiate outbound traffic to the internet. However, NAT instances come with management overhead, such as scaling, patching, and monitoring.
- Why Rejected: Although a NAT instance can work, it adds additional operational overhead since it must be manually scaled, maintained, and secured. It is less desirable compared to a fully managed solution like a NAT gateway, which eliminates the need for ongoing management.
Option B: Deploy a NAT gateway in the public subnets. Modify the private subnet route table to direct all internet-bound traffic to the NAT gateway.
- Explanation: A NAT gateway is a fully managed AWS service that allows instances in private subnets to access the internet while preventing inbound internet traffic from directly accessing those instances. It is highly available, scalable, and eliminates the operational overhead of a NAT instance.
- Why Selected: This is the best solution because the NAT gateway provides secure and scalable internet access for resources in private subnets without increasing operational overhead. It is fully managed, ensuring minimal maintenance and automatic scaling, making it a secure and efficient way to allow private subnet instances (like the MySQL cluster) to access the internet to retrieve product catalog data.
Option C: Configure an internet gatewa...
Author: Ava · Last updated Aug 7, 2026
A company is using AWS Key Management Service (AWS KMS) keys to encrypt AWS Lambda environment variables. A solutions architect needs to ensure that the required permissions are in place to decrypt and use the environment variables.
...
When using AWS KMS keys to encrypt AWS Lambda environment variables, it is important to ensure that the appropriate permissions are set up so that Lambda can decrypt the environment variables when executing. Let's analyze each option:
Option A: Add AWS KMS permissions in the Lambda resource policy.
- Explanation: The Lambda resource policy is used to control access to Lambda functions, allowing you to specify who can invoke or manage a function. However, the resource policy is not used for controlling permissions to access the KMS key for decryption.
- Why Rejected: This is not the appropriate location to grant permissions for decrypting KMS-encrypted environment variables. The Lambda resource policy is primarily for controlling access to Lambda invocation, not for managing KMS permissions.
Option B: Add AWS KMS permissions in the Lambda execution role.
- Explanation: The Lambda execution role is the IAM role that the Lambda function assumes when it runs. This role is where permissions are assigned for the Lambda function to interact with other AWS services, including KMS. By adding KMS permissions in the Lambda execution role, you ensure that the Lambda function can use the KMS key to decrypt the environment variables during execution.
- Why Selected: This is the correct way to grant the Lambda function the necessary permissions to decrypt the environment variables. The Lambda execution role is the entity that assumes the permissions needed for function execution, making it the proper place to assign these KMS permissions.
Option C: Add AWS KMS permissions in the Lambda function policy.
- Explanation: AWS Lambda does not have a separate "function policy" that can be used to control access to AWS resources. Instead, the Lamb...
Author: Chloe · Last updated Aug 7, 2026
A company has a financial application that produces reports. The reports average 50 KB in size and are stored in Amazon S3. The reports are frequently accessed during the first week after production and must be stored for several years. The rep...
To meet the requirements outlined—storing reports with frequent access in the first week, long-term retention, and ensuring retrieval within 6 hours—the following factors need to be considered:
Key Requirements:
1. Frequent Access in First Week: The reports need to be frequently accessed during the first week.
2. Long-Term Retention (several years): The reports must be stored for multiple years.
3. Retrieval Within 6 Hours: Retrieval time is critical, and it must occur within 6 hours.
Analysis of Options:
Option A: Use S3 Standard. Use an S3 Lifecycle rule to transition the reports to S3 Glacier after 7 days.
- Pros:
- S3 Glacier is a low-cost storage solution ideal for long-term retention.
- Glacier offers retrieval times from minutes to hours, with retrieval within 6 hours possible using the standard retrieval option.
- Cons:
- The first week will be on S3 Standard, which is relatively expensive compared to other storage options.
- This option does not optimize cost for less frequent access after the first week as efficiently as others.
- Transitioning directly to Glacier is suitable for data that is unlikely to be frequently accessed after the initial period, but retrieval times are slower than Glacier Standard (which is acceptable here but needs to be optimized).
Option B: Use S3 Standard. Use an S3 Lifecycle rule to transition the reports to S3 Standard-Infrequent Access (S3 Standard-IA) after 7 days.
- Pros:
- S3 Standard-IA is designed for infrequent access with lower storage costs, making it ideal for reports that are accessed less frequently after the first week.
- Faster retrieval times than Glacier (typically milliseconds to minutes).
- Storage cost is lower than Standard, so it can optimize costs after the first 7 days.
- Cons:
- S3 Standard-IA incurs retrieval costs when accessed, which may increase the cost for occasional access.
- Reports may still be slightly more expensive in Standard storage during the first week compared to the Intelligent-Tiering or Glacier options.
Option C: Use S3 Intelligent-Tiering. Configure S3 Intelligent-Tiering to transition the reports to S3 Standard-Infrequent Access (S3 Standard-IA) and S3 Glacier.
- Pr...
Author: Ava · Last updated Aug 7, 2026
A company needs to optimize the cost of its Amazon EC2 instances. The company also needs to change the type and family of its EC2 instances every 2-3 ...
To optimize costs for Amazon EC2 instances while also accommodating the need to change the type and family of instances every 2-3 months, we need to consider the flexibility and commitment involved with the pricing options.
Key Factors:
1. Cost Optimization: The company needs to reduce the cost of EC2 instances.
2. Flexibility: The company needs to be able to change the instance type and family frequently, every 2-3 months.
3. Commitment Period: The company has to decide on the commitment term to balance cost savings with flexibility.
Analysis of Options:
Option A: Purchase Partial Upfront Reserved Instances for a 3-year term.
- Pros:
- Reserved Instances (RIs) provide significant cost savings compared to On-Demand instances, especially when the company commits for a longer term (3 years in this case).
- Partial Upfront RIs provide savings without requiring the entire amount upfront.
- Cons:
- Reserved Instances are specific to instance types, families, regions, and availability zones. Changing the type and family of the instances every 2-3 months would conflict with the flexibility needed.
- RIs are best suited for stable workloads with predictable usage, which doesn't fit the company's need for changing instance types frequently.
- The 3-year term is a long commitment that may not provide the required flexibility.
Option B: Purchase a No Upfront Compute Savings Plan for a 1-year term.
- Pros:
- Compute Savings Plans offer flexibility across instance families, types, regions, and operating systems. This matches the company's need to change instance types and families every 2-3 months.
- The No Upfront option allows for flexibility in payment.
- The 1-year term provides a reasonable commitment for cost savings while being short enough to allow for frequent changes.
- Cons:
- While this plan provides flexibility, it might not offer as large a discount compared to Reserved Instances for the same usage. However, the savings are still...
Author: VioletCheetah55 · Last updated Aug 7, 2026
A solutions architect needs to review a company's Amazon S3 buckets to discover personally identifiable information (PII). The company stores the PII data in the us-east-1 Region and us-west-2 Regio...
To meet the requirement of discovering personally identifiable information (PII) in Amazon S3 with the least operational overhead, the solution must be efficient, automated, and specifically suited for identifying and classifying sensitive data, like PII, within S3 buckets.
Key Factors:
1. Discovery of PII: The solution must be capable of detecting and classifying PII data in S3 buckets.
2. Multi-Region Support: The company stores PII in both the us-east-1 and us-west-2 Regions.
3. Least Operational Overhead: The solution should minimize the need for manual intervention and be as automated as possible.
Analysis of Options:
Option A: Configure Amazon Macie in each Region. Create a job to analyze the data that is in Amazon S3.
- Pros:
- Amazon Macie is specifically designed to discover, classify, and protect sensitive data, including PII, in Amazon S3.
- It can automatically scan the contents of S3 buckets to find PII data like names, email addresses, credit card numbers, etc.
- Macie supports multiple regions, so it can cover both us-east-1 and us-west-2.
- Macie also offers automated data classification, reducing operational overhead by continuously monitoring the data.
- It provides detailed reports on the discovered PII, allowing the company to take appropriate actions.
- Cons:
- You need to configure Macie separately in each region, but this is a one-time setup and is relatively low overhead considering the task.
Option B: Configure AWS Security Hub for all Regions. Create an AWS Config rule to analyze the data that is in Amazon S3.
- Pros:
- AWS Security Hub aggregates security findings from multiple AWS services, providing a central location for security insights.
- AWS Config can track resource configurations and compliance over time.
- Cons:
- AWS Config and AWS Security Hub do not specialize in identifying sensitive data like PII. AWS Config would only monitor changes to resources and configurations but does not analy...
Author: Zara1234 · Last updated Aug 7, 2026
A company's SAP application has a backend SQL Server database in an on-premises environment. The company wants to migrate its on-premises application and database server to AWS. The company needs an instance type that meets the high demands of its SAP database. On-premises performance data sho...
To select the most suitable instance type for migrating the SAP application and its SQL Server database to AWS, we need to consider the specific requirements for both the application and the database, especially the high memory utilization indicated in the on-premises performance data.
Key Requirements:
1. High Memory Utilization: Both the SAP application and the database require substantial memory, which is crucial for their performance.
2. High Performance Needs: The instance must meet the high demands of both the application and the database.
3. Efficiency: The solution should provide an optimal balance of CPU, memory, and storage resources to meet these performance needs without overspending on resources that are not required.
Analysis of Options:
Option A: Use the compute optimized instance family for the application. Use the memory optimized instance family for the database.
- Pros:
- Compute-Optimized Instances (e.g., C5 or C6i) are designed for workloads that require high processing power but do not necessarily demand large amounts of memory. This is beneficial for applications that are compute-bound.
- Memory-Optimized Instances (e.g., R5 or X1e) provide a high amount of memory per vCPU, which is ideal for memory-intensive applications like databases, especially for SQL Server.
- This option would allow the company to tailor resources to the needs of each component, ensuring high performance where it's most needed.
- Cons:
- This approach requires managing two different instance types, which may add complexity compared to using a single instance family. However, this trade-off is acceptable if the application and database have distinctly different resource requirements.
Option B: Use the storage optimized instance family for both the application and the database.
- Pros:
- Storage-Optimized Instances (e.g., I3 or D2) are best suited for applications that require high I/O operations, such as NoSQL databases, data warehousing, and distributed file systems.
- Cons:
- This option is not ideal for memory-intensive workloads like the SAP application and SQL Server database. While storage-optimized instances provide fast and high-throughput storage, they do not provide the best memory or CPU capabilities for high-memory usage. This would lead to suboptimal performance for both the application and the database, especially given ...
Author: Arjun · Last updated Aug 7, 2026
A company runs an application in a VPC with public and private subnets. The VPC extends across multiple Availability Zones. The application runs on Amazon EC2 instances in private subnets. The application uses an Amazon Simple Queue Service (Amazon SQS) queue.
A solutions architect needs to design a se...
To design a secure solution that allows the EC2 instances in private subnets to connect to an Amazon Simple Queue Service (Amazon SQS) queue while maintaining security and privacy, we need to focus on the following factors:
Key Requirements:
1. Security: The EC2 instances are in private subnets, meaning they should not have direct access to the internet or expose their traffic to the public network.
2. Private Connectivity: The solution should ensure that the connection between the EC2 instances and SQS is secure, private, and does not traverse the public internet.
3. Seamless Access: The EC2 instances in the private subnets must be able to access the SQS queue securely without requiring public IP addresses or access through a NAT gateway.
Analysis of Options:
Option A: Implement an interface VPC endpoint for Amazon SQS. Configure the endpoint to use the private subnets. Add to the endpoint a security group that has an inbound access rule that allows traffic from the EC2 instances that are in the private subnets.
- Pros:
- Interface VPC Endpoints provide private connectivity to AWS services (including SQS) from within a VPC, without requiring internet access. This ensures that communication between the EC2 instances and SQS remains secure within the AWS network.
- By configuring the endpoint to use private subnets, all traffic stays within the VPC, meeting the requirement for private connectivity.
- Associating a security group with the endpoint and allowing traffic from the EC2 instances in the private subnets provides fine-grained access control, which adds an additional layer of security.
- Cons:
- There is a small overhead to manage security groups, but this is a standard practice to ensure secure access.
- Conclusion: This option is secure, efficient, and fully meets the requirements of private and secure connectivity.
Option B: Implement an interface VPC endpoint for Amazon SQS. Configure the endpoint to use the public subnets. Attach to the interface endpoint a VPC endpoint policy that allows access from the EC2 instances that are in the private subnets.
- Pros:
- Interface VPC Endpoints are a good solution for secure, private connectivity to AWS services.
- Cons:
- Configuring the endpoint in public subnets is not ideal because it exposes the endpoint to the public subnet, which could potentially create security concerns. The traffic from the private subnets would still route through the public subnet, which is not as secure as having everyt...
Author: Daniel · Last updated Aug 7, 2026
A solutions architect is using an AWS CloudFormation template to deploy a three-tier web application. The web application consists of a web tier and an application tier that stores and retrieves user data in Amazon DynamoDB tables. The web and application tiers are hosted on Amazon EC2 instances, and the database tier is not publicly accessible. The application EC2 inst...
To solve this problem, the solution needs to ensure that the EC2 instances in the application tier can access DynamoDB tables securely without exposing API credentials in the CloudFormation template. Let’s evaluate each option based on key factors like security, ease of implementation, and best practices for managing credentials:
Option A: Create an IAM role to read the DynamoDB tables. Associate the role with the application instances by referencing an instance profile.
- Reasoning: This option suggests creating an IAM role specifically for reading the DynamoDB tables, and associating it with the EC2 instances using an instance profile. The benefit of using IAM roles is that EC2 instances can securely assume the role to obtain temporary credentials to access AWS resources, without embedding static credentials in the template. This is a secure and recommended approach because it uses IAM roles and automatically handles the credentials through the instance profile, which eliminates the need to expose credentials.
- Why it’s selected: This follows AWS security best practices (IAM roles) and provides temporary credentials, which are safer than long-lived static API keys.
Option B: Create an IAM role that has the required permissions to read and write from the DynamoDB tables. Add the role to the EC2 instance profile, and associate the instance profile with the application instances.
- Reasoning: Similar to Option A, but with the addition that the IAM role grants both read and write permissions to DynamoDB. While this is a valid approach, the web application might only need read access to DynamoDB, not write access. Over-permissioning access (e.g., giving write access when not needed) violates the principle of least privilege.
- Why it’s rejected: This is a good option in terms of functionality, but it could grant excessive permissions, which is not ideal if the application only needs read access to DynamoDB. Option A is more aligned with least p...
Author: Aria · Last updated Aug 7, 2026
A solutions architect manages an analytics application. The application stores large amounts of semistructured data in an Amazon S3 bucket. The solutions architect wants to use parallel data processing to process the data more quickly. The solutions architect also wants to use info...
To address the solution, we need to focus on the following goals:
- Parallel data processing: This allows the data to be processed more quickly, which is essential for handling large amounts of data efficiently.
- Enriching the data using Amazon Redshift: The solution must facilitate using data stored in Amazon Redshift to enhance the S3 data.
Let’s evaluate each option:
Option A: Use Amazon Athena to process the S3 data. Use AWS Glue with the Amazon Redshift data to enrich the S3 data.
- Reasoning: Amazon Athena is a serverless query service that allows for parallel querying of data in S3 using standard SQL, making it a great tool for processing large, semi-structured datasets. AWS Glue is a fully managed ETL service that can be used to transform and enrich data, including integrating data from Amazon Redshift. However, the use of AWS Glue for enriching the S3 data might require manual configuration of the Redshift integration. Athena can process data in parallel, but the integration with Redshift might not be as seamless as other solutions.
- Why it’s rejected: While it’s a feasible solution, it requires additional configurations for Glue to enrich the data with Redshift, and it doesn’t provide a fully automated pipeline for complex tasks.
Option B: Use Amazon EMR to process the S3 data. Use Amazon EMR with the Amazon Redshift data to enrich the S3 data.
- Reasoning: Amazon EMR is an excellent choice for processing large datasets in parallel. It can run frameworks like Apache Spark and Hadoop, which are well-suited for large-scale data processing. EMR can easily interact with Amazon Redshift to enrich the data by using JDBC or custom scripts to pull the relevant data from Redshift. This solution would allow the parallel processing of data and enrich it using Redshift data in a scalable and efficient manner.
- Why it’s selected: EMR is highly flexible for large-scale parallel data processing, and integrating it with Redshift is straightforward for enriching the S3 data...
Author: Grace · Last updated Aug 7, 2026
A company has two VPCs that are located in the us-west-2 Region within the same AWS account. The company needs to allow network traffic between these VPCs. Approximately 500 GB of data transfer will occur betwe...
To determine the most cost-effective solution for connecting two VPCs that need to transfer approximately 500 GB of data each month, let’s evaluate each option based on the requirements:
Option A: Implement AWS Transit Gateway to connect the VPCs. Update the route tables of each VPC to use the transit gateway for inter-VPC communication.
- Reasoning: AWS Transit Gateway allows the connection of multiple VPCs in a hub-and-spoke model, simplifying routing and network management. While this is a powerful solution that scales well for multiple VPCs, it can be costly for smaller deployments due to its pricing model, which includes both hourly charges and data processing charges.
- Why it’s rejected: While AWS Transit Gateway is excellent for larger, more complex network architectures, it is relatively expensive compared to other solutions for connecting only two VPCs with moderate data transfer requirements (500 GB/month).
Option B: Implement an AWS Site-to-Site VPN tunnel between the VPCs. Update the route tables of each VPC to use the VPN tunnel for inter-VPC communication.
- Reasoning: AWS Site-to-Site VPN can be used to securely connect two VPCs. However, it involves using a VPN gateway on each VPC and might not be the most cost-effective for high data transfer volumes. The monthly cost for the VPN gateway is relatively low, but there can be additional costs for data transfer (especially for data transferred over public internet links). For 500 GB of data transfer per month, the costs could add up over time.
- Why it’s rejected: VPN is generally not the most cost-effective option when high-volume data transfer is required between VPCs. This solution is better suited for smaller or less frequent data transfer needs, and it can lead to higher costs for the volume of data required.
Option C: Set up a VPC peering connection between the VPCs. Update the route tables of each VPC to use the VPC peering connection for inter-...
Author: VenomousSerpent42 · Last updated Aug 7, 2026
A company hosts multiple applications on AWS for different product lines. The applications use different compute resources, including Amazon EC2 instances and Application Load Balancers. The applications run in different AWS accounts under the same organization in AWS Organizations across multiple AWS Regions. Teams for each product line have tagged each compute resource in the individual accounts.
The company want...
To meet the requirement of tracking the costs for each product line based on the tags applied to the compute resources across multiple AWS accounts and Regions, the company can leverage AWS Cost Allocation Tags and AWS Organizations' consolidated billing features. Here's an evaluation of each option:
Option A: Select a specific AWS generated tag in the AWS Billing console.
- Reasoning: AWS generated tags refer to tags that AWS automatically applies to resources. These tags include things like resource IDs, region information, and others that AWS generates internally for resource identification. While AWS generates many tags, they are not customizable and likely don't correspond directly to the product line tags that the teams have created. Furthermore, the tags the company wants to track are user-defined (e.g., product line-specific tags), not AWS-generated.
- Why it's rejected: This option won’t meet the requirements because AWS-generated tags do not represent the product line-specific information tagged by the teams.
Option B: Select a specific user-defined tag in the AWS Billing console.
- Reasoning: This option is correct because it involves selecting the user-defined tags (e.g., product line tags) that the teams have applied to their compute resources across different AWS accounts. By doing so, the company can track costs in the AWS Billing console based on those tags. Cost Allocation Tags in the Billing console allow for cost tracking by the user-defined tags, which is exactly what the company needs to allocate costs per product line.
- Why it's selected: This is a valid solution because it allows the company to select and track costs based on the specific user-defined tags (product line tags) that the teams have applied to resources.
Option C: Select a specific user-defined tag in the AWS Resource Groups console.
- Reasoning: The AWS Resource Groups console allows you to organize and manage AWS resources based on tags. However, it is not directly related to billing or cost allocation. While you can c...
Author: Mia · Last updated Aug 7, 2026
A company's solutions architect is designing an AWS multi-account solution that uses AWS Organizations. The solutions architect has organized the company's accounts into organizational units (OUs).
The solutions architect needs a solution that will identify any changes to the OU hierarchy. The solution also needs t...
To meet the requirements of identifying changes to the OU hierarchy in AWS Organizations and notifying the operations team, let’s evaluate the options based on key factors like ease of implementation, scalability, and operational overhead:
Option A: Provision the AWS accounts by using AWS Control Tower. Use account drift notifications to identify the changes to the OU hierarchy.
- Reasoning: AWS Control Tower is a service that provides a managed environment for setting up and governing AWS accounts. It includes pre-configured landing zones and integrates with AWS Organizations for account management. Account drift notifications in Control Tower are designed to monitor changes in account configurations, but they are generally related to configuration changes of accounts (like AWS Config rules) rather than changes in the OU hierarchy. Drift notifications may not capture organizational unit changes specifically.
- Why it's rejected: While AWS Control Tower helps with overall governance, drift notifications do not track changes to the OU hierarchy. Therefore, this option would not meet the requirement to monitor OU changes effectively.
Option B: Provision the AWS accounts by using AWS Control Tower. Use AWS Config aggregated rules to identify the changes to the OU hierarchy.
- Reasoning: AWS Config can track configuration changes for resources within an account, and aggregated rules can provide an overview of compliance across accounts in AWS Organizations. However, AWS Config primarily focuses on resource configuration changes, not changes to the AWS Organizations structure or OU hierarchy. It doesn't directly provide a way to track structural changes like changes to OUs themselves.
- Why it's rejected: While AWS Config can track configuration changes, it is not designed to track changes to the OU hierarchy in AWS Organizations, making it unsuitable for this use case.
Option C: Use AWS Service Catalog to create accounts in Organizations. Use an AWS CloudTrail orga...
Author: Emily · Last updated Aug 7, 2026
A company's website handles millions of requests each day, and the number of requests continues to increase. A solutions architect needs to improve the response time of the web application. The solutions architect determines that the application needs to decrease latency when retrieving product deta...
To improve the response time of the web application when retrieving product details from Amazon DynamoDB with minimal operational overhead, let's analyze each option:
A) Set up a DynamoDB Accelerator (DAX) cluster. Route all read requests through DAX.
- DAX is specifically designed for DynamoDB and provides a fully managed, in-memory cache that reduces the time it takes to retrieve data from DynamoDB by caching the results of read operations.
- It integrates directly with DynamoDB, and applications can use it by routing read requests through DAX without needing to make changes to the application code.
- DAX is optimized for read-heavy workloads and offers the lowest latency for DynamoDB queries.
- Operational Overhead: Very low. AWS manages the DAX cluster, and it’s a fully managed service that integrates seamlessly with DynamoDB.
- Best Use Case: When the application requires faster retrieval of frequently accessed items from DynamoDB with minimal changes to the application.
B) Set up Amazon ElastiCache for Redis between the DynamoDB table and the web application. Route all read requests through Redis.
- Redis is an in-memory data store and can be used to cache DynamoDB read results.
- However, integrating Redis with DynamoDB would require more complex setup, including managing cache invalidation and synchronizing data between DynamoDB and Redis.
- Operational Overhead: Higher than DAX. ElastiCache for Redis requires more management (e.g., handling replication, backups, failover, etc.) compared to DAX.
- Best Use Case: Redis is suited for scenarios where more complex caching strategies are needed, such as implementing advanced cache eviction policies or handling use cases like pub/sub. But in this context, it would add unnecessary complexity for DynamoDB caching.
C) Set up Amazon ElastiCache for Memcached between the DynamoDB table and the web application. Route all read requests through Memcached.
- Memcached is also an in-memory data st...
Author: Sofia · Last updated Aug 7, 2026
A solutions architect needs to ensure that API calls to Amazon DynamoDB from Amazon EC2 instances in a VPC do not travel across the internet.
Which combination of steps ...
To ensure that API calls to Amazon DynamoDB from Amazon EC2 instances in a VPC do not travel across the internet, the solutions architect needs to implement private connectivity between the VPC and DynamoDB. This can be done using VPC endpoints.
Let's break down each option:
A) Create a route table entry for the endpoint.
- Selected Reasoning: When you create a VPC endpoint, you need to add an appropriate route to your VPC route table to direct traffic destined for DynamoDB to the VPC endpoint. This ensures that traffic to DynamoDB stays within the AWS network and does not go over the internet.
- Rejection Reasoning: While creating the route table entry is essential, it cannot be done alone. It must be accompanied by setting up the correct endpoint (either gateway or interface). So, this step alone isn't sufficient without a VPC endpoint.
B) Create a gateway endpoint for DynamoDB.
- Selected Reasoning: Gateway endpoints are designed for services like DynamoDB and S3. A DynamoDB gateway endpoint allows traffic between your VPC and DynamoDB to be routed over the AWS backbone network rather than the internet, ensuring that the data doesn't travel across the public internet.
- Rejection Reasoning: Creating an interface endpoint (another option) could also meet the requirements but is generally used for services that do not support gateway endpoints. For DynamoDB, a gateway endpoint is more cost-effective and suitable.
C) Create an interface endpoint for Amazon EC2.
- Rejection Reasoning: Interface endpoints are used to privately connect to services that don't support gateway endpoints, such as AWS services like API Gateway or Lambda. DynamoDB does not require an interf...
Author: Charlotte · Last updated Aug 7, 2026
A company runs its applications on both Amazon Elastic Kubernetes Service (Amazon EKS) clusters and on-premises Kubernetes clusters. The company wants to view all clusters and workloads from a central loca...
To meet the requirement of viewing all Kubernetes clusters and workloads (both Amazon EKS and on-premises Kubernetes clusters) from a central location with the least operational overhead, let's evaluate each option:
A) Use Amazon CloudWatch Container Insights to collect and group the cluster information.
- Rejection Reasoning: CloudWatch Container Insights is used to collect, monitor, and analyze performance metrics and logs from containers running in Amazon EKS and other Kubernetes clusters. While it provides monitoring capabilities and gives insights into the health of the clusters, it does not offer a central management view of all clusters (EKS and on-premises). It is primarily designed for monitoring and not for managing or viewing Kubernetes clusters and workloads from a centralized location.
- Scenario for CloudWatch Container Insights: Best for observing metrics and logs but not for viewing and managing clusters from a central location.
B) Use Amazon EKS Connector to register and connect all Kubernetes clusters.
- Selected Reasoning: Amazon EKS Connector enables you to connect your on-premises Kubernetes clusters and other EKS clusters to the Amazon EKS management console. Once connected, you can view and manage both your Amazon EKS and on-premises Kubernetes clusters from a centralized console. This solution is specifically designed to integrate EKS and non-EKS Kubernetes clusters into a unified management environment. It involves minimal operational overhead, as AWS manages the connectivity and integration.
- Scenario for EKS Connector: Ideal for a hybrid environment with both Amazon EKS and on-premises Kubernetes clusters, where the goal is to have a centralized management view with minimal configuration.
C) Use AWS Systems Manager to collect and view the cluster information.
- Rejection Reasoning: AWS Systems Manager is a service for managing and automating operational tasks across AWS resources, including EC2 instances, but it is not specifically designed ...
Author: Ava · Last updated Aug 7, 2026
A company is building an ecommerce application and needs to store sensitive customer information. The company needs to give customers the ability to complete purchase transactions on the website. The company also needs to ensure that sensitive ...
The company's goal is to store sensitive customer information securely and protect it even from database administrators. Let's evaluate each option based on this requirement:
A) Store sensitive data in an Amazon Elastic Block Store (Amazon EBS) volume. Use EBS encryption to encrypt the data. Use an IAM instance role to restrict access.
- Rejection Reasoning: While EBS encryption helps protect data at rest, it doesn't offer protection from database administrators or internal personnel with sufficient privileges to access the underlying volume directly. Additionally, an IAM instance role only controls access to resources like EC2 instances, but it doesn't specifically protect the data from database administrators if they have access to the system. Therefore, it doesn’t fully meet the requirement to protect sensitive data from privileged users such as database administrators.
- Scenario for EBS Encryption: EBS encryption is useful for securing data stored on EBS volumes, but in this context, it's not sufficient because it doesn’t address the protection of data from privileged access by administrators.
B) Store sensitive data in Amazon RDS for MySQL. Use AWS Key Management Service (AWS KMS) client-side encryption to encrypt the data.
- Rejection Reasoning: RDS encryption is provided by AWS KMS, and while it does protect data at rest, client-side encryption is generally more complicated to manage and not the typical method for encrypting data in RDS. Typically, RDS supports server-side encryption (SSE) with AWS KMS, which handles encryption and decryption automatically. However, using client-side encryption for MySQL can be complex, and it might still expose sensitive data to authorized users (such as database administrators) who can bypass the encryption. To fully protect data from database administrators, using server-side encryption with fine-grained access control is recommended.
- Scenario for Client-Side Encryption: Client-side encryption would be better suited for applications that need to manage encryption keys locally. However, using server-side encryption with AWS KMS is typically easier and more effective for RDS.
C) Store sensitive data in Amazon S3. Use AWS Key Management Service (AWS KMS) server-side encryption to encrypt the data. Use S3 bucket policies to restrict access.
- Selected Reasoning: A...
Author: Amelia · Last updated Aug 7, 2026
A company has an on-premises MySQL database that handles transactional data. The company is migrating the database to the AWS Cloud. The migrated database must maintain compatibility with the company's applications that use the database. The migrated database also mus...
The company needs to migrate an on-premises MySQL database to AWS, maintaining compatibility with existing applications and ensuring automatic scaling during periods of increased demand. Let's evaluate each migration solution:
A) Use native MySQL tools to migrate the database to Amazon RDS for MySQL. Configure elastic storage scaling.
- Rejection Reasoning: RDS for MySQL supports MySQL compatibility, so the database will remain compatible with the company's applications. However, elastic storage scaling does not address automatic scaling of compute resources. This means that during periods of increased demand, the database's compute capacity won't automatically scale, which could lead to performance bottlenecks. Additionally, RDS for MySQL does not have automatic horizontal scaling (i.e., adding more read replicas or resources) to meet fluctuating demand unless configured manually.
- Scenario for RDS for MySQL: This solution works for MySQL compatibility and storage scaling but does not provide automatic compute scaling for high demand periods.
B) Migrate the database to Amazon Redshift by using the mysqldump utility. Turn on Auto Scaling for the Amazon Redshift cluster.
- Rejection Reasoning: Amazon Redshift is a data warehouse service designed for analytical workloads, not transactional databases. Migrating a transactional MySQL database to Redshift would break compatibility with the company's applications, which expect a MySQL-compatible database. Additionally, Redshift's Auto Scaling is focused on data warehousing needs, not on transactional workloads, making it unsuitable for this scenario.
- Scenario for Redshift: Redshift is suitable for analytics and data warehousing but not for transactional workloads or for maintaining compatibility with a MySQL database.
C) Use AWS Database Migration Service (AWS DMS) to migrate the database to Amazon Aurora. Turn on Aurora Auto Scaling.
- Selected Reasoning: Amazon Aurora is a fully ma...
Author: Sam · Last updated Aug 7, 2026
A company runs multiple Amazon EC2 Linux instances in a VPC across two Availability Zones. The instances host applications that use a hierarchical directory structure. The applications need to read and write rapidly and con...
In this scenario, the company needs a shared storage solution that supports rapid and concurrent reads and writes across multiple EC2 instances in different Availability Zones. Here’s an analysis of each option:
Option A: Create an Amazon S3 bucket. Allow access from all the EC2 instances in the VPC.
- Amazon S3 is an object storage service and is not ideal for use as a shared file system for applications requiring rapid, concurrent reads and writes to a hierarchical directory structure. S3 operates with higher latency and is optimized for object storage, not for block-level file system access.
- Key Reasoning: S3 would not meet the high-performance, low-latency requirements of rapidly and concurrently reading/writing from multiple EC2 instances.
- Rejected due to performance constraints and not being suitable for applications that require file system-like behavior (hierarchical structure).
Option B: Create an Amazon Elastic File System (Amazon EFS) file system. Mount the EFS file system from each EC2 instance.
- Amazon EFS is a managed NFS (Network File System) that provides a scalable, shared file system. It can be mounted concurrently from multiple EC2 instances and provides low-latency access to shared storage across multiple Availability Zones.
- Key Reasoning: EFS provides the necessary support for hierarchical directory structures and concurrent read/write access from multiple EC2 instances across Availability Zones. It is ideal for shared file storage in this case.
- Selected Option because it perfectly meets the requirements of the appl...
Author: Noah · Last updated Aug 7, 2026
A solutions architect is designing a workload that will store hourly energy consumption by business tenants in a building. The sensors will feed a database through HTTP requests that will add up usage for each tenant. The solutions architect must use managed services when possible. The workload will receive more features in the fut...
Let's analyze the options based on the requirements of the workload, including using managed services, minimizing operational overhead, and scaling with future features.
Option A: Use Amazon API Gateway with AWS Lambda functions to receive the data from the sensors, process the data, and store the data in an Amazon DynamoDB table.
- Amazon API Gateway allows easy handling of HTTP requests from the sensors and is a fully managed service. It integrates seamlessly with AWS Lambda, a serverless compute service, to process incoming data without the need to manage infrastructure.
- AWS Lambda scales automatically and only charges for execution time, which minimizes operational overhead, and it works well with event-driven architectures.
- Amazon DynamoDB is a fully managed NoSQL database that can store large amounts of data with low-latency access. It handles scalability automatically, which makes it ideal for this workload, especially as the workload grows with more features.
- Key Reasoning: This solution is serverless, highly scalable, and uses fully managed services, minimizing operational overhead. It's easy to maintain and extend as more features are added in the future. DynamoDB is well-suited for storing time-series data like energy consumption.
- Selected Option because it minimizes operational overhead, uses managed services, and scales automatically.
Option B: Use an Elastic Load Balancer (ELB) that is supported by an Auto Scaling group of Amazon EC2 instances to receive and process the data from the sensors. Use an Amazon S3 bucket to store the processed data.
- Elastic Load Balancer distributes traffic to EC2 instances, but this requires managing the infrastructure, scaling policies, and handling EC2 instance health and capacity.
- Amazon S3 is an object storage service that can store the processed data, but it doesn't have the same low-latency, high-performance characteristics as DynamoDB for structured data storage, especially when handling frequent, small updates (like adding hourly energy usage data).
- Key Reasoning: While the solution is scalable with ELB and Auto Scaling, it adds complexity in terms of infrastructure management and does not fit as well for real-time processing and efficient upd...
Author: Liam · Last updated Aug 7, 2026
A solutions architect is designing the storage architecture for a new web application used for storing and viewing engineering drawings. All application components will be deployed on the AWS infrastructure.
The application design must support caching to minimize the amount of time that users wait for the engineering drawings to...
To design a storage architecture that supports the storage and caching requirements for a web application storing engineering drawings, we need to carefully consider both the storage and caching components. The application needs to store petabytes of data and requires caching to minimize loading times for users.
Let’s evaluate each option:
Option A: Amazon S3 with Amazon CloudFront
- Amazon S3: S3 is an ideal storage service for large amounts of unstructured data, such as engineering drawings. It supports petabytes of data, is highly durable, and can be accessed via a simple HTTP-based interface. S3 is cost-effective and scalable.
- Amazon CloudFront: CloudFront is a content delivery network (CDN) that caches content at edge locations, minimizing latency and speeding up access for users by serving cached content from locations closer to them. This makes it an excellent option for caching engineering drawings to speed up loading times.
- Why Selected: This is a well-suited combination. S3 can store the engineering drawings, and CloudFront can efficiently cache the files to reduce load times. This solution provides both scalability for petabytes of data and caching to optimize user experience. It meets all the requirements: scalability, caching, and fast access.
Option B: Amazon S3 Glacier with Amazon ElastiCache
- Amazon S3 Glacier: S3 Glacier is designed for archival storage, not for frequent access or fast loading times. It is optimized for infrequent access to data and can have retrieval times that range from minutes to hours, which makes it unsuitable for an application that requires quick access to engineering drawings.
- Amazon ElastiCache: ElastiCache is typically used for caching data that needs to be accessed frequently, but it is not suitable for storing large volumes of static content like engineering drawings.
- Why Rejected: S3 Glacier is not appropriate for the application’s need for fast access to data. It would introduce significant delays in retrieving engineering drawings, making it unsuitable for this use case.
Option C: Amazon Elastic Block Store (Amazon EBS) volumes with Amazon CloudFront
...
Author: Emily · Last updated Aug 7, 2026
An Amazon EventBridge rule targets a third-party API. The third-party API has not received any incoming traffic. A solutions architect needs to determine whether the rule conditions are being met and ...
To determine whether the EventBridge rule conditions are being met and if the rule's target (the third-party API) is being invoked, the solutions architect needs to verify several key factors:
A) Check for metrics in Amazon CloudWatch in the namespace for AWS/Events.
- Reasoning: CloudWatch Metrics for EventBridge (`AWS/Events`) provide visibility into the success or failure of events being delivered to targets. However, CloudWatch metrics typically show high-level information about event delivery and rule execution but do not provide specific details on whether the third-party API target was successfully invoked.
- Why Rejected: CloudWatch Metrics would help determine if the event was triggered, but they won't confirm whether the target (third-party API) received or processed the event. For troubleshooting this specific issue, you need more detailed visibility into the event flow.
B) Review events in the Amazon Simple Queue Service (Amazon SQS) dead-letter queue.
- Reasoning: If the EventBridge rule is configured to use an Amazon SQS dead-letter queue (DLQ), any failed events (e.g., because of issues with the third-party API) would be delivered to this queue. This would allow you to review failed events.
- Why Rejected: This option is only applicable if the rule is configured to send failed events to an SQS dead-letter queue. If a DLQ is not configur...
Author: Maya2022 · Last updated Aug 7, 2026
A company has a large workload that runs every Friday evening. The workload runs on Amazon EC2 instances that are in two Availability Zones in the us-east-1 Region. Normally, the company must run no more than two instances at all times. However, the company wants to scale up to six instances each Friday to ...
To determine the best solution that meets the company's requirements of scaling EC2 instances to handle a higher workload on Fridays with the least operational overhead, we need to evaluate each option:
A) Create a reminder in Amazon EventBridge to scale the instances.
- Reasoning: Amazon EventBridge could be used to trigger an action like sending a notification or running an automation based on a scheduled event (e.g., every Friday evening). However, simply creating a reminder won't automatically scale the instances; you'd still need to set up custom actions (e.g., Lambda functions) to manually trigger scaling.
- Why Rejected: While EventBridge can help schedule events, it adds unnecessary complexity by requiring additional custom actions and manual intervention for scaling, leading to higher operational overhead compared to a more automated scaling solution.
B) Create an Auto Scaling group that has a scheduled action.
- Reasoning: An Auto Scaling group with a scheduled action allows you to scale your EC2 instances based on a predefined schedule. For example, you can set a scheduled action to scale the instance count up to six every Friday evening, and back to two instances at other times. This solution automates the scaling based on the schedule, reducing manual effort.
- Why Selected: This is the most straightforward and automated solution. It leverages AWS Auto Scaling's built-in scheduling capabilities, ensuring the instances scale according to the specified schedule without needing con...
Author: Suresh · Last updated Aug 7, 2026
A company is creating a REST API. The company has strict requirements for the use of TLS. The company requires TLSv1.3 on the API endpoints. The company also requires a specific public third-party certificate a...
To meet the company's strict requirements for TLSv1.3 and the use of a specific third-party certificate authority (CA), the solution must satisfy the following:
1. Use of TLSv1.3: TLSv1.3 must be enforced, and the solution must be compatible with AWS services supporting this version of TLS.
2. Third-party CA: The certificate must be signed by a specific third-party certificate authority (CA), not a self-signed certificate or an ACM private certificate.
Let’s analyze each option:
Option A:
- Description: Create a certificate on a local machine signed by the third-party CA, then import it into AWS Certificate Manager (ACM). Next, create an HTTP API in Amazon API Gateway with a custom domain, and configure the custom domain to use the certificate.
- Analysis: While this approach allows for the use of a third-party CA, managing certificates locally can be cumbersome. Importing the certificate to ACM from a local machine is possible, but AWS services may not be as seamless in managing certificates this way, and the setup may require additional configuration for automated renewals or management.
- Conclusion: This option is less optimal as it involves more manual steps and could complicate certificate management.
Option B:
- Description: Create a certificate directly in AWS Certificate Manager (ACM) that is signed by the third-party CA. Then, create an HTTP API in Amazon API Gateway with a custom domain, and configure the custom domain to use the certificate.
- Analysis: This option aligns perfectly with the requirements. ACM supports certificates from third-party CAs, and it is integrated with Amazon API Gateway, which can automatically enforce TLSv1.3 for the c...
Author: Emma · Last updated Aug 7, 2026
A company runs an application on AWS. The application receives inconsistent amounts of usage. The application uses AWS Direct Connect to connect to an on-premises MySQL-compatible database. The on-premises database consistently uses a minimum of 2 GiB of memory.
The company wants to migrate the on-premises database to a managed AWS service. The company wants to...
To meet the company's requirements for migrating the on-premises database to a managed AWS service with the least administrative overhead, we need to consider the following factors:
1. Database Compatibility: The on-premises database is MySQL-compatible, so the AWS service should support MySQL-compatible databases.
2. Auto Scaling: The company requires the ability to scale automatically to manage unexpected workload increases.
3. Administrative Overhead: The solution should minimize manual intervention and provide automated management features.
Let's analyze each option:
Option A:
- Description: Provision an Amazon DynamoDB database with default read and write capacity settings.
- Analysis: DynamoDB is a NoSQL database, and while it offers auto-scaling for throughput capacity, it is not MySQL-compatible. Since the company’s application uses a MySQL-compatible database, this option does not meet the compatibility requirement.
- Conclusion: This option is not suitable because DynamoDB is not MySQL-compatible.
Option B:
- Description: Provision an Amazon Aurora database with a minimum capacity of 1 Aurora Capacity Unit (ACU).
- Analysis: Aurora is a MySQL-compatible relational database service. However, this option specifies provisioning an Aurora database with a fixed minimum capacity, which lacks auto-scaling capabilities. This would require manual intervention to adjust capacity as usage increases or decreases, leading to higher administrative overhead.
- Conclusi...
Author: Aria · Last updated Aug 7, 2026
A company wants to use an event-driven programming model with AWS Lambda. The company wants to reduce startup latency for Lambda functions that run on Java 11. The company does not have strict latency requirements for the applications. The company wants to reduce cold starts...
To meet the company's goal of reducing startup latency for AWS Lambda functions running on Java 11, the solution must focus on reducing cold start times and outlier latencies without introducing unnecessary complexity or costs.
Let’s evaluate each option:
Option A: Configure Lambda provisioned concurrency.
- Description: Provisioned concurrency pre-allocates a set number of Lambda function instances, ensuring that they are always warm and ready to handle invocations immediately, which can significantly reduce cold starts.
- Analysis: This is a strong option for reducing cold starts, especially when using Java (which tends to have longer cold start times due to JVM initialization). Provisioned concurrency keeps a specified number of Lambda instances pre-initialized, leading to minimal latency during invocations. This approach does incur an extra cost since you are paying for the pre-warmed Lambda instances, but it is the most effective method to reduce cold start latency for high-volume workloads.
- Conclusion: This is the most effective solution to reduce cold starts but comes at a cost based on the number of pre-warmed instances you configure.
Option B: Increase the timeout of the Lambda functions.
- Description: Increasing the timeout allows the function to run longer, but it doesn't directly address cold starts or reduce latency. Cold starts occur when the function is initially invoked after being idle for a while, and increasing the timeout doesn't reduce the time it takes for the function to be ready to process the request.
- Analysis: While increasing the timeout might prevent the function from timing out during execution, it does not address cold start issues or reduce the startup latency.
- Conclusion: This option does not effectively reduce cold start latency and...
Author: Olivia · Last updated Aug 7, 2026
A financial services company launched a new application that uses an Amazon RDS for MySQL database. The company uses the application to track stock market trends. The company needs to operate the application for only 2 hours at the end of each week. The company needs ...
Given that the company operates its application for only 2 hours each week, the goal is to optimize costs based on usage patterns. Let's evaluate each option for cost-effectiveness, scalability, and suitability.
Option A: Migrate the existing RDS for MySQL database to an Aurora Serverless v2 MySQL database cluster.
- Description: Amazon Aurora Serverless v2 is a highly scalable database service that automatically adjusts its capacity based on demand. It is cost-effective because you only pay for the actual database usage, and it scales down to zero when not in use, reducing costs significantly.
- Analysis: Since the company only needs the database for 2 hours a week, Aurora Serverless v2 is an ideal solution because it allows the database to automatically scale down to zero during idle periods, ensuring the company only pays for the actual 2 hours of usage. This is both cost-effective and optimized for the company's low-frequency use case.
- Conclusion: This option provides the most cost-effective solution, as it minimizes costs during the idle periods and automatically adjusts capacity as needed.
Option B: Migrate the existing RDS for MySQL database to an Aurora MySQL database cluster.
- Description: Amazon Aurora (standard) is a fully managed relational database service that offers high availability and scalability, but unlike Aurora Serverless, it requires you to provision and pay for a minimum instance size even when the database is not in use.
- Analysis: Aurora MySQL would be a good solution for more consistently high usage or production environments, but it is not as cost-efficient as Aurora Serverless for the company's needs. The company would still incur costs for the database instance running continuously, even during the idle periods (e.g., the 166 hours per week when the database is not in use).
- Conclusion: This option is more costly because the database would be running continuously, which is not optimal given the company's intermittent usage.
...
Author: Ethan · Last updated Aug 7, 2026
A company deploys its applications on Amazon Elastic Kubernetes Service (Amazon EKS) behind an Application Load Balancer in an AWS Region. The application needs to store data in a PostgreSQL database engine. The company wants the data in the database to be highly available. The company also ne...
The company requires a highly available PostgreSQL database with increased capacity for read workloads. Let's break down the options to find the solution that best meets these needs with the most operational efficiency:
Option A: Create an Amazon DynamoDB database table configured with global tables.
- Description: DynamoDB is a NoSQL database, and while it offers high availability and the ability to scale globally with DynamoDB global tables, it is not compatible with PostgreSQL. The company's application specifically requires a PostgreSQL database engine, which means DynamoDB is not a valid solution.
- Analysis: While DynamoDB offers high availability and scalability, it does not meet the requirement for using PostgreSQL. Therefore, this option is not applicable to the problem.
- Conclusion: This option is rejected because it does not support PostgreSQL.
Option B: Create an Amazon RDS database with Multi-AZ deployments.
- Description: Amazon RDS Multi-AZ deployments provide high availability by automatically replicating database updates to a standby instance in a different Availability Zone. This solution ensures database failover in case of an Availability Zone failure.
- Analysis: Multi-AZ deployments for Amazon RDS provide high availability, but it only addresses the requirement for high availability, not the need for increased read capacity. In Multi-AZ configurations, the standby database cannot be used for read workloads, meaning that read scalability would be limited.
- Conclusion: While this option addresses high availability, it does not address the increased read workload requirement effectively. Therefore, it is not the best solution for this scenario.
Option C: Create an Amazon RDS database with Multi-AZ DB cluster deployment.
- Description: Amazon RDS for PostgreSQL supports Multi-AZ DB clusters for...
Author: Olivia Johnson · Last updated Aug 7, 2026
A company is building a RESTful serverless web application on AWS by using Amazon API Gateway and AWS Lambda. The users of this web application will be geographically distributed, and the company wants to reduce the latency of API requests...
In this scenario, the company wants to reduce the latency of API requests for users who are geographically distributed. Let’s break down the options and their relevance to the scenario:
A) Private endpoint:
- Explanation: Private endpoints are used for APIs that are accessible only within a specific Amazon Virtual Private Cloud (VPC). These endpoints provide private connectivity to API Gateway without exposing the API to the public internet.
- Why it’s not ideal: Since the users are geographically distributed, they would not benefit from private endpoints because this solution is best suited for internal applications where the traffic is restricted to a particular VPC. It doesn't reduce latency for users spread across different regions.
B) Regional endpoint:
- Explanation: Regional endpoints allow API Gateway to create a regional API endpoint for users within a specific AWS region. This means the API is accessible from the internet but is hosted in a particular region (e.g., US East or US West).
- Why it’s not ideal: While regional endpoints improve latency for users within the specific region, they do not help reduce latency for users in other parts of the world. Users outside the region will experience higher latency since requests have to travel further to reach the API.
C) Interface VPC endpoint:
- Explanation: Interface VPC endpoints are used to c...
Author: Sophia · Last updated Aug 7, 2026
A company uses an Amazon CloudFront distribution to serve content pages for its website. The company needs to ensure that clients use a TLS certificate when accessing the company's website. The company wants to automate the creation and renewal of...
In this case, the company needs a solution that ensures clients use a TLS certificate when accessing the website, while also automating the creation and renewal of the TLS certificates. Let’s evaluate each option based on these requirements.
A) Use a CloudFront security policy to create a certificate.
- Explanation: CloudFront security policies are used to configure SSL/TLS settings for your distribution, such as the supported TLS versions and ciphers. However, security policies themselves do not create or manage certificates.
- Why it’s not ideal: This option does not address the need for automating the creation or renewal of TLS certificates. CloudFront security policies only deal with SSL/TLS protocol settings, not the actual certificates.
B) Use a CloudFront origin access control (OAC) to create a certificate.
- Explanation: CloudFront Origin Access Control (OAC) is a mechanism used to control access between CloudFront and the origin server. It can secure the connection between CloudFront and the origin, but it does not handle the creation or management of certificates.
- Why it’s not ideal: Similar to option A, OAC does not fulfill the requirement to automate the creation and renewal of TLS certificates. It’s more concerned with securing the traffic between CloudFront and the origin.
C) Use AWS Certificate Manager (ACM) to create a certificate. Use DNS validation for the domain.
- Explanation: AWS Certificate Manager (ACM) is a service that helps manage SSL/TLS certificates, including creating, renewing, and deploying them. DNS valida...
Author: Emma · Last updated Aug 7, 2026
A company deployed a serverless application that uses Amazon DynamoDB as a database layer. The application has experienced a large increase in users. The company wants to improve database response time from milliseconds to microseconds and to cache r...
To improve the response time of a serverless application using Amazon DynamoDB and to cache requests, the solution must focus on reducing the database's response time from milliseconds to microseconds, while also minimizing operational overhead. Let's evaluate each option:
A) Use DynamoDB Accelerator (DAX).
- Explanation: DynamoDB Accelerator (DAX) is a fully managed, in-memory cache for DynamoDB that delivers microsecond response times for read-heavy workloads. DAX is designed specifically for DynamoDB, and it integrates seamlessly with the existing DynamoDB table, providing automatic caching of frequently accessed data.
- Why this is ideal: DAX directly addresses the requirement to reduce response times from milliseconds to microseconds. It is a fully managed service that reduces operational overhead by automatically caching DynamoDB read requests, and it integrates seamlessly with the existing DynamoDB infrastructure. This provides the least operational overhead since it requires no manual configuration of external caching systems.
B) Migrate the database to Amazon Redshift.
- Explanation: Amazon Redshift is a fully managed data warehouse designed for analytical workloads, optimized for complex queries and large-scale data processing.
- Why it’s not ideal: While Redshift is great for analytics and complex queries on large datasets, it is not designed to replace DynamoDB for low-latency transactional workloads. Migrating to Redshift would be overkill and would introduce significant operational overhead, as the application would need to be adapted to use a completely different database type with different query and data models....
Author: Benjamin · Last updated Aug 7, 2026
A company runs an application that uses Amazon RDS for PostgreSQL. The application receives traffic only on weekdays during business hours. The company wants to optimize costs and reduce operat...
To optimize costs and reduce operational overhead for an Amazon RDS for PostgreSQL database used during specific hours (weekdays, business hours), the company needs a solution that aligns with these usage patterns while minimizing unnecessary expenses. Let’s evaluate each option:
A) Use the Instance Scheduler on AWS to configure start and stop schedules.
- Explanation: The Instance Scheduler is a managed solution that allows you to automatically start and stop Amazon EC2 instances, Amazon RDS instances, and other AWS resources according to a defined schedule. The application only receives traffic during business hours on weekdays, so stopping the database during off-hours (nights and weekends) will save costs.
- Why this is ideal: This solution directly meets the company’s needs. It allows the database to automatically stop when not in use (outside of business hours) and start again when needed (during business hours). Since the database is not required during off-hours, this optimizes costs without requiring manual intervention. It is also fully managed, reducing operational overhead.
B) Turn off automatic backups. Create weekly manual snapshots of the database.
- Explanation: Turning off automatic backups and creating manual snapshots reduces costs, as automated backups incur storage charges. However, this solution introduces risks because it reduces the ability to restore the database to any point in time within the retention window. Snapshots also require manual management.
- Why it’s not ideal: Although this solution reduces storage costs, it introduces the risk of losing automated backups and complicates the recovery process. Also, it does not address the primary concern of optimizing database usage during business hours only. The database will still be running outside business hours, so it doesn't fully optimize costs.
C) Create a custom AWS L...
Author: Emma · Last updated Aug 7, 2026
A company uses locally attached storage to run a latency-sensitive application on premises. The company is using a lift and shift method to move the application to the AWS Cloud. The company does not want to change the ...
In this case, the company is moving a latency-sensitive application to the AWS Cloud without changing the application architecture, and it is using a "lift and shift" approach. The goal is to find a cost-effective solution while maintaining the required performance characteristics of the application. Let’s break down each option:
A) Configure an Auto Scaling group with an Amazon EC2 instance. Use an Amazon FSx for Lustre file system to run the application.
- Explanation: Amazon FSx for Lustre is a high-performance file system optimized for workloads like machine learning, high-performance computing (HPC), and other latency-sensitive applications. It is often used for data-intensive tasks.
- Why it’s not ideal: FSx for Lustre is more suited for specialized high-performance workloads rather than being a general-purpose solution. Additionally, using Lustre introduces complexity and higher costs that may not be justified for this use case. Since the application doesn't require such high-performance file system features, this solution would likely be overkill and more expensive than necessary.
B) Host the application on an Amazon EC2 instance. Use an Amazon Elastic Block Store (Amazon EBS) GP2 volume to run the application.
- Explanation: Amazon EBS GP2 volumes are general-purpose SSD volumes designed for a broad range of use cases, providing consistent and low-latency performance for applications running on EC2 instances.
- Why it’s not ideal: While GP2 volumes provide good performance for many workloads, they are based on a burstable performance model. For latency-sensitive applications, this could result in performance inconsistencies, especially if the volume reaches its burst limit. GP2 is not optimized for predictable low-latency performance at scale, making it less ideal for this use case.
C) Configure an Auto Scaling group with an Amazon EC2 instance. Use an Amazon FSx for OpenZ...
Author: Max · Last updated Aug 7, 2026
A company runs a stateful production application on Amazon EC2 instances. The application requires at least two EC2 instances to always be running.
A solutions architect needs to design a highly available and fault-tolerant architecture for the application. The solutions architect creates an Auto...
To design a highly available and fault-tolerant architecture for an application running on Amazon EC2 instances in an Auto Scaling group, it's essential to ensure that the application can withstand failures while maintaining the required minimum capacity of EC2 instances.
Let's analyze each option to determine the best course of action based on the requirements:
A) Set the Auto Scaling group's minimum capacity to two. Deploy one On-Demand Instance in one Availability Zone and one On-Demand Instance in a second Availability Zone.
- Reasoning: This option ensures that the application will always have two EC2 instances running, each in a separate Availability Zone. This provides high availability in case one Availability Zone experiences a failure.
- Analysis: While the Auto Scaling group will have a minimum capacity of two, the deployment of On-Demand Instances in two separate Availability Zones ensures fault tolerance. However, this setup doesn't account for the fact that an On-Demand instance could become unavailable for reasons like EC2 instance failure or a scaling event. The setup seems adequate but does not fully take into account Auto Scaling's flexibility to meet demand efficiently.
- Conclusion: This setup is a good option as it meets the minimum capacity requirements and ensures high availability.
B) Set the Auto Scaling group's minimum capacity to four. Deploy two On-Demand Instances in one Availability Zone and two On-Demand Instances in a second Availability Zone.
- Reasoning: The Auto Scaling group will always have at least four instances running, two in each Availability Zone. This increases the capacity compared to the minimum requirement.
- Analysis: While this ensures high availability and fault tolerance by using two Availability Zones, setting the minimum capacity to four exceeds the minimum requirement of two instances and could unnecessarily incur higher costs. It might be useful in situations where you need additional...
Author: Suresh · Last updated Aug 7, 2026
An ecommerce company uses Amazon Route 53 as its DNS provider. The company hosts its website on premises and in the AWS Cloud. The company's on-premises data center is near the us-west-1 Region. The company uses the eu-central-1 Region to host the website. The compa...
In this scenario, the company wants to minimize website load time for users by directing them to the nearest server, whether on-premises or in the AWS Cloud, based on their geographic location. To achieve this, the company can use different Amazon Route 53 routing policies.
A) Set up a geolocation routing policy. Send the traffic that is near us-west-1 to the on-premises data center. Send the traffic that is near eu-central-1 to eu-central-1.
- Reasoning: Geolocation routing allows you to send traffic to different resources based on the geographic location of the users. By setting up this policy, traffic from users near the us-west-1 Region will be directed to the on-premises data center, while traffic from users near the eu-central-1 Region will be directed to the AWS Cloud instance in eu-central-1.
- Analysis: This approach ensures that users are routed to the closest available resource based on their physical proximity. This minimizes latency by serving traffic from the closest server, reducing load times effectively.
- Conclusion: This solution is ideal as it fulfills the objective of minimizing load time by routing users to the nearest resource, whether on-premises or in the AWS Cloud, based on geolocation.
B) Set up a simple routing policy that routes all traffic that is near eu-central-1 to eu-central-1 and routes all traffic that is near the on-premises datacenter to the on-premises data center.
- Reasoning: A simple routing policy would direct traffic based on static conditions like proximity. However, it does not take into account routing based on actual server performance or load times. It simply routes all traffic near specific locations to those locations without considering latency or server health.
- Analysis: Although this approach will send traffic to the closest location, it doesn't account for any dynamic changes in load or performance. For example, if the on-premises data center experiences a performance issue, users near it would still be directed there, which could result in slower load times.
- Conclusion: While functional, a...
Author: Benjamin · Last updated Aug 7, 2026
A company has 5 PB of archived data on physical tapes. The company needs to preserve the data on the tapes for another 10 years for compliance purposes. The company wants to migrate to AWS in the next 6 months. The data center that stores the tapes has...
To find the most cost-effective solution for migrating 5 PB of archived data on physical tapes to AWS, considering the 1 Gbps uplink and compliance requirements, let's analyze each option:
A) Read the data from the tapes on premises. Stage the data in a local NFS storage. Use AWS DataSync to migrate the data to Amazon S3 Glacier Flexible Retrieval.
- Reasoning: AWS DataSync can be used to migrate data from on-premises storage to Amazon S3 Glacier Flexible Retrieval, which is cost-effective for archival purposes. However, staging the data on NFS storage before using DataSync introduces unnecessary complexity and cost, and the 1 Gbps uplink will be slow for migrating such a large volume (5 PB).
- Analysis: This option involves multiple steps—reading from the tapes, staging in local storage, and then transferring to AWS. With 1 Gbps bandwidth, it would take an extended period to transfer 5 PB of data, making it inefficient and costly. Additionally, storing data temporarily on local NFS storage increases complexity and costs further.
- Conclusion: This approach is less efficient in terms of both time and cost.
B) Use an on-premises backup application to read the data from the tapes and to write directly to Amazon S3 Glacier Deep Archive.
- Reasoning: This solution involves using a backup application to read the data from the physical tapes and directly write to S3 Glacier Deep Archive. Glacier Deep Archive is a very low-cost storage class designed for long-term retention.
- Analysis: This approach allows for a direct transfer of data to a cost-effective archive storage service without the need for intermediary storage. However, writing directly from the backup application might still be slow with the 1 Gbps bandwidth for such a large amount of data, and backup applications may not be optimized for this task, potentially adding complexity.
- Conclusion: This option is feasible but might be inefficient due to slow transfer speeds and the complexity of managing large-scale tape data migration directly through a backup application.
C) Order multiple AWS Snowball devices that...
Author: ShadowWolf101 · Last updated Aug 7, 2026
A company is deploying an application that processes large quantities of data in parallel. The company plans to use Amazon EC2 instances for the workload. The network architecture must be configurable to prevent groups of nodes...
To meet the requirement of ensuring that groups of nodes do not share the same underlying hardware, we need to focus on the concept of placement groups in Amazon EC2. The network architecture needs to ensure that instances are distributed across distinct physical hardware to minimize the impact of hardware failures on the application.
A) Run the EC2 instances in a spread placement group.
- Reasoning: A spread placement group ensures that EC2 instances are placed on distinct physical hardware within a single Availability Zone. This configuration is specifically designed to prevent instances from sharing the same underlying hardware and helps increase the fault tolerance of the application.
- Analysis: Since the requirement is to prevent groups of nodes from sharing the same underlying hardware, this solution fits perfectly. Instances in a spread placement group are distributed across multiple racks and hosts within the same Availability Zone, minimizing the risk of failure due to hardware issues. This makes it a great choice for applications that require high availability and fault tolerance.
- Conclusion: This option directly addresses the need to prevent instances from sharing the same underlying hardware, making it the best solution for the given requirement.
B) Group the EC2 instances in separate accounts.
- Reasoning: Grouping EC2 instances in separate AWS accounts is a logical separation strategy often used for organizational or billing purposes, but it does not directly control or manage how instances are distributed across physical hardware.
- Analysis: While this might provide isolation for security or management reasons, it does not fulfill the specific requirement of ensuring that EC2 instances do not share the same underlying hardware. This solution does not guarantee the physical s...
Author: Sam · Last updated Aug 7, 2026
A solutions architect is designing a disaster recovery (DR) strategy to provide Amazon EC2 capacity in a failover AWS Region. Business requirements state that the DR strategy must meet ...
To design a disaster recovery (DR) strategy for providing Amazon EC2 capacity in a failover AWS Region, the solution must guarantee that the necessary capacity will be available in the failover region when required. Let's evaluate each option:
A) Purchase On-Demand Instances in the failover Region.
- Reasoning: On-Demand Instances allow for flexible, pay-as-you-go capacity in the failover Region. However, they do not guarantee that specific capacity will be available when needed.
- Analysis: While On-Demand Instances are easy to scale and do not require long-term commitments, they come with the risk of insufficient capacity during peak demand periods, especially in a failover scenario. AWS might not be able to provide the required capacity if the region is experiencing high demand.
- Conclusion: This option does not provide a guarantee of capacity, which is a critical requirement for disaster recovery.
B) Purchase an EC2 Savings Plan in the failover Region.
- Reasoning: EC2 Savings Plans offer discounted pricing in exchange for a commitment to specific usage (in terms of EC2 usage and instance types).
- Analysis: Although EC2 Savings Plans can offer cost savings, they do not guarantee capacity in the failover region. Savings Plans are tied to usage but do not ensure that the capacity needed will be available when a failover occurs. They are more suited for cost optimization rather than ensuring capacity availability.
- Conclusion: This option does not guarantee the availability of EC2 capacity in the failover region, so it does not meet t...
Author: Evelyn · Last updated Aug 7, 2026
A company has five organizational units (OUs) as part of its organization in AWS Organizations. Each OU correlates to the five businesses that the company owns. The company's research and development (R&D) business is separating from the company and will need its own organization. A solutions architect crea...
When a business unit like the R&D business separates and requires its own AWS Organization, the solutions architect must carefully choose the right method to achieve this while ensuring smooth transitions without conflicts or data loss.
Let's evaluate the options one by one:
Option A: Have the R&D AWS account be part of both organizations during the transition.
- Reasoning: An AWS account can only be a member of one organization at a time. It cannot belong to two organizations simultaneously. This violates AWS's structural limitations.
- Rejected: Since AWS does not allow an account to be part of two organizations at the same time, this option is not feasible.
Option B: Invite the R&D AWS account to be part of the new organization after the R&D AWS account has left the prior organization.
- Reasoning: This approach involves moving the R&D AWS account from the old organization to the new one. However, this approach requires removing the account from the original organization before it can join the new one.
- Rejected: Although possible, the complexity arises from the fact that any move requires a clean transition, meaning there could be a gap in management or control. The solutions architect might prefer a more direct method to ensure resources are effectively managed during this transition.
Option C: Create a new R&D AWS account in the new organization. Migrate resources from the prior R&D AWS account to the new R&D AW...
Author: James · Last updated Aug 7, 2026
A company is designing a solution to capture customer activity in different web applications to process analytics and make predictions. Customer activity in the web applications is unpredictable and can increase suddenly. The company requires a solution that integrates with other web applic...
Let's evaluate each of the options based on the requirements provided:
Key Requirements:
- Capture customer activity from unpredictable web applications, which may increase suddenly (needs scalability).
- Integrate with other web applications.
- Authorization is required for security purposes.
Option A: Configure a Gateway Load Balancer (GWLB) in front of an Amazon Elastic Container Service (Amazon ECS) container instance that stores the information in an Amazon Elastic File System (EFS) file system. Authorization is resolved at the GWLB.
- Reasoning: The Gateway Load Balancer (GWLB) is typically used for managing third-party virtual appliances for network traffic processing, like firewalls or intrusion detection systems, and it's not ideal for handling API requests and data ingestion directly from web applications. It is not optimized for direct interaction with applications in terms of data capture and authorization processes.
- Rejected: This option doesn't fit the use case as it involves unnecessary complexity and doesn't directly align with the need to handle API traffic and manage authorization for analytics processing. It's not a good fit for the customer activity capture and analytics context.
Option B: Configure an Amazon API Gateway endpoint in front of an Amazon Kinesis data stream that stores the information in an Amazon S3 bucket. Use an AWS Lambda function to resolve authorization.
- Reasoning: This option uses API Gateway to expose an endpoint, allowing integration with web applications. It then streams the data into an Amazon Kinesis data stream, which can be processed in real time, and eventually stores the data in an S3 bucket for further analytics. The AWS Lambda function handling the authorization adds an additional layer of security.
- Pros: API Gateway can easily integrate with web applications, Kinesis is scalable and handles unpredictable increases in data, and Lambda offers flexible, on-demand processing for authorization.
- Selected: This option meets the requirements well. API Gateway can authenticate and authorize requests before they reach the Kinesis stream, making it a good choice for handling customer activity and analytics in real time.
Option C: Configure an Amazon API Gateway endpoint in front of an Ama...
Author: Zara · Last updated Aug 7, 2026
An ecommerce company wants a disaster recovery solution for its Amazon RDS DB instances that run Microsoft SQL Server Enterprise Edition. The company's current recovery point objective (RPO) and recovery time object...
Let's evaluate each option based on the company's disaster recovery requirements, which are a recovery point objective (RPO) of 24 hours and a recovery time objective (RTO) of 24 hours. The goal is to find the most cost-effective solution.
Option A: Create a cross-Region read replica and promote the read replica to the primary instance.
- Reasoning: This solution involves creating a cross-Region read replica of the RDS DB instance. Read replicas are designed for replication of data from the primary instance but are typically used for read scaling or disaster recovery in case the primary instance becomes unavailable. If the primary instance fails, the read replica can be promoted to a primary instance. However, cross-Region replication for Microsoft SQL Server is only supported for SQL Server Standard Edition, and not for the Enterprise Edition, as in the scenario.
- Rejected: This option isn't applicable for Microsoft SQL Server Enterprise Edition, so it doesn't meet the company's requirements. Additionally, managing cross-Region read replicas can incur extra costs compared to other methods.
Option B: Use AWS Database Migration Service (AWS DMS) to create RDS cross-Region replication.
- Reasoning: AWS DMS allows for data replication between databases, including between Regions. While DMS can be used for cross-Region replication, it is generally more suitable for migration and ongoing replication scenarios. DMS is not typically designed as a native disaster recovery solution because of potential performance overhead and complexity involved in replicating data continuously.
- Rejected: DMS is not an ideal solution for a disaster recovery scenario, especially considering it may not meet the desired RPO and RTO objectives for high availability in real-time environments. Additionally, it may not provide the same seamless failover process as other solutions.
Option C: Use cross-Region replication every 24 hours to copy native backups to an Amazon S3 bucket.
- Reasoning...
Author: Emma · Last updated Aug 7, 2026
A company runs a web application on Amazon EC2 instances in an Auto Scaling group behind an Application Load Balancer that has sticky sessions enabled. The web server currently hosts the user session state. The company wants to ensure high availability and av...
The requirement is to ensure high availability and avoid user session state loss in the event of a web server outage. Let's evaluate the options based on these goals, which include minimizing session loss, supporting high availability, and being suitable for a scalable web application.
Option A: Use an Amazon ElastiCache for Memcached instance to store the session data. Update the application to use ElastiCache for Memcached to store the session state.
- Reasoning: ElastiCache for Memcached is a highly scalable, in-memory key-value store that can be used to store session data. It provides low-latency and high-throughput performance. However, Memcached is not persistent by default and does not provide built-in persistence or replication features. If an outage occurs, the session data could be lost.
- Rejected: While it offers performance, it lacks durability and persistence, making it unsuitable for maintaining session data in the event of an outage. It may be suitable for scenarios with transient session data, but not for high availability and persistence.
Option B: Use Amazon ElastiCache for Redis to store the session state. Update the application to use ElastiCache for Redis to store the session state.
- Reasoning: ElastiCache for Redis is an in-memory data store that provides durability and persistence options. Redis supports replication, automatic failover, and persistence (via snapshots), making it an excellent option for high availability and ensuring that session state is not lost during web server outages.
- Selected: Redis is a strong choice for storing session data due to its high availability features, support for persistence, and the ability to replicate data across multiple nodes. This ensures that even if one server goes down, session data remains accessible, providing both high availability and fault tolerance.
Option C: Use an AWS Storage Gateway cached v...
Author: Daniel · Last updated Aug 7, 2026
A company migrated a MySQL database from the company's on-premises data center to an Amazon RDS for MySQL DB instance. The company sized the RDS DB instance to meet the company's average daily workload. Once a month, the database performs slowly when the company runs queries for a report. The company wants to...
The company's goal is to run monthly reports without affecting the performance of the daily workloads, and they are experiencing slower performance during report runs. Let's evaluate each option based on performance, cost, and practicality.
Option A: Create a read replica of the database. Direct the queries to the read replica.
- Reasoning: Creating a read replica of the RDS MySQL database allows for the distribution of read traffic across the primary DB instance and the read replica. This can help alleviate the load on the primary instance when running read-heavy operations like reports. The read replica can be used to handle the reporting queries, keeping the primary instance available for the daily workload.
- Selected: This is a suitable solution because read replicas are designed to handle read traffic and can offload reporting queries, which are typically read-intensive, from the primary instance. It allows the daily workload to continue running smoothly while the reporting queries are directed to the read replica. Additionally, RDS read replicas are cost-effective for scaling read-heavy workloads without the complexity of managing multiple full-fledged instances.
Option B: Create a backup of the database. Restore the backup to another DB instance. Direct the queries to the new database.
- Reasoning: Creating a backup and restoring it to another DB instance could provide an isolated environment to run the reporting queries. However, this process is manual, and maintaining a separate instance specifically for reports would introduce additional overhead for synchronization and management. Also, it may take time to restore the backup, which could impact the ability to run reports promptly.
- Rejected: While this approach may work, it is not ideal due to the additional management required for keeping the backup instance synchronized with the primary database. It also adds complexity and might not be efficient for running reports regularly.
Option C: Export the data to Amazon S3. Use Amazon Athena to query the S3 bucket.
- Reasoning: Exporting data to S3 ...
Author: Mia · Last updated Aug 7, 2026
A company runs a container application by using Amazon Elastic Kubernetes Service (Amazon EKS). The application includes microservices that manage customers and place orders. The company needs to route incoming requests to t...
To determine the most cost-effective solution for routing incoming requests to the appropriate microservices running on Amazon EKS, we need to assess the options based on key factors such as cost, scalability, flexibility, and ease of integration.
Option A: Use the AWS Load Balancer Controller to provision a Network Load Balancer
- Scenario: Network Load Balancers (NLBs) are typically used for routing TCP traffic or providing low-latency, high-throughput traffic routing.
- Pros: NLBs are cost-effective for high-performance network traffic.
- Cons: NLBs are not application-aware, which means they cannot route traffic based on HTTP/HTTPS requests, headers, or URL paths. This makes them unsuitable for routing traffic to specific microservices based on business logic.
- Conclusion: While NLBs are cost-effective in some scenarios (especially for TCP traffic), they are not the best fit for routing to microservices based on application-level logic, such as HTTP methods or URLs.
Option B: Use the AWS Load Balancer Controller to provision an Application Load Balancer
- Scenario: Application Load Balancers (ALBs) are designed for HTTP/HTTPS traffic and can route based on URL paths, host headers, and query strings, making them ideal for routing traffic to microservices.
- Pros: ALBs are application-aware, allowing for more granular routing to microservices. They also support path-based routing, making them a natural fit for a containerized application with multiple microservices.
- Cons: While ALBs are generally cost-effective for HTTP/HTTPS traffic, they come with an additional cost for features like routing and monitoring. However, the costs are typically still lower than the more complex options like API Gateway or Lambda.
- Conclusion: ALBs are a great choice for microservices architectures, as they provide fine-grained control over how traffic is routed to specific services.
Option C: Use an AWS Lambda function to connect the requests to Amazon EKS
- Scenario: Using AWS Lambda to han...
Author: StarryEagle42 · Last updated Aug 7, 2026
A company uses AWS and sells access to copyrighted images. The company's global customer base needs to be able to access these images quickly. The company must deny access to users from specific countries. The company...
Let's analyze each of the options in light of the company's requirements: quick global access to copyrighted images, denying access from specific countries, and minimizing costs.
Option A: Use Amazon S3 to store the images. Turn on multi-factor authentication (MFA) and public bucket access. Provide customers with a link to the S3 bucket.
- Scenario: The images are stored in S3 with public access enabled, and MFA is used to add security.
- Pros: This setup is simple to configure.
- Cons: Enabling public access means that anyone with the link can access the images, which doesn't meet the requirement to restrict access to users from specific countries. Moreover, public access to S3 introduces significant security risks, and it's difficult to control traffic based on geolocation. It also does not allow for the flexibility to restrict users from specific countries.
- Conclusion: This option is not ideal as it lacks the necessary access control mechanisms for country-based restrictions and could introduce security concerns.
Option B: Use Amazon S3 to store the images. Create an IAM user for each customer. Add the users to a group that has permission to access the S3 bucket.
- Scenario: Images are stored in S3, and each customer has an IAM user with permissions to access the images.
- Pros: This approach ensures that each customer has secure access to the images and allows for finer control over who can access the images.
- Cons: While IAM users can provide secure access, managing IAM users at this scale can be cumbersome, especially for a global customer base. It would also be difficult to implement country-based access restrictions with this method. Additionally, this option doesn't help optimize costs, as the company needs to manage individual IAM credentials and permissions for each customer.
- Conclusion: This approach could work for smaller-scale applications with few customers but is not scalable, cost-efficient, or ideal for controlling access based on countries.
Option C: Use Amazon EC2 instances that are behind Application Load Balancers (ALBs) to store the images. Deploy the instances only in the countries the company services. P...
Author: Ava · Last updated Aug 7, 2026
A solutions architect is designing a highly available Amazon ElastiCache for Redis based solution. The solutions architect needs to ensure that failures do not result in performance degradation or loss of data locally and within an AWS Region. The solution needs to p...
To meet the requirement of high availability for the Amazon ElastiCache for Redis solution, ensuring no performance degradation or data loss both locally and within an AWS Region, we need to carefully assess the options.
Option A: Use Multi-AZ Redis replication groups with shards that contain multiple nodes.
- Scenario: This configuration uses a Multi-AZ Redis replication group with multiple nodes across different availability zones (AZs).
- Pros: Multi-AZ replication ensures high availability by replicating data across different AZs within a region. If a failure occurs in one AZ, Redis can failover to a replica in another AZ, preventing performance degradation and data loss. The use of multiple nodes within the shards ensures that there is redundancy at the node level as well.
- Cons: The main limitation here is the complexity of managing a multi-AZ Redis replication group with sharding, which involves distributing data across multiple nodes in different AZs. However, this configuration provides high availability both locally (within an AZ) and at the region level.
- Conclusion: This is the best solution as it meets the need for both node-level and region-level high availability and ensures that failures do not result in data loss or performance degradation.
Option B: Use Redis shards that contain multiple nodes with Redis append-only files (AOF) turned on.
- Scenario: This option involves Redis shards with multiple nodes, and Redis append-only files (AOF) enabled for durability.
- Pros: AOF provides durability by writing every write operation to a log, which can help prevent data loss.
- Cons: While AOF ensures durability, it does not provide high availability or automatic failover across multiple AZs. If a node or an entire AZ fails, there is no automatic failover to another AZ or region. The AOF mechanism can also increase I/O load and latency depending o...
Author: Layla · Last updated Aug 7, 2026
A company plans to migrate to AWS and use Amazon EC2 On-Demand Instances for its application. During the migration testing phase, a technical team observes that the application takes a long time to launch and load memory to become fully pro...
To address the issue of long launch times for the application during the migration testing phase, let's analyze the different options based on their effectiveness in reducing the time it takes for the application to launch and become productive.
Option A: Launch two or more EC2 On-Demand Instances. Turn on auto scaling features and make the EC2 On-Demand Instances available during the next testing phase.
- Scenario: This involves scaling out by launching multiple EC2 instances and using Auto Scaling.
- Pros: Auto Scaling can dynamically increase the number of instances based on load, which can help handle varying traffic. However, it does not specifically address the long launch times of individual instances.
- Cons: This solution focuses on scaling and availability but does not address the core issue of reducing the launch time of a single instance. Launching multiple instances won't help reduce the startup latency of the application.
- Conclusion: This is not the best solution for reducing launch time, as it only deals with scaling the application, not optimizing the startup of individual instances.
Option B: Launch EC2 Spot Instances to support the application and to scale the application so it is available during the next testing phase.
- Scenario: This option involves using EC2 Spot Instances, which are cheaper but may be interrupted by AWS when there is higher demand for capacity.
- Pros: Spot Instances can reduce costs but allow scaling.
- Cons: Spot Instances are not ideal for applications with critical performance or availability requirements, as they can be terminated at any time with short notice. Additionally, they do not specifically address the issue of reducing instance launch time.
- Conclusion: This is not a suitable option for reducing launch time and would introduce instability due to potential interruptions from Spot Instances.
Option C: Launch the EC2 On-Demand Instances with hibernation turned on. Conf...
Author: Lina Zhang · Last updated Aug 7, 2026
A company's applications run on Amazon EC2 instances in Auto Scaling groups. The company notices that its applications experience sudden traffic increases on random days of the week. The company wants to maintain application performance ...
To determine the most cost-effective solution for maintaining application performance during sudden traffic increases, we need to evaluate each option based on the ability to handle unpredictable traffic spikes while minimizing unnecessary costs.
Option A: Use manual scaling to change the size of the Auto Scaling group.
- Scenario: Manual scaling involves manually adjusting the desired capacity of the Auto Scaling group based on observed traffic increases.
- Pros: Simple to configure and provides direct control over scaling.
- Cons: This option does not address the problem of unpredictable, sudden traffic increases. It requires the team to manually adjust the scaling settings each time there is a traffic spike, which could lead to delays in scaling and potential performance degradation during sudden traffic increases. It also involves human intervention, which is prone to errors.
- Conclusion: This option is not ideal as it is reactive and could introduce performance issues due to delayed scaling actions. It is not efficient for handling sudden, random traffic increases.
Option B: Use predictive scaling to change the size of the Auto Scaling group.
- Scenario: Predictive scaling involves using machine learning algorithms to forecast future traffic patterns and automatically adjust the size of the Auto Scaling group based on predictions.
- Pros: Predictive scaling can forecast traffic increases based on historical data and adjust scaling in advance, improving performance for known traffic patterns.
- Cons: The traffic increases the company experiences are described as "random," meaning predictive scaling may not be effective because it relies on patterns and trends. If traffic increases are unpredictable, this method might not scale quickly enough when unexpected surges happen.
- Conclusion: Predictive scaling is not the most suitable option in this case because it relies on past patterns, and the company experiences random traffic increases. Thus, it may not ...
Author: Ahmed · Last updated Aug 7, 2026
An ecommerce application uses a PostgreSQL database that runs on an Amazon EC2 instance. During a monthly sales event, database usage increases and causes database connection issues for the application. The traffic is unpredictable for subsequent monthly sales events, which impacts the sales forecast. The company needs to ma...
To address the unpredictable traffic spikes during monthly sales events and maintain the performance of the application, we need a solution that scales automatically to accommodate increased demand while being cost-effective.
Evaluating the Options:
A) Migrate the PostgreSQL database to Amazon Aurora Serverless v2:
- Advantages: Amazon Aurora Serverless v2 is designed for unpredictable workloads, and it can scale automatically based on the demand. It can automatically adjust the compute capacity in response to traffic spikes and reduce costs during periods of low activity.
- Cost-effectiveness: Aurora Serverless only charges for the actual compute capacity used, making it an ideal choice for handling fluctuating traffic patterns. If traffic spikes occur only during sales events, Aurora Serverless can scale up when needed and scale down during non-peak times, minimizing costs.
- Suitability: This solution works well for applications that have variable or unpredictable traffic, like monthly sales events, and want to minimize over-provisioning costs.
- Why it's selected: Aurora Serverless v2 offers automatic scaling and pricing based on usage, which is a cost-effective solution for managing unpredictable spikes in traffic. It supports PostgreSQL and is highly available.
B) Enable auto scaling for the PostgreSQL database on the EC2 instance to accommodate increased usage:
- Advantages: Auto scaling can help scale EC2 instances to handle increased traffic.
- Disadvantages: PostgreSQL on EC2 doesn't automatically scale the database itself (just the EC2 instance), and it requires manual configuration for the database's internal scaling (such as connection pooling, scaling storage, etc.). Also, this approach may not handle database-specific scaling needs, such as managing connection limits or CPU/memory usage.
- Cost-effectiveness: Auto scaling EC2 instances may not be as cost-effective because it involves managing the underlying infrastructure, and the EC2 instances may not scale as efficiently as Aurora Serverless for database-specific workloads.
- Suitability: This approach is generally better for applications with more predictable traffic or when you need t...
Author: Ming88 · Last updated Aug 7, 2026
A company hosts an internal serverless application on AWS by using Amazon API Gateway and AWS Lambda. The company's employees report issues with high latency when they begin using the application each da...
To address the issue of high latency when employees begin using the application each day, we need to focus on solutions that specifically improve the startup time for Lambda functions, which might be impacted by factors such as cold starts.
Evaluating the Options:
A) Increase the API Gateway throttling limit:
- Advantages: Increasing the throttling limit allows more requests to be handled concurrently by the API Gateway, which can help with managing high request volume.
- Disadvantages: This option doesn't directly address the latency due to cold starts of Lambda functions. Throttling limits focus on managing traffic flow but do not mitigate cold start issues or performance degradation during the initial request processing.
- Why rejected: This solution does not resolve the latency issue caused by cold starts, which is the root cause of the problem described.
B) Set up a scheduled scaling to increase Lambda provisioned concurrency before employees begin to use the application each day:
- Advantages: Provisioned concurrency pre-warms Lambda functions before they are invoked, ensuring that a specific number of instances are always available to handle requests without the cold start delay. This can be scheduled to ramp up the number of instances right before employees start using the application, significantly reducing latency.
- Why it's selected: This option directly addresses the cold start latency by ensuring Lambda functions are already warmed up and ready to serve requests when needed. It's a highly effective solution for reducing latency, especially for a scenario with predictable high usage at the start of the day.
C) Create an Amazon CloudWa...
Author: Emma Brown · Last updated Aug 7, 2026
A research company uses on-premises devices to generate data for analysis. The company wants to use the AWS Cloud to analyze the data. The devices generate .csv files and support writing the data to an SMB file share. Company analysts must be able to use SQL commands to query the data. The analysts will run que...
To meet the research company's requirements of analyzing .csv data stored in Amazon S3, while allowing analysts to run SQL queries cost-effectively, the solution should focus on integrating on-premises devices with AWS, storing the data efficiently, and allowing for SQL-based querying of the data. Let's evaluate each option.
Evaluating the Options:
A) Deploy an AWS Storage Gateway on premises in Amazon S3 File Gateway mode:
- Advantages: AWS Storage Gateway in S3 File Gateway mode allows on-premises devices to access Amazon S3 using SMB protocol. The data generated by the devices can be written to Amazon S3, which is scalable and cost-effective. This satisfies the need to store the .csv files in S3.
- Why it's selected: This is a cost-effective way to move the on-premises SMB-based data to S3 while keeping the device setup and integration minimal. S3 provides inexpensive storage, and the AWS Storage Gateway enables seamless integration with on-premises systems.
- Why other options are rejected: The other Storage Gateway mode options (like FSx) would involve additional complexity and potentially higher costs, as they are designed for different use cases (FSx is more suited for Windows or Lustre file systems).
B) Deploy an AWS Storage Gateway on premises in Amazon FSx File Gateway mode:
- Advantages: FSx File Gateway supports integration with Amazon FSx for Windows File Server, which provides a fully managed Windows file system.
- Disadvantages: This option is not cost-effective in this scenario because it is designed to support Windows-based file systems and isn't needed to support SMB to S3 transfers. The goal is to store the .csv files in S3, so this introduces unnecessary complexity and costs.
- Why rejected: Amazon FSx File Gateway would be a more expensive and complex solution that doesn't align with the goal of cost-effective storage in Amazon S3.
C) Set up an AWS Glue crawler to create a table based on the data that is in Amazon S3:
- Advantages: AWS Glue is a fully managed ETL service that can crawl the .csv files in Amazon S3 and automatically create tables in the AWS Glue Data Catalog. This allows the data to be queried with SQL tools like Amazon Athena.
- Why it's selected: Glue crawlers simplify the process of creating a schema for the .csv data in S3 and allow for easy querying. It integrates well with S3 and is a serverless service, so it helps keep costs low.
- Why other options are rejected: Other data storage or query services might require more management or additional setup, making them less cost-effective compared to Glue.
D) Set up an Amazon EMR cluster with EMR Fi...
