Examkin

Design for New Solutions

567 questions

All types567Multiple choice293Multiple select274
Question 1Question →

A commercial satellite imaging enterprise is designing a real-time satellite telemetry and command ingestion platform. The application tier consists of containerized microservices running on AWS Fargate behind an Application Load Balancer (ALB). The data tier uses an Amazon Aurora PostgreSQL database. The primary environment is hosted in the us-east-1 Region, and the company requires a disaster recovery (DR) environment in the us-west-2 Region.

The architecture must satisfy the following business and technical requirements:
- A Recovery Point Objective (RPO) of less than 1 minute.
- A Recovery Time Objective (RTO) of less than 15 minutes.
- Internal microservices must resolve service endpoints privately inside the VPCs of both Regions using the domain name satellite.internal.
- Outbound API commands sent from Fargate tasks to ground stations must remain highly available even if an entire Availability Zone experiences an outage.

Which of the following architectures meets these requirements with the lowest operational overhead?

Show answer & explanation

Answer: Deploy Amazon Aurora Global Database with the primary cluster in us-east-1 and a secondary cluster in us-west-2. In both Regions, deploy Fargate tasks across at least two Availability Zones, configuring route tables to point outbound internet traffic to independent NAT Gateways in each Availability Zone. Create a Route 53 Private Hosted Zone for satellite.internal and associate it with the VPCs in both us-east-1 and us-west-2. Set up Route 53 Failover routing with health checks to manage external traffic redirection during a failover.

Answer

The architecture that uses Amazon Aurora Global Database for sub-second cross-region replication, independent NAT Gateways in each Availability Zone of both Regions for high availability of outbound API calls, associates the Route 53 Private Hosted Zone with both regional VPCs for private name resolution, and uses Route 53 Failover routing for external traffic management.
The correct architecture uses Amazon Aurora Global Database to achieve low latency cross-region replication, ensuring that RPO and RTO goals are met. Outbound network traffic is protected from AZ failures by deploying redundant, local NAT Gateways within each zone. Private internal name resolution for satellite.internal is correctly established by associating the Route 53 Private Hosted Zone with the VPCs in both regions, and Route 53 Failover routing handles external traffic redirection smoothly.

Step-by-Step Solution

1
Evaluate the database replication strategy against RPO and RTO targets.
To meet an RPO under 1 minute and RTO under 15 minutes, cross-region replication must be continuous. Amazon Aurora Global Database provides sub-second replication latency, meeting the 1-minute RPO. Restoring from hourly backups fails both the RPO (1 hour) and RTO (restore time is typically >15 minutes).
Eliminates backup-and-restore options that fail RPO/RTO constraints.
2
Assess the high availability design of NAT Gateways for outbound container communication.
Configuring Fargate tasks across multiple AZs but routing all outbound traffic through a single NAT Gateway in one AZ exposes the system to complete outbound failure if that AZ goes down. Deploying independent NAT Gateways per AZ guarantees high availability.
Eliminates designs that introduce a single point of failure in outbound network pathways.
3
Confirm DNS configuration for internal resolution of custom hostnames across Regions.
Route 53 Private Hosted Zones must be explicitly associated with all VPCs that require local resolution of those private records. Without associating the hosted zone with the disaster recovery VPC, resources in the secondary region cannot resolve internal endpoints.
Secures functional name resolution in the secondary region during a failover event.

Key Concept

Disaster recovery design involving cross-region database replication, private DNS routing across multi-region VPCs, and Availability Zone level redundancy for egress networking.
Estimated Time:3m 0s
Question 2Question →

A gaming platform is launching a new multiplayer architecture in the `us-west-2` Region. The platform architecture requires two application VPCs (`vpc-game-prod-a` and `vpc-game-prod-b`) and one administrative management VPC (`vpc-mgmt-prod`). The management VPC hosts a Route 53 Private Hosted Zone (PHZ) `backend.gaming.internal` containing service endpoints that the application VPCs must resolve privately. The application VPCs must also access the internet for software updates through a centralized egress VPC (`vpc-egress-prod`) to minimize costs, but the egress path must survive a single Availability Zone (AZ) outage without disrupting egress traffic from unaffected AZs. Additionally, the game VPCs and management VPC must communicate with an on-premises graphics rendering cluster via a 10 Gbps AWS Direct Connect connection. Which TWO options should the Solutions Architect implement to satisfy these networking and DNS requirements?

Select all that apply

Show answer & explanation

Answer: Deploy an AWS Transit Gateway (`tgw-main`) and attach `vpc-game-prod-a`, `vpc-game-prod-b`, and `vpc-egress-prod`. In `vpc-egress-prod`, deploy a NAT Gateway in Availability Zone `us-west-2a` and another in `us-west-2b`. In the subnet route tables for the Transit Gateway attachment in `vpc-egress-prod`, configure the route for `0.0.0.0/0` to point to the NAT Gateway in the respective Availability Zone. Configure the Transit Gateway route table associated with the game VPCs to route `0.0.0.0/0` to the `vpc-egress-prod` attachment.; In the management account, create a cross-account VPC association authorization for `vpc-game-prod-a` and `vpc-game-prod-b` to the Private Hosted Zone `backend.gaming.internal`. In each game account, associate the respective game VPC with the Private Hosted Zone using the AWS CLI or API.

Answer

Deploy an AWS Transit Gateway and establish a centralized egress VPC with redundant NAT Gateways configured with AZ-specific routing, combined with cross-account Private Hosted Zone VPC associations.
Centralizing outbound egress traffic using Transit Gateway requires deploying a NAT Gateway in each active Availability Zone of the egress VPC and ensuring the subnet route tables route traffic to the NAT Gateway in the same zone. This maintains AZ isolation and resilience. Sharing a Route 53 Private Hosted Zone across AWS accounts is most efficiently achieved by creating a cross-account VPC association authorization in the hosted zone owner's account and executing the association in the client VPCs' accounts.

Step-by-Step Solution

1
Analyze egress requirements
Identified that a single NAT Gateway violates the high availability requirement across Availability Zones. Redundant NAT Gateways must be deployed in each active Availability Zone within the egress VPC, and subnets must route traffic based on their respective zone.
Ensures that a failure in one Availability Zone does not impact outbound traffic originating from or routed through other zones.
2
Analyze private DNS requirements
Determined that Route 53 Private Hosted Zones can be shared cross-account by generating a VPC association authorization from the owner account and accepting it from the consumer accounts.
Avoids the unnecessary deployment costs and management overhead of Route 53 Resolver Inbound and Outbound Endpoints for simple internal resolution.
3
Verify transitive routing constraints
Confirmed that Direct Connect Gateway alone does not support transitive routing between associated virtual private gateways. AWS Transit Gateway must be used for transit routing.
Adheres to AWS architectural constraints regarding the non-transitive nature of Direct Connect Gateway.

Key Concept

Designing highly resilient, cost-effective centralized egress topologies using AWS Transit Gateway and managing cross-account private DNS resolution without adding operational complexity.
Estimated Time:3m 0s
Question 3Question →

