All practice questions

1006 questions

All types1,964 Multiple choice1,006 Multiple select931 Ordering27

A company needs to interconnect 20 VPCs across multiple AWS accounts in a single AWS Region. The network design must support routing between all VPCs and an on-premises data center. Additionally, instances in all VPCs must be able to resolve domain names hosted in a single Route 53 Private Hosted Zone (PHZ) in a central shared services account. The solution must minimize administrative overhead and maintain high availability for outbound internet traffic. Which solution meets these requirements?

Associate a Direct Connect Gateway directly with the Virtual Private Gateways (VGWs) of all 20 VPCs, and rely on the Direct Connect Gateway to route transitive traffic between the VPCs and to the on-premises data center.

Deploy an AWS Transit Gateway to interconnect the VPCs and connect the on-premises network. Associate the centralized Route 53 Private Hosted Zone with all VPCs across the accounts, and deploy redundant NAT Gateways across multiple Availability Zones in an egress VPC.

Deploy an AWS Transit Gateway to interconnect the VPCs and connect the on-premises network. Configure a Route 53 Private Hosted Zone in the central account but do not associate it with the other VPCs, assuming DNS queries will route over the Transit Gateway.

Deploy an AWS Transit Gateway to interconnect the VPCs. Route all outbound internet traffic from all Availability Zones in the attached VPCs through a single NAT Gateway located in a single public subnet of a centralized egress VPC.

Show answer & explanation

Answer: Deploy an AWS Transit Gateway to interconnect the VPCs and connect the on-premises network. Associate the centralized Route 53 Private Hosted Zone with all VPCs across the accounts, and deploy redundant NAT Gateways across multiple Availability Zones in an egress VPC.

Answer

The correct architecture uses AWS Transit Gateway to act as a centralized hub for routing traffic transitively between all 20 VPCs and the on-premises data center. To allow DNS resolution for shared internal domains, the Route 53 Private Hosted Zone (PHZ) must be associated with all consumer VPCs across the accounts. Finally, high availability for egress traffic is maintained by using redundant NAT Gateways across multiple Availability Zones in the centralized egress VPC.

Step-by-Step Solution

Evaluate the routing requirements for transitive VPC-to-VPC and hybrid traffic.

Determine that AWS Transit Gateway is the appropriate service to support transitive routing and simplify connectivity for 20 VPCs.

Direct Connect Gateway cannot perform transitive routing between VPCs directly, making Transit Gateway necessary.

Evaluate the DNS configuration needed for cross-account private DNS resolution.

Determine that the central Private Hosted Zone (PHZ) must be associated with every VPC that requires resolution.

VPCs cannot resolve records in a PHZ unless the PHZ is explicitly associated with them.

Assess the high availability configuration for outbound internet traffic.

Determine that redundant NAT Gateways must be deployed across multiple Availability Zones in the central egress VPC.

A single NAT Gateway creates a single point of failure for outbound traffic across all Availability Zones.

Key Concept

AWS Transit Gateway for transitive hybrid routing, centralized Route 53 Private Hosted Zone association, and multi-AZ redundant egress architecture.

Question 2Question →

An enterprise is designing a multi-account AWS environment using AWS Organizations. The security team must enforce the following compliance requirements:

1. Member accounts must not be able to disable or disassociate Amazon GuardDuty.
2. A custom IAM role named `SecurityAuditRole` in member accounts, which is used for security scanning, must be protected against modification or deletion by any user in those accounts.
3. Centralized AWS CloudTrail logs from all member accounts must be encrypted in a dedicated S3 bucket in a Security account using an encryption key that permits cross-account log delivery.

Which combination of actions will meet these requirements with the least operational complexity?

Apply a Service Control Policy (SCP) at the Organization root that denies guardduty:Delete* and guardduty:Disassociate*, and denies IAM write actions where the resource is arn:aws:iam::*:role/SecurityAuditRole. Ensure local users in member accounts are granted permissions via local IAM policies. For CloudTrail, encrypt the S3 bucket in the Security account using an AWS KMS customer managed key, and update its key policy to allow the CloudTrail service principal from the Organization to perform cryptographic operations.

Apply a Service Control Policy (SCP) at the Organization root that grants full administrator privileges to all users, except for denying guardduty:Delete* and guardduty:Disassociate*, and denying IAM write actions on arn:aws:iam::*:role/SecurityAuditRole. Rely on this SCP to grant access to member account users without configuring local IAM policies. For CloudTrail, encrypt the S3 bucket in the Security account using an AWS KMS customer managed key, and update its key policy to allow the CloudTrail service principal.

Apply a Service Control Policy (SCP) at the Organization root that denies guardduty:Delete* and guardduty:Disassociate*, and denies IAM write actions where the resource is arn:aws:iam::*:role/SecurityAuditRole. In the member accounts, grant permissions via local IAM policies. For CloudTrail, encrypt the S3 bucket in the Security account using the default AWS managed key (aws/s3), and configure the key policy of aws/s3 to allow the CloudTrail service principal from all member accounts to perform cryptographic operations.

Apply a Service Control Policy (SCP) at the Organization root that denies guardduty:Delete* and guardduty:Disassociate*, and denies IAM write actions on arn:aws:iam::*:role/SecurityAuditRole. Create the SecurityAuditRole in all member accounts and establish a trust relationship with an external SAML identity provider, specifying the sts:AssumeRole action in the trust policy instead of sts:AssumeRoleWithSAML to simplify federated access. For CloudTrail, encrypt the S3 bucket in the Security account using an AWS KMS customer managed key.

Show answer & explanation

Answer: Apply a Service Control Policy (SCP) at the Organization root that denies guardduty:Delete* and guardduty:Disassociate*, and denies IAM write actions where the resource is arn:aws:iam::*:role/SecurityAuditRole. Ensure local users in member accounts are granted permissions via local IAM policies. For CloudTrail, encrypt the S3 bucket in the Security account using an AWS KMS customer managed key, and update its key policy to allow the CloudTrail service principal from the Organization to perform cryptographic operations.

Answer

Apply a Service Control Policy (SCP) at the Organization root that denies guardduty:Delete* and guardduty:Disassociate*, and denies IAM write actions where the resource is the specific SecurityAuditRole. Ensure local users in member accounts are granted permissions via local IAM policies. For CloudTrail, encrypt the S3 bucket in the Security account using an AWS KMS customer managed key, and update its key policy to allow the CloudTrail service principal from the Organization to perform cryptographic operations.

