All practice questions

1964 questions

All types1,964 Multiple choice1,006 Multiple select931 Ordering27

A solutions architect is designing a database strategy for an online application that uses an Amazon RDS for MySQL database. The database experiences sudden spikes in read query volume, which degrades performance. The solutions architect needs to offload this read traffic and allow the database to scale horizontally. Which of the following designs represents the correct and most efficient database strategy to scale read capacity?

Configure Amazon RDS Multi-AZ and direct all read traffic to the standby instance in the secondary Availability Zone.

Migrate the database to Amazon Aurora MySQL and configure Aurora Auto Scaling to dynamically scale the number of Aurora Replicas based on read load.

Deploy Amazon ElastiCache for Memcached, enabling its persistence and multi-AZ replication features to store and serve the relational query results.

Implement a secondary database in another AWS Region using a pilot light disaster recovery model to handle the read query spikes.

Show answer & explanation

Answer: Migrate the database to Amazon Aurora MySQL and configure Aurora Auto Scaling to dynamically scale the number of Aurora Replicas based on read load.

Answer

Migrate the database to Amazon Aurora MySQL and configure Aurora Auto Scaling to dynamically scale the number of Aurora Replicas based on read load.

Migrating to Amazon Aurora MySQL allows the architecture to utilize Aurora Replicas, which are active and capable of serving read traffic. By enabling Aurora Auto Scaling, the system can automatically adjust the number of replicas to handle dynamic changes in read demand, ensuring application performance and cost efficiency.

Step-by-Step Solution

Analyze the workload requirements

The requirement is to scale read capacity horizontally and handle sudden read spikes dynamically.

This helps determine which replication and auto-scaling mechanisms are valid.

Evaluate the database replication options

Amazon RDS Multi-AZ standbys cannot serve read traffic. Amazon Aurora Replicas can serve active read traffic and support dynamic auto-scaling.

This filters out strategies that cannot offload read queries.

Select the correct caching and scaling configuration

Aurora Auto Scaling with Aurora Replicas is selected because it meets the horizontal scalability requirement natively, whereas ElastiCache for Memcached lacks persistence and replication support.

This establishes the most efficient and architecturally sound database design.

Key Concept

Scaling database read capacity using Amazon Aurora Replicas and Aurora Auto Scaling.

Question 1082Question →

A logistics and fleet management SaaS platform collects real-time telemetry from delivery vehicles globally. The platform's ingestion tier is deployed in TelemetryIngestVPC in the eu-central-1 Region. The ingested data is processed by a latency-sensitive analytics engine deployed in AnalyticsVPC within the same Region. An on-premises monitoring operations center in Munich connects to AWS via a dedicated 10 Gbps AWS Direct Connect connection terminated at a Direct Connect Gateway (DXGW). The operations center uses internal DNS servers to resolve resources in TelemetryIngestVPC using a Route 53 Private Hosted Zone (PHZ) named fleet.internal. The platform has the following requirements:
- The network path between TelemetryIngestVPC and AnalyticsVPC must support maximum throughput and low latency, utilizing Jumbo Frames (MTU 9001).
- Outbound internet access from both VPCs must be highly available and resilient to Availability Zone outages, while minimizing latency.
- On-premises operators must be able to resolve DNS queries for fleet.internal.

Which of the following architectural designs meets these requirements with the lowest latency and highest throughput?

Establish an Transit Gateway to route all traffic between TelemetryIngestVPC and AnalyticsVPC, and configure the Direct Connect Gateway to handle transitive routing between the VPCs using the on-premises Direct Connect link. Associate the Route 53 Private Hosted Zone fleet.internal with both VPCs. Deploy Route 53 Resolver Inbound Endpoints in TelemetryIngestVPC. Configure independent NAT Gateways in each Availability Zone of both VPCs for outbound internet access.

Establish a VPC Peering connection between TelemetryIngestVPC and AnalyticsVPC to enable direct communication supporting MTU 9001. Deploy Route 53 Resolver Inbound Endpoints in TelemetryIngestVPC across multiple Availability Zones for on-premises DNS forwarding, but do not associate the Route 53 Private Hosted Zone fleet.internal with AnalyticsVPC. Configure independent NAT Gateways in each Availability Zone of both VPCs for outbound internet access.

Establish a VPC Peering connection between TelemetryIngestVPC and AnalyticsVPC. Associate the Route 53 Private Hosted Zone fleet.internal with both VPCs. Deploy Route 53 Resolver Inbound Endpoints across multiple Availability Zones in TelemetryIngestVPC to receive forwarded DNS queries from the on-premises network. Configure independent NAT Gateways in each Availability Zone of both VPCs for outbound internet access.

Establish a VPC Peering connection between TelemetryIngestVPC and AnalyticsVPC to enable direct communication supporting MTU 9001. Associate the Route 53 Private Hosted Zone fleet.internal with both VPCs. Deploy Route 53 Resolver Inbound Endpoints in TelemetryIngestVPC to receive forwarded DNS queries from the on-premises network. Deploy a single NAT Gateway in one Availability Zone of TelemetryIngestVPC and update the route tables of both VPCs to direct all outbound internet-bound traffic to this NAT Gateway.

Show answer & explanation

Answer: Establish a VPC Peering connection between TelemetryIngestVPC and AnalyticsVPC. Associate the Route 53 Private Hosted Zone fleet.internal with both VPCs. Deploy Route 53 Resolver Inbound Endpoints across multiple Availability Zones in TelemetryIngestVPC to receive forwarded DNS queries from the on-premises network. Configure independent NAT Gateways in each Availability Zone of both VPCs for outbound internet access.

Answer

Establish a VPC Peering connection between TelemetryIngestVPC and AnalyticsVPC, associate the Route 53 Private Hosted Zone fleet.internal with both VPCs, deploy Route 53 Resolver Inbound Endpoints across multiple Availability Zones in TelemetryIngestVPC, and configure independent NAT Gateways in each Availability Zone of both VPCs.

The correct architecture establishes a direct VPC Peering connection between TelemetryIngestVPC and AnalyticsVPC to achieve the lowest latency and highest throughput (supporting Jumbo Frames with MTU 9001). It associates the Route 53 Private Hosted Zone fleet.internal with both VPCs so that DNS resolution works natively in both environments. Furthermore, it deploys Route 53 Resolver Inbound Endpoints across multiple Availability Zones to handle DNS queries forwarded from on-premises, and implements independent NAT Gateways in each Availability Zone of both VPCs to ensure highly available, resilient, and low-latency outbound internet routing without cross-AZ performance penalties.

Step-by-Step Solution

Select the lowest-latency connectivity method between TelemetryIngestVPC and AnalyticsVPC.

VPC Peering is chosen because it supports Jumbo Frames (MTU 9001) for intra-region traffic, routing packets directly without intermediate hops (unlike Transit Gateway, which has additional processing overhead).

To satisfy the requirement of maximum throughput and lowest latency using Jumbo Frames.

Configure DNS resolution for both cloud resources and on-premises operators.

Associate the Route 53 Private Hosted Zone (PHZ) fleet.internal with both TelemetryIngestVPC and AnalyticsVPC. Then, set up Route 53 Resolver Inbound Endpoints in TelemetryIngestVPC.

A PHZ must be explicitly associated with a VPC for resources within that VPC to resolve its DNS records. The Inbound Endpoint allows on-premises DNS forwarders to query the PHZ over Direct Connect.

Configure highly available and optimized outbound internet access.

Deploy independent NAT Gateways in each Availability Zone (AZ) of both VPCs, and configure subnet route tables to direct internet-bound traffic to the NAT Gateway in the same AZ.

This setup prevents cross-AZ latency and data transfer charges, and ensures that an outage in one Availability Zone does not impact internet access for resources in another zone.

Key Concept

To optimize inter-VPC performance and latency within the same AWS Region, direct VPC Peering is preferred over transit networks due to native Jumbo Frame (MTU 9001) support and lack of additional transit hops. Furthermore, Private Hosted Zones must be associated with every communicating VPC, and NAT Gateways must be deployed per-AZ to maintain local routing domains and high availability.

Question 1083Question →

An enterprise runs a batch processing application on hybrid on-premises servers and Amazon EC2 instances. The application writes execution logs to `/var/log/app/batch.log`. To comply with compliance and auditing policies, these logs are rotated hourly and renamed using the format `/var/log/app/batch.log.YYYY-MM-DD-HH`. A Solutions Architect is deploying the unified CloudWatch agent to collect these logs and publish them to Amazon CloudWatch Logs. Which configuration strategy for the CloudWatch agent should the Solutions Architect implement to ensure that logs are continuously collected without gaps during and after the hourly rotation process?

Specify the static file path `/var/log/app/batch.log` in the `file_path` parameter of the agent configuration file and rely on the operating system file descriptor tracking to capture rotated log data.

Configure the agent to write directly to an Amazon S3 bucket in a centralized security account, using an S3 bucket policy that permits public write access to simplify cross-account authentication.

Use a wildcard pattern `/var/log/app/batch.log*` in the `file_path` parameter of the agent configuration file to ensure the agent monitors both the active and rotated files during the transition.

Enable log encryption using the AWS-managed KMS key for CloudWatch Logs (`aws/logs`) and configure the monitoring account's cross-account access by updating the policy of this AWS-managed key.

Show answer & explanation

Answer: Use a wildcard pattern `/var/log/app/batch.log*` in the `file_path` parameter of the agent configuration file to ensure the agent monitors both the active and rotated files during the transition.

Answer

Use a wildcard pattern `/var/log/app/batch.log*` in the `file_path` parameter of the agent configuration file to ensure the agent monitors both the active and rotated files during the transition.

Specifying a wildcard pattern `/var/log/app/batch.log*` in the `file_path` parameter of the CloudWatch agent configuration allows the agent to monitor both the active log file and any rotated files. This ensures that any log entries that remain in the buffer or are written during the rotation window are successfully captured and uploaded.

Step-by-Step Solution

Analyze the log rotation mechanism of the application.

The application writes to a static log file, which is renamed to include a timestamp hourly, and a new empty log file is created.

Understanding how the source application handles log files is critical to determining how the collection agent must be configured.

Select the correct path syntax for the CloudWatch agent config.

Using a wildcard pattern `/var/log/app/batch.log*` enables the agent to continuously monitor the active file and catch any remaining or late-written lines in the rotated files.

A static path configuration fails to track the renamed file during rotation, potentially leading to data loss.

Address encryption and security permissions appropriately.

Avoid modifying AWS-managed KMS keys or opening public write access to S3, using customer-managed KMS keys and secure IAM roles instead.

Ensures the solution maintains operational excellence and security compliance without using invalid AWS actions.

Key Concept

CloudWatch Agent Log Tracking and Wildcard Configuration

Estimated Time:2m 0s

Question 1084Question →

An enterprise manages its multi-account environment using AWS Organizations. An application running in a production account (Account A) writes transaction logs containing sensitive financial data to an Amazon S3 bucket in Account A. To comply with corporate data protection policies, these logs must be encrypted at rest using an encryption key managed by the central Security account (Account Sec). In addition, a compliance auditor role in Account Sec must have read access to these logs to conduct periodic compliance checks.