A company is designing a new relational Online Transaction Processing (OLTP) system. The system has key performance indicators requiring a recovery point objective (RPO) of zero (no data loss) and a recovery time objective (RTO) of less than 60 seconds during an Availability Zone outage. Additionally, the database must dynamically scale its read capacity to handle sudden spikes in query volume. Which of the following database configurations meets these requirements?

Show answer & explanation

Answer: Deploy an Amazon Aurora MySQL DB cluster with a primary instance and configure Aurora Auto Scaling to dynamically adjust the number of Aurora Replicas based on CPU utilization.

Answer

Deploy an Amazon Aurora MySQL DB cluster with a primary instance and configure Aurora Auto Scaling to dynamically adjust the number of Aurora Replicas based on CPU utilization.
The correct option addresses all requirements: Amazon Aurora replicates data synchronously to multiple Availability Zones within the region (maintaining an RPO of zero). It supports dynamic scaling of up to 15 Aurora Replicas using Aurora Auto Scaling to handle sudden increases in read volume. In the event of a primary instance failure, Aurora automatically fails over to one of the replicas in less than 30 seconds, which satisfies the RTO constraint of less than 60 seconds.

Step-by-Step Solution

1
Evaluate the database replication and high availability requirements.
An RPO of zero requires synchronous replication inside a single region, which is supported by Amazon Aurora's cluster volume write-path replication and RDS Multi-AZ synchronous replication.
Asynchronous replication (such as cross-region replicas) can lead to data loss and violates the RPO of zero constraint.
2
Determine the capability of the database architecture to serve read traffic.
Select a service that supports active horizontal read scaling. Aurora Replicas serve read queries and support Auto Scaling, whereas RDS Multi-AZ standby instances cannot be accessed for queries.
RDS standby instances are strictly passive and cannot offload read queries.
3
Confirm cross-account and encryption configurations if applicable.
Ensure KMS key sharing constraints are respected. Customer Managed Keys are required for cross-account resource sharing, as AWS-managed KMS keys cannot be shared.
AWS-managed keys cannot be updated with custom policies to allow external accounts.

Key Concept

Amazon Aurora vs. Amazon RDS Multi-AZ scaling and high availability features
Question 4Question →

A retail corporation is designing a new Point of Sale (POS) transaction processing pipeline across multiple accounts under AWS Organizations. The application tier runs on Amazon EC2 instances in a dedicated Ingestion VPC inside the Production Account (111122223333). These instances must upload transaction logs directly to an Amazon S3 bucket located in a centralized Compliance Account (444455556666). The compliance team requires that all uploaded logs be encrypted at rest using a Key Management Service (KMS) key managed exclusively by the compliance team. The ingestion application must be able to encrypt the logs during upload but must be strictly prevented from decrypting the logs once they are written. Furthermore, key administration must be restricted to the Compliance Account, and administrators in the Production Account must not have permissions to modify the key's configuration. Which combination of actions should the Solutions Architect take to design a compliant control structure? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: In the Compliance Account (444455556666), create a Customer Managed KMS key. Configure the key policy to grant the Production Account (111122223333) IAM role permission to perform the kms:GenerateDataKey and kms:DescribeKey actions, while omitting the kms:Decrypt permission for this role.; In the Compliance Account (444455556666), configure the S3 bucket policy to grant the Production Account (111122223333) IAM role permission for the s3:PutObject action, and enforce a condition requiring the s3:x-amz-server-side-encryption header to be set to aws:kms referencing the Customer Managed KMS key's Amazon Resource Name (ARN).

Answer

To achieve secure cross-account logging with proper segregation of duties, the solutions architect must create a Customer Managed Key (CMK) in the Compliance Account and grant the Production Account's IAM role permissions to generate and describe data keys (but not decrypt). Additionally, the Compliance Account S3 bucket policy must grant s3:PutObject to the Production IAM role while enforcing the use of the specific Customer Managed Key ARN using policy condition keys.
The correct combination requires creating a Customer Managed Key (CMK) in the Compliance Account, since only CMKs support the key policy modifications required for cross-account delegation. The key policy must grant key generation and description permissions to the Production Account IAM role while omitting decryption permissions to enforce segregation of duties. Simultaneously, the S3 bucket policy in the Compliance Account must grant PutObject permissions to the Production IAM role and enforce compliance by requiring that all uploads use the specified key via request headers.

Step-by-Step Solution

1
Determine the correct KMS key type for cross-account sharing.
Identify that a Customer Managed Key (CMK) must be created in the Compliance Account (444455556666) because AWS-managed keys (aws/s3) cannot be shared across accounts.
AWS-managed keys do not permit policy modification, meaning they cannot delegate cross-account access.
2
Enforce segregation of duties in the KMS key policy.
Configure the key policy of the CMK to grant kms:GenerateDataKey and kms:DescribeKey to the Production Account (111122223333) IAM role, but omit kms:Decrypt.
This allows the ingestion application to write and encrypt logs but prevents it from reading or decrypting logs once uploaded.
3
Configure S3 bucket boundary controls.
Write an S3 bucket policy in the Compliance Account allowing s3:PutObject for the Production role with a condition requiring s3:x-amz-server-side-encryption-aws-kms-key-id to match the CMK ARN.
Enforces that all uploaded objects must use the designated compliance key, blocking unencrypted or incorrectly encrypted uploads.

Key Concept

Cross-account KMS key sharing and S3 bucket access control design
Estimated Time:3m 0s
Question 5Question →

An electric vehicle (EV) charging network provider is designing a new global charging session management system. The system must process real-time telemetry and session initialization requests from 200,000200,000 charging stations. At the start of peak operational hours, session initialization requests spike from 2,0002,000 requests per second to 60,00060,000 requests per second within a 11-minute window. The system must process these requests with sub-100ms latency, validate the user's account status, verify charger availability, and persist session records. The read-to-write ratio is 4:14:1.

The architecture uses Amazon Route 53, an Application Load Balancer (ALB), and Amazon ECS on AWS Fargate for the API layer. The database layer is Amazon Aurora PostgreSQL.

Which two actions should the Solutions Architect recommend to ensure the platform scales efficiently and meets the performance requirements during peak traffic? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Request AWS Support to pre-warm the Application Load Balancer (ALB) to the expected peak throughput before the scheduled start of peak hours, and configure Amazon ECS Scheduled Scaling to scale out the Fargate tasks to the anticipated capacity prior to the spike.; Implement Amazon ElastiCache for Redis to cache charger availability and user account status, and configure Amazon Aurora Auto Scaling to scale read replicas horizontally while maintaining a minimum replica count sufficient to absorb the initial burst.

Answer

Request AWS Support to pre-warm the Application Load Balancer and configure ECS Scheduled Scaling before the event, and implement Amazon ElastiCache for Redis along with a pre-configured minimum replica count for Aurora Read Replicas.
To support a sudden 30-fold increase in traffic within a single minute, reactive scaling mechanisms are insufficient. Pre-warming the Application Load Balancer (ALB) ensures that AWS scales the load balancer's capacity ahead of time, preventing dropped connections at the start of the peak. Similarly, configuring Amazon ECS Scheduled Scaling ensures that Fargate tasks are fully provisioned and ready to accept traffic before the spike starts. To optimize the database layer, implementing Amazon ElastiCache for Redis offloads the frequent read operations (charger availability and account status) from the database. For the remaining reads, setting a high minimum count for Aurora Read Replicas ensures that read capacity is already in place to absorb the initial query spike.

