Amazon Practice Questions, Discussions & Exam Topics by our Authors
A flood monitoring agency has deployed more than 10,000 water-level monitoring sensors. Sensors send continuous data updates, and each update is less than 1 MB in size. The agency has a fleet of on-premises application servers. These servers receive updates from the sensors, convert the raw data into a human readable format, and write the results to an on-premises relational database server. Data analysts then use simple SQL queries to monitor the data.
The agency wants to increase overall application availability and reduce the effort that is required to perform maintenance tasks. These maintenance tasks, which include updates and patches to the application servers, cause downtime. While an application server is down, data is lost f...
Requirements Breakdown:
- Increase overall application availability: The solution must be highly available, which implies that there should be no downtime, even during maintenance tasks.
- Reduce maintenance efforts: Maintenance tasks (e.g., updates, patches) on on-premises application servers lead to downtime. We need a solution that reduces the overhead of such maintenance.
- Avoid data loss during server downtime: The solution should ensure that the data from the sensors is not lost when an application server is unavailable.
- Optimize operational overhead and costs: The solution should minimize operational complexity and should be cost-effective.
Option Analysis:
A) Send the sensor data to Amazon Kinesis Data Firehose. Use an AWS Lambda function to read the Kinesis Data Firehose data, convert it to .csv format, and insert it into an Amazon Aurora MySQL DB instance. Instruct the data analysts to query the data directly from the DB instance.
- Not the best option. While Kinesis Data Firehose can be used to ingest the sensor data, using an Amazon Aurora MySQL DB instance introduces complexity in terms of cost and scalability. Additionally, directly querying data from a relational database is not ideal for analytical purposes when you have large-scale sensor data. Aurora also requires maintenance and scaling, which contradicts the goal of reducing operational overhead. The operational burden of handling updates and scaling can still create issues.
B) Send the sensor data to Amazon Kinesis Data Firehose. Use an AWS Lambda function to read the Kinesis Data Firehose data, convert it to Apache Parquet format, and save it to an Amazon S3 bucket. Instruct the data analysts to query the data by using Amazon Athena.
- This is a strong option.
- Kinesis Data Firehose provides a fully managed solution for ingesting streaming data, which increases availability and reliability.
- Apache Parquet is a columnar storage format, which is optimized for query performance in analytics scenarios, making it a good fit for the data.
- Amazon Athena allows for SQL-like queries directly on data stored in Amazon S3, which significantly reduces the need for traditional database management and minimizes operational overhead.
- This solution offers scalability, cost-effectiveness (pay-as-you-go), and reduces maintenance efforts. It also ensures that data is no...
Author: Ahmed · Last updated May 13, 2026
A public retail web application uses an Application Load Balancer (ALB) in front of Amazon EC2 instances running across multiple Availability Zones (AZs) in a Region backed by an Amazon RDS MySQL Multi-AZ deployment. Target group health checks are configured to use HTTP and pointed at the product catalog page. Auto Scaling is configured to maintain the web fleet size based on the ALB health check.
Recently, the application experienced an outage. Auto Scaling continuously replaced the instances during the outage. A subsequent investigation determined that the web server metrics were within the normal range, but the database tier was experiencin...
Scenario Breakdown:
- Application Load Balancer (ALB): Balances traffic across multiple EC2 instances running across multiple Availability Zones.
- Amazon RDS MySQL Multi-AZ deployment: The database is highly available, but was experiencing high load during the outage, which resulted in elevated query response times.
- Auto Scaling: Was triggered based on ALB health checks, which failed even though the web server metrics were normal, suggesting that the health checks may not be monitoring the overall application stack properly.
Key Requirements:
- Remediate the issues: The root cause is that Auto Scaling continued to replace EC2 instances, even though the problem was with the database tier. This suggests that the health checks were insufficient to detect the actual problem.
- Improve monitoring and availability: The solution should not only prevent the issue from recurring but also enhance monitoring capabilities to ensure the entire application stack's availability is better tracked and that the load on the backend database is reduced.
Option Analysis:
A) Configure read replicas for Amazon RDS MySQL and use the single reader endpoint in the web application to reduce the load on the backend database tier.
- Correct choice. By setting up read replicas for Amazon RDS MySQL, the load on the primary database can be reduced by offloading read-heavy queries to the replicas. This would help balance the database load and ensure better scalability. The single reader endpoint allows the web application to automatically distribute read requests across all available read replicas. This improves database performance and reduces the strain on the primary database, making it a good solution for the database tier's scalability.
B) Configure the target group health check to point at a simple HTML page instead of a product catalog page and the Amazon Route 53 health check against the product page to evaluate full application functionality. Configure Amazon CloudWatch alarms to notify administrators when the site fails.
- Partially correct, but suboptimal. Changing the health check to a simple HTML page might avoid false positives from the target group health checks, but it does not address the underlying issue of high database load. The application itself, including database health, is still not adequately monitored. Also, Amazon Route 53 health checks can't evaluate database functionality, so this would still miss database-related issue...
Author: Grace · Last updated May 13, 2026
A company has an on-premises data center and is using Kubernetes to develop a new solution on AWS. The company uses Amazon Elastic Kubernetes Service (Amazon EKS) clusters for its development and test environments.
The EKS control plane and data plane for production workloads must reside on premises. The company ne...
To address the company's requirement of managing Kubernetes on AWS while keeping the production workloads on-premises, we need to find the most suitable solution that meets the following criteria:
1. On-premises control plane and data plane for production workloads: The production workloads need to reside on-premises, so the control plane must be managed in a way that allows Kubernetes clusters to run on-premises.
2. AWS-managed solution: The company is seeking an AWS-managed solution to reduce operational overhead.
A) Install an AWS Outposts server in the on-premises data center. Deploy Amazon EKS by using a local cluster configuration on the Outposts server for the production workloads.
- Analysis:
- AWS Outposts can bring AWS infrastructure to the on-premises data center, and you can run Amazon EKS with a local cluster configuration (which means that the EKS control plane is in the cloud, while the data plane is deployed on the Outposts hardware on-premises).
- However, this configuration might not meet the requirement to have both the control plane and data plane on-premises. The control plane would still reside in the AWS cloud, and only the data plane would be on-premises.
- This setup could also involve more operational overhead than needed, as the user would still need to manage a connection between the control plane in the cloud and the local data plane.
- Conclusion: While feasible, this solution doesn’t fully meet the requirement of having both the control plane and data plane on-premises. (Rejected)
B) Install Amazon EKS Anywhere on the company's hardware in the on-premises data center. Deploy the production workloads on an EKS Anywhere cluster.
- Analysis:
- Amazon EKS Anywhere is a fully AWS-managed solution that allows you to run Amazon EKS clusters on your on-premises hardware. It provides a Kubernetes environment that can run in your data center while being managed through AWS.
- This approach ensures that both the control plane and data plane are on-premises, which fully aligns with the company's requirement to keep the production workloads on-premises.
- EKS Anywhere...
Author: Ahmed · Last updated May 13, 2026
A company uses AWS Organizations to manage its development environment. Each development team at the company has its own AWS account. Each account has a single VPC and CIDR blocks that do not overlap.
The company has an Amazon Aurora DB cluster in a shared services account. All the development teams need to work with li...
To provide connectivity to the Amazon Aurora DB cluster with the least operational overhead, let's analyze each option:
A) Create an AWS Resource Access Manager (AWS RAM) resource share for the DB cluster. Share the DB cluster with all the development accounts.
- Analysis: AWS RAM allows you to share resources, such as VPCs, subnets, and databases, between AWS accounts. However, it is not typically used for sharing databases like Aurora directly. Aurora does not currently support being shared via AWS RAM directly for cross-account access. This option would not be feasible.
- Reason for Rejection: AWS RAM doesn't support directly sharing Aurora DB clusters, so it cannot provide the connectivity required.
B) Create a transit gateway in the shared services account. Create an AWS Resource Access Manager (AWS RAM) resource share for the transit gateway. Share the transit gateway with all the development accounts. Instruct the developers to accept the resource share. Configure networking.
- Analysis: A transit gateway could allow inter-VPC communication between the shared services account and all development accounts. Sharing the transit gateway using AWS RAM can help establish networking between the VPCs across accounts. However, setting up a transit gateway requires configuring routing and careful management of VPC attachments. While scalable and flexible, this solution involves additional operational overhead, such as setting up, maintaining, and configuring the transit gateway and routing.
- Reason for Rejection: While this solution would work, it introduces additional operational overhead due to the complexity of managing a transit gateway and configuring routing.
C) Create an Application Load Balancer (ALB) that points to the IP address of the DB cluster. Create an AWS PrivateLink endpoint service that uses the ALB. Add permissions to al...
Author: Michael · Last updated May 13, 2026
A company used AWS CloudFormation to create all new infrastructure in its AWS member accounts. The resources rarely change and are properly sized for the expected load. The monthly AWS bill is consistent.
Occasionally, a developer creates a new resource for testing and forgets to remove the resource when the test is complete. Most of these tests last a few days before the resources are no longer needed.
The company wants to automate the process of finding unused resources. A solutions architect needs to design a solution that determ...
To meet the company's requirements, let's evaluate each option based on the goal of detecting unused resources, identifying cost increases, and notifying the operations team.
A) Turn on billing alerts. Use AWS Cost Explorer to determine the costs for the past month. Create an Amazon CloudWatch alarm for total estimated charges. Specify a cost threshold that is higher than the costs that Cost Explorer determined. Add a notification to alert the operations team if the alarm threshold is breached.
- Analysis: While CloudWatch billing alarms can notify the team when total estimated charges exceed a certain threshold, this option only provides alerts based on aggregate costs. It does not offer detailed insights into which specific resources are causing the cost increase. This option requires manual effort to analyze historical data from AWS Cost Explorer to set an appropriate threshold.
- Reason for Rejection: It does not directly help identify which resources are unused and causing the cost increases, making it less effective for the company's needs of automatically identifying unused resources.
B) Turn on billing alerts. Use AWS Cost Explorer to determine the average monthly costs for the past 3 months. Create an Amazon CloudWatch alarm for total estimated charges. Specify a cost threshold that is higher than the costs that Cost Explorer determined. Add a notification to alert the operations team if the alarm threshold is breached.
- Analysis: Similar to option A, this solution uses CloudWatch billing alarms and AWS Cost Explorer. It extends the analysis to a 3-month window, which may help better predict typical costs. However, the solution still lacks granularity on individual resource usage and doesn't automatically identify unused resources or specific contributors to the cost increase.
- Reason for Rejection: Like option A, it doesn't pinpoint unused resources causing cost increases, so it doesn’t address the requirement of helping to identify unused resources directly.
C) Use AWS Cost Anomaly Detection to create a cost monitor that has a monitor type of Linked account. Create a subscription to send daily AWS cost summaries to the operations team. ...
Author: Layla · Last updated May 13, 2026
A company is deploying a new web-based application and needs a storage solution for the Linux application servers. The company wants to create a single location for updates to application data for all instances. The active dataset will be up to 100 GB in size. A solutions architect has determined that peak operations will occur for 3 hours daily and will require a total of 225 MiBps of read throughput.
The solutions architect must design a Multi...
Let’s go through the options and analyze each in terms of the company’s requirements:
Key Requirements:
1. Storage for Linux application servers: The solution should provide centralized storage for application data.
2. Up to 100 GB active dataset.
3. Peak operations for 3 hours daily: Peak read throughput of 225 MiBps.
4. Multi-AZ setup: The solution must be deployed across multiple Availability Zones.
5. Disaster Recovery (DR): The DR solution must have a Recovery Point Objective (RPO) of less than 1 hour.
A) Deploy a new Amazon Elastic File System (Amazon EFS) Multi-AZ file system. Configure the file system for 75 MiBps of provisioned throughput. Implement replication to a file system in the DR Region.
- Analysis:
- Amazon EFS is a fully managed, scalable, shared file storage service that supports Linux workloads and provides automatic scaling of throughput and capacity.
- EFS supports Multi-AZ by default, which ensures high availability within a region.
- Replication to another region (cross-region replication) is possible, but this involves a process that isn’t built into EFS itself; custom solutions like AWS DataSync would be needed to replicate the data.
- The throughput of 75 MiBps might not be enough to meet the required 225 MiBps peak throughput, especially since the solution would only be configured for half of the required peak throughput.
- EFS replication does not inherently meet the less than 1 hour RPO unless set up carefully with custom processes like DataSync.
- Conclusion: This option does not fully meet the performance or RPO requirements due to insufficient throughput and the need for custom replication setup. (Rejected)
B) Deploy a new Amazon FSx for Lustre file system. Configure Bursting Throughput mode for the file system. Use AWS Backup to back up the file system to the DR Region.
- Analysis:
- Amazon FSx for Lustre is designed for high-performance workloads, including those that require fast access to large datasets, making it a good choice for applications with high throughput requirements.
- However, Bursting Throughput mode in FSx for Lustre is not suitable for sustained throughput of 225 MiBps. This mode is designed for workloads that can tolerate short bursts but would not guarantee sustained high throughput for 3 hours daily.
- Using AWS Backup to replicate the data introduces an RPO that may not meet the requirement of less than 1 hour since backups are typically scheduled at longer intervals (e.g., daily), not frequent enough to meet the RPO.
- Conclusion: This option i...
Author: Sara · Last updated May 13, 2026
A company needs to gather data from an experiment in a remote location that does not have internet connectivity. During the experiment, sensors that are connected to a local network will generate 6 TB of data in a proprietary format over the course of 1 week. The sensors can be configured to upload their data files to an FTP server periodically, but the sensors do not have their own FTP server. The sensors also do not support other protocols...
Let's evaluate each option to determine which one best meets the requirements for gathering data from the sensors, transferring it to AWS, and ensuring the solution can work in a remote location with no internet connectivity.
Key Requirements:
- 6 TB of data generated over 1 week.
- Sensors can upload data via FTP.
- No internet connectivity at the remote location.
- Data must be collected centrally and moved to AWS object storage (Amazon S3) as soon as possible after the experiment.
A) Order an AWS Snowball Edge Compute Optimized device. Connect the device to the local network. Configure AWS DataSync with a target bucket name, and unload the data over NFS to the device. After the experiment, return the device to AWS so that the data can be loaded into Amazon S3.
- Analysis: The AWS Snowball Edge is a suitable device for edge computing and offline data transfer. It provides both local compute capabilities and the ability to transfer large amounts of data back to AWS. However, AWS DataSync is used for moving data over the network, but since there is no internet connectivity in the remote location, the Snowball Edge device cannot communicate directly with AWS services during the experiment. Additionally, the sensors can only upload data via FTP, and the solution described here doesn't provide an FTP server for the sensors.
- Reason for Rejection: The lack of an FTP server for the sensors and no ability to upload data directly to the device make this solution not viable.
B) Order an AWS Snowcone device, including an Amazon Linux 2 AMI. Connect the device to the local network. Launch an Amazon EC2 instance on the device. Create a shell script that periodically downloads data from each sensor. After the experiment, return the device to AWS so that the data can be loaded as an Amazon Elastic Block Store (Amazon EBS) volume.
- Analysis: The AWS Snowcone device provides local storage and compute capabilities, but it doesn't support a native FTP server. The idea of using a shell script to download data from the sensors assumes a mechanism for the sensors to share data (e.g., FTP, HTTP), but there is no mention of how the sensors would push data to the Snowcone device. Additionally, using EBS as the target for storing data after the experiment is not the most efficient way to move data into S3.
- Reason for Rejection: The solution does not include an FTP server, and it would require manual scripting and management of data transfer, making it overly complex and prone to errors.
C) Order an AWS Snowcone device, including an Amazon Linu...
Author: Amelia · Last updated May 13, 2026
A company that has multiple business units is using AWS Organizations with all features enabled. The company has implemented an account structure in which each business unit has its own AWS account. Administrators in each AWS account need to view detailed cost and utilization data for their account by using Amazon Athena.
Each business unit can have access to only its own cost and utilization data. The IAM policies that govern the ability to set up AWS Cost and Usage Reports are in pl...
To determine which solution meets the company's requirements with the least operational complexity, let's analyze each option:
Key Requirements:
- Each business unit must have access only to its own cost and utilization data.
- Administrators in each AWS account need to view detailed data using Amazon Athena.
- There is already a central Cost and Usage Report available in an Amazon S3 bucket.
- The solution should have the least operational complexity.
A) In the organization's management account, use AWS Resource Access Manager (AWS RAM) to share the Cost and Usage Report data with each member account.
- Analysis: AWS RAM enables resource sharing across accounts, but sharing Cost and Usage Reports (CUR) is not directly supported by AWS RAM. CURs are stored in an S3 bucket, and RAM typically shares AWS resources (like VPCs or Transit Gateways), not specific S3 objects.
- Reason for Rejection: This option is not feasible because AWS RAM does not support the sharing of S3 data (including the Cost and Usage Report) in the manner required.
B) In the organization's management account, configure an S3 event to invoke an AWS Lambda function each time a new file arrives in the S3 bucket that contains the central Cost and Usage Report. Configure the Lambda function to extract each member account's data and place the data in Amazon S3 under a separate prefix. Modify the S3 bucket policy to allow each member account to access its own prefix.
- Analysis: This solution would work by triggering a Lambda function every time a new file is added to the S3 bucket containing the central Cost and Usage Report. The Lambda function can parse the report, filter the data by account, and store it in separate S3 prefixes for each business unit. The S3 bucket policy can be adjusted to ensure that only the relevant business unit’s administrators can access their specific prefix.
- Reason for Selection: This solution provides granular access control to each account's data and is fully automated. It meets the requirement of having each business unit access only its own cost data while using Athena for querying. However, it involves setting up and maintaining the Lambda function and ensuring the S3 bucket policy is correct. While operational complexity exists due to the Lambda function setup, it...
Author: Sophia Clark · Last updated May 13, 2026
A company is designing an AWS environment for a manufacturing application. The application has been successful with customers, and the application's user base has increased. The company has connected the AWS environment to the company's on-premises data center through a 1 Gbps AWS Direct Connect connection. The company has configured BGP for the connection.
The company must update the existing net...
In this case, the company needs a solution that ensures high availability, fault tolerance, and security while being cost-effective. Let’s break down each option:
Option A: Add a dynamic private IP AWS Site-to-Site VPN as a secondary path to secure data in transit and provide resilience for the Direct Connect connection. Configure MACsec to encrypt traffic inside the Direct Connect connection.
- Pros:
- Adding a dynamic private IP AWS Site-to-Site VPN creates a secondary path for failover if the Direct Connect connection fails, ensuring high availability.
- The use of MACsec within Direct Connect ensures traffic encryption, increasing security.
- Cons:
- MACsec encryption on Direct Connect could increase costs (as MACsec typically requires additional hardware and can introduce complexity).
- While this solution does provide resilience, maintaining and monitoring two separate connections (Direct Connect and VPN) might be more complex and costly, particularly because Site-to-Site VPN connections, although inexpensive, add additional operational complexity.
Option B: Provision another Direct Connect connection between the company's on-premises data center and AWS to increase the transfer speed and provide resilience. Configure MACsec to encrypt traffic inside the Direct Connect connection.
- Pros:
- A second Direct Connect connection offers high availability and increased resilience.
- Direct Connect connections provide a dedicated, low-latency link to AWS, offering reliability.
- MACsec encryption increases security for data in transit.
- Cons:
- This solution requires provisioning an additional Direct Connect link, which incurs additional cost (Direct Connect is expensive to provision and maintain).
- Does not significantly reduce operational complexity, as you still need to manage two Direct Connect links.
Option C: Configure multiple private VIFs. Load balance data across the VIFs between the on-premises data center and AWS to provide resilience.
- Pros:
- Multiple Virtual Interfaces (VIFs) allow load balancing and provide a l...
Author: Emily · Last updated May 13, 2026
A company needs to modernize an application and migrate the application to AWS. The application stores user profile data as text in a single table in an on-premises MySQL database.
After the modernization, users will use the application to upload video files that are up to 4 GB in size. Other users must be able to download the video files from the application. The company...
To determine the best solution for modernizing and migrating the application to AWS while meeting the given requirements, let's analyze the key requirements:
- Storing large video files (up to 4 GB): The solution must be able to store large video files without affecting application performance.
- Rapid scaling: The solution must scale effectively as the number of videos increases.
- Separation of video storage from user profile data: Storing large video files directly in a database as base64-encoded strings or other inefficient storage methods is generally not ideal, as it can result in bloated database size and slow performance.
- Application performance: Storing videos directly in a database can affect performance; therefore, a solution that allows efficient video storage without compromising the database’s performance is necessary.
Let's evaluate each option:
Option A: Migrate the database to Amazon Aurora PostgreSQL by using AWS Database Migration Service (AWS DMS). Store the videos as base64-encoded strings in a TEXT column in the database.
- Pros: Amazon Aurora PostgreSQL provides a highly scalable database service, and it is a managed service, making migration easier.
- Cons: Storing videos as base64-encoded strings in the database is highly inefficient. Base64 encoding increases the size of the video by about 33%. Additionally, storing large files like videos directly in the database will impact database performance significantly, especially for retrieval and management. This approach will not scale well and would cause serious performance bottlenecks.
- Conclusion: This option is not ideal for storing large video files as it will adversely impact performance and scaling.
Option B: Migrate the database to Amazon DynamoDB by using AWS Database Migration Service (AWS DMS) with the AWS Schema Conversion Tool (AWS SCT). Store the videos as objects in Amazon S3. Store the S3 key in the corresponding DynamoDB item.
- Pros:
- Amazon DynamoDB is a highly scalable NoSQL database that can efficiently handle the application’s user profile data.
- Storing the videos in Amazon S3 is a great choice because S3 is designed for scalable, durable, and cost-effective object storage.
- The application can store only the S3 key in DynamoDB, which reduces the load on the database and optimizes performance.
- Amazon S3 provides rapid scaling for large file storage, ensuring that video file storage grows as needed without im...
Author: Sofia · Last updated May 13, 2026
A company stores and manages documents in an Amazon Elastic File System (Amazon EFS) file system. The file system is encrypted with an AWS Key Management Service (AWS KMS) key. The file system is mounted to an Amazon EC2 instance that runs proprietary software.
The company has enabled automatic backups for the file system. The automatic backups use the AWS Backup default bac...
To meet the company's requirement of recovering deleted documents within an RPO of 100 minutes, let's carefully evaluate each option in terms of the necessary backup and recovery strategies.
Key Requirements:
- RPO of 100 minutes: The company needs to recover data with minimal latency, i.e., within 100 minutes of deletion.
- Amazon EFS encrypted with KMS: The backup must ensure that encrypted files remain accessible and recoverable.
- Automatic backups: The company already uses AWS Backup with the default backup plan, but improvements are required to meet the RPO.
A) Create a new IAM role. Create a new backup plan. Use the new IAM role to create backups. Update the KMS key policy to allow the new IAM role to use the key. Implement an hourly backup schedule for the file system.
- Analysis:
- Hourly backup schedule: With backups only occurring every hour, this schedule would result in an RPO of 60 minutes (at best), but it does not meet the strict 100-minute RPO requirement. While close, it’s not sufficient to guarantee recovery within 100 minutes.
- The creation of a new IAM role and backup plan would add complexity but would not address the critical need for more frequent backups to meet the required RPO.
- Conclusion: While it may improve backup management, an hourly backup schedule does not guarantee recovery within the required RPO of 100 minutes. (Rejected)
B) Create a new backup plan. Update the KMS key policy to allow the AWSServiceRoleForBackup IAM role to use the key. Implement a custom cron expression to run a backup of the file system every 30 minutes.
- Analysis:
- Backup every 30 minutes: A backup every 30 minutes would meet the RPO of 100 minutes, as it ensures that recovery is possible within the window of 100 minutes. This frequency offers a better chance of meeting the required recovery time.
- Updating the KMS key policy is necessary to allow the AWS Backup service to access the encrypted EFS file system and backup the data, which is a valid requirement.
- Conclusion: This option meets the 100-minute RPO requirement by...
Author: Ella · Last updated May 13, 2026
A solutions architect must provide a secure way for a team of cloud engineers to use the AWS CLI to upload objects into an Amazon S3 bucket. Each cloud engineer has an IAM user, IAM access keys, and a virtual multi-factor authentication (MFA) device. The IAM users for the cloud engineers are in a group that is ...
In this scenario, the goal is to ensure that the cloud engineers can only perform actions in Amazon S3 if they use Multi-Factor Authentication (MFA), and the solution must integrate well with the AWS CLI for operations like uploading objects into an S3 bucket.
Let's go over each option:
Option A: Attach a policy to the S3 bucket to prompt the IAM user for an MFA code when the IAM user performs actions on the S3 bucket. Use IAM access keys with the AWS CLI to call Amazon S3.
- Pros: This option tries to enforce MFA but does so at the S3 bucket level, which is not how AWS typically enforces MFA for actions through IAM policies. Policies tied to the S3 bucket cannot directly enforce MFA authentication.
- Cons: The S3 bucket policy cannot prompt for MFA directly. MFA must be enforced using IAM policies. Bucket policies are used for managing access to S3 resources and cannot trigger MFA prompts.
- Conclusion: This option will not work as intended because MFA enforcement needs to be done using IAM policies, not S3 bucket policies.
Option B: Update the trust policy for the S3-access group to require principals to use MFA when principals assume the group. Use IAM access keys with the AWS CLI to call Amazon S3.
- Pros: This option suggests requiring MFA for assumed roles (if the user assumes a role), but it doesn’t directly address MFA enforcement for IAM users within the S3-access group.
- Cons: This option modifies the trust policy for assuming roles, but the cloud engineers are not assuming a role in this case. The focus should be on enforcing MFA for the IAM users themselves, not roles.
- Conclusion: This solution is not applicable since the cloud engineers are IAM users, not assuming roles.
Option C: Attach a policy to the S3-access group to deny all S3 actions unless MFA is present. Use IAM access keys with the AWS CLI to call Amazon S3.
- Pros: This solution uses an IAM policy to enforce MFA for S3 actions, which is the correct way to require MFA. By denying a...
Author: FrostFalcon88 · Last updated May 13, 2026
A company needs to migrate 60 on-premises legacy applications to AWS. The applications are based on the NET Framework and run on Windows.
The company needs a solution that minimizes migration time and requires no application code changes. Th...
The company needs to migrate 60 legacy applications that are based on the .NET Framework and run on Windows. The requirements are:
1. Minimize migration time: The company doesn't want to spend a lot of time making changes to the existing applications.
2. No application code changes: The legacy applications should be moved as-is without needing any code modifications.
3. No infrastructure management: The company does not want to manage the infrastructure manually.
Let’s analyze each option:
Option A: Refactor the applications and containerize them by using AWS Toolkit for .NET Refactoring. Use Amazon Elastic Container Service (Amazon ECS) with the Fargate launch type to host the containerized applications.
- Pros:
- Containerization using the AWS Toolkit for .NET Refactoring allows the company to move the applications without changing the code.
- Amazon ECS with Fargate allows the company to run containers without managing the underlying infrastructure, as Fargate abstracts infrastructure management.
- Cons:
- Containerization and refactoring are involved in this solution, and while it may reduce management overhead, it still requires time and effort to refactor the applications and make them containerized.
- This might introduce complexity because containerizing legacy .NET Framework applications that were not designed for containers could require additional testing and configuration adjustments, even if no code changes are needed.
- Conclusion: While ECS with Fargate is a great solution for containerized workloads, the refactoring and containerization process may still be time-consuming and involve work beyond what is strictly required (no code changes).
Option B: Use the Windows Web Application Migration Assistant to migrate the applications to AWS Elastic Beanstalk. Use Elastic Beanstalk to deploy and manage the applications.
- Pros:
- AWS Elastic Beanstalk is a Platform as a Service (PaaS) solution that abstracts infrastructure management, which meets the requirement of "no infrastructure management."
- Windows Web Application Migration Assistant is a tool designed for migrating Windows-based applications to Elastic Beanstalk, which can help reduce migration time.
- It allows the applications to run on Windows-based environments, which is suitable for .NET Framework applications.
- Cons:
- Elastic Beanstalk may not be the best choice if the applications have complex dependencies or are not easily containerized for PaaS environments.
- While it’s a simplified platform, Elastic Beanstalk may still require some level of configuration, and migrating legacy applications directly to Elastic Beanstalk...
Author: William · Last updated May 13, 2026
A company needs to run large batch-processing jobs on data that is stored in an Amazon S3 bucket. The jobs perform simulations. The results of the jobs are not time sensitive, and the process can withstand interruptions.
Each job must process 15-20 GB of data when the data is stored in the S3 bucket. The company will store the o...
To determine the most cost-effective solution for running large batch-processing jobs with non-time-sensitive data, we must consider the requirements and constraints provided:
Key Requirements:
- The jobs are non-time-sensitive and can withstand interruptions.
- The jobs need to process 15-20 GB of data stored in Amazon S3.
- The output from the jobs will be stored in another S3 bucket for further analysis.
- Cost-effectiveness is a priority.
Option Analysis:
A) Create a serverless data pipeline. Use AWS Step Functions for orchestration. Use AWS Lambda functions with provisioned capacity to process the data.
- Pros:
- Serverless architecture reduces infrastructure management.
- AWS Lambda can automatically scale.
- Cons:
- AWS Lambda has a payload limit of 6 MB (or 256 MB for Lambda@Edge), which is far smaller than the 15-20 GB data per job. Processing this large amount of data in Lambda is impractical, making it unsuitable for the described batch jobs.
B) Create an AWS Batch compute environment that includes Amazon EC2 Spot Instances. Specify the SPOT_CAPACITY_OPTIMIZED allocation strategy.
- Pros:
- EC2 Spot Instances are significantly cheaper than On-Demand Instances and are ideal for non-time-sensitive jobs.
- The SPOT_CAPACITY_OPTIMIZED allocation strategy helps improve the likelihood of Spot Instance availability by optimizing capacity.
- Cons:
- Spot Instances can be interrupted, which might require job retries. However, the jobs are non-time-sensitive and can withstand interruptions.
- While cost-effective, this option requires managing retries and job interruptions, which adds complexity but remains feasible for this case.
C) Cr...
Author: Aarav · Last updated May 13, 2026
A company has an application that analyzes and stores image data on premises. The application receives millions of new image files every day. Files are an average of 1 MB in size. The files are analyzed in batches of 1 GB. When the application analyzes a batch, the application zips the images together. The application then archives the images as a single file in an on-premises NFS server for long-term storage.
The company has a Microsoft Hyper-V environment on premises and has compute capacity available. The company does not have storage capacity and wants to archive the images on AWS. The company needs the ability to retrieve archived data within 1 week of a request....
Key Requirements and Constraints:
- The company needs to archive millions of 1 MB image files every day.
- The files are analyzed in batches of 1 GB.
- The company wants to store the images in AWS for long-term archiving.
- Retrieval of archived data needs to occur within 1 week of a request.
- The company has a 10 Gbps AWS Direct Connect connection.
- The company requires bandwidth limits and the ability to schedule copying during non-business hours.
- The company does not have storage capacity on-premises, and they want the archived data to be managed in the cloud efficiently.
Option Analysis:
A) Deploy an AWS DataSync agent on a new GPU-based Amazon EC2 instance. Configure the DataSync agent to copy the batch of files from the NFS on-premises server to Amazon S3 Glacier Instant Retrieval. After the successful copy, delete the data from the on-premises storage.
- Pros:
- S3 Glacier Instant Retrieval provides fast access to archived data, which is not needed since the data retrieval is within a 1-week window.
- DataSync is a high-speed tool that can efficiently copy data from on-premises to AWS.
- Cons:
- GPU-based EC2 instances are unnecessarily expensive for this use case, as there is no need for GPU processing in the image archiving task.
- S3 Glacier Instant Retrieval is designed for more frequent access, which is not required in this case. It is more expensive than necessary for long-term storage.
B) Deploy an AWS DataSync agent as a Hyper-V VM on premises. Configure the DataSync agent to copy the batch of files from the NFS on-premises server to Amazon S3 Glacier Deep Archive. After the successful copy, delete the data from the on-premises storage.
- Pros:
- AWS DataSync agent as a VM on Hyper-V fits the company’s existing infrastructure.
- S3 Glacier Deep Archive is the most cost-effective long-term storage option, ideal for data that is rarely accessed and can withstand a retrieval time of up to 12 hours (well within the 1-week retrieval requirement).
- The company can use bandwidth throttling and scheduling during non-business hours.
- Cons:
- Data retrieval from S3 Glacier Deep Archive...
Author: John · Last updated May 13, 2026
A company wants to record key performance indicators (KPIs) from its application as part of a strategy to convert to a user-based licensing schema. The application is a multi-tier application with a web-based UI. The company saves all log files to Amazon CloudWatch by using the CloudWatch agent. All logins to the application are saved in a log file.
As part of the new license schema, the company needs to find ou...
The company needs a solution to track the number of unique users for each client on a daily, weekly, and monthly basis without significant changes to the existing application. Let's evaluate the options based on the requirements and their impact on the application.
Key Requirements:
1. Track unique users: The company needs to track the number of unique users for each client.
2. Time-based tracking: The tracking should be done on a daily, weekly, and monthly basis.
3. Minimal changes to the application: The solution should require the least modification to the existing application, which already sends log files to Amazon CloudWatch using the CloudWatch agent.
A) Configure an Amazon CloudWatch Logs metric filter that saves each successful login as a metric. Configure the user name and client name as dimensions for the metric.
- Analysis:
- Metric filters in CloudWatch Logs allow you to search for specific log patterns and generate custom metrics based on those patterns.
- This approach can work well for detecting successful logins from the log file. By using the user name and client name as dimensions, you can track the number of logins per user and per client.
- However, CloudWatch metric filters are not directly suited for tracking unique users over time. The filter will count the number of events (logins), but it will not guarantee uniqueness because it might count multiple logins from the same user.
- This solution is useful for counting occurrences but would need additional steps or storage for tracking unique users.
- Conclusion: While this solution provides a count of logins, it doesn’t track unique users directly and would require additional processing. (Rejected)
B) Change the application logic to make each successful login generate a call to the AWS SDK to increment a custom metric that records user name and client name dimensions in CloudWatch.
- Analysis:
- This approach requires modifying the application logic to make calls to the AWS SDK every time a user logs in, which goes against the goal of minimizing changes to the application.
- While this would allow you to track user logins and include custom dimensions like user name and client name, modifying the application introduces more complexity and operational overhead.
- Additionally, making SDK calls for each login introduces potential performance overhead and unnecessary changes to the existing application.
- Conclusion: This solution introduces significant changes to the application and adds complexity without providing additional bene...
Author: Noah · Last updated May 13, 2026
A company is using GitHub Actions to run a CI/CD pipeline that accesses resources on AWS. The company has an IAM user that uses a secret key in the pipeline to authenticate to AWS. An existing IAM role with an attached policy grants the required permissions to deploy resources.
The company's security team implements a new requirement that pipelines can no longer use long-lived secret ...
Key Requirements:
- Replace long-lived secret keys with a solution for short-lived credentials.
- Minimal operational overhead is preferred.
- The pipeline should still have the ability to authenticate to AWS and assume roles to deploy resources.
Option Analysis:
A) Create an IAM SAML 2.0 identity provider (IdP) in AWS Identity and Access Management (IAM). Create a new IAM role with the appropriate trust policy that allows the sts:AssumeRole API call. Attach the existing IAM policy to the new IAM role. Update GitHub to use SAML authentication for the pipeline.
- Pros:
- SAML 2.0 is a standard identity federation mechanism and can work well for enterprise applications.
- It supports federated login and temporary credentials.
- Cons:
- SAML is generally more complex to implement compared to other options, especially in the context of GitHub Actions. The integration would require setting up a SAML identity provider and the pipeline to authenticate using SAML, which adds overhead.
- This method can be more complex to manage than alternatives like OIDC, making it less ideal for a CI/CD pipeline with minimal operational overhead.
B) Create an IAM OpenID Connect (OIDC) identity provider (IdP) in AWS Identity and Access Management (IAM). Create a new IAM role with the appropriate trust policy that allows the sts:AssumeRoleWithWebIdentity API call from the GitHub OIDC IdP. Update GitHub to assume the role for the pipeline.
- Pros:
- OIDC with GitHub Actions is a simple and modern solution for replacing long-lived secret keys. GitHub natively supports OIDC authentication, so there’s minimal setup required.
- The trust policy for the IAM role can be configured to accept web identity tokens issued by GitHub’s OIDC provider. This is a short-lived and highly secure solution.
- It is a well-integrated, native solution that works seamlessly with GitHub Actions, and it does not require managing secrets.
- Cons:
- None significant, as this is one of the best solutions in terms of simplicity, scalability, and security.
...
Author: Liam · Last updated May 13, 2026
A company is running a web-crawling process on a list of target URLs to obtain training documents for machine learning training algorithms. A fleet of Amazon EC2 t2.micro instances pulls the target URLs from an Amazon Simple Queue Service (Amazon SQS) queue. The instances then write the result of the crawling algorithm as a .csv file to an Amazon Elastic File System (Amazon EFS) volume. The EFS volume is mounted on all instances of the fleet.
A separate system adds the URLs to the SQS queue at infrequent rates. The instances crawl each URL in 10 seconds or less.
Met...
Key Requirements:
- Optimize costs by minimizing idle time and resource consumption.
- The fleet of EC2 t2.micro instances is idle when there are no URLs to crawl, which increases costs.
- The process needs to be efficient and cost-effective given the infrequent rate of new URLs being added to the SQS queue.
- The results of the crawling process need to be stored.
Option Analysis:
A) Use m5.8xlarge instances instead of t2.micro instances for the web-crawling process. Reduce the number of instances in the fleet by 50%.
- Pros:
- m5.8xlarge instances provide more CPU and memory than t2.micro, which may improve processing speed.
- Reducing the number of instances by 50% seems to reduce costs in the short term.
- Cons:
- Expensive solution: Using m5.8xlarge instances for web crawling would increase costs significantly, especially given the infrequent rate of URLs. The larger instances would still be idle when there are no URLs, resulting in wasted resources.
- This is not the most cost-effective solution since the goal is to minimize idle time and resource utilization, and this change only increases costs without addressing the root cause (idle time due to infrequent URLs).
B) Convert the web-crawling process into an AWS Lambda function. Configure the Lambda function to pull URLs from the SQS queue.
- Pros:
- Lambda is serverless, so it only runs when there are URLs to crawl, eliminating idle time and the need for continuously running EC2 instances.
- It automatically scales, so if there are no URLs, no compute resources are being used, which reduces costs.
- You pay for only the execution time, which is a more cost-efficient solution for this use case.
- AWS Lambda integrates well with SQS, and it can pull URLs from the queue and process them directly.
- Cons:
- Lambda has some limitations (e.g., execution time limits of 15 minutes), but it should work well for crawling tasks that take 10 seconds or less.
- Lambda functions would require a slight modification in the process to fit within its execution model, but this will ultimately result in lower operational overhead and cost.
- Conclusion: This option is highly cost-effective...
Author: Amira · Last updated May 13, 2026
A company needs to migrate its website from an on-premises data center to AWS. The website consists of a load balancer, a content management system (CMS) that runs on a Linux operating system, and a MySQL database.
The CMS requires persistent NFS-compatible storage for a file system. The new solution on AWS must be able to scale from 2 Amazon EC2 instances to 30 EC2 instances in response to...
Let's break down the key requirements:
1. No changes to the website: This implies that the architecture must be compatible with the existing CMS, MySQL, and load balancing setup.
2. Persistent NFS-compatible storage: The CMS needs access to a persistent shared storage system that is compatible with the NFS protocol.
3. Scalable from 2 to 30 EC2 instances: The solution must automatically scale up and down with varying traffic loads.
4. Prevent data loss: Any database or file storage solution must ensure that data is retained in the event of instance failures or scaling events.
Now, let’s evaluate the options:
---
Option A: EFS, Elastic Beanstalk, Aurora MySQL
- Amazon Elastic File System (EFS): This is a managed NFS-compatible file system, which meets the requirement for persistent shared storage.
- Elastic Beanstalk: This service simplifies deployment and scaling, and it supports Auto Scaling groups. It also automatically integrates with an Application Load Balancer.
- Amazon Aurora MySQL: This is a fully managed, scalable relational database, which ensures high availability and data durability. Aurora can also handle scaling, which is a requirement here.
Why this works:
- EFS provides NFS-compatible persistent storage.
- Elastic Beanstalk simplifies scaling from 2 to 30 EC2 instances without the need for manual intervention.
- Aurora MySQL provides a highly available and managed MySQL database, which is crucial to prevent data loss.
Why not others:
- This solution matches all the requirements and uses fully managed AWS services.
---
Option B: EBS Multi-Attach, Elastic Beanstalk, RDS MySQL
- EBS Multi-Attach: Allows an EBS volume to be attached to multiple EC2 instances, which may provide persistence, but it’s not NFS-compatible. This is an issue, as the CMS requires NFS storage.
- Elastic Beanstalk: As in Option A, this simplifies the scaling process.
- Amazon RDS for MySQL: A managed My...
Author: RadiantJaguar56 · Last updated May 13, 2026
A company needs to implement disaster recovery for a critical application that runs in a single AWS Region. The application's users interact with a web frontend that is hosted on Amazon EC2 instances behind an Application Load Balancer (ALB). The application writes to an Amazon RDS for MySQL DB instance. The application also outputs processed documents that are stored in an Amazon S3 bucket.
The company's finance team directly queries the database to run reports. During busy periods, these queries consume resources and negatively affect application performance.
A solutions ...
To solve the disaster recovery problem while also addressing performance issues caused by the office team's database queries, let’s analyze the requirements and evaluate each option.
Key Requirements:
1. Disaster Recovery (DR): Ensure that the application remains operational during a disaster, with minimal downtime and data loss.
2. Minimize Data Loss: The solution should prevent data loss, particularly for the RDS database and S3 bucket.
3. Resolve Performance Issues: Address the problem where the office team's queries negatively affect application performance.
4. Seamless Transition: The application should be able to recover quickly in the event of a disaster with minimal manual intervention.
Option A: Migrate to DynamoDB, Use Global Tables, S3 Replication
- DynamoDB: This option suggests migrating the database from RDS MySQL to Amazon DynamoDB. While DynamoDB is a NoSQL database with strong scalability, it would require significant application changes, especially since the application relies on MySQL. Migrating away from MySQL would likely involve a major reengineering effort.
- Global Tables: While DynamoDB Global Tables provide disaster recovery with replication across multiple regions, this introduces complexity and would not resolve the issue of running reports against the MySQL database.
- Lambda Syncing S3: Using Lambda to periodically sync S3 buckets across regions would replicate the data, but there are better ways to ensure S3 data availability without introducing a new technology stack like DynamoDB.
Why not this option?
- The need to migrate to DynamoDB would require substantial changes to the application and the MySQL database, making it an inappropriate solution. Additionally, using DynamoDB doesn't align with minimizing data loss in the MySQL database.
---
Option B: Read Replica, Read Queries Against Replica, S3 Replication
- Read Replica: Creating a read replica of the RDS MySQL database in another region addresses both disaster recovery and performance concerns. The read replica can handle the office team's read queries without impacting the primary database performance, and in case of a disaster, it can be promoted to the primary database.
- S3 Cross-Region Replication (CRR): CRR ensures that the data in the S3 bucket is replicated to another region, which provides a backup in case of a regional failure.
- Disaster Recovery: During a disaster, the read replica can be promoted to a primary DB instance, and the application can switch to the replicated S3 bucket.
Why this works?
- The solution minimizes data loss by providing cross-region replication for both the database and S3 data.
- The read replica alleviates performance issues by offloading report queries from the primary database to the replica.
- This solution is fully compatible with the existing application setup, requiring minimal changes.
---
Option C: Read Replica, S3 Replication, AMIs for EC2
- Read R...
Author: Lucas · Last updated May 13, 2026
A company has many services running in its on-premises data center. The data center is connected to AWS using AWS Direct Connect (DX) and an IPSec VPN. The service data is sensitive and connectivity cannot traverse the internet. The company wants to expand into a new market segme...
To meet the requirements of expanding the company's services to other AWS users while ensuring the connectivity does not traverse the internet, let's break down the needs and evaluate each option.
Key Requirements:
1. Sensitive Data: The data is sensitive, meaning it cannot traverse the public internet.
2. Connectivity over AWS Direct Connect (DX): The existing connection to AWS is via AWS Direct Connect (DX) and an IPSec VPN. This ensures private, dedicated connections that do not traverse the internet.
3. Offer Services to Other Companies Using AWS: The company wants to make its services available to other AWS customers, which likely involves allowing them to access the service securely.
Option A: VPC Endpoint Service with TCP Traffic and Network Load Balancer (NLB)
- VPC Endpoint Service: This allows services to be made available to other AWS customers securely over private connections, using the AWS PrivateLink technology.
- TCP Traffic: The VPC Endpoint Service can accept TCP traffic, which makes it flexible for various types of services, not limited to HTTP/S protocols.
- Network Load Balancer (NLB): This is an ideal choice for handling TCP traffic because NLB is designed to handle high-performance, low-latency TCP traffic.
- Available Over DX: The VPC Endpoint Service can be connected to via AWS Direct Connect, ensuring that the traffic does not traverse the internet but instead uses the private connection.
Why this works:
- Private Connectivity: The service is accessible securely and privately using Direct Connect and does not require internet traversal.
- Scalability and Security: PrivateLink ensures that the service is securely exposed to other AWS accounts without exposing the internal network to the internet.
Why not others?
- This solution fits the requirement of securely offering services to other AWS customers without exposing traffic to the internet.
---
Option B: VPC Endpoint Service with HTTP/HTTPS Traffic and Application Load Balancer (ALB)
- VPC Endpoint Service with HTTP/HTTPS Traffic: This would work for web-based services that require HTTP/HTTPS.
- Application Load Balancer (ALB): ALB is suitable for handling HTTP/HTTPS traffic and provides advanced routing features (e.g., path-based routing).
- Available Over DX: The VPC Endpoint Service can still be connected through Direct Connect.
Why this works:
...
Author: James · Last updated May 13, 2026
A company uses AWS Organizations to manage its AWS accounts. A solutions architect must design a solution in which only administrator roles are allowed to use IAM actions. However, the solutions architect does not have access to all the AWS accoun...
To meet the company's requirement of allowing only administrator roles to use IAM actions across all AWS accounts with the least operational overhead, let's analyze each option carefully.
Key Requirements:
1. Restrict IAM actions: Only administrator roles should be allowed to perform IAM actions.
2. Minimal operational overhead: The solution must be easy to implement and maintain, considering the company uses AWS Organizations and the solutions architect doesn't have access to all AWS accounts.
3. Account-wide application: The solution needs to apply across all AWS accounts managed under the AWS Organization.
A) Create an SCP that applies to all the AWS accounts to allow IAM actions only for administrator roles. Apply the SCP to the root OU.
- Analysis:
- Service Control Policies (SCPs) are used to manage permissions in AWS Organizations. However, SCPs allow or deny actions across accounts at an organizational level.
- The key challenge here is that SCPs cannot allow actions only for a specific set of roles (like administrator roles) but rather define the overall allowed or denied actions.
- Allowing IAM actions only for administrator roles cannot be directly implemented via SCPs since SCPs operate on actions and not specific IAM roles.
- Conclusion: This approach would not work because SCPs cannot target specific roles for permission grants or denials, and thus cannot restrict IAM actions to only administrator roles. (Rejected)
B) Configure AWS CloudTrail to invoke an AWS Lambda function for each event that is related to IAM actions. Configure the function to deny the action if the user who invoked the action is not an administrator.
- Analysis:
- AWS CloudTrail can log IAM actions, and Lambda can be used to process events from CloudTrail.
- While this solution may seem viable, it would add significant complexity and operational overhead. This setup would require creating a Lambda function, monitoring CloudTrail logs, and taking action dynamically, all of which adds complexity. It also may introduce delays in processing IAM actions because the actions would need to be intercepted and checked after the fact.
- Additionally, maintaining such a Lambda-based solution across multiple AWS accounts would be cumbersome, especially without access to all the accounts.
- Conclusion: While technically feasible, this approach introduces unnecessary operational overhead and is less efficien...
Author: Samuel · Last updated May 13, 2026
A company uses an organization in AWS Organizations to manage multiple AWS accounts. The company hosts some applications in a VPC in the company's shared services account.
The company has attached a transit gateway to the VPC in the shared services account.
The company is developing a new capability and has created a development environment that requires access to the applications that are in the shared services account. The company intends to delete and recreate resources frequently i...
Problem Analysis:
- The company has a shared services account hosting applications in a VPC, and a development account needs frequent access to these applications.
- The development team needs the ability to recreate the connection to the shared services account as resources are deleted and recreated frequently in the development environment.
- The solution must allow self-service for the development team to manage the connection to the shared services account.
Key Requirements:
1. Recreate Resources: The development team needs the ability to delete and recreate resources, including the connection, frequently.
2. Self-Service: The development team should be able to manage their connection to the shared services account independently.
3. Minimal Manual Interventions: The solution should allow the team to quickly re-establish the connection without requiring manual intervention from others.
---
Option A: Create a transit gateway in the development account and peer it with the shared services account
- Transit Gateway Peering: This involves creating a new transit gateway in the development account and peering it with the shared services account's transit gateway.
- Manual Setup: While peering requests can be automated, there would still be manual setup required for both sides of the peering, and you need to ensure that the shared services account is configured to accept peering requests automatically.
- Frequent Recreation: Since the development environment involves frequent deletion and recreation of resources, managing the peering manually each time can become cumbersome.
Why not this option?
- While the solution could work, it does not fully meet the need for self-service and ease of re-establishment, as it involves manual configuration each time a new connection is required.
---
Option B: Use AWS RAM to share the transit gateway and create a transit gateway attachment in the development account
- Resource Sharing with AWS RAM: AWS RAM can be used to share the transit gateway from the shared services account to the development account. This allows the development account to use the shared transit gateway without needing to create a new one.
- Automatic Acceptance: Automatic acceptance of resource sharing in AWS RAM ensures the connection is readily available in the development account, which is a good fit for self-service.
- Frequent Recreation: This solution allows the development team to accept the shared resource and attach it to their VPC whenever needed, supporting the frequent creation and deletion of resources in the development account.
Why this works:
- Minimal Manual Configuration: This solution meets the self-service requirement because the development account can accept the resource and manage the attachment without needing manual intervention.
- Frequent Resource D...
Author: Daniel · Last updated May 13, 2026
A company wants to migrate virtual Microsoft workloads from an on-premises data center to AWS. The company has successfully tested a few sample workloads on AWS. The company also has created an AWS Site-to-Site VPN connection to a VPC. A solutions architect needs to generate a total cost of ownership (TCO) report for the migration of all the workloads from the data center.
Simple Network Management Protocol (SNMP) has been enabled on each VM in the data center. The company can...
To meet the company's requirements, the solution must allow for the automatic import of discovery data into AWS Migration Hub, the ability to generate a TCO report, and it must work without installing additional software on the existing virtual machines (VMs). The company has already enabled SNMP on each VM, which allows for monitoring but does not enable any additional agents or software installations.
Let’s break down the options:
A) Use the AWS Application Migration Service agentless service and the AWS Migration Hub Strategy Recommendations to generate the TCO report.
- The AWS Application Migration Service allows for the migration of workloads to AWS, but it’s more focused on replicating and migrating workloads, rather than generating a TCO report.
- While AWS Migration Hub Strategy Recommendations can help plan a migration strategy, it doesn’t directly facilitate automatic discovery of the VMs in the on-premises data center, and it doesn't have a built-in mechanism to generate the TCO report by itself.
- This option is not ideal because the Application Migration Service focuses on migration itself, and doesn't offer automatic TCO reporting through the existing setup.
B) Launch a Windows Amazon EC2 instance. Install the Migration Evaluator agentless collector on the EC2 instance. Configure Migration Evaluator to generate the TCO report.
- This option involves launching an EC2 instance and installing the Migration Evaluator agentless collector, which is specifically designed to assess existing on-premises workloads for migration to AWS and generate a TCO report.
- It works in an agentless manner by using SNMP data from the VMs to import discovery data into AWS Migration Hub. However, the option mentions installing software on the EC2 instance, which might conflict with the requirement that no additional software be installed on the VMs themselves.
- This solution works for gathering the necessary data from the data center but might not complet...
Author: Maya · Last updated May 13, 2026
A company that is developing a mobile game is making game assets available in two AWS Regions. Game assets are served from a set of Amazon EC2 instances behind an Application Load Balancer (ALB) in each Region. The company requires game assets to be fetched from the closest Region. If game assets become unavailable ...
The company's requirements are:
- Serve game assets from the closest Region to the player.
- If the assets become unavailable in the closest Region, fall back to the other Region.
Let’s evaluate each option:
A) Create an Amazon CloudFront distribution. Create an origin group with one origin for each ALB. Set one of the origins as primary.
- CloudFront is a content delivery network (CDN) that caches assets at edge locations, improving performance.
- An origin group in CloudFront can allow failover between multiple origins (ALBs in this case). This option seems to fulfill the requirement of fetching assets from the closest Region, and if one Region becomes unavailable, CloudFront can automatically failover to the secondary Region.
- This option is solid because CloudFront inherently supports caching and can automatically failover between multiple ALBs via origin groups, ensuring both proximity and availability.
B) Create an Amazon Route 53 health check for each ALB. Create a Route 53 failover routing record pointing to the two ALBs. Set the Evaluate Target Health value to Yes.
- Route 53 failover routing enables directing traffic to a primary resource, with failover to a secondary resource if the primary fails, based on health checks.
- This setup will make sure that if one ALB becomes unavailable, the traffic is routed to the other ALB. However, failover routing is not designed for latency-based routing, and it doesn't ensure the game assets are served from the closest Region; it only responds to availability issues.
- This option would work for availability but does not address latency concerns of serving assets from the closest Region.
C) Create two Amazon CloudFront distributions, each with one ALB as the origin. Create an Amazon Route 53 failover routing record pointing to the two CloudFront distributions....
Author: Siddharth · Last updated May 13, 2026
A company deploys workloads in multiple AWS accounts. Each account has a VPC with VPC flow logs published in text log format to a centralized Amazon S3 bucket. Each log file is compressed with gzip compression. The company must retain the log files indefinitely.
A security engineer occasionally analyzes the logs by using Amazon Athena to query the VPC flow logs. The query performance is degrading over time as the number of ingested logs is growing. A solutions ar...
To improve performance when querying VPC flow logs with Athena and reduce storage space usage, it's important to focus on both data storage format optimization and query efficiency. Let’s analyze each option based on these goals:
A) Create an AWS Lambda function to decompress the gzip files and to compress the files with bzip2 compression. Subscribe the Lambda function to an s3:ObjectCreated:Put S3 event notification for the S3 bucket.
- Lambda decompression: While decompressing files and changing compression formats (from gzip to bzip2) could slightly improve query performance, it’s unlikely to provide significant performance improvements in Athena. Both gzip and bzip2 are compression formats, but compression format optimization alone won't make a big difference for Athena queries.
- Inefficient and unnecessary: Decompressing and recompressing logs adds unnecessary complexity, and this approach doesn't address Athena’s need for efficient query execution on structured data.
- Query performance: The major bottleneck in Athena performance is how the data is organized and partitioned, not just the compression format.
B) Enable S3 Transfer Acceleration for the S3 bucket. Create an S3 Lifecycle configuration to move files to the S3 Intelligent-Tiering storage class as soon as the files are uploaded.
- S3 Transfer Acceleration: This feature accelerates the transfer of data into S3, but it doesn’t affect the performance of Athena queries. It’s more about improving upload speed, not the actual query performance.
- S3 Intelligent-Tiering: This storage class automatically moves data between frequent and infrequent access tiers based on usage patterns, but this does not help with optimizing query performance in Athena.
- Not related to Athena performance: Transfer acceleration and storage class changes don’t address the issue of improving query performance when querying large datasets in Athena.
C) Update the VPC flow log configuration to store the files in Apache Parquet format. Specify hourly partitions for the lo...
Author: Lucas Carter · Last updated May 13, 2026
A company wants to establish a dedicated connection between its on-premises infrastructure and AWS. The company is setting up a 1 Gbps AWS Direct Connect connection to its account VPC. The architecture includes a transit gateway and a Direct Connect gateway to connect multiple VPCs and the on-premises infrastructure.
The company must connect ...
In this scenario, the company is setting up AWS Direct Connect to establish a dedicated connection between its on-premises infrastructure and AWS. The architecture involves a transit gateway and a Direct Connect gateway to connect multiple VPCs and the on-premises infrastructure. The company needs to connect to VPC resources over a transit virtual interface (VIF) using the Direct Connect connection.
Let’s evaluate each option:
A) Update the 1 Gbps Direct Connect connection to 10 Gbps.
- Unnecessary change: The company is using a 1 Gbps Direct Connect connection, but there’s no specific mention that the 1 Gbps connection is insufficient or a bottleneck. If the connection meets the needs of the workloads and the performance requirements, there is no need to upgrade to 10 Gbps unless there is a known performance issue or capacity requirement.
- Not related to meeting the transit VIF connection requirement: Increasing the connection speed to 10 Gbps won’t impact the ability to connect to VPC resources over the transit VIF.
B) Advertise the on-premises network prefixes over the transit VIF.
- Correct step: When using AWS Direct Connect with a transit VIF, the on-premises network prefixes must be advertised over the transit VIF to enable communication between the on-premises infrastructure and the VPCs connected via the transit gateway.
- Required action: This step ensures that traffic can be routed between the on-premises infrastructure and the VPCs via the Direct Connect connection.
C) Advertise the VPC prefixes from the Direct Connect gateway to the on-premises network over the transit VIF.
- Correct step: In order for the on-premises network to route traffic to resources in the VPC, the VPC prefixes (IP ranges) must be advertised from the Direct Connect gateway to the on-premises network. This ensures proper ro...
Author: Leah · Last updated May 13, 2026
A company wants to use Amazon WorkSpaces in combination with thin client devices to replace aging desktops. Employees use the desktops to access applications that work with Clinical trial data. Corporate security policy states that access to the applications must be restricted to only company branch office locations. The company is cons...
To address the company's requirements of restricting access to applications on Amazon WorkSpaces from only specific branch office locations, while maintaining operational efficiency, we must focus on solutions that offer centralized, scalable control over access without introducing unnecessary complexity.
Let's evaluate each option:
A) Create an IP access control group rule with the list of public addresses from the branch offices. Associate the IP access control group with the WorkSpaces directory.
- Correct approach for limiting access: Amazon WorkSpaces supports the use of IP access control groups to restrict access based on IP addresses. By creating a rule with the list of public IP addresses from the branch offices and associating this rule with the WorkSpaces directory, access can be limited to only those locations.
- Operational efficiency: This solution is highly efficient because it is simple to implement, centrally managed, and scalable. The list of IPs can be easily updated as branch office locations change, such as when a new office is added.
- Scalability: Adding new branch offices is straightforward by updating the IP access control group, so this solution will also scale well.
- Most suitable option: This option provides the simplest and most efficient way to meet the security requirements.
B) Use AWS Firewall Manager to create a web ACL rule with an IPSet with the list of public addresses from the branch office locations. Associate the web ACL with the WorkSpaces directory.
- AWS Firewall Manager: AWS Firewall Manager is primarily used for managing security rules across multiple accounts or regions, and it works in conjunction with services like AWS WAF (Web Application Firewall). However, AWS Firewall Manager is designed for managing web traffic and is not suited for Amazon WorkSpaces, which operates over non-web protocols like RDP or PCoIP.
- Not ideal for this scenario: Since WorkSpaces does not rely on web protocols for access, using AWS WAF and Firewall Manager is not a natural fit, making this solution unnecessarily complex and not directly aligned wi...
Author: Ethan · Last updated May 13, 2026
A company uses AWS Organizations. The company runs two firewall appliances in a centralized networking account. Each firewall appliance runs on a manually configured highly available Amazon EC2 instance. A transit gateway connects the VPC from the centralized networking account to VPCs of member accounts. Each firewall appliance uses a static private IP address that is then used to route traffic from the member accounts to the internet.
During a recent incident, a badly configured script initiated the termination of both firewall appliances. During the rebuild of the firewall appliances, the company wrote a new script to configure the firewall appliances at startup.
The company wants to modernize the deployment of the firewall appliances. The firewall appliances need the ability to scale horizontally to handle increased traffic when the netw...
To modernize the deployment of the firewall appliances and ensure horizontal scalability, the company needs a solution that accommodates traffic scaling while maintaining the firewall's function in compliance with company policies. The solution must also be cost-effective.
Option Breakdown:
A) Deploy a Gateway Load Balancer in the centralized networking account. Set up an endpoint service that uses AWS PrivateLink.
- Explanation: A Gateway Load Balancer (GWLB) is ideal for use with virtual appliances like firewalls, as it is specifically designed to integrate with appliances that handle network traffic at scale. Using AWS PrivateLink allows secure, private communication between VPCs. This setup facilitates traffic routing to the firewall appliances efficiently, and ensures high availability and scalability.
- Why it's selected: This option is designed for scenarios requiring network appliance integration, offering flexibility in managing traffic across multiple VPCs and ensuring scalability.
- Why others are rejected: This is a tailored solution for network appliances, and it supports horizontal scaling effectively. Other options may not directly address the need for scalable appliance deployments.
B) Deploy a Network Load Balancer in the centralized networking account. Set up an endpoint service that uses AWS PrivateLink.
- Explanation: While a Network Load Balancer (NLB) is suitable for distributing traffic to instances, it does not provide the level of integration and optimization that the Gateway Load Balancer (GWLB) provides for network appliances like firewalls.
- Why it's rejected: NLBs are more general-purpose and not optimized for integration with specialized appliances like firewalls. The GWLB is specifically designed for network appliances, which is a better fit.
C) Create an Auto Scaling group and a launch template that uses the new script as user data to configure the firewall appliances. Create a target group that uses the instance target type.
- Explanation: This option allows for horizontal scaling by automatically adding or removing EC2 instances based on traffic demand. The user data script ensures that the firewall appliance is configured when the instance starts, which is useful for automation. The instance target type ensures that EC2 instances are correctly registered with the target group in the load balancer.
- Why it's selected: This ensures scalable deployment of EC2 instances running the firewall appliances. It provides elasticity and allows the firewall appliances to scale based on network load.
- Why others ...
Author: Lina Zhang · Last updated May 13, 2026
A solutions architect must implement a multi-Region architecture for an Amazon RDS for PostgreSQL database that supports a web application. The database launches from an AWS CloudFormation template that includes AWS services and features that are present in both the primary and secondary Regions.
The database is configured for automated backups, and it has an RTO of 15 minutes and an RPO of 2 hours. The web application is configured t...
To meet the requirements for a highly available multi-Region architecture for Amazon RDS for PostgreSQL with a 15-minute RTO (Recovery Time Objective) and a 2-hour RPO (Recovery Point Objective), we need to ensure that the architecture can handle failover scenarios efficiently and with minimal downtime while maintaining data consistency. Let's analyze the available options:
Option A: Create a cross-Region read replica of the database in the secondary Region. Configure an AWS Lambda function in the secondary Region to promote the read replica during a failover event.
- Pros: Creating a cross-Region read replica provides a near-real-time copy of the primary database. This solution fits well with the 2-hour RPO requirement, as read replicas are updated asynchronously, allowing for relatively recent data to be available in the secondary Region. Promoting the read replica to a primary database during a failover event minimizes downtime, which aligns with the 15-minute RTO requirement.
- Cons: It relies on a manual intervention (via AWS Lambda) to promote the read replica, which could be delayed or fail if not implemented correctly.
- Use case: This is a valid option as it helps in setting up a multi-Region failover strategy by promoting a read replica when the primary database fails.
Option B: In the primary Region, create a health check on the database that will invoke an AWS Lambda function when a failure is detected. Program the Lambda function to recreate the database from the latest database snapshot in the secondary Region and update the Route 53 host records for the database.
- Pros: This option offers a fully automated approach by triggering a Lambda function to create a new database in the secondary Region from the latest snapshot during a failure event.
- Cons: This solution introduces higher recovery time compared to promoting a read replica. The process of creating a new database from a snapshot takes time, potentially violating the 15-minute RTO. Additionally, this approach may cause some data loss beyond the 2-hour RPO because the snapshot may not be perfectly aligned with the last committed transactions before the failure.
- Use case: While it can provide a failover solution, the time required to restore the database from a snapshot could lead to an unacceptable RTO, making it less suitable for this scenario.
Option C: Create an AWS Lambda function to copy the latest automated backup to the secondary Region every 2 hours.
- Pros: This could help with ensuring that recent backups are available in the secondary Region.
- Cons: Copying backups every 2 hours would only fulfill the RPO requirement but does not address the failover mec...
Author: Liam · Last updated May 13, 2026
An ecommerce company runs an application on AWS. The application has an Amazon API Gateway API that invokes an AWS Lambda function. The data is stored in an Amazon RDS for PostgreSQL DB instance.
During the company's most recent flash sale, a sudden increase in API calls negatively affected the application's performance. A solutions architect reviewed the Amazon CloudWatch metrics during that time and noticed a significant increase in ...
The company is experiencing performance issues during periods of high traffic, as indicated by the high CPU utilization on the database and a significant increase in Lambda invocations and database connections. The issue appears to be related to the database struggling with the load due to frequent database connections from the Lambda function. We need to recommend a solution that addresses these performance bottlenecks while maintaining the application’s scalability.
Option A: Increase the memory of the Lambda function. Modify the Lambda function to close the database connections when the data is retrieved.
- Pros: Increasing the memory of the Lambda function can help reduce the function's execution time, which may help in some cases. However, this only addresses the Lambda execution time and not the root cause of the database performance issues, which is the excessive number of database connections.
- Cons: Modifying the Lambda function to close the database connections properly is important, but it does not address the issue of the database being overwhelmed with too many simultaneous connections, particularly during high traffic periods.
- Use case: This approach is partially useful but doesn’t tackle the larger issue of excessive database connections causing high CPU utilization on the database.
Option B: Add an Amazon ElastiCache for Redis cluster to store the frequently accessed data from the RDS database.
- Pros: Using ElastiCache for Redis can offload frequent read traffic from the RDS database by caching frequently accessed data. This can significantly reduce the number of database queries and, in turn, reduce the load on the database during high traffic periods.
- Cons: While caching frequent reads can reduce database load, this doesn’t address the issue of managing database connections. The database may still suffer from performance issues related to connection management, which is a root cause of the high CPU utilization in this case.
- Use case: This approach is great for reducing read load on the database, but it doesn't resolve the connection management problem or optimize the interaction between Lambda and RDS.
Option C: Create an RDS proxy by usi...
Author: Ahmed · Last updated May 13, 2026
A retail company wants to improve its application architecture. The company's applications register new orders, handle returns of merchandise, and provide analytics. The applications store retail data in a MySQL database and an Oracle OLAP analytics database. All the applications and databases are hosted on Amazon EC2 instances.
Each application consists of several components that handle different parts of the order process. These components use incoming data from different sources. A separate ETL job runs every week and copies data from each application to the a...
To design an event-driven solution that provides near real-time analytics using serverless services, we need to focus on minimizing management overhead while leveraging the right AWS serverless services to handle the incoming data, application components, and analytics. Let’s analyze each option:
Option A: Migrate the individual applications as microservices to Amazon Elastic Container Service (Amazon ECS) containers that use AWS Fargate. Keep the retail MySQL database on Amazon EC2. Move the analytics database to Amazon Neptune. Use Amazon Simple Queue Service (Amazon SQS) to send all the incoming data to the microservices and the analytics database.
- Pros: ECS with AWS Fargate is a good option for running microservices with serverless compute, as it abstracts away infrastructure management. Amazon SQS can be used for decoupling application components and enabling an event-driven architecture.
- Cons: Keeping the retail MySQL database on EC2 is not optimal for a serverless solution. Additionally, Amazon Neptune is a graph database designed for complex relationships, which is not ideal for retail data like orders or merchandise, which are typically relational. Also, SQS might not be ideal for near real-time analytics; something like Amazon EventBridge would be more suitable for this use case.
- Use case: This option is not optimal because it doesn't fully embrace serverless services for the databases and uses an inappropriate database (Neptune) for analytics.
Option B: Create an Auto Scaling group for each application. Specify the necessary number of EC2 instances in each Auto Scaling group. Migrate the retail MySQL database and the analytics database to Amazon Aurora MySQL. Use Amazon Simple Notification Service (Amazon SNS) to send all the incoming data to the correct EC2 instances and the analytics database.
- Pros: Aurora MySQL is a good choice for the retail database, and SNS is useful for event-driven architectures. Aurora MySQL also offers some serverless capabilities.
- Cons: The use of EC2 instances and Auto Scaling groups for each application does not align with a serverless model, which is part of the requirement. Additionally, using SNS to directly send data to EC2 instances complicates the architecture and reduces the overall scalability and flexibility of the solution.
- Use case: This option requires managing EC2 instances, which is against the goal of using serverless services for easier scalability and reduced management overhead. It also doesn't leverage the full potential of serverless analytics and event-driven services.
Option C: Migrate the individual applications as microservices to Amazon Elastic Kubernet...
Author: Leo · Last updated May 13, 2026
A company is planning a migration from an on-premises data center to the AWS Cloud. The company plans to use multiple AWS accounts that are managed in an organization in AWS Organizations. The company will create a small number of accounts initially and will add accounts as needed. A solutions architect must design a sol...
When designing a solution to turn on AWS CloudTrail across multiple AWS accounts managed in AWS Organizations, the solution needs to be operationally efficient, scalable, and easy to manage as new accounts are added. Let's evaluate the options:
Option A: Create an AWS Lambda function that creates a new CloudTrail trail in all AWS accounts in the organization. Invoke the Lambda function daily by using a scheduled action in Amazon EventBridge.
- Pros: The Lambda function can automate the process of creating CloudTrail trails in each account. It is flexible and can be scheduled to run daily.
- Cons: This approach involves a manual process (Lambda triggered daily), which can lead to delays in setting up new accounts. Additionally, this approach introduces the potential for errors, as the Lambda function would need to handle all aspects of creating and managing trails in every account. There are also risks involved with ensuring that the Lambda function is up-to-date and correctly deployed across all accounts.
- Use case: This approach is not the most operationally efficient, as it requires periodic intervention (daily invocation) and manual management.
Option B: Create a new CloudTrail trail in the organization's management account. Configure the trail to log all events for all AWS accounts in the organization.
- Pros: This solution is highly operationally efficient because a single CloudTrail trail in the management account can log events from all accounts within the AWS Organization. It centralizes CloudTrail logging for all accounts and ensures that every event is captured in a single trail.
- Cons: This option requires careful configuration of the trail in the management account to log events across the entire organization. However, it does not require creating multiple trails in each account, reducing the complexity.
- Use case: This is the most operationally efficient and scalable option. Once the trail is set up in the management account, it automatically captures events for all accounts in the organization, ensuring compliance without the need for ongoing manual intervention.
Option C: Create a n...
Author: Zain · Last updated May 13, 2026
A software development company has multiple engineers who are working remotely. The company is running Active Directory Domain Services (AD DS) on an Amazon EC2 instance. The company's security policy states that all internal, nonpublic services that are deployed in a VPC must be accessible through a VPN. Mu...
In this scenario, the company has specific requirements for securing access to internal services via VPN with Multi-Factor Authentication (MFA). The goal is to integrate the VPN solution with Active Directory Domain Services (AD DS) to ensure secure, controlled access to the resources. Let’s evaluate each option carefully:
Option A: Create an AWS Site-to-Site VPN connection. Configure integration between a VPN and AD DS. Use an Amazon WorkSpaces client with MFA support enabled to establish a VPN connection.
- Analysis: The AWS Site-to-Site VPN is typically used for establishing a connection between on-premises networks and AWS. It is not designed for direct user access, but more for site-to-site communication. Amazon WorkSpaces can use MFA for remote desktop connections, but this option doesn’t fully address the need for secure, direct user VPN access to the VPC.
- Why rejected: This option doesn’t align with the need to provide secure, MFA-enabled VPN access for remote users. Site-to-Site VPN is not suitable for this specific scenario, where individual user access is required.
Option B: Create an AWS Client VPN endpoint. Create an AD Connector directory for integration with AD DS. Enable MFA for AD Connector. Use AWS Client VPN to establish a VPN connection.
- Analysis: AWS Client VPN is a managed VPN service that allows users to securely connect to resources in an AWS VPC. It can integrate with Active Directory (via AD Connector) to authenticate users. Additionally, AWS Client VPN supports MFA for added security. The integration with AD DS ensures that users are authenticated using company credentials, and MFA adds another layer of security.
- Why selected: This option meets the requirements perfectly. It enables secure VPN access with MFA support, integrates with AD DS using AD Connector, and provides...
Author: Oliver · Last updated May 13, 2026
A company is running a three-tier web application in an on-premises data center. The frontend is served by an Apache web server, the middle tier is a monolithic Java application, and the storage tier is a PostgreSQL database.
During a recent marketing promotion, customers could not place orders through the application because the application crashed. An analysis showed that all three tiers were overloaded. The application became unresponsive, and the database reached its capacity limit because of read operations. The company already has several similar promotions scheduled in the n...
To resolve the issues caused by overloads during marketing promotions and ensure scalability for future events, the company needs to migrate its three-tier web application to AWS. The goal is to minimize operational effort while maximizing scalability. Here is a breakdown of each option:
Option A: Refactor the frontend so that static assets can be hosted on Amazon S3. Use Amazon CloudFront to serve the frontend to customers. Connect the frontend to the Java application.
- Analysis: Hosting static assets (such as images, CSS, and JavaScript) on Amazon S3 and serving them through Amazon CloudFront would significantly reduce the load on the Apache web server. CloudFront is a content delivery network (CDN) that can distribute static content globally, improving performance and reducing latency. This approach helps offload static content delivery, improving the scalability and performance of the frontend.
- Why selected: This approach reduces load on the Apache server, improves scalability, and provides low-latency delivery for static content, minimizing the operational burden on the frontend.
Option B: Rehost the Apache web server of the frontend on Amazon EC2 instances that are in an Auto Scaling group. Use a load balancer in front of the Auto Scaling group. Use Amazon Elastic File System (Amazon EFS) to host the static assets that the Apache web server needs.
- Analysis: This option involves lifting and shifting the Apache web server to EC2 instances in an Auto Scaling group with an Elastic Load Balancer (ELB). This setup can scale horizontally to handle increased traffic, and using EFS for shared storage is a possible solution for maintaining consistency across instances. However, it doesn’t address the core problem of static content delivery, as it would still rely on EC2 for both dynamic and static content.
- Why rejected: Although this setup provides scalability for the web server, it still doesn’t offload the static content to a CDN like CloudFront, which would be more efficient. Also, managing EC2 instances and EFS requires more operational effort compared to the S3/CloudFront solution in Option A.
Option C: Rehost the Java application in an AWS Elastic Beanstalk environment that includes auto scaling.
- Analysis: AWS Elastic Beanstalk is a Platform as a Service (PaaS) that simplifies the deployment and management of applications. It supports auto scaling based on demand, which would help manage the increased load during promotions. Elastic Beanstalk handles the infrastructure, patching, scaling, and load balancing, which minimizes operational overhead.
- Why selected: Rehosting the Java application on Elastic Beanstalk offers scalability, ease of management, and minimal operational overhead. It also supports auto scaling, which is important for handling variable load during promotions.
Option D: Refactor the Java application....
Author: Ava · Last updated May 13, 2026
A company is deploying a new application on AWS. The application consists of an Amazon Elastic Kubernetes Service (Amazon EKS) cluster and an Amazon Elastic Container Registry (Amazon ECR) repository. The EKS cluster has an AWS managed node group.
The company's security guidelines state that all resources on AWS mu...
To meet the company's security requirement of continuously scanning AWS resources for vulnerabilities with the least operational overhead, let's evaluate the available options:
Option A: Activate AWS Security Hub. Configure Security Hub to scan the EKS nodes and the ECR repository.
- Analysis: AWS Security Hub provides a comprehensive view of security alerts and compliance status across AWS accounts. It aggregates findings from multiple AWS services like Amazon Inspector and AWS Config. However, Security Hub itself does not directly perform vulnerability scanning but integrates with services like Amazon Inspector to pull findings.
- Why rejected: While Security Hub aggregates security findings, it does not perform the actual scanning of EKS nodes or ECR repositories. Security Hub requires integrating with other tools like Amazon Inspector to perform security scans, and it may not be the most direct solution to meet the requirement for continuous scanning.
Option B: Activate Amazon Inspector to scan the EKS nodes and the ECR repository.
- Analysis: Amazon Inspector is a vulnerability management service that automatically scans AWS resources, including Amazon EC2 instances (which would include EKS worker nodes). It can scan ECR repositories for vulnerabilities in container images. Inspector integrates seamlessly with AWS services and provides automatic vulnerability detection and assessment.
- Why selected: Amazon Inspector directly addresses the need to scan the EKS nodes and the ECR repository with minimal operational overhead. It provides automated vulnerability scanning, is easy to integrate into the AWS environment, and requires minimal manual intervention after configuration. This solution fully meets the requirement for continuous security scanning with a low operational burden.
Opti...
Author: Ella · Last updated May 13, 2026
A company needs to improve the reliability of its ticketing application. The application runs on an Amazon Elastic Container Service (Amazon ECS) cluster. The company uses Amazon CloudFront to serve the application. A single ECS service of the ECS cluster is the CloudFront distribution's origin.
The application allows only a specific number of active users to enter a ticket purchasing flow. These users are identified by an encrypted attribute in their JSON Web Token (JWT). All other users are redirected to a waiting room module until there is available capacity for purchasing.
The application is experiencing high loads. The waiting room module is work...
To address the problem of high load affecting the ticketing application and impacting its reliability during high traffic periods, we need a solution that decouples the waiting room logic from the core ticketing service, scales each service independently, and reduces the load on the ticketing application. Below is a breakdown of each option.
Option Breakdown:
A) Create a separate service in the ECS cluster for the waiting room. Use a separate scaling configuration. Ensure that the ticketing service uses the JWT information and appropriately forwards requests to the waiting room service.
- Explanation: This option suggests decoupling the waiting room functionality into a separate ECS service and using a different scaling configuration. This separation would help by offloading the waiting room traffic from the ticketing service, allowing each service to scale independently based on its specific load. The ticketing service would need to inspect the JWT and forward traffic to the appropriate service (waiting room or ticketing).
- Why it's selected: This approach ensures that the waiting room's traffic doesn’t interfere with the ticketing application's availability. It leverages ECS's native service scaling features, which is cost-effective and simple to manage, particularly in environments already using ECS. Using separate scaling configurations for each service ensures that the ECS service dedicated to the ticketing application isn't overwhelmed by waiting room traffic.
- Why others are rejected: This is the simplest and most cost-effective solution as it works within the existing ECS infrastructure, without the added complexity of moving to Kubernetes or introducing additional services like App Mesh.
B) Move the application to an Amazon Elastic Kubernetes Service (Amazon EKS) cluster. Split the waiting room module into a pod that is separate from the ticketing pod. Make the ticketing pod part of a StatefulSet. Ensure that the ticketing pod uses the JWT information and appropriately forwards requests to the waiting room pod.
- Explanation: This option involves migrating the application to Amazon EKS, setting up the waiting room and ticketing services as separate pods. Making the ticketing pod part of a StatefulSet is not necessary for a stateless web service like ticketing, and would add complexity. The solution requires setting up Kubernetes, which is overkill in this case.
- Why it's rejected: While EKS can be a good fit for certain use cases, it introduces unnecessary complexity for a problem that could be solved within ECS. Additionally, StatefulSets are typically used for applications that require stable, persistent storage, which is not necessary here. Migrating to EKS adds operational overhead and may not yield significant benefits in this scenario.
C) Create a separate service in the ECS cluster for the waitin...
Author: GlowingTiger · Last updated May 13, 2026
A solutions architect is creating an AWS CloudFormation template from an existing manually created non-production AWS environment. The CloudFormation template can be destroyed and recreated as needed. The environment contains an Amazon EC2 instance. The EC2 instance has an instance profile that the EC2 instance uses to assume a role in a parent account.
The solutions architect recreates the role in a CloudFormation template and uses the same role name. When the CloudFormation tem...
To resolve the issue where the EC2 instance in the child account can no longer assume the role in the parent account due to insufficient permissions, we need to focus on the trust relationship and permissions necessary for the EC2 instance to assume the role. Here's a breakdown of the options:
Option Breakdown:
A) In the parent account, edit the trust policy for the role that the EC2 instance needs to assume. Ensure that the target role ARN in the existing statement that allows the sts:AssumeRole action is correct. Save the trust policy.
- Explanation: The trust policy in the parent account needs to grant the necessary permissions for the EC2 instance to assume the role. If the EC2 instance is in a different AWS account (the child account), the trust policy needs to reference the correct ARN or principal that corresponds to the EC2 instance. This option suggests verifying and ensuring that the trust policy is correctly configured with the correct role ARN.
- Why it’s selected: If the role is not correctly referenced in the parent account’s trust policy, the EC2 instance will not be able to assume the role. This option directly addresses the trust policy issue, which is the root cause of the problem.
- Why others are rejected: This option is the most direct and focused on solving the issue. The other options either address CloudFormation capabilities or incorrect configurations that don't directly address the trust policy.
B) In the parent account, edit the trust policy for the role that the EC2 instance needs to assume. Add a statement that allows the sts:AssumeRole action for the root principal of the child account. Save the trust policy.
- Explanation: This option suggests modifying the trust policy to allow the root principal of the child account to assume the role. The root principal generally refers to the root user of the child account, which might not be what is intended. Typically, it’s better to use the specific IAM role or IAM user from the child account that needs to assume the role, not th...
Author: Noah · Last updated May 13, 2026
A company's web application has reliability issues. The application serves customers globally. The application runs on a single Amazon EC2 instance and performs read-intensive operations on an Amazon RDS for MySQL database.
During high load, the application becomes unresponsive and requires a manual restart of the EC2 instance. A...
To determine the most suitable solution, let's break down each option based on the problem, key factors like reliability, performance, and development effort.
A) Create an Amazon CloudFront distribution. Specify the EC2 instance as the distribution's origin. Configure a Multi-AZ deployment for the RDS for MySQL database. Use the standby DB instance for the read-intensive operations.
- Analysis: CloudFront is primarily used for content delivery (e.g., caching static content like images, CSS, and JavaScript), but it won't help much with making a web application more resilient to high loads or database issues.
- Multi-AZ deployment for RDS helps with failover and availability, but using the standby instance for read-intensive operations doesn't fully address the scalability problem or handle the load during peak times. Standby instances are only used for failover, not for regular operational scaling.
- Why Rejected: While CloudFront could improve latency for static content delivery, it doesn't address the underlying issues related to high load or reliability of the application, especially with dynamic content.
B) Run the application on EC2 instances that are in an Auto Scaling group. Place the EC2 instances behind an Elastic Load Balancing (ELB) load balancer. Replace the database service with Amazon Aurora. Use Aurora Replicas for the read-intensive operations.
- Analysis: Running the application on EC2 instances within an Auto Scaling group and behind an Elastic Load Balancer (ELB) improves availability and can scale automatically based on load. This addresses the application's reliability by handling high traffic and distributing it across multiple EC2 instances.
- Using Amazon Aurora replaces the MySQL database with a more scalable and highly available database. Aurora can automatically handle scaling, and Aurora Replicas can be used to offload read operations, ensuring better performance during high load.
- Why Selected: This solution addresses both the application and database scaling, making the system more reliable and resilient to load spikes with minimal development effort.
C) Deploy AWS Global Accelerator. Configure a Multi-AZ deployment for t...
Author: Lina Zhang · Last updated May 13, 2026
A company needs to use an AWS Transfer Family SFTP-enabled server with an Amazon S3 bucket to receive updates from a third-party data supplier. The data is encrypted with Pretty Good Privacy (PGP) encryption. The company needs a solution that will automatically decrypt the data after the company receives the data.
A solutions architect will use a Transfer Family managed workflow. The company has created an IAM service role by using an IAM policy that allows access to AWS Secrets Manag...
To complete the solution for automatic decryption after receiving PGP-encrypted data using AWS Transfer Family, let's analyze each option carefully in terms of security, PGP key management, and the capabilities of Transfer Family managed workflows.
Key Requirements:
1. AWS Transfer Family: Used for handling SFTP file transfers.
2. PGP Encryption: The data received is encrypted using PGP, and it needs to be decrypted automatically.
3. Secrets Management: The company has already created an IAM role allowing access to AWS Secrets Manager and the S3 bucket, which indicates that the decryption key (the private key) will likely be stored in Secrets Manager.
4. Transfer Family Managed Workflow: This allows automating tasks such as decryption, file movement, etc.
A) Store the PGP public key in Secrets Manager. Add a nominal step in the Transfer Family managed workflow to decrypt files. Configure PGP encryption parameters in the nominal step. Associate the workflow with the Transfer Family server.
- Analysis: The PGP public key is used for encryption (not decryption). It can be shared and is meant for encrypting the data, not decrypting it. Decryption requires the private key. Therefore, storing the public key in Secrets Manager and trying to use it to decrypt data will not work.
- Why Rejected: The public key is not appropriate for decryption, making this option ineffective.
B) Store the PGP private key in Secrets Manager. Add an exception-handling step in the Transfer Family managed workflow to decrypt files. Configure PGP encryption parameters in the exception handler. Associate the workflow with the SFTP user.
- Analysis: Storing the PGP private key in Secrets Manager is correct since the private key is required for decrypting the data. However, the option suggests using an exception-handling step for decryption. Exception handlers are typically used for handling errors or unexpected conditions, not for the main decrypt...
Author: CrimsonViperX · Last updated May 13, 2026
A company is migrating infrastructure for its massive multiplayer game to AWS. The game's application features a leaderboard where players can see rankings in real time. The leaderboard requires microsecond reads and single-digit-millisecond write latencies. The datasets are single-digit terabytes in size and must be available to accept writes in less than a minute if a primary node failure occurs.
The company need...
To meet the requirements of the massive multiplayer game’s leaderboard, we need to consider both latency requirements (microsecond reads and single-digit-millisecond writes) and availability (quick recovery in case of primary node failure). Additionally, the data needs to persist for further analytical processing, which requires a solution that can store data in a way that supports analytics.
Let's analyze each option:
A) Create an Amazon RDS database with a read replica. Configure the application to point writes to the writer endpoint. Configure the application to point reads to the reader endpoint.
- Analysis: Amazon RDS is a managed relational database service that provides strong consistency and high availability with features like automated backups, multi-AZ deployments, and read replicas. While it can handle high availability and quick recovery, the latency requirements (microsecond reads and low write latency) might not be ideal for this use case. RDS, although suitable for general-purpose workloads, is not designed for microsecond read latencies, especially in scenarios like real-time leaderboards in massive multiplayer games.
- Why Rejected: RDS is better suited for transactional and relational workloads, but it doesn't meet the ultra-low latency requirements for microsecond reads or single-digit millisecond writes.
B) Create an Amazon MemoryDB for Redis cluster in Multi-AZ mode. Configure the application to interact with the primary node.
- Analysis: Amazon MemoryDB for Redis is a fully managed, in-memory database that supports microsecond read and low-latency write operations, making it well-suited for real-time use cases like leaderboards. MemoryDB is highly available with Multi-AZ deployments, which ensures data persistence and automatic failover. MemoryDB also allows for persistence (e.g., snapshotting) to support further analytical pro...
Author: NebulaEagle11 · Last updated May 13, 2026
A company is running several applications in the AWS Cloud. The applications are specific to separate business units in the company. The company is running the components of the applications in several AWS accounts that are in an organization in AWS Organizations.
Every cloud resource in the company's organization has a tag that is named BusinessUnit. Every tag already has the appropriate value of the business unit name.
The compa...
To allocate cloud costs to different business units and visualize those costs effectively, we need to consider both cost allocation and visualization of the data. The BusinessUnit tag already exists on all resources, so the solution must leverage cost allocation tags and tools for centralized reporting and analysis across multiple accounts in AWS Organizations.
Let’s analyze each option:
A) In the organization's management account, create a cost allocation tag that is named BusinessUnit. Also in the management account, create an Amazon S3 bucket and an AWS Cost and Usage Report (AWS CUR). Configure the S3 bucket as the destination for the AWS CUR. From the management account, query the AWS CUR data by using Amazon Athena. Use Amazon QuickSight for visualization.
- Analysis: This approach creates a cost allocation tag in the management account and uses the AWS Cost and Usage Report (AWS CUR) for tracking costs. The CUR is stored in an S3 bucket in the management account, and the data is queried using Amazon Athena for detailed analysis. QuickSight can then be used to visualize the data.
- Why Selected: This approach is centralized and efficient for the organization, as all data flows into one central location (the management account’s S3 bucket). The data can be queried easily with Athena and visualized using QuickSight, which is a powerful tool for creating cost dashboards and visualizations. Since all accounts are part of the same organization and the cost allocation tags are used properly, this solution will work across the whole organization.
B) In each member account, create a cost allocation tag that is named BusinessUnit. In the organization's management account, create an Amazon S3 bucket and an AWS Cost and Usage Report (AWS CUR). Configure the S3 bucket as the destination for the AWS CUR. Create an Amazon CloudWatch dashboard for visualization.
- Analysis: This option suggests creating the cost allocation tag in each member account, and then configuring a central S3 bucket in the management account for the AWS CUR. However, CloudWatch dashboards are more suited for monitoring real-time metrics and logs rather than detailed, historical cost reports from the CUR.
- Why Rejected: While this option enables cost data aggregation in a central S3 bucket, CloudWatch is not ideal for cost visualization. Athena and QuickSight are much better suited for querying and visualizing cost data from CUR reports, as CloudWatch is more focused on real-time metrics and operational data.
...
Author: Aarav · Last updated May 13, 2026
A utility company wants to collect usage data every 5 minutes from its smart meters to facilitate time-of-use metering. When a meter sends data to AWS, the data is sent to Amazon API Gateway, processed by an AWS Lambda function. and stored in an Amazon DynamoDB table. During the pilot phase, the Lambda functions took from 3 to 5 seconds to complete.
As more smart meters are deployed, the engineers notice the Lambda functions are taking from 1 to 2 minutes to complete. The functions are also increasing in duration as new types of metrics are collected from the devices....
Let's analyze each option in the context of the issue you're facing: Lambda functions experiencing increased duration, DynamoDB throughput errors (ProvisionedThroughputExceededException), and Lambda invocation errors (TooManyRequestsException).
A) Increase the write capacity units to the DynamoDB table.
- Analysis: The errors mentioned (ProvisionedThroughputExceededException) indicate that DynamoDB's provisioned throughput is being exceeded, which is causing write failures. Increasing the write capacity units (WCUs) will allow DynamoDB to handle a higher volume of write operations, which is a direct way to address this issue.
- Why Selected: This will resolve the DynamoDB errors, ensuring that the table can handle the increased write load without throughput limitations.
B) Increase the memory available to the Lambda functions.
- Analysis: Increasing the memory allocated to the Lambda functions can improve their performance because AWS Lambda allocates CPU power based on the memory configuration. More memory might reduce execution time, especially if the functions are doing CPU-intensive work or if memory is a limiting factor. However, this doesn't directly address the underlying cause of the Lambda invocation errors or the throughput problems with DynamoDB.
- Why Selected: Increasing memory could help improve Lambda function performance, particularly if the functions are becoming slow due to memory or CPU resource limitations. This might reduce the time taken by each Lambda execution and help avoid hitting the "TooManyRequestsException" errors by improving overall function efficiency.
C) Increase the payload size from the smart meters to send more data.
- Analysis: Increasing the payload size would increase the amount of data that needs to be processed by Lambda. This could lead to higher Lambda execution times and further exacerbate the issue. Additionally, it could overload both the Lambda function and the DynamoDB table with larger amounts of data that need to be written.
- Why Rejected: Increasing payload size does not solve the root causes of the performance and error issues. It would like...
Author: NebulaEagle11 · Last updated May 13, 2026
A company recently completed a successful proof of concept of Amazon WorkSpaces. A solutions architect needs to make the solution highly available across two AWS Regions. Amazon WorkSpaces is deployed in a failover Region, and a hosted zone is deployed i...
To configure high availability for Amazon WorkSpaces across two AWS Regions, we need to ensure that the solution allows users to seamlessly failover from the primary Region to the failover Region in case of an outage. Let's analyze each option and explain the reasoning behind each.
Option A:
Create a connection alias in the primary Region and in the failover Region. Associate the connection aliases with a directory in each Region. Create a Route 53 failover routing policy. Set Evaluate Target Health to Yes.
- Explanation: A failover routing policy in Route 53 is suitable for this use case because it allows you to configure a primary and secondary (failover) endpoint. If the primary Region becomes unavailable, traffic is automatically directed to the failover Region.
- Key Consideration: The Evaluate Target Health option ensures that Route 53 only routes traffic to a healthy resource. This is ideal for achieving high availability.
- Best Use Case: This option is the most suitable because it specifically addresses the need for a high availability failover between two Regions. The connection aliases in both Regions ensure the WorkSpaces can operate from either Region.
Option B:
Create a connection alias in the primary Region and in the failover Region. Associate the connection aliases with a directory in the primary Region. Create a Route 53 multivalue answer routing policy.
- Explanation: A multivalue answer routing policy routes traffic to multiple resources, but it doesn't consider health checks or prioritize one over the other in the event of failure. It’s more appropriate when you want to distribute traffic across multiple healthy resources rather than setting up a failover scenario.
- Key Consideration: While this option can route traffic to multiple resources, it does not inherently handle the failover scenario where one Region needs to take precedence if the other fails. This makes it less optimal for high availability.
- Best Use Case: This policy could work in a scenario where both Regions should receive traffic evenly, but it's not ideal for strict failover situations.
Option C:
Create a co...
Author: Lina Zhang · Last updated May 13, 2026
A company plans to migrate many VMs from an on-premises environment to AWS. The company requires an initial assessment of the on-premises environment before the migration, a visualization of the dependencies between applications that run on the VMs, and a report that provides an assessment of the on-premises environment.
To get this information, the company has initiated a Migration Evaluator assessment request. The company has the ability t...
To determine the best solution for providing the required information with the least operational overhead, let's break down the options and consider the key factors:
Option A:
Install the AWS Application Discovery Agent on each on-premises VM. After the data collection period ends, use AWS Migration Hub to view the application dependencies. Download the Quick insights assessment report from Migration Hub.
- Explanation: The AWS Application Discovery Agent is designed for collecting data about on-premises environments to help assess the workload and its dependencies. By installing the agent on each VM, you can gather the necessary information to visualize the dependencies between applications.
- Key Consideration: This option requires installing agents on each individual VM, which can be time-consuming and resource-intensive. After the data collection, AWS Migration Hub is used to visualize the dependencies and generate the Quick Insights report. This process is straightforward but has higher operational overhead due to the need to install and manage agents on multiple VMs.
- Best Use Case: This option is best for environments where detailed VM-level data is needed and where operational overhead from agent installation is not a concern.
Option B:
Install the Migration Evaluator Collector on each on-premises VM. After the data collection period ends, use Migration Evaluator to view the application dependencies. Download and export the discovered server list from Migration Evaluator. Upload the list to Amazon QuickSight When the QuickSight report is generated, download the Quick Insights assessment report.
- Explanation: Migration Evaluator provides an assessment tool that focuses on cost estimation and migration feasibility. The Migration Evaluator Collector collects data and integrates directly with the Migration Evaluator service. Once the data is collected, it can visualize dependencies, but to generate a report, you would need to upload data to QuickSight and generate the report separately.
- Key Consideration: This option introduces additional complexity as you have to involve QuickSight for visualization, which is an unnecessary step given the goal of the assessment. Using QuickSight here adds more operational overhead compared to other methods and could be considered overcomplicated for a simple dependency visualization and assessment.
- Best Use Case: This option could be useful when advanced visualization and custom reporting with QuickSight are needed but is unnecessary for the basic dependency analysis and assessment in this scenario.
Option C:
Set up the AWS Application Discovery Service Agentless Collector in the on-premises environment...
Author: FrostFalcon88 · Last updated May 13, 2026
A company hosts its primary API on AWS by using an Amazon API Gateway API and AWS Lambda functions that contain the logic for the API methods. The company's internal applications use the API for core functionality and business logic. The company's customers use the API to access data from their accounts. Several customers also have access to a legacy API that is running on a single standalone Amazon EC2 instance.
The company wants to increase the securi...
To enhance the security of the APIs and protect against threats like denial of service (DoS) attacks, vulnerabilities, and exploits, we need to select the best combination of AWS services that provide protection, monitoring, and analysis for both the API Gateway API and the legacy EC2-hosted API. Let's evaluate each option based on how they address these requirements:
Option A:
Use AWS WAF to protect both APIs. Configure Amazon Inspector to analyze the legacy API. Configure Amazon GuardDuty to monitor for malicious attempts to access the APIs.
- Explanation:
- AWS WAF (Web Application Firewall) is used to protect web applications from common threats such as DoS attacks, SQL injection, and cross-site scripting. It can be applied to both the API Gateway API and the legacy EC2-hosted API.
- Amazon Inspector is primarily used to assess the security and vulnerabilities of EC2 instances and applications. It can analyze the legacy API (hosted on EC2), but it doesn't provide specific monitoring or protection for the API Gateway API itself.
- Amazon GuardDuty is a threat detection service that monitors AWS accounts for malicious activity and unauthorized access. It can be used to monitor the APIs for unusual or malicious access attempts.
- Why Rejected: This option covers all the requirements except for providing targeted protections for the API Gateway API. It uses WAF for both APIs, which is good, but the vulnerability assessment is limited to the legacy EC2-hosted API, and there’s no direct mention of improving the security of the API Gateway API itself beyond WAF.
Option B:
Use AWS WAF to protect the API Gateway API. Configure Amazon Inspector to analyze both APIs. Configure Amazon GuardDuty to block malicious attempts to access the APIs.
- Explanation:
- AWS WAF is applied to the API Gateway API, which is a good fit since WAF protects APIs from common web exploits and attacks.
- Amazon Inspector is used to assess both APIs, but Amazon Inspector is typically focused on EC2 instances and the software running on them, so it’s not as useful for API Gateway, which is fully managed and doesn’t involve direct EC2 access.
- Amazon GuardDuty provides threat detection, but it does not directly block malicious traffic. It can alert on malicious activity, but it doesn't have the capability to block malicious attempts.
- Why Rejected: While Amazon Inspector could assess the legacy API (hosted on EC2), it is not as effective for the API Gateway API. Moreover, GuardDuty does not block malicious attempts—it only detects them. So,...
Author: William · Last updated May 13, 2026
A company is running a serverless ecommerce application on AWS. The application uses Amazon API Gateway to invoke AWS Lambda Java functions. The Lambda functions connect to an Amazon RDS for MySQL database to store data.
During a recent sale event, a sudden increase in web traffic resulted in poor API performance and database connection failures. The company needs to implement a solution to minim...
To solve the problem of poor API performance and database connection failures during high traffic events, the company needs a solution that minimizes Lambda function latency, supports traffic bursts, and reduces database connection issues. Let's evaluate the proposed options:
Option A:
Update the code of the Lambda functions so that the Lambda functions open the database connection outside of the function handler. Increase the provisioned concurrency for the Lambda functions.
- Explanation:
- Opening the database connection outside the Lambda function handler can improve performance by reusing the database connection across multiple invocations of the Lambda function during a cold start. This can reduce the overhead of establishing new connections each time.
- Provisioned concurrency ensures that a set number of Lambda instances are pre-warmed and ready to handle traffic, minimizing cold start latency.
- However, this approach doesn't address the core issue of database connection failures under high load. Lambda functions might still exhaust available database connections if the RDS instance is unable to handle the increased number of connections, even with persistent connections.
- Why Rejected: While this could reduce latency, it doesn't fully resolve the connection pooling issue and might still lead to failures in database connections under high traffic. Additionally, managing database connections manually within the Lambda function is not a scalable solution.
Option B:
Create an RDS Proxy endpoint for the database. Store database secrets in AWS Secrets Manager. Set up the required IAM permissions. Update the Lambda functions to connect to the RDS Proxy endpoint. Increase the provisioned concurrency for the Lambda functions.
- Explanation:
- RDS Proxy acts as a connection pool manager between the Lambda functions and the RDS database. It reduces the number of direct database connections by pooling them, which helps in managing database connection limits during bursts in traffic.
- Storing database secrets in AWS Secrets Manager is a best practice for securely managing credentials, and IAM permissions would control access to those credentials.
- Provisioned concurrency ensures pre-warmed Lambda functions are available to handle high traffic, improving response times.
- Why Selected: This option directly addresses both latency and connection issues. RDS Proxy helps manage database connections effectively, preventing failures under high traffic, and provisioned concurrency ensures that Lambda functions are always ready ...
Author: Kai99 · Last updated May 13, 2026
A company requires that all internal application connectivity use private IP addresses. To facilitate this policy, a solutions architect has created interface endpoints to connect to AWS Public services. Upon testing, the solutions architect notices that the service names are resolving to public IP addresses, and th...
To resolve the issue where the service names are resolving to public IP addresses and internal services cannot connect to the interface endpoints, we need to ensure that the internal services within the VPC resolve the service names to private IP addresses, as intended by the use of interface endpoints. Let's go through each option:
Option A: Update the subnet route table with a route to the interface endpoint.
- Explanation: The route table in a VPC is used to direct traffic to appropriate destinations based on IP address prefixes. While interface endpoints (like for AWS services) require the appropriate route to be set up for traffic to flow, they do not typically require specific routes in the subnet's route table. The connectivity issue described is more related to DNS resolution, not routing.
- Why Rejected: While route tables may need to be configured for other traffic routing purposes, this option does not address the issue of DNS resolution that causes the services to resolve to public IP addresses. The issue is related to how DNS queries for service names are resolved.
Option B: Enable the private DNS option on the VPC attributes.
- Explanation: AWS interface endpoints provide private connectivity to AWS services over private IP addresses. By default, AWS services' DNS names resolve to public IP addresses unless the Private DNS option is enabled for the VPC. Enabling this option ensures that the DNS names for AWS services resolve to private IP addresses when accessed from within the VPC. This is crucial for ensuring internal applications resolve service names to private IPs.
- Why Selected: Enabling private DNS ensures that the service names resolve to private IP addresses for communication over the private network. This resolves the problem of DNS resolution to public IPs and ensures the internal applications ...
Author: Olivia · Last updated May 13, 2026
A company is developing a latency-sensitive application. Part of the application includes several AWS Lambda functions that need to initialize as quickly as possible. The Lambda functions are written in Java and contain initialization code outside the handlers to load libraries, initial...
Option A: Move all the initialization code to the handlers for each Lambda function. Activate Lambda SnapStart for each Lambda function. Configure SnapStart to reference the $LATEST version of each Lambda function.
Reasoning:
- Lambda SnapStart can significantly reduce initialization latency for Lambda functions. When SnapStart is activated, the initialization code (outside the handler) is only executed once per Lambda function version. This means that the cold start latency is reduced for subsequent invocations, as SnapStart captures and caches the initialized state of the function.
- Moving initialization code to the handlers negates the benefit of SnapStart, as SnapStart relies on initialization being outside the handler. By moving everything to the handler, you force Lambda to re-initialize for each invocation, which would defeat the purpose of SnapStart.
Why it’s rejected:
- Moving the initialization code to the handlers would eliminate the benefit of SnapStart, which is specifically designed to reduce cold start times by caching the initialization state.
- This approach also complicates the design since Lambda handlers are typically expected to be lean and focused on the actual work.
Option B: Publish a version of each Lambda function. Create an alias for each Lambda function. Configure each alias to point to its corresponding version. Set up a provisioned concurrency configuration for each Lambda function to point to the corresponding alias.
Reasoning:
- Provisioned Concurrency guarantees a set number of Lambda instances to be ready and available at all times, eliminating cold starts for those instances. This would significantly reduce initialization time since the provisioned instances are pre-warmed.
- Aliases and versions in this case allow precise control over which code version is used, ensuring stability.
Why it’s rejected:
- This option incurs higher ongoing costs because provisioned concurrency requires the Lambda functions to be always "warm," whether or not they are used. This is ideal for high-performance applications that demand low latency but might be cost-prohibitive for applications with less frequent or bursty traffic.
- While it meets the startup performance requirement, it may not be the most cost-effective solution.
Option C: Publish a version of each Lambda function. Set up a provisioned concurrency configuration ...
Author: Sofia2021 · Last updated May 13, 2026
A solutions architect is importing a VM from an on-premises environment by using the Amazon EC2 VM Import feature of AWS Import/Export. The solutions architect has created an AMI and has provisioned an Amazon EC2 instance that is based on that AMI. The EC2 instance runs inside a public subnet in a VPC and has a public IP address assigned.
The EC2 instance does not appear as...
Key Factors to Consider:
When troubleshooting AWS Systems Manager (SSM) issues with an EC2 instance that isn't appearing as a managed instance, the most relevant factors to consider are:
- SSM Agent: The Systems Manager agent must be installed and running on the EC2 instance for it to register with Systems Manager.
- IAM Role: The EC2 instance needs to have an IAM role that grants necessary permissions to interact with Systems Manager.
- Network Connectivity: The EC2 instance needs the proper network configuration to communicate with AWS Systems Manager, particularly if it's in a private subnet.
- Service-Linked Roles: AWS services that interact with Systems Manager, like EC2 instances, require appropriate service-linked roles.
- Specific Tools/Agents: While the Application Discovery Agent may be relevant for other purposes, it’s not directly necessary for registering an EC2 instance with Systems Manager.
Option Breakdown:
A) Verify that Systems Manager Agent is installed on the instance and is running.
- Reasoning: The Systems Manager Agent (SSM Agent) is required to enable the EC2 instance to communicate with Systems Manager. If the agent is not installed or not running, the EC2 instance will not be able to register as a managed instance in Systems Manager.
- Selection: This is one of the first things to check because it’s fundamental to the instance being recognized by Systems Manager.
B) Verify that the instance is assigned an appropriate IAM role for Systems Manager.
- Reasoning: The EC2 instance needs an IAM role that grants it the necessary permissions to interact with Systems Manager (e.g., `AmazonSSMManagedInstanceCore`). If this role is missing or improperly configured, the EC2 instance won’t be able to register with Systems Manager.
- Selection: This is another critical step because IAM roles govern the permissions that are necessary for the EC2 instance to communicate with Systems Manager. Without the correct permissions, it cannot ...
