Amazon Practice Questions, Discussions & Exam Topics by our Authors
A company is migrating an on-premises application and a MySQL database to AWS. The application processes highly sensitive data, and new data is constantly updated in the database. The data must not be transferred over the internet. The company also must encrypt the data in transit and at rest.
The database is 5 TB in size. The company already has created the database schema in an Amazon RDS for MySQL DB instance. The company has set up a 1 Gbps AWS Direct Connect connection to AWS. The compa...
Let's evaluate the options based on the requirements of migrating a 5 TB MySQL database with high security, minimal downtime, and data encryption at rest and in transit. The company also needs to avoid transferring the data over the internet and already has AWS Direct Connect set up.
Breakdown of the Options:
Option A: Perform a database backup. Copy the backup files to an AWS Snowball Edge Storage Optimized device. Import the backup to Amazon S3. Use server-side encryption with Amazon S3 managed encryption keys (SSE-S3) for encryption at rest. Use TLS for encryption in transit. Import the data from Amazon S3 to the DB instance.
- Snowball Edge provides secure physical devices for large data transfers to AWS, especially for environments with limited internet connectivity.
- Advantages: Physical transport of the data avoids internet transfer and ensures high security.
- Disadvantages: Snowball is more suited for bulk data transfer. This approach may lead to more downtime due to the need to wait for the Snowball device to arrive, load, and transfer the data.
- Rejected: While secure, this solution doesn't minimize downtime during the migration, as it involves waiting for physical devices to arrive and be processed.
Option B: Use AWS Database Migration Service (AWS DMS) to migrate the data to AWS. Create a DMS replication instance in a private subnet. Create VPC endpoints for AWS DMS. Configure a DMS task to copy data from the on-premises database to the DB instance by using full load plus change data capture (CDC). Use the AWS Key Management Service (AWS KMS) default key for encryption at rest. Use TLS for encryption in transit.
- AWS DMS is designed for minimal downtime migrations by using continuous data replication with CDC (Change Data Capture) after an initial full load. It allows for the migration of live data while it is still being updated.
- Advantages:
- Secure and efficient.
- DMS supports encryption in transit (using TLS) and at rest (using KMS for encryption).
- It allows for near-zero downtime by keeping the source database in sync with the target.
- Best fit: This option is optimal for migrating a database with ongoing updates and minimal downtime, and it meets the security requirements.
- Selected: DMS is designed fo...
Author: Rahul · Last updated May 13, 2026
Accompany is deploying a new cluster for big data analytics on AWS. The cluster will run across many Linux Amazon EC2 instances that are spread across multiple Availability Zones.
All of the nodes in the cluster must have read and write access to common underlying file storage. The file storage must be highly available, must be resilient, must be compatible w...
The requirements for the storage solution are clear: it must be highly available, resilient, POSIX-compatible, and support high throughput. Let's break down each option and see which one best fits these needs.
Option A: Provision an AWS Storage Gateway file gateway NFS file share that is attached to an Amazon S3 bucket. Mount the NFS file share on each EC2 instance in the cluster.
- AWS Storage Gateway is typically used to bridge on-premises environments with cloud storage and is designed for hybrid cloud scenarios.
- Disadvantages:
- It's primarily focused on storing data in Amazon S3 and isn't designed for high-performance, low-latency file storage like Amazon EFS.
- While it offers NFS access to S3, it doesn't provide the same level of performance or POSIX file system compatibility as other options like Amazon EFS.
- It doesn't meet the high throughput requirements for big data analytics.
- Rejected: This option is not suited for high-performance, POSIX-compliant, high-throughput file storage.
Option B: Provision a new Amazon Elastic File System (Amazon EFS) file system that uses General Purpose performance mode. Mount the EFS file system on each EC2 instance in the cluster.
- Amazon EFS provides a fully managed, POSIX-compliant file system that supports NFS, making it a good fit for Linux-based clusters.
- General Purpose performance mode is designed for lower throughput and is good for general-purpose file storage.
- Disadvantages:
- While General Purpose mode supports moderate throughput, it may not provide the high throughput needed for big data analytics workloads.
- High throughput and low-latency requirements are not fully addressed by the General Purpose mode.
- Rejected: Although EFS is a good option for general file storage, General Purpose mode might not meet the performance requirements for big data analytics with high throughput.
Option C: Provision a new Amazon Elastic Block Store (Amazon EBS) volume that uses the io2 volume type. Attach the EBS volume to all of the EC2 instances in the cluster.
- Amazon EBS volumes are block-level storage and provide high-performance storage, especially with the io2 volume type, which is designed for high IOPS...
Author: Benjamin · Last updated May 13, 2026
A company hosts a software as a service (SaaS) solution on AWS. The solution has an Amazon API Gateway API that serves an HTTPS endpoint. The API uses AWS Lambda functions for compute. The Lambda functions store data in an Amazon Aurora Serverless v1 database.
The company used the AWS Serverless Application Model (AWS SAM) to deploy the solution. The solution extends across multiple Availability Zones and has no disaster recovery (DR) plan.
A solutions architect must...
To design a disaster recovery (DR) strategy for the solution with specific RTO (Recovery Time Objective) and RPO (Recovery Point Objective) requirements, let's evaluate the options based on the following criteria:
- RTO of 5 minutes: The solution must be able to recover and be operational within 5 minutes after a disaster.
- RPO of 1 minute: The data loss between the time of the disaster and recovery must be minimized, with a maximum of 1 minute of data loss.
- Disaster Recovery Across Regions: The DR solution should be able to replicate data and recover quickly in another AWS Region.
Breakdown of the Options:
Option A: Create a read replica of the Aurora Serverless v1 database in the target Region. Use AWS SAM to create a runbook to deploy the solution to the target Region. Promote the read replica to primary in case of disaster.
- Aurora Serverless v1 does not support cross-region read replicas. This would be applicable to standard Aurora databases but not Serverless v1.
- RPO and RTO considerations: While promoting a read replica can meet recovery needs, the lack of native cross-region replication for Aurora Serverless v1 makes this solution infeasible.
- Rejected: Aurora Serverless v1 cannot replicate across regions, and the read replica solution would not meet the RTO and RPO requirements.
Option B: Change the Aurora Serverless v1 database to a standard Aurora MySQL global database that extends across the source Region and the target Region. Use AWS SAM to create a runbook to deploy the solution to the target Region.
- Aurora MySQL Global Database provides cross-region replication and supports both the RTO and RPO requirements. With a global database, data can be replicated with low latency across regions, making it a good fit for disaster recovery.
- Advantages:
- Aurora Global Database allows for fast failover across regions, minimizing downtime and meeting the 5-minute RTO requirement.
- It supports continuous replication with low-latency, ensuring the 1-minute RPO requirement is met.
- Selected: This is a robust solution for DR that supports cross-region replication ...
Author: Amira99 · Last updated May 13, 2026
A company owns a chain of travel agencies and is running an application in the AWS Cloud. Company employees use the application to search for information about travel destinations. Destination content is updated four times each year.
Two fixed Amazon EC2 instances serve the application. The company uses an Amazon Route 53 public hosted zone with a multivalue record of travel.example.com that returns the Elastic IP addresses for the EC2 instances. The application uses Amazon DynamoDB as its primary data store. The company uses a self-hosted Redis instance as a caching solution.
During content updates, the load on the EC2 instances and the caching solution inc...
Option Analysis:
- A) Set up DynamoDB Accelerator (DAX) as in-memory cache. Update the application to use DAX. Create an Auto Scaling group for the EC2 instances. Create an Application Load Balancer (ALB). Set the Auto Scaling group as a target for the ALB. Update the Route 53 record to use a simple routing policy that targets the ALB's DNS alias. Configure scheduled scaling for the EC2 instances before the content updates.
- Why it works: DynamoDB Accelerator (DAX) is designed to cache the results of DynamoDB queries, significantly improving read performance and reducing load on the DynamoDB tables. This is especially beneficial during high-traffic events such as content updates. Auto Scaling ensures that the EC2 instances can scale based on demand. The Application Load Balancer (ALB) can distribute traffic across multiple EC2 instances, ensuring high availability. Scheduled scaling allows the system to handle increased load during the content updates.
- Why it’s a good option: This solution addresses the caching and EC2 scaling requirements while keeping the architecture highly available and automatically scalable, especially during peak loads caused by content updates.
- B) Set up Amazon ElastiCache for Redis. Update the application to use ElastiCache. Create an Auto Scaling group for the EC2 instances. Create an Amazon CloudFront distribution, and set the Auto Scaling group as an origin for the distribution. Update the Route 53 record to use a simple routing policy that targets the CloudFront distribution's DNS alias. Manually scale up EC2 instances before the content updates.
- Why it doesn’t fully meet the needs: ElastiCache for Redis is a great caching solution, and scaling EC2 instances through an Auto Scaling group ensures application scalability. However, using Amazon CloudFront as the origin for EC2 instances is not ideal for dynamic applications where content is frequently updated. CloudFront is better suited for static content delivery, not for serving dynamic traffic generated by an application. Also, manually scaling up EC2 instances introduces the possibility of human error and doesn't provide automatic scaling based on traffic demand.
- Why it’s not optimal: The need for manual scaling creates potential for human error, and CloudFront isn't the most appropriate for this use case where dynamic data (like frequently updated content) is involved.
- C) Set up Amazon ElastiCache for Memcached. Update the application to use Elas...
Author: SolarFalcon11 · Last updated May 13, 2026
A company needs to store and process image data that will be uploaded from mobile devices using a custom mobile app. Usage peaks between 8 AM and 5 PM on weekdays, with thousands of uploads per minute. The app is rarely used at any other time. A user is notified when image processing is complete.
Whic...
Option Analysis:
- A) Upload files from the mobile software directly to Amazon S3. Use S3 event notifications to create a message in an Amazon MQ queue.
- Why it’s not ideal: While Amazon MQ is a managed message broker service, it's not as cost-effective or scalable as SQS for high-throughput scenarios like this. Amazon MQ is designed for more traditional message queuing and does not necessarily optimize for the scale of image upload events that the scenario requires. Additionally, SQS is generally more flexible, easy to integrate with Lambda, and better suited for event-driven workloads.
- Why it’s rejected: SQS offers better scalability and ease of integration for this use case, especially in scenarios with thousands of events per minute.
- B) Upload files from the mobile software directly to Amazon S3. Use S3 event notifications to create a message in an Amazon Simple Queue Service (Amazon SQS) standard queue.
- Why it works: This option is optimal because:
- Amazon S3 can handle large numbers of file uploads, which is a crucial requirement here.
- S3 event notifications can automatically trigger messages to an SQS queue when a file is uploaded, which is efficient for integrating the upload and processing stages.
- SQS standard queues are highly scalable and can handle the throughput required by thousands of uploads per minute, ensuring that messages (representing image processing tasks) are queued for processing by downstream systems.
- Why it’s a good option: SQS is ideal for scalable, event-driven workloads and can integrate well with AWS Lambda to scale the image processing function as needed.
- C) Invoke an AWS Lambda function to perform image processing when a message is available in the queue.
- Why it works: Lambda is a highly scalable, serverless compute service that automatically adjusts to the volume of incoming messages. This is crucial for handling variable workloads (e.g., the peak upload times). By invoking a Lambda function to process images, the system can automatically scale the number of concurrent image processing jobs without manual intervention. Additionally, Lambda works seamlessly with SQS, ensuring smooth processing as messages arrive in the queue.
- Why it’s a good option: Lambda enables efficient scaling for the image processing workload, and because it operates in response to SQS messages, it integrates well into the event-driven architec...
Author: StarryEagle42 · Last updated May 13, 2026
A company is building an application on AWS. The application sends logs to an Amazon OpenSearch Service cluster for analysis. All data must be stored within a VPC.
Some of the company's developers work from home. Other developers work from three different company office locations. The developers need to access OpenSe...
Option Analysis:
- A) Configure and set up an AWS Client VPN endpoint. Associate the Client VPN endpoint with a subnet in the VPC. Configure a Client VPN self-service portal. Instruct the developers to connect by using the client for Client VPN.
- Why it works: AWS Client VPN is a fully managed, scalable VPN service that allows secure remote access to resources within a VPC. By configuring a Client VPN endpoint and associating it with a subnet, developers can securely connect to the VPC from any location (home, office, etc.) and access the OpenSearch Service. It is ideal for developers working remotely or from different locations, as it allows access to resources within the VPC without needing complex network configurations.
- Why it’s a good option: This option provides secure access, scales automatically with the number of users, and is easier to manage than other solutions. It directly supports developers working remotely or from multiple locations, as required in the use case.
- B) Create a transit gateway, and connect it to the VPC. Create an AWS Site-to-Site VPN. Create an attachment to the transit gateway. Instruct the developers to connect by using an OpenVPN client.
- Why it’s not ideal: While a Site-to-Site VPN can securely connect office networks to AWS, it does not provide an easy or scalable solution for individual remote developers to connect directly to the VPC. The setup would require additional configuration and is typically suited for connecting on-premises data centers to AWS rather than allowing individual developers to connect directly. Using OpenVPN with a transit gateway would not be as efficient as a dedicated solution like AWS Client VPN for remote access.
- Why it’s rejected: This is a more complex solution intended for enterprise-scale connections and doesn't directly support the remote developer access requirements in an efficient way.
- C) Create a transit gateway, and connect it to the VPC. Order an AWS Direct Connect connection. Set up a public VIF on th...
Author: Suresh · Last updated May 13, 2026
A company wants to migrate its website from an on-premises data center onto AWS. At the same time, it wants to migrate the website to a containerized microservice-based architecture to improve the availability and cost efficiency. The company's security policy states that privileges and network permissions must be configured according to best practice, using least privilege.
A solutions architect must create a containerized archite...
Option Analysis:
- A) Create tasks using the bridge network mode.
- Why it’s not ideal: The bridge network mode is used for Docker containers that are running on a single EC2 instance. While it works for some simple applications, it does not scale well for containerized microservices in a production environment, especially with Amazon ECS. The bridge network mode does not provide tasks with the same level of isolation and flexibility in terms of networking, which could limit the ability to apply security best practices and network segmentation.
- Why it’s rejected: In the context of modern containerized architectures and microservices, the bridge mode is not suitable, as it does not provide the necessary security and networking configurations that can be easily scaled in ECS.
- B) Create tasks using the awsvpc network mode.
- Why it works: The `awsvpc` network mode gives each ECS task its own elastic network interface (ENI), providing better networking isolation and security. This mode is recommended for applications that require secure, isolated networking environments. By using `awsvpc`, tasks can have security groups applied directly, enabling granular network-level access control to other resources in the VPC. This is crucial for implementing least privilege security policies.
- Why it’s a good option: The `awsvpc` network mode ensures that each task can be independently secured with security groups, which aligns well with the company's security policy and the principle of least privilege.
- C) Apply security groups to Amazon EC2 instances, and use IAM roles for EC2 instances to access other resources.
- Why it’s not ideal: While applying security groups to EC2 instances and using IAM roles for EC2 instances is a best practice for EC2-based applications, this approach does not address the specific security and network isolation requirements for the ECS tasks themselves. In a containerized architecture using ECS, the focus should be on applying security gro...
Author: Daniel · Last updated May 13, 2026
A company is running a serverless application that consists of several AWS Lambda functions and Amazon DynamoDB tables. The company has created new functionality that requires the Lambda functions to access an Amazon Neptune DB cluster. The Neptune DB cluster is located in three subnets in a VPC.
W...
Option Analysis:
- A) Create three public subnets in the Neptune VPC, and route traffic through an internet gateway. Host the Lambda functions in the three new public subnets.
- Why it’s not ideal: Hosting the Lambda functions in public subnets would expose them to the internet, which can increase the attack surface and violate the security principle of least privilege. The Lambda functions don't need public internet access to interact with Neptune or DynamoDB, as both services can be accessed securely through VPC-private connectivity. Additionally, Neptune, as a managed service, is typically used within private subnets to restrict direct internet access.
- Why it’s rejected: This solution increases security risks by placing Lambda functions in public subnets unnecessarily, which is not recommended for a secure serverless application architecture.
- B) Create three private subnets in the Neptune VPC, and route internet traffic through a NAT gateway. Host the Lambda functions in the three new private subnets.
- Why it works: Hosting Lambda functions in private subnets allows them to securely interact with the Neptune DB cluster without exposure to the public internet. The NAT gateway is useful for enabling outbound internet access for the Lambda functions if needed (e.g., for API calls or package downloads). This solution ensures that all traffic between the Lambda functions and Neptune DB remains within the VPC, maintaining secure, private communication.
- Why it’s a good option: Hosting Lambda in private subnets allows for secure access to both Neptune and DynamoDB, ensuring that the serverless application architecture remains isolated and follows security best practices.
- C) Host the Lambda functions outside the VPC. Update the Neptune security group to allow access from the IP ranges of the Lambda functions.
- Why it’s not ideal: Hosting Lambda functions outside of the VPC means they will need to access Neptune over the internet, which is not recommended for communication with services that reside inside a VPC. Furthermore, managing security group rules for Lambda functions accessing resources outside the VPC can lead to security risks and is cumbersome. Additionally, Lambda functions do not have IP addresses when they are outside a VPC, so configuring security groups based on IP rang...
Author: Aarav2020 · Last updated May 13, 2026
A company wants to design a disaster recovery (DR) solution for an application that runs in the company's data center. The application writes to an SMB file share and creates a copy on a second file share. Both file shares are in the data center. The application uses two types of files: metadata files and image files.
The company wants to store the copy on AWS. The company needs the abili...
To determine the most appropriate disaster recovery (DR) solution for the given scenario, we need to consider key factors like access time, cost, and the nature of the data. Here's an analysis of each option based on the provided requirements:
A) Deploy AWS Outposts with Amazon S3 storage. Configure a Windows Amazon EC2 instance on Outposts as a file server.
- Pros: AWS Outposts brings AWS infrastructure on-premises, allowing you to extend your existing data center to AWS seamlessly. This can provide a consistent hybrid environment, and using a Windows EC2 instance with SMB support could meet the file sharing requirements.
- Cons: AWS Outposts is typically used for more specific workloads where low latency is critical, or where there are regulatory requirements for on-premises infrastructure. This solution is expensive, especially when you're only dealing with backup and disaster recovery. It also introduces more complexity compared to other options for a disaster recovery scenario.
- Access Time: Outposts would likely meet the 5-minute access time requirement, but it may introduce more overhead in terms of management and cost.
B) Deploy an Amazon FSx File Gateway. Configure an Amazon FSx for Windows File Server Multi-AZ file system that uses SSD storage.
- Pros: Amazon FSx for Windows File Server is specifically designed to provide a fully managed file system that supports SMB, making it a good fit for this scenario. It offers multi-AZ deployment for high availability and durability, which is essential for disaster recovery. SSD storage ensures faster performance for metadata files.
- Cons: This option is more focused on providing a fully managed file server, which could be overkill for the backup and disaster recovery scenario, especially considering the low frequency of access for image files. The SSD storage might not be necessary for infrequently accessed files, leading to unnecessary costs.
- Access Time: With multi-AZ support, this solution can likely meet the 5-minute access time requireme...
Author: Leo · Last updated May 13, 2026
A company is creating a solution that can move 400 employees into a remote working environment in the event of an unexpected disaster. The user desktops have a mix of Windows and Linux operating systems. Multiple types of software, such as web browsers and mail clients, are installed on each desktop.
A solutions architect needs to implement a solution that can be integrated with the company's on-premises Active Directory to allow employees to use their exis...
To select the best solution for enabling 400 employees to work remotely during a disaster, the solution needs to meet several key requirements:
- Integration with on-premises Active Directory to leverage existing user credentials.
- Support for Windows and Linux desktops.
- Multifactor authentication (MFA) for secure access.
- Replicating the user experience from existing desktops.
Option Breakdown:
A) Use Amazon WorkSpaces for the cloud desktop service. Set up a VPN connection to the on-premises network. Create an AD Connector, and connect to the on-premises Active Directory. Activate MFA for Amazon WorkSpaces by using the AWS Management Console.
- Pros:
- Amazon WorkSpaces is a fully managed cloud desktop solution that provides Windows and Linux desktops with a user experience similar to physical desktops.
- AD Connector can be used to integrate Amazon WorkSpaces with the existing on-premises Active Directory, allowing employees to use their existing credentials.
- MFA can be enabled via the AWS Management Console.
- WorkSpaces is well-suited for a broad range of applications, including those that employees typically use in a remote environment, such as web browsers and mail clients.
- Cons:
- The solution requires setting up a VPN to connect to the on-premises network, which could add complexity and some maintenance overhead.
- There might be additional infrastructure setup required for VPN and MFA configuration, but WorkSpaces itself is a straightforward solution for cloud desktops.
B) Use Amazon AppStream 2.0 as an application streaming service. Configure Desktop View for the employees. Set up a VPN connection to the on-premises network. Set up Active Directory Federation Services (AD FS) on premises. Connect the VPC network to AD FS through the VPN connection.
- Pros:
- Amazon AppStream 2.0 is an application streaming service that allows users to access applications remotely.
- Integrating with AD FS could help authenticate users using on-premises Active Directory credentials.
- Cons:
- AppStream 2.0 does not provide full desktop virtualization. It is better suited for delivering applications rather than full desktops. This would not replicate the existing user desktop experience (e.g., custom software, personalizations, etc.).
- Desktop View configuration in AppStream 2.0 is not typically designed for full desktop environments, so users would not get the same experience as they would with WorkSpaces.
- ...
Author: Benjamin · Last updated May 13, 2026
A company has deployed an Amazon Connect contact center. Contact center agents are reporting large numbers of computer-generated calls. The company is concerned about the cost and productivity effects of these calls. The company wants a solution that will allow agents to flag the call as spam and automatically b...
To address the concern of blocking computer-generated calls (spam calls) in an Amazon Connect contact center while ensuring operational efficiency, we need to choose a solution that allows agents to quickly flag spam calls and automate the process of blocking those numbers for future calls.
Option Analysis:
A) Customize the Contact Control Panel (CCP) by adding a flag call button that will invoke an AWS Lambda function that calls the UpdateContactAttributes API. Use an Amazon DynamoDB table to store the spam numbers. Modify the contact flows to look for the updated attribute and to use a Lambda function to read and write to the DynamoDB table.
- Pros: This solution allows agents to flag spam calls directly within the CCP, making it user-friendly. The Lambda function can update the contact attributes, and the DynamoDB table can store the flagged spam numbers. The contact flow can then reference this table to avoid connecting future calls from the flagged numbers to agents.
- Cons: This requires customization of both the CCP and contact flows. While this solution is flexible, it adds complexity to the implementation and might require more maintenance.
- Use Case: This option is well-suited if the company wants agents to interact directly with the system and flag calls, and if there's a need for detailed customization and control over the process.
B) Use a Contact Lens for Amazon Connect rule that will look for spam calls. Use an Amazon DynamoDB table to store the spam numbers. Modify the contact flows to look for the rule and to invoke an AWS Lambda function to read and write to the DynamoDB table.
- Pros: Contact Lens offers built-in capabilities to analyze the content of calls, which can automatically detect spam or unwanted calls. It can trigger actions like invoking a Lambda function to update the spam list in DynamoDB.
- Cons: While Contact Lens can detect some forms of spam, it may not capture all computer-generated or robocalls accurately, depending on the rule configurations. Additionally, the solution requires modifying contact flows to call a Lambda function, which could increase complexity.
- Use Case: This is a good option if you want automated detection of spam calls based on content analysis but could have some limitations in detecting all types of spam calls, especially if they are not clearly identifiable through speech analysis.
C) Use an Amazon DynamoDB table to store the spam numbers. Create a quick connect that the agents ...
Author: Arjun · Last updated May 13, 2026
A company has mounted sensors to collect information about environmental parameters such as humidity and light throughout all the company's factories. The company needs to stream and analyze the data in the AWS Cloud in real time. If any of the parameters fall out of acceptable ran...
To meet the company's requirements of streaming and analyzing environmental data in real-time and sending notifications if parameters fall outside acceptable ranges, we need a solution that can:
1. Stream the data in real-time.
2. Analyze the data to detect out-of-range values.
3. Notify the operations team immediately if an anomaly is detected.
Let’s break down each option:
A) Stream the data to an Amazon Kinesis Data Firehose delivery stream. Use AWS Step Functions to consume and analyze the data in the Kinesis Data Firehose delivery stream. Use Amazon Simple Notification Service (Amazon SNS) to notify the operations team.
- Pros: Kinesis Data Firehose is a fully managed service designed for easy delivery of streaming data to destinations like Amazon S3 or Redshift. Step Functions can be used to orchestrate tasks and trigger actions, and SNS can notify the operations team.
- Cons: While Kinesis Data Firehose is great for data delivery, it's not ideal for real-time processing or complex analysis of streaming data. Step Functions is better suited for orchestrating workflows but is not optimized for direct, real-time data analysis. Firehose is better suited for data delivery rather than analysis.
- Use Case: This option is better suited for batch processing or for collecting and storing data. It may not provide the real-time analysis and notification needed for this use case.
B) Stream the data to an Amazon Managed Streaming for Apache Kafka (Amazon MSK) cluster. Set up a trigger in Amazon MSK to invoke an AWS Fargate task to analyze the data. Use Amazon Simple Email Service (Amazon SES) to notify the operations team.
- Pros: Amazon MSK provides a fully managed Kafka service for streaming data, and AWS Fargate can be used to run containerized tasks to process the data. SES can be used for sending emails to the operations team.
- Cons: Kafka and Fargate are powerful tools, but this solution is more complex and may be over-engineered for the given requirements. Setting up and maintaining a Kafka cluster, as well as the integration with Fargate, introduces more complexity than necessary for this use case. Additionally, real-time processing with MSK might not be as streamlined as other services like Kinesis.
- Use Case: This solution is better suited for very large-scale, complex stream processing applications, but it may not be the most e...
Author: John · Last updated May 13, 2026
A company is preparing to deploy an Amazon Elastic Kubernetes Service (Amazon EKS) cluster for a workload. The company expects the cluster to support an unpredictable number of stateless pods. Many of the pods will be created during a short time period as the workload ...
To maximize node resilience in an Amazon Elastic Kubernetes Service (Amazon EKS) cluster, the solution should ensure that the workload remains highly available and resilient to failures, especially when the workload dynamically scales based on replicas. Let's break down each option to see which best meets the requirements.
A) Use a separate launch template to deploy the EKS control plane into a second cluster that is separate from the workload node groups.
- Pros: The control plane is critical for managing the cluster, and separating it from workload nodes could isolate management and operational concerns.
- Cons: This approach doesn't directly address node resilience for workload pods or scaling challenges. In fact, it introduces unnecessary complexity because the EKS control plane is fully managed by AWS, so manually managing control plane nodes in a separate cluster is not needed. The issue is more about ensuring sufficient compute capacity and availability for workload pods, not managing the control plane.
- Use Case: This option is not directly relevant to maximizing node resilience for workloads, as it focuses on control plane architecture, which doesn't impact the resilience of the application workload.
B) Update the workload node groups. Use a smaller number of node groups and larger instances in the node groups.
- Pros: Fewer node groups and larger instances could simplify management.
- Cons: Using fewer, larger instances might reduce the overall resilience of the cluster. If a large instance fails, it can affect multiple pods, causing a larger disruption. The approach doesn't take full advantage of the flexibility and resilience offered by scaling node groups in different Availability Zones.
- Use Case: This is not ideal for maximizing node resilience because it may lead to reduced availability in the case of node failure. A more distributed approach with multiple smaller nodes would be more resilient.
C) Configure the Kubernetes Cluster Autoscaler to ensure that the compute capacity of the workload node groups stays underprovisioned.
- Pros: The Cluster Autoscaler can dynamica...
Author: BlazingPhoenix22 · Last updated May 13, 2026
A company needs to implement a disaster recovery (DR) plan for a web application. The application runs in a single AWS Region.
The application uses microservices that run in containers. The containers are hosted on AWS Fargate in Amazon Elastic Container Service (Amazon ECS). The application has an Amazon RDS for MySQL DB instance as its data layer and uses Amazon Route 53 for DNS resolution. An Amazon CloudWatch alarm invokes an Amazon EventBridge rule if the application experiences a failure.
A solutio...
Let's evaluate the options based on the requirements and the different aspects involved in a disaster recovery (DR) solution:
Key Factors:
1. Minimizing Recovery Time: The primary goal is to reduce the time needed for recovery.
2. High Availability of Application: The solution should ensure minimal downtime and seamless failover to the secondary Region.
3. RDS for MySQL: The application relies on RDS for MySQL, which suggests that the solution should be aligned with database recovery and failover strategies for relational databases.
4. Route 53 for DNS Resolution: Route 53 should be updated quickly to route traffic to the new Region.
Evaluation of Options:
Option A:
- Steps:
1. Set up a second ECS cluster and ECS service in the separate Region.
2. Lambda function creates an RDS snapshot, copies it to the second Region, creates a new RDS DB instance, and updates Route 53.
- Pros:
- This is a feasible approach with manual snapshot management for the RDS database.
- It ensures that you can recover the database to a point in time via snapshots.
- Route 53 will be updated to reroute traffic after recovery.
- Cons:
- Recovery time can be long due to the manual snapshot process (RDS snapshots take time to copy and restore).
- The database will not be fully in sync at the time of failover because snapshots are not real-time replication.
- RDS DB instance failover may take longer, especially since the database is not continuously synchronized.
Option B:
- Steps:
1. Lambda function to create a second ECS cluster and service in the separate Region.
2. Lambda also manages RDS snapshot creation, copying, and creating a new RDS instance.
3. Updates Route 53.
- Pros:
- Similar to Option A but automates the process via Lambda.
- Cons:
- Manual snapshotting still applies, leading to similar recovery time concerns as Option A.
- Snapshot-based recovery is not optimal for minimizing recovery time.
Option C:
- Steps:
1. Set up a second ...
Author: Layla · Last updated May 13, 2026
A company has AWS accounts that are in an organization in AWS Organizations. The company wants to track Amazon EC2 usage as a metric. The company's architecture team must receive a daily alert if the EC2 usage is more than 10% h...
To address the company's need to track EC2 usage and alert the architecture team if usage exceeds 10% more than the average of the past 30 days, we need to evaluate different AWS services based on their capabilities to monitor EC2 usage and send alerts based on usage thresholds.
Option Breakdown:
A) Configure AWS Budgets in the organization's management account. Specify a usage type of EC2 running hours. Specify a daily period. Set the budget amount to be 10% more than the reported average usage for the last 30 days from AWS Cost Explorer. Configure an alert to notify the architecture team if the usage threshold is met.
- Pros:
- AWS Budgets allows tracking of usage metrics, including EC2 running hours, and can provide notifications when the usage exceeds a set threshold.
- It can be configured to alert the architecture team when usage is 10% higher than the average from the last 30 days.
- Cons:
- AWS Budgets is more focused on cost tracking and budgets, rather than directly measuring usage metrics like EC2 usage in terms of hours or other relevant metrics. Although it is possible to track usage through a budget, this is typically more cost-related and less granular for performance usage tracking.
- Budgets may not track precise daily usage patterns or provide the kind of alerting that is specifically usage-based in real-time for EC2 instances.
B) Configure AWS Cost Anomaly Detection in the organization's management account. Configure a monitor type of AWS Service. Apply a filter of Amazon EC2. Configure an alert subscription to notify the architecture team if the usage is 10% more than the average usage for the last 30 days.
- Pros:
- AWS Cost Anomaly Detection is designed to detect unusual changes in usage, and it can track service-specific metrics, including EC2 usage. It can automatically detect anomalies and trigger alerts.
- The service can track EC2 usage across multiple accounts and regions, making it highly scalable in an organization setup with multiple AWS accounts.
- The ability to set up anomaly detection based on 30-day historical data is precisely what the company needs to monitor for the 10% usage increase.
- Cons:
- This is more cost-centric, detecting unusual increases in cost, but it cou...
Author: Liam123 · Last updated May 13, 2026
An e-commerce company is revamping its IT infrastructure and is planning to use AWS services. The company's CIO has asked a solutions architect to design a simple, highly available, and loosely coupled order processing application. The application is responsible for receiving and processing orders before storing them in an Amazon DynamoDB table. The application has a sporadic traffic pattern and sh...
To design a solution that is simple, highly available, loosely coupled, and scalable to handle sporadic traffic patterns with the ability to scale during marketing campaigns, we need to consider the following key factors:
1. Simplicity: The solution should not involve complex infrastructure or management overhead.
2. High Availability: The solution should ensure that the application remains operational even during traffic spikes.
3. Loosely Coupled: The order processing system should be independent of other components, so failures in one component don’t affect others.
4. Scalability: The solution should scale automatically based on traffic patterns, especially during marketing campaigns when traffic spikes are expected.
5. Minimal Delays: Processing the orders should be as fast as possible to avoid delays in storing the orders in DynamoDB.
Evaluation of Options:
Option A: EC2-hosted database and EC2 instances
- Steps: Use EC2 instances to host a database that receives and processes orders.
- Pros: EC2 provides full control over the processing logic.
- Cons:
- Complexity: Managing EC2 instances and databases requires significant setup, scaling, and maintenance.
- Manual scaling: EC2 instances must be manually scaled or require additional tools like Auto Scaling, which adds complexity.
- Tight coupling: The EC2-based solution involves tightly coupled components, which doesn't align with the loose coupling requirement.
- Not ideal for sporadic traffic: Scaling EC2 instances in response to traffic spikes can be slow and inefficient.
This option is rejected because it introduces unnecessary complexity, manual scaling, and is not highly available by default.
Option B: Amazon SQS queue and AWS Lambda function
- Steps: Receive orders in an SQS queue, and invoke a Lambda function to process the orders.
- Pros:
- Simple: SQS and Lambda are fully managed services that require minimal setup and maintenance.
- Highly Available: Both SQS and Lambda are inherently highly available.
- Scalable: Lambda automatically scales based on the number of incoming orders, ensuring that the system can handle traffic spikes.
- Loosely Coupled: SQS decouples the order receiving process from the processing logic, making the system more resilien...
Author: Elizabeth · Last updated May 13, 2026
A company is deploying AWS Lambda functions that access an Amazon RDS for PostgreSQL database. The company needs to launch the Lambda functions in a QA environment and in a production environment.
The company must not expose credentials within...
Let's evaluate the options based on the key requirements and considerations for securely managing and rotating database credentials without exposing them in the application code:
Key Requirements:
1. No Exposure of Credentials in Application Code: The database credentials should not be stored directly within the application code.
2. Automatic Rotation of Passwords: Passwords should be rotated automatically to ensure security and compliance.
3. Separation Between QA and Production: Credentials for both the QA and production environments should be managed securely and separately.
4. Access Control: The Lambda functions should have permissions to retrieve the credentials as needed.
Evaluation of Options:
Option A: Store the credentials in AWS Systems Manager Parameter Store
- Steps: Store the database credentials in the Parameter Store, encrypted with AWS KMS. Use the AWS SDK (Boto3) in the Lambda function to pull the credentials.
- Pros:
- Encryption: Parameter Store supports encryption using AWS KMS, so credentials are stored securely.
- Access Control: Lambda functions can be granted access to specific parameters via IAM roles.
- Integration with AWS SDK: Using Boto3 to pull credentials is straightforward and works well in Lambda.
- Cons:
- Automatic Rotation: Parameter Store does not support automatic rotation of credentials. This would need to be manually managed, which is a significant disadvantage compared to AWS Secrets Manager.
- Less Suitable for Credentials Management: AWS Secrets Manager is a more specialized service for managing database credentials and provides automatic rotation out of the box.
This option is rejected because it does not provide automatic credential rotation, which is a crucial requirement.
Option B: Store the credentials in AWS Secrets Manager
- Steps: Store credentials in AWS Secrets Manager for both QA and production environments, turn on rotation, and provide references to these secrets in Lambda environment variables.
- Pros:
- Automatic Rotation: Secrets Manager supports automatic rotation of credentials, including RDS passwords.
- Secure Storage: Credentials are stored securely and can be encrypted using AWS KMS.
- Environment Separation: You can easily create separate secrets for the QA and production environments.
- Seamless Integration with Lambda: Lambda functions can access secrets using environment variables, and access permissions can be controlled via IAM.
- Cons:
- Cost: Secrets Manager incurs additional costs, although the...
Author: SilverBear · Last updated May 13, 2026
A company is using AWS Control Tower to manage AWS accounts in an organization in AWS Organizations. The company has an OU that contains accounts. The company must prevent any new or existing Amazon EC2 instances in the ...
Key Requirements:
1. Prevent EC2 instances from gaining a public IP address: The solution should ensure that neither new EC2 instances nor existing instances in the specified organizational unit (OU) can receive public IP addresses.
2. Control across multiple accounts: The solution must apply to all accounts within the OU managed by AWS Control Tower.
3. Simplicity and effectiveness: The solution should be easy to implement and manage without significant manual effort or complex configurations.
Evaluation of Options:
Option A: Use AWS Systems Manager Automation
- Steps: Configure EC2 instances in each account in the OU to use AWS Systems Manager and use a Systems Manager Automation runbook to prevent public IP addresses from being attached.
- Pros:
- Systems Manager can be used to manage instances across multiple accounts.
- Automation runbooks can apply changes in a controlled manner.
- Cons:
- Manual intervention and complexity: This option would require manual or semi-automated processes for each instance, which is not scalable. It's not an ideal solution for preventing public IP assignments at the infrastructure level.
- Lack of proactive enforcement: Systems Manager does not provide a proactive, automatic way to prevent public IP assignments during instance launch or modification.
This option is rejected due to its reliance on manual processes and lack of proactive enforcement.
Option B: Implement AWS Control Tower proactive control
- Steps: Implement an AWS Control Tower proactive control that checks whether instances have a public IP address, sets the `AssociatePublicIpAddress` property to False, and attaches the control to the OU.
- Pros:
- Proactive control: AWS Control Tower proactive controls are designed to enforce policies and best practices across AWS accounts.
- Centralized management: This option integrates directly with AWS Control Tower and applies at the OU level, making it easy to manage across accounts.
- Automation: The proactive control ensures that instances launched in the OU will not have a public IP, and it can automatically enforce this setting.
- Cons:
- AWS Control Tower’s proactive controls may not provide the exact functionality to set the `AssociatePublicIpAddress` property to false across all instances directly, depending on the available pre-configured controls. While AWS Control Tower is an excellent service for governance, specific controls like this might need custom solutions or adjustments.
This option is likely the best approach as it utilizes AWS Control Tower’s built-in governance features and proactively ensures compliance. However, it may require additional details about the exact capabilities of proactive controls to confirm if this will be fully automated for all cases.
Option C: Create an SCP (Service Control Policy)...
Author: Daniel · Last updated May 13, 2026
A company is deploying a third-party web application on AWS. The application is packaged as a Docker image. The company has deployed the Docker image as an AWS Fargate service in Amazon Elastic Container Service (Amazon ECS). An Application Load Balancer (ALB) directs traffic to the application.
The company needs to give only a specific list of users the ability to access the application from the internet. The company cannot change the appli...
To determine the best solution, let's evaluate each option and examine their suitability based on the requirements:
Option A: Amazon Cognito User Pool with MFA
- What it involves:
- Creating an Amazon Cognito User Pool to manage users.
- Configuring MFA as a requirement for users.
- Configuring the Application Load Balancer (ALB) to require authentication through the Amazon Cognito hosted UI, which will authenticate the user before allowing access to the application.
- Why it's a good fit:
- Amazon Cognito allows you to manage users and authentication directly without modifying the application. It can also enforce MFA, meeting the company's security requirement.
- The ALB can be configured to trigger the Cognito authentication flow, providing controlled access only to users in the user pool and enforcing MFA during the login process.
- Why other options are less suitable:
- Option B requires IAM authentication, which doesn't support MFA enforcement at the application level through the ALB. It would only work if the users were authenti...
Author: Siddharth · Last updated May 13, 2026
A solutions architect is preparing to deploy a new security tool into several previously unused AWS Regions. The solutions architect will deploy the tool by using an AWS CloudFormation stack set. The stack set's template contains an IAM role that has a custom name. Upon creation of the stack ...
In this scenario, the issue revolves around the deployment of an AWS CloudFormation stack set, where the stack set template contains an IAM role with a custom name, and no stack instances are created successfully. Let's evaluate the options:
Option A: Enable the new Regions in all relevant accounts. Specify the CAPABILITY_NAMED_IAM capability during the creation of the stack set.
- What this option involves:
- Enabling the relevant AWS Regions for the stack set deployment.
- Specifying the `CAPABILITY_NAMED_IAM` capability, which is required when creating or updating stacks that include IAM resources with custom names.
- Why it's a good fit:
- Enabling the AWS Regions ensures that the stack set is deployed in the newly supported regions.
- The `CAPABILITY_NAMED_IAM` capability is necessary because the template includes an IAM role with a custom name, and CloudFormation needs explicit permission to create IAM resources with specific names.
- Why it's the correct choice:
- This option addresses both the need to enable the new regions and explicitly acknowledge the creation of IAM resources with custom names, which is likely the reason the stack set isn’t deploying successfully.
Option B: Use the Service Quotas console to request a quota increase for the number of CloudFormation stacks in each new Region in all relevant accounts. Specify the CAPABILITY_IAM capability during the creation of the stack set.
- What this option involves:
- Requesting a quota increase for CloudFormation stacks.
- Specifying the `CAPABILITY_IAM` capability (needed for IAM resources but not specifically for custom names).
- Why this is less suitable:
- This option is focused on increasing the quota for CloudFormation stacks, bu...
Author: Max · Last updated May 13, 2026
A company has an application that uses an Amazon Aurora PostgreSQL DB cluster for the application's database. The DB cluster contains one small primary instance and three larger replica instances. The application runs on an AWS Lambda function. The application makes many short-lived connections to the database's replica instances to perform read-only operations.
During periods of high traffic, the application becomes unreliable and th...
To solve the issue where the application becomes unreliable during periods of high traffic due to too many connections being established to the Amazon Aurora PostgreSQL DB cluster, let’s analyze the options in detail:
Option A: Use Amazon RDS Proxy to create a proxy for the DB cluster. Configure a read-only endpoint for the proxy. Update the Lambda function to connect to the proxy endpoint.
- What this option involves:
- Amazon RDS Proxy helps manage database connections more efficiently by pooling and reusing connections, which reduces the overhead of establishing new connections frequently.
- Configuring a read-only endpoint ensures that the Lambda function connects only to the replica instances, as the application only requires read operations.
- Why this is a good fit:
- RDS Proxy helps to efficiently manage connections, which is critical for high-traffic situations where too many connections are being established.
- By using the read-only endpoint, only replica instances are used, preventing overloading the primary instance.
- It optimizes Lambda connections by allowing for connection pooling, mitigating the “too many connections” problem.
- Why other options are less suitable:
- Option B: Increasing the `max_connections` sett...
Author: Nathan · Last updated May 13, 2026
A retail company is mounting IoT sensors in all of its stores worldwide. During the manufacturing of each sensor, the company's private certificate authority (CA) issues an X.509 certificate that contains a unique serial number. The company then deploys each certificate to its respective sensor.
A solutions architect needs to give the sensors the ability to sen...
To meet the requirement where IoT sensors should not be able to send data to AWS until they are installed, and the certificates issued by a private certificate authority (CA) contain a unique serial number for each sensor, the solution must involve a mechanism for validating these serial numbers and ensuring that sensors can only communicate with AWS after installation.
Option Breakdown:
A) Create an AWS Lambda function that can validate the serial number. Create an AWS IoT Core provisioning template. Include the SerialNumber parameter in the Parameters section. Add the Lambda function as a pre-provisioning hook. During manufacturing, call the RegisterThing API operation and specify the template and parameters.
- Pros:
- This option uses AWS IoT Core provisioning templates and a Lambda function as a pre-provisioning hook. The Lambda function can validate the serial number, ensuring that only the correct sensors can be provisioned and registered in AWS.
- The use of the `RegisterThing` API during manufacturing ensures that the sensors are not provisioned or allowed to send data until they are installed, as the validation check can be done at provisioning time.
- Cons:
- While it addresses the need for serial number validation during provisioning, it doesn’t provide a clear separation between manufacturing and installation, which is the core requirement for preventing the sensors from sending data until installation.
B) Create an AWS Step Functions state machine that can validate the serial number. Create an AWS IoT Core provisioning template. Include the SerialNumber parameter in the Parameters section. Specify the Step Functions state machine to validate parameters. Call the StartThingRegistrationTask API operation during installation.
- Pros:
- AWS Step Functions can manage a more complex workflow for validating serial numbers and initiating provisioning tasks.
- Cons:
- The use of AWS Step Functions adds unnecessary complexity to the solution. The Step Functions workflow isn't needed to validate the serial number and can make the solution more difficult to implement and maintain. Furthermore, the solution involves calling the `StartThingRegistrationTask` during installation, but the problem is specifically about preventing data submission until installation, and this approach is indirect for that requirement.
C) Create an AWS Lambda function...
Author: Aarav2020 · Last updated May 13, 2026
A startup company recently migrated a large ecommerce website to AWS. The website has experienced a 70% increase in sales. Software engineers are using a private GitHub repository to manage code. The DevOps team is using Jenkins for builds and unit testing. The engineers need to receive notifications for bad builds and zero downtime during deployments. The engineers also need to ensure any changes to production are seamless for users and can be roll...
The company's needs include ensuring notifications for bad builds, zero downtime during deployments, and the ability to roll back changes in production seamlessly. They are looking to use AWS CodePipeline for the build and deployment process. Let's evaluate the options based on these criteria:
Option A: Use GitHub websockets to trigger the CodePipeline pipeline. Use the Jenkins plugin for AWS CodeBuild to conduct unit testing. Send alerts to an Amazon SNS topic for any bad builds. Deploy in an in-place, all-at-once deployment configuration using AWS CodeDeploy.
- What this option involves:
- GitHub websockets: This is an incorrect choice. GitHub webhooks are typically used to trigger events in AWS CodePipeline, not websockets.
- Jenkins plugin for AWS CodeBuild: This allows Jenkins to trigger AWS CodeBuild for unit testing.
- In-place, all-at-once deployment with AWS CodeDeploy: This deployment configuration means the entire application is updated at once, leading to potential downtime during the deployment process. This violates the requirement for zero downtime.
- Why it's rejected:
- The use of websockets is not the best way to trigger pipelines from GitHub. Webhooks are more appropriate.
- All-at-once deployment can lead to downtime and is not suitable for seamless deployments, especially for production systems that need high availability.
Option B: Use GitHub webhooks to trigger the CodePipeline pipeline. Use the Jenkins plugin for AWS CodeBuild to conduct unit testing. Send alerts to an Amazon SNS topic for any bad builds. Deploy in a blue/green deployment using AWS CodeDeploy.
- What this option involves:
- GitHub webhooks: Correct choice for triggering AWS CodePipeline from GitHub.
- Jenkins plugin for AWS CodeBuild: Correct for running unit tests during the build phase.
- Blue/green deployment with AWS CodeDeploy: This deployment method ensures zero downtime during the deployment process. It involves creating two identical environments (blue and green). Traffic is routed to the green environment, and if issues arise, it can be switched back to the blue environment, enabling a quick rollback.
- Why it's the best fit:
- Blue/green deployment provid...
Author: Leo · Last updated May 13, 2026
A software as a service (SaaS) company has developed a multi-tenant environment. The company uses Amazon DynamoDB tables that the tenants share for the storage layer. The company uses AWS Lambda functions for the application services.
The company wants to offer a tiered subscription model that is based on resource consumption by each tenant. Each tenant is identified by a unique tenant ID that is sent as part of each request to the Lambda functions. The company has created an AWS Cost and Usage Report (AWS CUR) in an AWS accoun...
To solve this problem, we need to focus on a solution that provides a granular view of DynamoDB costs per tet with the least operational effort, leveraging AWS-native tools efficiently. The goal is to allocate DynamoDB costs to each tet based on resource consumption with minimal management overhead. Let’s evaluate each option.
Option A: Associate a new tag that is named tet ID with each table in DynamoDB. Activate the tag as a cost allocation tag in the AWS Billing and Cost Management console. Deploy new Lambda function code to log the tet ID in Amazon CloudWatch Logs. Use the AWS CUR to separate DynamoDB consumption cost for each tet ID.
- Pros:
- Using tags for resource tracking is a native AWS feature and integrates well with AWS billing.
- The AWS CUR already provides detailed cost data, and by enabling cost allocation tags, you can easily separate DynamoDB costs per tet.
- Minimal operational effort after the initial setup since the tags are applied to DynamoDB tables and cost data is automatically reported.
- No additional Lambda functions are needed for calculation; AWS billing takes care of that.
- Cons:
- You need to ensure that the tet ID is captured consistently as part of each request, which may require Lambda updates.
- The granularity may not include specific consumption metrics (e.g., read/write capacity units) but will provide cost data tied to the tag.
Option B: Configure the Lambda functions to log the tet ID and the number of RCUs and WCUs consumed from DynamoDB for each transaction to Amazon CloudWatch Logs. Deploy another Lambda function to calculate the tet costs by using the logged capacity units and the overall DynamoDB cost from the AWS Cost Explorer API. Create an Amazon EventBridge rule to invoke the calculation Lambda function on a schedule.
- Pros:
- Tracks actual consumption of RCUs and WCUs per tet, allowing for detailed resource usage tracking.
- Provides flexibility by using CloudWatch Logs and the AWS Cost Explorer API.
- More granular resource tracking than option A.
- Cons:
- Higher operational effort: involves custom Lambda functions, logging, and scheduled invocations.
- Requires manual calculation and maintenance of the tet cost calculation, which adds complexity.
- Requires careful setup of EventBridge rules to manage function schedules.
Option C: Create a new partition key that associates DynamoDB items with individual tets. Deploy a Lambda function to populate the new column as part of each transaction. Depl...
Author: Elijah · Last updated May 13, 2026
A company has an application that stores data in a single Amazon S3 bucket. The company must keep all data for 1 year. The company's security team is concerned that an attacker could gain access to the AWS account through leaked long-term cre...
To address the concern about protecting data in the S3 bucket from potential security breaches while ensuring that all data is retained for 1 year, the solution should provide robust data protection, versioning, and safeguards against unauthorized access. Let's analyze each option and determine the most appropriate one.
Option A: Create a new AWS account that is accessible only to the security team through an assumed role. Create an S3 bucket in the new account. Enable S3 Versioning and S3 Object Lock. Configure a default retention period of 1 year. Set up replication from the existing S3 bucket to the new S3 bucket. Create an S3 Batch Replication job to copy all existing data.
- Pros:
- S3 Object Locking and Versioning will ensure that objects cannot be deleted or modified during the retention period.
- S3 replication can safeguard against potential compromises of the original bucket.
- The creation of a new account for the security team adds an additional layer of protection by isolating access to the S3 bucket from the main account.
- Cons:
- Complexity: Setting up a new account, replicating data, and managing replication jobs can add operational complexity.
- Cost: Maintaining a new account and the replication of data could increase costs.
- This solution doesn't address the main concern of securing the data within the current S3 bucket but rather replicates it to a different account, which introduces complexity without directly securing the original bucket.
Option B: Use the s3-bucket-versioning-enabled AWS Config managed rule. Configure an automatic remediation action that uses an AWS Lambda function to enable S3 Versioning and MFA Delete on noncompliant resources. Add an S3 Lifecycle rule to delete objects after 1 year.
- Pros:
- The AWS Config managed rule ensures that versioning is enabled on the S3 bucket and can remediate any compliance violations automatically.
- MFA Delete adds an extra layer of protection against accidental or malicious deletions.
- Using S3 Lifecycle rules to delete objects after 1 year ensures compliance with the retention requirement.
- Cons:
- The focus is on remediating noncompliant resources, but it does not explicitly lock down data for the specified retention period. S3 Object Lock would provide stronger protection than just versioning and MFA Delete.
- MFA Delete requires a high level of manual intervention to set up and manage, as MFA Delete needs to be enabled with root account access.
- This option does not explicitly address securing data in the event of compromised credentials or more complex threat scenarios.
Option C: ...
Author: Mia · Last updated May 13, 2026
A company needs to improve the security of its web-based application on AWS. The application uses Amazon CloudFront with two custom origins. The first custom origin routes requests to an Amazon API Gateway HTTP API. The second custom origin routes traffic to an Application Load Balancer (ALB). The application integrates with an OpenID Connect (OIDC) identity provider (IdP) for user management.
A security audit shows that a JSON Web Token (JWT) authorizer provides access to the API. The security audit also shows ...
Key Factors for Evaluation:
1. Security Enforcement: The solution must ensure that only authenticated users can access both the API and the ALB.
2. Authentication Integration: The solution needs to integrate with the existing OpenID Connect (OIDC) identity provider (IdP) and JWT-based authentication.
3. Minimal Operational Overhead: The solution should require minimal custom management, especially in monitoring and blocking unauthenticated requests.
4. Scalability and Simplicity: The solution should scale easily with minimal operational complexity and should not require custom log analysis or complex configurations.
Evaluation of Each Option:
Option A: Configure the ALB to enforce authentication and authorization by integrating the ALB with the IdP
- Advantages:
- Direct Authentication Enforcement: This directly addresses the security issue by ensuring that only authenticated users can access the backend services through the ALB. Integrating with the IdP ensures that authentication and authorization are handled securely.
- Built-In Support: AWS ALB supports integrating with OIDC and other identity providers for user authentication, so this can be managed natively within the AWS environment.
- Disadvantages:
- No Additional Layers of Security: This method directly addresses the problem but may not apply any fine-grained authorization rules that might be needed beyond authentication alone.
- Reasoning: This is the most straightforward and secure solution. It enforces authentication at the ALB level, ensuring that only authenticated users can access backend services, and it integrates well with the existing OIDC setup.
Option B: Modify the CloudFront configuration to use signed URLs
- Advantages:
- Signed URLs Provide Security: Signed URLs can prevent unauthorized users from accessing CloudFront-distributed content by requiring a valid signature for access.
- Disadvantages:
- Not Addressing ALB Security: This solution only addresses the CloudFront distribution and not the ALB. It does not ensure that unauthenticated requests are blocked at the ALB, which remains a vulnerability.
- Complexity in Management: Managing signed URLs can add significant complexity, especially as it scales. Every request needs to be signed, and it may not be a suitable long-term solution.
- Reasoning: While this can secure CloudFront, it doesn't address the core issue of unauthenticated access to the ALB. It's a partial solution, not an overall one.
Option C: Cre...
Author: Andrew · Last updated May 13, 2026
A company creates an AWS Control Tower landing zone to manage and govern a multi-account AWS environment. The company's security team will deploy preventive controls and detective controls to monitor AWS services across all the accounts. The security team nee...
Key Factors for Evaluation:
1. Centralized View: The solution must provide a centralized way to monitor the security state across multiple accounts.
2. Preventive and Detective Controls: The solution should allow both preventive and detective controls to be deployed across all accounts.
3. Integration with Existing AWS Control Tower: The solution should integrate smoothly into the AWS Control Tower environment and align with its governance framework.
4. Scalability: The solution should scale effectively across multiple accounts without adding significant operational overhead.
Evaluation of Each Option:
Option A: Use AWS CloudFormation StackSets to deploy an AWS Config conformance pack to all accounts in the organization
- Advantages:
- AWS Config Conformance Packs: This option allows you to deploy predefined security controls across accounts. AWS Config is designed for continuous monitoring of AWS resources to ensure compliance.
- Centralized Compliance View: AWS Config provides a centralized view of compliance with custom conformance packs.
- Disadvantages:
- Preventive Control Focus: While AWS Config conformance packs focus on compliance and preventive controls, they don’t directly provide centralized detective monitoring of security events or threats.
- Limited Detective Capabilities: This option does not focus on real-time monitoring of security incidents or threats. AWS Config is more focused on configuration compliance rather than detecting security issues or violations actively.
- Reasoning: This solution is good for compliance monitoring and preventive controls but lacks a robust detective monitoring mechanism. It doesn't fully meet the requirement of providing a comprehensive view of the security state in real-time.
Option B: Enable Amazon Detective for the organization in AWS Organizations and designate one AWS account as the delegated administrator
- Advantages:
- Centralized Threat Investigation: Amazon Detective provides security teams with tools to investigate and analyze potential security threats in real-time, which helps detect suspicious activity.
- Detective Control: This option addresses the detective aspect of the security controls by providing deep insights into security incidents across multiple accounts.
- Disadvantages:
- Not a Comprehensive Centralized View: While Amazon Detective provides valuable insights into security investigations, it doesn’t provide a full, centralized view of all security aspects (including configuration, compliance, etc.) across the entire organization.
- Limited to Threat Detection: Amazon Detective is focused on investigation rather than broad security management, compliance, or preventive controls.
- Reasoning: Amazon Detective is an importa...
Author: Ishaan · Last updated May 13, 2026
A company that develops consumer electronics with offices in Europe and Asia has 60 TB of software images stored on premises in Europe. The company wants to transfer the images to an Amazon S3 bucket in the ap-northeast-1 Region. New software images are created daily and must be encrypted in transit. The company needs a solution that does not req...
Key Factors for Evaluation:
1. Encryption in Transit: The images must be encrypted during the transfer process.
2. Automatic Transfer of New and Existing Data: The solution must be automated to handle both existing data (60 TB) and daily updates (new images created daily).
3. No Custom Development: The solution must not require custom development, ensuring ease of use and minimal operational overhead.
4. Efficiency and Scalability: The solution should handle large data volumes efficiently and scale for future growth.
5. Low Complexity: The solution should be simple to deploy and manage without complex setup or maintenance.
Evaluation of Each Option:
Option A: Deploy an AWS DataSync agent and configure a task to transfer the images to the S3 bucket
- Advantages:
- Automated Transfer: AWS DataSync is designed for transferring large amounts of data between on-premises storage and AWS services, including Amazon S3, with minimal configuration. DataSync can be configured to transfer both existing data (60 TB) and new images created daily.
- Encryption in Transit: DataSync supports encryption in transit, ensuring that the data is securely transferred.
- Efficient Transfer: DataSync is optimized for large data migrations and incremental updates, ensuring that daily software image updates are automatically transferred.
- Disadvantages:
- Setup Required: While the setup involves configuring an agent and task, AWS DataSync is a managed service designed to simplify the process, requiring no custom development.
- Reasoning: This is the most suitable solution as it meets all the requirements: automated transfer of existing and new images, encrypted transfer, and no need for custom development. It is designed for large-scale transfers and integrates well with S3.
Option B: Configure Amazon Kinesis Data Firehose to transfer the images using S3 Transfer Acceleration
- Advantages:
- Transfer Speed: Kinesis Data Firehose can accelerate the transfer of data using S3 Transfer Acceleration.
- Disadvantages:
- Not Suitable for Large Files: Kinesis Data Firehose is designed for streaming data and might not be ideal for bulk transfer of large files (like 60 TB of software images) in a non-streaming manner.
- Complexity for Bulk Data: While it can handle real-time streaming, it is not a great fit for a bulk transfer of static data like images that need to be moved in bulk and incrementally over time.
- Encryption: Although Kinesis provides encryption options, it doesn’t natively encrypt files in transit in the same way as DataSync, and it may require more...
Author: Mia · Last updated May 13, 2026
A company has a web application that uses Amazon API Gateway. AWS Lambda, and Amazon DynamoDB. A recent marketing campaign has increased demand. Monitoring software reports that many requests have significantly longer response times than before the marketing campaign.
A solutions architect enabled Amazon CloudWatch Logs for API Gateway and noticed that errors are occurring on 20% of the requests. In CloudWatch, the Lambda function Throttles metric represents 1% of the requests and the Errors metric represents 10% of t...
To improve the response times for the web application as demand increases, the solutions architect needs to address the cause of the errors and long response times. Based on the provided details, errors occur when there is a call to DynamoDB, and these errors could be contributing to the slow response times. Let's review each option:
A) Increase the concurrency limit of the Lambda function.
- Reasoning: The Lambda Throttles metric indicates that only 1% of requests are throttled. This is a relatively low number, so increasing the concurrency limit would likely not resolve the root cause of the problem. Throttling is not the primary issue here; errors related to DynamoDB are more concerning.
- Conclusion: Increasing Lambda concurrency is not the most relevant option in this case since the bottleneck seems to be related to DynamoDB rather than Lambda itself.
B) Implement DynamoDB auto scaling on the table.
- Reasoning: The errors in the application logs are tied to calls to DynamoDB, which suggests that the table may be hitting throughput limits, especially during increased demand. DynamoDB auto scaling can automatically adjust the provisioned read and write capacity of the table to meet fluctuating traffic demands, reducing the likelihood of throttling errors in DynamoDB.
- Conclusion: This option directly addresses the issue with DynamoDB, where capacity could be exceeded under high load, leading to errors and slow responses. It allows the system to handle increased demand dynamically.
C) Increase the API Gateway throttle ...
Author: Emily · Last updated May 13, 2026
A company has an application that has a web frontend. The application runs in the company's on-premises data center and requires access to file storage for critical data. The application runs on three Linux VMs for redundancy. The architecture includes a load balancer with HTTP request-based routing.
The company needs to migrate the application to AWS as quick...
Let's review the options in detail to determine the most suitable solution for migrating the on-premises application to AWS with minimal changes while meeting the need for high availability.
A) Migrate the application to Amazon Elastic Container Service (Amazon ECS) containers that use the Fargate launch type in three Availability Zones. Use Amazon S3 to provide file storage for all three containers. Use a Network Load Balancer to direct traffic to the containers.
- Reasoning: ECS with Fargate allows you to deploy and manage containers without managing the underlying EC2 instances. While S3 is a scalable object storage service, it is not ideal for scenarios that require low-latency file system access, such as file storage used by a traditional application. The use of a Network Load Balancer (NLB) is typically for TCP traffic, not HTTP-based routing, and may not be suitable for handling the application's routing logic, which seems to be HTTP-based.
- Conclusion: While this solution involves containers and is highly scalable, using S3 and NLB doesn’t align with the requirements for low-latency file storage and HTTP-based load balancing.
B) Migrate the application to Amazon EC2 instances in three Availability Zones. Use Amazon Elastic File System (Amazon EFS) for file storage. Mount the file storage on all three EC2 instances. Use an Application Load Balancer to direct traffic to the EC2 instances.
- Reasoning: This solution closely matches the existing architecture of the on-premises system with minimal changes. By using EC2 instances across three Availability Zones, you achieve high availability. Amazon EFS is a fully managed file system that works well for shared file storage, which can be mounted across multiple EC2 instances. Application Load Balancer (ALB) is perfect for HTTP-based routing. This solution also provides automatic scaling and redundancy.
- Conclusion: This is the simplest and most straightforward solution with the fewest changes to the existing architecture. It maintains the use of VMs (via EC2), supports high availability, and provides suitable file storage with EFS.
C) Migrate the application to Amazon Elastic Kubernetes Service (Amazon EKS) containers that use the Fargate launch typ...
Author: Ella · Last updated May 13, 2026
A company is planning to migrate an on-premises data center to AWS. The company currently hosts the data center on Linux-based VMware VMs. A solutions architect must collect information about network dependencies between the VMs. The information must be in the form of a diagram that...
To select the best solution, let's analyze the options based on the requirement of collecting information about network dependencies between the VMs, including host IP addresses, hostnames, and network connections in a diagram format.
A) Use AWS Application Discovery Service. Select an AWS Migration Hub home AWS Region. Install the AWS Application Discovery Agent on the on-premises servers for data collection. Grant permissions to Application Discovery Service to use the Migration Hub network diagrams.
- Reasoning: AWS Application Discovery Service provides detailed information about on-premises applications and their dependencies, including network dependencies. By installing the Discovery Agent on the on-premises servers, the service can gather data about the VMs, such as IP addresses, hostnames, and network connection information. The network diagram can be accessed from the Migration Hub and visualized. This solution aligns well with the requirement of collecting network information and generating a diagram.
- Conclusion: This solution is a strong candidate because it utilizes the correct AWS services to collect and visualize network dependency data.
B) Use the AWS Application Discovery Service Agentless Collector for server data collection. Export the network diagrams from the AWS Migration Hub in .png format.
- Reasoning: The Agentless Collector gathers server information without the need to install agents on the VMs, but it may not provide as detailed network dependency information as the agent-based method. The network diagrams generated can be exported in a .png format, which provides a visual representation of network connections. However, this method may have limitations in capturing specific network details and IP address-level granularity compared to the agent-based approach.
- Conclusion: This solution is viable but might lack the level of detail needed (especially around IP addresses and hostnames) compared to using the Discovery Agent.
C) Install the AWS Application Migration Service agent on the on-premises servers for data coll...
Author: Benjamin · Last updated May 13, 2026
A company runs a software-as-a-service (SaaS) application on AWS. The application consists of AWS Lambda functions and an Amazon RDS for MySQL Multi-AZ database. During market events, the application has a much higher workload than normal. Users notice slow response times during the peak periods because of many database conn...
To meet the requirements of improving the scalable performance and availability of the database while addressing high database connections during peak workloads, let's review each option in detail.
A) Create an Amazon CloudWatch alarm action that triggers a Lambda function to add an Amazon RDS for MySQL read replica when resource utilization hits a threshold.
- Reasoning: While adding a read replica can help offload read traffic and improve scalability, creating an automated process via CloudWatch alarms to trigger the creation of a read replica may not be fast enough to address the immediate scaling needs during peak times. Also, adding a read replica dynamically during high traffic periods may introduce additional complexity and delays. This solution doesn't directly address the connection management issue.
- Conclusion: This option doesn't fully solve the issue because it focuses on scaling read replicas dynamically, which can be slow and doesn't tackle the root cause of high database connection usage.
B) Migrate the database to Amazon Aurora, and add a read replica. Add a database connection pool outside of the Lambda handler function.
- Reasoning: Migrating to Amazon Aurora is a good choice because it offers better scalability, performance, and high availability compared to RDS for MySQL. Adding a read replica improves scalability by offloading read operations. Implementing a connection pool outside of the Lambda function helps to reuse database connections efficiently, reducing the overhead caused by Lambda's frequent cold starts and database connection creation.
- Conclusion: This is a valid solution because it combines Aurora's scaling benefits with the database connection pooling to improve performance. However, it lacks automatic connection management at the database level.
C) Migrate the database to Amazon Aurora, and add a read replica. Use Amazon...
Author: Sofia2021 · Last updated May 13, 2026
A company is planning to migrate an application from on premises to the AWS Cloud. The company will begin the migration by moving the application's underlying data storage to AWS. The application data is stored on a shared file system on premises, and the application servers connect to the shared file system through SMB.
A solutions architect must implement a solution that uses an Amazon S3 bucket for shared storage. Until the application is fully migrated and code is rewritten to use native Amazon S3 APIs, the application must continue to h...
Let's break down each option based on the requirements: the need to migrate application data to Amazon S3 while still providing access via SMB for the application to function without requiring code changes immediately.
A) Create a new Amazon FSx for Windows File Server file system. Configure AWS DataSync with one location for the on-premises file share and one location for the new Amazon FSx file system. Create a new DataSync task to copy the data from the on-premises file share location to the Amazon FSx file system.
- Reasoning: Amazon FSx for Windows File Server supports SMB and would allow the application to continue using SMB for file access. AWS DataSync could be used to efficiently migrate data from on-premises to the Amazon FSx file system. This solution allows the application to keep using SMB during the transition without requiring changes to the application.
- Conclusion: This is a good solution because it allows the migration of data while maintaining SMB access. It uses a fully managed service (FSx) that provides the needed file system with SMB support and handles data migration with DataSync.
B) Create an S3 bucket for the application. Copy the data from the on-premises storage to the S3 bucket.
- Reasoning: Amazon S3 is an object storage service, not a file system. It doesn’t support SMB directly, which is the protocol the application currently uses to access data. While S3 is the destination, this option doesn't satisfy the requirement to allow the application to continue accessing data via SMB.
- Conclusion: This option doesn't work because the application cannot access S3 through SMB without additional infrastructure, and rewriting the application to use S3 APIs is a longer-term effort.
C) Deploy an AWS Server Migration Service (AWS SMS) VM to the on-premises environment. Use AWS SMS to migrate the file storage server from on-premises to an Amazon EC2 instance.
- Reasoning: AWS Server Migration Service (SMS)...
Author: NebulaEagle11 · Last updated May 13, 2026
A global company has a mobile app that displays ticket barcodes. Customers use the tickets on the mobile app to attend live events. Event scanners read the ticket barcodes and call a backend API to validate the barcode data against data in a database. After the barcode is scanned, the backend logic writes to the database's single table to mark the barcode as used.
The company needs to deploy the app on AWS wi...
To determine the best solution for meeting the low-latency requirement for a global mobile app, we must consider several key factors, including data consistency, proximity to users, infrastructure complexity, and AWS services' capabilities. Here's an analysis of the options:
Option A:
- Database: Amazon Aurora Global Database clusters provide cross-region replication and allow for low-latency reads and writes in multiple AWS Regions, making it ideal for global applications requiring consistent and low-latency access to data.
- Backend: Hosting the backend on Amazon ECS (Elastic Container Service) clusters in the same Regions as the database ensures that backend services are close to the database, reducing latency for database queries.
- Routing: Using AWS Global Accelerator helps route requests to the nearest ECS cluster, providing low-latency access and automatic fault tolerance.
- Route 53: Directs traffic to the Global Accelerator, which then routes the requests to the nearest ECS cluster.
Pros:
- Global low-latency access to both the database and the backend.
- Global Accelerator optimizes routing and minimizes latency by sending traffic to the nearest region.
- Amazon ECS is a managed service with good integration into the AWS ecosystem.
Cons:
- The backend is in ECS, which may require more management compared to serverless alternatives like Lambda.
- Complexity in managing ECS clusters and ensuring scalability.
Option B:
- Database: Amazon Aurora Global Database clusters, as in Option A, providing cross-region replication for low-latency reads and writes.
- Backend: Using Amazon EKS (Elastic Kubernetes Service) instead of ECS allows for more advanced container orchestration and scalability. However, Kubernetes comes with increased operational complexity.
- Routing: CloudFront routes requests to the nearest EKS cluster. CloudFront is a content delivery network (CDN), which may not be ideal for dynamic backend API calls, as it typically caches static content rather than routing API requests efficiently.
- Route 53: Directs traffic to the CloudFront distribution.
Pros:
- Amazon Aurora Global Database provides excellent low-latency reads and writes.
- Kubernetes provides more fine-grained control and scalability over containers.
Cons:
- CloudFront is more suited for static content delivery than dynamic API requests. This could lead to unnecessary caching or routing delays for real-time API requests.
- Kubernetes adds operational complexity, especially in terms ...
Author: MysticJaguar44 · Last updated May 13, 2026
A medical company is running a REST API on a set of Amazon EC2 instances. The EC2 instances run in an Auto Scaling group behind an Application Load Balancer (ALB). The ALB runs in three public subnets, and the EC2 instances run in three private subnets. The company has deployed an Amazon CloudFront distri...
In this scenario, the goal is to enhance the security of the origin (the ALB) while allowing CloudFront to continue serving as the CDN. The focus should be on protecting the ALB from unauthorized access, ensuring that only CloudFront requests can reach the ALB and securing communication between CloudFront and the origin.
Let's evaluate the options:
Option A: Use Secrets Manager + Lambda for Secret Rotation + WAF
- Secrets Manager: Storing a random string in Secrets Manager and rotating it automatically with Lambda is a good way to manage credentials.
- CloudFront Custom Header: CloudFront would inject this string as a custom header in its requests to the ALB, which could then be validated using AWS WAF to ensure only authorized requests from CloudFront are allowed.
- WAF String Match Rule: This rule could inspect the custom header and block requests that don’t have the correct header.
- Pros: This adds a dynamic layer of security by ensuring that only CloudFront (which can include the secret string in the header) can access the ALB.
- Cons: This solution introduces additional complexity, as it requires the Lambda function for rotation and managing secrets securely in Secrets Manager.
Option B: WAF with IP Match Condition of CloudFront Service IPs + ALB in Private Subnets
- WAF with IP Match: This solution configures WAF to allow only IP addresses from CloudFront to access the ALB. CloudFront IP ranges are well-documented, and this rule could block unauthorized traffic.
- ALB in Private Subnets: Moving the ALB to private subnets enhances security by ensuring that the ALB isn't publicly accessible directly.
- Pros: Using WAF with CloudFront IP ranges ensures that only traffic from CloudFront is allowed to reach the ALB. Moving the ALB into private subnets minimizes exposure.
- Cons: This option is a little more restrictive and might require additional network configurations. Moving the ALB to private subnets adds complexity, especially when combined with CloudFront.
Option C: Store String in Parameter Store + CloudFront Custom Header + ALB Blocking Access
- Systems Manager Parameter Store: This is a viable alternative to Secrets Manager for storing the random string. It can be automatically rotated, just like Secrets Manager.
- CloudFront Custom Header: Similar to Option A, CloudFront can inject the string as a custom header, which the ALB would inspect.
- ALB ...
Author: Deepak · Last updated May 13, 2026
To abide by industry regulations, a solutions architect must design a solution that will store a company's critical data in multiple public AWS Regions, including in the United States, where the company's headquarters is located. The solutions architect is required to provide access to the data stored in AWS to the company's global WAN network. The security team mandates that no traffic accessing...
Key Considerations:
1. Security: No traffic should traverse the public internet, meaning traffic needs to stay within the AWS private network or the company's private WAN.
2. Highly Available: The solution must be able to withstand failures and provide resilience, ensuring continuous access to the data across AWS Regions.
3. Cost-Effectiveness: The solution should balance the cost of setup and maintenance while meeting the technical and regulatory requirements.
4. Access to Multiple AWS Regions: The company must be able to access data across multiple AWS Regions from its global WAN.
Option A: Direct Connect to All AWS Regions with WAN Access
- Direct Connect to All AWS Regions: This option proposes establishing AWS Direct Connect (DX) connections from the headquarters to every AWS Region used, allowing access to the data stored in each Region.
- Traffic via the WAN: The company’s WAN network will route traffic over DX connections, ensuring no public internet traffic is used.
- Pros: This solution guarantees secure and private connections to all Regions via Direct Connect, ensuring that no traffic crosses the public internet.
- Cons: Establishing DX connections to every AWS Region can be costly and complex, especially as the company scales or adds new Regions. The network setup becomes more complicated with each additional connection to new Regions.
Option B: Direct Connect to One AWS Region + Inter-Region VPC Peering
- Direct Connect to One Region: This option suggests establishing two DX connections to a single AWS Region and then using inter-region VPC peering to access data in other Regions.
- Inter-region VPC Peering: Inter-region VPC peering allows communication between VPCs in different Regions, but it may introduce latency or reliability concerns, especially as the company adds more Regions.
- Pros: More cost-effective than Option A because it only requires DX connections to one Region. Inter-region VPC peering is relatively simple to set up.
- Cons: Inter-region VPC peering introduces potential network overhead and can lead to complexity in managing network routes. It also might not offer the best performance or reliability across Regions.
Option C: Direct Connect to One AWS Region + Transit VPC
- Direct Connect to One Region: This option also involves two DX connections to one Region, but it proposes using a Transit VPC solution to facilitate cross-region communication.
- Transit VPC: A Transit VPC allows routing traffic between multiple VPCs in different Regions, provi...
Author: Layla · Last updated May 13, 2026
A company has developed an application that is running Windows Server on VMware vSphere VMs that the company hosts on premises. The application data is stored in a proprietary format that must be read through the application. The company manually provisioned the servers and the application.
As part of its disaster recovery plan, the company wants the ability to host its application on AWS temporarily if the company's on-premises environment becomes unavailable. The company wan...
Key Considerations:
1. Disaster Recovery (DR) Requirements: The solution must ensure that the application can be quickly launched in AWS if the on-premises environment becomes unavailable, and then it must be able to return to the on-premises environment after the disaster recovery event.
2. Recovery Point Objective (RPO): The RPO is 5 minutes, meaning data replication must happen at least every 5 minutes to ensure minimal data loss.
3. Operational Overhead: The solution should minimize the manual effort and complexity involved in provisioning and managing the infrastructure, especially when failover or failback occurs.
4. Proprietary Application and Data: The application runs on Windows Server VMs, and the data is stored in a proprietary format that must be accessed through the application itself. This means that using a standard file-based solution might not suffice.
Evaluation of Each Option:
Option A: AWS DataSync to Amazon EBS Volumes
- AWS DataSync: This service can help transfer data to Amazon EBS, but it does not support the ongoing replication needed to meet the 5-minute RPO requirement without a more complex setup.
- Manual Provisioning with CloudFormation: Once the environment is unavailable, this solution requires manually provisioning EC2 instances using AWS CloudFormation templates, which introduces significant operational overhead.
- Pros: DataSync can efficiently transfer data to EBS volumes, and CloudFormation simplifies provisioning.
- Cons: DataSync is not designed to continuously replicate data at the required RPO of 5 minutes, and manual provisioning increases operational complexity. This does not provide the seamless recovery experience needed.
Option B: AWS Elastic Disaster Recovery (AWS DRS)
- AWS Elastic Disaster Recovery: This service is specifically designed for disaster recovery scenarios, providing near-zero RPO and RTO (Recovery Time Objective). It continuously replicates the source environment (in this case, VMware on-premises VMs) to AWS, ensuring that data and VM states are kept in sync with minimal latency.
- Replicated EC2 Instances: AWS DRS automatically provisions EC2 instances using the replicated data and EBS volumes when the on-premises environment becomes unavailable.
- Pros:
- Meets the 5-minute RPO requirement with continuous replication.
- Simple failover process without requiring manual intervention.
- Supports the full VM-based environment, which is critical for the proprietary application and its specific data format.
- Cons: AWS DRS incurs additional costs for continuous replication and recovery, but it is designed ...
Author: Benjamin · Last updated May 13, 2026
A company runs a highly available data collection application on Amazon EC2 in the eu-north-1 Region. The application collects data from end-user devices and writes records to an Amazon Kinesis data stream and a set of AWS Lambda functions that process the records. The company persists the output of the record processing to an Amazon S3 bucket in eu-north-1. The company uses the data in the S3 bucket as a data source for Amazon Athena.
The company wants to increase its global presence. A solutions architect must launch the data collection capabilities in the sa-east-1 and ap-northeast-1 Regions. The solutions architect deploys the application, the Kinesis data stream, and the Lambda functions in the two new Regions. T...
Key Considerations:
- Latency: The issue at hand is the lag time when data arrives from the new Regions (sa-east-1 and ap-northeast-1) to the S3 bucket in eu-north-1. This means data is being processed in these Regions and uploaded to S3 in eu-north-1, but the time taken for this data transfer is significant.
- Data Centralization: The company wants to centralize the data analysis, so the data must ultimately reside in S3 in eu-north-1.
- Performance Optimization: The solution must minimize the lag in data transfer from the two new Regions to the S3 bucket while respecting the requirement of centralization in eu-north-1.
Evaluation of Options:
Option A: Lambda Functions in a VPC with S3 Gateway Endpoint
- Lambda in VPC: Running Lambda in a VPC and using an S3 Gateway endpoint can enhance the security and efficiency of accessing S3 from within the VPC, but this setup does not address the core problem of cross-region latency. The network latency between the Regions will still persist when the data is uploaded from sa-east-1 and ap-northeast-1 to S3 in eu-north-1.
- Pros: Useful for securing Lambda functions’ access to S3 in a private network.
- Cons: Does not solve cross-region latency, so it would not significantly improve the lag time observed in this setup.
Option B: Turn on S3 Transfer Acceleration
- S3 Transfer Acceleration: This feature speeds up the upload of data to S3 by using Amazon CloudFront’s globally distributed edge locations. It helps to reduce latency when transferring large objects to S3 from geographically distant locations.
- Pros: This can significantly reduce the lag time for uploading data to the S3 bucket, especially from Regions far from eu-north-1.
- Cons: Transfer acceleration can improve upload speeds, but it increases costs, and it doesn’t address any issues related to how Lambda processes and pushes data. Not as effective for continuous data streams from multiple Regions, particularly if the data is coming in small, frequent batches (which is typical for streaming data).
Option C: S3 Bucket in Each Region with Cross-Region Replication
- S3 Bucket per Region: Creating an S3 bucket in each of the new Regions (sa-east-1 and ap-northeast-1) and using S3 Cross-Region Replication to replicate the data to the central S3 bucket in eu-north...
Author: Emma · Last updated May 13, 2026
A company provides a centralized Amazon EC2 application hosted in a single shared VPC. The centralized application must be accessible from client applications running in the VPCs of other business units. The centralized application front end is configured with a Network Load Balancer (NLB) for scalability.
Up to 10 business unit VPCs will need to be connected to the shared VPC. Some of the business unit VPC CIDR blocks overlap with the shared VPC, and some overlap with each other Network connectivity to the centralized application in the shared VPC should b...
Let's analyze the options in detail:
A) Create an AWS Transit Gateway. Attach the shared VPC and the authorized business unit VPCs to the transit gateway. Create a single transit gateway route table and associate it with all of the attached VPCs. Allow automatic propagation of routes from the attachments into the route table. Configure VPC routing tables to send traffic to the transit gateway.
- Pros:
- Scalable and Centralized: AWS Transit Gateway is designed to handle large-scale, centralized connectivity. You can attach up to 5,000 VPCs to a single Transit Gateway, which makes it highly scalable for your use case where up to 10 VPCs need to be connected.
- Flexible Routing: It allows you to have fine-grained control over routing policies, and you can limit which VPCs can communicate with others.
- Overlapping CIDR Handling: Transit Gateway supports VPCs with overlapping CIDR blocks through route table configuration and policy-based routing.
- Security and Control: You can restrict traffic based on the Transit Gateway route table and apply security policies on specific VPC attachments.
- Cons:
- Cost: Transit Gateway can become expensive depending on the scale (especially if there are many VPCs or large data transfer volumes), but it's a highly reliable and scalable solution.
- Conclusion: This is a good option for connecting multiple VPCs, especially in cases where you have VPCs with overlapping CIDR blocks. It provides scalable, secure, and centralized connectivity with robust routing controls.
B) Create a VPC endpoint service using the centralized application NLB and enable the option to require endpoint acceptance. Create a VPC endpoint in each of the business unit VPCs using the service name of the endpoint service. Accept authorized endpoint requests from the endpoint service console.
- Pros:
- Security and Access Control: This approach allows you to explicitly control access to the centralized application using AWS private endpoints, meaning only authorized business units with accepted endpoints can communicate with the application.
- Low Overhead: There’s no need to manage complex routing or VPN connections.
- Cons:
- Limited Scale: This method is better suited for smaller environments with fewer VPCs. While it allows access control, it might become cumbersome to manage a large number of endpoints.
- CIDR Overlap Challenges: This method doesn’t handle CIDR block overlap effectively. VPC endpoints are generally used for service-to-VPC communications and might not handle CIDR overlaps as gracefully as Transit Gateway.
- Conclusion: This approach could work for smaller or simpler environments but lacks t...
Author: Evelyn · Last updated May 13, 2026
A company wants to migrate its website to AWS. The website uses microservices and runs on containers that are deployed in an on-premises, self-managed Kubernetes cluster. All the manifests that define the deployments for the containers in the Kubernetes deployment are in source control.
All data for the website is stored in a PostgreSQL database. An open source container image repository runs alongside the on-premises environment.
...
To determine the best architecture for migrating the website to AWS with the least effort, we need to focus on minimizing the complexity of the migration process while meeting the company’s existing requirements. Let's evaluate each option:
A) Create an AWS App Runner service. Connect the App Runner service to the open source container image repository. Deploy the manifests from on-premises to the App Runner service. Create an Amazon RDS for PostgreSQL database.
- Advantages:
- Simplified deployment: AWS App Runner is a fully managed service designed to deploy containerized applications directly from source code or container images, which simplifies the deployment process without needing to manage infrastructure.
- Managed PostgreSQL: Amazon RDS for PostgreSQL is a fully managed database service that handles provisioning, patching, backups, and scaling, reducing operational overhead.
- Disadvantages:
- Limited Kubernetes compatibility: App Runner does not support Kubernetes-native workloads and manifests, which would require a significant rework to transition from Kubernetes deployments. This adds complexity to the migration process for a company already using Kubernetes.
- Not designed for complex microservices: App Runner is better suited for simpler applications and microservices, but for a more complex set of containerized applications using Kubernetes, it may not offer the required flexibility or scalability.
Use case: This option may be useful for simpler containerized applications but would require rearchitecting the application significantly. Given that the company is using Kubernetes, it may not be the best fit.
B) Create an Amazon Elastic Kubernetes Service (Amazon EKS) cluster that has managed node groups. Copy the application containers to a new Amazon Elastic Container Registry (Amazon ECR) repository. Deploy the manifests from on-premises to the EKS cluster. Create an Amazon Aurora PostgreSQL DB cluster.
- Advantages:
- Kubernetes support: Since the company already uses Kubernetes for its containerized applications, Amazon EKS is a natural fit. EKS is a managed Kubernetes service, so it would require minimal changes to the existing application deployment and manifest configurations.
- Amazon Aurora for PostgreSQL: Aurora PostgreSQL offers improved performance and scalability over standard PostgreSQL and is fully managed, reducing operational overhead.
- Disadvantages:
- Complexity: While EKS is a good match, it can introduce some complexity in terms of cluster management, especially with setting up networking, security, and scaling. However, it still provides the flexibility and Kubernetes-native experience that aligns well with the company's existing setup.
Use case: This option provides the closest alignment with the company's current infrastructure and would require the least modification of the existing application architecture. It is a good choice for complex, microservice-based architectures.
C) Create an Amazon Elastic Container...
Author: Layla · Last updated May 13, 2026
A company uses a mobile app on AWS to run online contests. The company selects a winner at random at the end of each contest. The contests run for variable lengths of time. The company does not need to retain any data from a contest after the contest is finished.
The company uses custom code that is hosted on Amazon EC2 instances to process the contest data and select a winner. The EC2 instances run behind an Application Load Balancer and store cont...
To reduce costs effectively, we need a solution that aligns with the company's requirements:
1. The contests are temporary, meaning that data does not need to be retained after the contest ends.
2. The solution should minimize the overhead and complexity associated with running the contests, especially in terms of compute resources.
3. Cost reduction is a priority, particularly when it comes to handling scalable storage and compute resources.
Let's evaluate each option:
A) Migrate storage of the contest entries to Amazon DynamoDB. Create a DynamoDB Accelerator (DAX) cluster. Rewrite the code to run as Amazon Elastic Container Service (Amazon ECS) containers that use the Fargate launch type. At the end of the contest, delete the DynamoDB table.
- Advantages:
- DynamoDB: It’s a fully managed NoSQL database, ideal for temporary data storage with automatic scaling based on demand. The data is ephemeral, which fits the requirement of not needing to retain data after the contest.
- Amazon ECS with Fargate: Fargate is serverless, so you only pay for the compute time your containers use. It reduces the operational overhead of managing EC2 instances.
- Disadvantages:
- DAX (DynamoDB Accelerator): While DAX provides in-memory caching for DynamoDB, it’s typically used for high-read, low-latency use cases, which may not be necessary in this scenario since the contest data likely doesn’t require frequent reads at scale. DAX also adds an additional cost, which may not be justified for this case.
- Storage Cleanup: Although DynamoDB allows easy deletion of data, the migration and use of DAX are unnecessary for this type of workload, adding complexity and cost.
Use case: While DynamoDB is a great choice for temporary data, the addition of DAX and ECS with Fargate seems over-engineered and unnecessarily expensive for the task at hand.
B) Migrate the storage of the contest entries to Amazon Redshift. Rewrite the code as AWS Lambda functions. At the end of the contest, delete the Redshift cluster.
- Advantages:
- AWS Lambda: Lambda is a serverless compute option, meaning you pay only for the execution time of your code, which can significantly reduce costs if the processing is event-driven.
- Disadvantages:
- Redshift: Redshift is a managed data warehouse service designed for complex queries and analytics, which is much more expensive and unnecessary for storing temporary contest entries. Redshift is optimized for large-scale analytical workloads and would not be a cost-effective solution for transient, high-throughput storage of contest entries.
- Cleanup overhead: The process of creating and deleting Redshift clusters every time a contest starts and ends would introduce additional operational overhead and inefficiency.
Use case: Redshift is an overkill for this scenario. Lambda would be useful, but pairing it with Redshift for this workload is not cost-effective or practical.
C) Add an A...
Author: Vikram · Last updated May 13, 2026
A company has implemented a new security requirement. According to the new requirement, the company must scan all traffic from corporate AWS instances in the company's VPC for violations of the company's security policies. As a result of these scans, the company can block access to and from specific IP addresses.
To meet the new requirement, the company deploys a set of Amazon EC2 instances in private subnets to serve as transparent proxies. The company installs approved proxy server software on these EC2 instances. The company modifies the route tables on all subnets to use the corresponding EC2 instances with proxy software as the default route. The company also creates security groups th...
To resolve the issue where traffic from the EC2 instances in private subnets is not being properly forwarded to the internet despite the company's configuration of transparent proxies, the main issue likely lies in the network routing configuration or source/destination checks. Let's analyze each of the options:
A) Disable source/destination checks on the EC2 instances that run the proxy software.
- Advantages:
- Correct solution: By default, EC2 instances in a VPC perform source/destination checks, which means they cannot forward traffic that is not destined for themselves (e.g., routing traffic between different network interfaces or for NAT purposes). Disabling the source/destination checks allows the EC2 instances to function as network devices (like routers), enabling them to forward traffic between the private subnets and the internet.
- Disadvantages:
- No significant drawbacks: Disabling the source/destination check is a standard practice when configuring EC2 instances to act as proxies or NAT devices.
Use case: This is the correct and most effective solution because the EC2 instances need to forward traffic between the private subnets and the internet, and disabling source/destination checks is required for this behavior.
B) Add a rule to the security group that is assigned to the proxy EC2 instances to allow all traffic between instances that have this security group. Assign this security group to all EC2 instances in the VPC.
- Advantages:
- Security Group Modification: This allows traffic between EC2 instances within the VPC, which can be useful in some situations.
- Disadvantages:
- Not directly related to the issue: The issue described is related to traffic forwarding and routing, not inter-instance communication. The proxy instances need to route traffic to the internet, and modifying the security group in this way does not address the need for routing configuration.
Use case: While security group rules might be useful for controlling intra-VPC communication, they are not relevant to enabling traffic forwarding between subnets and the internet. This is not the right solution.
C) Change the VPC's...
Author: Suresh · Last updated May 13, 2026
A company is running its solution on AWS in a manually created VPC. The company is using AWS CloudFormation to provision other parts of the infrastructure. According to a new requirement, the company must manage all infrastructure in...
To meet the requirement of managing the existing infrastructure in an automatic way with the least effort, the solution should focus on bringing the manually created VPC under management through AWS CloudFormation. Let's evaluate each option based on the goal of automating infrastructure management:
A) Create a new AWS Cloud Development Kit (AWS CDK) stack that strictly provisions the existing VPC resources and configuration. Use AWS CDK to import the VPC into the stack and to manage the VPC.
- Advantages:
- AWS CDK: The AWS CDK is a modern, code-first approach to infrastructure provisioning, which offers powerful capabilities for managing AWS resources.
- Import capability: AWS CDK allows you to import existing resources (including a VPC) into the stack and then manage them programmatically.
- Disadvantages:
- Effort required for import: While CDK can be used to import resources, the process may require some effort and the use of custom code to correctly model the existing infrastructure.
- Not as straightforward as CloudFormation: AWS CDK is more suited to new infrastructure rather than managing existing resources, particularly when the goal is to minimize effort.
Use case: AWS CDK is powerful but may not be the best choice for an immediate, straightforward solution for managing already existing resources. While feasible, it requires more upfront effort than other methods, especially when aiming for minimal effort.
B) Create a CloudFormation stack set that creates the VPC. Use the stack set to import the VPC into the stack.
- Advantages:
- CloudFormation StackSet: StackSets allow for the deployment of CloudFormation stacks across multiple regions and accounts, which is useful for a larger scale of infrastructure management.
- Disadvantages:
- Cannot directly import existing resources: CloudFormation StackSets do not support the direct import of already existing resources like a manually created VPC. This would require creating the VPC from scratch again, which is counterproductive in this scenario.
Use case: This option is not suitable because StackSets are designed for multi-region/account deployments and cannot directly import existing resources into a stack.
C) Create a new CloudFormation template that strictly provisions the existi...
Author: CrimsonViperX · Last updated May 13, 2026
A company has developed a new release of a popular video game and wants to make it available for public download. The new release package is approximately 5 GB in size. The company provides downloads for existing releases from a Linux-based, publicly facing FTP site hosted in an on-premises data center. The company expects the new release will be downloa...
Option A: Store the game files on Amazon EBS volumes mounted on Amazon EC2 instances within an Auto Scaling group. Configure an FTP service on the EC2 instances. Use an Application Load Balancer in front of the Auto Scaling group. Publish the game download URL for users to download the package.
- Reasoning: This approach involves setting up EC2 instances that can scale depending on demand and provide access via FTP. However, EBS volumes are not optimal for global distribution of large files. EBS is designed for persistent block storage, but not specifically for high-performance file delivery across multiple regions. Also, FTP is an outdated protocol, and the solution does not address the need for worldwide content delivery effectively.
- Key Issues: High management complexity, scaling issues, potentially high costs, and not optimized for global download speed.
- Use Case: Could work for an internal use case within a specific region, but not ideal for global distribution of large files.
Option B: Store the game files on Amazon EFS volumes that are attached to Amazon EC2 instances within an Auto Scaling group. Configure an FTP service on each of the EC2 instances. Use an Application Load Balancer in front of the Auto Scaling group. Publish the game download URL for users to download the package.
- Reasoning: Amazon EFS is a scalable, shared file storage solution, but it is better suited for use cases that involve distributed applications or workloads with highly variable storage needs. It is not designed for large-scale global file distribution. Like Option A, using FTP adds complexity, and this solution would not provide the best performance for worldwide users.
- Key Issues: EFS is not cost-effective or optimal for serving large downloadable files to global users, and FTP adds unnecessary overhead.
- Use Case: Suitable for shared access to files within a specific environment but not for high-performance global file downloads.
Option C: Configure Amazon Route 53 and an Amazon S3 bucket for website hosting. Upload the game f...
Author: ThunderBear · Last updated May 13, 2026
A company runs an application in the cloud that consists of a database and a website. Users can post data to the website, have the data processed, and have the data sent back to them in an email. Data is stored in a MySQL database running on an Amazon EC2 instance. The database is running in a VPC with two private subnets. The website is running on Apache Tomcat in a single EC2 instance in a different VPC with one public subnet. There is a single VPC peering connection between the database and ...
Option A: Place the Tomcat server in an Auto Scaling group with multiple EC2 instances behind an Application Load Balancer.
- Reasoning: By placing the Tomcat server in an Auto Scaling group with multiple EC2 instances, you can ensure high availability and handle fluctuations in traffic. The Application Load Balancer (ALB) will automatically distribute traffic across multiple instances of Tomcat, providing better load balancing and fault tolerance.
- Key Advantages: This solution addresses the issue of outages caused by high traffic by scaling the website dynamically based on demand. It improves the availability of the website, ensuring users can always access it even if one EC2 instance fails.
- Use Case: Ideal for scenarios where an application needs to handle fluctuating traffic while ensuring continuous availability and scaling based on demand.
Option B: Provision an additional VPC peering connection.
- Reasoning: VPC peering connects two VPCs, allowing resources to communicate between them. However, adding an additional VPC peering connection would not help address the root cause of the website's outages. The issue seems to be related to the web application’s ability to handle traffic, not the VPC peering connectivity. The single peering connection is sufficient for communication, and adding another one would not solve the scalability or reliability issues.
- Key Issues: This doesn't directly address the problem of scaling the website or improving its availability. VPC peering connections do not inherently improve traffic management or application performance.
- Use Case: VPC peering is useful for scenarios requiring communication between VPCs but does not resolve performance issues in this case.
Option C: Migrate the MySQL database to Amazon Aurora with one Aurora Replica.
- Reasoning: Amazon Aurora is a managed, highly available database service that is compatible with MySQL. By migrating to Aurora, the company can benefit from automated backups, replication, and scaling, making the database more resilient and capable of handling higher traffic loads. Aurora Replicas provide read scalability, reducing the load on the primary database and improving overall performance.
- Key Advantages: Aurora provides better availability, fault tolerance, and scalability compared to a MySQL database running on EC2. This can significantly improve the reliability of the backend database, especially under high traffic conditions.
- Use Case: Ideal for scenarios where a more scalable, highly available, and fault-tolerant database solution is required to support growing application demands.
Option D: Provision two NAT gateways in the database VPC.
- Reasoning: A NAT gateway is used to allow instances in private subnets to access the internet. However, the database VPC with MySQL should not need to access the i...
Author: William · Last updated May 13, 2026
A retail company is operating its ecommerce application on AWS. The application runs on Amazon EC2 instances behind an Application Load Balancer (ALB). The company uses an Amazon RDS DB instance as the database backend. Amazon CloudFront is configured with one origin that points to the ALB. Static content is cached. Amazon Route 53 is used to host all public zones.
After an update of the application, the ALB occasionally returns a 502 status code (Bad Gateway) error. The root cause is malformed HTTP headers that are returned to the ALB. The webpage returns successfully when a solutions architect reloads the webpage immediately after the error occu...
Option A: Create an Amazon S3 bucket. Configure the S3 bucket to host a static webpage. Upload the custom error pages to Amazon S3.
- Reasoning: This is the most straightforward and least operationally intensive option for serving a custom error page. By using an S3 bucket to host the static error page, the company can easily configure Amazon CloudFront to deliver it. The S3 bucket can be configured to serve static HTML files, and CloudFront can be set up to cache and distribute the error page to users when needed. This approach minimizes complexity and operational overhead because it doesn't require complex Lambda functions or DNS changes.
- Key Advantages: Simple to set up and manage, reduces complexity, integrates easily with CloudFront, and is highly scalable. The static nature of the error page makes it ideal for this use case.
- Use Case: Best for serving custom error pages when there are temporary application issues, such as 502 errors, and when you want a simple, scalable solution.
Option B: Create an Amazon CloudWatch alarm to invoke an AWS Lambda function if the ALB health check response Target.FailedHealthChecks is greater than 0. Configure the Lambda function to modify the forwarding rule at the ALB to point to a publicly accessible web server.
- Reasoning: While creating a CloudWatch alarm to trigger a Lambda function to modify the ALB's forwarding rule could theoretically help in rerouting traffic to a backup or static error page, it introduces significant complexity. You would need to handle the Lambda function's logic for modifying routing rules dynamically. Additionally, this solution doesn't directly address the core problem of serving a static error page.
- Key Issues: This is overly complex for simply showing a custom error page. It involves managing dynamic routing logic and additional operational overhead with Lambda functions and health checks. It also requires frequent updates or monitoring to ensure the correct target is selected.
- Use Case: More suitable for scenarios where routing traffic to backup servers or containers is needed, not for simple error page handling.
Option C: Modify the existing Amazon Route 53 records by adding health checks. Configure a fallback target if the health check fails. Modify DNS records to point to a publicly accessible webpage.
- Reasoning: This solution suggests modifying DNS settings to fallback to a different page when health checks fail. However, DNS changes are not instantaneous, and there is a potential for propagation delays. DNS-based redirection can be slow, and it's not ideal for real-time error handling, especially for HTTP status codes like 502.
- Key Issues: DNS propagation delays can create inconsistent user experiences. C...
Author: FrostFalcon88 · Last updated May 13, 2026
A company wants to migrate an Amazon Aurora MySQL DB cluster from an existing AWS account to a new AWS account in the same AWS Region. Both accounts are members of the same organization in AWS Organizations.
The company must minimize database service interruption before the...
Option A: Take a snapshot of the existing Aurora database. Share the snapshot with the new AWS account. Create an Aurora DB cluster in the new account from the snapshot.
- Reasoning: This option allows you to take a snapshot of the existing Aurora MySQL database, share that snapshot with the new AWS account, and then restore the snapshot in the new account to create a new Aurora DB cluster. This is a straightforward and common method for migrating an Aurora database between accounts in the same region.
- Key Advantages:
- Snapshot sharing is supported between accounts in the same AWS Region.
- Once the snapshot is restored, the database can be brought online with minimal downtime, and DNS cutover can be done when the migration is complete.
- This minimizes service interruption because the database in the old account will remain functional during the snapshot sharing and restoration process.
- Use Case: This method works well for a one-time migration where minimizing downtime is critical, and it is a native AWS feature designed for such use cases.
Option B: Create an Aurora DB cluster in the new AWS account. Use AWS Database Migration Service (AWS DMS) to migrate data between the two Aurora DB clusters.
- Reasoning: AWS DMS is a powerful tool for migrating data between databases in real-time, but for an Aurora MySQL migration, it adds unnecessary complexity compared to using a snapshot-based approach. While AWS DMS can replicate changes from the source database to the target database during the migration, it introduces an additional service and might involve more setup and management overhead.
- Key Issues:
- AWS DMS is useful for continuous replication during migration, but it requires configuration, monitoring, and management of migration tasks. The initial setup of DMS can be time-consuming, and it may involve ongoing operational complexity.
- This is overkill if the goal is to minimize downtime and perform a one-time migration, as a snapshot and restore process would be simpler and more efficient.
- Use Case: Best suited for continuous migration or when complex transformations are required, not for minimizing downtime in a simple migration scenario like this.
Option C: Use AWS Backup to share an Aurora database backup from the existing AWS account to the ...
Author: Aria · Last updated May 13, 2026
A software as a service (SaaS) company provides a media software solution to customers. The solution is hosted on 50 VPCs across various AWS Regions and AWS accounts. One of the VPCs is designated as a management VPC. The compute resources in the VPCs work independently.
The company has developed a new feature that requires all 50 VPCs to be able to communicate with each other. The new feature also requires one-way access from each customer's VPC to the company's management VPC. The management VPC hosts a compute resource that validates licenses for the media software so...
Option A: Create a transit gateway. Attach all the company's VPCs and relevant subnets to the transit gateway.
- Reasoning: Using a Transit Gateway is the most scalable and efficient option for enabling communication between multiple VPCs across regions and accounts. The Transit Gateway acts as a central hub to connect VPCs, enabling communication with minimal operational overhead. With the Transit Gateway, VPCs can be attached to the hub, and the required communication (including one-way access from each customer VPC to the management VPC) can be easily controlled via route tables.
- Key Advantages:
- Centralized management for routing between VPCs, which simplifies operations.
- Scalable solution that can accommodate an increasing number of VPCs.
- Simplifies inter-VPC connectivity and one-way access control from customer VPCs to the management VPC.
- Supports cross-region peering, which is ideal if the VPCs span across multiple AWS regions.
- Use Case: Best suited for scenarios requiring communication between a growing number of VPCs, where simplicity, scalability, and centralized management are essential.
Option B: Create VPC peering connections between all the company's VPCs.
- Reasoning: VPC peering is another option for VPC-to-VPC communication, but it can become complex and difficult to manage at scale. For 50 VPCs (and potentially more in the future), the number of peering connections would grow exponentially. Each new VPC would need to be peered with every other VPC, leading to a management overhead. Additionally, VPC peering doesn't support transitive routing, meaning each VPC can only communicate directly with the VPCs it's peered with. This would require maintaining a complex web of peering connections, making it inefficient as the solution grows.
- Key Issues:
- Scalability: The number of connections grows quadratically as the number of VPCs increases, creating significant operational overhead.
- Complexity: Managing peering connections between VPCs at scale can become error-prone and cumbersome.
- No Transitive Routing: VPC peering doesn’t support transitive routing, so each new connection would need to be explicitly configured to allow communication between VPCs that are not directly peered.
- Use Case: Suitable for small-scale environments with few VPCs and simpler connectivity requirements but not ideal for a growing SaaS solution with many VPCs.
Option C: Create a Network Load Balancer (NLB) that points to the compute resource for license validation. Create an AWS PrivateLink endpoint service that is available to each customer's VPC. Associate the endpoint service with the NLB.
- Reasoning: AWS PrivateLink enables secure and private communication between VPCs, which is ideal for services like license validation. However, this solution focuses on the one-way access from customer VPCs to the management VPC, which is a small part of the requirement. While PrivateLink provides a secu...
Author: RadiantJaguar56 · Last updated May 13, 2026
A company has multiple lines of business (LOBs) that roll up to the parent company. The company has asked its solutions architect to develop a solution with the following requirements:
* Produce a single AWS invoice for all of the AWS accounts used by its LOBs.
* The costs for each LOB account should be broken out on the invoice.
* Provide the ability to restrict services and features in the LOB accounts, as defined by the company's governance policy.
* Each LOB a...
To meet the requirements provided, let's carefully analyze each option and discuss the key reasoning behind selecting or rejecting each one.
Requirements Breakdown:
1. Produce a single AWS invoice for all AWS accounts used by its LOBs - This points to consolidated billing.
2. The costs for each LOB account should be broken out on the invoice - This requires a way to distinguish the costs between different LOB accounts.
3. Provide the ability to restrict services and features in the LOB accounts, as defined by the company's governance policy - This points to a service control mechanism (Service Control Policies, SCPs) to enforce restrictions.
4. Each LOB account should be delegated full administrator permissions, regardless of the governance policy - This means that while restrictions are applied via policies, LOB accounts need full administrative rights, which is compatible with SCPs allowing broader permissions at the account level.
Option Analysis:
- A) Use AWS Organizations to create an organization in the parent account for each LOB. Then invite each LOB account to the appropriate organization.
- This option is incorrect because AWS Organizations doesn't allow multiple organizations within a single account. AWS Organizations is intended to create one organization that includes multiple AWS accounts, not one organization per LOB. Hence, this option isn't viable for meeting the requirements.
- B) Use AWS Organizations to create a single organization in the parent account. Then, invite each LOB's AWS account to join the organization.
- This is a correct option. AWS Organizations allows the parent account to create a single organization and invite multiple LOB accounts into it. This setup allows for consolidated billing and cost management, meeting the requirement to produce a single AWS invoice. Additionally, AWS Organizations helps break out costs per account. This method also enables applying service control policies (SCPs) to enforce governance without impacting the LOB's administrative rights.
...
Author: Emily · Last updated May 13, 2026
A solutions architect has deployed a web application that serves users across two AWS Regions under a custom domain. The application uses Amazon Route 53 latency-based routing. The solutions architect has associated weighted record sets with a pair of web servers in separate Availability Zones for each Region.
The solutions architect runs a disaster recovery scenario. When all the web servers in...
Analysis of the Problem:
In this scenario, the solutions architect is using Amazon Route 53 latency-based routing with weighted record sets for disaster recovery. However, when the web servers in one Region are stopped, Route 53 does not automatically redirect users to the other Region. This could be due to issues in the configuration of health checks or the way the routing is set up.
Let's evaluate each option to identify the possible root causes:
Option-by-Option Breakdown:
A) The weight for the Region where the web servers were stopped is higher than the weight for the other Region.
- Rejection Reason: The weight of the resource record sets only determines how much traffic is routed to each region under normal conditions, but it does not affect the failover behavior when one region is down. Weight does not affect health-based failover in Route 53, so this is not the root cause of the issue. The failover should happen as long as health checks are configured correctly, regardless of the weight.
B) One of the web servers in the secondary Region did not pass its HTTP health check.
- Selected Option: This is a valid root cause. If a web server in the secondary Region fails its health check, Route 53 will not route traffic to that server, even if it's the only available Region. Route 53 latency-based routing uses health checks to determine which resources are available. If the health check for a web server in the secondary Region fails, it will prevent Route 53 from routing traffic to that region, causing users to remain stuck in the primary (failed) region. This scenario directly explains why Route 53 is not redirecting traffic to the other region.
C) Latency resource record sets cannot be used in combination with weighted resource record sets.
- Rejection Reason: This is incorrect. Latency-based routing and weighted routing in Route 53 can be used in conjunction. It's possible to combine th...