The Solutions Architect attempts to implement this by configuring the default server-side encryption (SSE-KMS) of the S3 bucket in Account A to use the AWS-managed KMS key for S3 (aws/s3) located in Account Sec. The architect also adds a bucket policy in Account A to grant s3:GetObject access to the compliance auditor role in Account Sec. Both the application in Account A and the auditor in Account Sec begin receiving Access Denied errors during write and read operations.

Which of the following describes the root cause of these failures and the correct way to resolve them?

The failures are caused by restrictive boundaries at the organization level. To resolve this, the architect must attach a Service Control Policy (SCP) to the Organizational Unit (OU) containing both accounts, explicitly allowing s3:* and kms:* actions across accounts. Because SCPs act as permission boundaries that automatically inherit down, this policy will authorize the cross-account S3 and KMS actions without needing to modify local IAM or KMS key policies.

AWS-managed KMS keys (such as aws/s3) cannot be used for cross-account operations because their key policies are managed by AWS and cannot be modified. To resolve this, the architect must create a customer-managed KMS key in Account Sec and configure its key policy to grant the application's IAM role in Account A permissions for kms:GenerateDataKey and kms:Decrypt. Additionally, the key policy must grant kms:Decrypt to the compliance auditor role in Account Sec, and the S3 bucket policy in Account A must grant the auditor role s3:GetObject permissions.

The AWS-managed KMS key (aws/s3) in Account Sec is restricted from cross-account access because the S3 bucket in Account A has not enabled cross-account key sharing. To resolve this, the architect must modify the S3 bucket configuration to enable cross-account KMS delegation, which permits the S3 service in Account A to utilize the AWS-managed key from Account Sec without requiring a customer-managed key.

The failures occur because S3 bucket policies have not been configured to manage decryption. To resolve this, the architect must create a customer-managed KMS key in Account Sec, and configure a bucket policy in Account A that grants both s3:GetObject and kms:Decrypt directly to the auditor's IAM role. Since S3 bucket policies centrally govern all access to the resource, this configuration allows the auditor to read and decrypt the logs without modifying KMS key policies.

Show answer & explanation

Answer: AWS-managed KMS keys (such as aws/s3) cannot be used for cross-account operations because their key policies are managed by AWS and cannot be modified. To resolve this, the architect must create a customer-managed KMS key in Account Sec and configure its key policy to grant the application's IAM role in Account A permissions for kms:GenerateDataKey and kms:Decrypt. Additionally, the key policy must grant kms:Decrypt to the compliance auditor role in Account Sec, and the S3 bucket policy in Account A must grant the auditor role s3:GetObject permissions.

Answer

Create a customer-managed KMS key in Account Sec, and configure its key policy to allow Account A's application role permissions to generate data keys and decrypt, and Account Sec's auditor role to decrypt. Configure the S3 bucket policy in Account A to allow the auditor role s3:GetObject.

The correct option correctly identifies that AWS-managed KMS keys (aws/s3) cannot be shared across accounts due to their unmodifiable key policies. A customer-managed KMS key in Account Sec is required, with its key policy configured to grant the necessary KMS permissions to the application role in Account A and the auditor role in Account Sec. Furthermore, the S3 bucket policy in Account A must grant read access (s3:GetObject) to the auditor role.

Step-by-Step Solution

Analyze the limitation of the current encryption configuration.

AWS-managed KMS keys (like aws/s3) have fixed policies that cannot be modified to grant cross-account access, causing operations to fail.

Identify the root cause of the Access Denied error when attempting to use the AWS-managed key from Account Sec.

Create a customer-managed KMS key in Account Sec.

A customer-managed KMS key is provisioned whose policy can be modified to delegate cross-account access.

Only customer-managed keys support custom key policies that permit cross-account usage.

Configure the customer-managed key policy in Account Sec.

Grant the application's IAM role in Account A permissions for kms:GenerateDataKey and kms:Decrypt, and grant the auditor's role in Account Sec permissions for kms:Decrypt.

The writer in Account A needs key permissions to encrypt uploads, and the reader in Account Sec needs key permissions to decrypt logs.

Configure S3 bucket default encryption and S3 bucket policy in Account A.

Set the S3 bucket's default SSE-KMS encryption to use the new customer-managed key. Add a bucket policy statement allowing the auditor role in Account Sec to perform s3:GetObject.

Enables automatic server-side encryption and delegates S3 read permissions to the cross-account auditor.

Key Concept

Cross-account S3 encryption using AWS KMS Customer Managed Keys

Question 1085Question →

A multinational financial enterprise is consolidating its network monitoring strategy across 150 member accounts within an AWS Organizations structure. A Solutions Architect must configure Amazon VPC Flow Logs in all member accounts to write directly to a single, centralized Amazon S3 bucket located in a dedicated Security account. The enterprise's security policy mandates that all logs must be encrypted at rest using an AWS KMS customer managed key owned by the Security account. Additionally, access must be restricted to ensure only the enterprise's organization can write to the bucket, and member accounts must not be able to read each other's logs. Which combination of configurations will meet these requirements while minimizing operational overhead?

In the Security account, configure the S3 bucket policy to allow the `delivery.logs.amazonaws.com` service principal to perform `s3:PutObject` and `s3:GetBucketAcl` actions, restricted by the `aws:PrincipalOrgID` condition. Enable default bucket encryption using the AWS-managed KMS key (`aws/s3`) in the Security account to avoid KMS key policy management overhead. In the member accounts, configure VPC Flow Logs to publish directly to the central S3 bucket.

In the Security account, configure the S3 bucket policy to allow the IAM roles of the member accounts to perform `s3:PutObject` and `s3:GetBucketAcl` actions, restricted by the `aws:PrincipalOrgID` condition. Configure the Security account's KMS key policy to allow the same member account IAM roles to perform `kms:GenerateDataKey*` and `kms:Decrypt` actions. In the member accounts, configure VPC Flow Logs to use an IAM role that writes to the central S3 bucket.

In the Security account, configure the S3 bucket policy to allow the `delivery.logs.amazonaws.com` service principal to perform `s3:PutObject` and `s3:GetBucketAcl` actions, restricted by the `aws:PrincipalOrgID` condition. In the Security account's KMS key policy, allow `delivery.logs.amazonaws.com` to perform `kms:GenerateDataKey*` and `kms:Decrypt` actions. In the member accounts, configure VPC Flow Logs to publish directly to the central S3 bucket.

In the Security account, configure the S3 bucket policy to allow the `delivery.logs.amazonaws.com` service principal to perform `s3:PutObject` and `s3:GetBucketAcl` actions, restricted by the `aws:PrincipalOrgID` condition. In the Security account's KMS key policy, allow only the root account of the Security account to manage the key, relying on the S3 bucket policy's `PutObject` permission to implicitly delegate KMS encryption permissions to the Log Delivery service. In the member accounts, configure VPC Flow Logs to publish directly to the central S3 bucket.

Show answer & explanation

Answer: In the Security account, configure the S3 bucket policy to allow the `delivery.logs.amazonaws.com` service principal to perform `s3:PutObject` and `s3:GetBucketAcl` actions, restricted by the `aws:PrincipalOrgID` condition. In the Security account's KMS key policy, allow `delivery.logs.amazonaws.com` to perform `kms:GenerateDataKey*` and `kms:Decrypt` actions. In the member accounts, configure VPC Flow Logs to publish directly to the central S3 bucket.

Answer

Configure the S3 bucket policy to allow the `delivery.logs.amazonaws.com` service principal to perform `s3:PutObject` and `s3:GetBucketAcl` actions with the `aws:PrincipalOrgID` condition. Grant `kms:GenerateDataKey*` and `kms:Decrypt` permissions to `delivery.logs.amazonaws.com` in the KMS key policy, and configure VPC Flow Logs to write directly to the bucket.

The correct solution involves configuring the S3 bucket policy to grant permissions to the Log Delivery service principal (`delivery.logs.amazonaws.com`) rather than local IAM roles, and explicitly allowing the same service principal to use the customer managed key in the KMS key policy. This is because cross-account log delivery for VPC Flow Logs runs under the Log Delivery service principal. Restricting access using the `aws:PrincipalOrgID` condition ensures that only VPC Flow Logs from within the organization can write to the bucket, maintaining security and preventing external writers.

Step-by-Step Solution

Identify the service principal responsible for delivering VPC Flow Logs directly to S3.

The AWS Log Delivery service principal is `delivery.logs.amazonaws.com`.

VPC Flow Logs do not use local IAM roles to write to S3; instead, the logs are delivered by a managed AWS service principal.

Determine the S3 bucket policy requirements for cross-account log delivery under AWS Organizations.

The bucket policy must allow `s3:PutObject` and `s3:GetBucketAcl` to `delivery.logs.amazonaws.com` restricted by `aws:PrincipalOrgID` to prevent external write access.

This restricts access to only the member accounts within the enterprise's AWS Organization.

Determine the KMS key policy requirements for encrypting the cross-account log delivery.

The KMS key policy must allow `delivery.logs.amazonaws.com` to perform `kms:GenerateDataKey*` and `kms:Decrypt` actions.

AWS KMS key policies must explicitly grant usage rights to service principals, as S3 bucket policies cannot delegate KMS permissions. AWS-managed keys cannot be used as their policies cannot be modified.

Key Concept

Cross-account log delivery via the Log Delivery service principal with SSE-KMS encryption using a Customer Managed Key.

Question 1086Question →

A media streaming company hosts a high-throughput video processing pipeline in the `us-west-2` Region across two VPCs: an Ingestion VPC and a Processing VPC. The Ingestion VPC receives raw high-definition video feeds and stores them temporarily on Amazon EC2 instances. The Processing VPC hosts a cluster of GPU-accelerated EC2 instances that pull these video files for transcoding. Currently, all network traffic between the two VPCs routes through an AWS Transit Gateway. The application requires transferring files of up to $50$ GB with a minimum throughput of $10$ Gbps and the lowest possible latency. During peak events, the company observes packet fragmentation and throughput limits due to MTU constraints on the Transit Gateway path. The company also uses an Amazon Route 53 Private Hosted Zone (PHZ) named `video.internal` for service discovery, which is currently associated only with the Ingestion VPC. Which solution should a solutions architect implement to optimize network performance, maximize throughput, and maintain DNS resolution?

Establish a VPC Peering connection directly between the Ingestion VPC and the Processing VPC. Configure VPC route tables to route traffic destined for the peer VPC CIDR through the peering connection, and enable jumbo frames (

9001

MTU) on the EC2 instances. Associate the Route 53 Private Hosted Zone `video.internal` with the Processing VPC.

9001

MTU) on the EC2 instances. Do not modify the Route 53 Private Hosted Zone, as DNS resolution is automatically shared across peered VPCs.