Step-by-Step Solution

1
Analyze the workload characteristics and scaling limits.
The traffic spikes 30-fold from 2,000 rps2,000\text{ rps} to 60,000 rps60,000\text{ rps} within 11 minute. Standard reactive scaling mechanisms (ALB auto-scaling, ECS target tracking, and Aurora Auto Scaling) have latency in spawning resources and will fail to absorb the sudden burst.
This establishes that proactive scaling strategies are required at the entry and compute layers to prevent performance degradation.
2
Address the load balancing and compute provisioning layers.
Pre-warming the ALB configures the load balancer for the target peak throughput beforehand. ECS Scheduled Scaling pre-allocates Fargate tasks to match the target capacity right before the peak hours begin, eliminating startup delay.
This guarantees that incoming connections are not dropped at the ingress point and that sufficient backend container capacity exists immediately.
3
Optimize the database layer for read and write loads.
Amazon ElastiCache for Redis caches the read-heavy transactions (charger availability and account status). Setting a high minimum reader count for Aurora Read Replicas pre-warms the database scaling pool for any uncached reads.
This isolates the primary database instance from write starvation and read latency spikes, adhering to AWS database best practices.

Key Concept

Proactive scaling and caching strategies are required to handle rapid, massive traffic spikes that exceed the response times of reactive auto-scaling policies.
Estimated Time:3m 0s
Question 6Question →

A logistics company is designing a real-time fleet monitoring platform for 1010 million active delivery vehicles. Each vehicle transmits telemetry data every 55 seconds over HTTPS, resulting in a sustained ingestion rate of 22 million requests per second. The peak request volume can suddenly double in less than a minute. The system must process these updates with a sub-second latency envelope and store them in a persistent data store. The engineering team also needs to query the latest vehicle positions with sub-millisecond latency. Which architecture meets these requirements with the highest performance and reliability, while minimizing operational overhead?

Show answer & explanation

Answer: Deploy a Network Load Balancer (NLB) to route incoming HTTPS requests to an Amazon Elastic Container Service (ECS) service on AWS Fargate. The ECS tasks process the updates, write the latest positions to an Amazon ElastiCache for Redis replication group with Multi-AZ enabled, and write the historical telemetry to an Amazon DynamoDB table in On-Demand capacity mode.

Answer

Deploy a Network Load Balancer (NLB) to route incoming HTTPS requests to an Amazon Elastic Container Service (ECS) service on AWS Fargate. The ECS tasks process the updates, write the latest positions to an Amazon ElastiCache for Redis replication group with Multi-AZ enabled, and write the historical telemetry to an Amazon DynamoDB table in On-Demand capacity mode.
The architecture combining a Network Load Balancer (NLB), Amazon ECS on Fargate, Amazon ElastiCache for Redis (Multi-AZ), and Amazon DynamoDB (On-Demand) is correct because it ensures instant scaling to handle massive traffic spikes without pre-warming, provides sub-millisecond read latency for latest positions with high availability, and persists historical telemetry with zero manual capacity scaling overhead.

Step-by-Step Solution

1
Analyze the entry point scaling requirements for the ingestion tier.
Determine that a Network Load Balancer (NLB) is required rather than an Application Load Balancer (ALB) because NLB can handle sudden spikes of millions of requests per second without pre-warming, which is critical since traffic can double from 22 million to 44 million requests per second in less than a minute.
To prevent request drops and high latency during sudden flash traffic surges.
2
Evaluate the caching tier for low-latency queries of the latest vehicle positions.
Identify that Amazon ElastiCache for Redis configured with Multi-AZ replication is required to achieve sub-millisecond query performance and ensure high availability, whereas Memcached lacks replication and Multi-AZ capabilities.
To satisfy the sub-millisecond read latency requirement while ensuring high availability during failovers.
3
Evaluate the persistent database layer for high-throughput writes.
Select Amazon DynamoDB in On-Demand capacity mode to persistently store the historical telemetry, as it handles unpredictable and massive write spikes automatically without manual capacity management, while avoiding RDS Multi-AZ standby instances which cannot serve read traffic to scale query workloads.
To manage operational overhead and handle massive persistent write volume without scale bottlenecks.

Key Concept

Selecting and configuring AWS ingestion, caching, and database services to optimize performance and handle massive, sudden scaling requirements without operational bottlenecks.
Question 7Question →

An enterprise is designing a centralized auditing solution where a data ingestion application running under an IAM role in a Production account (111122223333) must write audit logs to an Amazon S3 bucket located in a Security account (444455556666). The compliance requirements state that all logs must be encrypted at rest, and a compliance auditor using a role in the Audit account (777788889999) must be able to read and decrypt the logs. Additionally, to maintain chain of custody, administrators in the Production account must not have the ability to decrypt the logs once they are uploaded. Which configuration meets these requirements?

Show answer & explanation

Answer: Create both the S3 bucket and a customer managed key (CMK) in the Security account. Configure S3 default encryption on the bucket using this CMK. Update the KMS key policy to grant kms:GenerateDataKey to the Production application role, and kms:Decrypt to the Audit compliance role. Configure the S3 bucket policy to allow s3:PutObject from the Production application role and s3:GetObject from the Audit compliance role.

Answer

Create both the S3 bucket and a customer managed key (CMK) in the Security account, configure S3 default encryption using this CMK, grant key permissions to the respective roles, and configure the S3 bucket policy to explicitly allow cross-account access.
The correct option correctly positions the customer managed KMS key (CMK) and the S3 bucket within the Security account. This architecture prevents Production account administrators from overriding policies or obtaining decryption permissions. The KMS key policy explicitly permits the Production application to generate data keys for encryption, while permitting the Audit compliance role to decrypt the data. The S3 bucket policy permits the necessary cross-account read and write operations, satisfying all compliance and access requirements.

Step-by-Step Solution

1
Select the correct KMS key type for cross-account sharing.
Determine that a Customer Managed Key (CMK) is required because AWS managed keys (such as aws/s3) cannot be shared across accounts due to immutable key policies.
AWS managed keys restrict access to the local account, so cross-account decryption requires a customer managed key.
2
Determine the resource hosting account for compliance separation.
Create the KMS CMK and S3 bucket in the Security account.
By hosting the KMS key in the Security account, Production account administrators cannot access or modify the key policy, preserving the chain of custody.
3
Configure the resource-based access policies in the Security account.
Grant write access (s3:PutObject and kms:GenerateDataKey) to the Production application role, and read access (s3:GetObject and kms:Decrypt) to the Audit compliance role.
Resource-based policies (bucket policy and KMS key policy) must explicitly authorize cross-account actions for the external accounts to access resources.

Key Concept

Cross-account S3 and KMS key policy delegation for regulatory data segregation.
Question 8Question →