The correct solution uses an Organization-level SCP to restrict administrative actions (GuardDuty deletion and modification of the SecurityAuditRole) while relying on local IAM policies to grant permissions. It also uses a customer managed KMS key to support cross-account log encryption for CloudTrail, which is a requirement since AWS-managed keys cannot be shared across accounts.

Step-by-Step Solution

Enforce preventative guardrails using AWS Organizations Service Control Policies (SCPs).

SCPs are applied at the root of the Organization, preventing all roles/users (including root users of member accounts) from deleting/disassociating GuardDuty or modifying the SecurityAuditRole.

SCPs establish permission boundaries across the multi-account structure but do not grant permissions directly.

Configure local IAM permissions inside member accounts.

Local administrators configure IAM users, groups, or roles with policy access.

Since SCPs only filter permissions, local IAM policies are still required to grant active permissions.

Set up centralized logging and custom key encryption.

Create a customer managed key (CMK) in KMS in the Security account, configure its policy to allow CloudTrail from the Organization to encrypt logs, and specify this key for the S3 bucket encryption.

AWS-managed KMS keys (like aws/s3) cannot be shared across accounts or customized, necessitating the use of a Customer Managed Key.

Key Concept

AWS Organizations SCP boundaries combined with Customer Managed KMS Keys for cross-account governance.

Question 3Question →

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?

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 two Availability Zones, routing outbound internet traffic from all private subnets through a single NAT Gateway located in the primary Availability Zone of each Region to optimize NAT running costs. 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.

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.

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 in us-east-1, but do not associate it with the VPC in us-west-2, relying instead on Route 53 Resolver endpoint rules to forward queries to us-east-1. Set up Route 53 Failover routing with health checks.

Configure AWS Backup to take hourly copy-replicated snapshots of the Amazon Aurora DB cluster in us-east-1 and copy them to us-west-2, restoring the database in the secondary Region during failover. 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.

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

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.

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.

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 4Question →

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?

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.

Deploy an Amazon RDS for MySQL DB instance in a Multi-AZ deployment, and configure the application to send read queries directly to the standby instance in the secondary Availability Zone during peak traffic.

Deploy a single-node Amazon RDS for MySQL DB instance, and configure a cross-region read replica to act as the primary failover target with an automated script to promote the replica within 60 seconds.

Deploy an Amazon Aurora MySQL DB cluster, configure cross-account sharing using AWS-managed KMS keys to run read replicas in a secondary audit account, and scale them to absorb the read spikes.

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

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.

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.

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 5Question →

A software-as-a-service (SaaS) collaboration platform uses an Amazon RDS for PostgreSQL DB instance to manage user workspaces, active tasks, and team permissions. During peak business hours, the database experiences severe performance degradation, with CPU utilization exceeding 90% and query response times increasing significantly.

A database analysis reveals two main contributors to the bottleneck:
1. A massive volume of repetitive, read-only queries from application servers fetching static team permission configurations.
2. Exhaustion of database connection limits due to thousands of transient AWS Lambda functions frequently opening and closing connections to verify user session tokens.

The session token verification data changes dynamically and must be cached with high availability. The cache must support replication and automatic failover across multiple Availability Zones to prevent user session loss if a primary cache node fails.

Which architecture should a solutions architect implement to address these performance bottlenecks while meeting the high availability requirements?

Deploy an Amazon RDS Proxy between the Lambda functions and the PostgreSQL database to manage connection pooling, and implement an Amazon ElastiCache for Redis replication group with Multi-AZ enabled to cache the team permission rules and user session tokens.

Deploy an Amazon RDS Proxy between the Lambda functions and the PostgreSQL database to manage connection pooling, and implement an Amazon ElastiCache for Memcached cluster to cache the team permission rules and user session tokens.

Enable Multi-AZ deployment on the Amazon RDS for PostgreSQL DB instance, route the read-only queries for the team permission rules to the standby replica, and configure AWS Lambda reserved concurrency to limit the database connection count.

Deploy an Amazon ElastiCache for Memcached cluster with automatic replication across multiple Availability Zones to cache the team permission rules and user session tokens, and configure the Lambda functions to use an RDS Read Replica for database connection pooling.

Show answer & explanation

Answer: Deploy an Amazon RDS Proxy between the Lambda functions and the PostgreSQL database to manage connection pooling, and implement an Amazon ElastiCache for Redis replication group with Multi-AZ enabled to cache the team permission rules and user session tokens.

Answer

The correct solution uses Amazon RDS Proxy to pool database connections from the AWS Lambda functions, solving the connection exhaustion problem. It also uses an Amazon ElastiCache for Redis replication group with Multi-AZ enabled, meeting the replication and automatic failover requirements to ensure that cached session tokens survive node failures.

Step-by-Step Solution

Address the connection limit exhaustion caused by transient compute resources.

Introduce Amazon RDS Proxy to pool and share database connections from the AWS Lambda functions.

Lambda functions scale rapidly and open many short-lived connections, which easily exhausts database connection limits. RDS Proxy keeps database connections open and multiplexes the incoming traffic.

Select the correct caching engine based on high availability and replication requirements.

Choose Amazon ElastiCache for Redis over ElastiCache for Memcached.

The scenario requires session data to survive cache node failures through replication and automatic failover across multiple Availability Zones. Redis supports replication groups and Multi-AZ failover, whereas Memcached is a non-replicated cache.

Evaluate the read-scaling mechanism for database queries.

Avoid routing read traffic to the RDS Multi-AZ standby.

RDS standby replicas in a Multi-AZ deployment are passive and cannot serve read traffic. Offloading read queries requires a caching layer (like Redis) or dedicated Read Replicas.

Key Concept

Database connection pooling and cache replication strategies

Estimated Time:2m 30s

Question 6Question →

An energy utility company is migrating its regional billing system to AWS. The current architecture consists of 150 VMware vSphere VMs running Red Hat Enterprise Linux (RHEL) and Windows Server that host the web and application tiers, and 12 physical bare-metal servers running IBM AIX that host the core database engines. The security team has dictated two compliance requirements: (1) no software agents may be installed on the bare-metal database servers, and (2) the network team needs exact network dependency mappings (active ports, IP addresses, and connections) for the RHEL and Windows VMs to design target AWS Security Groups. The solutions architect must discover this environment, map the dependencies, and track the migration status from a centralized console. Which approach meets these requirements with the least operational effort?

Deploy the AWS Application Discovery Agent on the VMware vSphere VMs to collect network dependency mappings. For the IBM AIX database servers, manually collect their specifications and network connections, and import the data into AWS Migration Hub using the import CSV template. Use AWS Migration Hub to track the migration.