Keep the existing Transit Gateway configuration, but deploy a Transit Gateway Connect attachment with GRE tunnels between the Ingestion VPC and the Processing VPC to support virtual routing. Associate the Route 53 Private Hosted Zone `video.internal` with the Processing VPC.

Deploy a NAT Gateway in a public subnet of the Ingestion VPC, and route all outgoing transcoding traffic from the Processing VPC to this NAT Gateway using Transit Gateway. Associate the Route 53 Private Hosted Zone `video.internal` with the Processing VPC.

Show answer & explanation

Answer: Establish a VPC Peering connection directly between the Ingestion VPC and the Processing VPC. Configure VPC route tables to route traffic destined for the peer VPC CIDR through the peering connection, and enable jumbo frames ( $9001$ MTU) on the EC2 instances. Associate the Route 53 Private Hosted Zone `video.internal` with the Processing VPC.

Answer

Establish a VPC Peering connection directly between the Ingestion VPC and the Processing VPC, update VPC route tables to route peer traffic, enable jumbo frames (

9001

MTU), and associate the Route 53 Private Hosted Zone `video.internal` with the Processing VPC.

Establishing a VPC Peering connection directly between the two VPCs allows the configuration of jumbo frames (

9001

MTU) end-to-end, which reduces packet fragmentation and overhead. This optimizes throughput and latency compared to AWS Transit Gateway, which has an MTU limit of

8500

bytes. Furthermore, the Route 53 Private Hosted Zone must be associated with the Processing VPC so that instances in it can resolve endpoints under `video.internal`.

Step-by-Step Solution

Analyze MTU limits on the paths.

AWS Transit Gateway limits the MTU size to

8500

bytes for VPC attachments. VPC Peering supports jumbo frames up to

9001

bytes MTU for traffic within the same region.

To avoid packet fragmentation for large file transfers, the path must support jumbo frames (

9001

MTU).

Establish the optimized network path.

Create a VPC Peering connection directly between the Ingestion VPC and the Processing VPC, update route tables to use the peering connection, and configure EC2 instances to use jumbo frames.

This bypasses Transit Gateway, reduces the network hop, and enables end-to-end

9001

MTU.

Configure DNS resolution for the private domain.

Associate the Route 53 Private Hosted Zone `video.internal` with the Processing VPC.

Route 53 Private Hosted Zones are not transitively resolved across peered VPCs automatically; explicit association is required.

Key Concept

VPC Peering vs. Transit Gateway MTU support and Private Hosted Zone VPC association

Estimated Time:2m 0s

Question 1087Question →

An enterprise runs a high-volume payment processing application in a single AWS account in the us-east-1 Region. The system uses an Amazon Elastic Kubernetes Service (EKS) cluster for compute and an Amazon DynamoDB table for transaction states. The application has suffered outages due to regional service issues and internet routing degradation. To improve availability, the solutions architect must redesign the architecture to implement a multi-region Active-Passive disaster recovery (DR) strategy across us-east-1 and us-west-2. The solution must achieve a Recovery Time Objective (RTO) of less than 5 minutes and a Recovery Point Objective (RPO) of less than 1 minute. Which of the following actions should the solutions architect take to meet these reliability and disaster recovery requirements? (Select TWO.)

Select all that apply

Convert the existing DynamoDB table to a global table by adding a replica in the us-west-2 Region, and provision Route 53 Application Recovery Controller (ARC) routing controls linked to Route 53 failover routing records pointing to the Application Load Balancers in each region.

Deploy a duplicate EKS cluster in the us-west-2 Region with pre-provisioned worker nodes matching the baseline capacity of the primary region, and ensure the application deployment pipeline deploys container images and configuration maps to both EKS clusters to maintain configuration alignment.

Configure a pilot light DR strategy by maintaining a backup EKS cluster in the us-west-2 Region with an Auto Scaling Group size set to zero, and use an AWS Lambda function triggered by Route 53 DNS failover events to bootstrap the EKS nodes and pull the container images when an outage is detected in the us-east-1 Region.

Set up Route 53 active-passive failover using standard Route 53 HTTP/HTTPS health checks directly targeting the Application Load Balancers in both regions to automate DNS failover without manual intervention during a regional control plane event.

Establish an AWS Transit Gateway in both regions to route all outbound egress payment traffic from the us-west-2 EKS cluster through a single NAT Gateway in the us-east-1 Region to preserve static IP addresses for external payment providers.

Show answer & explanation

Answer: Convert the existing DynamoDB table to a global table by adding a replica in the us-west-2 Region, and provision Route 53 Application Recovery Controller (ARC) routing controls linked to Route 53 failover routing records pointing to the Application Load Balancers in each region.; Deploy a duplicate EKS cluster in the us-west-2 Region with pre-provisioned worker nodes matching the baseline capacity of the primary region, and ensure the application deployment pipeline deploys container images and configuration maps to both EKS clusters to maintain configuration alignment.

Answer

Convert the existing DynamoDB table to a global table, provision Route 53 ARC routing controls, deploy a duplicate EKS cluster in the secondary region with pre-provisioned baseline worker nodes, and keep application configurations synchronized across both clusters.

To achieve an RPO of under 1 minute and an RTO of under 5 minutes, database replication must be continuous and asynchronous, which is fulfilled by DynamoDB Global Tables. Furthermore, the standby EKS cluster must be pre-provisioned to run containerized workloads immediately without cold-start bootstrapping latency. Traffic routing must be managed deterministically using Route 53 Application Recovery Controller (ARC) routing controls, which bypass control plane dependencies of the failing region.

Step-by-Step Solution

Address the data replication requirements to meet the sub-minute recovery point objective (RPO).

Convert the DynamoDB table to a Global Table with replicas in both the primary and standby regions, enabling asynchronous replication with sub-second latency.

This guarantees that database transaction states are continuously replicated and available in the disaster recovery region with an RPO well below the 1-minute limit.

Ensure the compute infrastructure is pre-warmed to meet the strict 5-minute recovery time objective (RTO).

Deploy the secondary EKS cluster with pre-provisioned node capacity matching baseline requirements and configure the CI/CD pipeline to deploy container images and ConfigMaps to both regions.

Cold startup of EKS nodes, Kubernetes agent initialization, and pulling heavy container images during a failover event would exceed the 5-minute RTO.

Implement a highly reliable failover mechanism that does not depend on the control plane of the degraded region.

Create Route 53 Application Recovery Controller (ARC) routing controls and associate them with Route 53 failover records.

Route 53 ARC uses an extremely resilient, globally distributed data plane for state updates, allowing failover execution within seconds even during a full regional control plane failure.

Key Concept

Designing multi-region disaster recovery for applications requiring low RTO and RPO requires active data replication (such as DynamoDB Global Tables) and pre-provisioned, hot/warm standby compute resources combined with deterministic routing failover using Route 53 ARC.

Question 1088Question →

An enterprise uses AWS CloudFormation StackSets with service-managed permissions to deploy a standardized security baseline—consisting of IAM roles, AWS Config rules, and Amazon VPC security groups—across all member accounts within an AWS Organization. The templates are stored in a centralized Amazon S3 bucket in a dedicated administration account. Over time, developers in member accounts have manually modified security groups and IAM roles, introducing configuration drift. The Solutions Architect must establish a fully automated solution to detect stack drift across all accounts and remediate the drifted resources to align with the StackSet template. The remediation must not disrupt the stack management lifecycle or cause subsequent stack updates to fail. Which combination of actions will meet these requirements while adhering to the principle of least privilege?

Enable CloudFormation StackSets drift detection on a scheduled basis. Create an Amazon EventBridge rule in the administration account that filters for the CloudFormation StackSet Drift Detection Status Change event indicating a drifted state. Configure the rule to target an AWS Lambda function that initiates a StackSet update targeting the specific drifted accounts and regions using the baseline template. Encrypt the centralized S3 bucket using a Customer Managed Key (CMK) and update the KMS key policy to grant the cross-account AWSCloudFormationStackSetExecutionRole permissions to decrypt the template.

Enable CloudFormation StackSets drift detection on a scheduled basis. Create an Amazon EventBridge rule in the administration account that filters for CloudFormation StackSet Drift Detection Status Change events. Set the target to an AWS Lambda function that initiates a StackSet update using the baseline template to remediate drift. Encrypt the centralized S3 bucket using the default AWS managed key for S3 (aws/s3) and update the key policy to grant the cross-account AWSCloudFormationStackSetExecutionRole permissions to decrypt the template.

Configure an AWS Config rule in each member account to detect configuration changes. When a drifted resource is identified, trigger an AWS Systems Manager Automation runbook that assumes a local administrator role, deletes the drifted IAM roles and security groups, and recreates them using AWS CLI commands to match the baseline. Encrypt the centralized S3 bucket using a Customer Managed Key (CMK) and grant the Systems Manager execution role cross-account decrypt permissions.

Apply a Service Control Policy (SCP) to the organization root that denies cloudformation:UpdateStack and cloudformation:DeleteStack actions to all users except the StackSets execution role to prevent manual drift. Set up an AWS Config rule to monitor the resources and trigger an AWS Systems Manager Automation runbook in the management account that uses the admin role to run DetectStackDrift and automatically apply the baseline template. Encrypt the S3 bucket using a Customer Managed Key (CMK) with cross-account access.

Show answer & explanation

Answer: Enable CloudFormation StackSets drift detection on a scheduled basis. Create an Amazon EventBridge rule in the administration account that filters for the CloudFormation StackSet Drift Detection Status Change event indicating a drifted state. Configure the rule to target an AWS Lambda function that initiates a StackSet update targeting the specific drifted accounts and regions using the baseline template. Encrypt the centralized S3 bucket using a Customer Managed Key (CMK) and update the KMS key policy to grant the cross-account AWSCloudFormationStackSetExecutionRole permissions to decrypt the template.

Answer

Enable CloudFormation StackSets drift detection on a scheduled basis, use an EventBridge rule to trigger a Lambda function that executes a StackSet update using the baseline template, and encrypt the S3 bucket with a Customer Managed Key (CMK) sharing decrypt permissions with the execution role.

The correct solution automates the remediation workflow by using CloudFormation StackSets drift detection to trigger an EventBridge rule, which executes an AWS Lambda function to update the drifted stack instances back to the baseline. It correctly uses a Customer Managed Key (CMK) to encrypt the centralized S3 template bucket, enabling the cross-account StackSet execution roles to access the template payload.

Step-by-Step Solution

Establish cross-account decryption permissions for templates.

The S3 bucket holding the templates is encrypted using a KMS Customer Managed Key (CMK). The key policy is configured to allow cross-account 'kms:Decrypt' actions for the 'AWSCloudFormationStackSetExecutionRole' in member accounts.

AWS-managed keys (aws/s3) cannot be shared cross-account, so a Customer Managed Key must be used for member accounts to fetch the templates during deployment.

Enable drift detection at the StackSet level.

CloudFormation periodically scans all stack instances across member accounts and regions to detect configuration variance against the baseline template.

StackSets drift detection natively determines which resources have been manually modified or deleted without relying on individual agent scripts.

