Amazon Practice Questions, Discussions & Exam Topics by our Authors
A company has a solution that analyzes weather data from thousands of weather stations. The weather stations send the data over an Amazon API Gateway REST API that has an AWS Lambda function integration. The Lambda function calls a third-party service for data pre-processing. The third-party service gets overloaded and fails the pre-processing, causing a loss of data.
A solutions architect must improve the resiliency of the solut...
To improve the resiliency of the solution and ensure that no data is lost, the key objectives are to decouple the data processing pipeline, provide retries, and allow for processing to continue when failures occur, especially in the third-party service. Let's evaluate each option:
Key Requirements:
- No data loss: Ensure that if failures occur, data can be retained and processed later.
- Resiliency: The system should continue functioning even if the third-party service fails.
- Process failures gracefully: Allow the data to be retried or processed at a later time.
Option A: Create an Amazon Simple Queue Service (Amazon SQS) queue and configure it as the dead-letter queue for the API
- Dead-letter queues (DLQs) are used to store failed messages for later inspection, but they don't directly address the need to retry or process data after a failure.
- Drawbacks:
- A dead-letter queue is typically used to store messages that failed permanently after multiple retries. However, in this case, the requirement is to ensure the data can be processed later after a failure, not just stored for analysis.
- No retry mechanism: This option alone doesn't provide a way to automatically retry or process data later.
Option B: Create two Amazon Simple Queue Service (Amazon SQS) queues: a primary queue and a secondary queue (dead-letter queue). Configure the primary queue to be integrated with the API, and the Lambda function as the invocation target for the primary queue.
- Primary Queue: This is the main queue for processing the data, and the Lambda function would be triggered for each message.
- Secondary Queue (DLQ): This is where failed messages would go after several unsuccessful retry attempts.
- Benefits:
- Retry mechanism: The primary SQS queue allows for retries in case of failure, ensuring that messages are not lost immediately.
- No data loss: If the data cannot be processed successfully, it moves to the secondary queue, and you can analyze the failures later.
- Decoupling: Using an SQS queue decouples the API Gateway from Lambda, ensuring that data is not lost during API failures and can be processed asynchronously.
- W...
Author: NebulaEagle11 · Last updated Jul 6, 2026
A company built an ecommerce website on AWS using a three-tier web architecture. The application is Java-based and composed of an Amazon CloudFront distribution, an Apache web server layer of Amazon EC2 instances in an Auto Scaling group, and a backend Amazon Aurora MySQL database.
Last month, during a promotional sales event, users reported errors and timeouts while adding items to their shopping carts. The operations team recovered the logs created by the web servers and reviewed Aurora DB cluster performance metrics. Some of the web servers were terminated before log...
To improve application performance visibility during peak traffic events, the solutions architect must take steps that allow for comprehensive monitoring, performance analysis, and debugging of both the web servers and the backend database. Here's the reasoning for selecting the most suitable options:
Option A: Configure the Aurora MySQL DB cluster to publish slow query and error logs to Amazon CloudWatch Logs.
- Reason for selection: The solution needs to gather detailed performance data from the Aurora MySQL database. Slow query and error logs are essential to identifying bottlenecks and performance issues during peak traffic. By sending these logs to Amazon CloudWatch Logs, the team can monitor and review the queries that are causing performance problems.
- Why others are rejected: While other options provide visibility into different components, this one specifically targets the database's query performance, which was a key issue in the scenario.
Option B: Implement the AWS X-Ray SDK to trace incoming HTTP requests on the EC2 instances and implement tracing of SQL queries with the X-Ray SDK for Java.
- Reason for selection: AWS X-Ray is useful for tracing requests across different layers of the application. By tracing incoming HTTP requests and SQL queries, the team can better understand the performance issues and the root cause of errors and timeouts. This solution provides a holistic view of both web server performance and database interactions.
- Why others are rejected: X-Ray tracing provides end-to-end visibility of requests and is especially useful when debugging complex interactions across multiple tiers of the application. The integration of tracing into both the EC2 layer and the database (Aurora MySQL) ensures that both areas are monitored effectively.
Option D: Install and configure an Amazon CloudWatch Logs agent on the EC2 insta...
Author: Aarav · Last updated Jul 6, 2026
A company that provisions job boards for a seasonal workforce is seeing an increase in traffic and usage. The backend services run on a pair of Amazon EC2 instances behind an Application Load Balancer with Amazon DynamoDB as the datastore. Application read and write traffic is slow during peak ...
To provide a scalable application architecture that can handle peak seasons with the least development effort, the options must be evaluated based on scalability, ease of implementation, and the ability to meet the increasing demands of traffic and usage.
Option A: Migrate the backend services to AWS Lambda. Increase the read and write capacity of DynamoDB.
- Reason for rejection: Migrating to AWS Lambda can certainly scale with traffic, but it would require significant changes to the architecture, particularly in terms of how the application is structured and how state is managed. Simply increasing the read and write capacity of DynamoDB may not be sufficient to address the issue, as it doesn't solve the underlying problem of scaling backend services. Also, this approach adds complexity and would require significant refactoring of the existing application.
Option B: Migrate the backend services to AWS Lambda. Configure DynamoDB to use global tables.
- Reason for rejection: Like Option A, migrating to Lambda involves considerable refactoring of the backend services. Configuring DynamoDB to use global tables is useful for multi-region replication, but it wouldn't address the underlying issue of handling traffic spikes within a single region and optimizing the backend services to scale efficiently. This option also introduces more complexity with Lambda migration and potentially cross-region data replication, which may not be necessary.
Option C: Use Auto Scaling groups for the backend services. Use DynamoDB auto scaling.
- Reason for selection: This option is the most straightforward and scalable approach with the least development effort. By using Auto Scaling for the EC2 instances, the application can automatically adjust to varying levels of demand during peak seasons. The Dy...
Author: FrozenWolf2022 · Last updated Jul 6, 2026
A company is migrating to the cloud. It wants to evaluate the configurations of virtual machines in its existing data center environment to ensure that it can size new Amazon EC2 instances accurately. The company wants to collect metrics, such as CPU, memory, and disk utilization, and it needs an inventory of what processes are running on each instance. The company ...
To determine the most cost-effective solution for collecting the required metrics and inventory data, we need to carefully evaluate each option based on key factors such as ease of deployment, coverage, and costs associated with the chosen service.
Key Requirements:
- Collecting metrics: The company needs CPU, memory, disk utilization, and network information.
- Inventory of processes: The company needs detailed data about running processes on each machine.
- Mapping communication between servers: The company needs insight into network connections.
- Cost-effectiveness: The solution should be efficient and minimize costs, particularly during the migration phase.
Option Breakdown:
A) Use AWS Application Discovery Service and deploy the data collection agent to each virtual machine in the data center.
- Pros:
- AWS Application Discovery Service provides a comprehensive tool for discovering and assessing existing environments, and it can collect a broad range of data, including resource utilization (CPU, memory, disk) and running processes.
- This solution includes the ability to analyze network connections and map dependencies between servers.
- Cons:
- The agent deployment on each virtual machine may be time-consuming and require significant manual effort, especially in large environments.
- The service incurs costs based on the number of agents deployed, making it potentially more expensive if many virtual machines are involved.
B) Configure the Amazon CloudWatch agent on all servers within the local environment and publish metrics to Amazon CloudWatch Logs.
- Pros:
- CloudWatch is a widely used and cost-effective service for monitoring and collecting system-level metrics such as CPU, memory, and disk usage.
- The CloudWatch agent can be configured to gather a broad range of metrics and logs, and it provides detailed insight into server performance.
- Data is sent directly to CloudWatch, where you can configure alerts, visualize data, and track utilization.
- Cons:
- While CloudWatch can monitor many metrics, it does not provide out-of-the-box support for process-level data or mapping network connections.
- You would need to manually configure the agent on each server, which could be challenging in large-scale environments. However, the cost-effectiveness and scalability of CloudWatch make it a strong contender.
...
Author: Henry · Last updated Jul 6, 2026
A company provides a software as a service (SaaS) application that runs in the AWS Cloud. The application runs on Amazon EC2 instances behind a Network Load Balancer (NLB). The instances are in an Auto Scaling group and are distributed across three Availability Zones in a single AWS Region.
The company is deploying the application into additional Regions. The company must provide static IP addresses for the application to customers so that the cust...
To meet the requirement of providing static IP addresses for the application and routing customers to the geographically closest AWS Region, we need to consider the ability to use static IP addresses, route traffic efficiently to the correct region based on proximity, and manage multiple regions in a way that ensures high availability and performance.
Option A: Create an Amazon CloudFront distribution. Create a CloudFront origin group. Add the NLB for each additional Region to the origin group. Provide customers with the IP address ranges of the distribution’s edge locations.
- Reason for rejection: CloudFront typically uses edge locations to route traffic, but it is primarily designed for HTTP/HTTPS traffic rather than non-HTTP(S) protocols, which is a key consideration for SaaS applications that may not rely on these protocols. Additionally, CloudFront does not directly provide static IP addresses, as it uses dynamic edge locations for routing, and customers would need to allow list CloudFront edge IP ranges, not specific static IPs.
- Why not optimal: The use of CloudFront is not ideal when the primary requirement is to provide static IP addresses. CloudFront also does not directly address the issue of routing traffic to geographically closer regions via static IPs.
Option B: Create an AWS Global Accelerator standard accelerator. Create a standard accelerator endpoint for the NLB in each additional Region. Provide customers with the Global Accelerator IP address.
- Reason for selection: AWS Global Accelerator provides static IP addresses that remain consistent across regions. It intelligently routes traffic to the closest available endpoint (in this case, the NLB in the appropriate region) based on the user’s location. Global Accelerator uses Anycast routing to automatically direct users to the nearest region, and it also provides high availability by automatically routing traffic to healthy endpoints. This meets both the requirement for static IPs and geographically optimized routing.
- Why optimal: Global Accelerator directly provides static IP addresses and optimizes traffic routing to the nearest region, making it the most suitable option for the given requirements.
Option C: Create an Amazon CloudFront distribution...
Author: StarlightBear · Last updated Jul 6, 2026
A company is running multiple workloads in the AWS Cloud. The company has separate units for software development. The company uses AWS Organizations and federation with SAML to give permissions to developers to manage resources in their AWS accounts. The development units each deploy their production workloads into a common production account.
Recently, an incident occurred in the production account in which members of a development unit terminated an EC2 instance that belonged to a different development unit. A solutions architect must...
In this scenario, the primary goal is to create a solution that allows each development unit to manage its own resources while preventing incidents like the accidental termination of EC2 instances belonging to other development units. The solution needs to enforce boundaries based on resource tagging and should ensure that developers can manage only the resources tagged with their development unit’s name.
Let’s break down each option and evaluate its effectiveness:
Option A: Create separate OUs in AWS Organizations for each development unit. Assign the created OUs to the company AWS accounts. Create separate SCP with a deny action and a StringNotEquals condition for the DevelopmentUnit resource tag that matches the development unit name. Assign the SCP to the corresponding OU.
- Reason for rejection: While this approach makes good use of AWS Organizations and SCPs (Service Control Policies), it is not fully granular for resource-level management. SCPs are applied at the organizational level and restrict actions across all accounts in an OU. This would prevent developers from managing EC2 instances even if they belong to their own unit, as the SCP would apply the deny action across accounts within the OU. This would limit their ability to perform actions on their own resources and doesn’t allow for the flexibility needed to grant permissions per resource.
- Why not optimal: SCPs are better suited for broader permissions management and are not granular enough for managing access to specific resources (e.g., EC2 instances) within an account. It doesn’t meet the requirement of allowing developers to manage only their own resources without restricting them too broadly.
Option B: Pass an attribute for DevelopmentUnit as an AWS Security Token Service (AWS STS) session tag during SAML federation. Update the IAM policy for the developers assumed IAM role with a deny action and a StringNotEquals condition for the DevelopmentUnit resource tag and aws:PrincipalTag/DevelopmentUnit.
- Reason for selection: This option leverages AWS STS session tags, which can be passed during SAML federation, and uses IAM policies with a `StringNotEquals` condition on the `DevelopmentUnit` resource tag. This ensures that developers can only manage resources tagged with their specific development unit’s name. It enforces the principle of least privilege and allows each development unit to control its own resources by tagging EC2 instances with a `DevelopmentUnit` tag. This solution effectively prevents incidents like the one mentioned in the scenario, where developers from one unit accidentally terminated EC2 instances belonging to another unit.
- Why optimal: This approach combines the flexibility of IAM policies with the granular control of resource tags. It ensures that developers can manage only their assigned resources while preventing cross-unit actions that could lead to conflicts or mistakes. It is the most flexible and least restrictive solution for resource-level control.
Option C: Pass an attribute...
Author: Kai99 · Last updated Jul 6, 2026
An enterprise company is building an infrastructure services platform for its users. The company has the following requirements:
* Provide least privilege access to users when launching AWS infrastructure so users cannot provision unapproved services.
* Use a central account to manage the creation of infrastructure services.
* Provide the ability to distribute infrastructure services to multiple accounts in AWS Organization...
To meet the requirements of the enterprise company building the infrastructure services platform, let's carefully evaluate each option:
Requirements Recap:
1. Provide least privilege access to users when launching AWS infrastructure.
2. Use a central account to manage the creation of infrastructure services.
3. Distribute infrastructure services to multiple accounts in AWS Organizations.
4. Enforce tags on any infrastructure started by users.
Analysis of Each Option:
A) Develop infrastructure services using AWS CloudFormation templates. Add the templates to a central Amazon S3 bucket and add the IAM roles or users that require access to the S3 bucket policy.
- Explanation: While this option provides central storage for CloudFormation templates, it does not provide centralized management or governance of infrastructure services, nor does it enforce tagging. The access model is based on S3 bucket permissions, which is a less efficient and more error-prone way to manage infrastructure templates. Therefore, this option does not fully satisfy all requirements.
- Rejected: Does not address centralized management of services or enforcement of tags.
B) Develop infrastructure services using AWS CloudFormation templates. Upload each template as an AWS Service Catalog product to portfolios created in a central AWS account. Share these portfolios with the Organizations structure created for the company.
- Explanation: This option is strong because it:
- Uses AWS Service Catalog, a centralized service for managing infrastructure templates.
- Uploads CloudFormation templates as Service Catalog products to a portfolio, and shares those portfolios across AWS Organization accounts.
- Enables centralized management of resources and enforces least privilege access by limiting the services users can provision to only those products in the catalog.
- Tagging enforcement can also be managed through AWS Service Catalog's TagOption Library.
- Selected: This option provides centralized control, distribution across accounts, and the ability to enforce least privilege access.
C) Allow user IAM roles to have AWSCloudFormationFullAccess and AmazonS3ReadOnlyAccess permissions. Add an Organizations SCP at the AWS account root user level to deny all services except AWS CloudFormation and Amazon S3.
- Explanation: While this approach involves creating an SCP (Service Control Policy) to limit which services users can access, it doesn't provide centralized management of infrastructure templates or enforce any tags. The user's ability to create CloudFormation stacks is not directly tied to a service catalog or other governance mechanisms like tagging enforcement. Thus, it only limits service access but lack...
Author: VioletCheetah55 · Last updated Jul 6, 2026
A company deploys a new web application. As part of the setup, the company configures AWS WAF to log to Amazon S3 through Amazon Kinesis Data Firehose. The company develops an Amazon Athena query that runs once daily to return AWS WAF log data from the previous 24 hours. The volume of daily logs is constant. However, over time, the same query is taking more time to run.
A solutions architect needs...
To address the issue of increasing query times when running the Athena query on AWS WAF log data, we need to focus on optimizing how the data is structured and queried in Amazon Athena. Let’s evaluate the options:
A) Create an AWS Lambda function that consolidates each day's AWS WAF logs into one log file.
- Explanation: Consolidating logs into a single file might reduce the number of objects in S3, but it won’t address the core issue of Athena's performance when querying large datasets. In fact, consolidating data into a single large file could make queries less efficient because Athena will have to scan the entire log file, which is likely to increase query time as the data grows.
- Rejected: This approach does not solve the problem of increasing query time and could even worsen performance by forcing Athena to scan large files.
B) Reduce the amount of data scanned by configuring AWS WAF to send logs to a different S3 bucket each day.
- Explanation: Splitting the logs into different S3 buckets by day could organize the logs better, but it won't improve Athena's query performance. Athena queries are based on how data is structured (partitioned) and indexed, not just how it’s stored in S3 buckets. Additionally, separating logs into different buckets increases complexity and does not optimize the query process.
- Rejected: This option doesn’t optimize data partitioning or the query process in Athena.
C) Update the Kinesis Data Firehose configuration to partition the data in Amazon S3 by date and time. Create external tables for Amazon Redshift. Configure Amazon Redshift Spectrum to query the data s...
Author: Emily · Last updated Jul 6, 2026
A company is developing a web application that runs on Amazon EC2 instances in an Auto Scaling group behind a public-facing Application Load Balancer (ALB). Only users from a specific country are allowed to access the application. The company needs the ability to log the access requests th...
To determine the most suitable solution for blocking access to the web application based on country of origin, we need to consider factors such as ease of maintenance, effectiveness, and the ability to log blocked requests.
Key Requirements:
1. Blocking access based on country: Only users from a specific country should be allowed to access the application.
2. Logging blocked requests: The solution should be capable of logging blocked requests for monitoring and auditing purposes.
3. Least maintenance: The solution should be easy to manage and maintain over time.
4. Scalability: The solution should scale automatically with the application, as it runs on EC2 instances within an Auto Scaling group behind an ALB.
Option Breakdown:
A) Create an IPSet containing a list of IP ranges that belong to the specified country. Create an AWS WAF web ACL. Configure a rule to block any requests that do not originate from an IP range in the IPSet. Associate the rule with the web ACL. Associate the web ACL with the ALB.
- Pros:
- AWS WAF allows you to block requests based on IP ranges (country-specific), which is ideal for the given use case.
- AWS WAF supports logging of all requests, including blocked ones, which is important for auditing.
- WAF is fully managed, scalable, and integrates well with the ALB.
- Allows fine-grained control over web traffic, such as rate limiting and blocking specific countries.
- Cons:
- Requires maintaining an IPSet with the appropriate IP ranges, but this is automated with services like AWS IP Reputation Lists, making it relatively low-maintenance.
B) Create an AWS WAF web ACL. Configure a rule to block any requests that do not originate from the specified country. Associate the rule with the web ACL. Associate the web ACL with the ALB.
- Pros:
- AWS WAF can block requests based on the specified country (via GeoMatch conditions), which is directly aligned with the requirement.
- Like Option A, WAF integrates with the ALB and supports logging blocked requests.
- Fully managed service, scalable, and provides automatic updates for WAF rules.
- Cons:
- This option doesn’t explicitly mention us...
Author: Maya · Last updated Jul 6, 2026
A company is migrating an application from on-premises infrastructure to the AWS Cloud. During migration design meetings, the company expressed concerns about the availability and recovery options for its legacy Windows file server. The file server contains sensitive business-critical data that cannot be recreated in the event of data corruption or data loss. According to compliance requirements, the data must not travel across the public internet. The company wants to move to AWS managed services where possible.
The company decides to store...
To meet the company's requirements for disaster recovery (DR) with AWS-managed services, we need to ensure that the solution involves secure, private data transfer between regions, leveraging AWS-managed services for simplicity, availability, and compliance. Let's evaluate each option carefully.
Key Requirements:
- Disaster recovery: The company needs to replicate data from the primary region to the disaster recovery (DR) region.
- Sensitive business-critical data: The data cannot be exposed to the public internet.
- Compliance: The data must not travel over the public internet.
- AWS Managed Services: The company prefers to use managed services where possible to reduce maintenance overhead.
Option Breakdown:
A) Create a destination Amazon S3 bucket in the DR Region. Establish connectivity between the FSx for Windows File Server file system in the primary Region and the S3 bucket in the DR Region by using Amazon FSx File Gateway. Configure the S3 bucket as a continuous backup source in FSx File Gateway.
- Pros:
- Amazon FSx File Gateway is a managed service that integrates with Amazon FSx for Windows File Server to support hybrid cloud environments.
- S3 is scalable and cost-effective for storing backups.
- Data is stored securely in the DR region, and Amazon FSx File Gateway can facilitate continuous backups.
- Cons:
- FSx File Gateway is more suited for hybrid cloud environments, and using S3 as an intermediary might not align with the requirement for full Windows File Server replication for DR.
- This option does not directly replicate the FSx for Windows File Server file system itself; instead, it relies on backup/restore mechanisms using S3.
B) Create an FSx for Windows File Server file system in the DR Region. Establish connectivity between the VPC in the primary Region and the VPC in the DR Region by using AWS Site-to-Site VPN. Configure AWS DataSync to communicate by using VPN endpoints.
- Pros:
- AWS DataSync can efficiently transfer large volumes of data between file systems in different regions.
- Site-to-Site VPN ensures that the data transfer is private and does not traverse the public internet.
- Cons:
- Site-to-Site VPN may not provide the best performance for large-scale data transfers due to bandwidth limitations.
- VPN connectivity requires ongoing management, especially for scaling to meet large transfer demands.
C) Create an FSx for Windows File Server file system in the DR Region. Establish connectivity between the VPC in the primary Region and the VPC in the DR Region by using VPC peering. Configure AWS DataSync to communicate by using interface VPC end...
Author: Sofia · Last updated Jul 6, 2026
A company is currently in the design phase of an application that will need an RPO of less than 5 minutes and an RTO of less than 10 minutes. The solutions architecture team is forecasting that the database will store approximately 10 TB of data. As part of the design, they are looking for a database solution that will provide...
Requirements Recap:
- RPO of less than 5 minutes (Recovery Point Objective: minimal data loss).
- RTO of less than 10 minutes (Recovery Time Objective: fast recovery).
- Data size of approximately 10 TB.
- Failover to a secondary region.
- Lowest cost solution.
Analysis of Each Option:
A) Deploy an Amazon Aurora DB cluster and take snapshots of the cluster every 5 minutes. Once a snapshot is complete, copy the snapshot to a secondary Region to serve as a backup in the event of a failure.
- Explanation:
- Snapshots provide a backup but are not suitable for low RPO and RTO requirements. The process of taking snapshots every 5 minutes and copying them to a secondary region can lead to significant delays in recovery, making it unsuitable for an RPO of less than 5 minutes and an RTO of less than 10 minutes.
- Aurora snapshots are not real-time and might introduce high recovery times due to the need to restore the snapshot in the event of a failure.
- Cost: Aurora snapshots and cross-region snapshot copying incur additional costs, and this option could be more expensive due to the backup frequency and storage costs.
- Rejected: This option does not meet the low RPO and RTO requirements and is relatively high-cost compared to other solutions.
B) Deploy an Amazon RDS instance with a cross-Region read replica in a secondary Region. In the event of a failure, promote the read replica to become the primary.
- Explanation:
- Cross-region read replica in RDS allows for disaster recovery across regions. This option provides low RPO (as replication can be near real-time) and relatively quick failover (manual promotion of the read replica to become the primary).
- Cost: Cross-region read replicas are more cost-effective than using separate clusters in two regions, as it leverages RDS' built-in replication features. However, it still incurs some cost for replication, instance, and data transfer across regions.
- This option can meet the 5-minute RPO and 10-minute RTO with manual failover, which is acceptable in some scenarios but introduces the manual intervention requirement.
- Selected: This is the most cost-effective option for meeting th...
Author: Julian · Last updated Jul 6, 2026
A financial company needs to create a separate AWS account for a new digital wallet application. The company uses AWS Organizations to manage its accounts. A solutions architect uses the IAM user Support1 from the management account to create a new member account with finance1@ex...
To create IAM users in the newly created member account, the solutions architect needs to consider the correct method to access the new account and assign the necessary permissions.
Let's break down each option:
Option A: Sign in to the AWS Management Console with AWS account root user credentials by using the 64-character password from the initial AWS Organizations email sent to fice1@example.com. Set up the IAM users as required.
- This method involves using the root account credentials of the new member account (which would be sent to fice1@example.com).
- Drawback: The root user should not be used for day-to-day operations in AWS, as it has unlimited access. Best practices dictate using IAM roles and users to manage resources instead of the root user.
- Rejected: Root account usage is discouraged for security reasons.
Option B: From the management account, switch roles to assume the OrganizationAccountAccessRole role with the account ID of the new member account. Set up the IAM users as required.
- This method involves role assumption. The management account has an OrganizationAccountAccessRole (a predefined role) in all AWS accounts under the organization.
- Key advantage: This allows the solutions architect to securely access the new member account without using root credentials, and it adheres to AWS best practices for least privilege.
- Selected option: The solutions architect can assume this role from the management account, which would provide the necessary permissions to set up IAM users in the new member account.
Option C: Go to the AWS...
Author: RadiantPhoenixX · Last updated Jul 6, 2026
A car rental company has built a serverless REST API to provide data to its mobile app. The app consists of an Amazon API Gateway API with a Regional endpoint, AWS Lambda functions, and an Amazon Aurora MySQL Serverless DB cluster. The company recently opened the API to mobile apps of partners. A significant increase in the number of requests resulted, causing sporadic database memory errors.
Analysis of the API traffic indicates that clients are making multiple HTTP GET requests for the same queries in a short period of time. Traffic is concentrated during busi...
To address the car rental company’s issue of database memory errors due to increased API traffic and frequent duplicate requests, let's analyze the options available and evaluate the best strategy.
Breakdown of the Options:
Option A: Convert the API Gateway Regional endpoint to an edge-optimized endpoint. Enable caching in the production stage.
- Edge-optimized endpoints are primarily for global access and reduce latency by routing requests to the closest AWS region. This doesn't address the root issue of multiple identical GET requests hitting the database frequently. The caching aspect could help reduce database load by caching responses, but it is more effective for reducing latency rather than solving the specific problem of memory errors caused by repeated queries.
- Rejected: While caching is useful, this option is not the best solution for the described problem (frequent repetitive requests leading to database memory issues). Edge-optimized endpoints are not necessary for solving the database memory issues either.
Option B: Implement an Amazon ElastiCache for Redis cache to store the results of the database calls. Modify the Lambda functions to use the cache.
- ElastiCache for Redis is a good fit for caching frequently accessed data to reduce load on the database. By caching the results of the database calls in Redis, repeated identical GET requests can be served from the cache rather than querying the database each time, which would reduce the load on the Aurora DB and minimize memory errors.
- Key advantage: This option addresses the issue directly by reducing the strain on the database, especially for frequently accessed data, and it can handle spikes in traffic more effectively. It also scales automatically with the increased load.
- Selected option: This is the best solution because it directly addresses the issue of multiple redundant requests and database memory overload by caching frequent que...
Author: Amira99 · Last updated Jul 6, 2026
A company is migrating an on-premises application and a MySQL database to AWS. The application processes highly sensitive data, and new data is constantly updated in the database. The data must not be transferred over the internet. The company also must encrypt the data in transit and at rest.
The database is 5 TB in size. The company already has created the database schema in an Amazon RDS for MySQL DB instance. The company has set up a 1 Gbps AWS Direct Connect connection to AWS. The compa...
Let's evaluate the options based on the requirements of migrating a 5 TB MySQL database with high security, minimal downtime, and data encryption at rest and in transit. The company also needs to avoid transferring the data over the internet and already has AWS Direct Connect set up.
Breakdown of the Options:
Option A: Perform a database backup. Copy the backup files to an AWS Snowball Edge Storage Optimized device. Import the backup to Amazon S3. Use server-side encryption with Amazon S3 managed encryption keys (SSE-S3) for encryption at rest. Use TLS for encryption in transit. Import the data from Amazon S3 to the DB instance.
- Snowball Edge provides secure physical devices for large data transfers to AWS, especially for environments with limited internet connectivity.
- Advantages: Physical transport of the data avoids internet transfer and ensures high security.
- Disadvantages: Snowball is more suited for bulk data transfer. This approach may lead to more downtime due to the need to wait for the Snowball device to arrive, load, and transfer the data.
- Rejected: While secure, this solution doesn't minimize downtime during the migration, as it involves waiting for physical devices to arrive and be processed.
Option B: Use AWS Database Migration Service (AWS DMS) to migrate the data to AWS. Create a DMS replication instance in a private subnet. Create VPC endpoints for AWS DMS. Configure a DMS task to copy data from the on-premises database to the DB instance by using full load plus change data capture (CDC). Use the AWS Key Management Service (AWS KMS) default key for encryption at rest. Use TLS for encryption in transit.
- AWS DMS is designed for minimal downtime migrations by using continuous data replication with CDC (Change Data Capture) after an initial full load. It allows for the migration of live data while it is still being updated.
- Advantages:
- Secure and efficient.
- DMS supports encryption in transit (using TLS) and at rest (using KMS for encryption).
- It allows for near-zero downtime by keeping the source database in sync with the target.
- Best fit: This option is optimal for migrating a database with ongoing updates and minimal downtime, and it meets the security requirements.
- Selected: DMS is designed fo...
Author: Samuel · Last updated Jul 6, 2026
Accompany is deploying a new cluster for big data analytics on AWS. The cluster will run across many Linux Amazon EC2 instances that are spread across multiple Availability Zones.
All of the nodes in the cluster must have read and write access to common underlying file storage. The file storage must be highly available, must be resilient, must be compatible w...
The requirements for the storage solution are clear: it must be highly available, resilient, POSIX-compatible, and support high throughput. Let's break down each option and see which one best fits these needs.
Option A: Provision an AWS Storage Gateway file gateway NFS file share that is attached to an Amazon S3 bucket. Mount the NFS file share on each EC2 instance in the cluster.
- AWS Storage Gateway is typically used to bridge on-premises environments with cloud storage and is designed for hybrid cloud scenarios.
- Disadvantages:
- It's primarily focused on storing data in Amazon S3 and isn't designed for high-performance, low-latency file storage like Amazon EFS.
- While it offers NFS access to S3, it doesn't provide the same level of performance or POSIX file system compatibility as other options like Amazon EFS.
- It doesn't meet the high throughput requirements for big data analytics.
- Rejected: This option is not suited for high-performance, POSIX-compliant, high-throughput file storage.
Option B: Provision a new Amazon Elastic File System (Amazon EFS) file system that uses General Purpose performance mode. Mount the EFS file system on each EC2 instance in the cluster.
- Amazon EFS provides a fully managed, POSIX-compliant file system that supports NFS, making it a good fit for Linux-based clusters.
- General Purpose performance mode is designed for lower throughput and is good for general-purpose file storage.
- Disadvantages:
- While General Purpose mode supports moderate throughput, it may not provide the high throughput needed for big data analytics workloads.
- High throughput and low-latency requirements are not fully addressed by the General Purpose mode.
- Rejected: Although EFS is a good option for general file storage, General Purpose mode might not meet the performance requirements for big data analytics with high throughput.
Option C: Provision a new Amazon Elastic Block Store (Amazon EBS) volume that uses the io2 volume type. Attach the EBS volume to all of the EC2 instances in the cluster.
- Amazon EBS volumes are block-level storage and provide high-performance storage, especially with the io2 volume type, which is designed for high IOPS...
Author: Sara · Last updated Jul 6, 2026
A company hosts a software as a service (SaaS) solution on AWS. The solution has an Amazon API Gateway API that serves an HTTPS endpoint. The API uses AWS Lambda functions for compute. The Lambda functions store data in an Amazon Aurora Serverless v1 database.
The company used the AWS Serverless Application Model (AWS SAM) to deploy the solution. The solution extends across multiple Availability Zones and has no disaster recovery (DR) plan.
A solutions architect must...
To design a disaster recovery (DR) strategy for the solution with specific RTO (Recovery Time Objective) and RPO (Recovery Point Objective) requirements, let's evaluate the options based on the following criteria:
- RTO of 5 minutes: The solution must be able to recover and be operational within 5 minutes after a disaster.
- RPO of 1 minute: The data loss between the time of the disaster and recovery must be minimized, with a maximum of 1 minute of data loss.
- Disaster Recovery Across Regions: The DR solution should be able to replicate data and recover quickly in another AWS Region.
Breakdown of the Options:
Option A: Create a read replica of the Aurora Serverless v1 database in the target Region. Use AWS SAM to create a runbook to deploy the solution to the target Region. Promote the read replica to primary in case of disaster.
- Aurora Serverless v1 does not support cross-region read replicas. This would be applicable to standard Aurora databases but not Serverless v1.
- RPO and RTO considerations: While promoting a read replica can meet recovery needs, the lack of native cross-region replication for Aurora Serverless v1 makes this solution infeasible.
- Rejected: Aurora Serverless v1 cannot replicate across regions, and the read replica solution would not meet the RTO and RPO requirements.
Option B: Change the Aurora Serverless v1 database to a standard Aurora MySQL global database that extends across the source Region and the target Region. Use AWS SAM to create a runbook to deploy the solution to the target Region.
- Aurora MySQL Global Database provides cross-region replication and supports both the RTO and RPO requirements. With a global database, data can be replicated with low latency across regions, making it a good fit for disaster recovery.
- Advantages:
- Aurora Global Database allows for fast failover across regions, minimizing downtime and meeting the 5-minute RTO requirement.
- It supports continuous replication with low-latency, ensuring the 1-minute RPO requirement is met.
- Selected: This is a robust solution for DR that supports cross-region replication ...
Author: Ella · Last updated Jul 6, 2026
A company owns a chain of travel agencies and is running an application in the AWS Cloud. Company employees use the application to search for information about travel destinations. Destination content is updated four times each year.
Two fixed Amazon EC2 instances serve the application. The company uses an Amazon Route 53 public hosted zone with a multivalue record of travel.example.com that returns the Elastic IP addresses for the EC2 instances. The application uses Amazon DynamoDB as its primary data store. The company uses a self-hosted Redis instance as a caching solution.
During content updates, the load on the EC2 instances and the caching solution inc...
Option Analysis:
- A) Set up DynamoDB Accelerator (DAX) as in-memory cache. Update the application to use DAX. Create an Auto Scaling group for the EC2 instances. Create an Application Load Balancer (ALB). Set the Auto Scaling group as a target for the ALB. Update the Route 53 record to use a simple routing policy that targets the ALB's DNS alias. Configure scheduled scaling for the EC2 instances before the content updates.
- Why it works: DynamoDB Accelerator (DAX) is designed to cache the results of DynamoDB queries, significantly improving read performance and reducing load on the DynamoDB tables. This is especially beneficial during high-traffic events such as content updates. Auto Scaling ensures that the EC2 instances can scale based on demand. The Application Load Balancer (ALB) can distribute traffic across multiple EC2 instances, ensuring high availability. Scheduled scaling allows the system to handle increased load during the content updates.
- Why it’s a good option: This solution addresses the caching and EC2 scaling requirements while keeping the architecture highly available and automatically scalable, especially during peak loads caused by content updates.
- B) Set up Amazon ElastiCache for Redis. Update the application to use ElastiCache. Create an Auto Scaling group for the EC2 instances. Create an Amazon CloudFront distribution, and set the Auto Scaling group as an origin for the distribution. Update the Route 53 record to use a simple routing policy that targets the CloudFront distribution's DNS alias. Manually scale up EC2 instances before the content updates.
- Why it doesn’t fully meet the needs: ElastiCache for Redis is a great caching solution, and scaling EC2 instances through an Auto Scaling group ensures application scalability. However, using Amazon CloudFront as the origin for EC2 instances is not ideal for dynamic applications where content is frequently updated. CloudFront is better suited for static content delivery, not for serving dynamic traffic generated by an application. Also, manually scaling up EC2 instances introduces the possibility of human error and doesn't provide automatic scaling based on traffic demand.
- Why it’s not optimal: The need for manual scaling creates potential for human error, and CloudFront isn't the most appropriate for this use case where dynamic data (like frequently updated content) is involved.
- C) Set up Amazon ElastiCache for Memcached. Update the application to use Elas...
Author: Maya2022 · Last updated Jul 6, 2026
A company needs to store and process image data that will be uploaded from mobile devices using a custom mobile app. Usage peaks between 8 AM and 5 PM on weekdays, with thousands of uploads per minute. The app is rarely used at any other time. A user is notified when image processing is complete.
Whic...
Option Analysis:
- A) Upload files from the mobile software directly to Amazon S3. Use S3 event notifications to create a message in an Amazon MQ queue.
- Why it’s not ideal: While Amazon MQ is a managed message broker service, it's not as cost-effective or scalable as SQS for high-throughput scenarios like this. Amazon MQ is designed for more traditional message queuing and does not necessarily optimize for the scale of image upload events that the scenario requires. Additionally, SQS is generally more flexible, easy to integrate with Lambda, and better suited for event-driven workloads.
- Why it’s rejected: SQS offers better scalability and ease of integration for this use case, especially in scenarios with thousands of events per minute.
- B) Upload files from the mobile software directly to Amazon S3. Use S3 event notifications to create a message in an Amazon Simple Queue Service (Amazon SQS) standard queue.
- Why it works: This option is optimal because:
- Amazon S3 can handle large numbers of file uploads, which is a crucial requirement here.
- S3 event notifications can automatically trigger messages to an SQS queue when a file is uploaded, which is efficient for integrating the upload and processing stages.
- SQS standard queues are highly scalable and can handle the throughput required by thousands of uploads per minute, ensuring that messages (representing image processing tasks) are queued for processing by downstream systems.
- Why it’s a good option: SQS is ideal for scalable, event-driven workloads and can integrate well with AWS Lambda to scale the image processing function as needed.
- C) Invoke an AWS Lambda function to perform image processing when a message is available in the queue.
- Why it works: Lambda is a highly scalable, serverless compute service that automatically adjusts to the volume of incoming messages. This is crucial for handling variable workloads (e.g., the peak upload times). By invoking a Lambda function to process images, the system can automatically scale the number of concurrent image processing jobs without manual intervention. Additionally, Lambda works seamlessly with SQS, ensuring smooth processing as messages arrive in the queue.
- Why it’s a good option: Lambda enables efficient scaling for the image processing workload, and because it operates in response to SQS messages, it integrates well into the event-driven architec...
Author: IceDragon2023 · Last updated Jul 6, 2026
A company is building an application on AWS. The application sends logs to an Amazon OpenSearch Service cluster for analysis. All data must be stored within a VPC.
Some of the company's developers work from home. Other developers work from three different company office locations. The developers need to access OpenSe...
Option Analysis:
- A) Configure and set up an AWS Client VPN endpoint. Associate the Client VPN endpoint with a subnet in the VPC. Configure a Client VPN self-service portal. Instruct the developers to connect by using the client for Client VPN.
- Why it works: AWS Client VPN is a fully managed, scalable VPN service that allows secure remote access to resources within a VPC. By configuring a Client VPN endpoint and associating it with a subnet, developers can securely connect to the VPC from any location (home, office, etc.) and access the OpenSearch Service. It is ideal for developers working remotely or from different locations, as it allows access to resources within the VPC without needing complex network configurations.
- Why it’s a good option: This option provides secure access, scales automatically with the number of users, and is easier to manage than other solutions. It directly supports developers working remotely or from multiple locations, as required in the use case.
- B) Create a transit gateway, and connect it to the VPC. Create an AWS Site-to-Site VPN. Create an attachment to the transit gateway. Instruct the developers to connect by using an OpenVPN client.
- Why it’s not ideal: While a Site-to-Site VPN can securely connect office networks to AWS, it does not provide an easy or scalable solution for individual remote developers to connect directly to the VPC. The setup would require additional configuration and is typically suited for connecting on-premises data centers to AWS rather than allowing individual developers to connect directly. Using OpenVPN with a transit gateway would not be as efficient as a dedicated solution like AWS Client VPN for remote access.
- Why it’s rejected: This is a more complex solution intended for enterprise-scale connections and doesn't directly support the remote developer access requirements in an efficient way.
- C) Create a transit gateway, and connect it to the VPC. Order an AWS Direct Connect connection. Set up a public VIF on th...
Author: CrimsonViperX · Last updated Jul 6, 2026
A company wants to migrate its website from an on-premises data center onto AWS. At the same time, it wants to migrate the website to a containerized microservice-based architecture to improve the availability and cost efficiency. The company's security policy states that privileges and network permissions must be configured according to best practice, using least privilege.
A solutions architect must create a containerized archite...
Option Analysis:
- A) Create tasks using the bridge network mode.
- Why it’s not ideal: The bridge network mode is used for Docker containers that are running on a single EC2 instance. While it works for some simple applications, it does not scale well for containerized microservices in a production environment, especially with Amazon ECS. The bridge network mode does not provide tasks with the same level of isolation and flexibility in terms of networking, which could limit the ability to apply security best practices and network segmentation.
- Why it’s rejected: In the context of modern containerized architectures and microservices, the bridge mode is not suitable, as it does not provide the necessary security and networking configurations that can be easily scaled in ECS.
- B) Create tasks using the awsvpc network mode.
- Why it works: The `awsvpc` network mode gives each ECS task its own elastic network interface (ENI), providing better networking isolation and security. This mode is recommended for applications that require secure, isolated networking environments. By using `awsvpc`, tasks can have security groups applied directly, enabling granular network-level access control to other resources in the VPC. This is crucial for implementing least privilege security policies.
- Why it’s a good option: The `awsvpc` network mode ensures that each task can be independently secured with security groups, which aligns well with the company's security policy and the principle of least privilege.
- C) Apply security groups to Amazon EC2 instances, and use IAM roles for EC2 instances to access other resources.
- Why it’s not ideal: While applying security groups to EC2 instances and using IAM roles for EC2 instances is a best practice for EC2-based applications, this approach does not address the specific security and network isolation requirements for the ECS tasks themselves. In a containerized architecture using ECS, the focus should be on applying security gro...
Author: Vikram · Last updated Jul 6, 2026
A company is running a serverless application that consists of several AWS Lambda functions and Amazon DynamoDB tables. The company has created new functionality that requires the Lambda functions to access an Amazon Neptune DB cluster. The Neptune DB cluster is located in three subnets in a VPC.
W...
Option Analysis:
- A) Create three public subnets in the Neptune VPC, and route traffic through an internet gateway. Host the Lambda functions in the three new public subnets.
- Why it’s not ideal: Hosting the Lambda functions in public subnets would expose them to the internet, which can increase the attack surface and violate the security principle of least privilege. The Lambda functions don't need public internet access to interact with Neptune or DynamoDB, as both services can be accessed securely through VPC-private connectivity. Additionally, Neptune, as a managed service, is typically used within private subnets to restrict direct internet access.
- Why it’s rejected: This solution increases security risks by placing Lambda functions in public subnets unnecessarily, which is not recommended for a secure serverless application architecture.
- B) Create three private subnets in the Neptune VPC, and route internet traffic through a NAT gateway. Host the Lambda functions in the three new private subnets.
- Why it works: Hosting Lambda functions in private subnets allows them to securely interact with the Neptune DB cluster without exposure to the public internet. The NAT gateway is useful for enabling outbound internet access for the Lambda functions if needed (e.g., for API calls or package downloads). This solution ensures that all traffic between the Lambda functions and Neptune DB remains within the VPC, maintaining secure, private communication.
- Why it’s a good option: Hosting Lambda in private subnets allows for secure access to both Neptune and DynamoDB, ensuring that the serverless application architecture remains isolated and follows security best practices.
- C) Host the Lambda functions outside the VPC. Update the Neptune security group to allow access from the IP ranges of the Lambda functions.
- Why it’s not ideal: Hosting Lambda functions outside of the VPC means they will need to access Neptune over the internet, which is not recommended for communication with services that reside inside a VPC. Furthermore, managing security group rules for Lambda functions accessing resources outside the VPC can lead to security risks and is cumbersome. Additionally, Lambda functions do not have IP addresses when they are outside a VPC, so configuring security groups based on IP rang...
Author: Sofia · Last updated Jul 6, 2026
A company wants to design a disaster recovery (DR) solution for an application that runs in the company's data center. The application writes to an SMB file share and creates a copy on a second file share. Both file shares are in the data center. The application uses two types of files: metadata files and image files.
The company wants to store the copy on AWS. The company needs the abili...
To determine the most appropriate disaster recovery (DR) solution for the given scenario, we need to consider key factors like access time, cost, and the nature of the data. Here's an analysis of each option based on the provided requirements:
A) Deploy AWS Outposts with Amazon S3 storage. Configure a Windows Amazon EC2 instance on Outposts as a file server.
- Pros: AWS Outposts brings AWS infrastructure on-premises, allowing you to extend your existing data center to AWS seamlessly. This can provide a consistent hybrid environment, and using a Windows EC2 instance with SMB support could meet the file sharing requirements.
- Cons: AWS Outposts is typically used for more specific workloads where low latency is critical, or where there are regulatory requirements for on-premises infrastructure. This solution is expensive, especially when you're only dealing with backup and disaster recovery. It also introduces more complexity compared to other options for a disaster recovery scenario.
- Access Time: Outposts would likely meet the 5-minute access time requirement, but it may introduce more overhead in terms of management and cost.
B) Deploy an Amazon FSx File Gateway. Configure an Amazon FSx for Windows File Server Multi-AZ file system that uses SSD storage.
- Pros: Amazon FSx for Windows File Server is specifically designed to provide a fully managed file system that supports SMB, making it a good fit for this scenario. It offers multi-AZ deployment for high availability and durability, which is essential for disaster recovery. SSD storage ensures faster performance for metadata files.
- Cons: This option is more focused on providing a fully managed file server, which could be overkill for the backup and disaster recovery scenario, especially considering the low frequency of access for image files. The SSD storage might not be necessary for infrequently accessed files, leading to unnecessary costs.
- Access Time: With multi-AZ support, this solution can likely meet the 5-minute access time requireme...
Author: Scarlett · Last updated Jul 6, 2026
A company is creating a solution that can move 400 employees into a remote working environment in the event of an unexpected disaster. The user desktops have a mix of Windows and Linux operating systems. Multiple types of software, such as web browsers and mail clients, are installed on each desktop.
A solutions architect needs to implement a solution that can be integrated with the company's on-premises Active Directory to allow employees to use their exis...
To select the best solution for enabling 400 employees to work remotely during a disaster, the solution needs to meet several key requirements:
- Integration with on-premises Active Directory to leverage existing user credentials.
- Support for Windows and Linux desktops.
- Multifactor authentication (MFA) for secure access.
- Replicating the user experience from existing desktops.
Option Breakdown:
A) Use Amazon WorkSpaces for the cloud desktop service. Set up a VPN connection to the on-premises network. Create an AD Connector, and connect to the on-premises Active Directory. Activate MFA for Amazon WorkSpaces by using the AWS Management Console.
- Pros:
- Amazon WorkSpaces is a fully managed cloud desktop solution that provides Windows and Linux desktops with a user experience similar to physical desktops.
- AD Connector can be used to integrate Amazon WorkSpaces with the existing on-premises Active Directory, allowing employees to use their existing credentials.
- MFA can be enabled via the AWS Management Console.
- WorkSpaces is well-suited for a broad range of applications, including those that employees typically use in a remote environment, such as web browsers and mail clients.
- Cons:
- The solution requires setting up a VPN to connect to the on-premises network, which could add complexity and some maintenance overhead.
- There might be additional infrastructure setup required for VPN and MFA configuration, but WorkSpaces itself is a straightforward solution for cloud desktops.
B) Use Amazon AppStream 2.0 as an application streaming service. Configure Desktop View for the employees. Set up a VPN connection to the on-premises network. Set up Active Directory Federation Services (AD FS) on premises. Connect the VPC network to AD FS through the VPN connection.
- Pros:
- Amazon AppStream 2.0 is an application streaming service that allows users to access applications remotely.
- Integrating with AD FS could help authenticate users using on-premises Active Directory credentials.
- Cons:
- AppStream 2.0 does not provide full desktop virtualization. It is better suited for delivering applications rather than full desktops. This would not replicate the existing user desktop experience (e.g., custom software, personalizations, etc.).
- Desktop View configuration in AppStream 2.0 is not typically designed for full desktop environments, so users would not get the same experience as they would with WorkSpaces.
- ...
Author: Olivia · Last updated Jul 6, 2026
A company has deployed an Amazon Connect contact center. Contact center agents are reporting large numbers of computer-generated calls. The company is concerned about the cost and productivity effects of these calls. The company wants a solution that will allow agents to flag the call as spam and automatically b...
To address the concern of blocking computer-generated calls (spam calls) in an Amazon Connect contact center while ensuring operational efficiency, we need to choose a solution that allows agents to quickly flag spam calls and automate the process of blocking those numbers for future calls.
Option Analysis:
A) Customize the Contact Control Panel (CCP) by adding a flag call button that will invoke an AWS Lambda function that calls the UpdateContactAttributes API. Use an Amazon DynamoDB table to store the spam numbers. Modify the contact flows to look for the updated attribute and to use a Lambda function to read and write to the DynamoDB table.
- Pros: This solution allows agents to flag spam calls directly within the CCP, making it user-friendly. The Lambda function can update the contact attributes, and the DynamoDB table can store the flagged spam numbers. The contact flow can then reference this table to avoid connecting future calls from the flagged numbers to agents.
- Cons: This requires customization of both the CCP and contact flows. While this solution is flexible, it adds complexity to the implementation and might require more maintenance.
- Use Case: This option is well-suited if the company wants agents to interact directly with the system and flag calls, and if there's a need for detailed customization and control over the process.
B) Use a Contact Lens for Amazon Connect rule that will look for spam calls. Use an Amazon DynamoDB table to store the spam numbers. Modify the contact flows to look for the rule and to invoke an AWS Lambda function to read and write to the DynamoDB table.
- Pros: Contact Lens offers built-in capabilities to analyze the content of calls, which can automatically detect spam or unwanted calls. It can trigger actions like invoking a Lambda function to update the spam list in DynamoDB.
- Cons: While Contact Lens can detect some forms of spam, it may not capture all computer-generated or robocalls accurately, depending on the rule configurations. Additionally, the solution requires modifying contact flows to call a Lambda function, which could increase complexity.
- Use Case: This is a good option if you want automated detection of spam calls based on content analysis but could have some limitations in detecting all types of spam calls, especially if they are not clearly identifiable through speech analysis.
C) Use an Amazon DynamoDB table to store the spam numbers. Create a quick connect that the agents ...
Author: Elizabeth · Last updated Jul 6, 2026
A company has mounted sensors to collect information about environmental parameters such as humidity and light throughout all the company's factories. The company needs to stream and analyze the data in the AWS Cloud in real time. If any of the parameters fall out of acceptable ran...
To meet the company's requirements of streaming and analyzing environmental data in real-time and sending notifications if parameters fall outside acceptable ranges, we need a solution that can:
1. Stream the data in real-time.
2. Analyze the data to detect out-of-range values.
3. Notify the operations team immediately if an anomaly is detected.
Let’s break down each option:
A) Stream the data to an Amazon Kinesis Data Firehose delivery stream. Use AWS Step Functions to consume and analyze the data in the Kinesis Data Firehose delivery stream. Use Amazon Simple Notification Service (Amazon SNS) to notify the operations team.
- Pros: Kinesis Data Firehose is a fully managed service designed for easy delivery of streaming data to destinations like Amazon S3 or Redshift. Step Functions can be used to orchestrate tasks and trigger actions, and SNS can notify the operations team.
- Cons: While Kinesis Data Firehose is great for data delivery, it's not ideal for real-time processing or complex analysis of streaming data. Step Functions is better suited for orchestrating workflows but is not optimized for direct, real-time data analysis. Firehose is better suited for data delivery rather than analysis.
- Use Case: This option is better suited for batch processing or for collecting and storing data. It may not provide the real-time analysis and notification needed for this use case.
B) Stream the data to an Amazon Managed Streaming for Apache Kafka (Amazon MSK) cluster. Set up a trigger in Amazon MSK to invoke an AWS Fargate task to analyze the data. Use Amazon Simple Email Service (Amazon SES) to notify the operations team.
- Pros: Amazon MSK provides a fully managed Kafka service for streaming data, and AWS Fargate can be used to run containerized tasks to process the data. SES can be used for sending emails to the operations team.
- Cons: Kafka and Fargate are powerful tools, but this solution is more complex and may be over-engineered for the given requirements. Setting up and maintaining a Kafka cluster, as well as the integration with Fargate, introduces more complexity than necessary for this use case. Additionally, real-time processing with MSK might not be as streamlined as other services like Kinesis.
- Use Case: This solution is better suited for very large-scale, complex stream processing applications, but it may not be the most e...
Author: Chloe · Last updated Jul 6, 2026
A company is preparing to deploy an Amazon Elastic Kubernetes Service (Amazon EKS) cluster for a workload. The company expects the cluster to support an unpredictable number of stateless pods. Many of the pods will be created during a short time period as the workload ...
To maximize node resilience in an Amazon Elastic Kubernetes Service (Amazon EKS) cluster, the solution should ensure that the workload remains highly available and resilient to failures, especially when the workload dynamically scales based on replicas. Let's break down each option to see which best meets the requirements.
A) Use a separate launch template to deploy the EKS control plane into a second cluster that is separate from the workload node groups.
- Pros: The control plane is critical for managing the cluster, and separating it from workload nodes could isolate management and operational concerns.
- Cons: This approach doesn't directly address node resilience for workload pods or scaling challenges. In fact, it introduces unnecessary complexity because the EKS control plane is fully managed by AWS, so manually managing control plane nodes in a separate cluster is not needed. The issue is more about ensuring sufficient compute capacity and availability for workload pods, not managing the control plane.
- Use Case: This option is not directly relevant to maximizing node resilience for workloads, as it focuses on control plane architecture, which doesn't impact the resilience of the application workload.
B) Update the workload node groups. Use a smaller number of node groups and larger instances in the node groups.
- Pros: Fewer node groups and larger instances could simplify management.
- Cons: Using fewer, larger instances might reduce the overall resilience of the cluster. If a large instance fails, it can affect multiple pods, causing a larger disruption. The approach doesn't take full advantage of the flexibility and resilience offered by scaling node groups in different Availability Zones.
- Use Case: This is not ideal for maximizing node resilience because it may lead to reduced availability in the case of node failure. A more distributed approach with multiple smaller nodes would be more resilient.
C) Configure the Kubernetes Cluster Autoscaler to ensure that the compute capacity of the workload node groups stays underprovisioned.
- Pros: The Cluster Autoscaler can dynamica...
Author: VioletCheetah55 · Last updated Jul 6, 2026
A company needs to implement a disaster recovery (DR) plan for a web application. The application runs in a single AWS Region.
The application uses microservices that run in containers. The containers are hosted on AWS Fargate in Amazon Elastic Container Service (Amazon ECS). The application has an Amazon RDS for MySQL DB instance as its data layer and uses Amazon Route 53 for DNS resolution. An Amazon CloudWatch alarm invokes an Amazon EventBridge rule if the application experiences a failure.
A solutio...
Let's evaluate the options based on the requirements and the different aspects involved in a disaster recovery (DR) solution:
Key Factors:
1. Minimizing Recovery Time: The primary goal is to reduce the time needed for recovery.
2. High Availability of Application: The solution should ensure minimal downtime and seamless failover to the secondary Region.
3. RDS for MySQL: The application relies on RDS for MySQL, which suggests that the solution should be aligned with database recovery and failover strategies for relational databases.
4. Route 53 for DNS Resolution: Route 53 should be updated quickly to route traffic to the new Region.
Evaluation of Options:
Option A:
- Steps:
1. Set up a second ECS cluster and ECS service in the separate Region.
2. Lambda function creates an RDS snapshot, copies it to the second Region, creates a new RDS DB instance, and updates Route 53.
- Pros:
- This is a feasible approach with manual snapshot management for the RDS database.
- It ensures that you can recover the database to a point in time via snapshots.
- Route 53 will be updated to reroute traffic after recovery.
- Cons:
- Recovery time can be long due to the manual snapshot process (RDS snapshots take time to copy and restore).
- The database will not be fully in sync at the time of failover because snapshots are not real-time replication.
- RDS DB instance failover may take longer, especially since the database is not continuously synchronized.
Option B:
- Steps:
1. Lambda function to create a second ECS cluster and service in the separate Region.
2. Lambda also manages RDS snapshot creation, copying, and creating a new RDS instance.
3. Updates Route 53.
- Pros:
- Similar to Option A but automates the process via Lambda.
- Cons:
- Manual snapshotting still applies, leading to similar recovery time concerns as Option A.
- Snapshot-based recovery is not optimal for minimizing recovery time.
Option C:
- Steps:
1. Set up a second ...
Author: Nia · Last updated Jul 6, 2026
A company has AWS accounts that are in an organization in AWS Organizations. The company wants to track Amazon EC2 usage as a metric. The company's architecture team must receive a daily alert if the EC2 usage is more than 10% h...
To address the company's need to track EC2 usage and alert the architecture team if usage exceeds 10% more than the average of the past 30 days, we need to evaluate different AWS services based on their capabilities to monitor EC2 usage and send alerts based on usage thresholds.
Option Breakdown:
A) Configure AWS Budgets in the organization's management account. Specify a usage type of EC2 running hours. Specify a daily period. Set the budget amount to be 10% more than the reported average usage for the last 30 days from AWS Cost Explorer. Configure an alert to notify the architecture team if the usage threshold is met.
- Pros:
- AWS Budgets allows tracking of usage metrics, including EC2 running hours, and can provide notifications when the usage exceeds a set threshold.
- It can be configured to alert the architecture team when usage is 10% higher than the average from the last 30 days.
- Cons:
- AWS Budgets is more focused on cost tracking and budgets, rather than directly measuring usage metrics like EC2 usage in terms of hours or other relevant metrics. Although it is possible to track usage through a budget, this is typically more cost-related and less granular for performance usage tracking.
- Budgets may not track precise daily usage patterns or provide the kind of alerting that is specifically usage-based in real-time for EC2 instances.
B) Configure AWS Cost Anomaly Detection in the organization's management account. Configure a monitor type of AWS Service. Apply a filter of Amazon EC2. Configure an alert subscription to notify the architecture team if the usage is 10% more than the average usage for the last 30 days.
- Pros:
- AWS Cost Anomaly Detection is designed to detect unusual changes in usage, and it can track service-specific metrics, including EC2 usage. It can automatically detect anomalies and trigger alerts.
- The service can track EC2 usage across multiple accounts and regions, making it highly scalable in an organization setup with multiple AWS accounts.
- The ability to set up anomaly detection based on 30-day historical data is precisely what the company needs to monitor for the 10% usage increase.
- Cons:
- This is more cost-centric, detecting unusual increases in cost, but it cou...
Author: Vikram · Last updated Jul 6, 2026
An e-commerce company is revamping its IT infrastructure and is planning to use AWS services. The company's CIO has asked a solutions architect to design a simple, highly available, and loosely coupled order processing application. The application is responsible for receiving and processing orders before storing them in an Amazon DynamoDB table. The application has a sporadic traffic pattern and sh...
To design a solution that is simple, highly available, loosely coupled, and scalable to handle sporadic traffic patterns with the ability to scale during marketing campaigns, we need to consider the following key factors:
1. Simplicity: The solution should not involve complex infrastructure or management overhead.
2. High Availability: The solution should ensure that the application remains operational even during traffic spikes.
3. Loosely Coupled: The order processing system should be independent of other components, so failures in one component don’t affect others.
4. Scalability: The solution should scale automatically based on traffic patterns, especially during marketing campaigns when traffic spikes are expected.
5. Minimal Delays: Processing the orders should be as fast as possible to avoid delays in storing the orders in DynamoDB.
Evaluation of Options:
Option A: EC2-hosted database and EC2 instances
- Steps: Use EC2 instances to host a database that receives and processes orders.
- Pros: EC2 provides full control over the processing logic.
- Cons:
- Complexity: Managing EC2 instances and databases requires significant setup, scaling, and maintenance.
- Manual scaling: EC2 instances must be manually scaled or require additional tools like Auto Scaling, which adds complexity.
- Tight coupling: The EC2-based solution involves tightly coupled components, which doesn't align with the loose coupling requirement.
- Not ideal for sporadic traffic: Scaling EC2 instances in response to traffic spikes can be slow and inefficient.
This option is rejected because it introduces unnecessary complexity, manual scaling, and is not highly available by default.
Option B: Amazon SQS queue and AWS Lambda function
- Steps: Receive orders in an SQS queue, and invoke a Lambda function to process the orders.
- Pros:
- Simple: SQS and Lambda are fully managed services that require minimal setup and maintenance.
- Highly Available: Both SQS and Lambda are inherently highly available.
- Scalable: Lambda automatically scales based on the number of incoming orders, ensuring that the system can handle traffic spikes.
- Loosely Coupled: SQS decouples the order receiving process from the processing logic, making the system more resilien...
Author: Aria · Last updated Jul 6, 2026
A company is deploying AWS Lambda functions that access an Amazon RDS for PostgreSQL database. The company needs to launch the Lambda functions in a QA environment and in a production environment.
The company must not expose credentials within...
Let's evaluate the options based on the key requirements and considerations for securely managing and rotating database credentials without exposing them in the application code:
Key Requirements:
1. No Exposure of Credentials in Application Code: The database credentials should not be stored directly within the application code.
2. Automatic Rotation of Passwords: Passwords should be rotated automatically to ensure security and compliance.
3. Separation Between QA and Production: Credentials for both the QA and production environments should be managed securely and separately.
4. Access Control: The Lambda functions should have permissions to retrieve the credentials as needed.
Evaluation of Options:
Option A: Store the credentials in AWS Systems Manager Parameter Store
- Steps: Store the database credentials in the Parameter Store, encrypted with AWS KMS. Use the AWS SDK (Boto3) in the Lambda function to pull the credentials.
- Pros:
- Encryption: Parameter Store supports encryption using AWS KMS, so credentials are stored securely.
- Access Control: Lambda functions can be granted access to specific parameters via IAM roles.
- Integration with AWS SDK: Using Boto3 to pull credentials is straightforward and works well in Lambda.
- Cons:
- Automatic Rotation: Parameter Store does not support automatic rotation of credentials. This would need to be manually managed, which is a significant disadvantage compared to AWS Secrets Manager.
- Less Suitable for Credentials Management: AWS Secrets Manager is a more specialized service for managing database credentials and provides automatic rotation out of the box.
This option is rejected because it does not provide automatic credential rotation, which is a crucial requirement.
Option B: Store the credentials in AWS Secrets Manager
- Steps: Store credentials in AWS Secrets Manager for both QA and production environments, turn on rotation, and provide references to these secrets in Lambda environment variables.
- Pros:
- Automatic Rotation: Secrets Manager supports automatic rotation of credentials, including RDS passwords.
- Secure Storage: Credentials are stored securely and can be encrypted using AWS KMS.
- Environment Separation: You can easily create separate secrets for the QA and production environments.
- Seamless Integration with Lambda: Lambda functions can access secrets using environment variables, and access permissions can be controlled via IAM.
- Cons:
- Cost: Secrets Manager incurs additional costs, although the...
Author: Elijah · Last updated Jul 6, 2026
A company is using AWS Control Tower to manage AWS accounts in an organization in AWS Organizations. The company has an OU that contains accounts. The company must prevent any new or existing Amazon EC2 instances in the ...
Key Requirements:
1. Prevent EC2 instances from gaining a public IP address: The solution should ensure that neither new EC2 instances nor existing instances in the specified organizational unit (OU) can receive public IP addresses.
2. Control across multiple accounts: The solution must apply to all accounts within the OU managed by AWS Control Tower.
3. Simplicity and effectiveness: The solution should be easy to implement and manage without significant manual effort or complex configurations.
Evaluation of Options:
Option A: Use AWS Systems Manager Automation
- Steps: Configure EC2 instances in each account in the OU to use AWS Systems Manager and use a Systems Manager Automation runbook to prevent public IP addresses from being attached.
- Pros:
- Systems Manager can be used to manage instances across multiple accounts.
- Automation runbooks can apply changes in a controlled manner.
- Cons:
- Manual intervention and complexity: This option would require manual or semi-automated processes for each instance, which is not scalable. It's not an ideal solution for preventing public IP assignments at the infrastructure level.
- Lack of proactive enforcement: Systems Manager does not provide a proactive, automatic way to prevent public IP assignments during instance launch or modification.
This option is rejected due to its reliance on manual processes and lack of proactive enforcement.
Option B: Implement AWS Control Tower proactive control
- Steps: Implement an AWS Control Tower proactive control that checks whether instances have a public IP address, sets the `AssociatePublicIpAddress` property to False, and attaches the control to the OU.
- Pros:
- Proactive control: AWS Control Tower proactive controls are designed to enforce policies and best practices across AWS accounts.
- Centralized management: This option integrates directly with AWS Control Tower and applies at the OU level, making it easy to manage across accounts.
- Automation: The proactive control ensures that instances launched in the OU will not have a public IP, and it can automatically enforce this setting.
- Cons:
- AWS Control Tower’s proactive controls may not provide the exact functionality to set the `AssociatePublicIpAddress` property to false across all instances directly, depending on the available pre-configured controls. While AWS Control Tower is an excellent service for governance, specific controls like this might need custom solutions or adjustments.
This option is likely the best approach as it utilizes AWS Control Tower’s built-in governance features and proactively ensures compliance. However, it may require additional details about the exact capabilities of proactive controls to confirm if this will be fully automated for all cases.
Option C: Create an SCP (Service Control Policy)...
Author: Ella · Last updated Jul 6, 2026
A company is deploying a third-party web application on AWS. The application is packaged as a Docker image. The company has deployed the Docker image as an AWS Fargate service in Amazon Elastic Container Service (Amazon ECS). An Application Load Balancer (ALB) directs traffic to the application.
The company needs to give only a specific list of users the ability to access the application from the internet. The company cannot change the appli...
To determine the best solution, let's evaluate each option and examine their suitability based on the requirements:
Option A: Amazon Cognito User Pool with MFA
- What it involves:
- Creating an Amazon Cognito User Pool to manage users.
- Configuring MFA as a requirement for users.
- Configuring the Application Load Balancer (ALB) to require authentication through the Amazon Cognito hosted UI, which will authenticate the user before allowing access to the application.
- Why it's a good fit:
- Amazon Cognito allows you to manage users and authentication directly without modifying the application. It can also enforce MFA, meeting the company's security requirement.
- The ALB can be configured to trigger the Cognito authentication flow, providing controlled access only to users in the user pool and enforcing MFA during the login process.
- Why other options are less suitable:
- Option B requires IAM authentication, which doesn't support MFA enforcement at the application level through the ALB. It would only work if the users were authenti...
Author: Ravi Patel · Last updated Jul 6, 2026
A solutions architect is preparing to deploy a new security tool into several previously unused AWS Regions. The solutions architect will deploy the tool by using an AWS CloudFormation stack set. The stack set's template contains an IAM role that has a custom name. Upon creation of the stack ...
In this scenario, the issue revolves around the deployment of an AWS CloudFormation stack set, where the stack set template contains an IAM role with a custom name, and no stack instances are created successfully. Let's evaluate the options:
Option A: Enable the new Regions in all relevant accounts. Specify the CAPABILITY_NAMED_IAM capability during the creation of the stack set.
- What this option involves:
- Enabling the relevant AWS Regions for the stack set deployment.
- Specifying the `CAPABILITY_NAMED_IAM` capability, which is required when creating or updating stacks that include IAM resources with custom names.
- Why it's a good fit:
- Enabling the AWS Regions ensures that the stack set is deployed in the newly supported regions.
- The `CAPABILITY_NAMED_IAM` capability is necessary because the template includes an IAM role with a custom name, and CloudFormation needs explicit permission to create IAM resources with specific names.
- Why it's the correct choice:
- This option addresses both the need to enable the new regions and explicitly acknowledge the creation of IAM resources with custom names, which is likely the reason the stack set isn’t deploying successfully.
Option B: Use the Service Quotas console to request a quota increase for the number of CloudFormation stacks in each new Region in all relevant accounts. Specify the CAPABILITY_IAM capability during the creation of the stack set.
- What this option involves:
- Requesting a quota increase for CloudFormation stacks.
- Specifying the `CAPABILITY_IAM` capability (needed for IAM resources but not specifically for custom names).
- Why this is less suitable:
- This option is focused on increasing the quota for CloudFormation stacks, bu...
Author: Jack · Last updated Jul 6, 2026
A company has an application that uses an Amazon Aurora PostgreSQL DB cluster for the application's database. The DB cluster contains one small primary instance and three larger replica instances. The application runs on an AWS Lambda function. The application makes many short-lived connections to the database's replica instances to perform read-only operations.
During periods of high traffic, the application becomes unreliable and th...
To solve the issue where the application becomes unreliable during periods of high traffic due to too many connections being established to the Amazon Aurora PostgreSQL DB cluster, let’s analyze the options in detail:
Option A: Use Amazon RDS Proxy to create a proxy for the DB cluster. Configure a read-only endpoint for the proxy. Update the Lambda function to connect to the proxy endpoint.
- What this option involves:
- Amazon RDS Proxy helps manage database connections more efficiently by pooling and reusing connections, which reduces the overhead of establishing new connections frequently.
- Configuring a read-only endpoint ensures that the Lambda function connects only to the replica instances, as the application only requires read operations.
- Why this is a good fit:
- RDS Proxy helps to efficiently manage connections, which is critical for high-traffic situations where too many connections are being established.
- By using the read-only endpoint, only replica instances are used, preventing overloading the primary instance.
- It optimizes Lambda connections by allowing for connection pooling, mitigating the “too many connections” problem.
- Why other options are less suitable:
- Option B: Increasing the `max_connections` sett...
Author: Noah Williams · Last updated Jul 6, 2026
A retail company is mounting IoT sensors in all of its stores worldwide. During the manufacturing of each sensor, the company's private certificate authority (CA) issues an X.509 certificate that contains a unique serial number. The company then deploys each certificate to its respective sensor.
A solutions architect needs to give the sensors the ability to sen...
To meet the requirement where IoT sensors should not be able to send data to AWS until they are installed, and the certificates issued by a private certificate authority (CA) contain a unique serial number for each sensor, the solution must involve a mechanism for validating these serial numbers and ensuring that sensors can only communicate with AWS after installation.
Option Breakdown:
A) Create an AWS Lambda function that can validate the serial number. Create an AWS IoT Core provisioning template. Include the SerialNumber parameter in the Parameters section. Add the Lambda function as a pre-provisioning hook. During manufacturing, call the RegisterThing API operation and specify the template and parameters.
- Pros:
- This option uses AWS IoT Core provisioning templates and a Lambda function as a pre-provisioning hook. The Lambda function can validate the serial number, ensuring that only the correct sensors can be provisioned and registered in AWS.
- The use of the `RegisterThing` API during manufacturing ensures that the sensors are not provisioned or allowed to send data until they are installed, as the validation check can be done at provisioning time.
- Cons:
- While it addresses the need for serial number validation during provisioning, it doesn’t provide a clear separation between manufacturing and installation, which is the core requirement for preventing the sensors from sending data until installation.
B) Create an AWS Step Functions state machine that can validate the serial number. Create an AWS IoT Core provisioning template. Include the SerialNumber parameter in the Parameters section. Specify the Step Functions state machine to validate parameters. Call the StartThingRegistrationTask API operation during installation.
- Pros:
- AWS Step Functions can manage a more complex workflow for validating serial numbers and initiating provisioning tasks.
- Cons:
- The use of AWS Step Functions adds unnecessary complexity to the solution. The Step Functions workflow isn't needed to validate the serial number and can make the solution more difficult to implement and maintain. Furthermore, the solution involves calling the `StartThingRegistrationTask` during installation, but the problem is specifically about preventing data submission until installation, and this approach is indirect for that requirement.
C) Create an AWS Lambda function...
Author: ShadowWolf101 · Last updated Jul 6, 2026
A startup company recently migrated a large ecommerce website to AWS. The website has experienced a 70% increase in sales. Software engineers are using a private GitHub repository to manage code. The DevOps team is using Jenkins for builds and unit testing. The engineers need to receive notifications for bad builds and zero downtime during deployments. The engineers also need to ensure any changes to production are seamless for users and can be roll...
The company's needs include ensuring notifications for bad builds, zero downtime during deployments, and the ability to roll back changes in production seamlessly. They are looking to use AWS CodePipeline for the build and deployment process. Let's evaluate the options based on these criteria:
Option A: Use GitHub websockets to trigger the CodePipeline pipeline. Use the Jenkins plugin for AWS CodeBuild to conduct unit testing. Send alerts to an Amazon SNS topic for any bad builds. Deploy in an in-place, all-at-once deployment configuration using AWS CodeDeploy.
- What this option involves:
- GitHub websockets: This is an incorrect choice. GitHub webhooks are typically used to trigger events in AWS CodePipeline, not websockets.
- Jenkins plugin for AWS CodeBuild: This allows Jenkins to trigger AWS CodeBuild for unit testing.
- In-place, all-at-once deployment with AWS CodeDeploy: This deployment configuration means the entire application is updated at once, leading to potential downtime during the deployment process. This violates the requirement for zero downtime.
- Why it's rejected:
- The use of websockets is not the best way to trigger pipelines from GitHub. Webhooks are more appropriate.
- All-at-once deployment can lead to downtime and is not suitable for seamless deployments, especially for production systems that need high availability.
Option B: Use GitHub webhooks to trigger the CodePipeline pipeline. Use the Jenkins plugin for AWS CodeBuild to conduct unit testing. Send alerts to an Amazon SNS topic for any bad builds. Deploy in a blue/green deployment using AWS CodeDeploy.
- What this option involves:
- GitHub webhooks: Correct choice for triggering AWS CodePipeline from GitHub.
- Jenkins plugin for AWS CodeBuild: Correct for running unit tests during the build phase.
- Blue/green deployment with AWS CodeDeploy: This deployment method ensures zero downtime during the deployment process. It involves creating two identical environments (blue and green). Traffic is routed to the green environment, and if issues arise, it can be switched back to the blue environment, enabling a quick rollback.
- Why it's the best fit:
- Blue/green deployment provid...
Author: Elizabeth · Last updated Jul 6, 2026
A software as a service (SaaS) company has developed a multi-tenant environment. The company uses Amazon DynamoDB tables that the tenants share for the storage layer. The company uses AWS Lambda functions for the application services.
The company wants to offer a tiered subscription model that is based on resource consumption by each tenant. Each tenant is identified by a unique tenant ID that is sent as part of each request to the Lambda functions. The company has created an AWS Cost and Usage Report (AWS CUR) in an AWS accoun...
To solve this problem, we need to focus on a solution that provides a granular view of DynamoDB costs per tet with the least operational effort, leveraging AWS-native tools efficiently. The goal is to allocate DynamoDB costs to each tet based on resource consumption with minimal management overhead. Let’s evaluate each option.
Option A: Associate a new tag that is named tet ID with each table in DynamoDB. Activate the tag as a cost allocation tag in the AWS Billing and Cost Management console. Deploy new Lambda function code to log the tet ID in Amazon CloudWatch Logs. Use the AWS CUR to separate DynamoDB consumption cost for each tet ID.
- Pros:
- Using tags for resource tracking is a native AWS feature and integrates well with AWS billing.
- The AWS CUR already provides detailed cost data, and by enabling cost allocation tags, you can easily separate DynamoDB costs per tet.
- Minimal operational effort after the initial setup since the tags are applied to DynamoDB tables and cost data is automatically reported.
- No additional Lambda functions are needed for calculation; AWS billing takes care of that.
- Cons:
- You need to ensure that the tet ID is captured consistently as part of each request, which may require Lambda updates.
- The granularity may not include specific consumption metrics (e.g., read/write capacity units) but will provide cost data tied to the tag.
Option B: Configure the Lambda functions to log the tet ID and the number of RCUs and WCUs consumed from DynamoDB for each transaction to Amazon CloudWatch Logs. Deploy another Lambda function to calculate the tet costs by using the logged capacity units and the overall DynamoDB cost from the AWS Cost Explorer API. Create an Amazon EventBridge rule to invoke the calculation Lambda function on a schedule.
- Pros:
- Tracks actual consumption of RCUs and WCUs per tet, allowing for detailed resource usage tracking.
- Provides flexibility by using CloudWatch Logs and the AWS Cost Explorer API.
- More granular resource tracking than option A.
- Cons:
- Higher operational effort: involves custom Lambda functions, logging, and scheduled invocations.
- Requires manual calculation and maintenance of the tet cost calculation, which adds complexity.
- Requires careful setup of EventBridge rules to manage function schedules.
Option C: Create a new partition key that associates DynamoDB items with individual tets. Deploy a Lambda function to populate the new column as part of each transaction. Depl...
Author: Amelia · Last updated Jul 6, 2026
A company has an application that stores data in a single Amazon S3 bucket. The company must keep all data for 1 year. The company's security team is concerned that an attacker could gain access to the AWS account through leaked long-term cre...
To address the concern about protecting data in the S3 bucket from potential security breaches while ensuring that all data is retained for 1 year, the solution should provide robust data protection, versioning, and safeguards against unauthorized access. Let's analyze each option and determine the most appropriate one.
Option A: Create a new AWS account that is accessible only to the security team through an assumed role. Create an S3 bucket in the new account. Enable S3 Versioning and S3 Object Lock. Configure a default retention period of 1 year. Set up replication from the existing S3 bucket to the new S3 bucket. Create an S3 Batch Replication job to copy all existing data.
- Pros:
- S3 Object Locking and Versioning will ensure that objects cannot be deleted or modified during the retention period.
- S3 replication can safeguard against potential compromises of the original bucket.
- The creation of a new account for the security team adds an additional layer of protection by isolating access to the S3 bucket from the main account.
- Cons:
- Complexity: Setting up a new account, replicating data, and managing replication jobs can add operational complexity.
- Cost: Maintaining a new account and the replication of data could increase costs.
- This solution doesn't address the main concern of securing the data within the current S3 bucket but rather replicates it to a different account, which introduces complexity without directly securing the original bucket.
Option B: Use the s3-bucket-versioning-enabled AWS Config managed rule. Configure an automatic remediation action that uses an AWS Lambda function to enable S3 Versioning and MFA Delete on noncompliant resources. Add an S3 Lifecycle rule to delete objects after 1 year.
- Pros:
- The AWS Config managed rule ensures that versioning is enabled on the S3 bucket and can remediate any compliance violations automatically.
- MFA Delete adds an extra layer of protection against accidental or malicious deletions.
- Using S3 Lifecycle rules to delete objects after 1 year ensures compliance with the retention requirement.
- Cons:
- The focus is on remediating noncompliant resources, but it does not explicitly lock down data for the specified retention period. S3 Object Lock would provide stronger protection than just versioning and MFA Delete.
- MFA Delete requires a high level of manual intervention to set up and manage, as MFA Delete needs to be enabled with root account access.
- This option does not explicitly address securing data in the event of compromised credentials or more complex threat scenarios.
Option C: ...
Author: Scarlett · Last updated Jul 6, 2026
A company needs to improve the security of its web-based application on AWS. The application uses Amazon CloudFront with two custom origins. The first custom origin routes requests to an Amazon API Gateway HTTP API. The second custom origin routes traffic to an Application Load Balancer (ALB). The application integrates with an OpenID Connect (OIDC) identity provider (IdP) for user management.
A security audit shows that a JSON Web Token (JWT) authorizer provides access to the API. The security audit also shows ...
Key Factors for Evaluation:
1. Security Enforcement: The solution must ensure that only authenticated users can access both the API and the ALB.
2. Authentication Integration: The solution needs to integrate with the existing OpenID Connect (OIDC) identity provider (IdP) and JWT-based authentication.
3. Minimal Operational Overhead: The solution should require minimal custom management, especially in monitoring and blocking unauthenticated requests.
4. Scalability and Simplicity: The solution should scale easily with minimal operational complexity and should not require custom log analysis or complex configurations.
Evaluation of Each Option:
Option A: Configure the ALB to enforce authentication and authorization by integrating the ALB with the IdP
- Advantages:
- Direct Authentication Enforcement: This directly addresses the security issue by ensuring that only authenticated users can access the backend services through the ALB. Integrating with the IdP ensures that authentication and authorization are handled securely.
- Built-In Support: AWS ALB supports integrating with OIDC and other identity providers for user authentication, so this can be managed natively within the AWS environment.
- Disadvantages:
- No Additional Layers of Security: This method directly addresses the problem but may not apply any fine-grained authorization rules that might be needed beyond authentication alone.
- Reasoning: This is the most straightforward and secure solution. It enforces authentication at the ALB level, ensuring that only authenticated users can access backend services, and it integrates well with the existing OIDC setup.
Option B: Modify the CloudFront configuration to use signed URLs
- Advantages:
- Signed URLs Provide Security: Signed URLs can prevent unauthorized users from accessing CloudFront-distributed content by requiring a valid signature for access.
- Disadvantages:
- Not Addressing ALB Security: This solution only addresses the CloudFront distribution and not the ALB. It does not ensure that unauthenticated requests are blocked at the ALB, which remains a vulnerability.
- Complexity in Management: Managing signed URLs can add significant complexity, especially as it scales. Every request needs to be signed, and it may not be a suitable long-term solution.
- Reasoning: While this can secure CloudFront, it doesn't address the core issue of unauthenticated access to the ALB. It's a partial solution, not an overall one.
Option C: Cre...
Author: Rohan · Last updated Jul 6, 2026
A company creates an AWS Control Tower landing zone to manage and govern a multi-account AWS environment. The company's security team will deploy preventive controls and detective controls to monitor AWS services across all the accounts. The security team nee...
Key Factors for Evaluation:
1. Centralized View: The solution must provide a centralized way to monitor the security state across multiple accounts.
2. Preventive and Detective Controls: The solution should allow both preventive and detective controls to be deployed across all accounts.
3. Integration with Existing AWS Control Tower: The solution should integrate smoothly into the AWS Control Tower environment and align with its governance framework.
4. Scalability: The solution should scale effectively across multiple accounts without adding significant operational overhead.
Evaluation of Each Option:
Option A: Use AWS CloudFormation StackSets to deploy an AWS Config conformance pack to all accounts in the organization
- Advantages:
- AWS Config Conformance Packs: This option allows you to deploy predefined security controls across accounts. AWS Config is designed for continuous monitoring of AWS resources to ensure compliance.
- Centralized Compliance View: AWS Config provides a centralized view of compliance with custom conformance packs.
- Disadvantages:
- Preventive Control Focus: While AWS Config conformance packs focus on compliance and preventive controls, they don’t directly provide centralized detective monitoring of security events or threats.
- Limited Detective Capabilities: This option does not focus on real-time monitoring of security incidents or threats. AWS Config is more focused on configuration compliance rather than detecting security issues or violations actively.
- Reasoning: This solution is good for compliance monitoring and preventive controls but lacks a robust detective monitoring mechanism. It doesn't fully meet the requirement of providing a comprehensive view of the security state in real-time.
Option B: Enable Amazon Detective for the organization in AWS Organizations and designate one AWS account as the delegated administrator
- Advantages:
- Centralized Threat Investigation: Amazon Detective provides security teams with tools to investigate and analyze potential security threats in real-time, which helps detect suspicious activity.
- Detective Control: This option addresses the detective aspect of the security controls by providing deep insights into security incidents across multiple accounts.
- Disadvantages:
- Not a Comprehensive Centralized View: While Amazon Detective provides valuable insights into security investigations, it doesn’t provide a full, centralized view of all security aspects (including configuration, compliance, etc.) across the entire organization.
- Limited to Threat Detection: Amazon Detective is focused on investigation rather than broad security management, compliance, or preventive controls.
- Reasoning: Amazon Detective is an importa...
Author: StarlightBear · Last updated Jul 6, 2026
A company that develops consumer electronics with offices in Europe and Asia has 60 TB of software images stored on premises in Europe. The company wants to transfer the images to an Amazon S3 bucket in the ap-northeast-1 Region. New software images are created daily and must be encrypted in transit. The company needs a solution that does not req...
Key Factors for Evaluation:
1. Encryption in Transit: The images must be encrypted during the transfer process.
2. Automatic Transfer of New and Existing Data: The solution must be automated to handle both existing data (60 TB) and daily updates (new images created daily).
3. No Custom Development: The solution must not require custom development, ensuring ease of use and minimal operational overhead.
4. Efficiency and Scalability: The solution should handle large data volumes efficiently and scale for future growth.
5. Low Complexity: The solution should be simple to deploy and manage without complex setup or maintenance.
Evaluation of Each Option:
Option A: Deploy an AWS DataSync agent and configure a task to transfer the images to the S3 bucket
- Advantages:
- Automated Transfer: AWS DataSync is designed for transferring large amounts of data between on-premises storage and AWS services, including Amazon S3, with minimal configuration. DataSync can be configured to transfer both existing data (60 TB) and new images created daily.
- Encryption in Transit: DataSync supports encryption in transit, ensuring that the data is securely transferred.
- Efficient Transfer: DataSync is optimized for large data migrations and incremental updates, ensuring that daily software image updates are automatically transferred.
- Disadvantages:
- Setup Required: While the setup involves configuring an agent and task, AWS DataSync is a managed service designed to simplify the process, requiring no custom development.
- Reasoning: This is the most suitable solution as it meets all the requirements: automated transfer of existing and new images, encrypted transfer, and no need for custom development. It is designed for large-scale transfers and integrates well with S3.
Option B: Configure Amazon Kinesis Data Firehose to transfer the images using S3 Transfer Acceleration
- Advantages:
- Transfer Speed: Kinesis Data Firehose can accelerate the transfer of data using S3 Transfer Acceleration.
- Disadvantages:
- Not Suitable for Large Files: Kinesis Data Firehose is designed for streaming data and might not be ideal for bulk transfer of large files (like 60 TB of software images) in a non-streaming manner.
- Complexity for Bulk Data: While it can handle real-time streaming, it is not a great fit for a bulk transfer of static data like images that need to be moved in bulk and incrementally over time.
- Encryption: Although Kinesis provides encryption options, it doesn’t natively encrypt files in transit in the same way as DataSync, and it may require more...
Author: ShadowWolf101 · Last updated Jul 6, 2026
A company has a web application that uses Amazon API Gateway. AWS Lambda, and Amazon DynamoDB. A recent marketing campaign has increased demand. Monitoring software reports that many requests have significantly longer response times than before the marketing campaign.
A solutions architect enabled Amazon CloudWatch Logs for API Gateway and noticed that errors are occurring on 20% of the requests. In CloudWatch, the Lambda function Throttles metric represents 1% of the requests and the Errors metric represents 10% of t...
To improve the response times for the web application as demand increases, the solutions architect needs to address the cause of the errors and long response times. Based on the provided details, errors occur when there is a call to DynamoDB, and these errors could be contributing to the slow response times. Let's review each option:
A) Increase the concurrency limit of the Lambda function.
- Reasoning: The Lambda Throttles metric indicates that only 1% of requests are throttled. This is a relatively low number, so increasing the concurrency limit would likely not resolve the root cause of the problem. Throttling is not the primary issue here; errors related to DynamoDB are more concerning.
- Conclusion: Increasing Lambda concurrency is not the most relevant option in this case since the bottleneck seems to be related to DynamoDB rather than Lambda itself.
B) Implement DynamoDB auto scaling on the table.
- Reasoning: The errors in the application logs are tied to calls to DynamoDB, which suggests that the table may be hitting throughput limits, especially during increased demand. DynamoDB auto scaling can automatically adjust the provisioned read and write capacity of the table to meet fluctuating traffic demands, reducing the likelihood of throttling errors in DynamoDB.
- Conclusion: This option directly addresses the issue with DynamoDB, where capacity could be exceeded under high load, leading to errors and slow responses. It allows the system to handle increased demand dynamically.
C) Increase the API Gateway throttle ...
Author: Deepak · Last updated Jul 6, 2026
A company has an application that has a web frontend. The application runs in the company's on-premises data center and requires access to file storage for critical data. The application runs on three Linux VMs for redundancy. The architecture includes a load balancer with HTTP request-based routing.
The company needs to migrate the application to AWS as quick...
Let's review the options in detail to determine the most suitable solution for migrating the on-premises application to AWS with minimal changes while meeting the need for high availability.
A) Migrate the application to Amazon Elastic Container Service (Amazon ECS) containers that use the Fargate launch type in three Availability Zones. Use Amazon S3 to provide file storage for all three containers. Use a Network Load Balancer to direct traffic to the containers.
- Reasoning: ECS with Fargate allows you to deploy and manage containers without managing the underlying EC2 instances. While S3 is a scalable object storage service, it is not ideal for scenarios that require low-latency file system access, such as file storage used by a traditional application. The use of a Network Load Balancer (NLB) is typically for TCP traffic, not HTTP-based routing, and may not be suitable for handling the application's routing logic, which seems to be HTTP-based.
- Conclusion: While this solution involves containers and is highly scalable, using S3 and NLB doesn’t align with the requirements for low-latency file storage and HTTP-based load balancing.
B) Migrate the application to Amazon EC2 instances in three Availability Zones. Use Amazon Elastic File System (Amazon EFS) for file storage. Mount the file storage on all three EC2 instances. Use an Application Load Balancer to direct traffic to the EC2 instances.
- Reasoning: This solution closely matches the existing architecture of the on-premises system with minimal changes. By using EC2 instances across three Availability Zones, you achieve high availability. Amazon EFS is a fully managed file system that works well for shared file storage, which can be mounted across multiple EC2 instances. Application Load Balancer (ALB) is perfect for HTTP-based routing. This solution also provides automatic scaling and redundancy.
- Conclusion: This is the simplest and most straightforward solution with the fewest changes to the existing architecture. It maintains the use of VMs (via EC2), supports high availability, and provides suitable file storage with EFS.
C) Migrate the application to Amazon Elastic Kubernetes Service (Amazon EKS) containers that use the Fargate launch typ...
Author: Ishaan · Last updated Jul 6, 2026
A company is planning to migrate an on-premises data center to AWS. The company currently hosts the data center on Linux-based VMware VMs. A solutions architect must collect information about network dependencies between the VMs. The information must be in the form of a diagram that...
To select the best solution, let's analyze the options based on the requirement of collecting information about network dependencies between the VMs, including host IP addresses, hostnames, and network connections in a diagram format.
A) Use AWS Application Discovery Service. Select an AWS Migration Hub home AWS Region. Install the AWS Application Discovery Agent on the on-premises servers for data collection. Grant permissions to Application Discovery Service to use the Migration Hub network diagrams.
- Reasoning: AWS Application Discovery Service provides detailed information about on-premises applications and their dependencies, including network dependencies. By installing the Discovery Agent on the on-premises servers, the service can gather data about the VMs, such as IP addresses, hostnames, and network connection information. The network diagram can be accessed from the Migration Hub and visualized. This solution aligns well with the requirement of collecting network information and generating a diagram.
- Conclusion: This solution is a strong candidate because it utilizes the correct AWS services to collect and visualize network dependency data.
B) Use the AWS Application Discovery Service Agentless Collector for server data collection. Export the network diagrams from the AWS Migration Hub in .png format.
- Reasoning: The Agentless Collector gathers server information without the need to install agents on the VMs, but it may not provide as detailed network dependency information as the agent-based method. The network diagrams generated can be exported in a .png format, which provides a visual representation of network connections. However, this method may have limitations in capturing specific network details and IP address-level granularity compared to the agent-based approach.
- Conclusion: This solution is viable but might lack the level of detail needed (especially around IP addresses and hostnames) compared to using the Discovery Agent.
C) Install the AWS Application Migration Service agent on the on-premises servers for data coll...
Author: Joseph · Last updated Jul 6, 2026
A company runs a software-as-a-service (SaaS) application on AWS. The application consists of AWS Lambda functions and an Amazon RDS for MySQL Multi-AZ database. During market events, the application has a much higher workload than normal. Users notice slow response times during the peak periods because of many database conn...
To meet the requirements of improving the scalable performance and availability of the database while addressing high database connections during peak workloads, let's review each option in detail.
A) Create an Amazon CloudWatch alarm action that triggers a Lambda function to add an Amazon RDS for MySQL read replica when resource utilization hits a threshold.
- Reasoning: While adding a read replica can help offload read traffic and improve scalability, creating an automated process via CloudWatch alarms to trigger the creation of a read replica may not be fast enough to address the immediate scaling needs during peak times. Also, adding a read replica dynamically during high traffic periods may introduce additional complexity and delays. This solution doesn't directly address the connection management issue.
- Conclusion: This option doesn't fully solve the issue because it focuses on scaling read replicas dynamically, which can be slow and doesn't tackle the root cause of high database connection usage.
B) Migrate the database to Amazon Aurora, and add a read replica. Add a database connection pool outside of the Lambda handler function.
- Reasoning: Migrating to Amazon Aurora is a good choice because it offers better scalability, performance, and high availability compared to RDS for MySQL. Adding a read replica improves scalability by offloading read operations. Implementing a connection pool outside of the Lambda function helps to reuse database connections efficiently, reducing the overhead caused by Lambda's frequent cold starts and database connection creation.
- Conclusion: This is a valid solution because it combines Aurora's scaling benefits with the database connection pooling to improve performance. However, it lacks automatic connection management at the database level.
C) Migrate the database to Amazon Aurora, and add a read replica. Use Amazon...
Author: Sofia · Last updated Jul 6, 2026
A company is planning to migrate an application from on premises to the AWS Cloud. The company will begin the migration by moving the application's underlying data storage to AWS. The application data is stored on a shared file system on premises, and the application servers connect to the shared file system through SMB.
A solutions architect must implement a solution that uses an Amazon S3 bucket for shared storage. Until the application is fully migrated and code is rewritten to use native Amazon S3 APIs, the application must continue to h...
Let's break down each option based on the requirements: the need to migrate application data to Amazon S3 while still providing access via SMB for the application to function without requiring code changes immediately.
A) Create a new Amazon FSx for Windows File Server file system. Configure AWS DataSync with one location for the on-premises file share and one location for the new Amazon FSx file system. Create a new DataSync task to copy the data from the on-premises file share location to the Amazon FSx file system.
- Reasoning: Amazon FSx for Windows File Server supports SMB and would allow the application to continue using SMB for file access. AWS DataSync could be used to efficiently migrate data from on-premises to the Amazon FSx file system. This solution allows the application to keep using SMB during the transition without requiring changes to the application.
- Conclusion: This is a good solution because it allows the migration of data while maintaining SMB access. It uses a fully managed service (FSx) that provides the needed file system with SMB support and handles data migration with DataSync.
B) Create an S3 bucket for the application. Copy the data from the on-premises storage to the S3 bucket.
- Reasoning: Amazon S3 is an object storage service, not a file system. It doesn’t support SMB directly, which is the protocol the application currently uses to access data. While S3 is the destination, this option doesn't satisfy the requirement to allow the application to continue accessing data via SMB.
- Conclusion: This option doesn't work because the application cannot access S3 through SMB without additional infrastructure, and rewriting the application to use S3 APIs is a longer-term effort.
C) Deploy an AWS Server Migration Service (AWS SMS) VM to the on-premises environment. Use AWS SMS to migrate the file storage server from on-premises to an Amazon EC2 instance.
- Reasoning: AWS Server Migration Service (SMS)...
Author: Mia · Last updated Jul 6, 2026
A global company has a mobile app that displays ticket barcodes. Customers use the tickets on the mobile app to attend live events. Event scanners read the ticket barcodes and call a backend API to validate the barcode data against data in a database. After the barcode is scanned, the backend logic writes to the database's single table to mark the barcode as used.
The company needs to deploy the app on AWS wi...
To determine the best solution for meeting the low-latency requirement for a global mobile app, we must consider several key factors, including data consistency, proximity to users, infrastructure complexity, and AWS services' capabilities. Here's an analysis of the options:
Option A:
- Database: Amazon Aurora Global Database clusters provide cross-region replication and allow for low-latency reads and writes in multiple AWS Regions, making it ideal for global applications requiring consistent and low-latency access to data.
- Backend: Hosting the backend on Amazon ECS (Elastic Container Service) clusters in the same Regions as the database ensures that backend services are close to the database, reducing latency for database queries.
- Routing: Using AWS Global Accelerator helps route requests to the nearest ECS cluster, providing low-latency access and automatic fault tolerance.
- Route 53: Directs traffic to the Global Accelerator, which then routes the requests to the nearest ECS cluster.
Pros:
- Global low-latency access to both the database and the backend.
- Global Accelerator optimizes routing and minimizes latency by sending traffic to the nearest region.
- Amazon ECS is a managed service with good integration into the AWS ecosystem.
Cons:
- The backend is in ECS, which may require more management compared to serverless alternatives like Lambda.
- Complexity in managing ECS clusters and ensuring scalability.
Option B:
- Database: Amazon Aurora Global Database clusters, as in Option A, providing cross-region replication for low-latency reads and writes.
- Backend: Using Amazon EKS (Elastic Kubernetes Service) instead of ECS allows for more advanced container orchestration and scalability. However, Kubernetes comes with increased operational complexity.
- Routing: CloudFront routes requests to the nearest EKS cluster. CloudFront is a content delivery network (CDN), which may not be ideal for dynamic backend API calls, as it typically caches static content rather than routing API requests efficiently.
- Route 53: Directs traffic to the CloudFront distribution.
Pros:
- Amazon Aurora Global Database provides excellent low-latency reads and writes.
- Kubernetes provides more fine-grained control and scalability over containers.
Cons:
- CloudFront is more suited for static content delivery than dynamic API requests. This could lead to unnecessary caching or routing delays for real-time API requests.
- Kubernetes adds operational complexity, especially in terms ...
Author: Liam · Last updated Jul 6, 2026
A medical company is running a REST API on a set of Amazon EC2 instances. The EC2 instances run in an Auto Scaling group behind an Application Load Balancer (ALB). The ALB runs in three public subnets, and the EC2 instances run in three private subnets. The company has deployed an Amazon CloudFront distri...
In this scenario, the goal is to enhance the security of the origin (the ALB) while allowing CloudFront to continue serving as the CDN. The focus should be on protecting the ALB from unauthorized access, ensuring that only CloudFront requests can reach the ALB and securing communication between CloudFront and the origin.
Let's evaluate the options:
Option A: Use Secrets Manager + Lambda for Secret Rotation + WAF
- Secrets Manager: Storing a random string in Secrets Manager and rotating it automatically with Lambda is a good way to manage credentials.
- CloudFront Custom Header: CloudFront would inject this string as a custom header in its requests to the ALB, which could then be validated using AWS WAF to ensure only authorized requests from CloudFront are allowed.
- WAF String Match Rule: This rule could inspect the custom header and block requests that don’t have the correct header.
- Pros: This adds a dynamic layer of security by ensuring that only CloudFront (which can include the secret string in the header) can access the ALB.
- Cons: This solution introduces additional complexity, as it requires the Lambda function for rotation and managing secrets securely in Secrets Manager.
Option B: WAF with IP Match Condition of CloudFront Service IPs + ALB in Private Subnets
- WAF with IP Match: This solution configures WAF to allow only IP addresses from CloudFront to access the ALB. CloudFront IP ranges are well-documented, and this rule could block unauthorized traffic.
- ALB in Private Subnets: Moving the ALB to private subnets enhances security by ensuring that the ALB isn't publicly accessible directly.
- Pros: Using WAF with CloudFront IP ranges ensures that only traffic from CloudFront is allowed to reach the ALB. Moving the ALB into private subnets minimizes exposure.
- Cons: This option is a little more restrictive and might require additional network configurations. Moving the ALB to private subnets adds complexity, especially when combined with CloudFront.
Option C: Store String in Parameter Store + CloudFront Custom Header + ALB Blocking Access
- Systems Manager Parameter Store: This is a viable alternative to Secrets Manager for storing the random string. It can be automatically rotated, just like Secrets Manager.
- CloudFront Custom Header: Similar to Option A, CloudFront can inject the string as a custom header, which the ALB would inspect.
- ALB ...
Author: Carlos Garcia · Last updated Jul 6, 2026
To abide by industry regulations, a solutions architect must design a solution that will store a company's critical data in multiple public AWS Regions, including in the United States, where the company's headquarters is located. The solutions architect is required to provide access to the data stored in AWS to the company's global WAN network. The security team mandates that no traffic accessing...
Key Considerations:
1. Security: No traffic should traverse the public internet, meaning traffic needs to stay within the AWS private network or the company's private WAN.
2. Highly Available: The solution must be able to withstand failures and provide resilience, ensuring continuous access to the data across AWS Regions.
3. Cost-Effectiveness: The solution should balance the cost of setup and maintenance while meeting the technical and regulatory requirements.
4. Access to Multiple AWS Regions: The company must be able to access data across multiple AWS Regions from its global WAN.
Option A: Direct Connect to All AWS Regions with WAN Access
- Direct Connect to All AWS Regions: This option proposes establishing AWS Direct Connect (DX) connections from the headquarters to every AWS Region used, allowing access to the data stored in each Region.
- Traffic via the WAN: The company’s WAN network will route traffic over DX connections, ensuring no public internet traffic is used.
- Pros: This solution guarantees secure and private connections to all Regions via Direct Connect, ensuring that no traffic crosses the public internet.
- Cons: Establishing DX connections to every AWS Region can be costly and complex, especially as the company scales or adds new Regions. The network setup becomes more complicated with each additional connection to new Regions.
Option B: Direct Connect to One AWS Region + Inter-Region VPC Peering
- Direct Connect to One Region: This option suggests establishing two DX connections to a single AWS Region and then using inter-region VPC peering to access data in other Regions.
- Inter-region VPC Peering: Inter-region VPC peering allows communication between VPCs in different Regions, but it may introduce latency or reliability concerns, especially as the company adds more Regions.
- Pros: More cost-effective than Option A because it only requires DX connections to one Region. Inter-region VPC peering is relatively simple to set up.
- Cons: Inter-region VPC peering introduces potential network overhead and can lead to complexity in managing network routes. It also might not offer the best performance or reliability across Regions.
Option C: Direct Connect to One AWS Region + Transit VPC
- Direct Connect to One Region: This option also involves two DX connections to one Region, but it proposes using a Transit VPC solution to facilitate cross-region communication.
- Transit VPC: A Transit VPC allows routing traffic between multiple VPCs in different Regions, provi...
Author: SilverBear · Last updated Jul 6, 2026
A company has developed an application that is running Windows Server on VMware vSphere VMs that the company hosts on premises. The application data is stored in a proprietary format that must be read through the application. The company manually provisioned the servers and the application.
As part of its disaster recovery plan, the company wants the ability to host its application on AWS temporarily if the company's on-premises environment becomes unavailable. The company wan...
Key Considerations:
1. Disaster Recovery (DR) Requirements: The solution must ensure that the application can be quickly launched in AWS if the on-premises environment becomes unavailable, and then it must be able to return to the on-premises environment after the disaster recovery event.
2. Recovery Point Objective (RPO): The RPO is 5 minutes, meaning data replication must happen at least every 5 minutes to ensure minimal data loss.
3. Operational Overhead: The solution should minimize the manual effort and complexity involved in provisioning and managing the infrastructure, especially when failover or failback occurs.
4. Proprietary Application and Data: The application runs on Windows Server VMs, and the data is stored in a proprietary format that must be accessed through the application itself. This means that using a standard file-based solution might not suffice.
Evaluation of Each Option:
Option A: AWS DataSync to Amazon EBS Volumes
- AWS DataSync: This service can help transfer data to Amazon EBS, but it does not support the ongoing replication needed to meet the 5-minute RPO requirement without a more complex setup.
- Manual Provisioning with CloudFormation: Once the environment is unavailable, this solution requires manually provisioning EC2 instances using AWS CloudFormation templates, which introduces significant operational overhead.
- Pros: DataSync can efficiently transfer data to EBS volumes, and CloudFormation simplifies provisioning.
- Cons: DataSync is not designed to continuously replicate data at the required RPO of 5 minutes, and manual provisioning increases operational complexity. This does not provide the seamless recovery experience needed.
Option B: AWS Elastic Disaster Recovery (AWS DRS)
- AWS Elastic Disaster Recovery: This service is specifically designed for disaster recovery scenarios, providing near-zero RPO and RTO (Recovery Time Objective). It continuously replicates the source environment (in this case, VMware on-premises VMs) to AWS, ensuring that data and VM states are kept in sync with minimal latency.
- Replicated EC2 Instances: AWS DRS automatically provisions EC2 instances using the replicated data and EBS volumes when the on-premises environment becomes unavailable.
- Pros:
- Meets the 5-minute RPO requirement with continuous replication.
- Simple failover process without requiring manual intervention.
- Supports the full VM-based environment, which is critical for the proprietary application and its specific data format.
- Cons: AWS DRS incurs additional costs for continuous replication and recovery, but it is designed ...