Deploy the AWS Application Discovery Agentless Collector on the VMware vSphere vCenter Server to gather VM configuration and network dependencies. For the IBM AIX database servers, install the AWS Application Discovery Agent directly to capture database connections. Use AWS Migration Hub to track the migration.

Deploy the AWS Application Discovery Agentless Collector on the VMware vSphere vCenter Server. For the IBM AIX database servers, manually collect their configurations and upload them using the AWS Migration Hub import CSV template. Use AWS Migration Hub to track the migration.

Deploy the AWS Application Discovery Agent on all VMware vSphere VMs and the IBM AIX database servers. Enable agent-based discovery to stream all configuration, network connection, and process details directly to the Application Discovery Service. Use AWS Migration Hub to track the migration.

Show answer & explanation

Answer: Deploy the AWS Application Discovery Agent on the VMware vSphere VMs to collect network dependency mappings. For the IBM AIX database servers, manually collect their specifications and network connections, and import the data into AWS Migration Hub using the import CSV template. Use AWS Migration Hub to track the migration.

Answer

The correct option is correct because the AWS Application Discovery Agent supports Windows and Linux operating systems on VMware VMs and gathers the detailed network connection mapping required for designing target AWS Security Groups. Since IBM AIX is not supported by the Discovery Agent and security policies prevent agent installation on the database tier, manually collecting the database configuration details and importing them using the AWS Migration Hub CSV template is the only viable approach that fulfills all security and OS constraints.

Step-by-Step Solution

Analyze VM discovery requirements

The RHEL and Windows VMs require network dependency mapping (IPs, ports, connections) to build security groups.

This requirement determines whether to use the Agent-based or Agentless discovery tool.

Evaluate AWS Application Discovery Service tools

Identify that the Agentless Collector only gathers configuration and performance metrics, while the Application Discovery Agent captures network connections.

Choosing the agent for VMs ensures that network dependency mapping data is successfully collected.

Evaluate AIX and bare-metal constraints

The IBM AIX servers run on bare-metal and cannot support the discovery agent, and installing agents on these database servers is blocked by compliance.

Alternative discovery methods must be chosen for the database tier.

Select data import method for database tier

Choose the Migration Hub CSV import template to record the configurations of the AIX databases.

Manual import is the standard method for recording servers that cannot run agents or agentless collection.

Consolidate monitoring

Integrate both the agent-based discovery data and the manually imported CSV data into AWS Migration Hub.

This provides a single dashboard to track the migration status of all assets.

Key Concept

AWS Application Discovery Service supports agent-based discovery (which captures process and network dependency details) and agentless discovery (which captures configuration and performance metrics for VMware VMs). When servers cannot run agents due to OS support (such as IBM AIX) or security policies, the AWS Migration Hub import CSV template allows solutions architects to manually add these assets to the migration inventory.

Estimated Time:2m 0s

Question 7Question →

A logistics company is designing a new international package tracking application. The application requires a relational database to store shipping transit logs (OLTP workload). The system must meet a recovery point objective (RPO) of under 5 seconds and a recovery time objective (RTO) of under 2 minutes in the event of a regional outage. Additionally, the database must support low-latency local read access and horizontal read scaling for users in both the primary and secondary AWS regions. Which database and storage strategy meets these requirements?

Deploy Amazon RDS for PostgreSQL with Multi-AZ enabled in the primary region and a cross-region read replica in the secondary region. Route local read traffic in the primary region to the Multi-AZ standby database instance to scale read performance during peak tracking hours.

Deploy an Amazon Aurora Global Database. Use a customer managed KMS key in the primary region and a corresponding customer managed KMS key in the secondary region for encryption. Configure Aurora Auto Scaling for readers in both the primary and secondary regions to handle read traffic spikes.

Deploy an Amazon Aurora Global Database. Encrypt the primary cluster using the default AWS-managed KMS key (aws/rds), and modify the default key policy to grant the secondary region's replication infrastructure access to decrypt the data.

Deploy a single-region Amazon Aurora PostgreSQL database. Configure AWS Backup to take continuous backups and copy them to the secondary region. In the event of a regional outage, restore the database from the copied backup in the secondary region.

Show answer & explanation

Answer: Deploy an Amazon Aurora Global Database. Use a customer managed KMS key in the primary region and a corresponding customer managed KMS key in the secondary region for encryption. Configure Aurora Auto Scaling for readers in both the primary and secondary regions to handle read traffic spikes.

Answer

Deploy an Amazon Aurora Global Database with customer managed KMS keys in both regions and configure Aurora Auto Scaling for readers in both the primary and secondary regions.

Deploying an Amazon Aurora Global Database with customer managed KMS keys and reader auto scaling satisfies all requirements. Aurora Global Database has sub-second replication latency (meeting RPO) and can be promoted to a primary cluster in under a minute (meeting RTO). Reader auto scaling handles peak loads in both regions, and customer managed KMS keys allow the required cross-region decryption configurations.

Step-by-Step Solution

Evaluate the RTO/RPO requirements.

An RPO under 5 seconds and RTO under 2 minutes require continuous, low-latency cross-region replication and rapid promotion of the secondary cluster, which are features of Amazon Aurora Global Database.

This rules out backup-and-restore strategies that take hours.

Determine the scale-out reader requirements.

Using Aurora Auto Scaling on readers in both regions allows local read performance scaling during traffic surges.

Amazon RDS Multi-AZ standby instances cannot serve traffic and do not solve read performance spikes.

Analyze cross-region database encryption constraints.

Customer managed KMS keys must be used because AWS-managed KMS keys do not support policy modifications required for cross-region encryption key sharing.

Ensures the replication infrastructure has the necessary permissions to decrypt data in the secondary region.

Key Concept

Multi-region database design balancing replication lag, read scaling, and KMS encryption compatibility.

Question 8Question →

A logistics company is designing a real-time fleet monitoring platform for $10$ million active delivery vehicles. Each vehicle transmits telemetry data every $5$ seconds over HTTPS, resulting in a sustained ingestion rate of $2$ 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?

Deploy an Application Load Balancer (ALB) 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.

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 Memcached cluster with Multi-AZ replication enabled, and write the historical telemetry to an Amazon DynamoDB table in On-Demand capacity mode.

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.

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 RDS for PostgreSQL database configured with Multi-AZ, and configure the application to scale read queries for latest positions by directing them to the Multi-AZ standby instance.

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

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

2

million to

4

