All practice questions

1964 questions

All types1,964 Multiple choice1,006 Multiple select931 Ordering27

A financial enterprise is refactoring a data processing pipeline that spans multiple AWS accounts. A processing application hosted on Amazon EC2 instances in a private subnet of a production VPC (Account B) has no outbound internet route or NAT Gateway. The instances must read sensitive records from an Amazon S3 bucket in a compliance account (Account A). The S3 bucket is encrypted using a Customer Managed Key (CMK) in Account A. The security team requires that all data transit remain within the AWS network, and the S3 bucket must restrict access to requests originating from the production VPC's S3 Gateway VPC Endpoint. The instances use an IAM role to access the bucket. Currently, attempts to download and decrypt the S3 objects are failing. Which combination of architectural modifications will resolve the access failure while meeting all security requirements?

Deploy an Interface VPC Endpoint for KMS in the production VPC (Account B). In Account A, configure the customer-managed KMS key policy to allow the EC2 instances' IAM role to perform kms:Decrypt, and update the S3 bucket policy to allow the role to perform s3:GetObject with a condition restricting requests to the S3 Gateway VPC Endpoint ID.

Deploy an Interface VPC Endpoint for KMS in the production VPC (Account B). Update the S3 bucket policy in Account A to use the default AWS-managed S3 key (aws/s3), and configure the key policy of aws/s3 in Account A to allow the EC2 instances' IAM role to perform kms:Decrypt.

Attach a Service Control Policy (SCP) to the Organizational Unit (OU) containing Account B that explicitly grants the EC2 instances' IAM role cross-account permissions for s3:GetObject and kms:Decrypt against Account A's resources. In Account B, configure the S3 Gateway VPC Endpoint policy to allow KMS transit traffic.

Configure an AWS Transit Gateway between Account A and Account B to route KMS API traffic from Account B's private subnets to Account A. In Account A, configure an AWS Direct Connect Gateway to transitively route these KMS requests to the public AWS KMS service endpoint.

Show answer & explanation

Answer: Deploy an Interface VPC Endpoint for KMS in the production VPC (Account B). In Account A, configure the customer-managed KMS key policy to allow the EC2 instances' IAM role to perform kms:Decrypt, and update the S3 bucket policy to allow the role to perform s3:GetObject with a condition restricting requests to the S3 Gateway VPC Endpoint ID.

Answer

The correct solution involves deploying a KMS Interface VPC Endpoint in Account B because the S3 Gateway VPC Endpoint only routes S3 traffic, leaving the isolated EC2 instances unable to reach the public KMS endpoint to decrypt the downloaded objects. Furthermore, a Customer Managed Key in Account A is required because default AWS-managed keys cannot be shared cross-account, and the S3 bucket policy must explicitly permit the cross-account role while enforcing the S3 Gateway VPC Endpoint source condition.

Step-by-Step Solution

Address the network path for KMS requests.

Create an Interface VPC Endpoint for KMS (com.amazonaws.region.kms) in the production VPC (Account B).

Since the VPC has no internet access or NAT Gateway, and the S3 Gateway VPC Endpoint only routes S3 traffic, a dedicated interface endpoint is required to route KMS decryption requests privately to the AWS KMS service.

Configure the cross-account KMS Key Policy.

Modify the customer-managed KMS key policy in Account A to allow the IAM role of the EC2 instances in Account B to perform the kms:Decrypt action.

Cross-account access to KMS keys requires explicit delegation in the key policy of the owning account. AWS-managed keys cannot be used for this purpose.

Configure the S3 Bucket Policy with network restrictions.

Update the S3 bucket policy in Account A to allow the IAM role in Account B to perform s3:GetObject, with a condition block checking for the S3 Gateway VPC Endpoint ID using the aws:sourceVpce condition key.

This satisfies the requirement to restrict bucket access to requests originating from the specific S3 Gateway VPC Endpoint in the production VPC.

Key Concept

Cross-account resource access with KMS encryption requires explicit key policy sharing (using Customer Managed Keys) and network-level configurations (such as Interface VPC Endpoints) when resolving service calls from private, isolated subnets.

Estimated Time:2m 30s

Question 1242Question →

An organization operates a multi-account AWS environment structured with AWS Organizations. A central shared services account contains a shared services VPC, and multiple consumer spoke VPCs reside in separate member accounts. All VPCs are interconnected using an AWS Transit Gateway. In the shared services VPC, an Interface VPC Endpoint (AWS PrivateLink) has been created to connect to an external SaaS partner's proprietary API service. The security team requires that only specific IAM roles running application workloads in the spoke VPCs are allowed to access this SaaS API. Furthermore, DNS resolution for the SaaS provider's domain name must resolve to the private IP addresses of the Interface VPC Endpoint from within the spoke VPCs. Which combination of actions should the solutions architect take to meet these requirements in the most secure and operationally efficient manner? (Select TWO.)

Select all that apply

Authorize and associate the Route 53 Private Hosted Zone created for the SaaS provider's domain in the shared services account with the spoke VPCs in the consumer accounts.

Configure a VPC endpoint policy on the Interface VPC Endpoint in the shared services VPC that permits access only to the specific IAM role ARNs from the consumer accounts as the principals, and limits the actions to the required SaaS API operations.

Enable private DNS on the Interface VPC Endpoint in the shared services VPC, and enable DNS Support on the Transit Gateway attachments to automatically forward DNS queries for the SaaS domain from the spoke VPCs.

Attach a Service Control Policy (SCP) to the consumer accounts' Organizational Units (OUs) that grants the specific IAM roles access to the SaaS service endpoint while denying access to all other IAM entities.

Establish a separate Direct Connect gateway for each spoke account and configure transitive VPC-to-VPC routing tables within the Direct Connect gateway to direct traffic destined for the SaaS provider through the shared services VPC.

Show answer & explanation

Answer: Authorize and associate the Route 53 Private Hosted Zone created for the SaaS provider's domain in the shared services account with the spoke VPCs in the consumer accounts.; Configure a VPC endpoint policy on the Interface VPC Endpoint in the shared services VPC that permits access only to the specific IAM role ARNs from the consumer accounts as the principals, and limits the actions to the required SaaS API operations.

Answer

Authorize and associate the Route 53 Private Hosted Zone created for the SaaS provider's domain in the shared services account with the spoke VPCs in the consumer accounts, and configure a VPC endpoint policy on the Interface VPC Endpoint in the shared services VPC that permits access only to the specific IAM role ARNs from the consumer accounts as the principals.

To secure the PrivateLink endpoint, a resource-based VPC endpoint policy must be configured to permit only the authorized cross-account IAM role ARNs and block all other traffic. To ensure DNS resolution works seamlessly, the Route 53 Private Hosted Zone in the shared services account must be associated with the consumer spoke VPCs in the other accounts. This requires a cross-account authorization and association workflow.

Step-by-Step Solution

Configure the resource-based VPC endpoint policy on the Interface VPC Endpoint.

Access is restricted at the network endpoint boundary to only allow the specified cross-account IAM role ARNs, blocking any unauthorized IAM principals from the spoke VPCs.

This establishes least-privilege access at the PrivateLink ingress point for the SaaS API.

Authorize the cross-account Route 53 Private Hosted Zone association.

The shared services account (PHZ owner) creates an association authorization for each consumer spoke VPC.

Before a VPC in another AWS account can be associated with a Private Hosted Zone, the zone owner must explicitly authorize it.

Associate the Route 53 Private Hosted Zone with the spoke VPCs.

The spoke accounts accept the authorization and associate their VPCs with the Private Hosted Zone.

This allows clients within the spoke VPCs to resolve the SaaS domain name directly to the private IP addresses of the Interface VPC Endpoint in the shared services VPC.

Key Concept

Securing multi-account PrivateLink access and cross-account DNS resolution in a Transit Gateway topology.

Question 1243Question →

A high-throughput API ingestion service runs on Amazon EC2 instances inside an Auto Scaling group (ASG) deployed across $3$ Availability Zones ( $AZ-A$ , $AZ-B$ , and $AZ-C$ ). The instances reside in private subnets, and the ASG is placed behind an Application Load Balancer (ALB). The application instances require custom configuration scripts during launch, resulting in a total initialization and bootstrapping time of $360$ seconds before they can register as healthy targets. The platform experiences two major operational issues: first, every day at exactly $08:00$ UTC, a scheduled partner integration triggers a massive, instantaneous influx of API requests, causing immediate HTTP $503$ (Service Unavailable) errors on the ALB for the first $10$ minutes; second, during scaling activities, the ASG frequently launches more instances than required, leading to unnecessary costs. Furthermore, a recent outage in $AZ-A$ prevented instances in $AZ-B$ and $AZ-C$ from making outbound licensing API calls, which are routed through a single NAT Gateway located in $AZ-A$ . Which combination of actions should a Solutions Architect implement to address these scaling, reliability, and cost issues?

Deploy a secondary NAT Gateway in

AZ-B

and update the route tables of the private subnets in

AZ-B

and

AZ-C

to use the new NAT Gateway. Configure a scheduled scaling action to scale out the Auto Scaling group

15

minutes before

08:00

UTC, and request AWS Support to pre-warm the Application Load Balancer for the anticipated daily spike. Set the default cooldown and instance warmup periods on the Auto Scaling group to

400

seconds.

Deploy a NAT Gateway in each Availability Zone and update the route tables of each private subnet to direct outbound internet traffic to the NAT Gateway in its own zone. Configure a scheduled scaling action to scale out the Auto Scaling group

15

minutes before

08:00

UTC, and request AWS Support to pre-warm the Application Load Balancer for the anticipated daily spike. Set the default cooldown and instance warmup periods on the Auto Scaling group to

400

seconds.

15

minutes before

08:00

UTC, and request AWS Support to pre-warm the Application Load Balancer for the anticipated daily spike. Set the default cooldown and instance warmup periods on the Auto Scaling group to

180

seconds.

Deploy a NAT Gateway in each Availability Zone and update the route tables of each private subnet to direct outbound internet traffic to the NAT Gateway in its own zone. Configure a target tracking scaling policy based on the average CPU utilization metric with a target value of

60\%

, and set the instance warmup time to

400

