Amazon Practice Questions, Discussions & Exam Topics by our Authors
A weather service provides high-resolution weather maps from a web application hosted on AWS in the eu-west-1 Region. The weather maps are updated frequently and stored in Amazon S3 along with static HTML content. The web application is fronted by Amazon CloudFront.
The company recently expanded to serve users in the us-east-1 Region, and these new users report t...
To resolve the performance issues in the us-east-1 Region, the solution needs to address the latency that users in this region are experiencing when retrieving weather maps stored in an S3 bucket located in eu-west-1. The performance is likely due to the fact that the content is being served from an S3 bucket that is geographically distant, causing delays. Here’s the evaluation of the options:
Option A: Configure the AWS Global Accelerator endpoint for the S3 bucket in eu-west-1. Configure endpoint groups for TCP ports 80 and 443 in us-east-1.
- Reasoning: AWS Global Accelerator improves application performance by routing traffic to the nearest AWS endpoint, but it does not directly address the performance issues of serving static content from S3. Global Accelerator is typically used to route TCP/UDP traffic to specific AWS services (like EC2 or ALB), and not for optimizing static content delivery from S3. This would not improve the delivery speed of static content like weather maps stored in S3.
- Conclusion: This option is not suitable because it does not directly optimize S3 content delivery or static content performance.
Option B: Create a new S3 bucket in us-east-1. Configure S3 cross-Region replication to synchronize from the S3 bucket in eu-west-1.
- Reasoning: This is a strong option. By replicating the S3 content to a bucket in us-east-1, the content is stored closer to users in that region, reducing latency for fetching weather maps. Cross-Region replication ensures that the data is consistently updated across regions, and CloudFront can automatically cache and serve the content from the us-east-1 S3 bucket when requested. This solution addresses both latency and the need for up-to-date weather maps.
- Conclusion: This option is effective because it reduces latency by placing the content closer to users, while still ensuring that content is synchronized across regions.
Option C: Use Lambda@Edge to modify requests from North America to use the S3 Transfer Acceleration endpoint in us-east-1.
...
Author: Zain · Last updated May 13, 2026
A solutions architect is investigating an issue in which a company cannot establish new sessions in Amazon Workspaces. An initial analysis indicates that the issue involves user profiles. The Amazon Workspaces environment is configured to use Amazon FSx for Windows File Server as the profile share storage. The FSx for Windows File Server file system is configured with 10 TB of storage.
The solutions architect discovers that the file system has reached It...
The issue at hand is that the company cannot establish new sessions in Amazon WorkSpaces due to the user profile storage being full in Amazon FSx for Windows File Server. The storage has reached its maximum capacity, preventing new sessions from being created. The goal is to resolve this issue immediately and ensure it doesn't happen again.
Let’s evaluate each option to identify the most effective and sustainable solution:
Option A: Remove old user profiles to create space. Migrate the user profiles to an Amazon FSx for Lustre file system.
- Reasoning: Removing old profiles could provide immediate relief by freeing up space. However, migrating the profiles to an Amazon FSx for Lustre file system is not ideal. Amazon FSx for Lustre is designed for high-performance computing workloads that require fast data access, not for user profile storage. Using Lustre for user profiles could lead to performance issues and unnecessary complexity. Additionally, the Lustre file system is not optimized for general-purpose file sharing or Windows environments like FSx for Windows File Server is.
- Conclusion: While this option can address the immediate problem (freeing up space), it is not suitable as a long-term solution because Lustre is not designed for user profile storage.
Option B: Increase capacity by using the update-file-system command. Implement an Amazon CloudWatch metric that monitors free space. Use Amazon EventBridge to invoke an AWS Lambda function to increase capacity as required.
- Reasoning: This option suggests dynamically increasing the capacity of the FSx for Windows File Server file system using the update-file-system command. This is a practical solution because FSx for Windows File Server supports scalable storage. The use of Amazon CloudWatch and EventBridge can automate the monitoring of free space and trigger the addition of capacity as needed. This allows the system to scale as the storage dema...
Author: Elijah · Last updated May 13, 2026
An international delivery company hosts a delivery management system on AWS. Drivers use the system to upload confirmation of delivery. Confirmation includes the recipient's signature or a photo of the package with the recipient. The driver's handheld device uploads signatures and photos through FTP to a single Amazon EC2 instance. Each handheld device saves a file in a directory based on the signed-in user, and the file name matches the delivery number. The EC2 instance then adds metadata to the file after querying a central database to pull delivery information. The file is then placed in Amazon S3 for archiving.
As the company expands, drivers report that the system is rejecting connections. The FTP server is having problems because of dropped connections and memory issues in response to these problems, a system engineer schedules a cron task to reboot the EC2 instance every 30 minutes. The billing team report...
To address the issues with the FTP server and ensure scalability, reliability, and the ability to always update the system and archive files, let's evaluate each option based on the given requirements:
Option A: Create an AMI of the existing EC2 instance. Create an Auto Scaling group of EC2 instances behind an Application Load Balancer. Configure the Auto Scaling group to have a minimum of three instances.
- Reasoning: This approach creates an Auto Scaling group to distribute the workload across multiple EC2 instances, thus improving scalability. However, this solution does not address the core problem of reliability and proper file archiving, particularly the dropped connections and memory issues. While scaling the EC2 instances might improve the system's ability to handle traffic, it doesn't necessarily solve the problem of ensuring the files always make it to the archive and that the system is consistently updated. Furthermore, adding complexity with an Application Load Balancer and Auto Scaling is not the most efficient way to address the FTP and file handling issues when there are simpler alternatives.
- Conclusion: This option is not ideal because it doesn't directly address the reliability or file processing issues and adds unnecessary complexity.
Option B: Use AWS Transfer Family to create an FTP server that places the files in Amazon Elastic File System (Amazon EFS). Mount the EFS volume to the existing EC2 instance. Point the EC2 instance to the new path for file processing.
- Reasoning: AWS Transfer Family can provide a fully managed FTP server, which improves the scalability and management of the FTP server. By storing the files in Amazon EFS, you can scale file storage and avoid issues with the EC2 instance's local storage. However, this option still involves the EC2 instance for file processing, which doesn't completely resolve the problem of dropped connections and memory issues. Additionally, this introduces dependency on the EC2 instance for processing files and updating the cen...
Author: Noah · Last updated May 13, 2026
A company is running an application in the AWS Cloud. The application runs on containers m an Amazon Elastic Container Service (Amazon ECS) cluster. The ECS tasks use the Fargate launch type. The application's data is relational and is stored in Amazon Aurora MySQL. To meet regulatory requirements, the application must be able to recover to a separate AWS Region in the event ...
Solution Analysis for Meeting the Recovery Requirements
Key Requirements:
1. Recovery to a Separate Region: The application needs to recover to a different AWS Region in the event of a failure.
2. No Data Loss: The application cannot afford any data loss.
3. Minimal Operational Overhead: The solution should require minimal management and intervention.
Option A: Provision an Aurora Replica in a different Region
- Explanation: Amazon Aurora allows you to create cross-Region read replicas. The replica in another Region would provide a way to failover in case of an issue with the primary Region. Aurora cross-Region replication is asynchronous, but you can configure Aurora to use Aurora Global Databases, which is designed for cross-Region replication with minimal lag.
- Advantages:
- Minimal operational overhead, as Aurora handles the replication automatically.
- Aurora Global Databases enable low-latency reads and allow for automatic failover in case of regional failure.
- No need for manual intervention once set up.
- Aurora guarantees minimal data loss with Global Databases due to synchronous replication between Regions.
- Why Selected:
- This option meets the need for disaster recovery (DR) with no data loss, automatic failover, and minimal operational overhead.
Option B: Set up AWS DataSync for continuous replication of the data to a different Region
- Explanation: AWS DataSync is typically used for data transfer and replication between on-premises storage and AWS or between AWS services. It is not specifically optimized for database replication. DataSync works by moving large volumes of data efficiently, but it does not handle database consistency or ensure low-latency replication.
- Why Rejected:
- While DataSync is good for file-based data transfers, it is not designed for database replication and cannot guarantee continuous, low-latency, transactional consistency for a relational database like Aurora.
- This would introduce more...
Author: SolarFalcon11 · Last updated May 13, 2026
A financial services company receives a regular data feed from its credit card servicing partner. Approximately 5,000 records are sent every 15 minutes in plaintext, delivered over HTTPS directly into an Amazon S3 bucket with server-side encryption. This feed contains sensitive credit card primary account number (PAN) data. The company needs to automatically mask the PAN before sending the data to another S3 bucket for additional internal processing. The company also needs to remove and merge speci...
Solution Analysis for Automatically Masking PAN and Transforming Data
Key Requirements:
1. Masking Sensitive Data (PAN): The company needs to mask the Primary Account Number (PAN) before processing it further.
2. Field Removal and Merging: Specific fields need to be removed and merged as part of the processing.
3. Transformation to JSON: The records need to be transformed into JSON format.
4. Future Scalability: The solution must be easily expandable to accommodate additional data feeds.
5. Minimal Latency and Efficient Processing: The process must be efficient, with minimal overhead.
Option A: Invoke an AWS Lambda function on file delivery that extracts each record and writes it to an Amazon SQS queue. Invoke another Lambda function when new messages arrive in the SQS queue to process the records, writing the results to a temporary location in Amazon S3. Invoke a final Lambda function once the SQS queue is empty to transform the records into JSON format and send the results to another S3 bucket for internal processing.
- Explanation: This option uses AWS Lambda functions triggered by S3 file delivery. The records are processed in stages, with SQS used as a buffer between Lambda functions for scalability.
- Advantages:
- Scalable: AWS Lambda automatically scales to handle the number of records.
- Asynchronous Processing: SQS ensures that the Lambda functions can process the data without overwhelming the system, and any additional feeds can be easily incorporated by updating Lambda functions.
- Granular Control: Each step (masking PAN, removing and merging fields, and transforming into JSON) can be handled independently by separate Lambda functions, providing fine-grained control over the process.
- Challenges:
- Multiple Lambda Functions: Handling multiple Lambda functions with SQS introduces some complexity in managing the flow, especially when dealing with potential failures.
- Latency: While AWS Lambda scales well, it may introduce some latency due to the multiple steps and invocations (each Lambda function could take time to process, and additional intermediate storage might be required).
Option B: Invoke an AWS Lambda function on file delivery that extracts each record and writes it to an Amazon SQS queue. Configure an AWS Fargate container application to automatically scale to a single instance when the SQS queue contains messages. Have the application process each record, and transform the record into JSON format. When the queue is empty, send the results to another S3 bucket for internal processing and scale down the AWS Fargate instance.
- Explanation: This approach uses Lambda to trigger the processing flow, but instead of using additional Lambda functions, it uses AWS Fargate containers to process the data.
- Advantages:
- Scalability: Fargate automatically scales up or down depending on the queue length, which can be beneficial for larger datasets or varying data loads.
- Containerized Processing: AWS Fargate can offer more control over the processing logic and is suitable for complex or resource-intensive transformations.
- Challenges:
- Operational Overhead: Although Fargate scales automatically, it still requires container management and orchestration. Lambda functions would still need to be involved in triggering Fargate tasks, which introduces some complexity.
- More Complex Setup: The integration between Lambda and Fargate introduces additional setup complexity compared to the other solutions, especially when considering expansion or debugging.
- Latency: While Fargate offers scalability, the invocation of Fargate tasks may have a higher startup latenc...
Author: IronLion88 · Last updated May 13, 2026
A company wants to use AWS to create a business continuity solution in case the company's main on-premises application fails. The application runs on physical servers that also run other applications. The on-premises application that the company is planning to migrate uses a MySQL database as a data store. All the company's on-premises applicati...
Solution Analysis for Business Continuity with the Least Operational Overhead
Key Requirements:
1. Business Continuity: The company needs a solution that ensures the on-premises application, including the MySQL database, can be recovered quickly in the event of a failure.
2. Minimal Operational Overhead: The solution should require the least amount of manual intervention and management once set up.
3. Compatibility with Current Infrastructure: The company’s on-premises applications use operating systems compatible with Amazon EC2.
Option A: Install the AWS Replication Agent on the source servers, including the MySQL servers. Set up replication for all servers. Launch test instances for regular drills. Cut over to the test instances to fail over the workload in the case of a failure event.
- Explanation: This option involves using the AWS Replication Agent to replicate the on-premises servers to AWS, allowing for failover to test instances during a failure event.
- Advantages:
- Relatively Simple Setup: Installing the AWS Replication Agent is straightforward, and once it is set up, the failover process is clear.
- Testing Flexibility: Regular drills and testing instances ensure that the system is prepared for a real failure event.
- Challenges:
- Operational Complexity: Although the setup is straightforward, managing regular failovers and ensuring synchronization during an actual disaster can introduce some overhead. This requires proactive testing and ongoing maintenance.
- Not as Automated: The manual failover process (cutting over to test instances) may still involve operational overhead during an actual failure event.
Option B: Install the AWS Replication Agent on the source servers, including the MySQL servers. Initialize AWS Elastic Disaster Recovery (AWS DRS) in the target AWS Region. Define the launch settings. Frequently perform failover and fallback from the most recent point in time.
- Explanation: This option uses AWS Elastic Disaster Recovery (DRS), which automates the failover process for both physical and EC2 instances. It replicates data and allows for an automated failover and fallback mechanism.
- Advantages:
- Minimal Operational Overhead: AWS DRS automates the recovery process, including the replication and failover, reducing manual intervention.
- Continuous Replication: DRS replicates data continuously, ensuring the target environment is up-to-date with the source.
- Automated Failover and Fallback: The ability to perform failovers and fallback with minimal manual steps significantly reduces the complexity of disaster recovery.
- Challenges:
- Cost and Complexity of Setup: While DRS reduces operational overhead during failover, initial setup and configuration may require some time and effort. Additionally, the service is primarily geared for disaster recovery, so ongoing monitoring may still be necessary.
- Not Ideal for All Workloads: If only certain components of the application are critical, using DRS may feel like an over-engineered solution for some workloads.
Option C: Create AWS Database Migration Service (AWS DMS) replication servers and a target Amazon Aurora MySQL DB cluster to host the database. Create a DMS replication task to copy...
Author: Noah Williams · Last updated May 13, 2026
A company is subject to regulatory audits of its financial information. External auditors who use a single AWS account need access to the company's AWS account. A solutions architect must provide the auditors with secure, read-only access to the company's AWS ac...
Solution Analysis for Providing Secure Read-Only Access to Auditors
Key Requirements:
1. Secure, Read-Only Access: The auditors should only have read-only access to the company’s AWS resources.
2. Compliance with Security Best Practices: The solution should follow AWS security best practices, such as the principle of least privilege and secure access control.
3. External Access: The auditors need access from an external AWS account, not from within the company's AWS account.
Option A: In the company's AWS account, create resource policies for all resources in the account to grant access to the auditors' AWS account. Assign a unique external ID to the resource policy.
- Explanation: This option suggests using resource policies for individual resources to grant access to the auditors' AWS account. The external ID would be used for cross-account access.
- Advantages:
- Direct control over resource-level access.
- Challenges:
- Not Scalable: Managing resource policies for every individual AWS resource is impractical and error-prone, especially in a large environment with many resources.
- Complexity: It would require adding specific policies to each resource, which is cumbersome and difficult to manage over time.
- Lacks Flexibility: This approach is highly granular and does not provide an efficient way to grant read-only access across the account.
Option B: In the company's AWS account, create an IAM role that trusts the auditors' AWS account. Create an IAM policy that has the required permissions. Attach the policy to the role. Assign a unique external ID to the role's trust policy.
- Explanation: This option involves creating an IAM role in the company’s AWS account that trusts the auditors' AWS account. The auditors assume the role to gain access to the company's resources.
- Advantages:
- Secure and Scalable: This method follows AWS best practices for cross-account access using IAM roles, ensuring secure access to the company’s AWS resources.
- Read-Only Permissions: The IAM policy can be attached to the role with read-only permissions, ensuring the auditors cannot make changes to the resources.
- External ID: The use of an external ID adds an extra layer of security, preventing unauthorized access.
- Least Privilege: By defining granular permissions for the role, only the required access can be granted, adhering to the principle of least privilege.
- Easily Managed: This approach centralizes access control, making it easier to manage and audit.
- Why Selected:
- This solution adheres to AWS security best practices, is scalable, and provides the auditors with secure, read-only access. It ensures compliance with the principle of least privil...
Author: Sophia · Last updated May 13, 2026
A company has a latency-sensitive trading platform that uses Amazon DynamoDB as a storage backend. The company configured the DynamoDB table to use on-demand capacity mode. A solutions architect needs to design a solution to improve the performance of the trading platform. The new solution ...
Solution Analysis for Improving the Performance of a Latency-Sensitive Trading Platform
Key Requirements:
1. Latency Sensitivity: The trading platform is highly latency-sensitive, meaning the solution must minimize latency to provide the best user experience.
2. High Availability: The solution must ensure the trading platform remains available even during traffic spikes or failures.
3. DynamoDB as Storage Backend: The platform uses DynamoDB with on-demand capacity mode, which automatically adjusts to traffic changes but may still experience latency issues during read and write operations.
DynamoDB Accelerator (DAX) Overview:
DAX is an in-memory caching service for DynamoDB that can help reduce latency by caching the results of read queries, thus offloading the DynamoDB table from frequent read operations and improving response times. However, the latency for write operations cannot be fully eliminated by DAX alone, so designing for both read and write performance is important.
Option A: Create a two-node DynamoDB Accelerator (DAX) cluster. Configure an application to read and write data by using DAX.
- Explanation:
- DAX improves read and write performance by caching the data in memory. However, the solution uses a two-node DAX cluster, which doesn't meet the best practice for high availability in production environments. For high availability, at least a three-node DAX cluster is recommended.
- Advantages:
- It reduces latency for both read and write operations.
- Challenges:
- High Availability: A two-node DAX cluster cannot provide fault tolerance in case of a node failure, making it unsuitable for high availability requirements.
Option B: Create a three-node DynamoDB Accelerator (DAX) cluster. Configure an application to read data by using DAX and to write data directly to the DynamoDB table.
- Explanation:
- This option uses a three-node DAX cluster, which ensures high availability by providing fault tolerance. The application will read from the DAX cache to minimize latency, but it will write directly to DynamoDB.
- Advantages:
- High Availability: The three-node cluster provides fault tolerance and high availability.
- Reduced Latency for Reads: DAX caches read data in memory, reducing the latency for read operations.
- Challenges:
- Write Performance: Since writes go directly to DynamoDB and are not cached in DAX, write latency may still be an issue for the latency-sensitive trading platform. However, DynamoDB’s on-demand cap...
Author: Deepak · Last updated May 13, 2026
A company has migrated an application from on premises to AWS. The application frontend is a static website that runs on two Amazon EC2 instances behind an Application Load Balancer (ALB). The application backend is a Python application that runs on three EC2 instances behind another ALB. The EC2 instances are large, general purpose On-Demand Instances that were sized to meet the on-premises specifications for peak usage of the application.
The application averages hundreds of thousands of requests each month. However, the application is used mainly during lunchtime and receives minima...
To optimize the infrastructure cost of the application without affecting availability, we need to focus on two key points: reducing the cost of infrastructure during off-peak hours and optimizing the resource utilization based on the actual traffic patterns.
Let's analyze each option:
A) Change all the EC2 instances to compute-optimized instances that have the same number of cores as the existing EC2 instances.
- Why Rejected: This option is focused on changing the EC2 instance type to compute-optimized instances. However, the main issue here is cost, not performance. The problem isn’t necessarily that the EC2 instances need to be compute-optimized, but that the infrastructure is over-provisioned during non-peak hours. Switching to compute-optimized instances could increase costs if the demand for compute power doesn’t align with this type. It doesn’t address the fluctuation in demand that the solution is looking to optimize.
B) Move the application frontend to a static website that is hosted on Amazon S3.
- Why Selected: The application frontend is a static website. Hosting it on Amazon S3 is a much more cost-effective solution than maintaining EC2 instances. Amazon S3 is highly scalable, automatically handles traffic spikes, and costs are based on storage and requests rather than the size of EC2 instances. Moving the frontend to S3 can save on infrastructure costs and remove the need for EC2 instances dedicated to serving static content, as well as improve availability and scalability. This directly addresses both cost optimization and availability.
C) Deploy the application frontend by using AWS Elastic Beanstalk. Use the same instance type for the nodes.
- Why Rejected: Elastic Beanstalk provides an easy way to manage web applications, but if the frontend is static, using Elastic Beanstalk (which typically runs EC2 instances for applications) is overkill. S3 is better suited for hosting static websites, whereas Elastic Beanstalk is better for dynamic content that requires server-...
Author: Daniel · Last updated May 13, 2026
A company is running an event ticketing platform on AWS and wants to optimize the platform's cost-effectiveness. The platform is deployed on Amazon Elastic Kubernetes Service (Amazon EKS) with Amazon EC2 and is backed by an Amazon RDS for MySQL DB instance. The company is developing new application features to run on Amazon EKS with AWS Fargate.
The platform experie...
To determine the most cost-effective solution for the platform, we need to focus on the following aspects:
1. Scalability for Peaks: The platform experiences infrequent but high peaks in demand based on event dates. This means that during peak demand, the infrastructure must be able to scale efficiently and at a low cost, without overprovisioning during periods of low activity.
2. Predictability of Load: The baseline load can be predicted, but the peak demand depends on event dates. Thus, a combination of cost-effective solutions for both baseline and peak demand is required.
3. Cost Optimization: We want to minimize costs while ensuring that the platform is capable of scaling during high demand periods without impacting performance.
Analysis of Options:
A) Purchase Standard Reserved Instances for the EC2 instances that the EKS cluster uses in its baseline load. Scale the cluster with Spot Instances to handle peaks. Purchase 1-year All Upfront Reserved Instances for the database to meet predicted peak load for the year.
- Why Rejected:
- Reserved Instances for EC2: While purchasing Reserved Instances (RIs) for the EC2 instances handling the baseline load is generally a good idea for cost savings, Standard RIs commit you to specific instance types and sizes, which reduces flexibility. For workloads with fluctuating demand, this can be suboptimal, especially when scaling to handle peaks.
- RIs for Database: Purchasing 1-year All Upfront Reserved Instances for the database to meet peak load is not ideal. Database usage may not always match the predicted peak demand, meaning you'd overpay for database capacity you don't need during non-peak periods.
- Spot Instances: Using Spot Instances for scaling EC2 clusters is cost-effective, but they come with the risk of being terminated during heavy AWS demand, which may impact availability. This is a good option for workloads with some tolerance for interruption.
B) Purchase Compute Savings Plans for the predicted medium load of the EKS cluster. Scale the cluster with On-Demand Capacity Reservations based on event dates for peaks. Purchase 1-year No Upfront Reserved Instances for the database to meet the predicted base load. Temporarily scale out database read replicas during peaks.
- Why Rejected:
- Compute Savings Plans: Compute Savings Plans are flexible, which allows the company to apply savings across different EC2 instance types, EKS, or Fargate. However, buying them for only the predicted "medium load" might not provide the best savings if there is a wide variation in load.
- On-Demand Capacity Reservations: While this ensures capacity during peak demand, it is not cost-effective. On-Demand Capacity Reservations can be expensive, as they commit you to paying for reserved capacity regardless of usage.
- Database Scaling: Scaling read replicas during peaks can help offload read traffic, but it doesn't address scaling the primary DB instance itself during peaks, which could lead to performance bottlenecks during high traffic periods.
C) Purch...
Author: Victoria · Last updated May 13, 2026
A company has deployed an application on AWS Elastic Beanstalk. The application uses Amazon Aurora for the database layer. An Amazon CloudFront distribution serves web requests and includes the Elastic Beanstalk domain name as the origin server. The distribution is configured with an alternate domain name that visitors use when they access the application.
Each week, the company takes the application out of service for routine maintenance. During the time that the application is unavailable, the company wants visitors to receive an informational messa...
Let's break down the options and analyze each step to ensure the correct steps are selected to meet the requirements of displaying an informational message during the application maintenance period.
A) Upload static informational content to the S3 bucket.
- Reason for selection: This is the first step in the process, and it is required to have the content (the informational message) available to serve to visitors when the application is unavailable. By uploading the static content (such as an HTML page) to the S3 bucket, we can later configure CloudFront to serve this message to users instead of the usual application response.
B) Create a new CloudFront distribution. Set the S3 bucket as the origin.
- Reason for rejection: This is not necessary. The company already has a CloudFront distribution set up to serve content from the Elastic Beanstalk domain. Creating a new CloudFront distribution would add unnecessary complexity and would not be as efficient as configuring the existing distribution to handle the temporary change. It would also disrupt the existing CloudFront distribution setup.
C) Set the S3 bucket as a second origin in the original CloudFront distribution. Configure the distribution and the S3 bucket to use an origin access identity (OAI).
- Reason for selection: This is a good solution because it allows us to keep the existing CloudFront distribution and add the S3 bucket as a secondary origin. This way, we can serve the static informational content from the S3 bucket during maintenance without modifying the primary application origin. Using an OAI ensures that CloudFront accesses the S3 bucket securely.
D) During the weekly maintenance, edit the default cache behavior to use the S3 origin. Revert the change when the maintenance is complete.
- Reaso...
Author: SolarFalcon11 · Last updated May 13, 2026
A company gives users the ability to upload images from a custom application. The upload process invokes an AWS Lambda function that processes and stores the image in an Amazon S3 bucket. The application invokes the Lambda function by using a specific function version ARN.
The Lambda function accepts image processing parameters by using environment variables. The company often adjusts the environment variables of the Lambda function to achieve optimal image processing output. The company tests different parameters and publishes a new function version with the updated environment variables after validating results. This update process also requires frequent cha...
To simplify the process of updating image processing parameters for the Lambda function and minimize disruption to users, we need to focus on reducing the need for frequent changes to the custom application and the Lambda function’s environment variables. We also want to avoid unnecessary operational overhead.
Analysis of Each Option:
A) Directly modify the environment variables of the published Lambda function version. Use the `LATEST` version to test image processing parameters.
- Why Rejected:
- Modifying environment variables directly on the published Lambda function version would update the environment for all invocations of that version, which can disrupt users.
- The `LATEST` version is a moving target and is not suitable for production environments. Using `LATEST` would mean changes to the Lambda function are applied immediately, which can break existing functionality for users without proper testing.
- While this approach eliminates the need for frequent ARN updates, it lacks control over which version of the Lambda function is invoked, which could lead to unpredictable behavior for users.
B) Create an Amazon DynamoDB table to store the image processing parameters. Modify the Lambda function to retrieve the image processing parameters from the DynamoDB table.
- Why Rejected:
- Storing the image processing parameters in a DynamoDB table can provide flexibility to change parameters without redeploying the Lambda function. However, the Lambda function would still need to read the parameters from DynamoDB on every invocation, potentially adding overhead to the image processing task.
- While this approach removes the need to modify the Lambda function's environment variables, it introduces extra complexity and latency due to the database lookup, which may not be ideal for a real-time image processing workload.
C) Directly code the image processing parameters within the Lambda function and remove the environment variables. Publish a new function version when the company updates the parameters.
- Why Rejecte...
Author: Aarav · Last updated May 13, 2026
A global media company is planning a multi-Region deployment of an application. Amazon DynamoDB global tables will back the deployment to keep the user experience consistent across the two continents where users are concentrated. Each deployment will have a public Application Load Balancer (ALB). The company manages public DNS internally....
Let's break down each option and evaluate them based on the requirements: enabling multi-region deployment with minimal effort, handling user traffic with low latency, and making the application available through an apex domain.
A) Migrate public DNS to Amazon Route 53. Create CNAME records for the apex domain to point to the ALB. Use a geolocation routing policy to route traffic based on user location.
- Reason for rejection: While Route 53 is a good DNS service, it does not allow CNAME records at the apex (root) domain level, only for subdomains. The apex domain (e.g., `example.com`) cannot directly point to a CNAME record. This is a significant limitation for setting up an apex domain, so it’s not a suitable solution for the requirements.
B) Place a Network Load Balancer (NLB) in front of the ALB. Migrate public DNS to Amazon Route 53. Create a CNAME record for the apex domain to point to the NLB’s static IP address. Use a geolocation routing policy to route traffic based on user location.
- Reason for rejection: Although the NLB provides static IP addresses, it cannot directly support CNAME records for the apex domain. The same issue as Option A arises: CNAME records are not allowed at the apex domain level. Additionally, this introduces more complexity by involving both NLB and ALB, which isn’t necessary and adds overhead without significant benefit. It does not address the core requirement of using an apex domain with minimal effort.
C) Create an AWS Global Accelerator accelerator with multiple endpoint groups that target endpoints in appropriate AWS Regions. Use the accelerator’s static IP address to create a record in public DNS for the apex domain.
- Reason for selection: This is the most efficient and correc...
Author: Manish · Last updated May 13, 2026
A company is developing a new serverless API by using Amazon API Gateway and AWS Lambda. The company integrated the Lambda functions with API Gateway to use several shared libraries and custom classes.
A solutions architect needs to simplify t...
To meet the company's requirements for simplifying deployment and optimizing for code reuse with shared libraries and custom classes, let's evaluate each option and its viability.
Option A: Deploy the shared libraries and custom classes into a Docker image. Store the image in an S3 bucket. Create a Lambda layer that uses the Docker image as the source. Deploy the API's Lambda functions as Zip packages. Configure the packages to use the Lambda layer.
- Issues:
- Lambda layers cannot use Docker images directly as sources. Lambda layers are designed to work with Zip files or directories containing code, but not Docker images.
- Storing Docker images in an S3 bucket is not the typical use case; Docker images are best managed through Amazon ECR.
- Lambda functions packaged as Zip files and configured to use a Docker-based Lambda layer is not feasible since Lambda layers are not Docker-based.
Conclusion: This option is not viable.
Option B: Deploy the shared libraries and custom classes to a Docker image. Upload the image to Amazon Elastic Container Registry (Amazon ECR). Create a Lambda layer that uses the Docker image as the source. Deploy the API's Lambda functions as Zip packages. Configure the packages to use the Lambda layer.
- Issues:
- While Amazon ECR is the correct service for managing Docker images, Lambda layers still cannot use Docker images as sources. Lambda layers can only contain Zip files or directories with code. You cannot directly use Docker images in a Lambda layer.
Conclusion: This option is also not feasible due to the limitation on Lambda layers not supporting Docker images as sources.
Option C: Deploy the shared libraries and custom cl...
Author: Ella · Last updated May 13, 2026
A manufacturing company is building an inspection solution for its factory. The company has IP cameras at the end of each assembly line. The company has used Amazon SageMaker to train a machine learning (ML) model to identify common defects from still images.
The company wants to provide local feedback to factory workers when a defect is detected. The company must be able to provide this feedback even if the factory's internet connec...
To address the manufacturing company's need for local feedback when an internet connection is down, the solution must ensure that the ML model can be deployed locally and provide real-time inference without requiring a constant internet connection. Let's evaluate each option:
Option A: Set up an Amazon Kinesis video stream from each IP camera to AWS. Use Amazon EC2 instances to take still images of the streams. Upload the images to an Amazon S3 bucket. Deploy a SageMaker endpoint with the ML model. Invoke an AWS Lambda function to call the inference endpoint when new images are uploaded. Configure the Lambda function to call the local API when a defect is detected.
- Issues:
- This option requires a constant internet connection to stream video to AWS and invoke SageMaker endpoints. Since the company specifically wants the solution to work even if the internet is down, this option does not meet the requirement for local inference and feedback.
- Uploading images to S3 and invoking AWS Lambda adds latency and relies on internet connectivity, which would fail if the connectivity is lost.
Conclusion: This option is not viable due to the reliance on internet connectivity for uploading images and invoking Lambda functions.
Option B: Deploy AWS IoT Greengrass on the local server. Deploy the ML model to the Greengrass server. Create a Greengrass component to take still images from the cameras and run inference. Configure the component to call the local API when a defect is detected.
- Advantages:
- AWS IoT Greengrass allows local execution of machine learning models, even without internet access. It provides local feedback by running inference directly on the local server where the model is deployed.
- Greengrass is designed to handle edge computing tasks, allowing the local server to take images from cameras, process them, and provide feedback even if the internet is down.
- This solution aligns perfectly with the requi...
Author: ThunderBear · Last updated May 13, 2026
A solutions architect must create a business case for migration of a company's on-premises data center to the AWS Cloud. The solutions architect will use a configuration management database (CMDB) export of all the company's ...
To create a business case for migrating the company's on-premises data center to AWS Cloud, the solutions architect needs a cost-effective, automated solution that can analyze the company’s server infrastructure and generate insights regarding migration. Let’s evaluate each option:
Option A: Use AWS Well-Architected Tool to import the CMDB data to perform an analysis and generate recommendations.
- Issues:
- The AWS Well-Architected Tool is primarily designed to review and improve the architecture of workloads running in the AWS Cloud. It helps ensure workloads are optimized according to AWS best practices in areas such as security, performance, and cost.
- It does not provide a direct capability to import CMDB data or create a business case for migration.
- It does not focus on migrating on-premises servers to AWS or estimating migration costs.
Conclusion: This option is not suitable for creating a business case for migration because it does not offer the necessary features for analyzing on-premises data center configurations or generating cost estimates.
Option B: Use Migration Evaluator to perform an analysis. Use the data import template to upload the data from the CMDB export.
- Advantages:
- Migration Evaluator is designed specifically for assessing on-premises environments and estimating migration costs to AWS. It can take in data from a CMDB export and generate detailed reports and recommendations regarding the most cost-effective AWS migration options.
- It provides insights into which AWS services can replace the on-premises servers, and it can generate precise cost estimates for migration, making it an ideal tool for creating a business case for migration.
- The use of a data import template simplifies the process of mapping and importing CMDB data.
Con...
Author: Abigail · Last updated May 13, 2026
A company has a website that runs on Amazon EC2 instances behind an Application Load Balancer (ALB). The instances are in an Auto Scaling group. The ALB is associated with an AWS WAF web ACL.
The website often encounters attacks in the application layer. The attacks produce sudden and significant increases in traffic on the application server. The access logs show that each attack originates from different...
Let's break down each option and assess which one will meet the requirements most effectively with the least operational overhead.
Option A: Create an Amazon CloudWatch alarm that monitors server access. Set a threshold based on access by IP address. Configure an alarm action that adds the IP address to the web ACL’s deny list.
- Advantages:
- CloudWatch alarms can automatically trigger actions based on traffic patterns, such as adding a specific IP to a deny list. This allows for automation of security measures without manual intervention.
- The integration with AWS WAF means that adding an IP address to the deny list will immediately block malicious requests.
- Issues:
- The application is facing attacks from different IP addresses, so continually adding individual IP addresses to the deny list may not be the most efficient approach, especially if the attacks are distributed or have a high rate of change in IP addresses.
- This approach does not directly address high-volume attacks where a broader solution might be needed.
Conclusion: While this option offers some automation, it may not scale well in the face of dynamic and highly distributed application layer attacks, leading to increased operational complexity.
Option B: Deploy AWS Shield Advanced in addition to AWS WAF. Add the ALB as a protected resource.
- Advantages:
- AWS Shield Advanced is designed to protect against large-scale DDoS attacks, including application layer attacks, and offers automatic mitigation without the need for manual intervention.
- AWS Shield Advanced integrates seamlessly with AWS WAF and ALB to provide additional security layers.
- It provides protections against sudden increases in traffic from various sources (such as a distributed denial-of-service or application layer attacks) without requiring manual IP blocking.
- Conclusion:
- This solution requires minimal operational overhead as AWS Shield Advanced automatically detects and mitigates atta...
Author: CrystalWolfX · Last updated May 13, 2026
A company has a critical application in which the data tier is deployed in a single AWS Region. The data tier uses an Amazon DynamoDB table and an Amazon Aurora MySQL DB cluster. The current Aurora MySQL engine version supports a global database. The application tier is already deployed in two Regions.
Company policy states that critical applications must have application tier components and data tier components deployed across two Regions. The RTO and RPO must be no ...
To meet the company’s policy of having application and data tier components deployed across two Regions with minimal RTO and RPO (Recovery Time Objective and Recovery Point Objective), we need to ensure that the data tier is both highly available and resilient across two Regions. Let's evaluate each option:
Option A: Add another Region to the Aurora MySQL DB cluster
- Advantages:
- Amazon Aurora Global Databases for MySQL are specifically designed to support cross-Region replication, which provides low-latency reads and automatic failover in case of a Regional failure. This option ensures that the Aurora DB cluster can be deployed in two Regions, aligning with the company's policy of multi-Region deployment.
- It meets the requirement for RTO and RPO because it provides continuous replication with very low lag, ensuring minimal downtime and data loss in the event of a Regional failure.
Conclusion: This is a valid option to meet the company's policy and ensure high availability for the data tier.
Option B: Add another Region to each table in the Aurora MySQL DB cluster
- Issues:
- The Aurora MySQL engine supports global databases that span multiple Regions, but this option is not valid as phrased. The Aurora database itself spans multiple Regions, not individual tables. The correct approach would be to use the global database feature for the entire DB cluster, not tables.
Conclusion: This option is incorrect because it is not how Aurora Global Databases work. The global database operates at the DB cluster level, not at the table level.
Option C: Set up scheduled cross-Region backups for the DynamoDB table and the Aurora MySQL DB cluster
- Issues:
- While cross-Region backups help with disaster recovery, they do not provide the required low-latency replication or immediate failover capabilities. Scheduled backups can result in significant delays between the time data is written...
Author: Mia · Last updated May 13, 2026
A telecommunications company is running an application on AWS. The company has set up an AWS Direct Connect connection between the company's on-premises data center and AWS. The company deployed the application on Amazon EC2 instances in multiple Availability Zones behind an internal Application Load Balancer (ALB). The company's clients connect from the on-premises network by using HTTPS. The TLS terminates in the ALB. The company has multiple target groups and uses path-based routing to forward requests based on the URL path.
The company is planning to deploy an on-premises firewall appliance...
Evaluation of Options:
Let's analyze each option one by one:
A) Configure the existing ALB to use static IP addresses. Assign IP addresses in multiple Availability Zones to the ALB. Add the ALB IP addresses to the firewall appliance.
- Analysis:
- The Application Load Balancer (ALB) doesn't natively support static IP addresses. It automatically distributes traffic across multiple IP addresses that are not fixed and are dynamic. Therefore, you cannot assign static IP addresses directly to the ALB.
- While it's possible to assign an Elastic IP (EIP) to the ALB, this wouldn't work across multiple Availability Zones as you'd need multiple EIPs for each AZ, complicating management.
- Conclusion: This option is not feasible because ALBs don’t have static IP addresses, and relying on dynamic IP addresses doesn't work well for firewall configuration requiring static IPs.
B) Create a Network Load Balancer (NLB). Associate the NLB with one static IP address in multiple Availability Zones. Create an ALB-type target group for the NLB and add the existing ALB. Add the NLB IP addresses to the firewall appliance. Update the clients to connect to the NLB.
- Analysis:
- A Network Load Balancer (NLB) supports static IP addresses, which is required for the on-premises firewall to create an allow list.
- You can set up the NLB with static IPs, but the solution proposes creating an ALB-type target group for the NLB and adding the existing ALB, which is unnecessary. Typically, an NLB would route traffic directly to backend EC2 instances or services rather than another load balancer like an ALB.
- Conclusion: This is overly complicated and inefficient since it involves routing traffic through two layers of load balancers. The setup could be simplified without involving the ALB.
C) Create a Network Load Balancer (NLB). Associate the NLB with one static IP address in multiple Availability Zones. Add the existing target groups to the NLB. Update the clients to connect to the NLB. Delete the ALB. Add the NLB IP addresses to the firewall appliance.
- Analysis:
- This approach uses a Network Load Balancer (NLB), which can have static IP addresses that can be added to the firewall allow list.
- The NLB is suitable for handling HTTP...
Author: Zain · Last updated May 13, 2026
A company runs an application on a fleet of Amazon EC2 instances that are in private subnets behind an internet-facing Application Load Balancer (ALB). The ALB is the origin for an Amazon CloudFront distribution. An AWS WAF web ACL that contains various AWS managed rules is associated with the CloudFront distribution.
The company needs a solution ...
Let's break down each option and evaluate how well it addresses the requirement to prevent internet traffic from directly accessing the Application Load Balancer (ALB) while minimizing operational overhead.
Option A: Create a new web ACL that contains the same rules that the existing web ACL contains. Associate the new web ACL with the ALB.
- Explanation: This option suggests creating a new web ACL (with the same rules as the existing one) and applying it to the ALB. While this approach could technically prevent unwanted traffic, it introduces redundancy. The AWS WAF web ACL is already associated with the CloudFront distribution, which means it is already filtering traffic before it even reaches the ALB. Adding another web ACL to the ALB would be redundant and would not reduce direct access from the internet.
- Why rejected: This option introduces unnecessary complexity and redundancy, as the WAF rules are already protecting the traffic coming through CloudFront. There's no need for another web ACL on the ALB.
Option B: Associate the existing web ACL with the ALB.
- Explanation: Associating the existing web ACL with the ALB would apply the WAF rules directly to the ALB, filtering traffic before it reaches the EC2 instances. However, the key issue here is that traffic coming from CloudFront already benefits from these WAF protections. Direct access to the ALB by internet traffic would bypass the WAF, potentially allowing malicious traffic through. This option does not prevent direct access to the ALB.
- Why rejected: Associating the WAF with the ALB does not solve the problem of preventing internet traffic from directly accessing the ALB. The WAF is designed to filter CloudFront traffic, not traffic directly accessing the ALB.
Option C: Add a security group rule to the ALB to allow traffic from the AWS managed prefix list for CloudFront only.
- Explanation: This option in...
Author: Lucas · Last updated May 13, 2026
A company is running an application that uses an Amazon ElastiCache for Redis cluster as a caching layer. A recent security audit revealed that the company has configured encryption at rest for ElastiCache. However, the company did not configure ElastiCache to use encryption in transit. Additionally, users can access the cache without authentication.
A solutions archite...
Let's go through the options to understand how each one meets the requirements of enabling authentication and encryption in transit for an Amazon ElastiCache for Redis cluster.
Key Requirements:
1. Authentication: Redis should require an AUTH token for accessing the cache.
2. Encryption in Transit: Traffic between the clients and the Redis cluster should be encrypted, ensuring security during data transmission.
Option A: Create an AUTH token. Store the token in AWS System Manager Parameter Store, as an encrypted parameter. Create a new cluster with AUTH, and configure encryption in transit. Update the application to retrieve the AUTH token from Parameter Store when necessary and to use the AUTH token for authentication.
- Explanation: This option involves creating an AUTH token, storing it in AWS Systems Manager Parameter Store, and configuring a new Redis cluster to use authentication (via the AUTH token) and encryption in transit (via TLS). The application will retrieve the token from Parameter Store for each connection.
- Why rejected: While this option addresses both the authentication and encryption requirements, storing the token in AWS Systems Manager Parameter Store might not be as efficient or secure as using AWS Secrets Manager, which is specifically designed to store and manage sensitive information like authentication tokens. Furthermore, creating a new cluster instead of configuring the existing one leads to unnecessary overhead.
Option B: Create an AUTH token. Store the token in AWS Secrets Manager. Configure the existing cluster to use the AUTH token, and configure encryption in transit. Update the application to retrieve the AUTH token from Secrets Manager when necessary and to use the AUTH token for authentication.
- Explanation: This option involves creating an AUTH token, storing it securely in AWS Secrets Manager, and configuring the existing cluster to use authentication and encryption in transit. The application retrieves the AUTH token from Secrets Manager and uses it for authentication.
- Why selected: This solution is the most secure and efficient since AWS Secrets Manager is designed for securely managing sensitive information. Additionally, it allows you to configure the existing Redis ...
Author: Maya2022 · Last updated May 13, 2026
A company is running a compute workload by using Amazon EC2 Spot Instances that are in an Auto Scaling group. The launch template uses two placement groups and a single instance type.
Recently, a monitoring system reported Auto Scaling instance launch failures that correlated with longer wait times fo...
Let's evaluate each option to determine which one best improves the overall reliability of the workload that uses Amazon EC2 Spot Instances in an Auto Scaling group, based on the problem of instance launch failures and longer wait times:
Option A: Replace the launch template with a launch configuration to use an Auto Scaling group that uses attribute-based instance type selection.
- Explanation: This option involves switching from a launch template to a launch configuration and utilizing attribute-based instance type selection.
- Why rejected: Launch configurations are an older mechanism compared to launch templates. Launch templates offer more flexibility and features, such as the ability to use multiple versions and advanced configuration options. Replacing the launch template with a launch configuration would be a downgrade in terms of flexibility and may not provide significant improvements in reliability. Also, changing to attribute-based instance type selection may help with more diverse instance selection, but the underlying issue of using only one instance type with Spot Instances remains.
Option B: Create a new launch template version that uses attribute-based instance type selection. Configure the Auto Scaling group to use the new launch template version.
- Explanation: This option suggests creating a new version of the launch template to use attribute-based instance type selection, which allows the Auto Scaling group to select from a range of instance types dynamically.
- Why selected: Attribute-based instance type selection is a best practice for improving the reliability of Spot Instance workloads. By allowing Auto Scaling to select from a broader pool of instance types, this helps mitigate the risk of Spot Instance interruptions or failures to launch due to a lack of availability for the selected instance type. This option is optimal because it doesn't restrict the system to a single instance type and provides flexibility in choosing from multiple instance types. This sign...
Author: Henry · Last updated May 13, 2026
A company is migrating a document processing workload to AWS. The company has updated many applications to natively use the Amazon S3 API to store, retrieve, and modify documents that a processing server generates at a rate of approximately 5 documents every second. After the document processing is finished, customers can download the documents directly from Amazon S3.
During the migration, the company discovered that it could not immediately update the processing server that generates many documents to support the S3 API. The server runs on Linux and requires fast local ...
Let's analyze each option carefully based on the company's requirements:
Requirements:
1. The document processing server requires fast local access to the files (since it needs to generate and modify them quickly).
2. After processing, the files need to be made publicly available within 30 minutes.
3. The server cannot immediately support the Amazon S3 API, so a solution must bridge this gap with minimal effort.
---
A) Migrate the application to an AWS Lambda function. Use the AWS SDK for Java to generate, modify, and access the files that the company stores directly in Amazon S3.
- Analysis:
- AWS Lambda is serverless and event-driven, which is great for certain types of tasks like file processing. However, Lambda functions are stateless and have limited storage options.
- The main issue here is that the document processing server needs fast local access to the files, which a Lambda function wouldn't be able to provide since it’s not designed to store large volumes of data locally during execution.
- Furthermore, migrating the entire workload to Lambda would involve significant reworking of the existing system, especially since the server cannot yet support the S3 API.
- Conclusion: This option would require too much effort to adapt and is not suitable given the requirement for fast local access to files.
---
B) Set up an Amazon S3 File Gateway and configure a file share that is linked to the document store. Mount the file share on an Amazon EC2 instance by using NFS. When changes occur in Amazon S3, initiate a RefreshCache API call to update the S3 File Gateway.
- Analysis:
- The Amazon S3 File Gateway provides a way to integrate on-premises environments with Amazon S3 by providing an NFS file share that can be used to interact with S3.
- This could be a valid option if the document processing server was located on-premises or within an AWS environment that doesn't have direct support for the S3 API.
- However, the main drawback is that the RefreshCache API would introduce additional complexity to ensure that the changes made on the local filesystem are properly reflected in Amazon S3.
- While this option provides a file share, the extra overhead of managing cache updates and NFS-based file sharing might add unnecessary complexity.
- Conclusion: While it meets the fast local access requirement, this solution introduces overhead and isn't as straightforward as other options.
---
C) Configure Amazon FSx...
Author: William · Last updated May 13, 2026
A delivery company is running a serverless solution in the AWS Cloud. The solution manages user data, delivery information, and past purchase details. The solution consists of several microservices. The central user service stores sensitive data in an Amazon DynamoDB table. Several of the other microservices store a copy of parts of the sensitive data in different storage services.
The company needs the ability to delete user informatio...
The company needs to ensure that when a user is deleted from the central user service (which uses Amazon DynamoDB), all other microservices must also immediately delete their copies of that data. Here's a breakdown of each option:
Option A: Activate DynamoDB Streams on the DynamoDB table. Create an AWS Lambda trigger for the DynamoDB stream that will post events about user deletion in an Amazon SQS queue. Configure each microservice to poll the queue and delete the user from the DynamoDB table.
- Explanation: DynamoDB Streams can capture changes to the DynamoDB table, including deletions. However, using Lambda to post events about user deletions to an SQS queue introduces potential delays and complexity. Each microservice would need to poll the queue, which could introduce latency in ensuring that the deletions happen immediately across all microservices.
- Issues: While this setup could work, polling SQS queues for each microservice might not guarantee immediate consistency or efficient deletion. Polling also adds complexity to each microservice’s implementation and may not scale well with increased load.
- Rejection Reason: The polling mechanism via SQS is not the most optimal for real-time deletion propagation across all microservices.
Option B: Set up DynamoDB event notifications on the DynamoDB table. Create an Amazon SNS topic as a target for the DynamoDB event notification. Configure each microservice to subscribe to the SNS topic and to delete the user from the DynamoDB table.
- Explanation: DynamoDB event notifications would notify SNS about changes in the table. Each microservice would then be notified via SNS and could delete the user data accordingly.
- Issues: DynamoDB itself does not natively support direct event notifications for specific data changes like deletions. This would require additional configuration or customization. Also, using SNS would introduce possible delays in event delivery, and handling user deletions directly via SNS subscriptions might not be the most immediate or reliable method to trigger deletions in each microservice.
- Rejection Reason: DynamoDB event notifications are not specifically designed to handle deletion notifications in a simple, efficient manner, making this solution less ideal.
Option C: Configure the c...
Author: Aria · Last updated May 13, 2026
A company is running a web application in a VPC. The web application runs on a group of Amazon EC2 instances behind an Application Load Balancer (ALB). The ALB is using AWS WAF.
An external customer needs to connect to the web application. The company must provide IP ad...
The company needs to provide IP addresses for external customers to connect to their web application running in a VPC, while minimizing operational overhead. Let's evaluate each option:
Option A: Replace the ALB with a Network Load Balancer (NLB). Assign an Elastic IP address to the NLB.
- Explanation: A Network Load Balancer (NLB) can be used to provide static IP addresses for external access. It supports Elastic IP addresses (EIP), which can be directly assigned to the NLB, allowing you to provide a consistent IP address to external customers.
- Pros: NLB is designed for low latency and high throughput and supports static IPs, which meets the requirement for providing IP addresses to external customers.
- Cons: Replacing the ALB with an NLB might not be ideal if the web application requires HTTP/HTTPS features such as SSL termination, URL-based routing, or WAF, as the NLB does not offer these features (ALB does).
- Rejection Reason: While NLB is a good option for providing static IP addresses, it might not be suitable if your web application requires ALB-specific features like HTTP/HTTPS, SSL offloading, or WAF, which is part of the existing setup.
Option B: Allocate an Elastic IP address. Assign the Elastic IP address to the ALB. Provide the Elastic IP address to the customer.
- Explanation: Elastic IPs (EIP) can only be assigned to EC2 instances or NLBs, not ALBs. Therefore, this option is not feasible because you cannot assign an Elastic IP directly to an ALB.
- Rejection Reason: This solution is not possible due to the limitation that ALBs cannot have Elastic IPs assigned to them.
Option C: Create an AWS Global Accelerator standard accelerator. Specify the ALB as the accelerator's endpoint. Provide the accelerator's IP addresses to the customer.
- Explanation: AWS Global Accelerator provides st...
Author: Manish · Last updated May 13, 2026
A company has a few AWS accounts for development and wants to move its production application to AWS. The company needs to enforce Amazon Elastic Block Store (Amazon EBS) encryption at rest current production accounts and future production accounts only. The company needs a solution th...
To meet the company's requirements of enforcing Amazon Elastic Block Store (EBS) encryption at rest in production accounts, the solution must have built-in guardrails and blueprints for managing compliance. Here's an evaluation of the steps:
Option A: Use AWS CloudFormation StackSets to deploy AWS Config rules on production accounts.
- Explanation: AWS CloudFormation StackSets can be used to deploy AWS Config rules across multiple accounts. However, while this can help enforce compliance in terms of configurations like EBS encryption, it doesn't offer built-in blueprints or guardrails specific to AWS Control Tower, and it would require additional effort to manage ongoing compliance.
- Rejection Reason: AWS CloudFormation provides flexibility but doesn't directly provide the same built-in governance capabilities as AWS Control Tower. It's not the most automated or turnkey solution compared to using AWS Control Tower's native features.
Option B: Create a new AWS Control Tower landing zone in an existing developer account. Create OUs for accounts. Add production and development accounts to production and development OUs, respectively.
- Explanation: AWS Control Tower provides a solution to automate the setup of multi-account AWS environments with governance, guardrails, and best practices. However, creating a landing zone in an existing developer account is not ideal. Typically, the AWS Control Tower landing zone should be created in the management account to maintain central control.
- Rejection Reason: The landing zone should ideally be created in the management account, not a developer account. This approach would misalign with AWS Control Tower's best practices.
Option C: Create a new AWS Control Tower landing zone in the company’s management account. Add production and development accounts to production and development OUs, respectively.
- Explanation: This option follows AWS best practices. Creating the landing zone in the management account allows centralized governance and enforcement of guardrails. By creating OUs (Organizational Units) for production and development accounts, the company can apply different policies and guardrails to each set of accounts, including enforcing EBS encryption in production accounts.
- Selected Reason: AWS Control Tower in the management acc...
Author: Andrew · Last updated May 13, 2026
A company is running a critical stateful web application on two Linux Amazon EC2 instances behind an Application Load Balancer (ALB) with an Amazon RDS for MySQL database. The company hosts the DNS records for the application in Amazon Route 53. A solutions architect must recommend a solution to improve the resiliency of the application.
The solution must meet the following objectives:
* Application tier: RPO of 2 minutes. RTO of 30 minutes
* Database tier: RPO of 5 minutes. RTO of 30...
To meet the company's resiliency requirements for both the application tier and the database tier, we need a solution that minimizes recovery time and provides high availability across regions. Let’s evaluate each option based on the given objectives:
Option A: Configure the EC2 instances to use AWS Elastic Disaster Recovery. Create a cross-Region read replica for the RDS DB instance. Create an ALB in a second AWS Region. Create an AWS Global Accelerator endpoint, and associate the endpoint with the ALBs. Update DNS records to point to the Global Accelerator endpoint.
- Explanation: AWS Elastic Disaster Recovery (DRS) is designed to replicate EC2 instances to another region for disaster recovery. With a cross-Region read replica for the RDS database and the use of AWS Global Accelerator, this solution allows for quick failover between regions with minimal impact on latency.
- Pros:
- Elastic Disaster Recovery provides fast failover for EC2 instances.
- Cross-Region RDS replication ensures minimal data loss, with a 5-minute RPO for the database tier.
- AWS Global Accelerator ensures optimal routing and low-latency failover to the healthy region.
- Selected Reason: This solution meets both the RPO and RTO objectives, with the added benefit of minimal latency due to Global Accelerator's intelligent routing across regions. It is a robust, scalable solution with low operational overhead once set up.
Option B: Configure the EC2 instances to use Amazon Data Lifecycle Manager (Amazon DLM) to take snapshots of the EBS volumes. Configure RDS automated backups. Configure backup replication to a second AWS Region. Create an ALB in the second Region. Create an AWS Global Accelerator endpoint, and associate the endpoint with the ALBs. Update DNS records to point to the Global Accelerator endpoint.
- Explanation: Amazon DLM can automate snapshots of EC2 instances’ EBS volumes, and RDS automated backups provide data backups. However, this solution lacks real-time replication for the application tier (EC2 instances). While the database has backup replication across regions, this would create a higher RTO due to the need to restore EC2 instance snapshots from backups in case of a failure, which would likely take longer than using Elastic Disaster Recovery.
- Rejection Reason: While backup replication across regions is us...
Author: Emma · Last updated May 13, 2026
A solutions architect wants to cost-optimize and appropriately size Amazon EC2 instances in a single AWS account. The solutions architect wants to ensure that the instances are optimized based on CPU, memory, and network metrics.
Wh...
To meet the requirement of cost-optimizing and appropriately sizing Amazon EC2 instances based on CPU, memory, and network metrics, the solutions architect should focus on monitoring, metrics collection, and automated recommendations to optimize instance usage. Here's an evaluation of each option:
Option A: Purchase AWS Business Support or AWS Enterprise Support for the account.
- Explanation: AWS Business or Enterprise Support provides access to a variety of tools, including the AWS Trusted Advisor, which can help identify underutilized resources. However, it does not directly optimize instance sizing or provide detailed recommendations based on CPU, memory, and network metrics.
- Rejection Reason: While AWS Business or Enterprise Support can provide some level of insight through Trusted Advisor and other support tools, it does not directly address the requirement of optimizing EC2 instances based on the specific metrics of CPU, memory, and network utilization. Therefore, this is not the most relevant solution.
Option B: Turn on AWS Trusted Advisor and review any “Low Utilization Amazon EC2 Instances” recommendations.
- Explanation: AWS Trusted Advisor is a tool that provides real-time guidance to help provision resources based on best practices. The “Low Utilization Amazon EC2 Instances” recommendation can identify instances that are underutilized, which may be oversized or overprovisioned, and suggest downsizing or switching instance types.
- Pros: Trusted Advisor helps identify underutilized instances, allowing cost savings by downsizing or resizing instances. It’s a useful step for cost optimization.
- Selected Reason: Trusted Advisor’s "Low Utilization" recommendations are directly tied to optimizing EC2 instances based on utilization, which aligns with the goal of sizing EC2 instances appropriately.
Option C: Install the Amazon CloudWatch agent and configure memory metric collection on the EC2 instances.
- Explanation: By default, Amazon CloudWatch collects CPU, disk, and network metrics for EC2 instances. However, it does not collect memory usage metrics unless you install the CloudWatch agent. Collecting memory metrics allows a more complete picture of an EC2 instance’s performance and resource ut...
Author: Lucas Carter · Last updated May 13, 2026
A company uses an AWS CodeCommit repository. The company must store a backup copy of the data that is in the repository in a second A...
Option A: Configure AWS Elastic Disaster Recovery to replicate the CodeCommit repository data to the second Region.
Why Rejected: AWS Elastic Disaster Recovery (DRS) is primarily designed for disaster recovery of servers and workloads in the case of failure, replicating servers or entire environments between regions for high availability. It is not suited for replicating specific resources such as CodeCommit repositories, which are part of AWS Developer Tools. There is no direct integration between Elastic Disaster Recovery and CodeCommit repositories, so this option is not viable for CodeCommit data backup and replication.
---
Option B: Use AWS Backup to back up the CodeCommit repository on an hourly schedule. Create a cross-Region copy in the second Region.
Why Rejected: As of now, AWS Backup does not support direct backup of AWS CodeCommit repositories. While AWS Backup can be used for services like EC2, RDS, DynamoDB, and others, CodeCommit repositories are not included in the list of supported resources for backup via AWS Backup. Therefore, this option is not applicable for CodeCommit.
---
Option C: Create an Amazon EventBridge rule to invoke AWS CodeBuild when the company pushes code to the repository. Use CodeBuild to clone the repository. Create a .zip file of the content. Copy the file to an S3 bucket in the second Region.
Why Selected: This solution is feasible because it uses Amazon EventBrid...
Author: CrimsonViperX · Last updated May 13, 2026
A company has multiple business units that each have separate accounts on AWS. Each business unit manages its own network with several VPCs that have CIDR ranges that overlap. The company's marketing team has created a new internal application and wants to make the application accessible to all the other business un...
Option A: Instruct each business unit to add a unique secondary CIDR range to the business unit's VPC. Peer the VPCs and use a private NAT gateway in the secondary range to route traffic to the marketing team.
Why Rejected:
- Adding a unique secondary CIDR to each business unit’s VPC and peering VPCs can result in significant complexity in managing overlapping CIDR ranges, especially in large environments with multiple business units. The CIDR overlaps would need to be manually managed, and VPC peering itself can be operationally complex when there are many VPCs and CIDR conflicts.
- Additionally, using NAT gateways across VPCs adds unnecessary operational overhead in terms of managing routing and IP address translation. This would likely require careful manual configuration of route tables, NAT Gateway setup, and peering relationships.
- This option does not scale well and requires a high level of manual intervention.
---
Option B: Create an Amazon EC2 instance to serve as a virtual appliance in the marketing account's VPC. Create an AWS Site-to-Site VPN connection between the marketing team and each business unit's VPC. Perform NAT where necessary.
Why Rejected:
- This solution introduces unnecessary complexity and overhead by requiring a Site-to-Site VPN between every business unit's VPC and the marketing team’s VPC. Setting up and maintaining multiple VPNs can be time-consuming, particularly with many business units involved.
- Moreover, using EC2 as a virtual appliance requires ongoing management and scaling, adding operational overhead. There are also concerns about the availability and reliability of the EC2 instance as a central hub for NAT and routing.
- This solution also adds significant latency and complexity due to the VPNs and the need to manage NAT on the EC2 instance.
---
Option C: Create an AWS PrivateLink endpoint service to share the marketing application. Grant permission to specific AWS accounts to connect to the service. Create interface VPC endpoints in other accounts to access the application by using private IP addresses.
Why Selected:
- AWS PrivateLink provides a seamless way to privately connect VPCs across different AWS accounts using private IP addresses. This solution ...
Author: Amelia · Last updated May 13, 2026
A company needs to audit the security posture of a newly acquired AWS account. The company's data security team requires a notification only when an Amazon S3 bucket becomes publicly exposed. The company has already established an Amazon Simple Notification Service (Amazon ...
Option A: Create an S3 event notification on all S3 buckets for the isPublic event. Select the SNS topic as the target for the event notifications.
Why Rejected:
- Amazon S3 event notifications are primarily designed to trigger actions based on object-level events, such as object creation or deletion, not on changes to the bucket's configuration (e.g., making the bucket public).
- S3 does not natively support an "isPublic" event for bucket configuration changes. Therefore, this solution would not be able to notify the security team about changes that make a bucket publicly accessible.
- While S3 event notifications are useful for tracking object-level events, they do not cover the specific use case of monitoring public bucket access.
---
Option B: Create an analyzer in AWS Identity and Access Management (IAM) Access Analyzer. Create an Amazon EventBridge rule for the event type “Access Analyzer Finding” with a filter for “isPublic: true.” Select the SNS topic as the EventBridge rule target.
Why Selected:
- IAM Access Analyzer helps identify when an S3 bucket (or any other resource) becomes publicly accessible. By creating an analyzer in AWS IAM Access Analyzer, you can detect and monitor changes to a resource's access policy, such as making a bucket publicly accessible.
- EventBridge can then be used to filter specific findings from Access Analyzer, such as the event type indicating that a bucket has become public (i.e., "isPublic: true"). This allows automated notifications to be sent via SNS to the security team only when the bucket's access changes to public.
- This solution is highly relevant and precise for the task of monitoring public exposure of S3 buckets, and it integrates well with existing tools like SNS for notifications.
Key Factors:
- Provides visibility into the security posture of resources based on access policy findings.
- EventBridge can be fine-tuned to send notifications only for specific findings, ensuring the data security team is alerted only when necessary.
- Minimal operational overhead after initial setup.
---
Option C: Create ...
Author: Benjamin · Last updated May 13, 2026
A solutions architect needs to assess a newly acquired company's portfolio of applications and databases. The solutions architect must create a business case to migrate the portfolio to AWS. The newly acquired company runs applications in an on-premises data center. The data center is not well documented. The solutions architect cannot immediately determine how many applications and databases exist. Traffic for the applications is variable. Some applications are batch pr...
Option A: Use AWS Server Migration Service (AWS SMS) and AWS Database Migration Service (AWS DMS) to evaluate migration. Use AWS Service Catalog to understand application and database dependencies.
Why Rejected:
- AWS SMS is primarily used for migrating virtual machines (VMs) to AWS, and AWS DMS helps migrate databases. While these services are useful for the actual migration phase, they are not designed to help assess and discover applications and their dependencies before migration.
- AWS Service Catalog is used to manage collections of AWS resources, but it does not have the capability to provide deep insights into existing application dependencies, making it unsuitable for the early discovery phase of the migration process.
- This option focuses more on the migration process itself rather than the necessary assessment and discovery of the portfolio.
---
Option B: Use AWS Application Migration Service. Run agents on the on-premises infrastructure. Manage the agents by using AWS Migration Hub. Use AWS Storage Gateway to assess local storage needs and database dependencies.
Why Rejected:
- AWS Application Migration Service (formerly known as Server Migration Service) is primarily designed for lift-and-shift migrations of applications. It requires agents to be installed on the source infrastructure, which may not be feasible in the early discovery phase before the migration begins.
- AWS Storage Gateway is useful for integrating on-premises applications with AWS storage services, but it doesn’t help with understanding application dependencies or performing a portfolio assessment.
- While this option provides tools for migration and storage management, it doesn't focus on the required task of gaining insight into the application portfolio and understanding dependencies prior to migration.
---
Option C: Use Migration Evaluator to generate a list of servers. Build a report for a business case. Use AWS Migration Hub to view the portfolio. Use AWS Application Discovery Service to gain an understanding of application dependencies.
Why Selected:
- AWS Migration Evaluator (formerly known as TSO Logic) helps create a business case by generating a detailed report of the server portfolio, including the to...
Author: Ethan Smith · Last updated May 13, 2026
A company has an application that runs as a ReplicaSet of multiple pods in an Amazon Elastic Kubernetes Service (Amazon EKS) cluster. The EKS cluster has nodes in multiple Availability Zones. The application generates many small files that must be accessible across all running instances of the application. The company needs to back...
Option A: Create an Amazon Elastic File System (Amazon EFS) file system and a mount target for each subnet that contains nodes in the EKS cluster. Configure the ReplicaSet to mount the file system. Direct the application to store files in the file system. Configure AWS Backup to back up and retain copies of the data for 1 year.
Why Selected:
- Amazon EFS provides a scalable, managed network file system that is ideal for shared file storage across multiple instances. In this case, it allows all the pods in the EKS cluster (across multiple Availability Zones) to access the files concurrently and share data efficiently.
- Fast storage performance: EFS is designed to provide low-latency file operations, which is essential for applications that require fast access to many small files.
- Backup and retention: AWS Backup integrates seamlessly with EFS, allowing for automated backups and retention of data for up to 1 year. This ensures that the company's backup requirements are met without manual intervention.
- Multi-AZ support: Since the EKS nodes are spread across multiple Availability Zones, the EFS file system can be mounted in all subnets in those zones, ensuring high availability and fault tolerance for the application.
Key Factors:
- Shared file system across all pods.
- Low-latency access to files.
- Seamless integration with AWS Backup for automated, long-term retention of backups.
---
Option B: Create an Amazon Elastic Block Store (Amazon EBS) volume. Enable the EBS Multi-Attach feature. Configure the ReplicaSet to mount the EBS volume. Direct the application to store files in the EBS volume. Configure AWS Backup to back up and retain copies of the data for 1 year.
Why Rejected:
- EBS Multi-Attach allows an EBS volume to be attached to multiple EC2 instances in the same Availability Zone, but it does not work well in a Kubernetes environment where multiple pods on different nodes across multiple Availability Zones need to access the same storage.
- EBS volumes are designed for single-instance attachment, and while Multi-Attach supports EC2 instances, it does not natively support Kubernetes pods running across different Availability Zones. This could lead to issues in performance, reliability, and scalability.
- Ad...
Author: Lina Zhang · Last updated May 13, 2026
A company runs a customer service center that accepts calls and automatically sends all customers a managed, interactive, two-way experience survey by text message. The applications that support the customer service center run on machines that the company hosts in an on-premises data center. The hardware that the company uses is old, and the company is experiencing downtime with the sys...
To solve the problem, we need to consider the following factors for the best solution:
Key Factors:
1. Operational Overhead: The company seeks to reduce operational overhead, which means avoiding manual management of infrastructure like EC2 instances or self-hosted systems.
2. Reliability: The solution must be highly available and resilient, especially since the company is facing downtime with its current setup.
3. Scalability: The solution should be able to scale automatically based on demand (e.g., fluctuating call volumes or survey responses).
4. Integration: The solution should provide integrated services for both call center operations and survey management.
Analyzing the Options:
- Option A: Use Amazon Connect to replace the old call center hardware. Use Amazon Pinpoint to send text message surveys to customers.
- Amazon Connect is a fully managed cloud-based call center service that eliminates the need to manage traditional call center hardware, meeting the need for improved reliability and scalability.
- Amazon Pinpoint is a fully managed service for sending targeted messages, including text messages, with analytics, which fits perfectly for sending interactive surveys.
- Why it works: Both Amazon Connect and Amazon Pinpoint are fully managed services, meaning minimal operational overhead. They also integrate easily with each other for a seamless solution.
- Why it’s the best: This solution minimizes the need for managing infrastructure and provides a highly reliable, scalable, and easy-to-use approach for both call center operations and survey management.
- Option B: Use Amazon Connect to replace the old call center hardware. Use Amazon Simple Notification Service (Amazon SNS) to send text message surveys to customers.
- Amazon Connect still addresses the call center needs, but Amazon SNS is a simp...
Author: Isabella1 · Last updated May 13, 2026
A company is building a call center by using Amazon Connect. The company's operations team is defining a disaster recovery (DR) strategy across AWS Regions. The contact center has dozens of contact flows, hundreds of use...
To determine the best solution for disaster recovery (DR) with the lowest recovery time objective (RTO), we need to focus on key factors such as:
Key Factors:
1. Speed of Recovery: How quickly can we restore functionality in case of a failure?
2. Automation: How much manual intervention is required in the event of a failure?
3. Comprehensive Recovery: Does the solution ensure that all critical components (users, contact flows, phone numbers) are recovered?
4. Cost and Complexity: Does the solution balance complexity and cost while still achieving low RTO?
Analyzing the Options:
- Option A: Create an AWS Lambda function to check the availability of the Amazon Connect instance and to send a notification to the operations team in case of unavailability. Create an Amazon EventBridge rule to invoke the Lambda function every 5 minutes. After notification, instruct the operations team to use the AWS Management Console to provision a new Amazon Connect instance in a second Region. Deploy the contact flows, users, and claimed phone numbers by using an AWS CloudFormation template.
- Why it’s rejected: This option requires manual intervention from the operations team to provision the new Amazon Connect instance and deploy necessary components (contact flows, users, phone numbers) after receiving a notification. The manual step of provisioning a new instance increases the RTO significantly. Additionally, creating an EventBridge rule to check availability every 5 minutes does not guarantee immediate failover when needed.
- RTO Impact: Medium to high, because of the manual intervention required.
- Option B: Provision a new Amazon Connect instance with all existing users in a second Region. Create an AWS Lambda function to check the availability of the Amazon Connect instance. Create an Amazon EventBridge rule to invoke the Lambda function every 5 minutes. In the event of an issue, configure the Lambda function to deploy an AWS CloudFormation template that provisions contact flows and claimed numbers in the second Region.
- Why it’s rejected: Although this option automates more aspects of the recovery process (like deploying contact flows and claimed phone numbers), it still relies on an EventBridge rule that checks every 5 minutes. If the failure occurs in between checks, there will be a delay in initiating the recovery process. Also, provisioning users is not included in this option.
- RTO Impact: Medium, because of the relianc...
Author: Kai · Last updated May 13, 2026
A company runs an application on AWS. The company curates data from several different sources. The company uses proprietary algorithms to perform data transformations and aggregations. After the company performs ETL processes, the company stores the results in Amazon Redshift tables. The company sells this data to other companies. The company downloads the data as files from the Amazon Redshift tables and transmits the files to several data customers by using FTP. The number of data customers has grown significantly. Management of the data customers has become difficult.
The company will use AWS Data Exchange to create a data product that the company can use to shar...
To solve the problem of managing the growing number of data customers while ensuring data security, ease of access, and minimal operational overhead, we need to focus on the following key factors:
Key Factors:
1. Customer Identity Verification: The company needs to confirm the identity of data customers before sharing the data.
2. Access to the Latest Data: Customers need access to the most recent data when the company publishes it.
3. Operational Overhead: The solution should minimize ongoing operational management.
4. Security and Control: The company must ensure that only authorized customers have access to the data.
Analyzing the Options:
- Option A: Use AWS Data Exchange for APIs to share data with customers. Configure subscription verification. In the AWS account of the company that produces the data, create an Amazon API Gateway Data API service integration with Amazon Redshift. Require the data customers to subscribe to the data product.
- Why it's rejected: This option involves exposing an API via API Gateway, which may work for certain use cases but requires significant custom development to integrate with Redshift and manage subscriptions effectively. While this would provide real-time access to data, it introduces additional complexity in API management, authentication, and scaling. This solution increases operational overhead compared to more straightforward file-sharing approaches.
- RTO Impact: High operational overhead due to custom API management.
- Option B: In the AWS account of the company that produces the data, create an AWS Data Exchange datashare by connecting AWS Data Exchange to the Redshift cluster. Configure subscription verification. Require the data customers to subscribe to the data product.
- Why it works: This option directly integrates AWS Data Exchange with the Redshift cluster, allowing for the creation of a data product that can be subscribed to by customers. Data customers can easily access the most recent data without requiring manual file transfers. The subscription verification ensures that only authorized customers can access the data.
- Why it’s the best: This solution provides an efficient, low-overhead method for sharing data with customers. It integrates well with the existing Redshift data store and enables s...
Author: Sofia · Last updated May 13, 2026
A solutions architect is designing a solution to process events. The solution must have the ability to scale in and out based on the number of events that the solution receives. If a processing error occurs, the even...
To determine the best solution, let's break down the requirements and evaluate each option:
Key Requirements:
1. Scalability: The solution must scale in and out based on the number of events it receives.
2. Error Handling: If a processing error occurs, the event must be moved to a separate queue for review.
3. Operational Efficiency: The solution should be easy to manage and set up without excessive operational overhead.
Analyzing the Options:
- Option A: Send event details to an Amazon Simple Notification Service (Amazon SNS) topic. Configure an AWS Lambda function as a subscriber to the SNS topic to process the events. Add an on-failure destination to the function. Set an Amazon Simple Queue Service (Amazon SQS) queue as the target.
- Why it works: SNS can easily fan out events to Lambda functions. Lambda provides scalability to handle varying amounts of events, and it can be configured with an on-failure destination to send failed events to an SQS queue for review.
- Why it’s the best: This option fully meets the scalability requirement with Lambda's automatic scaling. It also ensures error handling by sending failed events to SQS.
- RTO Impact: Low operational overhead as SNS, Lambda, and SQS are fully managed services. This solution offers automatic scaling and built-in failure handling.
- Option B: Publish events to an Amazon Simple Queue Service (Amazon SQS) queue. Create an Amazon EC2 Auto Scaling group. Configure the Auto Scaling group to scale in and out based on the ApproximateAgeOfOldestMessage metric of the queue. Configure the application to write failed messages to a dead-letter queue.
- Why it’s rejected: While this approach provides scalability via EC2 Auto Scaling, it introduces complexity. It requires you to manage EC2 instances and an Auto Scaling group, which adds operational overhead. Additionally, manually scaling EC2 instances based on the queue's age can be less responsive compared to the more efficient Lambda-based scaling.
- Operational Complexity: Requir...
Author: Leah Davis · Last updated May 13, 2026
A company runs a processing engine in the AWS Cloud. The engine processes environmental data from logistics centers to calculate a sustainability index. The company has millions of devices in logistics centers that are spread across Europe. The devices send information to the processing engine through a RESTful API.
The API experiences unpredictable bursts of traffic. The company m...
Let's evaluate each option based on the following requirements:
Key Requirements:
1. Handling Unpredictable Bursts of Traffic: The solution must be able to scale efficiently during traffic bursts.
2. Data Loss is Unacceptable: The solution must ensure that no data is lost during processing, even in high-volume situations.
3. Scalability: The solution should automatically scale based on the incoming traffic.
4. Data Integrity and Processing: The solution must process data reliably and quickly.
Analyzing the Options:
- Option A: Create an Application Load Balancer (ALB) for the RESTful API. Create an Amazon Simple Queue Service (Amazon SQS) queue. Create a listener and a target group for the ALB. Add the SQS queue as the target. Use a container that runs in Amazon Elastic Container Service (Amazon ECS) with the Fargate launch type to process messages in the queue.
- Why it’s rejected: Although this option uses SQS to handle unpredictable traffic and ECS for processing, it involves more complex infrastructure setup (ALB, ECS, Fargate). The ALB is unnecessary when you already have an API Gateway solution for handling RESTful APIs. This option introduces additional components that could complicate scaling, error handling, and maintenance.
- RTO Impact: The ALB and ECS layers might cause higher operational overhead and are less efficient for handling RESTful APIs compared to alternatives like API Gateway.
- Option B: Create an Amazon API Gateway HTTP API that implements the RESTful API. Create an Amazon Simple Queue Service (Amazon SQS) queue. Create an API Gateway service integration with the SQS queue. Create an AWS Lambda function to process messages in the SQS queue.
- Why it works: This solution provides a highly scalable, fully managed API Gateway for handling RESTful API calls. The integration with Amazon SQS ensures that the data is queued for processing, and AWS Lambda allows for automatic scaling to process the data without worrying about server management. SQS ensures that data is not lost, as it provides durable message storage until Lambda processes it. The Lambda function can scale automatically based on the traffic, ensuring no data loss even during bursts.
- Why it’s the best: This solution is simple, scalable, and r...
Author: Benjamin · Last updated May 13, 2026
A company is designing its network configuration in the AWS Cloud. The company uses AWS Organizations to manage a multi-account setup. The company has three OUs. Each OU contains more than 100 AWS accounts. Each account has a single VPC, and all the VPCs in each OU are in the same AWS Region.
The CIDR ranges for all the AWS accounts do not overlap. The company needs to implement a solution in which VPCs ...
To solve this problem, the goal is to allow communication between VPCs within the same organizational unit (OU) but restrict communication between VPCs in different OUs. We need to choose a solution that minimizes operational overhead and ensures scalability as the company manages hundreds of accounts across multiple OUs.
Let's analyze each option based on the requirements:
Option A: Create an AWS CloudFormation stack set that establishes VPC peering between accounts in each OU. Provision the stack set in each OU.
- Explanation: This option involves manually establishing VPC peering connections between accounts in each OU using CloudFormation.
- Pros: It is highly customizable and works well for small-scale configurations.
- Cons: With over 100 accounts per OU, this approach would become unmanageable due to the sheer volume of VPC peering connections that would need to be maintained. Each account would require multiple peering connections to other accounts, and managing peering connections at this scale would lead to high operational overhead. Additionally, peering does not inherently scale well across multiple OUs.
- Why Rejected: This solution doesn’t scale well for large numbers of accounts and introduces significant operational complexity.
Option B: In each OU, create a dedicated networking account that has a single VPC. Share this VPC with all the other accounts in the OU by using AWS Resource Access Manager (AWS RAM). Create a VPC peering connection between the networking account and each account in the OU.
- Explanation: This option uses AWS Resource Access Manager (AWS RAM) to share a single VPC in the networking account with the other accounts in the OU. Each account then establishes a VPC peering connection with the networking account.
- Pros: Centralizes the networking in a single account, which simplifies management compared to individual VPC peering. It also...
Author: Alexander · Last updated May 13, 2026
A company is migrating an application to AWS. It wants to use fully managed services as much as possible during the migration. The company needs to store large important documents within the application with the following requirements:
1. The data must be highly durable and available
2. The data must always be encrypted at rest and in transit
3. ...
Let's analyze each option based on the company's requirements:
Key Requirements:
1. Highly durable and available – The solution must provide high availability and durability for the data.
2. Encrypted at rest and in transit – The data must be encrypted both when it is stored and during transmission.
3. Encryption key management – The encryption key must be managed by the company and rotated periodically.
Option A: Deploy the storage gateway to AWS in file gateway mode. Use Amazon EBS volume encryption using an AWS KMS key to encrypt the storage gateway volumes.
- Explanation: In this option, you deploy an AWS Storage Gateway in file gateway mode, which connects on-premises applications to AWS storage. You would use Amazon EBS volumes for the Storage Gateway with EBS encryption enabled.
- Pros: The Storage Gateway offers an on-premises solution to access cloud storage, which is ideal for hybrid environments. EBS volumes can be encrypted with KMS-managed keys.
- Cons: This option introduces complexity because it is more suited for hybrid cloud scenarios, where you need to integrate on-premises data with AWS. It doesn’t provide the most seamless solution for purely cloud-based workloads and doesn't directly address the goal of using fully managed cloud-native services.
- Why Rejected: This option is less suited for purely cloud-native storage needs and doesn't meet the requirement for fully managed services as the company is migrating to AWS.
Option B: Use Amazon S3 with a bucket policy to enforce HTTPS for connections to the bucket and to enforce server-side encryption and AWS KMS for object encryption.
- Explanation: Amazon S3 is a highly durable and available object storage service. You can enforce encryption at rest by enabling server-side encryption with AWS KMS keys, and enforce HTTPS for secure transmission of data.
- Pros: S3 offers high durability (11 9's) and availability, fully managed encryption both at rest and in transit. S3 supports encryption key management via AWS KMS, and you can set bucket policies to enforce encryption and HTTPS. S3 also supports automatic key rotation via KMS.
- Cons: S3 is designed for object storage and might not be optimal for use cases requiring high-performance file storage or complex file systems.
- Why Selected: This solution is fully managed, scalable, and meets all...
Author: Oliver · Last updated May 13, 2026
A company's public API runs as tasks on Amazon Elastic Container Service (Amazon ECS). The tasks run on AWS Fargate behind an Application Load Balancer (ALB) and are configured with Service Auto Scaling for the tasks based on CPU utilization. This service has been running well for several months.
Recently, API performance slowed down and made the application unusable. The company discovered that a significant number of SQL injection attacks had occurred against the API and that the API service had scaled to its maximum amount.
A solutions archite...
Let's analyze each option in detail, considering the goal of blocking SQL injection attacks while ensuring legitimate traffic can still pass through with minimal operational overhead:
Key Requirements:
1. Prevent SQL injection attacks – The primary goal is to prevent malicious requests from reaching the ECS API service.
2. Allow legitimate traffic – Legitimate users should not be impacted by the solution.
3. Maximize operational efficiency – The solution should be easy to implement, manage, and scale.
Option A: Create a new AWS WAF web ACL to monitor the HTTP requests and HTTPS requests that are forwarded to the ALB in front of the ECS tasks.
- Explanation: AWS WAF (Web Application Firewall) can be used to monitor incoming HTTP and HTTPS requests. A WAF web ACL (Access Control List) can be set up to filter and block suspicious traffic.
- Pros: AWS WAF is a fully managed service, easy to integrate with the ALB, and can block SQL injection attacks with predefined rules or custom rule sets.
- Cons: This option mentions monitoring traffic but doesn't provide specifics on how it will specifically block SQL injection attacks. Monitoring alone will not prevent the attacks effectively. Blocking needs to be part of the solution, and this option lacks clear rules to address the SQL injection vulnerability.
- Why Rejected: Monitoring alone isn’t sufficient; it doesn't actively prevent SQL injection attacks from reaching the ECS tasks.
Option B: Create a new AWS WAF Bot Control implementation. Add a rule in the AWS WAF Bot Control managed rule group to monitor traffic and allow only legitimate traffic to the ALB in front of the ECS tasks.
- Explanation: AWS WAF Bot Control is designed to identify and block bot traffic (e.g., automated scraping or attacks) based on behavior. This would help identify non-legitimate traffic patterns.
- Pros: Bot Control can be effective at blocking malicious bot traffic that might be responsible for SQL injection attacks.
- Cons: Bot Control primarily focuses on blocking bot traffic based on behavior patterns. While it may block some attack traffic, it is not specifically focused on blocking SQL injection attacks, and it may not be as precise as rules tailored to prevent SQL injection specifically.
- Why Rejected: This option is focused on blocking bots, which may not directly address SQL injection attacks, and may miss more sophisticated SQL injection techniques or legitimate non-bot traffic.
Option C: Create a new AWS WAF web ACL. Add a new rule that blocks requests that match the SQL database rule group. Set the web ACL to allow all other traffic that does not match those rules. Attach the w...
Author: FrozenWolf2022 · Last updated May 13, 2026
An environmental company is deploying sensors in major cities throughout a country to measure air quality. The sensors connect to AWS IoT Core to ingest timeseries data readings. The company stores the data in Amazon DynamoDB.
For business continuity, the company...
To design a solution that ingests and stores timeseries data in two AWS regions for business continuity, we need to ensure that the data can be reliably ingested from the sensors, stored in DynamoDB, and replicated across regions for high availability and fault tolerance. The solution must address two key aspects:
1. Ingest data from multiple regions – The IoT sensors will need to send data to AWS IoT Core endpoints in both regions.
2. Store and replicate the data across regions – The DynamoDB table needs to be replicated across regions to ensure high availability and business continuity.
Let's go through each option:
Option A: Create an Amazon Route 53 alias failover routing policy with values for AWS IoT Core data endpoints in both Regions. Migrate data to Amazon Aurora global tables.
- Explanation: This solution suggests using a failover routing policy for Route 53 to direct traffic to the IoT Core endpoints based on region availability. It also mentions migrating data to Amazon Aurora global tables.
- Pros: Aurora global tables provide cross-region replication and high availability, but it's a relational database service, not suitable for timeseries data.
- Cons: Aurora is not a good fit for storing timeseries data generated by sensors; DynamoDB is more appropriate for this use case due to its NoSQL nature and scalability. Additionally, using failover routing doesn’t meet the need for active-active data ingestion across regions.
- Why Rejected: Aurora isn’t the ideal storage solution for timeseries data, and the failover routing doesn't allow simultaneous ingestion in both regions. It introduces unnecessary complexity.
Option B: Create a domain configuration for AWS IoT Core in each Region. Create an Amazon Route 53 latency-based routing policy. Use AWS IoT Core data endpoints in both Regions as values. Migrate the data to Amazon MemoryDB for Redis and configure cross-Region replication.
- Explanation: This option uses latency-based routing to direct traffic to the closest IoT Core data endpoint and suggests using MemoryDB for Redis for data storage with cross-region replication.
- Pros: Latency-based routing can help direct traffic to the closest IoT endpoint, which is good for reducing latency.
- Cons: MemoryDB for Redis is a highly available in-memory data store, but it is not suited for long-term, persistent storage of timeseries data. Additionally, Redis doesn't provide the same level of durability and scalability for timeseries data as DynamoDB does. Using Redis as the data store is not optimal for the business requirements.
- Why Rejected: MemoryDB is not designed for the use case of storing timeseries data and doesn’t offer the durability and...
Author: Carlos Garcia · Last updated May 13, 2026
A company uses AWS Organizations for a multi-account setup in the AWS Cloud. The company's finance team has a data processing application that uses AWS Lambda and Amazon DynamoDB. The company's marketing team wants to access the data that is stored in the DynamoDB table.
The DynamoDB table contains confidential data. The marketing team can have access to only specific attributes of data in the DynamoDB table. The fi...
Let's evaluate each option step by step based on the company's requirements:
Requirements:
- The marketing team needs access to the data stored in DynamoDB, but only specific attributes.
- The marketing team and office team are in separate AWS accounts.
- The data in DynamoDB contains confidential information, so fine-grained access control is required.
Option Analysis:
---
A) Create an SCP to grant the marketing team's AWS account access to the specific attributes of the DynamoDB table. Attach the SCP to the OU of the office team.
- Analysis:
- Service Control Policies (SCPs) are used to define the maximum permissions that accounts in an AWS Organization can have. SCPs are applied at the organizational unit (OU) level and govern account-wide permissions, but they do not allow for fine-grained control over specific attributes within a service like DynamoDB.
- SCPs can't limit access to specific DynamoDB attributes. They only apply to broader permissions (such as "can access DynamoDB"). SCPs cannot control access to specific items or attributes within the table.
- Conclusion: This option is not suitable because SCPs are too broad and cannot enforce attribute-level control.
---
B) Create an IAM role in the office team's account by using IAM policy conditions for specific DynamoDB attributes (fine-grained access control). Establish trust with the marketing team's account. In the marketing team's account, create an IAM role that has permissions to assume the IAM role in the office team's account.
- Analysis:
- IAM roles allow cross-account access, and creating an IAM role in the office team’s account with a policy for fine-grained access control (using condition keys for DynamoDB) would allow the marketing team to assume the role and access specific data attributes.
- This solution uses trust relationships between the accounts, which is the correct approach for cross-account access.
- IAM policy conditions can indeed be used to limit access to specific attributes in DynamoDB, such as using the DynamoDB condition keys for `dynamodb:LeadingKeys` or `dynamodb:Attributes` to limit access to specific data elements.
- Conclusion: This is a valid solution that provides the necessary fine-grained control and uses cross-account access effectively.
---
C) Create a resource-based IAM policy that includes conditions for specific DynamoDB attributes (fine-grained access control). Attach the policy to the DynamoDB table. In the marketing team's account, create an IAM role that has permissions to access the DynamoDB table in the off...
Author: Mia · Last updated May 13, 2026
A solutions architect is creating an application that stores objects in an Amazon S3 bucket. The solutions architect must deploy the application in two AWS Regions that will be used simultaneously. The objects in the two S3 buckets must remain synchronized with each ot...
To meet the requirement of synchronizing objects between two Amazon S3 buckets in two AWS Regions with the least operational overhead, the best combination of options should ensure automatic synchronization while reducing the need for manual intervention or complex configurations.
Let's analyze each option:
A) Create an S3 Multi-Region Access Point and change the application to refer to the Multi-Region Access Point
- Reasoning: This option is highly suitable for applications that require access to multiple S3 buckets across regions but want the operational simplicity of managing a single endpoint. With Multi-Region Access Points, AWS automatically handles the routing of requests to the closest region. However, this does not replicate objects between the regions. It's a good choice for access optimization but does not meet the synchronization requirement.
- Conclusion: While beneficial for reducing complexity in accessing objects across regions, it does not solve the synchronization issue between the two S3 buckets.
B) Configure two-way S3 Cross-Region Replication (CRR) between the two S3 buckets
- Reasoning: Cross-Region Replication (CRR) allows the automatic replication of objects between two S3 buckets in different regions. Two-way replication ensures that updates in either bucket are synchronized to the other. This meets the synchronization requirement with minimal overhead and automation. It’s efficient, and once set up, it requires no further manual intervention.
- Conclusion: This is a perfect fit for the requirement to synchronize objects in both buckets automatically.
C) Modify the application to store objects in each S3 bucket
- Reasoning: Modifying the application to store objects in both S3 buckets means the application would directly upload objects to both regions. This introduces manual complexity and operational overhead because the application must manage the storage logic and handle the failure or availability issues in each region. This does not provid...
Author: Joseph · Last updated May 13, 2026
A company has an IoT platform that runs in an on-premises environment. The platform consists of a server that connects to IoT devices by using the MQTT protocol. The platform collects telemetry data from the devices at least once every 5 minutes. The platform also stores device metadata in a MongoDB cluster.
An application that is installed on an on-premises machine runs periodic jobs to aggregate and transform the telemetry and device metadata. The application creates reports that users view by using another web application that runs on the same on-premises machine. The periodic jobs take 120-600 seconds to...
To meet the company's requirements of moving the IoT platform to AWS while reducing operational overhead, we need to carefully choose solutions that are scalable, managed, and minimize maintenance efforts. Let's analyze each option:
A) Use AWS Lambda functions to connect to the IoT devices
- Reasoning: AWS Lambda functions are serverless, meaning they don't require the user to manage infrastructure. However, using Lambda to directly connect to IoT devices might not be the most optimal solution. Lambda is typically designed to respond to events (such as an S3 upload or an IoT Core message) rather than to maintain a persistent connection to IoT devices using MQTT. Maintaining persistent MQTT connections from Lambda could result in operational overhead and complexity.
- Conclusion: This approach is not ideal because Lambda is not designed for long-lived connections to IoT devices and might introduce unnecessary complexity.
B) Configure the IoT devices to publish to AWS IoT Core
- Reasoning: AWS IoT Core is a fully managed service that allows IoT devices to connect and securely transmit data to the cloud using MQTT, HTTP, or WebSockets. By configuring the IoT devices to publish directly to AWS IoT Core, the company can offload much of the management associated with maintaining connections to the devices, reducing operational overhead. IoT Core can then trigger actions such as storing data in other AWS services.
- Conclusion: This option is ideal because it simplifies the connection and communication with IoT devices, leveraging AWS's managed service that reduces operational complexity.
C) Write the metadata to a self-managed MongoDB database on an Amazon EC2 instance
- Reasoning: Managing a MongoDB database on an EC2 instance adds significant operational overhead. The company would have to manage the provisioning, patching, scaling, and availability of the MongoDB database. This increases the complexity and management burden compared to using a fully managed solution.
- Conclusion: This option is not ideal due to the high operational overhead involved in maintaining a self-managed database.
D) Write the metadata to ...
Author: Aditya · Last updated May 13, 2026
A global manufacturing company plans to migrate the majority of its applications to AWS. However, the company is concerned about applications that need to remain within a specific country or in the company's central on-premises data center because of data regulatory requirements or requirements for latency of single-digit milliseconds. The company also is concerned about the applications that it hosts in some of its factory sites, where limited network infrastructure exists.
The company wants a consistent developer experience so that its developers can build applications once a...
To meet the company's requirements for a consistent hybrid experience while addressing concerns about data regulatory requirements, latency, and limited network infrastructure in factory sites, the solution needs to allow the company to maintain applications both on-premises and in AWS. The solution should provide seamless tools, APIs, and services, ensuring a unified experience across on-premises, cloud, and hybrid environments.
Let's analyze each option:
A) Migrate all applications to the closest AWS Region that is compliant. Set up an AWS Direct Connect connection between the central on-premises data center and AWS. Deploy a Direct Connect gateway.
- Reasoning: AWS Direct Connect provides a dedicated network connection from on-premises data centers to AWS, reducing latency and improving bandwidth. However, this solution requires all applications to be migrated to AWS, which may not meet the requirement for applications that must remain in specific countries due to data regulatory requirements. It also doesn’t address the needs of applications in factory sites with limited network infrastructure.
- Conclusion: This option does not fully meet the requirement because it does not support applications that need to remain on-premises or in specific countries, nor does it solve the challenges of factory sites with limited infrastructure.
B) Use AWS Snowball Edge Storage Optimized devices for the applications that have data regulatory requirements or requirements for latency of single-digit milliseconds. Retain the devices on premises. Deploy AWS Wavelength to host the workloads in the factory sites.
- Reasoning: AWS Snowball Edge Storage Optimized devices are useful for local data storage and can run compute workloads with limited network connectivity, making them ideal for factory sites with limited infrastructure. However, Snowball Edge Storage Optimized devices are primarily for edge storage and do not offer the flexibility required for running complex applications that need low-latency compute. AWS Wavelength, which extends AWS infrastructure to telecom networks, is a good solution for low-latency applications in specific geographical locations, especially for factory sites.
- Conclusion: While Snowball...
Author: FrozenWolf2022 · Last updated May 13, 2026
A company is updating an application that customers use to make online orders. The number of attacks on the application by bad actors has increased recently.
The company will host the updated application on an Amazon Elastic Container Service (Amazon ECS) cluster. The company will use Amazon DynamoDB to store application data. A public Application Load Balancer (ALB) will provide end users with access to the application. The company must prevent ...
To meet the company's requirements of preventing attacks, ensuring business continuity, and minimizing service interruptions during an ongoing attack, we need to implement cost-effective, scalable, and secure measures. Let's go over each option and its reasoning:
A) Create an Amazon CloudFront distribution with the ALB as the origin. Add a custom header and random value on the CloudFront domain. Configure the ALB to conditionally forward traffic if the header and value match.
- Reasoning: CloudFront, a Content Delivery Network (CDN), can provide additional security by acting as a reverse proxy for the ALB, offering DDoS protection (via AWS Shield). Adding custom headers and conditional forwarding can help ensure that only legitimate traffic is passed to the ALB. However, this solution adds complexity to the architecture by introducing custom headers and conditional logic, which may not be necessary for basic security protection.
- Conclusion: While useful for enhancing security, this approach introduces additional complexity and does not directly address the core need for protecting the application during an attack in a straightforward manner.
B) Deploy the application in two AWS Regions. Configure Amazon Route 53 to route to both Regions with equal weight.
- Reasoning: Deploying the application in two regions can enhance availability and redundancy, ensuring business continuity in case one region becomes unavailable due to an attack or other issues. However, this approach significantly increases costs because it involves running duplicate infrastructure in multiple regions, which may not be necessary if we can protect the application more effectively with other services.
- Conclusion: While this improves availability, it introduces higher operational and cost complexity, and is likely an over-engineered solution to meet the company's needs. This is not the most cost-effective option for handling attacks and ensuring business continuity.
C) Configure auto scaling for Amazon ECS tasks. Create a DynamoDB Accelerator (DAX) cluster.
- Reasoning: Auto scaling ECS tasks ensures that the application can handle fl...
Author: Layla · Last updated May 13, 2026
A company runs a web application on AWS. The web application delivers static content from an Amazon S3 bucket that is behind an Amazon CloudFront distribution. The application serves dynamic content by using an Application Load Balancer (ALB) that distributes requests to a fleet of Amazon EC2 instances in Auto Scaling groups. The application uses a domain name setup in Amazon Route 53.
Some users reported occasional issues when the users attempted to access the website during peak hours. An operations team found that the ALB sometimes returned HTTP 503 Service U...
To meet the company's requirements of displaying a custom error message page when an HTTP 503 Service Unavailable error occurs, and to do so with minimal operational overhead, we need to consider solutions that efficiently integrate with the existing architecture without adding complexity or requiring significant changes.
Let's analyze each option:
A) Set up a Route 53 failover routing policy. Configure a health check to determine the status of the ALB endpoint and to fail over to the failover S3 bucket endpoint.
- Reasoning: This solution involves setting up a failover routing policy in Route 53 that would reroute traffic to a secondary S3 bucket if the ALB is unhealthy. This could work, but it introduces unnecessary complexity in routing traffic away from the ALB entirely during failures. Moreover, it does not provide the ability to display the custom error page immediately after a 503 error, as it would require routing all traffic to the secondary bucket, which might not be necessary.
- Conclusion: This option is more complex and introduces unnecessary failover logic, and it does not directly address the custom error page requirement. It is not the most efficient or low-overhead solution.
B) Create a second CloudFront distribution and an S3 static website to host the custom error page. Set up a Route 53 failover routing policy. Use an active-passive configuration between the two distributions.
- Reasoning: This solution involves creating a second CloudFront distribution with an S3 bucket to host the custom error page and setting up a failover routing policy. While this might work, it involves creating an entire secondary CloudFront distribution and managing the failover process, which is complex and requires ongoing maintenance. This solution also may not be necessary, as the primary CloudFront distribution could already handle errors.
- Conclusion: This solution introduces significant additional complexity and operational overhead for hosting and managing multiple distributions. It is not the most cost-effective or low-overhead solution.
C) Create a CloudFront origin group...
Author: Aarav · Last updated May 13, 2026
A company is planning to migrate an application to AWS. The application runs as a Docker container and uses an NFS version 4 file share.
A solutions architect must design a secure and scalable containerized solution that does not require pro...
To design a secure and scalable containerized solution without managing infrastructure, the following key factors should be considered:
1. No infrastructure management: The solution must avoid manual provisioning or management of servers or storage.
2. Secure and scalable storage: The storage solution must be secure and scalable, particularly since the application uses NFS.
3. Container orchestration: The solution must use a container service that supports orchestration, scaling, and easy management of Docker containers.
Let’s evaluate each option:
Option A: Deploy the application containers by using Amazon Elastic Container Service (Amazon ECS) with the Fargate launch type. Use Amazon Elastic File System (Amazon EFS) for shared storage.
- Amazon ECS with Fargate allows serverless deployment where there is no need to provision or manage underlying EC2 instances. Fargate automatically handles the infrastructure for you.
- Amazon EFS is a fully managed, scalable, and highly available NFS file system that can be easily mounted to Fargate tasks. It supports NFS version 4, which aligns with the requirements of the application’s file share.
- This option fits the requirement for secure and scalable containerization without manual infrastructure management.
Option B: Deploy the application containers by using Amazon Elastic Container Service (Amazon ECS) with the Fargate launch type. Use Amazon FSx for Lustre for shared storage.
- Amazon FSx for Lustre is a high-performance file system, optimized for workloads like machine learning or big data. It is not typically used for NFS workloads unless there's a specific need for high-performance computing.
- While FSx for Lustre offers scalable storage, it is not the ideal choice for typical containerized applications that need standard f...
Author: Aditya · Last updated May 13, 2026
A company is running an application in the AWS Cloud. The core business logic is running on a set of Amazon EC2 instances in an Auto Scaling group. An Application Load Balancer (ALB) distributes traffic to the EC2 instances. Amazon Route 53 record api.example.com is pointing to the ALB.
The company's development team makes major updates to the business logic. The company has a rule that when changes are deployed, only 10% of customers can receive t...
To deploy updates to the application while adhering to the rule of directing only 10% of customers to the new logic during the testing window, we need to focus on controlling how traffic is routed to the updated EC2 instances running the new business logic. We must also ensure that a customer consistently uses the same version of the business logic during their session.
Let's evaluate each option:
Option A: Create a second ALB, and deploy the new logic to a set of EC2 instances in a new Auto Scaling group. Configure the ALB to distribute traffic to the EC2 instances. Update the Route 53 record to use weighted routing, and point the record to both of the ALBs.
- Explanation: This approach involves creating a second ALB, deploying the updated logic to a new set of EC2 instances, and using Route 53 weighted routing to distribute traffic between the two ALBs.
- Drawbacks:
- Using two ALBs could lead to increased complexity and cost.
- Managing multiple ALBs for this simple scenario can add unnecessary overhead.
- While weighted routing with Route 53 is feasible for splitting traffic, it's not the best fit for ensuring session stickiness.
- Rejection reason: The use of two ALBs is more complex than necessary, and it does not address session consistency effectively.
Option B: Create a second target group that is referenced by the ALB. Deploy the new logic to EC2 instances in this new target group. Update the ALB listener rule to use weighted target groups. Configure ALB target group stickiness.
- Explanation: This option adds a second target group to the existing ALB, and updates the listener rule to distribute traffic based on weights. It also ensures stickiness, meaning a user will always be directed to the same version of the application during their session.
- Advantages:
- This approach uses a single ALB, which is simpler and more cost-effective than using multiple ALBs.
- Weighted routing via target groups allows control over how much traffic goes to the new version.
- Stickiness ensures that a customer consistently uses the same version of the application during the testing window.
- Why this option works: This option allows for controlled traffic distribution (10% to the new...