million requests per second in less than a minute.

To prevent request drops and high latency during sudden flash traffic surges.

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.

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 9Question →

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?

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.

Configure the S3 bucket in the Security account to use default S3 encryption with the AWS managed key (aws/s3). Create a bucket policy that grants s3:PutObject to the Production application role and s3:GetObject to the Audit compliance role. Grant the Audit compliance role decryption permissions using local IAM policies in the Production account.

Create both the S3 bucket and a customer managed key (CMK) in the Security account. Create a Service Control Policy (SCP) at the AWS Organizations root level that allows the Audit compliance role to perform kms:Decrypt and s3:GetObject on the Security account resources. Attach this SCP to the OUs containing the Production and Audit accounts.

Create the S3 bucket and a customer managed key (CMK) in the Security account. Configure the KMS key policy to trust the Audit account for kms:Decrypt operations. Authorize the Audit compliance role to read S3 objects by configuring local IAM policies in the Audit account, without adding the Audit role to the S3 bucket policy in the Security account.

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

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.

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.

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 10Question →

A global company has a multi-account AWS environment with $40$ spoke VPCs distributed across us-east-1 and us-west-2. The company is designing a hybrid network architecture to connect these VPCs to an on-premises data center with a redundant AWS Direct Connect (DX) infrastructure. The solution must allow spoke VPCs to communicate with the data center and with each other across regions. Additionally, all VPCs must resolve private DNS names hosted on-premises and in a centralized AWS Route 53 Private Hosted Zone (PHZ) in a shared services account, while outbound internet traffic must be routed through centralized NAT Gateways to minimize costs while maintaining high availability. Which architecture meets these requirements with the least administrative overhead and maintains high availability?

Deploy an AWS Transit Gateway (TGW) in each region and peer them. Attach the spoke VPCs to their regional TGW. Associate a Direct Connect Gateway (DXGW) with a Transit VIF on the Direct Connect connections, and associate the DXGW with the TGW in each region. In the shared services account, associate the Route 53 Private Hosted Zone (PHZ) with the spoke VPCs in both regions, and deploy centralized Route 53 Resolver outbound endpoints to forward on-premises queries. In each region, deploy redundant NAT Gateways across multiple Availability Zones in a dedicated egress VPC attached to the TGW, routing all outbound traffic (

0.0.0.0/0

) from the spoke VPCs to the egress VPC.

Connect the spoke VPCs in each region directly to a centralized Direct Connect Gateway (DXGW) using Private Virtual Interfaces (VIFs) to enable transitive routing between the VPCs and to the on-premises data center. Associate the centralized PHZ with the DXGW to enable DNS resolution across all accounts. Deploy a single NAT Gateway in the shared services VPC in the primary region to handle all egress traffic for both regions.

Deploy an AWS Transit Gateway (TGW) in each region and peer them. Attach the spoke VPCs to their regional TGW. Associate a Direct Connect Gateway (DXGW) with a Transit VIF on the Direct Connect connections, and associate the DXGW with the TGW in each region. Create a duplicate Route 53 PHZ in each individual spoke AWS account to avoid cross-account VPC associations, and configure Route 53 Resolver outbound endpoints in each spoke VPC to resolve on-premises domains. In each region, deploy redundant NAT Gateways across multiple Availability Zones in a dedicated egress VPC attached to the TGW, routing all outbound traffic (

0.0.0.0/0

) from the spoke VPCs to the egress VPC.

Deploy an AWS Transit Gateway (TGW) in each region and peer them. Attach the spoke VPCs to their regional TGW. Associate a Direct Connect Gateway (DXGW) with a Transit VIF on the Direct Connect connections, and associate the DXGW with the TGW in each region. In the shared services account, associate the Route 53 Private Hosted Zone (PHZ) with the spoke VPCs in both regions, and deploy centralized Route 53 Resolver outbound endpoints to forward on-premises queries. In each region, deploy a single NAT Gateway in a single Availability Zone within a dedicated egress VPC attached to the TGW, routing all outbound traffic (

0.0.0.0/0

) from the spoke VPCs to the egress VPC to reduce NAT Gateway costs.

Show answer & explanation

Answer: Deploy an AWS Transit Gateway (TGW) in each region and peer them. Attach the spoke VPCs to their regional TGW. Associate a Direct Connect Gateway (DXGW) with a Transit VIF on the Direct Connect connections, and associate the DXGW with the TGW in each region. In the shared services account, associate the Route 53 Private Hosted Zone (PHZ) with the spoke VPCs in both regions, and deploy centralized Route 53 Resolver outbound endpoints to forward on-premises queries. In each region, deploy redundant NAT Gateways across multiple Availability Zones in a dedicated egress VPC attached to the TGW, routing all outbound traffic ( $0.0.0.0/0$ ) from the spoke VPCs to the egress VPC.

Answer

Deploy regional Transit Gateways (TGWs) peered together, associate them with a Direct Connect Gateway (DXGW) via a Transit VIF, associate the centralized Private Hosted Zone (PHZ) with all spoke VPCs, utilize shared Route 53 Resolver outbound endpoints, and route egress traffic through dedicated egress VPCs with redundant NAT Gateways in each region.

The architecture that peers regional Transit Gateways (TGWs) and associates them with a Direct Connect Gateway (DXGW) via a Transit VIF provides multi-region, multi-account hybrid connectivity with minimal VIF management. Centralizing Route 53 Resolver outbound endpoints in a shared services account and sharing the forwarding rules via AWS Resource Access Manager (RAM) to the spoke VPCs is the most cost-effective and operationally efficient way to resolve on-premises DNS names. Cross-account association of the Route 53 Private Hosted Zone (PHZ) enables all VPCs to resolve internal AWS domains without duplicating hosted zones. Finally, placing redundant NAT Gateways across multiple Availability Zones in dedicated egress VPCs ensures high availability for outbound traffic while centralizing egress management.

Step-by-Step Solution

Establish multi-account, multi-region hybrid connectivity.

Attach spoke VPCs to regional Transit Gateways, peer the Transit Gateways, and connect them to the on-premises data center using a Direct Connect Gateway with a Transit VIF.

This pattern simplifies BGP routing, minimizes VIF configuration, and enables both VPC-to-on-premises and transitive cross-region VPC-to-VPC routing.

Design a centralized and scalable DNS resolution architecture.

Associate the centralized Private Hosted Zone in the shared services account with the spoke VPCs, and deploy central Route 53 Resolver outbound endpoints, sharing the forwarding rules with all accounts via Resource Access Manager.

