Amazon Practice Questions, Discussions & Exam Topics by our Authors
A company stores user data in AWS. The data is used continuously with peak usage during business hours. Access patterns vary, with some data not being used for months at a time. A solutions architect must choose a cost-effective solution that maintains the high...
Key Considerations:
1. Cost-effectiveness: The solution should minimize storage costs, especially for data that is not frequently accessed.
2. Durability: The solution must maintain the highest level of durability to ensure data safety.
3. High availability: Data must be readily available when needed, particularly during business hours.
4. Access patterns: Some data is frequently used, while other data may not be accessed for months.
Let's evaluate each option:
A) Amazon S3 Standard
- Pros: Amazon S3 Standard offers high durability (99.999999999% durability) and availability (99.99% availability), making it suitable for frequently accessed data. It provides low-latency access to data.
- Cons: S3 Standard is more expensive than other options like S3 Intelligent-Tiering or Glacier, especially for data that is not accessed frequently.
- Scenario Use: This option is ideal for data that is consistently accessed, but it is not cost-effective for data with sporadic access patterns.
B) Amazon S3 Intelligent-Tiering
- Pros: Amazon S3 Intelligent-Tiering automatically moves data between two access tiers (frequent and infrequent) based on changing access patterns. This offers cost savings by automatically shifting less-accessed data to a cheaper tier while maintaining high availability and durability (99.999999999% durability).
- Cons: There is a small cost associated with monitoring and automation in Intelligent-Tiering, but it is still a very cost-effective option for varying access patterns.
- Scenario Use: This is the best option when data access patterns are unpredictable and vary, ensuring that frequently accessed data is stored in the high-performance tier, while infrequently accessed data is moved to a more cost-effective storage tier. It also ensures high availability and durabil...
Author: FrostFalcon88 · Last updated Jul 12, 2026
A company is using multiple AWS accounts. The DNS records are stored in a private hosted zone for Amazon Route 53 in Account A. The company's applications and databases are running in Account B.
A solutions architect will deploy a two-tier application in a new VPC. To simplify the configuration, the db.example.com CNAME record set for the Amazon RDS endpoint was created in a private hosted zone for Amazon Route 53.
During deployment, the application failed to start. Troubleshooting revealed that db.example.com is not re...
Let's break down the issue and evaluate each option based on the steps necessary to resolve the problem.
Scenario Summary:
- The company is using multiple AWS accounts.
- Private hosted zone for DNS records is in Account A, while the application and databases are in Account B.
- CNAME record (db.example.com) for an RDS endpoint exists in the private hosted zone in Account A, but the EC2 instances in Account B cannot resolve the DNS record for `db.example.com`.
The issue lies in resolving the DNS record from Account B's VPC, which needs to access the private hosted zone in Account A.
Key Points:
- DNS resolution across accounts: For instances in Account B to resolve DNS records in Account A's private hosted zone, there needs to be an association between the VPC in Account B and the private hosted zone in Account A.
- The solution should allow cross-account DNS resolution so that the EC2 instances in Account B can resolve the domain names stored in the private hosted zone in Account A.
Option A: Deploy the database on a separate EC2 instance in the new VPC. Create a record set for the instance's private IP in the private hosted zone.
- Analysis: This option suggests deploying the database on a separate EC2 instance and manually creating a record set for it in the private hosted zone. While this might work for simple use cases, it does not address the core issue of enabling cross-account DNS resolution.
- Rejection Reason: This approach creates a new EC2 instance and adds a record to the private hosted zone, but it doesn't solve the issue of allowing EC2 instances in Account B to resolve DNS records from the private hosted zone in Account A. It doesn't leverage AWS best practices for cross-account DNS resolution.
Option B: Use SSH to connect to the application tier EC2 instance. Add an RDS endpoint IP address to the /etc/resolv.conf file.
- Analysis: This option involves manually modifying the `/etc/resolv.conf` file on the EC2 instance to add the IP address of the RDS endpoint. While this may provide a workaround for DNS resolution, it doesn't solve the underlying issue of cross-account DNS resolution and isn't scalable or a...
Author: Isabella · Last updated Jul 6, 2026
A company is testing an application that runs on an Amazon EC2 Linux instance. A single 500 GB Amazon Elastic Block Store (Amazon EBS) General Purpose SSO (gp2) volume is attached to the EC2 instance.
The company will deploy the application on multiple EC2 instances in an Auto Scaling group. All instances require access to the data that is stored in the EBS volume. The company n...
To meet the company's requirements, we need a solution that provides high availability and resilience without significant changes to the application's code. We are considering Amazon EC2 instances running in an Auto Scaling group, where all instances need access to the same data stored in an EBS volume.
Option Analysis:
A) Provision an EC2 instance that uses NFS server software. Attach a single 500 GB gp2 EBS volume to the instance.
- Challenges: This option introduces a single point of failure (the EC2 instance running the NFS server). If that instance becomes unavailable, the data access is also lost. Additionally, using a single EBS volume restricts the scalability and high availability of the solution. The Auto Scaling group needs to rely on this EC2 instance to provide access to data, which is a bottleneck and limits resilience.
- Rejection: Does not meet the high availability and resilience requirements. A single EC2 instance acting as an NFS server introduces a single point of failure.
B) Provision an Amazon FSx for Windows File Server file system. Configure the file system as an SMB file store within a single Availability Zone.
- Challenges: While Amazon FSx for Windows File Server provides shared storage with high availability features, it is limited to a single Availability Zone in this configuration. This introduces a potential risk for downtime if the Availability Zone experiences issues. Furthermore, the company might not require Windows-based file storage (SMB), which could lead to unnecessary complexity.
- Rejection: Single Availability Zone configuration does not m...
Author: Ming88 · Last updated Jul 12, 2026
A company used Amazon EC2 instances to deploy a web fleet to host a blog site. The EC2 instances are behind an Application Load Balancer (ALB) and are configured in an Auto Scaling group. The web application stores all blog content on an Amazon EFS volume.
The company recently added a feature for bloggers to add video to their posts, attracting 10 times the previous user traffic. At peak times of day, users repor...
To address the performance issues with video buffering and timeouts, we need a scalable and cost-efficient solution. Let's break down each option and evaluate it based on key factors such as scalability, cost-effectiveness, and ease of implementation.
Option A: Reconfigure Amazon EFS to enable maximum I/O
- Pros: Increasing I/O throughput on Amazon EFS may help improve performance, especially for file access.
- Cons: Even with maximum I/O, EFS is still not optimized for high-demand media delivery, especially when handling large video files and spikes in traffic. Additionally, it may increase costs since higher throughput levels come at a price, and scaling EFS isn't as flexible or cost-efficient as other options.
- Scalability: Limited scalability compared to other options.
- Cost-efficiency: EFS is more expensive than alternatives like Amazon S3 or CloudFront for serving static content (e.g., videos).
- Conclusion: This option doesn’t fully address the root cause of the issue — the high traffic and heavy video content — and it may not be cost-efficient for video delivery.
Option B: Update the blog site to use instance store volumes for storage. Copy the site contents to the volumes at launch and to Amazon S3 at shutdown
- Pros: Instance store volumes provide high I/O performance and could potentially improve access speed for blog content.
- Cons: Instance store volumes are ephemeral (i.e., data is lost when the instance is stopped or terminated), so they’re not suitable for storing persistent blog content, especially video files. Additionally, the process of copying content at launch and shutdown is complex, prone to failure, and requires extra management.
- Scalability: Limited scalability due to the complexity of copying data and maintaining instance store volumes.
- Cost-efficiency: This approach adds complexity, and it is not an ideal way to store or deliver large video files. Costs could be higher due to the need for custom automation.
- Conclusion: Not ideal for serving video content in a scalable way and not cost-effective for large, persistent data storage.
Option C: Configure an Amazon CloudFront distribution. Point the distribution to an S3 bucket, and migrate the videos from EFS to Amazon S3
- Pros: Amazon CloudFront is a Content Delivery Network (CDN) that caches content at e...
Author: Liam · Last updated Jul 6, 2026
A company recently launched a new application for its customers. The application runs on multiple Amazon EC2 instances across two Availability Zones. End users use TCP to communicate with the application.
The application must be highly available and must automatically scale as the...
To meet the requirements of high availability and automatic scaling for the application while also being cost-effective, we need to use a combination of services that ensure load balancing and auto-scaling without requiring manual intervention.
Option Analysis:
A) Add a Network Load Balancer in front of the EC2 instances.
- Advantages: A Network Load Balancer (NLB) is designed to handle high-performance, low-latency TCP traffic. It provides high availability by distributing incoming traffic across multiple EC2 instances in multiple Availability Zones, ensuring scalability and fault tolerance. Since the application uses TCP, this is the ideal load balancer for the use case.
- Reason for Selection: NLB is optimized for TCP traffic and offers excellent performance with minimal overhead. It is a cost-effective solution for handling high traffic loads and ensuring high availability.
B) Configure an Auto Scaling group for the EC2 instances.
- Advantages: Auto Scaling automatically adjusts the number of EC2 instances in response to changes in traffic, ensuring the application scales based on demand. This can reduce costs by automatically scaling down during periods of low usage while ensuring enough capacity during peak traffic.
- Reason for Selection: Auto Scaling is a key part of making the application highly available and cost-effective. It automatically adjusts capacity without requiring manual intervention and ensures that EC2 instances are only running when needed.
C) Add an Application Load Balancer in front of the EC2 instances.
- Challenges: While the Application Load Balancer (ALB) is well-suited for HTTP and HTTPS traffic, it is no...
Author: Benjamin · Last updated Jul 12, 2026
A company with global offices has a single 1 Gbps AWS Direct Connect connection to a single AWS Region. The company's on-premises network uses the connection to communicate with the company's resources in the AWS Cloud. The connection has a single private virtual interface that connects to a single VPC.
A solutions architect must implement a solution that adds a redundant Direct Connect connection in the same Region. The solutio...
To meet the requirements of adding a redundant Direct Connect connection and enabling connectivity to multiple AWS Regions, let's evaluate each option carefully based on scalability, redundancy, and simplicity of implementation.
Option A: Provision a Direct Connect gateway. Delete the existing private virtual interface from the existing connection. Create the second Direct Connect connection. Create a new private virtual interface on each connection, and connect both private virtual interfaces to the Direct Connect gateway. Connect the Direct Connect gateway to the single VPC.
- Pros: A Direct Connect gateway enables connectivity to multiple VPCs and regions, providing a scalable solution for global expansion. You can connect multiple VPCs in different regions using the same pair of Direct Connect connections.
- Cons: The requirement to delete the existing private virtual interface may result in a brief service disruption during implementation, which is undesirable in a production environment.
- Scalability: Excellent scalability across multiple regions as it can connect to multiple VPCs, including those in different AWS regions.
- Cost-efficiency: Direct Connect gateway provides a highly efficient, cost-effective way to interconnect multiple regions.
- Conclusion: This is a robust, scalable solution that supports future global expansion and provides redundancy for the existing connection.
Option B: Keep the existing private virtual interface. Create the second Direct Connect connection. Create a new private virtual interface on the new connection, and connect the new private virtual interface to the single VPC.
- Pros: This option allows you to keep the existing private virtual interface and create a new one on the second Direct Connect connection.
- Cons: This solution only provides redundancy within a single region and does not support connectivity to multiple AWS regions. If the company expands to other regions in the future, it would require additional configurations. It doesn't scale well for global connectivity.
- Scalability: Limited scalability. This solution only handles redundancy for a single VPC in one region, without providing inter-region connectivity.
- Cost-efficiency: It might be more cost-effective initially, but as the company expands, the need for further changes could increase costs.
- Conclusion: This option doesn't meet the requirement of providing connectivity to other regions and lacks scalability.
Option C: Keep the existing private virtual interface. Create the second Direct Connect connection. Create a new public virtual interface on the new connection, and connect the new public virtual interface to the single VPC.
- Pros: This approach adds a new connection with a public virtual interface, which can be used for accessing AWS publi...
Author: Deepak · Last updated Jul 6, 2026
A company is designing the architecture for a new mobile app that uses the AWS Cloud. The company uses organizational units (OUs) in AWS Organizations to manage its accounts. The company wants to tag Amazon EC2 instances with data sensitivity by using values of sensitive and nonsensitive. IAM identities must no...
Option Analysis:
A) In Organizations, create a new tag policy that specifies the data sensitivity tag key and the required values. Enforce the tag values for the EC2 instances. Attach the tag policy to the appropriate OU.
- Advantages: Tag policies in AWS Organizations allow you to define and enforce specific tagging rules across AWS accounts within an organization. By creating a tag policy that requires the data sensitivity tag key with specific values (e.g., "sensitive" or "nonsensitive") for EC2 instances, this will enforce consistency and compliance across accounts without requiring additional configuration on each individual EC2 instance. The policy will ensure that instances must have the correct tags when they are created.
- Reason for Selection: Tag policies are a powerful tool to centrally manage tagging rules for AWS resources. This satisfies the requirement to enforce a specific tag key and values, preventing the creation of EC2 instances without the required tags.
B) In Organizations, create a new service control policy (SCP) that specifies the data sensitivity tag key and the required tag values. Enforce the tag values for the EC2 instances. Attach the SCP to the appropriate OU.
- Challenges: Service Control Policies (SCPs) are used to control what actions accounts and IAM users can perform within AWS Organizations. However, SCPs do not directly manage tagging or enforce specific tag values for resources. SCPs are more focused on limiting or granting access to actions (e.g., EC2 instance creation) but are not designed to enforce tag compliance.
- Rejection: SCPs do not directly enforce tagging rules; tag enforcement is more appropriately handled through tag policies. This option does not align with the requirement to enforce specific tag values.
C) Create a tag policy to deny running instances when a tag key is not specified. Create another tag policy that prevents identities from deleting tags. Attach the tag policies to the appropriate OU.
- Challenges: While creating a tag policy to deny running instances without a specific tag is useful, AWS Tag Policies do not support blocking the running of instances based on missing tags directly. Additionally, enforcing the deletion of tags is typically handled through IAM permissions or SCPs, not tag policies.
- Rejection: Tag policies alone cannot prevent EC2 instances from running based on missing tags, and preventing the deletion of tags needs IA...
Author: William · Last updated Jul 12, 2026
A company has a web application that allows users to upload short videos. The videos are stored on Amazon EBS volumes and analyzed by custom recognition software for categorization.
The website contains static content that has variable traffic with peaks in certain months. The architecture consists of Amazon EC2 instances running in an Auto Scaling group for the web application and EC2 instances running in an Auto Scaling group to process an Amazon SQS queue. The compa...
To address the requirements of reducing operational overhead and leveraging AWS managed services while removing dependencies on third-party software, let's evaluate each option based on the key factors: operational overhead, use of AWS managed services, scalability, cost-effectiveness, and maintainability.
Option A: Use Amazon ECS containers for the web application and Spot instances for the Auto Scaling group that processes the SQS queue. Replace the custom software with Amazon Rekognition to categorize the videos.
- Pros: ECS provides a fully managed container orchestration service, which reduces operational overhead for managing EC2 instances. Spot instances can reduce costs for processing the SQS queue. Amazon Rekognition can easily replace the custom software for video categorization.
- Cons: While ECS is a great managed service, managing containers still requires some operational overhead, particularly in handling scaling and configurations. Additionally, Spot instances can be interrupted, which may cause delays in video processing, although they can reduce costs if used appropriately.
- Scalability: ECS is highly scalable, but the use of Spot instances introduces variability, making it less predictable for critical processing tasks.
- Cost-efficiency: Spot instances can reduce costs but may lead to some unpredictability in processing times.
- Conclusion: This option is a good fit for reducing operational overhead but introduces unpredictability with Spot instances. It still requires some container management, which may not fully eliminate operational overhead.
Option B: Store the uploaded videos in Amazon EFS and mount the file system to the EC2 instances for the web application. Process the SQS queue with an AWS Lambda function that calls the Amazon Rekognition API to categorize the videos.
- Pros: Amazon EFS offers a managed file system for EC2 instances, which reduces complexity compared to managing individual EBS volumes. Lambda is a fully managed service that automatically scales for processing the SQS queue, and Rekognition can handle video categorization without third-party software.
- Cons: EFS is ideal for sharing files across instances, but it can be more expensive and less efficient than S3 for large-scale, scalable object storage. Mounting EFS for the web application adds some complexity, and while Lambda scales well, the processing of videos could hit limits in terms of Lambda execution time, especially with large video files.
- Scalability: Lambda can scale to handle video processing from the SQS queue, but the scalability of EFS might not be as optimal for large video storage compared to S3.
- Cost-efficiency: EFS might incur higher costs for video storage compared to Amazon S3, which is better suited for storing large objects at scale.
- Conclusion: This option reduces operational overhead but may not be the most cost-effective or scalable solution for video storage and processing.
Option C: Host the web application in Amazon S3. Store the uploaded videos in ...
Author: Olivia Johnson · Last updated Jul 6, 2026
A company has a serverless application comprised of Amazon CloudFront, Amazon API Gateway, and AWS Lambda functions. The current deployment process of the application code is to create a new version number of the Lambda function and run an AWS CLI script to update. If the new function version has errors, another CLI script reverts by deploying the previous working version of the function. The company would like to decrease the time...
To address the company's desire to decrease the time for deploying new versions of the Lambda functions and reduce the time to detect and revert errors, let's evaluate each option based on ease of deployment, rollback speed, automation, and reliability.
Option A: Create and deploy nested AWS CloudFormation stacks with the parent stack consisting of the AWS CloudFront distribution and API Gateway, and the child stack containing the Lambda function. For changes to Lambda, create an AWS CloudFormation change set and deploy; if errors are triggered, revert the AWS CloudFormation change set to the previous version.
- Pros: CloudFormation provides an infrastructure-as-code (IaC) approach, which makes deployments repeatable, consistent, and easily auditable. Using CloudFormation change sets allows for a more structured deployment and rollback process.
- Cons: While CloudFormation can automate the infrastructure deployment, it does not directly address the Lambda deployment's granularity in terms of traffic management or versioning. Reverting an entire stack (including CloudFront and API Gateway) can be cumbersome and might affect other components beyond Lambda, making rollbacks slower than more specific solutions.
- Scalability: CloudFormation provides a scalable and repeatable process, but it may not be the most efficient for Lambda-specific deployments or rollbacks.
- Cost-efficiency: Using CloudFormation is a solid, cost-effective option for managing infrastructure, but it’s less optimized for quick Lambda function version management.
- Conclusion: While it provides a structured approach for managing infrastructure and Lambda together, it doesn’t offer the quickest, most granular solution for Lambda function deployment and rollback.
Option B: Use AWS SAM and built-in AWS CodeDeploy to deploy the new Lambda version, gradually shift traffic to the new version, and use pre-traffic and post-traffic test functions to verify code. Rollback if Amazon CloudWatch alarms are triggered.
- Pros: AWS SAM (Serverless Application Model) simplifies deploying serverless applications and integrates directly with AWS CodeDeploy. CodeDeploy allows for blue/green deployment, where traffic can be gradually shifted from the old Lambda version to the new version. Pre-traffic and post-traffic tests help validate that the new version is working correctly before fully rolling it out. If errors occur, you can easily revert using the built-in rollback mechanism.
- Cons: The initial setup of SAM and CodeDeploy might require some learning and configuration overhead. However, once set up, it automates deployment, traffic shifting, and rollback.
- Scalability: This solution scales well for Lambda functions, allowing for controlled deployments and rapid error detection and rollback.
- Cost-efficiency: This solution is cost-effective and leverages built-in AWS tools to manage deployments efficiently.
- Conclusion: This is the best option because it allows for smooth and gradual deployment with the ability to test and monitor the new function version before fully switching traffic. If issues arise, automatic rollback is possible, reducing downtim...
Author: Sara · Last updated Jul 6, 2026
A company is planning to store a large number of archived documents and make the documents available to employees through the corporate intranet. Employees will access the system by connecting through a client VPN service that is attached to a VPC. The data must not be accessible to the public.
The documents that the company is storing are copies of data that is held on physical media elsewhere...
To meet the requirements of the company while ensuring low cost and secure access to archived documents, let's break down each of the options:
Key Requirements:
1. Low retrieval frequency: Since the number of requests will be low, this implies that the company doesn't need a solution with high availability or fast retrieval speed.
2. Secure access: The documents must not be accessible to the public, and the access should only be from the corporate intranet via a VPN.
3. Cost-effective: The solution should minimize costs, especially considering that retrieval speed and availability are not priorities.
4. Data storage type: The data is archived and copied from physical media, so an archival or infrequent access storage class would be most suitable.
Option A: Create an Amazon S3 bucket. Configure the S3 bucket to use the S3 One Zone-Infrequent Access (S3 One Zone-IA) storage class as default. Configure the S3 bucket for website hosting. Create an S3 interface endpoint. Configure the S3 bucket to allow access only through that endpoint.
Reasoning:
- S3 One Zone-IA is a good fit for infrequent access, as it stores data in a single Availability Zone at a lower cost compared to standard S3 storage classes.
- S3 interface endpoint ensures that the data is only accessible through the internal network, not the public internet.
- Website hosting is unnecessary for the requirement of archiving documents. The company doesn't need to host the data for web access.
Rejection: While the storage class and endpoint are correct, the website hosting feature is not needed for this scenario. This adds unnecessary complexity and overhead.
Option B: Launch an Amazon EC2 instance that runs a web server. Attach an Amazon Elastic File System (Amazon EFS) file system to store the archived data in the EFS One Zone-Infrequent Access (EFS One Zone-IA) storage class. Configure the instance security groups to allow access only from private networks.
Reasoning:
- EFS One Zone-IA is a storage option suitable for infrequent access in a single Availability Zone, but it is more expensive than S3 Glacier or S3 One Zone-IA.
- EC2 and web server: This adds unnecessary complexity because you don't need to run an EC2 instance with a web server just to store and access documents. EC2 costs and management overhead are hi...
Author: Emma · Last updated Jul 6, 2026
A company is using an on-premises Active Directory service for user authentication. The company wants to use the same authentication service to sign in to the company's AWS accounts, which are using AWS Organizations. AWS Site-to-Site VPN connectivity already exists between the on-premises environment and all the company's AWS accounts.
The company's security policy requires co...
To solve this problem, we need to focus on the specific requirements, including using the on-premises Active Directory (AD) for user authentication, managing identities in a single location, and granting conditional access based on user groups and roles. Let’s analyze each option based on these criteria:
Option A: Configure AWS IAM Identity Center (AWS Single Sign-On) to connect to Active Directory by using SAML 2.0. Enable automatic provisioning by using the System for Cross-domain Identity Management (SCIM) v2.0 protocol. Grant access to the AWS accounts by using attribute-based access controls (ABACs).
- Advantages:
- SAML 2.0 integration allows seamless authentication with the on-premises Active Directory.
- SCIM v2.0 allows for automatic user provisioning, ensuring that user identities are synchronized across systems without manual intervention.
- ABAC (Attribute-based access controls) provides flexibility in granting access based on user attributes (like department, role, or any other AD attribute), which is ideal for conditional access control based on user groups or roles.
- Centralized identity management is possible as AWS IAM Identity Center can sync with AD and maintain user roles.
- Why Selected: This solution is fully integrated with both Active Directory and AWS, offering both automated provisioning and fine-grained control over access policies. It also supports centralized identity management, which is a key requirement.
- Drawback: ABAC might require additional setup, and configuring SCIM for provisioning may introduce complexity if not handled carefully, but it is well-suited for the security policy that requires dynamic, attribute-based access controls.
Option B: Configure AWS IAM Identity Center (AWS Single Sign-On) by using IAM Identity Center as an identity source. Enable automatic provisioning by using the System for Cross-domain Identity Management (SCIM) v2.0 protocol. Grant access to the AWS accounts by using IAM Identity Center permission sets.
- Advantages:
- IAM Identity Center as an identity source simplifies identity management within AWS, but it does not directly integrate with an external AD unless you configure external identity federation (e.g., via SAML).
- SCIM for provisioning allows user synchronization.
- IAM Identity Center permission sets are a good way to grant specific permissions across AWS accounts.
- Why Rejected: IAM Identity Center is not connected to the on-premises AD unless explicitly integrated using federation methods (such as SAML). Since the question specifies using the on-premises AD for authentication, this setup would be i...
Author: Noah · Last updated Jul 6, 2026
A company runs database workloads on AWS that are the backend for the company's customer portals. The company runs a Multi-AZ database cluster on Amazon RDS for PostgreSQL.
The company needs to implement a 30-day backup retention policy. The company currently has both automated RDS backups and manual RDS backups. The company wants to...
Option Analysis:
A) Configure the RDS backup retention policy to 30 days for automated backups by using AWS Backup. Manually delete manual backups that are older than 30 days.
- Advantages: Using AWS Backup to configure the backup retention for automated backups is a good choice for centralizing and managing backup policies. The manual backups can be deleted manually if they are older than 30 days, which ensures that only the required backups are retained. This approach ensures that both automated and manual backups are appropriately managed.
- Reason for Selection: AWS Backup is a cost-effective solution for managing backup retention policies, and the manual intervention for deleting old manual backups ensures that retention is maintained. This avoids unnecessary automation complexity for manual backups, making it a reasonable approach.
B) Disable RDS automated backups. Delete automated backups and manual backups that are older than 30 days. Configure the RDS backup retention policy to 30 days for automated backups.
- Challenges: Disabling automated backups for RDS is not an ideal solution because it would disrupt the ability of RDS to automatically create and manage backups of the database. Disabling automated backups defeats the purpose of using RDS for automatic database backup management, leading to the need for more manual intervention and administrative overhead.
- Rejection: Disabling automated backups is not a recommended approach because it compromises the automatic backup feature of RDS, which is essential for disaster recovery and backup consistency.
C) Configure the RDS backup retention policy to 30 days for automated backups. Manually delete manual backups that are older than 30 days.
- Advantages...
Author: IronLion88 · Last updated Jul 12, 2026
A software company has deployed an application that consumes a REST API by using Amazon API Gateway, AWS Lambda functions, and an Amazon DynamoDB table. The application is showing an increase in the number of errors during PUT requests. Most of the PUT calls come from a small number of clients that are authenticated with specific API keys.
A solutions architect has identified that a large number of the PUT requests originate from one client. The API is noncritical, and clients can toler...
To improve the customer experience and address the issues with PUT requests that are causing errors, the solutions architect needs to consider the root cause of the errors and recommend a solution that enhances the reliability of the API without impacting its reputation. Let's break down the options:
Option A: Implement retry logic with exponential backoff and irregular variation in the client application. Ensure that the errors are caught and handled with descriptive error messages.
- Reasoning:
- Retry logic with exponential backoff is a common approach to handle transient errors in APIs. It helps mitigate the impact of occasional spikes in traffic or temporary throttling by automatically retrying failed requests.
- Irregular variation in the retry intervals helps prevent all clients from retrying at the same time, which could create additional load on the system and exacerbate the problem.
- Descriptive error messages improve the customer experience by providing useful information when an error occurs, so users can understand what happened and why.
- Why this is a good choice:
- This approach is directly addressing the problem of errors in PUT requests due to high traffic from one client. Exponential backoff ensures that retries happen in a way that reduces the chance of overwhelming the API with too many retries at once.
- This solution improves the customer experience because errors will be less frequent, and retries will be handled gracefully, without frustrating users.
Selected because retrying failed requests with backoff is a proven method to manage API load and ensure better error handling, which is especially helpful in noncritical applications where retries can be tolerated.
Option B: Implement API throttling through a usage plan at the API Gateway level. Ensure that the client application handles code 429 replies without error.
- Reasoning:
- API throttling is typically used to limit the number of requests a client can make within a certain time period to protect the backend from overload.
- A code 429 (Too Many Requests) response is returned when the client exceeds the allowed limit. However, this requires proper handling by the client application to avoid an error response.
- Why this might not be the best choice:
- Throttling is useful for limiting requests from clients who are making too many requests in a short time. However, it can introduce delays and error responses that would still be visible to customers, which is undesirable if the goal is to improve the customer experience. While throttling prevents overloading the backend, it doesn't directly address the issue of retrying failed requests.
- The client application would need to handle the retries properly (which may overlap with Option A). If throttling is appli...
Author: SolarFalcon11 · Last updated Jul 6, 2026
A company is running a data-intensive application on AWS. The application runs on a cluster of hundreds of Amazon EC2 instances. A shared file system also runs on several EC2 instances that store 200 TB of data. The application reads and modifies the data on the shared file system and generates a report. The job runs once monthly, reads a subset of the files from the shared file system, and takes about 72 hours to complete. The compute instances scale in an Auto Scaling group, but the instances that host the shared file system run continuously. The compute and storage instances are all in the same AWS Region.
A solutions architect ...
To solve this problem, the goal is to reduce costs while maintaining high performance during the 72-hour job, which processes large amounts of data. Let's analyze the options based on performance, cost, and scalability:
Option A: Migrate the data from the existing shared file system to an Amazon S3 bucket that uses the S3 Intelligent-Tiering storage class. Before the job runs each month, use Amazon FSx for Lustre to create a new file system with the data from Amazon S3 by using lazy loading. Use the new file system as the shared storage for the duration of the job. Delete the file system when the job is complete.
- Advantages:
- Amazon S3 Intelligent-Tiering reduces costs by automatically moving objects between two access tiers (frequent and infrequent access) based on usage patterns, which can save money on the storage cost.
- FSx for Lustre offers high performance for data processing tasks and integrates well with S3 for fast data access.
- Lazy loading means only the data that is accessed is loaded, which can improve performance during the job and save on unnecessary I/O operations.
- Cost-effective: You only pay for the FSx for Lustre instance when it’s running, and it can be deleted after the job is completed, saving on costs during non-job periods.
- Why Selected: This solution provides a significant cost reduction by leveraging S3 for storage and using FSx for Lustre only when needed for high-performance access. Lazy loading ensures that only the necessary data is brought into the high-performance file system, which reduces unnecessary storage and compute costs.
- Drawback: The data migration to S3 and the setup of FSx for Lustre before the job might require some setup time, but overall, this option offers substantial cost savings and performance benefits for the 72-hour job.
Option B: Migrate the data from the existing shared file system to a large Amazon Elastic Block Store (Amazon EBS) volume with Multi-Attach enabled. Attach the EBS volume to each of the instances by using a user data script in the Auto Scaling group launch template. Use the EBS volume as the shared storage for the duration of the job. Detach the EBS volume when the job is complete.
- Advantages:
- EBS with Multi-Attach allows multiple EC2 instances to attach to the same volume, providing shared storage across instances.
- EBS is a highly reliable storage solution and works well for workloads with consistent, low-latency requirements.
- Why Rejected: EBS volumes are not designed for the scale and performance required for high-demand, data-intensive applications, especially with hundreds of EC2 instances. Additionally, managing the EBS volume in this way can lead to complexity, especially around attaching and detaching the volume from multiple instances. Moreover, EBS volumes are typically more expensive than alternatives like Amazon S3, and this solution doesn't offer the same level of performance scaling as FSx for Lustre.
- Drawback: EBS is not the best solution for large-scale shared file storage, especially in a dynamic, compute-intensive e...
Author: Rohan · Last updated Jul 6, 2026
A company is developing a new service that will be accessed using TCP on a static port. A solutions architect must ensure that the service is highly available, has redundancy across Availability Zones, and is accessible using the DNS name my.service.com, which is publicly accessible. The service must use fixed address assignments so other companies can add the addres...
To determine the best solution for the company's service, let's analyze the requirements in detail and evaluate the options accordingly. The service must be highly available, have redundancy across Availability Zones, be accessible via a static DNS name (`my.service.com`), and use fixed IP addresses for allow lists.
Requirements Breakdown:
1. Highly Available and Redundant across Availability Zones: The service should be distributed across multiple Availability Zones for fault tolerance and load balancing.
2. Static DNS Name: The service must be accessed via a DNS name (`my.service.com`), which needs to resolve to fixed IP addresses.
3. Fixed Address Assignments: The IP addresses need to be static so other companies can add them to their allow lists.
4. TCP Service on a Static Port: The service uses TCP and a static port, so the solution must support this.
Option A: Create Amazon EC2 instances with an Elastic IP address for each instance. Create a Network Load Balancer (NLB) and expose the static TCP port. Register EC2 instances with the NLB. Create a new name server record set named my.service.com, and assign the Elastic IP addresses of the EC2 instances to the record set. Provide the Elastic IP addresses of the EC2 instances to the other companies to add to their allow lists.
- Advantages:
- Elastic IP addresses (EIP) are static and can be used for fixed address assignments, meeting the requirement for companies to add IPs to allow lists.
- NLB is ideal for TCP-based services and supports high availability across multiple AZs.
- Why Rejected:
- Managing multiple EIPs for each instance can become cumbersome, especially when scaling out. It’s also unnecessary to directly assign multiple EIPs to instances if a Load Balancer is being used.
- The DNS name would require each individual EIP to be added to the record set, which may not be efficient for managing availability and scaling.
Option B: Create an Amazon ECS cluster and a service definition for the application. Create and assign public IP addresses for the ECS cluster. Create a Network Load Balancer (NLB) and expose the TCP port. Create a target group and assign the ECS cluster name to the NLB. Create a new A record set named my.service.com, and assign the public IP addresses of the ECS cluster to the record set. Provide the public IP addresses of the ECS cluster to the other companies to add to their allow lists.
- Advantages:
- ECS provides containerized deployments and is well-suited for scaling.
- NLB is ideal for TCP-based applications and works across multiple Availability Zones.
- Why Rejected:
- Public IP addresses for ECS tasks are not recommended for static IP assignments because ECS typically uses dynamic IPs that change over time. This could be problematic for fixed IP requirements for allow lists.
- Public IPs for ECS do not provide the same reliability as using Ela...
Author: Olivia · Last updated Jul 6, 2026
A company uses an on-premises data analytics platform. The system is highly available in a fully redundant configuration across 12 servers in the company's data center.
The system runs scheduled jobs, both hourly and daily, in addition to one-time requests from users. Scheduled jobs can take between 20 minutes and 2 hours to finish running and have tight SLAs. The scheduled jobs account for 65% of the system usage. User jobs typically finish running in less than 5 minutes and have no SLA. The user jobs account for 35% of system usage. During system failures, scheduled jobs must continue to meet SLAs. However, user jobs can be delayed.
A solutions a...
To meet the requirements of the company while transitioning to a consumption-based model on AWS EC2 instances, we need to focus on balancing cost efficiency with high availability, particularly for the scheduled jobs that have tight SLAs. Let's analyze each option in detail:
Key Requirements:
1. High availability: The system must be highly available across multiple Availability Zones.
2. Cost efficiency: The solution must adopt a consumption-based model to reduce costs without long-term commitments, leveraging cost-saving options like Spot Instances.
3. Scheduled job priority: Scheduled jobs account for 65% of system usage and must continue to meet SLAs, meaning these jobs should run on more reliable instance types.
4. User job flexibility: User jobs can be delayed, so they can run on cheaper, less reliable instance types, such as Spot Instances, as long as the system can handle Spot interruptions.
Option A: Split the 12 instances across two Availability Zones in the chosen AWS Region. Run two instances in each Availability Zone as On-Demand Instances with Capacity Reservations. Run four instances in each Availability Zone as Spot Instances.
- Reasoning:
- On-Demand Instances with Capacity Reservations are designed to ensure that a specific number of instances are always available, which is beneficial for meeting the SLAs of scheduled jobs.
- Spot Instances are cost-effective but can be interrupted, which is acceptable for user jobs since they can tolerate delays.
- Two Availability Zones: While this setup provides redundancy, it does not fully leverage the high availability that three Availability Zones offer, which could affect fault tolerance during system failures.
- Rejection: This option is less optimal because it only uses two Availability Zones, which reduces the overall availability and fault tolerance compared to using three Availability Zones.
Option B: Split the 12 instances across three Availability Zones in the chosen AWS Region. In one of the Availability Zones, run all four instances as On-Demand Instances with Capacity Reservations. Run the remaining instances as Spot Instances.
- Reasoning:
- Three Availability Zones: This improves fault tolerance and high availability.
- On-Demand Instances with Capacity Reservations: Having all four On-Demand Instances with capacity reservations in one Availability Zone ensures that you have guaranteed capacity, but this setup is inefficient because the other two Availability Zones may be underutilized.
- Spot Instances: These are used for user jobs, but the lack of balance across Availability Zones and the concentration of On-Demand Instances in just one zone can lead to uneven resource usage.
- Rejection: While this option provides some high availability by using three Availability Zones, the inefficient distribution of ...
Author: Emily · Last updated Jul 6, 2026
A company is planning to migrate a legacy application to AWS. The application currently uses NFS to communicate to an on-premises storage solution to store application data. The application cannot be modified to use any other communication protocols other than NF...
Option Analysis:
A) AWS DataSync
- Challenges: AWS DataSync is a service designed for transferring large amounts of data between on-premises storage and AWS storage services. While it is useful for migrating data, it does not provide a persistent storage solution that supports the NFS protocol for ongoing application communication. DataSync is a migration tool and not a replacement for the storage itself.
- Rejection: DataSync is not a storage solution but rather a data transfer service. It cannot be used for regular NFS communication, which the application requires.
B) Amazon Elastic Block Store (Amazon EBS)
- Challenges: Amazon EBS provides block-level storage that can be attached to EC2 instances. However, EBS is not designed to be shared across multiple EC2 instances or accessed via the NFS protocol natively. It only allows one EC2 instance to access the volume at a time, which does not meet the need for shared storage via NFS.
- Rejection: EBS does not support NFS communication out of the box and is more suitable for single-instance block storage, making it unsuitable for the legacy application’s requirements.
C) Amazon Elastic File System (Amazon EFS)
- Advantages: Amazon EFS provides a scalable and fully managed file storage solution that supports NFS. It is designed for shared access from multiple EC2 instances and can be accessed via the NFS protocol, making it a perfect fit for the lega...
Author: Michael · Last updated Jul 12, 2026
A security engineer determined that an existing application retrieves credentials to an Amazon RDS for MySQL database from an encrypted file in Amazon S3. For the next version of the application, the security engineer wants to implement the following application design changes to improve security:
The database must use strong, randomly generated passwords stored in a secure AWS managed service.
The application resources must be deployed through AWS CloudFormation.
The application must rotate credentials for the database every 90 days.
A so...
To meet the security engineer's requirements with the least amount of operational overhead, we need to focus on using AWS managed services for password management, rotation, and integrating it into the CloudFormation deployment process.
Requirements Analysis:
- Strong, randomly generated passwords: AWS Secrets Manager is specifically designed to store and manage sensitive information like database credentials, including generating strong and randomly generated passwords.
- Automatic password rotation every 90 days: Both Secrets Manager and Systems Manager Parameter Store support automated password rotation. However, Secrets Manager provides native, fully managed rotation functionality, reducing operational overhead.
- CloudFormation deployment: The solution needs to be deployable via CloudFormation templates.
- Minimal operational overhead: We aim to minimize manual intervention, so automated password rotation without requiring external components or manual intervention is ideal.
Option Analysis:
- A) Generate the database password as a secret resource using AWS Secrets Manager. Create an AWS Lambda function resource to rotate the database password. Specify a Secrets Manager RotationSchedule resource to rotate the database password every 90 days.
- Pros:
- AWS Secrets Manager is a fully managed service with built-in support for storing and rotating database credentials.
- Secrets Manager offers native rotation support, which can be configured using a RotationSchedule.
- This option is fully integrated with AWS services, reducing operational overhead.
- Cons:
- Lambda is required for custom rotation logic. However, since Secrets Manager provides automatic integration for rotation tasks, this is a minor concern.
- Why Selected: This option directly supports the requirements of storing and rotating credentials with minimal management overhead. AWS Secrets Manager is designed for this exact use case.
- B) Generate the database password as a SecureString parameter type using AWS Systems Manager Parameter Store. Create an AWS Lambda function resource to rotate the database password. Specify a Parameter Store RotationSchedule resource to rotate the dat...
Author: John · Last updated Jul 6, 2026
A company is storing data in several Amazon DynamoDB tables. A solutions architect must use a serverless architecture to make the data accessible publicly through a simple API over HTTPS. The solution must scale ...
In order to meet the requirements of storing data in Amazon DynamoDB tables, exposing it publicly via a simple API over HTTPS, and ensuring scalability in a serverless architecture, let's evaluate the different options:
Key Requirements:
1. Public API: The data should be accessible via an HTTPS API.
2. Serverless architecture: The solution must scale automatically with demand.
3. Accessing DynamoDB: The data stored in DynamoDB should be made accessible via the API.
4. Scalability: The solution should handle varying levels of demand without requiring manual intervention.
Option A: Create an Amazon API Gateway REST API. Configure this API with direct integrations to DynamoDB by using API Gateway’s AWS integration type.
- Reasoning:
- API Gateway REST API can be used to expose the data from DynamoDB through direct integrations.
- This approach uses direct integrations with DynamoDB, meaning API Gateway handles the communication between the API and DynamoDB directly without needing an intermediary like AWS Lambda.
- Why this option may work:
- It leverages serverless architecture since API Gateway and DynamoDB are both serverless.
- API Gateway can scale automatically in response to incoming traffic.
- Rejection: While this option is possible, it has some limitations in flexibility. Complex logic (like transformation, validation, etc.) might require the use of Lambda functions, and API Gateway REST APIs generally offer more advanced features and control than HTTP APIs in certain use cases.
Option B: Create an Amazon API Gateway HTTP API. Configure this API with direct integrations to DynamoDB by using API Gateway’s AWS integration type.
- Reasoning:
- HTTP API is a simpler and more cost-effective version of the REST API in Amazon API Gateway. It is optimized for lower latency and reduced cost, making it ideal for straightforward use cases like the one described here.
- Direct integrations to DynamoDB mean that API Gateway would handle the communication to DynamoDB directly, which fits well for a simple API use case without additional logic.
- Why this option is good:
- It provides a serverless, scalable solution that integrates directly with DynamoDB. This would allow the system to handle traffic automatically without manual scaling.
- HTTP API is generally faster and cheaper than REST API, which suits the requirement for a simple API and scalability.
- Selected: This option provides a simple, scalable, and cost-effective way to expose DynamoDB data publicly via an API. It meets all the criteria for a serverless architecture and automatic scaling.
Option C: Create an Amazon API Gateway HTTP API. Configure this API with integrations to AWS Lambda functions that return data from the DynamoDB tables.
- Reasoning:
- Using Lambda functions as intermediaries to return data from DynamoDB adds more flexibility, such as allowing for data transformation, validation, or other business logic.
- HTTP API is used here, which ensures low latency and cost-effectiveness for straightforward API use cases.
- Why this option works:
- Lambda functions add a level o...
Author: Michael · Last updated Jul 6, 2026
A company has registered 10 new domain names. The company uses the domains for online marketing. The company needs a solution that will redirect online visitors to a specific URL for each domain. All domains and target URLs are defined in a JSON document. All DNS records are managed by Amazon Route 53.
A solutions architect must implement a redirect service that accepts HTTP and HT...
To meet the company's requirement of redirecting online visitors from multiple domain names to specific URLs with the least amount of operational effort, we need a solution that is scalable, cost-effective, and easy to manage. Let's break down the options and determine which steps should be taken.
Key Requirements:
1. Redirect visitors to specific URLs: This requires a way to dynamically fetch the target URLs based on the incoming domain.
2. Handle HTTP and HTTPS traffic: The solution must be capable of redirecting both HTTP and HTTPS requests.
3. All DNS records are managed in Route 53: The solution should integrate well with Route 53.
4. Use a JSON document to map domains to target URLs: The redirection logic should be based on this document, reducing the need for hardcoding or manual configuration.
Option Analysis:
- A) Create a dynamic webpage that runs on an Amazon EC2 instance. Configure the webpage to use the JSON document in combination with the event message to look up and respond with a redirect URL.
- Pros:
- You could host a webpage on EC2 that processes the redirects.
- Cons:
- Operational overhead: EC2 instances require maintenance, scaling, and patching, which would introduce unnecessary operational complexity for a task like redirecting requests.
- Not serverless: This doesn't align with the serverless approach, which would be more scalable and easier to manage.
- Why Rejected: EC2 introduces too much operational overhead for a task that can be solved more efficiently with serverless technologies.
- B) Create an Application Load Balancer that includes HTTP and HTTPS listeners.
- Pros:
- Application Load Balancer (ALB) can handle HTTP/HTTPS traffic and can redirect based on specific rules.
- Cons:
- ALB does not directly handle the requirement of dynamically looking up the target URLs based on a JSON document.
- While ALB can redirect, the logic required for dynamic lookups is more complex to implement directly in ALB.
- Why Rejected: ALB alone cannot directly use the JSON document to manage the redirects dynamically. It is limited to static redirection rules.
- C) Create an AWS Lambda function that uses the JSON document in combination with the event message to look up and respond with a redirect URL.
- Pros:
- Serverless: Lambda allows for a fully serverless approach with minimal operational overhead.
- Dynamic logic: Lambda can dynamically look up the target URLs from the JSON document based on the incoming request (domain).
- Scalable: Lambda scales automatically based on the traffic without the need for provisioning or managing infrastructure.
- Cons:
- Lambda needs to be triggered via an API Gateway or another service, but this is easily set up.
- Why Selected: Lambda is a perfect ...
Author: IceDragon2023 · Last updated Jul 6, 2026
A company that has multiple AWS accounts is using AWS Organizations. The company's AWS accounts host VPCs, Amazon EC2 instances, and containers.
The company's compliance team has deployed a security tool in each VPC where the company has deployments. The security tools run on EC2 instances and send information to the AWS account that is dedicated for the compliance team. The company has tagged all the compliance-related resources with a key of 'costCenter' and a value or 'compliance'.
The company wants to identify the cost of the secur...
To meet the company's requirements for calculating the cost of security tools running on EC2 instances in different AWS accounts, the solution must leverage AWS's cost management and reporting tools, taking into account the cost tags and usage across multiple accounts in an organization.
Key Requirements:
1. Track and calculate costs for tagged resources: The goal is to calculate the cost associated with EC2 instances tagged with `"costCenter=compliance"`.
2. Accurate cost allocation across multiple accounts: The solution needs to aggregate costs from different AWS accounts, as the security tools run across several VPCs in those accounts.
3. Automated and monthly calculation: The cost calculation needs to be automated and occur on a monthly basis.
Option Analysis:
- A) In the management account of the organization, activate the costCenter user-defined tag. Configure monthly AWS Cost and Usage Reports to save to an Amazon S3 bucket in the management account. Use the tag breakdown in the report to obtain the total cost for the costCenter tagged resources.
- Pros:
- Activating the costCenter tag in the management account will allow aggregation of costs across all accounts in the AWS Organization.
- Using AWS Cost and Usage Reports (CUR) is a robust and accurate way to obtain detailed cost breakdowns.
- Cons:
- The tag must be activated across all member accounts, and this option assumes the management account has visibility into the usage and costs in the member accounts, which is typically the case.
- It requires setting up the CUR in a centralized S3 bucket, which requires some configuration but offers detailed and accurate reporting.
- Why Selected: This option effectively provides the required cost breakdown for the resources tagged with `costCenter=compliance` and consolidates it into a centralized report that can be accessed from the management account. It is simple, accurate, and leverages native AWS services for reporting.
- B) In the member accounts of the organization, activate the costCenter user-defined tag. Configure monthly AWS Cost and Usage Reports to save to an Amazon S3 bucket in the management account. Schedule a monthly AWS Lambda function to retrieve the reports and calculate the total cost for the costCenter tagged resources.
- Pros:
- This option also utilizes AWS Cost and Usage Reports for detailed breakdowns, which is a good choice for accurate cost calculation.
- Lambda could automate processing of the CURs.
- Cons:
- This solution involves more complexity and additional operational overhead since a Lambda function must be scheduled and configured to process the data and calculate the cost for the `costCenter` tagged ...
Author: GlowingTiger · Last updated Jul 6, 2026
A company has 50 AWS accounts that are members of an organization in AWS Organizations. Each account contains multiple VPCs. The company wants to use AWS Transit Gateway to establish connectivity between the VPCs in each member account. Each time a new member account is created, the company wants to automate the ...
The company has multiple AWS accounts, each containing multiple VPCs, and they want to automate the process of creating a new VPC and a Transit Gateway attachment whenever a new member account is added to their organization. The solution needs to ensure that connectivity is established between all the VPCs across different accounts.
Key Requirements:
1. Automated VPC creation: When a new member account is created, a new VPC should be created automatically.
2. Transit Gateway attachment: Each new VPC should be attached to an existing Transit Gateway in the management account.
3. Cross-account sharing: The Transit Gateway should be shared between the management and member accounts.
Option Analysis:
- A) From the management account, share the transit gateway with member accounts by using AWS Resource Access Manager.
- Pros:
- AWS Resource Access Manager (RAM) allows you to share resources, such as a Transit Gateway, across accounts in AWS Organizations.
- It provides a straightforward way to share the Transit Gateway across multiple accounts.
- Cons:
- This option only addresses the sharing of the Transit Gateway, but it does not automate the creation of new VPCs or Transit Gateway attachments.
- It doesn't address how the VPC is created or how the attachment process works.
- Why Selected: This option is a crucial part of the solution to allow member accounts to access the Transit Gateway, but it needs to be paired with automation for VPC creation and Transit Gateway attachment.
- B) From the management account, share the transit gateway with member accounts by using an AWS Organizations SCP.
- Pros:
- Service Control Policies (SCPs) in AWS Organizations are used to define permission guardrails.
- Cons:
- SCPs cannot be used to share or create AWS resources directly; they are primarily used for governance and access control.
- SCPs do not enable resource sharing or automation of VPC and Transit Gateway attachment creation.
- Why Rejected: SCPs are used for controlling permissions, not for resource sharing or automation, so this option doesn't meet the requirements.
- C) Launch an AWS CloudFormation stack set from the management account that automatically creates a new VPC and a VPC transit gateway attachment in a member account. Associate the attachment with the transit gateway in the management account by using the transit gateway ID.
- Pros:
- AWS CloudFormation stack sets allow you to automate the deployment of resources across multiple accounts.
- It can create both a new VPC and the required Transit Gateway attachment, ensuring that the VPC is automatically connected to the Transit Gateway in the management account.
...
Author: MoonlitPantherX · Last updated Jul 6, 2026
An enterprise company wants to allow its developers to purchase third-party software through AWS Marketplace. The company uses an AWS Organizations account structure with full features enabled, and has a shared services account in each organizational unit (OU) that will be used by procurement managers. The procurement team's policy indicates that developers should be able to obtain third-party software from an approved list only and use Private Marketplace in AWS Marketplace to achieve this requirement. The procurement team wants administration of Private Marketplace to be restricted to a role named procurement-manager-rol...
Analysis of the Options:
Key Factors for Decision:
- Security and Least Privilege: The procurement team needs to have controlled administrative access to AWS Private Marketplace, while preventing other roles (such as developers) from having this level of access.
- Centralized Management: Given that the company uses AWS Organizations, centralized control via Service Control Policies (SCPs) should be prioritized.
- Efficiency and Scalability: The solution should avoid excessive complexity and be scalable across multiple accounts and organizational units (OUs).
Option-by-Option Analysis:
A) Create an IAM role named procurement-manager-role in all AWS accounts in the organization. Add the PowerUserAccess managed policy to the role. Apply an inline policy to all IAM users and roles in every AWS account to deny permissions on the AWSPrivateMarketplaceAdminFullAccess managed policy.
- Pros:
- The role would be available across all AWS accounts.
- PowerUserAccess allows the role to perform most actions except for those that require administrative access.
- Cons:
- This approach is inefficient because the inline policy would need to be manually added to each IAM user and role in every account, which could be cumbersome and error-prone.
- The use of `PowerUserAccess` does not fully address the need to restrict Private Marketplace administrative permissions, as it does not directly limit access to AWSPrivateMarketplaceAdminFullAccess.
- It also requires managing multiple inline policies, making it less scalable.
B) Create an IAM role named procurement-manager-role in all AWS accounts in the organization. Add the AdministratorAccess managed policy to the role. Define a permissions boundary with the AWSPrivateMarketplaceAdminFullAccess managed policy and attach it to all the developer roles.
- Pros:
- The role is available in every account, and it provides the necessary permissions for the procurement manager.
- Using AdministratorAccess gives broad permissions.
- Cons:
- AdministratorAccess is excessive for the procurement-manager-role, as it grants far more permissions than needed, violating the principle of least privilege.
- Defining a permissions boundary for developer roles to limit them from managing Private Marketplace is not a best practice, as it adds unnecessary complexity to the developer roles and does not provide a central point of management for the administrative access control.
C) Create an IAM role named procurement-manager-role in all the shar...
Author: Aarav · Last updated Jul 6, 2026
A company is in the process of implementing AWS Organizations to constrain its developers to use only Amazon EC2, Amazon S3, and Amazon DynamoDB. The developers account resides in a dedicated organizational unit (OU). The solutions architect has implemented the following SCP on the developers account:
When this policy is deployed, IAM users in the developers account are still able to use AWS...
In this scenario, the company wants to constrain its developers to use only specific AWS services (Amazon EC2, Amazon S3, and Amazon DynamoDB). However, IAM users in the developers' account are still able to use other AWS services not listed in the Service Control Policy (SCP). Let's analyze the options to resolve this issue:
Key Requirements:
1. The developers' ability to use only EC2, S3, and DynamoDB should be allowed.
2. All other services must be denied explicitly to ensure strict access control.
3. The solution must be implemented using AWS Organizations SCP to enforce this at the organizational unit (OU) level.
Option A: Create an explicit deny statement for each AWS service that should be constrained.
- Reasoning:
- This option involves explicitly denying each service that developers should not have access to.
- While this approach could work, it could be cumbersome and error-prone to list every individual AWS service that should be denied (especially as new services are added to AWS). It also doesn't scale well over time.
- Why it’s rejected:
- Explicitly denying every service is not efficient and doesn't align with best practices. It would require constant updates as AWS releases new services. Additionally, this approach is prone to missing new or less commonly used services.
Option B: Remove the FullAWSAccess SCP from the developers accounts OU.
- Reasoning:
- FullAWSAccess is an SCP that grants broad permissions to AWS services. Removing this SCP would revoke all permissions, potentially causing users to lose access to necessary services, including EC2, S3, and DynamoDB.
- This action would effectively make the developers' account completely unusable until the correct permissions are applied.
- Why it’s rejected:
- Removing the FullAWSAccess SCP would likely break the access to required services (EC2, S3, DynamoDB), so this is not a suitable solution to enforce the intended restrictions w...
Author: Sofia · Last updated Jul 6, 2026
A company uses GPS trackers to document the migration patterns of thousands of sea turtles. The trackers check every 5 minutes to see if a turtle has moved more than 100 yards (91.4 meters). If a turtle has moved, its tracker sends the new coordinates to a web application running on three Amazon EC2 instances that are in multiple Availability Zones in one AWS Region.
Recently, the web application was overwhelmed while processing an unexpected volume of tracker data. Data was lost with no way to...
Let's go through the options one by one and evaluate them:
Option A: Create an Amazon S3 bucket to store the data. Configure the application to scan for new data in the bucket for processing.
- Explanation: S3 is designed to store large amounts of data with high availability and durability, but scanning for new data in an S3 bucket would require the application to constantly check the bucket, which can add operational complexity. Also, storing data in S3 without a proper queuing or event-driven system could result in delayed processing or data loss if the application is overwhelmed.
- Why rejected: This option would add significant operational overhead due to the need to continually scan the bucket and manage data processing. It also does not address the need for scalability and reliability in the face of unexpected data volume.
Option B: Create an Amazon API Gateway endpoint to handle transmitted location coordinates. Use an AWS Lambda function to process each item concurrently.
- Explanation: API Gateway can receive requests and forward them to a Lambda function. The Lambda function can then process the data concurrently. This is a scalable solution where each event can trigger a new Lambda invocation, ensuring that data is processed in near-real-time.
- Why rejected: While scalable and serverless, Lambda has limitations on concurrency, execution time, and memory. If there is an unexpected spike in data volume (such as a large number of GPS trackers sending data), Lambda functions might be throttled, causing some events to be lost, which is what happened previously in the problem. The lack of durability means there's no way to replay missed events.
Option C: Create an Amazon Simple Queue Service (Amazon SQS) queue to store the incoming data. Configure the application to poll for new messages for processing.
- Explanation: SQS is a fully managed message queue service...
Author: FrostFalcon88 · Last updated Jul 12, 2026
A company is hosting a monolithic REST-based API for a mobile app on five Amazon EC2 instances in public subnets of a VPC. Mobile clients connect to the API by using a domain name that is hosted on Amazon Route 53. The company has created a Route 53 multivalue answer routing policy with the IP addresses of all the EC2 instances. Recently, the app has been overwhelmed by large and sudden increases to traffic. The app has not been able to keep up with the...
Key Factors for Decision:
- Scalability: The app needs to be able to handle increasing traffic, so automatic scaling is necessary.
- Operational Overhead: The company is likely looking for a solution with minimal manual intervention and management.
- Cost-Effectiveness: The solution should be efficient in terms of cost while still providing the necessary scalability.
- Current Setup: The app is hosted on EC2 instances, and the current setup uses Route 53 for DNS-based load balancing, which is relatively simple but may not provide sufficient scalability or resilience.
Option-by-Option Analysis:
A) Separate the API into individual AWS Lambda functions. Configure an Amazon API Gateway REST API with Lambda integration for the backend. Update the Route 53 record to point to the API Gateway API.
- Pros:
- AWS Lambda is highly scalable and can automatically handle varying levels of traffic without the need for manual intervention.
- API Gateway is a fully managed service that integrates well with Lambda and can scale to handle large spikes in traffic.
- Cons:
- This solution involves refactoring the monolithic application into individual Lambda functions, which may require significant changes to the application code. This is high overhead in terms of development and operational effort for a quick solution.
- It may also incur higher costs if the Lambda functions are not optimized properly, especially with a large volume of requests.
- Not the least operational overhead since it requires significant changes to the existing infrastructure.
B) Containerize the API logic. Create an Amazon Elastic Kubernetes Service (Amazon EKS) cluster. Run the containers in the cluster by using Amazon EC2. Create a Kubernetes ingress. Update the Route 53 record to point to the Kubernetes ingress.
- Pros:
- EKS offers high scalability and allows you to run containerized applications with automated scaling.
- This approach provides a modern, flexible architecture.
- Cons:
- Setting up and managing EKS requires significant operational overhead and expertise in Kubernetes. While scalable, it involves much more complexity in terms of cluster management, scaling configurations, and ongoing maintenance.
- For a straightforward solution to scaling the existing monolithic API, this is not the best fit given the need for minimal operational overhead.
C) Create an Auto Scaling group. Place all the EC2 instances in the Auto Scalin...
Author: Deepak · Last updated Jul 6, 2026
A company's software development team needs an Amazon RDS Multi-AZ cluster. The RDS cluster will serve as a backend for a desktop client that is deployed on premises. The desktop client requires direct connectivity to the RDS cluster.
The company must give the development team the ability to connect to...
Let's analyze each option carefully:
Option A: Create a VPC and two public subnets. Create the RDS cluster in the public subnets. Use AWS Site-to-Site VPN with a customer gateway in the company's office.
- Explanation: In this option, the RDS cluster is placed in public subnets, meaning the RDS instance would be directly accessible from the internet. While the Site-to-Site VPN adds security for the office to the AWS environment, exposing the RDS cluster in public subnets is a significant security risk. It would allow potential internet traffic to reach the RDS instance, which is undesirable for most production environments.
- Why rejected: Exposing RDS to the public internet in this way is not secure and goes against best practices for placing database instances in public subnets, as it increases the attack surface.
Option B: Create a VPC and two private subnets. Create the RDS cluster in the private subnets. Use AWS Site-to-Site VPN with a customer gateway in the company's office.
- Explanation: This option creates a more secure setup by placing the RDS cluster in private subnets, making it not directly accessible from the public internet. The use of an AWS Site-to-Site VPN ensures that only authorized users from the office can access the AWS VPC securely over an encrypted connection.
- Why selected: Placing the RDS cluster in private subnets is a best practice for securing the database. The VPN connection ensures secure connectivity between the office and AWS, allowing the development team to access the RDS cluster securely when they are in the office. This setup offers a good balance of security and functionality without exposing the RDS instance to the internet.
Option C: Create a VPC and two private subnets. Create the RDS cluster in the private subnets. Use RDS security groups to allow the company's office IP ranges to access the cluster.
- Ex...
Author: Siddharth · Last updated Jul 12, 2026
A company has created an OU in AWS Organizations for each of its engineering teams. Each OU owns multiple AWS accounts. The organization has hundreds of AWS accounts.
A solutions architect must design a solution so that each OU ca...
Key Factors for Decision:
- Centralized Management: The solution needs to handle multiple AWS accounts and organizational units (OUs) effectively, ensuring that each engineering team (OU) can view usage costs across all the accounts they manage.
- Scalability: With hundreds of AWS accounts, the solution must be scalable without requiring manual intervention for each account.
- Visualization and Access: The teams need easy access to a breakdown of costs, preferably through dashboards that are easy to interpret.
Option-by-Option Analysis:
A) Create an AWS Cost and Usage Report (CUR) for each OU by using AWS Resource Access Manager. Allow each team to visualize the CUR through an Amazon QuickSight dashboard.
- Pros:
- AWS Cost and Usage Reports (CUR) are detailed reports that include information on costs and usage at a granular level.
- QuickSight provides a powerful and customizable dashboard to visualize and explore CUR data.
- Cons:
- Separate CUR for each OU: The need to create a CUR for each organizational unit (OU) adds complexity in managing multiple reports, especially when dealing with a large number of accounts. It also increases administrative overhead, as every OU must be separately configured for cost reporting and visualization.
- Using AWS Resource Access Manager (RAM) could be unnecessary in this scenario, as it would introduce complexity without providing much benefit for centralized cost visibility.
B) Create an AWS Cost and Usage Report (CUR) from the AWS Organizations management account. Allow each team to visualize the CUR through an Amazon QuickSight dashboard.
- Pros:
- Centralized Reporting: Creating a CUR at the AWS Organizations management account level allows for centralized cost reporting across all accounts in the organization. This solution would consolidate data and eliminate the need to manage separate reports for each OU.
- QuickSight Dashboards: Teams can use QuickSight to visualize the CUR and get a breakdown of usage costs. This provides detailed, interactive visualizations that can be tailored to specific needs.
- Scalable: This approach scales well with a large number of accounts and teams. The management account can handle cos...
Author: Sophia · Last updated Jul 6, 2026
A company is storing data on premises on a Windows file server. The company produces 5 GB of new data daily.
The company migrated part of its Windows-based workload to AWS and needs the data to be available on a file system in the cloud. The company already has established an AWS ...
To select the most appropriate data migration strategy for moving data from an on-premises Windows file server to AWS, the following key factors should be considered:
Key Factors:
1. Existing infrastructure: The company already has an AWS Direct Connect connection, which provides a dedicated network connection to AWS. This is important for ensuring high-speed data transfer.
2. Data size: The company produces 5 GB of new data daily, which should be efficiently transferred and stored in AWS.
3. File system in the cloud: The company needs a file system in the cloud to store the data that was previously on the Windows file server.
4. Windows-based workload: The company is using a Windows-based file server on-premises, so the solution should be compatible with the Windows environment.
Option A: Use the file gateway option in AWS Storage Gateway to replace the existing Windows file server, and point the existing file share to the new file gateway.
- Reasoning:
- AWS Storage Gateway is a hybrid cloud storage service that enables on-premises applications to seamlessly use AWS cloud storage. The File Gateway configuration allows the on-premises file server to connect directly to cloud-based storage such as Amazon S3.
- While this solution can replace the file server with cloud-based storage, it might not be the best fit for a scenario requiring a dedicated file system like Amazon FSx or Amazon EFS. File Gateway integrates directly with Amazon S3, which may not be ideal for workloads requiring a more traditional file system interface.
- Why it’s rejected:
- Since the company needs a file system in the cloud (likely to support more complex file operations like Windows-based file sharing), using S3 through a file gateway may not meet the exact requirements for a file system.
Option B: Use AWS DataSync to schedule a daily task to replicate data between the on-premises Windows file server and Amazon FSx.
- Reasoning:
- AWS DataSync is a fully managed service that automates and accelerates data transfer between on-premises storage and AWS storage services.
- Amazon FSx is a fully managed Windows file system in the cloud, designed specifically for Windows workloads. It provides features like SMB and NTFS, which are well-suited to Windows file server workloads.
- DataSync is optimized for large data transfers and can replicate t...
Author: Lucas Carter · Last updated Jul 6, 2026
A company's solutions architect is reviewing a web application that runs on AWS. The application references static assets in an Amazon S3 bucket in the us-east-1 Region. The company needs resiliency across multiple AWS Regions. The company already has created a...
Let's evaluate each option carefully based on operational overhead, resiliency, and simplicity.
Option A:
Configure the application to write each object to both S3 buckets. Set up an Amazon Route 53 public hosted zone with a record set by using a weighted routing policy for each S3 bucket. Configure the application to reference the objects by using the Route 53 DNS name.
- Operational Overhead: This solution would require the application to handle writing to both S3 buckets, adding complexity. The use of Route 53 with a weighted routing policy to manage the S3 bucket failover requires ongoing management and monitoring, especially when adding/removing objects or troubleshooting issues with DNS routing.
- Resiliency: Although this approach would provide failover capability by routing traffic to the healthy S3 bucket, the failure handling would need to be actively managed by adjusting Route 53 configurations. This could be error-prone and may require more manual intervention.
- Complexity: The DNS-based solution adds a layer of complexity in maintaining consistency between S3 buckets and managing the failover logic in Route 53.
Why this option is rejected: It introduces unnecessary complexity and higher operational overhead due to needing to manage both the application writes and DNS configurations for failover.
---
Option B:
Create an AWS Lambda function to copy objects from the S3 bucket in us-east-1 to the S3 bucket in the second Region. Invoke the Lambda function each time an object is written to the S3 bucket in us-east-1. Set up an Amazon CloudFront distribution with an origin group that contains the two S3 buckets as origins.
- Operational Overhead: This solution requires configuring a Lambda function that runs each time an object is written to the S3 bucket. This introduces additional operational overhead because you would need to manage the Lambda function and ensure it is running reliably.
- Resiliency: The setup with CloudFront using an origin group with two S3 buckets provides automatic failover across Regions. However, managing the Lambda function to copy data between Regions adds complexity.
- Complexity: The Lambda function, while automating cross-region replication, increases the complexity of the solution. Additionally, the added cost of running Lambda functions and monitoring them may add extra effor...
Author: Zara · Last updated Jul 6, 2026
A solutions architect is creating an application that will handle batch processing of large amounts of data. The input data will be held in Amazon S3 and the output data will be stored in a different S3 bucket. For processing, the application will transfer the data over the network b...
Let's evaluate each option to determine how it impacts data transfer costs:
Option A: Place all the EC2 instances in an Auto Scaling group.
- Explanation: An Auto Scaling group helps scale the number of EC2 instances based on traffic demands. However, it doesn't directly affect data transfer costs. It mainly addresses scaling for handling load, not how data is transferred between instances or S3 buckets.
- Why rejected: While Auto Scaling is useful for scaling resources dynamically, it doesn't impact the reduction of data transfer costs. The focus here should be on the placement of EC2 instances to minimize data transfer charges.
Option B: Place all the EC2 instances in the same AWS Region.
- Explanation: Placing all the EC2 instances in the same AWS Region ensures that data transfer between the EC2 instances and Amazon S3 (which are also region-specific services) is free. Data transfer within the same AWS Region is generally free or incurs lower costs, as there is no inter-region data transfer involved.
- Why selected: This is a strong option because data transfer within the same region is typically cheaper than data transfer across different regions. By ensuring all EC2 instances and S3 buckets are in the same region, the overall cost of data transfer is minimized.
Option C: Place all the EC2 instances in the same Availability Zone.
- Explanation: Placing EC2 instances in the same Availability Zone (AZ) may reduce data transfer costs between EC2 instances because data transfer within the same...
Author: Nathan · Last updated Jul 12, 2026
A company is hosting a three-tier web application in an on-premises environment. Due to a recent surge in traffic that resulted in downtime and a significant financial impact, company management has ordered that the application be moved to AWS. The application is written in .NET and has a dependency on a MySQL database. A solutions architect must design a scalable...
Let's go through the options, evaluating their suitability based on the requirements of scalability, high availability, and the company's reliance on a .NET application with a MySQL database.
Option A:
Use AWS Elastic Beanstalk to create a new application with a web server environment and an Amazon RDS MySQL Multi-AZ DB instance. The environment should launch a Network Load Balancer (NLB) in front of an Amazon EC2 Auto Scaling group in multiple Availability Zones. Use an Amazon Route 53 alias record to route traffic from the company’s domain to the NLB.
- Scalability: Elastic Beanstalk automatically scales the application, and the EC2 Auto Scaling group ensures it can handle increased load.
- High Availability: Using a Multi-AZ deployment of Amazon RDS MySQL ensures that the database is highly available. The Network Load Balancer in front of the Auto Scaling group helps route traffic effectively across multiple Availability Zones.
- Suitability: This is a simple and effective option for web applications. Elastic Beanstalk simplifies deployment and scaling, while RDS MySQL Multi-AZ provides robust database availability.
- Challenges: Elastic Beanstalk’s automatic scaling and deployment can be convenient, but may not provide as much flexibility in fine-tuning the infrastructure, especially if complex custom configurations are needed.
Why rejected: This solution is valid, but Elastic Beanstalk might not be the most customizable option for specific needs or advanced configurations. A more flexible solution like CloudFormation may be more appropriate.
---
Option B:
Use AWS CloudFormation to launch a stack containing an Application Load Balancer (ALB) in front of an Amazon EC2 Auto Scaling group spanning three Availability Zones. The stack should launch a Multi-AZ deployment of an Amazon Aurora MySQL DB cluster with a Retain deletion policy. Use an Amazon Route 53 alias record to route traffic from the company’s domain to the ALB.
- Scalability: EC2 Auto Scaling across multiple Availability Zones ensures the web application can scale to meet increased traffic.
- High Availability: The Aurora MySQL DB cluster in a Multi-AZ deployment provides enhanced availability and durability.
- Performance: Aurora is a more performance-optimized solution compared to traditional MySQL. Aurora can also automatically scale with increased traffic, making it more suitable for high-demand applications.
- Suitability: CloudFormation offers the flexibility to customize infrastructure as needed. Aurora’s MySQL compatibility ensures that the existing .NET application can interact with it without major code changes.
- Challenges: The setup might be more complex than Elastic Beanstalk, but it provides more control over the architecture.
Why this option is selected: This solution provides both high availability and scalability with the combination of EC2 Auto Scaling and Aurora. Aurora is well-suited for handling large-scale applications, and CloudFormation offers greater flexibility in managing infrastructure.
---
Option C:
Use AWS Ela...
Author: Alexander · Last updated Jul 6, 2026
A company is using AWS Organizations to manage multiple AWS accounts. For security purposes, the company requires the creation of an Amazon Simple Notification Service (Amazon SNS) topic that enables integration with a third-party alerting system in all the Organizations member accounts.
A solutions architect used an AWS CloudFormation template to create the SNS topic and stack sets to automate the deploymen...
Let's evaluate the options based on the requirement of deploying an Amazon SNS topic in all AWS accounts within an AWS Organization using AWS CloudFormation StackSets with security and ease of management in mind.
Key Requirements:
1. Security: The SNS topic must be integrated securely with a third-party alerting system across all member accounts in AWS Organizations.
2. Automation: Deployment should be automated and consistent across all accounts in the organization.
3. Permissions: Trusted access in AWS Organizations has been enabled, which simplifies managing permissions and allows StackSets to deploy resources across multiple accounts.
Option A:
Create a stack set in the Organizations member accounts. Use service-managed permissions. Set deployment options to deploy to an organization. Use CloudFormation StackSets drift detection.
- Service-managed permissions allow StackSets to assume necessary roles automatically in each member account, streamlining management.
- Drift detection can check if the stack is out of sync, which is useful for monitoring but doesn't directly relate to deployment automation.
- Challenges: This option suggests creating a stack set in the member accounts themselves, which is typically not how StackSets are managed. Normally, you define StackSets in the management account and deploy them across member accounts, not in individual member accounts.
Why rejected: StackSets should be created in the management account, not the member accounts. This option introduces confusion by suggesting the creation of stacks within member accounts, which is not ideal for centralized control and automation.
---
Option B:
Create stacks in the Organizations member accounts. Use self-service permissions. Set deployment options to deploy to an organization. Enable the CloudFormation StackSets automatic deployment.
- Self-service permissions would allow individual accounts to manage their own stacks, which is not optimal for a centralized, automated deployment model.
- Automatic deployment is useful but less secure since self-service permissions would require each account to manage its deployment, potentially leading to inconsistent configurations.
- Challenges: The self-service model would allow accounts to manage their own resources, which contradicts the goal of centralized, automated deployment and consistent configuration across all accounts.
Why rejected: Self-service per...
Author: Ava · Last updated Jul 6, 2026
A company hosts a multi-tier web application that uses an Amazon Aurora MySQL DB cluster for storage. The application tier is hosted on Amazon EC2 instances. The company's IT security guidelines mandate that the database credentials be encrypted and rotated ev...
Let's analyze the options carefully based on the requirement of securely storing and rotating database credentials every 14 days with the least operational effort:
Option A: Create a new AWS Key Management Service (AWS KMS) encryption key. Use AWS Secrets Manager to create a new secret that uses the KMS key with the appropriate credentials. Associate the secret with the Aurora DB cluster. Configure a custom rotation period of 14 days.
- Explanation: AWS Secrets Manager is specifically designed for securely storing and managing sensitive information such as database credentials. Secrets Manager integrates with Aurora MySQL and can automatically rotate database credentials without requiring custom Lambda functions. It supports KMS for encryption and can be configured to rotate credentials at a defined interval (in this case, every 14 days).
- Why selected: This option is the most appropriate because it directly leverages AWS Secrets Manager, which is purpose-built for this use case, reducing operational overhead. Secrets Manager automates the credential rotation process, ensuring compliance with the security guideline while minimizing manual effort and complexity.
Option B: Create two parameters in AWS Systems Manager Parameter Store: one for the user name as a string parameter and one that uses the SecureString type for the password. Select AWS Key Management Service (AWS KMS) encryption for the password parameter, and load these parameters in the application tier. Implement an AWS Lambda function that rotates the password every 14 days.
- Explanation: AWS Systems Manager Parameter Store is another option for storing sensitive information securely using KMS encryption. However, it requires additional configuration for credential rotation using a Lambda function, which introduces more operational effort. You would need to write and manage the Lambda function, handle parameter retrieval in your application, and ensure the credentials are updated.
- Why rejected: While this option does meet the requirement of secure storage and credential rotation, it introduces more manual work compared to Secrets Manager, which already provides automated credential rotation out-of-the-box. Additionally, using Parameter Store may not be as seamless in terms of integration with Aurora as Secrets Manager.
Option C: Store a file that contains the credentials in an AWS Key Management Service (AWS KMS) encrypted Amazon Elastic File System (Amazon EFS) file system. Mount the EFS file system in all EC2 instances of the application tier. Restrict...
Author: SilverBear · Last updated Jul 12, 2026
A company wants to migrate its workloads from on premises to AWS. The workloads run on Linux and Windows. The company has a large on-premises infrastructure that consists of physical machines and VMs that host numerous applications.
The company must capture details about the system configuration, system performance, running processes, and network connections of its on-premises workloads. The company also must divide the on-premises applications into groups for AWS migrations. The company needs recommendations...
Let's go through the available options based on the company's need to assess its on-premises workloads, capture detailed system information, group applications for migration, and get recommendations for cost-effective EC2 instance types for running the workloads on AWS.
Key Requirements:
1. Capture system details: System configuration, performance, running processes, and network connections.
2. Group applications for migration: Organize workloads for migration into logical groups.
3. Recommendations for EC2 instance types: Provide cost-effective EC2 instance type recommendations for running workloads.
Option A:
Assess the existing applications by installing AWS Application Discovery Agent on the physical machines and VMs.
- Assessment: The AWS Application Discovery Agent collects critical information about on-premises workloads, including system configurations, performance metrics, running processes, and network connections.
- Relevance: This agent is specifically designed to perform a detailed assessment of on-premises environments and is a foundational tool for planning the migration to AWS.
- Why selected: This is a core tool for gathering detailed insights on the on-premises infrastructure, making it an essential step in the migration process.
Why not other options: This is the primary tool for workload discovery and assessment, making it a natural first step in the migration process.
---
Option B:
Assess the existing applications by installing AWS Systems Manager Agent on the physical machines and VMs.
- Assessment: The AWS Systems Manager Agent (SSM Agent) is used for managing and automating tasks on EC2 instances. However, it is not designed to gather system-level discovery information required for migration assessments.
- Relevance: While the SSM Agent can provide valuable insights for ongoing management and automation, it does not have the discovery capabilities required for detailed migration planning.
- Why rejected: The SSM Agent does not provide the detailed system and performance data necessary for migration assessments.
---
Option C:
Group servers into applications for migration by using AWS Systems Manager Application Manager.
- Grouping: AWS Systems Manager Application Manager allows you to manage applications and their resources after migration, but it doesn't provide a direct mechanism to group on-premises servers for migration planning.
- Relevance: Systems Manager Application Manager is more about managing applications post-migration and does not play a role in pre-migration grouping and planning.
- Why rejected: This tool is useful for post-migration management, but does not help in the pre-migration step of grouping workloads.
---
Option D:
Group servers int...
Author: Akash · Last updated Jul 6, 2026
A company is hosting an image-processing service on AWS in a VPC. The VPC extends across two Availability Zones. Each Availability Zone contains one public subnet and one private subnet.
The service runs on Amazon EC2 instances in the private subnets. An Application Load Balancer in the public subnets is in front of the service. The service needs to communicate with the internet and does so through two NAT gateways. The service uses Amazon S3 for image storage. The EC2 instances retrieve approximately 1 =D0=A2=D0=92 of data from an S3 bucket each day.
The company has promoted t...
Let’s review each option in light of the requirements: reducing cloud expenditures without compromising security or increasing operational overhead, while maintaining the current configuration with secure access to the internet and S3.
Option A: Replace the NAT gateways with NAT instances. In the VPC route table, create a route from the private subnets to the NAT instances.
- Cost considerations: NAT gateways are managed services that incur higher costs compared to NAT instances, which can be more cost-effective since they are simply EC2 instances running a NAT service. This would reduce costs significantly.
- Security: NAT instances require manual management (e.g., monitoring, patching, scaling), which increases operational overhead. In contrast, NAT gateways are fully managed by AWS and offer better fault tolerance and scaling without requiring user intervention.
- Operational overhead: Moving from NAT gateways to NAT instances introduces additional operational complexity, as the NAT instances must be managed and scaled manually. This would require ongoing effort to monitor and handle failures.
- Why rejected: While this solution could reduce costs, it increases operational overhead significantly. For a highly secure and low-operational overhead environment, this is not the best choice.
---
Option B: Move the EC2 instances to the public subnets. Remove the NAT gateways.
- Cost considerations: Moving EC2 instances to the public subnets would eliminate the need for NAT gateways, which can save money on data transfer fees associated with the NAT gateways.
- Security: Moving EC2 instances to public subnets means that they would have direct access to the internet. This is a security risk, especially since the service is promoted as highly secure. Public subnets expose the EC2 instances to the internet, which could make them more vulnerable to attacks.
- Operational overhead: This option would not only compromise security but would also require more stringent security measures (e.g., managing security groups and network ACLs more carefully), which would increase operational complexity.
- Why rejected: This option compromises the security of the service, which contradicts the company's requirement for a highly secure service.
---
Option C: Set up an S3 gateway VPC endpoint in the VPC. Attach an endpoint policy to the endpoint to allow the required actions on the S3 bucket.
- Cost considerations: This solution is cost-effective bec...
Author: Kunal · Last updated Jul 6, 2026
A streaming media company is rebuilding its infrastructure to accommodate increasing demand for video content that users consume daily.
The company needs to process terabyte-sized videos to block some content in the videos. Video processing can take up to 20 minutes.
The compa...
Let's break down the options and analyze which will meet the company's requirements to process terabyte-sized videos efficiently while scaling with demand and remaining cost-effective.
Option A: Use AWS Lambda functions to process videos. Store video metadata in Amazon DynamoDB. Store video content in Amazon S3 Intelligent-Tiering.
- Explanation: AWS Lambda is a serverless compute service that can scale automatically, but it has limitations, especially around the duration of execution (max 15 minutes per invocation). Given that video processing takes up to 20 minutes, Lambda would not be ideal here. DynamoDB is great for metadata storage but doesn't fit well with the requirement for handling large amounts of video data (metadata aside). S3 Intelligent-Tiering is good for cost optimization based on access patterns but doesn’t address the heavy lifting of video processing.
- Why rejected: AWS Lambda cannot handle the processing time of 20 minutes required for video processing. Moreover, Lambda may not be cost-effective for large-scale video processing because of its short execution time limit.
Option B: Use Amazon Elastic Container Service (Amazon ECS) and AWS Fargate to implement microservices to process videos. Store video metadata in Amazon Aurora. Store video content in Amazon S3 Intelligent-Tiering.
- Explanation: ECS with Fargate allows containerized applications to scale automatically based on demand. This solution can handle long-running tasks like video processing efficiently. Storing video metadata in Amazon Aurora is also appropriate for structured data and scalable, but storing video content in S3 Intelligent-Tiering might not be the best fit due to unpredictable access patterns of large video files. S3 Standard or other more optimized tiers would be a better choice for large video content.
- Why rejected: Storing video content in S3 Intelligent-Tiering may not be optimal due to the nature of video consumption (likely frequent access). However, ECS and Fargate are suitable for processing long-running tasks.
Option C: Use Amazon EC2 instances in an Auto Scaling group behind an Application Load Balancer (ALB) to process videos. Store video content in Amazon S3 Standard. Use Amazon Simple Queue Service (Amazon SQS) for que...
Author: Henry · Last updated Jul 12, 2026
A company recently deployed an application on AWS. The application uses Amazon DynamoDB. The company measured the application load and configured the RCUs and WCUs on the DynamoDB table to match the expected peak load. The peak load occurs once a week for a 4-hour period and is double the average load. The application load is close to the average load for the rest of the week. The access pattern includes many more wr...
To address this scenario, the company is looking to minimize the cost of using Amazon DynamoDB while maintaining performance during peak load periods. Let's analyze each option to determine the best solution:
A) Use AWS Application Auto Scaling to increase capacity during the peak period. Purchase reserved RCUs and WCUs to match the average load.
- Auto Scaling: This is a viable option to automatically scale the RCUs and WCUs based on the demand. During peak times, the system can scale up, and during off-peak times, it can scale down. This will ensure the application performs well even under varying loads. However, purchasing reserved capacity for the average load can still be more expensive than other flexible solutions, especially when the demand fluctuates significantly.
- Challenges: Reserved capacity locks in the provisioned capacity for the entire period, which could lead to over-provisioning during off-peak times. This is not ideal because the application has a fluctuating load, with many more writes than reads.
B) Configure on-demand capacity mode for the table.
- On-demand capacity mode: This automatically adjusts to accommodate varying levels of read and write requests. With on-demand capacity, there is no need to configure RCUs and WCUs, which can be beneficial for workloads with unpredictable or fluctuating traffic. This can save costs by scaling the capacity dynamically based on the actual usage.
- Challenges: While on-demand capacity can be cost-effective for unpredictable loads, it could still result in higher costs if the peak load exceeds the thresholds and there are many write-heavy operations. This is more of a "catch-all" approach, but it could lead to higher costs during the peak load when compared to a more targeted solution.
C) Configure DynamoDB Accelerator (DAX) in front of the table. Reduce the provisioned read capacity to match the new peak load on the table.
- DAX (DynamoDB Accelerator): DAX is a caching service that improves the performance of DynamoDB by caching frequently accessed items, par...
Author: Aarav · Last updated Jul 6, 2026
A company runs an on-premises application on a Kubernetes cluster. The company recently added millions of new customers. The company's existing on-premises infrastructure is unable to handle the large number of new customers. The company needs to migrate the on-premises application to the AWS Cloud.
The company will migrate to an Amazon Elastic Kubernetes Service (Amazon EKS) cluster. The company doe...
In order to meet the requirements of the company with least operational overhead, we need to consider the level of management and automation involved in each option, while ensuring scalability and the ability to handle large numbers of customers. Let's evaluate each option:
Option A: Use a self-managed node to supply compute capacity. Deploy the application to the new EKS cluster.
- Pros: Provides full control over the nodes. The company can choose the instance types and configurations that best fit the application's needs.
- Cons: This option requires managing and maintaining the EC2 instances, which involves patching, scaling, and monitoring the infrastructure. This increases the operational overhead.
- Conclusion: This is not ideal as it increases the operational burden, which the company is trying to avoid.
Option B: Use managed node groups to supply compute capacity. Deploy the application to the new EKS cluster.
- Pros: AWS manages the EC2 instances, including scaling and health checks. This reduces operational overhead compared to self-managed nodes.
- Cons: The company still needs to manage the configuration of the nodes and ensure they are appropriately sized. It requires some ongoing management but is better than managing individual nodes.
- Conclusion: This is a good option as it reduces operational overhead compared to Option A, but it still requires more management than some other options.
Option C: Use AWS Fargate to supply compute capacity. Create a Fargate profile. Use the Fargate profile to deploy the application.
- Pros: AWS Fargate is a serverless compute engine for containers. It completely abstracts the underlying compute infrastructure, allowing the company to...
Author: Vivaan · Last updated Jul 12, 2026
A solutions architect needs to advise a company on how to migrate its on-premises data processing application to the AWS Cloud. Currently, users upload input files through a web portal. The web server then stores the uploaded files on NAS and messages the processing server over a message queue. Each media file can take up to 1 hour to process. The company has determined that the number of media files awaiting proc...
In order to determine the most cost-effective migration strategy, let’s analyze the key factors and requirements presented:
Key Considerations:
1. High Volume During Business Hours: The company experiences a significant increase in the number of files needing processing during business hours, followed by a sharp decline after hours.
2. Cost-Effective Scaling: The solution should scale according to demand and be cost-effective, particularly during low-traffic periods (i.e., after business hours).
3. Processing Time: Media files can take up to an hour to process, which could influence the choice of compute resources.
4. Storage Needs: Processed files need to be stored, and efficient, scalable storage must be used.
Option Breakdown:
A) Create a queue using Amazon SQS. Configure the existing web server to publish to the new queue. When there are messages in the queue, invoke an AWS Lambda function to pull requests from the queue and process the files. Store the processed files in an Amazon S3 bucket.
- Pros:
- SQS is a managed service that scales automatically, and Lambda can scale up or down based on demand.
- Using Lambda is ideal for short, bursty processing jobs, as it provides automatic scaling with no need to manage infrastructure.
- S3 is highly cost-effective for storing processed files.
- Cons:
- Lambda has a processing time limit (15 minutes), which is insufficient for processing media files that can take up to 1 hour. This would require workarounds or segmentation of the media files, making this approach impractical for the use case.
B) Create a queue using Amazon MQ. Configure the existing web server to publish to the new queue. When there are messages in the queue, create a new Amazon EC2 instance to pull requests from the queue and process the files. Store the processed files in Amazon EFS. Shut down the EC2 instance after the task is complete.
- Pros:
- Amazon MQ is a managed message broker that supports traditional messaging protocols, which might be necessary for legacy systems.
- EC2 instances can provide the necessary compute power for longer processing times (up to 1 hour).
- Amazon EFS provides shared storage for the processed files.
- Cons:
- This option involves the overhead of managing EC2 instances and shutting them down after use, which may not be cost-effective, particularly if many instances are required to handle spikes in demand. Additionally, EFS is more expensive compared to S3 for large data storage.
- Amazon MQ may be overkill compared to SQS for this use case, especially given that SQS is simpler, more cost-effective, and better in...
Author: IceDragon2023 · Last updated Jul 6, 2026
A company is using Amazon OpenSearch Service to analyze data. The company loads data into an OpenSearch Service cluster with 10 data nodes from an Amazon S3 bucket that uses S3 Standard storage. The data resides in the cluster for 1 month for read-only analysis. After 1 month, the company deletes the index that contains the data from the cluster. For compliance purposes, the company must retain a copy of all input da...
To address the company's requirements, the solution should:
1. Meet compliance requirements by retaining a copy of all input data.
2. Minimize ongoing costs associated with storing data in Amazon OpenSearch Service, particularly since the data is only used for read-only analysis for 1 month before being deleted.
3. Provide cost-effective storage for the data after 1 month, when it is no longer needed in OpenSearch Service for active analysis.
Option Breakdown:
A) Replace all the data nodes with UltraWarm nodes to handle the expected capacity. Transition the input data from S3 Standard to S3 Glacier Deep Archive when the company loads the data into the cluster.
- Pros:
- UltraWarm nodes are optimized for read-only, infrequently accessed data, making them a good fit for this scenario where the data is read-only for 1 month.
- S3 Glacier Deep Archive is the lowest-cost storage option, which could satisfy the compliance requirement for retaining input data after it is removed from the OpenSearch cluster.
- Cons:
- Transitioning the data to S3 Glacier Deep Archive immediately when it's loaded into the cluster would make it difficult to access the data while it's still being used in the OpenSearch cluster. Glacier Deep Archive is ideal for long-term storage but is not efficient for active analysis, especially within the 1-month retention period.
- This option doesn't fully optimize costs during the 1-month retention period when data is actively used in OpenSearch.
B) Reduce the number of data nodes in the cluster to 2. Add UltraWarm nodes to handle the expected capacity. Configure the indexes to transition to UltraWarm when OpenSearch Service ingests the data. Transition the input data to S3 Glacier Deep Archive after 1 month by using an S3 Lifecycle policy.
- Pros:
- UltraWarm nodes will reduce costs during the read-only analysis period by providing low-cost storage for data in OpenSearch.
- Using S3 Glacier Deep Archive after 1 month through an S3 Lifecycle policy is a cost-effective way to retain the data for compliance while reducing storage costs.
- Reducing the number of data nodes to 2 will further reduce costs while maintaining the necessary capacity for analysis.
- Cons:
- No major cons for this option, as it optimizes costs both during the active use period and the retention period for compliance.
C) Reduce the number of data nodes in the cluster to 2. Add UltraWarm nodes to handle the expected capacity. Configure the indexes to transition to UltraWarm when OpenS...
Author: Lina Zhang · Last updated Jul 6, 2026
A company has 10 accounts that are part of an organization in AWS Organizations. AWS Config is configured in each account. All accounts belong to either the Prod OU or the NonProd OU.
The company has set up an Amazon EventBridge rule in each AWS account to notify an Amazon Simple Notification Service (Amazon SNS) topic when an Amazon EC2 security group inbound rule is created with 0.0.0.0/0 as the source. The company's security team is subscribed to the SNS topic.
For all accounts in the No...
To meet the requirement of removing the ability to create a security group inbound rule with 0.0.0.0/0 as the source in all accounts under the NonProd OU, the solution should focus on enforcing a policy that prevents the creation of such rules with the least operational overhead. Let's evaluate each option:
A) Modify the EventBridge rule to invoke an AWS Lambda function to remove the security group inbound rule and to publish to the SNS topic. Deploy the updated rule to the NonProd OU.
- Pros:
- The approach would automatically remove any rule with 0.0.0.0/0 and notify via SNS.
- Cons:
- This involves invoking a Lambda function and adding extra logic to remove the rule once it is created, which introduces additional complexity and operational overhead. Lambda functions also need to be managed, monitored, and maintained.
- It does not directly prevent the creation of the rule, but rather acts as a reactive solution that removes the rule after creation, which is not ideal in this case.
B) Add the vpc-sg-open-only-to-authorized-ports AWS Config managed rule to the NonProd OU.
- Pros:
- The vpc-sg-open-only-to-authorized-ports AWS Config rule checks security groups to ensure that they are only open to authorized ports, which can help ensure compliance.
- Cons:
- This rule does not specifically address the creation of inbound rules with 0.0.0.0/0. It focuses on security group configurations related to authorized ports, so it doesn't directly enforce the restriction needed here. Therefore, it does not fully meet the requirement.
C) Configure an SCP to allow the ec2:AuthorizeSecurityGroupIngress action when the value of the aws:SourceIp condition key is not 0.0.0.0/0. Apply the SCP to the NonProd OU.
- Pros:
- This SCP would allow the ec2:AuthorizeSecurityGroupIngress action, but only when the source IP is not 0.0.0.0/0, which is a good attempt at limiting what IP addresses can be used a...
Author: David · Last updated Jul 6, 2026
A company is launching a new application that requires a structured database to store user profiles, application settings, and transactional data. The database must be scalable with application traffic and ...
Let's evaluate each option based on the following requirements: scalability, backups, cost-effectiveness, and ease of management.
Option A: Deploy a self-managed database on Amazon EC2 instances by using open source software. Use Spot Instances for cost optimization. Configure automated backups to Amazon S3.
- Pros:
- Self-managed databases can be cost-effective, especially using open-source software.
- Spot Instances can provide significant savings on EC2 costs.
- Automated backups to Amazon S3 can be configured easily.
- Cons:
- Management Overhead: Self-managing the database means the company needs to handle updates, scaling, and backups, which increases operational complexity.
- Scalability: Spot Instances can be terminated by AWS with short notice, which could cause issues in terms of scalability and availability, especially with transactional data.
- Backup: Backing up to S3 is not ideal for structured database solutions like this; using Amazon S3 for backups is better suited for static storage, not databases, unless there is an additional complex backup strategy implemented.
- Conclusion: This option could be cost-effective in the short term but introduces significant operational overhead and possible reliability issues with Spot Instances, making it less desirable.
Option B: Use Amazon RDS. Use on-demand capacity mode for the database with General Purpose SSD storage. Configure automatic backups with a retention period of 7 days.
- Pros:
- Managed Service: Amazon RDS is a fully managed database service, reducing operational overhead (AWS manages backups, scaling, and updates).
- Scalability: On-demand capacity mode scales with application traffic, making it ideal for fluctuating workloads.
- Backups: Automatic backups are handled by RDS, ensuring data is safely backed up and easily recoverable.
- Cost-effective: RDS is relatively cost-effective for moderate workloads with the option to scale capacity up or down based on demand.
- Cons:
- May be slightly more expensive than a self-managed EC2 database, especially with high on-demand usage.
- Conclusion: This is a solid choice for most use cases as it balances cost and management overhead. The only drawback is the higher cost compared to a self-managed solution.
Option C: Use Amazon Aurora Serverless for the database. Use serverless capacity scaling. Configure automated backups to Amazon S3.
- Pros:
- Serverless: Aurora Serverless automatically scales with application demand, making it an excellent option for variable workloads, where the application’s traffic fluctuates.
- Automatic ...
Author: Leo · Last updated Jul 12, 2026
A company hosts a Git repository in an on-premises data center. The company uses webhooks to invoke functionality that runs in the AWS Cloud. The company hosts the webhook logic on a set of Amazon EC2 instances in an Auto Scaling group that the company set as a target for an Application Load Balancer (ALB). The Git server calls the ALB for the configured webhoo...
To move the solution to a serverless architecture with the least operational overhead, we need to evaluate each option based on the following criteria:
1. Serverless nature: The solution should minimize the need to manage infrastructure.
2. Ease of scalability: It should scale automatically based on incoming webhook requests.
3. Operational overhead: The solution should be easy to manage without needing constant intervention, such as provisioning and maintaining infrastructure.
4. Integration with Git: The solution should allow the Git server to call the necessary endpoint, similar to how the existing system is designed.
Option Breakdown:
A) For each webhook, create and configure an AWS Lambda function URL. Update the Git servers to call the individual Lambda function URLs.
- Pros:
- AWS Lambda function URLs are a simple and serverless way to expose HTTP endpoints for Lambda functions.
- This option provides minimal operational overhead as the Lambda functions are fully managed.
- Cons:
- This solution requires configuring multiple Lambda function URLs if there are many webhooks, which could become cumbersome to manage as the number of webhooks increases.
- This might not be as flexible or organized as using a central API Gateway to manage all the webhooks in one place.
B) Create an Amazon API Gateway HTTP API. Implement each webhook logic in a separate AWS Lambda function. Update the Git servers to call the API Gateway endpoint.
- Pros:
- API Gateway provides a centralized, scalable endpoint that can handle many webhooks.
- AWS Lambda is serverless and scales automatically, reducing operational overhead.
- This solution is easy to manage and is very flexible, as you can manage multiple webhook logic separately in different Lambda functions.
- API Gateway integrates well with Lambda, allowing you to define routes for each webhook.
- Cons:
- There might be slight complexity in setting up routes in API Gateway, especially for many webhooks.
- While simple, there is a small added management layer with the API Gateway, but it is minimal compared to managing EC2 instances.
C) Deploy the webhook logic to AWS App Runner. Create an ALB, and set App Runner as the target. Update the Git...
Author: Lucas · Last updated Jul 6, 2026
A company is planning to migrate 1,000 on-premises servers to AWS. The servers run on several VMware clusters in the company's data center. As part of the migration plan, the company wants to gather server metrics such as CPU details, RAM usage, operating system information, and ...
To determine the best solution for the company’s migration needs, let's break down the requirements and evaluate each option based on the key factors like ease of implementation, functionality, and scalability:
Requirements:
- Gather server metrics (CPU details, RAM usage, OS information, and running processes) from on-premises servers.
- Query and analyze the collected data.
- The servers are in VMware clusters.
- The solution should facilitate a smooth migration process with the ability to query and analyze the data.
Option A:
Deploy and configure the AWS Agentless Discovery Connector virtual appliance on the on-premises hosts. Configure Data Exploration in AWS Migration Hub. Use AWS Glue to perform an ETL job against the data. Query the data by using Amazon S3 Select.
- Pros: The AWS Agentless Discovery Connector allows gathering detailed metrics from VMware clusters without requiring agents on the individual servers. Data Exploration in AWS Migration Hub can help visualize and analyze the data. AWS Glue can perform ETL tasks, and S3 Select enables querying specific parts of large data stored in Amazon S3.
- Cons: This solution requires configuring the Agentless Discovery Connector and setting up ETL workflows, which can be more complex to implement compared to other options. Additionally, querying through S3 Select may not be as efficient or intuitive as other options like Amazon Athena.
- Best use case: This approach is more suitable when dealing with large datasets, and when extracting data into S3 for further processing or integration with other AWS services. However, it's more complex and may require additional configuration effort.
Option B:
Export only the VM performance information from the on-premises hosts. Directly import the required data into AWS Migration Hub. Update any missing information in Migration Hub. Query the data by using Amazon QuickSight.
- Pros: Amazon QuickSight can be a great tool for visualizing and analyzing data. This option provides an easy way to view VM performance data directly in the Migration Hub console.
- Cons: This option does not provide a detailed way to capture comprehensive server information such as running processes and RAM usage. It only focuses on VM performance data, which might not be sufficient for detailed server migration planning. Additionally, relying on Migration Hub limits the query capability and flexibility compared to using other tools like Athena.
- Best use case: QuickSight is ideal for data visualization but may not be suitable when detailed server metrics like processes and RAM usage are required. This is more suitable for basic performance metrics analysis rather than deep system-level analysis.
...
Author: MysticJaguar44 · Last updated Jul 6, 2026
A company is building a serverless application that runs on an AWS Lambda function that is attached to a VPC. The company needs to integrate the application with a new service from an external provider. The external provider supports only requests that come from public IPv4 addresses that are in an allow list.
The company must provide a single public IP address to t...
To solve the problem, we need to consider how to provide a single public IP address that allows the Lambda function to access the external service while attached to a VPC. Let's evaluate the options and determine which one will meet the requirements.
Key Requirements:
1. The Lambda function is inside a VPC, meaning it has a private IP address by default.
2. The external service only accepts requests from public IPv4 addresses in an allow list.
3. The Lambda function needs to be able to use a single public IP address to interact with the service.
Option A: Deploy a NAT gateway. Associate an Elastic IP address with the NAT gateway. Configure the VPC to use the NAT gateway.
- Explanation: A NAT gateway allows instances in a private subnet (or Lambda function in a VPC) to access the internet using a single public IP address (the Elastic IP associated with the NAT gateway). The Lambda function will route its outbound requests through the NAT gateway, which will use the Elastic IP to interact with the external service.
- Pros: This is a typical solution for providing internet access to resources in private subnets. The NAT gateway ensures that the Lambda function uses a single public IP address for outgoing traffic, as required by the external provider.
- Cons: Although this is an appropriate solution, it involves additional costs and configuration compared to other simpler methods.
- Best Use Case: Ideal when the Lambda function is in a private subnet and needs a single public IP address for internet communication.
Option B: Deploy an egress-only internet gateway. Associate an Elastic IP address with the egress-only internet gateway. Configure the elastic network interface on the Lambda function to use the egress-only internet gateway.
- Explanation: An egress-only internet gateway is designed for IPv6 traffic, allowing outbound communication from instances in a VPC to the internet while blocking inbound traffic. However, the external service only accepts IPv4 addresses, so this solution is not suitable for IPv4 communication.
- Cons: This method would only work for IPv6, which doesn't match the requirement for a public IPv4 address.
- Best Use Case: This solution is not applicable because it’s designed for IPv6 tr...
Author: Mia · Last updated Jul 6, 2026
A solutions architect has developed a web application that uses an Amazon API Gateway Regional endpoint and an AWS Lambda function. The consumers of the web application are all close to the AWS Region where the application will be deployed. The Lambda function only queries an Amazon Aurora MySQL database. The solutions architect has configured the database to have three read replicas.
During testing, the application does not meet performance requirements. Under high load, the applicat...
To address the performance issues of the web application, particularly related to a large number of database connections under high load, let's analyze the situation and the possible solutions.
Key Problem:
- Large number of database connections: The Lambda function is opening too many connections to the Aurora MySQL database under high load, which can overwhelm the database and affect performance.
- Performance improvement is necessary: The application must improve its performance without violating its architecture, and database connection management must be optimized.
Key Factors:
- Aurora MySQL is being used with read replicas, so the solution should improve connection handling to prevent excessive load on the database.
- AWS Lambda is used to interact with the database, so it needs efficient connection management.
Option A: Use the cluster endpoint of the Aurora database.
- Reasoning:
- Aurora cluster endpoint connects to the primary instance of the Aurora cluster. If the application is querying the read replica endpoint, it may not be able to handle write traffic efficiently.
- Using the cluster endpoint could help balance both read and write traffic, but it doesn't directly address the issue of managing the large number of connections that are opened under high load.
- Why it’s rejected:
- This option might not be the most effective for solving the issue of database connection management under high load. It can help with routing but doesn’t directly improve how connections are managed across Lambda invocations.
Option B: Use RDS Proxy to set up a connection pool to the reader endpoint of the Aurora database.
- Reasoning:
- Amazon RDS Proxy is a fully managed, highly available database proxy that can pool and share database connections. This helps improve the efficiency of handling database connections, particularly in serverless environments like Lambda.
- By using RDS Proxy to pool connections to the read replicas of the Aurora database, the Lambda function can re-use existing database connections rather than opening new ones for every invocation. This reduces the load on the database and improves performance.
- Why it’s selected:
- RDS Proxy is specifically designed to improve performance for serverless applications by pooling database connections. This option is highly suited to managing database connections efficiently under high load.
Option C: Use the Lambda Provisioned Concurrency feature.
- Reasoning:
...
Author: Oliver · Last updated Jul 6, 2026
A company is planning to host a web application on AWS and wants to load balance the traffic across a group of Amazon EC2 instances. One of the security requirements is to enable end-to-end encryption in tra...
To meet the requirement of end-to-end encryption in transit between the client and the web server, it’s essential to ensure that the traffic is encrypted from the client to the Application Load Balancer (ALB) and then to the EC2 instances. Let’s go through each option and analyze the scenarios.
Option A: Place the EC2 instances behind an Application Load Balancer (ALB). Provision an SSL certificate using AWS Certificate Manager (ACM), and associate the SSL certificate with the ALB. Export the SSL certificate and install it on each EC2 instance. Configure the ALB to listen on port 443 and to forward traffic to port 443 on the instances.
- Reasoning:
- This option leverages SSL termination at the ALB. The ALB decrypts the traffic at the load balancer level and forwards the unencrypted traffic to the EC2 instances over HTTP (port 80), which is more efficient for load balancing and reduces the need for each EC2 instance to handle SSL decryption.
- End-to-end encryption is achieved because the traffic from the client to the ALB is encrypted with SSL/TLS, and the ALB handles SSL encryption for the traffic between the client and the server.
- The requirement is for end-to-end encryption, so it's crucial to have encryption from the client to the load balancer, and this can be done without requiring SSL on the EC2 instances themselves.
- Why it’s selected:
- End-to-end encryption is satisfied because the traffic between the client and the ALB is encrypted (via SSL/TLS), and the SSL certificate used on the ALB ensures the client’s data is protected.
- No need to install SSL certificates on each EC2 instance; managing SSL on the ALB simplifies the architecture.
Option B: Associate the EC2 instances with a target group. Provision an SSL certificate using AWS Certificate Manager (ACM). Create an Amazon CloudFront distribution and configure it to use the SSL certificate. Set CloudFront to use the target group as the origin server.
- Reasoning:
- CloudFront provides caching and content delivery across multiple regions, improving performance. However, this solution adds unnecessary complexity if the primary requirement is just end-to-end encryption.
- While this solution would secure traffic from the client to CloudFront (over HTTPS), it adds additional layers (CloudFront and a separate SSL certificate) that are unnecessary if the only goal is encrypting traffic between the client and the web server. Additionally, you would need to manage CloudFront and the SSL certificate configuration, which increases complexity.
- Why it’s rejected:
- This solution is overcomplicated for a basic load balancing and encryption use case. CloudFront is not needed unless you have a specific requirement for caching ...
Author: Mia · Last updated Jul 6, 2026
A company wants to migrate its data analytics environment from on premises to AWS. The environment consists of two simple Node.js applications. One of the applications collects sensor data and loads it into a MySQL database. The other application aggregates the data into reports. When the aggregation jobs run, some of the load jobs fail to run correctly.
The company must resolve the data loading issue....
The company needs to migrate its data analytics environment from on-premises to AWS while ensuring the migration occurs without interruptions to customer operations. Additionally, the company wants to resolve data loading issues and move to a more reliable architecture. Here's an analysis of the proposed solutions:
Key Considerations:
1. Minimize interruptions: The migration must be seamless with no impact on customer-facing services.
2. Resolve data loading issues: Aggregation jobs fail under the current setup, so better handling of database connections and performance improvements are needed.
3. Ensure reliability: The solution should handle data replication, allow for smooth cutover, and optimize job execution without disrupting existing processes.
Option A: Set up an Amazon Aurora MySQL database as a replication target for the on-premises database. Create an Aurora Replica for the Aurora MySQL database, and move the aggregation jobs to run against the Aurora Replica. Set up collection endpoints as AWS Lambda functions behind a Network Load Balancer (NLB), and use Amazon RDS Proxy to write to the Aurora MySQL database. When the databases are synced, disable the replication job and restart the Aurora Replica as the primary instance. Point the collector DNS record to the NLB.
- Explanation: This option uses Aurora MySQL replication for migration, with aggregation jobs running on the Aurora Replica, which is a good approach for offloading work from the primary instance. The use of AWS Lambda with RDS Proxy is intended to improve database connection management. However, NLB is typically used for TCP traffic, not for managing HTTP-based Lambda functions or application traffic, which makes this option less optimal for web application traffic.
- Cons: The architecture with Lambda functions behind an NLB is more suited for low-level TCP-based workloads rather than HTTP-based application workloads. Additionally, the extra complexity of using Lambda functions in this context could introduce challenges.
- Best Use Case: More suitable for TCP-heavy use cases, not for web-based applications requiring seamless HTTP integration.
Option B: Set up an Amazon Aurora MySQL database. Use AWS Database Migration Service (AWS DMS) to perform continuous data replication from the on-premises database to Aurora. Move the aggregation jobs to run against the Aurora MySQL database. Set up collection endpoints behind an Application Load Balancer (ALB) as Amazon EC2 instances in an Auto Scaling group. When the databases are synced, point the collector DNS record to the ALB. Disable the AWS DMS sync task after the cutover from on-premises to AWS.
- Explanation: This option uses AWS DMS for continuous data replication, which is ideal for minimizing downtime during the migration. The ALB is used to manage traffic to EC2 instances running the collection endpoints. Auto Scaling helps ensure the environment can scale based on load. The architecture is straightforward and follows common best practices for web applications.
- Pros: The use of AWS DMS for continuous replication ensures a seamless migration, and the ALB in front of EC2 instances allows for flexible traffic management. The Auto Scaling group ensures the application can scale dynamically to handle load without downtime.
- Cons: There’s some complexity in maintaining EC2 instances for the collection endpoints, and the migration process might take more time depending on the v...
Author: Charlotte · Last updated Jul 6, 2026
A health insurance company stores personally identifiable information (PII) in an Amazon S3 bucket. The company uses server-side encryption with S3 managed encryption keys (SSE-S3) to encrypt the objects. According to a new requirement, all current and future objects in the S3 bucket must be encrypted by keys th...
Let's analyze each option in terms of the requirements and the key factors involved:
Key Factors:
1. Current encryption with SSE-S3: Objects are currently encrypted with S3-managed keys, which are not customer-managed keys.
2. Requirement to use customer-managed encryption keys: The new requirement specifies that the company must use keys managed by the security team.
3. No versioning enabled on the S3 bucket: Any changes to the objects must be performed in a way that doesn't depend on versioning.
4. Re-uploading objects: Since versioning is not enabled, re-uploading objects is necessary to enforce the new encryption settings for existing objects.
Option A: In the S3 bucket properties, change the default encryption to SSE-S3 with a customer managed key. Use the AWS CLI to re-upload all objects in the S3 bucket. Set an S3 bucket policy to deny unencrypted PutObject requests.
- Why it's rejected:
- This option suggests using SSE-S3 with a customer-managed key, but SSE-S3 with a customer-managed key isn't possible, as SSE-S3 only works with S3-managed keys (not customer-managed ones).
- The requirement is for encryption with customer-managed keys, which would be better fulfilled using SSE-KMS (AWS KMS keys).
- Scenario for use: If the requirement was to use SSE-S3 with a managed key, this could have worked, but it's incompatible with the use of customer-managed keys.
Option B: In the S3 bucket properties, change the default encryption to server-side encryption with AWS KMS managed encryption keys (SSE-KMS). Set an S3 bucket policy to deny unencrypted PutObject requests. Use the AWS CLI to re-upload all objects in the S3 bucket.
- Why it's selected:
- This option correctly specifies SSE-KMS, which allows the company to use customer-managed keys.
- It also sets the default encryption for future objects to SSE-KMS, which ensures compliance with the new requirement.
- The S3 bucket policy to deny unencrypted `PutObject` requests ensures that no new objects can be uploaded without prope...