Automate remediation using EventBridge and Lambda.

An EventBridge rule intercepts drift status changes and invokes a Lambda function that triggers an update on the drifted stack instances using the original baseline template.

Updating the stack instance with the original template restores the resources to their baseline state cleanly, preserving physical resource IDs and preventing subsequent CloudFormation lifecycle failures.

Key Concept

Continuous drift detection and automated remediation within multi-account environments using CloudFormation StackSets and cross-account KMS CMK policies.

Question 1089Question →

An energy transmission operator uses AWS Organizations to manage its multi-account environment. To comply with national security regulations, all grid control plane access logs from the Grid Operations account (Account ID: $444455556666$ ) must be archived to a centralized compliance S3 bucket in the Security Auditing account (Account ID: $111122223333$ ).

The security engineering team has established the following requirements:
1. All logs must be encrypted at rest using a Customer Managed Key (CMK) created and managed in the Security Auditing account.
2. The Grid Operations account must have permissions to upload log files to the compliance S3 bucket but must be strictly prevented from decrypting or reading any logs once they are archived.
3. The objects uploaded to the compliance S3 bucket must be owned by the Security Auditing account to ensure compliance audits can access them.

Which combination of configurations will securely meet these requirements?

In the Security Auditing account (

111122223333

), enable default encryption on the compliance S3 bucket using the AWS-managed key for Amazon S3 (aws/s3). Configure the bucket policy to grant the Grid Operations account's IAM role (GridLoggerRole) permissions to perform s3:PutObject. In the Grid Operations account (

444455556666

), attach an IAM policy to GridLoggerRole allowing s3:PutObject on the compliance S3 bucket and kms:GenerateDataKey on the aws/s3 key.

In the Security Auditing account (

111122223333

), configure the compliance S3 bucket with S3 Object Ownership set to Object Writer. Modify the bucket policy to allow the Grid Operations account's IAM role (GridLoggerRole) to perform s3:PutObject with a condition requiring the bucket-owner-full-control canned ACL. In the KMS key policy, grant GridLoggerRole permission to perform kms:GenerateDataKey, kms:DescribeKey, and kms:Decrypt. In the Grid Operations account (

444455556666

), attach an IAM policy to GridLoggerRole allowing s3:PutObject and the required ACL.

In the Security Auditing account (

111122223333

), configure the compliance S3 bucket with S3 Object Ownership set to Bucket Owner Enforced. Apply a bucket policy that allows the Grid Operations account's IAM role (GridLoggerRole) to perform s3:PutObject. Create a KMS Customer Managed Key (CMK) and modify its key policy to allow GridLoggerRole to perform kms:GenerateDataKey and kms:DescribeKey, while omitting kms:Decrypt. In the Grid Operations account (

444455556666

), attach an IAM policy to GridLoggerRole that allows s3:PutObject on the compliance S3 bucket and kms:GenerateDataKey and kms:DescribeKey on the KMS CMK.

In the Security Auditing account (

111122223333

), configure the compliance S3 bucket with S3 Object Ownership set to Bucket Owner Enforced. Apply a bucket policy that allows the Grid Operations account's IAM role (GridLoggerRole) to perform s3:PutObject. Create a KMS Customer Managed Key (CMK) and modify its key policy to allow the Grid Operations account root principal to perform all KMS actions, including kms:Decrypt. In the AWS Organizations management account, attach a Service Control Policy (SCP) to the Grid Operations OU that explicitly denies kms:Decrypt and s3:GetObject to GridLoggerRole.

Show answer & explanation

Answer: In the Security Auditing account ( $111122223333$ ), configure the compliance S3 bucket with S3 Object Ownership set to Bucket Owner Enforced. Apply a bucket policy that allows the Grid Operations account's IAM role (GridLoggerRole) to perform s3:PutObject. Create a KMS Customer Managed Key (CMK) and modify its key policy to allow GridLoggerRole to perform kms:GenerateDataKey and kms:DescribeKey, while omitting kms:Decrypt. In the Grid Operations account ( $444455556666$ ), attach an IAM policy to GridLoggerRole that allows s3:PutObject on the compliance S3 bucket and kms:GenerateDataKey and kms:DescribeKey on the KMS CMK.

Answer

The correct option is the configuration that sets S3 Object Ownership to Bucket Owner Enforced in the Security Auditing account, creates a Customer Managed Key (CMK) that grants kms:GenerateDataKey and kms:DescribeKey to the logging role while omitting kms:Decrypt, and configures the corresponding S3 bucket policy and IAM policy in the Grid Operations account.

The correct solution uses S3 Object Ownership set to Bucket Owner Enforced, which disables Access Control Lists (ACLs) and automatically transfers ownership of all uploaded objects to the bucket owner. To meet the security constraint of preventing the logging role from decrypting written logs, the Customer Managed Key (CMK) policy in the Auditing account must explicitly grant kms:GenerateDataKey and kms:DescribeKey to the logging role while omitting kms:Decrypt. The IAM policy in the logging account and the S3 bucket policy in the auditing account must also align with these restricted permissions.

Step-by-Step Solution

Ensure that the Security Auditing account automatically owns all uploaded log files.

Configure S3 Object Ownership on the compliance S3 bucket to Bucket Owner Enforced, which disables ACLs and automatically transfers ownership of all uploaded objects to the bucket owner.

This guarantees that the Security Auditing account can manage and audit the uploaded logs, satisfying the ownership requirement.

Enable cross-account S3 write permissions.

Apply a bucket policy on the compliance S3 bucket in the Security Auditing account that grants the Grid Operations role (GridLoggerRole) permission to perform s3:PutObject.

Allows the logging service in the remote account to write files to the centralized bucket.

Configure the encryption keys to enforce write-only compliance.

Create a Customer Managed Key (CMK) in the Security Auditing account and configure its key policy to allow the GridLoggerRole to perform kms:GenerateDataKey and kms:DescribeKey, while omitting the kms:Decrypt permission.

Allows the logging role to generate the data keys needed to encrypt and upload objects, but prevents it from decrypting or reading the uploaded logs.

Configure the local permissions in the source account.

Attach an IAM policy to GridLoggerRole in the Grid Operations account allowing s3:PutObject on the compliance S3 bucket and kms:GenerateDataKey/kms:DescribeKey on the Security Auditing KMS CMK.

Permits the logging role to invoke the necessary S3 and KMS actions from the source account.

Key Concept

Cross-account S3 bucket log delivery using S3 Bucket Owner Enforced ownership and KMS Customer Managed Keys with write-only policy constraints.

Question 1090Question →

A logistics enterprise operates a fleet-tracking portal backed by an Amazon RDS for PostgreSQL Multi-AZ DB instance. The database stores real-time delivery route details, driver availability, and active shipment states. During shift changes, the database experiences CPU utilization spikes up to $98\%$ and application connection timeouts due to a surge in read queries from dispatchers querying driver status. A solutions architect must design a caching layer to offload these read-intensive queries. The caching solution must support multi-AZ replication to ensure high availability, automatic failover without application changes, and the capability to restore cached routing structures from disk in the event of a cache node restart. Additionally, the application requires sub-key eviction policies to purge specific route legs when driver status changes. Which configuration meets these requirements with the lowest operational complexity?

Deploy an Amazon ElastiCache for Redis cluster with Multi-AZ enabled and automatic failover. Configure the application to use a Redis hash structure for route details, allowing the update and eviction of individual fields, and enable Redis replication groups.

Deploy an Amazon ElastiCache for Memcached cluster with nodes distributed across multiple Availability Zones. Configure the application to serialize route legs as JSON strings, and implement a custom background script to periodically export cached keys to Amazon S3 to provide persistence.

Enable read routing on the secondary standby instance of the existing Amazon RDS for PostgreSQL Multi-AZ deployment, and update the application configuration to direct all read queries for driver status and active delivery states to this secondary instance.

Deploy an Amazon RDS Proxy instance in front of the PostgreSQL database, and configure a single-node Amazon ElastiCache for Redis instance with Append Only File (AOF) enabled, relying on the RDS Proxy to queue write operations during Redis cache failover events.

Show answer & explanation

Answer: Deploy an Amazon ElastiCache for Redis cluster with Multi-AZ enabled and automatic failover. Configure the application to use a Redis hash structure for route details, allowing the update and eviction of individual fields, and enable Redis replication groups.

Answer

Deploy an Amazon ElastiCache for Redis cluster with Multi-AZ enabled and automatic failover, using a Redis hash structure for route details.

The correct answer is to deploy an Amazon ElastiCache for Redis cluster with Multi-AZ and automatic failover. Redis supports the required features, including multi-AZ replication, persistence via Append Only File (AOF) or daily backups, and complex data structures (like hashes) which enable sub-key eviction policies.

Step-by-Step Solution

Analyze the technical requirements of the caching layer.

The cache must support multi-AZ replication, automatic failover, persistence (restore from disk on restart), and sub-key eviction (data structures).

This determines which caching engine (Redis vs Memcached) is appropriate.

Compare ElastiCache Redis and Memcached against the requirements.

Memcached does not support replication, failover, persistence, or sub-key eviction/hashes. Redis supports replication, Multi-AZ failover, persistence (AOF/RDB), and hashes.

This rules out Memcached-based solutions.

Evaluate the database-level alternative of reading from the standby instance.

Amazon RDS for PostgreSQL Multi-AZ standby instances are passive and cannot serve read traffic.

This rules out routing reads to the RDS standby instance.

Select the correct ElastiCache configuration that meets the requirements with minimal operational complexity.

An ElastiCache for Redis cluster with Multi-AZ and replication groups handles failover automatically, while native Redis hashes satisfy the sub-key eviction requirement.

This provides the optimal, highly available, and performant caching design.

Key Concept

Selecting the correct caching engine (Redis vs Memcached) and configuration based on requirements for replication, persistence, and complex data structures.

Question 1091Question →

An enterprise runs a high-performance compute (HPC) financial simulation application on a fleet of Amazon EC2 instances in an Auto Scaling group behind an Application Load Balancer (ALB). The instances process incoming client requests, run resource-intensive simulations, and store large intermediate scratch files locally. The raw historical data models are hosted in an Amazon S3 bucket.

During market opening hours, the incoming request volume spikes instantly by $200\times$ . During these events, the ALB drops connections during the first five minutes of the traffic spike. Concurrently, the compute nodes experience severe write latency and CPU underutilization because the default EBS gp3 volumes ( $100\text{ GiB}$ ) cannot keep up with the I/O throughput required for the intermediate scratch files.

Which two actions should the Solutions Architect take to resolve these bottlenecks? (Select TWO.)

Select all that apply

Contact AWS Support to pre-warm the Application Load Balancer with the expected request rate and payload size before the market opens.

Migrate the compute instances to an instance store-enabled family and configure the application to write transient scratch files to the local NVMe storage.

Configure a target tracking scaling policy on the Auto Scaling group using the ALBRequestCountPerTarget metric to dynamically scale the load balancer and backend capacity.