This avoids the administrative overhead of duplicating hosted zones and the high cost of deploying duplicate Resolver endpoints in every spoke VPC.

Design a highly available and cost-effective internet egress path.

Configure dedicated egress VPCs attached to the Transit Gateways with redundant NAT Gateways across multiple Availability Zones in each region.

Centralizing NAT Gateways reduces NAT Gateway hourly charges compared to deploying them in every spoke VPC, while using multiple Availability Zones ensures high availability for egress traffic.

Key Concept

Multi-region hybrid network integration using AWS Transit Gateway, Direct Connect Gateway, cross-account Route 53 Resolver endpoints, and centralized egress VPCs.

Estimated Time:2m 0s

Question 11Question →

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?

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.

Configure the AutoScalingRollingUpdate update policy in the CloudFormation template, setting the MinInstancesInService parameter equal to the Auto Scaling group's desired capacity. Implement the cfn-signal helper script in the instance user data to notify CloudFormation of a successful bootstrap before updating the remaining instances.

Configure AWS CodeDeploy to manage a blue/green deployment using the existing Auto Scaling group. Define a deployment configuration that utilizes the AfterAllowTestTraffic lifecycle event hook to run validation tests on the new instances before CodeDeploy switches the production traffic to the new Auto Scaling group.

Create a nested CloudFormation stack containing the Auto Scaling group with the UpdateReplacePolicy attribute set to Retain. Deploy the new stack version alongside the old version, manually modify the ALB listener rules to point to the new Auto Scaling group's target group after validation, and then delete the old stack.

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

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

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.

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.

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 12Question →

An enterprise is designing a hybrid network architecture for its multi-account AWS environment. The environment consists of $30$ spoke VPCs spread across two AWS Regions: `us-east-1` and `us-west-2`. The VPCs are connected using an AWS Transit Gateway (TGW) in each region. The on-premises data center must connect to AWS with high availability and optimal performance.

The primary path is a $10$ Gbps AWS Direct Connect (DX) connection using a Transit Virtual Interface (Transit VIF) terminated at a Direct Connect Gateway (DXGW) associated with both TGWs. A backup path is established using an AWS Site-to-Site VPN connection over the internet, terminating directly on the TGWs.

During failover testing, the network team observes that traffic originating from the on-premises data center to the AWS spoke VPCs is being load-balanced across both the DX and VPN paths, causing asymmetric routing. Furthermore, outbound traffic from the AWS spoke VPCs to the on-premises network ( $10.0.0.0/8$ ) is preferring the VPN path because the on-premises router is advertising $10.0.0.0/8$ over the DX connection and more specific subnets ( $10.0.0.0/16$ and $10.1.0.0/16$ ) over the VPN connection.

Which combination of routing configurations will resolve these routing issues and ensure that the DX connection is prioritized for bi-directional traffic, while maintaining the VPN as a dynamic failover?

Configure the on-premises router to advertise the identical

10.0.0.0/8

prefix over both the DX and VPN BGP sessions. Set a higher BGP Local Preference on the on-premises router for routes received from AWS via the DX connection compared to the VPN. Prepend the on-premises Autonomous System (AS) number multiple times on the BGP advertisements sent to AWS over the VPN connection.

Configure the on-premises router to advertise the identical

10.0.0.0/8

prefix over both BGP sessions. Set a higher Multi-Exit Discriminator (MED) value on the BGP advertisements sent to AWS over the VPN connection. On the on-premises router, prepend the Autonomous System (AS) number on the DX BGP advertisements to skew the inbound path selection.

Leave the prefix advertisements as they are. In the AWS Transit Gateway route tables, configure a static route for

10.0.0.0/8

pointing to the DXGW attachment, and set its administrative distance lower than the propagated routes from the VPN connection to override the subnet specificity.

Route all on-premises and outbound traffic through a centralized egress VPC in each region containing a single NAT Gateway. On the on-premises router, configure policy-based routing to forward traffic to the NAT Gateway IP address, and configure the Transit Gateway to prioritize the NAT Gateway route over the VPN.

Show answer & explanation

Answer: Configure the on-premises router to advertise the identical $10.0.0.0/8$ prefix over both the DX and VPN BGP sessions. Set a higher BGP Local Preference on the on-premises router for routes received from AWS via the DX connection compared to the VPN. Prepend the on-premises Autonomous System (AS) number multiple times on the BGP advertisements sent to AWS over the VPN connection.

Answer

Configure the on-premises router to advertise the identical

10.0.0.0/8

The correct configuration addresses both inbound and outbound traffic paths. First, by advertising the identical prefix of

10.0.0.0/8

over both BGP sessions, it eliminates the longest prefix match bias toward the VPN. Second, by prepending the Autonomous System (AS) number on the VPN advertisements, the AS-path length for the VPN route becomes longer than the DX route, which causes AWS Transit Gateway to prefer the DX path for outbound traffic. Finally, setting a higher BGP Local Preference on the on-premises router for the DX connection ensures that traffic originating from the data center to AWS prefers the DX path, resolving the asymmetric routing issue.

Step-by-Step Solution

Align prefix advertisements across both hybrid paths.

The on-premises router is configured to advertise the same

10.0.0.0/8

prefix on both the DX Transit VIF and Site-to-Site VPN BGP sessions.

AWS Transit Gateway evaluates route preference starting with the longest prefix match. Because the VPN was advertising more specific subnets (

10.0.0.0/16

and

10.1.0.0/16

), AWS preferred the VPN path. Identical prefixes allow the TGW to move to the next BGP selection criteria.

Configure AS-path prepending on the standby path.

The Autonomous System (AS) number is prepended multiple times to BGP route advertisements sent over the VPN connection to AWS.

When prefix lengths are equal, AWS Transit Gateway prefers routes with shorter AS-path lengths. Prepending the AS-path on the VPN makes it look longer, forcing AWS to prefer the DX path for outbound traffic to on-premises.

Configure Local Preference on the customer gateway (on-premises router).

A higher BGP Local Preference is applied to routes received from AWS via the DX connection relative to those received via the VPN.

Local Preference is an attribute used within an Autonomous System to choose the exit point for outbound traffic. Setting it higher on the DX connection ensures that traffic originating from the data center to AWS prefers the DX connection over the VPN, preventing asymmetric routing.

Key Concept

BGP Path Selection and Longest Prefix Match in Hybrid AWS Environments

Question 13Question →

