Amazon Practice Questions, Discussions & Exam Topics by our Authors
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: Matthew · Last updated Apr 16, 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: Abigail · Last updated Apr 16, 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: Emily · Last updated Apr 16, 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: Olivia · Last updated Apr 16, 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: Stella · Last updated Apr 16, 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: Aria · Last updated Apr 16, 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: Amira99 · Last updated Apr 16, 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: Michael · Last updated Apr 16, 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: MysticJaguar44 · Last updated Apr 16, 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: Oliver · Last updated Apr 16, 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: Amira99 · Last updated Apr 16, 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: Julian · Last updated Apr 16, 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: Michael · Last updated Apr 16, 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: Emily · Last updated Apr 16, 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: Liam123 · Last updated Apr 16, 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: Victoria · Last updated Apr 16, 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: Daniel · Last updated Apr 16, 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: CrystalWolfX · Last updated Apr 16, 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: Aarav · Last updated Apr 16, 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: Layla · Last updated Apr 16, 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: Emily · Last updated Apr 16, 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: Aria · Last updated Apr 16, 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: RadiantPhoenixX · Last updated Apr 16, 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: Olivia · Last updated Apr 16, 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: Emma · Last updated Apr 16, 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: StarryEagle42 · Last updated Apr 16, 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: GlowingTiger · Last updated Apr 16, 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: Aarav · Last updated Apr 16, 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: Ava · Last updated Apr 16, 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: Liam · Last updated Apr 16, 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: Nia · Last updated Apr 16, 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: Ella · Last updated Apr 16, 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: FrozenWolf2022 · Last updated Apr 16, 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: Charlotte · Last updated Apr 16, 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: Ryan · Last updated Apr 16, 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: Noah · Last updated Apr 16, 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...
Author: Andrew · Last updated Apr 16, 2026
A company wants to use Amazon Elastic Container Service (Amazon ECS) clusters and Amazon RDS DB instances to build and run a payment processing application. The company will run the application in its on-premises data center for compliance purposes.
A solutions architect wants to use AWS Outposts as part of the solution. The solutions architect is working ...
To determine the responsibilities of the company's operational team when using AWS Outposts for building and running a payment processing application, it's important to understand the roles of both AWS and the company in managing an Outposts environment. AWS Outposts bring AWS infrastructure, services, and operating models to on-premises data centers. While AWS manages certain aspects of Outposts, the company will have some responsibilities as well. Let’s evaluate the options based on this shared responsibility model.
Evaluating the Options:
A) Providing resilient power and network connectivity to the Outposts racks:
- Advantages: Ensuring resilient power and network connectivity to the Outposts racks is typically the responsibility of the customer (the company). AWS will provide the hardware and infrastructure, but the company needs to ensure that the data center environment is properly connected to power and networking resources for the Outposts hardware to function.
- Why selected: The operational team is responsible for maintaining the environment that the Outposts rely on, including providing power and network connectivity. AWS will handle the infrastructure management, but resilient power and network connectivity are typically on the operational team.
B) Managing the virtualization hypervisor, storage systems, and the AWS services that run on Outposts:
- Disadvantages: AWS manages the hardware, including the virtualization infrastructure (hypervisor), storage, and the underlying services running on the Outposts racks. The company does not directly manage these components.
- Why rejected: AWS takes care of managing the virtualization layer, storage systems, and running services. The operational team focuses more on using the resources AWS provides rather than managing the underlying infrastructure directly.
C) Physical security and access controls of the data center environment:
- Advantages: The company is responsible for securing the physical access to the data center environment. This includes controlling access to Outposts racks, servers, and network equipment to ensure compliance with security standards and regulations.
- Why selected: Physical security is a fundamental responsibility of the c...
Author: Zara · Last updated Apr 16, 2026
A company is planning to migrate a TCP-based application into the company's VPC. The application is publicly accessible on a nonstandard TCP port through a hardware appliance in the company's data center. This public endpoint can process up to 3 million requests per second with low latency. The company requires th...
To migrate a TCP-based application into AWS while maintaining high performance, the solution needs to meet the requirements of handling up to 3 million requests per second with low latency. Let's evaluate the options based on these needs.
Evaluating the Options:
A) Deploy a Network Load Balancer (NLB). Configure the NLB to be publicly accessible over the TCP port that the application requires:
- Advantages: A Network Load Balancer (NLB) is specifically designed for high performance and low-latency, handling millions of requests per second. It operates at the TCP/UDP layer (Layer 4) and can scale automatically to handle the required load. It is capable of providing a highly available, scalable, and low-latency solution for public-facing applications.
- Why selected: Since the application is TCP-based and requires handling millions of requests per second with low latency, the NLB is the best choice. It can support nonstandard ports and provide the performance and scalability needed. It's also well-suited for use cases like this, where the primary concern is traffic routing and performance at the network layer.
- Why others are rejected: The NLB is designed for TCP traffic and is ideal for this scenario where performance at scale and low latency are paramount.
B) Deploy an Application Load Balancer (ALB). Configure the ALB to be publicly accessible over the TCP port that the application requires:
- Advantages: ALBs can handle HTTP and HTTPS traffic and provide intelligent routing, SSL offloading, and WebSocket support.
- Disadvantages: ALBs operate at Layer 7 (the application layer), making them better suited for HTTP/HTTPS traffic. They are not ideal for general TCP traffic, especially at the scale and low-latency required by the application. The ALB will not perform as well with non-HTTP protocols or high-volume TCP workloads.
- Why rejected: The ALB is not designed to efficiently handle raw TCP traffic at the sc...
Author: FrozenWolf2022 · Last updated Apr 16, 2026
A company runs its critical database on an Amazon RDS for PostgreSQL DB instance. The company wants to migrate to Amazon Aurora PostgreSQL with minimal downtime and data loss.
Wh...
To select the best solution for migrating an Amazon RDS for PostgreSQL DB instance to Amazon Aurora PostgreSQL with minimal downtime and data loss, let's evaluate each option.
A) Create a DB snapshot of the RDS for PostgreSQL DB instance to populate a new Aurora PostgreSQL DB cluster.
- Explanation: This method involves taking a snapshot of the RDS PostgreSQL DB instance and restoring it into an Aurora PostgreSQL DB cluster.
- Advantages:
- Easy to set up.
- Provides a way to move data from RDS PostgreSQL to Aurora PostgreSQL.
- Minimal operational overhead.
- Disadvantages:
- It introduces downtime during the snapshot creation and the restore process. While the snapshot captures data at a certain point in time, any updates to the RDS instance after the snapshot is taken will not be reflected in the Aurora cluster.
- This could lead to data loss for transactions that happen during the migration.
B) Create an Aurora read replica of the RDS for PostgreSQL DB instance. Promote the Aurora read replica to a new Aurora PostgreSQL DB cluster.
- Explanation: This method involves setting up an Aurora read replica of the RDS for PostgreSQL DB instance. After replication is complete, the replica is promoted to a standalone Aurora DB cluster.
- Advantages:
- Minimal downtime as the RDS instance continues to be available during the migration.
- Replication ensures that all changes made to the source database are captured.
- Aurora can take over as the primary database with almost no downtime once the replica is promoted.
- Disadvantages:
- More complex to set up and manage compared to other options.
- Requires additional time for replication to sync all the data between RDS and Aurora.
C) Use data import from Amazon S3 to migrate the database to an Aurora PostgreSQL DB cluster.
- Explanation: This method involves exporting the data to Amazon S3 and then importing it into an Aurora PostgreSQL DB cluster.
- Advantages:
- Suitable for large datasets or when performing bulk data migration.
- Can be useful for migrations where data from a variety of sources (other ...
Author: Daniel · Last updated Apr 16, 2026
A company's infrastructure consists of hundreds of Amazon EC2 instances that use Amazon Elastic Block Store (Amazon EBS) storage. A solutions architect must ensure that every EC2 instance can be recovered after a disaster.
...
To meet the requirement of ensuring that every EC2 instance can be recovered after a disaster with the least amount of effort, we will evaluate each option based on factors such as ease of implementation, operational overhead, and effectiveness in disaster recovery.
A) Take a snapshot of the EBS storage that is attached to each EC2 instance. Create an AWS CloudFormation template to launch new EC2 instances from the EBS storage.
- Explanation: This approach involves taking a snapshot of the EBS volumes and then using AWS CloudFormation to automate the launch of EC2 instances from these snapshots.
- Advantages:
- CloudFormation is a powerful tool for automating infrastructure deployment.
- EBS snapshots ensure that the data is preserved.
- Disadvantages:
- This solution requires manually creating CloudFormation templates and managing them.
- It doesn’t fully automate the recovery process for all EC2 instances and requires careful setup to ensure recovery of both EC2 instances and associated EBS volumes.
- Higher operational overhead for maintaining CloudFormation templates for each EC2 instance.
- Not as simple as some other options.
B) Take a snapshot of the EBS storage that is attached to each EC2 instance. Use AWS Elastic Beanstalk to set the environment based on the EC2 template and attach the EBS storage.
- Explanation: This option proposes using AWS Elastic Beanstalk for deployment, while still relying on EBS snapshots for storage.
- Advantages:
- Elastic Beanstalk simplifies the deployment of applications.
- Elastic Beanstalk can scale automatically, which could potentially help in managing EC2 instance recovery.
- Disadvantages:
- Elastic Beanstalk is typically used for managing application environments, not necessarily for the full disaster recovery of EC2 instances with specific EBS snapshots.
- This doesn’t fully align with the goal of recovering EC2 instances with their specific EBS volumes as it is more application-centric rather than infrastructure-centric.
- The solution requires more complex configuration and might not meet the requirement with minimal effort.
C) Use AWS Backup to set up a backup plan for the entire group of EC2 instances. Use the AWS Backup API or the AWS CLI to speed up the restore process for multiple EC2 instances.
- Explanation: This option involves using AWS Backup, which is a managed service that automates backups and restores of EC2 instances and other AWS resources.
- Advantages:
- AWS Backup is designed for s...
Author: Rohan · Last updated Apr 16, 2026
A company recently migrated to the AWS Cloud. The company wants a serverless solution for large-scale parallel on-demand processing of a semistructured dataset. The data consists of logs, media files, sales transactions, and IoT sensor data that is stored in Amazon S3. The company wants the solution to proces...
To determine the best solution for the company's requirement of a serverless, scalable, parallel processing system for a semistructured dataset stored in Amazon S3, we need to assess each option based on key factors such as operational efficiency, ease of scaling, and cost-effectiveness.
A) Use the AWS Step Functions Map state in Inline mode to process the data in parallel.
- Explanation: AWS Step Functions provides a Map state to iterate over a collection of items and process them in parallel. The Inline mode runs a specified Lambda function for each iteration.
- Advantages:
- Step Functions simplifies the orchestration of workflows and can provide parallel processing for small-scale datasets.
- Suitable for workflows that require conditional branching and state transitions.
- Disadvantages:
- Inline mode is not designed for large-scale, high-volume parallel processing.
- For very large datasets or high-frequency execution, Inline mode may encounter scaling or performance limitations.
- Operational complexity increases as you scale the number of parallel tasks, and the overall cost could increase with the high number of Lambda invocations.
B) Use the AWS Step Functions Map state in Distributed mode to process the data in parallel.
- Explanation: The Distributed mode of the Map state in AWS Step Functions is specifically designed for scaling large-scale parallel processing. It can distribute a large set of tasks across multiple AWS resources, such as Lambda functions.
- Advantages:
- Distributed mode provides true parallel processing at scale, making it ideal for processing thousands of items in the dataset in parallel.
- Step Functions will automatically handle task failures and retries, and scaling is managed seamlessly.
- This mode is more suited for handling large datasets and processing them efficiently with minimal operational overhead.
- Disadvantages:
- More complex than simpler solutions, although it offers more scalability and fault tolerance.
C) Use AWS Glue to process the data in parallel.
- Explanation: AWS Glue is a serverless data integration service that supports ETL (Extract, Transform, Load) processes for big data. It is optimized for batch processing of large datasets stored in Amazon S3.
- Advantages:
- AWS Glue can process large datasets in parallel and provides built-in optimizations for data transformation tasks.
- Fully serverless,...
Author: BlazingPhoenix22 · Last updated Apr 16, 2026
A company will migrate 10 PB of data to Amazon S3 in 6 weeks. The current data center has a 500 Mbps uplink to the internet. Other on-premises applications share the uplink. The company can use 80% of the internet...
To determine the best solution for migrating 10 PB of data to Amazon S3 in 6 weeks with the constraints of a 500 Mbps uplink and 80% of bandwidth allocated to migration (which equates to 400 Mbps), we need to evaluate the feasibility, scalability, and efficiency of each option.
A) Configure AWS DataSync to migrate the data to Amazon S3 and to automatically verify the data.
- Explanation: AWS DataSync is a managed service that automates the transfer of large volumes of data to Amazon S3. It provides encryption, data verification, and efficient data transfer capabilities.
- Advantages:
- High transfer speeds: AWS DataSync is optimized for large-scale data migrations and can leverage high-speed data transfer protocols to efficiently move data, which could provide much higher throughput than the uplink speed limit.
- Automatic verification: It offers automated data verification to ensure that data is copied correctly.
- Scalability: DataSync scales well for large data migrations and can handle 10 PB of data effectively.
- Managed service: Reduces operational overhead compared to other manual methods.
- Disadvantages:
- May still be constrained by the bandwidth of the internet connection unless other optimizations are available.
Why it's a good fit: DataSync provides high-speed, reliable migration capabilities with data verification, making it an ideal choice for a migration task of this size.
B) Use rsync to transfer the data directly to Amazon S3.
- Explanation: `rsync` is a command-line tool that can be used to transfer files over the network. It is commonly used for incremental transfers and is often employed for smaller-scale migrations.
- Advantages:
- Free and open-source, with minimal setup.
- Good for smaller datasets or incremental changes.
- Disadvantages:
- Performance issues: `rsync` is not optimized for transferring large volumes of data to cloud storage. It may not perform well for 10 PB of data, especially over a bandwidth-limited connection like the one described (500 Mbps).
- Lack of automation and management: It requires manual setup and management of multiple concurrent transfers to be effective, making it operationally more complex for this scale.
- Not optimized for cloud storage: rsync works best for file systems, but Amazon S3 is object storage, which means `rsync` is not designed to integrate well with it. You would need additional steps to integrate with S3, leading to more complexity.
Why it's rejected: `rsync` is not well-suited for a large-scale migration to Amazon S3, especially with the need for optimal bandwidth utilization and efficient handling of 10 PB of data.
C) Use the AWS CLI and multiple copy processes to send the data directly to Amazon S3.
- Explanation: Using the AWS CLI with multiple copy processes means manually managing multiple S3 `cp` commands or p...
Author: John · Last updated Apr 16, 2026
A company has several on-premises Internet Small Computer Systems Interface (ISCSI) network storage servers. The company wants to reduce the number of these servers by moving to the AWS Cloud. A solutions architect must provide low-latency access to frequently used data and reduce the depen...
To meet the company's requirements of reducing the dependency on on-premises Internet Small Computer Systems Interface (iSCSI) network storage servers while ensuring low-latency access to frequently used data, we need to evaluate the options based on key factors such as infrastructure changes, low-latency access, and minimizing complexity.
A) Deploy an Amazon S3 File Gateway.
- Explanation: An Amazon S3 File Gateway provides an interface to Amazon S3 that allows on-premises applications to store and retrieve files as objects in S3. It supports file-based protocols such as NFS and SMB.
- Advantages:
- Minimal infrastructure changes: It allows existing on-premises applications to interact with S3, minimizing changes to applications.
- Data storage in S3: Provides scalable and durable storage with access through file protocols.
- Disadvantages:
- Not ideal for low-latency access: Amazon S3 is an object storage service, which typically does not offer the low-latency access needed for applications requiring fast performance.
- Not ideal for frequently accessed data: S3 File Gateway may not provide the performance necessary for workloads that require high-throughput and low-latency access to frequently used data.
Why it’s rejected: S3 is object storage, and while it offers good scalability, it is not optimized for low-latency, high-performance access that is required by some workloads.
B) Deploy Amazon Elastic Block Store (Amazon EBS) storage with backups to Amazon S3.
- Explanation: Amazon EBS provides block-level storage that can be attached to EC2 instances. Data can be backed up to Amazon S3 using EBS snapshots.
- Advantages:
- Low-latency access: EBS provides high-performance, low-latency block storage.
- Backup to S3: Snapshots allow for durable backups of EBS volumes.
- Disadvantages:
- On-premises storage issue: This option requires the use of EC2 instances, which doesn’t directly address the reduction of on-premises storage servers. It adds complexity in terms of managing EC2 instances and storage.
- Manual management: Although EBS provides low-latency storage, managing backups and ensuring minimal disruption to the workload may require additional setup.
Why it’s rejected: While EBS offers low-latency access, it requires more management and infrastructure overhead compared to solutions that are better suited to reducing on-premises servers without significant changes.
C) Deploy an AWS Storage Gateway volume gateway that is configured with stored volumes.
- Explanation: The stored volumes configuration of the AWS Storage Gateway stores all data on-premises while asynchron...
Author: ElectricLionX · Last updated Apr 16, 2026
A solutions architect is designing an application that will allow business users to upload objects to Amazon S3. The solution needs to maximize object durability. Objects also must be readily available at any time and for any length of time. Users will access objects frequently within the first 30 days after the objects are uploaded,...
In this case, the solution needs to maximize object durability, provide frequent access for objects in the first 30 days, and minimize costs by reducing storage costs for less frequently accessed objects after 30 days.
Let’s break down the options and key factors:
A) Store all the objects in S3 Standard with an S3 Lifecycle rule to transition the objects to S3 Glacier after 30 days.
- Pros: S3 Glacier is a very low-cost storage option for archiving data, making it an excellent choice for rarely accessed data.
- Cons: Objects stored in Glacier are not readily available. Accessing data in Glacier involves retrieval times (hours), which would not meet the requirement of ensuring that objects are "readily available at any time."
- Best for: Data that needs to be archived and doesn’t require quick access, like long-term backups.
- Why not selected: Glacier does not meet the requirement of “readily available at any time,” which is essential in this case.
B) Store all the objects in S3 Standard with an S3 Lifecycle rule to transition the objects to S3 Standard-Infrequent Access (S3 Standard-IA) after 30 days.
- Pros: S3 Standard-IA is designed for infrequently accessed data but still offers low-latency and high-throughput access. It balances cost and access performance well.
- Cons: S3 Standard-IA has a higher storage cost than S3 Glacier, but it provides faster access, which may be more expensive in cases where Glacier’s retrieval time is acceptable.
- Best for: Frequently accessed data that becomes less used over time but still needs to be available quickly.
- Why not selected: S3 Standard-IA might be more expensive than other options like S3 One Zone-IA if the durability requirement does not necessitate redundant storage across multiple availability zones.
C) Store all the objects in S3 Standard with an S3 Lifecycle rule to transition the objects to S3 One Zone-Infrequent Access (S3 One Zone-IA) after 30 days.
- Pros: S3 One Zone-IA is much cheaper than S3 Standard-IA because it stores data in a single availability zone. This can reduce costs while maintaining good access times...
Author: Amelia · Last updated Apr 16, 2026
A company has migrated a two-tier application from its on-premises data center to the AWS Cloud. The data tier is a Multi-AZ deployment of Amazon RDS for Oracle with 12 TB of General Purpose SSD Amazon Elastic Block Store (Amazon EBS) storage. The application is designed to process and store documents in the database as binary large objects (blobs) with an average document size of 6 MB.
The database size has grown over time, reducing the performance and increasing...
In this case, the company is facing performance and cost issues due to the storage growth and its reliance on Amazon RDS for Oracle with large binary objects (blobs) in the database. The goal is to improve database performance and reduce storage costs, while maintaining high availability and resilience.
Let's evaluate each option based on key factors: performance, cost-effectiveness, scalability, and alignment with the company's requirements.
A) Reduce the RDS DB instance size. Increase the storage capacity to 24 TiB. Change the storage type to Magnetic.
- Pros: Reducing the DB instance size would lower the cost of compute resources. Increasing storage capacity to 24 TiB would provide more room for data growth.
- Cons: Magnetic storage is a slow, legacy option that would drastically reduce database performance, especially when dealing with large binary objects (6 MB each). RDS Magnetic storage is not ideal for transactional or high-performance applications. The increased storage capacity may solve the space issue but not the performance bottleneck.
- Best for: Situations where cost is a major concern, and performance is not critical (e.g., archiving or infrequent access).
- Why not selected: This option would degrade performance significantly and is not suitable for a production environment that needs high availability, resilience, and good performance.
B) Increase the RDS DB instance size. Increase the storage capacity to 24 TiB. Change the storage type to Provisioned IOPS.
- Pros: Increasing the RDS DB instance size and using Provisioned IOPS (SSD) would improve performance, especially for write-heavy operations. Provisioned IOPS would provide high, consistent I/O performance, suitable for applications with high throughput and low-latency requirements.
- Cons: This option would likely lead to higher costs, especially with 24 TiB of Provisioned IOPS storage. While performance would improve, the company is still storing large binary objects (blobs) in the database, which isn't the most cost-effective approach for handling large binary data. Additionally, it does not address the issue of inefficient use of database storage for blobs.
- Best for: Applications that need high performance and can justify the higher cost of Provisioned IOPS storage.
- Why not selected: While it would improve performance, this solution does not address the underlying issue of inefficient storage for large binary objects (blobs) and would increase costs due to the high price of Provisioned IOPS.
C) Create an Amazon S3 bucket. Update the application to store documents in the S3 bucket. Store the object metadata in the existing database.
- Pros: This is a highly cost-effectiv...
Author: Maya · Last updated Apr 16, 2026
A company has an application that serves clients that are deployed in more than 20.000 retail storefront locations around the world. The application consists of backend web services that are exposed over HTTPS on port 443. The application is hosted on Amazon EC2 instances behind an Application Load Balancer (ALB). The retail locations communicate with the web application over the public internet. The company allows each retail location to register the IP address that the retail location has been allocated by its local ISP.
The compa...
To increase the security of the application endpoint and restrict access to only the IP addresses registered by the retail locations, the solution needs to efficiently and dynamically manage access control based on the retail locations' IPs, with minimal overhead for maintenance. Let's evaluate each option:
A) Associate an AWS WAF web ACL with the ALB. Use IP rule sets on the ALB to filter traffic. Update the IP addresses in the rule to include the registered IP addresses.
- Pros: AWS WAF is a scalable and easy-to-manage solution that can be integrated with the ALB to filter inbound traffic. You can create an IP rule set in AWS WAF that allows or denies traffic based on the source IP addresses. This option allows flexibility in dynamically updating the registered IPs as the list changes. Additionally, AWS WAF can be used to provide protection against common web application attacks.
- Cons: There might be some overhead in managing the IP rules if the number of retail locations grows significantly. However, this is a manageable solution with the option to automate the update process through scripts or AWS Lambda functions to update the IPs dynamically.
- Best for: Use cases that require granular, scalable traffic filtering at the application layer. This solution is ideal for controlling access to the application while still allowing flexibility to modify IP restrictions.
- Why selected: AWS WAF is a good choice here because it integrates seamlessly with the ALB and allows for easy management of IP-based access control, which can be updated dynamically.
B) Deploy AWS Firewall Manager to manage the ALB. Configure firewall rules to restrict traffic to the ALB. Modify the firewall rules to include the registered IP addresses.
- Pros: AWS Firewall Manager can help centralize the management of firewall rules across multiple accounts, which is beneficial if the organization is managing multiple AWS accounts and VPCs.
- Cons: This solution adds complexity and is best suited for managing a broader range of security policies across multiple accounts and resources. It is not optimized for managing IP-based access control for a single ALB, especially when the need is limited to controlling access to one application with a known set of registered IP addresses.
- Best for: Organizations with multiple accounts or resources that require consistent firewall management across AWS.
- Why not selected: This solution is more complex than necessary for this use case, where managing IP filtering directly through AWS WAF on the ALB would be simpler and more efficient.
C) Store the IP addresses in an Amazon Dynam...
Author: Noah · Last updated Apr 16, 2026
A company is building a data analysis platform on AWS by using AWS Lake Formation. The platform will ingest data from different sources such as Amazon S3 and Amazon RDS. The company needs a secure solution to prevent access to portions of the data that con...
To meet the company's requirement of securing sensitive data within a data analysis platform while minimizing operational overhead, let's evaluate each solution option based on key factors like security, manageability, scalability, and operational complexity:
A) Create an IAM role that includes permissions to access Lake Formation tables.
- Pros: IAM roles are a fundamental way to control access to AWS resources and can be used to grant or deny access to Lake Formation tables based on user roles and permissions.
- Cons: While IAM roles are important for access control, they don't address the need to restrict access to sensitive data within a table itself (e.g., specific rows or cells of data). IAM alone cannot provide fine-grained security on data inside the tables based on content.
- Best for: Controlling access at the resource level (e.g., who can access specific tables or databases).
- Why not selected: This option does not offer the necessary granularity to protect sensitive portions of data within the tables (row-level or cell-level security). Therefore, it doesn't fulfill the requirement of securing sensitive information effectively.
B) Create data filters to implement row-level security and cell-level security.
- Pros: AWS Lake Formation provides built-in functionality to define data filters that enforce row-level security (RLS) and cell-level security (CLS) on tables. This solution can limit access to sensitive data by controlling which rows or cells of a table are visible to users based on defined permissions. It is a highly efficient, low-maintenance solution that integrates directly into Lake Formation.
- Cons: Requires defining appropriate filters, but this is a manageable configuration that can be easily maintained as data access requirements change.
- Best for: Organizations that need fine-grained access control to protect sensitive data at the row or cell level, without complex manual interventions.
- Why selected: This solution is the best fit because it directly addresses the need for controlling access to specific portions of the data (sensitive information) with minimal operational overhead. Once the filters are defined, they can be enforced automatically, reducing manual effort.
C) Create an AWS Lambda function that removes sensitive information before Lake Formation ingests the data.
- Pros: This approach would allow you to preprocess the data before it is ingested into Lake Formation, removing sensitive information in advance.
- Cons: While this approach could work, it adds significant operational overhead because you would need to maintain and monitor ...
Author: Amira99 · Last updated Apr 16, 2026
A company deploys Amazon EC2 instances that run in a VPC. The EC2 instances load source data into Amazon S3 buckets so that the data can be processed in the future. According to compliance laws, the data must not be transmitted over the public internet. Servers in the company's on-premises data ce...
To meet the compliance requirements that the data must not be transmitted over the public internet, the solution must ensure that both data transfer to/from Amazon S3 and the communication between the EC2 instances and the on-premises data center occur over private connections without crossing the public internet. Let's evaluate each option based on these key requirements:
A) Deploy an interface VPC endpoint for Amazon EC2. Create an AWS Site-to-Site VPN connection between the company and the VPC.
- Pros: An interface VPC endpoint enables private communication between VPC resources and EC2 instances without the need for public IP addresses, which ensures that the communication does not traverse the public internet. The Site-to-Site VPN connection would establish a secure, encrypted tunnel between the on-premises data center and the VPC, also avoiding the public internet for communication.
- Cons: While the VPN provides a secure connection to the VPC, it doesn't address the requirement for private communication between EC2 instances and S3. Additionally, EC2 to S3 communication would still be subject to public internet traffic unless a VPC endpoint is used specifically for Amazon S3.
- Best for: Secure private communication between the VPC and on-premises data center.
- Why not selected: This option does not ensure that communication with S3 is kept private because it relies on an interface VPC endpoint for EC2, which only applies to EC2-to-EC2 communication, not EC2-to-S3. The VPC endpoint for S3 is necessary to keep S3 access private.
B) Deploy a gateway VPC endpoint for Amazon S3. Set up an AWS Direct Connect connection between the on-premises network and the VPC.
- Pros: A gateway VPC endpoint for Amazon S3 allows EC2 instances to access S3 buckets securely and privately within the VPC without using the public internet. AWS Direct Connect is a dedicated network connection that establishes a private connection between the on-premises data center and AWS, providing reliable, secure communication over a private link.
- Cons: Direct Connect can be more expensive and complex to set up than a VPN. It might be overkill if the need is only to ensure private communication with S3 and between the VPC and the on-premises network.
- Best for: Organizations that require a high-throughput, low-latency, private network connection to AWS, and where communication with S3 and the on-premises data center must be private.
- Why selected: This solution ensures that both EC2 instances communicate privately with S3 (via the gateway VPC endpoint) and that communication between the on-premises data center and the VPC remains private (via Direct Connect). This meets the compliance requirement of preventing public i...
Author: Sara · Last updated Apr 16, 2026
A company has an application with a REST-based interface that allows data to be received in near-real time from a third-party vendor. Once received, the application processes and stores the data for further analysis. The application is running on Amazon EC2 instances.
The third-party vendor has received many 503 Service Unavailable Errors when sending data to the application. When the data volume spikes, the compute...
To address the problem of 503 Service Unavailable errors when the data volume spikes, we need to design a scalable solution that can handle varying amounts of traffic without overloading the application. Here's an analysis of each option:
Option A: Use Amazon Kinesis Data Streams to ingest the data. Process the data using AWS Lambda functions.
- Why it might work: Kinesis can help decouple data ingestion from the actual processing by buffering incoming data. Lambda is scalable and can process messages as they come through, allowing for nearly real-time data processing. This approach provides automatic scaling based on demand, which helps handle varying traffic loads without overloading the application.
- Why it's not ideal: If the application’s processing requirements are complex or need more than what Lambda offers (e.g., long-running tasks), this might not be a good fit. Lambda also has certain execution time limits (15 minutes), which may not work for all use cases.
- Key factors to consider: This design is best for real-time processing with limited compute complexity.
Option B: Use Amazon API Gateway on top of the existing application. Create a usage plan with a quota limit for the third-party vendor.
- Why it might work: API Gateway can help with throttling and rate-limiting, potentially reducing the number of incoming requests during traffic spikes. The quota can help prevent overloading the backend.
- Why it's not ideal: Rate limiting may not be sufficient to address scalability issues if the backend itself is overwhelmed. It does not scale the backend resources or improve the application’s ability to handle increased traffic; it just manages the traffic coming in.
- Key factors to consider: This design is more about controlling the flow of incoming data rather than improving the application’s scalability.
Option C: Use Amazon Simple Notification Service (Amazon SNS) to ingest the data. Put the EC2 instances in an Auto Scaling group behind an Application Load Balancer.
- Why it might work: SNS can decouple the data ingestion process, allowing you to asynchronously process incoming data. By placing EC2 instances behind an Auto Scaling grou...