Enable Multi-AZ on an Amazon RDS for PostgreSQL instance and route read queries for the data models to the standby instance endpoint.

Configure the Auto Scaling group scale-out policies with a cooldown period of

10\text{ seconds}

to rapidly provision new EC2 instances during the traffic spike.

Show answer & explanation

Answer: Contact AWS Support to pre-warm the Application Load Balancer with the expected request rate and payload size before the market opens.; Migrate the compute instances to an instance store-enabled family and configure the application to write transient scratch files to the local NVMe storage.

Answer

Contact AWS Support to pre-warm the Application Load Balancer with the expected request rate and payload size before the market opens, and migrate the compute instances to an instance store-enabled family to write transient scratch files to the local NVMe storage.

Pre-warming the Application Load Balancer prepares the load balancer infrastructure to handle the sudden

200\times

traffic spike without dropping packets or requests. Migrating the instances to an instance store-enabled family provides dedicated local NVMe storage, which delivers the sub-millisecond latency and high IOPS required for the compute fleet's transient scratch files, resolving the storage bottleneck.

Step-by-Step Solution

Analyze the load balancer performance during rapid traffic spikes.

Standard Application Load Balancers scale dynamically but reactively. An instantaneous

200\times

traffic spike will overwhelm the balancer before it can scale, leading to dropped connections.

AWS Support must pre-warm the ALB to handle predictable, sudden flash spikes.

Assess the performance characteristics of the local scratch storage.

The EBS gp3 volumes configured with default settings are limited to 3,000 IOPS and 125 MB/s, causing high write latency and CPU underutilization during simulation runs.

Transient scratch space requires high-performance, low-latency disk storage. Moving to instance store-enabled EC2 instances provides local NVMe storage that easily handles these I/O requirements.

Evaluate and eliminate incorrect scaling and database options.

Target tracking scaling is too slow for instantaneous spikes. RDS Multi-AZ standbys cannot serve read traffic. Extremely short cooldown periods (e.g.,

10\text{ seconds}

) lead to duplicate scaling actions before instances are fully bootstrapped.

Ensures the solution avoids common architectural misconceptions regarding database replication and Auto Scaling cooldown configurations.

Key Concept

Optimizing compute scaling for flash traffic and utilizing high-performance local instance store for transient write workloads.

Alternative Method

Instead of pre-warming the ALB manually, if the traffic spike is predictable and occurs at a precise time daily, a Scheduled Scaling policy can be configured on the Auto Scaling group to scale out the EC2 instances in advance, though the ALB itself must still be pre-warmed by AWS Support if the spike is extremely large and sudden.

Estimated Time:3m 0s

Question 1092Question →

A logistics enterprise runs a real-time fleet tracking and route optimization application. The core system operates in the us-west-2 Region. The architecture consists of a shared services VPC hosting a latency-critical Kafka ingestion cluster, and ten regional ingestion VPCs in the same region. The regional VPCs receive continuous GPS telemetry from millions of IoT gateway devices over the internet, preprocess the messages on EC2 fleets, and forward them to the Kafka cluster.

Currently, all inter-VPC traffic is routed through a central AWS Transit Gateway. The telemetry preprocessing nodes experience frequent packet drops and microsecond latency spikes during peak hours, violating the strict sub-10ms data ingestion SLA. Additionally, the telemetry nodes fail to resolve the private DNS names of the Kafka brokers, which are defined in a Route 53 Private Hosted Zone (PHZ) in the shared services VPC. Outbound traffic to the on-premises database for metadata enrichment is routed via a single NAT Gateway in the shared services VPC.

The enterprise requires a solution that minimizes inter-VPC latency, ensures maximum throughput, maintains high availability for database enrichment routing, and resolves the DNS resolution failures.

Which of the following actions should the Solutions Architect recommend?

Peer the regional ingestion VPCs directly with the shared services VPC to bypass the Transit Gateway. Rely on a Route 53 Resolver inbound endpoint in the shared services VPC to handle DNS resolution from the regional VPCs without associating the Private Hosted Zone with them. Deploy a NAT Gateway in each Availability Zone of the shared services VPC.

Peer the regional ingestion VPCs directly with the shared services VPC to bypass the Transit Gateway, enabling Jumbo Frames (9001-byte MTU) for the data ingestion traffic. Associate the Kafka Private Hosted Zone with all regional VPCs. Keep the single NAT Gateway in the shared services VPC but configure routing tables in all Availability Zones to point to it.

Peer the regional ingestion VPCs directly with the shared services VPC to bypass the Transit Gateway, enabling Jumbo Frames (9001-byte MTU) for the data ingestion traffic. Associate the Kafka Private Hosted Zone with all regional VPCs. Deploy a NAT Gateway in each Availability Zone of the shared services VPC to provide highly available outbound routes.

Establish a centralized AWS Direct Connect Gateway and configure it to route transitive traffic directly between the regional VPCs and the shared services VPC, bypassing both Transit Gateway and VPC Peering. Associate the Kafka Private Hosted Zone with the Direct Connect Gateway. Deploy a NAT Gateway in each Availability Zone of the shared services VPC.

Show answer & explanation

Answer: Peer the regional ingestion VPCs directly with the shared services VPC to bypass the Transit Gateway, enabling Jumbo Frames (9001-byte MTU) for the data ingestion traffic. Associate the Kafka Private Hosted Zone with all regional VPCs. Deploy a NAT Gateway in each Availability Zone of the shared services VPC to provide highly available outbound routes.

Answer

Peer the regional ingestion VPCs directly with the shared services VPC to bypass the Transit Gateway, enabling Jumbo Frames (9001-byte MTU) for the data ingestion traffic. Associate the Kafka Private Hosted Zone with all regional VPCs. Deploy a NAT Gateway in each Availability Zone of the shared services VPC to provide highly available outbound routes.

The correct answer optimizes latency and throughput by establishing direct VPC Peering connections, which bypasses the Transit Gateway hop and enables Jumbo Frames (9001-byte MTU) for same-region traffic. It also correctly resolves DNS by associating the Route 53 Private Hosted Zone with all regional VPCs and ensures high availability for outbound traffic by deploying a NAT Gateway in each Availability Zone of the shared services VPC.

Step-by-Step Solution

Replace the Transit Gateway path for inter-VPC ingestion traffic with direct VPC Peering connections between the regional VPCs and the shared services VPC.

Bypasses the Transit Gateway processing overhead (reducing latency by 1-2 ms) and enables Jumbo Frames (9001-byte MTU) to maximize throughput and prevent packet fragmentation.

Intra-region VPC Peering supports up to 9001-byte MTU, whereas Transit Gateway supports up to 8500-byte MTU and introduces processing latency.

Associate the Route 53 Private Hosted Zone (PHZ) created in the shared services VPC with each of the ten regional ingestion VPCs.

Enables resources within the regional VPCs to successfully resolve the private DNS names of the Kafka brokers.

Route 53 Private Hosted Zones are isolated by default and must be explicitly associated with any VPC that requires name resolution for the zone.

Deploy a NAT Gateway in each Availability Zone of the shared services VPC and configure the private subnet route tables to direct outbound 0.0.0.0/0 traffic to the local NAT Gateway in the same zone.

Ensures that outbound traffic to the on-premises database for metadata enrichment is highly available and resilient to Availability Zone failures.

A single NAT Gateway presents a single point of failure for multi-AZ architectures. Redundant NAT Gateways ensure high availability.

Key Concept

Optimizing multi-VPC latency and throughput involves using direct VPC Peering to leverage Jumbo Frames (9001-byte MTU) and bypass Transit Gateway hops, coupled with proper Private Hosted Zone association for DNS resolution and redundant NAT Gateways for outbound path resilience.

Estimated Time:3m 0s

Question 1093Question →

A smart grid IoT SaaS provider collects real-time power grid telemetry from millions of sensors. The ingestion tier runs on Amazon EC2 instances in an Ingestion VPC, and the analytics processing tier runs in a separate Processing VPC within the same AWS Region. Currently, the VPCs are connected via an AWS Transit Gateway. During peak demand, the processing tier experiences latency spikes and packet drops when retrieving large payload batches of $9000$ bytes from the ingestion tier. Additionally, the processing instances resolve the ingestion tier's service endpoint using public DNS, which routes the traffic through NAT Gateways. The provider requires a solution that minimizes latency, maximizes throughput, and eliminates unnecessary data transfer costs. Which two actions should the Solutions Architect take to meet these requirements?

Select all that apply

Establish a VPC Peering connection between the Ingestion VPC and the Processing VPC, update the route tables to route traffic over the peering connection, and configure the EC2 instances in both VPCs to use a maximum transmission unit (MTU) of

9001

bytes.

Associate the Route 53 Private Hosted Zone that contains the private DNS records for the ingestion service with the Processing VPC, allowing the processing instances to resolve the service directly to its private IP addresses.

Modify the Transit Gateway route tables to route the inter-VPC traffic through a Direct Connect Gateway connected to an on-premises virtual router to manage transitive routing paths at high speeds.

Request AWS Support to pre-warm the Application Load Balancers in the Ingestion VPC to handle the peak traffic volume, and configure the processing instances to access the ingestion service using the load balancer's public DNS name.

Deploy redundant NAT Gateways across multiple Availability Zones in the Processing VPC, and route all inter-VPC traffic destined for the Ingestion VPC through these NAT Gateways to leverage their

100\text{ Gbps}

bandwidth capacity.

Show answer & explanation

Answer: Establish a VPC Peering connection between the Ingestion VPC and the Processing VPC, update the route tables to route traffic over the peering connection, and configure the EC2 instances in both VPCs to use a maximum transmission unit (MTU) of $9001$ bytes.; Associate the Route 53 Private Hosted Zone that contains the private DNS records for the ingestion service with the Processing VPC, allowing the processing instances to resolve the service directly to its private IP addresses.

Answer

Establishing a VPC Peering connection with an MTU of

9001

bytes and associating the Route 53 Private Hosted Zone with the Processing VPC.

Establishing a VPC Peering connection within the same region allows network packets to use Jumbo Frames with an MTU of

9001

bytes, preventing the fragmentation of

9000

-byte payloads that occurs over Transit Gateway attachments (which are capped at

8500

bytes). Additionally, associating the Route 53 Private Hosted Zone with the Processing VPC ensures that DNS queries for the ingestion service resolve to private IP addresses rather than public IPs, eliminating the need to route traffic through NAT Gateways, which reduces both latency and data processing charges.

Step-by-Step Solution

Analyze the MTU constraints of the current network transit path.

AWS Transit Gateway VPC attachments support a maximum MTU of

8500

bytes. Payloads of

9000

bytes will be fragmented or dropped, leading to latency and packet loss.

Establishing a direct VPC Peering connection allows for an MTU of

9001

bytes (Jumbo Frames) within the same region, preventing packet fragmentation.

Examine the DNS resolution and path for inter-VPC traffic.

Processing instances are currently resolving the ingestion endpoint using public DNS, which routes traffic via NAT Gateways, increasing latency and data processing costs.