A financial services company is designing a hybrid network architecture to connect $15$ spoke VPCs in a single AWS Region to its on-premises data center. The company has a dedicated $10\text{ Gbps}$ AWS Direct Connect connection and wants to establish an AWS Site-to-Site VPN connection over the public internet as a backup. The architecture must ensure that all spoke VPCs can communicate with the data center, that the VPN is only utilized if the Direct Connect connection becomes unavailable, and that administrative overhead is minimized. Which approach should the solutions architect recommend?

Create a Virtual Private Gateway (VGW) in each of the

15

spoke VPCs. Associate all

15

VGWs with a single Direct Connect Gateway (DXGW) connected via a Private Virtual Interface (Private VIF). Establish a separate Site-to-Site VPN connection from the on-premises data center to each of the

15

VGWs, using BGP routing with AS PATH prepending on the VPN connections.

Deploy an AWS Transit Gateway (TGW) and attach the

15

spoke VPCs to it. Associate the TGW with a Direct Connect Gateway (DXGW) connected via a Transit Virtual Interface (Transit VIF). Establish a single AWS Site-to-Site VPN connection from the on-premises data center to the TGW. Advertise identical prefixes over BGP for both paths, and prepend the AS PATH on the VPN connection to make it the less preferred path.

Deploy an AWS Transit Gateway (TGW) and attach the

15

spoke VPCs to it. Associate the TGW with a Direct Connect Gateway (DXGW) connected via a Private Virtual Interface (Private VIF). Establish a single AWS Site-to-Site VPN connection from the on-premises data center to the TGW. Configure static routes on the TGW pointing to the DXGW with a lower metric than the VPN routes.

Establish a hub-and-spoke VPC Peering topology by peering all

15

spoke VPCs with a central transit VPC. Associate the central VPC's Virtual Private Gateway (VGW) with a Direct Connect Gateway (DXGW) connected via a Private Virtual Interface (Private VIF). Create a single Site-to-Site VPN connection to the central VPC's VGW. Configure the route tables of the spoke VPCs to route on-premises traffic through the central VPC.

Show answer & explanation

Answer: Deploy an AWS Transit Gateway (TGW) and attach the $15$ spoke VPCs to it. Associate the TGW with a Direct Connect Gateway (DXGW) connected via a Transit Virtual Interface (Transit VIF). Establish a single AWS Site-to-Site VPN connection from the on-premises data center to the TGW. Advertise identical prefixes over BGP for both paths, and prepend the AS PATH on the VPN connection to make it the less preferred path.

Answer

Deploy an AWS Transit Gateway (TGW) and attach the

15

The correct solution uses AWS Transit Gateway to aggregate connectivity for the

15

spoke VPCs, bypassing the

10

VGW attachment limit of a Direct Connect Gateway. It utilizes a Transit Virtual Interface (Transit VIF) to connect the Transit Gateway to the Direct Connect Gateway, which is the only supported VIF type for Transit Gateway. Active/passive routing is achieved dynamically using BGP by advertising identical prefixes on both paths and prepending the AS PATH on the VPN connection, ensuring AWS prefers the shorter AS PATH on the Direct Connect connection under normal operations.

Step-by-Step Solution

Evaluate the scaling requirement for the

15

spoke VPCs.

Identify that a standard Direct Connect Gateway directly associated with Virtual Private Gateways (VGWs) is limited to a maximum of

10

VPCs, necessitating the use of AWS Transit Gateway (TGW) to aggregate the attachments.

Ensures the solution scales to meet the requirements of

15

VPCs without hitting service limits.

Determine the correct interface type for connecting the Transit Gateway to the Direct Connect Gateway.

Confirm that a Transit Virtual Interface (Transit VIF) is required on the Direct Connect connection to terminate on the Direct Connect Gateway and associate with the TGW.

Private VIFs only support VGW associations and cannot be used to connect to a Transit Gateway.

Configure backup routing and path preference.

Set up a Site-to-Site VPN connection to the Transit Gateway, advertise the same routes via BGP, and prepend the AS PATH on the VPN connection.

Allows BGP to automatically route traffic over the Direct Connect path as the primary route, while dynamically failing over to the VPN path only if the Direct Connect path goes offline.

Key Concept

Scale hybrid connectivity and configure active/passive routing over AWS Direct Connect and VPN using AWS Transit Gateway and Direct Connect Gateway.

Question 14Question →

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?

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.

In the Compliance account, enable default S3 bucket encryption using the AWS-managed KMS key (aws/s3). Configure the S3 bucket policy in the Compliance account to allow the ECS task role in the Application account to perform s3:PutObject. Configure the ECS task role with IAM policies allowing s3:PutObject on the bucket and kms:GenerateDataKey on the AWS-managed key.

In the Compliance account, create a Customer Managed Key (CMK). Attach a Service Control Policy (SCP) to the Organizational Unit containing the Application account that grants the ECS task role permissions to perform kms:GenerateDataKey on the CMK in the Compliance account. Configure the S3 bucket policy to allow the Application account's ECS task role to perform s3:PutObject.

In the Compliance account, create a Customer Managed Key (CMK). Configure the S3 bucket policy in the Compliance account to allow the ECS task role to perform s3:PutObject and kms:GenerateDataKey. Configure the ECS task role with an IAM policy that allows s3:PutObject on the S3 bucket.

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

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

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.

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.

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 15Question →

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\%$ 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?

Provision a second Auto Scaling group and a new ALB for the new application version. In Amazon Route 53, configure weighted routing policies for the application's domain name, setting a weight of

10

for the new ALB and

90

for the existing ALB. If errors occur, update the Route 53 weights to route

100\%

of the traffic to the existing ALB.

Configure the existing Auto Scaling group with a CloudFormation UpdatePolicy set to AutoScalingRollingUpdate. Configure the MaxBatchSize parameter to

10\%

of the total instance count to ensure only a subset of instances are updated first. Define CloudFormation rollback triggers using Amazon CloudWatch alarms to automatically revert the stack update if errors are detected.

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

10

to the new target group and

90

to the existing target group. After validating the deployment, update the CloudFormation template to set the weight of the new target group to

100

, and then terminate the old Auto Scaling group and target group.

Configure AWS CodeDeploy to perform an in-place deployment to the existing Auto Scaling group using the CodeDeployDefault.OneAtATime deployment configuration. Attach CloudWatch alarms to the deployment group to trigger an automatic rollback to the previous application version if errors are detected.

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 $10$ to the new target group and $90$ to the existing target group. After validating the deployment, update the CloudFormation template to set the weight of the new target group to $100$ , 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\%

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\%

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

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.

