Amazon Practice Questions, Discussions & Exam Topics by our Authors
A company runs an application in the AWS Cloud that generates sensitive archival data files. The company wants to rearchitect the application's data storage. The company wants to encrypt the data files and to ensure that third parties do not have access to the data before the data is enc...
Analyzing the Requirements:
The company wants to:
1. Encrypt sensitive archival data files: This implies that encryption must be performed before storing the data in the cloud.
2. Ensure third parties do not have access to the data before it is encrypted: This suggests that the data must be encrypted before it is sent to AWS (i.e., client-side encryption).
3. Use Amazon S3 for storage: The company has already set up an S3 bucket to store the archival data.
Evaluating Each Option:
A) Configure the S3 bucket to use client-side encryption with an Amazon S3 managed encryption key. Configure the application to use the S3 bucket to store the archival files.
- Why this might work: Client-side encryption means the application will encrypt data before uploading it to S3. This ensures that data is encrypted before it reaches AWS, and no third parties can access the unencrypted data. S3-managed encryption keys (SSE-S3) are used for the server-side decryption when the data is read, but the application does the encryption.
- Why this might not be ideal: Using an S3-managed encryption key means the encryption key is managed by Amazon, which might not be desirable for sensitive data where the company needs full control over key management. Also, SSE-S3 does not provide the level of fine-grained control and auditability that AWS KMS would offer.
B) Configure the S3 bucket to use server-side encryption with AWS KMS keys (SSE-KMS). Configure the application to use the S3 bucket to store the archival files.
- Why this might not be ideal: This option involves server-side encryption, which means that the data is uploaded to S3 in plaintext and only encrypted when it reaches the S3 bucket. The company is concerned about third parties having access to the data before it is encrypted and sent to AWS. Server-side encryption doesn't fulfill this requ...
Author: Emma · Last updated Apr 16, 2026
A company uses Amazon RDS with default backup settings for its database tier. The company needs to make a daily backup of the database to meet regulatory requirements. The company must retain the backups for 30...
Analyzing the Requirements:
The company needs to:
1. Make a daily backup of the database.
2. Retain the backups for 30 days to meet regulatory requirements.
3. Minimize operational overhead, ensuring that the solution is simple and automated.
Evaluating Each Option:
A) Write an AWS Lambda function to create an RDS snapshot every day.
- Why this might work: This option involves creating a Lambda function that can automatically create an RDS snapshot every day, which ensures regular backups. The snapshots can then be retained for 30 days.
- Why this might not be ideal: While this approach automates the backup process, it involves maintaining a Lambda function and handling retention logic for the snapshots manually. The operational overhead is relatively high because you must manage the Lambda function, ensure it works correctly, and handle snapshot deletions after 30 days. Additionally, Lambda might not be the best choice for something that could be handled directly by RDS backup mechanisms.
B) Modify the RDS database to have a retention period of 30 days for automated backups.
- Why this works well: Amazon RDS provides automated backups as a managed feature, which includes daily snapshots. By setting the retention period to 30 days, RDS will automatically keep daily backups for the required duration. This approach is fully integrated into RDS, reducing manual intervention, operational overhead, and complexity.
- Why this is ideal: This solution leverages RDS’s native automated backup feature, which is designed specifically for this use case. The backups are managed automatically, and there’s no need for manual intervention or additional custom solutions, ensuring low operational overhead.
C) Use AWS Systems Manager Maintenance Windows to modify the RDS backup retention period.
- Why...
Author: StarryEagle42 · Last updated Apr 16, 2026
A company that runs its application on AWS uses an Amazon Aurora DB cluster as its database. During peak usage hours when multiple users access and read the data, the monitoring system shows degradation of database performance for the write queries. The company wants to increase the scal...
Analyzing the Requirements:
The company is experiencing degradation in write query performance during peak usage hours, particularly when multiple users access and read the data. The company wants to increase scalability to meet peak usage demands, but it also needs a cost-effective solution.
Evaluating Each Option:
A) Create a second Aurora DB cluster. Configure a copy job to replicate the users' data to the new database. Update the application to use the second database to read the data.
- Why this might not be ideal: While creating a second Aurora DB cluster could help by offloading some of the read traffic, the solution introduces additional complexity and costs. Replicating data to a new DB cluster may also introduce latency and consistency issues between the two clusters. This approach increases operational overhead and requires manual management of replication and data consistency.
- Why this is rejected: It is more complex and costly than alternatives like read replicas, and may not provide the necessary scalability or performance benefits that are needed for the application to meet peak usage demands.
B) Create an Amazon DynamoDB Accelerator (DAX) cluster in front of the existing Aurora DB cluster. Update the application to use the DAX cluster for read-only queries. Write data directly to the Aurora DB cluster.
- Why this might not be ideal: DAX is designed for use with DynamoDB to speed up read-heavy workloads, but Aurora is a relational database and is not compatible with DAX. DAX cannot be used as a caching layer for Aurora, so this solution is not applicable.
- Why this is rejected: DAX is not compatible with Aurora, making this solution irrelevant for the requirements. It doesn’t solve the scalability issue for an Aurora database.
C) Create an Aurora read replica in the existing Aurora DB cluster. Update the application to use the replica endpoint for read-only queries and to use the cluster endpoint for write queries.
- Why this works well: Aurora read replicas can offload read queries from the primary database cluster. By directi...
Author: Ella · Last updated Apr 16, 2026
A company's near-real-time streaming application is running on AWS. As the data is ingested, a job runs on the data and takes 30 minutes to complete. The workload frequently experiences high latency due to large amounts of incoming data. A solutions architect needs to design a scalable and...
Analyzing the Requirements:
The company’s application is running into latency issues because of the large amounts of incoming data, and the job processing it takes 30 minutes to complete. The goal is to design a scalable, serverless solution that improves performance and reduces latency.
Evaluating Each Option:
A) Use Amazon Kinesis Data Firehose to ingest the data.
- Why this might work: Amazon Kinesis Data Firehose is a fully managed service that can ingest streaming data and automatically deliver it to destinations like Amazon S3, Amazon Redshift, or Amazon Elasticsearch Service. It can scale automatically to handle high data volumes, making it ideal for ingesting real-time data.
- Why this might not be ideal: While Kinesis Data Firehose is excellent for data ingestion, it does not address the issue of processing data in near-real-time or improving the latency of the processing job. It is primarily focused on the ingestion layer, and the solution still needs a way to handle processing and job execution, which takes 30 minutes in the current setup.
B) Use AWS Lambda with AWS Step Functions to process the data.
- Why this works: AWS Lambda is a serverless compute service that can automatically scale to handle large amounts of incoming data, and it is well-suited for real-time or near-real-time processing. AWS Step Functions can be used to orchestrate multiple Lambda functions, enabling complex workflows and breaking down the 30-minute job into smaller tasks that can run in parallel or asynchronously. This can significantly reduce latency by processing the data faster and in a scalable, serverless manner.
- Why this is ideal: Lambda and Step Functions are both serverless and can scale automatically with incoming data. This option provides a highly scalable solution to process data faster and reduce the job's latency, making it a strong candidate for enhancing performance.
C) Use AWS Database Migration Service (AWS DMS) to ingest the data.
- Why this might not be ideal: AWS DMS is typically used for migrating databases to AWS and replicating data between different data stores. It is not designed to handl...
Author: Jack · Last updated Apr 16, 2026
A company runs a web application on multiple Amazon EC2 instances in a VPC. The application needs to write sensitive data to an Amazon S3 bucket. The data cannot be sent ...
To meet the requirement of writing sensitive data to an Amazon S3 bucket without sending it over the public internet, let's analyze each option and determine the most suitable one:
Option A: Create a gateway VPC endpoint for Amazon S3. Create a route in the VPC route table to the endpoint.
- Explanation: A gateway VPC endpoint for Amazon S3 allows communication between instances in the VPC and S3 without using the public internet. Traffic to Amazon S3 will be routed directly through the VPC endpoint, making this a private connection.
- Why it’s suitable: This option ensures that sensitive data is not sent over the public internet. It provides secure, private access to Amazon S3, which meets the security and compliance requirements.
- Why others are rejected:
- Option B: Creating an internal Network Load Balancer (NLB) with the S3 bucket as the target doesn’t make sense because an NLB is typically used to route traffic to EC2 in...
Author: Zara1234 · Last updated Apr 16, 2026
A company runs its production workload on Amazon EC2 instances with Amazon Elastic Block Store (Amazon EBS) volumes. A solutions architect needs to analyze the current EBS volume cost and to recommend optimizations. The recommendations n...
To analyze current EBS volume costs and recommend optimizations along with estimated monthly savings, let's evaluate each of the provided options based on their purpose and relevance.
Option A: Use Amazon Inspector reporting to generate EBS volume recommendations for optimization.
- Explanation: Amazon Inspector is a security assessment service, which is used to automatically assess applications for vulnerabilities and deviations from best practices in security. It does not specifically provide recommendations or analysis for optimizing EBS volumes or cost.
- Why it’s rejected: Since the objective is to analyze EBS volume costs and optimization opportunities, Amazon Inspector is not the right tool because it focuses on security rather than cost or performance optimization.
Option B: Use AWS Systems Manager reporting to determine EBS volume recommendations for optimization.
- Explanation: AWS Systems Manager is a suite of tools for managing and automating various aspects of AWS resources. While Systems Manager provides valuable insights into resource management, it does not specialize in offering direct EBS volume cost or optimization recommendations.
- Why it’s rejected: AWS Systems Manager can help with operations and monitoring but does not specifically offer detailed recommendations related to EBS cost optimization. It is more useful for managing EC2 instances, patching, and automation.
Option C: Use Amazon CloudWatch metrics reporting to determine EBS volume recommendations for optimization.
- Explanation: Amazon CloudWatch provides monitoring and observability of AWS resources, including EC2 and EBS. It can monitor EBS performance metrics (e.g...
Author: SilverBear · Last updated Apr 16, 2026
A global company runs its workloads on AWS. The company's application uses Amazon S3 buckets across AWS Regions for sensitive data storage and analysis. The company stores millions of objects in multiple S3 buckets daily. The company wants to...
To identify all S3 buckets that are not versioning-enabled across multiple regions, let's analyze each of the provided solutions and determine which one best fits the requirements.
Option A: Use Amazon S3 Storage Lens to identify all S3 buckets that are not versioning-enabled across Regions.
- Explanation: Amazon S3 Storage Lens provides a comprehensive analytics service for monitoring and understanding S3 storage usage and activity. It can provide insights into S3 bucket configurations, including whether versioning is enabled or not across all S3 buckets in an AWS account, across multiple regions.
- Why it’s suitable: S3 Storage Lens can specifically analyze bucket configurations like versioning, making it a direct and scalable solution for identifying buckets that aren't versioning-enabled. It works across AWS Regions and can be used to aggregate data from multiple buckets for easier reporting and identification.
- Why other options are rejected:
- Option B: IAM Access Analyzer for S3 is used to analyz...
Author: Olivia Johnson · Last updated Apr 16, 2026
A company wants to enhance its ecommerce order-processing application that is deployed on AWS. The application must process each order exactly once without affecting the customer experience d...
To determine which solution best meets the requirements for processing ecommerce orders exactly once while ensuring customer experience is not impacted during unpredictable traffic surges, let’s analyze each of the provided options based on the following key criteria:
1. Exactly Once Processing: The solution must guarantee that each order is processed exactly once, even during traffic spikes.
2. Scalability: The solution should scale automatically to handle unpredictable traffic surges without degrading performance.
3. Impact on Customer Experience: The solution must not interfere with the customer-facing aspects of the ecommerce application.
Option A: Create an Amazon Simple Queue Service (Amazon SQS) FIFO queue. Put all the orders in the SQS queue. Configure an AWS Lambda function as the target to process the orders.
- Explanation: Amazon SQS FIFO (First-In-First-Out) queues provide exactly once message processing and guarantee the order in which messages are processed. By using a FIFO queue, you can ensure that orders are processed exactly once and in the order they are received. The AWS Lambda function can scale automatically to process messages as they come in, making it suitable for handling traffic surges without affecting the customer experience.
- Why it’s suitable: SQS FIFO queues ensure exactly-once processing and maintain the order of messages, which is critical for order processing. The Lambda function can scale a...
Author: Suresh · Last updated Apr 16, 2026
A company has two AWS accounts: Production and Development. The company needs to push code changes in the Development account to the Production account. In the alpha phase, only two senior developers on the development team need access to the Production account. In t...
To determine which solution will best meet the requirements of pushing code changes from the Development account to the Production account, and controlling access for developers in different phases, let’s evaluate each option based on the following criteria:
Key Requirements:
1. Access control for senior developers in the alpha phase.
2. Scalability of access for more developers in the beta phase.
3. Separation of duties between the Development and Production accounts.
4. Least privilege access.
Option A: Create two policy documents by using the AWS Management Console in each account. Assign the policy to developers who need access.
- Explanation: This option suggests creating two policies, one in each account, and assigning them directly to developers who need access. However, this solution does not specify how the developers in the Development account will securely access resources in the Production account.
- Why it’s rejected: The option is not ideal for cross-account access between two AWS accounts. While it could work for users in a single account, it does not facilitate controlled access between separate accounts (Development and Production) and does not scale well when more developers need access in the beta phase. Managing access through direct policy assignment also becomes cumbersome as the number of developers increases.
Option B: Create an IAM role in the Development account. Grant the IAM role access to the Production account. Allow developers to assume the role.
- Explanation: This solution suggests creating an IAM role in the Development account, granting that role access to resources in the Production account, and allowing developers to assume that role. However, this approach does not make use of the Production account’s security features to restrict access properly. It's generally better practice to define roles in the Production account to limit access from outside sources like Development.
- Why it’s rejected: This approach might lead to security concerns, as it could potentially allow too much access from the Development account and might not fit well for a controlled, least-privilege access model between accounts.
Option C: Create an IAM role in the Production account. Define a trust policy that specifies the Development account. Allow developers to assume the role.
- Explanation: This option creates an IAM role in the Production account and defines a trust policy tha...
Author: Joseph · Last updated Apr 16, 2026
A company wants to restrict access to the content of its web application. The company needs to protect the content by using authorization techniques that are available on AWS. The company also wants to implement a serverless architecture for authorization and authentication that has low login latency.
The solution must integrate with the web application and serve web content globa...
To determine the most appropriate solution, let's evaluate each option against the key requirements:
Key Requirements:
1. Authentication and Authorization: The company needs to protect its content using authorization techniques on AWS.
2. Serverless Architecture: The solution should be serverless, so no infrastructure management is required.
3. Low Latency: The solution must provide low login latency.
4. Global Reach: The solution should serve web content globally and handle potentially increasing traffic as the user base grows.
A) Configure Amazon Cognito for authentication. Implement Lambda@Edge for authorization. Configure Amazon CloudFront to serve the web application globally.
- Authentication: Amazon Cognito is an excellent choice for authentication, as it is a fully managed service that allows easy integration for web applications and supports OAuth, SAML, and social logins.
- Authorization: Lambda@Edge allows for serverless authorization logic to be executed at AWS locations globally, ensuring low latency for authentication checks.
- Global Content Delivery: Amazon CloudFront is a global Content Delivery Network (CDN) that can distribute web content with low latency to users worldwide.
- Serverless and Scalable: This solution is serverless, as both Cognito and Lambda@Edge are fully managed services, and CloudFront handles content delivery globally with low overhead.
- Why not others: This solution is ideal because it uses fully managed services that scale well, and it ensures low-latency authentication and authorization with global content delivery.
B) Configure AWS Directory Service for Microsoft Active Directory for authentication. Implement AWS Lambda for authorization. Use an Application Load Balancer to serve the web application globally.
- Authentication: AWS Directory Service (Microsoft AD) is suitable for enterprises needing Active Directory integration but can be more complex to manage and less suited for scalable, serverless web applications.
- Authorization: AWS Lambda is a good choice for serverless authorization, but the use of AWS Directory Service requires additional management and complexity.
- Global Content Delivery: An Application Load Balancer (ALB) can distribute traffic but lacks the global distribution capabilities of CloudFront, leading to potential higher latency.
- Why not others: While ALB can s...
Author: FrostFalcon88 · Last updated Apr 16, 2026
A development team uses multiple AWS accounts for its development, staging, and production environments. Team members have been launching large Amazon EC2 instances that are underutilized. A solutions architect must prevent large instances from being launched...
To determine the most effective solution to prevent the launch of large EC2 instances across multiple AWS accounts, let's analyze each option based on key factors like ease of implementation, operational overhead, scalability, and effectiveness:
Key Requirements:
- Prevent large EC2 instances from being launched across multiple AWS accounts.
- Minimize operational overhead.
- Implement the solution globally across all environments (development, staging, production).
A) Update the IAM policies to deny the launch of large EC2 instances. Apply the policies to all users.
- IAM Policies: While updating IAM policies to deny the launch of large EC2 instances is an option, IAM policies are typically user-specific. Applying these policies to every user in every account could lead to complexity as the number of users and permissions increases.
- Operational Overhead: Managing IAM policies across multiple accounts can become cumbersome as users and roles increase. Additionally, IAM policies are not centralized when managing multiple AWS accounts.
- Why not: This solution would require manually updating policies for each user, which creates unnecessary operational overhead and does not scale well as the number of accounts grows.
B) Define a resource in AWS Resource Access Manager that prevents the launch of large EC2 instances.
- AWS Resource Access Manager (RAM): RAM is typically used to share resources like VPCs, subnets, and other resources across AWS accounts. However, it is not designed to enforce restrictions like preventing the launch of specific EC2 instances.
- Why not: RAM cannot be used for policy enforcement in this case, as its primary use is for resource sharing rather than controlling permissions or actions like launching EC2 instances.
C) Create an IAM role in each account that denies the launch of large EC2 instances. Grant the developers IAM group access to the role.
- IAM Roles: This would require creating individual IAM roles in each account and then assigning the appropriate permissions t...
Author: William · Last updated Apr 16, 2026
A company has migrated a fleet of hundreds of on-premises virtual machines (VMs) to Amazon EC2 instances. The instances run a diverse fleet of Windows Server versions along with several Linux distributions. The company wants a solution that will automate inventory and updates of the operating systems. The company also needs a summary o...
To determine the most appropriate solution for automating inventory, updates, and vulnerability reviews of the operating systems across hundreds of EC2 instances, let's break down the options based on the specific requirements:
Key Requirements:
1. Automate inventory and updates for both Windows and Linux operating systems.
2. Summary of common vulnerabilities for monthly reviews.
3. Ensure minimal operational overhead while meeting compliance and security needs.
A) Set up AWS Systems Manager Patch Manager to manage all the EC2 instances. Configure AWS Security Hub to produce monthly reports.
- Systems Manager Patch Manager: This is a good choice for automating the patching process of both Windows and Linux instances. It can help apply patches, and track their status across EC2 instances, which addresses the need for automatic updates.
- AWS Security Hub: Security Hub aggregates security findings from various services like Amazon GuardDuty, AWS Config, and Inspector. While it provides useful insights into security posture, it doesn’t focus specifically on vulnerabilities or patch management for operating systems.
- Why not: While this option addresses the patching and reporting needs, Security Hub isn't specialized in vulnerability scanning for operating systems and would require additional services (like Amazon Inspector) to provide detailed vulnerability summaries.
B) Set up AWS Systems Manager Patch Manager to manage all the EC2 instances. Deploy Amazon Inspector, and configure monthly reports.
- Systems Manager Patch Manager: This is a strong choice for automating OS patch management, both for Windows and Linux instances.
- Amazon Inspector: Amazon Inspector performs vulnerability assessments and provides detailed findings about the security posture of your EC2 instances. This directly meets the requirement for a monthly review of vulnerabilities.
- Why selected: This solution addresses all the key requirements: automated patching (via Patch Manager), vulnerability scanning and assessment (via Amazon Inspector), and a...
Author: Liam123 · Last updated Apr 16, 2026
A company hosts its application in the AWS Cloud. The application runs on Amazon EC2 instances in an Auto Scaling group behind an Elastic Load Balancing (ELB) load balancer. The application connects to an Amazon DynamoDB table.
For disaster recovery (DR) purposes, the company wants to ensure that the applicat...
To determine the best solution for ensuring minimal downtime in the event of a disaster recovery (DR) scenario, let's evaluate the options based on key factors like availability, downtime, automation, and complexity.
Key Requirements:
1. Disaster Recovery (DR) with minimal downtime: The solution should ensure the application can failover to another AWS Region with minimal downtime.
2. Global Availability of Data: The DynamoDB table should be accessible across regions with minimal latency.
3. Automated Failover: The solution should automatically reroute traffic to the DR region with minimal manual intervention.
A) Create an Auto Scaling group and an ELB in the DR Region. Configure the DynamoDB table as a global table. Configure DNS failover to point to the new DR Region's ELB.
- Auto Scaling Group and ELB in DR Region: Creating an Auto Scaling group and an ELB in the DR region ensures that the application can scale and handle traffic in the DR region.
- Global DynamoDB Table: Configuring DynamoDB as a global table ensures that the data is automatically replicated across regions, which allows for seamless access to the data in the DR region without downtime.
- DNS Failover: Using DNS failover (with Amazon Route 53) allows automatic redirection of traffic to the DR region’s ELB when needed.
- Why selected: This solution provides the least downtime by automatically failing over to the DR region using global tables for DynamoDB and automated DNS failover. It minimizes the impact of a disaster by keeping both the application and data in sync and ready for immediate failover.
B) Create an AWS CloudFormation template to create EC2 instances, ELBs, and DynamoDB tables to be launched when necessary. Configure DNS failover to point to the new DR Region's ELB.
- CloudFormation Template: While this approach allows for creating resources in the DR region, it requires manual intervention to trigger the CloudFormation stack to launch the resources when necessary. This adds operational complexity and downtime during the recovery process, as resources won’t be available until the stack is launched and configured.
- DynamoDB Table: The DynamoDB table is not set up as a global table, which means the data wouldn’t be automatically available in the DR region.
- Why not: The recovery...
Author: Chloe · Last updated Apr 16, 2026
A company runs an application on Amazon EC2 instances in a private subnet. The application needs to store and retrieve data in Amazon S3 buckets. According to regulatory requirements, the data must not travel across the public i...
To determine the most cost-effective solution that ensures compliance with the requirement that data does not travel across the public internet when stored in Amazon S3, let's evaluate each option:
Key Requirements:
1. Private Subnet: The EC2 instances are located in a private subnet, meaning they cannot directly access the public internet.
2. Data Compliance: The application must store and retrieve data from S3 without the data traveling over the public internet.
3. Cost-effectiveness: The solution should meet the requirement with minimal operational cost.
A) Deploy a NAT gateway to access the S3 buckets.
- NAT Gateway: A NAT gateway enables instances in a private subnet to access the internet, including S3. However, this would route traffic over the public internet, which violates the regulatory requirement that data should not travel across the public internet.
- Why not: Using a NAT gateway doesn’t meet the requirement since it routes data over the public internet, which violates the regulatory constraint.
B) Deploy AWS Storage Gateway to access the S3 buckets.
- AWS Storage Gateway: This service provides hybrid cloud storage integration between on-premises environments and Amazon S3. While it allows access to S3, it is designed primarily for on-premises-to-cloud storage integration and not specifically for EC2 instances in a VPC.
- Why not: This option is more suited for on-premises environments that need to access cloud storage. It is more complex and expensive compared to a solution designed to work directly within the VPC, like an S3 endpoint.
...
Author: Ethan Smith · Last updated Apr 16, 2026
A company hosts an application on Amazon EC2 instances that run in a single Availability Zone. The application is accessible by using the transport layer of the Open Systems Interconnection (OSI) model. The company needs the application architecture to have hi...
To meet the high availability requirements for the application, the company needs to ensure the application is not tied to a single Availability Zone, and that traffic can be distributed across instances while maintaining fault tolerance and scalability. Let's evaluate each option and its relevance:
Option A: Configure new EC2 instances in a different Availability Zone. Use Amazon Route 53 to route traffic to all instances.
- Explanation: This approach spreads the application across multiple Availability Zones, which increases fault tolerance. By using Amazon Route 53, traffic can be routed across these instances based on health checks, enhancing availability. However, Route 53 is not an ideal load balancer for managing real-time traffic distribution (especially TCP traffic), and it requires more manual configuration than a load balancer.
- Rejected because: While this increases high availability, it doesn't provide automatic scaling or load balancing, which would be beneficial in maintaining the application's performance and uptime under varying loads.
Option B: Configure a Network Load Balancer in front of the EC2 instances.
- Explanation: A Network Load Balancer (NLB) distributes traffic across EC2 instances, offering fault tolerance for TCP-based applications. It can automatically handle traffic spikes and route traffic to healthy instances, improving high availability.
- Selected because: The NLB is efficient for distributing TCP traffic, which aligns with the company’s requirement to ensure high availability at the transport layer (OSI model). It offers better fault tolerance and load balancing than Route 53 alone.
Option C: Configure a Network Load Balancer for TCP traffic to the instances. Configure an Application Load Balancer for HTTP and HTTPS traffic to the instances.
- Explanation: This approach uses both NLB for TCP and Application Load Balancer (ALB) for HTTP/HTTPS. It provides fine-grained control over traffic based on the protocol type but adds complexity.
- Rejected because: While this is a comprehensive solution, it introduces unnecessary complexity wh...
Author: Nathan · Last updated Apr 16, 2026
A company uses Amazon S3 to host its static website. The company wants to add a contact form to the webpage. The contact form will have dynamic server-side components for users to input their name, email address, phone number, and user message.
The company expects fewer than 100 site visits each month. The contact form...
To determine the most cost-effective solution, we need to consider the following factors:
- Cost: The solution should be affordable, particularly given that the company expects fewer than 100 site visits each month.
- Ease of implementation: The solution should be simple and quick to set up.
- Scalability: Although the company expects a low number of site visits, the solution should be able to scale if the traffic increases.
- Server-side components: The contact form requires dynamic behavior, which necessitates server-side components like processing form submissions and sending notifications.
Now, let’s analyze each option:
Option A: Host the dynamic contact form in Amazon Elastic Container Service (Amazon ECS). Set up Amazon Simple Email Service (Amazon SES) to connect to a third-party email provider.
- Explanation: Hosting the contact form in ECS introduces unnecessary complexity and cost for a small-scale use case like this. ECS is typically suited for containerized applications with more complex scaling requirements, which is overkill for a low-traffic, simple contact form. Integrating Amazon SES with a third-party email provider adds additional complexity, and SES is designed more for sending bulk emails rather than for simple form submissions.
- Rejected because: It introduces unnecessary infrastructure (ECS) and complexity when a simpler, cheaper solution would work.
Option B: Create an Amazon API Gateway endpoint that returns the contact form from an AWS Lambda function. Configure another Lambda function on the API Gateway to publish a message to an Amazon Simple Notification Service (Amazon SNS) topic.
- Explanation: This is a highly scalable, serverless approach that involves using Amazon API Gateway, AWS Lambda, and SNS. The API Gateway serves the contact form dynamically, and Lambda handles form submissions and sends an email notification via SNS. Given the low volume of traffic (fewer than 100 visits per month), this is a cost-effective and scalable solution because Lambda charges only for the compute time used, and SNS offers a pay-per-use model as well.
- Selected because: This solution leverages AWS serverless technologies that are inexpensive, scalable, and simple to set up. It requires minima...
Author: Oliver · Last updated Apr 16, 2026
A company creates dedicated AWS accounts in AWS Organizations for its business units. Recently, an important notification was sent to the root user email address of a business unit account instead of the assigned account owner. The company wants to ensure that all future notifications can be sent to different employee...
To meet the company's requirements of sending notifications to different employees based on categories (billing, operations, or security), we need a solution that ensures the right people receive notifications securely and in an organized way. Let's evaluate each option:
Option A: Configure each AWS account to use a single email address that the company manages. Ensure that all account owners can access the email account to receive notifications. Configure alternate contacts for each AWS account with corresponding distribution lists for the billing team, the security team, and the operations team for each business unit.
- Explanation: This approach involves a shared email address for all account owners to receive notifications, which could be risky in terms of security, as multiple users would have access to a common account. However, alternate contacts for billing, security, and operations are correctly defined, which is good for organization.
- Rejected because: Using a single shared email address for all account owners reduces security by giving many people access to sensitive notifications. It's also not ideal for tracking specific notifications for each category (billing, security, operations) and could lead to confusion or oversight.
Option B: Configure each AWS account to use a different email distribution list for each business unit that the company manages. Configure each distribution list with administrator email addresses that can respond to alerts. Configure alternate contacts for each AWS account with corresponding distribution lists for the billing team, the security team, and the operations team for each business unit.
- Explanation: This option suggests using different email distribution lists for each business unit, which could work well for organizing the recipients of notifications. Distribution lists for each category (billing, security, operations) are clearly defined and can route notifications to the right team members.
- Selected because: This approach is secure, as it uses distribution lists to manage notifications rather than shared email addresses. It also allows proper segregation of notification types (billing, security, operations) to the appropriate teams, ensuring that the right people are notified securely. The use of administrator email addresses within the distribution lists is also practical for responding to alerts.
Option...
Author: Vikram · Last updated Apr 16, 2026
A company runs an ecommerce application on AWS. Amazon EC2 instances process purchases and store the purchase details in an Amazon Aurora PostgreSQL DB cluster.
Customers are experiencing application timeouts during times of peak usage. A solutions architect needs to rearchitect the application so that the applicati...
To meet the requirements of scaling the application to handle peak usage and avoid timeouts during high traffic periods, the company needs a combination of scalable compute resources and mechanisms to better handle database traffic. Let's evaluate each option based on the context and key factors:
Option A: Configure an Auto Scaling group of new EC2 instances to retry the purchases until the processing is complete. Update the applications to connect to the DB cluster by using Amazon RDS Proxy.
- Explanation: An Auto Scaling group for EC2 instances can help scale out compute resources during peak times. RDS Proxy is a connection pooler for Amazon RDS (including Aurora), which improves database performance by managing a pool of database connections and reducing the connection overhead. This can significantly reduce timeouts caused by database connection limits.
- Selected because: Using an Auto Scaling group ensures that the application can scale dynamically based on demand, while RDS Proxy optimizes database connections, both addressing the peak usage and improving reliability without changing the fundamental application structure. This is cost-effective because Auto Scaling only uses resources as needed, and RDS Proxy can lower database connection overhead.
Option B: Configure the application to use an Amazon ElastiCache cluster in front of the Aurora PostgreSQL DB cluster.
- Explanation: ElastiCache is a caching service that can improve performance by caching frequently accessed data, which reduces the load on the database. However, ElastiCache does not directly address the issue of scaling compute capacity or reducing database connection contention during peak traffic times.
- Rejected because: While ElastiCache could improve performance, it doesn't address the underlying issue of the application and database handling high concurrency during peak traffic. It’s a useful optimization but not the primary solution to avoid timeouts during heavy load.
Option C: Update the application to send the purchase requests to an Amazon Simple Queue Service (Amazon SQS) queue. Configure an Auto Scaling group of new EC2 instances that read from the SQS queue.
- Explanation: Using SQS as a buffer allows the application to decouple the purchase request processing from the user-facing interface. By storing requests in the queue, the system can handle bursts of traffic ...
Author: Arjun · Last updated Apr 16, 2026
A company that uses AWS Organizations runs 150 applications across 30 different AWS accounts. The company used AWS Cost and Usage Report to create a new report in the management account. The report is delivered to an Amazon S3 bucket that is replicated to a bucket in the data collection account.
The company's senior leadership wants to view a cu...
To meet the senior leadership's requirements of viewing a custom dashboard that provides NAT gateway costs daily from the beginning of the current month, we need to evaluate the options based on how each tool can query the data efficiently and how they fit within the AWS ecosystem for reporting and dashboarding. Let's analyze each option:
Option A: Share an Amazon QuickSight dashboard that includes the requested table visual. Configure QuickSight to use AWS DataSync to query the new report.
- Explanation: Amazon QuickSight is a business intelligence (BI) service that enables you to create and share visualizations and dashboards. However, AWS DataSync is designed for transferring large amounts of data between on-premises storage and AWS services, and it's not typically used to query reports. QuickSight generally queries data using data sources like Amazon S3, Redshift, or Athena, not AWS DataSync.
- Rejected because: AWS DataSync is not the appropriate service to query data for reporting purposes. QuickSight requires integration with services like Athena, not DataSync.
Option B: Share an Amazon QuickSight dashboard that includes the requested table visual. Configure QuickSight to use Amazon Athena to query the new report.
- Explanation: Amazon Athena is a serverless interactive query service that makes it easy to analyze data in Amazon S3 using standard SQL. By configuring Athena to query the AWS Cost and Usage Report (which is stored in S3), QuickSight can visualize the queried data and create custom dashboards. This setup is a typical and cost-effective solution for analyzing and visualizing large datasets from S3.
- Selected because: Athena is the ideal tool for querying large datasets like AWS Cost and Usage Reports stored in S3, and QuickSight can then create and share custom dashboards based on that data. This approach is highly scalable, cost-effective, and well-suited to the requirement.
...
Author: Amelia · Last updated Apr 16, 2026
A company is hosting a high-traffic static website on Amazon S3 with an Amazon CloudFront distribution that has a default TTL of 0 seconds. The company wants to implement caching to improve performance for the website. However, the company also wants to ensure that stale content is not served for more than a few minutes a...
To meet the requirements of caching content while ensuring that stale content is not served for more than a few minutes after a deployment, we need to balance performance (caching) with the need to quickly refresh content after changes. Let's evaluate the options one by one:
A) Set the CloudFront default TTL to 2 minutes.
- Reasoning: Setting a TTL of 2 minutes in CloudFront ensures that the cache will expire every 2 minutes, meaning that CloudFront will revalidate content regularly. This approach gives a balance between serving cached content and fetching fresh content from the origin server after deployment. A 2-minute TTL would be fast enough to ensure that new content is fetched in a timely manner after a deployment.
- Why it works: This choice aligns with the need to serve fresh content while still benefiting from caching. Content will be refreshed every 2 minutes, which satisfies the requirement that stale content is not served for more than a few minutes.
B) Set a default TTL of 2 minutes on the S3 bucket.
- Reasoning: Amazon S3 itself does not have a direct mechanism to set TTLs on objects in the same way that CloudFront does. S3 can manage metadata for caching, but the TTL is primarily managed at the CloudFront level, not at S3. This option would not have the desired impact because TTL needs to be configured on the CloudFront distribution, not on S3.
- Why it's rejected: S3 by itself cannot directly control caching behavior for CloudFront beyond providing caching headers or metadata. This option would not address the TTL needs as effectively as CloudFront configuration.
C) Add a Cache-Control private directive to the objects in Amazon S3.
- Reasoning: A `Cache-Control: private` directive indicates that content is specific to a user and should not be cached by shared caches (like CloudFront). This would effectively prevent CloudFront from caching the objects, which directly conflicts with the goal of improving performance by caching content.
- Why it's rejected: The `private` directive would prevent CloudFront from caching the objects, leading ...
Author: John · Last updated Apr 16, 2026
A company runs its application by using Amazon EC2 instances and AWS Lambda functions. The EC2 instances run in private subnets of a VPC. The Lambda functions need direct network access to the EC2 instances for the application to work.
The application will run for 1 year. The number of Lambda functions that the application uses will...
Let's evaluate the options one by one and consider the key factors such as minimizing costs, ensuring the Lambda functions can access the EC2 instances, and meeting the network access requirements.
A) Purchase an EC2 Instance Savings Plan. Connect the Lambda functions to the private subnets that contain the EC2 instances.
- Reasoning: An EC2 Instance Savings Plan is intended for customers who have predictable workloads using EC2 instances. However, the company needs to connect AWS Lambda to EC2 instances, which are in private subnets. While EC2 Savings Plans offer cost savings for EC2 instances, it doesn't directly address the Lambda cost or how Lambda interacts with private subnets.
- Why it's rejected: Lambda functions do not run on EC2 instances directly and are not directly associated with EC2 Instance Savings Plans. Additionally, Lambda functions in private subnets might require additional networking configurations, and this solution doesn't specifically address Lambda pricing optimization. It’s more relevant for EC2-related costs, which is not the primary goal here.
B) Purchase an EC2 Instance Savings Plan. Connect the Lambda functions to new public subnets in the same VPC where the EC2 instances run.
- Reasoning: The goal is to ensure that the Lambda functions can communicate with the EC2 instances, which are in private subnets. If you place Lambda in public subnets, you would need to configure NAT gateways or Internet access, which could increase costs and complexity, as well as introduce potential security risks.
- Why it's rejected: Placing Lambda in public subnets with a NAT Gateway would introduce unnecessary additional costs for data transfer and other associated charges. Also, it doesn't directly address Lambda-specific cost savings or the need for Lambda to access EC2 instances securely within private subnets.
C) Purchas...
Author: Ming · Last updated Apr 16, 2026
A company has deployed a multi-account strategy on AWS by using AWS Control Tower. The company has provided individual AWS accounts to each of its developers. The company wants to implement controls to limit AWS resource costs that the...
Let's evaluate the options one by one based on minimizing operational overhead and providing a solution that can effectively limit resource costs for developers:
A) Instruct each developer to tag all their resources with a tag that has a key of CostCenter and a value of the developer's name. Use the required-tags AWS Config managed rule to check for the tag. Create an AWS Lambda function to terminate resources that do not have the tag. Configure AWS Cost Explorer to send a daily report to each developer to monitor their spending.
- Reasoning: This approach requires developers to manually tag their resources, which could be error-prone and inconsistent over time. The Lambda function that terminates untagged resources adds operational complexity and overhead. While AWS Config and Lambda functions can enforce some level of automation, they would require ongoing maintenance and monitoring, which increases operational overhead.
- Why it's rejected: The manual tagging process, the need for Lambda functions to terminate resources, and the need to continuously manage and monitor the setup increases complexity and operational overhead. It doesn't provide a scalable or automated way to limit costs.
B) Use AWS Budgets to establish budgets for each developer account. Set up budget alerts for actual and forecast values to notify developers when they exceed or expect to exceed their assigned budget. Use AWS Budgets actions to apply a DenyAll policy to the developer's IAM role to prevent additional resources from being launched when the assigned budget is reached.
- Reasoning: AWS Budgets is an excellent tool for controlling costs by setting spending limits. Using AWS Budgets actions to apply a DenyAll policy when the budget is exceeded is an effective way to enforce cost controls. Budget alerts keep developers informed about their spending. This solution directly addresses cost control, is automated, and does not require manual intervention.
- Why it works: This approach minimizes operational overhead while effectively controlling costs. AWS Budgets is designed to handle cost management across multiple accounts, and using IAM policies to prevent resource launches when budgets are exceeded is a clean and automated solution. This...
Author: NebulaEagle11 · Last updated Apr 16, 2026
A solutions architect is designing a three-tier web application. The architecture consists of an internet-facing Application Load Balancer (ALB) and a web tier that is hosted on Amazon EC2 instances in private subnets. The application tier with the business logic runs on EC2 instances in private subnets. The database tier consists of Microsoft SQL Server that runs on EC2 instances in ...
Let's break down each option and evaluate its suitability based on the requirements for security, correct network traffic flow, and the design of the three-tier architecture.
A) Configure the security group for the web tier to allow inbound HTTPS traffic from the security group for the ALB.
- Reasoning: The web tier EC2 instances should only accept inbound HTTPS traffic from the Application Load Balancer (ALB) to ensure that traffic is properly routed and secured from the internet. The ALB handles public-facing requests and forwards them to the web tier instances. By allowing inbound HTTPS traffic from the ALB's security group, you limit exposure to just traffic from the load balancer, which minimizes security risks.
- Why it works: This configuration ensures that only traffic from the ALB (and not directly from the internet) reaches the web tier, improving security and traffic flow.
B) Configure the security group for the web tier to allow outbound HTTPS traffic to 0.0.0.0/0.
- Reasoning: The web tier EC2 instances may need to access external services (such as updates, third-party APIs, or resources) over HTTPS. Configuring outbound HTTPS traffic to `0.0.0.0/0` is necessary for this, as it allows the web instances to access external services securely.
- Why it works: This allows the web tier to make HTTPS requests to any external IP address, ensuring that the web tier can reach the internet if needed. However, you should monitor outbound traffic closely to ensure it's strictly necessary and avoid any security issues.
C) Configure the security group for the database tier to allow inbound Microsoft SQL Server traffic from the security group for the application tier.
- Reasoning: The application tier EC2 instances interact with the database tier (Microsoft SQL Server) to fetch or store data. Therefore, the security group for the database tier should allow inbound Microsoft SQL Server traffic (typically TCP port 1433) from the application tier's security group. This ensures that only the application tier can communicate with the database, preventing unauthorized access.
- Why it works: This configuration enforces a principle of least privilege by allowing only the application tier to access the database, while blocking access from any other tier or external sources.
D) Configure the security group for the database tier to allow outbound HTTPS traffic and Microsoft SQL Server traffic to the security group for the web tier.
- Reasoning: The database tier does not need to initiate HTTPS or SQL Server tra...
Author: Sophia Clark · Last updated Apr 16, 2026
A company has released a new version of its production application. The company's workload uses Amazon EC2, AWS Lambda, AWS Fargate, and Amazon SageMaker.
The company wants to cost optimize the workload now that usage is at a steady state. The company wants to cover the most s...
To meet the requirements of cost optimization across multiple services with the fewest savings plans, we need to consider which savings plans cover the services effectively and ensure flexibility and cost savings.
Option Analysis:
A) Purchase an EC2 Instance Savings Plan for Amazon EC2 and SageMaker.
- Reasoning: The EC2 Instance Savings Plan specifically applies to EC2 instance usage. However, it does not cover AWS Lambda or AWS Fargate, which are key components of the workload. Additionally, SageMaker does not benefit from EC2 Instance Savings Plans directly; SageMaker has its own savings plan type.
- Why it's rejected: This plan doesn't cover Lambda or Fargate, and it’s not optimal for SageMaker, which has its own savings plan. The coverage is limited, leading to the need for multiple savings plans.
B) Purchase a Compute Savings Plan for Amazon EC2, Lambda, and SageMaker.
- Reasoning: The Compute Savings Plan is flexible and applies to a wide range of compute services, including EC2, Lambda, and SageMaker. This plan is highly effective because it covers multiple services in one plan, providing cost optimization without requiring multiple savings plans.
- Why it works: This option is ideal because it covers EC2, Lambda, and SageMaker under a single savings plan. Since these are key services used in the workload, the Compute Savings Plan provides broad coverage and reduces the need for multiple separate savings plans.
C) Purchase a SageMaker Savings Plan.
- Reasoning: The SageMaker Savings Plan is specific to SageMaker, which is a machine learning service. While this is a targeted and effective savings plan for SageMaker usage, it does not cover EC2, Lambda, or Fargate. Therefore, it is not a good fit for the broader workload that involves more serv...
Author: Abigail · Last updated Apr 16, 2026
A company uses a Microsoft SQL Server database. The company's applications are connected to the database. The company wants to migrate to an Amazon Aurora PostgreSQL database with minimal changes to the ap...
When migrating from Microsoft SQL Server to an Amazon Aurora PostgreSQL database with minimal changes to the application code, we must consider the compatibility of SQL Server’s T-SQL syntax with PostgreSQL and the potential changes needed to the application code.
Let's analyze each option:
1. A) Use the AWS Schema Conversion Tool (AWS SCT) to rewrite the SQL queries in the applications.
- The AWS Schema Conversion Tool (SCT) helps with migrating database schema but does not rewrite SQL queries in the applications. It primarily assists in converting the database schema and objects (like tables, indexes, etc.) from one database engine to another.
- Rejection: This option doesn’t directly address rewriting application SQL queries. It only helps with schema and data migration.
2. B) Enable Babelfish on Aurora PostgreSQL to run the SQL queries from the applications.
- Babelfish for Aurora PostgreSQL is designed to help migrate applications from SQL Server to Aurora PostgreSQL without requiring significant changes in the application code. Babelfish allows Aurora PostgreSQL to understand T-SQL queries, making it compatible with SQL Server syntax. This option would allow the application to keep using SQL Server-style queries while accessing the Aurora PostgreSQL database.
- Acceptance: Babelfish is a key feature for this scenario as it allows the application to continue using SQL Server queries without modification. This minimizes the effort required to migrate the application code.
3. C) Migrate the database schema and data by using the AWS Schema Conversion Tool (AWS SCT) and AWS Database Migration Service (AWS DMS).
- AWS SCT can help migrate the schema and database objects, while AWS DMS is used to migrate the actual data. However, neither AWS SCT nor DMS will assist in handling SQL query translation or enable compatibility for SQL Server syntax in PostgreSQL.
- Rejection: Although this is part of the migration process (for schema and data), it doesn't directly add...
Author: Jack · Last updated Apr 16, 2026
A company plans to rehost an application to Amazon EC2 instances that use Amazon Elastic Block Store (Amazon EBS) as the attached storage.
A solutions architect must design a solution to ensure that all newly created Amazon EBS volumes are encrypted by default. The...
Objective:
The goal is to ensure that all newly created Amazon EBS volumes are encrypted by default and to prevent the creation of unencrypted EBS volumes.
Let's analyze each option:
1. A) Configure the EC2 account attributes to always encrypt new EBS volumes.
- Explanation: Amazon EC2 provides the ability to set account-wide defaults for EBS volume encryption. By configuring the EC2 account attributes, you can ensure that any newly created EBS volumes are encrypted by default, using either the AWS managed key (aws/ebs) or a custom key.
- Acceptance: This is a direct solution to the requirement. It ensures that all EBS volumes created in the account are encrypted by default, which is exactly what the company needs.
- Reasoning: This option is the most efficient and straightforward way to ensure that all EBS volumes are encrypted by default, and it also prevents the creation of unencrypted volumes.
2. B) Use AWS Config. Configure the encrypted-volumes identifier. Apply the default AWS Key Management Service (AWS KMS) key.
- Explanation: AWS Config is a service that provides configuration monitoring and compliance auditing, and it can be used to track whether resources (including EBS volumes) are encrypted. However, it does not enforce encryption settings. It can flag non-compliance but does not prevent the creation of unencrypted volumes by default.
- Rejection: While this option can help in identifying and auditing non-compliant resources, it does not automatically enforce encryption or prevent unencrypted volumes from being created. It's more of a monitoring solution than an enforcement mechanism.
3. C) Configure AWS Systems Manager to create encrypted copies of the EBS volumes. Reconfigure the EC2 instances to use the encrypted volumes.
- Explanation: This option involves using AWS Systems Manager to create encrypted copies of existing EBS volumes, then manually reconfiguring EC2 instances to u...
Author: Aria · Last updated Apr 16, 2026
An ecommerce company wants to collect user clickstream data from the company's website for real-time analysis. The website experiences fluctuating traffic patterns throughout the day. The company needs a scalable soluti...
Objective:
The goal is to collect user clickstream data from the company’s website in real-time for analysis, and the solution must be scalable to handle fluctuating traffic patterns throughout the day.
Let's break down the options:
A) Use a data stream in Amazon Kinesis Data Streams in on-demand mode to capture the clickstream data. Use AWS Lambda to process the data in real time.
- Explanation:
- Amazon Kinesis Data Streams in on-demand mode is a scalable, real-time data streaming service that can handle fluctuating traffic patterns by automatically scaling the number of shards.
- AWS Lambda can be used to process the data in real time as it integrates seamlessly with Kinesis. Lambda scales automatically, making it ideal for variable workloads.
- Acceptance: This solution is well-suited for real-time, scalable processing of fluctuating clickstream data. It’s flexible, easy to use, and adapts to changes in traffic without requiring manual intervention.
- Reasoning: Kinesis Data Streams in on-demand mode will scale based on the incoming volume of data, and Lambda can scale to handle real-time data processing. This combination addresses both scalability and real-time processing needs.
B) Use Amazon Kinesis Data Firehose to capture the clickstream data. Use AWS Glue to process the data in real time.
- Explanation:
- Amazon Kinesis Data Firehose is primarily used for streaming data into storage solutions like Amazon S3, Redshift, or Elasticsearch. While it can handle real-time data ingestion, it is optimized for batch processing, not real-time processing.
- AWS Glue is a serverless data integration service typically used for ETL (extract, transform, load) jobs. It processes data in batch, making it unsuitable for low-latency, real-time analytics.
- Rejection: This combination is not suitable for real-time processing since AWS Glue is not designed for real-time data processing, and Kinesis Data Firehose is intended for streamlining data into storage rather than immediate analysis.
C) Use Amazon Kinesis Video Streams to capture the clickstream data. Use AWS Glue to pr...
Author: Joseph · Last updated Apr 16, 2026
A global company runs its workloads on AWS. The company's application uses Amazon S3 buckets across AWS Regions for sensitive data storage and analysis. The company stores millions of objects in multiple S3 buckets daily. The company wants to...
Objective:
The goal is to identify all S3 buckets that are not versioning-enabled across multiple AWS Regions.
Let's break down each option:
A) Set up an AWS CloudTrail event that has a rule to identify all S3 buckets that are not versioning-enabled across Regions.
- Explanation:
- AWS CloudTrail captures API activity, including S3 actions. However, CloudTrail itself is primarily used for auditing API calls and not for tracking specific configurations like versioning status of S3 buckets.
- CloudTrail can help monitor actions performed on S3 buckets (like creation or modification), but it doesn’t directly report the versioning status of all buckets.
- Rejection: This solution is more focused on auditing actions, and it wouldn't provide a comprehensive view of which buckets are not versioning-enabled. It would require additional steps or custom code to check for versioning status.
B) Use Amazon S3 Storage Lens to identify all S3 buckets that are not versioning-enabled across Regions.
- Explanation:
- Amazon S3 Storage Lens provides visibility into your S3 storage usage and activity. It can generate reports on S3 bucket configuration, including the versioning status of buckets.
- S3 Storage Lens can be configured to show which buckets have versioning enabled or not across multiple Regions. It provides an easy way to identify all S3 buckets and their versioning status.
- Acceptance: This is the most appropriate solution for identifying which S3 buckets are not versioning-enabled, as S3 Storage Lens can report on versioning status and works across multiple Regions.
C) Enable IAM Access Analyzer for S3 to identify a...
Author: Ethan · Last updated Apr 16, 2026
A company needs to optimize its Amazon S3 storage costs for an application that generates many files that cannot be recreated. Each file is approximately 5 MB and is stored in Amazon S3 Standard storage.
The company must store the files for 4 years before the files can be deleted. The files must be immediately accessible. The files are frequently accessed in the...
Objective:
The company needs to optimize Amazon S3 storage costs for files that:
- Are approximately 5 MB each,
- Are frequently accessed in the first 30 days of creation,
- Are rarely accessed after the first 30 days,
- Need to be stored for 4 years before deletion,
- Must be immediately accessible.
Key factors to consider:
- Frequent access in the first 30 days: The storage solution needs to support high availability during this time, with quick access to the files.
- Infrequent access after 30 days: A more cost-effective storage class should be used after the first 30 days, as the files are rarely accessed after that.
- 4-year retention period: The solution should be cost-effective for long-term storage.
- Immediate accessibility: The files must be accessible at any time.
Let's evaluate each option:
A) Create an S3 Lifecycle policy to move the files to S3 Glacier Instant Retrieval 30 days after object creation. Delete the files 4 years after object creation.
- Explanation:
- S3 Glacier Instant Retrieval is designed for long-term archival storage of rarely accessed data but allows for retrieval within milliseconds. It is designed to be cost-effective for infrequent access data.
- However, the files are frequently accessed in the first 30 days, which makes S3 Glacier Instant Retrieval too expensive for the first 30 days due to its retrieval times and costs.
- Rejection: While Glacier Instant Retrieval is a good option for infrequent access data, it’s not ideal for data that needs frequent access in the first 30 days.
B) Create an S3 Lifecycle policy to move the files to S3 One Zone-Infrequent Access (S3 One Zone-IA) 30 days after object creation. Delete the files 4 years after object creation.
- Explanation:
- S3 One Zone-IA is a cost-effective storage class for infrequently accessed data that doesn't require multiple Availability Zone resilience. It is less expensive than S3 Standard-IA, but files are stored in only one Availability Zone, making it less durable.
- Since the company requires immediate accessibility and durability for 4 years, S3 One Zone-IA may not meet these needs. One Availability Zone means a single point of failure if that zone experiences an issue, which could be a concern for critical data.
- Rejection: The durability concerns o...
Author: MysticJaguar44 · Last updated Apr 16, 2026
A company runs its critical storage application in the AWS Cloud. The application uses Amazon S3 in two AWS Regions. The company wants the application to send remote user data to the nearest S3 bucket with no public network congestion. The company also wants the applic...
To solve this problem, let's analyze the key requirements and each option:
Key Requirements:
1. Remote user data should be sent to the nearest S3 bucket: This is about reducing latency and improving the speed of data uploads by routing the data to the nearest S3 endpoint.
2. No public network congestion: The solution needs to avoid bottlenecks or public internet congestion for better performance and reliability.
3. Failover with minimal management: The company needs an automated failover solution with as little manual intervention or management as possible.
Analyzing the options:
A) Implement an active-active design between the two Regions. Configure the application to use the regional S3 endpoints closest to the user.
- Pros: This design allows users to access the nearest S3 bucket, potentially reducing latency.
- Cons: Although it achieves proximity, managing an active-active design manually can be complex and may require custom logic for failover in case of issues in one region. This doesn't offer the simplest failover option.
B) Use an active-passive configuration with S3 Multi-Region Access Points. Create a global endpoint for each of the Regions.
- Pros: S3 Multi-Region Access Points provide a global endpoint, which automatically routes user traffic to the closest region. This solution also allows for simple failover in case of issues.
- Cons: The active-passive configuration means only one region would be "active" at a time, which might not provide the best performance if one region experiences congestion or outages.
C) Send user data to the regional S3 endpoints closest to the user. Configure an S3 cross-account replication rule to keep the S3 buckets synchronized.
- Pros: This solution ensures that user data is sent to ...
Author: Kai99 · Last updated Apr 16, 2026
A company is migrating a data center from its on-premises location to AWS. The company has several legacy applications that are hosted on individual virtual servers. Changes to the application designs cannot be made.
Each individual virtual server currently runs as its own EC2 instance. A solutions architect needs to ensure that the applications ar...
Let's break down the key requirements of the situation and analyze the solutions:
Key Requirements:
1. The company has several legacy applications: These applications cannot be re-architected or redesigned, so they need to be migrated as-is to AWS.
2. Reliability and fault tolerance: After migration, the applications need to be able to tolerate failures, ensuring they remain available.
3. The applications run on individual virtual servers: Each application is independent and currently runs as a single virtual server (EC2 instance), so the solution should respect this setup.
Analyzing the options:
A) Create an Auto Scaling group that has a minimum of one and a maximum of one. Create an Amazon Machine Image (AMI) of each application instance. Use the AMI to create EC2 instances in the Auto Scaling group. Configure an Application Load Balancer in front of the Auto Scaling group.
- Pros: The Auto Scaling group ensures that one EC2 instance is always running. The Application Load Balancer (ALB) provides fault tolerance by distributing traffic across multiple instances. This could help in ensuring availability.
- Cons: Setting the Auto Scaling group to a minimum and maximum size of 1 doesn't provide redundancy, as there is still only one instance running. If that instance fails, the Auto Scaling group won't spin up another instance. Also, Auto Scaling wouldn't help with fault tolerance unless there are multiple instances running.
- Use case: This could be a solution if you only need to ensure the availability of a single EC2 instance, but it doesn't offer full fault tolerance or reliability after migration.
B) Use AWS Backup to create an hourly backup of the EC2 instance that hosts each application. Store the backup in Amazon S3 in a separate Availability Zone. Configure a disaster recovery process to restore the EC2 instance for each application from its most recent backup.
- Pros: AWS Backup can help automate the backup of EC2 instances and store them securely in Amazon S3.
- Cons: This solution provides disaster recovery but not continuous high availability. In the event of a failure, the system would rely on restoring from backups, which would introduce downtime, and it doesn't provide fault tolerance for real-time application availability.
- Use case...
Author: Sam · Last updated Apr 16, 2026
A company wants to isolate its workloads by creating an AWS account for each workload. The company needs a solution that centrally manages networking components for the workloads. The solution also must create accounts with automatic security c...
Let's evaluate the requirements and each option based on the following key factors:
Key Requirements:
1. Isolate workloads by creating an AWS account for each workload: The company wants to have a separate AWS account per workload for isolation.
2. Centrally manage networking components for the workloads: This means that networking resources such as VPCs, subnets, and routing need to be managed centrally across multiple accounts.
3. Automatic security controls (guardrails): Security should be enforced automatically across all the accounts to ensure compliance and safety.
Analyzing the options:
A) Use AWS Control Tower to deploy accounts. Create a networking account that has a VPC with private subnets and public subnets. Use AWS Resource Access Manager (AWS RAM) to share the subnets with the workload accounts.
- Pros: AWS Control Tower provides a centralized way to set up and manage multiple accounts, with built-in security guardrails. The networking account setup with VPC sharing through AWS RAM allows centralized management of networking components. Using RAM to share subnets simplifies the network management across multiple accounts.
- Cons: The VPC is centralized, but each workload account still uses the shared subnets, and there could be complexity in managing traffic and routing if the workloads grow in complexity.
- Use case: This is a good solution when you need central management of networking but want to avoid deploying individual VPCs in each account. It is suitable for smaller, less complex networking needs.
B) Use AWS Organizations to deploy accounts. Create a networking account that has a VPC with private subnets and public subnets. Use AWS Resource Access Manager (AWS RAM) to share the subnets with the workload accounts.
- Pros: AWS Organizations allows centralized management of accounts, and the use of AWS RAM for sharing subnets allows a centralized networking model.
- Cons: Unlike AWS Control Tower, this solution does not come with automatic security guardrails. It would require manual enforcement of security policies across accounts, which increases operational overhead.
- Use case: This could be used if security controls are not as critical or if the company wants more manual control over security guardrails, but it is not the least operationally complex option.
C) Use AWS Control Tower to deploy accounts. Deploy a VPC in...
Author: Harper · Last updated Apr 16, 2026
A company hosts a website on Amazon EC2 instances behind an Application Load Balancer (ALB). The website serves static content. Website traffic is increasing. The company wants to mini...
Let's analyze the company's needs and evaluate the options:
Key Requirements:
1. Website serves static content: This means the website doesn't require dynamic content generation (e.g., server-side scripting, database queries) for the bulk of its traffic.
2. Traffic is increasing: The company needs to handle more traffic without drastically increasing costs.
3. Minimize hosting costs: The goal is to reduce costs associated with website hosting while still ensuring reliability and scalability.
Analyzing the Options:
A) Move the website to an Amazon S3 bucket. Configure an Amazon CloudFront distribution for the S3 bucket.
- Pros:
- Cost-effective: Amazon S3 is a very cost-efficient solution for serving static content. The cost of hosting static files (e.g., HTML, CSS, images) in S3 is minimal compared to running EC2 instances.
- Scalable: Amazon S3 automatically scales to handle traffic increases, without needing manual intervention.
- CloudFront Integration: CloudFront, a Content Delivery Network (CDN), will cache the content at edge locations around the world, reducing latency and improving performance for users across different regions.
- High Availability and Reliability: S3 is highly durable and available, and CloudFront improves global content delivery.
- Simplicity: This solution eliminates the need for EC2 instances and load balancing, simplifying management and reducing costs.
- Cons:
- This approach works best for purely static websites. If there is any dynamic content in the future, additional services (like AWS Lambda or API Gateway) would be needed.
B) Move the website to an Amazon S3 bucket. Configure an Amazon ElastiCache cluster for the S3 bucket.
- Pros:
- S3 for static content hosting is cost-effective.
- ElastiCache helps improve performance by caching data in-memory for dynamic content.
- Cons:
- ElastiCache is unnecessary for static content: Since the website serves static content, caching with ElastiCache doesn’t add much value and wou...
Author: Lucas Carter · Last updated Apr 16, 2026
A company is implementing a shared storage solution for a media application that the company hosts on AWS. The company needs the ability to use SMB clients to access stored data.
Whi...
Let's analyze the company's requirements and evaluate the options:
Key Requirements:
1. SMB clients: The company needs to use SMB (Server Message Block) clients to access the stored data, which is a protocol commonly used for file sharing in Windows environments.
2. Shared storage solution: The company needs a shared storage solution, which allows multiple clients to access the same data concurrently.
3. Minimal administrative overhead: The company wants a solution that is easy to manage and doesn't require complex setup or ongoing management.
Analyzing the options:
A) Create an AWS Storage Gateway Volume Gateway. Create a file share that uses the required client protocol. Connect the application server to the file share.
- Pros:
- Volume Gateway allows for hybrid storage solutions, integrating on-premises applications with cloud storage. You can use SMB for file sharing.
- Provides a way to connect on-premises environments to AWS and use AWS storage like Amazon S3.
- It supports SMB, so it fits the requirement for SMB clients.
- Cons:
- More complex setup and ongoing management: While the Volume Gateway does support SMB, it is typically used for hybrid environments where on-premises storage is integrated with cloud. It might require more management and administrative overhead compared to fully cloud-native solutions like Amazon FSx.
- Not fully cloud-native: It requires maintaining an on-premises appliance (or virtual appliance), adding complexity.
B) Create an AWS Storage Gateway Tape Gateway. Configure tapes to use Amazon S3. Connect the application server to the Tape Gateway.
- Pros:
- Tape Gateway is primarily used for backup and archiving purposes.
- Integrates with Amazon S3 for tape storage.
- Cons:
- Not suitable for regular file sharing: Tape Gateway is designed for archival and backup workloads, not for providing shared file access over SMB.
- Does not meet the requirement: This solution doesn’t support the real-time file access and sharing needed for the media application.
C) Create an Amazon EC2 Windows instance. Install and configure a Windows file share role on the instance. Connect the application server to the file share.
- Pros:
- This approach could work for S...
Author: Ishaan · Last updated Apr 16, 2026
A company is designing its production application's disaster recovery (DR) strategy. The application is backed by a MySQL database on an Amazon Aurora cluster in the us-east-1 Region. The company has chosen the us-west-1 Region as its DR Region.
The company's target recovery point objective (RPO) is 5 minutes and the target recovery time objective (RTO...
Let's analyze each option based on the company's target disaster recovery (DR) requirements:
Target requirements:
- Recovery Point Objective (RPO): 5 minutes (data loss of no more than 5 minutes).
- Recovery Time Objective (RTO): 20 minutes (restore service in no more than 20 minutes).
- Minimize configuration changes: The solution should be simple and cause minimal disruption to existing configurations.
Option A: Create an Aurora read replica in us-west-1 similar in size to the production application's Aurora MySQL cluster writer instance.
- RPO: Aurora replicas can be asynchronously replicated. The RPO with a read replica would depend on the replication lag, which can be less than 5 minutes in most cases but is not guaranteed to always meet this requirement under high load or network latency. The lag could also vary, making it less reliable for strict RPO requirements.
- RTO: Failover from a read replica to a primary instance is not instantaneous. While Aurora can fail over to the replica, there is typically a short delay while the replication catches up and the new writer is promoted. This may exceed the target RTO of 20 minutes.
- Operational efficiency: While simple to configure, it still involves manual intervention to promote the replica during a disaster.
- Conclusion: This solution doesn't meet the strict RPO and RTO requirements. It's less reliable for the given target goals.
Option B: Convert the Aurora cluster to an Aurora global database. Configure managed failover.
- RPO: Aurora global databases support cross-region replication with very low latency (sub-second lag). This means the RPO requirement of 5 minutes is easily met.
- RTO: Aurora global databases offer automatic managed failover between regions. The failover process is much faster than with read replicas, typically occurring in seconds to minutes, well within the 20-minute RTO target.
- Operational efficiency: Aurora global databases are designed for minimal configuration changes and fully handle failover management automatically, providing high operational efficiency with no manual intervention needed in case of a disaster.
- Conclusion: This solution meets both the RPO and RTO requirements effectively and has high o...
Author: Ethan · Last updated Apr 16, 2026
A company runs a critical data analysis job each week before the first day of the work week. The job requires at least 1 hour to complete the analysis. The job is stateful and cannot tolerate interruptions. The com...
Let's evaluate each option in terms of how well it meets the requirements:
Requirements:
1. The job runs weekly, requiring at least 1 hour to complete.
2. The job is stateful and cannot tolerate interruptions.
Option A: Create a container for the job. Schedule the job to run as an AWS Fargate task on an Amazon Elastic Container Service (Amazon ECS) cluster by using Amazon EventBridge Scheduler.
- Stateful: AWS Fargate tasks are suitable for running containerized applications. The tasks can maintain state as long as they are properly configured with persistent storage (e.g., Amazon EFS for shared file storage or Amazon S3 for file persistence). This can be configured to prevent interruptions.
- Execution Time: Fargate tasks can run for longer than 1 hour without interruptions, which aligns with the job’s requirement for a 1-hour execution window.
- Scheduling: Amazon EventBridge Scheduler can be used to easily schedule the task to run weekly before the work week, fitting the job's schedule requirements.
- Conclusion: Fargate tasks are well-suited to stateful, long-running jobs and can meet both the execution and scheduling requirements.
Option B: Configure the job to run in an AWS Lambda function. Create a scheduled rule in Amazon EventBridge to invoke the Lambda function.
- Stateful: AWS Lambda functions are stateless by design, meaning they cannot maintain state between executions. This would be incompatible with the job's requirement to be stateful and not tolerate interruptions.
- Execution Time: Lambda has a maximum execution time limit of 15 minutes. The job requires at least 1 hour, making Lambda unsuitable for long-running processes like this one.
- Conclusion: Lambda is not suitable because it cannot handle the job’s long duration or stateful requirement.
Option C: Configure an Auto Scaling group of Amazon EC2 Spot Instanc...
Author: Noah · Last updated Apr 16, 2026
A company runs workloads in the AWS Cloud. The company wants to centrally collect security data to assess security across the entire company and to improve workload protection.
...
Let's evaluate each option based on the goal of centrally collecting security data to assess security across the company and improve workload protection, with the focus on minimizing development effort.
Option A: Configure a data lake in AWS Lake Formation. Use AWS Glue crawlers to ingest the security data into the data lake.
- Effort to Implement: Setting up AWS Lake Formation requires some initial configuration of data lakes, data access controls, and security policies. AWS Glue crawlers would need to be configured to ingest security data, which adds some complexity. While this solution provides a structured data lake, it still requires significant setup for access control, data cataloging, and ongoing management.
- Suitability: While this can be a robust solution for large-scale data management and security assessments, it involves more development and setup than the company likely needs, especially when the goal is to reduce development effort.
- Conclusion: While effective for long-term data collection, it requires more development effort to implement and manage than other solutions, making it a less optimal choice in terms of minimizing effort.
Option B: Configure an AWS Lambda function to collect the security data in .csv format. Upload the data to an Amazon S3 bucket.
- Effort to Implement: Setting up an AWS Lambda function to collect security data and upload it to an S3 bucket is a simple solution that requires minimal configuration. However, managing the security data as .csv files in S3 is less scalable and harder to query for complex security assessments.
- Suitability: This approach provides an easy, low-effort way to collect data, but storing data in flat .csv format could hinder efficient analysis, especially as the data grows. For ongoing security assessments, it might become cumbersome to extract insights from raw .csv data.
- Conclusion: While this is an easy and low-effort solution to implement, it might not be scalable or efficient enough for ongoing security assessments across a large organization. It could be better suited for simpler or small-scale use cases.
Option C: Configure a data lake in Amazon Security Lake to collect the security data. Upload the data to an Amazon S3 buck...
Author: Sara · Last updated Apr 16, 2026
A company is migrating five on-premises applications to VPCs in the AWS Cloud. Each application is currently deployed in isolated virtual networks on premises and should be deployed similarly in the AWS Cloud. The applications need to reach a shared services VPC. All the applications must be able to communicate with each other.
If the migration is successful, the c...
Key Requirements:
- Five on-premises applications need to be migrated to isolated VPCs in AWS.
- All applications must reach a shared services VPC and communicate with each other.
- The solution needs to scale for the migration of over 100 applications in the future with minimal administrative overhead.
Option A: Deploy software VPN tunnels between the application VPCs and the shared services VPC. Add routes between the application VPCs in their subnets to the shared services VPC.
- Scalability: Managing VPN tunnels between every application VPC and the shared services VPC becomes complex as the number of VPCs grows. For more than 100 VPCs, the administrative overhead of managing multiple VPN tunnels and route configurations increases significantly.
- Administrative Overhead: This solution would require continuous management of VPN tunnels, including encryption keys and tunnel health checks, along with routing updates as new VPCs are added.
- Conclusion: This option does not scale well and would become difficult to manage as the number of applications increases.
Option B: Deploy VPC peering connections between the application VPCs and the shared services VPC. Add routes between the application VPCs in their subnets to the shared services VPC through the peering connection.
- Scalability: While VPC peering can work well for small numbers of VPCs, as the number of VPCs increases, it requires the creation of many peering connections. Each new VPC would need to be peered with every other VPC that needs communication, which leads to a full mesh of peering relationships.
- Administrative Overhead: Managing a full mesh of peering connections becomes increasingly complex and error-prone as the number of VPCs grows. You also need to manage the route tables for each VPC and ensure that they correctly reflect the peering connections.
- Conclusion: This option will lead to high administrative overhead and complexity as the network grows, making it less suitable for scaling with hundreds of applications.
Option C: Deploy an AWS Direct Connect connection between the application VPCs and the shared services VPC. Add routes from the application VPCs in their subnets ...
Author: StarryEagle42 · Last updated Apr 16, 2026
A company wants to use Amazon Elastic Container Service (Amazon ECS) to run its on-premises application in a hybrid environment. The application currently runs on containers on premises.
The company needs a single container solution that can scale in an on-premises, hybrid, or cloud environment. The company must run new application con...
Key Requirements:
- The company wants to run its on-premises application in a hybrid environment using Amazon ECS.
- The application must run on containers in both on-premises and cloud environments.
- The solution must scale for both on-premises and cloud environments.
- HTTP traffic must be managed using a load balancer.
Option A: Set up an ECS cluster that uses the AWS Fargate launch type for the cloud application containers. Use an Amazon ECS Anywhere external launch type for the on-premises application containers.
- ECS Fargate (cloud): Fargate is ideal for serverless container orchestration, meaning you don't need to manage EC2 instances directly. It scales automatically and is well-suited for cloud-based containers.
- ECS Anywhere (on-premises): ECS Anywhere allows the management of on-premises containers as part of an ECS cluster. This makes it an appropriate solution for hybrid environments. The on-premises containers will still be part of the ECS cluster and can be managed centrally.
- Load Balancer: Using a load balancer (whether an Application Load Balancer or Network Load Balancer) will be compatible with this setup.
- Conclusion: This option is ideal because it uses ECS Fargate for cloud containers (scalable and easy to manage) and ECS Anywhere for on-premises containers, providing a seamless hybrid environment.
Option B: Set up an Application Load Balancer for cloud ECS services.
- Suitability: The Application Load Balancer is a good choice for managing HTTP/HTTPS traffic in the cloud environment. It can distribute traffic to ECS tasks running in the cloud (Fargate or EC2 instances).
- Limitation: This option only addresses the cloud environment. It doesn’t handle the hybrid nature of the application (on-premises + cloud) and doesn’t address the scaling of on-premises containers.
- Conclusion: While useful for cloud-based ECS services, this option does not meet the requirement for a hybrid environment where both on-premises and cloud containers need to be managed together.
Option C: Set up a Network Load Balancer for cloud ECS services.
- Suitability: A Network Load Balancer (NLB) is suitable for managing traffic to applications that require low-latency or TCP/UDP traffic. It can be used with E...
Author: Noah · Last updated Apr 16, 2026
A company is migrating its workloads to AWS. The company has sensitive and critical data in on-premises relational databases that run on SQL Server instances.
The company wants to use the AWS Cloud to increase security an...
To select the most suitable solution, let's analyze each option based on the company’s goal of increasing security and reducing operational overhead for sensitive and critical data in on-premises SQL Server databases.
A) Migrate the databases to Amazon EC2 instances. Use an AWS Key Management Service (AWS KMS) AWS managed key for encryption.
- Reasoning: Using EC2 instances to run SQL Server would essentially replicate the on-premises setup in the cloud. While you can control the EC2 instances and use AWS KMS for encryption, this option would still require the company to manage the underlying operating system, patches, SQL Server configurations, backups, and high availability. This would not significantly reduce operational overhead compared to the on-premises solution, as the company would still be responsible for a large portion of the infrastructure.
- Rejected because: The need to manage EC2 instances and SQL Server configurations would result in high operational overhead. Additionally, while encryption is provided by KMS, this doesn't necessarily increase security over a managed service.
B) Migrate the databases to a Multi-AZ Amazon RDS for SQL Server DB instance. Use an AWS Key Management Service (AWS KMS) AWS managed key for encryption.
- Reasoning: Amazon RDS (Relational Database Service) for SQL Server provides a fully managed database service, meaning AWS handles patching, backups, high availability, and other administrative tasks. Using Multi-AZ deployments ensures high availability and data durability, automatically replicating data between availability zones for fault tolerance. RDS also supports AWS KMS for encryption, ensuring that sensitive data is encrypted both at rest and in transit.
- Advantages: This option significantly reduces operational overhead by automating management tasks like patching and backups. It also enhances security through encryption and ensures high availability with Multi-AZ. This is ideal for workloads that require security, high availability, and reduc...
Author: Oscar · Last updated Apr 16, 2026
A company wants to migrate an application to AWS. The company wants to increase the application's current availability. The company wants to use AWS WAF in the appl...
To select the best solution, we need to evaluate the requirements: increasing the application's availability and using AWS WAF in the architecture.
A) Create an Auto Scaling group that contains multiple Amazon EC2 instances that host the application across two Availability Zones. Configure an Application Load Balancer (ALB) and set the Auto Scaling group as the target. Connect a WAF to the ALB.
- Reasoning: This option provides high availability by distributing the EC2 instances across multiple Availability Zones using Auto Scaling, which automatically adjusts the number of instances based on load. The Application Load Balancer (ALB) will distribute traffic across the EC2 instances, and the AWS WAF can be connected to the ALB to filter and protect the traffic. This setup increases both availability and security, aligning well with the company's goals.
- Selected because: It ensures high availability and scalability with Auto Scaling and ALB, while also integrating AWS WAF for enhanced security.
B) Create a cluster placement group that contains multiple Amazon EC2 instances that host the application. Configure an Application Load Balancer and set the EC2 instances as the targets. Connect a WAF to the placement group.
- Reasoning: A placement group is a way to control the placement of EC2 instances within a single Availability Zone to meet low-latency or high-throughput needs. However, it does not provide automatic scaling or high availability across multiple Availability Zones. Using a placement group would not increase availability as effectively as an Auto Scaling group across multiple Availability Zones. AWS WAF cannot be directly associated with a placement group; it can only be associated with an ALB or CloudFront distribution.
- Rejected because: This solution doesn’t improve availability across multiple Availability Zones and cannot integrate WAF with the placement group. It's less suitable for high-availability scenarios.
...
Author: Ahmed · Last updated Apr 16, 2026
A company manages a data lake in an Amazon S3 bucket that numerous applications access. The S3 bucket contains a unique prefix for each application. The company wants to restrict each application to its specific prefix and to have granular control of the ...
To meet the company's goal of restricting each application to its specific prefix in the S3 bucket with granular control and minimal operational overhead, let's evaluate the provided options:
A) Create dedicated S3 access points and access point policies for each application.
- Reasoning: S3 access points are designed to provide fine-grained access control to specific parts of an S3 bucket (like prefixes) for different applications. Each access point can be restricted to a specific prefix in the bucket, and access can be controlled using policies. This allows for granular control over the objects under each prefix with minimal operational overhead. Each application would access its specific data using its corresponding access point, making it easy to manage permissions.
- Advantages: This approach is simple, scalable, and reduces operational overhead. By using access points and policies, access to each prefix can be tightly controlled without needing to replicate data or set complex access control lists (ACLs).
- Selected because: It meets the requirements directly and efficiently, with the least operational overhead and easy management.
B) Create an S3 Batch Operations job to set the ACL permissions for each object in the S3 bucket.
- Reasoning: S3 Batch Operations allow you to perform bulk operations on objects within the S3 bucket, such as setting ACLs. However, using batch jobs to manage ACLs would require creating and maintaining ACLs for each object, which is more error-prone and requires more ongoing management. It also doesn't provide the granularity of access control needed for specific prefixes in an efficient way.
- Rejected because: While this solution can provide some level of access control, it is not the most efficient approach and adds unnecessary complexity in managing individual object-level ACLs, especially as the number of o...
Author: Madison · Last updated Apr 16, 2026
A company has an application that customers use to upload images to an Amazon S3 bucket. Each night, the company launches an Amazon EC2 Spot Fleet that processes all the images that the company received that day. The processing for each image takes 2 minutes and requires 512 MB of memory.
A solutions architect needs to ch...
Let's evaluate each of the options based on the requirement of processing images immediately when uploaded, while being cost-effective.
A) Use S3 Event Notifications to write a message with image details to an Amazon Simple Queue Service (Amazon SQS) queue. Configure an AWS Lambda function to read the messages from the queue and to process the images.
- Reasoning: This solution uses S3 event notifications to trigger an action whenever a new image is uploaded. The message containing the image details is sent to an SQS queue. An AWS Lambda function can then read from the queue and process the image. Lambda is well-suited for this use case since it is serverless, scales automatically with the load, and charges based on execution time, making it very cost-effective for workloads that require short processing times, like image processing (2 minutes per image).
- Advantages: Lambda is highly scalable, cost-efficient (since you're only charged for execution time), and can easily handle the processing for each image. SQS ensures reliable message delivery.
- Selected because: This solution meets the requirements with minimal cost and management overhead. It leverages serverless computing (Lambda), which is perfect for handling event-driven processing like image uploads.
B) Use S3 Event Notifications to write a message with image details to an Amazon Simple Queue Service (Amazon SQS) queue. Configure an EC2 Reserved Instance to read the messages from the queue and to process the images.
- Reasoning: This option involves using EC2 instances (with Reserved Instances) to process the images. While Reserved Instances may reduce costs for long-term EC2 usage, it still requires the company to manage and maintain the EC2 instances, which adds operational overhead. Additionally, EC2 instances are more expensive than Lambda for this use case, especially for short-lived, event-driven tasks.
- Rejected because: This solution introduces unnecessary complexity and cost. Reserved Instances are intended for consistent, long-term workloads, and they would be more costly compared to Lam...
Author: Aria · Last updated Apr 16, 2026
A company wants to improve the availability and performance of its hybrid application. The application consists of a stateful TCP-based workload hosted on Amazon EC2 instances in different AWS Regions and a stateless UDP-based workload hosted on premises.
Whic...
To improve the availability and performance of the hybrid application, let's analyze each of the options:
A) Create an accelerator using AWS Global Accelerator. Add the load balancers as endpoints.
- Reasoning: AWS Global Accelerator is designed to improve the availability and performance of applications with global users. By using Global Accelerator, traffic can be routed to the closest AWS Region based on health checks and routing policies, improving both availability and performance. Global Accelerator works well for TCP-based applications, such as the stateful workload running on EC2 instances. It can route traffic to both the EC2 endpoints in different AWS Regions and the on-premises endpoints if needed. This would improve both the performance (due to low-latency routing) and availability (by ensuring high availability of endpoints).
- Selected because: This is a great option for improving availability and performance across multiple AWS Regions. It also works well for TCP workloads.
B) Create an Amazon CloudFront distribution with an origin that uses Amazon Route 53 latency-based routing to route requests to the load balancers.
- Reasoning: CloudFront is a content delivery network (CDN) optimized for static content, but it is not typically used for TCP-based stateful workloads. While Route 53 can perform latency-based routing, CloudFront does not natively support TCP load balancing, especially for stateful applications. Therefore, this option would not be as suitable for the TCP-based workload that requires stateful connections.
- Rejected because: CloudFront is more suited for static content and does not handle TCP connections in the same way as a load balancer would. It's not the best fit for stateful TCP workloads.
C) Configure two Application Load Balancers in each Region. The first will route to the EC2 endpoints, and the second will route to the on-premises endpoints.
- Reasoning: Application Load Balancers (ALBs) are designed for HTTP and HTTPS traffic, making them a good fit for stateless UDP-based workloads. However, since the UDP-based workload is on-premises and the EC2 workload is TCP-based, this configuration introduces unnecessary complexity an...
Author: William · Last updated Apr 16, 2026
A company runs a self-managed Microsoft SQL Server on Amazon EC2 instances and Amazon Elastic Block Store (Amazon EBS). Daily snapshots are taken of the EBS volumes.
Recently, all the company's EBS snapshots were accidentally deleted while running a snapshot cleaning script that deletes all expired EBS snapshots. A solutions architect needs to update the arch...
To meet the requirement of preventing data loss without retaining EBS snapshots indefinitely, let's evaluate each option based on the key factors: simplicity, cost, development effort, and scalability.
A) Change the IAM policy of the user to deny EBS snapshot deletion.
- Pros: This is a simple and low-cost solution since it involves updating IAM policies.
- Cons: While this prevents deletion of EBS snapshots by the user, it does not address the issue of keeping snapshots for a reasonable period of time. It merely blocks accidental deletions but does not automate snapshot management or retention, which is crucial in this case.
- Use case: This could be used in scenarios where preventing deletion is important, but there’s still a need for manual snapshot retention policies.
B) Copy the EBS snapshots to another AWS Region after completing the snapshots daily.
- Pros: This provides a level of disaster recovery by having snapshots in a separate region. It adds some protection against region-specific issues.
- Cons: This requires setting up cross-region replication, which could add complexity and increase costs. Additionally, it doesn’t address the need for managing snapshot retention or automating the cleanup of old snapshots. It introduces more development effort for automation.
- Use case: This could be used for disaster recovery purposes, but it doesn't specifically address the issue of ensuring snapshots aren’t deleted prematurely or ensuring that retention policies are adhered to.
C) Create a 7-day EBS snapshot retention rule in Recycle Bin and apply the rule for all snapshots.
- Pros: The Recycle Bin feature allows snapshots to be retained for a specified period (in this case, 7 days) before they are permanently dele...
Author: Henry · Last updated Apr 16, 2026
A company wants to use an AWS CloudFormation stack for its application in a test environment. The company stores the CloudFormation template in an Amazon S3 bucket that blocks public access. The company wants to grant CloudFormation access to the template in the S3 bucket based on specific user request...
To meet the requirements of granting CloudFormation access to an S3 bucket that blocks public access while maintaining security best practices, we need to carefully evaluate each option based on factors such as security, ease of implementation, and suitability for temporary access.
A) Create a gateway VPC endpoint for Amazon S3. Configure the CloudFormation stack to use the S3 object URL.
- Pros: A VPC endpoint for S3 allows private communication between the VPC and S3, which means no traffic goes over the internet. This maintains security by not exposing S3 to the public internet.
- Cons: This option doesn’t address the specific requirement for granting temporary access to CloudFormation based on user requests. The VPC endpoint is generally used for secure communication between EC2 instances in a VPC and S3, not for granting temporary access to CloudFormation. Additionally, configuring CloudFormation to use the S3 URL may still require more manual steps, and it doesn't solve the problem of controlled, temporary access.
- Use case: This is suitable for environments where you want private communication between EC2 instances and S3, but it’s not ideal for granting temporary access to CloudFormation.
B) Create an Amazon API Gateway REST API that has the S3 bucket as the target. Configure the CloudFormation stack to use the API Gateway URL.
- Pros: Using API Gateway could allow for more complex, controlled access to the S3 bucket.
- Cons: This approach is unnecessarily complex. You would need to set up an API Gateway with proper security configurations (IAM roles, Lambda, etc.), which adds overhead and development effort. Also, it doesn't directly address the need for temporary, specific access by CloudFormation. Furthermore, this increases complexity and potentially introduces more points of failure.
- Use case: This option would be better if you needed to create a custom API to handle S3 access or transform data between S3 and CloudFormation, but it introduces unnecessary complexity for this specific scenario.
C) Create a ...
Author: Alexander · Last updated Apr 16, 2026
A company has applications that run in an organization in AWS Organizations. The company outsources operational support of the applications. The company needs to provide access for the external support engineers without compromising security.
The external support engineers need access to the AWS Management Console. The external support engineers also need operating sy...
To meet the requirements of providing external support engineers with access to both the AWS Management Console and EC2 instances in a secure and efficient manner, let’s analyze the given options based on security, ease of implementation, and best practices.
A) Confirm that AWS Systems Manager Agent (SSM Agent) is installed on all instances. Assign an instance profile with the necessary policy to connect to Systems Manager. Use AWS IAM Identity Center to provide the external support engineers console access. Use Systems Manager Session Manager to assign the required permissions.
- Pros:
- No need for direct SSH access: This approach avoids exposing the EC2 instances to the internet by using Systems Manager (SSM) for access, which is secure and managed.
- Centralized console access: IAM Identity Center provides secure, centralized management for console access to external support engineers.
- No additional key management: SSM eliminates the need for managing SSH keys and credentials on individual instances.
- Security best practices: Using SSM and IAM Identity Center adheres to security best practices, as it does not rely on SSH, and there is no direct network access needed to the instances.
- Cons: This solution requires ensuring that the SSM Agent is installed on all instances and that the necessary IAM policies are in place. However, this is generally a best practice for managing EC2 instances.
- Use case: Ideal when secure access is required without the need for SSH access to the EC2 instances, and when centralized management of user access is needed through IAM Identity Center.
B) Confirm that AWS Systems Manager Agent (SSM Agent) is installed on all instances. Assign an instance profile with the necessary policy to connect to Systems Manager. Use Systems Manager Session Manager to provide local IAM user credentials in each AWS account to the external support engineers for console access.
- Pros:
- SSM is used to provide access to instances, which is secure and scalable.
- Cons:
- Providing local IAM user credentials for console access is a security risk as it requires managing individual IAM users for each support engineer across all accounts. This is more complex and increases the attack surface.
- It’s less efficient and harder to scale than using IAM Identity Center, which can manage access across multiple accounts with a single set of credentials.
- Use case: This approach might work in isolated scenarios, but it does not follow security best practices as well as using IAM Identity Center.
C) Confirm that all instances have a security group that allows SSH access only from the external support engineers’ source IP address ra...
Author: Vikram · Last updated Apr 16, 2026
A company uses Amazon RDS for PostgreSQL to run its applications in the us-east-1 Region. The company also uses machine learning (ML) models to forecast annual revenue based on near real-time reports. The reports are generated by using the same RDS for PostgreSQL database. The database performance slows during b...
To improve database performance, it's essential to reduce the load on the primary database instance during business hours when reports are being generated. Let's analyze the solutions based on their cost-effectiveness, simplicity, and ability to meet the requirements:
A) Create a cross-Region read replica. Configure the reports to be generated from the read replica.
- Pros: A cross-Region read replica could offload reporting tasks from the primary database, improving performance. However, cross-region replication introduces significant latency due to data transfer between regions.
- Cons: Cross-Region replication incurs additional costs for inter-region data transfer, and the added latency between the primary region and the replica might be a concern for near real-time reporting. Also, this solution is not cost-effective because of the complexity and the cost of transferring data across regions.
- Use case: This might be appropriate if there were strict requirements to have a replica in a different region, but it is not the best option for performance improvement in this case due to latency and cost concerns.
B) Activate Multi-AZ DB instance deployment for RDS for PostgreSQL. Configure the reports to be generated from the standby database.
- Pros: Multi-AZ deployments improve availability and disaster recovery but do not directly address performance concerns during peak business hours. The standby instance is meant to be a failover, not for read queries, and it would not offload reporting traffic effectively.
- Cons: This option increases costs because it involves duplicating resources for high availability but does not provide a solution to offload read traffic. Multi-AZ is primarily for fault tolerance and cannot be used to scale read capacity during high load.
- Use case: Suitable for improving availability but not performance under normal load conditions.
C) Use AWS Data Migration Service (AWS DMS) to logically replicate data to a new database. Configure the reports to be generated from the new databas...
Author: Olivia · Last updated Apr 16, 2026
A company hosts its multi-tier, public web application in the AWS Cloud. The web application runs on Amazon EC2 instances, and its database runs on Amazon RDS. The company is anticipating a large increase in sales during an upcoming holiday weekend. A solutions architect needs to build a solution to analyze the performan...
To analyze the performance of a web application with a granularity of no more than 2 minutes, we need a solution that provides real-time or near-real-time monitoring and analysis. Let's evaluate the options based on cost, ease of implementation, and ability to meet the granularity requirement.
A) Send Amazon CloudWatch logs to Amazon Redshift. Use Amazon QuickSight to perform further analysis.
- Pros: Redshift can handle large volumes of data and is suitable for running complex queries for analysis. QuickSight integrates well with Redshift for visualizing data.
- Cons: Sending CloudWatch logs to Redshift requires a more complex setup. Additionally, CloudWatch logs are generally not designed for real-time analysis; they typically have a delay in log delivery and processing. This approach may not meet the requirement for granularity of 2 minutes and could introduce latency.
- Use case: This option is useful for deep, historical data analysis on large datasets, but it’s not ideal for near real-time monitoring with granular intervals.
B) Enable detailed monitoring on all EC2 instances. Use Amazon CloudWatch metrics to perform further analysis.
- Pros: CloudWatch detailed monitoring provides a 1-minute granularity, which is within the required 2-minute granularity. This allows you to monitor EC2 instance performance metrics such as CPU utilization, memory, disk I/O, and network I/O in near real time.
- Cons: This solution focuses on EC2 instance metrics but does not directly address application-level performance or database metrics. However, for the purposes of general EC2 performance analysis, this is a very cost-effective and simple solution.
- Use case: Ideal when you need to analyze EC2 instance performance at fine granularity, such as CPU or memory utilization, with minimal setup.
C) Create an AWS Lambda function to fetch EC2 logs from Amazon CloudWatch Logs. Use Amazon CloudWatch metrics to p...
Author: Grace · Last updated Apr 16, 2026
A company runs an application that stores and shares photos. Users upload the photos to an Amazon S3 bucket. Every day, users upload approximately 150 photos. The company wants to design a solution that creates a thumbnail of each new photo and store...
Let's analyze each option based on cost-effectiveness, scalability, and how well it aligns with the requirements of the company.
A) Configure an Amazon EventBridge scheduled rule to invoke a script every minute on a long-running Amazon EMR cluster. Configure the script to generate thumbnails for the photos that do not have thumbnails. Configure the script to upload the thumbnails to the second S3 bucket.
- Reasoning:
- Cost: Running a long-running EMR cluster 24/7 to check for new uploads would likely incur higher costs due to the cluster's compute resources being continuously available.
- Scalability: While EMR can scale, this approach is overkill for the small, predictable number of new uploads (150 photos daily) and doesn't justify the operational overhead.
- Latency: This solution has higher latency since it only runs once per minute, which isn't ideal for real-time photo processing.
- Rejection: This option is less cost-effective because of the continuous operation of an EMR cluster, which introduces unnecessary costs and complexity for the task.
B) Configure an Amazon EventBridge scheduled rule to invoke a script every minute on a memory-optimized Amazon EC2 instance that is always on. Configure the script to generate thumbnails for the photos that do not have thumbnails. Configure the script to upload the thumbnails to the second S3 bucket.
- Reasoning:
- Cost: Like option A, this involves running an EC2 instance continuously, which may incur higher costs than needed. The instance needs to be always on to check for uploads and generate thumbnails, leading to inefficient resource usage.
- Scalability: EC2 instances can scale, but for 150 photos per day, an EC2 instance running constantly would not be an optimal solution.
- Latency: The solution runs on a fixed schedule (every minute), which may not be ideal for handling the new photos immediately after upload.
- Rejection: This option has higher costs compared to serverless solutions and does not offer efficient scaling.
C) Configure an S3 event notification to invoke an AWS Lambda function each time a user uploads a new photo to the application...