seconds. Set the default cooldown period to

400

seconds.

Show answer & explanation

Answer: Deploy a NAT Gateway in each Availability Zone and update the route tables of each private subnet to direct outbound internet traffic to the NAT Gateway in its own zone. Configure a scheduled scaling action to scale out the Auto Scaling group $15$ minutes before $08:00$ UTC, and request AWS Support to pre-warm the Application Load Balancer for the anticipated daily spike. Set the default cooldown and instance warmup periods on the Auto Scaling group to $400$ seconds.

Answer

15

minutes before

08:00

UTC, and request AWS Support to pre-warm the Application Load Balancer for the anticipated daily spike. Set the default cooldown and instance warmup periods on the Auto Scaling group to

400

seconds.

The correct response resolves all specified requirements. By deploying a NAT Gateway in each of the three Availability Zones, egress traffic is fully isolated at the zone level, ensuring that an outage in one zone does not disrupt licensing API calls in the others. Requesting AWS Support to pre-warm the Application Load Balancer and configuring a scheduled scaling policy to scale out the Auto Scaling group

15

minutes before

08:00

UTC ensures that both the load balancer and the targets (which take

360

seconds to bootstrap) are ready before the predictable spike occurs, eliminating HTTP

503

errors. Finally, adjusting the cooldown and instance warmup periods to

400

seconds (which is greater than the

360

-second initialization duration) ensures the Auto Scaling group waits for newly launched instances to become healthy and start reporting metrics before evaluating further scaling actions, preventing over-provisioning.

Step-by-Step Solution