Update the Application Load Balancer listener rule in CloudFormation to assign a weight of

10

to the new target group and

90

to the original target group.

Exactly

10\%

of incoming live traffic is immediately routed to the new version.

This establishes the requested canary testing configuration at the load balancer layer.

Monitor the deployment. If errors occur, revert the weights to route

100\%

of traffic to the original target group. If successful, set the weight of the new target group to

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 16Question →

A software-as-a-service (SaaS) provider manages $50$ AWS accounts using AWS Organizations. The security team is setting up an organization-wide trail in AWS CloudTrail to consolidate log delivery into a centralized Amazon S3 bucket in a dedicated Logging account. They require all consolidated logs to be encrypted at rest using an AWS Key Management Service (AWS KMS) key.

Which configuration is required to successfully deliver the encrypted logs from all accounts to the centralized S3 bucket?

Configure the S3 bucket policy in the Logging account to allow the s3:PutObject and s3:GetBucketAcl actions for the cloudtrail.amazonaws.com service principal with a condition matching the organization ID. Create a customer managed KMS key in the Logging account with a key policy that grants the kms:GenerateDataKey* and kms:DescribeKey permissions to the CloudTrail service principal with a condition matching the organization ARN.

Configure the S3 bucket policy in the Logging account to allow the s3:PutObject and s3:GetBucketAcl actions for the cloudtrail.amazonaws.com service principal with a condition matching the organization ID. Enable default S3 bucket encryption using the AWS-managed KMS key for S3 (aws/s3) in the Logging account, and configure the trail to use this key.

Create a customer managed KMS key in the Logging account with a key policy that grants the kms:GenerateDataKey* and kms:DescribeKey permissions to the CloudTrail service principal. Create an IAM role in the Logging account that allows the CloudTrail service principal to write to the S3 bucket, and rely on IAM delegation for member accounts without modifying the S3 bucket policy.

Create a customer managed KMS key in the Logging account with a key policy that grants the kms:GenerateDataKey* and kms:DescribeKey permissions to the CloudTrail service principal. Attach a Service Control Policy (SCP) to the root of the AWS Organization that explicitly grants the s3:PutObject permission on the centralized S3 bucket to the CloudTrail service principal for all OUs.

Show answer & explanation

Answer: Configure the S3 bucket policy in the Logging account to allow the s3:PutObject and s3:GetBucketAcl actions for the cloudtrail.amazonaws.com service principal with a condition matching the organization ID. Create a customer managed KMS key in the Logging account with a key policy that grants the kms:GenerateDataKey* and kms:DescribeKey permissions to the CloudTrail service principal with a condition matching the organization ARN.

Answer

The correct answer provides the necessary resource-based policies to authorize cross-account CloudTrail log delivery and KMS encryption. Specifically, the S3 bucket policy must allow the cloudtrail.amazonaws.com service principal to write objects and read ACLs, restricted to the organization ID. In addition, because logs from member accounts are delivered to a centralized bucket, an AWS-managed KMS key cannot be used since its policy cannot be modified to permit cross-account access. Therefore, a customer managed KMS key must be created, and its key policy must allow the CloudTrail service principal to generate data keys on behalf of the organization's accounts.

Step-by-Step Solution

Configure permissions for the S3 bucket in the Logging account.

The S3 bucket policy is updated to allow the cloudtrail.amazonaws.com service principal to write logs (s3:PutObject) and read bucket ACLs (s3:GetBucketAcl), restricted to the Organization ID using the aws:PrincipalOrgID condition.

CloudTrail requires explicit bucket policy permissions to deliver logs to an S3 bucket in a different account.

Create and configure a Customer Managed Key (CMK) in AWS KMS.

A customer managed KMS key is created in the Logging account. The key policy is configured to grant kms:GenerateDataKey* and kms:DescribeKey permissions to the cloudtrail.amazonaws.com service principal, with conditions to restrict usage to trails within the Organization.

AWS-managed KMS keys cannot be shared cross-account. Consolidating encrypted logs from multiple member accounts requires a customer managed key with a custom key policy that allows cross-account usage.

Enable the KMS encryption on the organization trail.

The organization trail is configured to encrypt logs using the newly created customer managed KMS key.

This ensures that all logs delivered from any member account in the organization are securely encrypted using the customer managed KMS key before being stored in the centralized S3 bucket.

Key Concept

Centralized cross-account logging with encryption using AWS KMS customer managed keys and S3 bucket policies in a multi-account organization.

Estimated Time:2m 30s

Question 17Question →

An enterprise is designing a hybrid network architecture to connect ` $45$ ` spoke VPCs in the `us-east-1` Region to its on-premises corporate data center. The architecture must support a high-throughput primary path and a redundant backup path. The enterprise has provisioned a ` $10\text{ Gbps}$ ` AWS Direct Connect connection and wants to use an IPsec Site-to-Site VPN over the public internet as the backup. The design must ensure that the Direct Connect connection is the preferred path for all bidirectional traffic under normal operating conditions, failover to the VPN is automatic, routing is symmetric to support stateful firewalls on-premises, and administrative overhead is minimized. Which architecture and routing configuration will meet these requirements?

Configure an AWS Transit Gateway in `us-east-1` and attach the `

45

` spoke VPCs. Create a Direct Connect Gateway and associate it with the Transit Gateway using a Transit Virtual Interface. Establish an IPsec Site-to-Site VPN connection and attach it to the Transit Gateway. Enable BGP routing on both paths, and configure the on-premises router to assign a higher BGP Local Preference to routes received via the Direct Connect connection compared to the VPN connection.

Configure an AWS Transit Gateway in `us-east-1` and attach the `

45

` spoke VPCs. Create a Direct Connect Gateway and associate it with the Transit Gateway using a Private Virtual Interface. Establish an IPsec Site-to-Site VPN connection and attach it to the Transit Gateway. Configure static routes in the Transit Gateway route table pointing to the VPN attachment with a higher administrative distance to ensure it is only used during a failover.

Create a Virtual Private Gateway in each of the `

45

` spoke VPCs. Set up a mesh of VPC peering connections among all `

45

` VPCs to enable inter-VPC traffic. Associate each Virtual Private Gateway with a Direct Connect Gateway using Private Virtual Interfaces, and establish separate Site-to-Site VPN connections to each VPC to act as backup paths. Configure the on-premises router to prefer the Direct Connect path using BGP Local Preference.

