Amazon Practice Questions, Discussions & Exam Topics by our Authors
A solutions architect must analyze a company's Amazon EC2 instances and Amazon Elastic Block Store (Amazon EBS) volumes to determine whether the company is using resources efficiently. The company is running several large, high-memory EC2 instances to host database clusters that are deployed in active/passive configurations. The utilization of these EC2 instances varies by the applications that use the databases, and the company has...
To determine the most cost-effective solution for analyzing EC2 instances and EBS volumes, the focus is on identifying utilization patterns and efficiently rightsizing the instances based on actual resource use. Let’s evaluate each option:
Option A: Create a dashboard by using AWS Systems Manager OpsCenter. Configure visualizations for Amazon CloudWatch metrics that are associated with the EC2 instances and their EBS volumes. Review the dashboard periodically, and identify usage patterns. Rightsize the EC2 instances based on the peaks in the metrics.
- Reasoning: Systems Manager OpsCenter is generally used for managing and troubleshooting operational issues rather than continuous monitoring and analysis of resource utilization. While you can visualize CloudWatch metrics, OpsCenter is not specifically designed for continuous resource analysis and rightsizing. It would require manual intervention to identify usage patterns, which could be more time-consuming and less efficient compared to other solutions.
- Rejected because: Although OpsCenter can be used to visualize metrics, it is not the most efficient or focused tool for this specific task of resource analysis and rightsizing.
Option B: Turn on Amazon CloudWatch detailed monitoring for the EC2 instances and their EBS volumes. Create and review a dashboard that is based on the metrics. Identify usage patterns. Rightsize the EC2 instances based on the peaks in the metrics.
- Reasoning: CloudWatch detailed monitoring gives you more granular data on EC2 and EBS usage, allowing you to identify usage patterns over time. By setting up a CloudWatch dashboard, you can track metrics like CPU usage, memory, and disk I/O to spot usage peaks and valleys. However, this approach still requires manual review and interpretation of the data. While CloudWatch provides the necessary data, it doesn't automate the rightsizing process or provide actionable recommendations directly.
- Rejected because: While CloudWatch provides valuable data, the solution still involves manual intervention to interpret metrics and identify patterns, which is less automated and efficient compared to other options.
Option C: Install the Amazon CloudWatch agent on each of the EC2 instances. Turn on AWS Compute Optimizer, and let it run for at least...
Author: Carlos Garcia · Last updated Jul 6, 2026
A company uses AWS Organizations for a multi-account setup in the AWS Cloud. The company uses AWS Control Tower for governance and uses AWS Transit Gateway for VPC connectivity across accounts.
In an AWS application account, the company's application team has deployed a web application that uses AWS Lambda and Amazon RDS. The company's database administrators have a separate DBA account and use the account to centrally manage all the databases across the organization. The database administrators use an Amazon EC2 instance that is deployed in the DBA account to access an RDS database that is deployed m the application account.
The application team has stored the database credentials as secrets in AWS Secrets Manager in the application account. The application team is manually sharing the secrets with...
To solve this scenario, we need to ensure that the database administrators in the DBA account have access to the secrets stored in the application account without the need for manual sharing. The approach should be secure, scalable, and follow best practices in AWS IAM and cross-account access management.
Option Analysis
A) Use AWS Resource Access Manager (AWS RAM) to share the secrets from the application account with the DBA account. In the DBA account, create an IAM role that is named DBA-Admin. Grant the role the required permissions to access the shared secrets. Attach the DBA-Admin role to the EC2 instance for access to the cross-account secrets.
- Analysis: AWS RAM can indeed be used to share resources across accounts, but in the case of AWS Secrets Manager, it doesn't directly support resource sharing like it does for services such as Amazon VPC or AWS License Manager. Therefore, AWS RAM is not applicable for sharing secrets.
- Conclusion: This option is not feasible for sharing secrets.
B) In the application account, create an IAM role that is named DBA-Secret. Grant the role the required permissions to access the secrets. In the DBA account, create an IAM role that is named DBA-Admin. Grant the DBA-Admin role the required permissions to assume the DBA-Secret role in the application account. Attach the DBA-Admin role to the EC2 instance for access to the cross-account secrets.
- Analysis: This solution uses the principle of cross-account role assumption, which is a common approach to grant access to resources across accounts. The DBA-Admin role in the DBA account will assume the DBA-Secret role in the application account to access the secrets. This option is secure and adheres to best practices of IAM role assumption for cross-account access.
- Conclusion: This option is valid, and it provides a secure, scalable solution.
C) In the DBA account, create an IAM role that is named DBA-Admin. Grant the role the required p...
Author: Stella · Last updated Jul 6, 2026
A company manages multiple AWS accounts by using AWS Organizations. Under the root OU, the company has two OUs: Research and DataOps.
Because of regulatory requirements, all resources that the company deploys in the organization must reside in the ap-northeast-1 Region. Additionally, EC2 instances that the company deploys in the DataOps OU must use a predefined list of instance types.
A solutions architect must implement a solution tha...
To implement the solution for the company’s requirements efficiently while ensuring compliance, the solution must apply region restrictions across all accounts and ensure that EC2 instances in the DataOps OU use only specific instance types. The solution must also minimize ongoing maintenance.
Option A: Create an IAM role in one account under the DataOps OU. Use the ec2:InstanceType condition key in an inline policy on the role to restrict access to specific instance types.
- Rejected because: IAM policies only apply to users, groups, and roles. Using IAM roles for managing instance types is too specific to a single account and would not scale well across all accounts under the DataOps OU. This approach also requires maintaining policies across multiple accounts, which adds operational complexity and does not address the region restriction.
Option B: Create an IAM user in all accounts under the root OU. Use the aws:RequestedRegion condition key in an inline policy on each user to restrict access to all AWS Regions except ap-northeast-1.
- Rejected because: This approach is overly manual and inefficient, requiring the creation of IAM users in each account, which is not scalable. Additionally, managing inline policies on every IAM user in every account creates significant overhead. This does not maximize operational efficiency.
Option C: Create an SCP. Use the aws:RequestedRegion condition key to restrict access to all AWS Regions except ap-northeast-1. Apply the SCP to the root OU.
- Selected because: This solution leverages Service Control Policies (SCPs), which provide a central, scalable way to enforce region restrictions across all accounts in AWS Organizations. By applying this SCP to the root OU, it ens...
Author: Ahmed97 · Last updated Jul 6, 2026
A company runs a serverless application in a single AWS Region. The application accesses external URLs and extracts metadata from those sites. The company uses an Amazon Simple Notification Service (Amazon SNS) topic to publish URLs to an Amazon Simple Queue Service (Amazon SQS) queue. An AWS Lambda function uses the queue as an event source and processes the URLs from the queue. Results are saved to an Amazon S3 bucket.
The company wants to process each URL in other Regions to compare possible differences in site localization. URL...
To implement a multi-Region deployment that meets the company's requirements, we need to make changes that ensure each Region processes URLs from the existing SNS topic and writes results to the existing S3 bucket in the primary Region. Let's analyze the options:
Option A: Deploy the SQS queue with the Lambda function to other Regions.
- Rejected because: The solution already has an SQS queue and a Lambda function in the primary Region. Replicating the queue and Lambda in other Regions is unnecessary because the objective is to keep the original Region as the source for publishing URLs and process them in multiple Regions. This would also complicate the architecture and increase maintenance.
Option B: Subscribe the SNS topic in each Region to the SQS queue.
- Rejected because: SNS topics can be subscribed to multiple endpoints, but subscribing the SNS topic directly to SQS queues in other Regions wouldn't achieve the desired outcome. The SNS topic is already publishing URLs to the queue in the primary Region, and it's unclear how adding other Regions to the SQS queue subscription will provide the multi-Region processing without replicating logic or queue data across Regions.
Option C: Subscribe the SQS queue in each Region to the SNS topic.
- Selected because: This approach allows the SNS topic to continue publishing URLs from the primary Region, while also allowing SQS queues in other Regions to receive the same messages. By subscribing SQS queues in other Regions to the SNS topic in the primary ...
Author: Manish · Last updated Jul 6, 2026
A company runs a proprietary stateless ETL application on an Amazon EC2 Linux instances. The application is a Linux binary, and the source code cannot be modified. The application is single-threaded, uses 2 GB of RAM, and is highly CPU intensive. The application is scheduled to run every 4 hours and runs for up to 2...
Option Analysis
A) Use AWS Lambda to run the application. Use Amazon CloudWatch Logs to invoke the Lambda function every 4 hours.
- Analysis: AWS Lambda is suitable for stateless applications, but it has limits on execution time, memory, and CPU resources. The maximum execution time for Lambda is 15 minutes, which may not be enough for the 20-minute runtime of the application. Additionally, Lambda has a memory limit of 10 GB, which might be sufficient for the 2 GB of RAM requirement, but the highly CPU-intensive nature of the application could be a challenge due to Lambda's limitations on CPU performance.
- Conclusion: This option is not recommended because the Lambda execution time limit of 15 minutes is too short for the application’s 20-minute runtime.
B) Use AWS Batch to run the application. Use an AWS Step Functions state machine to invoke the AWS Batch job every 4 hours.
- Analysis: AWS Batch is ideal for running large-scale, batch-processing jobs that are highly CPU-intensive and can run for extended periods. AWS Step Functions can be used to automate the invocation of the Batch job every 4 hours. This solution is well-suited for stateless ETL tasks that require significant CPU resources and can run for a long time. The application’s runtime of 20 minutes is within an acceptable range for AWS Batch jobs, and the architecture is scalable.
- Conclusion: This option is valid and well-suited to the use case, as it meets the need for a long runtime and high CPU utilization.
C) Use AWS Fargate to run the application. Use Amazon EventBridge (Amazon CloudWatch Events) to invoke the Fargate task every 4 hours.
- Analysis: AWS Fargate is designed for running containerized applications and abstracts the infrastructure management. While ...
Author: Jack · Last updated Jul 6, 2026
A company is creating a sequel for a popular online game. A large number of users from all over the world will play the game within the first week after launch. Currently, the game consists of the following components deployed in a single AWS Region:
* Amazon S3 bucket that stores game assets
* Amazon DynamoDB table that stores player scores
A solutions architect needs to design a multi-Reg...
Option Analysis
A) Create an Amazon CloudFront distribution to serve assets from the S3 bucket. Configure S3 Cross-Region Replication. Create a new DynamoDB table in a new Region. Use the new table as a replica target for DynamoDB global tables.
- Analysis:
- CloudFront: This is a good choice for serving assets globally because it caches content at edge locations, improving the performance of static assets like images, videos, and other game data stored in S3.
- S3 Cross-Region Replication: This will replicate assets across regions automatically, ensuring that users in different regions have low-latency access to the game assets.
- DynamoDB Global Tables: DynamoDB Global Tables automatically replicate data across regions and provide a fully managed multi-region solution. This is ideal for reducing latency for player scores and ensuring data consistency across regions.
Conclusion: This option is ideal as it leverages fully managed AWS services with minimal configuration, provides scalability, and ensures low latency and high availability.
B) Create an Amazon CloudFront distribution to serve assets from the S3 bucket. Configure S3 Same-Region Replication. Create a new DynamoDB table in a new Region. Configure asynchronous replication between the DynamoDB tables by using AWS Database Migration Service (AWS DMS) with change data capture (CDC).
- Analysis:
- CloudFront: This is still a good solution for serving assets globally.
- S3 Same-Region Replication: This only replicates objects within the same region, which does not help reduce latency in multiple regions.
- AWS DMS with CDC: While AWS DMS can replicate data across regions, it is not the most efficient or seamless method for DynamoDB replication. DynamoDB Global Tables are specifically designed for cross-region replication, so DMS would add complexity and overhead.
Conclusion: This option is not ideal because it uses a less efficient and more complex method (AWS DMS) for DynamoDB replication, and S3 Same-Region Replication doesn’t address the multi-region requirement.
C) Create another S3 bucket in a new Region, and configure S3 Cross-Region Replication between the buckets. Create an Amazon CloudFront distribution and configure origin failover with two origins accessing the S3 buckets in each Region. Configure DynamoDB global tables by enabling Amazon DynamoDB Strea...
Author: RadiantPhoenixX · Last updated Jul 6, 2026
A company has an on-premises website application that provides real estate information for potential renters and buyers. The website uses a Java backend and a NoSQL MongoDB database to store subscriber data.
The company needs to migrate the entire application to AWS with a similar structure. The application must b...
To determine the best solution, we need to evaluate each option based on the following key factors:
1. Database Compatibility: The company currently uses MongoDB as its database. Any solution should provide MongoDB-compatible storage without requiring changes to the application. This eliminates options that would require changing the database (e.g., using Amazon Aurora, which is a relational database service).
2. High Availability: The solution must ensure that both the database and application are deployed in a way that guarantees high availability. This means deploying resources across multiple Availability Zones (AZs) to avoid any single point of failure.
3. Non-Modification of Application: The company cannot make any changes to the application, meaning we need a solution where the application can continue using the current database and infrastructure with minimal modifications.
Option A: Use an Amazon Aurora DB cluster as the database for the subscriber data. Deploy Amazon EC2 instances in an Auto Scaling group across multiple Availability Zones for the Java backend application.
- Why it’s not suitable: Aurora is a relational database service, not a NoSQL database like MongoDB. Since the company uses MongoDB, migrating to Aurora would require changes to the application to support a relational database structure, which the company cannot do. This option does not meet the requirement to use MongoDB for the database.
Option B: Use MongoDB on Amazon EC2 instances as the database for the subscriber data. Deploy EC2 instances in an Auto Scaling group in a single Availability Zone for the Java backend application.
- Why it’s not suitable: While MongoDB on EC2 instances does meet the database compatibility requirement, this option does not provide high availability because it deploys EC2 instances in a single Availability Zone. A single AZ deployment would create a single point of failure, which does not meet the high availability requirement.
Option C: Configure Amazon DocumentDB (with MongoDB compatibility) with appropriately sized in...
Author: Zara · Last updated Jul 6, 2026
A digital marketing company has multiple AWS accounts that belong to various teams. The creative team uses an Amazon S3 bucket in its AWS account to securely store images and media files that are used as content for the company's marketing campaigns. The creative team wants to share the S3 bucket with the strategy team so that the strategy team can view the objects.
A solutions architect has created an IAM role that is named strategy_reviewer in the Strategy account. The solutions architect also has set up a custom AWS Key Management Service (AWS KMS) key in the Creative account and has associated the key with the S3 bucket. However, when users from the Strategy account assume the IAM role and try to access objects in the S3 bucket, they recei...
Key Considerations:
1. S3 Bucket Access: The Strategy account needs read-only access to the S3 bucket objects in the Creative account.
2. KMS Permissions: The S3 objects are encrypted using a custom KMS key in the Creative account, so appropriate permissions for decryption must be granted for users in the Strategy account.
3. Security Principle: The solution must follow the principle of least privilege, ensuring that only the necessary permissions are granted.
Option Analysis:
A) Create a bucket policy that includes read permissions for the S3 bucket. Set the principal of the bucket policy to the account ID of the Strategy account.
- Why it’s selected: This option allows the Strategy account to have the required read access to the S3 bucket without directly modifying IAM roles. The principal set to the Strategy account ID ensures that only the Strategy account has access.
- Why other options are rejected: The bucket policy allows for precise control over who can access the S3 bucket and does not require granting any permissions that would be considered overly permissive (e.g., setting the principal to an anonymous user).
B) Update the strategy_reviewer IAM role to grant full permissions for the S3 bucket and to grant decrypt permissions for the custom KMS key.
- Why it’s not selected: This option grants full permissions on the S3 bucket, which violates the principle of least privilege. The Strategy team only needs read permissions, not full control. Granting full permissions is excessive.
C) Update the custom KMS key policy in the Creative account to grant decrypt permissions to the strategy_reviewer IAM role.
- Why it’s selected: The custom KMS key used to encrypt the S3 objects must be accessible by the Strategy account for decryption. Granting decrypt permissions to the `strategy_reviewer` role ensures that users from the Strategy account can decrypt the objects in the S3 bucket without modifying the S3 bucket permissions themselves.
- Why other options are rejected: The KMS key policy needs to be updated for decrypt ...
Author: NebulaEagle11 · Last updated Jul 6, 2026
A life sciences company is using a combination of open source tools to manage data analysis workflows and Docker containers running on servers in its on-premises data center to process genomics data. Sequencing data is generated and stored on a local storage area network (SAN), and then the data is processed. The research and development teams are running into capacity issues and have decided to re-architect their genomics analysis platform on AWS to scale based on workload demands and reduce the turnaround time from weeks to days.
The company has a high-speed AWS Direct Connect connection. Sequencers will generate ar...
Key Considerations:
- Data Transfer: The sequencing data is expected to be around 200 GB per genome, and there will be 10-15 job requests per day. This requires a scalable and efficient data transfer solution to move data to AWS.
- Scalability: The solution should scale based on workload demands to reduce turnaround time from weeks to days, suggesting the need for automatic scaling of compute resources.
- Processing Jobs: Each job can take several hours to process with ideal compute capacity, meaning the solution needs to efficiently manage containerized processing tasks.
- Event-driven Architecture: The solution should trigger the appropriate processing tasks once data is transferred to Amazon S3.
- On-Demand Compute: The company needs on-demand compute resources that can scale dynamically without requiring manual intervention.
Option Analysis:
A) Use regularly scheduled AWS Snowball Edge devices to transfer the sequencing data into AWS. When AWS receives the Snowball Edge device and the data is loaded into Amazon S3, use S3 events to trigger an AWS Lambda function to process the data.
- Why it’s not selected: While AWS Snowball Edge is an excellent solution for transferring large amounts of data when network bandwidth is limited, the data transfer rate of 200 GB per genome is quite large, and regularly scheduled transfers might not be ideal. Additionally, using AWS Lambda for processing large genomics data would be inefficient because Lambda has memory and execution time limits (15 minutes per function), and this task requires longer processing times. Lambda isn't designed for running complex Docker containers or handling data processing that requires several hours to complete.
B) Use AWS Data Pipeline to transfer the sequencing data to Amazon S3. Use S3 events to trigger an Amazon EC2 Auto Scaling group to launch custom-AMI EC2 instances running the Docker containers to process the data.
- Why it’s not selected: While AWS Data Pipeline can be used for transferring data, it's an older service that is now somewhat superseded by newer solutions like AWS DataSync and AWS Batch. Using EC2 Auto Scaling and custom AMI EC2 instances can work, but this requires manual configuration and management of the EC2 instances, which could introduce complexity and overhead. AWS Batch provides better managed orchestration for large-scale compute tasks like this, which makes this option less ideal.
C) Use AWS DataSync to transfer the sequencing d...
Author: Aria · Last updated Jul 6, 2026
A company runs a content management application on a single Windows Amazon EC2 instance in a development environment. The application reads and writes static content to a 2 TB Amazon Elastic Block Store (Amazon EBS) volume that is attached to the instance as the root device. The company plans to deploy this application in production as a highly available and fault-tolerant solution that runs on at least three EC2 instances across multiple Availability Zones.
A solutions architect must design a solution that joins all the instances that run the application to an Active Directory domain. The solution als...
Key Considerations:
- High Availability and Fault Tolerance: The solution must be highly available and fault-tolerant, running the application on at least three EC2 instances across multiple Availability Zones.
- Active Directory (AD) Integration: The application must be able to join all EC2 instances to an Active Directory domain to manage authentication and authorization.
- Windows ACLs: The solution must support Windows Access Control Lists (ACLs) to manage file permissions.
- Consistent Content Across Instances: All instances must maintain exactly the same content at any given point in time, meaning the application needs access to a shared file system that can maintain consistency across multiple EC2 instances.
- Management Overhead: The solution should minimize ongoing management and complexity.
Option Analysis:
A) Create an Amazon Elastic File System (Amazon EFS) file share. Create an Auto Scaling group that extends across three Availability Zones and maintains a minimum size of three instances. Implement a user data script to install the application, join the instance to the AD domain, and mount the EFS file share.
- Why it’s selected: Amazon EFS is a fully managed, scalable file storage service that supports Windows ACLs and provides a shared file system across multiple EC2 instances. EFS automatically scales, ensuring that the application has consistent access to the same content across all instances. Additionally, EFS is highly available and durable, making it suitable for a fault-tolerant solution.
- Why other options are rejected:
- EFS is a good fit here because it provides simple file sharing across multiple instances with minimal management overhead.
- EFS can be easily integrated into a Windows environment with domain-joined instances, and it can be mounted across multiple Availability Zones, ensuring availability and fault tolerance.
B) Create a new AMI from the current EC2 instance that is running. Create an Amazon FSx for Lustre file system. Create an Auto Scaling group that extends across three Availability Zones and maintains a minimum size of three instances. Implement a user data script to join the instance to the AD domain and mount the FSx for Lustre file system.
- Why it’s not selected: Amazon FSx for Lustre is designed for high-performance workloads, such as data processing, and it’s optimized for workloads requiring high throughput and low latency. However, this file system is not ideal for Windows-based workloads that require support for Windows ACLs, and it doesn't provide the same level of integration with Windows servers as Amazon FSx for Windows File Server.
- Why i...
Author: RadiantPhoenixX · Last updated Jul 6, 2026
A software as a service (SaaS) based company provides a case management solution to customers A3 part of the solution. The company uses a standalone Simple Mail Transfer Protocol (SMTP) server to send email messages from an application. The application also stores an email template for acknowledgement email messages that populate customer data before the application sends the email message to the customer.
The com...
Key Considerations:
- Minimize Operational Overhead: The solution needs to minimize ongoing maintenance and management.
- Cost-Effectiveness: The solution should be affordable, particularly since the company is migrating to the cloud and aims to optimize cost efficiency.
- Email Templates and Customer Data: The solution needs to handle dynamic email templates where customer data can be merged into predefined templates.
- Scalability and Simplicity: The solution should be easily scalable and not require extensive management.
Option Analysis:
A) Set up an SMTP server on Amazon EC2 instances by using an AMI from the AWS Marketplace. Store the email template in an Amazon S3 bucket. Create an AWS Lambda function to retrieve the template from the S3 bucket and merge the customer data with the template. Use an SDK in the Lambda function to send the email message.
- Why it’s not selected: Setting up an SMTP server on EC2 instances would require significant management, including handling the email server's health, scaling, and security. Additionally, while the Lambda function could be used to manage the email templates, this option introduces unnecessary complexity and operational overhead, as the company would need to maintain EC2 instances and handle potential email delivery issues.
- Why it’s not ideal: The operational overhead of managing EC2 instances and maintaining an SMTP server is much higher than using a fully managed service like Amazon SES.
B) Set up Amazon Simple Email Service (Amazon SES) to send email messages. Store the email template in an Amazon S3 bucket. Create an AWS Lambda function to retrieve the template from the S3 bucket and merge the customer data with the template. Use an SDK in the Lambda function to send the email message.
- Why it’s not selected: While Amazon SES is a good choice for sending emails, this solution requires manually merging the template and customer data using Lambda and then sending the email. It lacks the built-in templating support that Amazon SES offers, which means the company would have to handle template management and data replacement manually.
- Why it’s not ideal: This solution could work but would still require additional logic to handle the dynamic merging of customer data into the templates. It’s less streamlined than directly using SES templating features.
C) Set up an SMTP server on Amazon EC2 instances by using an AMI from the AWS Mar...
Author: Amira · Last updated Jul 6, 2026
A company is processing videos in the AWS Cloud by Using Amazon EC2 instances in an Auto Scaling group. It takes 30 minutes to process a video Several EC2 instances scale in and out depending on the number of videos in an Amazon Simple Queue Service (Amazon SQS) queue.
The company has configured the SQS queue with a redrive policy that specifies a target dead-letter queue and a maxReceiveCount of 1. The company has set the visibility timeout for the SQS queue to 1 hour. The company has set up an Amazon CloudWatch alarm to notify the development team when there are messages in the dead-letter queue.
S...
To solve the problem of messages being moved to the dead-letter queue despite no errors in the application logs, let’s evaluate each option systematically:
A) Turn on termination protection for the EC2 Instances:
- Reasoning: Termination protection ensures that an EC2 instance cannot be accidentally terminated. However, this does not address the issue of messages being moved to the dead-letter queue due to incomplete processing. If EC2 instances are terminating before completing their task, termination protection may help prevent accidental terminations, but it does not solve the core issue of message visibility timeouts or failed message processing.
- Rejection Reason: This option doesn’t directly resolve the root cause of the issue, which seems to be related to how SQS messages are being processed and not the accidental termination of EC2 instances.
B) Update the visibility timeout for the SQS queue to 3 hours:
- Reasoning: The visibility timeout is how long a message remains invisible to other consumers after it is retrieved by an EC2 instance. If the EC2 instance takes longer than expected (more than 1 hour) to process a video, it could potentially retrieve the message again, leading to the message being moved to the dead-letter queue. Increasing the visibility timeout to 3 hours would ensure that the message remains invisible to other instances during processing, providing enough time for the video to be processed properly.
- Rejection Reason: This option directly addresses the core problem of messages being retried before they are processed. Increasing the visibility timeout ensures that the message is not processed multiple times while still being worked on, avoiding unnecessary moves to the dead-letter que...
Author: Noah · Last updated Jul 6, 2026
A company has developed APIs that use Amazon API Gateway with Regional endpoints. The APIs call AWS Lambda functions that use API Gateway authentication mechanisms. After a design review, a solutions architect identifies a set of APIs that do not require public access.
The solutions architect must design a solution to make the set of APIs accessibl...
To meet the requirements of making the APIs accessible only from a VPC while maintaining authenticated access, we need a solution that restricts access to the API to private network traffic and ensures proper authentication. Let's evaluate the options:
Option A: Create an internal Application Load Balancer (ALB). Create a target group. Select the Lambda function to call. Use the ALB DNS name to call the API from the VPC.
- Reasoning: Using an internal ALB as a proxy to the Lambda function adds complexity and introduces unnecessary overhead. The ALB setup would require configuring the Lambda as a target, which could be useful for routing traffic but is not the most efficient solution. Also, it doesn't inherently provide API Gateway authentication mechanisms, which is required.
- Conclusion: This option adds unnecessary complexity and does not directly leverage API Gateway's native capabilities for authentication. It’s a more complicated solution than needed.
Option B: Remove the DNS entry that is associated with the API in API Gateway. Create a hosted zone in Amazon Route 53. Create a CNAME record in the hosted zone. Update the API in API Gateway with the CNAME record. Use the CNAME record to call the API from the VPC.
- Reasoning: This option involves DNS manipulation and does not provide any security or authentication mechanisms for restricting API access to the VPC. It only changes the way the API is addressed. There’s no direct way to restrict access to the VPC and ensure only authenticated requests are accepted.
- Conclusion: This solution lacks the necessary network-level security and doesn’t directly solve the problem of restricting access to the VPC. It is not a valid solution for the r...
Author: Emily · Last updated Jul 6, 2026
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: Scarlett · Last updated Jul 6, 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: Aarav · Last updated Jul 6, 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: ShadowWolf101 · Last updated Jul 6, 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: Samuel · Last updated Jul 6, 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: MoonlitPantherX · Last updated Jul 6, 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 · Last updated Jul 6, 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: Ryan · Last updated Jul 6, 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: Chloe · Last updated Jul 6, 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: Ming · Last updated Jul 6, 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: Suresh · Last updated Jul 6, 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: Zain · Last updated Jul 6, 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: Evelyn · Last updated Jul 6, 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: Amira · Last updated Jul 6, 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: Oscar · Last updated Jul 6, 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: Maya2022 · Last updated Jul 6, 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: Siddharth · Last updated Jul 6, 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: Leah · Last updated Jul 6, 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: Ethan Smith · Last updated Jul 6, 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: Manish · Last updated Jul 6, 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: Zara · Last updated Jul 6, 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: Sara · Last updated Jul 6, 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: Ming88 · Last updated Jul 6, 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: Kai · Last updated Jul 6, 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: Olivia · Last updated Jul 6, 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: Ethan · Last updated Jul 6, 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: Emma · Last updated Jul 6, 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: Carlos Garcia · Last updated Jul 6, 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: Oliver · Last updated Jul 6, 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: Amira · Last updated Jul 6, 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: Jack · Last updated Jul 6, 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: Joseph · Last updated Jul 6, 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: GlowingTiger · Last updated Jul 6, 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: IronLion88 · Last updated Jul 6, 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: Amira · Last updated Jul 6, 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: Manish · Last updated Jul 6, 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: Matthew · Last updated Jul 6, 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...