By associating the Route 53 Private Hosted Zone with the Processing VPC, the processing instances resolve the ingestion service directly to its private IPs, keeping traffic within the private network.

Key Concept

Inter-VPC performance optimization using VPC Peering for Jumbo Frames (MTU

9001

) and private DNS resolution with Route 53 Private Hosted Zones.

Estimated Time:2m 0s

Question 1094Question →

A company runs a high-volume financial transaction application on Amazon EC2 instances within an Auto Scaling group (ASG) distributed across three Availability Zones ( $AZ-1$ , $AZ-2$ , and $AZ-3$ ). The instances reside in private subnets and must connect to external payment APIs to process requests. All private subnets currently route internet-bound traffic through a single NAT Gateway located in a public subnet in $AZ-1$ . The application requires exactly $7$ minutes to bootstrap, initialize caches, and pass Application Load Balancer (ALB) health checks. During sudden, unscheduled traffic surges, the application experiences two main failures: first, the ALB drops requests and returns 503 errors before the ASG can scale; second, the ASG continuously launches new instances in rapid succession, resulting in severe over-provisioning and the premature termination of active instances. Additionally, a recent localized utility outage in $AZ-1$ disabled the single NAT Gateway, which halted all outbound payment processing for instances running in $AZ-2$ and $AZ-3$ .

Which TWO actions should the Solutions Architect take to resolve these issues while ensuring maximum fault tolerance and scaling efficiency?

Select all that apply

Deploy a dedicated NAT Gateway in the public subnet of each Availability Zone, and update the route tables of the private subnets in each zone to point outbound

0.0.0.0/0

traffic to the NAT Gateway in their respective zone.

Modify the Auto Scaling group scaling policies to use target tracking and set the instance warmup duration to

480

seconds.

Reduce the default cooldown period of the Auto Scaling group to

300

seconds to allow scaling policies to execute more rapidly during sudden peaks.

Deploy an additional NAT Gateway in

AZ-2

, and update the route tables of private subnets in both

AZ-2

and

AZ-3

to point outbound

0.0.0.0/0

traffic to this new NAT Gateway to distribute outbound NAT traffic.

Submit a ticket to AWS Support to request permanent pre-warming of the Application Load Balancer to its maximum anticipated capacity to absorb unscheduled traffic surges.

Show answer & explanation

Answer: Deploy a dedicated NAT Gateway in the public subnet of each Availability Zone, and update the route tables of the private subnets in each zone to point outbound $0.0.0.0/0$ traffic to the NAT Gateway in their respective zone.; Modify the Auto Scaling group scaling policies to use target tracking and set the instance warmup duration to $480$ seconds.

Answer

Deploy a dedicated NAT Gateway in the public subnet of each Availability Zone, and update the route tables of the private subnets in each zone to point outbound traffic to the local NAT Gateway. Additionally, configure the Auto Scaling group to use target tracking and set the instance warmup duration to

480

seconds.

The correct options are deploying a dedicated NAT Gateway in the public subnet of each Availability Zone and modifying the Auto Scaling group to set the instance warmup duration to

480

seconds. Deploying a NAT Gateway in each Availability Zone ensures high availability and fault tolerance, isolating failures to a single zone. Setting the instance warmup duration to

480

seconds (

8

minutes) ensures that the Auto Scaling group waits for the newly launched instances to fully initialize (which takes

7

minutes) before evaluating capacity metrics again, resolving the over-provisioning loop.

Step-by-Step Solution

Analyze the NAT Gateway architecture for single points of failure.

Identify that routing all outbound traffic from private subnets across three Availability Zones to a single NAT Gateway in

AZ-1

creates a single point of failure.

To build a fault-tolerant architecture, we must eliminate single points of failure. Deploying a NAT Gateway in each AZ ensures local outbound routing remains active even if one AZ experiences an outage.

Address the Auto Scaling over-provisioning issue related to instance initialization time.

Determine that the application requires

7

minutes (

420

seconds) to pass health checks, which means any warmup or cooldown period less than

420

seconds will cause the ASG to scale out repeatedly before the first batch of instances can handle the load.

Increasing the instance warmup duration to a value greater than the bootstrap time (e.g.,

480

seconds) ensures that the scaling policy ignores newly launched instances for metrics aggregation until they are ready to handle traffic, preventing over-provisioning.

Evaluate options for managing Application Load Balancer scaling and pre-warming.

Confirm that ALBs scale dynamically but cannot be pre-warned permanently for unscheduled spikes. Instead, scaling policies must be configured with appropriate metrics and warmup times to handle normal scaling, while utilizing caching or queuing to absorb instantaneous shock loads if necessary.

This rules out permanent pre-warming requests to AWS Support as a viable architectural solution.

Key Concept

Designing multi-AZ fault tolerance for NAT Gateways and configuring Auto Scaling group cooldown and warmup periods to align with application bootstrapping latency.

Question 1095Question →

A company hosts a read-heavy web application on Amazon EC2 instances in an Auto Scaling group behind an Application Load Balancer (ALB). The application layer is backed by an Amazon RDS for MySQL Multi-AZ DB instance, and the EC2 instances use attached Amazon EBS gp3 volumes to cache static assets. The company expects traffic to spike tenfold in less than 5 minutes due to a promotional event. Which two actions should a solutions architect recommend to optimize compute and storage performance, and ensure the system can handle the sudden surge?

Select all that apply

Deploy Amazon RDS Read Replicas and modify the application to route read-heavy database queries to the read replica endpoints.

Increase the provisioned IOPS and throughput on the existing EBS gp3 volumes to accommodate the higher read-intensive local storage demands.

Configure the application to route read-heavy database queries to the standby DB instance of the RDS Multi-AZ deployment to balance the query load.

Rely on the Application Load Balancer's default auto-scaling behavior to dynamically allocate compute capacity during the sudden traffic spike.

Purchase EC2 Instance Savings Plans to optimize compute costs for both the scaling EC2 instances and the application's auxiliary AWS Fargate tasks.

Show answer & explanation

Answer: Deploy Amazon RDS Read Replicas and modify the application to route read-heavy database queries to the read replica endpoints.; Increase the provisioned IOPS and throughput on the existing EBS gp3 volumes to accommodate the higher read-intensive local storage demands.

Answer

Deploy Amazon RDS Read Replicas and route read traffic to them, and increase the provisioned IOPS and throughput on the existing EBS gp3 volumes.

Deploying Amazon RDS Read Replicas allows horizontal scaling of the read-heavy database workload, while increasing the provisioned IOPS and throughput on the existing EBS gp3 volumes directly optimizes storage performance without requiring volume resizing or system downtime.

Step-by-Step Solution

Analyze the database workload bottlenecks under a tenfold traffic increase.

Identify that the primary database is a read-heavy RDS MySQL Multi-AZ deployment. Since the standby replica in RDS Multi-AZ cannot serve read traffic, horizontal scaling must be achieved by deploying RDS Read Replicas.

This offloads read operations from the primary DB instance, preventing CPU and memory exhaustion.

Evaluate the local storage performance characteristics of the EC2 instances.

Identify that EBS gp3 volumes are used for read-intensive static session assets. These volumes support independent configuration of IOPS and throughput.

Provisioning higher IOPS and throughput directly on gp3 volumes prevents storage I/O bottlenecks during the flash sale without the need to increase volume capacity or cause downtime.

Address the rapid network/compute traffic scaling requirements at the load balancing tier.

Recognize that a tenfold spike within 5 minutes is too rapid for default ALB auto-scaling, requiring pre-warming or scheduled scaling.

This ensures the ALB has the capacity provisioned beforehand, preventing HTTP 503 errors and dropped connections.

Key Concept

Scaling read-heavy database workloads with RDS Read Replicas, optimizing EBS gp3 performance independently of volume size, and understanding ALB scaling limitations under sudden spikes.

Question 1096Question →

An enterprise runs a data processing application on Amazon EC2 instances in an application VPC within Account A. The application needs to retrieve daily encrypted logs from an Amazon S3 bucket located in Account B. The data transfer must be highly secure, must not traverse the public internet, and must enforce the principle of least privilege. The S3 bucket is currently encrypted using an AWS KMS key.

Which two actions should a Solutions Architect take to strengthen the identity, access, and network security for this data transfer?

Select all that apply

Create a gateway VPC endpoint for Amazon S3 in the application's VPC, and update the route tables to route S3 traffic through this endpoint. Update the S3 bucket policy in the security account to allow the application's IAM role to access the bucket, with a condition restricting requests to those originating from the S3 gateway VPC endpoint ID.

Configure the S3 bucket to use a customer managed KMS key. Update the KMS key policy in the security account to trust the application's account and grant the application's IAM role permission to perform decrypt and generate data key operations, and update the application's IAM policy to allow these same actions on the KMS key.

Configure the S3 bucket to use the default AWS managed KMS key (aws/s3). Update the application's IAM policy in the application account to allow the application's IAM role to perform decrypt and generate data key operations on the aws/s3 KMS key in the security account.

Create an internet gateway in the application's VPC and configure a public subnet. Deploy a NAT gateway in the public subnet, and route all S3 traffic through it. Update the S3 bucket policy in the security account to restrict access only to the Elastic IP address of the NAT gateway using the aws:SourceIp condition.

Use AWS Resource Access Manager (RAM) to share the S3 Gateway VPC Endpoint from the application account to the security account. Create a Service Control Policy (SCP) at the organizational unit (OU) level that permits the application's IAM role to access the S3 bucket directly, bypassing the need for local IAM policy updates.

Show answer & explanation

Answer: Create a gateway VPC endpoint for Amazon S3 in the application's VPC, and update the route tables to route S3 traffic through this endpoint. Update the S3 bucket policy in the security account to allow the application's IAM role to access the bucket, with a condition restricting requests to those originating from the S3 gateway VPC endpoint ID.; Configure the S3 bucket to use a customer managed KMS key. Update the KMS key policy in the security account to trust the application's account and grant the application's IAM role permission to perform decrypt and generate data key operations, and update the application's IAM policy to allow these same actions on the KMS key.

Answer

Creating an S3 gateway VPC endpoint in the application's VPC, updating the route tables, and restricting the bucket policy to the gateway VPC endpoint ID, while also using a customer managed KMS key with cross-account access granted via key and IAM policies.

To satisfy the security requirements of keeping traffic off the public internet and using least-privilege access: first, a gateway VPC endpoint is configured in the application's VPC to route S3 traffic internally. The S3 bucket policy is restricted using the aws:sourceVpce condition, ensuring that only requests coming through the VPC endpoint are allowed. Second, a Customer Managed KMS Key (CMK) is implemented because cross-account access to encrypted S3 resources requires a key policy that explicitly trusts the external account, which is not possible with AWS-managed keys.

Step-by-Step Solution

Set up a gateway VPC endpoint for S3 in the application VPC (Account A) and update the route tables to route all S3 traffic through the endpoint.

Network traffic to S3 is kept entirely within the AWS network, satisfying the constraint of not traversing the public internet.