A company is designing a deployment pipeline using AWS CloudFormation to update a stateless API application running on Amazon EC2 instances. The instances are managed by an Auto Scaling group (ASG) behind an Application Load Balancer (ALB). The update process must guarantee zero downtime. The new version of the API must be fully validated using synthetic test traffic in the production environment before receiving any live production traffic. If validation fails, the deployment must immediately revert to the previous version without configuration changes or downtime. Which deployment strategy should the solutions architect recommend to meet these requirements?

Show answer & explanation

Answer: Configure a blue/green deployment strategy by defining a second target group and a second Auto Scaling group in the CloudFormation template. Use an ALB test listener to route synthetic test traffic to the new target group for validation. Once validation succeeds, update the ALB production listener default action to point to the new target group, and then scale down the old Auto Scaling group.

Answer

Configure a blue/green deployment strategy by defining a second target group and a second Auto Scaling group in the CloudFormation template. Use an ALB test listener to route synthetic test traffic to the new target group for validation. Once validation succeeds, update the ALB production listener default action to point to the new target group, and then scale down the old Auto Scaling group.
Implementing a blue/green deployment by creating a secondary target group and Auto Scaling group via AWS CloudFormation fulfills all criteria. Using an Application Load Balancer (ALB) test listener enables validation with synthetic traffic on the new instances without affecting live users. Updating the production listener default action to point to the green target group provides an instantaneous, zero-downtime cutover that is easily reversible by pointing back to the blue target group if issues arise.

Step-by-Step Solution

1
Define target groups and Auto Scaling groups.
Two distinct target groups (Blue and Green) and two Auto Scaling groups are declared in the CloudFormation template, allowing isolated environments to run concurrently.
Separating environments is necessary to validate the new application version in production without impacting the live version.
2
Configure ALB test and production listeners.
A production listener routes user traffic to the active version, while a test listener routes QA/synthetic traffic to the new version.
This allows tests to run against the new code in the actual production environment without exposing live users to unvalidated code.
3
Perform the traffic swap and clean up.
Once validated, update the production listener's default action to point to the new target group. The old Auto Scaling group is then scaled down to optimize costs.
Swapping listener targets provides an instantaneous cutover with zero downtime and a simple rollback path if post-deployment anomalies occur.

Key Concept

Designing automated, zero-downtime blue/green deployment strategies using AWS CloudFormation and Application Load Balancer target group swapping.
Question 9Question →

A company is developing a new regulatory reporting system. The application runs on Amazon ECS tasks in an Application account (Account ID: 123456789012). The system must write weekly reports to an Amazon S3 bucket located in a dedicated Compliance account (Account ID: 987654321098). The reports must be encrypted at rest using AWS KMS. The compliance team requires that the encryption key's access policy is managed under the Compliance account, and only the reporting application is authorized to perform encryption operations. Which design should a Solutions Architect recommend to meet these requirements securely?

Show answer & explanation

Answer: In the Compliance account, create a Customer Managed Key (CMK). Configure the CMK's key policy to grant the ECS task role in the Application account permissions to perform kms:GenerateDataKey. Update the S3 bucket policy in the Compliance account to allow the ECS task role to perform s3:PutObject. Configure the ECS task role with IAM policies allowing s3:PutObject on the bucket and kms:GenerateDataKey on the CMK.

Answer

In the Compliance account, create a Customer Managed Key (CMK). Configure the CMK's key policy to grant the ECS task role in the Application account permissions to perform kms:GenerateDataKey. Update the S3 bucket policy in the Compliance account to allow the ECS task role to perform s3:PutObject. Configure the ECS task role with IAM policies allowing s3:PutObject on the bucket and kms:GenerateDataKey on the CMK.
The correct design uses a Customer Managed Key (CMK) in the Compliance account and explicitly grants the Application account's ECS task role permission to perform the kms:GenerateDataKey operation. Because the S3 bucket and the KMS key are in a different account than the ECS task, the cross-account permissions must be granted on both the resource policies (S3 bucket policy and KMS key policy) and the ECS task role's IAM policy.

Step-by-Step Solution

1
Select the correct key type for cross-account operations.
Choose a Customer Managed Key (CMK) in the Compliance account because AWS-managed keys cannot be shared cross-account.
AWS-managed keys do not allow policy modifications, which are required to add the external Application account principal.
2
Configure the key policy for the Customer Managed Key.
Add a statement in the CMK policy that allows the ECS task role in the Application account to perform the kms:GenerateDataKey operation.
When writing to S3 with SSE-KMS, the caller must have the permission to generate a data key from the KMS key.
3
Configure the S3 bucket policy and IAM permissions.
Add a statement in the S3 bucket policy allowing s3:PutObject for the ECS task role, and ensure the ECS task role's IAM policy allows s3:PutObject and kms:GenerateDataKey.
Cross-account access requires permissions to be granted on both the trust resource policy (bucket policy/key policy) and the caller's identity-based policy (IAM policy).

Key Concept

Cross-account S3 access with KMS encryption requires Customer Managed Keys (CMKs) and correct alignment of both IAM policies and resource policies (S3 bucket and KMS key policies).
Estimated Time:2m 0s
Question 10Question →

A company is designing the deployment pipeline for a new web application. The application will run on Amazon EC2 instances within an Auto Scaling group behind an Application Load Balancer (ALB). The infrastructure is provisioned using AWS CloudFormation. The team requires a deployment strategy that can route exactly 10%10\% of user traffic to the new version for testing. If any errors are detected, the deployment must immediately roll back all traffic to the old version. If the deployment is successful, all traffic must be shifted to the new version. The strategy must minimize both the time to roll back and the cost of keeping duplicate environments running after the deployment is complete.

Which deployment strategy meets these requirements?

Show answer & explanation

Answer: Provision a second Auto Scaling group and a new ALB target group for the new application version. In the CloudFormation template, update the ALB listener rule to distribute traffic by assigning a weight of 1010 to the new target group and 9090 to the existing target group. After validating the deployment, update the CloudFormation template to set the weight of the new target group to 100100, and then terminate the old Auto Scaling group and target group.

Answer

Provision a second Auto Scaling group and a new Application Load Balancer target group, then use AWS CloudFormation to shift traffic weights on the listener rule from 90/10 to 0/100.
The correct strategy uses Application Load Balancer (ALB) weighted target groups. This allows the system to direct exactly 10%10\% of the live user traffic to the new Auto Scaling group and target group. Because the traffic shift happens at the load balancer layer, rollbacks can be performed instantaneously by updating the listener rule weights back to 100%100\% for the old target group. Once the deployment is verified, the old Auto Scaling group and target group can be deleted, ensuring that duplicate costs are minimized.

Step-by-Step Solution

1
Provision a second Auto Scaling group and target group for the new version of the application using AWS CloudFormation.
A separate environment with the new version is created without impacting the existing production environment.
This allows testing the new version in isolation before routing live traffic to it.
2
Update the Application Load Balancer listener rule in CloudFormation to assign a weight of 1010 to the new target group and 9090 to the original target group.
Exactly 10%10\% of incoming live traffic is immediately routed to the new version.
This establishes the requested canary testing configuration at the load balancer layer.
3
Monitor the deployment. If errors occur, revert the weights to route 100%100\% of traffic to the original target group. If successful, set the weight of the new target group to 100%100\%.
Traffic is either immediately rolled back or fully shifted to the new version, and the old Auto Scaling group and target group are terminated.
Shifting traffic at the Application Load Balancer level ensures instantaneous rollback or cutover, and terminating old resources minimizes ongoing costs.