Configure egress redundancy by provisioning a NAT Gateway in each of the three Availability Zones (

AZ-A

AZ-B

, and

AZ-C

Three separate NAT Gateways are active across the three zones.

This removes the single point of failure by ensuring that an outage in one zone does not affect internet-bound traffic from instances in other zones.

Configure route tables in each zone to point internet-bound traffic (

0.0.0.0/0

) to the NAT Gateway residing within the corresponding Availability Zone.

Outbound traffic from each subnet is localized to its respective Availability Zone.

This establishes fault isolation and eliminates cross-zone routing dependencies.

Submit a support ticket to AWS to pre-warm the Application Load Balancer in preparation for the daily

08:00

UTC traffic burst.

The Application Load Balancer is pre-scaled to handle the sudden, massive volume of requests.

Application Load Balancers scale gradually; a massive, instantaneous surge will result in HTTP

503

errors unless the load balancer is pre-warmed.

Establish a scheduled scaling policy to scale out the Auto Scaling group

15

minutes prior to the

08:00

UTC surge, and set the default cooldown and instance warmup to

400

seconds.

Instances are launched, fully bootstrapped, and healthy before the spike begins, and the Auto Scaling group does not launch redundant instances.

15

-minute buffer allows the

360

-second bootstrapping process to finish. Ensuring the warmup and cooldown periods exceed

360

seconds prevents metric lag from triggering unnecessary secondary scale-out actions.

Key Concept

Configuring resilient egress architecture, pre-warming load balancers for flash traffic, and aligning Auto Scaling cooldown periods with instance initialization times.

Estimated Time:3m 0s

Question 1244Question →

A financial services company is centralizing audit transaction logs from multiple member accounts within an AWS Organization into a single Amazon S3 bucket in a dedicated Compliance account. The existing logs in the member accounts are currently encrypted using Customer Managed Keys (CMKs) in AWS Key Management Service (AWS KMS). The company requires that all replicated logs in the Compliance account be encrypted with a key owned by the Compliance account, and that member accounts must be blocked from decrypting any logs once they are successfully copied. Additionally, all existing logs must be backfilled to the centralized bucket. A Solutions Architect configures S3 Cross-Region Replication (CRR) on the source buckets in the member accounts. However, the replication jobs fail to copy any existing logs, and new logs replicated to the Compliance account remain encrypted with the member accounts' KMS keys. Which combination of actions will successfully resolve these issues and meet the security requirements?

Configure default encryption on the destination S3 bucket in the Compliance account using the default AWS managed KMS key (aws/s3). Update the IAM replication roles in the member accounts to grant cross-account permissions for the aws/s3 key, then execute an S3 Batch Operations job to copy the existing logs.

Create a Customer Managed Key (CMK) in the Compliance account. Attach a Service Control Policy (SCP) to the organization's root that explicitly permits the member accounts' replication roles to perform kms:GenerateDataKey, kms:Encrypt, and kms:Decrypt actions on the Compliance account's CMK. Run an S3 Batch Replication job in each member account.

Create a Customer Managed Key (CMK) in the Compliance account and modify its key policy to grant the source replication IAM roles kms:GenerateDataKey and kms:Encrypt permissions. Configure replication rules in the member accounts to use the Compliance account's CMK for encrypting replicas, and execute S3 Batch Replication jobs in each member account to backfill the existing logs.

Create a Customer Managed Key (CMK) in the Compliance account. Update the destination S3 bucket policy in the Compliance account to grant kms:GenerateDataKey and kms:Encrypt permissions on the CMK to the replication IAM roles of the member accounts. Configure the member accounts' replication rules to point to the destination bucket's key, and run S3 Batch Replication jobs.

Show answer & explanation

Answer: Create a Customer Managed Key (CMK) in the Compliance account and modify its key policy to grant the source replication IAM roles kms:GenerateDataKey and kms:Encrypt permissions. Configure replication rules in the member accounts to use the Compliance account's CMK for encrypting replicas, and execute S3 Batch Replication jobs in each member account to backfill the existing logs.

Answer

The correct answer provides a valid path for cross-account S3 replication of KMS-encrypted objects. It addresses the limitation of AWS-managed keys by using a Customer Managed Key (CMK) in the Compliance account and updating its key policy to allow the member accounts' replication roles to perform encryption operations (kms:GenerateDataKey and kms:Encrypt). By not granting kms:Decrypt, it guarantees that member accounts cannot read the replicated archives. Finally, it uses S3 Batch Replication to resolve the failure to replicate existing logs, which are otherwise ignored by live S3 replication rules.

Step-by-Step Solution

Analyze cross-account key sharing capability

Determine that default AWS managed keys (aws/s3) cannot be shared across accounts due to non-modifiable key policies, necessitating a Customer Managed Key (CMK) in the destination Compliance account.

AWS-managed keys do not permit external principles in their policies.

Configure destination key policy for write-only permission

Add kms:GenerateDataKey and kms:Encrypt permissions for the replication roles, while omitting kms:Decrypt.

This enables source replication roles to encrypt objects using the destination key without granting them read access to the replicated data.

Configure the S3 replication rule parameters

Enable replication of KMS-encrypted objects and specify the Compliance account CMK ARN as the destination encryption key.

Forces the replication process to re-encrypt the replicated objects with the destination key instead of preserving the source key.

Address the replication of existing logs

Create and execute S3 Batch Replication jobs in each member account.

Standard S3 replication only triggers on new PUT operations. S3 Batch Replication is required to backfill existing historical data.

Key Concept

Cross-account S3 replication with KMS encryption requires a destination Customer Managed Key (CMK) with a key policy permitting external replication roles to encrypt, and S3 Batch Replication to copy pre-existing objects.

Estimated Time:3m 0s

Question 1245Question →

A retail company operates a legacy inventory application in the us-east-1 Region. The architecture consists of Amazon EC2 instances inside a private subnet of VPC-A. Outbound traffic to third-party APIs goes through a single NAT Gateway located in a public subnet of Availability Zone us-east-1a. The application queries an Amazon Aurora PostgreSQL database cluster. Internal service resolution is handled via a Route 53 Private Hosted Zone (PHZ) associated with VPC-A.

To support a new business continuity policy, the Solutions Architect must design a disaster recovery (DR) solution in the us-west-2 Region with a target Recovery Time Objective (RTO) of 15 minutes and a Recovery Point Objective (RPO) of 5 minutes. The architect also needs to eliminate single points of failure in the us-east-1 outbound path.

Which TWO steps should the Solutions Architect take to meet these requirements?

Select all that apply

Deploy a NAT Gateway in a public subnet in each Availability Zone in us-east-1, and configure the private subnet route tables to route outbound traffic through the local NAT Gateway in the same Availability Zone.

Create an Amazon Aurora Global Database with the primary cluster in us-east-1 and a secondary cluster in us-west-2, and use Route 53 Application Recovery Controller (ARC) routing controls to manage failover.

Deploy a single NAT Gateway in a public subnet in us-east-1a, and route outbound internet traffic from all private subnets across all Availability Zones in us-east-1 through this single NAT Gateway.

Configure AWS Backup to take daily snapshots of the Amazon Aurora PostgreSQL database cluster, copy the snapshots to us-west-2, and restore the cluster in us-west-2 during a failover event.

Create a duplicate Route 53 Private Hosted Zone with the same domain name in the us-west-2 VPC to independently manage internal DNS name resolution for the resources during disaster recovery.

Show answer & explanation

Answer: Deploy a NAT Gateway in a public subnet in each Availability Zone in us-east-1, and configure the private subnet route tables to route outbound traffic through the local NAT Gateway in the same Availability Zone.; Create an Amazon Aurora Global Database with the primary cluster in us-east-1 and a secondary cluster in us-west-2, and use Route 53 Application Recovery Controller (ARC) routing controls to manage failover.

Answer

Deploying a NAT Gateway in each Availability Zone in the primary region, configuring private subnet route tables to use the local NAT Gateway, setting up an Amazon Aurora Global Database, and using Route 53 Application Recovery Controller (ARC) for traffic management.

Deploying a NAT Gateway in each Availability Zone in the primary region ensures that an outage in one zone does not impact outbound connectivity for resources in other zones, removing a single point of failure. Setting up an Amazon Aurora Global Database provides cross-region replication with a typical RPO of under 1 second, meeting the 5-minute requirement. Utilizing Route 53 Application Recovery Controller (ARC) routing controls provides a mechanism to shift application traffic across regions within minutes, achieving the 15-minute RTO requirement.

Step-by-Step Solution

Analyze outbound connectivity requirements and configure highly available NAT Gateways.

Redundant NAT Gateways are deployed in each public subnet of the primary region, and route tables are updated so each private subnet points to its local NAT Gateway.

Ensures outbound internet traffic has no single point of failure across Availability Zones.

Evaluate the DR database replication solution for the required RTO/RPO.

Amazon Aurora Global Database replication is configured to us-west-2, providing low-latency physical replication.

Achieves an RPO of under 1 second, satisfying the 5-minute RPO target.

Configure cross-region routing and failover control.

Route 53 Application Recovery Controller (ARC) routing controls are created to handle active/standby traffic routing.

Allows traffic shift and database promotion to execute within minutes, satisfying the 15-minute RTO target.

Key Concept

Designing a resilient multi-region disaster recovery strategy and eliminating single points of failure within a region by using multi-AZ NAT Gateways and active-standby replication configurations.

Question 1246Question →

An enterprise is planning to migrate a trade clearing platform to AWS. The platform consists of the following components:

* Front-end Web Portal: Runs on Apache HTTP Server on enterprise Linux virtual machines (VMs). No source code is available, but it can be easily installed or packaged.
* Core Transaction Backend: A Java Spring Boot service running on custom on-premises middleware. It requires upgrading to the latest Java runtime to comply with enterprise security policies. The business wants to package it to reduce infrastructure management overhead.
* Backend Database: Runs on Microsoft SQL Server Enterprise Edition. It has heavy dependencies on Windows-specific Active Directory authentication. Due to licensing constraints and a strict 2-hour downtime window, the team cannot migrate this database engine to open-source engines or modify the application database layer.
* Legacy Reporting Service: Runs on an older IBM AIX server. The organization has decided that this reporting tool is no longer needed as reporting functions are moving to a new SaaS platform in 9 months. However, it must remain fully functional on-premises until the SaaS platform goes live.

Which combination of migration strategies represents the most appropriate mapping for these components according to the 7 Rs framework? (Select TWO.)

Select all that apply

Replatform the core transaction backend by containerizing it for Amazon ECS on AWS Fargate, and Replatform the database by migrating it to Amazon RDS for SQL Server.

Retain the legacy reporting service on-premises, and Rehost the front-end web portal to Amazon EC2 using AWS Application Migration Service (MGN).

Refactor the core transaction backend by containerizing it for Amazon ECS on AWS Fargate, and Replatform the database by migrating it to Amazon Aurora PostgreSQL.

Replatform the legacy reporting service by migrating the workload to an Amazon EC2 instance running Red Hat Enterprise Linux (RHEL), and Rehost the database to Amazon RDS for SQL Server.

Refactor the database by migrating it to Amazon RDS for SQL Server to preserve Windows-specific Active Directory authentication, and Retire the legacy reporting service immediately.

Rehost the front-end web portal by containerizing it to run on AWS Fargate, and Relocate the legacy reporting service to VMware Cloud on AWS.

Show answer & explanation

Answer: Replatform the core transaction backend by containerizing it for Amazon ECS on AWS Fargate, and Replatform the database by migrating it to Amazon RDS for SQL Server.; Retain the legacy reporting service on-premises, and Rehost the front-end web portal to Amazon EC2 using AWS Application Migration Service (MGN).

Answer

Replatform the core transaction backend by containerizing it for Amazon ECS on AWS Fargate, and Replatform the database by migrating it to Amazon RDS for SQL Server; and Retain the legacy reporting service on-premises, and Rehost the front-end web portal to Amazon EC2 using AWS Application Migration Service (MGN).

The correct combination specifies Replatforming the core transaction backend by containerizing it for Amazon ECS on AWS Fargate, and Replatforming the database by migrating it to Amazon RDS for SQL Server. It also specifies Retaining the legacy reporting service on-premises, and Rehosting the front-end web portal to Amazon EC2 using AWS Application Migration Service (MGN). Containerization of a Spring Boot app without architecture change is Replatforming. Moving SQL Server to Amazon RDS for SQL Server is also Replatforming because it keeps the same database engine but leverages a managed service. Retaining the legacy AIX application is correct because it cannot run on standard x86 cloud architecture and is scheduled for decommissioning within 9 months. Rehosting the web portal using AWS MGN allows lift-and-shift of the Linux VMs without source code or reconfiguration.

Step-by-Step Solution

Analyze the front-end web portal migration requirements.

Since there is no source code available and it runs on enterprise Linux VMs, migrating it as-is using VM-level replication tools represents a classic Rehost strategy.

Rehosting (lift-and-shift) minimizes migration risk and requires no application modifications or code access.

Analyze the core transaction backend requirements.

Containerizing the Spring Boot service to run on ECS Fargate without architectural changes is classified as Replatforming.

This optimizes infrastructure management and runtime environment versioning without restructuring the core application code.

Analyze the database migration options and constraints.

The SQL Server database has licensing, Active Directory, and 2-hour downtime constraints. Moving it to Amazon RDS for SQL Server is a Replatform strategy.

Moving to a managed database service (RDS) while keeping the same database engine is Replatforming, whereas changing database engines (e.g., to Aurora PostgreSQL) would require schema conversions and application rewrites, which is Refactoring.

Analyze the legacy reporting service constraints.

The legacy AIX workload is being decommissioned in 9 months and cannot run on x86 platforms. It must remain functional on-premises until then, indicating a Retain strategy.

Workloads that cannot be easily migrated due to OS constraints (IBM AIX) and are scheduled for decommissioning in the near term should be retained on-premises to avoid unnecessary migration costs and risks.

Key Concept

Selecting the correct migration strategy (Rehost, Replatform, Refactor, Retain, Retire, Relocate, Re-purchase) for each multi-tier application component based on architecture, OS constraints, licensing, downtime tolerance, and lifecycle plans.

Estimated Time:3m 0s

Question 1247Question →

A company is planning to migrate a legacy core banking audit system to AWS. The system consists of three main components:

1. Reporting Frontend: A Java Tomcat application running on Red Hat Enterprise Linux (RHEL) virtual machines. Due to strict compliance regulations, no code modifications can be made, and the migration must be completed within a tight two-week cutover window.
2. Transaction Database: An Oracle Database Enterprise Edition instance containing proprietary PL/SQL business logic. The company wants to migrate this to Amazon Aurora PostgreSQL to eliminate expensive licensing costs.
3. Audit Log Store: An on-premises NFS file share containing millions of read-only text files. The company wants to move this to a managed service on AWS to reduce storage costs and administrative overhead, while keeping the NFS interface without changing how the frontend accesses the files.

Which combination of migration strategies represents the most appropriate path for each component to meet the company's requirements?

Rehost the reporting frontend on Amazon EC2; Refactor the transaction database by converting the schema and migrating to Amazon Aurora PostgreSQL; Replatform the audit log store to Amazon EFS.

Rehost the reporting frontend on Amazon EC2; Replatform the transaction database by converting the schema and migrating to Amazon Aurora PostgreSQL; Replatform the audit log store to Amazon EFS.

Replatform the reporting frontend by migrating to AWS Elastic Beanstalk; Refactor the transaction database by converting the schema and migrating to Amazon Aurora PostgreSQL; Rehost the audit log store on an Amazon EC2 instance running a self-managed NFS server.

Refactor the reporting frontend to run as serverless functions on AWS Lambda; Refactor the transaction database by converting the schema and migrating to Amazon Aurora PostgreSQL; Replatform the audit log store to Amazon EFS.

Show answer & explanation

Answer: Rehost the reporting frontend on Amazon EC2; Refactor the transaction database by converting the schema and migrating to Amazon Aurora PostgreSQL; Replatform the audit log store to Amazon EFS.

Answer

Rehost the reporting frontend on Amazon EC2; Refactor the transaction database by converting the schema and migrating to Amazon Aurora PostgreSQL; Replatform the audit log store to Amazon EFS.

The correct strategy maps each component to its ideal 7 Rs path based on the constraints. The reporting frontend is rehosted to meet the two-week timeline and zero-code-change requirement. The database is refactored because a heterogeneous migration from Oracle to PostgreSQL requires database schema conversion and code rewrite. The audit log store is replatformed to a managed NFS service (Amazon EFS) to reduce administrative overhead without changing the frontend's access method.

Step-by-Step Solution

Analyze the requirements for the Reporting Frontend.

The frontend cannot undergo code changes due to compliance regulations, and the migration timeline is extremely short (two weeks). This matches the Rehost (lift-and-shift) migration strategy using tools like AWS Application Migration Service (MGN) to move the VMs to Amazon EC2.

Rehosting minimizes change and risk, meeting the zero-code-change and short-timeline constraints.

Analyze the requirements for the Transaction Database.

The database needs to migrate from Oracle to Amazon Aurora PostgreSQL to save on licensing. This is a heterogeneous database migration requiring schema conversion (PL/SQL to PL/pgSQL) and modification of application queries.

A database engine change requires application and schema modifications, classifying this as a Refactor (Re-architect) migration strategy.

Analyze the requirements for the Audit Log Store.

The file share needs to move to AWS to reduce administrative overhead and costs, but must continue using the NFS interface without changing application code. This maps to Replatforming (lift-tinker-and-shift) to Amazon EFS.

Replatforming moves the workload to a managed service (Amazon EFS) to reduce overhead while keeping the core architecture and protocols (NFS) identical.

Key Concept

Selecting migration strategies (7 Rs) based on application constraints, licensing, and timelines.

Question 1248Question →

An enterprise is building a new IoT-enabled manufacturing platform in the `us-east-1` Region. The network architecture consists of three VPCs across different AWS accounts within an AWS Organization:

- An application VPC `vpc-factory-prod` ( $172.16.0.0/16$ )
- A logistics VPC `vpc-warehouse-prod` ( $172.17.0.0/16$ )
- A shared services VPC `vpc-shared-core` ( $192.168.0.0/20$ )

All VPCs are interconnected using an AWS Transit Gateway named `tgw-mfg-core` with attachments in two Availability Zones (`us-east-1a` and `us-east-1b`).

The Solutions Architect must meet the following requirements:
1. Provide highly available and fault-tolerant egress-only internet connectivity for private instances in `vpc-factory-prod` and `vpc-warehouse-prod` while minimizing NAT gateway costs by centralizing egress traffic.
2. Allow private instances in the consumer VPCs (`vpc-factory-prod` and `vpc-warehouse-prod`) to resolve private DNS queries for resources hosted in `vpc-shared-core` via a Route 53 Private Hosted Zone (PHZ) named `corp.internal` associated with `vpc-shared-core`.

Which TWO configurations must the Solutions Architect implement to satisfy these networking and connectivity requirements?

Select all that apply

Deploy one NAT Gateway in a public subnet in `us-east-1a` and another in `us-east-1b` within `vpc-shared-core`. In `vpc-shared-core`, configure the route tables of the subnets containing the Transit Gateway attachments to direct outbound traffic (

0.0.0.0/0

) to the NAT Gateway in their respective Availability Zone. Point the default route (

0.0.0.0/0

) in the Transit Gateway route table associated with the spoke VPCs to the `vpc-shared-core` attachment.

Submit a VPC association authorization from the AWS account hosting `vpc-shared-core` for the `corp.internal` Private Hosted Zone targeting `vpc-factory-prod` and `vpc-warehouse-prod`. From the spoke accounts, accept the authorizations to associate the hosted zone with the spoke VPCs, and ensure both `enableDnsSupport` and `enableDnsHostnames` are set to true on all three VPCs.

Deploy a single NAT Gateway in a public subnet in `us-east-1a` within `vpc-shared-core`. In the Transit Gateway route table associated with the spoke VPCs, configure a default route (

0.0.0.0/0

) pointing to the `vpc-shared-core` attachment to centralize internet egress and minimize billing charges.

Configure VPC peering connections between `vpc-factory-prod` and `vpc-shared-core`, and between `vpc-warehouse-prod` and `vpc-shared-core`. Configure the route tables in the spoke VPCs to route internet-bound traffic (

0.0.0.0/0

) through the peering connections to the Internet Gateway attached to `vpc-shared-core`.

Establish a Route 53 Resolver outbound endpoint in `vpc-shared-core` and inbound endpoints in `vpc-factory-prod` and `vpc-warehouse-prod`. Create Route 53 forwarding rules in the spoke accounts to forward queries for `corp.internal` to the inbound endpoints.

Show answer & explanation

Answer: Deploy one NAT Gateway in a public subnet in `us-east-1a` and another in `us-east-1b` within `vpc-shared-core`. In `vpc-shared-core`, configure the route tables of the subnets containing the Transit Gateway attachments to direct outbound traffic ( $0.0.0.0/0$ ) to the NAT Gateway in their respective Availability Zone. Point the default route ( $0.0.0.0/0$ ) in the Transit Gateway route table associated with the spoke VPCs to the `vpc-shared-core` attachment.; Submit a VPC association authorization from the AWS account hosting `vpc-shared-core` for the `corp.internal` Private Hosted Zone targeting `vpc-factory-prod` and `vpc-warehouse-prod`. From the spoke accounts, accept the authorizations to associate the hosted zone with the spoke VPCs, and ensure both `enableDnsSupport` and `enableDnsHostnames` are set to true on all three VPCs.

Answer

Deploying redundant NAT Gateways per Availability Zone in the shared services VPC and routing outbound Transit Gateway traffic to them ensures highly available centralized egress. Performing cross-account Private Hosted Zone association authorizations allows spoke VPCs to resolve internal DNS queries directly.

Deploying one NAT Gateway per Availability Zone in the shared services VPC and routing outbound traffic from the Transit Gateway attachment subnets to the local NAT Gateway provides a fault-tolerant and zone-redundant egress path. For cross-account DNS resolution of a Private Hosted Zone, the owner account must authorize the association, and the spoke accounts must accept it, while ensuring DNS hostnames and support are enabled on all target VPCs.

Step-by-Step Solution

Analyze the egress requirements for the multi-VPC environment.

Identified that spoke VPCs require outbound internet access through the central shared services VPC using AWS Transit Gateway.

Centralizing egress through a shared services VPC reduces the number of public subnets and NAT Gateways required, but high availability must be maintained by deploying NAT Gateways in multiple Availability Zones.

Configure Transit Gateway and central VPC routing for high-availability egress.

Created a default route pointing to the Transit Gateway in the spoke VPC subnets, and configured the central VPC's Transit Gateway attachment subnets to route traffic to local NAT Gateways in their respective Availability Zones.

This keeps traffic within the same Availability Zone to avoid cross-AZ latency and data transfer costs, while avoiding a single point of failure.

Establish cross-account DNS resolution.

Used the AWS CLI or SDK to create a VPC association authorization from the owner account of the Private Hosted Zone, and accepted the association in the consumer spoke accounts.

VPCs in different accounts cannot be directly associated with a Private Hosted Zone via the console; it requires a programmatic two-step authorization and association process.

Key Concept

Centralized egress and cross-account DNS resolution in a multi-account AWS Transit Gateway architecture.

Estimated Time:3m 0s

Question 1249Question →

An enterprise operates a high-traffic financial platform. The application tier is deployed in private subnets across multiple Availability Zones in an Application VPC, which is connected to a Transit Gateway. A Shared Services VPC hosts a centralized outbound NAT Gateway and a Route 53 Private Hosted Zone (PHZ) for internal service discovery. Users report intermittent latency spikes and connection timeouts. A network audit reveals that outbound traffic to external financial APIs from all Availability Zones in the Application VPC routes through a single NAT Gateway in the Shared Services VPC. Additionally, internal DNS queries for services in the PHZ fail to resolve from the Application VPC, and sudden traffic spikes during market open cause the Application Load Balancer (ALB) to drop connections. Which combination of actions should the Solutions Architect implement to optimize network performance, minimize latency, and resolve these issues?

Associate the Route 53 Private Hosted Zone with the Application VPC to enable local DNS resolution. Deploy a NAT Gateway in each Availability Zone within the Shared Services VPC and configure the routing tables accordingly. Request AWS Support to pre-warm the Application Load Balancer prior to market open events.

Configure Transit Gateway route propagation to automatically share DNS resolution records between VPCs. Deploy a NAT Gateway in each Availability Zone within the Shared Services VPC and configure the routing tables accordingly. Request AWS Support to pre-warm the Application Load Balancer prior to market open events.

Associate the Route 53 Private Hosted Zone with the Application VPC to enable local DNS resolution. Retain the single NAT Gateway in the Shared Services VPC to centralize outbound traffic flow and save costs, while using cross-zone load balancing. Request AWS Support to pre-warm the Application Load Balancer prior to market open events.

Associate the Route 53 Private Hosted Zone with the Application VPC to enable local DNS resolution. Deploy a NAT Gateway in each Availability Zone within the Shared Services VPC and configure the routing tables accordingly. Rely on the default auto-scaling behavior of the Application Load Balancer to handle the market open traffic spikes.

Show answer & explanation

Answer: Associate the Route 53 Private Hosted Zone with the Application VPC to enable local DNS resolution. Deploy a NAT Gateway in each Availability Zone within the Shared Services VPC and configure the routing tables accordingly. Request AWS Support to pre-warm the Application Load Balancer prior to market open events.

Answer

Associate the Route 53 Private Hosted Zone with the Application VPC, deploy NAT Gateways in each Availability Zone within the Shared Services VPC, and request AWS Support to pre-warm the Application Load Balancer before market open events.

The correct option optimizes performance and minimizes latency by implementing three key practices: associating the Route 53 Private Hosted Zone directly with the Application VPC to allow immediate and local resolution of internal domains; deploying redundant NAT Gateways across all active Availability Zones to keep outbound traffic local to each zone and remove cross-AZ network latency; and pre-warming the Application Load Balancer to guarantee that the sudden influx of connections at market open is handled smoothly without dropped packets.

Step-by-Step Solution

Associate the Route 53 Private Hosted Zone with the Application VPC.

Instances in the Application VPC resolve internal service endpoints locally and successfully.

Route 53 Private Hosted Zones are private by default and must be explicitly associated with any VPC that requires resolution of their records.

Deploy NAT Gateways in each Availability Zone in the Shared Services VPC and update route tables.

Outbound traffic to external APIs remains within the same Availability Zone, minimizing latency and eliminating a single point of failure.

Routing all cross-AZ traffic through a single NAT Gateway introduces latency and creates a single point of failure.

Submit a pre-warming request to AWS Support for the Application Load Balancer.

The Application Load Balancer is pre-scaled to handle the anticipated surge of connections at market open without dropping requests.

Standard auto-scaling is reactive and cannot scale fast enough to meet instantaneous flash traffic demands.

Key Concept

Minimizing network latency and optimizing performance in hybrid and multi-account architectures by implementing multi-AZ NAT Gateway redundancy, proper private DNS association, and proactive load balancer scaling.

Question 1250Question →

A company is reviewing the security posture of an internal corporate portal hosted on Amazon EC2 instances in a private subnet. The portal is currently accessed by employees on-premises via an AWS Direct Connect connection and an internal Application Load Balancer (ALB). The business now requires that external strategic partners also access the portal securely over the public internet. These partners authenticate using a third-party SAML 2.0 Identity Provider (IdP). The company must protect the portal against web-based attacks, block malicious traffic at the edge, and enforce SAML-based authentication for external partners, while maintaining direct internal access for employees without sending employee traffic over the internet. Which two actions should the solutions architect take to meet these requirements?

Select all that apply

Create an internet-facing ALB in the public subnets. Configure an HTTPS listener on the internet-facing ALB with an authentication action using Amazon Cognito. Configure an Amazon Cognito user pool federated with the partner's SAML 2.0 IdP to authenticate external users before forwarding requests to the target group.

Associate an AWS WAF WebACL containing custom rules and AWS Managed Rules with the internet-facing ALB. Configure the WebACL rule priority to evaluate specific block and rate-limiting rules first, followed by general allow rules.

Associate an AWS WAF WebACL with the internet-facing ALB. Configure the WebACL rule priorities such that general IP-based allow rules are evaluated first to speed up processing of legitimate traffic, followed by specific SQL injection and cross-site scripting (XSS) inspection rules.

Configure an IAM role for partner access with a trust relationship that specifies the SAML IdP as the principal, using the sts:AssumeRole action in the trust policy to allow partner users to federate directly and access the internal application servers.

Configure the Amazon Cognito user pool to encrypt partner profile data using the AWS-managed KMS key for Cognito Identity Pools, and update the policy of this AWS-managed key to grant the partner's external AWS account access to decrypt the data.

Show answer & explanation

Answer: Create an internet-facing ALB in the public subnets. Configure an HTTPS listener on the internet-facing ALB with an authentication action using Amazon Cognito. Configure an Amazon Cognito user pool federated with the partner's SAML 2.0 IdP to authenticate external users before forwarding requests to the target group.; Associate an AWS WAF WebACL containing custom rules and AWS Managed Rules with the internet-facing ALB. Configure the WebACL rule priority to evaluate specific block and rate-limiting rules first, followed by general allow rules.

Answer

Create an internet-facing Application Load Balancer integrated with Amazon Cognito and a federated SAML user pool for partner authentication, and associate an AWS WAF WebACL with rule priorities configured to evaluate specific block and rate-limiting rules before general allow rules.

The correct solution deploys an internet-facing ALB for partner ingress, integrating Cognito User Pools to offload SAML 2.0 authentication from the backend applications. Security is strengthened by associating AWS WAF with the internet-facing ALB and ensuring specific security blocks and rate limits are evaluated first, blocking threats before they can reach the application or trigger broader allow rules.

Step-by-Step Solution

Address network ingress for external users

Deploy an internet-facing ALB in public subnets while keeping the existing internal ALB for on-premises employee access, ensuring internal traffic does not transit the public internet.

This establishes a distinct network path for external partners, separating public internet access from internal Direct Connect paths.

Establish SAML-based federated authentication

Configure Cognito User Pools with SAML federation linked to the partner's IdP, and configure ALB listener rules to authenticate requests via Cognito before forwarding them.

Cognito handles the SAML exchange and user authentication at the ALB layer, preventing unauthenticated traffic from reaching backend EC2 instances.

Apply edge security protections and rule ordering

Associate an AWS WAF WebACL with the internet-facing ALB. Structure WebACL rules so that rate-limiting, SQL injection, and other block rules run with higher priority (evaluated first) than any general allow rules.

Proper WAF rule ordering prevents malicious traffic from bypassing inspection filters via generic permit statements.

Key Concept

Strengthening public-facing network endpoints through proper WAF rule prioritization, Cognito-integrated ALB authentication with external SAML IdPs, and segregation of internal and external traffic paths.

Question 1251Question →

A company is migrating its on-premises virtual machines to AWS using AWS Application Migration Service (MGN). A solutions architect needs to configure network access to ensure the replication agents installed on the source servers can communicate with the AWS migration infrastructure. Which of the following network configuration steps are required to establish this connectivity? (Select TWO.)

Select all that apply

Allow outbound traffic from the on-premises source servers to the AWS Application Migration Service API endpoints over TCP port 443.

Allow inbound traffic to the replication servers in the AWS staging area over TCP port 1500.

Configure staging area security groups to allow inbound replication traffic only over TCP port 443, as block-level data replication does not utilize TCP port 1500.

Configure a Direct Connect gateway to route transitive replication traffic directly between multiple target VPCs.

Deploy a single NAT Gateway in a single Availability Zone to route all outbound control plane traffic for replication servers distributed across multiple Availability Zones.

Show answer & explanation

Answer: Allow outbound traffic from the on-premises source servers to the AWS Application Migration Service API endpoints over TCP port 443.; Allow inbound traffic to the replication servers in the AWS staging area over TCP port 1500.

Answer

Allow outbound traffic from the on-premises source servers to the AWS Application Migration Service API endpoints over TCP port 443, and allow inbound traffic to the replication servers in the AWS staging area over TCP port 1500.

For successful migration using AWS MGN, on-premises source servers must have outbound access over TCP port 443 to communicate with the service API endpoints, and the security groups of the replication servers in the AWS staging area must allow inbound traffic on TCP port 1500 for data replication.

Step-by-Step Solution

Identify the control plane communication requirements for the MGN replication agent.

The replication agent requires outbound HTTPS access (TCP port 443) to communicate with the AWS MGN service endpoints.

This allows the agent to register with the service and receive instructions.

Identify the data plane replication requirements.

The replication agent requires outbound access to the replication servers in the staging area over TCP port 1500.

This port is dedicated to block-level data replication stream from the source servers to the staging area.

Key Concept

AWS MGN network port requirements for control plane and replication data transit.

Question 1252Question →

A financial services company runs a high-volume trading platform on AWS. The application tier runs on Amazon EC2 instances in an Auto Scaling group behind an Application Load Balancer (ALB). The database tier uses an Amazon Aurora PostgreSQL database cluster with one writer and two readers. Every morning at the market open, the platform experiences an instantaneous, massive spike in traffic. During these events, users experience HTTP 503 Service Unavailable errors and dashboard widgets fail to load or display stale data. Investigation reveals that the ALB drops connections during the initial minute of the spike before scaling, and the database reader instances experience CPU utilization near 100% with elevated replication lag. Which two actions should a Solutions Architect recommend to optimize the performance of the compute and storage layers during these spikes? (Select TWO).

Select all that apply

Enable Aurora Auto Scaling for the Aurora Replicas in the database cluster to dynamically scale horizontal read capacity based on average CPU utilization.

Configure an Amazon EC2 Auto Scaling warm pool to keep pre-initialized instances ready, and request AWS Support to pre-warm the Application Load Balancer prior to the scheduled market opening times.

Enable read routing to the RDS Multi-AZ standby database instance to distribute read queries across both the active and standby nodes.

Adjust the Application Load Balancer target tracking scaling policy thresholds to trigger scaling earlier, relying on dynamic scaling to absorb the instantaneous traffic spikes.

Purchase EC2 Instance Savings Plans to cover the compute costs of the EC2 instances, AWS Fargate tasks, and AWS Lambda functions.

Show answer & explanation

Answer: Enable Aurora Auto Scaling for the Aurora Replicas in the database cluster to dynamically scale horizontal read capacity based on average CPU utilization.; Configure an Amazon EC2 Auto Scaling warm pool to keep pre-initialized instances ready, and request AWS Support to pre-warm the Application Load Balancer prior to the scheduled market opening times.

Answer

To resolve the performance bottlenecks, the Solutions Architect should enable Aurora Auto Scaling for the database cluster's reader instances to dynamically scale horizontal read capacity based on average CPU utilization, and configure an Amazon EC2 Auto Scaling warm pool to keep pre-initialized instances ready while requesting AWS Support to pre-warm the Application Load Balancer prior to the scheduled market opening times.

The correct recommendations are to configure Aurora Auto Scaling for the reader instances and to use EC2 warm pools combined with pre-warming the Application Load Balancer. Aurora Auto Scaling dynamically adjusts horizontal read capacity to handle high query loads and reduce replication lag. Pre-warming the Application Load Balancer ensures the load balancer has sufficient capacity to handle instantaneous traffic spikes without dropping connections, while EC2 warm pools decrease instance launch times by maintaining pre-initialized instances.

Step-by-Step Solution

Analyze the database performance bottleneck under read-heavy traffic.

Identify that reader instances are overloaded with high CPU utilization and replication lag is increasing.

To optimize database read performance, horizontal scaling using Aurora Auto Scaling for the Aurora Replicas is required.

Analyze the entry-point bottleneck for sudden, instantaneous traffic spikes.

Identify that the Application Load Balancer is dropping connections because dynamic scaling cannot keep up with flash spikes.

To handle predictable, instant surges, the ALB must be pre-warmed by AWS Support, and EC2 warm pools should be used to minimize the boot time of new application instances.

Key Concept

Scaling compute and storage layers dynamically and proactively to handle instantaneous traffic spikes and database read contention.

Estimated Time:3m 0s

Question 1253Question →

An enterprise is designing a high-throughput, global Online Transaction Processing (OLTP) application. The primary database will be deployed in the `us-east-1` Region, and a secondary replica must be maintained in the `us-west-2` Region to support local read traffic and serve as a hot standby. The business requirements dictate a Disaster Recovery (DR) profile with a Recovery Point Objective (RPO) of less than $1\text{ second}$ and a Recovery Time Objective (RTO) of less than $1\text{ minute}$ . Additionally, read capacity in `us-west-2` must scale dynamically to handle unpredictable spikes in query volume. Finally, the database backups must be exported daily to an Amazon S3 bucket and made accessible to an external auditing team operating in a separate, isolated AWS account. The audit data must remain encrypted at rest.

Which TWO database and storage configurations should the Solutions Architect implement to meet these requirements?

Select all that apply

Provision an Amazon Aurora Global Database with the primary cluster in `us-east-1` and a secondary cluster in `us-west-2`. Define an Application Auto Scaling policy for the Aurora Replicas in `us-west-2` using the `RDSReaderAverageCPUUtilization` predefined metric.

Export the database snapshots to an Amazon S3 bucket. Configure default encryption on the S3 bucket using a Customer Managed Key (CMK) in AWS KMS, and update the key policy to grant the auditing account's IAM principal permissions to decrypt the data.

Export the database snapshots to an Amazon S3 bucket. Configure default encryption on the S3 bucket using the AWS managed key for Amazon S3 (`aws/s3`), and configure the S3 bucket policy to allow cross-account access for the auditing account's IAM principal.

Provision an Amazon RDS for PostgreSQL instance with a Multi-AZ deployment, and configure a Read Replica in `us-west-2`. Rely on the standby replica in the Multi-AZ deployment to automatically scale read capacity dynamically using Amazon RDS Auto Scaling.

Implement a replication strategy that copies automated Aurora DB cluster snapshots from `us-east-1` to `us-west-2` every

4\text{ hours}

. Use AWS Systems Manager to trigger a Lambda function to automatically restore the cluster from the latest copied snapshot during a regional failover.

Show answer & explanation

Answer: Provision an Amazon Aurora Global Database with the primary cluster in `us-east-1` and a secondary cluster in `us-west-2`. Define an Application Auto Scaling policy for the Aurora Replicas in `us-west-2` using the `RDSReaderAverageCPUUtilization` predefined metric.; Export the database snapshots to an Amazon S3 bucket. Configure default encryption on the S3 bucket using a Customer Managed Key (CMK) in AWS KMS, and update the key policy to grant the auditing account's IAM principal permissions to decrypt the data.

Answer

The correct configurations are to provision an Amazon Aurora Global Database with Application Auto Scaling on reader instances in the secondary region, and to encrypt the daily S3 exports with a Customer Managed Key (CMK) while updating its key policy to allow cross-account decrypt access.

The correct solution involves utilizing Amazon Aurora Global Database to achieve near-instantaneous cross-region replication (RPO <

1\text{ s}

) and swift failover capabilities (RTO <

1\text{ m}

). Auto Scaling on the reader instances in the secondary region dynamically handles scale-out based on read load. Additionally, using a Customer Managed Key (CMK) for the S3 backup exports allows the key policy to be customized, enabling cross-account decryption for the auditing team.

Step-by-Step Solution

Evaluate the disaster recovery constraints (RTO <

1\text{ minute}

, RPO <

1\text{ second}

) against the database engine replication capabilities.

Amazon Aurora Global Database provides physical, storage-based replication across regions with typical lag under

1\text{ second}

(meeting the RPO) and supports fast failover/promotion in under a minute (meeting the RTO). Snapshot-based copying is rejected because it fails the strict RPO/RTO limits.

Choosing the correct replication and disaster recovery topology is the foundation of the storage and database strategy.

Determine the scale-out capability of the reader instances in the secondary region.

By using Aurora Auto Scaling with a target tracking policy based on average CPU utilization, reader instances in the secondary region can scale out horizontally to absorb unpredictable query spikes.

Standard RDS Multi-AZ standby instances cannot serve read traffic or scale dynamically, requiring dedicated read replicas with scaling policies.

Address the cross-account S3 backup access and encryption requirements.

A Customer Managed Key (CMK) is required because its key policy can be modified to grant cross-account decrypt permissions. AWS managed keys (like `aws/s3`) do not support cross-account access.

Security controls require proper KMS key type selection for cross-account resource sharing.

Key Concept

Cross-region database replication topology (Aurora Global Database) combined with reader auto-scaling and cross-account KMS key sharing requirements.

Question 1254Question →

A company runs a high-volume OLTP application on an Amazon RDS for PostgreSQL database configured in a Multi-AZ deployment. During end-of-month reporting cycles, users experience significant performance degradation and query timeouts on their analytics dashboards. Monitoring metrics show that the primary database instance is experiencing CPU utilization near $100\%$ and high read IOPS, while write transaction response times increase. The analytics queries are strictly read-only. Which of the following optimization strategies should the solutions architect implement to resolve the performance bottleneck in a cost-effective and operationally efficient manner?

Configure the reporting dashboards to point to the DNS endpoint of the standby instance in the secondary Availability Zone of the Multi-AZ deployment.

Request AWS Support to pre-warm an Application Load Balancer placed in front of the RDS database instances to load balance the database connection requests.

Create one or more Amazon RDS PostgreSQL Read Replicas and update the reporting application to route the read-only query traffic to the read replica endpoints.

Purchase EC2 Instance Savings Plans to automatically cover the compute cost of the database instances as they scale during reporting periods.

Show answer & explanation

Answer: Create one or more Amazon RDS PostgreSQL Read Replicas and update the reporting application to route the read-only query traffic to the read replica endpoints.

Answer

Create one or more Amazon RDS PostgreSQL Read Replicas and update the reporting application to route the read-only query traffic to the read replica endpoints.

Creating one or more Amazon RDS PostgreSQL Read Replicas is the correct strategy because standard RDS PostgreSQL Read Replicas allow read-only query workloads to be offloaded from the primary write instance, thereby reducing CPU and IOPS contention. This is supported by PostgreSQL read replicas, which run independently of the Multi-AZ standby.

Step-by-Step Solution

Analyze the metrics and determine that read-only analytical queries are causing CPU and resource contention on the primary database instance.

The bottleneck is identified as read traffic conflict on the write-optimized primary instance.

Understanding the nature of the database workload is required to select the correct scaling model.

Evaluate the capabilities of Amazon RDS Multi-AZ standby instances and database load balancing options.

Determine that standby instances in RDS Multi-AZ cannot serve read traffic and that ALBs cannot load balance database connections directly.

Eliminating options that are technically unfeasible or do not support read workloads.

Deploy one or more RDS PostgreSQL Read Replicas and modify the reporting dashboard connection endpoints.

The reporting queries are routed to the Read Replicas, offloading CPU and IOPS demands from the primary instance.

Implementing horizontal read scaling resolves the performance issues on the primary database.

Key Concept

Horizontal scaling of database read workloads using Read Replicas in Amazon RDS.

Question 1255Question →

An enterprise is designing a new AWS environment in the eu-west-1 Region. The architecture consists of two spoke VPCs (vpc-workload-a and vpc-workload-b) and a centralized services VPC (vpc-shared-services). The workloads in both spoke VPCs must:

1. Resolve internal DNS queries for a Route 53 Private Hosted Zone (PHZ) named internal.enterprise that is created and managed in the shared services AWS account.
2. Have outbound-only internet access that is resilient to Availability Zone (AZ) outages.
3. Be prevented from communicating directly with each other.

Which TWO actions should the solutions architect take to meet these requirements? (Select TWO.)

Select all that apply

Associate the Route 53 Private Hosted Zone internal.enterprise with both vpc-workload-a and vpc-workload-b by submitting VPC association authorization requests and associating the VPCs.

Deploy one NAT Gateway in each of two Availability Zones within the public subnets of vpc-shared-services, and route outbound internet traffic from the spoke VPCs through an AWS Transit Gateway to the shared services VPC.

Associate the Route 53 Private Hosted Zone with the Transit Gateway attachment in the shared services account, allowing all attached spoke VPCs to inherit the DNS resolution automatically.

Deploy a single NAT Gateway in a single public subnet of vpc-shared-services and configure the routing tables in both Availability Zones of the spoke VPCs to send internet-bound traffic to this NAT Gateway via the Transit Gateway.

Enable Transit Gateway route propagation between vpc-workload-a and vpc-workload-b to allow transitive routing to the NAT Gateway in the public subnets of the other spoke VPC.

Show answer & explanation

Answer: Associate the Route 53 Private Hosted Zone internal.enterprise with both vpc-workload-a and vpc-workload-b by submitting VPC association authorization requests and associating the VPCs.; Deploy one NAT Gateway in each of two Availability Zones within the public subnets of vpc-shared-services, and route outbound internet traffic from the spoke VPCs through an AWS Transit Gateway to the shared services VPC.

Answer

To meet the requirements, the solutions architect must associate the Route 53 Private Hosted Zone internal.enterprise with both workload VPCs, and deploy redundant NAT Gateways across two Availability Zones in the shared services VPC, routing egress traffic from the workloads through AWS Transit Gateway.

Associating the Private Hosted Zone directly with all target VPCs ensures proper cross-account DNS resolution. Deploying redundant NAT Gateways across multiple Availability Zones in the centralized services VPC provides a highly available, fault-tolerant path for outbound internet traffic using Transit Gateway routing, without enabling direct spoke-to-spoke communication.

Step-by-Step Solution

Configure DNS cross-account association.

Associate the Route 53 Private Hosted Zone hosted in the shared services account with the workload VPCs in other accounts using the AWS CLI or SDK to authorize and associate.

Route 53 Private Hosted Zones require direct association with VPCs for DNS resolution, and cross-account associations require authorization.

Configure highly available centralized egress.

Deploy NAT Gateways in multiple public subnets across different Availability Zones within the central egress or shared services VPC.

This avoids a single point of failure for outbound traffic.

Set up Transit Gateway routing with isolation.

Create Transit Gateway route tables that direct outbound 0.0.0.0/0 traffic from the spoke VPCs to the shared services VPC attachment, while ensuring no routes exist between the spoke VPCs.

This satisfies the requirement to keep the spoke VPCs isolated from each other while permitting centralized internet access.

Key Concept

Centralized network architecture design with high availability, private DNS resolution, and VPC isolation using AWS Transit Gateway and Route 53 PHZ.

Question 1256Question →

An enterprise is designing a new hybrid network architecture to connect three spoke VPCs (`vpc-app-prod`, `vpc-web-prod`, and `vpc-db-prod`) in the `us-west-2` Region to an on-premises data center. The design must satisfy the following requirements:
1. Provide outbound internet access for all spoke VPCs that is both highly available and cost-effective.
2. Establish transitive hybrid connectivity between all spoke VPCs and the on-premises network.
3. Enable private DNS resolution for an internal domain (`aws.corp.internal`) hosted in a Route 53 Private Hosted Zone (PHZ) across all three spoke VPCs.

Which design should the solutions architect choose to meet these requirements?

Deploy an AWS Transit Gateway. Attach the three spoke VPCs and a centralized egress VPC containing a NAT Gateway in each Availability Zone to the Transit Gateway. Connect the Transit Gateway to an AWS Direct Connect Gateway for on-premises connectivity. Associate the Route 53 Private Hosted Zone `aws.corp.internal` directly with the three spoke VPCs.

Deploy an AWS Transit Gateway. Attach the three spoke VPCs and a centralized egress VPC containing a single NAT Gateway in one Availability Zone to the Transit Gateway. Connect the Transit Gateway to an AWS Direct Connect Gateway for on-premises connectivity. Associate the Route 53 Private Hosted Zone `aws.corp.internal` directly with the three spoke VPCs.

Attach the three spoke VPCs directly to an AWS Direct Connect Gateway using Virtual Private Gateways. Deploy a centralized egress VPC with a NAT Gateway in each Availability Zone. Associate the Route 53 Private Hosted Zone `aws.corp.internal` directly with the three spoke VPCs.

Deploy an AWS Transit Gateway. Attach the three spoke VPCs and a centralized egress VPC containing a NAT Gateway in each Availability Zone to the Transit Gateway. Connect the Transit Gateway to an AWS Direct Connect Gateway for on-premises connectivity. Configure Route 53 Resolver outbound and inbound endpoints in each VPC to resolve the domain names without associating the Private Hosted Zone.

Show answer & explanation

Answer: Deploy an AWS Transit Gateway. Attach the three spoke VPCs and a centralized egress VPC containing a NAT Gateway in each Availability Zone to the Transit Gateway. Connect the Transit Gateway to an AWS Direct Connect Gateway for on-premises connectivity. Associate the Route 53 Private Hosted Zone `aws.corp.internal` directly with the three spoke VPCs.

Answer

Deploy an AWS Transit Gateway, attach the spoke VPCs and a centralized egress VPC containing redundant NAT Gateways (one per Availability Zone) to the Transit Gateway, connect the Transit Gateway to an AWS Direct Connect Gateway, and associate the Route 53 Private Hosted Zone directly with all three spoke VPCs.

The correct design uses AWS Transit Gateway to enable transitive connectivity to the on-premises network via a Direct Connect Gateway. It routes outbound internet traffic through a centralized egress VPC that contains a NAT Gateway in each Availability Zone, ensuring high availability. Private DNS resolution is achieved simply and cost-effectively by directly associating the Route 53 Private Hosted Zone with the spoke VPCs.

Step-by-Step Solution

Select the hub-and-spoke component for transitive routing.

AWS Transit Gateway is chosen to connect the three spoke VPCs and the egress VPC, enabling centralized traffic flow and hybrid routing.

Transit Gateway acts as a cloud router that scales network connections transitively, allowing all spoke VPCs to share resources like Direct Connect and egress VPCs.

Design the outbound internet access path with redundancy.

Deploy NAT Gateways in multiple Availability Zones within the centralized egress VPC.

This configuration avoids a single point of failure and ensures that outbound internet traffic is highly available across Availability Zone outages.

Configure private DNS resolution across all spoke VPCs.

Associate the Route 53 Private Hosted Zone directly with all three spoke VPCs (`vpc-app-prod`, `vpc-web-prod`, and `vpc-db-prod`).

Direct VPC association allows instances in all spoke VPCs to resolve domain names in the Private Hosted Zone privately without the added cost and complexity of Route 53 Resolver endpoints.

Key Concept

Centralized egress design with redundant NAT Gateways combined with Transit Gateway and multi-VPC Private Hosted Zone association.

Estimated Time:2m 0s

Question 1257Question →

A global logistics provider is planning to migrate its legacy supply chain orchestration system to AWS. The migration must be completed within $6\text{ months}$ , and the target architecture must optimize cost and minimize administrative overhead where possible. A Solutions Architect has discovered the following three key workloads during the assessment phase:

1. Proprietary Message Broker: A self-managed RabbitMQ cluster running on CentOS $7$ virtual machines. The broker utilizes custom-compiled, third-party Erlang modules for legacy protocol translation. The source code for these custom modules has been lost, preventing recompilation.
2. Analytical Data Warehouse: A $50\text{ TB}$ Oracle Data Warehouse that relies heavily on Oracle-specific analytical functions, stored procedures, and materialized views. The business intends to migrate this workload to Amazon Redshift to eliminate costly license agreements and improve analytical performance, which will require redesigning the database schema and rewriting downstream reporting queries.
3. Legacy Document Archiving Service: An archiving daemon written in C that runs on legacy Solaris SPARC hardware. The daemon writes static PDF files to a shared NFS mount. This system is scheduled to be completely decommissioned in $9\text{ months}$ when a new cloud-native Software-as-a-Service (SaaS) document management platform is fully rolled out.

Which of the following migration strategies represent the most appropriate alignment with the $7\text{ Rs}$ framework for these workloads? (Select TWO.)

Select all that apply

Replatform the Proprietary Message Broker to Amazon MQ for RabbitMQ to eliminate operating system patching and cluster management overhead.

Refactor (Re-architect) the Analytical Data Warehouse by using the AWS Schema Conversion Tool (AWS SCT) and AWS Database Migration Service (AWS DMS) to migrate the schema and data to Amazon Redshift.

Replatform the Analytical Data Warehouse by using AWS DMS to load the data directly into Amazon Redshift, since database engine conversions to managed target services are classified as replatforming.

Retain the Legacy Document Archiving Service on-premises and establish a hybrid network connection to allow migrated cloud workloads to interface with the shared NFS mount until it is decommissioned.

Rehost the Legacy Document Archiving Service by utilizing AWS Application Migration Service (AWS MGN) to replicate the Solaris SPARC virtual machines directly into an Amazon EC2 environment.

Show answer & explanation

Answer: Refactor (Re-architect) the Analytical Data Warehouse by using the AWS Schema Conversion Tool (AWS SCT) and AWS Database Migration Service (AWS DMS) to migrate the schema and data to Amazon Redshift.; Retain the Legacy Document Archiving Service on-premises and establish a hybrid network connection to allow migrated cloud workloads to interface with the shared NFS mount until it is decommissioned.

Answer

The correct strategies are to Refactor (Re-architect) the Analytical Data Warehouse using AWS SCT and AWS DMS to migrate the schema and data to Amazon Redshift, and to Retain the Legacy Document Archiving Service on-premises while establishing a hybrid network connection for access.

Refactoring the Analytical Data Warehouse is correct because migrating from an Oracle Data Warehouse to Amazon Redshift is a heterogeneous migration that requires rewriting database schema and downstream analytical queries. Retaining the Legacy Document Archiving Service on-premises is correct because the system runs on Solaris SPARC hardware (which cannot run directly on standard AWS x86/ARM compute) and is scheduled for decommissioning within 9 months, rendering migration efforts unnecessary and cost-ineffective.

Step-by-Step Solution

Evaluate the migration options for the Proprietary Message Broker under the 7 Rs framework.

The message broker requires custom Erlang modules for which source code is lost. Because Amazon MQ is a managed service that does not support custom Erlang modules or OS-level plugins, replatforming to Amazon MQ is not viable. The broker must be rehosted on EC2 to preserve the custom CentOS setup.

Identify the technical blocker (custom modules with lost source code) that prevents moving to a managed service.

Evaluate the migration classification for the Analytical Data Warehouse.

Migrating a 50 TB Oracle Data Warehouse to Amazon Redshift involves a heterogeneous database engine conversion, schema redesign using AWS SCT, and modifying application/query code. Under AWS framework guidelines, this is classified as Refactoring (Re-architecting).

Distinguish between Replatforming (minor optimization, same engine/minor adjustments) and Refactoring (architectural/engine changes requiring schema rewrites).

Evaluate the constraints of the Legacy Document Archiving Service.

The service runs on Solaris SPARC (incompatible with standard x86-64 EC2 platforms directly) and will be decommissioned in 9 months. Emulating SPARC on AWS or refactoring the daemon is not cost-effective for a short lifecycle, meaning it should be Retained on-premises with hybrid access.

Determine the optimal strategy based on the remaining lifetime of the system and architecture compatibility constraints.

Key Concept

Selecting migration strategies within the 7 Rs framework based on architecture platform compatibility, managed service limitations, and system lifecycle constraints.

Question 1258Question →

A gaming company hosts a multiplayer matchmaking service on AWS. The application's compute tier is deployed in private subnets across three Availability Zones ( $us-east-1a$ , $us-east-1b$ , and $us-east-1c$ ) within an Auto Scaling group (ASG) behind an Application Load Balancer (ALB). Outbound requests to external third-party game servers are routed through a single NAT Gateway located in $us-east-1a$ .

During a daily scheduled global tournament, player traffic surges instantaneously. The following issues are observed:
1. Outbound traffic to the external game servers fails completely if there is an outage in $us-east-1a$ , disabling matchmaking for players in $us-east-1b$ and $us-east-1c$ .
2. The ASG scale-out policy (based on CPU utilization) triggers immediately during the traffic surge. However, because new instances require $8$ minutes ( $480$ seconds) to download configuration files, install dependencies, and bootstrap the application, the ASG continues to launch unnecessary additional instances every few minutes before the previously launched instances can start processing traffic. This behavior leads to significant over-provisioning and high compute costs.

Which two actions should the solutions architect take to resolve these issues while maintaining high availability and minimizing cost?

Select all that apply

Deploy a NAT Gateway in the public subnet of each Availability Zone, and update the route tables of the private subnets to route outbound traffic through the NAT Gateway located in their respective Availability Zone.

Configure the step scaling policy's warmup period and the Auto Scaling group's default cooldown period to at least 500 seconds, ensuring that no new scaling activities are triggered before the running instances complete their bootstrapping.

Deploy a secondary NAT Gateway in the public subnet of

us-east-1b

, and configure a Route 53 active-passive failover policy to dynamically update the VPC route tables if the primary NAT Gateway in

us-east-1a

fails.

Modify the scaling policy to use target tracking on CPU utilization with the instance warm-up set to 120 seconds, allowing the Auto Scaling group to aggressively launch instances to absorb the flash traffic.

Request AWS Support to pre-warm the Application Load Balancer, and configure the target group deregistration delay to 480 seconds to allow the instances to receive traffic during their bootstrapping phase.

Show answer & explanation

Answer: Deploy a NAT Gateway in the public subnet of each Availability Zone, and update the route tables of the private subnets to route outbound traffic through the NAT Gateway located in their respective Availability Zone.; Configure the step scaling policy's warmup period and the Auto Scaling group's default cooldown period to at least 500 seconds, ensuring that no new scaling activities are triggered before the running instances complete their bootstrapping.

Answer

Deploy a NAT Gateway in the public subnet of each Availability Zone and update private subnet route tables, and configure the step scaling policy's warmup period and the Auto Scaling group's default cooldown period to at least 500 seconds.

To ensure high availability and fault tolerance for outbound internet traffic, a NAT Gateway must be deployed in the public subnet of each Availability Zone, and the private subnet route tables must be updated to route traffic through their local NAT Gateway. This eliminates the single point of failure and cross-AZ dependency of the single NAT Gateway. To resolve the over-provisioning issue caused by the 8-minute bootstrapping time, the scaling policy's warmup period and the default cooldown period must be increased to a duration longer than the bootstrapping time (e.g., 500 seconds). This prevents the Auto Scaling group from launching additional instances before the previously launched instances have finished bootstrapping and begun reporting metrics.

Step-by-Step Solution

Analyze the outbound traffic path during an Availability Zone outage.

The single NAT Gateway in the first Availability Zone represents a single point of failure for all three Availability Zones.

Outbound communication with external game servers is critical for matchmaking across all zones.

Determine the correct configuration to establish high availability for outbound traffic.

A NAT Gateway must be deployed in each of the three Availability Zones, with respective private subnet route tables updated to route traffic locally.

This removes the cross-AZ dependency and ensures that an outage in one zone does not affect outbound traffic in the remaining zones.

Evaluate the relationship between instance bootstrapping duration and Auto Scaling group scaling activity.

The 8-minute bootstrapping time is significantly longer than the time the ASG waits before initiating another scaling evaluation.

When the ASG launches an instance, if the warm-up and cooldown periods are shorter than 8 minutes, the ASG will evaluate metrics before the instance is ready to take load, resulting in over-provisioning.

Formulate the correct Auto Scaling group policy adjustments.

Set both the step scaling policy's warm-up period and the default cooldown period to at least 500 seconds (greater than 480 seconds).

This forces the ASG to pause scaling evaluations until the newly launched instances are ready and contributing to CPU utilization metrics, preventing unnecessary scale-out.

Key Concept

To prevent scale-out over-provisioning when EC2 instances have long bootstrap times, the Auto Scaling group's cooldown and scaling policy warm-up periods must be configured to be longer than the bootstrap duration. Additionally, NAT Gateways must be deployed in each Availability Zone to avoid cross-AZ failures and single points of failure for outbound traffic.

Estimated Time:4m 0s

Question 1259Question →

An enterprise uses AWS Organizations to manage a multi-account environment. The central Platform DevOps team maintains configuration baselines using Ansible playbooks stored in a private GitHub repository. To automate configuration management and enforce these baselines on Amazon EC2 instances across multiple workload accounts, the team uses AWS Systems Manager State Manager associations. To pull the playbooks from the private repository, State Manager requires a GitHub Personal Access Token (PAT). The DevOps team stores the GitHub PAT as a secret in AWS Secrets Manager within a centralized Shared Services account. They configure the secret using the default AWS-managed KMS key (aws/secretsmanager). The EC2 instances in the workload accounts are assigned an IAM instance profile with a policy that allows the secretsmanager:GetSecretValue action on the secret's ARN. When the State Manager association executes in the workload accounts, the execution fails on the EC2 instances, and the Systems Manager runbook log displays an AccessDeniedException error related to AWS KMS decryption. Which of the following actions should the Solutions Architect take to resolve this issue and enable successful configuration management?

Update the workload accounts' IAM instance profile policies to explicitly grant the kms:Decrypt action targeting the default AWS-managed KMS key (aws/secretsmanager) ARN in the Shared Services account, and configure the secret's resource policy to trust the workload account IDs.

Create and attach a Service Control Policy (SCP) to the Organizational Unit (OU) containing the workload accounts that explicitly permits the secretsmanager:GetSecretValue and kms:Decrypt actions, ensuring the permissions are inherited by the IAM roles without modifying local KMS or secret resource policies.

Re-create the secret in the Shared Services account using a Customer Managed Key (CMK). Configure the CMK key policy to allow kms:Decrypt permissions for the workload accounts' IAM roles. Add a resource-based policy to the Secrets Manager secret that permits secretsmanager:GetSecretValue for the workload IAM roles, and update the workload accounts' IAM instance profile policies to allow kms:Decrypt on the CMK.

Enable AWS CloudFormation drift detection on the workload stacks to identify modified local configuration parameters, trigger an SSM Automation runbook to restore the SSM Agent configuration to its baseline, and configure AWS CodeDeploy to perform a linear deployment of the Ansible playbook.

Show answer & explanation

Answer: Re-create the secret in the Shared Services account using a Customer Managed Key (CMK). Configure the CMK key policy to allow kms:Decrypt permissions for the workload accounts' IAM roles. Add a resource-based policy to the Secrets Manager secret that permits secretsmanager:GetSecretValue for the workload IAM roles, and update the workload accounts' IAM instance profile policies to allow kms:Decrypt on the CMK.

Answer

The correct answer is to re-create the secret in the Shared Services account using a Customer Managed Key (CMK), configure the CMK's key policy and secret's resource policy to allow access from the workload accounts' IAM roles, and update the workload accounts' IAM instance profile policies to allow kms:Decrypt on the CMK.

The correct answer is correct because AWS Secrets Manager secrets encrypted with the default AWS-managed key (aws/secretsmanager) cannot be accessed cross-account. AWS-managed keys do not allow their key policies to be modified, which is a prerequisite for cross-account access. Therefore, a Customer Managed Key (CMK) must be used. Additionally, cross-account access requires a resource-based policy on the secret itself to grant retrieval permissions to the external workload account roles, and the workload roles must have corresponding IAM policies allowing secrets retrieval and KMS decryption.

Step-by-Step Solution

Identify the root cause of the AccessDeniedException error during the State Manager association run.

The execution log indicates a KMS decryption error, pointing to a cross-account decryption permission issue when the managed instances retrieve the GitHub Personal Access Token from Secrets Manager in the Shared Services account.

SSM State Manager uses the IAM instance profile of the EC2 instance to execute tasks, meaning the instance's IAM role must have permission to access the secret and decrypt the KMS key.

Analyze the KMS key type used for encrypting the secret.

The secret was encrypted using the default AWS-managed KMS key (aws/secretsmanager), which cannot be modified to grant cross-account access.

AWS-managed KMS keys do not allow custom key policies, making them incompatible with cross-account access scenarios.

Configure a Customer Managed Key (CMK) and resource policies to establish secure cross-account access.

A CMK is created in the Shared Services account with a key policy allowing kms:Decrypt to workload roles. The secret is re-created with this CMK, and its resource policy is configured to allow secretsmanager:GetSecretValue for the workload roles. The workload instance profile IAM policies are updated to allow kms:Decrypt on the CMK and secretsmanager:GetSecretValue on the secret.

Establishing cross-account access to Secrets Manager requires both a resource policy on the secret, an IAM policy on the requesting role, and a custom KMS key policy permitting cross-account decryption.

Key Concept

Establishing secure cross-account access for AWS Secrets Manager secrets requires using a Customer Managed Key (CMK) because default AWS-managed keys (e.g., aws/secretsmanager) cannot be shared cross-account or have their key policies modified.

Question 1260Question →

A gaming company has an existing analytics pipeline where game clients upload telemetry data directly to an Amazon S3 bucket in a shared-services account. The data contains customer identifiers. Currently, the objects are encrypted using SSE-S3. The security team has updated compliance guidelines requiring:
1. Data must be encrypted at rest using a customer-managed key (CMK) that supports automated annual rotation.
2. Cross-account access must be configured to allow a data analytics team in a separate AWS account to query the S3 bucket using Amazon Athena, ensuring they can decrypt the data.
3. Write access to the bucket must be restricted so that only clients coming from a specific list of corporate IP ranges can put objects.

Which of the following actions should the Solutions Architect take to enhance data protection and meet these compliance requirements? (Select TWO.)

Select all that apply

Create a customer managed key (CMK) in the shared-services account and configure the S3 bucket to use SSE-KMS. Update the key policy to allow the IAM role used by Amazon Athena in the analytics account to perform the kms:Decrypt action.

Update the S3 bucket policy in the shared-services account to grant the Amazon Athena IAM role in the analytics account s3:GetObject and s3:ListBucket permissions, and add a condition denying s3:PutObject requests that do not originate from the allowed corporate IP ranges.

Configure the S3 bucket to use SSE-KMS with the AWS-managed key (aws/s3). Update the key policy of aws/s3 to grant the Amazon Athena IAM role in the analytics account kms:Decrypt permissions.

Attach a Service Control Policy (SCP) at the root of the organization that explicitly grants the Amazon Athena IAM role in the analytics account permission to access the S3 bucket and the KMS key in the shared-services account.

Modify the trust policy of the Amazon Athena IAM role in the analytics account to list the S3 bucket ARN in the shared-services account as a trusted service principal, thereby allowing cross-account read access without modifying the S3 bucket policy.

Show answer & explanation

Answer: Create a customer managed key (CMK) in the shared-services account and configure the S3 bucket to use SSE-KMS. Update the key policy to allow the IAM role used by Amazon Athena in the analytics account to perform the kms:Decrypt action.; Update the S3 bucket policy in the shared-services account to grant the Amazon Athena IAM role in the analytics account s3:GetObject and s3:ListBucket permissions, and add a condition denying s3:PutObject requests that do not originate from the allowed corporate IP ranges.

Answer

Create a customer managed key (CMK) in the shared-services account with cross-account access to the Athena role, and update the S3 bucket policy to allow cross-account access with IP restrictions on write operations.

To satisfy the requirements, a customer managed key (CMK) must be created in the shared-services account because AWS-managed keys (like aws/s3) cannot have their key policies modified to grant cross-account permissions. The key policy of the CMK must explicitly allow the analytics account's Athena execution IAM role to perform the decrypt action. Furthermore, the S3 bucket policy in the shared-services account must be updated to grant the cross-account Athena IAM role read permissions (GetObject and ListBucket) and enforce IP-based write restrictions using a condition block.

Step-by-Step Solution

Evaluate KMS key type requirements.

Since cross-account access to encrypted S3 objects is required, standard AWS-managed keys (aws/s3) cannot be used because their key policies are immutable. A customer managed key (CMK) must be created.

Customer managed keys allow policy updates to authorize cross-account decryption.

Configure S3 bucket policy for cross-account read access and write restrictions.

Create a bucket policy in the shared-services account that allows s3:GetObject and s3:ListBucket for the external Athena IAM role. Include a conditional deny block restricting s3:PutObject actions to specific corporate IP ranges.

S3 cross-account access requires explicit permission in both the IAM policy of the calling principal and the S3 bucket policy.

Update the KMS key policy.

Grant kms:Decrypt permissions to the external Athena IAM role ARN in the key policy of the CMK.

The client must have both S3 read permissions and KMS decrypt permissions to read the encrypted S3 objects.

Key Concept

Cross-account S3 access with SSE-KMS encryption requires configuring both the S3 bucket policy and the customer managed KMS key policy to permit the external IAM principal, as AWS-managed keys cannot be shared cross-account.

PreviousPage 63 / 99Next

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