Amazon Practice Questions, Discussions & Exam Topics by our Authors
A company runs a highly available data collection application on Amazon EC2 in the eu-north-1 Region. The application collects data from end-user devices and writes records to an Amazon Kinesis data stream and a set of AWS Lambda functions that process the records. The company persists the output of the record processing to an Amazon S3 bucket in eu-north-1. The company uses the data in the S3 bucket as a data source for Amazon Athena.
The company wants to increase its global presence. A solutions architect must launch the data collection capabilities in the sa-east-1 and ap-northeast-1 Regions. The solutions architect deploys the application, the Kinesis data stream, and the Lambda functions in the two new Regions. T...
Key Considerations:
- Latency: The issue at hand is the lag time when data arrives from the new Regions (sa-east-1 and ap-northeast-1) to the S3 bucket in eu-north-1. This means data is being processed in these Regions and uploaded to S3 in eu-north-1, but the time taken for this data transfer is significant.
- Data Centralization: The company wants to centralize the data analysis, so the data must ultimately reside in S3 in eu-north-1.
- Performance Optimization: The solution must minimize the lag in data transfer from the two new Regions to the S3 bucket while respecting the requirement of centralization in eu-north-1.
Evaluation of Options:
Option A: Lambda Functions in a VPC with S3 Gateway Endpoint
- Lambda in VPC: Running Lambda in a VPC and using an S3 Gateway endpoint can enhance the security and efficiency of accessing S3 from within the VPC, but this setup does not address the core problem of cross-region latency. The network latency between the Regions will still persist when the data is uploaded from sa-east-1 and ap-northeast-1 to S3 in eu-north-1.
- Pros: Useful for securing Lambda functions’ access to S3 in a private network.
- Cons: Does not solve cross-region latency, so it would not significantly improve the lag time observed in this setup.
Option B: Turn on S3 Transfer Acceleration
- S3 Transfer Acceleration: This feature speeds up the upload of data to S3 by using Amazon CloudFront’s globally distributed edge locations. It helps to reduce latency when transferring large objects to S3 from geographically distant locations.
- Pros: This can significantly reduce the lag time for uploading data to the S3 bucket, especially from Regions far from eu-north-1.
- Cons: Transfer acceleration can improve upload speeds, but it increases costs, and it doesn’t address any issues related to how Lambda processes and pushes data. Not as effective for continuous data streams from multiple Regions, particularly if the data is coming in small, frequent batches (which is typical for streaming data).
Option C: S3 Bucket in Each Region with Cross-Region Replication
- S3 Bucket per Region: Creating an S3 bucket in each of the new Regions (sa-east-1 and ap-northeast-1) and using S3 Cross-Region Replication to replicate the data to the central S3 bucket in eu-north...
Author: BlazingPhoenix22 · Last updated Jul 6, 2026
A company provides a centralized Amazon EC2 application hosted in a single shared VPC. The centralized application must be accessible from client applications running in the VPCs of other business units. The centralized application front end is configured with a Network Load Balancer (NLB) for scalability.
Up to 10 business unit VPCs will need to be connected to the shared VPC. Some of the business unit VPC CIDR blocks overlap with the shared VPC, and some overlap with each other Network connectivity to the centralized application in the shared VPC should b...
Let's analyze the options in detail:
A) Create an AWS Transit Gateway. Attach the shared VPC and the authorized business unit VPCs to the transit gateway. Create a single transit gateway route table and associate it with all of the attached VPCs. Allow automatic propagation of routes from the attachments into the route table. Configure VPC routing tables to send traffic to the transit gateway.
- Pros:
- Scalable and Centralized: AWS Transit Gateway is designed to handle large-scale, centralized connectivity. You can attach up to 5,000 VPCs to a single Transit Gateway, which makes it highly scalable for your use case where up to 10 VPCs need to be connected.
- Flexible Routing: It allows you to have fine-grained control over routing policies, and you can limit which VPCs can communicate with others.
- Overlapping CIDR Handling: Transit Gateway supports VPCs with overlapping CIDR blocks through route table configuration and policy-based routing.
- Security and Control: You can restrict traffic based on the Transit Gateway route table and apply security policies on specific VPC attachments.
- Cons:
- Cost: Transit Gateway can become expensive depending on the scale (especially if there are many VPCs or large data transfer volumes), but it's a highly reliable and scalable solution.
- Conclusion: This is a good option for connecting multiple VPCs, especially in cases where you have VPCs with overlapping CIDR blocks. It provides scalable, secure, and centralized connectivity with robust routing controls.
B) Create a VPC endpoint service using the centralized application NLB and enable the option to require endpoint acceptance. Create a VPC endpoint in each of the business unit VPCs using the service name of the endpoint service. Accept authorized endpoint requests from the endpoint service console.
- Pros:
- Security and Access Control: This approach allows you to explicitly control access to the centralized application using AWS private endpoints, meaning only authorized business units with accepted endpoints can communicate with the application.
- Low Overhead: There’s no need to manage complex routing or VPN connections.
- Cons:
- Limited Scale: This method is better suited for smaller environments with fewer VPCs. While it allows access control, it might become cumbersome to manage a large number of endpoints.
- CIDR Overlap Challenges: This method doesn’t handle CIDR block overlap effectively. VPC endpoints are generally used for service-to-VPC communications and might not handle CIDR overlaps as gracefully as Transit Gateway.
- Conclusion: This approach could work for smaller or simpler environments but lacks t...
Author: Stella · Last updated Jul 6, 2026
A company wants to migrate its website to AWS. The website uses microservices and runs on containers that are deployed in an on-premises, self-managed Kubernetes cluster. All the manifests that define the deployments for the containers in the Kubernetes deployment are in source control.
All data for the website is stored in a PostgreSQL database. An open source container image repository runs alongside the on-premises environment.
...
To determine the best architecture for migrating the website to AWS with the least effort, we need to focus on minimizing the complexity of the migration process while meeting the company’s existing requirements. Let's evaluate each option:
A) Create an AWS App Runner service. Connect the App Runner service to the open source container image repository. Deploy the manifests from on-premises to the App Runner service. Create an Amazon RDS for PostgreSQL database.
- Advantages:
- Simplified deployment: AWS App Runner is a fully managed service designed to deploy containerized applications directly from source code or container images, which simplifies the deployment process without needing to manage infrastructure.
- Managed PostgreSQL: Amazon RDS for PostgreSQL is a fully managed database service that handles provisioning, patching, backups, and scaling, reducing operational overhead.
- Disadvantages:
- Limited Kubernetes compatibility: App Runner does not support Kubernetes-native workloads and manifests, which would require a significant rework to transition from Kubernetes deployments. This adds complexity to the migration process for a company already using Kubernetes.
- Not designed for complex microservices: App Runner is better suited for simpler applications and microservices, but for a more complex set of containerized applications using Kubernetes, it may not offer the required flexibility or scalability.
Use case: This option may be useful for simpler containerized applications but would require rearchitecting the application significantly. Given that the company is using Kubernetes, it may not be the best fit.
B) Create an Amazon Elastic Kubernetes Service (Amazon EKS) cluster that has managed node groups. Copy the application containers to a new Amazon Elastic Container Registry (Amazon ECR) repository. Deploy the manifests from on-premises to the EKS cluster. Create an Amazon Aurora PostgreSQL DB cluster.
- Advantages:
- Kubernetes support: Since the company already uses Kubernetes for its containerized applications, Amazon EKS is a natural fit. EKS is a managed Kubernetes service, so it would require minimal changes to the existing application deployment and manifest configurations.
- Amazon Aurora for PostgreSQL: Aurora PostgreSQL offers improved performance and scalability over standard PostgreSQL and is fully managed, reducing operational overhead.
- Disadvantages:
- Complexity: While EKS is a good match, it can introduce some complexity in terms of cluster management, especially with setting up networking, security, and scaling. However, it still provides the flexibility and Kubernetes-native experience that aligns well with the company's existing setup.
Use case: This option provides the closest alignment with the company's current infrastructure and would require the least modification of the existing application architecture. It is a good choice for complex, microservice-based architectures.
C) Create an Amazon Elastic Container...
Author: Oliver · Last updated Jul 6, 2026
A company uses a mobile app on AWS to run online contests. The company selects a winner at random at the end of each contest. The contests run for variable lengths of time. The company does not need to retain any data from a contest after the contest is finished.
The company uses custom code that is hosted on Amazon EC2 instances to process the contest data and select a winner. The EC2 instances run behind an Application Load Balancer and store cont...
To reduce costs effectively, we need a solution that aligns with the company's requirements:
1. The contests are temporary, meaning that data does not need to be retained after the contest ends.
2. The solution should minimize the overhead and complexity associated with running the contests, especially in terms of compute resources.
3. Cost reduction is a priority, particularly when it comes to handling scalable storage and compute resources.
Let's evaluate each option:
A) Migrate storage of the contest entries to Amazon DynamoDB. Create a DynamoDB Accelerator (DAX) cluster. Rewrite the code to run as Amazon Elastic Container Service (Amazon ECS) containers that use the Fargate launch type. At the end of the contest, delete the DynamoDB table.
- Advantages:
- DynamoDB: It’s a fully managed NoSQL database, ideal for temporary data storage with automatic scaling based on demand. The data is ephemeral, which fits the requirement of not needing to retain data after the contest.
- Amazon ECS with Fargate: Fargate is serverless, so you only pay for the compute time your containers use. It reduces the operational overhead of managing EC2 instances.
- Disadvantages:
- DAX (DynamoDB Accelerator): While DAX provides in-memory caching for DynamoDB, it’s typically used for high-read, low-latency use cases, which may not be necessary in this scenario since the contest data likely doesn’t require frequent reads at scale. DAX also adds an additional cost, which may not be justified for this case.
- Storage Cleanup: Although DynamoDB allows easy deletion of data, the migration and use of DAX are unnecessary for this type of workload, adding complexity and cost.
Use case: While DynamoDB is a great choice for temporary data, the addition of DAX and ECS with Fargate seems over-engineered and unnecessarily expensive for the task at hand.
B) Migrate the storage of the contest entries to Amazon Redshift. Rewrite the code as AWS Lambda functions. At the end of the contest, delete the Redshift cluster.
- Advantages:
- AWS Lambda: Lambda is a serverless compute option, meaning you pay only for the execution time of your code, which can significantly reduce costs if the processing is event-driven.
- Disadvantages:
- Redshift: Redshift is a managed data warehouse service designed for complex queries and analytics, which is much more expensive and unnecessary for storing temporary contest entries. Redshift is optimized for large-scale analytical workloads and would not be a cost-effective solution for transient, high-throughput storage of contest entries.
- Cleanup overhead: The process of creating and deleting Redshift clusters every time a contest starts and ends would introduce additional operational overhead and inefficiency.
Use case: Redshift is an overkill for this scenario. Lambda would be useful, but pairing it with Redshift for this workload is not cost-effective or practical.
C) Add an A...
Author: SolarFalcon11 · Last updated Jul 6, 2026
A company has implemented a new security requirement. According to the new requirement, the company must scan all traffic from corporate AWS instances in the company's VPC for violations of the company's security policies. As a result of these scans, the company can block access to and from specific IP addresses.
To meet the new requirement, the company deploys a set of Amazon EC2 instances in private subnets to serve as transparent proxies. The company installs approved proxy server software on these EC2 instances. The company modifies the route tables on all subnets to use the corresponding EC2 instances with proxy software as the default route. The company also creates security groups th...
To resolve the issue where traffic from the EC2 instances in private subnets is not being properly forwarded to the internet despite the company's configuration of transparent proxies, the main issue likely lies in the network routing configuration or source/destination checks. Let's analyze each of the options:
A) Disable source/destination checks on the EC2 instances that run the proxy software.
- Advantages:
- Correct solution: By default, EC2 instances in a VPC perform source/destination checks, which means they cannot forward traffic that is not destined for themselves (e.g., routing traffic between different network interfaces or for NAT purposes). Disabling the source/destination checks allows the EC2 instances to function as network devices (like routers), enabling them to forward traffic between the private subnets and the internet.
- Disadvantages:
- No significant drawbacks: Disabling the source/destination check is a standard practice when configuring EC2 instances to act as proxies or NAT devices.
Use case: This is the correct and most effective solution because the EC2 instances need to forward traffic between the private subnets and the internet, and disabling source/destination checks is required for this behavior.
B) Add a rule to the security group that is assigned to the proxy EC2 instances to allow all traffic between instances that have this security group. Assign this security group to all EC2 instances in the VPC.
- Advantages:
- Security Group Modification: This allows traffic between EC2 instances within the VPC, which can be useful in some situations.
- Disadvantages:
- Not directly related to the issue: The issue described is related to traffic forwarding and routing, not inter-instance communication. The proxy instances need to route traffic to the internet, and modifying the security group in this way does not address the need for routing configuration.
Use case: While security group rules might be useful for controlling intra-VPC communication, they are not relevant to enabling traffic forwarding between subnets and the internet. This is not the right solution.
C) Change the VPC's...
Author: Mia · Last updated Jul 6, 2026
A company is running its solution on AWS in a manually created VPC. The company is using AWS CloudFormation to provision other parts of the infrastructure. According to a new requirement, the company must manage all infrastructure in...
To meet the requirement of managing the existing infrastructure in an automatic way with the least effort, the solution should focus on bringing the manually created VPC under management through AWS CloudFormation. Let's evaluate each option based on the goal of automating infrastructure management:
A) Create a new AWS Cloud Development Kit (AWS CDK) stack that strictly provisions the existing VPC resources and configuration. Use AWS CDK to import the VPC into the stack and to manage the VPC.
- Advantages:
- AWS CDK: The AWS CDK is a modern, code-first approach to infrastructure provisioning, which offers powerful capabilities for managing AWS resources.
- Import capability: AWS CDK allows you to import existing resources (including a VPC) into the stack and then manage them programmatically.
- Disadvantages:
- Effort required for import: While CDK can be used to import resources, the process may require some effort and the use of custom code to correctly model the existing infrastructure.
- Not as straightforward as CloudFormation: AWS CDK is more suited to new infrastructure rather than managing existing resources, particularly when the goal is to minimize effort.
Use case: AWS CDK is powerful but may not be the best choice for an immediate, straightforward solution for managing already existing resources. While feasible, it requires more upfront effort than other methods, especially when aiming for minimal effort.
B) Create a CloudFormation stack set that creates the VPC. Use the stack set to import the VPC into the stack.
- Advantages:
- CloudFormation StackSet: StackSets allow for the deployment of CloudFormation stacks across multiple regions and accounts, which is useful for a larger scale of infrastructure management.
- Disadvantages:
- Cannot directly import existing resources: CloudFormation StackSets do not support the direct import of already existing resources like a manually created VPC. This would require creating the VPC from scratch again, which is counterproductive in this scenario.
Use case: This option is not suitable because StackSets are designed for multi-region/account deployments and cannot directly import existing resources into a stack.
C) Create a new CloudFormation template that strictly provisions the existi...
Author: RadiantJaguar56 · Last updated Jul 6, 2026
A company has developed a new release of a popular video game and wants to make it available for public download. The new release package is approximately 5 GB in size. The company provides downloads for existing releases from a Linux-based, publicly facing FTP site hosted in an on-premises data center. The company expects the new release will be downloa...
Option A: Store the game files on Amazon EBS volumes mounted on Amazon EC2 instances within an Auto Scaling group. Configure an FTP service on the EC2 instances. Use an Application Load Balancer in front of the Auto Scaling group. Publish the game download URL for users to download the package.
- Reasoning: This approach involves setting up EC2 instances that can scale depending on demand and provide access via FTP. However, EBS volumes are not optimal for global distribution of large files. EBS is designed for persistent block storage, but not specifically for high-performance file delivery across multiple regions. Also, FTP is an outdated protocol, and the solution does not address the need for worldwide content delivery effectively.
- Key Issues: High management complexity, scaling issues, potentially high costs, and not optimized for global download speed.
- Use Case: Could work for an internal use case within a specific region, but not ideal for global distribution of large files.
Option B: Store the game files on Amazon EFS volumes that are attached to Amazon EC2 instances within an Auto Scaling group. Configure an FTP service on each of the EC2 instances. Use an Application Load Balancer in front of the Auto Scaling group. Publish the game download URL for users to download the package.
- Reasoning: Amazon EFS is a scalable, shared file storage solution, but it is better suited for use cases that involve distributed applications or workloads with highly variable storage needs. It is not designed for large-scale global file distribution. Like Option A, using FTP adds complexity, and this solution would not provide the best performance for worldwide users.
- Key Issues: EFS is not cost-effective or optimal for serving large downloadable files to global users, and FTP adds unnecessary overhead.
- Use Case: Suitable for shared access to files within a specific environment but not for high-performance global file downloads.
Option C: Configure Amazon Route 53 and an Amazon S3 bucket for website hosting. Upload the game f...
Author: Emma · Last updated Jul 6, 2026
A company runs an application in the cloud that consists of a database and a website. Users can post data to the website, have the data processed, and have the data sent back to them in an email. Data is stored in a MySQL database running on an Amazon EC2 instance. The database is running in a VPC with two private subnets. The website is running on Apache Tomcat in a single EC2 instance in a different VPC with one public subnet. There is a single VPC peering connection between the database and ...
Option A: Place the Tomcat server in an Auto Scaling group with multiple EC2 instances behind an Application Load Balancer.
- Reasoning: By placing the Tomcat server in an Auto Scaling group with multiple EC2 instances, you can ensure high availability and handle fluctuations in traffic. The Application Load Balancer (ALB) will automatically distribute traffic across multiple instances of Tomcat, providing better load balancing and fault tolerance.
- Key Advantages: This solution addresses the issue of outages caused by high traffic by scaling the website dynamically based on demand. It improves the availability of the website, ensuring users can always access it even if one EC2 instance fails.
- Use Case: Ideal for scenarios where an application needs to handle fluctuating traffic while ensuring continuous availability and scaling based on demand.
Option B: Provision an additional VPC peering connection.
- Reasoning: VPC peering connects two VPCs, allowing resources to communicate between them. However, adding an additional VPC peering connection would not help address the root cause of the website's outages. The issue seems to be related to the web application’s ability to handle traffic, not the VPC peering connectivity. The single peering connection is sufficient for communication, and adding another one would not solve the scalability or reliability issues.
- Key Issues: This doesn't directly address the problem of scaling the website or improving its availability. VPC peering connections do not inherently improve traffic management or application performance.
- Use Case: VPC peering is useful for scenarios requiring communication between VPCs but does not resolve performance issues in this case.
Option C: Migrate the MySQL database to Amazon Aurora with one Aurora Replica.
- Reasoning: Amazon Aurora is a managed, highly available database service that is compatible with MySQL. By migrating to Aurora, the company can benefit from automated backups, replication, and scaling, making the database more resilient and capable of handling higher traffic loads. Aurora Replicas provide read scalability, reducing the load on the primary database and improving overall performance.
- Key Advantages: Aurora provides better availability, fault tolerance, and scalability compared to a MySQL database running on EC2. This can significantly improve the reliability of the backend database, especially under high traffic conditions.
- Use Case: Ideal for scenarios where a more scalable, highly available, and fault-tolerant database solution is required to support growing application demands.
Option D: Provision two NAT gateways in the database VPC.
- Reasoning: A NAT gateway is used to allow instances in private subnets to access the internet. However, the database VPC with MySQL should not need to access the i...
Author: Harper · Last updated Jul 6, 2026
A retail company is operating its ecommerce application on AWS. The application runs on Amazon EC2 instances behind an Application Load Balancer (ALB). The company uses an Amazon RDS DB instance as the database backend. Amazon CloudFront is configured with one origin that points to the ALB. Static content is cached. Amazon Route 53 is used to host all public zones.
After an update of the application, the ALB occasionally returns a 502 status code (Bad Gateway) error. The root cause is malformed HTTP headers that are returned to the ALB. The webpage returns successfully when a solutions architect reloads the webpage immediately after the error occu...
Option A: Create an Amazon S3 bucket. Configure the S3 bucket to host a static webpage. Upload the custom error pages to Amazon S3.
- Reasoning: This is the most straightforward and least operationally intensive option for serving a custom error page. By using an S3 bucket to host the static error page, the company can easily configure Amazon CloudFront to deliver it. The S3 bucket can be configured to serve static HTML files, and CloudFront can be set up to cache and distribute the error page to users when needed. This approach minimizes complexity and operational overhead because it doesn't require complex Lambda functions or DNS changes.
- Key Advantages: Simple to set up and manage, reduces complexity, integrates easily with CloudFront, and is highly scalable. The static nature of the error page makes it ideal for this use case.
- Use Case: Best for serving custom error pages when there are temporary application issues, such as 502 errors, and when you want a simple, scalable solution.
Option B: Create an Amazon CloudWatch alarm to invoke an AWS Lambda function if the ALB health check response Target.FailedHealthChecks is greater than 0. Configure the Lambda function to modify the forwarding rule at the ALB to point to a publicly accessible web server.
- Reasoning: While creating a CloudWatch alarm to trigger a Lambda function to modify the ALB's forwarding rule could theoretically help in rerouting traffic to a backup or static error page, it introduces significant complexity. You would need to handle the Lambda function's logic for modifying routing rules dynamically. Additionally, this solution doesn't directly address the core problem of serving a static error page.
- Key Issues: This is overly complex for simply showing a custom error page. It involves managing dynamic routing logic and additional operational overhead with Lambda functions and health checks. It also requires frequent updates or monitoring to ensure the correct target is selected.
- Use Case: More suitable for scenarios where routing traffic to backup servers or containers is needed, not for simple error page handling.
Option C: Modify the existing Amazon Route 53 records by adding health checks. Configure a fallback target if the health check fails. Modify DNS records to point to a publicly accessible webpage.
- Reasoning: This solution suggests modifying DNS settings to fallback to a different page when health checks fail. However, DNS changes are not instantaneous, and there is a potential for propagation delays. DNS-based redirection can be slow, and it's not ideal for real-time error handling, especially for HTTP status codes like 502.
- Key Issues: DNS propagation delays can create inconsistent user experiences. C...
Author: Aarav · Last updated Jul 6, 2026
A company wants to migrate an Amazon Aurora MySQL DB cluster from an existing AWS account to a new AWS account in the same AWS Region. Both accounts are members of the same organization in AWS Organizations.
The company must minimize database service interruption before the...
Option A: Take a snapshot of the existing Aurora database. Share the snapshot with the new AWS account. Create an Aurora DB cluster in the new account from the snapshot.
- Reasoning: This option allows you to take a snapshot of the existing Aurora MySQL database, share that snapshot with the new AWS account, and then restore the snapshot in the new account to create a new Aurora DB cluster. This is a straightforward and common method for migrating an Aurora database between accounts in the same region.
- Key Advantages:
- Snapshot sharing is supported between accounts in the same AWS Region.
- Once the snapshot is restored, the database can be brought online with minimal downtime, and DNS cutover can be done when the migration is complete.
- This minimizes service interruption because the database in the old account will remain functional during the snapshot sharing and restoration process.
- Use Case: This method works well for a one-time migration where minimizing downtime is critical, and it is a native AWS feature designed for such use cases.
Option B: Create an Aurora DB cluster in the new AWS account. Use AWS Database Migration Service (AWS DMS) to migrate data between the two Aurora DB clusters.
- Reasoning: AWS DMS is a powerful tool for migrating data between databases in real-time, but for an Aurora MySQL migration, it adds unnecessary complexity compared to using a snapshot-based approach. While AWS DMS can replicate changes from the source database to the target database during the migration, it introduces an additional service and might involve more setup and management overhead.
- Key Issues:
- AWS DMS is useful for continuous replication during migration, but it requires configuration, monitoring, and management of migration tasks. The initial setup of DMS can be time-consuming, and it may involve ongoing operational complexity.
- This is overkill if the goal is to minimize downtime and perform a one-time migration, as a snapshot and restore process would be simpler and more efficient.
- Use Case: Best suited for continuous migration or when complex transformations are required, not for minimizing downtime in a simple migration scenario like this.
Option C: Use AWS Backup to share an Aurora database backup from the existing AWS account to the ...
Author: Olivia Johnson · Last updated Jul 6, 2026
A software as a service (SaaS) company provides a media software solution to customers. The solution is hosted on 50 VPCs across various AWS Regions and AWS accounts. One of the VPCs is designated as a management VPC. The compute resources in the VPCs work independently.
The company has developed a new feature that requires all 50 VPCs to be able to communicate with each other. The new feature also requires one-way access from each customer's VPC to the company's management VPC. The management VPC hosts a compute resource that validates licenses for the media software so...
Option A: Create a transit gateway. Attach all the company's VPCs and relevant subnets to the transit gateway.
- Reasoning: Using a Transit Gateway is the most scalable and efficient option for enabling communication between multiple VPCs across regions and accounts. The Transit Gateway acts as a central hub to connect VPCs, enabling communication with minimal operational overhead. With the Transit Gateway, VPCs can be attached to the hub, and the required communication (including one-way access from each customer VPC to the management VPC) can be easily controlled via route tables.
- Key Advantages:
- Centralized management for routing between VPCs, which simplifies operations.
- Scalable solution that can accommodate an increasing number of VPCs.
- Simplifies inter-VPC connectivity and one-way access control from customer VPCs to the management VPC.
- Supports cross-region peering, which is ideal if the VPCs span across multiple AWS regions.
- Use Case: Best suited for scenarios requiring communication between a growing number of VPCs, where simplicity, scalability, and centralized management are essential.
Option B: Create VPC peering connections between all the company's VPCs.
- Reasoning: VPC peering is another option for VPC-to-VPC communication, but it can become complex and difficult to manage at scale. For 50 VPCs (and potentially more in the future), the number of peering connections would grow exponentially. Each new VPC would need to be peered with every other VPC, leading to a management overhead. Additionally, VPC peering doesn't support transitive routing, meaning each VPC can only communicate directly with the VPCs it's peered with. This would require maintaining a complex web of peering connections, making it inefficient as the solution grows.
- Key Issues:
- Scalability: The number of connections grows quadratically as the number of VPCs increases, creating significant operational overhead.
- Complexity: Managing peering connections between VPCs at scale can become error-prone and cumbersome.
- No Transitive Routing: VPC peering doesn’t support transitive routing, so each new connection would need to be explicitly configured to allow communication between VPCs that are not directly peered.
- Use Case: Suitable for small-scale environments with few VPCs and simpler connectivity requirements but not ideal for a growing SaaS solution with many VPCs.
Option C: Create a Network Load Balancer (NLB) that points to the compute resource for license validation. Create an AWS PrivateLink endpoint service that is available to each customer's VPC. Associate the endpoint service with the NLB.
- Reasoning: AWS PrivateLink enables secure and private communication between VPCs, which is ideal for services like license validation. However, this solution focuses on the one-way access from customer VPCs to the management VPC, which is a small part of the requirement. While PrivateLink provides a secu...
Author: GlowingTiger · Last updated Jul 6, 2026
A company has multiple lines of business (LOBs) that roll up to the parent company. The company has asked its solutions architect to develop a solution with the following requirements:
* Produce a single AWS invoice for all of the AWS accounts used by its LOBs.
* The costs for each LOB account should be broken out on the invoice.
* Provide the ability to restrict services and features in the LOB accounts, as defined by the company's governance policy.
* Each LOB a...
To meet the requirements provided, let's carefully analyze each option and discuss the key reasoning behind selecting or rejecting each one.
Requirements Breakdown:
1. Produce a single AWS invoice for all AWS accounts used by its LOBs - This points to consolidated billing.
2. The costs for each LOB account should be broken out on the invoice - This requires a way to distinguish the costs between different LOB accounts.
3. Provide the ability to restrict services and features in the LOB accounts, as defined by the company's governance policy - This points to a service control mechanism (Service Control Policies, SCPs) to enforce restrictions.
4. Each LOB account should be delegated full administrator permissions, regardless of the governance policy - This means that while restrictions are applied via policies, LOB accounts need full administrative rights, which is compatible with SCPs allowing broader permissions at the account level.
Option Analysis:
- A) Use AWS Organizations to create an organization in the parent account for each LOB. Then invite each LOB account to the appropriate organization.
- This option is incorrect because AWS Organizations doesn't allow multiple organizations within a single account. AWS Organizations is intended to create one organization that includes multiple AWS accounts, not one organization per LOB. Hence, this option isn't viable for meeting the requirements.
- B) Use AWS Organizations to create a single organization in the parent account. Then, invite each LOB's AWS account to join the organization.
- This is a correct option. AWS Organizations allows the parent account to create a single organization and invite multiple LOB accounts into it. This setup allows for consolidated billing and cost management, meeting the requirement to produce a single AWS invoice. Additionally, AWS Organizations helps break out costs per account. This method also enables applying service control policies (SCPs) to enforce governance without impacting the LOB's administrative rights.
...
Author: Kai · Last updated Jul 6, 2026
A solutions architect has deployed a web application that serves users across two AWS Regions under a custom domain. The application uses Amazon Route 53 latency-based routing. The solutions architect has associated weighted record sets with a pair of web servers in separate Availability Zones for each Region.
The solutions architect runs a disaster recovery scenario. When all the web servers in...
Analysis of the Problem:
In this scenario, the solutions architect is using Amazon Route 53 latency-based routing with weighted record sets for disaster recovery. However, when the web servers in one Region are stopped, Route 53 does not automatically redirect users to the other Region. This could be due to issues in the configuration of health checks or the way the routing is set up.
Let's evaluate each option to identify the possible root causes:
Option-by-Option Breakdown:
A) The weight for the Region where the web servers were stopped is higher than the weight for the other Region.
- Rejection Reason: The weight of the resource record sets only determines how much traffic is routed to each region under normal conditions, but it does not affect the failover behavior when one region is down. Weight does not affect health-based failover in Route 53, so this is not the root cause of the issue. The failover should happen as long as health checks are configured correctly, regardless of the weight.
B) One of the web servers in the secondary Region did not pass its HTTP health check.
- Selected Option: This is a valid root cause. If a web server in the secondary Region fails its health check, Route 53 will not route traffic to that server, even if it's the only available Region. Route 53 latency-based routing uses health checks to determine which resources are available. If the health check for a web server in the secondary Region fails, it will prevent Route 53 from routing traffic to that region, causing users to remain stuck in the primary (failed) region. This scenario directly explains why Route 53 is not redirecting traffic to the other region.
C) Latency resource record sets cannot be used in combination with weighted resource record sets.
- Rejection Reason: This is incorrect. Latency-based routing and weighted routing in Route 53 can be used in conjunction. It's possible to combine th...
Author: Lina Zhang · Last updated Jul 6, 2026
A flood monitoring agency has deployed more than 10,000 water-level monitoring sensors. Sensors send continuous data updates, and each update is less than 1 MB in size. The agency has a fleet of on-premises application servers. These servers receive updates from the sensors, convert the raw data into a human readable format, and write the results to an on-premises relational database server. Data analysts then use simple SQL queries to monitor the data.
The agency wants to increase overall application availability and reduce the effort that is required to perform maintenance tasks. These maintenance tasks, which include updates and patches to the application servers, cause downtime. While an application server is down, data is lost f...
Requirements Breakdown:
- Increase overall application availability: The solution must be highly available, which implies that there should be no downtime, even during maintenance tasks.
- Reduce maintenance efforts: Maintenance tasks (e.g., updates, patches) on on-premises application servers lead to downtime. We need a solution that reduces the overhead of such maintenance.
- Avoid data loss during server downtime: The solution should ensure that the data from the sensors is not lost when an application server is unavailable.
- Optimize operational overhead and costs: The solution should minimize operational complexity and should be cost-effective.
Option Analysis:
A) Send the sensor data to Amazon Kinesis Data Firehose. Use an AWS Lambda function to read the Kinesis Data Firehose data, convert it to .csv format, and insert it into an Amazon Aurora MySQL DB instance. Instruct the data analysts to query the data directly from the DB instance.
- Not the best option. While Kinesis Data Firehose can be used to ingest the sensor data, using an Amazon Aurora MySQL DB instance introduces complexity in terms of cost and scalability. Additionally, directly querying data from a relational database is not ideal for analytical purposes when you have large-scale sensor data. Aurora also requires maintenance and scaling, which contradicts the goal of reducing operational overhead. The operational burden of handling updates and scaling can still create issues.
B) Send the sensor data to Amazon Kinesis Data Firehose. Use an AWS Lambda function to read the Kinesis Data Firehose data, convert it to Apache Parquet format, and save it to an Amazon S3 bucket. Instruct the data analysts to query the data by using Amazon Athena.
- This is a strong option.
- Kinesis Data Firehose provides a fully managed solution for ingesting streaming data, which increases availability and reliability.
- Apache Parquet is a columnar storage format, which is optimized for query performance in analytics scenarios, making it a good fit for the data.
- Amazon Athena allows for SQL-like queries directly on data stored in Amazon S3, which significantly reduces the need for traditional database management and minimizes operational overhead.
- This solution offers scalability, cost-effectiveness (pay-as-you-go), and reduces maintenance efforts. It also ensures that data is no...
Author: VioletCheetah55 · Last updated Jul 6, 2026
A public retail web application uses an Application Load Balancer (ALB) in front of Amazon EC2 instances running across multiple Availability Zones (AZs) in a Region backed by an Amazon RDS MySQL Multi-AZ deployment. Target group health checks are configured to use HTTP and pointed at the product catalog page. Auto Scaling is configured to maintain the web fleet size based on the ALB health check.
Recently, the application experienced an outage. Auto Scaling continuously replaced the instances during the outage. A subsequent investigation determined that the web server metrics were within the normal range, but the database tier was experiencin...
Scenario Breakdown:
- Application Load Balancer (ALB): Balances traffic across multiple EC2 instances running across multiple Availability Zones.
- Amazon RDS MySQL Multi-AZ deployment: The database is highly available, but was experiencing high load during the outage, which resulted in elevated query response times.
- Auto Scaling: Was triggered based on ALB health checks, which failed even though the web server metrics were normal, suggesting that the health checks may not be monitoring the overall application stack properly.
Key Requirements:
- Remediate the issues: The root cause is that Auto Scaling continued to replace EC2 instances, even though the problem was with the database tier. This suggests that the health checks were insufficient to detect the actual problem.
- Improve monitoring and availability: The solution should not only prevent the issue from recurring but also enhance monitoring capabilities to ensure the entire application stack's availability is better tracked and that the load on the backend database is reduced.
Option Analysis:
A) Configure read replicas for Amazon RDS MySQL and use the single reader endpoint in the web application to reduce the load on the backend database tier.
- Correct choice. By setting up read replicas for Amazon RDS MySQL, the load on the primary database can be reduced by offloading read-heavy queries to the replicas. This would help balance the database load and ensure better scalability. The single reader endpoint allows the web application to automatically distribute read requests across all available read replicas. This improves database performance and reduces the strain on the primary database, making it a good solution for the database tier's scalability.
B) Configure the target group health check to point at a simple HTML page instead of a product catalog page and the Amazon Route 53 health check against the product page to evaluate full application functionality. Configure Amazon CloudWatch alarms to notify administrators when the site fails.
- Partially correct, but suboptimal. Changing the health check to a simple HTML page might avoid false positives from the target group health checks, but it does not address the underlying issue of high database load. The application itself, including database health, is still not adequately monitored. Also, Amazon Route 53 health checks can't evaluate database functionality, so this would still miss database-related issue...
Author: Ethan Smith · Last updated Jul 6, 2026
A company has an on-premises data center and is using Kubernetes to develop a new solution on AWS. The company uses Amazon Elastic Kubernetes Service (Amazon EKS) clusters for its development and test environments.
The EKS control plane and data plane for production workloads must reside on premises. The company ne...
To address the company's requirement of managing Kubernetes on AWS while keeping the production workloads on-premises, we need to find the most suitable solution that meets the following criteria:
1. On-premises control plane and data plane for production workloads: The production workloads need to reside on-premises, so the control plane must be managed in a way that allows Kubernetes clusters to run on-premises.
2. AWS-managed solution: The company is seeking an AWS-managed solution to reduce operational overhead.
A) Install an AWS Outposts server in the on-premises data center. Deploy Amazon EKS by using a local cluster configuration on the Outposts server for the production workloads.
- Analysis:
- AWS Outposts can bring AWS infrastructure to the on-premises data center, and you can run Amazon EKS with a local cluster configuration (which means that the EKS control plane is in the cloud, while the data plane is deployed on the Outposts hardware on-premises).
- However, this configuration might not meet the requirement to have both the control plane and data plane on-premises. The control plane would still reside in the AWS cloud, and only the data plane would be on-premises.
- This setup could also involve more operational overhead than needed, as the user would still need to manage a connection between the control plane in the cloud and the local data plane.
- Conclusion: While feasible, this solution doesn’t fully meet the requirement of having both the control plane and data plane on-premises. (Rejected)
B) Install Amazon EKS Anywhere on the company's hardware in the on-premises data center. Deploy the production workloads on an EKS Anywhere cluster.
- Analysis:
- Amazon EKS Anywhere is a fully AWS-managed solution that allows you to run Amazon EKS clusters on your on-premises hardware. It provides a Kubernetes environment that can run in your data center while being managed through AWS.
- This approach ensures that both the control plane and data plane are on-premises, which fully aligns with the company's requirement to keep the production workloads on-premises.
- EKS Anywhere...
Author: Liam123 · Last updated Jul 6, 2026
A company uses AWS Organizations to manage its development environment. Each development team at the company has its own AWS account. Each account has a single VPC and CIDR blocks that do not overlap.
The company has an Amazon Aurora DB cluster in a shared services account. All the development teams need to work with li...
To provide connectivity to the Amazon Aurora DB cluster with the least operational overhead, let's analyze each option:
A) Create an AWS Resource Access Manager (AWS RAM) resource share for the DB cluster. Share the DB cluster with all the development accounts.
- Analysis: AWS RAM allows you to share resources, such as VPCs, subnets, and databases, between AWS accounts. However, it is not typically used for sharing databases like Aurora directly. Aurora does not currently support being shared via AWS RAM directly for cross-account access. This option would not be feasible.
- Reason for Rejection: AWS RAM doesn't support directly sharing Aurora DB clusters, so it cannot provide the connectivity required.
B) Create a transit gateway in the shared services account. Create an AWS Resource Access Manager (AWS RAM) resource share for the transit gateway. Share the transit gateway with all the development accounts. Instruct the developers to accept the resource share. Configure networking.
- Analysis: A transit gateway could allow inter-VPC communication between the shared services account and all development accounts. Sharing the transit gateway using AWS RAM can help establish networking between the VPCs across accounts. However, setting up a transit gateway requires configuring routing and careful management of VPC attachments. While scalable and flexible, this solution involves additional operational overhead, such as setting up, maintaining, and configuring the transit gateway and routing.
- Reason for Rejection: While this solution would work, it introduces additional operational overhead due to the complexity of managing a transit gateway and configuring routing.
C) Create an Application Load Balancer (ALB) that points to the IP address of the DB cluster. Create an AWS PrivateLink endpoint service that uses the ALB. Add permissions to al...
Author: Sofia · Last updated Jul 6, 2026
A company used AWS CloudFormation to create all new infrastructure in its AWS member accounts. The resources rarely change and are properly sized for the expected load. The monthly AWS bill is consistent.
Occasionally, a developer creates a new resource for testing and forgets to remove the resource when the test is complete. Most of these tests last a few days before the resources are no longer needed.
The company wants to automate the process of finding unused resources. A solutions architect needs to design a solution that determ...
To meet the company's requirements, let's evaluate each option based on the goal of detecting unused resources, identifying cost increases, and notifying the operations team.
A) Turn on billing alerts. Use AWS Cost Explorer to determine the costs for the past month. Create an Amazon CloudWatch alarm for total estimated charges. Specify a cost threshold that is higher than the costs that Cost Explorer determined. Add a notification to alert the operations team if the alarm threshold is breached.
- Analysis: While CloudWatch billing alarms can notify the team when total estimated charges exceed a certain threshold, this option only provides alerts based on aggregate costs. It does not offer detailed insights into which specific resources are causing the cost increase. This option requires manual effort to analyze historical data from AWS Cost Explorer to set an appropriate threshold.
- Reason for Rejection: It does not directly help identify which resources are unused and causing the cost increases, making it less effective for the company's needs of automatically identifying unused resources.
B) Turn on billing alerts. Use AWS Cost Explorer to determine the average monthly costs for the past 3 months. Create an Amazon CloudWatch alarm for total estimated charges. Specify a cost threshold that is higher than the costs that Cost Explorer determined. Add a notification to alert the operations team if the alarm threshold is breached.
- Analysis: Similar to option A, this solution uses CloudWatch billing alarms and AWS Cost Explorer. It extends the analysis to a 3-month window, which may help better predict typical costs. However, the solution still lacks granularity on individual resource usage and doesn't automatically identify unused resources or specific contributors to the cost increase.
- Reason for Rejection: Like option A, it doesn't pinpoint unused resources causing cost increases, so it doesn’t address the requirement of helping to identify unused resources directly.
C) Use AWS Cost Anomaly Detection to create a cost monitor that has a monitor type of Linked account. Create a subscription to send daily AWS cost summaries to the operations team. ...
Author: RadiantPhoenixX · Last updated Jul 6, 2026
A company is deploying a new web-based application and needs a storage solution for the Linux application servers. The company wants to create a single location for updates to application data for all instances. The active dataset will be up to 100 GB in size. A solutions architect has determined that peak operations will occur for 3 hours daily and will require a total of 225 MiBps of read throughput.
The solutions architect must design a Multi...
Let’s go through the options and analyze each in terms of the company’s requirements:
Key Requirements:
1. Storage for Linux application servers: The solution should provide centralized storage for application data.
2. Up to 100 GB active dataset.
3. Peak operations for 3 hours daily: Peak read throughput of 225 MiBps.
4. Multi-AZ setup: The solution must be deployed across multiple Availability Zones.
5. Disaster Recovery (DR): The DR solution must have a Recovery Point Objective (RPO) of less than 1 hour.
A) Deploy a new Amazon Elastic File System (Amazon EFS) Multi-AZ file system. Configure the file system for 75 MiBps of provisioned throughput. Implement replication to a file system in the DR Region.
- Analysis:
- Amazon EFS is a fully managed, scalable, shared file storage service that supports Linux workloads and provides automatic scaling of throughput and capacity.
- EFS supports Multi-AZ by default, which ensures high availability within a region.
- Replication to another region (cross-region replication) is possible, but this involves a process that isn’t built into EFS itself; custom solutions like AWS DataSync would be needed to replicate the data.
- The throughput of 75 MiBps might not be enough to meet the required 225 MiBps peak throughput, especially since the solution would only be configured for half of the required peak throughput.
- EFS replication does not inherently meet the less than 1 hour RPO unless set up carefully with custom processes like DataSync.
- Conclusion: This option does not fully meet the performance or RPO requirements due to insufficient throughput and the need for custom replication setup. (Rejected)
B) Deploy a new Amazon FSx for Lustre file system. Configure Bursting Throughput mode for the file system. Use AWS Backup to back up the file system to the DR Region.
- Analysis:
- Amazon FSx for Lustre is designed for high-performance workloads, including those that require fast access to large datasets, making it a good choice for applications with high throughput requirements.
- However, Bursting Throughput mode in FSx for Lustre is not suitable for sustained throughput of 225 MiBps. This mode is designed for workloads that can tolerate short bursts but would not guarantee sustained high throughput for 3 hours daily.
- Using AWS Backup to replicate the data introduces an RPO that may not meet the requirement of less than 1 hour since backups are typically scheduled at longer intervals (e.g., daily), not frequent enough to meet the RPO.
- Conclusion: This option i...
Author: Nathan · Last updated Jul 6, 2026
A company needs to gather data from an experiment in a remote location that does not have internet connectivity. During the experiment, sensors that are connected to a local network will generate 6 TB of data in a proprietary format over the course of 1 week. The sensors can be configured to upload their data files to an FTP server periodically, but the sensors do not have their own FTP server. The sensors also do not support other protocols...
Let's evaluate each option to determine which one best meets the requirements for gathering data from the sensors, transferring it to AWS, and ensuring the solution can work in a remote location with no internet connectivity.
Key Requirements:
- 6 TB of data generated over 1 week.
- Sensors can upload data via FTP.
- No internet connectivity at the remote location.
- Data must be collected centrally and moved to AWS object storage (Amazon S3) as soon as possible after the experiment.
A) Order an AWS Snowball Edge Compute Optimized device. Connect the device to the local network. Configure AWS DataSync with a target bucket name, and unload the data over NFS to the device. After the experiment, return the device to AWS so that the data can be loaded into Amazon S3.
- Analysis: The AWS Snowball Edge is a suitable device for edge computing and offline data transfer. It provides both local compute capabilities and the ability to transfer large amounts of data back to AWS. However, AWS DataSync is used for moving data over the network, but since there is no internet connectivity in the remote location, the Snowball Edge device cannot communicate directly with AWS services during the experiment. Additionally, the sensors can only upload data via FTP, and the solution described here doesn't provide an FTP server for the sensors.
- Reason for Rejection: The lack of an FTP server for the sensors and no ability to upload data directly to the device make this solution not viable.
B) Order an AWS Snowcone device, including an Amazon Linux 2 AMI. Connect the device to the local network. Launch an Amazon EC2 instance on the device. Create a shell script that periodically downloads data from each sensor. After the experiment, return the device to AWS so that the data can be loaded as an Amazon Elastic Block Store (Amazon EBS) volume.
- Analysis: The AWS Snowcone device provides local storage and compute capabilities, but it doesn't support a native FTP server. The idea of using a shell script to download data from the sensors assumes a mechanism for the sensors to share data (e.g., FTP, HTTP), but there is no mention of how the sensors would push data to the Snowcone device. Additionally, using EBS as the target for storing data after the experiment is not the most efficient way to move data into S3.
- Reason for Rejection: The solution does not include an FTP server, and it would require manual scripting and management of data transfer, making it overly complex and prone to errors.
C) Order an AWS Snowcone device, including an Amazon Linu...
Author: StarlightBear · Last updated Jul 6, 2026
A company that has multiple business units is using AWS Organizations with all features enabled. The company has implemented an account structure in which each business unit has its own AWS account. Administrators in each AWS account need to view detailed cost and utilization data for their account by using Amazon Athena.
Each business unit can have access to only its own cost and utilization data. The IAM policies that govern the ability to set up AWS Cost and Usage Reports are in pl...
To determine which solution meets the company's requirements with the least operational complexity, let's analyze each option:
Key Requirements:
- Each business unit must have access only to its own cost and utilization data.
- Administrators in each AWS account need to view detailed data using Amazon Athena.
- There is already a central Cost and Usage Report available in an Amazon S3 bucket.
- The solution should have the least operational complexity.
A) In the organization's management account, use AWS Resource Access Manager (AWS RAM) to share the Cost and Usage Report data with each member account.
- Analysis: AWS RAM enables resource sharing across accounts, but sharing Cost and Usage Reports (CUR) is not directly supported by AWS RAM. CURs are stored in an S3 bucket, and RAM typically shares AWS resources (like VPCs or Transit Gateways), not specific S3 objects.
- Reason for Rejection: This option is not feasible because AWS RAM does not support the sharing of S3 data (including the Cost and Usage Report) in the manner required.
B) In the organization's management account, configure an S3 event to invoke an AWS Lambda function each time a new file arrives in the S3 bucket that contains the central Cost and Usage Report. Configure the Lambda function to extract each member account's data and place the data in Amazon S3 under a separate prefix. Modify the S3 bucket policy to allow each member account to access its own prefix.
- Analysis: This solution would work by triggering a Lambda function every time a new file is added to the S3 bucket containing the central Cost and Usage Report. The Lambda function can parse the report, filter the data by account, and store it in separate S3 prefixes for each business unit. The S3 bucket policy can be adjusted to ensure that only the relevant business unit’s administrators can access their specific prefix.
- Reason for Selection: This solution provides granular access control to each account's data and is fully automated. It meets the requirement of having each business unit access only its own cost data while using Athena for querying. However, it involves setting up and maintaining the Lambda function and ensuring the S3 bucket policy is correct. While operational complexity exists due to the Lambda function setup, it...
Author: Nia · Last updated Jul 6, 2026
A company is designing an AWS environment for a manufacturing application. The application has been successful with customers, and the application's user base has increased. The company has connected the AWS environment to the company's on-premises data center through a 1 Gbps AWS Direct Connect connection. The company has configured BGP for the connection.
The company must update the existing net...
In this case, the company needs a solution that ensures high availability, fault tolerance, and security while being cost-effective. Let’s break down each option:
Option A: Add a dynamic private IP AWS Site-to-Site VPN as a secondary path to secure data in transit and provide resilience for the Direct Connect connection. Configure MACsec to encrypt traffic inside the Direct Connect connection.
- Pros:
- Adding a dynamic private IP AWS Site-to-Site VPN creates a secondary path for failover if the Direct Connect connection fails, ensuring high availability.
- The use of MACsec within Direct Connect ensures traffic encryption, increasing security.
- Cons:
- MACsec encryption on Direct Connect could increase costs (as MACsec typically requires additional hardware and can introduce complexity).
- While this solution does provide resilience, maintaining and monitoring two separate connections (Direct Connect and VPN) might be more complex and costly, particularly because Site-to-Site VPN connections, although inexpensive, add additional operational complexity.
Option B: Provision another Direct Connect connection between the company's on-premises data center and AWS to increase the transfer speed and provide resilience. Configure MACsec to encrypt traffic inside the Direct Connect connection.
- Pros:
- A second Direct Connect connection offers high availability and increased resilience.
- Direct Connect connections provide a dedicated, low-latency link to AWS, offering reliability.
- MACsec encryption increases security for data in transit.
- Cons:
- This solution requires provisioning an additional Direct Connect link, which incurs additional cost (Direct Connect is expensive to provision and maintain).
- Does not significantly reduce operational complexity, as you still need to manage two Direct Connect links.
Option C: Configure multiple private VIFs. Load balance data across the VIFs between the on-premises data center and AWS to provide resilience.
- Pros:
- Multiple Virtual Interfaces (VIFs) allow load balancing and provide a l...
Author: Ahmed97 · Last updated Jul 6, 2026
A company needs to modernize an application and migrate the application to AWS. The application stores user profile data as text in a single table in an on-premises MySQL database.
After the modernization, users will use the application to upload video files that are up to 4 GB in size. Other users must be able to download the video files from the application. The company...
To determine the best solution for modernizing and migrating the application to AWS while meeting the given requirements, let's analyze the key requirements:
- Storing large video files (up to 4 GB): The solution must be able to store large video files without affecting application performance.
- Rapid scaling: The solution must scale effectively as the number of videos increases.
- Separation of video storage from user profile data: Storing large video files directly in a database as base64-encoded strings or other inefficient storage methods is generally not ideal, as it can result in bloated database size and slow performance.
- Application performance: Storing videos directly in a database can affect performance; therefore, a solution that allows efficient video storage without compromising the database’s performance is necessary.
Let's evaluate each option:
Option A: Migrate the database to Amazon Aurora PostgreSQL by using AWS Database Migration Service (AWS DMS). Store the videos as base64-encoded strings in a TEXT column in the database.
- Pros: Amazon Aurora PostgreSQL provides a highly scalable database service, and it is a managed service, making migration easier.
- Cons: Storing videos as base64-encoded strings in the database is highly inefficient. Base64 encoding increases the size of the video by about 33%. Additionally, storing large files like videos directly in the database will impact database performance significantly, especially for retrieval and management. This approach will not scale well and would cause serious performance bottlenecks.
- Conclusion: This option is not ideal for storing large video files as it will adversely impact performance and scaling.
Option B: Migrate the database to Amazon DynamoDB by using AWS Database Migration Service (AWS DMS) with the AWS Schema Conversion Tool (AWS SCT). Store the videos as objects in Amazon S3. Store the S3 key in the corresponding DynamoDB item.
- Pros:
- Amazon DynamoDB is a highly scalable NoSQL database that can efficiently handle the application’s user profile data.
- Storing the videos in Amazon S3 is a great choice because S3 is designed for scalable, durable, and cost-effective object storage.
- The application can store only the S3 key in DynamoDB, which reduces the load on the database and optimizes performance.
- Amazon S3 provides rapid scaling for large file storage, ensuring that video file storage grows as needed without im...
Author: Samuel · Last updated Jul 6, 2026
A company stores and manages documents in an Amazon Elastic File System (Amazon EFS) file system. The file system is encrypted with an AWS Key Management Service (AWS KMS) key. The file system is mounted to an Amazon EC2 instance that runs proprietary software.
The company has enabled automatic backups for the file system. The automatic backups use the AWS Backup default bac...
To meet the company's requirement of recovering deleted documents within an RPO of 100 minutes, let's carefully evaluate each option in terms of the necessary backup and recovery strategies.
Key Requirements:
- RPO of 100 minutes: The company needs to recover data with minimal latency, i.e., within 100 minutes of deletion.
- Amazon EFS encrypted with KMS: The backup must ensure that encrypted files remain accessible and recoverable.
- Automatic backups: The company already uses AWS Backup with the default backup plan, but improvements are required to meet the RPO.
A) Create a new IAM role. Create a new backup plan. Use the new IAM role to create backups. Update the KMS key policy to allow the new IAM role to use the key. Implement an hourly backup schedule for the file system.
- Analysis:
- Hourly backup schedule: With backups only occurring every hour, this schedule would result in an RPO of 60 minutes (at best), but it does not meet the strict 100-minute RPO requirement. While close, it’s not sufficient to guarantee recovery within 100 minutes.
- The creation of a new IAM role and backup plan would add complexity but would not address the critical need for more frequent backups to meet the required RPO.
- Conclusion: While it may improve backup management, an hourly backup schedule does not guarantee recovery within the required RPO of 100 minutes. (Rejected)
B) Create a new backup plan. Update the KMS key policy to allow the AWSServiceRoleForBackup IAM role to use the key. Implement a custom cron expression to run a backup of the file system every 30 minutes.
- Analysis:
- Backup every 30 minutes: A backup every 30 minutes would meet the RPO of 100 minutes, as it ensures that recovery is possible within the window of 100 minutes. This frequency offers a better chance of meeting the required recovery time.
- Updating the KMS key policy is necessary to allow the AWS Backup service to access the encrypted EFS file system and backup the data, which is a valid requirement.
- Conclusion: This option meets the 100-minute RPO requirement by...
Author: Chloe · Last updated Jul 6, 2026
A solutions architect must provide a secure way for a team of cloud engineers to use the AWS CLI to upload objects into an Amazon S3 bucket. Each cloud engineer has an IAM user, IAM access keys, and a virtual multi-factor authentication (MFA) device. The IAM users for the cloud engineers are in a group that is ...
In this scenario, the goal is to ensure that the cloud engineers can only perform actions in Amazon S3 if they use Multi-Factor Authentication (MFA), and the solution must integrate well with the AWS CLI for operations like uploading objects into an S3 bucket.
Let's go over each option:
Option A: Attach a policy to the S3 bucket to prompt the IAM user for an MFA code when the IAM user performs actions on the S3 bucket. Use IAM access keys with the AWS CLI to call Amazon S3.
- Pros: This option tries to enforce MFA but does so at the S3 bucket level, which is not how AWS typically enforces MFA for actions through IAM policies. Policies tied to the S3 bucket cannot directly enforce MFA authentication.
- Cons: The S3 bucket policy cannot prompt for MFA directly. MFA must be enforced using IAM policies. Bucket policies are used for managing access to S3 resources and cannot trigger MFA prompts.
- Conclusion: This option will not work as intended because MFA enforcement needs to be done using IAM policies, not S3 bucket policies.
Option B: Update the trust policy for the S3-access group to require principals to use MFA when principals assume the group. Use IAM access keys with the AWS CLI to call Amazon S3.
- Pros: This option suggests requiring MFA for assumed roles (if the user assumes a role), but it doesn’t directly address MFA enforcement for IAM users within the S3-access group.
- Cons: This option modifies the trust policy for assuming roles, but the cloud engineers are not assuming a role in this case. The focus should be on enforcing MFA for the IAM users themselves, not roles.
- Conclusion: This solution is not applicable since the cloud engineers are IAM users, not assuming roles.
Option C: Attach a policy to the S3-access group to deny all S3 actions unless MFA is present. Use IAM access keys with the AWS CLI to call Amazon S3.
- Pros: This solution uses an IAM policy to enforce MFA for S3 actions, which is the correct way to require MFA. By denying a...
Author: Layla · Last updated Jul 6, 2026
A company needs to migrate 60 on-premises legacy applications to AWS. The applications are based on the NET Framework and run on Windows.
The company needs a solution that minimizes migration time and requires no application code changes. Th...
The company needs to migrate 60 legacy applications that are based on the .NET Framework and run on Windows. The requirements are:
1. Minimize migration time: The company doesn't want to spend a lot of time making changes to the existing applications.
2. No application code changes: The legacy applications should be moved as-is without needing any code modifications.
3. No infrastructure management: The company does not want to manage the infrastructure manually.
Let’s analyze each option:
Option A: Refactor the applications and containerize them by using AWS Toolkit for .NET Refactoring. Use Amazon Elastic Container Service (Amazon ECS) with the Fargate launch type to host the containerized applications.
- Pros:
- Containerization using the AWS Toolkit for .NET Refactoring allows the company to move the applications without changing the code.
- Amazon ECS with Fargate allows the company to run containers without managing the underlying infrastructure, as Fargate abstracts infrastructure management.
- Cons:
- Containerization and refactoring are involved in this solution, and while it may reduce management overhead, it still requires time and effort to refactor the applications and make them containerized.
- This might introduce complexity because containerizing legacy .NET Framework applications that were not designed for containers could require additional testing and configuration adjustments, even if no code changes are needed.
- Conclusion: While ECS with Fargate is a great solution for containerized workloads, the refactoring and containerization process may still be time-consuming and involve work beyond what is strictly required (no code changes).
Option B: Use the Windows Web Application Migration Assistant to migrate the applications to AWS Elastic Beanstalk. Use Elastic Beanstalk to deploy and manage the applications.
- Pros:
- AWS Elastic Beanstalk is a Platform as a Service (PaaS) solution that abstracts infrastructure management, which meets the requirement of "no infrastructure management."
- Windows Web Application Migration Assistant is a tool designed for migrating Windows-based applications to Elastic Beanstalk, which can help reduce migration time.
- It allows the applications to run on Windows-based environments, which is suitable for .NET Framework applications.
- Cons:
- Elastic Beanstalk may not be the best choice if the applications have complex dependencies or are not easily containerized for PaaS environments.
- While it’s a simplified platform, Elastic Beanstalk may still require some level of configuration, and migrating legacy applications directly to Elastic Beanstalk...
Author: David · Last updated Jul 6, 2026
A company needs to run large batch-processing jobs on data that is stored in an Amazon S3 bucket. The jobs perform simulations. The results of the jobs are not time sensitive, and the process can withstand interruptions.
Each job must process 15-20 GB of data when the data is stored in the S3 bucket. The company will store the o...
To determine the most cost-effective solution for running large batch-processing jobs with non-time-sensitive data, we must consider the requirements and constraints provided:
Key Requirements:
- The jobs are non-time-sensitive and can withstand interruptions.
- The jobs need to process 15-20 GB of data stored in Amazon S3.
- The output from the jobs will be stored in another S3 bucket for further analysis.
- Cost-effectiveness is a priority.
Option Analysis:
A) Create a serverless data pipeline. Use AWS Step Functions for orchestration. Use AWS Lambda functions with provisioned capacity to process the data.
- Pros:
- Serverless architecture reduces infrastructure management.
- AWS Lambda can automatically scale.
- Cons:
- AWS Lambda has a payload limit of 6 MB (or 256 MB for Lambda@Edge), which is far smaller than the 15-20 GB data per job. Processing this large amount of data in Lambda is impractical, making it unsuitable for the described batch jobs.
B) Create an AWS Batch compute environment that includes Amazon EC2 Spot Instances. Specify the SPOT_CAPACITY_OPTIMIZED allocation strategy.
- Pros:
- EC2 Spot Instances are significantly cheaper than On-Demand Instances and are ideal for non-time-sensitive jobs.
- The SPOT_CAPACITY_OPTIMIZED allocation strategy helps improve the likelihood of Spot Instance availability by optimizing capacity.
- Cons:
- Spot Instances can be interrupted, which might require job retries. However, the jobs are non-time-sensitive and can withstand interruptions.
- While cost-effective, this option requires managing retries and job interruptions, which adds complexity but remains feasible for this case.
C) Cr...
Author: Victoria · Last updated Jul 6, 2026
A company has an application that analyzes and stores image data on premises. The application receives millions of new image files every day. Files are an average of 1 MB in size. The files are analyzed in batches of 1 GB. When the application analyzes a batch, the application zips the images together. The application then archives the images as a single file in an on-premises NFS server for long-term storage.
The company has a Microsoft Hyper-V environment on premises and has compute capacity available. The company does not have storage capacity and wants to archive the images on AWS. The company needs the ability to retrieve archived data within 1 week of a request....
Key Requirements and Constraints:
- The company needs to archive millions of 1 MB image files every day.
- The files are analyzed in batches of 1 GB.
- The company wants to store the images in AWS for long-term archiving.
- Retrieval of archived data needs to occur within 1 week of a request.
- The company has a 10 Gbps AWS Direct Connect connection.
- The company requires bandwidth limits and the ability to schedule copying during non-business hours.
- The company does not have storage capacity on-premises, and they want the archived data to be managed in the cloud efficiently.
Option Analysis:
A) Deploy an AWS DataSync agent on a new GPU-based Amazon EC2 instance. Configure the DataSync agent to copy the batch of files from the NFS on-premises server to Amazon S3 Glacier Instant Retrieval. After the successful copy, delete the data from the on-premises storage.
- Pros:
- S3 Glacier Instant Retrieval provides fast access to archived data, which is not needed since the data retrieval is within a 1-week window.
- DataSync is a high-speed tool that can efficiently copy data from on-premises to AWS.
- Cons:
- GPU-based EC2 instances are unnecessarily expensive for this use case, as there is no need for GPU processing in the image archiving task.
- S3 Glacier Instant Retrieval is designed for more frequent access, which is not required in this case. It is more expensive than necessary for long-term storage.
B) Deploy an AWS DataSync agent as a Hyper-V VM on premises. Configure the DataSync agent to copy the batch of files from the NFS on-premises server to Amazon S3 Glacier Deep Archive. After the successful copy, delete the data from the on-premises storage.
- Pros:
- AWS DataSync agent as a VM on Hyper-V fits the company’s existing infrastructure.
- S3 Glacier Deep Archive is the most cost-effective long-term storage option, ideal for data that is rarely accessed and can withstand a retrieval time of up to 12 hours (well within the 1-week retrieval requirement).
- The company can use bandwidth throttling and scheduling during non-business hours.
- Cons:
- Data retrieval from S3 Glacier Deep Archive...
Author: Daniel · Last updated Jul 6, 2026
A company wants to record key performance indicators (KPIs) from its application as part of a strategy to convert to a user-based licensing schema. The application is a multi-tier application with a web-based UI. The company saves all log files to Amazon CloudWatch by using the CloudWatch agent. All logins to the application are saved in a log file.
As part of the new license schema, the company needs to find ou...
The company needs a solution to track the number of unique users for each client on a daily, weekly, and monthly basis without significant changes to the existing application. Let's evaluate the options based on the requirements and their impact on the application.
Key Requirements:
1. Track unique users: The company needs to track the number of unique users for each client.
2. Time-based tracking: The tracking should be done on a daily, weekly, and monthly basis.
3. Minimal changes to the application: The solution should require the least modification to the existing application, which already sends log files to Amazon CloudWatch using the CloudWatch agent.
A) Configure an Amazon CloudWatch Logs metric filter that saves each successful login as a metric. Configure the user name and client name as dimensions for the metric.
- Analysis:
- Metric filters in CloudWatch Logs allow you to search for specific log patterns and generate custom metrics based on those patterns.
- This approach can work well for detecting successful logins from the log file. By using the user name and client name as dimensions, you can track the number of logins per user and per client.
- However, CloudWatch metric filters are not directly suited for tracking unique users over time. The filter will count the number of events (logins), but it will not guarantee uniqueness because it might count multiple logins from the same user.
- This solution is useful for counting occurrences but would need additional steps or storage for tracking unique users.
- Conclusion: While this solution provides a count of logins, it doesn’t track unique users directly and would require additional processing. (Rejected)
B) Change the application logic to make each successful login generate a call to the AWS SDK to increment a custom metric that records user name and client name dimensions in CloudWatch.
- Analysis:
- This approach requires modifying the application logic to make calls to the AWS SDK every time a user logs in, which goes against the goal of minimizing changes to the application.
- While this would allow you to track user logins and include custom dimensions like user name and client name, modifying the application introduces more complexity and operational overhead.
- Additionally, making SDK calls for each login introduces potential performance overhead and unnecessary changes to the existing application.
- Conclusion: This solution introduces significant changes to the application and adds complexity without providing additional bene...
Author: Henry · Last updated Jul 6, 2026
A company is using GitHub Actions to run a CI/CD pipeline that accesses resources on AWS. The company has an IAM user that uses a secret key in the pipeline to authenticate to AWS. An existing IAM role with an attached policy grants the required permissions to deploy resources.
The company's security team implements a new requirement that pipelines can no longer use long-lived secret ...
Key Requirements:
- Replace long-lived secret keys with a solution for short-lived credentials.
- Minimal operational overhead is preferred.
- The pipeline should still have the ability to authenticate to AWS and assume roles to deploy resources.
Option Analysis:
A) Create an IAM SAML 2.0 identity provider (IdP) in AWS Identity and Access Management (IAM). Create a new IAM role with the appropriate trust policy that allows the sts:AssumeRole API call. Attach the existing IAM policy to the new IAM role. Update GitHub to use SAML authentication for the pipeline.
- Pros:
- SAML 2.0 is a standard identity federation mechanism and can work well for enterprise applications.
- It supports federated login and temporary credentials.
- Cons:
- SAML is generally more complex to implement compared to other options, especially in the context of GitHub Actions. The integration would require setting up a SAML identity provider and the pipeline to authenticate using SAML, which adds overhead.
- This method can be more complex to manage than alternatives like OIDC, making it less ideal for a CI/CD pipeline with minimal operational overhead.
B) Create an IAM OpenID Connect (OIDC) identity provider (IdP) in AWS Identity and Access Management (IAM). Create a new IAM role with the appropriate trust policy that allows the sts:AssumeRoleWithWebIdentity API call from the GitHub OIDC IdP. Update GitHub to assume the role for the pipeline.
- Pros:
- OIDC with GitHub Actions is a simple and modern solution for replacing long-lived secret keys. GitHub natively supports OIDC authentication, so there’s minimal setup required.
- The trust policy for the IAM role can be configured to accept web identity tokens issued by GitHub’s OIDC provider. This is a short-lived and highly secure solution.
- It is a well-integrated, native solution that works seamlessly with GitHub Actions, and it does not require managing secrets.
- Cons:
- None significant, as this is one of the best solutions in terms of simplicity, scalability, and security.
...
Author: Grace · Last updated Jul 6, 2026
A company is running a web-crawling process on a list of target URLs to obtain training documents for machine learning training algorithms. A fleet of Amazon EC2 t2.micro instances pulls the target URLs from an Amazon Simple Queue Service (Amazon SQS) queue. The instances then write the result of the crawling algorithm as a .csv file to an Amazon Elastic File System (Amazon EFS) volume. The EFS volume is mounted on all instances of the fleet.
A separate system adds the URLs to the SQS queue at infrequent rates. The instances crawl each URL in 10 seconds or less.
Met...
Key Requirements:
- Optimize costs by minimizing idle time and resource consumption.
- The fleet of EC2 t2.micro instances is idle when there are no URLs to crawl, which increases costs.
- The process needs to be efficient and cost-effective given the infrequent rate of new URLs being added to the SQS queue.
- The results of the crawling process need to be stored.
Option Analysis:
A) Use m5.8xlarge instances instead of t2.micro instances for the web-crawling process. Reduce the number of instances in the fleet by 50%.
- Pros:
- m5.8xlarge instances provide more CPU and memory than t2.micro, which may improve processing speed.
- Reducing the number of instances by 50% seems to reduce costs in the short term.
- Cons:
- Expensive solution: Using m5.8xlarge instances for web crawling would increase costs significantly, especially given the infrequent rate of URLs. The larger instances would still be idle when there are no URLs, resulting in wasted resources.
- This is not the most cost-effective solution since the goal is to minimize idle time and resource utilization, and this change only increases costs without addressing the root cause (idle time due to infrequent URLs).
B) Convert the web-crawling process into an AWS Lambda function. Configure the Lambda function to pull URLs from the SQS queue.
- Pros:
- Lambda is serverless, so it only runs when there are URLs to crawl, eliminating idle time and the need for continuously running EC2 instances.
- It automatically scales, so if there are no URLs, no compute resources are being used, which reduces costs.
- You pay for only the execution time, which is a more cost-efficient solution for this use case.
- AWS Lambda integrates well with SQS, and it can pull URLs from the queue and process them directly.
- Cons:
- Lambda has some limitations (e.g., execution time limits of 15 minutes), but it should work well for crawling tasks that take 10 seconds or less.
- Lambda functions would require a slight modification in the process to fit within its execution model, but this will ultimately result in lower operational overhead and cost.
- Conclusion: This option is highly cost-effective...
Author: Evelyn · Last updated Jul 6, 2026
A company needs to migrate its website from an on-premises data center to AWS. The website consists of a load balancer, a content management system (CMS) that runs on a Linux operating system, and a MySQL database.
The CMS requires persistent NFS-compatible storage for a file system. The new solution on AWS must be able to scale from 2 Amazon EC2 instances to 30 EC2 instances in response to...
Let's break down the key requirements:
1. No changes to the website: This implies that the architecture must be compatible with the existing CMS, MySQL, and load balancing setup.
2. Persistent NFS-compatible storage: The CMS needs access to a persistent shared storage system that is compatible with the NFS protocol.
3. Scalable from 2 to 30 EC2 instances: The solution must automatically scale up and down with varying traffic loads.
4. Prevent data loss: Any database or file storage solution must ensure that data is retained in the event of instance failures or scaling events.
Now, let’s evaluate the options:
---
Option A: EFS, Elastic Beanstalk, Aurora MySQL
- Amazon Elastic File System (EFS): This is a managed NFS-compatible file system, which meets the requirement for persistent shared storage.
- Elastic Beanstalk: This service simplifies deployment and scaling, and it supports Auto Scaling groups. It also automatically integrates with an Application Load Balancer.
- Amazon Aurora MySQL: This is a fully managed, scalable relational database, which ensures high availability and data durability. Aurora can also handle scaling, which is a requirement here.
Why this works:
- EFS provides NFS-compatible persistent storage.
- Elastic Beanstalk simplifies scaling from 2 to 30 EC2 instances without the need for manual intervention.
- Aurora MySQL provides a highly available and managed MySQL database, which is crucial to prevent data loss.
Why not others:
- This solution matches all the requirements and uses fully managed AWS services.
---
Option B: EBS Multi-Attach, Elastic Beanstalk, RDS MySQL
- EBS Multi-Attach: Allows an EBS volume to be attached to multiple EC2 instances, which may provide persistence, but it’s not NFS-compatible. This is an issue, as the CMS requires NFS storage.
- Elastic Beanstalk: As in Option A, this simplifies the scaling process.
- Amazon RDS for MySQL: A managed My...
Author: IronLion88 · Last updated Jul 6, 2026
A company needs to implement disaster recovery for a critical application that runs in a single AWS Region. The application's users interact with a web frontend that is hosted on Amazon EC2 instances behind an Application Load Balancer (ALB). The application writes to an Amazon RDS for MySQL DB instance. The application also outputs processed documents that are stored in an Amazon S3 bucket.
The company's finance team directly queries the database to run reports. During busy periods, these queries consume resources and negatively affect application performance.
A solutions ...
To solve the disaster recovery problem while also addressing performance issues caused by the office team's database queries, let’s analyze the requirements and evaluate each option.
Key Requirements:
1. Disaster Recovery (DR): Ensure that the application remains operational during a disaster, with minimal downtime and data loss.
2. Minimize Data Loss: The solution should prevent data loss, particularly for the RDS database and S3 bucket.
3. Resolve Performance Issues: Address the problem where the office team's queries negatively affect application performance.
4. Seamless Transition: The application should be able to recover quickly in the event of a disaster with minimal manual intervention.
Option A: Migrate to DynamoDB, Use Global Tables, S3 Replication
- DynamoDB: This option suggests migrating the database from RDS MySQL to Amazon DynamoDB. While DynamoDB is a NoSQL database with strong scalability, it would require significant application changes, especially since the application relies on MySQL. Migrating away from MySQL would likely involve a major reengineering effort.
- Global Tables: While DynamoDB Global Tables provide disaster recovery with replication across multiple regions, this introduces complexity and would not resolve the issue of running reports against the MySQL database.
- Lambda Syncing S3: Using Lambda to periodically sync S3 buckets across regions would replicate the data, but there are better ways to ensure S3 data availability without introducing a new technology stack like DynamoDB.
Why not this option?
- The need to migrate to DynamoDB would require substantial changes to the application and the MySQL database, making it an inappropriate solution. Additionally, using DynamoDB doesn't align with minimizing data loss in the MySQL database.
---
Option B: Read Replica, Read Queries Against Replica, S3 Replication
- Read Replica: Creating a read replica of the RDS MySQL database in another region addresses both disaster recovery and performance concerns. The read replica can handle the office team's read queries without impacting the primary database performance, and in case of a disaster, it can be promoted to the primary database.
- S3 Cross-Region Replication (CRR): CRR ensures that the data in the S3 bucket is replicated to another region, which provides a backup in case of a regional failure.
- Disaster Recovery: During a disaster, the read replica can be promoted to a primary DB instance, and the application can switch to the replicated S3 bucket.
Why this works?
- The solution minimizes data loss by providing cross-region replication for both the database and S3 data.
- The read replica alleviates performance issues by offloading report queries from the primary database to the replica.
- This solution is fully compatible with the existing application setup, requiring minimal changes.
---
Option C: Read Replica, S3 Replication, AMIs for EC2
- Read R...
Author: Sofia2021 · Last updated Jul 6, 2026
A company has many services running in its on-premises data center. The data center is connected to AWS using AWS Direct Connect (DX) and an IPSec VPN. The service data is sensitive and connectivity cannot traverse the internet. The company wants to expand into a new market segme...
To meet the requirements of expanding the company's services to other AWS users while ensuring the connectivity does not traverse the internet, let's break down the needs and evaluate each option.
Key Requirements:
1. Sensitive Data: The data is sensitive, meaning it cannot traverse the public internet.
2. Connectivity over AWS Direct Connect (DX): The existing connection to AWS is via AWS Direct Connect (DX) and an IPSec VPN. This ensures private, dedicated connections that do not traverse the internet.
3. Offer Services to Other Companies Using AWS: The company wants to make its services available to other AWS customers, which likely involves allowing them to access the service securely.
Option A: VPC Endpoint Service with TCP Traffic and Network Load Balancer (NLB)
- VPC Endpoint Service: This allows services to be made available to other AWS customers securely over private connections, using the AWS PrivateLink technology.
- TCP Traffic: The VPC Endpoint Service can accept TCP traffic, which makes it flexible for various types of services, not limited to HTTP/S protocols.
- Network Load Balancer (NLB): This is an ideal choice for handling TCP traffic because NLB is designed to handle high-performance, low-latency TCP traffic.
- Available Over DX: The VPC Endpoint Service can be connected to via AWS Direct Connect, ensuring that the traffic does not traverse the internet but instead uses the private connection.
Why this works:
- Private Connectivity: The service is accessible securely and privately using Direct Connect and does not require internet traversal.
- Scalability and Security: PrivateLink ensures that the service is securely exposed to other AWS accounts without exposing the internal network to the internet.
Why not others?
- This solution fits the requirement of securely offering services to other AWS customers without exposing traffic to the internet.
---
Option B: VPC Endpoint Service with HTTP/HTTPS Traffic and Application Load Balancer (ALB)
- VPC Endpoint Service with HTTP/HTTPS Traffic: This would work for web-based services that require HTTP/HTTPS.
- Application Load Balancer (ALB): ALB is suitable for handling HTTP/HTTPS traffic and provides advanced routing features (e.g., path-based routing).
- Available Over DX: The VPC Endpoint Service can still be connected through Direct Connect.
Why this works:
...
Author: Sofia · Last updated Jul 6, 2026
A company uses AWS Organizations to manage its AWS accounts. A solutions architect must design a solution in which only administrator roles are allowed to use IAM actions. However, the solutions architect does not have access to all the AWS accoun...
To meet the company's requirement of allowing only administrator roles to use IAM actions across all AWS accounts with the least operational overhead, let's analyze each option carefully.
Key Requirements:
1. Restrict IAM actions: Only administrator roles should be allowed to perform IAM actions.
2. Minimal operational overhead: The solution must be easy to implement and maintain, considering the company uses AWS Organizations and the solutions architect doesn't have access to all AWS accounts.
3. Account-wide application: The solution needs to apply across all AWS accounts managed under the AWS Organization.
A) Create an SCP that applies to all the AWS accounts to allow IAM actions only for administrator roles. Apply the SCP to the root OU.
- Analysis:
- Service Control Policies (SCPs) are used to manage permissions in AWS Organizations. However, SCPs allow or deny actions across accounts at an organizational level.
- The key challenge here is that SCPs cannot allow actions only for a specific set of roles (like administrator roles) but rather define the overall allowed or denied actions.
- Allowing IAM actions only for administrator roles cannot be directly implemented via SCPs since SCPs operate on actions and not specific IAM roles.
- Conclusion: This approach would not work because SCPs cannot target specific roles for permission grants or denials, and thus cannot restrict IAM actions to only administrator roles. (Rejected)
B) Configure AWS CloudTrail to invoke an AWS Lambda function for each event that is related to IAM actions. Configure the function to deny the action if the user who invoked the action is not an administrator.
- Analysis:
- AWS CloudTrail can log IAM actions, and Lambda can be used to process events from CloudTrail.
- While this solution may seem viable, it would add significant complexity and operational overhead. This setup would require creating a Lambda function, monitoring CloudTrail logs, and taking action dynamically, all of which adds complexity. It also may introduce delays in processing IAM actions because the actions would need to be intercepted and checked after the fact.
- Additionally, maintaining such a Lambda-based solution across multiple AWS accounts would be cumbersome, especially without access to all the accounts.
- Conclusion: While technically feasible, this approach introduces unnecessary operational overhead and is less efficien...
Author: VioletCheetah55 · Last updated Jul 6, 2026
A company uses an organization in AWS Organizations to manage multiple AWS accounts. The company hosts some applications in a VPC in the company's shared services account.
The company has attached a transit gateway to the VPC in the shared services account.
The company is developing a new capability and has created a development environment that requires access to the applications that are in the shared services account. The company intends to delete and recreate resources frequently i...
Problem Analysis:
- The company has a shared services account hosting applications in a VPC, and a development account needs frequent access to these applications.
- The development team needs the ability to recreate the connection to the shared services account as resources are deleted and recreated frequently in the development environment.
- The solution must allow self-service for the development team to manage the connection to the shared services account.
Key Requirements:
1. Recreate Resources: The development team needs the ability to delete and recreate resources, including the connection, frequently.
2. Self-Service: The development team should be able to manage their connection to the shared services account independently.
3. Minimal Manual Interventions: The solution should allow the team to quickly re-establish the connection without requiring manual intervention from others.
---
Option A: Create a transit gateway in the development account and peer it with the shared services account
- Transit Gateway Peering: This involves creating a new transit gateway in the development account and peering it with the shared services account's transit gateway.
- Manual Setup: While peering requests can be automated, there would still be manual setup required for both sides of the peering, and you need to ensure that the shared services account is configured to accept peering requests automatically.
- Frequent Recreation: Since the development environment involves frequent deletion and recreation of resources, managing the peering manually each time can become cumbersome.
Why not this option?
- While the solution could work, it does not fully meet the need for self-service and ease of re-establishment, as it involves manual configuration each time a new connection is required.
---
Option B: Use AWS RAM to share the transit gateway and create a transit gateway attachment in the development account
- Resource Sharing with AWS RAM: AWS RAM can be used to share the transit gateway from the shared services account to the development account. This allows the development account to use the shared transit gateway without needing to create a new one.
- Automatic Acceptance: Automatic acceptance of resource sharing in AWS RAM ensures the connection is readily available in the development account, which is a good fit for self-service.
- Frequent Recreation: This solution allows the development team to accept the shared resource and attach it to their VPC whenever needed, supporting the frequent creation and deletion of resources in the development account.
Why this works:
- Minimal Manual Configuration: This solution meets the self-service requirement because the development account can accept the resource and manage the attachment without needing manual intervention.
- Frequent Resource D...
Author: Ahmed97 · Last updated Jul 6, 2026
A company wants to migrate virtual Microsoft workloads from an on-premises data center to AWS. The company has successfully tested a few sample workloads on AWS. The company also has created an AWS Site-to-Site VPN connection to a VPC. A solutions architect needs to generate a total cost of ownership (TCO) report for the migration of all the workloads from the data center.
Simple Network Management Protocol (SNMP) has been enabled on each VM in the data center. The company can...
To meet the company's requirements, the solution must allow for the automatic import of discovery data into AWS Migration Hub, the ability to generate a TCO report, and it must work without installing additional software on the existing virtual machines (VMs). The company has already enabled SNMP on each VM, which allows for monitoring but does not enable any additional agents or software installations.
Let’s break down the options:
A) Use the AWS Application Migration Service agentless service and the AWS Migration Hub Strategy Recommendations to generate the TCO report.
- The AWS Application Migration Service allows for the migration of workloads to AWS, but it’s more focused on replicating and migrating workloads, rather than generating a TCO report.
- While AWS Migration Hub Strategy Recommendations can help plan a migration strategy, it doesn’t directly facilitate automatic discovery of the VMs in the on-premises data center, and it doesn't have a built-in mechanism to generate the TCO report by itself.
- This option is not ideal because the Application Migration Service focuses on migration itself, and doesn't offer automatic TCO reporting through the existing setup.
B) Launch a Windows Amazon EC2 instance. Install the Migration Evaluator agentless collector on the EC2 instance. Configure Migration Evaluator to generate the TCO report.
- This option involves launching an EC2 instance and installing the Migration Evaluator agentless collector, which is specifically designed to assess existing on-premises workloads for migration to AWS and generate a TCO report.
- It works in an agentless manner by using SNMP data from the VMs to import discovery data into AWS Migration Hub. However, the option mentions installing software on the EC2 instance, which might conflict with the requirement that no additional software be installed on the VMs themselves.
- This solution works for gathering the necessary data from the data center but might not complet...
Author: Oliver · Last updated Jul 6, 2026
A company that is developing a mobile game is making game assets available in two AWS Regions. Game assets are served from a set of Amazon EC2 instances behind an Application Load Balancer (ALB) in each Region. The company requires game assets to be fetched from the closest Region. If game assets become unavailable ...
The company's requirements are:
- Serve game assets from the closest Region to the player.
- If the assets become unavailable in the closest Region, fall back to the other Region.
Let’s evaluate each option:
A) Create an Amazon CloudFront distribution. Create an origin group with one origin for each ALB. Set one of the origins as primary.
- CloudFront is a content delivery network (CDN) that caches assets at edge locations, improving performance.
- An origin group in CloudFront can allow failover between multiple origins (ALBs in this case). This option seems to fulfill the requirement of fetching assets from the closest Region, and if one Region becomes unavailable, CloudFront can automatically failover to the secondary Region.
- This option is solid because CloudFront inherently supports caching and can automatically failover between multiple ALBs via origin groups, ensuring both proximity and availability.
B) Create an Amazon Route 53 health check for each ALB. Create a Route 53 failover routing record pointing to the two ALBs. Set the Evaluate Target Health value to Yes.
- Route 53 failover routing enables directing traffic to a primary resource, with failover to a secondary resource if the primary fails, based on health checks.
- This setup will make sure that if one ALB becomes unavailable, the traffic is routed to the other ALB. However, failover routing is not designed for latency-based routing, and it doesn't ensure the game assets are served from the closest Region; it only responds to availability issues.
- This option would work for availability but does not address latency concerns of serving assets from the closest Region.
C) Create two Amazon CloudFront distributions, each with one ALB as the origin. Create an Amazon Route 53 failover routing record pointing to the two CloudFront distributions....
Author: Manish · Last updated Jul 6, 2026
A company deploys workloads in multiple AWS accounts. Each account has a VPC with VPC flow logs published in text log format to a centralized Amazon S3 bucket. Each log file is compressed with gzip compression. The company must retain the log files indefinitely.
A security engineer occasionally analyzes the logs by using Amazon Athena to query the VPC flow logs. The query performance is degrading over time as the number of ingested logs is growing. A solutions ar...
To improve performance when querying VPC flow logs with Athena and reduce storage space usage, it's important to focus on both data storage format optimization and query efficiency. Let’s analyze each option based on these goals:
A) Create an AWS Lambda function to decompress the gzip files and to compress the files with bzip2 compression. Subscribe the Lambda function to an s3:ObjectCreated:Put S3 event notification for the S3 bucket.
- Lambda decompression: While decompressing files and changing compression formats (from gzip to bzip2) could slightly improve query performance, it’s unlikely to provide significant performance improvements in Athena. Both gzip and bzip2 are compression formats, but compression format optimization alone won't make a big difference for Athena queries.
- Inefficient and unnecessary: Decompressing and recompressing logs adds unnecessary complexity, and this approach doesn't address Athena’s need for efficient query execution on structured data.
- Query performance: The major bottleneck in Athena performance is how the data is organized and partitioned, not just the compression format.
B) Enable S3 Transfer Acceleration for the S3 bucket. Create an S3 Lifecycle configuration to move files to the S3 Intelligent-Tiering storage class as soon as the files are uploaded.
- S3 Transfer Acceleration: This feature accelerates the transfer of data into S3, but it doesn’t affect the performance of Athena queries. It’s more about improving upload speed, not the actual query performance.
- S3 Intelligent-Tiering: This storage class automatically moves data between frequent and infrequent access tiers based on usage patterns, but this does not help with optimizing query performance in Athena.
- Not related to Athena performance: Transfer acceleration and storage class changes don’t address the issue of improving query performance when querying large datasets in Athena.
C) Update the VPC flow log configuration to store the files in Apache Parquet format. Specify hourly partitions for the lo...
Author: VioletCheetah55 · Last updated Jul 6, 2026
A company wants to establish a dedicated connection between its on-premises infrastructure and AWS. The company is setting up a 1 Gbps AWS Direct Connect connection to its account VPC. The architecture includes a transit gateway and a Direct Connect gateway to connect multiple VPCs and the on-premises infrastructure.
The company must connect ...
In this scenario, the company is setting up AWS Direct Connect to establish a dedicated connection between its on-premises infrastructure and AWS. The architecture involves a transit gateway and a Direct Connect gateway to connect multiple VPCs and the on-premises infrastructure. The company needs to connect to VPC resources over a transit virtual interface (VIF) using the Direct Connect connection.
Let’s evaluate each option:
A) Update the 1 Gbps Direct Connect connection to 10 Gbps.
- Unnecessary change: The company is using a 1 Gbps Direct Connect connection, but there’s no specific mention that the 1 Gbps connection is insufficient or a bottleneck. If the connection meets the needs of the workloads and the performance requirements, there is no need to upgrade to 10 Gbps unless there is a known performance issue or capacity requirement.
- Not related to meeting the transit VIF connection requirement: Increasing the connection speed to 10 Gbps won’t impact the ability to connect to VPC resources over the transit VIF.
B) Advertise the on-premises network prefixes over the transit VIF.
- Correct step: When using AWS Direct Connect with a transit VIF, the on-premises network prefixes must be advertised over the transit VIF to enable communication between the on-premises infrastructure and the VPCs connected via the transit gateway.
- Required action: This step ensures that traffic can be routed between the on-premises infrastructure and the VPCs via the Direct Connect connection.
C) Advertise the VPC prefixes from the Direct Connect gateway to the on-premises network over the transit VIF.
- Correct step: In order for the on-premises network to route traffic to resources in the VPC, the VPC prefixes (IP ranges) must be advertised from the Direct Connect gateway to the on-premises network. This ensures proper ro...
Author: Julian · Last updated Jul 6, 2026
A company wants to use Amazon WorkSpaces in combination with thin client devices to replace aging desktops. Employees use the desktops to access applications that work with Clinical trial data. Corporate security policy states that access to the applications must be restricted to only company branch office locations. The company is cons...
To address the company's requirements of restricting access to applications on Amazon WorkSpaces from only specific branch office locations, while maintaining operational efficiency, we must focus on solutions that offer centralized, scalable control over access without introducing unnecessary complexity.
Let's evaluate each option:
A) Create an IP access control group rule with the list of public addresses from the branch offices. Associate the IP access control group with the WorkSpaces directory.
- Correct approach for limiting access: Amazon WorkSpaces supports the use of IP access control groups to restrict access based on IP addresses. By creating a rule with the list of public IP addresses from the branch offices and associating this rule with the WorkSpaces directory, access can be limited to only those locations.
- Operational efficiency: This solution is highly efficient because it is simple to implement, centrally managed, and scalable. The list of IPs can be easily updated as branch office locations change, such as when a new office is added.
- Scalability: Adding new branch offices is straightforward by updating the IP access control group, so this solution will also scale well.
- Most suitable option: This option provides the simplest and most efficient way to meet the security requirements.
B) Use AWS Firewall Manager to create a web ACL rule with an IPSet with the list of public addresses from the branch office locations. Associate the web ACL with the WorkSpaces directory.
- AWS Firewall Manager: AWS Firewall Manager is primarily used for managing security rules across multiple accounts or regions, and it works in conjunction with services like AWS WAF (Web Application Firewall). However, AWS Firewall Manager is designed for managing web traffic and is not suited for Amazon WorkSpaces, which operates over non-web protocols like RDP or PCoIP.
- Not ideal for this scenario: Since WorkSpaces does not rely on web protocols for access, using AWS WAF and Firewall Manager is not a natural fit, making this solution unnecessarily complex and not directly aligned wi...
Author: Ella · Last updated Jul 6, 2026
A company uses AWS Organizations. The company runs two firewall appliances in a centralized networking account. Each firewall appliance runs on a manually configured highly available Amazon EC2 instance. A transit gateway connects the VPC from the centralized networking account to VPCs of member accounts. Each firewall appliance uses a static private IP address that is then used to route traffic from the member accounts to the internet.
During a recent incident, a badly configured script initiated the termination of both firewall appliances. During the rebuild of the firewall appliances, the company wrote a new script to configure the firewall appliances at startup.
The company wants to modernize the deployment of the firewall appliances. The firewall appliances need the ability to scale horizontally to handle increased traffic when the netw...
To modernize the deployment of the firewall appliances and ensure horizontal scalability, the company needs a solution that accommodates traffic scaling while maintaining the firewall's function in compliance with company policies. The solution must also be cost-effective.
Option Breakdown:
A) Deploy a Gateway Load Balancer in the centralized networking account. Set up an endpoint service that uses AWS PrivateLink.
- Explanation: A Gateway Load Balancer (GWLB) is ideal for use with virtual appliances like firewalls, as it is specifically designed to integrate with appliances that handle network traffic at scale. Using AWS PrivateLink allows secure, private communication between VPCs. This setup facilitates traffic routing to the firewall appliances efficiently, and ensures high availability and scalability.
- Why it's selected: This option is designed for scenarios requiring network appliance integration, offering flexibility in managing traffic across multiple VPCs and ensuring scalability.
- Why others are rejected: This is a tailored solution for network appliances, and it supports horizontal scaling effectively. Other options may not directly address the need for scalable appliance deployments.
B) Deploy a Network Load Balancer in the centralized networking account. Set up an endpoint service that uses AWS PrivateLink.
- Explanation: While a Network Load Balancer (NLB) is suitable for distributing traffic to instances, it does not provide the level of integration and optimization that the Gateway Load Balancer (GWLB) provides for network appliances like firewalls.
- Why it's rejected: NLBs are more general-purpose and not optimized for integration with specialized appliances like firewalls. The GWLB is specifically designed for network appliances, which is a better fit.
C) Create an Auto Scaling group and a launch template that uses the new script as user data to configure the firewall appliances. Create a target group that uses the instance target type.
- Explanation: This option allows for horizontal scaling by automatically adding or removing EC2 instances based on traffic demand. The user data script ensures that the firewall appliance is configured when the instance starts, which is useful for automation. The instance target type ensures that EC2 instances are correctly registered with the target group in the load balancer.
- Why it's selected: This ensures scalable deployment of EC2 instances running the firewall appliances. It provides elasticity and allows the firewall appliances to scale based on network load.
- Why others ...
Author: Aria · Last updated Jul 6, 2026
A solutions architect must implement a multi-Region architecture for an Amazon RDS for PostgreSQL database that supports a web application. The database launches from an AWS CloudFormation template that includes AWS services and features that are present in both the primary and secondary Regions.
The database is configured for automated backups, and it has an RTO of 15 minutes and an RPO of 2 hours. The web application is configured t...
To meet the requirements for a highly available multi-Region architecture for Amazon RDS for PostgreSQL with a 15-minute RTO (Recovery Time Objective) and a 2-hour RPO (Recovery Point Objective), we need to ensure that the architecture can handle failover scenarios efficiently and with minimal downtime while maintaining data consistency. Let's analyze the available options:
Option A: Create a cross-Region read replica of the database in the secondary Region. Configure an AWS Lambda function in the secondary Region to promote the read replica during a failover event.
- Pros: Creating a cross-Region read replica provides a near-real-time copy of the primary database. This solution fits well with the 2-hour RPO requirement, as read replicas are updated asynchronously, allowing for relatively recent data to be available in the secondary Region. Promoting the read replica to a primary database during a failover event minimizes downtime, which aligns with the 15-minute RTO requirement.
- Cons: It relies on a manual intervention (via AWS Lambda) to promote the read replica, which could be delayed or fail if not implemented correctly.
- Use case: This is a valid option as it helps in setting up a multi-Region failover strategy by promoting a read replica when the primary database fails.
Option B: In the primary Region, create a health check on the database that will invoke an AWS Lambda function when a failure is detected. Program the Lambda function to recreate the database from the latest database snapshot in the secondary Region and update the Route 53 host records for the database.
- Pros: This option offers a fully automated approach by triggering a Lambda function to create a new database in the secondary Region from the latest snapshot during a failure event.
- Cons: This solution introduces higher recovery time compared to promoting a read replica. The process of creating a new database from a snapshot takes time, potentially violating the 15-minute RTO. Additionally, this approach may cause some data loss beyond the 2-hour RPO because the snapshot may not be perfectly aligned with the last committed transactions before the failure.
- Use case: While it can provide a failover solution, the time required to restore the database from a snapshot could lead to an unacceptable RTO, making it less suitable for this scenario.
Option C: Create an AWS Lambda function to copy the latest automated backup to the secondary Region every 2 hours.
- Pros: This could help with ensuring that recent backups are available in the secondary Region.
- Cons: Copying backups every 2 hours would only fulfill the RPO requirement but does not address the failover mec...
Author: Charlotte · Last updated Jul 6, 2026
An ecommerce company runs an application on AWS. The application has an Amazon API Gateway API that invokes an AWS Lambda function. The data is stored in an Amazon RDS for PostgreSQL DB instance.
During the company's most recent flash sale, a sudden increase in API calls negatively affected the application's performance. A solutions architect reviewed the Amazon CloudWatch metrics during that time and noticed a significant increase in ...
The company is experiencing performance issues during periods of high traffic, as indicated by the high CPU utilization on the database and a significant increase in Lambda invocations and database connections. The issue appears to be related to the database struggling with the load due to frequent database connections from the Lambda function. We need to recommend a solution that addresses these performance bottlenecks while maintaining the application’s scalability.
Option A: Increase the memory of the Lambda function. Modify the Lambda function to close the database connections when the data is retrieved.
- Pros: Increasing the memory of the Lambda function can help reduce the function's execution time, which may help in some cases. However, this only addresses the Lambda execution time and not the root cause of the database performance issues, which is the excessive number of database connections.
- Cons: Modifying the Lambda function to close the database connections properly is important, but it does not address the issue of the database being overwhelmed with too many simultaneous connections, particularly during high traffic periods.
- Use case: This approach is partially useful but doesn’t tackle the larger issue of excessive database connections causing high CPU utilization on the database.
Option B: Add an Amazon ElastiCache for Redis cluster to store the frequently accessed data from the RDS database.
- Pros: Using ElastiCache for Redis can offload frequent read traffic from the RDS database by caching frequently accessed data. This can significantly reduce the number of database queries and, in turn, reduce the load on the database during high traffic periods.
- Cons: While caching frequent reads can reduce database load, this doesn’t address the issue of managing database connections. The database may still suffer from performance issues related to connection management, which is a root cause of the high CPU utilization in this case.
- Use case: This approach is great for reducing read load on the database, but it doesn't resolve the connection management problem or optimize the interaction between Lambda and RDS.
Option C: Create an RDS proxy by usi...
Author: Victoria · Last updated Jul 6, 2026
A retail company wants to improve its application architecture. The company's applications register new orders, handle returns of merchandise, and provide analytics. The applications store retail data in a MySQL database and an Oracle OLAP analytics database. All the applications and databases are hosted on Amazon EC2 instances.
Each application consists of several components that handle different parts of the order process. These components use incoming data from different sources. A separate ETL job runs every week and copies data from each application to the a...
To design an event-driven solution that provides near real-time analytics using serverless services, we need to focus on minimizing management overhead while leveraging the right AWS serverless services to handle the incoming data, application components, and analytics. Let’s analyze each option:
Option A: Migrate the individual applications as microservices to Amazon Elastic Container Service (Amazon ECS) containers that use AWS Fargate. Keep the retail MySQL database on Amazon EC2. Move the analytics database to Amazon Neptune. Use Amazon Simple Queue Service (Amazon SQS) to send all the incoming data to the microservices and the analytics database.
- Pros: ECS with AWS Fargate is a good option for running microservices with serverless compute, as it abstracts away infrastructure management. Amazon SQS can be used for decoupling application components and enabling an event-driven architecture.
- Cons: Keeping the retail MySQL database on EC2 is not optimal for a serverless solution. Additionally, Amazon Neptune is a graph database designed for complex relationships, which is not ideal for retail data like orders or merchandise, which are typically relational. Also, SQS might not be ideal for near real-time analytics; something like Amazon EventBridge would be more suitable for this use case.
- Use case: This option is not optimal because it doesn't fully embrace serverless services for the databases and uses an inappropriate database (Neptune) for analytics.
Option B: Create an Auto Scaling group for each application. Specify the necessary number of EC2 instances in each Auto Scaling group. Migrate the retail MySQL database and the analytics database to Amazon Aurora MySQL. Use Amazon Simple Notification Service (Amazon SNS) to send all the incoming data to the correct EC2 instances and the analytics database.
- Pros: Aurora MySQL is a good choice for the retail database, and SNS is useful for event-driven architectures. Aurora MySQL also offers some serverless capabilities.
- Cons: The use of EC2 instances and Auto Scaling groups for each application does not align with a serverless model, which is part of the requirement. Additionally, using SNS to directly send data to EC2 instances complicates the architecture and reduces the overall scalability and flexibility of the solution.
- Use case: This option requires managing EC2 instances, which is against the goal of using serverless services for easier scalability and reduced management overhead. It also doesn't leverage the full potential of serverless analytics and event-driven services.
Option C: Migrate the individual applications as microservices to Amazon Elastic Kubernet...
Author: Lucas · Last updated Jul 6, 2026
A company is planning a migration from an on-premises data center to the AWS Cloud. The company plans to use multiple AWS accounts that are managed in an organization in AWS Organizations. The company will create a small number of accounts initially and will add accounts as needed. A solutions architect must design a sol...
When designing a solution to turn on AWS CloudTrail across multiple AWS accounts managed in AWS Organizations, the solution needs to be operationally efficient, scalable, and easy to manage as new accounts are added. Let's evaluate the options:
Option A: Create an AWS Lambda function that creates a new CloudTrail trail in all AWS accounts in the organization. Invoke the Lambda function daily by using a scheduled action in Amazon EventBridge.
- Pros: The Lambda function can automate the process of creating CloudTrail trails in each account. It is flexible and can be scheduled to run daily.
- Cons: This approach involves a manual process (Lambda triggered daily), which can lead to delays in setting up new accounts. Additionally, this approach introduces the potential for errors, as the Lambda function would need to handle all aspects of creating and managing trails in every account. There are also risks involved with ensuring that the Lambda function is up-to-date and correctly deployed across all accounts.
- Use case: This approach is not the most operationally efficient, as it requires periodic intervention (daily invocation) and manual management.
Option B: Create a new CloudTrail trail in the organization's management account. Configure the trail to log all events for all AWS accounts in the organization.
- Pros: This solution is highly operationally efficient because a single CloudTrail trail in the management account can log events from all accounts within the AWS Organization. It centralizes CloudTrail logging for all accounts and ensures that every event is captured in a single trail.
- Cons: This option requires careful configuration of the trail in the management account to log events across the entire organization. However, it does not require creating multiple trails in each account, reducing the complexity.
- Use case: This is the most operationally efficient and scalable option. Once the trail is set up in the management account, it automatically captures events for all accounts in the organization, ensuring compliance without the need for ongoing manual intervention.
Option C: Create a n...
Author: Zain · Last updated Jul 6, 2026
A software development company has multiple engineers who are working remotely. The company is running Active Directory Domain Services (AD DS) on an Amazon EC2 instance. The company's security policy states that all internal, nonpublic services that are deployed in a VPC must be accessible through a VPN. Mu...
In this scenario, the company has specific requirements for securing access to internal services via VPN with Multi-Factor Authentication (MFA). The goal is to integrate the VPN solution with Active Directory Domain Services (AD DS) to ensure secure, controlled access to the resources. Let’s evaluate each option carefully:
Option A: Create an AWS Site-to-Site VPN connection. Configure integration between a VPN and AD DS. Use an Amazon WorkSpaces client with MFA support enabled to establish a VPN connection.
- Analysis: The AWS Site-to-Site VPN is typically used for establishing a connection between on-premises networks and AWS. It is not designed for direct user access, but more for site-to-site communication. Amazon WorkSpaces can use MFA for remote desktop connections, but this option doesn’t fully address the need for secure, direct user VPN access to the VPC.
- Why rejected: This option doesn’t align with the need to provide secure, MFA-enabled VPN access for remote users. Site-to-Site VPN is not suitable for this specific scenario, where individual user access is required.
Option B: Create an AWS Client VPN endpoint. Create an AD Connector directory for integration with AD DS. Enable MFA for AD Connector. Use AWS Client VPN to establish a VPN connection.
- Analysis: AWS Client VPN is a managed VPN service that allows users to securely connect to resources in an AWS VPC. It can integrate with Active Directory (via AD Connector) to authenticate users. Additionally, AWS Client VPN supports MFA for added security. The integration with AD DS ensures that users are authenticated using company credentials, and MFA adds another layer of security.
- Why selected: This option meets the requirements perfectly. It enables secure VPN access with MFA support, integrates with AD DS using AD Connector, and provides...
Author: Isabella1 · Last updated Jul 6, 2026
A company is running a three-tier web application in an on-premises data center. The frontend is served by an Apache web server, the middle tier is a monolithic Java application, and the storage tier is a PostgreSQL database.
During a recent marketing promotion, customers could not place orders through the application because the application crashed. An analysis showed that all three tiers were overloaded. The application became unresponsive, and the database reached its capacity limit because of read operations. The company already has several similar promotions scheduled in the n...
To resolve the issues caused by overloads during marketing promotions and ensure scalability for future events, the company needs to migrate its three-tier web application to AWS. The goal is to minimize operational effort while maximizing scalability. Here is a breakdown of each option:
Option A: Refactor the frontend so that static assets can be hosted on Amazon S3. Use Amazon CloudFront to serve the frontend to customers. Connect the frontend to the Java application.
- Analysis: Hosting static assets (such as images, CSS, and JavaScript) on Amazon S3 and serving them through Amazon CloudFront would significantly reduce the load on the Apache web server. CloudFront is a content delivery network (CDN) that can distribute static content globally, improving performance and reducing latency. This approach helps offload static content delivery, improving the scalability and performance of the frontend.
- Why selected: This approach reduces load on the Apache server, improves scalability, and provides low-latency delivery for static content, minimizing the operational burden on the frontend.
Option B: Rehost the Apache web server of the frontend on Amazon EC2 instances that are in an Auto Scaling group. Use a load balancer in front of the Auto Scaling group. Use Amazon Elastic File System (Amazon EFS) to host the static assets that the Apache web server needs.
- Analysis: This option involves lifting and shifting the Apache web server to EC2 instances in an Auto Scaling group with an Elastic Load Balancer (ELB). This setup can scale horizontally to handle increased traffic, and using EFS for shared storage is a possible solution for maintaining consistency across instances. However, it doesn’t address the core problem of static content delivery, as it would still rely on EC2 for both dynamic and static content.
- Why rejected: Although this setup provides scalability for the web server, it still doesn’t offload the static content to a CDN like CloudFront, which would be more efficient. Also, managing EC2 instances and EFS requires more operational effort compared to the S3/CloudFront solution in Option A.
Option C: Rehost the Java application in an AWS Elastic Beanstalk environment that includes auto scaling.
- Analysis: AWS Elastic Beanstalk is a Platform as a Service (PaaS) that simplifies the deployment and management of applications. It supports auto scaling based on demand, which would help manage the increased load during promotions. Elastic Beanstalk handles the infrastructure, patching, scaling, and load balancing, which minimizes operational overhead.
- Why selected: Rehosting the Java application on Elastic Beanstalk offers scalability, ease of management, and minimal operational overhead. It also supports auto scaling, which is important for handling variable load during promotions.
Option D: Refactor the Java application....
Author: Ava · Last updated Jul 6, 2026
A company is deploying a new application on AWS. The application consists of an Amazon Elastic Kubernetes Service (Amazon EKS) cluster and an Amazon Elastic Container Registry (Amazon ECR) repository. The EKS cluster has an AWS managed node group.
The company's security guidelines state that all resources on AWS mu...
To meet the company's security requirement of continuously scanning AWS resources for vulnerabilities with the least operational overhead, let's evaluate the available options:
Option A: Activate AWS Security Hub. Configure Security Hub to scan the EKS nodes and the ECR repository.
- Analysis: AWS Security Hub provides a comprehensive view of security alerts and compliance status across AWS accounts. It aggregates findings from multiple AWS services like Amazon Inspector and AWS Config. However, Security Hub itself does not directly perform vulnerability scanning but integrates with services like Amazon Inspector to pull findings.
- Why rejected: While Security Hub aggregates security findings, it does not perform the actual scanning of EKS nodes or ECR repositories. Security Hub requires integrating with other tools like Amazon Inspector to perform security scans, and it may not be the most direct solution to meet the requirement for continuous scanning.
Option B: Activate Amazon Inspector to scan the EKS nodes and the ECR repository.
- Analysis: Amazon Inspector is a vulnerability management service that automatically scans AWS resources, including Amazon EC2 instances (which would include EKS worker nodes). It can scan ECR repositories for vulnerabilities in container images. Inspector integrates seamlessly with AWS services and provides automatic vulnerability detection and assessment.
- Why selected: Amazon Inspector directly addresses the need to scan the EKS nodes and the ECR repository with minimal operational overhead. It provides automated vulnerability scanning, is easy to integrate into the AWS environment, and requires minimal manual intervention after configuration. This solution fully meets the requirement for continuous security scanning with a low operational burden.
Opti...
Author: Scarlett · Last updated Jul 6, 2026
A company needs to improve the reliability of its ticketing application. The application runs on an Amazon Elastic Container Service (Amazon ECS) cluster. The company uses Amazon CloudFront to serve the application. A single ECS service of the ECS cluster is the CloudFront distribution's origin.
The application allows only a specific number of active users to enter a ticket purchasing flow. These users are identified by an encrypted attribute in their JSON Web Token (JWT). All other users are redirected to a waiting room module until there is available capacity for purchasing.
The application is experiencing high loads. The waiting room module is work...
To address the problem of high load affecting the ticketing application and impacting its reliability during high traffic periods, we need a solution that decouples the waiting room logic from the core ticketing service, scales each service independently, and reduces the load on the ticketing application. Below is a breakdown of each option.
Option Breakdown:
A) Create a separate service in the ECS cluster for the waiting room. Use a separate scaling configuration. Ensure that the ticketing service uses the JWT information and appropriately forwards requests to the waiting room service.
- Explanation: This option suggests decoupling the waiting room functionality into a separate ECS service and using a different scaling configuration. This separation would help by offloading the waiting room traffic from the ticketing service, allowing each service to scale independently based on its specific load. The ticketing service would need to inspect the JWT and forward traffic to the appropriate service (waiting room or ticketing).
- Why it's selected: This approach ensures that the waiting room's traffic doesn’t interfere with the ticketing application's availability. It leverages ECS's native service scaling features, which is cost-effective and simple to manage, particularly in environments already using ECS. Using separate scaling configurations for each service ensures that the ECS service dedicated to the ticketing application isn't overwhelmed by waiting room traffic.
- Why others are rejected: This is the simplest and most cost-effective solution as it works within the existing ECS infrastructure, without the added complexity of moving to Kubernetes or introducing additional services like App Mesh.
B) Move the application to an Amazon Elastic Kubernetes Service (Amazon EKS) cluster. Split the waiting room module into a pod that is separate from the ticketing pod. Make the ticketing pod part of a StatefulSet. Ensure that the ticketing pod uses the JWT information and appropriately forwards requests to the waiting room pod.
- Explanation: This option involves migrating the application to Amazon EKS, setting up the waiting room and ticketing services as separate pods. Making the ticketing pod part of a StatefulSet is not necessary for a stateless web service like ticketing, and would add complexity. The solution requires setting up Kubernetes, which is overkill in this case.
- Why it's rejected: While EKS can be a good fit for certain use cases, it introduces unnecessary complexity for a problem that could be solved within ECS. Additionally, StatefulSets are typically used for applications that require stable, persistent storage, which is not necessary here. Migrating to EKS adds operational overhead and may not yield significant benefits in this scenario.
C) Create a separate service in the ECS cluster for the waitin...
