Amazon Practice Questions, Discussions & Exam Topics by our Authors
A company has a data lake in Amazon S3 that needs to be accessed by hundreds of applications across many AWS accounts. The company's information security policy states that the S3 bucket must not be accessed over the public internet and that each application should have the minimum permissions necessary to function.
To meet these requirements, a solutions architect plans to use an S3 access ...
Let's evaluate each option to identify the steps required to meet the security and architectural requirements for securely providing access to the S3 bucket through S3 access points while maintaining the principle of least privilege.
Option A: Create an S3 access point for each application in the AWS account that owns the S3 bucket. Configure each access point to be accessible only from the application's VPC. Update the bucket policy to require access from an access point.
- Pros:
- S3 access points are specifically designed to provide access to S3 buckets in a controlled manner, with fine-grained control over who can access the data.
- By configuring each access point to be accessible only from the specific VPC of the application, the solution adheres to the requirement that the data must not be accessed over the public internet.
- The bucket policy can enforce that access to the bucket must come from the access point, providing an additional layer of security and ensuring that no direct access to the S3 bucket occurs from other sources.
- Cons:
- Slightly higher complexity in managing access points for each application. However, this complexity is manageable when the access control model is well-defined.
This option is correct because it aligns with the requirement of limiting access from specific VPCs and ensures minimal access permissions.
Option B: Create an interface endpoint for Amazon S3 in each application's VPC. Configure the endpoint policy to allow access to an S3 access point. Create a VPC gateway attachment for the S3 endpoint.
- Pros:
- Interface endpoints enable private access to S3 services from a VPC, avoiding public internet traffic.
- The endpoint policy can control access, allowing communication with the S3 access point.
- Cons:
- Interface endpoints are typically used for accessing AWS services via private IP addresses from within a VPC, but this is not necessary for accessing S3 in this scenario because the more appropriate solution would be to use gateway endpoints for S3.
- Using interface endpoints requires unnecessary complexity and cost compared to using gateway endpoints.
This option is rejected because gateway endpoints are simpler, more cost-effective, and specifically designed for services like S3.
Option C: Create a gateway endpoint for Amazon S3 in each application's VPC. Configure the endpoint policy to allow access to an S3 access point. Specify the route table that is used to access the access point.
- Pros:
- Gateway endpoints are the most efficient and cost-effective method for accessing S3 securely from within a VPC without going through the public internet.
- Endpoint policies can enforce fine-grained access control to the S3 access point, ensuring that only specific applications ...
Author: Olivia · Last updated May 13, 2026
A company has developed a hybrid solution between its data center and AWS. The company uses Amazon VPC and Amazon EC2 instances that send application logs to Amazon CloudWatch. The EC2 instances read data from multiple relational databases that are hosted on premises.
The company wants to monitor which EC2 instances are connected to the databases in near-real time. The company already has a monitoring soluti...
Let’s evaluate each of the options and determine which solution would best meet the company's requirements for monitoring EC2 instances' connections to on-premises databases and sending this networking traffic to Splunk in near-real time.
Option A: Enable VPC flow logs, and send them to CloudWatch. Create an AWS Lambda function to periodically export the CloudWatch logs to an Amazon S3 bucket by using the pre-defined export function. Generate ACCESS_KEY and SECRET_KEY AWS credentials. Configure Splunk to pull the logs from the S3 bucket by using those credentials.
- Pros:
- VPC flow logs capture network traffic between EC2 instances and databases, which is the information the company needs to monitor.
- Storing logs in Amazon S3 and configuring Splunk to pull logs can be a viable approach.
- Cons:
- Latency issues: This solution is not real-time, as it relies on periodic Lambda functions to export logs. This delays the data being sent to Splunk.
- Operational overhead: The Lambda function, manual management of credentials (ACCESS_KEY, SECRET_KEY), and frequent exports introduce more complexity.
- This approach does not fully align with the requirement for near-real-time monitoring.
This option is rejected because of the delays introduced by the periodic export and the complexity of managing credentials.
Option B: Create an Amazon Kinesis Data Firehose delivery stream with Splunk as the destination. Configure a pre-processing AWS Lambda function with a Kinesis Data Firehose stream processor that extracts individual log events from records sent by CloudWatch Logs subscription filters. Enable VPC flow logs, and send them to CloudWatch. Create a CloudWatch Logs subscription that sends log events to the Kinesis Data Firehose delivery stream.
- Pros:
- Near-real-time processing: This option allows near-real-time streaming of data from CloudWatch Logs to Splunk through Kinesis Data Firehose.
- The Lambda function preprocesses log events, making them ready to be sent to Splunk.
- Kinesis Data Firehose allows direct delivery to Splunk, ensuring efficient log management.
- Cons:
- Additional configuration is required for Lambda and CloudWatch Logs subscription filters, which might add complexity but not significantly.
This option is chosen because it allows near-real-time monitoring and delivers logs efficiently to Splunk with minimal delay.
Option C: Ask the company to log every...
Author: MysticJaguar44 · Last updated May 13, 2026
A company has five development teams that have each created five AWS accounts to develop and host applications. To track spending, the development teams log in to each account every month, record the current cost from the AWS Billing and Cost Management console, and provide the information to the company's finance team.
The company has strict compliance requirements and needs to ensure that resources are created only in AWS Regions in the United States. However, some resources have been created in other Regions.
A solutions architect needs to implement a solution that gives the finance team the ability to track an...
Key Requirements:
1. Consolidated Billing: The fice team needs a consolidated view of expenditures across multiple AWS accounts.
2. Compliance for Resource Creation: The company needs to ensure that resources are created only in AWS Regions within the United States.
3. Operational Efficiency: The solution must minimize manual effort, provide automation, and ensure the governance and compliance are enforced effectively.
Solution Analysis:
A) Create a new account to serve as a management account. Create an Amazon S3 bucket for the fice team. Use AWS Cost and Usage Reports to create monthly reports and store the data in the fice team's S3 bucket.
- Pros:
- AWS Cost and Usage Reports provide a detailed breakdown of costs, which can be stored in an S3 bucket and shared with the fice team.
- Consolidated cost tracking is made possible through AWS Cost and Usage Reports.
- Cons:
- This approach would require the fice team to manually download and analyze cost data from the S3 bucket.
- It does not provide automated cost analysis or an easy-to-use interface for ongoing tracking.
Reason for rejection: While it provides consolidated billing reports, it lacks automation and efficiency for ongoing monitoring, making it a less optimal choice compared to other solutions.
B) Create a new account to serve as a management account. Deploy an organization in AWS Organizations with all features enabled. Invite all the existing accounts to the organization. Ensure that each account accepts the invitation.
- Pros:
- AWS Organizations with all features enabled allows for consolidated billing across multiple accounts.
- It provides a centralized way to manage billing and track expenses without the need for separate reporting from each account.
- Cons:
- While this is a necessary step for consolidated billing, it doesn't directly address the issue of ensuring resources are created only in approved regions.
Reason for rejection: This is an important first step, but on its own, it doesn’t solve the issue of enforcing regional restrictions for resource creation.
C) Create an OU that includes all the development teams. Create an SCP that allows the creation of resources only in Regions that are in the United States. Apply the SCP to the OU.
- Pros:
- Service Control Policies (SCPs) in AWS Organizations are powerful for enforcing specific rules across AWS accounts.
- Allowing only specific regions ensures that resources are created only in the United States, helping meet compliance requirements.
- Cons:
- The policy needs to be configured in such a way that it specifically allows the U.S. regions, which may not always be straightforward to enforce effectively.
Reason for rejection: The SCP approach for explicitly allowing resources in only certain regions is a bit restrictive and could lead to confusion or oversight if regions need to be updated or expanded in the future. Explicitly denying regions outside the United States is more effective.
D) Create an OU that includes all the developme...
Author: Mia · Last updated May 13, 2026
A company needs to create and manage multiple AWS accounts for a number of departments from a central location. The security team requires read-only access to all accounts from its own AWS account. The company is using AWS Organizations and...
In order to meet the requirements of providing the security team with read-only access to all AWS accounts in the organization, we need to consider each option and evaluate its viability based on key factors such as central management, simplicity, security, and scalability. Let’s break down each option:
Option A: Use the OrganizationAccountAccessRole IAM role to create a new IAM policy with read-only access in each member account. Establish a trust relationship between the IAM policy in each member account and the security account. Ask the security team to use the IAM policy to gain access.
- Pros: This option creates read-only access via an IAM policy within each account. It enables centralized management of access through IAM roles, but it introduces some complexity by requiring separate trust relationships and policies to be set up in every member account.
- Cons: Managing policies in every member account could become tedious, especially as the organization grows, because each account would need to have its own trust relationship and IAM policies. This introduces a scalability problem and increases the administrative overhead.
Option B: Use the OrganizationAccountAccessRole IAM role to create a new IAM role with read-only access in each member account. Establish a trust relationship between the IAM role in each member account and the security account. Ask the security team to use the IAM role to gain access.
- Pros: This approach is very similar to Option A but uses IAM roles rather than IAM policies. This could be simpler because IAM roles can be centrally managed, and the security team can assume the role in each account.
- Cons: While roles are better suited for cross-account access, having to manually set up these roles and manage the trust relationship in each member account still introduces complexity and can create issues as the organization scales. Additionally, creating read-only access roles in each member account is still somewhat cumbersome.
Option C: Ask the security team to use AWS Security Token Service (AWS STS) to call the AssumeRole API for the OrganizationAccountAccessRole IAM role in the management account from the security account. Use the generated temporary credentials to gain access.
- Pros: AWS STS and the AssumeRole API are designed for cross-account access and temporary credentials, making this approach highly flexible and secure. The security team ca...
Author: CrimsonViperX · Last updated May 13, 2026
A large company runs workloads in VPCs that are deployed across hundreds of AWS accounts. Each VPC consists of public subnets and private subnets that span across multiple Availability Zones. NAT gateways are deployed in the public subnets and allow outbound connectivity to the internet from the private subnets.
A solutions architect is working on a hub-and-spoke design. All private subnets in the spoke VPCs must route traffic to the internet through an egress V...
To meet the requirement of routing traffic from the private subnets of spoke VPCs to the internet through an egress VPC, let's break down the options based on scalability, ease of management, and the overall design of the network:
Option A: Create peering connections between the egress VPC and the spoke VPCs. Configure the required routing to allow access to the internet.
- Analysis: While VPC peering can work for connecting the egress VPC to the spoke VPCs, this approach becomes less scalable when there are hundreds of spoke VPCs. Peering each spoke VPC with the egress VPC would require a large number of peering connections, and VPC peering has limitations, such as not supporting transitive routing. This would lead to complex network configurations as the number of VPCs increases.
- Rejected: Scalable solution with VPC peering is impractical for large numbers of VPCs.
Option B: Create a transit gateway, and share it with the existing AWS accounts. Attach existing VPCs to the transit gateway. Configure the required routing to allow access to the internet.
- Analysis: A Transit Gateway (TGW) is designed for large-scale architectures with multiple VPCs. It allows for easier, centralized management of routing between VPCs. By connecting the spoke VPCs to a transit gateway, and routing traffic through the egress VPC, the solution provides a scalable and manageable approach to handle internet access from multiple spoke VPCs. The central transit gateway can act as a hub, simplifying routing management compared to VPC peering.
- The transit gateway supports transitive routing, meaning that the spoke VPCs don't need to be directly peered with each other but can route traffic through the transit gateway to the egress VPC.
- Transit Gateway also scales much better than VPC peering, especially when dealing with hundreds of VP...
Author: Benjamin · Last updated May 13, 2026
An education company is running a web application used by college students around the world. The application runs in an Amazon Elastic Container Service (Amazon ECS) cluster in an Auto Scaling group behind an Application Load Balancer (ALB). A system administrator detects a weekly spike in the number of failed login attempts, which overwhelm the application's authentication service. All the failed login attempts originate from about 500 different IP addresses that ch...
To prevent the failed login attempts from overwhelming the authentication service, the key challenge is to efficiently block traffic from a large number of IP addresses that change weekly. The solution must be operationally efficient, scalable, and capable of automatically adapting to these weekly changes in IP addresses.
Let's evaluate the options:
Option A: Use AWS Firewall Manager to create a security group and security group policy to deny access from the IP addresses.
- Analysis: AWS Firewall Manager helps you manage security policies at scale across multiple accounts. However, managing security group rules for 500 dynamically changing IP addresses on a weekly basis would require constant updates and manual intervention, which is not operationally efficient. Security groups are more effective for controlling traffic at the instance level and are not designed to handle large numbers of dynamically changing IP addresses effectively.
- Rejected: This option requires too much manual intervention and is not ideal for dynamic IP blocking.
Option B: Create an AWS WAF web ACL with a rate-based rule, and set the rule action to Block. Connect the web ACL to the ALB.
- Analysis: AWS WAF (Web Application Firewall) with a rate-based rule is a great fit for this scenario. A rate-based rule can automatically block IP addresses that exceed a certain threshold of requests in a given time window (e.g., 5 requests per second). This would effectively block the IP addresses involved in the failed login attempts and prevent them from overwhelming the authentication service. Since the IP addresses change weekly, WAF's rate-based rules can dynamically handle the incoming traffic without requiring constant updates to ...
Author: FrostFalcon88 · Last updated May 13, 2026
A company operates an on-premises software-as-a-service (SaaS) solution that ingests several files daily. The company provides multiple public SFTP endpoints to its customers to facilitate the file transfers. The customers add the SFTP endpoint IP addresses to their firewall allow list for outbound traffic. Changes to the SFTP endpoint IP addresses are not permitted.
The...
Let's evaluate each option based on the requirement to migrate the on-premises software-as-a-service (SaaS) solution to AWS, decrease operational overhead for file transfers, and ensure that the customer IP addresses for outbound traffic do not change.
Option A: Register the customer-owned block of IP addresses in the company's AWS account. Create Elastic IP addresses from the address pool and assign them to an AWS Transfer for SFTP endpoint. Use AWS Transfer to store the files in Amazon S3.
- Analysis: AWS Transfer for SFTP is a managed service that allows you to host SFTP endpoints with minimal operational overhead. By registering the customer-owned block of IP addresses, the company can associate these IPs with Elastic IPs and bind them to the AWS Transfer for SFTP endpoint. This allows customers to continue using the same IP addresses they have added to their firewall allow list. The files would be stored in Amazon S3, which is a scalable and managed storage service, reducing the need to manage the storage infrastructure. This option fits well with the requirement of migrating the service to AWS with reduced operational overhead.
- Selected: This solution directly meets the requirements by allowing a seamless transition to a managed SFTP service while retaining the required static IPs and reducing operational overhead.
Option B: Add a subnet containing the customer-owned block of IP addresses to a VPC. Create Elastic IP addresses from the address pool and assign them to an Application Load Balancer (ALB). Launch EC2 instances hosting FTP services in an Auto Scaling group behind the ALB. Store the files in attached Amazon Elastic Block Store (Amazon EBS) volumes.
- Analysis: While this approach allows you to maintain control over the IP addresses and use EC2 instances for FTP services, it introduces significant operational overhead. Managing EC2 instances for hosting FTP services, Auto Scaling groups, and EBS volumes for storage requires manual intervention for scaling, monitoring, patching, and management. Additionally, FTP is not as efficient or secure as SFTP. This solution increases the...
Author: Zara · Last updated May 13, 2026
A company has a new application that needs to run on five Amazon EC2 instances in a single AWS Region. The application requires high-throughput, low-latency network connections between all of the EC2 instances where the application will run. There ...
To determine the best solution for the given requirements—high-throughput, low-latency network connections between EC2 instances without the need for fault tolerance—we need to carefully evaluate each option:
Option A: Launch five new EC2 instances into a cluster placement group. Ensure that the EC2 instance type supports enhanced networking.
- Analysis: A cluster placement group is designed to place EC2 instances physically close to one another in the same Availability Zone (AZ), which provides low-latency, high-throughput network performance between the instances. Enhanced networking (e.g., using Elastic Network Adapter - ENA) further improves network performance. This solution is ideal for applications requiring high-throughput, low-latency networking, and since fault tolerance is not a requirement, this option fits well.
- Selected: This option is optimal because the cluster placement group ensures the high-throughput, low-latency connectivity required by the application.
Option B: Launch five new EC2 instances into an Auto Scaling group in the same Availability Zone. Attach an extra elastic network interface to each EC2 instance.
- Analysis: While an Auto Scaling group provides automatic scaling capabilities, the solution doesn’t directly address the need for high-throughput, low-latency networking between the instances. Adding extra network interfaces might improve network availability but doesn't guarantee the low-latency, high-throughput requirements. Moreover, an Auto Scaling group is typically used for scalability and fault tolerance, which isn't necessary in this scenario.
- Rejected: This option does not meet th...
Author: Max · Last updated May 13, 2026
A company is creating a REST API to share information with six of its partners based in the United States. The company has created an Amazon API Gateway Regional endpoint. Each of the six partners will access the API once per day to post daily sales figures.
After initial deployment, the company observes 1,000 requests per second originating from 500 different IP addresses around the world. Th...
Let's analyze the options one by one based on the company's need to secure its API and minimize cost, while addressing the observed botnet traffic.
Option A:
- Create an Amazon CloudFront distribution with the API as the origin.
- CloudFront can help distribute content and serve as a content delivery network (CDN), which improves performance but doesn’t necessarily address the botnet traffic.
- Create an AWS WAF web ACL with a rule to block clients that submit more than five requests per day.
- This is a good approach for limiting bot traffic, but setting the limit to five requests per day may be too restrictive for legitimate traffic, as each of the six partners will make one request per day.
- Associate the web ACL with the CloudFront distribution.
- This ensures the traffic is filtered before reaching the API Gateway.
- Configure CloudFront with an origin access identity (OAI) and associate it with the distribution.
- OAI ensures that CloudFront is the only service allowed to access the API Gateway directly.
- Configure API Gateway to ensure only the OAI can run the POST method.
- This adds a layer of security by ensuring that only CloudFront can make requests to the API.
Issue: The key issue here is that the restriction of five requests per day might be too low for legitimate users (the partners). The company's partners will be posting daily, so they will likely exceed this limit.
---
Option B:
- Create an Amazon CloudFront distribution with the API as the origin.
- Same as Option A, CloudFront provides caching and CDN capabilities but doesn't directly address the botnet issue.
- Create an AWS WAF web ACL with a rule to block clients that submit more than five requests per day.
- Same issue as in Option A: five requests per day might block legitimate requests from the partners.
- Add a custom header to the CloudFront distribution populated with an API key.
- This adds an extra layer of authentication by requiring an API key, which could help identify the partners.
- Configure the API to require an API key on the POST method.
- This ensures that only clients with the correct API key can post data.
Issue: The same limitation of five requests per day for legitimate users applies here. Also, the API key could be effective but doesn't necessarily prevent botnet traffic if the bots are able to mimic legitimate API calls.
---
Option C:
- Create an AWS WAF web ACL with a rule to allow access to the IP addresses used by the six partners.
- This is an effective way to allow traffic only from the kno...
Author: Ella · Last updated May 13, 2026
A company uses an Amazon Aurora PostgreSQL DB cluster for applications in a single AWS Region. The company's database team must monitor all data activi...
To monitor all data activity on an Amazon Aurora PostgreSQL DB cluster, the company needs a solution that enables detailed logging and analysis of database operations. Let's break down each option to evaluate how it addresses the goal:
Option A: Set up an AWS Database Migration Service (AWS DMS) change data capture (CDC) task. Specify the Aurora DB cluster as the source. Specify Amazon Kinesis Data Firehose as the target. Use Kinesis Data Firehose to upload the data into an Amazon OpenSearch Service cluster for further analysis.
- Pros: This solution leverages AWS DMS for change data capture (CDC), which allows you to capture changes in the database. Kinesis Data Firehose can stream the data into Amazon OpenSearch Service, which is a powerful tool for analyzing and visualizing log data.
- Cons: While this option could work for tracking changes, OpenSearch might not be the best tool for directly monitoring database activity in a highly detailed manner. It is better suited for log data analysis and may require additional setup and maintenance for database activity monitoring.
Option B: Start a database activity stream on the Aurora DB cluster to capture the activity stream in Amazon EventBridge. Define an AWS Lambda function as a target for EventBridge. Program the Lambda function to decrypt the messages from EventBridge and to publish all database activity to Amazon S3 for further analysis.
- Pros: Aurora's database activity stream is a built-in feature designed specifically for capturing detailed database activity, including reads, writes, and other database operations. Integrating with Amazon EventBridge provides flexibility in handling these events, and using Lambda allows for customized processing (e.g., decrypting and storing the activity data in S3).
- Cons: This option requires additional development work to program the Lambda function and manage S3 storage. While it’s flexible, it may be more complex compared to other options that provide more streamlined data collection and analysis.
Option C: Start a database activity stream on the Aurora DB cluster to push the activity stream to an Amazon Kinesis data stream. Configure Amazon Kinesis Data Firehose to consume t...
Author: Chloe · Last updated May 13, 2026
An entertainment company recently launched a new game. To ensure a good experience for players during the launch period, the company deployed a static quantity of 12 r6g.16xlarge (memory optimized) Amazon EC2 instances behind a Network Load Balancer. The company's operations team used the Amazon CloudWatch agent and a custom metric to include memory utilization in its monitoring strategy.
Analysis of the CloudWatch metrics from the launch period showed consumption at about one quarter of the CPU and memory that the company expected. Initial demand for the game has subsided and has become more variable. The company decides t...
To meet the requirements of dynamically scaling the instance fleet based on varying demand while also being cost-effective, let's analyze each option.
Key Points to Consider:
1. Instance Type Selection: The company is monitoring both CPU and memory utilization, so it's essential to choose an instance type that balances cost with the resources (memory and CPU) needed by the game.
2. Cost-Effectiveness: The company aims to be cost-effective after the initial period, so scaling down the number of instances when demand is lower should be prioritized.
3. Auto Scaling Configuration: The minimum, desired, and maximum capacity must be chosen carefully to allow flexibility but not over-provision resources.
---
Option A: c6g.4xlarge (compute optimized) instances
- Instance Type: `c6g.4xlarge` are compute optimized instances, which means they are more suited for applications that require a lot of CPU resources relative to memory. Since the game seems to be memory-intensive (based on the initial use of memory-optimized instances), switching to compute-optimized instances would likely result in suboptimal performance, as they may not have enough memory to handle the workload.
- Capacity Configuration: The Auto Scaling configuration of a minimum of 3, desired of 3, and maximum of 12 makes sense in terms of scaling, but using compute-optimized instances does not align well with the company's observed requirements for memory, which would likely lead to inefficient performance.
Why it's rejected: The choice of `c6g.4xlarge` would be inefficient given that the game likely requires more memory than compute power, leading to potential performance issues.
---
Option B: m6g.4xlarge (general purpose) instances
- Instance Type: `m6g.4xlarge` instances are general purpose, providing a balanced ratio of CPU and memory. This option could work well if the game required a balance of CPU and memory, but based on the company's initial use of memory-optimized `r6g` instances, it's likely that the game’s workload is more memory-intensive. Switching to general-purpose instances could lead to suboptimal performance in terms of memory capacity.
- Capacity Configuration: As with Option A, this configuration allows for flexibility in scaling, but the instance type is not the most optimal choice for a memory-heavy application.
Why it's rejected: While ...
Author: Joseph · Last updated May 13, 2026
A financial services company loaded millions of historical stock trades into an Amazon DynamoDB table. The table uses on-demand capacity mode. Once each day at midnight, a few million new records are loaded into the table. Application read activity against the table happens in bursts throughout the day. and a limited set of keys are repeatedly loo...
To address the company's needs of reducing costs associated with DynamoDB while handling millions of records and periodic application read bursts, let's evaluate each option carefully. Key factors include the need to handle burst read activity, optimize costs, and reduce dependency on on-demand capacity mode.
Option A: Deploy an Amazon ElastiCache cluster in front of the DynamoDB table
- Use Case: Amazon ElastiCache (either Redis or Memcached) is a caching solution designed to store frequently accessed data in memory to reduce load on databases, which can speed up response times for read-heavy applications.
- How it helps: Caching repetitive queries can reduce DynamoDB read traffic, leading to cost savings. By caching the most frequently accessed keys, it offloads the read pressure from DynamoDB.
- Why it might be rejected: While this could save costs on DynamoDB read requests, managing a separate ElastiCache instance introduces extra complexity. Additionally, this approach doesn’t directly optimize DynamoDB capacity pricing, as the underlying DynamoDB table still operates on on-demand capacity mode, which can be costly for large-scale data loads. The setup requires maintaining synchronization between DynamoDB and ElastiCache, which adds overhead.
Why it’s rejected: While it can help with read-heavy applications, it doesn’t directly address the cost reduction of DynamoDB itself and requires additional complexity and management.
---
Option B: Deploy DynamoDB Accelerator (DAX). Configure DynamoDB auto scaling. Purchase Savings Plans in Cost Explorer
- DAX: DynamoDB Accelerator (DAX) is a managed in-memory cache for DynamoDB. It can significantly speed up response times for read-heavy workloads and reduce the load on the main DynamoDB table.
- Auto Scaling: DynamoDB auto-scaling automatically adjusts the read and write capacity based on usage, helping to optimize costs.
- Savings Plans: Purchasing DynamoDB Savings Plans can help lock in discounted rates for DynamoDB usage, leading to reduced costs over time.
Why it’s a strong candidate: DAX would help reduce read latency and offload traffic from the DynamoDB table. The combination of DAX and auto-scaling ensures that DynamoDB adjusts dynamically to the workload, reducing costs during low-demand periods while maintaining performance during bursts. Savings Plans further optimize costs.
Why it might be rejected: The main disadvantage is that this solution might still require high operational overhea...
Author: SolarFalcon11 · Last updated May 13, 2026
A company is creating a centralized logging service running on Amazon EC2 that will receive and analyze logs from hundreds of AWS accounts. AWS PrivateLink is being used to provide connectivity between the client services and the logging service.
In each AWS account with a client, an interface endpoint has been created for the logging service and is available. The logging service running on EC2 instances with a Network Load Balancer (NLB) are ...
To resolve the issue of clients being unable to submit logs using the VPC endpoint to the centralized logging service, let's break down the possible steps needed to ensure proper connectivity and security settings. The problem revolves around ensuring that the network traffic is correctly routed and allowed between the interface endpoints, Network Load Balancer (NLB), and EC2 instances hosting the logging service.
Key Considerations:
- AWS PrivateLink enables communication between services in different VPCs over private connections.
- NACL (Network Access Control List) and security groups control traffic flow at different layers, and both need to be configured correctly.
- NLB must be set up to allow traffic from the VPC endpoint.
- EC2 instances running the logging service need to accept traffic from the NLB and interface endpoints.
---
Option A: Check that the NACL is attached to the logging service subnet to allow communications to and from the NLB subnets. Check that the NACL is attached to the NLB subnet to allow communications to and from the logging service subnets running on EC2 instances.
- Reasoning: NACLs are a stateless layer of security, so both inbound and outbound rules must be configured properly to allow the necessary traffic between subnets.
- For logging service subnet (EC2 instances): The NACL must allow traffic from the NLB's subnet.
- For NLB subnet: The NACL must allow traffic from the logging service EC2 subnet.
- Why it's selected: Properly configured NACLs ensure that network traffic flows between the logging service and the clients via the NLB. This is an essential step in ensuring that the VPC endpoint can successfully send traffic to the logging service through the NLB.
Why the other options are rejected:
- Without properly configured NACLs, even if the security groups are correctly configured, the network-level traffic might be blocked, causing the issue.
---
Option B: Check that the NACL is attached to the logging service subnets to allow communications to and from the interface endpoint subnets. Check that the NACL is attached to the interface endpoint subnet to allow communications to and from the logging service subnets running on EC2 instances.
- Reasoning: While NACLs are necessary, focusing specifically on allowing traffic to/from the interface endpoint subnet isn't a comprehensive solution because the NACL configuration described in Option A already takes care of both NLB and EC2 communication.
- Why it's rejected: The issue isn’t limited to communication between the VPC endpoint and the logging service subnet but involves the NLB...
Author: Ella · Last updated May 13, 2026
A company has millions of objects in an Amazon S3 bucket. The objects are in the S3 Standard storage class. All the S3 objects are accessed frequently. The number of users and applications that access the objects is increasing rapidly. The objects are encrypted with server-side encryption with AWS KMS keys (SSE-KMS).
A solutions architect reviews the company's monthly AWS invoice and notices that AWS KMS costs are increasing because of the high number of...
Analyzing the Options:
Option A: Create a new S3 bucket with SSE-C encryption
- Explanation: Server-Side Encryption with Customer-Provided Keys (SSE-C) requires you to manage your own encryption keys. This option increases operational overhead, as you would need to handle and rotate the encryption keys manually. Additionally, AWS KMS costs are eliminated, but there are other challenges with this approach, such as key management, access control, and possible operational complexity in integrating SSE-C with applications that are already using SSE-KMS.
- Why it’s not optimal: This adds complexity to key management and does not directly address the main issue of rising AWS KMS costs while maintaining compatibility with existing encryption features. It also requires significant changes to how encryption is handled.
Option B: Create a new S3 bucket with SSE-S3 encryption
- Explanation: Server-Side Encryption with Amazon S3-managed keys (SSE-S3) eliminates the need for AWS KMS, reducing the KMS-related costs. You can use S3 Batch Operations to copy the objects from the old bucket to the new bucket with SSE-S3 encryption. SSE-S3 is fully managed by AWS, meaning you do not need to manage encryption keys directly. This option reduces operational overhead significantly while also reducing the AWS KMS cost.
- Why it’s a good choice: SSE-S3 is easy to implement, with minimal changes to the existing application. It addresses the cost issue by removing the dependence on AWS KMS for key management, while still offering encryption and security. Since the S3 Standard storage class is still used, object access remains fast.
Option C: Use AWS CloudHSM to store encryption keys
- Explanation: AWS CloudHSM offers hardware-based key storage a...
Author: Ming · Last updated May 13, 2026
A media storage application uploads user photos to Amazon S3 for processing by AWS Lambda functions. Application state is stored in Amazon DynamoDB tables. Users are reporting that some uploaded photos are not being processed properly. The application developers trace the logs and find that Lambda is experiencing photo processing issues when thousands of users upload photos simultaneously. The issues are the result of Lambda concurrency limits an...
Analyzing the Options:
Option A: Evaluate and adjust the RCUs (Read Capacity Units) for the DynamoDB tables
- Explanation: Read Capacity Units (RCUs) in DynamoDB determine how much data can be read from the database per second. If your application is experiencing issues when multiple users upload photos simultaneously, adjusting RCUs might help address throttling issues that occur due to insufficient read capacity when accessing DynamoDB data. However, the problem in the application seems more related to Lambda concurrency and the overall write-heavy load on DynamoDB rather than insufficient reads.
- Why it's not the best choice: Since the issue appears to be more related to Lambda concurrency limits and DynamoDB write throughput, increasing RCUs (read capacity) alone won't directly resolve the problem, especially if the main issue is with writes and processing bottlenecks.
Option B: Evaluate and adjust the WCUs (Write Capacity Units) for the DynamoDB tables
- Explanation: Write Capacity Units (WCUs) in DynamoDB determine how much data can be written to the database per second. If Lambda functions are writing large amounts of data to DynamoDB (such as after processing user photos), insufficient WCUs could result in throttling. Increasing the WCUs would improve the system’s ability to handle more concurrent writes.
- Why it's a good choice: If the performance bottleneck is occurring due to insufficient write throughput to DynamoDB (as might be the case with multiple simultaneous photo uploads), adjusting the WCUs to meet the write demands could increase the overall performance and reliability of the application.
Option C: Add an Amazon ElastiCache layer to increase the performance of Lambda functions
- Explanation: Amazon ElastiCache is a service that provides an in-memory data store. It can be used to cache frequently accessed data to reduce load on databases. However, it doesn’t directly address the issue at hand, which is Lambda concurrency and DynamoDB performance during high traffic (simultaneous photo uploads).
- Why it's not optimal: While ElastiCache could improve performance in some use cases (like reducing database read load), the primary issue here is related to Lambda concurrency and DynamoDB write throughput, not caching frequen...
Author: Siddharth · Last updated May 13, 2026
A company runs an application in an on-premises data center. The application gives users the ability to upload media files. The files persist in a file server. The web application has many users. The application server is overutilized, which causes data uploads to fail occasionally. The company frequently adds new storage to the file server. The company wants to resolve these challenges by migrating the application to AWS.
Users from across the United States and Canada access the application. Only authenticated users should have the ability to access the ...
Analyzing the Options:
Option A: Use AWS Application Migration Service to migrate the application server to Amazon EC2 instances
- Explanation: This option suggests migrating the application as-is to EC2 instances and setting up an Auto Scaling group for scaling the application. The files will be stored on Amazon S3, and Amazon Cognito will be used to handle user authentication.
- Why it’s not the best choice: While this option can work, it involves significant operational overhead. The need to refactor the application to store files in Amazon S3, along with the management of EC2 instances and scaling, increases complexity. The application also would need to be manually configured for fault tolerance, monitoring, and high availability. This approach is more suited for lift-and-shift migrations, which are not ideal for reducing operational overhead or accelerating development.
Option B: Use AWS Application Migration Service to migrate the application server to Amazon EC2 instances
- Explanation: Similar to Option A, this option involves migrating the application to EC2 instances and setting up Auto Scaling. AWS IAM Identity Center (formerly AWS Single Sign-On) is used for user authentication. The application is then refactored to use Amazon S3 for file storage.
- Why it’s not optimal: This option also involves migrating the application to EC2, which, while providing flexibility, still results in higher operational overhead. IAM Identity Center is typically used for centralized access management across AWS services, and while it can be used for authentication, it is not specifically tailored for web application user sign-ins compared to Amazon Cognito. Additionally, managing EC2 instances, scaling, and updates would still require considerable effort and resources.
Option C: Create a static website for uploads of media files
- Explanation: This option proposes a serverless architecture where AWS AppSync is u...
Author: Manish · Last updated May 13, 2026
A company has an application that is deployed on Amazon EC2 instances behind an Application Load Balancer (ALB). The instances are part of an Auto Scaling group. The application has unpredictable workloads and frequently scales out and in. The company's development team wants to analyze application logs to find ways to improve the application's performance. However, the logs ...
Analyzing the Options:
Option A: Enable access logs for the ALB. Store the logs in an Amazon S3 bucket.
- Explanation: Enabling access logs for the Application Load Balancer (ALB) will record all incoming requests to the load balancer, and these logs can be stored in an Amazon S3 bucket. While this helps capture detailed information about the requests and responses handled by the ALB, it doesn't provide visibility into the application-level logs. It only captures metadata like request paths, client IPs, and response status codes, but not the actual application logs generated on the EC2 instances.
- Why it’s not optimal: This option focuses on the network layer (ALB) and not the application logs on the EC2 instances. If the goal is to analyze application-level logs for performance improvements, the ALB access logs alone are insufficient because they don't contain the necessary application details.
Option B: Configure the EC2 instances to publish logs to Amazon CloudWatch Logs by using the unified CloudWatch agent.
- Explanation: This option involves configuring the EC2 instances to send their application logs to Amazon CloudWatch Logs. The CloudWatch agent can be used to publish both system and application logs, and because CloudWatch is a centralized service, it will retain the logs even after instances scale in or terminate. This ensures that logs are preserved independently of the lifecycle of the EC2 instances.
- Why it’s the best choice: By sending application logs to CloudWatch Logs, the logs are available after EC2 instances scale in, which resolves the issue of losing logs. CloudWatch Logs also integrates well with other AWS services for monitoring and analysis, making it an effective solution for tracking application performance. It is specifically designed for capturing logs that persist beyond the lifetime of EC2 instances, thus pro...
Author: Emma · Last updated May 13, 2026
A company runs an unauthenticated static website (www.example.com) that includes a registration form for users. The website uses Amazon S3 for hosting and uses Amazon CloudFront as the content delivery network with AWS WAF configured. When the registration form is submitted, the website calls an Amazon API Gateway API endpoint that invokes an AWS Lambda function to process the payload and forward the payload to an external API call.
During testing, a solutions architect encounters a cross-origin resource sha...
Analyzing the Options:
Option A: Change the CORS configuration on the S3 bucket. Add rules for CORS to the AllowedOrigin element for www.example.com.
- Explanation: This option suggests modifying the CORS configuration on the Amazon S3 bucket. The Access-Control-Allow-Origin header should be configured to allow requests from `www.example.com` to the S3 origin. Since the website is hosted on S3, enabling CORS at this level allows the browser to access the content from the S3 bucket.
- Why it might not be enough: This option only applies to direct access to static resources (e.g., images, CSS, or JavaScript files) hosted on S3. The CORS issue you're experiencing is likely occurring when the browser makes an HTTP request to the API Gateway, not directly to the S3 bucket. Therefore, changing the S3 CORS configuration wouldn't resolve the issue with API Gateway and Lambda functions.
Option B: Enable the CORS setting in AWS WAF. Create a web ACL rule in which the Access-Control-Allow-Origin header is set to www.example.com.
- Explanation: AWS WAF is a web application firewall that helps protect applications from common web exploits. However, AWS WAF is not designed to modify CORS headers. WAF is generally used for filtering malicious traffic and applying security rules, not for managing CORS headers in responses.
- Why it's not optimal: AWS WAF cannot be used to handle CORS headers directly. Modifying CORS headers is outside the scope of WAF's functionality, making this option inappropriate for solving the CORS error.
Option C: Enable the CORS setting on the API Gateway API endpoint. Ensure that the API endpoint is configured to return all responses that have the Access-Control-Allow-Origin header set to www.example.com.
- Explanation: Enabling CORS at the API Gateway level is the correct approach for API-related CORS issues. When an HTTP request is made from a different origin (in this case, from `www.example...
Author: Max · Last updated May 13, 2026
A company has many separate AWS accounts and uses no central billing or management. Each AWS account hosts services for different departments in the company. The company has a Microsoft Azure Active Directory that is deployed.
A solutions architect needs to centralize billing and management of the company's AWS accounts. The company wants to start using identity federation instead of manual user m...
To meet the requirements of centralizing billing and management, using identity federation, and utilizing temporary credentials, the following steps need to be taken:
Explanation of Options:
A) Create a new AWS account to serve as a management account. Deploy an organization in AWS Organizations. Invite each existing AWS account to join the organization. Ensure that each account accepts the invitation.
- Why it's selected: Creating a new management account and deploying AWS Organizations is essential for centralizing billing and management across multiple AWS accounts. AWS Organizations will allow the company to group all accounts, manage billing centrally, and enable consolidated billing. This is a fundamental step for managing multiple AWS accounts.
- Why others are rejected: Without AWS Organizations, billing and account management will remain decentralized, which contradicts the requirement of centralizing management.
B) Configure each AWS account's email address to be aws+@example.com so that account management email messages and invoices are sent to the same place.
- Why it's rejected: This step is related to email address configuration for management purposes, but it doesn't address centralizing billing or managing user access, nor does it support identity federation or temporary credentials.
C) Deploy AWS IAM Identity Center (AWS Single Sign-On) in the management account. Connect IAM Identity Center to the Azure Active Directory. Configure IAM Identity Center for automatic synchronization of users and groups.
- Why it's selected: AWS IAM Identity Center (formerly AWS Single Sign-On) can be used to implement identity federation and to synchronize users and groups from Azure Active Directory. This allows the company to manage users centrally and use temporary credentials instead of long-lived access keys. This meets the requirement of identity fed...
Author: ShadowWolf101 · Last updated May 13, 2026
A company wants to manage the costs associated with a group of 20 applications that are infrequently used, but are still business-critical, by migrating to AWS. The applications are a mix of Java and Node.js spread across different instance clusters. The company wants to minimize costs while standardizing by using a single deployment methodology.
Most of the applications are part of month-end processing routines with a small number of concurrent users, but they are occasionally run at other times. Average application memory consumption is less than 1 GB. though some applications...
To determine the most cost-effective solution for the company's requirements, we need to consider factors such as cost minimization, infrequent but business-critical usage, memory requirements, and the need to standardize on a single deployment methodology. Let's break down each option:
A) Deploy a separate AWS Lambda function for each application. Use AWS CloudTrail logs and Amazon CloudWatch alarms to verify completion of critical jobs.
- Why it's rejected: AWS Lambda is ideal for short-running, event-driven applications with low memory requirements. However, the applications in question may run for several hours, especially the billing report, which could exceed the maximum timeout limit for Lambda functions (15 minutes). Lambda is also not suited for applications that require more than 3 GB of memory, making it unsuitable for the higher memory applications in this scenario. Additionally, the billing application requires consistent, long-running processes that Lambda is not designed for.
B) Deploy Amazon ECS containers on Amazon EC2 with Auto Scaling configured for memory utilization of 75%. Deploy an ECS task for each application being migrated with ECS task scaling. Monitor services and hosts by using Amazon CloudWatch.
- Why it's selected: ECS with EC2 instances offers flexibility and cost control by running containerized applications on EC2 instances. This approach provides automatic scaling and can be configured to adjust resources based on the memory usage of the containers. ECS tasks are also well-suited for the Java and Node.js applications, especially when considering infrequent usage and the ability to scale containers as needed. ECS can also support applications that need more than 2.5 GB of memory, which makes it suitable for the billing application. The cost can be minimized by using EC2 spot instances or configuring the EC2 instances for optimal resource utilization. Additionally, ECS offers a unified, standardized deployment methodology across the applications.
C) Deploy AWS Elastic Beanstalk for each application with Auto Scaling to ensure that all requests have sufficient resources. Monitor each AWS Elastic Beanstalk deployment by using CloudWatch alarms.
- Why it's rejected: While Elastic Beanstalk offers an easy-to-manage solution for deploying applications with automatic scaling, it is ofte...
Author: IronLion88 · Last updated May 13, 2026
A solutions architect needs to review the design of an Amazon EMR cluster that is using the EMR File System (EMRFS). The cluster performs tasks that are critical to business needs. The cluster is running Amazon EC2 On-Demand Instances at all times for all task, primary, and core nodes. The EMR tasks run each morning, starting at 1:00 AM. and take 6 hours to finish running. The amount of time to complete the processing is not a priority because the data is not referenced until late...
To minimize compute costs for the Amazon EMR cluster while meeting the requirements, the solutions architect must consider several factors such as cost-effectiveness, instance availability, and the criticality of tasks. Let's analyze each option:
Option A: Launch all task, primary, and core nodes on Spot Instances in an instance fleet. Terminate the cluster, including all instances, when the processing is completed.
- Pros: Spot Instances offer significant cost savings compared to On-Demand Instances. Terminating the cluster after processing completes ensures no additional costs are incurred for idle resources.
- Cons: Spot Instances can be interrupted, and since the tasks are critical to business needs, this could lead to potential failures if instances are terminated unexpectedly. The processing time is not a priority, but the risk of interruptions still remains a factor for core and primary nodes.
- Scenario Fit: This solution would work if the processing was not time-sensitive and could handle interruptions, but the critical nature of the tasks makes it less ideal.
Option B: Launch the primary and core nodes on On-Demand Instances. Launch the task nodes on Spot Instances in an instance fleet. Terminate the cluster, including all instances, when the processing is completed. Purchase Compute Savings Plans to cover the On-Demand Instance usage.
- Pros: Using On-Demand Instances for the primary and core nodes ensures the reliability of critical nodes without interruption, while Spot Instances for task nodes help reduce costs. Compute Savings Plans provide additional cost savings for On-Demand Instances.
- Cons: While this minimizes costs for the task nodes, it does not take full advantage of Spot Instances for the entire cluster, especially for core and primary nodes. Compute Savings Plans also only help reduce costs for On-Demand Instances but do not address the cost of Spot Instance usage.
- Scenario Fit: This approach balances cost savings for task nodes with reliability for critical nodes, but it doesn't fully maximize cost savings as it still relies on On-Demand Instances for core and primary nodes.
Option C: Continue to launch all nodes on On-Demand Instances. Terminate the cluster, including all instances, when the processing is completed. Purchase Compute Savings Plans to cover the On-Demand Instance usage.
- Pros: This option simplifies the setup and ensures reliabilit...
Author: Aria · Last updated May 13, 2026
A company has migrated a legacy application to the AWS Cloud. The application runs on three Amazon EC2 instances that are spread across three Availability Zones. One EC2 instance is in each Availability Zone. The EC2 instances are running in three private subnets of the VPC and are set up as targets for an Application Load Balancer (ALB) that is associated with three public subnets.
The application needs to communicate with on-premises systems. Only traffic from IP addresses in the company's IP address range are allowed to access the on-premises systems. The company's security team is bringing only one IP address from its internal IP address range to the cloud. The company has added this IP address to the allow list for the company firewall...
Analyzing the Requirements:
The company has migrated a legacy application to AWS and needs to communicate with on-premises systems. Only traffic from the company's IP range is allowed to reach the on-premises systems. The company has set up an Elastic IP (EIP) to ensure secure communication between its cloud resources and on-premises systems, but the solution must be resilient to failures (automatic failover).
Breakdown of the Options:
A) Deploy three NAT gateways, one in each public subnet. Assign the Elastic IP address to the NAT gateways. Turn on health checks for the NAT gateways. If a NAT gateway fails a health check, recreate the NAT gateway and assign the Elastic IP address to the new NAT gateway.
- Why it's rejected: Although using multiple NAT gateways in different Availability Zones (AZs) for high availability is a good practice, this option requires manual intervention if a NAT gateway fails. The solution mentions recreating the NAT gateway and assigning the Elastic IP, which is not automatic in AWS. Additionally, if you use a single Elastic IP, it can't be reassigned across multiple NAT gateways seamlessly without manual intervention or additional configuration. This approach doesn't fully meet the requirement of automatic failure recovery.
B) Replace the ALB with a Network Load Balancer (NLB). Assign the Elastic IP address to the NLB. Turn on health checks for the NLB. In the case of a failed health check, redeploy the NLB in different subnets.
- Why it's rejected: NLBs are designed for routing traffic at the network layer and can be assigned an Elastic IP, but this option requires manual redeployment of the NLB in case of failure. It would involve downtime while the NLB is redeployed and would not provide an automatic failover mechanism. Additionally, the main purpose of the NLB is to route traffic between clients and application instances, not necessarily for enabling communication with on-premises systems (which is the priority here). Thus, it doesn't meet the full requirements for secure communication with the on-premises systems.
C)...
Author: Madison · Last updated May 13, 2026
A company uses AWS Organizations to manage more than 1,000 AWS accounts. The company has created a new developer organization. There are 540 developer member accounts that must be moved to the new developer organization. All accounts are set up with all the required information so that each account can be operated as a standalone account.
W...
To move all 540 developer accounts to the new developer organization, let's evaluate each option based on the AWS Organizations functionality and the requirements for managing large-scale account migration.
A) Call the MoveAccount operation in the Organizations API from the old organization's management account to migrate the developer accounts to the new developer organization.
- Why it's rejected: The MoveAccount operation is not available in the AWS Organizations API. AWS Organizations does not allow the direct movement of accounts between organizations using a single operation. Instead, accounts need to be invited to join the new organization or removed and then invited to the new organization, as outlined in other steps. Therefore, this option is not valid.
B) From the management account, remove each developer account from the old organization using the RemoveAccountFromOrganization operation in the Organizations API.
- Why it's selected: The RemoveAccountFromOrganization operation is part of the AWS Organizations API. To move an account to a new organization, it must first be removed from the old organization. This is a key step in the migration process. After removal, the account can then be invited to the new organization. This step is a necessary part of the migration process for each account.
C) From each developer account, remove the account from the old organization using the RemoveAccountFromOrganization operation in the Organizations API.
- Why it's rejected: Removing an account from an organization requires administrative privileges in the organization's management account, not from the account itself. Therefore, a developer account cannot remove itself from the organization. This operation should be done by the management account, not the individual developer accounts. Thus, this option is not applicable.
D) Sign in to the new developer organization's management account and create a placeholder member account that acts as a target for the developer account migration.
- Why it's rejected: Creating a placeholder account is ...
Author: Zara · Last updated May 13, 2026
A company's interactive web application uses an Amazon CloudFront distribution to serve images from an Amazon S3 bucket. Occasionally, third-party tools ingest corrupted images into the S3 bucket. This image corruption causes a poor user experience in the application later. The company has successfully implemented and tested Python logic to detect corrupt images.
A solutions archit...
To address the issue of corrupted images being served from the S3 bucket, the solution must ensure that the image corruption is detected quickly and efficiently after ingestion, with minimal latency between the ingestion and serving. The following are key considerations for each option:
Option A: Use a Lambda@Edge function that is invoked by a viewer-response event.
- How it works: Lambda@Edge is a service that allows you to run functions at CloudFront edge locations. The viewer-response event is triggered when CloudFront is preparing to send a response to the client (i.e., when it’s about to serve the image).
- Pros: This approach integrates directly with CloudFront, ensuring that the user gets the response as soon as possible. If the image is corrupted, the Lambda function can intercept the response and take action (e.g., serving a placeholder image).
- Cons: This approach does not address the issue of detecting the corruption right when the image is ingested into the S3 bucket. The corruption check would happen too late in the process, as it would only occur when the user requests the image.
Option B: Use a Lambda@Edge function that is invoked by an origin-response event.
- How it works: This event is triggered when CloudFront receives a response from the origin (in this case, the S3 bucket). It is similar to the viewer-response event but happens earlier in the request-response cycle.
- Pros: The Lambda@Edge function can check the image as it comes from the S3 bucket before serving it to the user. This allows for some handling of the corrupted images at the CloudFront edge location.
- Cons: While it’s closer to the ingestion point than Option A, it still does not prevent the issue from being present in the S3 bucket initially. Additionally, this approach still doesn’t directly prevent corrupted images from being uploaded or detected immediately after ingestion.
Option C: Use an S3 event notification that invokes an AWS Lambda function.
- How it works: This approach uses S3 event notifications to trigger a Lambda function immediately after an image is uploaded to the S3 bucket. The Lambda function can run the ...
Author: Krishna · Last updated May 13, 2026
A company has an application that runs on Amazon EC2 instances in an Amazon EC2 Auto Scaling group. The company uses AWS CodePipeline to deploy the application. The instances that run in the Auto Scaling group are constantly changing because of scaling events.
When the company deploys new application code versions, the company installs the AWS CodeDeploy agent on any new target EC2 instances and associates the instances with the CodeDeploy deployment group. ...
To address the deployment process for an application running on Amazon EC2 instances in an Auto Scaling group, we need to minimize operational overhead, ensure automation, and account for the dynamic nature of the EC2 instances (as they change due to scaling events). Let's evaluate each option:
Option A: Configure Amazon EventBridge to invoke an AWS Lambda function when a new EC2 instance is launched into the Auto Scaling group. Code the Lambda function to associate the EC2 instances with the CodeDeploy deployment group.
- How it works: This option involves setting up an EventBridge rule to trigger a Lambda function when new EC2 instances are launched in the Auto Scaling group. The Lambda function will then associate the new instances with the CodeDeploy deployment group.
- Pros: This approach automates the process of associating new instances with the CodeDeploy deployment group as they are launched. It works well in dynamic environments where EC2 instances are frequently changing due to scaling events.
- Cons: While this automation ensures that new instances are associated with the deployment group, it requires writing custom Lambda functions and managing event-driven workflows. This introduces some complexity, and operational overhead might increase with custom Lambda code management.
Option B: Write a script to suspend Amazon EC2 Auto Scaling operations before the deployment of new code. When the deployment is complete, create a new AMI and configure the Auto Scaling group's launch template to use the new AMI for new launches. Resume Amazon EC2 Auto Scaling operations.
- How it works: This option involves suspending the Auto Scaling process, deploying the new code, creating a new AMI with the updated code, updating the Auto Scaling group's launch template to use the new AMI, and then resuming Auto Scaling operations.
- Pros: This solution effectively controls the deployment process and ensures that all instances in the Auto Scaling group run the same version of the application code after the deployment.
- Cons: This process involves manual steps (or scripting) and requires creating a new AMI each time there is a code update. The solution could introduce downtime during the process of suspending scaling, deploying code, creating AMIs, and updating the launch template. This approach also requires managing AMIs and making adjustments to the Auto Scaling group’s configuration, which could increase operational complexity.
Option C: Create a new AWS CodeBuild project that creates a new AMI that contains the new code. Configure CodeBuild to update the Auto Scaling groups launch template to the new AMI. Run an Amazon EC2 Auto Scaling instance refresh operation.
- How it works: This option uses AWS CodeBuild to create a new AMI that includes ...
Author: Sophia Clark · Last updated May 13, 2026
A company has a website that runs on four Amazon EC2 instances that are behind an Application Load Balancer (ALB). When the ALB detects that an EC2 instance is no longer available, an Amazon CloudWatch alarm enters the ALARM state. A member of the company's operations team then manually adds a new EC2 instance behind the ALB.
A solutions architect needs to design a highly available solution that automatically handles the replac...
To design a highly available solution that automatically handles the replacement of EC2 instances without manual intervention and minimizes downtime, we need to focus on key factors such as automation, scalability, and high availability. Here's an evaluation of each option:
Option A: Delete the existing ALB. Create an Auto Scaling group that is configured to handle the web application traffic. Attach a new launch template to the Auto Scaling group. Create a new ALB. Attach the Auto Scaling group to the new ALB. Attach the existing EC2 instances to the Auto Scaling group.
- Pros: This option introduces Auto Scaling, which will automatically manage EC2 instances to maintain the desired capacity. However, deleting the existing ALB means setting up a new load balancer, which introduces unnecessary complexity and downtime. Additionally, attaching the existing EC2 instances to the new Auto Scaling group is not an ideal approach, as it doesn't provide a seamless transition.
- Cons: Deleting the ALB and reconfiguring everything is a disruptive process. The existing EC2 instances would also need to be carefully managed and transitioned, which can be error-prone and cause more downtime.
- Scenario Fit: This option is more disruptive than necessary and introduces unnecessary downtime by deleting and reconfiguring the ALB.
Option B: Create an Auto Scaling group that is configured to handle the web application traffic. Attach a new launch template to the Auto Scaling group. Attach the Auto Scaling group to the existing ALB. Attach the existing EC2 instances to the Auto Scaling group.
- Pros: This solution integrates the Auto Scaling group with the existing ALB, ensuring that the load balancer can distribute traffic to the instances managed by the Auto Scaling group. The Auto Scaling group will automatically handle instance replacements.
- Cons: Attaching existing EC2 instances to the Auto Scaling group could cause issues because the EC2 instances were not originally launched through the Auto Scaling group. This may cause misalignments in instance configurations or scaling behavior, and there may be inconsistencies in instance health reporting.
- Scenario Fit: While this option avoids deleting the ALB, it does not fully automate the process of instance management due to the manual addition of existing EC2 instances. It also introduces potential operational complexity.
Option C: Delete the existing ALB and the EC2 instances. Create an Auto Scaling group that is configured to handle the web application traffic. Attach a new launch template to the Auto Scaling group. Create a new ALB. Attach the Auto Scal...
Author: Oscar · Last updated May 13, 2026
A company wants to optimize AWS data-transfer costs and compute costs across developer accounts within the company's organization in AWS Organizations. Developers can configure VPCs and launch Amazon EC2 instances in a single AWS Region. The EC2 instances retrieve approximately 1 TB of data each day from Amazon S3.
The developer activity leads to excessive monthly data-transfer charges and NAT gateway processing charges between EC2 instances and S3 buckets, along with high compute costs. The company wants to proactively enforce approved architectural patterns for any EC2 instance and VPC...
To optimize AWS data-transfer and compute costs across the developer accounts, it’s crucial to design a solution that minimizes unnecessary data transfer, manages costs effectively, and enforces architectural patterns while not hampering developer productivity. Let’s analyze each option based on these criteria:
Option A: Create SCPs to prevent developers from launching unapproved EC2 instance types. Provide the developers with an AWS CloudFormation template to deploy an approved VPC configuration with S3 interface endpoints. Scope the developers' IAM permissions so that the developers can launch VPC resources only with CloudFormation.
- Pros: Service Control Policies (SCPs) can effectively restrict the launch of unapproved EC2 instance types. CloudFormation templates ensure that developers use approved infrastructure patterns, such as S3 interface endpoints, which reduce data transfer and NAT gateway processing costs. By limiting the ability to create infrastructure directly and only allowing CloudFormation-based deployments, the company can enforce consistent and cost-effective architectures.
- Cons: Developers would still need to use CloudFormation, which adds some overhead in the short term for fast-paced development. However, this is a manageable trade-off to ensure the architecture remains cost-effective and compliant.
- Scenario Fit: This solution meets the requirements of enforcing cost-effective architecture patterns without negatively affecting the developers' speed too much. It reduces the risk of expensive data transfer between EC2 instances and S3 buckets.
Option B: Create a daily forecasted budget with AWS Budgets to monitor EC2 compute costs and S3 data-transfer costs across the developer accounts. When the forecasted cost is 75% of the actual budget cost, send an alert to the developer teams. If the actual budget cost is 100%, create a budget action to terminate the developers' EC2 instances and VPC infrastructure.
- Pros: AWS Budgets can help track cost usage and alert teams when costs are approaching thresholds. Budget actions like terminating EC2 instances can prevent excessive spending.
- Cons: This approach does not directly prevent or reduce the root cause of the high data transfer and compute costs, such as inefficient EC2-to-S3 traffic. It only reacts to cost overruns, and by terminating EC2 instances, it risks interrupting development, which could lead to productivity loss.
- Scenario Fit: This solution is reactive, not proactive, and could negatively impact developer work speed. It doesn't prevent the underlying inefficiencies in infrastructure design.
Option C: Create an AWS Service Catalog portfolio that users can use to create an approved VPC configuration with S3 gateway endpoin...
Author: RadiantPhoenixX · Last updated May 13, 2026
A company is expanding. The company plans to separate its resources into hundreds of different AWS accounts in multiple AWS Regions. A solutions architect must recommend a solution that denies access to any operation...
To meet the requirement of denying access to any operations outside of specifically designated AWS Regions across multiple AWS accounts, let's analyze the options and their applicability.
Key Requirements:
- Restrict access to specific AWS Regions: The company wants to enforce access limitations to specific Regions only.
- Scalable solution: The solution must scale across hundreds of AWS accounts in multiple Regions.
- Centralized management: The solution should be manageable at scale, given the large number of accounts and Regions.
Evaluation of Options:
Option A: Create IAM roles for each account. Create IAM policies with conditional allow permissions that include only approved Regions for the accounts.
- How it works: This approach involves creating IAM roles for each account and IAM policies that specify which Regions are allowed by including conditional statements in the policies.
- Pros:
- Granular control: This allows you to define very specific permissions for each account.
- Customizable: Policies can be tailored to specific use cases or regions per account.
- Cons:
- Scalability issues: Managing hundreds of IAM policies across multiple accounts could become cumbersome and error-prone, particularly with the rapid expansion of the company's accounts.
- Manual effort: The setup and ongoing management of IAM policies in each account could require significant manual effort and may not scale well across many accounts or Regions.
Option B: Create an organization in AWS Organizations. Create IAM users for each account. Attach a policy to each user to block access to Regions where an account cannot deploy infrastructure.
- How it works: This solution involves using AWS Organizations and IAM users to attach policies that restrict access to specific Regions.
- Pros:
- Centralized management: By using AWS Organizations, you can manage permissions for multiple accounts from a single location.
- IAM policy flexibility: Policies can be defined for specific users or groups to restrict access to specific Regions.
- Cons:
- IAM users limitation: This option requires IAM users to be created and managed for each account, which can be cumbersome if the company needs to manage a large number of users.
- Not ideal for large-scale environments: Managing IAM users at scale (especially in a growing environment) might become complex and hard to maintain as the organization expands.
Option C: Launch an AWS Control Tower landing zone. Create OUs and attach SCPs that deny access to run se...
Author: Stella · Last updated May 13, 2026
A company wants to refactor its retail ordering web application that currently has a load-balanced Amazon EC2 instance fleet for web hosting, database API services, and business logic. The company needs to create a decoupled, scalable architecture with a mechanism f...
To evaluate the best solution, let’s break down the requirements and key factors:
- Decoupling: The application needs a decoupled architecture, meaning different parts of the application (like web hosting, database API services, and business logic) should operate independently and interact through queues or APIs.
- Scalability: The architecture should be able to scale efficiently based on demand without significant operational overhead.
- Failed Order Retention: The solution must include a mechanism to retain failed orders for later processing or troubleshooting.
- Minimizing Operational Costs: The solution should not introduce excessive management or operational costs, and it should leverage AWS services that simplify operations, reducing the need for manual intervention.
Evaluating Each Option:
Option A:
- Web Hosting: Amazon S3 is a cost-effective and scalable option for static content hosting.
- Database API Services: Amazon API Gateway is a managed service that allows the creation of APIs with minimal management.
- Order Queuing: Amazon SQS provides a scalable and decoupled mechanism for queuing orders.
- Business Logic: Amazon ECS is a good choice for containerized applications but might involve more management overhead compared to serverless options.
- Failed Order Retention: Using SQS long polling is a reliable option for retaining failed orders, but this requires additional management of the message queue.
Why rejected: ECS introduces some complexity in terms of managing containers and scaling compared to serverless or fully managed solutions. While scalable, it might not align with the operational cost-minimizing requirement as well as other serverless or PaaS-based solutions.
Option B:
- Web Hosting: AWS Elastic Beanstalk is a fully managed service that simplifies deploying web applications but may incur higher costs compared to S3 for static websites.
- Database API Services: Amazon API Gateway is a suitable choice for API management.
- Order Queuing: Amazon MQ, while it supports advanced queuing features, typically incurs higher operational overhead and cost compared to SQS.
- Business Logic: AWS Step Functions can be useful for orchestrating complex workflows but can add unnecessary complexity and cost for simpler use cases.
- Failed Order Retention: Amazon S3 Glacier Deep Archive is a good choice for long-term retention but may introduce unnecessary comp...
Author: Andrew · Last updated May 13, 2026
A company hosts a web application on AWS in the us-east-1 Region. The application servers are distributed across three Availability Zones behind an Application Load Balancer. The database is hosted in a MySQL database on an Amazon EC2 instance. A solutions architect needs to design a cross-Region data recovery solution using AWS services with an RTO of less than 5 minutes and an RPO of less than 1 minute. The solutions architect i...
To meet the requirements of a cross-Region data recovery solution with RTO of less than 5 minutes and RPO of less than 1 minute, the solution needs to ensure high availability and fast failover while minimizing downtime and data loss during a Region failure. Let's evaluate each option:
Key Considerations:
- RTO (Recovery Time Objective): Time it takes to recover from a failure. In this case, it needs to be less than 5 minutes.
- RPO (Recovery Point Objective): The maximum acceptable amount of data loss, which is less than 1 minute in this case.
- The solution must be cross-Region (because the solution is designed for the us-east-1 and us-west-2 Regions).
- The solution should be low-latency and highly available, with minimal management overhead.
Evaluating the Options:
Option A: Migrate the database to an Amazon RDS for MySQL instance with a cross-Region read replica in us-west-2.
- Pros: Amazon RDS for MySQL supports read replicas across Regions, which can help with disaster recovery. The cross-Region read replica ensures that the data is asynchronously replicated, and you can promote the read replica to be the primary in case of a failure in the primary Region.
- Cons: While this option is good for read-heavy workloads, the replication is asynchronous, meaning there could be a small lag between the primary and the replica. This might not meet the RPO of less than 1 minute reliably, as data might not be fully synchronized in the event of a failure.
Why rejected: The asynchronous nature of cross-Region read replicas does not guarantee an RPO of less than 1 minute, and the failover process might take more than 5 minutes to fully propagate the changes.
Option B: Migrate the database to an Amazon Aurora global database with the primary in us-east-1 and the secondary in us-west-2.
- Pros: Aurora global databases are designed specifically for cross-Region replication with low-latency failover. Aurora guarantees less than 1 second RPO, which meets the RPO requirement. The failover process is fast, often under a minute, ensuring that the RTO is well within the 5-minute requirement.
- Cons: Aurora might be more expensive than a standard MySQL deployment, and i...
Author: Ming · Last updated May 13, 2026
A company is using AWS Organizations to manage multiple accounts. Due to regulatory requirements, the company wants to restrict specific member accounts to certain AWS Regions, where they are permitted to deploy resources. The resources in the accounts must be tagged, enforced based on a group ...
To address the regulatory requirement of restricting member accounts to specific AWS Regions and enforcing tagging based on a group standard, the solution needs to provide a centralized approach with minimal configuration. Let's analyze the options:
Key Requirements:
- Restrict specific member accounts to certain AWS Regions.
- Enforce resource tagging based on a group standard.
- Centrally manage and minimize configuration.
- Leverage AWS Organizations and minimize the need for per-account configurations.
Evaluating the Options:
Option A: Create an AWS Config rule in the specific member accounts to limit Regions and apply a tag policy.
- Pros: AWS Config can be used to enforce compliance with rules (e.g., region restrictions and tagging).
- Cons: This approach would require configuration in each individual account, which does not align with the requirement for minimal configuration. The regional restrictions and tagging enforcement would have to be manually applied to each member account, leading to increased complexity and management overhead.
Why rejected: While AWS Config can enforce resource policies, it does not provide a centralized, automated method of managing these rules across multiple accounts under AWS Organizations. This would require significant manual setup for each member account.
Option B: From the AWS Billing and Cost Management console, in the management account, disable Regions for the specific member accounts and apply a tag policy on the root.
- Pros: Disabling Regions at the Billing and Cost Management level could prevent member accounts from using certain Regions. A tag policy can be centrally applied from the root.
- Cons: Disabling Regions at the Billing and Cost Management level is not a robust way to enforce region restrictions; it’s not a standard mechanism for restricting regions at the AWS Organizations level. Tag policies can be centrally managed, but restricting Regions from the Billing and Cost Management console is not the most effective or standard approach.
Why rejected: This solution lacks flexibility and control, and it is not a proper way to enforce Region restrictions or to handle them in a centralized manner within the scope of AWS Organizations.
Option C...
Author: Sam · Last updated May 13, 2026
A company has an application that generates reports and stores them in an Amazon S3 bucket. When a user accesses their report, the application generates a signed URL to allow the user to download the report. The company's security team has discovered that the files are public and that anyone can download them without authentication. The company has suspended the generation of n...
To address the issue of public access to reports in the Amazon S3 bucket and immediately remediate the security problem without disrupting the application's normal workflow, let's evaluate each option carefully.
Key Requirements:
- Remediate the security issue immediately: The solution must stop public access to files without disrupting the normal workflow of generating signed URLs for authenticated users.
- Minimize impact on the application: The application must continue to generate signed URLs and allow authenticated users to download reports.
Evaluating the Options:
Option A: Create an AWS Lambda function that applies a deny-all policy for users who are not authenticated. Create a scheduled event to invoke the Lambda function.
- Pros: This approach can be used to dynamically update permissions on objects in the S3 bucket and enforce policies based on authentication status.
- Cons: While Lambda can automate changes, this solution is complex and may introduce delays in remediation. Lambda is also not the most direct or simple way to prevent public access to files in S3. Scheduled events may not provide an immediate, real-time solution to the problem.
Why rejected: Although it can work, it is overly complex and doesn't provide an immediate fix without introducing additional configuration or potential delays.
Option B: Review the AWS Trusted Advisor bucket permissions check and implement the recommended actions.
- Pros: AWS Trusted Advisor provides insights and recommendations for optimizing AWS environments, including S3 bucket permissions.
- Cons: While Trusted Advisor helps identify misconfigurations, it does not provide an immediate, hands-on solution to remediate the issue. It's a diagnostic tool, not a corrective action.
Why rejected: Trusted Advisor is useful for auditing but does not provide an immediate mechanism for fixing the current public access issue directly.
Option C: Run a script that puts a private ACL on all of the ob...
Author: Emily · Last updated May 13, 2026
A company is planning to migrate an Amazon RDS for Oracle database to an RDS for PostgreSQL DB instance in another AWS account. A solutions architect needs to design a migration strategy that will require no downtime and that will minimize the amount of time necessary to complete the migration. The migration strategy must replicate all existing data and any new data that is created during the migration. The target database must be identical to the source database at completion of the migration process.
All applications currently use an Amazon Route 53 CNAME ...
To meet the requirements of migrating an Amazon RDS for Oracle database to an RDS for PostgreSQL DB instance with no downtime, replicating all existing and new data, and ensuring the target database is identical to the source, let’s carefully analyze the available steps.
Key Requirements:
1. Zero downtime: The migration must be performed with minimal interruption to applications.
2. Replication of existing and new data: The migration must ensure that both the existing data and any changes made during the migration are captured.
3. End result: The target database must be identical to the source at the end of the migration.
4. Applications use CNAME records: Applications use Route 53 CNAME records to reference the database.
Evaluating the Options:
Option A: Create a new RDS for PostgreSQL DB instance in the target account. Use the AWS Schema Conversion Tool (AWS SCT) to migrate the database schema from the source database to the target database.
- Pros: AWS SCT helps in converting the schema from Oracle to PostgreSQL. This is useful for handling the schema migration.
- Cons: This only covers the schema migration, and it doesn’t address migrating the data or keeping the target database synchronized with the source during the migration process.
Why rejected: This option doesn’t handle data replication or ensure zero downtime. It only migrates the schema, which is incomplete for the migration requirements.
Option B: Use the AWS Schema Conversion Tool (AWS SCT) to create a new RDS for PostgreSQL DB instance in the target account with the schema and initial data from the source database.
- Pros: The SCT helps in migrating the schema and initial data from the source Oracle database to the target PostgreSQL database.
- Cons: It still doesn’t provide replication for ongoing changes. While it helps with the initial load of data, it doesn’t address the need to keep the databases synchronized during migration.
Why rejected: It’s better than Option A since it migrates both the schema and initial data, but it doesn’t replicate ongoing changes or handle zero downtime.
Option C: Configure VPC peering between the VPCs in the two AWS accounts to provide connectivity to both DB instances from the target account. Configure the security groups that are attached to each DB instance to allow traffic on the database port from the VPC in the target account.
- Pros: VPC peering ensures that the databases in different AWS accounts can communicate with each other, which is necessary for data migration.
- Cons: This step is a necessary part of the migration, but it doesn’t directly address data replication or zero downtime during migration. It simply enables network connectivity.
Why selected: VPC peering is essential to allow communication between the source and target databases for data replication purposes. However, it’s only part of the solution and needs to be combined with other migration tools.
Opt...
Author: Ella · Last updated May 13, 2026
A company has implemented an ordering system using an event-driven architecture. During initial testing, the system stopped processing orders. Further log analysis revealed that one order message in an Amazon Simple Queue Service (Amazon SQS) standard queue was causing an error on the backend and blocking all subsequent order messages. The visibility timeout of the queue is set to 30 seconds, and the backend processing timeout is set to 10 seconds. A soluti...
In an event-driven architecture, when a message in the queue causes a failure, it can block subsequent messages from being processed. To address the issue described, the solutions architect needs a strategy that allows faulty messages to be isolated while ensuring that the system can continue processing valid messages.
Let's evaluate the options:
A) Increase the backend processing timeout to 30 seconds to match the visibility timeout.
- Explanation: Increasing the backend processing timeout could potentially prevent the visibility timeout from prematurely hiding the message while the backend is still working on it. However, this would only resolve the problem if the issue is purely related to timing between the backend processing and the queue visibility. It does not address isolating faulty messages and continuing to process others, which is the main concern here. Additionally, this solution could cause delays in processing valid messages if the backend is slower than expected.
- Rejection Reason: Does not isolate the faulty message, leading to potential delays in overall system performance.
B) Reduce the visibility timeout of the queue to automatically remove the faulty message.
- Explanation: Reducing the visibility timeout might cause the message to be returned to the queue before the backend finishes processing it, potentially leading to duplicate message processing. This might help in the short term, but it doesn't address isolating the faulty message. Additionally, it could lead to processing failures if the backend is unable to handle the message in the reduced time frame.
- Rejection Reason: This option doesn't isolate the faulty message and might cause duplicate...
Author: Julian · Last updated May 13, 2026
A company has automated the nightly retraining of its machine learning models by using AWS Step Functions. The workflow consists of multiple steps that use AWS Lambda. Each step can fail for various reasons, and any failure causes a failure of the overall workflow.
A review reveals that the retraining has failed multiple nights in a row without the company noticing the failure. A solutions architect needs to improve the workflow so t...
To meet the requirement of ensuring that notifications are sent for all types of failures in the retraining process, the solutions architect needs to implement a combination of steps that not only capture failures across all steps in the workflow but also reliably send notifications. Here's a breakdown of the different options and the reasoning behind selecting the best combination:
A) Create an Amazon Simple Notification Service (Amazon SNS) topic with a subscription of type "Email" that targets the team's mailing list.
- Explanation: SNS is a highly suitable service for sending notifications, especially via email. By creating an SNS topic with an email subscription, you ensure that any failure in the workflow triggers an email notification to the team's mailing list.
- Selection Reason: This option is ideal because it provides a reliable, scalable way to send notifications and can integrate easily with Step Functions. SNS allows for broad notification support, including email, SMS, and others.
- Rejection Reason: Without adding the SNS topic to the workflow and ensuring it is triggered upon failures, this step alone wouldn't send notifications.
B) Create a task named "Email" that forwards the input arguments to the SNS topic.
- Explanation: A task that forwards the input to the SNS topic would allow the workflow to trigger notifications when a failure occurs. This could be done within Step Functions, and the task would ensure that the failure event is communicated to the SNS topic.
- Selection Reason: This step is necessary for connecting the workflow with the SNS topic, ensuring that a failure in any part of the workflow results in the notification being sent. The email subscription to SNS will ensure that the team receives a message.
- Rejection Reason: Without this task, Step Functions would not be able to forward failure events to the SNS topic.
C) Add a Catch field to all Task, Map, and Parallel states that have a statement of "ErrorEquals": [ "States.ALL" ] and "Next": "Email".
- Explanation: The `Catch` field in Step Functions allows you to catch errors and specify how to handle them, such as transitioning to a new task. By adding a `Catch` field to handle all errors (`"States.ALL"`), you can direct Step Functions to the "Email" task in case of failure. This will ensure that any failure triggers the email notification task.
- Selection Reason: This is a key part of error handling...
Author: FrostFalcon88 · Last updated May 13, 2026
A company plans to deploy a new private intranet service on Amazon EC2 instances inside a VPC. An AWS Site-to-Site VPN connects the VPC to the company's on-premises network. The new service must communicate with existing on-premises services. The on-premises services are accessible through the use of hostnames that reside in the company.example DNS zone. This DNS zone is wholly hosted on premises and is available only on the company's private netwo...
To meet the requirements for the new service to communicate with existing on-premises services, the solutions architect needs to ensure that the new service in the VPC can resolve hostnames in the `company.example` domain, which is hosted on-premises.
Let's evaluate each option:
A) Create an empty private zone in Amazon Route 53 for company.example. Add an additional NS record to the company's on-premises company.example zone that points to the authoritative name servers for the new private zone in Route 53.
- Explanation: This option proposes creating a new private DNS zone in Route 53 for `company.example` and then configuring the on-premises DNS to forward requests for this domain to Route 53. While this could work, the main issue is that the DNS zone is already hosted on-premises, and the goal is to resolve the DNS names in this existing zone, not create a new one in Route 53. This solution introduces unnecessary complexity, as it requires a new zone and DNS forwarding, which is not necessary when the DNS zone is already available on-premises.
- Rejection Reason: This option requires creating a new DNS zone in Route 53, which is not needed since the DNS zone already exists on-premises.
B) Turn on DNS hostnames for the VPC. Configure a new outbound endpoint with Amazon Route 53 Resolver. Create a Resolver rule to forward requests for company.example to the on-premises name servers.
- Explanation: This solution proposes using Route 53 Resolver to forward DNS queries from the VPC to the on-premises name servers. By creating an outbound resolver endpoint and a resolver rule, the VPC can forward DNS requests for `company.example` to the on-premises DNS servers. This setup ensures that the new EC2 instances in the VPC can resolve hostnames from the `company.example` domain, as these requests are forwarded to the existing on-premises DNS infrastructure.
- Selection Reason: This is the best solution because it ensures the VPC instances can resolve the required DNS records hosted on-premises, and it leverages the existing DNS infrastructure without requiring unnecessary changes. It also uses the Route 53 Resolver, which is designed for such use cases.
- Rejection Reason: None. This is the most appropriate solution for t...
Author: Isabella · Last updated May 13, 2026
A company uses AWS CloudFormation to deploy applications within multiple VPCs that are all attached to a transit gateway. Each VPC that sends traffic to the public internet must send the traffic through a shared services VPC. Each subnet within a VPC uses the default VPC route table, and the traffic is routed to the transit gateway. The transit gateway uses its default route table for any VPC attachment.
A security audit reveals that an Amazon EC2 instance that is deployed within a VPC can communicate with an EC2 instance that is deployed in any of the company...
To meet the requirement of limiting traffic between VPCs while allowing only authorized VPCs to communicate with each other, the solutions architect needs to control the routing of traffic and restrict inter-VPC communication based on the specified authorization.
Let’s evaluate the options:
A) Update the network ACL of each subnet within a VPC to allow outbound traffic only to the authorized VPCs. Remove all deny rules except the default deny rule.
- Explanation: Network ACLs (NACLs) control inbound and outbound traffic at the subnet level. While they could restrict traffic, they are generally less granular than other methods like route tables and security groups, and they are not the best way to manage VPC-to-VPC communication in this case. Managing inter-VPC communication at the NACL level would be cumbersome, especially if there are many subnets or VPCs involved, and it would require extensive configuration changes in multiple locations.
- Rejection Reason: NACLs are not designed to manage inter-VPC routing at scale, and this approach would require manual updates to every subnet, making it difficult to manage and scale effectively.
B) Update all the security groups that are used within a VPC to deny outbound traffic to security groups that are used within the unauthorized VPCs.
- Explanation: Security groups control traffic at the instance level, and although they can be used to limit communication between instances, they are not designed for managing large-scale inter-VPC routing or controlling traffic across an entire VPC. Using security groups to manage communication between VPCs would require a significant amount of configuration for each instance and would be cumbersome to maintain as the environment scales.
- Rejection Reason: Security groups are not intended to control inter-VPC communication at scale, and applying restrictions at the security group level would require extensive management across all instances and security group...
Author: MoonlitPantherX · Last updated May 13, 2026
A company has a Windows-based desktop application that is packaged and deployed to the users' Windows machines. The company recently acquired another company that has employees who primarily use machines with a Linux operating system. The acquiring company has decided to migrate and rehost the Windows-based desktop application to AWS.
All employees must be authenticated before they use the application. The acquiring company uses Active Director...
To determine the best solution for migrating and rehosting the Windows-based desktop application to AWS with minimal development effort, we need to consider several key factors: the authentication mechanism, the platform compatibility (Windows vs. Linux), and the user experience.
Let’s evaluate each option:
A) Set up and provision an Amazon Workspaces virtual desktop for every employee. Implement authentication by using Amazon Cognito identity pools. Instruct employees to run the application from their provisioned Workspaces virtual desktops.
- Explanation: Amazon Workspaces provides managed virtual desktops on the AWS cloud. This option would involve provisioning a WorkSpace for each employee, where the application could be installed and used. Authentication could be handled via Amazon Cognito, which can integrate with existing identity providers.
- Rejection Reason: Although this solution could work, it is more resource-intensive as it requires managing a separate virtual desktop for each employee. Workspaces are typically used for more isolated use cases and can be expensive, especially when scaling to a large number of employees. This also doesn't directly solve the need for multi-platform (Windows and Linux) support, as Workspaces would still require users to operate within a Windows environment.
B) Create an Auto Scaling group of Windows-based Amazon EC2 instances. Join each EC2 instance to the company’s Active Directory domain. Implement authentication by using the Active Directory that is running on premises. Instruct employees to run the application by using a Windows remote desktop.
- Explanation: This approach would involve running Windows-based EC2 instances, joining them to the on-premises Active Directory, and using remote desktop access. Authentication could be integrated directly with the existing Active Directory setup.
- Rejection Reason: This option requires setting up and maintaining Windows EC2 instances, which could lead to significant complexity in managing these instances. Moreover, it doesn't address the cross-platform need, as the solution is still Windows-centric. Employees using Linux-based machines would need to rely on Windows remote desktop, which may introduce user experience challenges.
C) Use an Amazon AppStream 2.0 image builder to create an image that includes the application and the required configurations. Provision an AppStream 2.0 On-Demand fleet with dynamic Fleet Auto Scaling policies for running the image. Implement authentication by using AppStream 2.0 user...
Author: Charlotte · Last updated May 13, 2026
A company is collecting a large amount of data from a fleet of IoT devices. Data is stored as Optimized Row Columnar (ORC) files in the Hadoop Distributed File System (HDFS) on a persistent Amazon EMR cluster. The company's data analytics team queries the data by using SQL in Apache Presto deployed on the same EMR cluster. Queries scan large amounts of data, always run for less than 15 minutes, and run only between 5 PM and 10 PM.
The company is concerned about...
To choose the most cost-effective solution, let’s break down the options considering the given constraints:
- Data is stored in ORC format in HDFS on a persistent EMR cluster.
- Queries typically scan large amounts of data but run for less than 15 minutes.
- Queries are only run between 5 PM and 10 PM, suggesting limited periods of activity.
- The company is concerned about the high cost of the current solution.
Option A: Store data in Amazon S3. Use Amazon Redshift Spectrum to query data.
- Storage: Storing the data in Amazon S3 makes it easily accessible and cost-effective, as Amazon S3 provides low-cost storage, especially for large datasets.
- Querying: Redshift Spectrum allows querying of S3 data using SQL, and it can scale to handle large queries. However, this solution requires an Amazon Redshift cluster, which can incur high costs, especially if the queries are intermittent (5 PM to 10 PM).
- Cost Considerations: Even though Redshift Spectrum queries are priced based on the amount of data scanned, maintaining a Redshift cluster (even if only using Spectrum) can still result in higher ongoing costs compared to more serverless options.
- Verdict: The cost of maintaining an Amazon Redshift cluster may not be optimal if query load is intermittent.
Option B: Store data in Amazon S3. Use the AWS Glue Data Catalog and Amazon Athena to query data.
- Storage: Storing data in Amazon S3 offers low-cost, durable storage. S3 is a great fit for large, unstructured datasets like ORC files.
- Querying: Amazon Athena is a serverless query service that directly queries data in S3 using SQL. Athena pricing is based on the amount of data scanned per query, which is cost-effective because there is no need to maintain infrastructure (e.g., no clusters).
- Cost Considerations: Since the data is only queried for a limited time each day, Athena’s pay-per-query model is a good fit because you pay only when you query the data. Additionally, AWS Glue Data Catalog can be used to manage the metadata of the data in S3, which is fully integrated with Athena.
- Verdict: This solution is highly cost-effective since there’s no need to maintain persistent infrastructure and you pay only for the data scanned...
Author: Isabella · Last updated May 13, 2026
A large company recently experienced an unexpected increase in Amazon RDS and Amazon DynamoDB costs. The company needs to increase visibility into details of AWS Billing and Cost Management. There are various accounts associated with AWS Organizations, including many development and production accounts. There is no consistent tagging strategy across the organization, but there are guidelines in place that require all infrastructure to be deployed using AWS CloudFormation with consistent taggi...
To meet the company’s requirements of increasing visibility into AWS Billing and Cost Management and ensuring that all resources have consistent tagging for cost center and project ID numbers, let's evaluate each option based on the key factors:
Option A: Use Tag Editor to tag existing resources. Create cost allocation tags to define the cost center and project ID and allow 24 hours for tags to propagate to existing resources.
- Tagging Existing Resources: Tag Editor is a useful tool for bulk tagging resources, but it requires 24 hours for tags to propagate and be visible in AWS Cost Explorer and billing reports.
- Cost Allocation Tags: This would allow the cost center and project ID to be properly tracked. However, this does not address how to ensure that all future resources are tagged consistently.
- Limitations: The 24-hour propagation delay might not be ideal for quick tracking. Additionally, there is no automatic enforcement to ensure that resources created in the future have these tags.
- Verdict: This approach is helpful for retroactively tagging existing resources, but it doesn’t provide a strategy for enforcing tagging on future resources. It could be a good first step but requires additional measures for future consistency.
Option B: Use an AWS Config rule to alert the team of untagged resources. Create a centralized AWS Lambda-based solution to tag untagged RDS databases and DynamoDB resources every hour using a cross-account role.
- AWS Config Rule: AWS Config can be used to track resource configurations and can alert you when resources are missing tags. However, while alerts are useful, they do not provide automatic enforcement of tagging.
- AWS Lambda Automation: A Lambda-based solution that runs every hour to tag untagged RDS and DynamoDB resources is a proactive approach. This would help with tagging resources that may have been missed. However, it could introduce delays if resources are not tagged immediately upon creation, and it would require complex cross-account roles.
- Limitations: This solution introduces complexity (Lambda automation, cross-account roles), and it still doesn’t stop untagged resources from being created in the first place. It’s reactive rather than preventive.
- Verdict: While this is a practical solution for ongoing tagging, it’s not the most efficient approach since it doesn’t prevent untagged resources from being created in the first place and requires extra automation effort.
Option C: Use Tag Editor to tag existing resources. Create cost allocation tags to define t...
Author: Oliver · Last updated May 13, 2026
A company wants to send data from its on-premises systems to Amazon S3 buckets. The company created the S3 buckets in three different accounts. The company must send the data privately without the data traveling across the internet. The company has no existing dedicated connec...
To meet the requirement of sending data privately from the on-premises systems to Amazon S3 buckets in different accounts without traversing the internet, the company needs to establish secure and private connectivity to AWS and ensure that the data transfer between the on-premises system and the S3 buckets happens within the AWS network.
Let's analyze each option:
Option A: Establish a networking account in the AWS Cloud. Create a private VPC in the networking account. Set up an AWS Direct Connect connection with a private VIF between the on-premises environment and the private VPC.
- Pros: AWS Direct Connect provides a dedicated network connection from the on-premises environment to AWS, which does not travel over the public internet. A private VIF (Virtual Interface) ensures that the data remains within AWS's private network.
- Cons: While Direct Connect ensures a private connection, it does not directly connect to Amazon S3. The company would need additional configurations such as a VPC endpoint or a VPN to ensure that data flows from the VPC to the S3 buckets across different accounts.
- Scenario Fit: This option is a good starting point, as it ensures private connectivity between on-premises systems and the AWS cloud, but additional steps are required for routing traffic to S3.
Option B: Establish a networking account in the AWS Cloud. Create a private VPC in the networking account. Set up an AWS Direct Connect connection with a public VIF between the on-premises environment and the private VPC.
- Pros: A public VIF provides a connection to AWS public services, including S3.
- Cons: Using a public VIF means the traffic travels over the internet to reach S3. The requirement explicitly states that the company wants to send data privately, which rules out using a public VIF. This does not meet the requirement of private data transfer.
- Scenario Fit: This option is not suitable because it involves internet traffic, which violates the requirement of sending data privately without using the internet.
Option C: Create an Amazon S3 interface endpoint in the networking account.
- Pros: An Amazon S3 interface endpoint provides private connectivity to S3 over AWS’s internal network. Data sent to and from S3 through this endpoint will not traverse the public internet.
- Cons: An S3 interface endpoint allows private communication with S3 but only works for VPCs within the same account. This would require the S3 buckets to be in the same VPC or connected via peering/VPN. However, this might not directly address cross-account access for the S3 buckets.
- Scenario Fit: This option is useful if ...
Author: Aria · Last updated May 13, 2026
A company operates quick-service restaurants. The restaurants follow a predictable model with high sales traffic for 4 hours daily. Sales traffic is lower outside of those peak hours.
The point of sale and management platform is deployed in the AWS Cloud and has a backend that is based on Amazon DynamoDB. The database table uses provisioned throughput mode with 100,000 RCUs and 80,000 WCUs to match known peak resource ...
To meet the company's goal of reducing DynamoDB costs while minimizing operational overhead, let’s evaluate each option:
Option A: Reduce the provisioned RCUs and WCUs.
- Scaling Manually: The company’s system has predictable traffic with high sales during peak hours. By manually reducing the provisioned read and write capacity units (RCUs and WCUs) during non-peak hours, the company could save costs. However, this requires regular manual intervention to adjust the capacity according to the traffic pattern.
- Operational Overhead: While this could reduce costs, it creates operational overhead because the capacity would need to be adjusted daily (or periodically), and the company might need to constantly monitor traffic trends to avoid throttling during peak times.
- Verdict: This option is not ideal because of the manual overhead involved in adjusting the capacity frequently, which increases complexity and potential risk of under-provisioning during peak traffic.
Option B: Change the DynamoDB table to use on-demand capacity.
- On-Demand Scaling: In on-demand capacity mode, DynamoDB automatically scales to accommodate the workload. It is ideal for unpredictable workloads where you don’t want to manually adjust the capacity.
- Cost Efficiency: This could be more cost-effective than provisioned capacity because the company would only pay for the actual usage rather than over-provisioning for peak hours.
- Verdict: On-demand capacity is ideal for varying workloads, but in this case, since the sales traffic is predictable with clear peak and off-peak times, it may not be the most cost-effective solution, as it could lead to higher costs during peak hours where the system would still need to scale up quickly.
Option C: Enable DynamoDB auto scaling for the table.
- Auto Scaling: DynamoDB auto scaling adjusts the RCUs and WCUs based on traffic patterns, automatically increasing throughput during high traffic and reducing it during low traffic times. This allows the company to match throughput demand while optimizing cost.
- Cost Efficiency: Auto scaling en...
Author: Manish · Last updated May 13, 2026
A company hosts a blog post application on AWS using Amazon API Gateway, Amazon DynamoDB, and AWS Lambda. The application currently does not use API keys to authorize requests. The API model is as follows:
GET /posts/{postId}: to get post details
GET /users/{userId}: to get user details
GET /comments/{commentId}: to get comments details
The company has noticed users are actively discussing topics in the comments sect...
To reduce comment latency and improve user experience by delivering comments in real-time, let’s evaluate each option:
Option A: Use edge-optimized API with Amazon CloudFront to cache API responses.
- Edge-Optimized API: Edge-optimized APIs in API Gateway use Amazon CloudFront to deliver responses closer to the end-users, which can reduce latency in some cases. However, the caching mechanism is typically useful for static content and would not be ideal for real-time updates.
- Caching Issue: For real-time content like comments, caching is not the best approach, as it would return stale data. API responses need to reflect the most up-to-date information, and caching would delay this.
- Verdict: This is not suitable for real-time updates because caching would interfere with the timely delivery of comments. It’s better for situations where content does not change frequently.
Option B: Modify the blog application code to request GET/comments/{commentId} every 10 seconds.
- Polling: This approach involves the blog application making repeated requests to the API every 10 seconds. While this would update the comments regularly, it introduces inefficiency because:
- API Load: Making requests every 10 seconds creates a constant load on the backend, which could strain the DynamoDB and Lambda functions.
- Latency: Although this reduces comment latency somewhat, it is not ideal for real-time applications, as there’s still a delay of up to 10 seconds, and it doesn't scale well.
- Network Traffic: Constant polling increases network traffic unnecessarily and is inefficient.
- Verdict: While it could work to update comments regularly, this approach is not efficient and can lead to unnecessary load on resources, especially as the number of users grows.
Option C: Use AWS AppSync and leverage WebSockets to deliver comments.
- Real-Time Updates with WebSockets: AWS AppSync is designed to manage real-time applications and can use WebSockets to deliver data updates to clients in real-time. By using AppSync, the blog application can...
Author: Scarlett · Last updated May 13, 2026
A company manages hundreds of AWS accounts centrally in an organization in AWS Organizations. The company recently started to allow product teams to create and manage their own S3 access points in their accounts. The S3 access points can be accessed only ...
To enforce the requirement that S3 access points can only be created within VPCs, we need to evaluate the operational efficiency of each option. Let's break down the options and why one is most suitable.
A) Set the S3 access point resource policy to deny the s3:CreateAccessPoint action unless the s3:AccessPointNetworkOrigin condition key evaluates to VPC.
- Pros: This option provides a granular way to control the S3 access point creation at the resource level, ensuring that only VPC-based access points can be created. This is the most direct way to control the action at the S3 resource level.
- Cons: While effective, this may be harder to manage at scale if there are many accounts, as each S3 access point would need a policy applied, and managing multiple policies across hundreds of accounts could become cumbersome.
- Use Case: This option is good for organizations that need highly granular control but may struggle with scalability in large environments with multiple accounts.
B) Create an SCP at the root level in the organization to deny the s3:CreateAccessPoint action unless the s3:AccessPointNetworkOrigin condition key evaluates to VPC.
- Pros: Service Control Policies (SCPs) provide a central mechanism to enforce policies across all accounts in an AWS Organization. This option allows the enforcement of the access point creation rule uniformly at the organizational level, making it scalable and easier to manage. SCPs are powerful and can prevent unwanted behavior across multiple accounts.
- Cons: SCPs can only deny or allow actions at the organizational level, and they can’t apply specific policies to particular AWS resources within those accounts. It also might be too broad if not configured carefully, potentially blocking other S3-related actions.
- Use Case: This option is ideal for centralized control across multiple accounts in an organization, particularly in large organizations where operational efficiency is critical.
C) Use AWS CloudFormation StackSets to create a new IAM policy in each AW...
Author: Abigail · Last updated May 13, 2026
A solutions architect must update an application environment within AWS Elastic Beanstalk using a blue/green deployment methodology. The solutions architect creates an environment that is identical to the existing application environment ...
To complete the update using the blue/green deployment methodology within AWS Elastic Beanstalk, we need to transition traffic from the existing (blue) environment to the new (green) environment in a safe and controlled manner. Let's evaluate the available options.
A) Redirect to the new environment using Amazon Route 53.
- Pros: This approach is applicable if the application is using Route 53 for domain name resolution. However, managing DNS records manually can add complexity, and you would need to ensure proper propagation and handling of traffic between environments.
- Cons: Redirecting traffic using Route 53 alone doesn't integrate directly with the Elastic Beanstalk blue/green deployment process. Route 53 changes can introduce delays and require manual intervention in DNS management.
- Use Case: This option is typically used in custom DNS management outside of Elastic Beanstalk's built-in blue/green deployment capabilities.
B) Select the Swap Environment URLs option.
- Pros: This option is part of the Elastic Beanstalk blue/green deployment process. Selecting the "Swap Environment URLs" option allows Elastic Beanstalk to automatically handle the URL swap between the blue and green environments. The existing environment (blue) URL is switched to point to the new environment (green), ensuring a smooth transition of traffic with minimal downtime.
- Cons: This is the most direct, efficient, and operationally integrated way to perform the swap in Elastic Beanstalk. No manual DNS changes are needed, and the transition is automated.
- Use Case: This option is ideal for completing a blue/green deployment, ensuring minimal disruption and maintaining application availability with Elastic Beanstalk's native ...
Author: Benjamin · Last updated May 13, 2026
A company is building an image service on the web that will allow users to upload and search random photos. At peak usage, up to 10,000 users worldwide will upload their images. The will then overlay text on the uploaded images, which ...
To design a scalable and cost-efficient image service on the web, we need to consider the following factors:
1. Scalability: The service should be able to handle up to 10,000 users uploading images simultaneously, as well as the processing workload.
2. Storage: The uploaded images need to be stored and later processed efficiently.
3. Processing and Workflow: There needs to be an effective mechanism for processing the images (overlaying text and potentially transforming images) after upload.
4. Performance: The service needs to provide fast and reliable access to the processed images.
5. Cost Efficiency: The solution should scale dynamically to meet demand without over-provisioning resources.
A) Store the uploaded images in Amazon Elastic File System (Amazon EFS). Send application log information about each image to Amazon CloudWatch Logs. Create a fleet of Amazon EC2 instances that use CloudWatch Logs to determine which images need to be processed. Place processed images in another directory in Amazon EFS. Enable Amazon CloudFront and configure the origin to be one of the EC2 instances in the fleet.
- Pros:
- EFS provides scalable, shared file storage, which could be useful for storing and accessing images across multiple EC2 instances.
- CloudWatch Logs and EC2 instances are fine for certain workflows, as logs can trigger specific processing actions.
- Cons:
- This solution involves manual scaling of EC2 instances and uses CloudWatch Logs to determine processing, which adds complexity and overhead.
- EFS is expensive compared to Amazon S3, especially for large-scale data like images.
- Using EC2 as the CloudFront origin can lead to higher latency and operational complexity.
- Managing EC2 scaling manually is less efficient than using serverless options like SQS or SNS for queuing.
Use Case: This option could be used for small-scale systems but is not optimal for handling large numbers of concurrent users, especially with cost concerns for EFS and EC2 scaling complexity.
B) Store the uploaded images in an Amazon S3 bucket and configure an S3 bucket event notification to send a message to Amazon Simple Notification Service (Amazon SNS). Create a fleet of Amazon EC2 instances behind an Application Load Balancer (ALB) to pull messages from Amazon SNS to process the images and place them in Amazon Elastic File System (Amazon EFS). Use Amazon CloudWatch metrics for the SNS message volume to scale out EC2 instances. Enable Amazon CloudFront and co...
Author: John · Last updated May 13, 2026
A company has deployed its database on an Amazon RDS for MySQL DB instance in the us-east-1 Region. The company needs to make its data available to customers in Europe. The customers in Europe must have access to the same data as customers in the United States (US) and will not tolerate high application latency or stale data. The customers in Europe and the customers in the...
To meet the company's requirements of minimizing latency and ensuring real-time updates for customers in both the US and Europe while allowing them to write to the database, let's carefully consider each option and how it addresses these key requirements:
Key Requirements:
1. Low Latency: Customers in Europe and the US need to access the database with low latency.
2. Real-time Data Availability: Both regions need to have access to the same data in real time.
3. Bidirectional Writes: Both US and Europe-based customers need to be able to write to the database.
Option A: Create an Amazon Aurora MySQL replica of the RDS for MySQL DB instance. Pause application writes to the RDS DB instance. Promote the Aurora Replica to a standalone DB cluster. Reconfigure the application to use the Aurora database and resume writes. Add eu-west-1 as a secondary Region to the DB cluster. Enable write forwarding on the DB cluster. Deploy the application in eu-west-1. Configure the application to use the Aurora MySQL endpoint in eu-west-1.
- Pros: This option involves creating an Aurora MySQL replica, which can provide automatic failover and replication across regions. Aurora supports cross-Region replication, and using write forwarding between regions would allow writes to be forwarded to the appropriate region and data to be kept in sync.
- Cons: It requires promoting the Aurora replica and reconfiguring the application to use Aurora. There is also a pause in application writes while this migration occurs. This approach may involve additional complexity for ensuring bidirectional writes across regions. The application architecture would need to be refactored, and transitioning to Aurora could require extra resources.
- Scenario Fit: This solution is feasible but involves some complexity in terms of application changes and potential downtime during the migration.
Option B: Add a cross-Region replica in eu-west-1 for the RDS for MySQL DB instance. Configure the replica to replicate write queries back to the primary DB instance. Deploy the application in eu-west-1. Configure the application to use the RDS for MySQL endpoint in eu-west-1.
- Pros: Cross-Region replication between RDS for MySQL DB instances allows data to be replicated across regions. This configuration would ensure that customers in Europe have access to the same data as customers in the US.
- Cons: RDS for MySQL does not support cross-Region replication with bidirectional writes. This means that while the data in Europe could be kept up to date with the US region, writes made in Europe would not automatically be replicated back to the US region in real time.
- Scenario Fit: This option does not meet the requirement of allowing bidirectional writes across regions, which is a critical need for the solution.
Option C: Copy the most recent snapshot from the RDS for MySQL DB instance to eu-west-1. Create a new RDS for MySQL DB instance in eu-west-1 from the ...
Author: Ethan · Last updated May 13, 2026
A company is serving files to its customers through an SFTP server that is accessible over the internet. The SFTP server is running on a single Amazon EC2 instance with an Elastic IP address attached. Customers connect to the SFTP server through its Elastic IP address and use SSH for authentication. The EC2 instance also has an attached security group that allows access from all customer IP addresses.
A solutions architect must implement a solution to improve availability, minimi...
The company needs to improve the availability, minimize infrastructure management complexity, and ensure minimal disruption to customers accessing files while keeping the customer connection process unchanged. Let's evaluate each solution based on these factors:
A) Disassociate the Elastic IP address from the EC2 instance. Create an Amazon S3 bucket to be used for SFTP file hosting. Create an AWS Transfer Family server. Configure the Transfer Family server with a publicly accessible endpoint. Associate the SFTP Elastic IP address with the new endpoint. Point the Transfer Family server to the S3 bucket. Sync all files from the SFTP server to the S3 bucket.
- Pros:
- AWS Transfer Family integrates well with S3 and provides a fully managed SFTP service.
- This solution abstracts away much of the infrastructure management by offloading the complexity of running and maintaining the SFTP server to AWS Transfer Family.
- Files stored in S3 are highly available and can scale automatically.
- Cons:
- This solution introduces a change in how customers connect to the service (i.e., they would now connect to the Transfer Family endpoint rather than the Elastic IP directly). The requirement specified that the connection method should not change.
- Use Case: This option is great for fully managed file hosting on S3, but it doesn’t meet the requirement to keep customer connection methods the same.
B) Disassociate the Elastic IP address from the EC2 instance. Create an Amazon S3 bucket to be used for SFTP file hosting. Create an AWS Transfer Family server. Configure the Transfer Family server with a VPC-hosted, internet-facing endpoint. Associate the SFTP Elastic IP address with the new endpoint. Attach the security group with customer IP addresses to the new endpoint. Point the Transfer Family server to the S3 bucket. Sync all files from the SFTP server to the S3 bucket.
- Pros:
- This solution uses AWS Transfer Family for SFTP hosting with S3, which simplifies infrastructure management and ensures scalability and high availability.
- It allows the use of a VPC-hosted internet-facing endpoint, ensuring secure and controlled access.
- The SFTP Elastic IP address is still retained and associated with the new endpoint, so customer connection methods remain unchanged.
- Cons:
- Similar to option A, while the connection method remains the same, the backend architecture is fully managed and uses Transfer Family, which might require some setup and testing to ensure smooth migration.
- Use Case: This option is highly suitable as it keeps customer connections unchanged while transitioning to a fully managed, scalable solution using Transfer Family and S3.
C) Disassociate the Elastic IP address from the EC2 instance. Create a new Amazon Elastic File System (Amazon EFS) file system to be used for SFTP file hosting. Create an AWS Fargate task definition to run an SFTP server. Specify the EFS file system as a mount in the task definition. Create a Fargate...
Author: IceDragon2023 · Last updated May 13, 2026
A company ingests and processes streaming market data. The data rate is constant. A nightly process that calculates aggregate statistics takes 4 hours to complete. The statistical analysis is not critical to the business, and data points are processed during the next iteration if a particular run fails.
The current architecture uses a pool of Amazon EC2 Reserved Instances with 1-year reservations. These EC2 instances run full time to ingest and store the streaming data in attached Amazon Elastic Block Store (Amazon EBS) volumes. A scheduled script launches EC2 On-Demand Instances each night to perform the nightly processing. The instances access the stored data from NFS shares on the inge...
To determine the most cost-effective solution, we need to evaluate the benefits and trade-offs of each option based on the following key factors:
1. Cost: The company is looking for the most cost-effective solution, particularly considering that the current Reserved Instances are expiring.
2. Scalability and Flexibility: The solution should scale easily and adapt to varying workloads.
3. Processing Requirements: The nightly process takes 4 hours, and the data analysis is not critical, meaning there's some flexibility in timing.
4. Simplicity of Management: The solution should minimize complexity in deployment and maintenance.
5. Fault Tolerance: The company prefers a design where data points can be reprocessed in case of failure, which aligns with using reliable and fault-tolerant AWS services.
Let’s analyze each option:
Option A:
Update the ingestion process to use Amazon Kinesis Data Firehose to save data to Amazon S3. Use a scheduled script to launch EC2 On-Demand Instances each night to perform the batch processing of the S3 data. Configure the script to terminate the instances when the processing is complete.
- Pros:
- Kinesis Data Firehose is a fully managed service for ingesting and storing data, which simplifies the ingestion process and offloads management.
- EC2 On-Demand Instances provide flexibility in scaling compute resources as needed for the batch processing.
- S3 is a cost-effective storage option, and using it for data storage reduces the complexity of managing NFS shares.
- Cons:
- EC2 On-Demand Instances can be costly for regular use, especially since the nightly processing lasts for 4 hours.
- The scheduled script adds management overhead and complexity.
- There's no cost optimization for the compute resources since On-Demand pricing can be high.
Option B:
Update the ingestion process to use Amazon Kinesis Data Firehose to save data to Amazon S3. Use AWS Batch with Spot Instances to perform nightly processing with a maximum Spot price that is 50% of the On-Demand price.
- Pros:
- AWS Batch is a managed service that simplifies batch processing and can scale the compute resources automatically.
- Spot Instances offer significant cost savings (up to 90% off On-Demand prices), which is ideal for non-critical processes like nightly aggregation that can tolerate interruptions.
- S3 storage is cost-effective and scalable.
- Cons:
- Spot Instances can be interrupted, although AWS Batch can handle this gracefully by resuming jobs, but it might introduce complexity in managing interruptions.
- There might still be some management overhead for configuring AWS Batch.
Option C:
Update the ingestion process to use a fleet of EC2 Reserved Instances with 3-year reservations behind a Network ...
Author: MysticJaguar44 · Last updated May 13, 2026
A company needs to migrate an on-premises SFTP site to AWS. The SFTP site currently runs on a Linux VM. Uploaded files are made available to downstream applications through an NFS share.
As part of the migration to AWS, a solutions architect must implement high availability. The solution must provide external vendors with a set of static public IP addresses that the vendors can allow. The company ha...
To meet the company's requirements of migrating an on-premises SFTP site to AWS while ensuring high availability and providing external vendors with static public IP addresses, let's evaluate the different options based on the key factors involved: high availability, public IP addresses for external vendors, operational overhead, and compatibility with NFS share configuration.
Key Requirements:
1. High Availability: The solution must be able to provide access from multiple availability zones (AZs) to ensure that the SFTP service is highly available.
2. Public IPs for Vendors: External vendors need a set of static public IPs that can be allowed by the vendors.
3. Operational Overhead: The solution should minimize operational overhead and management complexity, as the company is looking for an easy-to-manage setup.
4. NFS Compatibility: The downstream applications that currently access files via an NFS share need to continue to do so after the migration.
Option A: Create an AWS Transfer Family server. Configure an internet-facing VPC endpoint for the Transfer Family server. Specify an Elastic IP address for each subnet. Configure the Transfer Family server to place files into an Amazon Elastic File System (Amazon EFS) file system that is deployed across multiple Availability Zones. Modify the configuration on the downstream applications that access the existing NFS share to mount the EFS endpoint instead.
- Pros:
- The AWS Transfer Family is a managed service designed for SFTP with minimal operational overhead. It integrates with EFS, which supports NFS access and is highly available across multiple AZs.
- Elastic IP addresses (EIPs) can be allocated to the VPC subnets to meet the requirement for static public IPs.
- EFS is a fully managed, scalable, and highly available service that provides NFS compatibility, making it suitable for the downstream applications to access the files.
- Cons:
- Internet-facing VPC endpoint for Transfer Family may require more configuration for controlling access to the endpoint and handling any potential security concerns.
- Configuration changes to the downstream applications to mount EFS may require some effort.
- Scenario Fit: This is a solid option for reducing operational overhead with the AWS Transfer Family and leveraging EFS for high availability and NFS access.
Option B: Create an AWS Transfer Family server. Configure a publicly accessible endpoint for the Transfer Family server. Configure the Transfer Family server to place files into an Amazon Elastic File System (Amazon EFS) file system that is deployed across multiple Availability Zones. Modify the configuration on the downstream applications that access the existing NFS share to mount the EFS endpoint instead.
- Pros:
- Similar to Option A, AWS Transfer Family supports SFTP with minimal management.
- EFS provides high availability across multiple AZs, and supports NFS for downstream applications.
- A publicly accessible endpoint allows for easy access to the SFTP service.
- Cons:
- Publicly accessible endpoint means that the Transfer Family service will have a public IP. Although this simplifies access for vendors, it may not fully meet the security requirement of having static public IPs that vendors can allow. Managing security with this public endpoint could be more challenging.
- Scenario Fit: Alt...