This establishes a private network path to S3 and avoids public internet exposure.

Configure the S3 bucket policy in Account B to permit access to the IAM role in Account A only when the aws:sourceVpce condition matches the gateway VPC endpoint ID created in Account A.

Access is restricted to requests coming strictly from the authorized VPC endpoint.

This enforces least-privilege network constraints at the S3 resource layer.

Configure the S3 bucket in Account B to use a Customer Managed Key (CMK) instead of the AWS managed key (aws/s3).

The key policy can now be customized to support cross-account operations.

AWS managed KMS keys do not support policy modification to allow cross-account access.

Update the Customer Managed KMS key policy in Account B to grant permission to the external Account A principal, and update the application's IAM policy in Account A to permit the role to perform kms:Decrypt and kms:GenerateDataKey.

The application's IAM role is authorized to decrypt the objects retrieved from S3.

Both key policy (in Account B) and IAM policy (in Account A) must grant the permissions for cross-account KMS usage to succeed.

Key Concept

Securing cross-account resource access in a multi-account environment using gateway VPC endpoints, custom S3 bucket policies with endpoint conditions, and Customer Managed Keys for cross-account KMS decryption.

Estimated Time:3m 0s

Question 1097Question →

A financial services corporation is designing a new payment processing system across two AWS regions: `us-east-1` (Primary) and `us-west-2` (Secondary). In each region, they have deployed a production VPC (`VPC-Prod-US1` and `VPC-Prod-US2` respectively) and a shared services VPC (`VPC-Shared-US1` and `VPC-Shared-US2`). The company has two on-premises data centers connected to AWS via separate $10\text{ Gbps}$ AWS Direct Connect connections terminating at different Direct Connect locations.

The architecture must satisfy the following design constraints:
1. Production VPCs in both regions must communicate with each other privately with low latency and high throughput.
2. Both on-premises data centers must have redundant, dynamically routed network paths to reach VPCs in both AWS regions.
3. Applications in the production VPCs must resolve private DNS names in a Route 53 Private Hosted Zone (PHZ) hosted in `VPC-Shared-US1`, as well as on-premises DNS records.
4. Outbound internet traffic from `VPC-Prod-US1` must be centralized through `VPC-Shared-US1` for security inspection, ensuring no single point of failure across Availability Zones.

Which of the following configurations should the solutions architect implement to meet all requirements?

Deploy an AWS Transit Gateway (TGW) in each region (TGW-US1 and TGW-US2) and peer them. Associate local VPCs with their respective TGWs. Associate a Direct Connect Gateway (DXGW) with TGW-US1 and TGW-US2. To resolve private DNS records, configure a Route 53 Resolver Inbound Endpoint in VPC-Shared-US1 and an Outbound Endpoint in VPC-Shared-US2, relying on the peered TGW paths to implicitly resolve hostnames in the Private Hosted Zone (PHZ) associated with VPC-Shared-US1. Deploy redundant NAT Gateways across multiple Availability Zones in VPC-Shared-US1, routing outbound VPC-Prod-US1 traffic through TGW-US1 to these NAT Gateways.

Deploy an AWS Transit Gateway (TGW) in each region (TGW-US1 and TGW-US2) and peer them. Associate local VPCs with their respective TGWs. Associate a Direct Connect Gateway (DXGW) with TGW-US1 and TGW-US2. For DNS resolution, create cross-account VPC association authorizations to associate the Shared VPC's Private Hosted Zone (PHZ) with VPC-Prod-US1 and VPC-Prod-US2, and share Route 53 Resolver Outbound rules via AWS RAM. Deploy a single NAT Gateway in VPC-Shared-US1's primary Availability Zone to minimize ongoing NAT processing costs, and configure VPC-Prod-US1 route tables in all Availability Zones to route outbound internet traffic through TGW-US1 to this single NAT Gateway.

Deploy an AWS Transit Gateway (TGW) in each region (TGW-US1 and TGW-US2) and peer them. Associate local VPCs with their respective TGWs. Associate a Direct Connect Gateway (DXGW) with TGW-US1 and TGW-US2. Create cross-account VPC association authorizations to associate the Private Hosted Zone (PHZ) owned by VPC-Shared-US1 with VPC-Prod-US1 and VPC-Prod-US2. Set up Route 53 Resolver Outbound Endpoints in the Shared VPCs to forward on-premises DNS queries, and share the rules with the Production VPCs using AWS Resource Access Manager (RAM). Deploy redundant NAT Gateways across multiple Availability Zones in VPC-Shared-US1, and route outbound VPC-Prod-US1 traffic through TGW-US1 to these NAT Gateways.

Deploy a Direct Connect Gateway (DXGW) and associate it directly with VPC-Prod-US1, VPC-Shared-US1, VPC-Prod-US2, and VPC-Shared-US2 to handle hybrid routing. Connect VPC-Prod-US1 and VPC-Prod-US2 via an Inter-Region VPC Peering connection to facilitate cross-region communication. Create cross-account VPC association authorizations to associate the PHZ owned by VPC-Shared-US1 with all VPCs. Set up Route 53 Resolver Inbound Endpoints in VPC-Shared-US1 to handle all outbound on-premises DNS resolution, and deploy a single NAT Gateway in VPC-Shared-US1 to handle egress traffic routed over the VPC peering connection.

Show answer & explanation

Answer: Deploy an AWS Transit Gateway (TGW) in each region (TGW-US1 and TGW-US2) and peer them. Associate local VPCs with their respective TGWs. Associate a Direct Connect Gateway (DXGW) with TGW-US1 and TGW-US2. Create cross-account VPC association authorizations to associate the Private Hosted Zone (PHZ) owned by VPC-Shared-US1 with VPC-Prod-US1 and VPC-Prod-US2. Set up Route 53 Resolver Outbound Endpoints in the Shared VPCs to forward on-premises DNS queries, and share the rules with the Production VPCs using AWS Resource Access Manager (RAM). Deploy redundant NAT Gateways across multiple Availability Zones in VPC-Shared-US1, and route outbound VPC-Prod-US1 traffic through TGW-US1 to these NAT Gateways.

Answer

The correct configuration is to deploy Transit Gateways in both regions, peer them, and associate them with a Direct Connect Gateway for hybrid routing. Explicitly associate the Private Hosted Zone with the production VPCs using cross-account authorizations, deploy Route 53 Resolver Outbound Endpoints shared via AWS Resource Access Manager, and deploy redundant NAT Gateways across multiple Availability Zones in the shared services VPC for centralized egress.

The correct configuration utilizes peered AWS Transit Gateways across regions to connect the VPCs, and associates them with a Direct Connect Gateway for hybrid connectivity. For DNS resolution, it correctly uses cross-account VPC association authorizations to associate the Private Hosted Zone with the production VPCs in both regions, allowing them to resolve internal names. It also deploys Route 53 Resolver Outbound Endpoints in the shared VPCs and shares forwarding rules via AWS RAM to resolve on-premises records. Finally, to ensure high availability for outbound traffic without a single point of failure, it deploys redundant NAT Gateways across multiple Availability Zones in the shared services VPC and routes internet-bound traffic through the Transit Gateway to those NAT Gateways.

Step-by-Step Solution

Configure hybrid and inter-region network routing.

Transit Gateways are peered between regions, local VPCs are attached to local Transit Gateways, and a Direct Connect Gateway is associated with both Transit Gateways to provide redundant path routing via BGP.

This satisfies the requirements for private, high-throughput, low-latency communication between the regions and provides redundant hybrid paths to on-premises data centers.

Set up DNS resolution for the Private Hosted Zone (PHZ).

Use cross-account VPC association authorizations from the shared services account to authorize and associate the PHZ with the production VPCs in both regions.

VPCs cannot resolve records in a PHZ unless the PHZ is explicitly associated with them. Peering or Transit Gateway connectivity does not propagate DNS resolution transitively.

Configure hybrid DNS query forwarding.

Deploy Route 53 Resolver Outbound Endpoints in the Shared VPCs, configure forwarding rules pointing to on-premises DNS servers, and share the rules using AWS Resource Access Manager (RAM).

This allows production VPCs to resolve on-premises domain names through the outbound endpoints via the Direct Connect paths.

Implement resilient centralized egress.

Deploy a NAT Gateway in each Availability Zone of VPC-Shared-US1. Point the route tables of VPC-Prod-US1 to route internet traffic to TGW-US1, which routes it to VPC-Shared-US1, where it is routed to the zone-local NAT Gateways.

This ensures that egress internet traffic is inspected centrally and remains highly available without a single point of failure in any single Availability Zone.

Key Concept

Multi-region hybrid networking design combining Transit Gateway peering, Direct Connect Gateway routing, cross-account Route 53 Private Hosted Zone association, and highly available centralized NAT gateway routing.

Estimated Time:3m 0s

Question 1098Question →

A logistics company operates a fleet tracking application across multiple AWS accounts within an AWS Organization. The primary application tier runs in the `us-west-2` region under Account A (Production), and an active-passive disaster recovery (DR) environment is established in `us-east-1` under Account B (Disaster Recovery). The database layer uses Amazon Aurora PostgreSQL. The application servers, hosted on Amazon EC2 instances in private subnets across $3$ Availability Zones, depend on an internal API gateway deployed in a shared services VPC in Account C (Shared Services). This internal dependency is resolved privately using a Route $53$ Private Hosted Zone (PHZ) hosted in Account C.

During a disaster recovery simulation, the following issues were documented:
1. Outbound telemetry data transmission to external APIs failed when a single Availability Zone (AZ) in `us-west-2` experienced an outage, because all private subnets were routing internet-bound traffic through a single NAT Gateway located in that AZ.
2. When the primary database was manually stopped to simulate a regional failure, client traffic was not redirected to `us-east-1` because the Route $53$ failover routing policy was monitoring the Application Load Balancer (ALB) health, which remained healthy as the web servers were still running and returning a $200$ OK status.
3. After database failover to `us-east-1` was forced, the application servers in Account B failed to resolve the internal API gateway domain hosted in Account C.

Which set of actions will resolve these issues while meeting a target Recovery Time Objective (RTO) of $15$ minutes and a Recovery Point Objective (RPO) of $1$ minute?

Configure Amazon Aurora Global Database with the primary cluster in `us-west-2` and a secondary cluster in `us-east-1`. Deploy a NAT Gateway in each Availability Zone of the VPCs in both Account A and Account B. Create a Route

53

health check targeting a custom deep health check endpoint on the application that actively queries the database. Authorize the Account B VPC to associate with the Account C Private Hosted Zone by running the `create-vpc-association-authorization` command from Account C, and then associate the VPC from Account B.

Implement a backup plan using AWS Backup to copy Aurora snapshots from Account A to Account B every

12

hours. Deploy a single NAT Gateway in each VPC to minimize idle resource costs. Create a Route

53

health check targeting the ALB's default DNS name. Share the Route

53

Private Hosted Zone from Account C with Account B using AWS Resource Access Manager, then associate the VPC in Account B.

