Amazon Practice Questions, Discussions & Exam Topics by our Authors
A large international university has deployed all of its compute services in the AWS Cloud. These services include Amazon EC2, Amazon RDS, and Amazon DynamoDB. The university currently relies on many custom scripts to back up its infrastructure. However, the university wants to centralize manage...
To meet the university's goal of centralizing and automating data backups for its AWS services (Amazon EC2, Amazon RDS, and Amazon DynamoDB), we need to assess each option based on factors like ease of management, integration with AWS services, and automation. Let’s analyze the options:
A) Use third-party backup software with an AWS Storage Gateway tape gateway virtual tape library.
- Analysis: While third-party backup software and AWS Storage Gateway can be used to backup data, this solution introduces complexity and potential operational overhead. It requires managing third-party software alongside AWS services, which does not align with the university’s goal of centralizing and automating backups using AWS native options. Additionally, AWS Storage Gateway's tape gateway is designed primarily for hybrid cloud environments and not specifically for native AWS services like EC2, RDS, or DynamoDB.
- Rejection: This option is not the best fit because it introduces complexity and relies on third-party software, which contradicts the goal of leveraging AWS native services for backup automation.
B) Use AWS Backup to configure and monitor all backups for the services in use.
- Analysis: AWS Backup is a fully managed backup service that integrates with many AWS services, including Amazon EC2, Amazon RDS, and Amazon DynamoDB. It allows you to centralize backup management, automate backup schedules, and ensure consistent backup policies across AWS resources. AWS Backup also supports backup monitoring and auditing, which is essential for compliance and operational oversight. It is a native AWS solution, which aligns perfectly with the university’s goal of automating and centralizing backup management.
- Selection: This is the most suitable option. AWS Backup is purpose-built for centralized backup management across multiple AWS services, offering automation and integration with a wide variety of AWS services. It meets the university’s requirements effectively with minimal operational overhead....
Author: NightmareDragon2025 · Last updated Jul 12, 2026
A company wants to build a map of its IT infrastructure to identify and enforce policies on resources that pose security risks. The company's security team must be able to query data in the IT infrastructure map and quickly identify...
To meet the company's requirement of building a map of its IT infrastructure, identifying security risks, and querying the data with minimal operational overhead, we need to analyze each option based on the following factors:
1. Operational Overhead: How much management and maintenance is required for the solution.
2. Suitability for Graph-Based Data: The IT infrastructure map is essentially a graph of resources, so we need a database that can efficiently store and query graph-like data (e.g., relationships between resources).
3. Querying Complexity: The solution should allow efficient and easy querying, particularly to identify security risks in the infrastructure.
A) Use Amazon RDS to store the data. Use SQL to query the data to identify security risks.
- Analysis: Amazon RDS is a relational database service, which is optimized for structured data in tables. While it can store data in a structured format and support SQL queries, it is not ideal for graph-based data where relationships between resources need to be represented and queried efficiently. SQL can handle basic relationships, but it's not optimized for querying complex relationships like those found in an infrastructure map.
- Rejection: This option may work in some scenarios but would result in more complex queries and less efficient querying of relationships between resources. It's not the best fit for graph-like data in infrastructure mapping.
B) Use Amazon Neptune to store the data. Use SPARQL to query the data to identify security risks.
- Analysis: Amazon Neptune is a fully managed graph database that supports both the Property Graph and RDF (Resource Description Framework) models. It is designed specifically for storing and querying graph data, making it an ideal choice for mapping IT infrastructure and identifying relationships between resources. It supports SPARQL (for RDF data) and Gremlin (for Property Graph), both of which are optimized for querying graph relationships. This makes querying the infrastructure map for security risks highly efficient.
- Selection: This option is the most suitable for the...
Author: Emma · Last updated Jul 12, 2026
A large company wants to provide its globally located developers separate, limited size, managed PostgreSQL databases for development purposes. The databases will be low volume. The developers need the databases only when ...
Let's analyze each option for this scenario:
A) Give the developers the ability to launch separate Amazon Aurora instances. Set up a process to shut down Aurora instances at the end of the workday and to start Aurora instances at the beginning of the next workday.
- Pros: Aurora is a fully managed service, and developers can launch separate instances, which ensures they can have independent environments.
- Cons: Managing the startup and shutdown process is manual and introduces overhead. Aurora instances are relatively expensive compared to other PostgreSQL solutions, especially if you have to run them all the time, even though they're low volume.
- Why rejected: The need for manual or automated processes to start and stop instances adds complexity and doesn't inherently reduce costs since Aurora is designed for high availability and can incur significant operational costs even when idle. This will not meet the "cost-effectiveness" requirement.
B) Develop an AWS Service Catalog product that enforces size restrictions for launching Amazon Aurora instances. Give the developers access to launch the product when they need a development database.
- Pros: Service Catalog can enforce size restrictions, ensuring that the database instances are within the required capacity for low-volume usage.
- Cons: Like option A, this still involves using Amazon Aurora, which is not the most cost-effective for low-volume databases. While size restrictions can limit costs, it's still an overkill for simple development purposes.
- Why rejected: It still involves the complexity and cost of running Aurora instances, which might be over-provisioned for the low-volume development needs.
C) Create an Amazon Aurora Serverless cluster. Develop an AWS Service Catalog product to launch databases in the cluster with the default capacity settings. Grant the developers access to the product.
- Pros: Aurora Serverless adjusts capacity dynamically, ...
Author: Liam · Last updated Jul 12, 2026
A company is building a web application that serves a content management system. The content management system runs on Amazon EC2 instances behind an Application Load Balancer (ALB). The EC2 instances run in an Auto Scaling group across multiple Availability Zones. Users are constantly adding and updating files, blogs, and other website assets in the content management system.
A solutions archi...
Let's analyze each option for this scenario:
A) Update the EC2 user data in the Auto Scaling group lifecycle policy to copy the website assets from the EC2 instance that was launched most recently. Configure the ALB to make changes to the website assets only in the newest EC2 instance.
- Pros: EC2 instances would be updated with the latest assets based on the most recently launched instance, which might seem efficient.
- Cons: This introduces complexity as only the most recent EC2 instance is used to update the website assets. This method can create potential race conditions or lag between instances, and doesn't provide a consistent and immediate way to share assets across all instances. This approach could cause inconsistent content if different instances have different versions of assets.
- Why rejected: It is not ideal for shared content updates because it’s dependent on the launch order of EC2 instances and doesn’t ensure that all EC2 instances are immediately up-to-date with the website content.
B) Copy the website assets to an Amazon Elastic File System (Amazon EFS) file system. Configure each EC2 instance to mount the EFS file system locally. Configure the website hosting application to reference the website assets that are stored in the EFS file system.
- Pros: Amazon EFS provides a shared file system across all EC2 instances. EFS is highly available, scalable, and supports multiple EC2 instances accessing the same files concurrently, which is ideal for scenarios where you need to share content among multiple instances. It ensures that all EC2 instances access the most up-to-date version of the website assets.
- Cons: EFS is an additional service, and while it’s easy to set up and manage, it may introduce higher costs compared to other solutions like S3 or EBS. However, for shared, low-latency access to website assets across multiple EC2 instances, EFS is highly efficient.
- Why selected: EFS is designed for scenarios where multiple EC2 instances need to access a shared file system. It guarantees that all instances have up-to-date content with minimal lag, making it the best choice in this case.
C) Copy the website assets to an Amazon S3 bucket. Ensure that each EC2 instance downloads ...
Author: Liam · Last updated Jul 12, 2026
A company's web application consists of multiple Amazon EC2 instances that run behind an Application Load Balancer in a VPC. An Amazon RDS for MySQL DB instance contains the data. The company needs the ability to automatically detect and respond to suspicious or unexpected behavior in its AWS environment....
Let's evaluate each option based on the requirements of automatic detection and response to suspicious or unexpected behavior:
A) Use Amazon GuardDuty to perform threat detection. Configure Amazon EventBridge to filter for GuardDuty findings and to invoke an AWS Lambda function to adjust the AWS WAF rules.
- Pros: Amazon GuardDuty is a threat detection service that continuously monitors for malicious or unauthorized behavior. It integrates well with EventBridge to automatically respond to findings. The Lambda function can adjust the AWS WAF rules in real time based on GuardDuty's findings. GuardDuty provides a comprehensive detection solution, identifying threats like anomalous API calls, unusual network traffic, and compromised EC2 instances.
- Cons: There are no significant cons for this scenario, as GuardDuty is well-suited for detecting suspicious activities and integrates seamlessly with AWS services such as WAF and Lambda.
- Why selected: This solution provides continuous threat detection with automatic responses through EventBridge and Lambda. It complements the existing AWS WAF integration and offers a proactive, automated approach to detecting and responding to threats, making it the best choice for the company’s needs.
B) Use AWS Firewall Manager to perform threat detection. Configure Amazon EventBridge to filter for Firewall Manager findings and to invoke an AWS Lambda function to adjust the AWS WAF web ACL.
- Pros: AWS Firewall Manager is a service that simplifies managing firewall rules across multiple accounts and resources. It integrates well with AWS WAF, but it is primarily used to manage and enforce security policies rather than detecting specific threats.
- Cons: Firewall Manager is not specifically designed for threat detection; rather, it's a management tool. It works with WAF but does not perform real-time threat detection like GuardDuty. Therefore, it's less ideal for responding to unexpected or suspicious behavior as required in this scenario.
- Why rejected: Firewall Manager is more focused on managing security configurations, not on detecting threats or anomalies. GuardDuty is the better option for act...
Author: Kunal · Last updated Jul 12, 2026
A company is planning to run a group of Amazon EC2 instances that connect to an Amazon Aurora database. The company has built an AWS CloudFormation template to deploy the EC2 instances and the Aurora DB cluster. The company wants to allow the instances to authenticate to the database in a secure way. The compan...
Let's analyze each option in terms of meeting the requirements for secure database authentication and minimizing operational effort:
A) Create a database user with a user name and password. Add parameters for the database user name and password to the CloudFormation template. Pass the parameters to the EC2 instances when the instances are launched.
- Pros: This approach would allow the EC2 instances to authenticate using a username and password.
- Cons: The main issue with this approach is that it still involves static credentials (username and password), which is against the goal of not maintaining static database credentials. The credentials would need to be stored somewhere, either in the CloudFormation template or passed in as parameters, which could be a security risk. Additionally, if credentials change, the entire template would need to be updated and redeployed.
- Why rejected: This option involves managing static credentials, which the company is trying to avoid, and it adds overhead in maintaining and updating credentials securely.
B) Create a database user with a user name and password. Store the user name and password in AWS Systems Manager Parameter Store. Configure the EC2 instances to retrieve the database credentials from Parameter Store.
- Pros: Storing credentials in AWS Systems Manager Parameter Store is more secure than directly hardcoding them in the CloudFormation template. Parameter Store can be encrypted, and access can be controlled using IAM roles. This approach reduces the operational overhead of managing static credentials manually.
- Cons: While this approach secures the credentials, it still involves managing static credentials (username and password). If credentials change, the EC2 instances would need to retrieve the updated credentials, which could add complexity. It also still requires the manual management of usernames and passwords.
- Why rejected: While it improves security compared to storing credentials directly in CloudFormation, it still relies on static database credentials, which is not the most secure solution.
C) Configure the DB cluster to use IAM ...
Author: Krishna · Last updated Jul 12, 2026
A company wants to configure its Amazon CloudFront distribution to use SSL/TLS certificates. The company does not want to use the default domain name for the distribution. Instead, the company wants to use a different domain name for t...
Let's evaluate each option in terms of the requirements of using SSL/TLS certificates with CloudFront and avoiding additional costs:
A) Request an Amazon issued private certificate from AWS Certificate Manager (ACM) in the us-east-1 Region.
- Pros: Private certificates can be issued by ACM for internal use or for private resources, which are typically not for public-facing use.
- Cons: CloudFront requires the certificate to be a public certificate to serve content to the internet. Private certificates are not suitable for use with CloudFront for public-facing domain names.
- Why rejected: A private certificate is not appropriate for CloudFront, which requires a public certificate to serve SSL/TLS traffic to users on the internet.
B) Request an Amazon issued private certificate from AWS Certificate Manager (ACM) in the us-west-1 Region.
- Pros: This option would allow for a private certificate to be issued, potentially useful for internal applications.
- Cons: As with Option A, private certificates are not compatible with CloudFront for serving public SSL/TLS traffic.
- Why rejected: A private certificate is not usable with CloudFront for public SSL/TLS encryption, so this option does not meet the requirement.
C) Request an Amazon issued public certificate from AWS Certificate Manager (ACM) in the us-east-1 Region.
- Pros: A public certificate fr...
Author: Krishna · Last updated Jul 12, 2026
A company creates operations data and stores the data in an Amazon S3 bucket. For the company's annual audit, an external consultant needs to access an annual report that is stored in the S3 bucket. The external consultant needs to access the report for 7 days.
The company must implement a solution to allow ...
Let's evaluate each option based on the requirements:
Option A: Create a new S3 bucket that is configured to host a public static website. Migrate the operations data to the new S3 bucket. Share the S3 website URL with the external consultant.
- Drawbacks:
- This option involves moving the data to a new S3 bucket, which introduces unnecessary overhead and additional complexity for a one-time audit.
- Hosting the S3 bucket as a public website increases the security risk, as it makes all the content within that bucket publicly accessible unless you implement additional access control mechanisms.
- This option does not restrict the external consultant's access to just the report and could expose more data than necessary.
- Use case: This approach is not ideal for this scenario because of the operational inefficiencies and potential security concerns.
Option B: Enable public access to the S3 bucket for 7 days. Remove access to the S3 bucket when the external consultant completes the audit.
- Drawbacks:
- Enabling public access to the entire S3 bucket can expose sensitive data to the internet, which could create security risks. The requirement is to give the consultant access only to a single report, not to everything in the bucket.
- The need to manually remove public access after 7 days introduces operational overhead and potential for human error.
- Use case: This approach is not secure and introduces unnecessary complexity. It's not recommended for temporary access to a single file.
Option C: Create a new IAM user that has access to the report in the S3 bucket. Provide the access keys to t...
Author: Ethan · Last updated Jul 12, 2026
A company plans to run a high performance computing (HPC) workload on Amazon EC2 Instances. The workload requires low-latency network performance and high network throughput with tightly co...
Let's evaluate each option based on the requirements:
Option A: Configure the EC2 instances to be part of a cluster placement group.
- Benefits:
- A cluster placement group is designed specifically for workloads that require low-latency and high throughput between instances.
- Instances in a cluster placement group are placed physically close to each other within a single Availability Zone, minimizing network latency and maximizing network performance.
- This configuration is perfect for high-performance computing (HPC) workloads that involve tight node-to-node communication.
- Use case: This is the ideal option for workloads that require low-latency network performance and high throughput, such as HPC applications. The instances in the cluster can communicate with minimal network delay, making this the best choice for the given requirements.
Option B: Launch the EC2 instances with Dedicated Instance type.
- Drawbacks:
- Dedicated Instances are instances that run on hardware dedicated to a single customer, but they don't offer the low-latency or high throughput capabilities required for tightly coupled communication.
- While Dedicated Instances ensure physical isolation, they do not improve network performance or enable the tight coupling between instances that are needed for HPC workloads.
- Use case: Dedicated Instances are better suited for workloads that require hardware isolation for compliance or licensing reasons, but they are not optimal for high-performance computing with tight node-to-node communication.
Option C: Launch the EC2 instances as Spot Instances.
- Drawbacks:
- Spot Instances can be interrupted by AWS with little no...
Author: Suresh · Last updated Jul 12, 2026
A company has primary and secondary data centers that are 500 miles (804.7 km) apart and interconnected with high-speed fiber-optic cable. The company needs a highly available and secure network connection between its data centers and a VPC on AWS for a mission-critical workload. A soluti...
Let's evaluate each option based on the requirements of high availability, resiliency, and security for the network connection between the data centers and AWS.
Option A: Two AWS Direct Connect connections from the primary data center terminating at two Direct Connect locations on two separate devices
- Benefits:
- This setup involves two separate devices for Direct Connect at two different locations.
- It provides resiliency by ensuring that if one Direct Connect device or location fails, traffic can be rerouted to the other one.
- However, it lacks full geographic redundancy, as both connections are coming from the same data center (the primary data center). If the primary data center experiences an issue, both connections might go down, making this solution vulnerable to a single point of failure in that location.
- Drawbacks:
- Although this offers redundancy in terms of the devices and locations within the primary data center, it does not provide full geographic resilience between the primary and secondary data centers, which is critical for a mission-critical workload.
- Use case: This might be suitable in situations where the primary data center is expected to handle all traffic and any failure will be mitigated within that data center. However, for true resilience across geographically separated data centers, this option is not optimal.
Option B: A single AWS Direct Connect connection from each of the primary and secondary data centers terminating at one Direct Connect location on the same device
- Drawbacks:
- This setup creates a single point of failure at the Direct Connect location and device. If the device or location fails, all traffic from both data centers would be disrupted.
- There is no redundancy in either the data center or the device, and there is no geographic diversity to prevent service disruptions in case of a failure at either data center or the Direct Connect location.
- Use case: This is not an ideal solution for a mission-critical workload because it does not offer resiliency, particularly given the reliance on a single device and locatio...
Author: Michael · Last updated Jul 12, 2026
A company runs several Amazon RDS for Oracle On-Demand DB instances that have high utilization. The RDS DB instances run in member accounts that are in an organization in AWS Organizations.
The company's finance team has access to the organization's management account and member accounts. The finance team wants...
Let's evaluate each option to determine which will help the finance team optimize costs for their Amazon RDS for Oracle On-Demand DB instances:
Option A: Use the Trusted Advisor recommendations in the management account.
- Benefits:
- The management account in AWS Organizations has access to AWS Trusted Advisor for all linked accounts in the organization.
- You can view Trusted Advisor recommendations across the entire organization from the management account, which provides a unified view of all accounts’ resources and optimizations.
- Use case: This option is highly suitable because the finance team can access all recommendations from a single point (the management account) and optimize costs across the organization's accounts, including the ones with high utilization.
Option B: Use the Trusted Advisor recommendations in the member accounts where the RDS DB instances are running.
- Drawbacks:
- Trusted Advisor checks in individual member accounts are typically restricted to that account's resources. To optimize costs for RDS DB instances across the organization, accessing Trusted Advisor through the management account (which aggregates recommendations for all accounts) is a more efficient option.
- If you use individual member accounts, you would need to check each member account individually for recommendations, which can be inefficient.
- Use case: This option might be helpful if the finance team only wants to optimize costs in a specific member account, but for organization-wide optimization, it is more practical to use the management account (Option A).
Option C: Review the Trusted Advisor checks for Amazon RDS Reserved Instance Optimization.
- Benefits:
- The RDS Reserved Instance Optimization check in Trusted Advisor specifically helps identify opportunities for optimizing costs related to RDS Reserved Instances.
- It checks if there are underutilized Reserved Instances or if instances could be converted to Reserved Instances for cost savings.
- Use case: This option is directly relevant because the company i...
Author: Aria · Last updated Jul 12, 2026
A solutions architect is creating an application. The application will run on Amazon EC2 instances in private subnets across multiple Availability Zones in a VPC. The EC2 instances will frequently access large files that contain confidential information. These files are stored in Amazon S3 buckets for processing. The solutions archite...
Let's evaluate the options based on the requirement to optimize network architecture and minimize data transfer costs for EC2 instances accessing large files in S3, while keeping the instances in private subnets.
Option A: Create a gateway endpoint for Amazon S3 in the VPC. In the route tables for the private subnets, add an entry for the gateway endpoint.
- Benefits:
- A gateway endpoint is a private connection between the VPC and Amazon S3 that allows traffic to flow directly from the private subnets to S3 without traversing the public internet.
- This eliminates data transfer charges associated with traffic leaving the VPC to access Amazon S3 via the internet (e.g., through a NAT gateway).
- It is highly cost-effective because the data stays within the AWS network, and there is no charge for data transfer between VPCs and S3 if the traffic stays within the same region.
- Best practice for private subnet architectures where EC2 instances need to access S3 securely without the need for public IPs or NAT gateways.
- Use case: This is the most optimal solution as it directly addresses the requirement to minimize data transfer costs and is designed to work within private subnets. It avoids using the internet or NAT for accessing S3, which would incur unnecessary data transfer fees.
Option B: Create a single NAT gateway in a public subnet. In the route tables for the private subnets, add a default route that points to the NAT gateway.
- Drawbacks:
- A NAT gateway allows instances in private subnets to access the internet for things like software updates, external API calls, or S3 access. However, using a NAT gateway for accessing S3 would incur additional data transfer costs, as traffic to and from S3 would go over the internet (even if it's within the same region).
- Data transfer costs are higher when traffic goes through a NAT gateway because it's routing traffic out of the private subnet to the internet, then back into AWS. This solution is less optimal in terms of cost optimization.
- Use case: While this solution allows access to S3, it increases data transfer costs and is not the ...
Author: Abigail · Last updated Jul 12, 2026
A company wants to relocate its on-premises MySQL database to AWS. The database accepts regular imports from a client-facing application, which causes a high volume of write operations. The company is concerned that the amount of traffic might be causing ...
When designing the architecture for relocating an on-premises MySQL database to AWS, the goal is to improve performance and reduce the impact of high write operations from the client-facing application. Below, we'll analyze each option to determine which is most appropriate.
A) Provision an Amazon RDS for MySQL DB instance with Provisioned IOPS SSD storage. Monitor write operation metrics by using Amazon CloudWatch. Adjust the provisioned IOPS if necessary.
- Why this option might work: Amazon RDS with Provisioned IOPS (SSD) provides high-performance storage for database workloads with a focus on low-latency, high-throughput performance for read and write operations. This option is particularly suited to workloads with high write traffic because it ensures faster and more consistent performance during heavy I/O operations.
- Why this might not be ideal: While provisioning IOPS SSD can help handle heavy write operations, it doesn't specifically address traffic bottlenecks related to reads. If the write operations are consistently heavy, this solution might still cause latency in the application if not properly managed.
B) Provision an Amazon RDS for MySQL DB instance with General Purpose SSD storage. Place an Amazon ElastiCache cluster in front of the DB instance. Configure the application to query ElastiCache instead.
- Why this option might work: This setup could help offload read-heavy traffic from the MySQL database to ElastiCache (in-memory caching), which would reduce the load on the MySQL instance and improve performance. This is particularly beneficial if the application has read-heavy patterns but still needs to handle the writes in MySQL. ElastiCache is great for caching frequent queries and can significantly improve response time by reducing the load on the database.
- Why this might not be ideal: Since the issue described in the problem is a high volume of write operations, using ElastiCache would only help with the read load and won't directly address the issue of write operations. For a solution focused specifically on handling high write traffic, the addition of ElastiCache may not fully mitigate the performance issues related to high write operations.
C) Provision an Amazon DocumentDB (with MongoDB compatibility) instance with a memory-optimized instance type. Monitor Amazon CloudWatch f...
Author: Emma Brown · Last updated Jul 12, 2026
A company runs an application in the AWS Cloud that generates sensitive archival data files. The company wants to rearchitect the application's data storage. The company wants to encrypt the data files and to ensure that third parties do not have access to the data before the data is enc...
Analyzing the Requirements:
The company wants to:
1. Encrypt sensitive archival data files: This implies that encryption must be performed before storing the data in the cloud.
2. Ensure third parties do not have access to the data before it is encrypted: This suggests that the data must be encrypted before it is sent to AWS (i.e., client-side encryption).
3. Use Amazon S3 for storage: The company has already set up an S3 bucket to store the archival data.
Evaluating Each Option:
A) Configure the S3 bucket to use client-side encryption with an Amazon S3 managed encryption key. Configure the application to use the S3 bucket to store the archival files.
- Why this might work: Client-side encryption means the application will encrypt data before uploading it to S3. This ensures that data is encrypted before it reaches AWS, and no third parties can access the unencrypted data. S3-managed encryption keys (SSE-S3) are used for the server-side decryption when the data is read, but the application does the encryption.
- Why this might not be ideal: Using an S3-managed encryption key means the encryption key is managed by Amazon, which might not be desirable for sensitive data where the company needs full control over key management. Also, SSE-S3 does not provide the level of fine-grained control and auditability that AWS KMS would offer.
B) Configure the S3 bucket to use server-side encryption with AWS KMS keys (SSE-KMS). Configure the application to use the S3 bucket to store the archival files.
- Why this might not be ideal: This option involves server-side encryption, which means that the data is uploaded to S3 in plaintext and only encrypted when it reaches the S3 bucket. The company is concerned about third parties having access to the data before it is encrypted and sent to AWS. Server-side encryption doesn't fulfill this requ...
Author: Vikram · Last updated Jul 12, 2026
A company uses Amazon RDS with default backup settings for its database tier. The company needs to make a daily backup of the database to meet regulatory requirements. The company must retain the backups for 30...
Analyzing the Requirements:
The company needs to:
1. Make a daily backup of the database.
2. Retain the backups for 30 days to meet regulatory requirements.
3. Minimize operational overhead, ensuring that the solution is simple and automated.
Evaluating Each Option:
A) Write an AWS Lambda function to create an RDS snapshot every day.
- Why this might work: This option involves creating a Lambda function that can automatically create an RDS snapshot every day, which ensures regular backups. The snapshots can then be retained for 30 days.
- Why this might not be ideal: While this approach automates the backup process, it involves maintaining a Lambda function and handling retention logic for the snapshots manually. The operational overhead is relatively high because you must manage the Lambda function, ensure it works correctly, and handle snapshot deletions after 30 days. Additionally, Lambda might not be the best choice for something that could be handled directly by RDS backup mechanisms.
B) Modify the RDS database to have a retention period of 30 days for automated backups.
- Why this works well: Amazon RDS provides automated backups as a managed feature, which includes daily snapshots. By setting the retention period to 30 days, RDS will automatically keep daily backups for the required duration. This approach is fully integrated into RDS, reducing manual intervention, operational overhead, and complexity.
- Why this is ideal: This solution leverages RDS’s native automated backup feature, which is designed specifically for this use case. The backups are managed automatically, and there’s no need for manual intervention or additional custom solutions, ensuring low operational overhead.
C) Use AWS Systems Manager Maintenance Windows to modify the RDS backup retention period.
- Why...
Author: Rahul · Last updated Jul 12, 2026
A company that runs its application on AWS uses an Amazon Aurora DB cluster as its database. During peak usage hours when multiple users access and read the data, the monitoring system shows degradation of database performance for the write queries. The company wants to increase the scal...
Analyzing the Requirements:
The company is experiencing degradation in write query performance during peak usage hours, particularly when multiple users access and read the data. The company wants to increase scalability to meet peak usage demands, but it also needs a cost-effective solution.
Evaluating Each Option:
A) Create a second Aurora DB cluster. Configure a copy job to replicate the users' data to the new database. Update the application to use the second database to read the data.
- Why this might not be ideal: While creating a second Aurora DB cluster could help by offloading some of the read traffic, the solution introduces additional complexity and costs. Replicating data to a new DB cluster may also introduce latency and consistency issues between the two clusters. This approach increases operational overhead and requires manual management of replication and data consistency.
- Why this is rejected: It is more complex and costly than alternatives like read replicas, and may not provide the necessary scalability or performance benefits that are needed for the application to meet peak usage demands.
B) Create an Amazon DynamoDB Accelerator (DAX) cluster in front of the existing Aurora DB cluster. Update the application to use the DAX cluster for read-only queries. Write data directly to the Aurora DB cluster.
- Why this might not be ideal: DAX is designed for use with DynamoDB to speed up read-heavy workloads, but Aurora is a relational database and is not compatible with DAX. DAX cannot be used as a caching layer for Aurora, so this solution is not applicable.
- Why this is rejected: DAX is not compatible with Aurora, making this solution irrelevant for the requirements. It doesn’t solve the scalability issue for an Aurora database.
C) Create an Aurora read replica in the existing Aurora DB cluster. Update the application to use the replica endpoint for read-only queries and to use the cluster endpoint for write queries.
- Why this works well: Aurora read replicas can offload read queries from the primary database cluster. By directi...
Author: Emma · Last updated Jul 12, 2026
A company's near-real-time streaming application is running on AWS. As the data is ingested, a job runs on the data and takes 30 minutes to complete. The workload frequently experiences high latency due to large amounts of incoming data. A solutions architect needs to design a scalable and...
Analyzing the Requirements:
The company’s application is running into latency issues because of the large amounts of incoming data, and the job processing it takes 30 minutes to complete. The goal is to design a scalable, serverless solution that improves performance and reduces latency.
Evaluating Each Option:
A) Use Amazon Kinesis Data Firehose to ingest the data.
- Why this might work: Amazon Kinesis Data Firehose is a fully managed service that can ingest streaming data and automatically deliver it to destinations like Amazon S3, Amazon Redshift, or Amazon Elasticsearch Service. It can scale automatically to handle high data volumes, making it ideal for ingesting real-time data.
- Why this might not be ideal: While Kinesis Data Firehose is excellent for data ingestion, it does not address the issue of processing data in near-real-time or improving the latency of the processing job. It is primarily focused on the ingestion layer, and the solution still needs a way to handle processing and job execution, which takes 30 minutes in the current setup.
B) Use AWS Lambda with AWS Step Functions to process the data.
- Why this works: AWS Lambda is a serverless compute service that can automatically scale to handle large amounts of incoming data, and it is well-suited for real-time or near-real-time processing. AWS Step Functions can be used to orchestrate multiple Lambda functions, enabling complex workflows and breaking down the 30-minute job into smaller tasks that can run in parallel or asynchronously. This can significantly reduce latency by processing the data faster and in a scalable, serverless manner.
- Why this is ideal: Lambda and Step Functions are both serverless and can scale automatically with incoming data. This option provides a highly scalable solution to process data faster and reduce the job's latency, making it a strong candidate for enhancing performance.
C) Use AWS Database Migration Service (AWS DMS) to ingest the data.
- Why this might not be ideal: AWS DMS is typically used for migrating databases to AWS and replicating data between different data stores. It is not designed to handl...
Author: Akash · Last updated Jul 12, 2026
A company runs a web application on multiple Amazon EC2 instances in a VPC. The application needs to write sensitive data to an Amazon S3 bucket. The data cannot be sent ...
To meet the requirement of writing sensitive data to an Amazon S3 bucket without sending it over the public internet, let's analyze each option and determine the most suitable one:
Option A: Create a gateway VPC endpoint for Amazon S3. Create a route in the VPC route table to the endpoint.
- Explanation: A gateway VPC endpoint for Amazon S3 allows communication between instances in the VPC and S3 without using the public internet. Traffic to Amazon S3 will be routed directly through the VPC endpoint, making this a private connection.
- Why it’s suitable: This option ensures that sensitive data is not sent over the public internet. It provides secure, private access to Amazon S3, which meets the security and compliance requirements.
- Why others are rejected:
- Option B: Creating an internal Network Load Balancer (NLB) with the S3 bucket as the target doesn’t make sense because an NLB is typically used to route traffic to EC2 in...
Author: Charlotte · Last updated Jul 12, 2026
A company runs its production workload on Amazon EC2 instances with Amazon Elastic Block Store (Amazon EBS) volumes. A solutions architect needs to analyze the current EBS volume cost and to recommend optimizations. The recommendations n...
To analyze current EBS volume costs and recommend optimizations along with estimated monthly savings, let's evaluate each of the provided options based on their purpose and relevance.
Option A: Use Amazon Inspector reporting to generate EBS volume recommendations for optimization.
- Explanation: Amazon Inspector is a security assessment service, which is used to automatically assess applications for vulnerabilities and deviations from best practices in security. It does not specifically provide recommendations or analysis for optimizing EBS volumes or cost.
- Why it’s rejected: Since the objective is to analyze EBS volume costs and optimization opportunities, Amazon Inspector is not the right tool because it focuses on security rather than cost or performance optimization.
Option B: Use AWS Systems Manager reporting to determine EBS volume recommendations for optimization.
- Explanation: AWS Systems Manager is a suite of tools for managing and automating various aspects of AWS resources. While Systems Manager provides valuable insights into resource management, it does not specialize in offering direct EBS volume cost or optimization recommendations.
- Why it’s rejected: AWS Systems Manager can help with operations and monitoring but does not specifically offer detailed recommendations related to EBS cost optimization. It is more useful for managing EC2 instances, patching, and automation.
Option C: Use Amazon CloudWatch metrics reporting to determine EBS volume recommendations for optimization.
- Explanation: Amazon CloudWatch provides monitoring and observability of AWS resources, including EC2 and EBS. It can monitor EBS performance metrics (e.g...
Author: Chloe · Last updated Jul 12, 2026
A global company runs its workloads on AWS. The company's application uses Amazon S3 buckets across AWS Regions for sensitive data storage and analysis. The company stores millions of objects in multiple S3 buckets daily. The company wants to...
To identify all S3 buckets that are not versioning-enabled across multiple regions, let's analyze each of the provided solutions and determine which one best fits the requirements.
Option A: Use Amazon S3 Storage Lens to identify all S3 buckets that are not versioning-enabled across Regions.
- Explanation: Amazon S3 Storage Lens provides a comprehensive analytics service for monitoring and understanding S3 storage usage and activity. It can provide insights into S3 bucket configurations, including whether versioning is enabled or not across all S3 buckets in an AWS account, across multiple regions.
- Why it’s suitable: S3 Storage Lens can specifically analyze bucket configurations like versioning, making it a direct and scalable solution for identifying buckets that aren't versioning-enabled. It works across AWS Regions and can be used to aggregate data from multiple buckets for easier reporting and identification.
- Why other options are rejected:
- Option B: IAM Access Analyzer for S3 is used to analyz...
Author: Abigail · Last updated Jul 12, 2026
A company wants to enhance its ecommerce order-processing application that is deployed on AWS. The application must process each order exactly once without affecting the customer experience d...
To determine which solution best meets the requirements for processing ecommerce orders exactly once while ensuring customer experience is not impacted during unpredictable traffic surges, let’s analyze each of the provided options based on the following key criteria:
1. Exactly Once Processing: The solution must guarantee that each order is processed exactly once, even during traffic spikes.
2. Scalability: The solution should scale automatically to handle unpredictable traffic surges without degrading performance.
3. Impact on Customer Experience: The solution must not interfere with the customer-facing aspects of the ecommerce application.
Option A: Create an Amazon Simple Queue Service (Amazon SQS) FIFO queue. Put all the orders in the SQS queue. Configure an AWS Lambda function as the target to process the orders.
- Explanation: Amazon SQS FIFO (First-In-First-Out) queues provide exactly once message processing and guarantee the order in which messages are processed. By using a FIFO queue, you can ensure that orders are processed exactly once and in the order they are received. The AWS Lambda function can scale automatically to process messages as they come in, making it suitable for handling traffic surges without affecting the customer experience.
- Why it’s suitable: SQS FIFO queues ensure exactly-once processing and maintain the order of messages, which is critical for order processing. The Lambda function can scale a...
Author: FlamePhoenix2025 · Last updated Jul 12, 2026
A company has two AWS accounts: Production and Development. The company needs to push code changes in the Development account to the Production account. In the alpha phase, only two senior developers on the development team need access to the Production account. In t...
To determine which solution will best meet the requirements of pushing code changes from the Development account to the Production account, and controlling access for developers in different phases, let’s evaluate each option based on the following criteria:
Key Requirements:
1. Access control for senior developers in the alpha phase.
2. Scalability of access for more developers in the beta phase.
3. Separation of duties between the Development and Production accounts.
4. Least privilege access.
Option A: Create two policy documents by using the AWS Management Console in each account. Assign the policy to developers who need access.
- Explanation: This option suggests creating two policies, one in each account, and assigning them directly to developers who need access. However, this solution does not specify how the developers in the Development account will securely access resources in the Production account.
- Why it’s rejected: The option is not ideal for cross-account access between two AWS accounts. While it could work for users in a single account, it does not facilitate controlled access between separate accounts (Development and Production) and does not scale well when more developers need access in the beta phase. Managing access through direct policy assignment also becomes cumbersome as the number of developers increases.
Option B: Create an IAM role in the Development account. Grant the IAM role access to the Production account. Allow developers to assume the role.
- Explanation: This solution suggests creating an IAM role in the Development account, granting that role access to resources in the Production account, and allowing developers to assume that role. However, this approach does not make use of the Production account’s security features to restrict access properly. It's generally better practice to define roles in the Production account to limit access from outside sources like Development.
- Why it’s rejected: This approach might lead to security concerns, as it could potentially allow too much access from the Development account and might not fit well for a controlled, least-privilege access model between accounts.
Option C: Create an IAM role in the Production account. Define a trust policy that specifies the Development account. Allow developers to assume the role.
- Explanation: This option creates an IAM role in the Production account and defines a trust policy tha...
Author: Ava · Last updated Jul 12, 2026
A company wants to restrict access to the content of its web application. The company needs to protect the content by using authorization techniques that are available on AWS. The company also wants to implement a serverless architecture for authorization and authentication that has low login latency.
The solution must integrate with the web application and serve web content globa...
To determine the most appropriate solution, let's evaluate each option against the key requirements:
Key Requirements:
1. Authentication and Authorization: The company needs to protect its content using authorization techniques on AWS.
2. Serverless Architecture: The solution should be serverless, so no infrastructure management is required.
3. Low Latency: The solution must provide low login latency.
4. Global Reach: The solution should serve web content globally and handle potentially increasing traffic as the user base grows.
A) Configure Amazon Cognito for authentication. Implement Lambda@Edge for authorization. Configure Amazon CloudFront to serve the web application globally.
- Authentication: Amazon Cognito is an excellent choice for authentication, as it is a fully managed service that allows easy integration for web applications and supports OAuth, SAML, and social logins.
- Authorization: Lambda@Edge allows for serverless authorization logic to be executed at AWS locations globally, ensuring low latency for authentication checks.
- Global Content Delivery: Amazon CloudFront is a global Content Delivery Network (CDN) that can distribute web content with low latency to users worldwide.
- Serverless and Scalable: This solution is serverless, as both Cognito and Lambda@Edge are fully managed services, and CloudFront handles content delivery globally with low overhead.
- Why not others: This solution is ideal because it uses fully managed services that scale well, and it ensures low-latency authentication and authorization with global content delivery.
B) Configure AWS Directory Service for Microsoft Active Directory for authentication. Implement AWS Lambda for authorization. Use an Application Load Balancer to serve the web application globally.
- Authentication: AWS Directory Service (Microsoft AD) is suitable for enterprises needing Active Directory integration but can be more complex to manage and less suited for scalable, serverless web applications.
- Authorization: AWS Lambda is a good choice for serverless authorization, but the use of AWS Directory Service requires additional management and complexity.
- Global Content Delivery: An Application Load Balancer (ALB) can distribute traffic but lacks the global distribution capabilities of CloudFront, leading to potential higher latency.
- Why not others: While ALB can s...
Author: Vivaan · Last updated Jul 12, 2026
A development team uses multiple AWS accounts for its development, staging, and production environments. Team members have been launching large Amazon EC2 instances that are underutilized. A solutions architect must prevent large instances from being launched...
To determine the most effective solution to prevent the launch of large EC2 instances across multiple AWS accounts, let's analyze each option based on key factors like ease of implementation, operational overhead, scalability, and effectiveness:
Key Requirements:
- Prevent large EC2 instances from being launched across multiple AWS accounts.
- Minimize operational overhead.
- Implement the solution globally across all environments (development, staging, production).
A) Update the IAM policies to deny the launch of large EC2 instances. Apply the policies to all users.
- IAM Policies: While updating IAM policies to deny the launch of large EC2 instances is an option, IAM policies are typically user-specific. Applying these policies to every user in every account could lead to complexity as the number of users and permissions increases.
- Operational Overhead: Managing IAM policies across multiple accounts can become cumbersome as users and roles increase. Additionally, IAM policies are not centralized when managing multiple AWS accounts.
- Why not: This solution would require manually updating policies for each user, which creates unnecessary operational overhead and does not scale well as the number of accounts grows.
B) Define a resource in AWS Resource Access Manager that prevents the launch of large EC2 instances.
- AWS Resource Access Manager (RAM): RAM is typically used to share resources like VPCs, subnets, and other resources across AWS accounts. However, it is not designed to enforce restrictions like preventing the launch of specific EC2 instances.
- Why not: RAM cannot be used for policy enforcement in this case, as its primary use is for resource sharing rather than controlling permissions or actions like launching EC2 instances.
C) Create an IAM role in each account that denies the launch of large EC2 instances. Grant the developers IAM group access to the role.
- IAM Roles: This would require creating individual IAM roles in each account and then assigning the appropriate permissions t...
Author: Layla · Last updated Jul 12, 2026
A company has migrated a fleet of hundreds of on-premises virtual machines (VMs) to Amazon EC2 instances. The instances run a diverse fleet of Windows Server versions along with several Linux distributions. The company wants a solution that will automate inventory and updates of the operating systems. The company also needs a summary o...
To determine the most appropriate solution for automating inventory, updates, and vulnerability reviews of the operating systems across hundreds of EC2 instances, let's break down the options based on the specific requirements:
Key Requirements:
1. Automate inventory and updates for both Windows and Linux operating systems.
2. Summary of common vulnerabilities for monthly reviews.
3. Ensure minimal operational overhead while meeting compliance and security needs.
A) Set up AWS Systems Manager Patch Manager to manage all the EC2 instances. Configure AWS Security Hub to produce monthly reports.
- Systems Manager Patch Manager: This is a good choice for automating the patching process of both Windows and Linux instances. It can help apply patches, and track their status across EC2 instances, which addresses the need for automatic updates.
- AWS Security Hub: Security Hub aggregates security findings from various services like Amazon GuardDuty, AWS Config, and Inspector. While it provides useful insights into security posture, it doesn’t focus specifically on vulnerabilities or patch management for operating systems.
- Why not: While this option addresses the patching and reporting needs, Security Hub isn't specialized in vulnerability scanning for operating systems and would require additional services (like Amazon Inspector) to provide detailed vulnerability summaries.
B) Set up AWS Systems Manager Patch Manager to manage all the EC2 instances. Deploy Amazon Inspector, and configure monthly reports.
- Systems Manager Patch Manager: This is a strong choice for automating OS patch management, both for Windows and Linux instances.
- Amazon Inspector: Amazon Inspector performs vulnerability assessments and provides detailed findings about the security posture of your EC2 instances. This directly meets the requirement for a monthly review of vulnerabilities.
- Why selected: This solution addresses all the key requirements: automated patching (via Patch Manager), vulnerability scanning and assessment (via Amazon Inspector), and a...
Author: Ethan Smith · Last updated Jul 12, 2026
A company hosts its application in the AWS Cloud. The application runs on Amazon EC2 instances in an Auto Scaling group behind an Elastic Load Balancing (ELB) load balancer. The application connects to an Amazon DynamoDB table.
For disaster recovery (DR) purposes, the company wants to ensure that the applicat...
To determine the best solution for ensuring minimal downtime in the event of a disaster recovery (DR) scenario, let's evaluate the options based on key factors like availability, downtime, automation, and complexity.
Key Requirements:
1. Disaster Recovery (DR) with minimal downtime: The solution should ensure the application can failover to another AWS Region with minimal downtime.
2. Global Availability of Data: The DynamoDB table should be accessible across regions with minimal latency.
3. Automated Failover: The solution should automatically reroute traffic to the DR region with minimal manual intervention.
A) Create an Auto Scaling group and an ELB in the DR Region. Configure the DynamoDB table as a global table. Configure DNS failover to point to the new DR Region's ELB.
- Auto Scaling Group and ELB in DR Region: Creating an Auto Scaling group and an ELB in the DR region ensures that the application can scale and handle traffic in the DR region.
- Global DynamoDB Table: Configuring DynamoDB as a global table ensures that the data is automatically replicated across regions, which allows for seamless access to the data in the DR region without downtime.
- DNS Failover: Using DNS failover (with Amazon Route 53) allows automatic redirection of traffic to the DR region’s ELB when needed.
- Why selected: This solution provides the least downtime by automatically failing over to the DR region using global tables for DynamoDB and automated DNS failover. It minimizes the impact of a disaster by keeping both the application and data in sync and ready for immediate failover.
B) Create an AWS CloudFormation template to create EC2 instances, ELBs, and DynamoDB tables to be launched when necessary. Configure DNS failover to point to the new DR Region's ELB.
- CloudFormation Template: While this approach allows for creating resources in the DR region, it requires manual intervention to trigger the CloudFormation stack to launch the resources when necessary. This adds operational complexity and downtime during the recovery process, as resources won’t be available until the stack is launched and configured.
- DynamoDB Table: The DynamoDB table is not set up as a global table, which means the data wouldn’t be automatically available in the DR region.
- Why not: The recovery...
Author: Olivia · Last updated Jul 12, 2026
A company runs an application on Amazon EC2 instances in a private subnet. The application needs to store and retrieve data in Amazon S3 buckets. According to regulatory requirements, the data must not travel across the public i...
To determine the most cost-effective solution that ensures compliance with the requirement that data does not travel across the public internet when stored in Amazon S3, let's evaluate each option:
Key Requirements:
1. Private Subnet: The EC2 instances are located in a private subnet, meaning they cannot directly access the public internet.
2. Data Compliance: The application must store and retrieve data from S3 without the data traveling over the public internet.
3. Cost-effectiveness: The solution should meet the requirement with minimal operational cost.
A) Deploy a NAT gateway to access the S3 buckets.
- NAT Gateway: A NAT gateway enables instances in a private subnet to access the internet, including S3. However, this would route traffic over the public internet, which violates the regulatory requirement that data should not travel across the public internet.
- Why not: Using a NAT gateway doesn’t meet the requirement since it routes data over the public internet, which violates the regulatory constraint.
B) Deploy AWS Storage Gateway to access the S3 buckets.
- AWS Storage Gateway: This service provides hybrid cloud storage integration between on-premises environments and Amazon S3. While it allows access to S3, it is designed primarily for on-premises-to-cloud storage integration and not specifically for EC2 instances in a VPC.
- Why not: This option is more suited for on-premises environments that need to access cloud storage. It is more complex and expensive compared to a solution designed to work directly within the VPC, like an S3 endpoint.
...
Author: SolarFalcon11 · Last updated Jul 12, 2026
A company hosts an application on Amazon EC2 instances that run in a single Availability Zone. The application is accessible by using the transport layer of the Open Systems Interconnection (OSI) model. The company needs the application architecture to have hi...
To meet the high availability requirements for the application, the company needs to ensure the application is not tied to a single Availability Zone, and that traffic can be distributed across instances while maintaining fault tolerance and scalability. Let's evaluate each option and its relevance:
Option A: Configure new EC2 instances in a different Availability Zone. Use Amazon Route 53 to route traffic to all instances.
- Explanation: This approach spreads the application across multiple Availability Zones, which increases fault tolerance. By using Amazon Route 53, traffic can be routed across these instances based on health checks, enhancing availability. However, Route 53 is not an ideal load balancer for managing real-time traffic distribution (especially TCP traffic), and it requires more manual configuration than a load balancer.
- Rejected because: While this increases high availability, it doesn't provide automatic scaling or load balancing, which would be beneficial in maintaining the application's performance and uptime under varying loads.
Option B: Configure a Network Load Balancer in front of the EC2 instances.
- Explanation: A Network Load Balancer (NLB) distributes traffic across EC2 instances, offering fault tolerance for TCP-based applications. It can automatically handle traffic spikes and route traffic to healthy instances, improving high availability.
- Selected because: The NLB is efficient for distributing TCP traffic, which aligns with the company’s requirement to ensure high availability at the transport layer (OSI model). It offers better fault tolerance and load balancing than Route 53 alone.
Option C: Configure a Network Load Balancer for TCP traffic to the instances. Configure an Application Load Balancer for HTTP and HTTPS traffic to the instances.
- Explanation: This approach uses both NLB for TCP and Application Load Balancer (ALB) for HTTP/HTTPS. It provides fine-grained control over traffic based on the protocol type but adds complexity.
- Rejected because: While this is a comprehensive solution, it introduces unnecessary complexity wh...
Author: Emma · Last updated Jul 12, 2026
A company uses Amazon S3 to host its static website. The company wants to add a contact form to the webpage. The contact form will have dynamic server-side components for users to input their name, email address, phone number, and user message.
The company expects fewer than 100 site visits each month. The contact form...
To determine the most cost-effective solution, we need to consider the following factors:
- Cost: The solution should be affordable, particularly given that the company expects fewer than 100 site visits each month.
- Ease of implementation: The solution should be simple and quick to set up.
- Scalability: Although the company expects a low number of site visits, the solution should be able to scale if the traffic increases.
- Server-side components: The contact form requires dynamic behavior, which necessitates server-side components like processing form submissions and sending notifications.
Now, let’s analyze each option:
Option A: Host the dynamic contact form in Amazon Elastic Container Service (Amazon ECS). Set up Amazon Simple Email Service (Amazon SES) to connect to a third-party email provider.
- Explanation: Hosting the contact form in ECS introduces unnecessary complexity and cost for a small-scale use case like this. ECS is typically suited for containerized applications with more complex scaling requirements, which is overkill for a low-traffic, simple contact form. Integrating Amazon SES with a third-party email provider adds additional complexity, and SES is designed more for sending bulk emails rather than for simple form submissions.
- Rejected because: It introduces unnecessary infrastructure (ECS) and complexity when a simpler, cheaper solution would work.
Option B: Create an Amazon API Gateway endpoint that returns the contact form from an AWS Lambda function. Configure another Lambda function on the API Gateway to publish a message to an Amazon Simple Notification Service (Amazon SNS) topic.
- Explanation: This is a highly scalable, serverless approach that involves using Amazon API Gateway, AWS Lambda, and SNS. The API Gateway serves the contact form dynamically, and Lambda handles form submissions and sends an email notification via SNS. Given the low volume of traffic (fewer than 100 visits per month), this is a cost-effective and scalable solution because Lambda charges only for the compute time used, and SNS offers a pay-per-use model as well.
- Selected because: This solution leverages AWS serverless technologies that are inexpensive, scalable, and simple to set up. It requires minima...
Author: Zara1234 · Last updated Jul 12, 2026
A company creates dedicated AWS accounts in AWS Organizations for its business units. Recently, an important notification was sent to the root user email address of a business unit account instead of the assigned account owner. The company wants to ensure that all future notifications can be sent to different employee...
To meet the company's requirements of sending notifications to different employees based on categories (billing, operations, or security), we need a solution that ensures the right people receive notifications securely and in an organized way. Let's evaluate each option:
Option A: Configure each AWS account to use a single email address that the company manages. Ensure that all account owners can access the email account to receive notifications. Configure alternate contacts for each AWS account with corresponding distribution lists for the billing team, the security team, and the operations team for each business unit.
- Explanation: This approach involves a shared email address for all account owners to receive notifications, which could be risky in terms of security, as multiple users would have access to a common account. However, alternate contacts for billing, security, and operations are correctly defined, which is good for organization.
- Rejected because: Using a single shared email address for all account owners reduces security by giving many people access to sensitive notifications. It's also not ideal for tracking specific notifications for each category (billing, security, operations) and could lead to confusion or oversight.
Option B: Configure each AWS account to use a different email distribution list for each business unit that the company manages. Configure each distribution list with administrator email addresses that can respond to alerts. Configure alternate contacts for each AWS account with corresponding distribution lists for the billing team, the security team, and the operations team for each business unit.
- Explanation: This option suggests using different email distribution lists for each business unit, which could work well for organizing the recipients of notifications. Distribution lists for each category (billing, security, operations) are clearly defined and can route notifications to the right team members.
- Selected because: This approach is secure, as it uses distribution lists to manage notifications rather than shared email addresses. It also allows proper segregation of notification types (billing, security, operations) to the appropriate teams, ensuring that the right people are notified securely. The use of administrator email addresses within the distribution lists is also practical for responding to alerts.
Option...
Author: Evelyn · Last updated Jul 12, 2026
A company runs an ecommerce application on AWS. Amazon EC2 instances process purchases and store the purchase details in an Amazon Aurora PostgreSQL DB cluster.
Customers are experiencing application timeouts during times of peak usage. A solutions architect needs to rearchitect the application so that the applicati...
To meet the requirements of scaling the application to handle peak usage and avoid timeouts during high traffic periods, the company needs a combination of scalable compute resources and mechanisms to better handle database traffic. Let's evaluate each option based on the context and key factors:
Option A: Configure an Auto Scaling group of new EC2 instances to retry the purchases until the processing is complete. Update the applications to connect to the DB cluster by using Amazon RDS Proxy.
- Explanation: An Auto Scaling group for EC2 instances can help scale out compute resources during peak times. RDS Proxy is a connection pooler for Amazon RDS (including Aurora), which improves database performance by managing a pool of database connections and reducing the connection overhead. This can significantly reduce timeouts caused by database connection limits.
- Selected because: Using an Auto Scaling group ensures that the application can scale dynamically based on demand, while RDS Proxy optimizes database connections, both addressing the peak usage and improving reliability without changing the fundamental application structure. This is cost-effective because Auto Scaling only uses resources as needed, and RDS Proxy can lower database connection overhead.
Option B: Configure the application to use an Amazon ElastiCache cluster in front of the Aurora PostgreSQL DB cluster.
- Explanation: ElastiCache is a caching service that can improve performance by caching frequently accessed data, which reduces the load on the database. However, ElastiCache does not directly address the issue of scaling compute capacity or reducing database connection contention during peak traffic times.
- Rejected because: While ElastiCache could improve performance, it doesn't address the underlying issue of the application and database handling high concurrency during peak traffic. It’s a useful optimization but not the primary solution to avoid timeouts during heavy load.
Option C: Update the application to send the purchase requests to an Amazon Simple Queue Service (Amazon SQS) queue. Configure an Auto Scaling group of new EC2 instances that read from the SQS queue.
- Explanation: Using SQS as a buffer allows the application to decouple the purchase request processing from the user-facing interface. By storing requests in the queue, the system can handle bursts of traffic ...
Author: RadiantPhoenixX · Last updated Jul 12, 2026
A company that uses AWS Organizations runs 150 applications across 30 different AWS accounts. The company used AWS Cost and Usage Report to create a new report in the management account. The report is delivered to an Amazon S3 bucket that is replicated to a bucket in the data collection account.
The company's senior leadership wants to view a cu...
To meet the senior leadership's requirements of viewing a custom dashboard that provides NAT gateway costs daily from the beginning of the current month, we need to evaluate the options based on how each tool can query the data efficiently and how they fit within the AWS ecosystem for reporting and dashboarding. Let's analyze each option:
Option A: Share an Amazon QuickSight dashboard that includes the requested table visual. Configure QuickSight to use AWS DataSync to query the new report.
- Explanation: Amazon QuickSight is a business intelligence (BI) service that enables you to create and share visualizations and dashboards. However, AWS DataSync is designed for transferring large amounts of data between on-premises storage and AWS services, and it's not typically used to query reports. QuickSight generally queries data using data sources like Amazon S3, Redshift, or Athena, not AWS DataSync.
- Rejected because: AWS DataSync is not the appropriate service to query data for reporting purposes. QuickSight requires integration with services like Athena, not DataSync.
Option B: Share an Amazon QuickSight dashboard that includes the requested table visual. Configure QuickSight to use Amazon Athena to query the new report.
- Explanation: Amazon Athena is a serverless interactive query service that makes it easy to analyze data in Amazon S3 using standard SQL. By configuring Athena to query the AWS Cost and Usage Report (which is stored in S3), QuickSight can visualize the queried data and create custom dashboards. This setup is a typical and cost-effective solution for analyzing and visualizing large datasets from S3.
- Selected because: Athena is the ideal tool for querying large datasets like AWS Cost and Usage Reports stored in S3, and QuickSight can then create and share custom dashboards based on that data. This approach is highly scalable, cost-effective, and well-suited to the requirement.
...
Author: Ethan · Last updated Jul 12, 2026
A company is hosting a high-traffic static website on Amazon S3 with an Amazon CloudFront distribution that has a default TTL of 0 seconds. The company wants to implement caching to improve performance for the website. However, the company also wants to ensure that stale content is not served for more than a few minutes a...
To meet the requirements of caching content while ensuring that stale content is not served for more than a few minutes after a deployment, we need to balance performance (caching) with the need to quickly refresh content after changes. Let's evaluate the options one by one:
A) Set the CloudFront default TTL to 2 minutes.
- Reasoning: Setting a TTL of 2 minutes in CloudFront ensures that the cache will expire every 2 minutes, meaning that CloudFront will revalidate content regularly. This approach gives a balance between serving cached content and fetching fresh content from the origin server after deployment. A 2-minute TTL would be fast enough to ensure that new content is fetched in a timely manner after a deployment.
- Why it works: This choice aligns with the need to serve fresh content while still benefiting from caching. Content will be refreshed every 2 minutes, which satisfies the requirement that stale content is not served for more than a few minutes.
B) Set a default TTL of 2 minutes on the S3 bucket.
- Reasoning: Amazon S3 itself does not have a direct mechanism to set TTLs on objects in the same way that CloudFront does. S3 can manage metadata for caching, but the TTL is primarily managed at the CloudFront level, not at S3. This option would not have the desired impact because TTL needs to be configured on the CloudFront distribution, not on S3.
- Why it's rejected: S3 by itself cannot directly control caching behavior for CloudFront beyond providing caching headers or metadata. This option would not address the TTL needs as effectively as CloudFront configuration.
C) Add a Cache-Control private directive to the objects in Amazon S3.
- Reasoning: A `Cache-Control: private` directive indicates that content is specific to a user and should not be cached by shared caches (like CloudFront). This would effectively prevent CloudFront from caching the objects, which directly conflicts with the goal of improving performance by caching content.
- Why it's rejected: The `private` directive would prevent CloudFront from caching the objects, leading ...
Author: Alexander · Last updated Jul 12, 2026
A company runs its application by using Amazon EC2 instances and AWS Lambda functions. The EC2 instances run in private subnets of a VPC. The Lambda functions need direct network access to the EC2 instances for the application to work.
The application will run for 1 year. The number of Lambda functions that the application uses will...
Let's evaluate the options one by one and consider the key factors such as minimizing costs, ensuring the Lambda functions can access the EC2 instances, and meeting the network access requirements.
A) Purchase an EC2 Instance Savings Plan. Connect the Lambda functions to the private subnets that contain the EC2 instances.
- Reasoning: An EC2 Instance Savings Plan is intended for customers who have predictable workloads using EC2 instances. However, the company needs to connect AWS Lambda to EC2 instances, which are in private subnets. While EC2 Savings Plans offer cost savings for EC2 instances, it doesn't directly address the Lambda cost or how Lambda interacts with private subnets.
- Why it's rejected: Lambda functions do not run on EC2 instances directly and are not directly associated with EC2 Instance Savings Plans. Additionally, Lambda functions in private subnets might require additional networking configurations, and this solution doesn't specifically address Lambda pricing optimization. It’s more relevant for EC2-related costs, which is not the primary goal here.
B) Purchase an EC2 Instance Savings Plan. Connect the Lambda functions to new public subnets in the same VPC where the EC2 instances run.
- Reasoning: The goal is to ensure that the Lambda functions can communicate with the EC2 instances, which are in private subnets. If you place Lambda in public subnets, you would need to configure NAT gateways or Internet access, which could increase costs and complexity, as well as introduce potential security risks.
- Why it's rejected: Placing Lambda in public subnets with a NAT Gateway would introduce unnecessary additional costs for data transfer and other associated charges. Also, it doesn't directly address Lambda-specific cost savings or the need for Lambda to access EC2 instances securely within private subnets.
C) Purchas...
Author: Elijah · Last updated Jul 12, 2026
A company has deployed a multi-account strategy on AWS by using AWS Control Tower. The company has provided individual AWS accounts to each of its developers. The company wants to implement controls to limit AWS resource costs that the...
Let's evaluate the options one by one based on minimizing operational overhead and providing a solution that can effectively limit resource costs for developers:
A) Instruct each developer to tag all their resources with a tag that has a key of CostCenter and a value of the developer's name. Use the required-tags AWS Config managed rule to check for the tag. Create an AWS Lambda function to terminate resources that do not have the tag. Configure AWS Cost Explorer to send a daily report to each developer to monitor their spending.
- Reasoning: This approach requires developers to manually tag their resources, which could be error-prone and inconsistent over time. The Lambda function that terminates untagged resources adds operational complexity and overhead. While AWS Config and Lambda functions can enforce some level of automation, they would require ongoing maintenance and monitoring, which increases operational overhead.
- Why it's rejected: The manual tagging process, the need for Lambda functions to terminate resources, and the need to continuously manage and monitor the setup increases complexity and operational overhead. It doesn't provide a scalable or automated way to limit costs.
B) Use AWS Budgets to establish budgets for each developer account. Set up budget alerts for actual and forecast values to notify developers when they exceed or expect to exceed their assigned budget. Use AWS Budgets actions to apply a DenyAll policy to the developer's IAM role to prevent additional resources from being launched when the assigned budget is reached.
- Reasoning: AWS Budgets is an excellent tool for controlling costs by setting spending limits. Using AWS Budgets actions to apply a DenyAll policy when the budget is exceeded is an effective way to enforce cost controls. Budget alerts keep developers informed about their spending. This solution directly addresses cost control, is automated, and does not require manual intervention.
- Why it works: This approach minimizes operational overhead while effectively controlling costs. AWS Budgets is designed to handle cost management across multiple accounts, and using IAM policies to prevent resource launches when budgets are exceeded is a clean and automated solution. This...
Author: Madison · Last updated Jul 12, 2026
A solutions architect is designing a three-tier web application. The architecture consists of an internet-facing Application Load Balancer (ALB) and a web tier that is hosted on Amazon EC2 instances in private subnets. The application tier with the business logic runs on EC2 instances in private subnets. The database tier consists of Microsoft SQL Server that runs on EC2 instances in ...
Let's break down each option and evaluate its suitability based on the requirements for security, correct network traffic flow, and the design of the three-tier architecture.
A) Configure the security group for the web tier to allow inbound HTTPS traffic from the security group for the ALB.
- Reasoning: The web tier EC2 instances should only accept inbound HTTPS traffic from the Application Load Balancer (ALB) to ensure that traffic is properly routed and secured from the internet. The ALB handles public-facing requests and forwards them to the web tier instances. By allowing inbound HTTPS traffic from the ALB's security group, you limit exposure to just traffic from the load balancer, which minimizes security risks.
- Why it works: This configuration ensures that only traffic from the ALB (and not directly from the internet) reaches the web tier, improving security and traffic flow.
B) Configure the security group for the web tier to allow outbound HTTPS traffic to 0.0.0.0/0.
- Reasoning: The web tier EC2 instances may need to access external services (such as updates, third-party APIs, or resources) over HTTPS. Configuring outbound HTTPS traffic to `0.0.0.0/0` is necessary for this, as it allows the web instances to access external services securely.
- Why it works: This allows the web tier to make HTTPS requests to any external IP address, ensuring that the web tier can reach the internet if needed. However, you should monitor outbound traffic closely to ensure it's strictly necessary and avoid any security issues.
C) Configure the security group for the database tier to allow inbound Microsoft SQL Server traffic from the security group for the application tier.
- Reasoning: The application tier EC2 instances interact with the database tier (Microsoft SQL Server) to fetch or store data. Therefore, the security group for the database tier should allow inbound Microsoft SQL Server traffic (typically TCP port 1433) from the application tier's security group. This ensures that only the application tier can communicate with the database, preventing unauthorized access.
- Why it works: This configuration enforces a principle of least privilege by allowing only the application tier to access the database, while blocking access from any other tier or external sources.
D) Configure the security group for the database tier to allow outbound HTTPS traffic and Microsoft SQL Server traffic to the security group for the web tier.
- Reasoning: The database tier does not need to initiate HTTPS or SQL Server tra...
Author: Olivia · Last updated Jul 12, 2026
A company has released a new version of its production application. The company's workload uses Amazon EC2, AWS Lambda, AWS Fargate, and Amazon SageMaker.
The company wants to cost optimize the workload now that usage is at a steady state. The company wants to cover the most s...
To meet the requirements of cost optimization across multiple services with the fewest savings plans, we need to consider which savings plans cover the services effectively and ensure flexibility and cost savings.
Option Analysis:
A) Purchase an EC2 Instance Savings Plan for Amazon EC2 and SageMaker.
- Reasoning: The EC2 Instance Savings Plan specifically applies to EC2 instance usage. However, it does not cover AWS Lambda or AWS Fargate, which are key components of the workload. Additionally, SageMaker does not benefit from EC2 Instance Savings Plans directly; SageMaker has its own savings plan type.
- Why it's rejected: This plan doesn't cover Lambda or Fargate, and it’s not optimal for SageMaker, which has its own savings plan. The coverage is limited, leading to the need for multiple savings plans.
B) Purchase a Compute Savings Plan for Amazon EC2, Lambda, and SageMaker.
- Reasoning: The Compute Savings Plan is flexible and applies to a wide range of compute services, including EC2, Lambda, and SageMaker. This plan is highly effective because it covers multiple services in one plan, providing cost optimization without requiring multiple savings plans.
- Why it works: This option is ideal because it covers EC2, Lambda, and SageMaker under a single savings plan. Since these are key services used in the workload, the Compute Savings Plan provides broad coverage and reduces the need for multiple separate savings plans.
C) Purchase a SageMaker Savings Plan.
- Reasoning: The SageMaker Savings Plan is specific to SageMaker, which is a machine learning service. While this is a targeted and effective savings plan for SageMaker usage, it does not cover EC2, Lambda, or Fargate. Therefore, it is not a good fit for the broader workload that involves more serv...
Author: Suresh · Last updated Jul 12, 2026
A company uses a Microsoft SQL Server database. The company's applications are connected to the database. The company wants to migrate to an Amazon Aurora PostgreSQL database with minimal changes to the ap...
When migrating from Microsoft SQL Server to an Amazon Aurora PostgreSQL database with minimal changes to the application code, we must consider the compatibility of SQL Server’s T-SQL syntax with PostgreSQL and the potential changes needed to the application code.
Let's analyze each option:
1. A) Use the AWS Schema Conversion Tool (AWS SCT) to rewrite the SQL queries in the applications.
- The AWS Schema Conversion Tool (SCT) helps with migrating database schema but does not rewrite SQL queries in the applications. It primarily assists in converting the database schema and objects (like tables, indexes, etc.) from one database engine to another.
- Rejection: This option doesn’t directly address rewriting application SQL queries. It only helps with schema and data migration.
2. B) Enable Babelfish on Aurora PostgreSQL to run the SQL queries from the applications.
- Babelfish for Aurora PostgreSQL is designed to help migrate applications from SQL Server to Aurora PostgreSQL without requiring significant changes in the application code. Babelfish allows Aurora PostgreSQL to understand T-SQL queries, making it compatible with SQL Server syntax. This option would allow the application to keep using SQL Server-style queries while accessing the Aurora PostgreSQL database.
- Acceptance: Babelfish is a key feature for this scenario as it allows the application to continue using SQL Server queries without modification. This minimizes the effort required to migrate the application code.
3. C) Migrate the database schema and data by using the AWS Schema Conversion Tool (AWS SCT) and AWS Database Migration Service (AWS DMS).
- AWS SCT can help migrate the schema and database objects, while AWS DMS is used to migrate the actual data. However, neither AWS SCT nor DMS will assist in handling SQL query translation or enable compatibility for SQL Server syntax in PostgreSQL.
- Rejection: Although this is part of the migration process (for schema and data), it doesn't directly add...
Author: Ava · Last updated Jul 12, 2026
A company plans to rehost an application to Amazon EC2 instances that use Amazon Elastic Block Store (Amazon EBS) as the attached storage.
A solutions architect must design a solution to ensure that all newly created Amazon EBS volumes are encrypted by default. The...
Objective:
The goal is to ensure that all newly created Amazon EBS volumes are encrypted by default and to prevent the creation of unencrypted EBS volumes.
Let's analyze each option:
1. A) Configure the EC2 account attributes to always encrypt new EBS volumes.
- Explanation: Amazon EC2 provides the ability to set account-wide defaults for EBS volume encryption. By configuring the EC2 account attributes, you can ensure that any newly created EBS volumes are encrypted by default, using either the AWS managed key (aws/ebs) or a custom key.
- Acceptance: This is a direct solution to the requirement. It ensures that all EBS volumes created in the account are encrypted by default, which is exactly what the company needs.
- Reasoning: This option is the most efficient and straightforward way to ensure that all EBS volumes are encrypted by default, and it also prevents the creation of unencrypted volumes.
2. B) Use AWS Config. Configure the encrypted-volumes identifier. Apply the default AWS Key Management Service (AWS KMS) key.
- Explanation: AWS Config is a service that provides configuration monitoring and compliance auditing, and it can be used to track whether resources (including EBS volumes) are encrypted. However, it does not enforce encryption settings. It can flag non-compliance but does not prevent the creation of unencrypted volumes by default.
- Rejection: While this option can help in identifying and auditing non-compliant resources, it does not automatically enforce encryption or prevent unencrypted volumes from being created. It's more of a monitoring solution than an enforcement mechanism.
3. C) Configure AWS Systems Manager to create encrypted copies of the EBS volumes. Reconfigure the EC2 instances to use the encrypted volumes.
- Explanation: This option involves using AWS Systems Manager to create encrypted copies of existing EBS volumes, then manually reconfiguring EC2 instances to u...
Author: Isabella · Last updated Jul 12, 2026
An ecommerce company wants to collect user clickstream data from the company's website for real-time analysis. The website experiences fluctuating traffic patterns throughout the day. The company needs a scalable soluti...
Objective:
The goal is to collect user clickstream data from the company’s website in real-time for analysis, and the solution must be scalable to handle fluctuating traffic patterns throughout the day.
Let's break down the options:
A) Use a data stream in Amazon Kinesis Data Streams in on-demand mode to capture the clickstream data. Use AWS Lambda to process the data in real time.
- Explanation:
- Amazon Kinesis Data Streams in on-demand mode is a scalable, real-time data streaming service that can handle fluctuating traffic patterns by automatically scaling the number of shards.
- AWS Lambda can be used to process the data in real time as it integrates seamlessly with Kinesis. Lambda scales automatically, making it ideal for variable workloads.
- Acceptance: This solution is well-suited for real-time, scalable processing of fluctuating clickstream data. It’s flexible, easy to use, and adapts to changes in traffic without requiring manual intervention.
- Reasoning: Kinesis Data Streams in on-demand mode will scale based on the incoming volume of data, and Lambda can scale to handle real-time data processing. This combination addresses both scalability and real-time processing needs.
B) Use Amazon Kinesis Data Firehose to capture the clickstream data. Use AWS Glue to process the data in real time.
- Explanation:
- Amazon Kinesis Data Firehose is primarily used for streaming data into storage solutions like Amazon S3, Redshift, or Elasticsearch. While it can handle real-time data ingestion, it is optimized for batch processing, not real-time processing.
- AWS Glue is a serverless data integration service typically used for ETL (extract, transform, load) jobs. It processes data in batch, making it unsuitable for low-latency, real-time analytics.
- Rejection: This combination is not suitable for real-time processing since AWS Glue is not designed for real-time data processing, and Kinesis Data Firehose is intended for streamlining data into storage rather than immediate analysis.
C) Use Amazon Kinesis Video Streams to capture the clickstream data. Use AWS Glue to pr...
Author: Emma · Last updated Jul 12, 2026
A global company runs its workloads on AWS. The company's application uses Amazon S3 buckets across AWS Regions for sensitive data storage and analysis. The company stores millions of objects in multiple S3 buckets daily. The company wants to...
Objective:
The goal is to identify all S3 buckets that are not versioning-enabled across multiple AWS Regions.
Let's break down each option:
A) Set up an AWS CloudTrail event that has a rule to identify all S3 buckets that are not versioning-enabled across Regions.
- Explanation:
- AWS CloudTrail captures API activity, including S3 actions. However, CloudTrail itself is primarily used for auditing API calls and not for tracking specific configurations like versioning status of S3 buckets.
- CloudTrail can help monitor actions performed on S3 buckets (like creation or modification), but it doesn’t directly report the versioning status of all buckets.
- Rejection: This solution is more focused on auditing actions, and it wouldn't provide a comprehensive view of which buckets are not versioning-enabled. It would require additional steps or custom code to check for versioning status.
B) Use Amazon S3 Storage Lens to identify all S3 buckets that are not versioning-enabled across Regions.
- Explanation:
- Amazon S3 Storage Lens provides visibility into your S3 storage usage and activity. It can generate reports on S3 bucket configuration, including the versioning status of buckets.
- S3 Storage Lens can be configured to show which buckets have versioning enabled or not across multiple Regions. It provides an easy way to identify all S3 buckets and their versioning status.
- Acceptance: This is the most appropriate solution for identifying which S3 buckets are not versioning-enabled, as S3 Storage Lens can report on versioning status and works across multiple Regions.
C) Enable IAM Access Analyzer for S3 to identify a...
Author: VioletCheetah55 · Last updated Jul 12, 2026
A company needs to optimize its Amazon S3 storage costs for an application that generates many files that cannot be recreated. Each file is approximately 5 MB and is stored in Amazon S3 Standard storage.
The company must store the files for 4 years before the files can be deleted. The files must be immediately accessible. The files are frequently accessed in the...
Objective:
The company needs to optimize Amazon S3 storage costs for files that:
- Are approximately 5 MB each,
- Are frequently accessed in the first 30 days of creation,
- Are rarely accessed after the first 30 days,
- Need to be stored for 4 years before deletion,
- Must be immediately accessible.
Key factors to consider:
- Frequent access in the first 30 days: The storage solution needs to support high availability during this time, with quick access to the files.
- Infrequent access after 30 days: A more cost-effective storage class should be used after the first 30 days, as the files are rarely accessed after that.
- 4-year retention period: The solution should be cost-effective for long-term storage.
- Immediate accessibility: The files must be accessible at any time.
Let's evaluate each option:
A) Create an S3 Lifecycle policy to move the files to S3 Glacier Instant Retrieval 30 days after object creation. Delete the files 4 years after object creation.
- Explanation:
- S3 Glacier Instant Retrieval is designed for long-term archival storage of rarely accessed data but allows for retrieval within milliseconds. It is designed to be cost-effective for infrequent access data.
- However, the files are frequently accessed in the first 30 days, which makes S3 Glacier Instant Retrieval too expensive for the first 30 days due to its retrieval times and costs.
- Rejection: While Glacier Instant Retrieval is a good option for infrequent access data, it’s not ideal for data that needs frequent access in the first 30 days.
B) Create an S3 Lifecycle policy to move the files to S3 One Zone-Infrequent Access (S3 One Zone-IA) 30 days after object creation. Delete the files 4 years after object creation.
- Explanation:
- S3 One Zone-IA is a cost-effective storage class for infrequently accessed data that doesn't require multiple Availability Zone resilience. It is less expensive than S3 Standard-IA, but files are stored in only one Availability Zone, making it less durable.
- Since the company requires immediate accessibility and durability for 4 years, S3 One Zone-IA may not meet these needs. One Availability Zone means a single point of failure if that zone experiences an issue, which could be a concern for critical data.
- Rejection: The durability concerns o...
Author: Noah · Last updated Jul 12, 2026
A company runs its critical storage application in the AWS Cloud. The application uses Amazon S3 in two AWS Regions. The company wants the application to send remote user data to the nearest S3 bucket with no public network congestion. The company also wants the applic...
To solve this problem, let's analyze the key requirements and each option:
Key Requirements:
1. Remote user data should be sent to the nearest S3 bucket: This is about reducing latency and improving the speed of data uploads by routing the data to the nearest S3 endpoint.
2. No public network congestion: The solution needs to avoid bottlenecks or public internet congestion for better performance and reliability.
3. Failover with minimal management: The company needs an automated failover solution with as little manual intervention or management as possible.
Analyzing the options:
A) Implement an active-active design between the two Regions. Configure the application to use the regional S3 endpoints closest to the user.
- Pros: This design allows users to access the nearest S3 bucket, potentially reducing latency.
- Cons: Although it achieves proximity, managing an active-active design manually can be complex and may require custom logic for failover in case of issues in one region. This doesn't offer the simplest failover option.
B) Use an active-passive configuration with S3 Multi-Region Access Points. Create a global endpoint for each of the Regions.
- Pros: S3 Multi-Region Access Points provide a global endpoint, which automatically routes user traffic to the closest region. This solution also allows for simple failover in case of issues.
- Cons: The active-passive configuration means only one region would be "active" at a time, which might not provide the best performance if one region experiences congestion or outages.
C) Send user data to the regional S3 endpoints closest to the user. Configure an S3 cross-account replication rule to keep the S3 buckets synchronized.
- Pros: This solution ensures that user data is sent to ...
Author: Leo · Last updated Jul 12, 2026
A company is migrating a data center from its on-premises location to AWS. The company has several legacy applications that are hosted on individual virtual servers. Changes to the application designs cannot be made.
Each individual virtual server currently runs as its own EC2 instance. A solutions architect needs to ensure that the applications ar...
Let's break down the key requirements of the situation and analyze the solutions:
Key Requirements:
1. The company has several legacy applications: These applications cannot be re-architected or redesigned, so they need to be migrated as-is to AWS.
2. Reliability and fault tolerance: After migration, the applications need to be able to tolerate failures, ensuring they remain available.
3. The applications run on individual virtual servers: Each application is independent and currently runs as a single virtual server (EC2 instance), so the solution should respect this setup.
Analyzing the options:
A) Create an Auto Scaling group that has a minimum of one and a maximum of one. Create an Amazon Machine Image (AMI) of each application instance. Use the AMI to create EC2 instances in the Auto Scaling group. Configure an Application Load Balancer in front of the Auto Scaling group.
- Pros: The Auto Scaling group ensures that one EC2 instance is always running. The Application Load Balancer (ALB) provides fault tolerance by distributing traffic across multiple instances. This could help in ensuring availability.
- Cons: Setting the Auto Scaling group to a minimum and maximum size of 1 doesn't provide redundancy, as there is still only one instance running. If that instance fails, the Auto Scaling group won't spin up another instance. Also, Auto Scaling wouldn't help with fault tolerance unless there are multiple instances running.
- Use case: This could be a solution if you only need to ensure the availability of a single EC2 instance, but it doesn't offer full fault tolerance or reliability after migration.
B) Use AWS Backup to create an hourly backup of the EC2 instance that hosts each application. Store the backup in Amazon S3 in a separate Availability Zone. Configure a disaster recovery process to restore the EC2 instance for each application from its most recent backup.
- Pros: AWS Backup can help automate the backup of EC2 instances and store them securely in Amazon S3.
- Cons: This solution provides disaster recovery but not continuous high availability. In the event of a failure, the system would rely on restoring from backups, which would introduce downtime, and it doesn't provide fault tolerance for real-time application availability.
- Use case...
Author: Emily · Last updated Jul 12, 2026
A company wants to isolate its workloads by creating an AWS account for each workload. The company needs a solution that centrally manages networking components for the workloads. The solution also must create accounts with automatic security c...
Let's evaluate the requirements and each option based on the following key factors:
Key Requirements:
1. Isolate workloads by creating an AWS account for each workload: The company wants to have a separate AWS account per workload for isolation.
2. Centrally manage networking components for the workloads: This means that networking resources such as VPCs, subnets, and routing need to be managed centrally across multiple accounts.
3. Automatic security controls (guardrails): Security should be enforced automatically across all the accounts to ensure compliance and safety.
Analyzing the options:
A) Use AWS Control Tower to deploy accounts. Create a networking account that has a VPC with private subnets and public subnets. Use AWS Resource Access Manager (AWS RAM) to share the subnets with the workload accounts.
- Pros: AWS Control Tower provides a centralized way to set up and manage multiple accounts, with built-in security guardrails. The networking account setup with VPC sharing through AWS RAM allows centralized management of networking components. Using RAM to share subnets simplifies the network management across multiple accounts.
- Cons: The VPC is centralized, but each workload account still uses the shared subnets, and there could be complexity in managing traffic and routing if the workloads grow in complexity.
- Use case: This is a good solution when you need central management of networking but want to avoid deploying individual VPCs in each account. It is suitable for smaller, less complex networking needs.
B) Use AWS Organizations to deploy accounts. Create a networking account that has a VPC with private subnets and public subnets. Use AWS Resource Access Manager (AWS RAM) to share the subnets with the workload accounts.
- Pros: AWS Organizations allows centralized management of accounts, and the use of AWS RAM for sharing subnets allows a centralized networking model.
- Cons: Unlike AWS Control Tower, this solution does not come with automatic security guardrails. It would require manual enforcement of security policies across accounts, which increases operational overhead.
- Use case: This could be used if security controls are not as critical or if the company wants more manual control over security guardrails, but it is not the least operationally complex option.
C) Use AWS Control Tower to deploy accounts. Deploy a VPC in...
Author: Kai99 · Last updated Jul 12, 2026
A company hosts a website on Amazon EC2 instances behind an Application Load Balancer (ALB). The website serves static content. Website traffic is increasing. The company wants to mini...
Let's analyze the company's needs and evaluate the options:
Key Requirements:
1. Website serves static content: This means the website doesn't require dynamic content generation (e.g., server-side scripting, database queries) for the bulk of its traffic.
2. Traffic is increasing: The company needs to handle more traffic without drastically increasing costs.
3. Minimize hosting costs: The goal is to reduce costs associated with website hosting while still ensuring reliability and scalability.
Analyzing the Options:
A) Move the website to an Amazon S3 bucket. Configure an Amazon CloudFront distribution for the S3 bucket.
- Pros:
- Cost-effective: Amazon S3 is a very cost-efficient solution for serving static content. The cost of hosting static files (e.g., HTML, CSS, images) in S3 is minimal compared to running EC2 instances.
- Scalable: Amazon S3 automatically scales to handle traffic increases, without needing manual intervention.
- CloudFront Integration: CloudFront, a Content Delivery Network (CDN), will cache the content at edge locations around the world, reducing latency and improving performance for users across different regions.
- High Availability and Reliability: S3 is highly durable and available, and CloudFront improves global content delivery.
- Simplicity: This solution eliminates the need for EC2 instances and load balancing, simplifying management and reducing costs.
- Cons:
- This approach works best for purely static websites. If there is any dynamic content in the future, additional services (like AWS Lambda or API Gateway) would be needed.
B) Move the website to an Amazon S3 bucket. Configure an Amazon ElastiCache cluster for the S3 bucket.
- Pros:
- S3 for static content hosting is cost-effective.
- ElastiCache helps improve performance by caching data in-memory for dynamic content.
- Cons:
- ElastiCache is unnecessary for static content: Since the website serves static content, caching with ElastiCache doesn’t add much value and wou...
Author: MoonlitPantherX · Last updated Jul 12, 2026
A company is implementing a shared storage solution for a media application that the company hosts on AWS. The company needs the ability to use SMB clients to access stored data.
Whi...
Let's analyze the company's requirements and evaluate the options:
Key Requirements:
1. SMB clients: The company needs to use SMB (Server Message Block) clients to access the stored data, which is a protocol commonly used for file sharing in Windows environments.
2. Shared storage solution: The company needs a shared storage solution, which allows multiple clients to access the same data concurrently.
3. Minimal administrative overhead: The company wants a solution that is easy to manage and doesn't require complex setup or ongoing management.
Analyzing the options:
A) Create an AWS Storage Gateway Volume Gateway. Create a file share that uses the required client protocol. Connect the application server to the file share.
- Pros:
- Volume Gateway allows for hybrid storage solutions, integrating on-premises applications with cloud storage. You can use SMB for file sharing.
- Provides a way to connect on-premises environments to AWS and use AWS storage like Amazon S3.
- It supports SMB, so it fits the requirement for SMB clients.
- Cons:
- More complex setup and ongoing management: While the Volume Gateway does support SMB, it is typically used for hybrid environments where on-premises storage is integrated with cloud. It might require more management and administrative overhead compared to fully cloud-native solutions like Amazon FSx.
- Not fully cloud-native: It requires maintaining an on-premises appliance (or virtual appliance), adding complexity.
B) Create an AWS Storage Gateway Tape Gateway. Configure tapes to use Amazon S3. Connect the application server to the Tape Gateway.
- Pros:
- Tape Gateway is primarily used for backup and archiving purposes.
- Integrates with Amazon S3 for tape storage.
- Cons:
- Not suitable for regular file sharing: Tape Gateway is designed for archival and backup workloads, not for providing shared file access over SMB.
- Does not meet the requirement: This solution doesn’t support the real-time file access and sharing needed for the media application.
C) Create an Amazon EC2 Windows instance. Install and configure a Windows file share role on the instance. Connect the application server to the file share.
- Pros:
- This approach could work for S...
Author: Emma · Last updated Jul 12, 2026
A company is designing its production application's disaster recovery (DR) strategy. The application is backed by a MySQL database on an Amazon Aurora cluster in the us-east-1 Region. The company has chosen the us-west-1 Region as its DR Region.
The company's target recovery point objective (RPO) is 5 minutes and the target recovery time objective (RTO...
Let's analyze each option based on the company's target disaster recovery (DR) requirements:
Target requirements:
- Recovery Point Objective (RPO): 5 minutes (data loss of no more than 5 minutes).
- Recovery Time Objective (RTO): 20 minutes (restore service in no more than 20 minutes).
- Minimize configuration changes: The solution should be simple and cause minimal disruption to existing configurations.
Option A: Create an Aurora read replica in us-west-1 similar in size to the production application's Aurora MySQL cluster writer instance.
- RPO: Aurora replicas can be asynchronously replicated. The RPO with a read replica would depend on the replication lag, which can be less than 5 minutes in most cases but is not guaranteed to always meet this requirement under high load or network latency. The lag could also vary, making it less reliable for strict RPO requirements.
- RTO: Failover from a read replica to a primary instance is not instantaneous. While Aurora can fail over to the replica, there is typically a short delay while the replication catches up and the new writer is promoted. This may exceed the target RTO of 20 minutes.
- Operational efficiency: While simple to configure, it still involves manual intervention to promote the replica during a disaster.
- Conclusion: This solution doesn't meet the strict RPO and RTO requirements. It's less reliable for the given target goals.
Option B: Convert the Aurora cluster to an Aurora global database. Configure managed failover.
- RPO: Aurora global databases support cross-region replication with very low latency (sub-second lag). This means the RPO requirement of 5 minutes is easily met.
- RTO: Aurora global databases offer automatic managed failover between regions. The failover process is much faster than with read replicas, typically occurring in seconds to minutes, well within the 20-minute RTO target.
- Operational efficiency: Aurora global databases are designed for minimal configuration changes and fully handle failover management automatically, providing high operational efficiency with no manual intervention needed in case of a disaster.
- Conclusion: This solution meets both the RPO and RTO requirements effectively and has high o...
Author: Elizabeth · Last updated Jul 12, 2026
A company runs a critical data analysis job each week before the first day of the work week. The job requires at least 1 hour to complete the analysis. The job is stateful and cannot tolerate interruptions. The com...
Let's evaluate each option in terms of how well it meets the requirements:
Requirements:
1. The job runs weekly, requiring at least 1 hour to complete.
2. The job is stateful and cannot tolerate interruptions.
Option A: Create a container for the job. Schedule the job to run as an AWS Fargate task on an Amazon Elastic Container Service (Amazon ECS) cluster by using Amazon EventBridge Scheduler.
- Stateful: AWS Fargate tasks are suitable for running containerized applications. The tasks can maintain state as long as they are properly configured with persistent storage (e.g., Amazon EFS for shared file storage or Amazon S3 for file persistence). This can be configured to prevent interruptions.
- Execution Time: Fargate tasks can run for longer than 1 hour without interruptions, which aligns with the job’s requirement for a 1-hour execution window.
- Scheduling: Amazon EventBridge Scheduler can be used to easily schedule the task to run weekly before the work week, fitting the job's schedule requirements.
- Conclusion: Fargate tasks are well-suited to stateful, long-running jobs and can meet both the execution and scheduling requirements.
Option B: Configure the job to run in an AWS Lambda function. Create a scheduled rule in Amazon EventBridge to invoke the Lambda function.
- Stateful: AWS Lambda functions are stateless by design, meaning they cannot maintain state between executions. This would be incompatible with the job's requirement to be stateful and not tolerate interruptions.
- Execution Time: Lambda has a maximum execution time limit of 15 minutes. The job requires at least 1 hour, making Lambda unsuitable for long-running processes like this one.
- Conclusion: Lambda is not suitable because it cannot handle the job’s long duration or stateful requirement.
Option C: Configure an Auto Scaling group of Amazon EC2 Spot Instanc...
Author: BlazingPhoenix22 · Last updated Jul 12, 2026
A company runs workloads in the AWS Cloud. The company wants to centrally collect security data to assess security across the entire company and to improve workload protection.
...
Let's evaluate each option based on the goal of centrally collecting security data to assess security across the company and improve workload protection, with the focus on minimizing development effort.
Option A: Configure a data lake in AWS Lake Formation. Use AWS Glue crawlers to ingest the security data into the data lake.
- Effort to Implement: Setting up AWS Lake Formation requires some initial configuration of data lakes, data access controls, and security policies. AWS Glue crawlers would need to be configured to ingest security data, which adds some complexity. While this solution provides a structured data lake, it still requires significant setup for access control, data cataloging, and ongoing management.
- Suitability: While this can be a robust solution for large-scale data management and security assessments, it involves more development and setup than the company likely needs, especially when the goal is to reduce development effort.
- Conclusion: While effective for long-term data collection, it requires more development effort to implement and manage than other solutions, making it a less optimal choice in terms of minimizing effort.
Option B: Configure an AWS Lambda function to collect the security data in .csv format. Upload the data to an Amazon S3 bucket.
- Effort to Implement: Setting up an AWS Lambda function to collect security data and upload it to an S3 bucket is a simple solution that requires minimal configuration. However, managing the security data as .csv files in S3 is less scalable and harder to query for complex security assessments.
- Suitability: This approach provides an easy, low-effort way to collect data, but storing data in flat .csv format could hinder efficient analysis, especially as the data grows. For ongoing security assessments, it might become cumbersome to extract insights from raw .csv data.
- Conclusion: While this is an easy and low-effort solution to implement, it might not be scalable or efficient enough for ongoing security assessments across a large organization. It could be better suited for simpler or small-scale use cases.
Option C: Configure a data lake in Amazon Security Lake to collect the security data. Upload the data to an Amazon S3 buck...