Key Concept

Canary deployments using Application Load Balancer weighted target groups in AWS CloudFormation.
Estimated Time:2m 0s
Question 11Question →

An enterprise is designing a deployment pipeline for a legacy Java application hosted on Amazon EC2 instances within an Auto Scaling group behind an Application Load Balancer. The deployment must achieve zero downtime and allow for a 1-hour verification window where the old version remains active but receives no traffic, enabling rapid rollback if issues are detected. If the validation succeeds, the old instances must be automatically terminated. The deployment process must be fully managed with minimal custom configuration. Which two configurations should the Solutions Architect include in the AWS CodeDeploy deployment group to meet these requirements? (Select two.)

Select all that apply

Show answer & explanation

Answer: Configure the deployment group to copy the Auto Scaling group and use the Application Load Balancer target group to route traffic.; Configure the deployment group settings to reroute traffic immediately, and set the original Auto Scaling group instances to terminate after a waiting period of 60 minutes.

Answer

Configure the deployment group to copy the Auto Scaling group and use the Application Load Balancer target group to route traffic, and configure the deployment group settings to reroute traffic immediately while setting the original Auto Scaling group instances to terminate after a waiting period of 60 minutes.
For an EC2 Auto Scaling deployment using CodeDeploy, a blue/green deployment requires copying the Auto Scaling group and using an Application Load Balancer target group to route traffic. Setting the deployment group to reroute traffic immediately and setting the original instances to terminate after a 60-minute wait time ensures that traffic shifts to the new version immediately while keeping the old instances running and deregistered from the load balancer. This provides a 1-hour window for verification and rapid rollback without downtime, followed by automated termination.

Step-by-Step Solution

1
Determine the deployment type and environment configuration.
CodeDeploy Blue/Green deployment is chosen, configuring the deployment group to copy the original Auto Scaling group and swap traffic via the Application Load Balancer target group.
This establishes a fully managed blue/green setup where CodeDeploy handles the creation of the green environment automatically.
2
Configure the traffic rerouting and validation window.
Set the deployment group to reroute traffic immediately once the green instances pass health checks, and configure the original instances' termination wait time to 60 minutes.
This meets the requirement of keeping the old instances active but not receiving traffic (deregistered) for a 1-hour verification period to allow rapid rollback.

Key Concept

AWS CodeDeploy Blue/Green deployment configurations for EC2 Auto Scaling Groups
Question 12Question →

An enterprise is designing a deployment pipeline for a critical transaction-processing application. The application runs on Amazon EC2 instances managed by an Auto Scaling group (ASG) behind an Application Load Balancer (ALB). The infrastructure is defined and managed using AWS CloudFormation. The application processes long-running database transactions that can take up to 1212 minutes to complete; interrupting these transactions results in data corruption. The deployment strategy must meet the following requirements:

1. Roll out updates with zero downtime.
2. Ensure that instances are never terminated while processing active transactions.
3. Automatically roll back the CloudFormation stack to the previous version if new instances fail to initialize or fail application-level health checks.
4. Minimize additional compute costs by avoiding the pre-allocation of a duplicate Auto Scaling group during the deployment.

Which configuration strategy should the Solutions Architect implement to meet these requirements?

Show answer & explanation

Answer: Update the CloudFormation template to configure the ASG `UpdatePolicy` with `AutoScalingRollingUpdate`. Set `WaitOnResourceSignals` to `true` and define an appropriate `Timeout`. Configure an `EC2_INSTANCE_TERMINATING` lifecycle hook on the ASG that runs a script to wait for active connections to drain before completing the hook. In the EC2 user data, start the application, run a local health check script, and invoke the `cfn-signal` helper utility upon success.

Answer

Configure the Auto Scaling group's CloudFormation UpdatePolicy to use AutoScalingRollingUpdate, enable WaitOnResourceSignals, implement an EC2_INSTANCE_TERMINATING lifecycle hook, and use the cfn-signal helper utility in the EC2 user data.
The correct strategy uses the `AutoScalingRollingUpdate` policy in CloudFormation to update instances in place, which avoids the cost of a duplicate Auto Scaling group. By setting `WaitOnResourceSignals` to true and using `cfn-signal` in the EC2 user data, CloudFormation ensures that the application is fully running and healthy before continuing the rollout, automatically rolling back if any batch fails. The `EC2_INSTANCE_TERMINATING` lifecycle hook allows the instances to finish their long-running transactions (up to 1212 minutes) before they are terminated, preventing data corruption.

Step-by-Step Solution

1
Configure the CloudFormation UpdatePolicy on the AWS::AutoScaling::AutoScalingGroup resource to use AutoScalingRollingUpdate.
This ensures that updates are rolled out in batches, maintaining service availability and avoiding the cost of a duplicate Auto Scaling group.
Meets the requirements of zero downtime and minimized resource costs during deployment.
2
Enable WaitOnResourceSignals and configure an appropriate Timeout in the AutoScalingRollingUpdate policy.
CloudFormation will pause the update and wait for a success signal from each newly launched EC2 instance before updating subsequent batches.
Allows CloudFormation to automatically roll back the stack if new instances fail to start or report healthy within the timeout period.
3
Configure an EC2_INSTANCE_TERMINATING lifecycle hook on the Auto Scaling group.
When an instance is selected for termination during the rolling update, the lifecycle hook transitions the instance to the Terminating:Wait state.
This pauses termination and allows a custom script or daemon on the instance to complete any ongoing long-running transactions (up to the 1212-minute limit) before signaling completion.
4
In the EC2 user data script, configure the application startup, run a local health check to verify its readiness, and call the cfn-signal utility.
Once the application is verified as fully functional on the new instance, a success signal is sent to CloudFormation.
Ensures that CloudFormation only proceeds with the deployment when the new version is confirmed healthy, triggering a rollback if the signal fails.

Key Concept

Auto Scaling Rolling Updates with Lifecycle Hooks and CloudFormation Signals
Question 13Question →

An e-commerce company is migrating its order processing service to a containerized application running on Amazon ECS with AWS Fargate, fronted by an Application Load Balancer (ALB). The service is highly sensitive to downtime, and any deployment must ensure zero downtime. Additionally, the development team wants to test new releases under production load by routing 10%10\% of the traffic to the new version for a 1515-minute observation period. If the new version triggers any CloudWatch alarms for 5xx5\text{xx} errors or high latency during this period, the deployment must automatically roll back. Which deployment strategy should the Solutions Architect design to satisfy these requirements?

Show answer & explanation

Answer: Configure the Amazon ECS service to use the AWS CodeDeploy blue/green deployment controller. Create a CodeDeploy deployment group utilizing the CodeDeployDefault.ECSCanary10Percent15Minutes configuration, and specify the CloudWatch alarms for 5xx5\text{xx} errors and latency as rollback triggers in the deployment group.

Answer

Configure the Amazon ECS service to use the AWS CodeDeploy blue/green deployment controller with the CodeDeployDefault.ECSCanary10Percent15Minutes configuration, and associate CloudWatch alarms with the deployment group for automated rollback.
The correct option is correct because AWS CodeDeploy blue/green deployment is the standard AWS solution for performing canary and linear deployments on Amazon ECS. It natively shifts a specified percentage of traffic (such as 10%10\%) to the new task set for a defined duration (such as 1515 minutes) using the Application Load Balancer's target groups. It also integrates directly with Amazon CloudWatch alarms to automatically trigger rollbacks if application-level errors or latency exceed thresholds during the deployment window.

Step-by-Step Solution

1
Change the deployment controller of the Amazon ECS service to AWS CodeDeploy.
Amazon ECS delegates the deployment and traffic routing process to AWS CodeDeploy rather than using the default rolling update scheduler.
CodeDeploy is required to manage weighted traffic shifting (canary/linear) between two task sets (Blue and Green) on ECS.
2
Configure the deployment group in AWS CodeDeploy to use the predefined Canary configuration.
The deployment group is set to CodeDeployDefault.ECSCanary10Percent15Minutes, which directs 10%10\% of production traffic to the new Fargate tasks for 1515 minutes.
This matches the requirement to test new releases under a small portion of production load for a specific duration.
3
Attach CloudWatch alarms for 5xx5\text{xx} errors and latency to the CodeDeploy deployment group's rollback configuration.
If any of the specified alarms enter the ALARM state during the 1515-minute canary period, CodeDeploy immediately aborts the deployment and routes 100%100\% of traffic back to the original task set.
This fulfills the automated rollback requirement with zero downtime.

Key Concept

AWS CodeDeploy Blue/Green Deployment with Canary traffic shifting on ECS
Question 14Question →

A research organization is designing a genomic data processing platform. The processing applications run on Amazon EC2 instances in a dedicated Computation Account (Account A). The raw genome sequencing output files must be written directly to an Amazon S3 bucket located in a central Data Archive Account (Account B).

The organization's security policy requires:
- All data stored in the S3 bucket must be encrypted at rest using SSE-KMS with a Customer Managed Key (CMK) managed by the Data Archive Account (Account B).
- The Data Archive Account must maintain full ownership of all uploaded objects, and access control lists (ACLs) must be completely disabled.
- The EC2 instances in Account A must have the minimum necessary permissions to perform the uploads.

Which combination of configuration steps will meet these security requirements?

Show answer & explanation

Answer: In Account B, configure S3 Object Ownership to Bucket Owner Enforced. Modify the KMS CMK key policy to grant the EC2 instance role in Account A permissions for kms:GenerateDataKey and kms:Decrypt. Configure the S3 bucket policy to allow s3:PutObject for the EC2 instance role in Account A. In Account A, assign an IAM policy to the EC2 instances that allows s3:PutObject on the bucket in Account B and kms:GenerateDataKey on the KMS CMK in Account B.

Answer

In Account B, configure S3 Object Ownership to Bucket Owner Enforced. Modify the KMS CMK key policy to grant the EC2 instance role in Account A permissions for kms:GenerateDataKey and kms:Decrypt. Configure the S3 bucket policy to allow s3:PutObject for the EC2 instance role in Account A. In Account A, assign an IAM policy to the EC2 instances that allows s3:PutObject on the bucket in Account B and kms:GenerateDataKey on the KMS CMK in Account B.
The correct option addresses all security requirements by using a Customer Managed Key (CMK) whose key policy can be modified to grant the necessary KMS permissions to the external IAM role in Account A. Setting S3 Object Ownership to Bucket Owner Enforced disables ACLs completely and automatically assigns ownership of all uploaded objects to Account B. S3 bucket policies and IAM policies are correctly configured to allow the cross-account s3:PutObject operation.

Step-by-Step Solution

1
Disable ACLs and enforce bucket owner ownership in the target account.
S3 Object Ownership in the Data Archive Account (Account B) is set to Bucket Owner Enforced, disabling ACLs and ensuring all uploaded files are owned by the bucket owner.
Meets the requirement to maintain full ownership of all objects and completely disable ACLs.
2
Configure cross-account KMS permissions on the Customer Managed Key (CMK) in Account B.
The KMS key policy in Account B is updated to permit the IAM role from Account A to perform kms:GenerateDataKey and kms:Decrypt operations.
Allows the external account's role to generate data keys for encrypting files uploaded to the S3 bucket using the target KMS key.
3
Configure the S3 bucket policy in Account B and IAM role policy in Account A.
The S3 bucket policy in Account B allows s3:PutObject for the role in Account A. The IAM policy of the role in Account A allows s3:PutObject on the bucket in Account B and kms:GenerateDataKey on the KMS CMK in Account B.
Grants the necessary S3 and KMS permissions across the account boundary for a successful write operation.

Key Concept

Cross-account Amazon S3 uploads with SSE-KMS encryption and Bucket Owner Enforced object ownership
Question 15Question →

A multinational financial enterprise is building a regulatory reporting data pipeline. The application tier runs on Amazon EC2 instances in an Application Account (Account A: 111122223333111122223333). The reporting logs must be delivered to an Amazon S3 bucket in a Centralized Security Account (Account B: 444455556666444455556666). The compliance requirements mandate that all logs must be encrypted at rest using a Key Management Service (KMS) key, and the Centralized Security Account must have full ownership of all uploaded objects to prevent access delegation issues. The application tier must only have permissions to write objects and must not be allowed to decrypt the logs once written. Which combination of actions must the solutions architect take to meet these security requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Enable S3 Object Ownership with the Bucket Owner Enforced setting on the S3 bucket in Account B, and configure the S3 bucket policy in Account B to grant s3:PutObject permissions to Account A's EC2 instance profile role.; Create a customer managed KMS key in Account B, configure its key policy to grant kms:GenerateDataKey permissions to Account A's EC2 instance profile role, and configure the S3 bucket in Account B to use this customer managed KMS key for default encryption.

Answer

Enable S3 Object Ownership with the Bucket Owner Enforced setting on the S3 bucket in Account B, configure the bucket policy to grant s3:PutObject permissions to Account A's role, and use a customer managed KMS key in Account B with key policy permissions for kms:GenerateDataKey granted to Account A.
To support cross-account KMS encryption, a customer managed key (CMK) must be created in the destination account because AWS managed keys (such as aws/s3) do not support policy modification and cannot be shared across accounts. Granting the writing role `kms:GenerateDataKey` allows the application to encrypt files without requiring `kms:Decrypt` access. Additionally, disabling S3 ACLs using the Bucket Owner Enforced setting ensures that all objects uploaded to the bucket are automatically owned by the bucket owner (the security account), resolving potential ownership and permission delegation issues.

Step-by-Step Solution

1
Address the cross-account encryption requirement by creating a customer managed key (CMK) in the destination security account (Account B).
A CMK is established which supports cross-account key policy delegation, unlike default AWS-managed KMS keys.
AWS-managed keys (e.g., aws/s3) cannot be shared across accounts as their policies are not editable.
2
Configure the key policy of the newly created CMK to allow Account A's EC2 instance profile role to generate data keys.
The application can perform encryption at write time by calling kms:GenerateDataKey without requiring decryption permissions.
Applying the principle of least privilege ensures the writing account cannot decrypt or read the logs once written.
3
Configure the destination S3 bucket in Account B with default encryption using the customer managed KMS key.
All objects uploaded to the bucket are automatically encrypted with the specified CMK.
Enforces compliance control for encryption at rest for all incoming reporting logs.
4
Enable the Bucket Owner Enforced setting under S3 Object Ownership on the bucket in Account B, and grant s3:PutObject permissions in the bucket policy to Account A's role.
S3 ACLs are disabled, and the Centralized Security Account (Account B) automatically owns all uploaded log objects.
Ensures that the security account maintains full control and ownership of the logs without relying on object ACLs from the writer account.

Key Concept

Designing cross-account security controls using KMS key policies and S3 Object Ownership (Bucket Owner Enforced) to maintain compliance and data ownership.
Question 16Question →

A healthcare provider is designing a new digital medical imaging archive and diagnostic report system. The system must store structured patient metadata logs (OLTP workload) and unstructured medical images in DICOM format (Object storage). The metadata database must support high-volume write transactions and scale read traffic to handle sudden spikes from hospital clients. The disaster recovery requirements demand a Recovery Time Objective (RTO) of 1515 minutes and a Recovery Point Objective (RPO) of 11 minute. Additionally, for regulatory compliance, the medical images must be securely archived and replicated to a destination bucket in a secondary, isolated AWS account in a different AWS region, encrypted at rest using AWS KMS. Which of the following database and storage configurations should the solutions architect choose to meet these requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Deploy an Amazon Aurora global database with the primary cluster in the active region and a secondary cluster in the disaster recovery region, utilizing Aurora Replicas in both regions to handle database operations.; Store the medical images in Amazon S3, and configure S3 Cross-Region Replication (CRR) to a destination bucket in the disaster recovery region using a Customer Managed Key (CMK) in AWS KMS with appropriate cross-account key policies.

Answer

Deploy an Amazon Aurora global database with the primary cluster in the active region and a secondary cluster in the disaster recovery region, and store the medical images in Amazon S3, configuring S3 Cross-Region Replication (CRR) using a Customer Managed Key (CMK) in AWS KMS with cross-account key policies.
Deploying an Amazon Aurora global database provides sub-second replication to the disaster recovery region, satisfying the strict RTO of 1515 minutes and RPO of 11 minute, while supporting read replicas for traffic scaling. For object storage, utilizing Amazon S3 with Cross-Region Replication (CRR) and a Customer Managed Key (CMK) configured with cross-account policies allows secure replication of medical images to a secondary AWS account, which is impossible with AWS-managed keys.

Step-by-Step Solution

1
Evaluate the database tier for high performance, read scaling, and strict RTO/RPO targets.
Determine that Amazon Aurora Global Database satisfies the RTO of 1515 minutes and RPO of 11 minute via storage-based physical replication, while standard RDS snapshot replication fails the RPO target.
Aurora Global Database replicates data sub-second, allowing for near-zero RPO and rapid failover.
2
Assess the scalability and read routing configuration of the database options.
Eliminate the configuration routing read queries to the RDS standby instance because Multi-AZ standby instances do not accept read traffic.
RDS standby instances are purely passive; read scaling requires read replicas or Aurora replicas.
3
Evaluate S3 Cross-Region Replication (CRR) requirements for cross-account destination buckets.
Identify that the default AWS-managed KMS key (aws/s3) cannot be used because its policy cannot be modified to grant cross-account access.
A Customer Managed Key (CMK) is required to configure key policies allowing cross-account decryption and encryption.

Key Concept

Selecting and configuring highly available, secure, and compliant databases and storage with cross-region and cross-account capabilities to meet RTO/RPO constraints.
Question 17Question →

A global online retailer is launching a flash sale platform for limited-edition merchandise drops. The system expects sudden, extreme traffic surges where active users scale from 5,0005,000 to over 1,500,0001,500,000 within 60 seconds60\text{ seconds} at the start of a sale. The current architecture consists of an Application Load Balancer (ALB), an Amazon ECS on AWS Fargate service, and an Amazon Aurora PostgreSQL database cluster. During testing, the sudden influx of connection requests led to HTTP 503503 Service Unavailable errors from the ALB, and database write latency spiked, causing the Fargate tasks to exhaust their connection pools. Which combination of architectural optimizations will best resolve these performance and scalability issues? (Select TWO)

Select all that apply

Show answer & explanation

Answer: Submit an AWS Support ticket to pre-warm the Application Load Balancer (ALB) with the expected traffic profile and surge rates prior to the start of the drop event.; Decouple the write operations by routing order requests to an Amazon Kinesis Data Stream, and configure an AWS Lambda function to poll the stream and perform batch writes to the Amazon Aurora database.

Answer

Pre-warm the Application Load Balancer (ALB) by contacting AWS Support, and decouple the database write operations using Amazon Kinesis Data Streams and AWS Lambda to process database updates in batches.
Contacting AWS Support to pre-warm the ALB ensures that the load balancer is provisioned with sufficient capacity before the flash sale starts, preventing HTTP 503 errors. Decoupling the write path using Amazon Kinesis Data Streams and AWS Lambda allows the system to ingest massive transaction volumes instantly and write to the Aurora database in controlled, batched operations, preventing database CPU exhaustion.

Step-by-Step Solution

1
Analyze the bottleneck at the ingress layer (Application Load Balancer) during an instantaneous surge.
Dynamic auto-scaling policies cannot react quickly enough, causing HTTP 503 errors. Determine that ALB pre-warming via AWS Support is required.
ALBs scale gradually based on traffic trends, but a sudden flash spike from 5,000 to 1.5 million requests in 60 seconds will saturate the existing capacity before scaling completes.
2
Analyze the bottleneck at the database layer (Amazon Aurora PostgreSQL).
Determine that decoupling writes using a queuing/streaming ingestion tier is necessary to absorb the peak throughput.
Direct, concurrent database writes from scaled container tasks can exhaust database connection pools and CPU. Buffering updates in Amazon Kinesis and processing them in batches via AWS Lambda smooths out the database write load.
3
Evaluate the architectural validity of the distractors.
Identify that the options suggesting dynamic ALB auto-scaling, routing reads to a standby, and using replicated Memcached are invalid.
Aurora standby instances do not handle read scaling, Memcached does not support replication or persistence, and ALB dynamic scaling is too slow for flash spikes.

Key Concept

Architecting systems for extreme flash traffic spikes by pre-warming load balancers and decoupling database writes to manage scalability and performance.
Question 18Question →

A financial services company is launching a personalized dashboard that provides real-time portfolio performance metrics to 2,000,0002,000,000 active customers. During the stock market opening at 9:30 AM, query traffic is projected to surge instantly from 2,0002,000 requests per second to 300,000300,000 requests per second. The application is hosted on Amazon EC2 instances within an Auto Scaling group behind an Application Load Balancer (ALB), and the portfolio data resides in an Amazon RDS for PostgreSQL database. To handle this daily flash traffic spike without dropping connections or incurring high latency, which strategy should a solutions architect implement?