Configure an AWS Transit Gateway in `us-east-1` and attach the `

45

` spoke VPCs. Create a Direct Connect Gateway and associate it with the Transit Gateway using a Transit Virtual Interface. Establish an IPsec Site-to-Site VPN connection to the Transit Gateway. Enable Equal-Cost Multi-Path routing on the Transit Gateway, and configure the on-premises router to advertise more specific prefixes over the VPN connection than over the Direct Connect connection.

Show answer & explanation

Answer: Configure an AWS Transit Gateway in `us-east-1` and attach the ` $45$ ` spoke VPCs. Create a Direct Connect Gateway and associate it with the Transit Gateway using a Transit Virtual Interface. Establish an IPsec Site-to-Site VPN connection and attach it to the Transit Gateway. Enable BGP routing on both paths, and configure the on-premises router to assign a higher BGP Local Preference to routes received via the Direct Connect connection compared to the VPN connection.

Answer

Configure an AWS Transit Gateway, connect the Direct Connect Gateway via a Transit Virtual Interface, establish a Site-to-Site VPN, use BGP routing on both paths, and configure the on-premises router to prefer the Direct Connect path using a higher BGP Local Preference.

The correct configuration uses AWS Transit Gateway to centralize connection management for the `

45

` spoke VPCs, which minimizes administrative overhead. By using a Direct Connect Gateway associated via a Transit Virtual Interface (Transit VIF), the enterprise can route traffic transitively from the Transit Gateway to the on-premises data center. BGP routing allows for dynamic failover. To ensure symmetric routing, the on-premises router must be configured with a higher BGP Local Preference for routes learned via Direct Connect, making it the preferred path for inbound traffic, while AWS automatically prefers the Direct Connect Gateway path over the VPN path for outbound traffic if AS path lengths are equal.

Step-by-Step Solution

Consolidate multi-VPC networking.

Attach all `

45

` spoke VPCs to a central AWS Transit Gateway to minimize administrative overhead.

Managing individual VPC connections or peering meshes at scale is administratively complex and does not scale.

Establish the primary and backup hybrid connectivity paths.

Associate the Direct Connect Gateway with the Transit Gateway via a Transit Virtual Interface (Transit VIF), and attach the IPsec Site-to-Site VPN directly to the Transit Gateway.

Transit Gateway requires a Transit VIF to integrate with Direct Connect Gateway for transitive routing. The Site-to-Site VPN acts as a backup path.

Configure dynamic routing for outbound traffic from AWS.

Enable BGP propagation. AWS Transit Gateway automatically prefers the Direct Connect Gateway path over the VPN path for outbound traffic when prefix lengths and AS path lengths are equal.

Using dynamic BGP propagation ensures automatic failover and allows AWS to utilize its default path selection hierarchy.

Configure dynamic routing for inbound traffic from on-premises and ensure symmetry.

Configure the customer gateway router to assign a higher BGP Local Preference to prefixes received over the Direct Connect path compared to the VPN path.

Symmetric routing is achieved when both inbound and outbound traffic prefer the same path under normal operating conditions. Local Preference is a local BGP attribute that ensures the on-premises router prefers the Direct Connect link.

Key Concept

Symmetric routing and failover in a hybrid Transit Gateway architecture using Direct Connect and Site-to-Site VPN.

Question 18Question →

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 $12$ 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?

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.

Update the CloudFormation template to configure the ASG `UpdatePolicy` with `AutoScalingReplacingUpdate`. Rely on the ALB target group's default deregistration delay to drain connections. Configure the CloudFormation stack with a rollback trigger based on CloudWatch alarms monitoring the application's health.

Configure AWS CodeDeploy to perform an In-Place deployment using a `CodeDeployDefault.AllAtOnce` configuration. Use a CodeDeploy `ApplicationStop` lifecycle hook to wait for active connections to drain. Configure CloudWatch alarms to trigger a CodeDeploy automatic rollback on deployment failure.

Create a new AWS CloudFormation template that uses the `AWS::CodeDeploy::BlueGreen` hook to manage the EC2 Auto Scaling group deployment. Configure the deployment group to use a canary shifting strategy and monitor CloudWatch alarms to trigger an automatic rollback.

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

12

minutes) before they are terminated, preventing data corruption.

Step-by-Step Solution

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.

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.

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

12

-minute limit) before signaling completion.

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 19Question →

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\%$ of the traffic to the new version for a $15$ -minute observation period. If the new version triggers any CloudWatch alarms for $5\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?

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

5\text{xx}

errors and latency as rollback triggers in the deployment group.

Configure the Amazon ECS service to use the ECS rolling update deployment type. Enable the ECS deployment circuit breaker with rollback enabled, and set the minimum healthy percent to

100\%

and maximum percent to

200\%

Deploy a second Amazon ECS service with the new application version. Configure the Application Load Balancer with two path-based target groups. Use Amazon Route 53 weighted routing policies to route

10\%

of the traffic to the new ECS service, and configure an AWS Lambda function to monitor CloudWatch alarms and update Route 53 weights to

0\%

if alarms are triggered.

Configure the Amazon ECS service to use the ECS rolling update deployment type. Use an AWS Systems Manager Automation runbook to gradually register new Fargate tasks to the target group in

10\%

increments every

1.5

minutes, and configure the target group to deregister tasks if the

5\text{xx}

metric alarm triggers.

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 $5\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\%

) to the new task set for a defined duration (such as

15

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

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.

Configure the deployment group in AWS CodeDeploy to use the predefined Canary configuration.

The deployment group is set to CodeDeployDefault.ECSCanary10Percent15Minutes, which directs

10\%

of production traffic to the new Fargate tasks for

15

minutes.

This matches the requirement to test new releases under a small portion of production load for a specific duration.

Attach CloudWatch alarms for

5\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

15

-minute canary period, CodeDeploy immediately aborts the deployment and routes

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 20Question →

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?

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.

In Account B, configure S3 Object Ownership to Bucket Owner Enforced and set the bucket's default encryption to use the AWS managed key (aws/s3). 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.

In Account B, configure S3 Object Ownership to Bucket Owner Preferred. 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 and specifies the bucket-owner-full-control canned ACL during upload.

In Account B, configure S3 Object Ownership to Bucket Owner Enforced. In the AWS Organizations management account, attach a Service Control Policy (SCP) to the Organizational Unit (OU) containing Account A and Account B that allows s3:PutObject on the bucket and kms:GenerateDataKey on the KMS CMK. In Account A, assign an IAM policy to the EC2 instances that allows s3:PutObject on the bucket in Account B.

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

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

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.

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.

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

Page 1 / 51Next

All practice questions

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept