Amazon Practice Questions, Discussions & Exam Topics by our Authors
A company has a multi-tier web application. The application's internal service components are deployed on Amazon EC2 instances. The internal service components need to access third-party software as a service (SaaS) APIs that are hosted on AWS.
The company needs to provide secure and private connectivity from the application's internal services to the ...
Solution Overview:
The company needs to provide secure and private connectivity from its internal service components on Amazon EC2 instances to a third-party SaaS application hosted on AWS. The goal is to minimize public internet exposure, ensuring that the internal services can securely access the third-party service without having direct access via the public internet.
Analysis of the Options:
1. A) Implement an AWS Site-to-Site VPN to establish a secure connection with the third-party SaaS provider.
- Reasoning: An AWS Site-to-Site VPN is typically used to create a secure connection between an on-premises network and AWS. This option is not ideal for connecting to a third-party SaaS application because it is primarily designed for direct connections to an AWS VPC from external networks, not for accessing SaaS providers. Additionally, this option might expose public IP addresses and increase management complexity.
- When to use: This would be useful for connecting on-premises networks to AWS VPCs but not for connecting directly to a third-party SaaS provider.
- Why it's rejected: It’s not the optimal solution for private, secure connectivity to a third-party SaaS provider on AWS, which is the main requirement here.
2. B) Deploy AWS Transit Gateway to manage and route traffic between the application's VPC and the third-party SaaS provider.
- Reasoning: AWS Transit Gateway is designed for managing traffic between multiple VPCs, VPNs, and on-premises networks. It allows you to centralize the routing of traffic between multiple AWS VPCs. However, AWS Transit Gateway does not provide direct integration with third-party SaaS applications and would not be the best solution for private connectivity to such services.
- When to use: This is ideal for managing inter-VPC traffic or connecting on-premises data centers to AWS environments but not for direct connections to external SaaS providers.
- Why it's rejected: While useful for internal traffic management, it doesn’t directly address the need for private connectivity to third-party SaaS applications.
3. C) Configure AWS PrivateLink to allow only outbound traffic from the VPC without enabling the third-party SaaS provider to establish.
- Reasoning: AWS PrivateLink provides private connectivity to services across VPCs b...
Author: Vikram · Last updated Jul 12, 2026
A solutions architect needs to connect a company's corporate network to its VPC to allow on-premises access to its AWS resources. The solution must provide encryption of all traffic between the corporate network and the VPC at the network layer and the session layer. The solution also must provide sec...
Solution Overview:
The company needs a solution that connects its corporate network to its VPC, ensuring encrypted traffic between the on-premises network and AWS resources, with security controls to limit unrestricted access.
Analysis of the Options:
1. A) Configure AWS Direct Connect to connect to the VPC. Configure the VPC route tables to allow and deny traffic between AWS and on-premises as required.
- Reasoning: AWS Direct Connect provides a dedicated network connection between on-premises systems and AWS. However, while Direct Connect provides a private, low-latency connection, it does not automatically encrypt the traffic. Encryption would need to be implemented at the higher layers (e.g., using IPsec or application-level encryption). Moreover, Direct Connect lacks native security controls to enforce restrictions based on traffic patterns, which would need to be manually configured in the network layers.
- When to use: This is ideal when low-latency, high-throughput connections are required, and encryption can be handled externally.
- Why it's rejected: Direct Connect does not provide encryption out of the box at the network or session layer. It also requires manual management for security controls like route tables and ACLs, making it less ideal compared to other options that offer integrated security features.
2. B) Create an IAM policy to allow access to the AWS Management Console only from a defined set of corporate IP addresses. Restrict user access based on job responsibility by using an IAM policy and roles.
- Reasoning: This option focuses on controlling access to the AWS Management Console using IAM policies based on user identity and IP address. While it provides security at the user level for console access, it does not address the requirement for encrypted network communication between the on-premises systems and AWS resources. It’s not relevant for establishing a network connection.
- When to use: This would be useful for controlling access to the AWS Management Console for administrative users, not for securing network-level traffic.
- Why it's rejected: This option does not address the need for secure, encrypted connectivity between the corporate network and AWS VPC resources.
3. C) Configure AWS Site-to-Site VPN to connect to the VPC. Configure route table entries to direct traffic from on-premises to the VPC. Configure instance security groups and network ACLs to allow only requi...
Author: SolarFalcon11 · Last updated Jul 12, 2026
A company has a custom application with embedded credentials that retrieves information from a database in an Amazon RDS for MySQL DB cluster. The company needs to make the application more secure with minimal programming effort. The company has created cred...
To meet the company's requirement of improving security with minimal programming effort, let's evaluate each option:
A) Store the credentials in AWS Key Management Service (AWS KMS). Create keys in AWS KMS. Configure the application to load the database credentials from AWS KMS. Enable automatic key rotation.
- Rejection Reason: AWS KMS is designed for encryption key management, not for storing application credentials directly. It does not provide the functionality to store and manage credentials like AWS Secrets Manager or Parameter Store. Additionally, using KMS alone would require extra effort to manage and retrieve credentials securely, which doesn't align with the requirement of minimal programming effort.
B) Store the credentials in encrypted local storage. Configure the application to load the database credentials from the local storage. Set up a credentials rotation schedule by creating a cron job.
- Rejection Reason: Storing credentials in local storage can lead to security risks, especially if the application is not properly secured and encrypted. The method of setting up cron jobs for rotating credentials is not a best practice, as it is prone to errors and can lead to operational overhead. There is also an increased risk of exposing credentials during rotation.
C) Store the credentials in AWS Secrets Manager. Configure the application to load the database credentials from Secrets Manager. Set up a credentials rotation schedule by creating an AWS Lambda function for Secrets Manager.
- Selected Option: AWS Secrets Manager is a fully managed service designed to store and rotate credentials securely. It simplifies credential management by allowing automated credential rotation via Lambda functions. This option meets the company's security r...
Author: Scarlett · Last updated Jul 12, 2026
A company wants to move its application to a serverless solution. The serverless solution needs to analyze existing data and new data by using SQL. The company stores the data in an Amazon S3 bucket. The data must be encrypted at rest and replicated t...
To meet the company's requirements with the least operational overhead, let's evaluate each option:
Key Requirements:
1. Serverless solution: The company seeks a serverless solution to handle data queries.
2. SQL-based querying: The solution must be able to analyze data using SQL.
3. Encrypted at rest: Data must be securely stored, encrypted at rest.
4. Cross-region replication: The data should be replicated to a different AWS Region.
5. Minimal operational overhead: The solution should minimize the need for complex configuration and management.
Option Evaluation:
A) Create a new S3 bucket that uses server-side encryption with AWS KMS multi-Region keys (SSE-KMS). Configure Cross-Region Replication (CRR). Load the data into the new S3 bucket. Use Amazon Athena to query the data.
- Selected Option: Amazon Athena is a fully managed, serverless query service designed specifically for running SQL queries directly on data stored in Amazon S3.
- Encryption: SSE-KMS provides a higher level of security for sensitive data as it uses AWS Key Management Service to manage encryption keys and allows for multi-Region key management, which is a good fit for the encryption requirements.
- Cross-Region Replication (CRR): This option supports data replication across AWS Regions using CRR, ensuring that the data is available in multiple regions.
- Operational Overhead: Athena is serverless and does not require managing infrastructure, so it significantly reduces operational overhead. The use of KMS for encryption is straightforward, and CRR on the S3 bucket is easy to configure.
- Why It's Best: Athena directly supports SQL queries on S3 data, and it works well with cross-region replication. This solution is highly scalable, secure, and minimizes operational burden.
B) Create a new S3 bucket that uses server-side encryption with Amazon S3 managed keys (SSE-S3). Configure Cross-Region Replication (CRR). Load the data into the new S3 bucket. Use Amazon RDS to query the data.
- Rejection Reason: While SSE-S3 provides encryption, it lacks the advanced control and flexibility of SSE-KMS, such as managing keys or multi-region encryption. Using Amazon RDS instead of Athena introduces more operational overhead since RDS is not serverless, requiring the management of databases and resources....
Author: Elijah · Last updated Jul 12, 2026
A company has a web application that has thousands of users. The application uses 8-10 user-uploaded images to generate AI images. Users can download the generated AI images once every 6 hours. The company also has a premium user option that gives users the ability to download the generated AI images anytime.
The company uses the user-uploaded images to run AI mo...
To determine the most cost-effective storage solution for the company's web application, we need to evaluate the storage options based on several factors:
Key Requirements:
1. Cost-effectiveness: The solution should minimize costs while meeting the needs for storage and access patterns.
2. Frequent and Infrequent Access: Different types of images need to be accessed with different frequency:
- Premium users: Must have immediate access to generated AI images at any time.
- Non-premium users: Can only download AI images once every 6 hours, which makes their images "infrequent access."
- Uploaded images: Used for AI model training twice a year, suggesting very infrequent access.
3. Data Storage: Different data needs to be stored at different access levels, so we should choose the most appropriate storage classes for each.
Let's evaluate each option:
---
A) Move uploaded images to Amazon S3 Glacier Deep Archive. Move premium user-generated AI images to S3 Standard. Move non-premium user-generated AI images to S3 Standard-Infrequent Access (S3 Standard-IA).
- Analysis:
- Uploaded images (S3 Glacier Deep Archive): Since uploaded images are rarely accessed (used twice a year for training), S3 Glacier Deep Archive is a good choice for the most cost-effective long-term storage. This class is designed for extremely low-cost, long-term storage with retrieval times of hours.
- Premium user-generated AI images (S3 Standard): Premium users require immediate access, so S3 Standard is appropriate for these images due to the frequent access requirement.
- Non-premium user-generated AI images (S3 Standard-IA): Non-premium images are accessed less frequently (once every 6 hours), so S3 Standard-IA is ideal. It is cheaper than S3 Standard and designed for infrequent access, providing a balance of cost and retrieval speed.
- Why this is the best option: This option effectively uses the correct storage classes based on access patterns, balancing cost and performance. Premium images are stored in S3 Standard for fast access, while non-premium images are stored in S3 Standard-IA, and uploaded images are stored in Glacier Deep Archive for very low-cost long-term storage.
---
B) Move uploaded images to Amazon S3 Glacier Deep Archive. Move all generated AI images to S3 Glacier Flexible Retrieval.
- Analysis:
- Uploaded images (S3 Glacier Deep Archive): Again, this is appropriate for long-term storage of uploaded images due to infrequent access.
- All generated AI images (S3 Glacier Flexible Retrieval): Storing all generated AI images in S3 Glacier Flexible Retrieval is a poor choice be...
Author: StarlightBear · Last updated Jul 12, 2026
A company is developing machine learning (ML) models on AWS. The company is developing the ML models as independent microservices. The microservices fetch approximately 1 GB of model data from Amazon S3 at startup and load the data into memory. Users access the ML models through an asynchronous API. Users can send a request or a batch of requests.
The company provides the ML models to hundreds of users. The usage patterns f...
To determine which solution meets the company's requirements for developing and scaling machine learning (ML) models as independent microservices, let's evaluate each option with the following key factors:
Key Requirements:
1. Irregular usage patterns: Some models are not used for extended periods, while others may receive large batches of requests at a time.
2. Scaling: The solution needs to efficiently scale to handle both low and high loads without excessive overhead.
3. Data loading: Each model loads approximately 1 GB of model data at startup, so the solution must be able to handle this efficiently.
4. Asynchronous access: Users interact with the models via asynchronous APIs, so the solution must accommodate handling multiple requests and processing them efficiently.
5. Cost efficiency: The solution should be cost-effective, especially when handling irregular usage patterns.
Option Analysis:
---
A) Direct the requests from the API to a Network Load Balancer (NLB). Deploy the ML models as AWS Lambda functions that the NLB will invoke. Use auto scaling to scale the Lambda functions based on the traffic that the NLB receives.
- Rejection Reason: While AWS Lambda can handle unpredictable workloads and scale automatically, it’s not well-suited for 1 GB of model data that needs to be loaded into memory. Lambda functions have a memory limit (maximum of 10 GB), and loading large data sets into memory could lead to performance issues or out-of-memory errors. Additionally, Lambda functions have a cold start time, which could be problematic for workloads that require fast response times, particularly with the large data loading involved.
- Why rejected: Lambda is not optimal for applications that require loading large models into memory due to the inherent startup latency and memory limitations.
---
B) Direct the requests from the API to an Application Load Balancer (ALB). Deploy the ML models as Amazon Elastic Container Service (Amazon ECS) services that the ALB will invoke. Use auto scaling to scale the ECS cluster instances based on the traffic that the ALB receives.
- Selected Option: Amazon ECS is a better fit for this scenario as it allows the company to deploy microservices using containers. ECS can manage the models, and auto scaling can be used to adjust the number of containers based on traffic, which helps address both high and low usage periods. Since the models require 1 GB of data to be loaded into memory at startup, ECS services running on EC2 instances are better suited for handling large memory loads compared to Lambda.
- Why this is the best option: ECS provides more control over re...
Author: John · Last updated Jul 12, 2026
A company runs a web application on Amazon EC2 instances in an Auto Scaling group behind an Application Load Balancer (ALB). The application stores data in an Amazon Aurora MySQL DB cluster.
The company needs to create a disaster recovery (DR) solution. The acceptable recovery time for the DR solution is up to 30 minutes. The ...
To design a disaster recovery (DR) solution with a recovery time objective (RTO) of up to 30 minutes, the solution needs to minimize downtime, allow for fast failover, and meet the company's needs for minimal customer impact. Let’s evaluate each option based on the provided criteria:
Key Requirements:
1. Recovery time of up to 30 minutes: The solution must allow for quick failover between primary and secondary infrastructure.
2. Active-passive or active-active failover: The DR solution should have a mechanism to quickly failover to the secondary infrastructure when needed.
3. Minimal operational overhead: The solution should minimize complexity and not require significant ongoing maintenance when the primary infrastructure is healthy.
4. Aurora MySQL as the database: The DR solution should ensure that the Aurora MySQL DB cluster is replicated and available in the secondary region if failover is needed.
Option Evaluation:
---
A) Deploy the DR infrastructure in a second AWS Region with an ALB and an Auto Scaling group. Set the desired capacity and maximum capacity of the Auto Scaling group to a minimum value. Convert the Aurora MySQL DB cluster to an Aurora global database. Configure Amazon Route 53 for an active-passive failover with ALB endpoints.
- Analysis:
- Auto Scaling and ALB: The Auto Scaling group is deployed with minimal capacity, which minimizes cost when the primary region is healthy. This approach ensures the DR infrastructure is ready to scale up quickly when needed.
- Aurora Global Database: Aurora global databases allow for low-latency replication across regions, with automatic failover to the secondary region. This ensures that the database will be available in the DR region in the event of a failure.
- Route 53 for Active-Passive Failover: Route 53 can be configured for active-passive failover, where the secondary region is only used when the primary region becomes unavailable. This approach minimizes cost and resources when the primary region is healthy but provides fast failover in the event of failure.
- Why this option is ideal: The Aurora global database combined with active-passive failover via Route 53 provides a solution with minimal operational overhead, quick recovery, and low-cost DR infrastructure when the primary region is healthy.
---
B) Deploy the DR infrastructure in a second AWS Region with an ALB and an Auto Scaling group. Update the Auto Scaling group to include EC2 instances from the second region. Use Amazon Route 53 to configure active-active failover. Convert the Aurora MySQL DB cluster to an Aurora global database.
- Analysis:
- Active-Active Failover: In an active-active setup, both regions are handling traffic simultaneously. This increases complexity and cost, especially when the primary region is healthy, as both regions would need to maintain EC2 instances in the Auto Scaling group and ALB endpoints.
- Aurora Global Database: This would provide database replication, but using active...
Author: Noah Williams · Last updated Jul 12, 2026
A company is migrating its data processing application to the AWS Cloud. The application processes several short-lived batch jobs that cannot be disrupted. Data is generated after each batch job is completed. The data is accessed for 30 days and retained for 2 years.
The company wants to...
Let's break down each of the options in terms of cost, availability, and compliance with the company's requirements.
Key Requirements:
1. Short-lived batch jobs: The jobs should not be disrupted.
2. Data access for 30 days: Data needs to be easily accessible within 30 days.
3. Data retention for 2 years: Data is retained for a period of 2 years.
4. Cost efficiency: The company wants to keep costs low.
---
Option A: Migrate the data processing application to Amazon EC2 Spot Instances. Store the data in Amazon S3 Standard. Move the data to Amazon S3 Glacier Instant Retrieval after 30 days. Set an expiration to delete the data after 2 years.
- EC2 Spot Instances: These are suitable for workloads that can tolerate interruptions, but since these batch jobs are short-lived and cannot be disrupted, Spot Instances may cause issues due to potential termination, which makes this option risky.
- S3 Standard for storage: S3 Standard is typically more expensive than other storage tiers like Glacier. It’s ideal for frequently accessed data, but it doesn’t match the requirement for long-term storage cost-efficiency.
- S3 Glacier Instant Retrieval: While it offers low-latency retrieval, it’s more expensive than S3 Glacier Flexible Retrieval for long-term data that isn’t frequently accessed.
- S3 Glacier Instant Retrieval after 30 days: Not the most cost-effective choice for storage that is retained for two years. A better option would be S3 Glacier Flexible Retrieval or S3 Glacier Deep Archive.
Reason for rejection: EC2 Spot Instances are unsuitable for this workload, and Glacier Instant Retrieval is too expensive for long-term storage.
---
Option B: Migrate the data processing application to Amazon EC2 On-Demand Instances. Store the data in Amazon S3 Glacier Instant Retrieval. Move the data to S3 Glacier Deep Archive after 30 days. Set an expiration to delete the data after 2 years.
- EC2 On-Demand Instances: These offer guaranteed availability and are suitable for applications where you cannot afford interruptions, like in this case with the short-lived batch jobs. However, they are more expensive than Spot Instances.
- S3 Glacier Instant Retrieval: Again, this is more expensive than Glacier Flexible Retrieval or Glacier Deep Archive for long-term data storage.
- Move to Glacier Deep Archive after 30 days: This is cost-effective for long-term storage, but the initial use of Glacier Instant Retrieval does...
Author: Aarav · Last updated Jul 12, 2026
A company needs to design a hybrid network architecture. The company's workloads are currently stored in the AWS Cloud and in on-premises data centers. The workloads require single-digit latencies to communicate. The company uses an AWS Transit Gateway transit gateway to c...
Key Requirements:
1. Hybrid network architecture: The company has workloads in both AWS and on-premises data centers.
2. Single-digit latencies: The connection between the on-premises data centers and AWS must have low latency.
3. Cost-effectiveness: The solution should be cost-effective while meeting latency requirements.
4. AWS Transit Gateway: The company already uses a transit gateway to connect multiple VPCs.
---
Option A: Establish an AWS Site-to-Site VPN connection to each VPC.
- VPN Connection: While Site-to-Site VPN connections are commonly used to connect on-premises networks to AWS, they typically do not provide the low latencies required for single-digit latency communication. VPNs are encrypted and can introduce some overhead, impacting latency.
- Cost-effective: This option may seem cost-effective in the short term, but for low-latency requirements, it may not meet the performance goals, and the cost of managing multiple VPNs across VPCs can add up.
Reason for rejection: VPN connections do not guarantee low latencies and may not be ideal for single-digit latency requirements.
---
Option B: Associate an AWS Direct Connect gateway with the transit gateway that is attached to the VPCs.
- Direct Connect Gateway: This is a good choice for a hybrid cloud architecture that requires low-latency, high-bandwidth communication. Direct Connect offers dedicated network connections, providing a more stable and predictable network performance compared to VPNs.
- Cost-effectiveness: Although Direct Connect involves a higher initial setup cost, it can be more cost-effective in the long run for high-performance networking, particularly when you need consistent low latency.
- Integration with Transit Gateway: Associating the Direct Connect gateway with the Transit Gateway ensures seamless connectivity between on-premises data centers and multiple VPCs in AWS, without the complexity of managing multiple VPN connections.
Reason for selection: This option provides the low latency and high performance needed while integrating well with the existing Transit Gateway.
---
Option C: Establish an AWS Site-to-Site VPN connection to an AWS Direct Connect gateway.
- VPN with Direct Connect Gateway: While Direct Connect Gateway can connect multiple VPCs and on-premises environments, adding a VPN connection on top of it is unnecessary and adds ...
Author: Deepak · Last updated Jul 12, 2026
A global ecommerce company runs its critical workloads on AWS. The workloads use an Amazon RDS for PostgreSQL DB instance that is configured for a Multi-AZ deployment.
Customers have reported application timeouts when the company undergoes database failovers...
Key Requirements:
1. Resilient solution: The company needs a solution that can reduce failover time during database failovers.
2. Reduce application timeouts: Customers are experiencing application timeouts during database failovers, so the goal is to minimize downtime and reduce the duration of failover events.
Option A: Create an Amazon RDS Proxy. Assign the proxy to the DB instance.
- Amazon RDS Proxy: RDS Proxy acts as an intermediary between the application and the RDS database. It helps to improve application availability and reduce failover time by managing database connections and pooling them effectively. During a failover event, RDS Proxy will redirect connections to the new primary database, reducing the downtime and mitigating application timeouts. This approach can significantly reduce the time applications experience connectivity issues during a failover.
- Resilience and Performance: RDS Proxy helps to manage failovers more seamlessly by quickly rerouting database connections to the new primary instance, reducing the failover impact on applications.
Reason for selection: This is the most suitable solution for reducing failover time and mitigating application timeouts. RDS Proxy improves availability by efficiently managing database connections during failovers.
---
Option B: Create a read replica for the DB instance. Move the read traffic to the read replica.
- Read Replica: A read replica is a copy of the primary database that can be used for read traffic. While this solution can offload read traffic from the primary database, it does not directly address failover times or prevent application timeouts during a failover event. Read replicas can be promoted to become the new primary instance during failovers, but promoting the replica can take time, leading to additional downtime and longer failover durations.
- Failover Delay: The failover process itself still takes time to promote the read replica and reroute traffic, which may not address the critical need for reducing application timeouts during failovers.
Reason for rejection: While read replica...
Author: Benjamin · Last updated Jul 12, 2026
A company has multiple Amazon RDS DB instances that run in a development AWS account. All the instances have tags to identify them as development resources. The company needs the development DB instances to run on a schedule only durin...
Key Requirements:
1. Development DB instances: These instances should only run during business hours.
2. Least operational overhead: The solution should be easy to implement and manage, without requiring significant manual intervention.
3. Automated start/stop: The company needs to automate the start and stop process based on a schedule.
Option A: Create an Amazon CloudWatch alarm to identify RDS instances that need to be stopped. Create an AWS Lambda function to start and stop the RDS instances.
- CloudWatch Alarm: CloudWatch alarms are typically used to monitor resource metrics and trigger actions based on thresholds. While you could use CloudWatch to detect certain events (like high CPU usage or storage), using it to identify when to stop or start RDS instances based solely on a schedule (business hours) adds unnecessary complexity.
- Lambda Functions: Lambda functions can automate the start and stop process. However, combining CloudWatch alarms with Lambda would require additional setup to manage the schedule logic, and this introduces complexity that could be avoided with a simpler solution.
Reason for rejection: This approach introduces unnecessary complexity by relying on alarms to trigger actions that could be based on a fixed schedule. It also requires continuous monitoring and management of alarm conditions.
---
Option B: Create an AWS Trusted Advisor report to identify RDS instances to be started and stopped. Create an AWS Lambda function to start and stop the RDS instances.
- AWS Trusted Advisor: Trusted Advisor provides best practice recommendations for optimizing AWS resources, but it does not directly support scheduling the start or stop of instances based on specific times, like business hours. It is more focused on cost optimization, security, and performance, not on operational scheduling.
- Lambda Functions: Lambda could be used to automate the start and stop of RDS instances, but using Trusted Advisor reports for scheduling is inefficient and not purpose-built for the task.
Reason for rejection: Trusted...
Author: CrimsonViperX · Last updated Jul 12, 2026
A consumer survey company has gathered data for several years from a specific geographic region. The company stores this data in an Amazon S3 bucket in an AWS Region.
The company has started to share this data with a marketing firm in a new geographic region. The company has granted the firm's AWS account access to the S3 bucket. The compan...
Key Requirements:
1. Minimize data transfer costs: The company wants to minimize the cost of data transfer when the marketing firm requests data from the S3 bucket.
2. Access control: The company has already granted the marketing firm's AWS account access to the S3 bucket.
---
Option A: Configure the Requester Pays feature on the company’s S3 bucket.
- Requester Pays: When the Requester Pays feature is enabled on an S3 bucket, the requester (in this case, the marketing firm) is responsible for the data transfer and request costs when accessing the data.
- Cost Implications: This option shifts the data transfer costs to the marketing firm, which is not the goal here. The company likely wants to minimize its own data transfer costs, rather than transferring this cost to the marketing firm.
Reason for rejection: The Requester Pays feature would place the cost burden on the marketing firm, which is counterproductive if the goal is for the company to minimize its own data transfer costs.
---
Option B: Configure S3 Cross-Region Replication (CRR) from the company’s S3 bucket to one of the marketing firm’s S3 buckets.
- Cross-Region Replication (CRR): This solution replicates objects from the company’s S3 bucket in one AWS Region to another AWS Region (where the marketing firm’s S3 bucket is located). By doing so, the marketing firm can access the data locally within its AWS Region, thus reducing data transfer costs for both the company and the marketing firm.
- Cost Efficiency: This reduces the transfer costs for the marketing firm, as accessing data locally within its Region avoids inter-region data transfer costs. However, it introduces the cost of replication itself, which could add additional charges.
- Replication Overhead: While the replication setup could incur costs, it is more efficient than data transfer over the internet, as data within the same Region is free, and replication happens automatically in the background.
Reason for selection: This is the most cost-effective and scalable solution to minimize data transfer costs between Regions, as it allows the marketing firm to access the d...
Author: James · Last updated Jul 12, 2026
A company uses AWS to host its public ecommerce website. The website uses an AWS Global Accelerator accelerator for traffic from the internet. The Global Accelerator accelerator forwards the traffic to an Application Load Balancer (ALB) that is the entry point for an Auto Scaling group.
The company recently identified a DDoS attack on the w...
Let's evaluate the options based on the scenario provided, keeping in mind the goal of mitigating DDoS attacks with the least implementation effort:
Option A: Configure an AWS WAF web ACL for the Global Accelerator accelerator to block traffic by using rate-based rules
- Explanation: AWS WAF (Web Application Firewall) can be applied at the Global Accelerator level to help mitigate DDoS attacks. Configuring a WAF Web ACL with rate-based rules will allow for traffic filtering by identifying and mitigating abusive traffic patterns based on request rates.
- Why it's a good choice: Global Accelerator works by forwarding traffic to your Application Load Balancer (ALB). Adding AWS WAF at the Global Accelerator level allows for filtering of malicious traffic before it reaches the ALB and Auto Scaling group. This option directly addresses DDoS threats without additional configuration complexity. It's also a managed solution by AWS, making it easy to implement with minimal operational effort.
- Why not other options: This approach works in a way that directly addresses the DDoS attack scenario and integrates into the existing architecture with minimal changes.
Option B: Configure an AWS Lambda function to read the ALB metrics to block attacks by updating a VPC network ACL
- Explanation: While Lambda can be used to automate responses to metrics from the ALB, including potentially modifying VPC network ACLs, this option adds complexity.
- Why it's less ideal: Monitoring ALB metrics and reacting to attack patterns with Lambda introduces custom logic and operational overhead. Network ACLs also operate at the subnet level, which means that updating them dynamically may not be efficient for addressing application-level DDoS attacks. Moreover, this option adds more custom development and doesn't leverage manag...
Author: Victoria · Last updated Jul 12, 2026
A company uses an Amazon DynamoDB table to store data that the company receives from devices. The DynamoDB table supports a customer-facing website to display recent activity on customer devices. The company configured the table with provisioned throughput for writes and reads.
The company wants to calculate performance metrics for customer device data o...
Let's evaluate the options based on the company's requirement to calculate performance metrics for customer device data on a daily basis with minimal effect on the table's provisioned read and write capacity:
Option A: Use an Amazon Athena SQL query with the Amazon Athena DynamoDB connector to calculate performance metrics on a recurring schedule.
- Explanation: Amazon Athena allows you to run SQL queries directly on data stored in Amazon S3. With the Athena DynamoDB connector, you can query data from DynamoDB tables, and Athena can execute the queries without consuming DynamoDB provisioned throughput, as it reads the data from DynamoDB in a way that doesn't impact its operational capacity.
- Why it's a good choice: Athena is serverless, so there’s no need to provision resources for running queries. It integrates well with DynamoDB via the connector, and queries are executed without affecting DynamoDB's performance. You can schedule recurring queries using AWS services like AWS Lambda or Amazon CloudWatch Events. This approach minimizes impact on DynamoDB capacity and is easy to scale.
- Why not other options: Athena's serverless nature makes it an ideal choice for this type of use case where minimizing operational overhead and impact on provisioned capacity is critical. Other options might require more effort in resource management and could put a greater load on DynamoDB.
Option B: Use an AWS Glue job with the AWS Glue DynamoDB export connector to calculate performance metrics on a recurring schedule.
- Explanation: AWS Glue can extract, transform, and load (ETL) data from DynamoDB. The Glue DynamoDB connector allows you to pull data from DynamoDB into a data lake or warehouse. However, the export process can consume throughput on DynamoDB, especially if you're pulling large amounts of data.
- Why it's less ideal: While AWS Glue is effective for ETL tasks and does provide automated scheduling, it will consume read capacity on DynamoDB to extract data. For large datasets or frequent extraction, this could negatively affect the table’s provisioned throughput and the performance of the live customer-facing application. Additionally, the ...
Author: Amira · Last updated Jul 12, 2026
A solutions architect is designing the cloud architecture for a new stateless application that will be deployed on AWS. The solutions architect created an Amazon Machine Image (AMI) and launch template for the application.
Based on the number of jobs that need to be processed, the processing must run in parallel while adding and removing application Amaz...
Let's evaluate each option based on the requirements of the stateless application:
Key Requirements:
1. Stateless application: This implies that the application can scale horizontally and doesn’t need to rely on any local state.
2. Parallel processing: Multiple instances should process jobs in parallel.
3. Durable job storage: Jobs should be stored in a way that ensures they are not lost.
4. Auto-scaling based on job load: EC2 instances should be added or removed automatically based on the number of jobs to be processed.
Option A: Create an Amazon Simple Notification Service (Amazon SNS) topic to send the jobs that need to be processed. Create an Auto Scaling group by using the launch template with the scaling policy set to add and remove EC2 instances based on CPU usage.
- Explanation: SNS is a messaging service where subscribers (EC2 instances) receive notifications. However, SNS doesn’t store messages, so jobs could be missed if no EC2 instances are available to receive them. The auto-scaling policy based on CPU usage is not directly related to job load and may not scale effectively for the number of jobs being processed.
- Why it's less ideal: SNS is more suited for real-time notifications rather than queuing jobs for parallel processing. Additionally, scaling based on CPU usage may not align with the number of jobs being processed, which is the more appropriate metric to trigger scaling.
Option B: Create an Amazon Simple Queue Service (Amazon SQS) queue to hold the jobs that need to be processed. Create an Auto Scaling group by using the launch template with the scaling policy set to add and remove EC2 instances based on network usage.
- Explanation: SQS is designed to hold messages (or jobs in this case) durably, and EC2 instances can pull jobs from the queue to process them. However, scaling based on network usage is not a reliable metric for job load. Network usage doesn’t correlate well with the number of jobs or their processing rate.
- Why it's less ideal: While SQS is a good choice for durable job storage, scaling based on network usage doesn’t align with the job queue length or processing demand. Using network usage may lead to inefficient scaling and cause overprovisioning or underprovisioning of EC2 instances.
Option C: Create an Amazon Simple Queue Service (Amazon SQS) queue to hold the jobs that need to be processed. Create an Auto S...
Author: FlamePhoenix2025 · Last updated Jul 12, 2026
A global ecommerce company uses a monolithic architecture. The company needs a solution to manage the increasing volume of product data. The solution must be scalable and have a modular service architecture. The company needs to maintain its structured database schemas. The company also needs a storage so...
Let's evaluate each option based on the requirements for scalability, modularity, maintaining structured database schemas, and a solution with the least operational overhead:
Option A: Use an Amazon EC2 instance in an Auto Scaling group to deploy a containerized application. Use an Application Load Balancer to distribute web traffic. Use an Amazon RDS DB instance to store product data and product images.
- Explanation: This option suggests using EC2 instances in an Auto Scaling group for application deployment, which can scale based on load. It uses Amazon RDS for structured database storage and product image storage on RDS as well.
- Why it’s less ideal: Using EC2 instances for hosting the application means more infrastructure management overhead. Managing EC2 instances, Auto Scaling, and an Application Load Balancer involves more operational complexity compared to fully managed services. Additionally, storing product images on RDS is not the most optimal solution because RDS is designed for structured data, not for storing large files like images, which can lead to inefficiency.
Option B: Use AWS Lambda functions to manage the existing monolithic application. Use Amazon DynamoDB to store product data and product images. Use Amazon Simple Notification Service (Amazon SNS) for event-driven communication between the Lambda functions.
- Explanation: This option suggests using AWS Lambda for managing the monolithic application, along with DynamoDB for storing product data and images. SNS would be used for event-driven communication between the Lambda functions.
- Why it’s less ideal: AWS Lambda is typically used for stateless, event-driven applications, and applying it to a monolithic architecture may introduce unnecessary complexity. Lambda is also not ideal for managing a large monolithic application due to execution time limits and state management challenges. Additionally, storing product images in DynamoDB is not ideal because DynamoDB is optimized for structured data and not large binary objects like images.
Option C: Use Amazon Elastic Kubernetes Service (Amazon EKS) with an Amazon EC2 deployment to deploy a containerized application. Use an Amazon Aurora cluster to store the product data. Use AWS Step Functions to manage workflows. Store the product images in Amazon S3 Glacier Deep Archive.
- Explanation: This option uses EKS to deploy the contain...
Author: Liam · Last updated Jul 12, 2026
A company is migrating an application from an on-premises environment to AWS. The application will store sensitive data in Amazon S3. The company must encrypt the data before st...
Let’s evaluate each option based on the requirement to encrypt sensitive data before storing it in Amazon S3:
Key Considerations:
- Data encryption before storing in S3: The data must be encrypted before being uploaded to Amazon S3.
- Security of the encryption keys: The company should have control over encryption keys or use AWS-managed options that provide security and compliance.
- Compliance and management: The solution must comply with industry standards and allow the company to manage keys securely.
Option A: Encrypt the data by using client-side encryption with customer managed keys.
- Explanation: Client-side encryption means that the data is encrypted before it is sent to S3. The company manages the encryption keys on the client side.
- Why it’s a good choice: This method gives the company full control over the encryption process and key management. Data is encrypted on the client side before being uploaded to S3, ensuring that sensitive data is encrypted before storage.
- Why it’s a better choice: Client-side encryption with customer-managed keys provides flexibility and control over the keys and the encryption process. However, it requires the company to handle encryption and key management, which might increase operational complexity.
- Ideal Scenario: If the company has specific requirements for key management and does not want to rely on AWS’s key management systems, this option would be suitable.
Option B: Encrypt the data by using server-side encryption with AWS KMS keys (SSE-KMS).
- Explanation: Server-side encryption with AWS KMS (SSE-KMS) means that data is encrypted on the server side before it is stored in S3, with keys managed by AWS KMS.
- Why it’s less ideal: This option provides encryption at rest managed by AWS, but it doesn't meet the requirement of encrypting the data before uploading to S3, as the data is encrypted after being received by S3. It also uses AWS KMS, which gives the company less control over key management compared to client-side encryption with customer-managed keys.
- Ideal Scenario: This is ideal if...
Author: Sam · Last updated Jul 12, 2026
A company wants to create an Amazon EMR cluster that multiple teams will use. The company wants to ensure that each team's big data workloads can access only the AWS services that each team needs to interact with. The company does not want the workloads to have access to Instance Met...
To meet the requirements of the company, we need to ensure two things:
1. Access Control: Each team’s big data workloads should only be able to interact with the AWS services they specifically need.
2. Instance Metadata Service (IMDS): The company doesn’t want the workloads to have access to IMDSv2, which is used to get metadata about the EC2 instances.
Let’s break down the given options:
Option A: Configure interface VPC endpoints for each AWS service that the teams need. Use the required interface VPC endpoints to submit the big data workloads.
- Explanation: Interface VPC endpoints allow you to securely connect to AWS services from within a VPC without using public IP addresses. This option restricts traffic between the cluster and the AWS services via private IPs, ensuring that each team can only access the services they need.
- IMDSv2 Control: This option does not directly address the issue of restricting access to IMDSv2, which is a separate concern. However, this solution still allows control over service access by using VPC endpoints.
- Use Case: This option is useful when the company wants to manage access to specific AWS services at a granular level. However, it does not prevent IMDSv2 access by default, so it doesn't fully address the second requirement.
Option B: Create EMR runtime roles. Configure the cluster to use the runtime roles. Use the runtime roles to submit the big data workloads.
- Explanation: EMR runtime roles can be assigned to specific roles to manage permissions and provide access to AWS services. This solution isolates permissions at the EMR job level, so each team can only interact with the services they need.
- IMDSv2 Control: The runtime role configuration itself does not prevent access to IMDSv2, meaning it doesn’t fully solve the issue of restricting instance metadata access.
- Use Case: This option is useful for managing permissions at the EMR job level, but it doesn’t directly address the need to prevent IMDSv2 access.
Option C: Create an EC2 IAM instance profile that has the required permissions for each team. Use the instance profile to submit the big data workloads.
- Explanation: An EC2 IAM instance profile provides the necessary perm...
Author: Scarlett · Last updated Jul 12, 2026
A solutions architect is designing an application that helps users fill out and submit registration forms. The solutions architect plans to use a two-tier architecture that includes a web application server tier and a worker tier.
The application needs to process submitted forms quickly. The application ne...
Problem Analysis
The application needs to:
1. Process each form exactly once: Ensuring no duplication or loss of data is essential.
2. Process the form quickly: The system should handle high throughput efficiently without delays.
3. Ensure no data loss: The solution should provide durability to ensure that no form is lost, even during failures.
Let's analyze each option:
Option A: Use an Amazon Simple Queue Service (Amazon SQS) FIFO queue between the web application server tier and the worker tier to store and forward form data.
- Explanation: FIFO queues in Amazon SQS ensure that messages are processed exactly once and in the order they are received, providing strong delivery guarantees. The FIFO queue prevents duplicate messages and ensures data is not lost.
- Why it meets the requirements:
- Exactly-once processing: FIFO queues guarantee that each form is processed exactly once and in the correct order.
- Durability: SQS stores messages durably, preventing data loss even if there is a failure.
- Scalability: While FIFO queues are generally not as scalable as standard queues, they can handle moderate throughput needs and are ideal for use cases where order and exactly-once processing are crucial.
- Use Case: This is the ideal solution for the scenario where forms must be processed exactly once without losing data.
Option B: Use an Amazon API Gateway HTTP API between the web application server tier and the worker tier to store and forward form data.
- Explanation: API Gateway is typically used to create RESTful APIs that expose HTTP endpoints for client communication. While it can forward data, it’s not designed for reliable, message-based processing of large workloads.
- Why it doesn't meet the requirements:
- Data Loss: API Gateway does not inherently provide message durability or reliability, meaning it could lead to data loss if the worker tier is unavailable.
- Exactly-once processing: It doesn’t guarantee exactly-once delivery of data, as there’s no queueing mechanism.
- Performance: It's not optimized for high-throughput processing and might introduce latency in real-time data processing.
- Use Case: This option is suitable for creating simple APIs but not for processing data reliably, especially where exactly-once processing and durability are important.
Option C: Use an Amazon Simple Queue Service (Amazon SQS) standard queue between the web application server tier and th...
Author: Aarav2020 · Last updated Jul 12, 2026
A finance company uses an on-premises search application to collect streaming data from various producers. The application provides real-time updates to search and visualization features.
The company is planning to migrat...
Problem Analysis
The company needs a solution that:
1. Ingests and processes streaming data: The data comes from various producers in real time.
2. Provides real-time updates to search and visualization features: The solution must be able to quickly process, search, and visualize the data.
3. Migrates to AWS: The company wants to leverage AWS-native solutions rather than on-premises infrastructure.
Let's analyze each option:
Option A: Use Amazon EC2 instances to ingest and process the data streams to Amazon S3 buckets for storage. Use Amazon Athena to search the data. Use Amazon Managed Grafana to create visualizations.
- Explanation: EC2 instances can be used to ingest and process streaming data and store it in Amazon S3. Amazon Athena would allow querying the data in S3 using SQL, and Amazon Managed Grafana could be used for visualizations.
- Why it doesn’t meet the requirements:
- Latency: EC2 instances are not the best option for handling real-time data streams at scale, and while S3 + Athena can work for batch processing, it's not suitable for real-time search and visualization. Athena is designed for querying data stored in S3 but is not optimized for real-time querying or frequent updates.
- Real-time processing: This architecture does not natively support real-time data ingestion and processing.
- Use Case: This solution might work for ad-hoc querying and data visualization over stored data, but it is not ideal for real-time data streams and updates.
Option B: Use Amazon EMR to ingest and process the data streams to Amazon Redshift for storage. Use Amazon Redshift Spectrum to search the data. Use Amazon QuickSight to create visualizations.
- Explanation: EMR can process large-scale streaming data, and Amazon Redshift is a fully managed data warehouse for storage. Redshift Spectrum allows you to query data stored in S3, and QuickSight is a visualization tool.
- Why it doesn’t meet the requirements:
- Real-time streaming: While EMR can handle big data processing, Redshift is optimized for analytical workloads and might not be the best fit for real-time updates and searches, especially for streaming data. Redshift requires batch loading, which introduces delays, not ideal for real-time applications.
- Latency: The batch-oriented nature of Redshift means it may not meet the company's real-time search and visualization needs effectively.
- Use Case: This solution is more suited for analytical workloads that need to process large amounts of data, but it’s not ideal for real-time data streaming and search.
Option C: Use Amazon Elastic Kubernetes Service (Amazon EKS) to ingest and process the data stream...
Author: Amira99 · Last updated Jul 12, 2026
A company currently runs an on-premises application that usesASP.NET on Linux machines. The application is resource-intensive and serves customers directly.
The company wants to modernize the application to .NET. The company wants to run the application on containers and to scale based on Amazon CloudWatch metrics. The company also wants ...
Problem Analysis
The company wants to modernize its application, which currently runs on on-premises Linux machines with ASP.NET, to .NET and containerize it. The main goals are to:
1. Containerize the application: The company wants to run the application in containers for better scalability.
2. Scale based on CloudWatch metrics: The solution needs to be able to automatically scale based on metrics like CPU and memory usage.
3. Reduce operational overhead: The solution should minimize the operational management tasks, such as infrastructure management, provisioning, and scaling.
Let's analyze each of the options:
Option A: Use AWS App2Container to containerize the application. Use an AWS CloudFormation template to deploy the application to Amazon Elastic Container Service (Amazon ECS) on AWS Fargate.
- Explanation: AWS App2Container can be used to automatically containerize the application. ECS with Fargate is a fully managed container service where you don’t need to manage the underlying EC2 instances. Fargate handles the scaling and provisioning of resources automatically.
- Why it meets the requirements:
- Containerization: App2Container effectively helps in containerizing an on-premises .NET application.
- Scaling: ECS with Fargate can automatically scale based on CloudWatch metrics without the need to manage EC2 instances directly.
- Reduced Operational Overhead: Fargate is a serverless option, meaning that the company doesn't need to worry about managing infrastructure, patching, or scaling EC2 instances.
- Use Case: This is a great choice for minimizing operational overhead, automating scaling, and running containers without worrying about the underlying infrastructure.
Option B: Use AWS App2Container to containerize the application. Use an AWS CloudFormation template to deploy the application to Amazon Elastic Container Service (Amazon ECS) on Amazon EC2 instances.
- Explanation: This option also uses AWS App2Container for containerization and ECS for deployment. However, instead of Fargate, it uses EC2 instances to run the containers.
- Why it doesn’t meet the requirements:
- Operational Overhead: Managing EC2 instances introduces more operational overhead. The company would need to manage EC2 instances, ensure they scale appropriately, and patch them, which reduces the benefit of using a managed container service.
- Scaling: While ECS with EC2 instances can scale, the company would still be responsible for managing the instances, which adds to the operational overhead.
- Use Case: This solution would work if the company preferred more control over EC2 instances, but it doesn’t reduce operational overhead as much as Fargate.
Option C: Use AWS App Runner to containerize the application. Use App Runner to deploy the application to Amazon Elastic Container Service (Am...
Author: Mia · Last updated Jul 12, 2026
A company is designing a new internal web application in the AWS Cloud. The new application must securely retrieve and store multiple employee usernames and passwords from an AWS managed service....
Problem Analysis
The company needs a solution to securely store and retrieve employee usernames and passwords in the AWS Cloud. The solution must meet the following criteria:
1. Security: The credentials need to be stored securely.
2. Low operational overhead: The solution should be easy to manage without requiring significant operational effort.
3. AWS-managed service: The solution should leverage an AWS-managed service to minimize maintenance and management overhead.
Let's analyze each option:
Option A: Store the employee credentials in AWS Systems Manager Parameter Store. Use AWS CloudFormation and the BatchGetSecretValue API to retrieve usernames and passwords from Parameter Store.
- Explanation: AWS Systems Manager Parameter Store can securely store sensitive information, such as passwords. However, it is more typically used for less sensitive data compared to AWS Secrets Manager. While Parameter Store supports encryption, it lacks some of the advanced features that Secrets Manager offers, such as automatic rotation of secrets.
- Why it doesn't meet the requirements:
- Security: While Parameter Store can encrypt sensitive data, Secrets Manager is purpose-built for managing sensitive secrets such as credentials and provides additional security features.
- Operational Overhead: Secrets Manager is a fully managed service specifically designed for securely storing and managing credentials, and it integrates seamlessly with other AWS services. Parameter Store, while useful, doesn’t offer the same level of automation for secret rotation or integration features.
- Use Case: Parameter Store is a great service for general configuration management but is not ideal for managing credentials at scale with minimal operational overhead.
Option B: Store the employee credentials in AWS Secrets Manager. Use AWS CloudFormation and AWS Batch with the BatchGetSecretValue API to retrieve the usernames and passwords from Secrets Manager.
- Explanation: AWS Secrets Manager is specifically designed for securely storing and managing sensitive information, such as credentials. It provides automated secret rotation, fine-grained access control, and encryption at rest. It integrates with AWS services like Lambda, EC2, and more, making it easier to manage and use secrets in various applications.
- Why it meets the requirements:
- Security: Secrets Manager is designed to securely store sensitive information with encryption and automated secret rotation.
- Operational Overhead: Secrets Manager is a fully managed service, meaning it takes care of the complexity of storing and rotating secrets, which reduces the operational burden.
- Scalability and ease of use: Secrets Manager provides built-in integrations for retrieving secrets in a secure and straightforward manner.
- Use Case: This is the ideal solution for...
Author: Ahmed · Last updated Jul 12, 2026
A company that is in the ap-northeast-1 Region has a fleet of thousands of AWS Outposts servers. The company has deployed the servers at remote locations around the world. All the servers regularly download new software versions that consist of 100 files. There is significant latency before all servers run the new software versions.
The com...
To solve the problem of reducing the deployment latency for software updates on the AWS Outposts servers, we need to consider several key factors, such as the geographic distribution of the servers, the size of the software package (100 files), and the need to reduce latency.
Option A: Create an Amazon S3 bucket in ap-northeast-1, set up a CloudFront distribution in ap-northeast-1 with a CachingDisabled cache policy, and use signed URLs.
- Pros: CloudFront provides content delivery with low latency, especially for geographically distributed users. However, the CachingDisabled cache policy means that CloudFront won’t cache the content at edge locations, which defeats the purpose of using CloudFront. This option doesn't optimize latency effectively.
- Cons: The lack of caching in CloudFront leads to unnecessary retrievals directly from the S3 bucket, which doesn't reduce latency. This is not an optimal choice since we want to minimize latency by caching content closer to the remote locations.
- Conclusion: This option doesn’t meet the requirement effectively because it doesn’t leverage caching.
Option B: Create an Amazon S3 bucket in ap-northeast-1, create a second S3 bucket in us-east-1, configure replication between the buckets, and set up CloudFront with ap-northeast-1 as the primary origin and us-east-1 as the secondary origin.
- Pros: Using multiple S3 buckets in different regions (ap-northeast-1 and us-east-1) can reduce latency for geographically distant clients, but it introduces replication overhead. The replication process adds complexity and operational overhead because the company has to manage the cross-region replication setup.
- Cons: Cross-region replication introduces delays and added complexity, which increases operational overhead. Additionally, this might not provide significant latency improvement compared to a simpler solution like CloudFront caching.
- Conclusion: This option is more complex and introduces extra overhead without offering substantial advantages over...
Author: William · Last updated Jul 12, 2026
A company needs to architect a hybrid DNS solution. This solution will use an Amazon Route 53 private hosted zone for the domain cloud.example.com for the resources stored within VPCs.
The company has the following DNS resolution requirements:
On-premises systems should be able to resolve and connect to cloud.example.com.
All VPCs should be able to resolve cloud.example.com.
There is already an AWS Direct Conne...
Architecture Options Breakdown:
Option A:
- Description: This option involves associating the Route 53 private hosted zone to all VPCs, creating a Route 53 inbound resolver in the shared services VPC, attaching all VPCs to the transit gateway, and creating forwarding rules in the on-premises DNS server for `cloud.example.com` that point to the inbound resolver.
- Key Elements:
- Inbound resolver for DNS resolution from on-premises to AWS.
- VPC associations and transit gateway configuration for VPC DNS resolution.
- Pros:
- Direct integration of VPCs with the private hosted zone via the inbound resolver.
- AWS-native approach, ensuring that DNS resolution between the on-premises network and the VPCs is fast and secure.
- Cons:
- Requires careful configuration of forwarding rules and resolvers.
- May add complexity due to the need for configuring each VPC with forwarding rules to the inbound resolver.
- Potential overhead with the inbound resolver configuration, requiring more management effort.
- Use Case: Suitable for hybrid scenarios where on-premises DNS resolution must be routed through AWS Route 53, providing a centralized inbound DNS solution.
Option B:
- Description: This option involves associating the Route 53 private hosted zone to all VPCs, deploying an EC2 conditional forwarder in the shared services VPC, attaching all VPCs to the transit gateway, and creating forwarding rules in the on-premises DNS server for `cloud.example.com` that point to the conditional forwarder.
- Key Elements:
- EC2 conditional forwarder to handle DNS queries for the specific domain.
- Forwarding configuration from on-premises DNS to the EC2 conditional forwarder.
- Pros:
- EC2 conditional forwarders are flexible and can work with any DNS server.
- Can be integrated into more complex DNS setups if needed.
- Cons:
- Requires managing an EC2 instance as a conditional forwarder, introducing additional management overhead.
- Performance may not be optimal compared to Route 53 resolvers.
- Potential latency introduced due to the reliance on an EC2 instance.
- Use Case: This could be considered if the company has a more complex DNS infrastructure requiring custom DNS handling beyond what Route 53 provides natively.
Option C:
- Description: This option involves associating the Route 53 private hosted zone to the shared services VPC, creating a Route 53 outbound resolver in the shared services VPC, attaching all VPCs to the transit gateway, and creating forwarding rules in the on-premises DNS server for `cloud.example.com` that point to the outbound resolver.
- Key Elements:
- Outbou...
Author: Ella · Last updated Jul 6, 2026
A company currently runs an on-premises stock trading application by using Microsoft Windows Server. The company wants to migrate the application to the AWS Cloud.
The company needs to design a highly available solution that provides low-latency access to block storage ac...
To design a highly available solution for migrating a stock trading application from on-premises to AWS Cloud with low-latency access to block storage across multiple Availability Zones, we need to consider key factors such as availability, latency, scalability, and ease of implementation. Let’s evaluate each option:
Option A: Configure a Windows Server cluster that spans two Availability Zones on Amazon EC2 instances. Install the application on both cluster nodes. Use Amazon FSx for Windows File Server as shared storage between the two cluster nodes.
- Pros: Amazon FSx for Windows File Server provides fully managed, high-performance Windows file storage. It supports SMB protocol and can span multiple Availability Zones, offering a highly available solution with minimal operational overhead. This solution leverages shared storage that both EC2 instances can access.
- Cons: This option is a good fit for general file-based applications, but it may introduce unnecessary overhead if the application is more specialized in how it handles data (e.g., database or transactional data).
- Conclusion: This option provides a highly available, easy-to-implement solution with low-latency access to shared file storage, making it a good candidate for the application. It’s straightforward in terms of implementation.
Option B: Configure a Windows Server cluster that spans two Availability Zones on Amazon EC2 instances. Install the application on both cluster nodes. Use Amazon Elastic Block Store (Amazon EBS) General Purpose SSD (gp3) volumes as storage attached to the EC2 instances. Set up application-level replication to sync data from one EBS volume in one Availability Zone to another EBS volume in the second Availability Zone.
- Pros: Amazon EBS gp3 volumes are high-performance block storage, and they offer cost-effective storage for EC2 instances.
- Cons: While EBS volumes provide block-level storage, EBS replication between Availability Zones requires additional setup and application-level management. This increases complexity and operational overhead, as the application must handle synchronization and failover. There is also potential for latency in data synchronization between zones, which is not ideal for low-latency access, especially for stock trading applications that require high performance.
- Conclusion: The requirement to set up application-level replication introduces significant complexity and may not provide the necessary low-latency access or ease of management. This option adds extra operational effort and is not ideal for the given requirements.
Option C: Deploy the application on Amazon EC2 instances in two Availability Zones. Configur...
Author: ThunderBear · Last updated Jul 12, 2026
A company is providing weather data over a REST-based API to several customers. The API is hosted by Amazon API Gateway and is integrated with different AWS Lambda functions for each API operation. The company uses Amazon Route 53 for DNS and has created a resource record of weather.example.com. The company stores data for the API in Amazon DynamoDB tabl...
To address the need for high availability and failover for the weather API across AWS Regions, we need a solution that allows the API to automatically switch to a backup Region if the primary Region experiences issues. Let's analyze each option in detail to determine the most appropriate solution:
A) Deploy a new set of Lambda functions in a new Region. Update the API Gateway API to use an edge-optimized API endpoint with Lambda functions from both Regions as targets. Convert the DynamoDB tables to global tables.
- Analysis: This option suggests using an edge-optimized API Gateway and routing traffic to Lambda functions from multiple Regions. However, the edge-optimized API Gateway is designed to reduce latency by routing traffic to the closest endpoint. It doesn't offer a true failover solution between regions. Additionally, while the global tables for DynamoDB would provide replication across regions, it doesn't fully address the failover of the entire API infrastructure.
- Why Rejected: The edge-optimized API Gateway is not designed to manage Region failover by itself. This would still result in downtime during Region failure since the API Gateway doesn't inherently provide failover logic across regions.
B) Deploy a new API Gateway API and Lambda functions in another Region. Change the Route 53 DNS record to a multivalue answer. Add both API Gateway APIs to the answer. Enable target health monitoring. Convert the DynamoDB tables to global tables.
- Analysis: Using Route 53 with a multivalue answer enables DNS to return multiple IP addresses for the same domain. By enabling health checks, Route 53 can route traffic to the healthy region. However, this approach does not guarantee automatic failover in case of API Gateway or Lambda failure. Additionally, DNS propagation delays can cause downtime, as Route 53 will only route traffic to healthy endpoints after detecting a failure.
- Why Rejected: While it provides some level of high availability, DNS-based failover is not ideal because of potential propagation delays, which can lead to service interruptions during Region failures. DNS-based routing isn't as fast as other approaches for failover.
C) Deploy a new API Gateway API and Lambda functions in another Re...
Author: Ava · Last updated Jul 6, 2026
A company is designing a web application with an internet-facing Application Load Balancer (ALB).
The company needs the ALB to receive HTTPS web traffic from the public internet. The ALB must send only HTTPS traffic to the web application servers hosted on the Amazon EC2 instances on port 443. The ALB must perform a health check of the web application servers over...
Let's break down the requirements and evaluate the different security group configurations to determine which ones are needed for this scenario:
Requirements Recap:
- The ALB must receive HTTPS traffic from the public internet on port 443.
- The ALB must send HTTPS traffic on port 443 to the web application servers (Amazon EC2 instances).
- The ALB must perform a health check over HTTPS on port 8443 for the EC2 instances.
Option A: Allow HTTPS inbound traffic from 0.0.0.0/0 for port 443.
- Explanation: The ALB must receive traffic from the public internet on port 443 (HTTPS). This rule ensures that the ALB can accept incoming HTTPS traffic from any source (`0.0.0.0/0`) on port 443, which is required to handle public web traffic.
- Conclusion: Selected, as it is necessary for the ALB to receive HTTPS traffic from the internet.
Option B: Allow all outbound traffic to 0.0.0.0/0 for port 443.
- Explanation: This option configures the ALB to allow outbound traffic to any destination (0.0.0.0/0) on port 443. While this could theoretically be useful, the ALB doesn’t necessarily need to allow all outbound traffic to the internet on port 443. The ALB will only need to send traffic on port 443 to the web application instances (EC2), which means restricting outbound traffic to specific destinations (e.g., the EC2 instances) would be more appropriate.
- Conclusion: Rejected, as the ALB does not need to send all outbound traffic to the internet. Instead, traffic needs to go to the EC2 instances on port 443.
Option C: Allow HTTPS outbound traffic to the web application instances for port 443.
- Explanation: This rule allows the ALB to send HTTPS traffic to the EC2 instances on port 443. This is required because the ALB will forward traffic to the web application servers over HTTPS on port 443.
- Conclusion: Selected, as this is essential for forwarding the...
Author: GlowingTiger · Last updated Jul 12, 2026
A company uses AWS Organizations with a single OU named Production to manage multiple accounts. All accounts are members of the Production OU. Administrators use deny list SCPs in the root of the organization to manage access to restricted services.
The company recently acquired a new business unit and invited the new unit's existing AWS account to the organization. Once onboarded, the administrators of the new business unit discovered that they are not able to update existi...
Let's break down each option and consider the key factors to determine the best choice.
Option A: Remove the organization's root SCPs that limit access to AWS Config. Create AWS Service Catalog products for the company’s standard AWS Config rules and deploy them throughout the organization, including the new account.
- Explanation: This option suggests removing SCPs that are restricting access to AWS Config and then creating AWS Service Catalog products to deploy the AWS Config rules.
- Why it's rejected: Removing the SCPs at the root level would open up the organization to unrestricted access to AWS Config, which is not a recommended approach because it may allow undesired changes. Creating Service Catalog products adds complexity and long-term maintenance overhead. You would need to keep track of those products across multiple accounts and ensure consistent deployment, making this an unnecessarily complicated and maintainable solution.
Option B: Create a temporary OU named Onboarding for the new account. Apply an SCP to the Onboarding OU to allow AWS Config actions. Move the new account to the Production OU when adjustments to AWS Config are complete.
- Explanation: This option involves creating a temporary organizational unit (OU) for the new account, applying an SCP that allows access to AWS Config, and then moving the account to the Production OU once the required adjustments are made.
- Why it's rejected: While this option offers a temporary solution, it introduces unnecessary complexity by creating a new OU and requiring the movement of accounts between OUs. Additionally, temporary OUs add overhead when managing SCPs for the organization long-term.
Option C: Convert the organization’s root SCPs from deny list SCPs to allow list SCPs to allow the required services only. Temporarily apply an SCP to the organization's root that allows AWS Config actions for principals only in the new account.
- Explanation: This option suggests changing the root SCP from a deny list to an allow list, and then tem...
Author: Lucas · Last updated Jul 6, 2026
A company hosts an application on AWS. The application gives users the ability to upload photos and store the photos in an Amazon S3 bucket. The company wants to use Amazon CloudFront and a custom domain name to upload the photo files t...
To meet the company's requirement of uploading photos to an S3 bucket using Amazon CloudFront with a custom domain name, the solution must address the security of the communication (via HTTPS), the configuration of CloudFront, and how CloudFront interacts with the S3 bucket in the eu-west-1 Region.
Let’s break down each option:
Option A: Use AWS Certificate Manager (ACM) to create a public certificate in the us-east-1 Region. Use the certificate in CloudFront.
- Explanation: CloudFront requires an SSL/TLS certificate for secure communication over HTTPS. AWS Certificate Manager (ACM) certificates are region-specific for CloudFront, and ACM certificates for CloudFront must be created in the us-east-1 Region, even if the CloudFront distribution is associated with another region (in this case, eu-west-1).
- Conclusion: Selected. The ACM certificate must be in the us-east-1 Region for CloudFront, regardless of where the S3 bucket is located.
Option B: Use AWS Certificate Manager (ACM) to create a public certificate in eu-west-1. Use the certificate in CloudFront.
- Explanation: Although the certificate is created in the same region as the S3 bucket (eu-west-1), CloudFront requires certificates to be created in us-east-1 for global use, not in the region where the content resides.
- Conclusion: Rejected. This option is not valid because CloudFront doesn’t support certificates created in regions other than us-east-1.
Option C: Configure Amazon S3 to allow uploads from CloudFront. Configure S3 Transfer Acceleration.
- Explanation: S3 Transfer Acceleration is used to speed up the upload of files to S3 from geographically distant locations by routing uploads through CloudFront edge locations. While this option accelerates uploads, it is not necessary to specificall...
Author: MysticJaguar44 · Last updated Jul 12, 2026
A company is running a two-tier web-based application in an on-premises data center. The application layer consists of a single server running a stateful application. The application connects to a PostgreSQL database running on a separate server. The application's user base is expected to grow significantly, so the company is migrating the application and database to AWS. The solution will use Amazon Aurora Post...
Let's analyze the problem and each option carefully.
Key Requirements:
- Scalability: The application and database need to scale to meet growing user demand.
- Consistency: The user experience needs to remain consistent, and sessions should be properly managed.
- High Availability: The solution must ensure high availability for both the application and database tiers.
Solution Components:
- Amazon Aurora PostgreSQL: Amazon Aurora is a managed relational database service with automatic failover and horizontal scaling for read replicas. Aurora provides Aurora Replicas for read scaling, and the primary writer instance handles write operations.
- Amazon EC2 Auto Scaling: This will automatically adjust the number of EC2 instances in response to changes in load, ensuring that the application tier scales up or down based on demand.
- Elastic Load Balancing (ELB): ELB distributes traffic between application instances, and the configuration of load balancing (whether it’s round robin, least outstanding requests, etc.) impacts performance and reliability.
Option Breakdown:
A) Enable Aurora Auto Scaling for Aurora Replicas. Use a Network Load Balancer with the least outstanding requests routing algorithm and sticky sessions enabled.
- Analysis: Aurora Auto Scaling for Replicas helps scale read traffic but does not help scale the writer for write-heavy workloads. For the application, using a Network Load Balancer (NLB) with the least outstanding requests routing algorithm is typically used for low-level network traffic, such as with protocols like TCP. However, sticky sessions are generally not a good fit with NLB since session affinity is typically better suited for HTTP/HTTPS traffic, which is managed by an Application Load Balancer (ALB).
- Why Rejected: This solution does not address the need to scale both read and write traffic to the database effectively and misaligns with sticky sessions being applied to a Network Load Balancer, which isn’t ideal for session persistence.
B) Enable Aurora Auto Scaling for Aurora writers. Use an Application Load Balancer with the round robin routing algorithm and sticky sessions enabled.
- Analysis: Aurora Auto Scaling for writers does not exist, because Aurora automatically handles write scaling by promoting a new writer in case of failure or scaling for read replicas. The Application Load Balancer (ALB), with th...
Author: CrimsonViperX · Last updated Jul 6, 2026
A weather forecasting company collects temperature readings from various sensors on a continuous basis. An existing data ingestion process collects the readings and aggregates the readings into larger Apache Parquet files. Then the process encrypts the files by using client-side encryption with KMS managed keys (CSE-KMS). Finally, the process writes the files to an Amazon S3 bucket with separate prefixes for each calendar day.
Th...
The weather forecasting company wants to run occasional SQL queries on encrypted Apache Parquet files stored in Amazon S3, so we need to select a solution that meets the requirements of querying the data efficiently and cost-effectively. Let's analyze each option in detail:
Option A: Configure Amazon Athena to read the encrypted files. Run SQL queries on the data directly in Amazon S3.
- Explanation: Amazon Athena is a serverless query service that allows you to run SQL queries directly on data stored in Amazon S3 without needing to move or load the data. Athena supports Apache Parquet files natively and can work with client-side encryption using KMS managed keys (CSE-KMS). Since the data is already in S3 and Athena is billed based on the amount of data scanned, this is an efficient and cost-effective solution for occasional querying.
- Conclusion: Selected. Athena is the most cost-effective option because it is serverless, does not require data transformation, and integrates easily with encrypted data stored in S3. Since the company only needs to run occasional queries, Athena's pay-per-query model ensures that the company only pays for the data it queries, making it highly cost-efficient.
Option B: Use Amazon S3 Select to run SQL queries on the data directly in Amazon S3.
- Explanation: S3 Select allows you to retrieve a subset of data from an S3 object, but it is mainly designed for simpler queries on a specific file (e.g., extracting parts of an object). It can be used to run SQL queries on individual Parquet files in S3, but it is not ideal for running complex queries over multiple files or aggregating data across large datasets like in the scenario described.
- Conclusion: Rejected. While S3 Select could work for simpler queries on individual files, it does not scale well for running complex ...
Author: Zara · Last updated Jul 12, 2026
A company uses a service to collect metadata from applications that the company hosts on premises. Consumer devices such as TVs and internet radios access the applications. Many older devices do not support certain HTTP headers and exhibit errors when these headers are present in responses. The company has configured an on-premises load balancer to remove the unsupported headers from responses sent to older devices, which the company identified by the User-Agent headers.
The company wants to migrate the service ...
The company needs a solution that can support older devices that don’t handle certain HTTP headers and remove those headers based on the `User-Agent` headers. The company wants to use AWS serverless technologies to achieve this and has already migrated their applications to Lambda functions. Let's evaluate each option to identify which best meets the requirements.
Key Requirements:
1. Remove unsupported headers: Based on the `User-Agent` header, certain HTTP headers need to be removed from responses for older devices.
2. Serverless architecture: The solution should make use of serverless technologies.
3. Compatibility with AWS Lambda: The migrated Lambda functions should still be invoked based on incoming requests.
4. Support for older devices: The solution must work seamlessly for devices that don’t support certain HTTP headers.
Option A: Create an Amazon CloudFront distribution for the metadata service. Create an Application Load Balancer (ALB). Configure the CloudFront distribution to forward requests to the ALB. Configure the ALB to invoke the correct Lambda function for each type of request. Create a CloudFront function to remove the problematic headers based on the value of the User-Agent header.
- Analysis: This solution utilizes CloudFront and an Application Load Balancer (ALB). CloudFront can forward requests to ALB, which will then invoke the Lambda functions. The CloudFront function can handle the removal of problematic headers based on the `User-Agent` header. CloudFront functions are lightweight and run at the edge, which makes them ideal for modifying HTTP responses before they reach the client.
- Why Selected: This option efficiently leverages CloudFront to remove the problematic headers at the edge, reducing latency and improving performance. Additionally, using a CloudFront function provides a low-latency solution for modifying responses based on headers, making it an ideal choice for devices that don’t support certain headers. This is the most effective way to handle the issue without introducing significant overhead.
Option B: Create an Amazon API Gateway REST API for the metadata service. Configure API Gateway to invoke the correct Lambda function for each type of request. Modify the default gateway responses to remove the problematic headers based on the value of the User-Agent header.
- Analysis: This option suggests using API Gateway REST API to handle requests and invoking the correct Lambda function for each type of request. API Gateway provides some flexibility in modifying responses, but the solution might require manual configurations to handle the removal of headers based on `User-Agent`. The main issue is that API Gateway does not handle header manipulations as easily or efficiently as CloudFront at the edge, especially for the type of requirement in this scenario.
- Why Rejected: While API Gateway can be used, it is not as well-suited for handling header manipulations for older devices as CloudFront functions. The solution may introduce unnecessary complexity an...
Author: Sofia2021 · Last updated Jul 6, 2026
A company is implementing a new application on AWS. The company will run the application on multiple Amazon EC2 instances across multiple Availability Zones within multiple AWS Regions. The application will be available through the internet. Users will access the application from around the world.
The company wants to ensure that each use...
To address the requirements of the application, which needs to direct users to the nearest Amazon EC2 instances based on their geographic location, let’s evaluate each option carefully based on the key factors:
Key factors:
1. Geolocation or proximity-based routing: The solution needs to send users to the EC2 instances closest to their location. This involves routing based on geographic proximity.
2. Availability across multiple Regions and Availability Zones: The solution needs to distribute traffic across multiple AWS Regions and Availability Zones.
3. Routing Method: The routing policy must support global traffic distribution.
4. Load Balancer Type: The load balancer type should suit the application’s traffic pattern and routing method.
A) Amazon Route 53 geolocation routing policy with an internet-facing Application Load Balancer (ALB)
- Geolocation routing allows users to be directed to the closest set of resources based on their geographic location (continent or country). However, geolocation routing typically works within a specific AWS Region. It cannot distribute traffic across multiple Regions based on proximity.
- Application Load Balancer (ALB) is ideal for HTTP/HTTPS traffic and supports content-based routing, but it doesn't automatically optimize for geolocation in multiple Regions.
Why rejected: Geolocation routing is limited to a specific region, which means this won't work across multiple Regions. It also doesn't prioritize proximity based on the user's location in a multi-region setup.
B) Amazon Route 53 geoproximity routing policy with an internet-facing Network Load Balancer (NLB)
- Geoproximity routing is designed to route traffic based on the geographical proximity of the requesting user to the resources. It can route traffic to the EC2 instances in the nearest AWS Region, which satisfies the need for proximity-based routing across multiple Regions.
- Network Load Balancer (NLB) is suited for low-latency, high-throughput, and TCP...
Author: Liam · Last updated Jul 12, 2026
A retail company needs to provide a series of data files to another company, which is its business partner. These files are saved in an Amazon S3 bucket under Account A, which belongs to the retail company. The business partner company wants one of its IAM users, User_DataProcessor, to access the files from its own AWS account (A...
To allow the business partner’s IAM user (User_DataProcessor) in Account B to access the S3 bucket in Account A, the companies need to establish the correct permissions using AWS IAM and S3 policies. Let's analyze each of the options and determine the most appropriate actions.
Option A: Turn on the cross-origin resource sharing (CORS) feature for the S3 bucket in Account A.
Reasoning: CORS (Cross-Origin Resource Sharing) is used to allow web browsers to access resources from a different domain. However, in this case, the business partner (User_DataProcessor) is accessing S3 from AWS IAM, not from a web browser. Therefore, enabling CORS will not help with this scenario.
Rejection: This option is not relevant because the access is not coming from a web browser but from another AWS account via IAM credentials.
Option B: In Account A, set the S3 bucket policy to the following:
```json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": "",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::bucket-name/",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "AccountB-ID"
}
}
}
]
}
```
Reasoning: This bucket policy allows the IAM users from Account B (with the right permissions) to access the S3 bucket in Account A. It uses `aws:SourceAccount` to limit the access to only Account B, which is a good security practice. The `Principal` is set to `` to allow users from Account B, and the condition ensures that only the specified source account can access the bucket.
Selection: This option is correct because it explicitly allows access from Account B, with conditions to ensure that only the authorized account can access the bucket's content.
Option C: In Account A, set the S3 bucket policy to the following:
```json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": "",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::bucket-name/",
"Condition": {
"StringEquals": {
"aws:SourceArn": "arn:aws:aws:userid/AccountB-ID"
}
}
}
]
}
```
Reasoning: This policy uses `aws:SourceArn` to specify the source ARN, but it is not as commonly used in S3 bucket policies. Typ...
Author: BlazingPhoenix22 · Last updated Jul 6, 2026
A financial services company plans to launch a new application on AWS to handle sensitive financial transactions. The company will deploy the application on Amazon EC2 instances. The company will use Amazon RDS for MySQL as the database. The company's security policies mandate that data m...
To meet the company's security requirements of encrypting sensitive financial data at rest and in transit with the least operational overhead, let's analyze the options based on the key factors:
Key Factors:
1. Encryption at rest: The company mandates that the data stored in Amazon RDS for MySQL must be encrypted.
2. Encryption in transit: Data must be encrypted during transmission.
3. Operational overhead: The solution should minimize operational complexity, favoring AWS-native services wherever possible.
4. Security compliance: The solution must align with security standards for handling sensitive financial data.
A) Configure encryption at rest for Amazon RDS for MySQL by using AWS KMS managed keys. Configure AWS Certificate Manager (ACM) SSL/TLS certificates for encryption in transit.
- Encryption at rest: Amazon RDS for MySQL supports encryption at rest using AWS Key Management Service (KMS) managed keys. This is straightforward to configure and manage.
- Encryption in transit: AWS Certificate Manager (ACM) can be used to easily provision SSL/TLS certificates for encrypting data in transit. This is a native solution provided by AWS, reducing operational overhead.
Why selected: This solution leverages AWS-native tools for both encryption at rest (RDS with KMS) and in transit (ACM with SSL/TLS). It provides an integrated, fully managed solution with minimal operational complexity. It is the least operational overhead solution as AWS manages the KMS and ACM services.
B) Configure encryption at rest for Amazon RDS for MySQL by using AWS KMS managed keys. Configure IPsec tunnels for encryption in transit.
- Encryption at rest: Using AWS KMS-managed keys for RDS encryption at rest is fine.
- Encryption in transit: IPsec tunnels are a secure method of encrypting data in transit. However, this approach requires additional configuration and management of the tunnels, including setting up the VPN and managing the security policies. This increases the operational overhead significantly compared to using SSL/TLS for encrypting data in transit.
Why rejected: While IPsec tunnels are a valid solution for encryption in transit, they add complexity and operational overhead compared to the simpler ACM SSL/TLS ...
Author: BlazingPhoenix22 · Last updated Jul 12, 2026
A company is running a traditional web application on Amazon EC2 instances. The company needs to refactor the application as microservices that run on containers. Separate versions of the application exist in two distinct environments: production and testing. Load for the application is variable, but the minimum load and the maximum load are known. A solutions architect needs to des...
To choose the most cost-effective and operationally efficient solution for refactoring the application into a serverless architecture while minimizing operational complexity, let's examine each option in detail:
A) Upload the container images to AWS Lambda as functions. Configure a concurrency limit for the associated Lambda functions to handle the expected peak load. Configure two separate Lambda integrations within Amazon API Gateway: one for production and one for testing.
- Reasoning: AWS Lambda is a serverless compute service, which can automatically scale based on demand. This option would allow you to upload container images to Lambda, and the service would manage scaling. However, there are some limitations:
- Container Size Limitation: Lambda functions have a size limit for their deployment package (10 GB for container images), which might be restrictive depending on the size of your containerized application.
- Operational Complexity: While Lambda offers auto-scaling, managing concurrency limits for a variable load could increase complexity. Additionally, managing two separate Lambda integrations for testing and production can increase overhead compared to simpler options.
- Cost: Lambda charges based on invocation and duration, which could be more expensive if your application has frequent or sustained loads. The cost can become high if the application runs continuously with varying loads.
- Rejection: While Lambda can be a valid option for certain microservices, the complexity and potential cost make it less ideal for a variable-load, containerized application when other services provide better cost and operational management.
B) Upload the container images to Amazon Elastic Container Registry (Amazon ECR). Configure two auto scaled Amazon Elastic Container Service (Amazon ECS) clusters with the Fargate launch type to handle the expected load. Deploy tasks from the ECR images. Configure two separate Application Load Balancers to direct traffic to the ECS clusters.
- Reasoning:
- ECS with Fargate: ECS with Fargate is a serverless container service that handles container orchestration without the need to manage EC2 instances. It scales automatically based on load, which makes it suitable for handling the known variable load of your application.
- Auto Scaling: ECS supports auto-scaling policies, which will allow it to scale to meet both the minimum and maximum loads efficiently.
- Cost Efficiency: Fargate charges based on the resources consumed by containers, so you only pay for what you use. Given that ECS with Fargate automatically scales, this is a cost-effective solution for handling variable loads.
- Operational Simplicity: Managing ECS with Fargate is simpler than managing a full EC2 or Kubernetes infrastructure because you don't need to manage the underlying instances.
- Multiple Environments: Using separate ECS clusters for testing and production can be handled easily, as ECS allows for clear separation of environments.
- Selection: This option is very cost-effective and minimizes operational complexity by ...
Author: SolarFalcon11 · Last updated Jul 6, 2026
A company is migrating its on-premises Oracle database to an Amazon RDS for Oracle database. The company needs to retain data for 90 days to meet regulatory requirements. The company must also be able to restore the database to a specific point in ...
To meet the company's requirements of retaining data for 90 days and restoring the Amazon RDS for Oracle database to a specific point in time for up to 14 days with the least operational overhead, we need to consider the following:
Key Factors:
1. Data Retention for 90 Days: The company needs to retain data for 90 days to comply with regulatory requirements.
2. Point-in-Time Restore for 14 Days: The company needs the ability to restore the database to a specific point in time, going back up to 14 days.
3. Operational Overhead: The solution should minimize manual management, favoring automation where possible.
A) Create Amazon RDS automated backups. Set the retention period to 90 days.
- Automated backups are a native feature of Amazon RDS and automatically back up the database daily, retaining transaction logs. This meets both requirements:
- Data retention: The automated backup retention period can be set up to 35 days, which is more than enough to ensure compliance with the 14-day point-in-time restore.
- Point-in-time restore: RDS automated backups support point-in-time recovery for up to 35 days, so the company can restore the database to any specific time within this period, meeting the 14-day restore requirement.
Why selected: This solution is fully managed by AWS, requires no manual intervention, and ensures both long-term data retention and the ability to restore to a specific point in time. It provides a low operational overhead solution and integrates well into RDS functionality.
B) Create an Amazon RDS manual snapshot every day. Delete manual snapshots that are older than 90 days.
- Manual snapshots are created on-demand and can be retained for as long as needed, but they require manual intervention to delete older snapshots.
- While you can retain snapshots for 90 days, this solution requires manual snapshot management and deletion, which introduces more operational overhead compared to ...
Author: GlowingTiger · Last updated Jul 12, 2026
A company has a multi-tier web application that runs on a fleet of Amazon EC2 instances behind an Application Load Balancer (ALB). The instances are in an Auto Scaling group. The ALB and the Auto Scaling group are replicated in a backup AWS Region. The minimum value and the maximum value for the Auto Scaling group are set to zero. An Amazon RDS Multi-AZ DB instance stores the application's data. The DB instance has a read replica in the backup Region. The application presents an endpoint to end users by using an Amazon Route 53 record.
The company needs to reduce its RTO to less t...
To address the requirement of reducing the Recovery Time Objective (RTO) to less than 15 minutes while providing automatic failover to the backup AWS Region, let’s evaluate each option and determine the best solution.
A) Reconfigure the application's Route 53 record with a latency-based routing policy that load balances traffic between the two ALBs. Create an AWS Lambda function in the backup Region to promote the read replica and modify the Auto Scaling group values. Create an Amazon CloudWatch alarm that is based on the HTTPCode_Target_5XX_Count metric for the ALB in the primary Region. Configure the CloudWatch alarm to invoke the Lambda function.
- Reasoning:
- Latency-based routing in Route 53 would allow load balancing traffic across two Regions. However, latency-based routing isn't ideal for failover scenarios because it is intended to distribute traffic for optimal performance, not for high availability or disaster recovery.
- CloudWatch alarm on ALB HTTP errors could trigger the Lambda function, but relying solely on an alarm for application-level failure detection may not always provide timely enough failover, especially if the application health check is not available in time.
- Lambda to promote the read replica: The read replica promotion process might not be fast enough to meet the 15-minute RTO, particularly if it involves manual configuration steps.
- Rejection: This approach doesn’t offer the level of automation and responsiveness needed for an RTO of less than 15 minutes, especially considering that latency-based routing doesn't handle failover well.
B) Create an AWS Lambda function in the backup Region to promote the read replica and modify the Auto Scaling group values. Configure Route 53 with a health check that monitors the web application and sends an Amazon Simple Notification Service (SNS) notification to the Lambda function when the health check status is unhealthy. Update the application's Route 53 record with a failover policy that routes traffic to the ALB in the backup Region when a health check failure occurs.
- Reasoning:
- Health checks in Route 53 are a better way to detect if the primary region's application is down. When a health check failure occurs, Route 53 can automatically failover to the backup Region.
- Lambda function to promote the read replica: This ensures that when failover happens, the read replica is promoted to the primary DB. Additionally, modifying the Auto Scaling group to scale up in the backup Region will allow the application to scale automatically.
- Failover policy: Route 53 with a failover policy ensures that traffic is routed to the backup Region quickly if the health check in the primary Region fails. This meets the RTO requirement of less than 15 minutes.
- Selection: This solution offers an automated, cost-effective way to handle failov...
Author: Daniel · Last updated Jul 6, 2026
A company is hosting a critical application on a single Amazon EC2 instance. The application uses an Amazon ElastiCache for Redis single-node cluster for an in-memory data store. The application uses an Amazon RDS for MariaDB DB instance for a relational database. For the application to function, each piece of the infrastructure must be healthy and must be in an active state.
A solutions architect needs to improve the application's...
To improve the application's architecture for automatic recovery with minimal downtime, the solutions architect should implement measures that address failure scenarios for the EC2 instance, RDS database, and ElastiCache. Let’s evaluate each option based on the specific needs of the infrastructure:
A) Use an Elastic Load Balancer to distribute traffic across multiple EC2 instances. Ensure that the EC2 instances are part of an Auto Scaling group that has a minimum capacity of two instances.
- Reasoning:
- This option addresses the need for fault tolerance at the EC2 level. By using an Elastic Load Balancer (ELB), traffic can be distributed across multiple EC2 instances. This ensures that if one EC2 instance fails, traffic is automatically routed to healthy instances, reducing downtime.
- The Auto Scaling group ensures that the application scales based on load and automatically replaces failed instances, providing high availability.
- Critical for improving the application's resilience and reducing downtime by ensuring multiple instances are always running.
- Selection: This is a critical step to ensure that if the single EC2 instance fails, there are other EC2 instances available to take over, ensuring no downtime.
B) Use an Elastic Load Balancer to distribute traffic across multiple EC2 instances. Ensure that the EC2 instances are configured in unlimited mode.
- Reasoning:
- While using an Elastic Load Balancer is appropriate for distributing traffic, configuring EC2 instances in unlimited mode is related to EC2's burstable performance (T instances) and does not provide direct fault tolerance or high availability.
- This option does not guarantee automatic recovery from failure. The key issue is that unlimited mode allows instances to exceed their baseline CPU credits but does not help in case of EC2 instance failure. The instances could still fail if there's a hardware issue or other failure.
- Rejection: This does not improve fault tolerance in a failure scenario because it focuses only on performance scaling and not on availability or redundancy.
C) Modify the DB instance to create a read replica in the same Availability Zone. Promote the read replica to be the primary DB instance in failure scenarios.
- Reasoning:
- A read replica in the same Availability Zone is not a high-availability solution because it doesn’t provide protection against AZ failure. If the AZ goes down, both the primary DB instance and its read replica could be affected.
- Promoting the read replica could reduce downtime if the primary DB instance fails, but without Multi-AZ deployment, the application would still be at risk of prolonged downtime during failure scenarios.
- Rejection: This solution is not sufficient to ensure high availability and automatic recovery in case of failure because it lacks the ability to recover from AZ failure...
Author: Aarav2020 · Last updated Jul 6, 2026
A retail company is operating its ecommerce application on AWS. The application runs on Amazon EC2 instances behind an Application Load Balancer (ALB). The company uses an Amazon RDS DB instance as the database backend. Amazon CloudFront is configured with one origin that points to the ALB. Static content is cached. Amazon Route 53 is used to host all public zones.
After an update of the application, the ALB occasionally returns a 502 status code (Bad Gateway) error. The root cause is malformed HTTP headers that are returned to the ALB. The webpage returns successfully when a solutions architect reloads the webpage immediately after the error o...
To meet the requirement of providing a custom error page instead of the standard ALB error page with the least operational overhead, we need a solution that can intercept errors from the ALB and display the custom error page without requiring complex configurations. Let’s evaluate each option:
A) Create an Amazon S3 bucket. Configure the S3 bucket to host a static webpage. Upload the custom error pages to Amazon S3.
- Reasoning:
- Creating an Amazon S3 bucket to host a static webpage with custom error pages is an effective solution for providing a custom error page. S3 hosting is low-cost and straightforward to set up, and it can be configured to serve a custom error page in case of a 502 or other errors.
- This method allows serving the error page efficiently with minimal operational overhead. The S3 bucket can directly serve the custom error page without additional complexity.
- Selection: This is the most straightforward option to meet the requirement of serving a custom error page with minimal overhead. It leverages S3’s static website hosting feature.
B) Create an Amazon CloudWatch alarm to invoke an AWS Lambda function if the ALB health check response `Target.FailedHealthChecks` is greater than 0. Configure the Lambda function to modify the forwarding rule at the ALB to point to a publicly accessible web server.
- Reasoning:
- While CloudWatch alarms can trigger Lambda functions, this approach introduces additional complexity. You would need to manage an AWS Lambda function to modify the ALB's forwarding rules dynamically, which can create operational overhead and delays in triggering the custom error page.
- Moreover, this solution is not ideal for displaying a static custom error page because it requires complex actions (modifying ALB forwarding rules) instead of directly serving a pre-configured custom error page.
- Rejection: This solution is unnecessarily complex and involves modifying ALB rules, which increases operational overhead.
C) Modify the existing Amazon Route 53 records by adding health checks. Configure a fallback target if the health check fails. Modify DNS records to point to a publicly accessible webpage.
- Reasoning:
- Modifying Route 53 records with health checks and configuring a fallback target is a valid approach but may introduce additional complexity. Health checks in Route 53 are typically used for DNS failover between regions or endpoints, but ...
Author: RadiantJaguar56 · Last updated Jul 6, 2026
A company is developing a new application that uses a relational database to store user data and application configurations. The company expects the application to have steady user growth. The company expects the database usage to be variable and read-heavy, with occasional writes.
The company wants to cost-optimize the database solution. The company wants...
To determine the most cost-effective database solution, we need to focus on the following key factors:
Key Factors:
1. Workload Type: The database usage is expected to be read-heavy with occasional writes, meaning there will be periods of low write activity and possibly high read activity.
2. Scalability: The company expects steady user growth, so the solution should be able to handle this growth in a cost-efficient way.
3. Cost Optimization: Since the company is looking to cost-optimize the database solution, the solution should be able to scale automatically without requiring constant manual intervention or over-provisioning.
4. AWS Managed Services: The company wants to use an AWS managed database solution to avoid managing database infrastructure manually.
A) Deploy the database on Amazon RDS. Use Provisioned IOPS SSD storage to ensure consistent performance for read and write operations.
- Provisioned IOPS SSD (io1 or io2) is designed to provide high, consistent performance for both read and write operations, but this comes at a higher cost.
- This option may be suitable for workloads requiring high transaction throughput and low latency. However, since the application is expected to be read-heavy with occasional writes, the use of Provisioned IOPS can be overkill for this specific workload type and can be more expensive than necessary.
Why rejected: While this option provides high performance, it’s costly for the described workload, especially since the application is more read-heavy with occasional writes. It doesn't scale automatically with usage, and provisioning IOPS for occasional writes would lead to unnecessary cost.
B) Deploy the database on Amazon Aurora Serverless to automatically scale the database capacity based on actual usage to accommodate the workload.
- Amazon Aurora Serverless automatically adjusts the database’s capacity based on the actual workload, which is ideal for applications with variable and unpredictable usage patterns.
- It is well-suited for read-heavy workloads with occasional writes, as it can scale based on the actual needs without over-provisioning.
- Aurora Serverless provides a cost-effective solution for variable workloads because you only pay for the database capacity that is actually in use, and it can scale up or down as needed.
Why selected: Aurora Serverless is the most cost-effective solution because it automa...
Author: Isabella1 · Last updated Jul 12, 2026
A company has many AWS accounts and uses AWS Organizations to manage all of them. A solutions architect must implement a solution that the company can use to share a common network across multiple accounts.
The company's infrastructure team has a dedicated infrastructure account that has a VPC. The infrastructure team must use this account to manage the network. Individual accounts cannot have the ability to manage their own networks. Ho...
In this scenario, the company needs to share a common network (VPC) across multiple AWS accounts while ensuring that individual accounts can create resources within specific subnets but cannot manage the network itself. The infrastructure team will manage the VPC in the infrastructure account. Let's go through the options and explain which ones fit best.
Option A: Create a transit gateway in the infrastructure account.
- Analysis: A transit gateway allows inter-VPC communication but does not necessarily address the requirement of sharing a common network within subnets across multiple accounts. This option could be useful if the accounts needed to connect VPCs across different regions or different accounts, but it doesn't directly enable sharing subnets or giving other accounts access to specific parts of a VPC.
- Rejection Reason: The question specifically mentions sharing a common network (VPC) and enabling accounts to create resources within subnets, not managing inter-VPC routing. Therefore, a transit gateway isn't necessary for this use case.
Option B: Enable resource sharing from the AWS Organizations management account.
- Analysis: This option suggests enabling resource sharing from the management account of AWS Organizations. However, resource sharing is typically managed through AWS Resource Access Manager (RAM) for specific resources like subnets or security groups. While this may sound related, it doesn’t directly involve VPC sharing or subnet-level sharing.
- Rejection Reason: This step alone does not provide a direct way to share the VPC or subnets across accounts. AWS Organizations management account is more about managing the organization, not necessarily about resource sharing within specific accounts.
Option C: Create VPCs in each AWS account within the organization in AWS Organizations. Configure the VPCs to share the same CIDR range and subnets as the VPC in the infrastructure account. Peer the VPCs in each individual account with the VPC in the infrastructure account.
- Analysis: This option describes setting up peering relationships between VPCs across multiple accounts, which would allow the sharing of networking resources. However, the key point is that individual a...
Author: Kai99 · Last updated Jul 6, 2026
A company hosts its application on several Amazon EC2 instances inside a VPC. The company creates a dedicated Amazon S3 bucket for each customer to store their relevant information in Amazon S3.
The company wants to ensure that the application running on EC2 instances can securely access only the S3 b...
To determine the most cost-effective and least operationally complex solution, we need to focus on securing access to Amazon S3 buckets while ensuring that only the EC2 instances within the VPC can access the company's AWS account's S3 buckets.
Key Factors:
1. Security: The solution must ensure that the EC2 instances in the VPC can only access the specific S3 buckets associated with the company’s account.
2. Operational Overhead: The solution should require minimal manual configuration and ongoing management.
3. Cost-Effectiveness: The solution should be cost-effective and avoid unnecessary infrastructure.
A) Create a gateway endpoint for Amazon S3 that is attached to the VPC. Update the IAM instance profile policy to provide access to only the specific buckets that the application needs.
- Gateway endpoints allow EC2 instances within the VPC to securely access Amazon S3 without requiring public internet access. This provides a secure, private connection to S3.
- IAM instance profile policies can be configured to restrict access to specific S3 buckets. The instance profile ensures that only EC2 instances with the correct IAM role can access the appropriate buckets.
Why selected: This solution is secure, simple to implement, and requires the least operational overhead. The gateway endpoint ensures traffic is routed privately, and IAM policies can enforce strict access control. The company can easily control which EC2 instances can access specific S3 buckets, all without needing to manage additional infrastructure like NAT gateways or managing complex network configurations.
B) Create a NAT gateway in a public subnet with a security group that allows access to only Amazon S3. Update the route tables to use the NAT Gateway.
- A NAT Gateway allows EC2 instances in private subnets to access the internet. While this can provide internet access to EC2 instances for accessing S3, it introduces unnecessary complexity and cost.
- Security group restrictions could be used to control traffic, but it’s not as effective or straightforward as using a gateway endpoint for direct, secure access to S3.
Why rejected: A NAT gateway is more complex and introduces higher operational over...
Author: Krishna · Last updated Jul 12, 2026
A company wants to use a third-party software-as-a-service (SaaS) application. The third-party SaaS application is consumed through several API calls. The third-party SaaS application also runs on AWS inside a VPC.
The company will consume the third-party SaaS application from inside a VPC. The company has internal security policies that mandate the use of private connectivity that does not traverse the internet. No resources that ru...
Let's evaluate each option based on the requirements:
Requirements:
- Private Connectivity: The connection should not traverse the public internet.
- No resources in the company’s VPC should be accessed from outside the VPC.
- Least Privilege Permissions: Only allow the minimum necessary access.
Option A: Create an AWS PrivateLink interface VPC endpoint. Connect this endpoint to the endpoint service that the third-party SaaS application provides. Create a security group to limit the access to the endpoint. Associate the security group with the endpoint.
- Analysis: AWS PrivateLink enables secure, private connectivity between VPCs and services running on AWS. By using a VPC interface endpoint, the company can securely consume the third-party SaaS application without the traffic going over the public internet. The traffic will stay within the AWS network. Additionally, you can configure a security group to control access to the interface endpoint, ensuring the company VPC has the least privileged access required. This solution perfectly meets the company's requirement of private connectivity and adherence to the principle of least privilege.
- Selection Reason: This is the most appropriate option because it provides private connectivity, ensures that no resources from the company VPC are exposed externally, and allows precise control over permissions using security groups.
Option B: Create an AWS Site-to-Site VPN connection between the third-party SaaS application and the company VPC. Configure network ACLs to limit access across the VPN tunnels.
- Analysis: A Site-to-Site VPN is designed for connecting on-premises networks or remote data centers to AWS VPCs. However, since the third-party SaaS application is already running on AWS and is consumed via API calls, establishing a VPN connection to the SaaS application may be unnecessary and complex. It also could potentially involve routing traffic through the internet (since the VPN is typically for on-prem to cloud connections), which does not meet the requirement for private connectivity within AWS.
- Rejection Reason: This is not suitable for the requirement of private connectivity ...
Author: Isabella1 · Last updated Jul 6, 2026
A company is building a cloud-based application on AWS that will handle sensitive customer data. The application uses Amazon RDS for the database, Amazon S3 for object storage, and S3 Event Notifications that invoke AWS Lambda for serverless processing.
The company uses AWS IAM Identity Center to manage user credentials. The development, testing, and operations teams need secure access to Amazon RDS and Amazon S3 while ensuring the...
To determine the best solution for this use case, we need to consider a few key factors such as security (confidentiality of sensitive data), operational overhead, scalability, and compliance with the principle of least privilege.
A) Use IAM roles with least privilege to grant all the teams access. Assign IAM roles to each team with customized IAM policies defining specific permission for Amazon RDS and S3 object access based on team responsibilities.
- Pros: This solution allows precise control over access, granting specific IAM roles with customized policies for each team based on their needs.
- Cons: While effective for enforcing least privilege, managing numerous IAM roles and policies could become cumbersome as the teams grow or new permissions need to be added/modified. Each role/policy requires manual upkeep, leading to increased operational overhead.
- Scenario Use: This could be used for smaller teams or when the roles and responsibilities of the teams are relatively static.
B) Enable IAM Identity Center with an Identity Center directory. Create and configure permission sets with granular access to Amazon RDS and Amazon S3. Assign all the teams to groups that have specific access with the permission sets.
- Pros: IAM Identity Center (formerly AWS SSO) is designed to simplify user management, especially in terms of centralizing authentication and authorization. By configuring permission sets with granular access, you can assign precise permissions to teams or groups with less manual overhead.
- Cons: This solution requires setting up and configuring IAM Identity Center, which may involve additional complexity upfront. However, once configured, it’s easy to manage and scale with much less operational overhead compared to manually managing IAM roles and policies.
- Scenario Use: This is best when you need to centrally manage access across multiple teams and ensure consistent and secure access control, with minimal overhead as the team grows or as the scope of access changes.
C) Create individual IAM users for each member in all the teams with role-based permissions. Assign the IAM roles with predefined policies for RDS and S3 access to each user based on user needs. Implement IAM Access Analyzer for perio...
Author: Aarav · Last updated Jul 12, 2026
A company needs to implement a patching process for its servers. The on-premises servers and Amazon EC2 instances use a variety of tools to perform patching. Management requires a single report showing the patch status of all the serve...
Let's go through each option to determine the best solution for patching the on-premises servers and EC2 instances and generating a unified report of patch status.
Requirements:
- Unified patching process for both on-premises servers and EC2 instances.
- Single report showing patch status for all servers and instances.
Option A: Use AWS Systems Manager to manage patches on the on-premises servers and EC2 instances. Use Systems Manager to generate patch compliance reports.
- Analysis: AWS Systems Manager provides a powerful suite of tools to manage the configuration and patching of both EC2 instances and on-premises servers. By installing the Systems Manager Agent (SSM Agent) on the on-premises servers, Systems Manager can patch both EC2 instances and on-premises servers in a consistent manner. Systems Manager Patch Manager can be used to manage patching, and AWS Systems Manager Compliance can generate a comprehensive patch compliance report for all instances.
- Selection Reason: This option directly addresses the need for managing patching across both EC2 and on-premises servers and generating a single, consolidated compliance report. It is an efficient and well-integrated solution within the AWS ecosystem.
Option B: Use AWS OpsWorks to manage patches on the on-premises servers and EC2 instances. Use Amazon QuickSight integration with OpsWorks to generate patch compliance reports.
- Analysis: AWS OpsWorks is a configuration management service that can also be used for patching servers, including EC2 and on-premises instances. However, it is more focused on configuration management and application deployment rather than patching. QuickSight integration could provide reporting, but it is primarily for visualizing data and not designed specifically for patching compliance.
- Rejection Reason: While AWS OpsWorks can manage patches, it is not as tailored for patch management as Systems Manager, which has more specific ...
Author: Matthew · Last updated Jul 6, 2026
A company has an Amazon S3 bucket that contains sensitive data files. The company has an application that runs on virtual machines in an on-premises data center. The company currently uses AWS IAM Identity Center.
The application requires temporary access to files in the S3 bucket. The comp...
Let's break down the options in the context of the company’s requirements: granting temporary and secure access to sensitive data files in an S3 bucket from an application running on virtual machines in an on-premises data center, with the company using AWS IAM Identity Center for managing user credentials.
A) Create an S3 bucket policy that permits access to the bucket from the public IP address range of the company’s on-premises data center.
- Pros: This option seems straightforward, as it involves using a bucket policy to restrict access to specific IP ranges.
- Cons: This approach introduces significant security risks because it does not provide temporary, fine-grained access control. The policy would allow any machine from the specified IP range to access the bucket, which could be a security vulnerability if an IP address is spoofed or compromised. Furthermore, this approach lacks integration with AWS IAM Identity Center, meaning there’s no centralized control over who or what accesses the bucket.
- Scenario Use: This method is only suitable for less secure, less dynamic environments where access needs can be easily controlled by IP and no sensitive data is involved.
B) Use IAM Roles Anywhere to obtain security credentials in IAM Identity Center that grant access to the S3 bucket. Configure the virtual machines to assume the role by using the AWS CLI.
- Pros: IAM Roles Anywhere allows the on-premises application to assume a role in AWS securely using IAM Identity Center, obtaining temporary security credentials. This solution integrates well with the existing IAM Identity Center setup and adheres to the principle of least privilege. The credentials provided are temporary, reducing the security risks associated with long-term access keys.
- Cons: This option requires setting up IAM Roles Anywhere, which can involve additional configuration steps. However, the benefits of security, temporary credentials, and the use of IAM Identity Center make it an excellent choice.
- Scenario Use: Ideal when the company already uses AWS IAM Identity Center and needs a secure, centralized way to manage access to S3 for on-premises applications.
C...
Author: Zara1234 · Last updated Jul 12, 2026
A company is running an application on several Amazon EC2 instances in an Auto Scaling group behind an Application Load Balancer. The load on the application varies throughout the day, and EC2 instances are scaled in and out on a regular basis. Log files from the EC2 instances are copied to a central Amazon S3 bucket every 15 minutes. The security team discovers that log files are mis...
In this scenario, the company is facing issues where log files from EC2 instances are missing upon termination. The goal is to ensure that log files are properly copied to a central Amazon S3 bucket before the instance is terminated. Let's review each option based on the requirements:
Key Points to Consider:
- Log files need to be copied before termination: The log files should be copied from the instance before it is terminated.
- Automating the process during the termination: The solution must automate the process of copying log files when an EC2 instance is terminated in the Auto Scaling group.
- Handling lifecycle events: Auto Scaling lifecycle hooks and EventBridge should be leveraged to trigger the process during the termination lifecycle.
Option A: Create a script to copy log files to Amazon S3, and store the script in a file on the EC2 instance. Create an Auto Scaling lifecycle hook and an Amazon EventBridge rule to detect lifecycle events from the Auto Scaling group. Invoke an AWS Lambda function on the `autoscaling:EC2_INSTANCE_TERMINATING` transition to send ABANDON to the Auto Scaling group to prevent termination, run the script to copy the log files, and terminate the instance using the AWS SDK.
- Analysis: This option involves creating a script on the EC2 instance to copy the log files and using a Lambda function in response to the termination event. The Lambda function sends an `ABANDON` signal to prevent termination, runs the script to copy the log files, and then terminates the instance using the AWS SDK.
- Rejection Reason: While this approach would work, it introduces unnecessary complexity with the `ABANDON` action and manually invoking termination using the AWS SDK. It also involves more steps than required for just copying the log files during the termination process.
Option B: Create an AWS Systems Manager document with a script to copy log files to Amazon S3. Create an Auto Scaling lifecycle hook and an Amazon EventBridge rule to detect lifecycle events from the Auto Scaling group. Invoke an AWS Lambda function on the `autoscaling:EC2_INSTANCE_TERMINATING` transition to call the AWS Systems Manager API `SendCommand` operation to run the document to copy the log files and send `CONTINUE` to the Auto Scaling group to terminate the instance.
- Analysis: This option leverages AWS Systems Manager to run a script that copies the log files and integrates it with ...
Author: ThunderBear · Last updated Jul 6, 2026
A company hosts its core network services, including directory services and DNS, in its on-premises data center. The data center is connected to the AWS Cloud using AWS Direct Connect (DX). Additional AWS accounts are planned that will require quick, cost-effective, and consistent access to these network...
Let's evaluate the options based on the company’s requirements: providing quick, cost-effective, and consistent access to on-premises network services (directory services, DNS, etc.) for multiple AWS accounts with the least operational overhead.
A) Create a DX connection in each new account. Route the network traffic to the on-premises servers.
- Pros: This solution directly connects each new account to the on-premises network using AWS Direct Connect (DX).
- Cons: This is not cost-effective and introduces significant operational overhead because each new account requires a separate DX connection. Managing multiple DX connections across multiple accounts would become cumbersome and expensive. Additionally, each new connection requires setup, management, and monitoring, which increases complexity.
- Scenario Use: This approach is only practical for a very limited number of accounts or if there are unique, isolated requirements per account.
B) Configure VPC endpoints in the DX VPC for all required services. Route the network traffic to the on-premises servers.
- Pros: VPC endpoints allow secure, scalable access to AWS services directly from within a VPC. However, VPC endpoints are primarily designed for AWS services like S3, DynamoDB, etc., and not for accessing on-premises network services like DNS or directory services.
- Cons: VPC endpoints cannot directly route traffic to on-premises network resources such as directory services or DNS, so they would not meet the requirement of connecting to on-premises servers. This solution is more suitable for accessing AWS-managed services.
- Scenario Use: This option is suitable if the primary goal was to connect to AWS services (e.g., S3) but not for connecting to on-premises resources.
C) Create a VPN connection between each new account and the DX VPC. Route the network traffic to the on-premises servers.
- Pros: Setting up a VPN connection between new accounts and the DX VPC is a valid method to route traffic from AWS to on-premises services. It can be cost-effective and quick to implement compared to creating a separate DX connection for each new account.
- Cons: While the VPN soluti...
Author: IronLion88 · Last updated Jul 12, 2026
A company hosts its main public web application in one AWS Region across multiple Availability Zones. The application uses an Amazon EC2 Auto Scaling group and an Application Load Balancer (ALB).
A web development team needs a cost-optimized compute solution to improve the comp...
Let's evaluate each option based on the company's requirement to improve the ability to serve dynamic content globally to millions of customers while keeping the solution cost-optimized:
A) Create an Amazon CloudFront distribution. Configure the existing ALB as the origin.
- Pros: Amazon CloudFront is a content delivery network (CDN) that caches content at edge locations around the world, significantly improving latency for customers globally. Using CloudFront with the existing Application Load Balancer (ALB) as the origin allows dynamic content to be served more efficiently. CloudFront also supports features like caching, automatic failover, and DDoS protection (via AWS Shield). Additionally, CloudFront reduces the load on the origin server (the ALB and EC2 instances) by caching responses for frequently requested content.
- Cons: There may be a small upfront configuration cost, but CloudFront is cost-effective, especially when serving dynamic content and reducing server load by caching static content.
- Scenario Use: This solution is ideal when serving dynamic content globally with minimal latency. It's a highly cost-effective and scalable way to distribute traffic while optimizing costs based on demand.
B) Use Amazon Route 53 to serve traffic to the ALB and EC2 instances based on the geographic location of each customer.
- Pros: Amazon Route 53 can route traffic based on geolocation, which can direct users to the closest AWS region or availability zone. This could potentially reduce latency by directing traffic to the nearest region.
- Cons: While this method might help route traffic more efficiently, it does not provide a global caching layer like CloudFront, which would still result in the need to serve dynamic content directly from EC2 instances. This increases operational complexity, latency, and costs. It's also not as scalable or efficient as using a CDN to cache content closer to users.
- Scenario Use: This could be useful for simple geolocation-based routing but does not address the need for global content distribution or cost-optimized compute solutions like CloudFront.
C) Create an Amazon S3 bucket with publ...