Show answer & explanation

Answer: Deploy an Amazon ElastiCache for Redis cluster in front of the PostgreSQL database to cache read-heavy queries. Configure the Auto Scaling group to use step scaling policies based on CPU utilization, and contact AWS Support to pre-warm the Application Load Balancer prior to the market opening.

Answer

Deploy an Amazon ElastiCache for Redis cluster in front of the PostgreSQL database to cache read-heavy queries. Configure the Auto Scaling group to use step scaling policies based on CPU utilization, and contact AWS Support to pre-warm the Application Load Balancer prior to the market opening.
The correct strategy combines caching at the database layer (ElastiCache for Redis) to reduce query load, proactive capacity allocation (ALB pre-warming) to handle the instant 150-fold traffic surge, and horizontal step scaling to add EC2 instances in response to CPU metrics. This ensures both the ingress layer (ALB) and the compute/storage layers scale dynamically and performantly.

Step-by-Step Solution

1
Analyze load scaling limits of the Application Load Balancer (ALB).
Identify that a sudden 150-fold traffic spike will outpace the ALB's automatic scaling rate, necessitating pre-warming by AWS Support.
ALB auto-scaling is gradual and cannot react instantly to massive, sub-minute surges.
2
Optimize database read throughput using a caching layer.
Place an Amazon ElastiCache for Redis cluster in front of the RDS PostgreSQL database to handle high-frequency, read-heavy query loads.
Caching prevents database bottlenecking and reduces query response times during peak hours.
3
Configure the Auto Scaling group to react quickly and stably to load surges.
Apply step scaling policies with appropriate warm-up times to scale out EC2 instances in defined increments.
Step scaling is more responsive to large spikes than simple scaling, and proper warm-up times prevent premature scaling evaluation.

Key Concept

Handling instantaneous flash traffic spikes by combining load balancer pre-warming, database query caching, and horizontal step scaling.
Estimated Time:2m 0s
Question 19Question →

A digital advertising company is designing a real-time bidding (RTB) platform that processes ad auction requests from global ad exchanges. The system must handle a baseline of 100,000100,000 requests per second (RPS) and scale to support sudden spikes of up to 800,000800,000 RPS with sub-1515 millisecond response times. The current design proposes using an Application Load Balancer (ALB) routing traffic to Amazon ECS tasks running on AWS Fargate, with Amazon Aurora PostgreSQL as the persistent database.

Which two actions should the solutions architect take to meet the performance and latency requirements under peak traffic loads? (Select two.)

Select all that apply

Show answer & explanation

Answer: Request AWS Support to pre-warm the ALB to the expected peak traffic capacity of 800,000800,000 requests per second.; Configure Aurora Replicas in the database cluster and set up Auto Scaling to dynamically add replicas based on read load.

Answer

The correct actions are to request AWS Support to pre-warm the Application Load Balancer (ALB) to the expected peak traffic capacity of 800,000800,000 requests per second, and to configure Aurora Replicas in the database cluster with Auto Scaling to dynamically handle the read load.
Pre-warming the Application Load Balancer (ALB) ensures that it has sufficient capacity provisioned beforehand to handle the massive, instantaneous 8-fold traffic spike without dropping connections. Utilizing Aurora Replicas with Auto Scaling allows the database layer to horizontally scale read capacity to handle the increased query volume, preserving sub-15ms response times.

Step-by-Step Solution

1
Analyze traffic characteristics and scaling limitations of the load balancing tier.
The application faces an immediate 8-fold traffic surge from 100,000100,000 to 800,000800,000 requests per second. Under default behavior, the ALB will fail to scale quickly enough, resulting in dropped packets and increased latency.
Requesting pre-warming for the ALB is necessary to prepare the balancer's capacity ahead of time for the peak spike.
2
Evaluate the database read-scaling capabilities of Amazon Aurora.
Dynamic read-scaling is achieved by adding Aurora Replicas to the cluster and configuring Auto Scaling based on metrics such as CPU utilization.
This offloads read operations from the primary writer node to the horizontally scaled reader nodes.
3
Eliminate incorrect configurations for databases and caches.
Multi-AZ standby instances cannot receive read queries. Amazon ElastiCache for Memcached does not offer replication or persistent failover features.
Identifying invalid database replication architectures and cache engine features helps refine the solution to comply with best practices.

Key Concept

Handling sudden massive spikes requires pre-provisioning capacity on the entry layer (ELB pre-warming) and utilizing scalable read replicas at the database tier.
Estimated Time:2m 0s
Question 20Question →

An enterprise is building a new content delivery portal. The architecture requires two storage tiers:

1. A persistent store for user session data (NoSQL workload) requiring sub-millisecond latencies for active sessions and active-active replication between two AWS regions.
2. A shared file system (File storage) to host legacy application files that must be concurrently mounted by multiple Linux-based Amazon EC2 instances across three Availability Zones. The file system must be encrypted at rest using a key that allows the enterprise to delegate access to a central security auditing account.

Which two storage and database configurations should the solutions architect select to meet these requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Amazon DynamoDB global tables to store the user session data.; Amazon Elastic File System (Amazon EFS) encrypted at rest using a customer managed KMS key.

Answer

Amazon DynamoDB global tables to store the user session data, and Amazon Elastic File System (Amazon EFS) encrypted at rest using a customer managed KMS key.
To store the NoSQL user session data with sub-millisecond latency and active-active replication, Amazon DynamoDB global tables are the optimal choice. For the legacy shared file system, Amazon Elastic File System (Amazon EFS) natively supports concurrent mounts across multiple Availability Zones for Linux-based EC2 instances. To allow cross-account access delegation to the security auditing account, EFS must be encrypted at rest with a customer managed KMS key, as its key policy can be customized to grant cross-account permissions.

Step-by-Step Solution

1
Analyze the session data requirements: NoSQL workload, sub-millisecond latencies, active-active cross-region replication.
Identify Amazon DynamoDB global tables as the matching service because DynamoDB is a NoSQL store that supports sub-millisecond read/write latency with global tables offering active-active multi-region replication.
This guarantees that session data is available and replicated across both target regions with high performance.
2
Analyze the file storage requirements: shared file system concurrently mounted by Linux instances across three Availability Zones.
Identify Amazon Elastic File System (Amazon EFS) as the appropriate managed file storage service since it supports NFSv4 mounts across multiple Availability Zones concurrently.
EFS is a native shared file storage service designed for concurrent access from Linux hosts.
3
Evaluate key delegation requirements for EFS encryption at rest.
Choose a customer managed KMS key rather than an AWS managed key.
AWS managed keys do not support policy modification to delegate cross-account access to the security auditing account, whereas customer managed keys support full policy customization.

Key Concept

Selecting appropriate database and storage services based on workload characteristics (NoSQL vs. File), performance parameters, replication capabilities, and cross-account encryption access control requirements.
Estimated Time:2m 30s
Page 1 / 29Next