Amazon Practice Questions, Discussions & Exam Topics by our Authors
A company has an application that uses Docker containers in its local data center. The application runs on a container host that stores persistent data in a volume on the host. The container instances use the stored persistent data.
The company wants to move the application to a fully managed service...
To move the application to a fully managed service, we need to address several key requirements:
Key Requirements:
1. No server or storage management: The company does not want to manage infrastructure, meaning the solution should be fully managed with minimal operational overhead.
2. Persistent storage for containers: The application uses persistent data in Docker containers, so the solution must support container-based persistent storage.
3. Fully managed service: The company wants to avoid managing servers, implying the need for a fully managed container service.
Option A: Use Amazon Elastic Kubernetes Service (Amazon EKS) with self-managed nodes. Create an Amazon Elastic Block Store (Amazon EBS) volume attached to an Amazon EC2 instance. Use the EBS volume as a persistent volume mounted in the containers.
- Analysis: Amazon EKS is a managed Kubernetes service, but using self-managed nodes implies that the company would still be responsible for managing the underlying EC2 instances and storage (EBS volumes). This does not meet the requirement of avoiding infrastructure management. While Kubernetes can manage persistent volumes, the operational overhead of managing EC2 instances and EBS volumes is still present.
- Reason for rejection: The company is looking for a solution with no infrastructure management, and self-managed EC2 instances don't meet that need.
Option B: Use Amazon Elastic Container Service (Amazon ECS) with an AWS Fargate launch type. Create an Amazon Elastic File System (Amazon EFS) volume. Add the EFS volume as a persistent storage volume mounted in the containers.
- Analysis: Amazon ECS with AWS Fargate is a fully managed container service that abstracts the underlying infrastructure, so no EC2 instances or servers need to be managed. Amazon EFS is a fully managed file storage service that can be shared between...
Author: Ahmed97 · Last updated Sep 15, 2026
A gaming company wants to launch a new internet-facing application in multiple AWS Regions. The application will use the TCP and UDP protocols for communication. The company needs to provide high availability and minimum latency for global users.
...
To meet the company's requirements of high availability, low latency, and global distribution for their internet-facing application, we need to consider the following:
Key Considerations:
- Global Traffic Routing: The solution must distribute traffic to the closest AWS region to minimize latency.
- High Availability: The application needs to be highly available across multiple regions.
- TCP and UDP Support: The application uses both TCP and UDP protocols for communication, so the chosen services must support both.
Option A: Create internal Network Load Balancers in front of the application in each Region.
- Analysis: Internal Network Load Balancers (NLBs) are used for routing traffic within a Virtual Private Cloud (VPC), not for internet-facing applications. Therefore, they are not suitable for distributing global internet traffic.
- Reason for rejection: Since the application is internet-facing, internal NLBs are not appropriate for this use case.
Option B: Create external Application Load Balancers in front of the application in each Region.
- Analysis: Application Load Balancers (ALBs) are designed for HTTP/HTTPS traffic and operate at the application layer (Layer 7), which is great for web-based applications. However, they do not support UDP and TCP protocols, which the application requires.
- Reason for rejection: ALBs are not suitable for this use case because they do not support UDP and TCP, which the gaming application needs.
Option C: Create an AWS Global Accelerator accelerator to route traffic to the load balancers in each Region.
- Analysis: AWS Global Accelerator is designed to improve the availability and performance of global applications by r...
Author: Sofia · Last updated Sep 15, 2026
A city has deployed a web application running on Amazon EC2 instances behind an Application Load Balancer (ALB). The application's users have reported sporadic performance, which appears to be related to DDoS attacks originating from random IP addresses. The city needs a solution that requir...
To address the problem of sporadic performance due to DDoS attacks, let's review the options:
Option A: Enable an AWS WAF web ACL on the ALB, and configure rules to block traffic from unknown sources
- Pros: AWS WAF (Web Application Firewall) is designed specifically for filtering web traffic and can be applied directly to the ALB. By setting up a Web ACL (Access Control List), you can create rules to block unwanted or malicious traffic, which is likely coming from random IP addresses in this case. This solution is relatively easy to set up with minimal configuration changes and provides visibility into the traffic, which aids in creating an audit trail.
- Cons: AWS WAF does not natively provide DDoS protection, but can be a part of the solution for filtering unwanted traffic.
- Conclusion: Suitable for the requirement to block DDoS traffic and provide visibility with a minimal setup, but not the most robust DDoS protection.
Option B: Subscribe to Amazon Inspector. Engage the AWS DDoS Response Team (DRT) to integrate mitigating controls into the service
- Pros: Amazon Inspector is a service for automated security assessments and identifying vulnerabilities. AWS DDoS Response Team (DRT) offers expert guidance in mitigating DDoS attacks.
- Cons: This option focuses on security vulnerability scanning and does not directly address DDoS protection for web applications. The DRT’s involvement might be helpful in more severe or large-scale attacks but does not provide an immediate solution for the sporadic performance problems.
- Conclusion: Not a fitting option since it focuses on security assessments rather than immediate DDoS mitigation.
Option C: Subscribe to AWS Shield Advanced. Engage the AWS DDoS Response Team (DRT) to integrate mitigating controls into the service
- Pros: AWS Shield Advanced ...
Author: IceDragon2023 · Last updated Sep 15, 2026
A company copies 200 TB of data from a recent ocean survey onto AWS Snowball Edge Storage Optimized devices. The company has a high performance computing (HPC) cluster that is hosted on AWS to look for oil and gas deposits. A solutions architect must provide the cluster with consistent sub-millisecond latency and high-throughput access to the ...
To address the scenario of providing the HPC cluster with consistent sub-millisecond latency and high-throughput access to data on the Snowball Edge Storage Optimized devices, let's evaluate each option:
Option A: Create an Amazon S3 bucket. Import the data into the S3 bucket. Configure an AWS Storage Gateway file gateway to use the S3 bucket. Access the file gateway from the HPC cluster instances.
- Pros: AWS Storage Gateway can provide on-premises access to cloud storage via file protocols. It can be useful for hybrid environments where you need to access S3 data as if it were a local file system.
- Cons: This option relies on Amazon S3, which is primarily optimized for durability and availability rather than high-performance computing. The file gateway doesn't provide sub-millisecond latency and high throughput for HPC workloads. It would introduce additional overhead for file system access.
- Conclusion: While it provides an easy way to access S3 storage, it doesn't meet the sub-millisecond latency and high-throughput requirements for HPC clusters. Not suitable for this specific scenario.
Option B: Create an Amazon S3 bucket. Import the data into the S3 bucket. Configure an Amazon FSx for Lustre file system, and integrate it with the S3 bucket. Access the FSx for Lustre file system from the HPC cluster instances.
- Pros: Amazon FSx for Lustre is a high-performance file system designed for workloads like HPC that require low-latency and high-throughput access. It integrates well with S3, enabling fast data access with seamless scaling.
- Cons: The initial data importation from the Snowball Edge devices would first require transferring data to S3. Although FSx for Lustre offers excellent performance, this would add an extra step of uploading the data to S3 before it is available for access, which could introduce additional time compared to direct import.
- Conclusion: This option is feasible but involves an extra step (S3 import) before accessing the data, which migh...
Author: Vivaan · Last updated Sep 15, 2026
A company has NFS servers in an on-premises data center that need to periodically back up small amounts of data to Amazon S3.
Which so...
To determine the most cost-effective and suitable solution for periodically backing up small amounts of data from on-premises NFS servers to Amazon S3, let's evaluate each option:
Option A: Set up AWS Glue to copy the data from the on-premises servers to Amazon S3
- Pros: AWS Glue is typically used for extracting, transforming, and loading (ETL) large datasets to and from data sources. It can connect to various data sources, including S3.
- Cons: AWS Glue is designed for more complex ETL processes rather than simple file backups. It's also overkill for periodically backing up small amounts of data. Glue's cost structure is based on data processing and can be more expensive for a simple task, as it is generally designed for larger, more complex workloads.
- Conclusion: This is not a cost-effective solution for periodic backups of small amounts of data due to its complexity and associated costs.
Option B: Set up an AWS DataSync agent on the on-premises servers, and sync the data to Amazon S3
- Pros: AWS DataSync is optimized for large-scale data transfers, offering fast, secure, and efficient file transfer between on-premises storage and AWS services like S3. It is designed for use cases where there is a need to sync data to S3, and it handles various data types efficiently.
- Cons: AWS DataSync is generally more cost-effective for large-scale, regular, or high-volume transfers, but it can still be cost-effective for small amounts of data. However, it may incur costs based on the volume of data transferred, and setting it up might involve some complexity if the data transfer needs are minimal.
- Conclusion: While AWS DataSync is a good solution, it might be sligh...
Author: GlowingTiger · Last updated Sep 15, 2026
An online video game company must maintain ultra-low latency for its game servers. The game servers run on Amazon EC2 instances. The company needs a solution that can handle millions of UDP internet traffic r...
Let's evaluate the options to meet the company's requirement for handling ultra-low latency and millions of UDP traffic requests each second for game servers running on Amazon EC2 instances.
Option A: Configure an Application Load Balancer with the required protocol and ports for the internet traffic. Specify the EC2 instances as the targets.
- Pros: Application Load Balancers (ALB) are designed for HTTP/HTTPS traffic, making them suitable for web applications. They offer intelligent routing and are highly scalable.
- Cons: ALBs are not optimized for UDP traffic. ALBs only support HTTP, HTTPS, and WebSocket protocols. Therefore, they cannot handle UDP traffic, which is crucial for online video games.
- Conclusion: This option is not suitable because it cannot handle UDP traffic, which is essential for game server performance.
Option B: Configure a Gateway Load Balancer for the internet traffic. Specify the EC2 instances as the targets.
- Pros: A Gateway Load Balancer is used for traffic management between virtual appliances like firewalls, proxies, and other services in your VPC. It is suitable for more complex network-level traffic.
- Cons: Gateway Load Balancers are not designed to handle UDP traffic at the scale required for game servers. They are better suited for use cases that require traffic inspection or packet-level inspection rather than general-purpose load balancing for UDP.
- Conclusion: This option is not ideal for handling millions of UDP traffic requests for gaming, as it's not optimized for that kind of use.
Option C: Configure a Network Load Balancer with the required p...
Author: Michael · Last updated Sep 15, 2026
A company runs a three-tier application in a VPC. The database tier uses an Amazon RDS for MySQL DB instance.
The company plans to migrate the RDS for MySQL DB instance to an Amazon Aurora PostgreSQL DB cluster. The company needs a solution that replicates the data changes that ...
To meet the requirements of migrating data from an Amazon RDS for MySQL DB instance to an Amazon Aurora PostgreSQL DB cluster, and ensuring data changes are replicated during the migration, let's evaluate the options:
Option A: Use AWS Database Migration Service (AWS DMS) Schema Conversion to transform the database objects.
- Pros: AWS DMS can be used to migrate the data from MySQL to PostgreSQL and handle schema conversion. Schema conversion helps translate the MySQL schema into the appropriate PostgreSQL schema format, including changes in data types, indexes, and constraints.
- Cons: While AWS DMS can help with schema conversion, it is not sufficient on its own for migrating the data during the process. It is just one part of the migration process.
- Conclusion: This step is necessary for the schema transformation but needs to be paired with other migration tasks for data replication and migration.
Option B: Use AWS Database Migration Service (AWS DMS) Schema Conversion to create an Aurora PostgreSQL read replica on the RDS for MySQL DB instance.
- Pros: AWS DMS can handle the data migration process, but it cannot create a read replica of an Aurora PostgreSQL DB cluster from an RDS for MySQL DB instance directly. Aurora PostgreSQL cannot be a read replica of MySQL, so this approach is not feasible.
- Cons: There is no support for creating an Aurora PostgreSQL read replica from an RDS for MySQL DB instance. Aurora MySQL supports read replicas for MySQL, but Aurora PostgreSQL does not support MySQL as a source for replication.
- Conclusion: This is not a valid solution because read replicas between MySQL and PostgreSQL are not supported.
Option C: Configure an Aurora MySQL read replica for the RDS for MySQL DB instance.
- Pros: This option involves creating an Aurora MySQL read replica from the MySQL database. However, this is only useful if the company...
Author: Daniel · Last updated Sep 15, 2026
A company hosts a database that runs on an Amazon RDS instance that is deployed to multiple Availability Zones. The company periodically runs a script against the database to report new entries that are added to the database. The script that runs against the database negatively affects the performance of a critical application. The compan...
Evaluation of Each Option:
Option A: Add functionality to the script to identify the instance that has the fewest active connections. Configure the script to read from that instance to report the total new entries.
- Reasoning:
- This option introduces additional complexity by requiring the script to monitor multiple database instances and choose the one with the least load. While it may reduce competition for resources on the busiest instance, it still requires the script to run against a primary instance (or one with fewer active connections), which could still impact the performance of the critical application.
- Operational Overhead: This adds a layer of logic to the script, increasing its complexity and making maintenance harder.
- Rejection Reasoning: This approach doesn't address the root issue (performance impact on the critical application) effectively and increases the complexity of the solution with minimal gain.
Option B: Create a read replica of the database. Configure the script to query only the read replica to report the total new entries.
- Reasoning:
- By creating a read replica, you offload the query traffic from the primary instance, ensuring that the performance of the critical application running on the primary instance isn't negatively impacted.
- Operational Overhead: Minimal – Amazon RDS handles replication automatically, and no additional manual intervention is required once the read replica is set up.
- Cost: The cost of the read replica depends on the instance type and region, but it's typically lower than running a separate database instance.
- Effectiveness: This option minimizes operational overhead while effectively offloading the query work from the primary instance, ensuring that the critical application performance remains unaffected.
- Why it’s optimal: Read replicas are designed specifically to handle read-heavy workloads and can significantly improve application performance when multiple queries need to be executed without overloading the primary database. Minimal operational overhead and low cost make this the most suitable option.
Option C: Instruct the development team to manually export the new entries for the day in the database at the end of each day....
Author: Zain · Last updated Sep 15, 2026
A company is using an Application Load Balancer (ALB) to present its application to the internet. The company finds abnormal traffic access patterns across the application. A solutions architect needs to improve visibility into the infrastructure to help the company under...
Evaluation of Each Option:
Option A: Create a table in Amazon Athena for AWS CloudTrail logs. Create a query for the relevant information.
- Reasoning:
- CloudTrail logs capture API calls made to AWS services, which is useful for auditing and security-related events, but it does not capture the detailed traffic access patterns of an Application Load Balancer (ALB). ALB traffic logs (such as IP addresses, request paths, and response times) are not stored in CloudTrail.
- Operational Overhead: Medium – Setting up Athena and creating queries for CloudTrail logs is straightforward, but it won't provide the required information regarding the traffic patterns related to the ALB.
- Effectiveness: Not effective in capturing the traffic access patterns for ALB. This option would not meet the requirement.
- Rejection Reasoning: CloudTrail logs don't capture the necessary traffic access details of ALB, so this option is not suitable.
Option B: Enable ALB access logging to Amazon S3. Create a table in Amazon Athena, and query the logs.
- Reasoning:
- ALB access logs provide detailed information about requests that are sent to the load balancer, such as client IP addresses, requested URLs, response codes, latencies, etc. These logs are stored in Amazon S3, which can be directly queried using Amazon Athena.
- Operational Overhead: Low – Enabling access logging on the ALB is a simple configuration change. Once logs are in S3, querying them via Athena is efficient and provides the required visibility without manual intervention.
- Effectiveness: This solution directly meets the requirement by providing a scalable, queryable log of traffic access patterns. It’s automated and easy to use for querying abnormal traffic patterns.
- Why it’s optimal: This option provides direct visibility into traffic patterns, and Athena allows for easy querying without manually processing raw log files. It's a minimal-effort and highly effective solution.
Option C: Enable ALB access logging to Amazon S3. Open e...
Author: Scarlett · Last updated Sep 15, 2026
A company wants to use NAT gateways in its AWS environment. The company's Amazon EC2 instances in private subnets must be able to connect to the public internet th...
Evaluation of Each Option:
Option A: Create public NAT gateways in the same private subnets as the EC2 instances.
- Reasoning:
- A NAT gateway must be in a public subnet to allow it to route traffic to the internet. Private subnets don't have a route to the internet by default, which makes placing a NAT gateway in a private subnet unfeasible for allowing internet access.
- Operational Overhead: High – Not a valid solution, as NAT gateways cannot function in private subnets. This would lead to configuration issues.
- Rejection Reasoning: NAT gateways must be placed in a public subnet to be able to route internet traffic. This option is invalid.
Option B: Create private NAT gateways in the same private subnets as the EC2 instances.
- Reasoning:
- The term "private NAT gateway" is not valid in AWS terminology. NAT gateways must be placed in public subnets to route traffic to and from the internet. Even if a NAT device were in a private subnet, it would still be unable to route traffic to the internet.
- Operational Overhead: Not feasible because private subnets cannot have NAT gateways, as these require internet connectivity, which private subnets lack.
- Rejection Reasoning: This option is not valid because there is no such thing as a "private NAT gateway" in AWS, and NAT gateways must be in a public subnet.
Option C: Create public NAT gateways in public subnets in the same VPCs as the EC2 instances.
- Reasoning:
- This is the correct setup. NAT gateways should be placed in public subnets, which have a route to the internet through an Internet Gateway. EC2 instances in private subnets can use these public NAT gateways to access the internet for tasks like software updates or accessing e...
Author: Maya · Last updated Sep 15, 2026
A company has an organization in AWS Organizations. The company runs Amazon EC2 instances across four AWS accounts in the root organizational unit (OU). There are three nonproduction accounts and one production account. The company wants to prohibit users from launching EC2 instances of a certain size in the nonproduction accounts. The company has created a service contro...
Evaluation of Each Option:
Option A: Attach the SCP to the root OU for the organization.
- Reasoning:
- Attaching the SCP to the root OU will affect all accounts in the organization, including both production and nonproduction accounts. This means that the SCP will apply universally to all accounts within the organization.
- Operational Overhead: High – The requirement is to apply the SCP to nonproduction accounts only. Applying it at the root level would restrict EC2 instance launching in both production and nonproduction accounts, which is not the desired outcome.
- Effectiveness: Not optimal because it affects the production account, which should not be restricted.
- Rejection Reasoning: This option is not suitable because it would inadvertently restrict EC2 instance launching in the production account as well.
Option B: Attach the SCP to the three nonproduction Organizations member accounts.
- Reasoning:
- This approach targets the three nonproduction accounts directly, applying the SCP only to those accounts that require the restriction.
- Operational Overhead: Medium – This is a valid approach, but it requires applying the SCP to each nonproduction account individually, which could become cumbersome if the number of accounts grows.
- Effectiveness: Effective in restricting the EC2 instance types in the nonproduction accounts without affecting the production account.
- Why it’s optimal: This solution directly applies the SCP to the relevant nonproduction accounts and does not impact the production account. It's effective, but could be less scalable if more accounts are added in the future.
Option C: Attach the SCP to the Organizations management account.
- Reasoning:
- Attaching the SCP to the management account would not meet the requirement because the management account typically manages the organization, and SCPs attached here don't affect the individual member accounts directly. SCPs should be applied to the organizational units (OUs) or individual accounts.
- Operational Overhead: High – Misapplication of SCPs at the management account level wouldn't restrict EC2 instance launches in specific member accounts.
- Effectiveness: Ineffective – This would not target the correct accounts as SCPs are generally i...
Author: Harper · Last updated Sep 15, 2026
A company's website hosted on Amazon EC2 instances processes classified data stored in Amazon S3. Due to security concerns, the company requires a private and secure connection betwe...
Evaluation of Each Option:
Option A: Set up S3 bucket policies to allow access from a VPC endpoint.
- Reasoning:
- Amazon VPC endpoints allow secure, private communication between resources in a VPC and supported AWS services like S3, without needing to go over the public internet. This ensures that traffic between the EC2 instances and S3 remains private and secure, which meets the requirement for a private and secure connection.
- Operational Overhead: Low – Configuring a VPC endpoint is a straightforward process, and it does not involve managing additional credentials or networking complexity.
- Effectiveness: Very effective – This solution ensures private, secure communication between EC2 instances and S3, without any public internet exposure.
- Why it’s optimal: This option directly addresses the security and privacy concerns by ensuring all traffic between EC2 and S3 is kept within the AWS network using private connectivity.
Option B: Set up an IAM policy to grant read-write access to the S3 bucket.
- Reasoning:
- While setting up an IAM policy to grant read-write access is necessary to control permissions for EC2 instances accessing S3, it does not address the need for a private and secure connection. This solution focuses on access control rather than securing the connection itself.
- Operational Overhead: Medium – Setting up IAM policies is a standard practice, but it doesn't resolve the requirement for a private and secure connection.
- Effectiveness: Ineffective – IAM policies control what users and services can do, but they don’t ensure the traffic between EC2 and S3 is private and not traversing the public internet.
- Rejection Reasoning: This solution is necessary for access control but does not meet the requirement for a private connection.
Option C: Set up a NAT gateway to access resources outside the private subnet.
- Reasoning:
- A NAT gateway is used to provide internet access to res...
Author: Liam123 · Last updated Sep 15, 2026
An ecommerce company runs its application on AWS. The application uses an Amazon Aurora PostgreSQL cluster in Multi-AZ mode for the underlying database. During a recent promotional campaign, the application experienced heavy read load and write load. Users experienced timeout issues when they attempted to access the application.
A solutions architec...
To address the application’s scalability and high availability needs with the least downtime, let’s analyze the options based on key factors:
Key factors for consideration:
1. Scalability: The ability to handle high load and scale dynamically based on traffic.
2. High Availability: Ensuring that the system remains available even in the event of failures.
3. Minimal Downtime: Since the problem arose during a promotional campaign, minimizing downtime is crucial.
4. Cost and Complexity: The solution should not introduce unnecessary complexity or costs.
Option A: Create an Amazon EventBridge rule that has the Aurora cluster as a source. Create an AWS Lambda function to log the state change events of the Aurora cluster. Add the Lambda function as a target for the EventBridge rule. Add additional reader nodes to fail over to.
- Analysis: This solution proposes adding reader nodes to the Aurora cluster and using an EventBridge rule with Lambda to log state changes. The additional reader nodes can help offload the read-heavy traffic during high-load periods, improving scalability and reducing the risk of timeouts due to excessive reads. However, this approach introduces additional complexity (EventBridge and Lambda) and would not directly address the root cause of write load or help with ensuring high availability in a failover situation.
- Rejected because: The EventBridge + Lambda setup adds complexity and does not directly tackle the write load issues, making it less effective in addressing the immediate problem during the campaign.
Option B: Modify the Aurora cluster and activate the zero-downtime restart (ZDR) feature. Use Database Activity Streams on the cluster to track the cluster status.
- Analysis: The Zero-Downtime Restart (ZDR) feature allows for restarts without application downtime, which can be helpful in some maintenance scenarios. However, ZDR is mainly useful for applying minor updates without taking the system offline, and does not directly help with high availability or scalability under load. The Database Activity Streams would only help monitor the status and wouldn’t actively mitigate load-related issues.
- Rejected because: ZDR only addresses restart scenarios and would not improve scalab...
Author: FlamePhoenix2025 · Last updated Sep 15, 2026
A company is designing a web application on AWS. The application will use a VPN connection between the company's existing data centers and the company's VPCs.
The company uses Amazon Route 53 as its DNS service. The application must use private DNS records to communicat...
To meet the requirements of secure and private communication between a VPC and on-premises services using DNS, let’s analyze the options based on the following key factors:
Key Factors for Consideration:
1. Security: The solution should ensure private DNS resolution, meaning that DNS queries between the VPC and on-premises services should not be exposed to the public internet.
2. DNS Functionality: The solution should support communication between the VPC and on-premises services using private DNS records.
3. Integration with VPC: The solution should be well-integrated with the VPC and provide secure and efficient DNS resolution.
4. VPN Communication: Since the communication will occur over a VPN connection between the on-premises data centers and the VPC, the solution should support DNS resolution over the VPN.
Option A: Create a Route 53 Resolver outbound endpoint. Create a resolver rule. Associate the resolver rule with the VPC.
- Analysis: A Route 53 Resolver outbound endpoint allows DNS queries from the VPC to resolve to an external DNS server, which could be useful if the VPC needs to query on-premises DNS servers. However, this would be the opposite direction of what is required here (communication from on-premises to VPC), and does not provide private DNS resolution for on-premises services in a secure manner.
- Rejected because: The outbound endpoint is used to allow VPC instances to query external DNS servers, which doesn’t match the requirement of having private DNS records for communication from the VPC to on-premises services.
Option B: Create a Route 53 Resolver inbound endpoint. Create a resolver rule. Associate the resolver rule with the VPC.
- Analysis: A Route 53 Resolver inbound endpoint allows DNS queries from external sources (such as on-premises servers) to resolve to Route 53 records inside the VPC. By creating a resolver rule and associating it with the VPC, DNS queries from on-premises servers can resolve priva...
Author: Ryan · Last updated Sep 15, 2026
A company is running a photo hosting service in the us-east-1 Region. The service enables users across multiple countries to upload and view photos. Some photos are heavily viewed for months, and others are viewed for less than a week. The application allows uploads of up to 20 MB for each photo. The service uses the phot...
To determine the most cost-effective and efficient solution for a photo hosting service, let’s analyze the options based on the key requirements:
Key Factors:
1. Cost-Effectiveness: Given that some photos are frequently viewed for months while others are viewed for a shorter period, it’s important to balance cost based on storage and access frequency.
2. Access Speed: Since some photos are heavily viewed, the solution should allow for quick access to those frequently viewed items, without incurring unnecessary costs for infrequent access.
3. Metadata Handling: The metadata is crucial for determining which photos to display, and it needs to be easily stored and retrieved.
4. Storage Size: The photos are up to 20 MB, so storage needs to accommodate relatively large files efficiently.
Option A: Store the photos in Amazon DynamoDB. Turn on DynamoDB Accelerator (DAX) to cache frequently viewed items.
- Analysis: DynamoDB is a NoSQL database designed for fast read and write operations, but it is not optimized for storing large files like images. Storing photos in DynamoDB would incur high costs due to the size of the data and storage needs. DAX can help with caching but doesn't address the underlying problem of storing large photos cost-effectively.
- Rejected because: DynamoDB is not designed to handle large files like photos, making it a poor choice for this use case. It would be inefficient and costly.
Option B: Store the photos in the Amazon S3 Intelligent-Tiering storage class. Store the photo metadata and its S3 location in DynamoDB.
- Analysis: S3 Intelligent-Tiering automatically moves data between two access tiers based on access patterns, which can be beneficial for photos that are accessed frequently or infrequently. However, it may not be the most cost-effective solution for frequently accessed items because it’s designed for objects with unpredictable access patterns. Storing metadata in DynamoDB is appropriate for fast lookup, but the cost of using S3 Intelligent-Tiering for photos that are frequently accessed may not be optimal.
- Rejected because: While Intelligent-Tiering is a good fit for unpredictable access patterns, it may be more expensive for frequently accessed items compared to S3 Standard storage.
Option C: Store the...
Author: Daniel · Last updated Sep 15, 2026
A company runs a highly available web application on Amazon EC2 instances behind an Application Load Balancer. The company uses Amazon CloudWatch metrics.
As the traffic to the web application increases, some EC2 instances become overloaded with many outstanding requests. The CloudWatch metrics show that the number of requests processed and the time to receive the responses from some EC2 instances are both higher com...
To address the requirement of preventing overloaded EC2 instances from receiving new requests while maintaining high availability and responsiveness in the application, let’s analyze the options based on the following key factors:
Key Factors:
1. Load Balancing Based on Instance Load: The EC2 instances should be balanced based on their current load to ensure that requests are not directed to those that are already overloaded.
2. Use of CloudWatch Metrics: The solution should leverage CloudWatch metrics like request count and response time to make intelligent routing decisions.
3. Routing Method: Choosing between round robin or least outstanding requests is important to ensure that the traffic is balanced in a way that avoids overloading the instances.
Option A: Use the round robin routing algorithm based on the RequestCountPerTarget and ActiveConnectionCount CloudWatch metrics.
- Analysis: The round robin routing algorithm distributes requests evenly across available EC2 instances without considering their current load (other than the basic metrics). While RequestCountPerTarget and ActiveConnectionCount are useful metrics, they don’t directly help in identifying the instances with the highest load or the longest response times. This approach doesn’t prevent overloaded instances from receiving requests, as it simply distributes traffic evenly.
- Rejected because: Round robin routing does not adapt to the real-time performance or load of individual EC2 instances, which is needed to prevent overloading specific instances.
Option B: Use the least outstanding requests algorithm based on the RequestCountPerTarget and ActiveConnectionCount CloudWatch metrics.
- Analysis: The least outstanding requests routing algorithm aims to route requests to the instances with the fewest outstanding requests, which is more adaptive to the current load of the instances. However, the RequestCountPerTarget and ActiveConnectionCount metrics are not ideal for determining which instance is "outstanding" in terms of active requests or response times. These metrics mainly provide information about the overall number of requests or active connections, rather than providing insight into how long requests are waiting to be processed.
- Rejected because: While the least outstanding requests approach is generally good for balancing traffi...
Author: Ming · Last updated Sep 15, 2026
A company uses Amazon EC2, AWS Fargate, and AWS Lambda to run multiple workloads in the company's AWS account. The company wants to fully make use of its Compute Savings Plans. The company wants to receive notification when coverage of the Compute...
To meet the company's requirements of receiving notifications when the coverage of their Compute Savings Plans drops, we need to evaluate the most operationally efficient solution that integrates well with AWS services and provides the necessary alerts. Let’s analyze the options based on key factors such as ease of setup, automation, and notification granularity.
Key Factors for Consideration:
1. Operational Efficiency: The solution should minimize the operational overhead while providing automated notifications without needing custom code or manual intervention.
2. Notification Delivery: Notifications should be delivered to the appropriate recipients when the coverage drops below a specific threshold.
3. Integration with AWS Services: The solution should use AWS-native services to minimize complexity and ensure seamless integration.
Option A: Create a daily budget for the Savings Plans by using AWS Budgets. Configure the budget with a coverage threshold to send notifications to the appropriate email message recipients.
- Analysis: AWS Budgets is a native service that allows you to track spending, usage, and other metrics, including Savings Plans coverage. You can set a budget to track Compute Savings Plans coverage and configure alerts to notify you when the coverage drops below a certain threshold. AWS Budgets provides an easy-to-use interface for setting up thresholds and sending notifications automatically. This approach does not require custom code or management, making it highly operationally efficient.
- Selected Option: This solution offers a straightforward, automated approach using AWS-native services without the need for manual monitoring or custom code, making it the most operationally efficient choice.
Option B: Create a Lambda function that runs a coverage report against the Savings Plans. Use Amazon Simple Email Service (Amazon SES) to email the report to the appropriate email message recipients.
- Analysis: While this approach could technically achieve the goal, it requires more effort in development and maintenance. You would need to write and manage a ...
Author: Charlotte · Last updated Sep 15, 2026
A company runs a real-time data ingestion solution on AWS. The solution consists of the most recent version of Amazon Managed Streaming for Apache Kafka (Amazon MSK). The solution is deployed in a VPC in private subnets across three Availability Zones.
A solutions architect needs to redesign the data ingestion solution to be publicly availabl...
Let's analyze each option carefully:
Option A: Configure public subnets in the existing VPC. Deploy an MSK cluster in the public subnets. Update the MSK cluster security settings to enable mutual TLS authentication.
Analysis:
- This option suggests deploying the MSK cluster in public subnets. Although it meets the requirement for being publicly available, MSK generally performs better in private subnets due to security and best practices, as it avoids exposing Kafka brokers directly to the public internet.
- Security concerns arise with this approach, as publicly exposing MSK could lead to potential risks, even with encryption and mutual TLS authentication.
- Additionally, managing MSK in public subnets can lead to unnecessary exposure to the internet, which is not an optimal security practice.
Why Rejected:
- Security concerns with deploying MSK in public subnets and exposing it directly to the internet are significant.
- Operational complexity and risks involved in securing MSK with mutual TLS in public subnets.
Option B: Create a new VPC that has public subnets. Deploy an MSK cluster in the public subnets. Update the MSK cluster security settings to enable mutual TLS authentication.
Analysis:
- Similar to Option A, this solution proposes deploying MSK in public subnets, but with a new VPC.
- While creating a new VPC can help with isolation, the issue of exposing MSK to the internet directly remains.
- Mutual TLS authentication can ensure data security, but it doesn't address the inherent security risks of making MSK publicly accessible.
Why Rejected:
- Like Option A, the direct exposure of MSK to the internet is a major security concern.
- There are better ways to expose services securely without publicly exposing MSK.
Option C: Deploy an Application Load Balancer (ALB) that uses private subnets. Configure an ALB security g...
Author: Oliver · Last updated Sep 15, 2026
A company wants to migrate an on-premises legacy application to AWS. The application ingests customer order files from an on-premises enterprise resource planning (ERP) system. The application then uploads the files to an SFTP server. The application uses a scheduled job that checks for order files every hour.
The company already has an AWS account that has connectivity to the on-premises network. The new application on AWS must support integration with the...
Let's analyze each option in detail:
Option A: Create an AWS Transfer Family SFTP internet-facing server in two Availability Zones. Use Amazon S3 storage. Create an AWS Lambda function to process order files. Use S3 Event Notifications to send s3:ObjectCreated: events to the Lambda function.
Analysis:
- AWS Transfer Family SFTP: The internet-facing SFTP server ensures the ERP system can connect to AWS securely over the SFTP protocol.
- Two Availability Zones: This provides high availability and resilience, ensuring the application can withstand a failure in one zone.
- Amazon S3 Storage: S3 is ideal for storing file-based data. It's secure, scalable, and integrates well with other AWS services.
- Lambda Function with S3 Event Notifications: Lambda functions are a great way to process files as soon as they arrive in S3. S3 Event Notifications will automatically trigger the Lambda function when a new file is uploaded to S3, ensuring immediate processing.
Why Selected:
- Security: SFTP is a secure protocol, and using AWS Transfer Family ensures secure and compliant data transfers.
- Resilience: Deploying in two Availability Zones ensures high availability.
- Real-time Processing: S3 Event Notifications enable immediate triggering of Lambda, which processes files as soon as they arrive.
- Operational Efficiency: Using Lambda and S3 reduces the need for manual or scheduled jobs, making the solution more efficient and cost-effective.
Why Rejected:
- N/A, this option is selected due to its simplicity, scalability, and ability to meet all requirements efficiently.
Option B: Create an AWS Transfer Family SFTP internet-facing server in one Availability Zone. Use Amazon Elastic File System (Amazon EFS) storage. Create an AWS Lambda function to process order files. Use a Transfer Family managed workflow to invoke the Lambda function.
Analysis:
- Single Availability Zone: This reduces the resilience of the solution because if the Availability Zone experiences an outage, the application could go down. It does not meet the requirement for resilience as effectively as Option A (which uses two Availability Zones).
- Amazon EFS Storage: EFS provides a managed, scalable file system that can be accessed by multiple instances or services concurrently. However, it's typically used for applications requiring shared storage across multiple instances. While it’s a valid option, S3 is generally more cost-effective for file storage, especially when integrated with serverless solutions like Lambda.
- Lambda with Transfer Family Managed Workflow: This could work, but the Lambda function may not trigger immediately based on SFTP uploads; the managed workflow's execution might introduce delays, and workflows are better suited for more complex file processing.
Why Rejected:
- The solution in one Availability Zone lacks resilience.
- EFS is not the best fit here because S3 offers better integration with Lambda and is more cost-effective for file storage and proc...
Author: Max · Last updated Sep 15, 2026
A company's applications use Apache Hadoop and Apache Spark to process data on premises. The existing infrastructure is not scalable and is complex to manage.
A solutions architect must design a scalable solution that reduces operational complexi...
Let's break down and analyze each option to determine the most suitable solution for a scalable, simplified, and on-premises data processing solution.
Option A: Use AWS Site-to-Site VPN to access the on-premises Hadoop Distributed File System (HDFS) data and application. Use an Amazon EMR cluster to process the data.
Analysis:
- Site-to-Site VPN: This option involves connecting the on-premises Hadoop HDFS environment to AWS using a VPN. While this provides a secure link to the data, it might introduce network latency and bandwidth limitations, particularly when processing large volumes of data. The continuous reliance on on-premises storage could also cause performance bottlenecks.
- Amazon EMR: Using an EMR cluster for data processing offloads the heavy lifting of analytics to AWS, which improves scalability and reduces operational complexity. However, the data still resides on-premises, which creates complexity in maintaining a high-speed connection to the data and affects overall performance due to latency.
Why Rejected:
- The solution still relies on on-premises storage, and network bandwidth and latency can cause performance issues.
- While processing with EMR helps offload complexity, the reliance on on-premises HDFS limits the scalability and agility of the overall solution.
Option B: Use AWS DataSync to connect to the on-premises Hadoop Distributed File System (HDFS) cluster. Create an Amazon EMR cluster to process the data.
Analysis:
- AWS DataSync: DataSync is a service that automates the transfer of large volumes of data from on-premises storage to AWS. This solution would allow for more efficient and automated data transfers, significantly reducing the operational complexity of moving large datasets to AWS.
- Amazon EMR: As in Option A, using EMR for data processing leverages AWS scalability and management benefits. DataSync helps streamline the transfer of data from on-premises HDFS to Amazon S3 or directly to an EMR cluster, improving data accessibility.
Why Rejected:
- While DataSync simplifies the transfer of data to AWS, the data is still primarily on-premises, which introduces potential performance issues, particularly if frequent data transfers are required. The solution doesn't fully resolve the operational complexity of maintaining on-premises infrastructure.
Option C: Migrate the Apache Hadoop application and the Apache Spark application to Amazon EMR clusters on AWS Outposts. Use the EMR clusters to process the data.
Analysis:
- AWS Outposts: Outposts allow you to run AWS infrastructure on-premises, offering the ability to run EMR clusters locally while still taking advantage of AWS's managed service benefits. This could be useful if you need to keep the data and proce...
Author: Ryan · Last updated Sep 15, 2026
A company is migrating a large amount of data from on-premises storage to AWS. Windows, Mac, and Linux based Amazon EC2 instances in the same AWS Region will access the data by using SMB and NFS storage protocols. The company will access a portion of the data routinely. The company will access the remaining data infrequently.
...
Let's evaluate each option based on the company's requirements: accessing the data using SMB and NFS protocols, with some data being accessed routinely and other data being accessed infrequently. The solution needs to meet these requirements while minimizing operational overhead.
Option A: Create an Amazon Elastic File System (Amazon EFS) volume that uses EFS Intelligent-Tiering. Use AWS DataSync to migrate the data to the EFS volume.
Analysis:
- Amazon EFS: EFS is a fully managed NFS-based file system that can be accessed by multiple EC2 instances, making it ideal for a use case requiring NFS and SMB access. EFS Intelligent-Tiering automatically moves data between the Standard and Infrequent Access (IA) storage classes based on access patterns, which is suitable for data that has varying access frequency.
- AWS DataSync: DataSync simplifies the data migration process, offering efficient transfer from on-premises storage to AWS.
Why Selected:
- Operational Simplicity: EFS is fully managed, so operational overhead is minimized. Intelligent-Tiering automatically manages storage costs by moving infrequently accessed data to lower-cost storage, without manual intervention.
- SMB/NFS Support: EFS supports both SMB (through Amazon FSx for Windows File Server) and NFS, which is ideal for this scenario since the company needs to use these protocols.
- Scalability and Flexibility: EFS automatically scales with demand, eliminating the need for manual capacity planning or maintenance.
Why Rejected:
- N/A. This option is selected because it meets the requirements effectively with minimal overhead and management.
Option B: Create an Amazon FSx for ONTAP instance. Create an FSx for ONTAP file system with a root volume that uses the auto-tiering policy. Migrate the data to the FSx for ONTAP volume.
Analysis:
- Amazon FSx for ONTAP: FSx for ONTAP is a fully managed file system that supports both NFS and SMB protocols. It also supports automatic data tiering, which can move data between high-performance and lower-cost storage tiers.
- However, FSx for ONTAP is more complex and might require more configuration and management compared to EFS, particularly with tiering and storage policy settings.
Why Rejected:
- Operational Overhead: FSx for ONTAP has a more complex configuration than EFS, particularly with auto-tiering. It may also require ongoing management related to the performance and cost optimization of the storage tiers.
- Cost and Complexity: While it provides additional features, it may not be necessary unless the company specifically requires the advanced capabilities of ONTAP (e.g., specific data management features), making it more complex than necessary for a simple use case.
Option...
Author: Abigail · Last updated Sep 15, 2026
A manufacturing company runs its report generation application on AWS. The application generates each report in about 20 minutes. The application is built as a monolith that runs on a single Amazon EC2 instance. The application requires frequent updates to its tightly coupled modules. The application becomes complex to maintain as the company adds new features.
Each time the company patches a software module, the application experiences downtime. Report generation must restart from the beginning after any interrupti...
Let's evaluate each option based on the company's requirements: the need for flexibility, scalability, minimal downtime, and the ability to gradually improve the application.
Option A: Run the application on AWS Lambda as a single function with maximum provisioned concurrency.
Analysis:
- AWS Lambda: Lambda is a serverless compute service designed to run code in response to events, but it is best suited for short-lived, stateless functions.
- Monolithic application: The current report generation application is a monolith, and moving it to AWS Lambda as a single function could be challenging. Lambda is not typically suited for long-running processes like report generation that takes around 20 minutes to complete.
- Provisioned concurrency: While provisioned concurrency can mitigate cold starts, it does not address the fundamental issue of long-running tasks, as Lambda has a maximum execution time of 15 minutes, which would not meet the requirement of generating reports that take 20 minutes.
Why Rejected:
- Lambda is not suitable for long-running, stateful applications. The application also needs to handle complex dependencies and updates, which Lambda does not support well for this type of workload.
Option B: Run the application on Amazon EC2 Spot Instances as microservices with a Spot Fleet default allocation strategy.
Analysis:
- Amazon EC2 Spot Instances: Spot Instances offer a cost-effective way to run EC2 instances, but they can be interrupted with little notice, which would introduce significant risk for the application. The report generation process could be interrupted by Spot Instance termination, and since the process restarts from the beginning after any interruption, this would not meet the reliability requirement.
- Microservices: While running the application as microservices is a good idea for flexibility and scalability, the inherent risk of Spot Instances causing interruptions would make this an unreliable solution for the report generation process.
Why Rejected:
- The potential for Spot Instance termination makes this option unsuitable for an application that needs minimal downtime and reliability.
Option C: Run the application on Amazon Elastic Container Service (Amazon ECS) as microservices with service auto-scaling.
Analysis:
- Amazon ECS: ECS allows you to run containers and orchestrates microservices effectively. Running the application as microservices on ECS would provide flexibility, scalability, and allow for gradual improvements. Microservices would also allow for independent updates, reducing downtime.
- Service Auto Scaling: ECS supports auto ...
Author: Harper · Last updated Sep 15, 2026
A company wants to rearchitect a large-scale web application to a serverless microservices architecture. The application uses Amazon EC2 instances and is written in Python.
The company selected one component of the web application to test as a microservice. The component supports hundreds of requests each second. The company wants to create and test the microservice on an AWS solution that sup...
In this scenario, the company is aiming to rearchitect a large-scale web application to a serverless microservices architecture. The key requirements for the solution include:
1. Support for Python – The microservice is written in Python.
2. Scalability – The solution must scale automatically to handle hundreds of requests per second.
3. Minimal Infrastructure – The solution should not require much infrastructure management or operational support.
4. Minimal Operational Support – The solution should reduce the need for ongoing operational overhead.
Let's evaluate each option against these requirements:
A) Use a Spot Fleet with auto scaling of EC2 instances that run the most recent Amazon Linux operating system
- Pros: Spot Fleet with auto scaling can provide cost-effective scaling by using EC2 instances in a fleet that automatically adjusts based on demand.
- Cons: This option requires management of EC2 instances (even if auto-scaling is configured). It introduces complexity in managing instances, load balancing, and scaling, which does not fully align with the goal of minimal infrastructure management. The reliance on EC2 instances also doesn't embrace the serverless paradigm.
- Conclusion: Not ideal, as it requires more infrastructure management compared to a fully serverless solution.
B) Use an AWS Elastic Beanstalk web server environment that has high availability configured
- Pros: Elastic Beanstalk simplifies the deployment and management of applications, including automatic scaling and high availability.
- Cons: Elastic Beanstalk still uses EC2 instances (though managed), which means some level of infrastructure management is involved. While it abstracts much of the complexity, it’s not fully serverless, and might not provide the same level of automation as AWS Lambda.
- Conclusion: While s...
Author: Olivia · Last updated Sep 15, 2026
A company has an AWS Direct Connect connection from its on-premises location to an AWS account. The AWS account has 30 different VPCs in the same AWS Region. The VPCs use private virtual interfaces (VIFs). Each VPC has a CIDR block that does not overlap with other networks under the company's control.
The company wants to centrally manage the networking architecture while still allow...
Let's evaluate the options for a company that wants to centrally manage the networking architecture while allowing communication between 30 VPCs and on-premises networks. The key requirements are:
- The ability to communicate across all 30 VPCs and the on-premises network.
- Centralized management of networking.
- Least operational overhead.
A) Create a transit gateway, and associate the Direct Connect connection with a new transit VIF. Turn on the transit gateway's route propagation feature.
- Pros: A transit gateway allows centralized management of VPC interconnectivity. The Direct Connect connection can be linked to the transit gateway via a transit VIF (Virtual Interface), enabling efficient communication between all VPCs and on-premises networks. The route propagation feature allows for automatic updates to the route tables, minimizing the need for manual configuration. It scales well as the company grows (e.g., adding more VPCs), and it reduces complexity compared to managing multiple VPC peering connections.
- Cons: None significant for the scenario, as the transit gateway is designed specifically for such use cases and offers seamless scalability.
- Conclusion: This solution best meets the requirements of central management and minimal operational overhead. It scales well, allows easy VPC communication, and integrates directly with the existing Direct Connect connection.
B) Create a Direct Connect gateway. Recreate the private VIFs to use the new gateway. Associate each VPC by creating new virtual private gateways.
- Pros: The Direct Connect gateway provides a solution for connecting multiple VPCs to a single Direct Connect connection, especially for multi-region setups. This would also work for VPC-to-VPC communication in the same region.
- Cons: Recreating the private VIFs and creating new virtual private gateways for each VPC introduces additional complexity. Each VPC would require its own virtual private gateway, which can quickly become cumbersome with 30 VPCs. This solution requires more manual setup and ongoing ...
Author: Isabella1 · Last updated Sep 15, 2026
A company has applications that run on Amazon EC2 instances. The EC2 instances connect to Amazon RDS databases by using an IAM role that has associated policies. The company wants to use AWS Systems Manager to patch the EC2 inst...
Let's evaluate the options for the company that wants to use AWS Systems Manager to patch EC2 instances without disrupting running applications. The EC2 instances already connect to Amazon RDS databases using an IAM role with associated policies. The company wants to ensure that Systems Manager can manage these instances for patching.
Key Requirements:
1. Use AWS Systems Manager to patch EC2 instances.
2. Do not disrupt running applications.
3. Maintain IAM role and permissions for EC2 instances to interact with RDS.
4. Ensure the EC2 instances are able to interact with Systems Manager for patching purposes.
A) Create a new IAM role. Attach the AmazonSSMManagedInstanceCore policy to the new IAM role. Attach the new IAM role to the EC2 instances and the existing IAM role.
- Pros: Creating a new IAM role with the `AmazonSSMManagedInstanceCore` policy can give EC2 instances the necessary permissions for Systems Manager to manage them. Adding both the new IAM role and the existing IAM role ensures the EC2 instances maintain the permissions needed to access RDS databases as well.
- Cons: While this option works, it involves attaching a new IAM role in addition to the existing one, which could complicate the configuration unnecessarily.
- Conclusion: This approach works, but it's more complex than necessary, as only one IAM role needs to be modified to grant Systems Manager access.
B) Create an IAM user. Attach the AmazonSSMManagedInstanceCore policy to the IAM user. Configure Systems Manager to use the IAM user to manage the EC2 instances.
- Pros: IAM users can be used to control access to AWS services.
- Cons: IAM users are not intended for EC2 instances to interact with AWS services. EC2 instances should use IAM roles, not IAM users, to authenticate and interact with AWS services like Systems Manager. This approach would not work for Systems Manager patching of EC2 instances.
- Conc...
Author: William · Last updated Sep 15, 2026
A company runs container applications by using Amazon Elastic Kubernetes Service (Amazon EKS) and the Kubernetes Horizontal Pod Autoscaler. The workload is not consistent throughout the day. A solutions architect notices that the number of nodes does not automatically scale out when the existing nodes have reached maximum ...
To resolve the issue where the number of nodes in the Amazon EKS cluster does not automatically scale out when the existing nodes reach maximum capacity, let's evaluate each option to determine which solution will resolve the issue with the least administrative overhead:
A) Scale out the nodes by tracking the memory usage.
- Pros: Tracking memory usage is a valid metric for scaling, as it can indicate when the nodes are running out of resources.
- Cons: Manually scaling based on memory usage adds administrative overhead because the solution is not automated. You would need to constantly monitor the memory usage and scale out manually, which defeats the purpose of automatic scaling. Kubernetes already provides mechanisms for auto-scaling at the pod level, but scaling out nodes manually or based on static metrics is inefficient and prone to delays.
- Conclusion: This solution does not address the root cause of the problem and introduces more manual effort, so it is not the best option.
B) Use the Kubernetes Cluster Autoscaler to manage the number of nodes in the cluster.
- Pros: The Kubernetes Cluster Autoscaler automatically adjusts the number of nodes in your cluster based on the resource requests and utilization of pods. If pods are not schedulable due to resource limits, the Cluster Autoscaler can add new nodes to the cluster. It integrates seamlessly with Amazon EKS and Kubernetes and requires minimal administrative overhead once set up. This is the most appropriate solution for dynamically scaling the number of nodes in response to workloads.
- Cons: The Cluster Autoscaler must be correctly configured and integrated with your EKS cluster, but it is a fully managed and well-documented solution.
- Conclusion: This solution directly solves the problem of auto-scaling nodes in an EKS cluster with the least administrative overhead, making it the best choice.
C) Use an AWS Lambda ...
Author: Henry · Last updated Sep 15, 2026
A company maintains about 300 TB in Amazon S3 Standard storage month after month. The S3 objects are each typically around 50 GB in size and are frequently replaced with multipart uploads by their global application. The number and size of S3 objects remain constant, but the c...
The company maintains 300 TB of data in Amazon S3 Standard storage, with objects around 50 GB each, frequently replaced through multipart uploads. Given this situation, the company is seeing increasing S3 storage costs and seeks to reduce those costs. Let's evaluate each solution:
A) Switch from multipart uploads to Amazon S3 Transfer Acceleration.
- Pros: S3 Transfer Acceleration is designed to speed up the upload and download of objects to/from S3, especially for geographically dispersed clients.
- Cons: While it improves upload performance, it does not address the storage cost issue. S3 Transfer Acceleration increases costs due to additional charges for data transfer over accelerated networks, and it doesn't change the underlying storage class or reduce storage costs.
- Conclusion: This option is irrelevant to cost reduction because it does not impact the storage class or management of the data, which is the core issue.
B) Enable an S3 Lifecycle policy that deletes incomplete multipart uploads.
- Pros: Multipart uploads are split into parts, and if not completed properly, they leave incomplete objects in the storage. These objects can incur unnecessary costs. Enabling a lifecycle policy to automatically delete incomplete multipart uploads prevents these objects from being left behind in the storage, which would reduce unnecessary costs.
- Cons: While this helps to remove incomplete uploads, it doesn't reduce the cost of the completed objects themselves (which are large and frequently replaced). However, since the storage is replaced, preventing incomplete uploads will save costs related to orphaned partial uploads, reducing overall storage consumption.
- Conclusion: This option helps reduce costs related to incomplete multipart uploads, but it won't directly address the core problem of large, frequently replaced S3 objects consuming a significant portion of the storage.
C) Configure S3 inventory to prevent ob...
Author: Emma · Last updated Sep 15, 2026
A company has deployed a multiplayer game for mobile devices. The game requires live location tracking of players based on latitude and longitude. The data store for the game must support rapid updates and retrieval of locations.
The game uses an Amazon RDS for PostgreSQL DB instance with read replicas to store the location data. During peak usage periods, the database is unable to maintain the performance...
The main challenge here is the inability of the current Amazon RDS for PostgreSQL database instance, especially during peak usage periods, to support the required read and write performance due to the increasing user base and the need for live location tracking.
Let's evaluate the options one by one:
A) Take a snapshot of the existing DB instance. Restore the snapshot with Multi-AZ enabled.
- Reasoning: Multi-AZ deployments provide high availability by automatically replicating data to a standby instance in a different Availability Zone. However, Multi-AZ is primarily for failover and disaster recovery, not for improving the read/write performance during peak usage. In the case of rapidly increasing read/write requests, Multi-AZ will not solve the issue as it doesn't directly enhance performance for heavy traffic. It ensures availability, not performance scaling under load.
- Rejected because: Multi-AZ only helps with availability, not performance scaling during peak load.
B) Migrate from Amazon RDS to Amazon OpenSearch Service with OpenSearch Dashboards.
- Reasoning: Amazon OpenSearch Service (formerly Amazon Elasticsearch Service) is used primarily for search and log analytics. While it’s useful for handling large amounts of log data and performing search queries, it is not designed for transactional databases or real-time location data like latitude and longitude updates. OpenSearch can be used for storing and analyzing game events but not for transactional data like user location tracking in real-time.
- Rejected because: OpenSearch is not suited for transactional databases and real-time location tracking updates, which require a different type of database optimized for rapid updates.
C) Deploy Amazon DynamoDB Accelerator (DAX) in front of the existing DB instance. Modify the game to use DAX.
- Reasoning: Amazon DynamoDB Accelerator (DAX) is a fully managed, in-memory cache for DynamoDB that can significantly accelerate read performance for applications using Dynam...
Author: Sara · Last updated Sep 15, 2026
A company stores critical data in Amazon DynamoDB tables in the company's AWS account. An IT administrator accidentally deleted a DynamoDB table. The deletion caused a significant loss of data and disrupted the company's operations. The company wants to prevent this ...
Let’s evaluate each option to understand which one best addresses the requirement of preventing disruptions caused by accidental deletion with the least operational overhead:
A) Configure a trail in AWS CloudTrail. Create an Amazon EventBridge rule for delete actions. Create an AWS Lambda function to automatically restore deleted DynamoDB tables.
- Reasoning: This solution would involve multiple steps: configuring AWS CloudTrail to log delete actions, setting up an EventBridge rule to capture delete actions, and creating an AWS Lambda function to restore deleted tables. While this solution could automatically restore deleted tables, it introduces complexity and operational overhead. Specifically, maintaining CloudTrail, EventBridge, and the Lambda function requires constant monitoring and management, and it may not be the simplest or most efficient way to handle accidental deletions.
- Rejected because: While this solution could restore deleted tables automatically, it has a higher operational overhead, requiring multiple AWS services to work together and ongoing management.
B) Create a backup and restore plan for the DynamoDB tables. Recover the DynamoDB tables manually.
- Reasoning: Creating a backup and restore plan would ensure that the tables can be recovered in the event of deletion, but this still requires manual intervention. While it’s important to have a backup strategy, relying on manual recovery can lead to delays in restoring data, which could disrupt operations and potentially be inefficient during high-pressure situations.
- Rejected because: This requires manual recovery, which is not the ideal solution for preventing disruption or ensuring a quick, automatic response to accidental deletions.
C) Configure deletion protection on the DynamoDB tables.
- ...
Author: Noah · Last updated Sep 15, 2026
A company has an on-premises data center that is running out of storage capacity. The company wants to migrate its storage infrastructure to AWS while minimizing bandwidth costs. The solution must allow for...
Let's analyze each of the given options to determine the best solution that meets the requirements of migrating storage infrastructure to AWS while minimizing bandwidth costs and allowing for immediate retrieval of data at no additional cost:
A) Deploy Amazon S3 Glacier Vault and enable expedited retrieval. Enable provisioned retrieval capacity for the workload.
- Reasoning: Amazon S3 Glacier is designed for archival storage, and while it provides low-cost storage, it is not optimized for immediate retrieval. Even with expedited retrieval, data may take minutes to retrieve, and the process involves additional costs. This is not ideal if the company needs immediate access to data at no additional cost. Additionally, Glacier is best suited for infrequently accessed data, not for regular or frequent retrieval.
- Rejected because: While Glacier is cost-effective, it doesn’t meet the need for immediate retrieval at no additional cost. Expedited retrieval is still a paid feature.
B) Deploy AWS Storage Gateway using cached volumes. Use Storage Gateway to store data in Amazon S3 while retaining copies of frequently accessed data subsets locally.
- Reasoning: AWS Storage Gateway with cached volumes allows data to be stored in Amazon S3 while retaining frequently accessed data locally. This option minimizes bandwidth costs because it only transfers infrequently accessed data to S3, with the frequently accessed subset kept on-premises. This solution allows for immediate retrieval of locally cached data without incurring additional costs. The rest of the data is stored in Amazon S3, which is easily accessible.
- Selected because: This solution provides immediate retrieval of locally cached data at no additional cost and minimizes bandwidth costs, which is a key requirement of the company. It combines the benefits of cloud storage and local caching to balance cost and performance.
C) Deploy AWS Storage Gateway using stored volumes to store data locally. Use Storage Gateway to asynchronously back up point-in-time snapshots of the data to Amazon S3.
- Reasoning: Stored volumes...
Author: Joseph · Last updated Sep 15, 2026
A company runs a three-tier web application in a VPC across multiple Availability Zones. Amazon EC2 instances run in an Auto Scaling group for the application tier.
The company needs to make an automated scaling plan that will analyze each resource's daily and weekly historical workload trends. The configuration must scale resources appropriately acc...
Let’s evaluate each of the given options and determine the best scaling strategy based on the requirement to analyze historical trends and scale resources accordingly, considering both forecasted demand and live utilization changes.
A) Implement dynamic scaling with step scaling based on average CPU utilization from the EC2 instances.
- Reasoning: Step scaling adjusts capacity based on a set of predefined steps depending on the value of a specified metric (e.g., CPU utilization). While this approach can scale EC2 instances effectively based on CPU utilization, it doesn’t account for forecasted demand and doesn’t use historical workload trends or live changes in utilization in an integrated way. It simply reacts to thresholds set for CPU metrics and may not optimally address usage trends over time (daily/weekly).
- Rejected because: Step scaling doesn’t utilize forecast data or historical usage trends for proactive scaling, making it less ideal for meeting the company’s requirements.
B) Enable predictive scaling to forecast and scale. Configure dynamic scaling with target tracking.
- Reasoning: Predictive scaling uses historical data and trends (such as daily and weekly patterns) to forecast future resource requirements. This is particularly useful for scaling based on anticipated demand. By combining this with dynamic scaling using target tracking, the system can adjust capacity based on live utilization and forecasted demand. Target tracking helps ensure that the system maintains a specified metric, such as average CPU utilization or request count, within a defined target range, ensuring that scaling responds in real-time as well.
- Selected because: This option perfectly aligns with the company’s need to scale resources according to both historical workload trends (through predictive scaling) and live utilization changes (via dynamic scaling with target tracking). It addresses both short-term fluctuations and long-term trend...
Author: ElectricLionX · Last updated Sep 15, 2026
A package delivery company has an application that uses Amazon EC2 instances and an Amazon Aurora MySQL DB cluster. As the application becomes more popular, EC2 instance usage increases only slightly. DB cluster usage increases at a much faster rate.
The company adds a read replica, which reduces the DB cluster usage for a short period of time. However, the load continues to increase. The operations that cause the increase in DB cluster usage are all repeated r...
Let’s analyze each option to determine the most cost-effective solution to alleviate the increased DB cluster usage caused by repeated read statements related to delivery details.
A) Implement an Amazon ElastiCache for Redis cluster between the application and the DB cluster.
- Reasoning: Amazon ElastiCache for Redis is an in-memory caching solution designed to offload frequent read queries from the database. In this scenario, delivery details that are frequently read could be cached in Redis, reducing the load on the Aurora MySQL DB cluster. Redis is highly efficient for storing and retrieving frequently accessed data, and using it for repeated read operations can significantly improve performance by reducing database load and enhancing the speed of read queries. Additionally, ElastiCache for Redis is cost-effective compared to scaling up database resources because it reduces the need for additional database replicas or instances. Redis caches data for fast retrieval without the database having to handle every query.
- Selected because: This solution is most cost-effective because Redis can handle frequent read requests without continuously burdening the database, saving on the cost of adding more database resources. It also helps reduce latency and improve the scalability of the system by reducing pressure on the DB cluster.
B) Add an additional read replica to the DB cluster.
- Reasoning: Adding another read replica would help distribute the read load, but it does not address the core problem: the repeated nature of the read queries. Even though adding a replica can provide more capacity for read requests, the DB cluster will still experience the same amount of repeated traffic, and this solution doesn't reduce the underlying load effectively. Additionally, adding read replicas increases the costs as each replica incurs additional charges.
- Rejected because: This only scales the DB cluster vertically but does not solve the issue of repeated queries. It’s also a more expensive solution because each additional read replica adds cost, without address...
Author: Noah · Last updated Sep 15, 2026
A company has an application that uses an Amazon DynamoDB table for storage. A solutions architect discovers that many requests to the table are not returning the latest data. The company's users have not reported any other issues with database perf...
In this scenario, the issue is that requests to the DynamoDB table are not returning the latest data. Since latency is in an acceptable range and performance is not impacted, the problem seems to be related to how up-to-date the data is when retrieved.
Let's evaluate each option:
A) Add read replicas to the table.
- Not a good fit for this scenario. DynamoDB does not support traditional read replicas in the way some other databases do. However, it does provide global tables, which replicate data across regions. This approach would not directly address the issue of inconsistent reads within a single region and would not ensure that the latest data is available on reads. Additionally, it introduces more complexity and costs, especially if you do not require cross-region replication.
B) Use a global secondary index (GSI).
- Not a good fit for this scenario. A GSI is useful when you want to query the table with a different sort key or partition key. However, it doesn't directly solve the problem of fetching the latest data. If the issue is that the application is not seeing the most recent updates (likely due to the nature of read consistency), simply adding a GSI will not resolve this.
C) Request strongly consistent reads for the table.
- The most appropriate option. By default, DynamoDB uses eventually consistent reads, which means the data returned might not be the most recent if there are ongoing writes to the table. Strongly consistent reads ensure that the data returned is the latest...
Author: John · Last updated Sep 15, 2026
A company has deployed its application on Amazon EC2 instances with an Amazon RDS database. The company used the principle of least privilege to configure the database access credentials. The company's security team wants to protect the application and the database from SQL in...
To address the requirements of protecting the application and database from SQL injection and other web-based attacks while maintaining the principle of least privilege, let's evaluate each option:
A) Use security groups and network ACLs to secure the database and application servers.
- Not the best fit. Security groups and network ACLs are used primarily for controlling network traffic between resources in your AWS environment. While they are essential for limiting access to your application and database servers (e.g., allowing only certain IP ranges or instances to communicate with the RDS database), they do not directly protect against SQL injection attacks or other web-based attacks like cross-site scripting (XSS) or cross-site request forgery (CSRF). These types of attacks target vulnerabilities in the web application layer rather than the network level.
B) Use AWS WAF to protect the application. Use RDS parameter groups to configure the security settings.
- A very strong option. AWS WAF (Web Application Firewall) provides a managed service to protect your application from common web attacks, including SQL injection and XSS. It is specifically designed to protect against threats targeting the application layer, and you can easily create custom rules or use AWS managed rule sets to prevent SQL injection attempts.
- RDS parameter groups can be used to configure certain database-level security settings, but they do not directly protect the application from SQL injection or other web-based attacks.
- AWS WAF would address the concern of SQL injection directly by inspecting HTTP requests and blocking malicious patterns before they reach the application.
- Why it's selected: This solution has minimal operational overhead because AWS WAF is a managed service that doesn't require you to manually manage infrastructure or implement custom application-level protections like input validation or sanitation. It directly addresses web-based attacks with minimal configuration.
C) Use AWS Network Firewall to protect the application and the database.
- Not a good fi...
Author: Joseph · Last updated Sep 15, 2026
An ecommerce company runs applications in AWS accounts that are part of an organization in AWS Organizations. The applications run on Amazon Aurora PostgreSQL databases across all the accounts. The company needs to prevent malicious activity and must identify abnormal failed and incompl...
To meet the requirements of identifying abnormal failed and incomplete login attempts to Amazon Aurora PostgreSQL databases with the least operational overhead, let's evaluate each option:
A) Attach service control policies (SCPs) to the root of the organization to identify the failed login attempts.
- Not suitable for this use case. SCPs in AWS Organizations are used to manage permissions across AWS accounts within an organization. They define what actions are allowed or denied at the account level but are not designed for monitoring or auditing specific activities like failed login attempts to a database. SCPs are more about controlling access rather than identifying abnormal or malicious behavior. Therefore, this option does not directly address the issue of identifying failed or incomplete login attempts.
B) Enable the Amazon RDS Protection feature in Amazon GuardDuty for the member accounts of the organization.
- A very strong option. GuardDuty can monitor Amazon RDS (including Aurora) and detect suspicious activity such as anomalous login attempts. Enabling GuardDuty for the member accounts in the organization will allow you to identify and respond to potential security threats, including failed or incomplete login attempts. GuardDuty provides a managed, automated solution that does not require you to set up complex monitoring or logging pipelines. This makes it an excellent choice for meeting the requirement with minimal operational overhead.
- Why it's selected: GuardDuty provides threat detection without requiring significant setup or manual management. It can detect failed login attempts, abnormal behaviors, and other potential malicious activities related to Amazon RDS databases, which directly addresses the requirements.
C) Publish the Aurora general logs to a log group in Amazon CloudWatch Logs. Export the log data to a central Amazon S3 bucket.
- Requires more operational overhead. While publishing Aurora general logs to CloudWatch Logs and exporting them to S3 will allow you to analyze database logs for failed or incomplete login attempts, this solutio...
Author: Ava · Last updated Sep 15, 2026
A company has an AWS Direct Connect connection from its corporate data center to its VPC in the us-east-1 Region. The company recently acquired a corporation that has several VPCs and a Direct Connect connection between its on-premises data center and the eu-west-2 Region. The CIDR blocks for the VPCs of the company and the corporation do not overlap. The company requires connectivity between two Region...
Let's analyze the given scenario and the available options to select the most suitable solution for meeting the company's requirements.
Requirements:
- Connectivity between two regions (us-east-1 and eu-west-2).
- Connectivity between the data centers (corporate and newly acquired).
- Scalable solution with reduced operational overhead.
- The CIDR blocks of the VPCs of both companies do not overlap, which simplifies routing between them.
A) Set up inter-Region VPC peering between the VPC in us-east-1 and the VPCs in eu-west-2.
- Not the best fit. While inter-region VPC peering is a viable option for connecting VPCs across regions, it has some limitations:
- Limited scalability: Managing multiple peering connections becomes complex as the number of VPCs grows. This can result in a high operational overhead, especially with many VPCs across regions.
- Routing complexity: You would need to create individual peering connections between each VPC in the two regions, leading to more complex management.
- Limited to VPC-to-VPC connections: It doesn’t inherently address the requirement for Direct Connect connectivity between the data centers and VPCs, making it less suitable for this multi-faceted requirement.
B) Create private virtual interfaces from the Direct Connect connection in us-east-1 to the VPCs in eu-west-2.
- Not ideal. Creating private virtual interfaces between the Direct Connect connection in us-east-1 and the VPCs in eu-west-2 would require additional Direct Connect connections and private virtual interfaces in both regions.
- This introduces complexity, as it would require separate connections in both regions and could be more expensive than alternative solutions.
- Moreover, the setup would be more involved, needing configuration changes in both the existing Direct Connect and additional connections to connect between regions, which doesn’t align with the operational overhead goal.
C) Establish VPN appliances in a fully meshed VPN network hosted by Amazon EC2. Use AWS VPN CloudHub to send and receive data between the data centers and each VPC.
- Not ideal. While AWS VPN CloudHub allows communication between multiple VPN connections in diffe...
Author: Matthew · Last updated Sep 15, 2026
A company is developing a mobile game that streams score updates to a backend processor and then posts results on a leaderboard. A solutions architect needs to design a solution that can handle large traffic spikes, process the mobile game updates in order of receipt, and store the processed updates in a highly available database. The company al...
To design a solution that handles large traffic spikes, processes updates in order of receipt, and stores the processed updates in a highly available database while minimizing management overhead, let's evaluate the available options:
A) Push score updates to Amazon Kinesis Data Streams. Process the updates in Kinesis Data Streams with AWS Lambda. Store the processed updates in Amazon DynamoDB.
- Selected option. This is a strong choice because:
- Scalable: Amazon Kinesis Data Streams can handle large traffic spikes by ingesting a high volume of real-time data. Kinesis is designed for streaming workloads, which is a perfect fit for processing game score updates.
- Processing in Order: Kinesis guarantees that data is processed in the order it is ingested within a shard, ensuring the correct order of score updates.
- Lambda Integration: AWS Lambda can automatically scale in response to incoming events from Kinesis, allowing for flexible, serverless processing without the need to manage infrastructure.
- DynamoDB: Amazon DynamoDB is a fully managed NoSQL database that is highly available and scalable, which is ideal for storing leaderboard data in a fast, efficient, and reliable manner. DynamoDB also supports strong consistency and can handle high read and write throughput.
- Minimal management overhead: The combination of Kinesis, Lambda, and DynamoDB is a fully managed solution that minimizes operational overhead since AWS manages the underlying infrastructure and scaling for you.
- Why it's selected: This solution effectively meets all requirements: handling high traffic, processing updates in order, and storing data in a highly available database while minimizing operational complexity.
B) Push score updates to Amazon Kinesis Data Streams. Process the updates with a fleet of Amazon EC2 instances set up for Auto Scaling. Store the processed updates in Amazon Redshift.
- Not ideal:
- EC2 Management: Using EC2 instances for processing adds operational overhead. While Auto Scaling helps with traffic spikes, you still need to manage the EC2 fleet, ensuring proper scaling, monitoring, and maintenance.
- Redshift for leaderboard storage: Amazon Redshift is a data warehouse designed for complex analytical queries on large datasets, not for low-latency transactional updates like a leaderboard. It is not well-suited for storing real-time game score updates.
- Higher complexity: This approach introduces more management overhead than the serverless Lambda solution and may not be as efficient for the use case of storing leaderboard data.
C) Push score updates to an ...
Author: StarlightBear · Last updated Sep 15, 2026
A company has multiple AWS accounts with applications deployed in the us-west-2 Region. Application logs are stored within Amazon S3 buckets in each account. The company wants to build a centralized log analysis solution that uses a single S3 bucket. Logs must not leave us-west-2, and the...
To solve this problem, we need to evaluate each option with key factors in mind: operational overhead, cost-effectiveness, and compliance with the requirement that logs stay within the us-west-2 region.
Option A: Create an S3 Lifecycle policy that copies the objects from one of the application S3 buckets to the centralized S3 bucket.
- Pros:
- Lifecycle policies are easy to set up and require minimal maintenance.
- There is minimal operational overhead because AWS manages the lifecycle of objects.
- Cons:
- Lifecycle policies are typically used to move or expire objects rather than to copy them continuously.
- Lifecycle policies don’t support cross-account operations (it can’t automatically move data from one account’s S3 bucket to another’s). The solution requires one S3 bucket, which wouldn't work well with the multi-account scenario.
Conclusion: This option is not suitable for multi-account scenarios, as it does not support cross-account transfers.
Option B: Use S3 Same-Region Replication to replicate logs from the S3 buckets to another S3 bucket in us-west-2. Use this S3 bucket for log analysis.
- Pros:
- S3 Same-Region Replication (SRR) is an excellent choice for ensuring that data remains within the same region (us-west-2) as required.
- This solution is designed for cross-account replication and is highly automated, reducing operational overhead.
- SRR also allows for automated replication as soon as new data is written, meeting the need for real-time log analysis.
- Cons:
- Slightly higher costs due to replication charges.
- Setup might require some configuration for cross-account access (IAM roles), but it is still less complex than other solutions.
Conclusion: This is a strong option since it meets all the requirements with minimal operational overhead.
Option C: Write a script that uses the PutObject API operation every day to copy the entire contents of the buckets to another S3 bucket in us-west-2. Use this S3 bucket for log analysis.
- Pros...
Author: Leah Davis · Last updated Sep 15, 2026
A company has an application that delivers on-demand training videos to students around the world. The application also allows authorized content developers to upload videos. The data is stored in an Amazon S3 bucket in the us-east-2 Region.
The company has created an S3 bucket in the eu-west-2 Region and an S3 bucket in the ap-southeast-1 Region. The company wants to replicate the data to the new S3 buckets. The company needs to minimize latency for developers...
In this case, the company needs to replicate data from an Amazon S3 bucket in us-east-2 to the new S3 buckets in eu-west-2 and ap-southeast-1, while minimizing latency for content developers and students located near these regions. Additionally, the company wants to make the fewest changes to the application. Let’s go through each option step-by-step:
Option A: Configure one-way replication from the us-east-2 S3 bucket to the eu-west-2 S3 bucket. Configure one-way replication from the us-east-2 S3 bucket to the ap-southeast-1 S3 bucket.
- Pros:
- This solution minimizes complexity and keeps the S3 buckets synchronized.
- No modification is needed for video uploads, which keeps operational changes minimal.
- The replication ensures that videos are available in the eu-west-2 and ap-southeast-1 regions for fast streaming by students.
- Cons:
- This approach does not address content developers' uploading experience. Developers who are located closer to eu-west-2 or ap-southeast-1 might experience higher latency when uploading videos to the us-east-2 region. This issue could be resolved by adjusting the upload strategy in the application.
Conclusion: This is a feasible option because it allows video streaming to be optimized in both regions, but the upload path for developers will still be from us-east-2.
Option B: Configure one-way replication from the us-east-2 S3 bucket to the eu-west-2 S3 bucket. Configure one-way replication from the eu-west-2 S3 bucket to the ap-southeast-1 S3 bucket.
- Pros:
- This solution replicates the data from us-east-2 to eu-west-2, and then from eu-west-2 to ap-southeast-1, creating an additional layer of data redundancy across regions.
- It allows for replication to both eu-west-2 and ap-southeast-1, providing optimized streaming access for students.
- Cons:
- This introduces a second hop in replication, adding more complexity and potential latency when updating or adding new videos. eu-west-2 is a middle stage in this replication, meaning the latest data may not be available in ap-southeast-1 as quickly.
- This approach doesn't directly address the need to reduce upload latency for content developers located closer to eu-west-2 or ap-southeast-1.
Conclusion: This solution adds unnecessary complexity and latency, especially with the additional hop in replication. This makes it less efficient compared to Option A.
Option C: Configure two-way (bidirectional) replication among the S3 buckets that are in all three Regions.
- Pros:
- With bidirectional replication, data can be synchronized across all three regions.
- Cons:
- Increased complexity: Bidirectional replication introduces unnecessary complexity, as it requires both buckets t...
Author: Noah · Last updated Sep 15, 2026
A company has a new mobile app. Anywhere in the world, users can see local news on topics they choose. Users also can post photos and videos from inside the app.
Users access content often in the first minutes after the content is posted. New content quickly replaces older content, and then the older content disappears. The local nature of the news means that users consume 90%...
To solve this problem, we need to focus on minimizing the latency for content uploads and ensure that the solution is both efficient and scalable. Let's analyze the options one by one based on the key factors of latency, content delivery speed, and cost-efficiency.
Option A: Upload and store content in Amazon S3. Use Amazon CloudFront for the uploads.
- Pros:
- CloudFront is a content delivery network (CDN) designed to distribute content globally with low latency.
- CloudFront would help speed up content delivery once it is uploaded and stored in S3.
- Cons:
- CloudFront is designed for content delivery rather than uploads. It does not optimize upload latency, and in fact, CloudFront would not help speed up the upload process from the user's device to the S3 bucket. This is more useful for speeding up the download/streaming part of the application.
Conclusion: This option focuses more on content distribution and streaming (download), not optimizing the upload process for content creators. Therefore, it is not the best solution for minimizing upload latency.
Option B: Upload and store content in Amazon S3. Use S3 Transfer Acceleration for the uploads.
- Pros:
- S3 Transfer Acceleration is designed to accelerate the upload speed to S3 by routing uploads through Amazon's edge locations, which reduces latency and speeds up transfers over long distances.
- It benefits users uploading from geographically distant locations, as it optimizes upload speeds, particularly when the user is far from the S3 bucket's region.
- Cons:
- While S3 Transfer Acceleration speeds up uploads, the feature comes with additional costs.
- For local content uploads (e.g., when users are within the region of the S3 bucket), S3 Transfer Acceleration may not provide substantial gains.
Conclusion: S3 Transfer Acceleration is a strong option for speeding up uploads, especially for users who are not geographically near the S3 bucket. It minimizes upload latency but incurs additional costs.
Option C: Upload content to Amazon EC2 instances in the Region that is closest to the user. Copy the data to Amazon S3.
- Pros:
- Uploading directly to EC2...
Author: Emma · Last updated Sep 15, 2026
A company is building a new application that uses serverless architecture. The architecture will consist of an Amazon API Gateway REST API and AWS Lambda functions to manage incoming requests.
The company wants to add a service that can send messages received from the API Gateway REST API to multiple target Lambda functions for processing. The service must offer message filtering that gives t...
To meet the company's requirements of sending messages to multiple Lambda functions with message filtering and minimizing operational overhead, let’s evaluate each option carefully.
Option A: Send the requests from the API Gateway REST API to an Amazon Simple Notification Service (Amazon SNS) topic. Subscribe Amazon Simple Queue Service (Amazon SQS) queues to the SNS topic. Configure the target Lambda functions to poll the different SQS queues.
- Pros:
- SNS can publish messages to multiple subscribers, and each SQS queue can be filtered using message attributes.
- Each Lambda function can then process only the messages it needs by filtering the messages in the SQS queue.
- Cons:
- There is some complexity in managing multiple SQS queues and ensuring proper message filtering in each queue.
- Lambda functions need to poll the queues, which can add some operational overhead in managing queue-based processing.
Conclusion: While this solution could work, it introduces more operational complexity with multiple queues and polling. It requires managing different queues and ensuring correct filtering at the SQS level, which could lead to more manual configuration and management.
Option B: Send the requests from the API Gateway REST API to Amazon EventBridge. Configure EventBridge to invoke the target Lambda functions.
- Pros:
- EventBridge is designed to route events to multiple targets, including Lambda functions. It has built-in event filtering capabilities, allowing only relevant events to be sent to each target function.
- This allows you to configure filtering rules for each Lambda function to receive only the necessary events based on event patterns or attributes.
- EventBridge integrates well with serverless architectures and provides native support for handling multiple targets and filtering, which reduces operational overhead.
- Cons:
- This solution is highly scalable and flexible, but requires understanding how to create proper event rules and patterns for filtering.
Conclusion: EventBridge is the best option because it has native support for event routing and filtering, reducing operational overhead compared to the SQS-based solutions. This solution aligns with the serverless architecture and provides an elegant, scalable solution.
Option C: Send the requests from the API Gateway REST API to Amazon Managed Streaming for Apache Kafka (Amazon MSK). Configure Am...
Author: FrostFalcon88 · Last updated Sep 15, 2026
A company migrated millions of archival files to Amazon S3. A solutions architect needs to implement a solution that will encrypt all the archival data by using a customer-provided key. The solution must encrypt exi...
To implement encryption of both existing and future objects in Amazon S3 using a customer-provided key (SSE-C), we need to evaluate the options based on the following criteria:
1. Encryption for Existing Objects: The solution must encrypt the unencrypted objects that are already in S3.
2. Encryption for Future Objects: The solution must also automatically encrypt any new objects that are uploaded to S3.
3. Use of SSE-C (Customer-Provided Key): The requirement specifies that the solution should use SSE-C, where the customer manages the encryption key.
Let's evaluate each option:
Option A: Create a list of unencrypted objects by filtering an Amazon S3 Inventory report. Configure an S3 Batch Operations job to encrypt the objects from the list with a server-side encryption with a customer-provided key (SSE-C). Configure the S3 default encryption feature to use a server-side encryption with a customer-provided key (SSE-C).
- Pros:
- S3 Inventory can generate a report of all objects in a bucket, including whether they are encrypted or not.
- S3 Batch Operations allows you to process large numbers of objects at once, making it a scalable solution for encrypting existing unencrypted objects.
- Default Encryption can be set at the bucket level to automatically apply SSE-C to all future uploads, ensuring that future objects are encrypted with the customer-provided key.
- Cons:
- The process of generating an inventory report and running a batch job requires manual setup. This adds some operational overhead.
- SSE-C requires the customer to manage the encryption keys themselves, which can increase the operational burden if the key management process is not automated.
Conclusion: This option meets the requirement to encrypt existing and future objects with SSE-C, using a combination of S3 Inventory and S3 Batch Operations, along with default encryption. It is the correct choice but requires some setup for the batch job.
Option B: Use S3 Storage Lens metrics to identify unencrypted S3 buckets. Configure the S3 default encryption feature to use a server-side encryption with AWS KMS keys (SSE-KMS).
- Pros:
- S3 Storage Lens can provide insights into S3 usage and help identify unencrypted buckets.
- S3 Default Encryption can be set to use SSE-KMS, ensuring that future objects are encrypted with AWS-managed KMS keys.
- Cons:
- This solution does not meet the requirement of using a customer-provided key (SSE-C), as it uses SSE-KMS, which ...
Author: Madison · Last updated Sep 15, 2026
The DNS provider that hosts a company's domain name records is experiencing outages that cause service disruption for a website running on AWS. The company needs to migrate to a more resilient managed DNS service and wants the servic...
To rapidly migrate the DNS hosting service for a company facing outages with its DNS provider, the solution needs to be resilient, efficient, and directly integrated with AWS. The goal is to transition to a more reliable managed DNS service hosted on AWS, minimizing downtime and avoiding further disruptions.
Option A: Create an Amazon Route 53 public hosted zone for the domain name. Import the zone file containing the domain records hosted by the previous provider.
Reasoning:
- This is the best option for migrating to a fully managed DNS service in AWS because Amazon Route 53 is designed to provide highly available and scalable DNS hosting.
- A public hosted zone is the right choice because the domain name records should be publicly accessible on the internet (which is usually the case for websites).
- Importing the existing zone file from the current DNS provider makes the transition faster and minimizes manual configuration.
- Route 53 supports features like health checks, failover, and DNS routing policies, which make it highly resilient and suitable for a production environment.
Rejected Reasons:
- This option is the most efficient and relevant choice for the scenario where a public website needs DNS hosting. It fully leverages AWS's DNS service capabilities.
Option B: Create an Amazon Route 53 private hosted zone for the domain name. Import the zone file containing the domain records hosted by the previous provider.
Reasoning:
- A private hosted zone is used for DNS records that are meant to be resolved only within a VPC. This is useful for internal resources, such as internal services or applications.
- Since this is about migrating a public website, using a private hosted zone would not be appropriate for DNS records that need to be publicly available.
Rejected Reasons:
- Private hosted zones are intended for internal, non-public use, so it does not meet the requirement of providing a public DNS service for a website.
Option C: Create a Simple AD directory in AWS. Enable zone transfer between the DNS provider and AWS Directory Service for Microsoft Active Directory for the domain records.
Reasoning:
- AWS Simple AD and AWS Directory Service are used for di...
Author: Aarav · Last updated Sep 15, 2026
A company is building an application on AWS that connects to an Amazon RDS database. The company wants to manage the application configuration and to securely store and retrieve credentials for the database and other se...
To securely store and retrieve credentials for an application connecting to an Amazon RDS database, while minimizing administrative overhead, the solution should leverage AWS services that are specifically designed for managing configurations and secrets in a scalable, secure, and easy-to-use manner.
Option A: Use AWS AppConfig to store and manage the application configuration. Use AWS Secrets Manager to store and retrieve the credentials.
Reasoning:
- AWS AppConfig is specifically designed for managing application configurations, providing an easy way to store and deploy configuration data without impacting the application's performance. It also supports validation and versioning of configuration data.
- AWS Secrets Manager is a fully managed service designed to store, rotate, and retrieve credentials securely. It is the ideal service for managing database credentials because it integrates easily with other AWS services (like Amazon RDS) and automates the process of credential rotation, ensuring enhanced security with minimal manual intervention.
- This solution is highly scalable, secure, and designed to integrate well with AWS-based applications, making it the most efficient in terms of administrative overhead.
Rejected Reasons:
- This option is selected because it meets all the requirements: it leverages purpose-built AWS services, integrates easily, minimizes administrative overhead, and handles credentials securely.
Option B: Use AWS Lambda to store and manage the application configuration. Use AWS Systems Manager Parameter Store to store and retrieve the credentials.
Reasoning:
- AWS Lambda is a serverless compute service, and while it can handle some configuration management tasks, it is not ideal for storing application configurations directly. Lambda functions are typically used to execute code rather than serve as a configuration management system.
- AWS Systems Manager Parameter Store can store credentials, but it does not offer the same level of security management and features (like automated secret rotation) as AWS Secrets Manager. While Parameter Store is secure, it lacks some of the advanced features that Secrets Manager provides, especially for handling credentials and automating secret rotation.
- This option requires more manual setup and lacks the out-of-the-box credential management features that AWS Secrets Manager provides.
Rejected Reasons:
- While Parameter Store can handle credential storage, it is not as feature-rich and automated as AWS Secrets Manager. Additionally, Lambda introduces more complexity than needed for configuration management, and it is not the bes...
Author: Oscar · Last updated Sep 15, 2026
To meet security requirements, a company needs to encrypt all of its application data in transit while communicating with an Amazon RDS MySQL DB instance. A recent security audit revealed that encryption at rest is enabled using AWS Key Management Service (AWS KMS),...
To meet the security requirement of encrypting application data in transit while communicating with an Amazon RDS MySQL DB instance, the focus is on ensuring that the data being transmitted between the application and the database is encrypted. Since encryption at rest is already enabled via AWS KMS, the next step is to ensure that data in transit is also secured. Let's analyze each option to determine the best approach.
Option A: Enable IAM database authentication on the database.
Reasoning:
- IAM database authentication provides a mechanism for securely managing database credentials using AWS Identity and Access Management (IAM) users and roles. While this enhances authentication security, it does not directly address encryption of data in transit between the application and the database.
- IAM authentication is beneficial for credential management but does not ensure that data transmitted between the client and RDS is encrypted. This option focuses on authentication and not encryption.
Rejected Reasons:
- This option does not fulfill the requirement of encrypting data in transit, as it is primarily focused on managing authentication rather than securing the data flow between the application and the database.
Option B: Provide self-signed certificates. Use the certificates in all connections to the RDS instance.
Reasoning:
- Self-signed certificates can be used to encrypt connections to the RDS instance, but they are generally not recommended for production environments due to potential security concerns such as trust issues and difficulty in managing certificate chains.
- While this option does encrypt data in transit, self-signed certificates require additional manual management and might pose security risks compared to other more robust and automated solutions. The lack of a trusted certificate authority (CA) could lead to potential vulnerabilities.
Rejected Reasons:
- Self-signed certificates can be more cumbersome to manage, lack automation, and might introduce trust issues in a production environment, making it less secure and convenient compared to other more secure, managed optio...
Author: Michael · Last updated Sep 15, 2026
A company is designing a new web service that will run on Amazon EC2 instances behind an Elastic Load Balancing (ELB) load balancer. However, many of the web service clients can only reach IP addresses authorized o...
To meet the client's needs where many of the web service clients can only reach IP addresses authorized on their firewalls, the key is to ensure that the web service can be accessed through static, predictable IP addresses. Given this requirement, the solution should focus on using a static IP address that the clients can whitelist.
Option A: A Network Load Balancer with an associated Elastic IP address.
Reasoning:
- Network Load Balancer (NLB) is designed to handle TCP traffic at the connection level, and it supports static IP addresses via Elastic IP addresses (EIP), which would allow the clients to whitelist those static IPs.
- The NLB provides high availability, low latency, and can be used with an Elastic IP, which is exactly what the clients need to whitelist a static IP address on their firewalls.
- Since many clients require fixed IP addresses, using an NLB with an Elastic IP ensures that the IP address is static and predictable, making it easy for the clients to configure their firewalls.
Selected Reasons:
- This solution satisfies the requirement of providing static, predictable IP addresses that clients can whitelist. The NLB is a good fit for handling high volumes of TCP traffic and offers features like low-latency routing.
Option B: An Application Load Balancer with an associated Elastic IP address.
Reasoning:
- Application Load Balancer (ALB) operates at the HTTP/HTTPS layer and does not natively support the association of Elastic IP addresses. The ALB automatically assigns public IP addresses, but they are dynamic and cannot be manually controlled or whitelisted by clients.
- While ALBs are good for HTTP/S traffic and provide advanced routing features, they do not meet the client's requirement for static IP addresses to whitelist on their firewalls.
Rejected Reasons:
- The key requirement here is to have a static IP address, which is not achievable directly with an ALB. Since ALBs do not support Elastic IPs, this option does not meet the security requirements for clients to whitelist static IPs.
Option C: An A record in an Amazon Route 53 hosted zone poi...
Author: Matthew · Last updated Sep 15, 2026
A company has established a new AWS account. The account is newly provisioned and no changes have been made to the default settings. The company is concerned about the security ...
To secure the AWS root user, it is essential to follow best practices that minimize the use of this account, limit its permissions, and protect it with strong authentication methods. The root user has full access to all resources and services in the AWS account, so securing it is a high priority to avoid unauthorized access.
Let's evaluate each option:
Option A: Create IAM users for daily administrative tasks. Disable the root user.
Reasoning:
- Disabling the root user is not possible in AWS. The root user is essential for account management and cannot be completely disabled.
- While creating IAM users for daily tasks is a best practice (since IAM users can be restricted to necessary permissions), the idea of disabling the root user is not feasible.
Rejected Reasons:
- Disabling the root user is not an option in AWS. While creating IAM users for administrative tasks is good, this solution does not fully address the requirement to secure the root user.
Option B: Create IAM users for daily administrative tasks. Enable multi-factor authentication on the root user.
Reasoning:
- Creating IAM users for day-to-day tasks is the best practice. These users can be given specific, limited permissions based on the principle of least privilege.
- Enabling multi-factor authentication (MFA) on the root user is essential to adding an extra layer of security. MFA ensures that even if someone obtains the root user’s credentials, they cannot access the account without the second authentication factor.
- This approach is recommended by AWS to secure the root user while minimizing its use. The root user should be reserved for very specific administrative tasks that cannot be performed by IAM users.
Selected Reasons:
- This is the most secure approach, as it combines the use of IAM users for regular tasks with an additional layer of security (MFA) on the root user. It minimizes the use of the root account while enhancing its security when access is necessa...
Author: Liam · Last updated Sep 15, 2026
A company is deploying an application that processes streaming data in near-real time. The company plans to use Amazon EC2 instances for the workload. The network architecture must be configurable to provide the lowest possible latency...
To meet the requirements of the company for a low-latency network architecture when processing streaming data in near-real time on Amazon EC2 instances, we need to focus on the solutions that optimize the network performance between EC2 instances while ensuring scalability and low latency.
Let’s analyze each option:
A) Enable and configure enhanced networking on each EC2 instance
Reasoning:
Enhanced networking provides higher bandwidth, lower latency, and lower jitter compared to standard EC2 networking. By enabling enhanced networking, you can achieve a direct network path with less contention, making it ideal for workloads requiring low-latency communication between EC2 instances.
Why selected: Enhanced networking is specifically designed for high-performance workloads, ensuring minimal latency, which is crucial for streaming data applications.
Why rejected: None; this option is highly beneficial for the given scenario.
B) Group the EC2 instances in separate accounts
Reasoning:
This would add unnecessary complexity to the networking setup and would not optimize latency. Keeping the instances within a single account enables simpler network configuration and better network latency management. Additionally, cross-account communication typically introduces more overhead.
Why rejected: Separating EC2 instances across different accounts does not contribute to reducing network latency and increases operational complexity.
C) Run the EC2 instances in a cluster placement group
Reasoning:
Cluster placement groups are designed to group instances in a way that places them physically close to each other within a data center. This reduces network latency between instances sinc...
Author: Julian · Last updated Sep 15, 2026
A financial services company wants to shut down two data centers and migrate more than 100 TB of data to AWS. The data has an intricate directory structure with millions of small files stored in deep hierarchies of subfolders. Most of the data is unstructured, and the company's file storage consists of SMB-based storage types from multiple vendors. The company does not want to ...
To address the requirements of migrating over 100 TB of data, which has an intricate directory structure, deep subfolder hierarchies, millions of small files, and is currently accessed via SMB-based file storage, we need to focus on options that will provide the least operational overhead, preserve the access method, and ensure seamless migration. Let’s analyze each option:
A) Use AWS Direct Connect to migrate the data to Amazon S3
Reasoning:
AWS Direct Connect provides a dedicated network connection between on-premises data centers and AWS, which can improve the transfer speed of large volumes of data. However, Direct Connect by itself doesn’t handle the migration of SMB-based file systems or manage directory structures and file-level access. It would need additional tools for migrating the data to Amazon S3 (which is object storage) while maintaining file access methods like SMB.
Why rejected: Although Direct Connect improves data transfer speed, it would require additional steps to convert the file system to an object store (Amazon S3), and this could increase operational overhead. Additionally, applications accessing SMB storage would need to be changed, which the company wants to avoid.
B) Use AWS DataSync to migrate the data to Amazon FSx for Lustre
Reasoning:
AWS DataSync is a service that can efficiently transfer large amounts of data, including preserving directory structures, and it integrates well with AWS storage solutions. However, Amazon FSx for Lustre is a high-performance file system optimized for workloads like machine learning and high-performance computing (HPC). It is not designed for SMB-based workloads and does not support native SMB access after migration.
Why rejected: FSx for Lustre is optimized for performance workloads, not for SMB-based file access. Since the company uses SMB for accessing data, this option would require a change in how applications access the data, which the company wants to avoid.
C) Use AWS Dat...
Author: NebulaEagle11 · Last updated Sep 15, 2026
A company uses an organization in AWS Organizations to manage AWS accounts that contain applications. The company sets up a dedicated monitoring member account in the organization. The company wants to query and visualize observability...
To meet the requirement of querying and visualizing observability data across multiple AWS accounts using Amazon CloudWatch in a centralized monitoring account, we need to implement a solution that ensures the monitoring account can access CloudWatch data from all other AWS accounts in the organization. Let's analyze each option:
A) Enable CloudWatch cross-account observability for the monitoring account. Deploy an AWS CloudFormation template provided by the monitoring account in each AWS account to share the data with the monitoring account.
Reasoning:
CloudWatch cross-account observability is designed to allow a centralized monitoring account to collect and visualize metrics and logs from multiple AWS accounts. By deploying a CloudFormation template in each AWS account, the necessary permissions and resource sharing for cross-account access can be automatically set up. This is an efficient way to collect CloudWatch data from multiple accounts, as it automates the setup.
Why selected: This option directly addresses the need for centralized monitoring and visualizing of data across AWS accounts with minimal operational overhead. It provides a secure and automated method of configuring cross-account access for CloudWatch.
Why rejected: None. This solution is the most efficient and recommended method for meeting the requirements.
B) Set up service control policies (SCPs) to provide access to CloudWatch in the monitoring account under the Organizations root organizational unit (OU).
Reasoning:
Service Control Policies (SCPs) are used to control access to AWS services within an AWS Organization, but they do not grant permissions for specific services. SCPs restrict what actions can be performed at the account or organizational unit level, but they do not provide direct permissions for querying or visualizing CloudWatch data ...