Configure Amazon Aurora Global Database with the primary cluster in `us-west-2` and a secondary cluster in `us-east-1`. Deploy a single NAT Gateway in a shared public subnet in each region to route all egress traffic. Set up a Route

53

health check targeting a custom deep health check endpoint that queries the database. Establish a VPC peering connection between Account B and Account C to enable private resolution of the internal API gateway domain without associating the Private Hosted Zone.

Configure Amazon Aurora Global Database with the primary cluster in `us-west-2` and a secondary cluster in `us-east-1`. Deploy a NAT Gateway in each Availability Zone of both VPCs. Configure Route

53

failover records using the ALB's default health check. Create an inbound Route

53

Resolver endpoint in Account C and associate the Private Hosted Zone with the Account B VPC directly from the Account B AWS Management Console without cross-account authorization.

Show answer & explanation

Answer: Configure Amazon Aurora Global Database with the primary cluster in `us-west-2` and a secondary cluster in `us-east-1`. Deploy a NAT Gateway in each Availability Zone of the VPCs in both Account A and Account B. Create a Route $53$ health check targeting a custom deep health check endpoint on the application that actively queries the database. Authorize the Account B VPC to associate with the Account C Private Hosted Zone by running the `create-vpc-association-authorization` command from Account C, and then associate the VPC from Account B.

Answer

The correct option is the one that configures Amazon Aurora Global Database, deploys a NAT Gateway in each Availability Zone of the VPCs, utilizes a custom deep health check endpoint to monitor database connectivity, and establishes the cross-account Private Hosted Zone association using the Route

53

VPC association authorization workflow.

The correct option addresses all three failure scenarios according to AWS best practices: it uses Amazon Aurora Global Database to achieve the required

1

minute RPO and

15

minutes RTO; it secures egress high availability by placing a NAT Gateway in each Availability Zone; it monitors application health holistically with a deep health check; and it correctly follows the cross-account Private Hosted Zone association API workflow.

Step-by-Step Solution

Address database replication requirements.

Configure Amazon Aurora Global Database spanning `us-west-2` and `us-east-1`.

Aurora Global Database provides sub-second RPO and promotes a secondary region in under

1

minute, satisfying the target RPO of

1

minute and RTO of

15

minutes.

Ensure egress connectivity reliability.

Deploy a NAT Gateway in each Availability Zone containing private subnets in both Account A and Account B.

This removes the single point of failure where an Availability Zone outage could disable internet egress for the remaining zones.

Configure DNS-level failover monitoring.

Create a Route

53

health check targeting an application endpoint that performs a database query.

A shallow load balancer health check only verifies that the web/app servers are responding, failing to detect database outages. A deep health check ensures failover triggers when the database is unreachable.

Establish cross-account DNS resolution.

Execute `create-vpc-association-authorization` in Account C for the Account B VPC, then run `associate-vpc-with-hosted-zone` in Account B.

Private Hosted Zones must be explicitly associated with consumer VPCs across different accounts, requiring an authorization step from the zone's owner account.

Key Concept

Multi-region disaster recovery coordination involving database replication, redundant network egress paths, deep application health checks, and secure cross-account private DNS hosting.

Estimated Time:3m 0s

Question 1099Question →

An enterprise is launching a new platform in the us-east-1 Region across three AWS accounts. The network architecture consists of a production application VPC (vpc-production-app) running workloads in private subnets across three Availability Zones, a PCI-compliant payment processing VPC (vpc-payment-processing) running workloads in private subnets across two Availability Zones, and a shared egress VPC (vpc-shared-egress) containing NAT Gateways and AWS Network Firewall endpoints. Outbound internet access from the application and payment VPCs must be routed through the central firewall in vpc-shared-egress. The latency between vpc-production-app and vpc-payment-processing must be minimized, and data transfer costs must be optimized by keeping direct VPC-to-VPC traffic off the Transit Gateway. Finally, all VPCs must resolve DNS records in a Route 53 Private Hosted Zone (PHZ) named corp.internal hosted in a centralized services AWS account. The entire architecture must remain resilient to Availability Zone failures.

Which two design strategies should the Solutions Architect implement to meet these requirements? (Select TWO.)

Select all that apply

Establish a VPC Peering connection directly between vpc-production-app and vpc-payment-processing for local VPC-to-VPC traffic. Create a Transit Gateway (TGW) and attach all three VPCs. Route all outbound internet traffic (0.0.0.0/0) from the spoke VPCs to the TGW, which forwards it to the vpc-shared-egress VPC.

Enable DNS support and DNS hostnames in all three VPCs. Authorize and associate the Route 53 Private Hosted Zone corp.internal in the central services account with the VPCs in the application and payment processing accounts, allowing native cross-account resolution via the default VPC Route 53 Resolver.

Deploy a single NAT Gateway in one Availability Zone of the vpc-shared-egress VPC, and route all outbound internet traffic (0.0.0.0/0) from both spoke VPCs to this NAT Gateway using a shared Transit Gateway route table to minimize NAT gateway hourly charges.

Associate a single Direct Connect Gateway with both vpc-production-app and vpc-payment-processing to route VPC-to-VPC traffic directly between them, bypassing the Transit Gateway and optimizing internal data transfer costs.

Configure Route 53 Resolver inbound and outbound endpoints in each of the three VPCs, and create Route 53 forwarding rules pointing to the central services account's resolver to resolve queries for the corp.internal domain.

Show answer & explanation

Answer: Establish a VPC Peering connection directly between vpc-production-app and vpc-payment-processing for local VPC-to-VPC traffic. Create a Transit Gateway (TGW) and attach all three VPCs. Route all outbound internet traffic (0.0.0.0/0) from the spoke VPCs to the TGW, which forwards it to the vpc-shared-egress VPC.; Enable DNS support and DNS hostnames in all three VPCs. Authorize and associate the Route 53 Private Hosted Zone corp.internal in the central services account with the VPCs in the application and payment processing accounts, allowing native cross-account resolution via the default VPC Route 53 Resolver.

Answer

Establish a VPC Peering connection directly between the production application VPC and the payment processing VPC for local VPC-to-VPC traffic, and route outbound internet traffic through a Transit Gateway to the shared egress VPC. In addition, enable DNS support and DNS hostnames, and associate the central services Private Hosted Zone with the application and payment VPCs.

The correct strategy combines a direct VPC Peering connection to route low-latency, cost-optimized inter-spoke VPC traffic (bypassing the Transit Gateway processing fees) with a Transit Gateway to centralize all outbound internet egress through the centralized shared egress VPC. In addition, configuring cross-account Route 53 Private Hosted Zone associations directly with the consumer VPCs enables native, cost-free DNS resolution of the internal domain without the overhead of Resolver endpoints.

Step-by-Step Solution

Address direct VPC-to-VPC latency and cost constraints by establishing a direct VPC Peering connection between the production application VPC and the payment processing VPC.

Enables direct routing for local subnet traffic between the two VPCs, bypassing Transit Gateway data processing fees and minimizing latency.

Direct VPC Peering provides the lowest latency and is free for data transfer within the same Availability Zone, satisfying the requirement to keep direct inter-VPC traffic off the Transit Gateway.

Configure Transit Gateway attachments for the application, payment, and shared egress VPCs, and define a default route (0.0.0.0/0) in the spoke VPC route tables targeting the Transit Gateway.

Outbound internet traffic is centralized and directed to the shared egress VPC where it can be inspected by AWS Network Firewall and sent through multi-AZ NAT Gateways.

Satisfies the requirement for secure, centralized egress filtering via the firewall and NAT gateways while preserving Availability Zone resilience.

Establish cross-account DNS resolution by authorizing the central services account's Private Hosted Zone to be associated with the application and payment VPCs, then performing the association.

Allows resources in the spoke VPCs to natively resolve DNS queries for the internal domain using the standard AWS-provided DNS server (Route 53 Resolver at the .2 IP address).

Eliminates the cost and administrative overhead of creating Route 53 Resolver endpoints and forwarding rules, which would otherwise incur continuous hourly charges.

Key Concept

Multi-VPC hybrid and egress networking design, optimizing for latency and cost (avoiding Transit Gateway processing fees via VPC Peering), resilience (multi-AZ NAT Gateways), and cross-account DNS resolution using Route 53 Private Hosted Zone associations.

Question 1100Question →

A solutions architect is designing the database strategy for a new Online Transaction Processing (OLTP) workload. The application requires a relational database, automatic failover with a Recovery Time Objective (RTO) of less than 120 seconds, and horizontal scaling of read throughput to handle traffic spikes. Which of the following database configurations meet these requirements? (Select TWO.)

Select all that apply

Amazon Aurora MySQL with Aurora Replicas deployed across multiple Availability Zones

Amazon RDS for MySQL in a Multi-AZ deployment with one or more Read Replicas deployed in different Availability Zones

Amazon RDS for MySQL in a Multi-AZ deployment, using the standby replica to serve read traffic during peak periods

Amazon RDS for MySQL in a single-instance configuration, relying on automated daily snapshots to restore the database to a secondary Availability Zone during a failure

Amazon Aurora MySQL with cross-account Aurora Replicas encrypted using the default AWS-managed KMS key (aws/rds) to share data across accounts

Show answer & explanation

Answer: Amazon Aurora MySQL with Aurora Replicas deployed across multiple Availability Zones; Amazon RDS for MySQL in a Multi-AZ deployment with one or more Read Replicas deployed in different Availability Zones

Answer

The correct configurations are Amazon Aurora MySQL with Aurora Replicas deployed across multiple Availability Zones, and Amazon RDS for MySQL in a Multi-AZ deployment with one or more Read Replicas deployed in different Availability Zones.

Amazon Aurora MySQL native routing allows Aurora Replicas to serve read traffic while acting as hot standbys for automatic failover within 30 seconds. Amazon RDS for MySQL Multi-AZ deployments provide synchronous replication to a standby instance for automatic failover (RTO < 120 seconds), while separate Read Replicas are used to scale read traffic horizontally.

Step-by-Step Solution

Analyze the requirements for OLTP workload, relational engine, automatic failover with RTO < 120 seconds, and read scaling.

Identify that the solution must provide both high availability (active-passive failover) and read scalability (active-active read path).

This filters out single-instance setups and configurations that cannot scale reads.

Evaluate Amazon Aurora replication capabilities.

Confirm Aurora Replicas support both auto-failover (RTO < 30 seconds) and read scaling.

Aurora native architecture supports up to 15 Aurora Replicas sharing the same storage layer for read scaling and failover.

Evaluate standard Amazon RDS for MySQL replication capabilities.

Confirm standard RDS Multi-AZ provides synchronous replication and automatic failover (RTO 60-120 seconds), while separate Read Replicas provide horizontal read scaling.

Standard RDS standby instances cannot serve traffic, necessitating separate Read Replicas for scaling reads.

Key Concept

Distinguishing read scaling mechanisms and high availability architectures in Amazon RDS and Amazon Aurora.

PreviousPage 55 / 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

Alternative Method

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