All practice questions

1964 questions

All types1,964 Multiple choice1,006 Multiple select931 Ordering27

A logistics company is deploying a new shipping coordination platform on Amazon EC2 instances in a dedicated Production AWS account. The platform belongs to an AWS Organization. The Solutions Architect must design a logging solution that achieves the following:
1. Collects application transaction logs from the EC2 instances. The application writes logs to `/var/log/shipping/transaction.log`, which are rotated hourly and renamed with a timestamp suffix (e.g., `/var/log/shipping/transaction.log.2026-07-16-11`). These logs must be sent to Amazon CloudWatch Logs.
2. Tracks all API activity in the Production account and centralizes these logs in a secure Amazon S3 bucket located in a separate Audit AWS account within the organization.

An organizational trail has been configured in the management account to write logs to the central S3 bucket in the Audit account.

Which two configurations are required to ensure both application logs are correctly collected without data loss and API logs are successfully delivered to the Audit account? (Select TWO.)

Select all that apply

Configure the CloudWatch agent on the EC2 instances with the log file path set to `/var/log/shipping/transaction.log*` in the agent configuration file.

Apply an S3 bucket policy to the centralized S3 bucket in the Audit account that allows the `s3:PutObject` action, specifying `cloudtrail.amazonaws.com` as the Principal and containing a condition matching the AWS Organization ID.

Configure the CloudWatch agent on the EC2 instances with the log file path set to `/var/log/shipping/transaction.log` in the agent configuration file.

Apply an S3 bucket policy to the centralized S3 bucket in the Audit account that allows the `s3:PutObject` action, specifying the Production AWS account ID as the Principal.

Configure the centralized S3 bucket to use the default AWS-managed key `aws/s3` for server-side encryption to automatically encrypt the incoming log files from all organization accounts.

Show answer & explanation

Answer: Configure the CloudWatch agent on the EC2 instances with the log file path set to `/var/log/shipping/transaction.log*` in the agent configuration file.; Apply an S3 bucket policy to the centralized S3 bucket in the Audit account that allows the `s3:PutObject` action, specifying `cloudtrail.amazonaws.com` as the Principal and containing a condition matching the AWS Organization ID.

Answer

To collect the rotated application logs without data loss, the CloudWatch agent must be configured with a wildcard path (`/var/log/shipping/transaction.log*`). To allow cross-account organizational CloudTrail delivery, the S3 bucket policy must permit the `s3:PutObject` action to the `cloudtrail.amazonaws.com` service principal, restricted by the Organization ID.

The configuration using the wildcard path `/var/log/shipping/transaction.log*` is correct because it allows the CloudWatch agent to continue tracking and processing logs that have been rotated and renamed before delivery completes. The configuration applying an S3 bucket policy with `cloudtrail.amazonaws.com` as the principal and an Organization ID condition is correct because organizational trail log delivery is performed by the CloudTrail service principal, which needs explicit write access restricted to the organization's boundary.

Step-by-Step Solution

Address the log rotation requirement for the CloudWatch agent.

Identify that files rotated hourly and renamed with a timestamp suffix require a wildcard suffix in the CloudWatch agent configuration's `file_path` property to prevent data loss.

Without a wildcard, the agent will only monitor the active file and may miss log lines during the rotation process when the file is renamed.

Address the cross-account organizational trail delivery to the centralized S3 bucket.

Determine that the S3 bucket policy must grant write permissions to the AWS service principal `cloudtrail.amazonaws.com` and use the `aws:PrincipalOrgID` condition to restrict access to the organization.

CloudTrail writes logs as a service. Granting permission to individual member accounts' root ARNs or IDs as the Principal is incorrect and will block log delivery.

Verify KMS key and encryption constraints.

Ensure that if encryption is configured, it does not use the default AWS-managed KMS key since it cannot support cross-account policies.

Cross-account AWS services like CloudTrail writing to an encrypted bucket in another account require a customer managed key with custom key policy permissions.

Key Concept

To achieve operational excellence in multi-account logging, log agents must be configured to handle log rotation patterns with wildcards, and centralized storage buckets must utilize service-principal-based policies with organizational boundaries.

Question 1002Question →

A logistics tracking company has a dashboard that displays real-time delivery status updates. The backend database is an Amazon RDS for PostgreSQL DB instance. During peak hours, the database experiences high CPU utilization due to a surge in read queries for tracking information. The tracking data changes frequently, but the dashboard can tolerate slightly stale data. The company wants to improve database efficiency, reduce read load on the primary DB instance, and ensure that cached tracking status updates are replicated across multiple Availability Zones for high availability. Which TWO options should a Solutions Architect recommend to meet these requirements? (Select TWO.)

Select all that apply

Create an Amazon RDS read replica and configure the dashboard application to route read queries to it.

Configure an Amazon ElastiCache for Redis cluster with replication enabled across multiple Availability Zones to cache read queries.

Configure the application to route read queries to the standby instance of the existing Multi-AZ RDS deployment.

Deploy an Amazon ElastiCache for Memcached cluster to cache the tracking data and configure auto-replication across multiple Availability Zones.

Configure AWS Resource Access Manager (RAM) to share the database instance with external accounts to distribute the query load.

Show answer & explanation

Answer: Create an Amazon RDS read replica and configure the dashboard application to route read queries to it.; Configure an Amazon ElastiCache for Redis cluster with replication enabled across multiple Availability Zones to cache read queries.

Answer

To improve database efficiency and reduce read load, create an Amazon RDS read replica for offloading read queries, and deploy an Amazon ElastiCache for Redis cluster with replication to cache queries with high availability.

To offload read traffic from the primary RDS PostgreSQL instance, creating an RDS read replica is the standard design pattern. For the caching layer, since the company requires high availability and replication across multiple Availability Zones, Amazon ElastiCache for Redis must be used because Amazon ElastiCache for Memcached does not support replication or multi-AZ clustering.

Step-by-Step Solution

Analyze the primary bottleneck and target requirements.

The bottleneck is read-heavy load on the primary RDS PostgreSQL DB instance. The solution must reduce this read load and cache data with multi-AZ replication support.

Identifying the read-heavy nature and replication needs helps filter the suitable AWS services.

Evaluate the read replica option.

RDS read replicas are designed to offload read traffic from the primary instance.

This directly reduces CPU utilization on the primary RDS instance.

Evaluate the caching solutions.

Amazon ElastiCache for Redis is selected because it supports replication and Multi-AZ, whereas Memcached does not.

This satisfies the requirement for a high-availability caching layer.

Key Concept

Offloading database reads using read replicas and high-availability caching with Amazon ElastiCache for Redis.

Question 1003Question →

An application runs on Amazon EC2 instances behind an Application Load Balancer (ALB) inside an Auto Scaling group. The custom AMI used for the instances requires approximately $5$ minutes to complete bootstrapping and start serving requests. The current Auto Scaling group cooldown is configured for $60$ seconds. During sudden traffic surges, the Auto Scaling group launches a large number of unnecessary instances, resulting in high resource waste. Additionally, instances in private subnets cannot reliably communicate with third-party APIs because all outbound internet traffic is currently routed through a single NAT Gateway located in a single Availability Zone. Which two changes should the solutions architect implement to address these scaling and fault tolerance issues?

Select all that apply

Increase the Auto Scaling group cooldown period to

360

seconds.

Deploy a NAT Gateway in each Availability Zone and update the route tables to direct outbound traffic from the private subnets to their respective local NAT Gateway.

Decrease the Auto Scaling group cooldown period to

30

seconds to allow the group to add instances more rapidly.

Configure a single NAT Gateway in a public subnet and route outbound traffic from all private subnets across all Availability Zones to it.

Request that AWS Support pre-warm the Application Load Balancer to handle the instance bootstrapping delay.

Show answer & explanation

Answer: Increase the Auto Scaling group cooldown period to $360$ seconds.; Deploy a NAT Gateway in each Availability Zone and update the route tables to direct outbound traffic from the private subnets to their respective local NAT Gateway.

Answer

Increase the Auto Scaling group cooldown period to

360

seconds and deploy a NAT Gateway in each Availability Zone, updating the route tables to route outbound traffic through the local NAT Gateway in each zone.

Increasing the Auto Scaling group cooldown period to

360

seconds gives the custom AMI sufficient time to complete its

5

-minute bootstrapping phase before the Auto Scaling group evaluates metrics again. This successfully resolves the redundant scaling issue. Furthermore, deploying a NAT Gateway in each Availability Zone and updating the route tables to route traffic locally ensures that outbound traffic is fault-tolerant and has no single point of failure.

Step-by-Step Solution

Analyze the cause of redundant instance scaling during traffic surges.

The

60

-second cooldown is shorter than the

5

-minute (

300

seconds) instance boot time, causing the group to continuously launch instances before the first ones can start serving traffic and lower metrics.

To prevent redundant launches, the cooldown period must be set longer than the bootstrapping duration (e.g.,

360

seconds).

Identify the outbound connectivity vulnerability.

A single NAT Gateway is a single point of failure across all Availability Zones.

To make the outbound connectivity fault tolerant, a NAT Gateway must be deployed in each Availability Zone.

Key Concept

Auto Scaling cooldown configuration and Multi-AZ NAT Gateway redundancy

Estimated Time:2m 0s

Question 1004Question →

A company has a fleet of Amazon EC2 instances that must maintain a specific security configuration. A Solutions Architect needs to implement a solution to automatically detect and remediate any configuration drift on these instances. Which of the following approaches should the Solutions Architect use to achieve this goal? (Select TWO.)

Select all that apply

Use AWS Systems Manager State Manager to define and enforce the desired configuration on the instances at regular intervals.

Use AWS Config with an AWS Systems Manager Automation runbook as a remediation action to automatically correct non-compliant resource configurations.

Modify the AWS Organizations Service Control Policy (SCP) attached to the account to prevent local IAM users from making manual configuration changes within the EC2 operating systems.

Enable AWS CloudFormation drift detection with automatic stack rollback to revert manual changes made to the instances.

Configure AWS Key Management Service (AWS KMS) with an AWS-managed key to automatically intercept and override configuration changes on the instances.

Show answer & explanation

Answer: Use AWS Systems Manager State Manager to define and enforce the desired configuration on the instances at regular intervals.; Use AWS Config with an AWS Systems Manager Automation runbook as a remediation action to automatically correct non-compliant resource configurations.

Answer

Use AWS Systems Manager State Manager to define and enforce configurations, and use AWS Config with an AWS Systems Manager Automation runbook as a remediation action.

The correct options are using AWS Systems Manager State Manager and using AWS Config with SSM Automation. State Manager enforces defined configuration states at regular intervals. AWS Config detects non-compliant resource states and triggers SSM Automation runbooks to remediate them.

Step-by-Step Solution

Analyze the requirements for configuration drift detection and remediation on EC2 instances.

Identify that the solution must monitor configuration compliance and automatically revert any deviations.

This establishes the need for configuration management tools (SSM State Manager) and compliance monitoring with remediation (AWS Config + SSM Automation).

Evaluate the capabilities of AWS Systems Manager State Manager.

Confirm State Manager can apply SSM documents at set schedules to keep EC2 instances in a consistent state.

This provides continuous enforcement of the desired OS-level or application-level configurations.

Evaluate the capabilities of AWS Config combined with SSM Automation.

Confirm AWS Config can detect compliance drift and trigger an SSM Automation runbook to remediate the drift.

This provides automated compliance detection and remediation at the resource level.

Key Concept

Continuous compliance and drift remediation utilizing AWS Systems Manager and AWS Config.

Question 1005Question →

A gaming company operates a multiplayer online game where player session state and matchmaking queues are managed by an application running on Amazon EC2 instances in an Auto Scaling group behind an Application Load Balancer (ALB). The backend database is an Amazon RDS for PostgreSQL DB instance configured in a Multi-AZ deployment. During daily peak hours, players experience severe latency spikes and disconnected sessions. Monitoring data shows that the RDS primary DB instance has 90% CPU utilization and read IOPS throttling while the standby DB instance has 0% CPU utilization. Additionally, the EC2 instances experience a sudden CPU utilization spike of 98% for the first 5 minutes of the peak window, causing the ALB to report 502 Bad Gateway errors before the Auto Scaling group can successfully launch and bootstrap new instances. Which combination of actions should a Solutions Architect recommend to resolve the database and compute performance bottlenecks?

Deploy Amazon RDS Read Replicas to scale read queries, and request AWS Support to pre-warm the Application Load Balancer to handle the initial traffic spikes.

Route player session read queries to the passive standby DB instance in the Multi-AZ deployment, and configure a warm pool for the Auto Scaling group.

Deploy Amazon RDS Read Replicas to offload the read-heavy matchmaking queries from the primary DB instance, and configure the Auto Scaling group with a warm pool and step scaling policies.

Increase the Auto Scaling group default cooldown period to prevent rapid scaling actions, and upgrade the RDS instance to a larger instance class with Multi-AZ enabled.

Show answer & explanation

Answer: Deploy Amazon RDS Read Replicas to offload the read-heavy matchmaking queries from the primary DB instance, and configure the Auto Scaling group with a warm pool and step scaling policies.

Answer

Deploy Amazon RDS Read Replicas to offload the read-heavy matchmaking queries from the primary DB instance, and configure the Auto Scaling group with a warm pool and step scaling policies.

Deploying Amazon RDS Read Replicas is the correct approach to scale read workloads because it allows the primary instance to delegate read queries to replicas. Utilizing an Auto Scaling group warm pool keeps instances in a stopped or running state with pre-bootstrapped applications, drastically reducing the time it takes to serve traffic during sudden scaling events.

Step-by-Step Solution

Identify the database bottleneck and distinguish between Multi-AZ and Read Replica functionalities.

Recognize that the standby database in an RDS Multi-AZ configuration is passive and cannot serve read traffic.

This rules out solutions attempting to route reads to the standby DB instance.

Address the database read scaling requirements.

Deploy Amazon RDS Read Replicas to offload read-heavy query workloads from the primary DB instance.

Read replicas are designed specifically to scale read throughput horizontally.

Address the EC2 compute scaling bottleneck.

Implement an Auto Scaling group warm pool and step scaling policies to keep instances in a pre-bootstrapped state.

This avoids the 5-minute cold start/bootstrapping latency that causes the initial CPU spike and ALB 502 errors.

Key Concept

Scaling read workloads in Amazon RDS using Read Replicas vs Multi-AZ, and optimizing EC2 Auto Scaling performance using warm pools and scaling policies.

Estimated Time:2m 0s

Question 1006Question →

An enterprise operates a critical inventory management application in the `us-east-1` Region. The application runs on Amazon EC2 instances in an Auto Scaling group behind an Application Load Balancer (ALB). The database tier uses an Amazon RDS for PostgreSQL DB instance. The company wants to improve the reliability and disaster recovery posture of this workload by implementing a cross-Region solution in `us-west-2`. The solution must support a Recovery Time Objective (RTO) of $15$ minutes and a Recovery Point Objective (RPO) of $5$ minutes. Which combination of actions should the solutions architect perform to meet these requirements? (Select TWO.)

Select all that apply

Create an Amazon RDS cross-Region read replica of the PostgreSQL DB instance in `us-west-2`. Configure the disaster recovery environment's Auto Scaling group with a minimum capacity of

1

instance to serve as a warm standby, and promote the replica during a failover event.

Configure Amazon Route 53 active-passive failover routing. Create a primary failover alias record pointing to the Application Load Balancer in `us-east-1` and associate it with a Route 53 health check. Create a secondary failover alias record pointing to the Application Load Balancer in `us-west-2`.

Configure AWS Backup to take snapshots of the PostgreSQL database every

4

hours, copy the snapshots to `us-west-2`, and restore the database to a new instance during a failover event.

Configure Amazon Route 53 active-passive failover routing by creating a primary failover alias record pointing to the `us-east-1` Application Load Balancer and a secondary failover alias record pointing to the `us-west-2` Application Load Balancer, without associating health checks.

Configure outbound internet routing for the application servers in the `us-west-2` private subnets across

3

Availability Zones by routing all traffic through a single NAT Gateway deployed in one public subnet.

Show answer & explanation

Answer: Create an Amazon RDS cross-Region read replica of the PostgreSQL DB instance in `us-west-2`. Configure the disaster recovery environment's Auto Scaling group with a minimum capacity of $1$ instance to serve as a warm standby, and promote the replica during a failover event.; Configure Amazon Route 53 active-passive failover routing. Create a primary failover alias record pointing to the Application Load Balancer in `us-east-1` and associate it with a Route 53 health check. Create a secondary failover alias record pointing to the Application Load Balancer in `us-west-2`.

Answer

The solutions architect should create an Amazon RDS cross-Region read replica of the PostgreSQL database in the standby region and configure the Auto Scaling group with a minimum capacity of one instance. Additionally, they should configure Route 53 active-passive failover routing with a health check associated with the primary record.

To meet the

5

-minute RPO, a cross-Region read replica is required because database updates are asynchronously replicated with very low latency. To meet the

15

-minute RTO, Route 53 active-passive failover routing with a health check must be configured on the primary record to detect failures and automatically point DNS queries to the standby region's load balancer. Additionally, the standby Auto Scaling group must have a minimum capacity of at least one instance to quickly handle the initial wave of traffic and scale up.

Step-by-Step Solution

Evaluate database replication options against the target RPO constraint.

Amazon RDS cross-Region read replicas offer continuous asynchronous replication, satisfying the RPO of

5

minutes. Snapshot restores scheduled every

4

hours violate the RPO.

Choosing the correct database replication method ensures data loss limits are maintained within the required recovery window.

Evaluate DNS failover routing mechanisms against the target RTO constraint.

Amazon Route 53 active-passive failover routing automatically shifts traffic within minutes, meeting the

15

-minute RTO. A health check must be associated with the primary record for automatic failover to function.

Without a health check on the primary record, Route 53 cannot determine when the endpoint is down, preventing automatic routing to the secondary region.

Ensure the backup region's internal networking supports high availability.

Avoid non-redundant NAT Gateways in the target region. Instead, deploy redundant NAT Gateways across Availability Zones to avoid a single point of failure.

Disaster recovery designs must ensure the standby site is highly available to successfully take over operations during an outage.

Key Concept

Disaster recovery designs must align database replication and DNS failover health checking to meet business RTO and RPO objectives without introducing infrastructure single points of failure.

Estimated Time:2m 0s

Question 1007Question →

A healthcare enterprise is building a diagnostics imaging platform across multiple AWS accounts in the `us-east-1` region. The architecture contains `vpc-diagnostics-prod` (CIDR $10.100.0.0/16$ ) with EC2 instances processing images in private subnets across two Availability Zones (`us-east-1a` and `us-east-1b`), `vpc-shared-services` (CIDR $10.200.0.0/16$ ) hosting core infrastructure including a Route 53 Private Hosted Zone (PHZ) `imaging.internal`, and `vpc-security-egress` (CIDR $10.250.0.0/16$ ) dedicated to outbound inspection using AWS Network Firewall and NAT Gateways. The corporate on-premises datacenter is connected via AWS Direct Connect (DX) terminating on a Direct Connect Gateway (DXGW) associated with an AWS Transit Gateway (`tgw-us-east-1`). The enterprise requires: (1) Image processing instances in `vpc-diagnostics-prod` must resolve names in `imaging.internal` and the on-premises domain `corp.local`. (2) On-premises servers must be able to resolve names in `imaging.internal`. (3) All outbound internet traffic from `vpc-diagnostics-prod` must be inspected by AWS Network Firewall in `vpc-security-egress` in a manner that tolerates a single Availability Zone outage without losing internet connectivity or violating security requirements. Which TWO network configurations should the solutions architect implement to meet these requirements?

Select all that apply

In `vpc-security-egress`, deploy AWS Network Firewall endpoints and NAT Gateways across both Availability Zones. Configure the Transit Gateway route table for `vpc-diagnostics-prod` with a default route (

0.0.0.0/0

) pointing to the Transit Gateway attachment for `vpc-security-egress`. In `vpc-security-egress`, route traffic from the Transit Gateway attachment subnets to the local Network Firewall endpoint, then to the local NAT Gateway, and configure NAT Gateway subnet route tables to route outbound traffic through the Internet Gateway.

Associate the `imaging.internal` Private Hosted Zone with both `vpc-shared-services` and `vpc-diagnostics-prod`. In `vpc-shared-services`, create a Route 53 Resolver Inbound Endpoint and configure on-premises DNS servers to forward queries for `imaging.internal` to its IP addresses. Create a Route 53 Resolver Outbound Endpoint in `vpc-diagnostics-prod` and a Resolver rule that forwards queries for `corp.local` to the on-premises DNS servers over the Direct Connect connection.

In `vpc-security-egress`, deploy AWS Network Firewall endpoints in both Availability Zones and a single NAT Gateway in the `us-east-1a` public subnet. Configure the Transit Gateway route table for `vpc-diagnostics-prod` to route all internet-bound traffic through the `vpc-security-egress` attachment, routing all firewall-inspected traffic to the single NAT Gateway to minimize NAT Gateway hourly charges.

Associate the `imaging.internal` Private Hosted Zone only with `vpc-shared-services`. Create a Route 53 Resolver Outbound Endpoint in `vpc-diagnostics-prod` and configure a forwarding rule for `imaging.internal` that forwards DNS requests directly to the Route 53 Resolver IP address (

169.254.169.253

) in `vpc-shared-services` via the Transit Gateway connection.

Associate the Direct Connect Gateway directly with the Virtual Private Gateways (VGWs) attached to `vpc-diagnostics-prod` and `vpc-shared-services`. Use the Direct Connect Gateway to enable transitive routing and pass DNS queries directly between the on-premises network and the VPCs, bypassing the Transit Gateway for DNS traffic to reduce latency.

Show answer & explanation

Answer: In `vpc-security-egress`, deploy AWS Network Firewall endpoints and NAT Gateways across both Availability Zones. Configure the Transit Gateway route table for `vpc-diagnostics-prod` with a default route ( $0.0.0.0/0$ ) pointing to the Transit Gateway attachment for `vpc-security-egress`. In `vpc-security-egress`, route traffic from the Transit Gateway attachment subnets to the local Network Firewall endpoint, then to the local NAT Gateway, and configure NAT Gateway subnet route tables to route outbound traffic through the Internet Gateway.; Associate the `imaging.internal` Private Hosted Zone with both `vpc-shared-services` and `vpc-diagnostics-prod`. In `vpc-shared-services`, create a Route 53 Resolver Inbound Endpoint and configure on-premises DNS servers to forward queries for `imaging.internal` to its IP addresses. Create a Route 53 Resolver Outbound Endpoint in `vpc-diagnostics-prod` and a Resolver rule that forwards queries for `corp.local` to the on-premises DNS servers over the Direct Connect connection.

Answer

To satisfy all requirements, the solutions architect must deploy redundant AWS Network Firewall endpoints and NAT Gateways across both Availability Zones in the egress VPC and configure Transit Gateway route tables accordingly. For DNS, the solutions architect must associate the private hosted zone with the consumer VPCs, create an Inbound Endpoint for on-premises-to-AWS queries, and create an Outbound Endpoint with a forwarding rule for AWS-to-on-premises queries.

For resilient egress filtering, the correct configurations establish redundant, local-zone processing by routing through local AWS Network Firewall endpoints and local NAT Gateways within each Availability Zone. For hybrid and cross-account DNS resolution, the correct approach involves associating the Route 53 Private Hosted Zone directly with all consumer VPCs, deploying a Route 53 Resolver Inbound Endpoint to allow on-premises systems to resolve AWS records, and deploying a Route 53 Resolver Outbound Endpoint with a forwarding rule to resolve on-premises DNS records.

Step-by-Step Solution

Configure highly available outbound internet inspection by deploying AWS Network Firewall endpoints and NAT Gateways in each Availability Zone within the egress VPC.

Avoids cross-Availability Zone dependencies, ensuring that an outage in one zone does not impact the outbound traffic flow of the other zone.

Meets the high availability requirement and eliminates single points of failure for egress traffic.

Associate the Route 53 Private Hosted Zone directly with all participating VPCs that require name resolution.

Instances in the diagnostics production VPC can resolve records in the shared services private hosted zone locally.

Route 53 Private Hosted Zones cannot be resolved transitively across VPCs without direct association or a resolver endpoint routing architecture.

Set up Route 53 Resolver Inbound and Outbound Endpoints in the appropriate VPCs to bridge DNS resolution between AWS and the on-premises datacenter.

On-premises servers can resolve private AWS DNS names by forwarding queries to the Inbound Endpoint, and AWS workloads can resolve corporate domains by forwarding requests through the Outbound Endpoint.

Allows bidirectional DNS resolution between the on-premises network and AWS over the Direct Connect hybrid link.

Key Concept

Designing highly available, secure hybrid network routing and DNS resolution using AWS Transit Gateway, AWS Network Firewall, NAT Gateways, and Route 53 Resolver endpoints.

Estimated Time:3m 0s

Question 1008Question →

An enterprise operates a multi-tier application across two AWS accounts. Account A hosts the production web application on Amazon EC2 instances inside private subnets across three Availability Zones (AZs) in VPC A in the us-east-1 Region. The instances must access the internet to process payment transactions. Account B hosts a Route 53 Private Hosted Zone (PHZ) named api.internal used for core service discovery. To enhance reliability and establish a disaster recovery (DR) architecture in us-west-2 (VPC B in Account A) that meets a Recovery Time Objective (RTO) of 10 minutes and a Recovery Point Objective (RPO) of 1 minute, the solutions architect deploys an Amazon Aurora PostgreSQL Global Database with the primary cluster in us-east-1 and a secondary cluster in us-west-2. Which combination of architectural improvements and failover configurations will meet the reliability and DR requirements?

Deploy a NAT Gateway in each Availability Zone of VPC A, updating the private route tables to route outbound traffic through the local NAT Gateway in the same zone. In Account B, authorize the association of the api.internal Private Hosted Zone with VPC B in Account A, and then in Account A, associate the Private Hosted Zone with VPC B. Configure Route 53 failover routing records pointing to the Application Load Balancers (ALBs) in both regions, and associate the primary record with a Route 53 health check that monitors a custom application health endpoint performing local database connectivity checks.

Deploy a NAT Gateway in each Availability Zone of VPC A, updating the private route tables to route outbound traffic through the local NAT Gateway in the same zone. Create a duplicate Private Hosted Zone named api.internal in Account A and associate it directly with VPC B to manage DNS resolution locally. Configure Route 53 failover routing records pointing to the ALBs in both regions, and associate the primary record with a Route 53 health check that monitors a custom application health endpoint performing local database connectivity checks.

Deploy a single NAT Gateway in a public subnet of VPC A, and update all private route tables across all Availability Zones to route outbound internet traffic through this single gateway. In Account B, authorize the association of the api.internal Private Hosted Zone with VPC B in Account A, and then in Account A, associate the Private Hosted Zone with VPC B. Configure Route 53 failover routing records pointing to the ALBs in both regions, and associate the primary record with a Route 53 health check that monitors a custom application health endpoint performing local database connectivity checks.

Deploy a NAT Gateway in each Availability Zone of VPC A, updating the private route tables to route outbound traffic through the local NAT Gateway in the same zone. In Account B, authorize the association of the api.internal Private Hosted Zone with VPC B in Account A, and then in Account A, associate the Private Hosted Zone with VPC B. Configure Route 53 failover routing records pointing to the ALBs in both regions, and associate the primary record with a Route 53 health check that performs a basic TCP ping check on port 80 of the primary ALB.

Show answer & explanation

Answer: Deploy a NAT Gateway in each Availability Zone of VPC A, updating the private route tables to route outbound traffic through the local NAT Gateway in the same zone. In Account B, authorize the association of the api.internal Private Hosted Zone with VPC B in Account A, and then in Account A, associate the Private Hosted Zone with VPC B. Configure Route 53 failover routing records pointing to the Application Load Balancers (ALBs) in both regions, and associate the primary record with a Route 53 health check that monitors a custom application health endpoint performing local database connectivity checks.

Answer

The configuration implementing local NAT Gateways per Availability Zone, a cross-account Route 53 Private Hosted Zone association, and Route 53 failover records with database-aware health checks.

Deploying a NAT Gateway in each Availability Zone of VPC A ensures that a single zone outage does not disrupt outbound connectivity for the remaining healthy zones. Authorizing and associating the Private Hosted Zone across accounts correctly enables cross-account DNS resolution in the disaster recovery VPC without split-brain issues. Configuring a Route 53 health check that performs a deep application check (database connectivity) ensures that Route 53 fails over to the secondary Region if the primary database becomes degraded, meeting the RTO and RPO objectives.

Step-by-Step Solution

Ensure NAT gateway redundancy in the primary VPC.

Deploy one NAT Gateway per Availability Zone and update the private subnet route tables to direct outbound traffic to the NAT Gateway in the same zone.

This prevents a single Availability Zone failure from disrupting outbound connectivity for all instances.

Associate the core services Private Hosted Zone cross-account.

Authorize the association of the hosted zone in Account B with VPC B in Account A, and then execute the association in Account A.

This establishes consistent DNS resolution in the disaster recovery Region without running into split-brain issues from duplicating the zone.

Implement active-passive routing with deep health checks.

Configure Route 53 failover records pointing to regional endpoints, and bind the primary record to an application health check that monitors backend database connectivity.

This ensures that regional database degradation causes the primary health check to fail, triggering automatic DNS failover to the secondary Region.

Key Concept

Reliability and multi-region disaster recovery for multi-account web applications with strict RTO/RPO requirements.

Question 1009Question →

A healthcare company is preparing to launch a suite of critical applications in the ap-southeast-1 region across three distinct VPCs: vpc-clinical-app, vpc-billing-app, and vpc-core-services. The company requires local DNS resolution for a private hosted zone (PHZ) named corp.internal across all three VPCs. The application servers in vpc-clinical-app and vpc-billing-app must access external regulatory endpoints over the internet, and all resources must connect to an on-premises EHR (Electronic Health Record) system over a 10 Gbps AWS Direct Connect connection. The architecture must minimize latency, avoid transitive routing issues, ensure high availability for outbound egress, and prevent DNS resolution failures. Which architecture meets these requirements with the lowest operational overhead?

Deploy a Transit Gateway attached to all three VPCs. Connect a Direct Connect Gateway to the Transit Gateway using a transit virtual interface for hybrid connectivity. Create a central egress VPC with public and private subnets across two Availability Zones, hosting a NAT Gateway in each of the two public subnets. Configure the Transit Gateway route tables to route all internet-bound traffic from the spoke VPCs to the egress VPC. Associate the private hosted zone with all three VPCs, and deploy Route 53 Inbound Resolver endpoints in two Availability Zones of the core services VPC to accept DNS queries forwarded from the on-premises DNS servers.

Deploy a Transit Gateway attached to all three VPCs. Connect a Direct Connect Gateway to the Transit Gateway using a transit virtual interface for hybrid connectivity. Create a central egress VPC containing public and private subnets, and host one NAT Gateway in the public subnet to centralize outbound traffic. Configure the Transit Gateway route tables to route all internet-bound traffic from the spoke VPCs to the egress VPC. Associate the private hosted zone with all three VPCs, and deploy Route 53 Inbound Resolver endpoints in two Availability Zones of the core services VPC to accept DNS queries forwarded from the on-premises DNS servers.

Deploy a Transit Gateway attached to all three VPCs. Connect a Direct Connect Gateway to the Transit Gateway using a transit virtual interface for hybrid connectivity. Create a central egress VPC with public and private subnets across two Availability Zones, hosting a NAT Gateway in each of the two public subnets. Configure the Transit Gateway route tables to route all internet-bound traffic from the spoke VPCs to the egress VPC. Link the private hosted zone only to the core services VPC, and deploy Route 53 Inbound Resolver endpoints in two Availability Zones of the core services VPC to accept DNS queries forwarded from the on-premises DNS servers.

Connect a Direct Connect Gateway directly to all three VPCs using private virtual interfaces to handle on-premises and inter-VPC routing. Deploy a separate NAT Gateway inside a public subnet within each individual spoke VPC for local egress. Associate the private hosted zone with all three VPCs, and deploy Route 53 Inbound Resolver endpoints in two Availability Zones of the core services VPC to accept DNS queries forwarded from the on-premises DNS servers.

Show answer & explanation

Answer: Deploy a Transit Gateway attached to all three VPCs. Connect a Direct Connect Gateway to the Transit Gateway using a transit virtual interface for hybrid connectivity. Create a central egress VPC with public and private subnets across two Availability Zones, hosting a NAT Gateway in each of the two public subnets. Configure the Transit Gateway route tables to route all internet-bound traffic from the spoke VPCs to the egress VPC. Associate the private hosted zone with all three VPCs, and deploy Route 53 Inbound Resolver endpoints in two Availability Zones of the core services VPC to accept DNS queries forwarded from the on-premises DNS servers.

Answer

The correct architecture uses AWS Transit Gateway associated with a Direct Connect Gateway via a transit virtual interface to handle hybrid and inter-VPC traffic. Highly available internet egress is achieved by using a central egress VPC with public subnets across two Availability Zones, each hosting a NAT Gateway. Private DNS resolution is configured by associating the Route 53 Private Hosted Zone with all three VPCs, and deploying Route 53 Inbound Resolver endpoints across two Availability Zones in the core services VPC to resolve queries from on-premises DNS servers.

Associating the private hosted zone with all three VPCs ensures that resource records can be resolved locally within each VPC. Deploying Route 53 Inbound Resolver endpoints across two Availability Zones in the core services VPC allows on-premises DNS servers to forward queries for the private hosted zone to highly available endpoints. Using a Transit Gateway connected to the Direct Connect Gateway via a transit virtual interface enables multi-VPC hybrid connectivity and inter-VPC routing without transitive limitations. Finally, hosting a NAT Gateway in each of the two public subnets within the central egress VPC ensures that internet-bound traffic from the spoke VPCs remains highly available and does not have a single point of failure.

Step-by-Step Solution

Select the appropriate hybrid connectivity model.

Determine that a Transit Gateway connected to a Direct Connect Gateway via a transit virtual interface is required.

Direct Connect Gateway alone does not support transitive routing between associated VPCs, so a Transit Gateway is necessary to enable both on-premises access and secure inter-VPC traffic.

Design a highly available outbound internet egress path.

Establish a central egress VPC with NAT Gateways deployed across two Availability Zones, and route internet-bound traffic from the spoke VPCs to the Transit Gateway.

Deploying NAT Gateways in multiple Availability Zones removes single points of failure, ensuring that outbound internet traffic survives an Availability Zone outage.

Configure DNS resolution for the private hosted zone.

Associate the Route 53 Private Hosted Zone with all three VPCs, and deploy Inbound Resolver endpoints in two Availability Zones of the core services VPC.

Associating the private hosted zone with all VPCs allows instances in any VPC to resolve local DNS records. Deploying multi-AZ inbound endpoints allows the on-premises DNS server to forward queries and resolve resources in the cloud without outages.

Key Concept

Multi-VPC hybrid routing with Transit Gateway, high availability egress design, and cross-VPC Private Hosted Zone association with Route 53 Resolver endpoints.

Question 1010Question →

A software-as-a-service (SaaS) provider is establishing a new application environment in the eu-central-1 Region. The architecture features $3$ spoke VPCs (vpc-tenant-a, vpc-tenant-b, and vpc-services) and a central egress VPC (vpc-egress). The instances in the tenant VPCs require access to APIs in the services VPC, must resolve internal domain names managed in a Route 53 Private Hosted Zone (PHZ) created in the services VPC, and need outbound internet access for patching. Which TWO network architecture configurations should the solutions architect implement to satisfy these connectivity and DNS requirements while ensuring high availability and resilience?

Select all that apply

Interconnect all tenant and services VPCs using an AWS Transit Gateway, and authorize and associate the services Private Hosted Zone with each of the tenant VPCs.

Deploy NAT Gateways in multiple Availability Zones in the central egress VPC, and configure the spoke VPC route tables to route outbound internet traffic to the AWS Transit Gateway.

Deploy a single NAT Gateway in a single Availability Zone within the central egress VPC to centralize and route all outbound internet traffic from the spokes.

Associate the services Private Hosted Zone directly with the AWS Transit Gateway to automatically inherit DNS resolution across all attached spokes.

Establish a Direct Connect Gateway and attach it to all VPCs to handle transitive routing and DNS propagation between the spokes.

Show answer & explanation

Answer: Interconnect all tenant and services VPCs using an AWS Transit Gateway, and authorize and associate the services Private Hosted Zone with each of the tenant VPCs.; Deploy NAT Gateways in multiple Availability Zones in the central egress VPC, and configure the spoke VPC route tables to route outbound internet traffic to the AWS Transit Gateway.

Answer

Interconnect all tenant and services VPCs using an AWS Transit Gateway, authorize and associate the services Private Hosted Zone with each of the tenant VPCs, deploy NAT Gateways in multiple Availability Zones in the central egress VPC, and configure the spoke VPC route tables to route outbound internet traffic to the AWS Transit Gateway.

The correct solution involves interconnecting all VPCs through an AWS Transit Gateway to establish the networking fabric. To enable internal name resolution, the Private Hosted Zone in the services VPC must be associated with each of the tenant VPCs. To ensure high availability for outbound egress, NAT Gateways must be deployed in multiple Availability Zones in the egress VPC, and the spoke VPC route tables must point to the Transit Gateway for default routing.

Step-by-Step Solution

Configure the core network interconnectivity using AWS Transit Gateway.

All spoke VPCs (vpc-tenant-a, vpc-tenant-b, and vpc-services) and the central egress VPC (vpc-egress) are attached to the Transit Gateway, enabling VPC-to-VPC IP routing.

This establishes the necessary network path for VPCs to communicate with the services VPC and the egress VPC.

Set up private DNS resolution across all VPCs.

The Route 53 Private Hosted Zone created in the services VPC is associated with both tenant VPCs.

Route 53 Private Hosted Zones must be explicitly associated with each VPC requiring DNS resolution. Because these are in a multi-VPC architecture, cross-account or cross-VPC association authorizations must be completed so that queries from tenant VPCs can resolve DNS names in the services VPC.

Deploy high-availability NAT Gateways and configure egress routing.

NAT Gateways are placed in multiple Availability Zones in vpc-egress. Spoke VPC route tables route default traffic (

0.0.0.0/0

) to the Transit Gateway, which routes it to vpc-egress, and then through the NAT Gateways to the internet.

Deploying NAT Gateways in multiple Availability Zones removes the single point of failure, satisfying the resilience and high availability requirement.

Key Concept

Designing highly resilient, multi-VPC architectures using Transit Gateway for routing, multi-AZ NAT Gateways for egress, and cross-VPC Route 53 Private Hosted Zone associations for internal name resolution.

Question 1011Question →

A digital broadcasting company is launching a global video-on-demand platform. Transcoding engines running on Amazon ECS on AWS Fargate in the Media Processing Account ( $222244446666) need to write processed video segments directly to an Amazon S3 bucket located in the Content Distribution Account ($ 888800002222). To comply with digital rights management (DRM) policies, all video files must be encrypted at rest with AWS Key Management Service (AWS KMS), and the transcoding engines must only be allowed to encrypt the assets without having permission to decrypt them after writing. Which combination of configurations will successfully allow the ECS tasks in the Media Processing Account to write these encrypted video segments to the S3 bucket in the Content Distribution Account while adhering to the principle of least privilege?

Create a Customer Managed Key (CMK) in the Content Distribution Account. Configure the key policy of the CMK to grant the Media Processing Account's ECS task role permissions to perform `kms:GenerateDataKey`. In the Content Distribution Account, configure the S3 bucket policy to allow the ECS task role `s3:PutObject` permissions. In the Media Processing Account, configure the ECS task IAM role with permissions to perform `s3:PutObject` on the target S3 bucket and `kms:GenerateDataKey` on the CMK in the Content Distribution Account.

Use the default AWS-managed KMS key for Amazon S3 (`aws/s3`) in the Content Distribution Account. Configure the S3 bucket policy in the Content Distribution Account to allow `s3:PutObject` from the Media Processing Account's ECS task role. In the Media Processing Account, attach an IAM policy to the ECS task role that allows `s3:PutObject` on the target bucket and `kms:GenerateDataKey` on the `aws/s3` key.

Create a Customer Managed Key (CMK) in the Content Distribution Account. Attach a Service Control Policy (SCP) to the Organizational Unit (OU) containing both accounts that explicitly allows `s3:PutObject` and `kms:GenerateDataKey` across all resources. Rely on this SCP to grant the necessary cross-account write permissions to the ECS tasks without configuring individual IAM policies or the S3 bucket policy.

Create a Customer Managed Key (CMK) in the Content Distribution Account. Configure the S3 bucket policy in the Content Distribution Account to allow the Media Processing Account's root principal to perform `s3:PutObject` and `kms:GenerateDataKey` operations. In the Media Processing Account, configure the ECS task IAM role with `s3:PutObject` and `kms:GenerateDataKey` permissions, relying on the bucket policy to delegate the KMS authorization.

Show answer & explanation

Answer: Create a Customer Managed Key (CMK) in the Content Distribution Account. Configure the key policy of the CMK to grant the Media Processing Account's ECS task role permissions to perform `kms:GenerateDataKey`. In the Content Distribution Account, configure the S3 bucket policy to allow the ECS task role `s3:PutObject` permissions. In the Media Processing Account, configure the ECS task IAM role with permissions to perform `s3:PutObject` on the target S3 bucket and `kms:GenerateDataKey` on the CMK in the Content Distribution Account.

Answer

Create a Customer Managed Key (CMK) in the Content Distribution Account, configure the key policy to grant the ECS task role permissions to perform `kms:GenerateDataKey`, configure the S3 bucket policy to allow the ECS task role `s3:PutObject`, and configure the ECS task IAM role in the Media Processing Account with permissions for both `s3:PutObject` and `kms:GenerateDataKey`.

The correct configuration uses a Customer Managed Key (CMK) in the destination account because AWS-managed keys cannot be shared cross-account. Since the task only needs to write (encrypt) data, granting only the `kms:GenerateDataKey` permission aligns with the least privilege principle and prevents it from decrypting the files later. The bucket policy explicitly allows the Fargate task role to perform `s3:PutObject`, and the task role's IAM policy in the processing account allows both the S3 write action and the KMS data key generation action.

Step-by-Step Solution

Determine the type of KMS key needed for cross-account S3 encryption.

Identify that a Customer Managed Key (CMK) must be used, as the default AWS-managed KMS key (`aws/s3`) cannot be configured with cross-account permissions.

AWS-managed keys do not allow modifications to their key policies, making them unusable for cross-account access.

Configure permissions in the destination Content Distribution Account.

Add an S3 bucket policy allowing `s3:PutObject` for the ECS task role in the Media Processing Account, and add a KMS key policy allowing `kms:GenerateDataKey` for the same role.

Resource policies in the owning account must explicitly trust the external account's role to access the S3 bucket and the encryption key.

Configure permissions in the source Media Processing Account.

Attach an IAM policy to the ECS task role allowing `s3:PutObject` on the target bucket and `kms:GenerateDataKey` on the CMK.

The caller's IAM role must have explicit permission to access target resources in another account, in addition to the resource-level permissions.

Apply the principle of least privilege for encryption constraints.

Only grant `kms:GenerateDataKey` permission to the ECS task role, omitting `kms:Decrypt`.

This allows the ECS task to encrypt and write objects to S3 but prevents it from decrypting the assets once they are written.

Key Concept

Cross-account S3 bucket access with KMS CMK encryption

Question 1012Question →

A data processing workload is hosted on a fleet of Amazon EC2 instances managed by an Auto Scaling group. The launch template uses a user data bootstrap script to pull dependencies and configure the application, taking $7$ minutes before the instance is ready to accept tasks. The Auto Scaling group scales out using a step scaling policy with a cooldown set to $300$ seconds. During traffic bursts, the Auto Scaling group launches multiple waves of redundant instances before the initial new instances can begin processing tasks, resulting in resource over-provisioning. Which configuration change will prevent this redundant instance creation?

Increase the Auto Scaling group's default cooldown and instance warm-up periods to at least

420

seconds.

Decrease the Auto Scaling group's default cooldown period to

180

seconds to force more frequent policy evaluations.

Request an Application Load Balancer pre-warming from AWS Support to absorb the incoming burst traffic.

Consolidate all egress traffic through a single NAT Gateway to speed up the download of bootstrap files.

Show answer & explanation

Answer: Increase the Auto Scaling group's default cooldown and instance warm-up periods to at least $420$ seconds.

Answer

Increase the Auto Scaling group's default cooldown and instance warm-up periods to at least

420

seconds.

The correct answer is to increase the Auto Scaling group's default cooldown and instance warm-up periods to at least

420

seconds. This aligns the scaling policy evaluation timing with the actual duration needed for a new instance to become healthy, preventing premature launch of extra instances.

Step-by-Step Solution

Analyze the bootstrapping duration of the instances.

The instance takes

7

minutes to initialize, which is equal to

420

seconds.

We must determine the minimum time needed for a new instance to become healthy and start handling traffic.

Compare the initialization time with the current scaling policy cooldown configuration.

The current cooldown is

300

seconds, which is shorter than the

420

seconds required for bootstrapping.

This mismatch causes the Auto Scaling group to trigger subsequent scaling actions before the first instance starts taking load.

Adjust the scaling parameters to prevent premature scale-out.

Increasing the cooldown and warm-up periods to at least

420

seconds allows the scaling group to pause further scaling actions until the new instance is active.

This aligns the scaling feedback loop with actual instance availability, stopping the redundant creation of instances.

Key Concept

Auto Scaling Cooldown and Warm-up Alignment

Question 1013Question →

An administrator deployed an Amazon S3 bucket by using an AWS CloudFormation template. A developer subsequently modified the bucket's lifecycle policy directly in the Amazon S3 console. Which AWS CloudFormation feature should the administrator use to identify the discrepancy between the template definition and the current live configuration of the S3 bucket?

AWS CloudFormation drift detection

A Service Control Policy (SCP) attached to the organizational unit to grant the CloudFormation stack permission to automatically restore the bucket's lifecycle policy

An AWS-managed KMS key (aws/s3) with an attached key policy that restricts bucket configuration changes to CloudFormation stack updates

A linear deployment strategy configured in AWS CodeDeploy to automatically rollback the live S3 bucket modifications when they occur

Show answer & explanation

Answer: AWS CloudFormation drift detection

Answer

AWS CloudFormation drift detection

AWS CloudFormation drift detection allows you to compare the stack's current resource configuration against the template's specified properties. Running drift detection on the stack identifies that the S3 bucket's configuration has drifted due to the manual lifecycle policy modification, indicating the exact differences.

Step-by-Step Solution

Analyze the scenario requirements.

The goal is to find a feature that identifies out-of-band changes (drift) made directly to an S3 bucket that was deployed via CloudFormation.

Identifying changes that make a live resource differ from its defined template configuration is known as detecting configuration drift.

Evaluate the capabilities of AWS CloudFormation.

CloudFormation provides a built-in feature called drift detection.

Drift detection compares the current configuration of stack resources with the expected configuration defined in the CloudFormation template.

Key Concept

Identifying configuration drift on resources managed by AWS CloudFormation.

Question 1014Question →

An enterprise runs a critical application on Amazon EC2 instances within an Auto Scaling group in a Production AWS account. The application generates business logs located at `/var/log/app/transaction.log`. These logs are rotated hourly and renamed using the format `/var/log/app/transaction.log-YYYYMMDD-HH`. The company's compliance policy requires that all logs be consolidated into a centralized Amazon OpenSearch Service domain managed in a dedicated Security AWS account. The solution must ensure zero data loss during log file rotations, tolerate downstream OpenSearch Service ingestion throttling or outages, and adhere strictly to the principle of least privilege. Which of the following approaches is the MOST operationally excellent and secure way to implement this logging architecture?

Configure the CloudWatch agent on the EC2 instances with the log path set to `/var/log/app/transaction.log*` to monitor active and rotated log files. Send the logs to a local CloudWatch log group. In the Security account, create a CloudWatch Logs destination resource pointing to a local Kinesis Data Firehose delivery stream, and attach an access policy allowing the Production account to publish to it. In the Production account, create a CloudWatch Logs subscription filter on the log group pointing to the Security account's destination ARN. Configure the Kinesis Data Firehose stream to deliver logs to the Amazon OpenSearch Service domain and write failed documents to an S3 backup bucket in the Security account.

Configure the CloudWatch agent on the EC2 instances with the log path set to `/var/log/app/transaction.log` to track the active log stream. Send the logs to a local CloudWatch log group. In the Security account, create a CloudWatch Logs destination resource pointing to a local Kinesis Data Firehose delivery stream, and attach an access policy allowing the Production account to publish to it. In the Production account, create a CloudWatch Logs subscription filter on the log group pointing to the Security account's destination ARN. Configure the Kinesis Data Firehose stream to deliver logs to the Amazon OpenSearch Service domain and write failed logs to an S3 backup bucket in the Security account.

Configure the CloudWatch agent on the EC2 instances with the log path set to `/var/log/app/transaction.log*` and configure the agent to publish logs directly to a Kinesis Data Firehose delivery stream in the Security account. Create an IAM role in the Production account that attempts to assume a role in the Security account to write directly to Firehose, but do not configure any CloudWatch log groups in the Production account to act as a buffer or local log cache.

Configure the CloudWatch agent on the EC2 instances with the log path set to `/var/log/app/transaction.log*` and publish logs to a local CloudWatch log group in the Production account. Create a Kinesis Data Firehose delivery stream in the Production account that delivers logs directly to the Amazon OpenSearch Service domain in the Security account. Configure Kinesis Data Firehose to write failed documents to an S3 bucket in the Security account, and apply a bucket policy that grants `s3:PutObject` to the Production account IAM role but omits the `s3:PutObjectAcl` permission required to grant bucket owner full control.

Show answer & explanation

Answer: Configure the CloudWatch agent on the EC2 instances with the log path set to `/var/log/app/transaction.log*` to monitor active and rotated log files. Send the logs to a local CloudWatch log group. In the Security account, create a CloudWatch Logs destination resource pointing to a local Kinesis Data Firehose delivery stream, and attach an access policy allowing the Production account to publish to it. In the Production account, create a CloudWatch Logs subscription filter on the log group pointing to the Security account's destination ARN. Configure the Kinesis Data Firehose stream to deliver logs to the Amazon OpenSearch Service domain and write failed documents to an S3 backup bucket in the Security account.

Answer

The correct approach is to configure the CloudWatch agent with a wildcard path to capture rotated files, publish to a local CloudWatch log group, stream to a cross-account CloudWatch Logs destination in the Security account, and use Kinesis Data Firehose in the Security account to route to OpenSearch and back up failed documents to an S3 bucket in the same account.

The correct approach utilizes a wildcard pattern `/var/log/app/transaction.log*` in the CloudWatch agent config to ensure rotated logs are captured. It routes logs via a local CloudWatch log group to a cross-account CloudWatch Logs destination, which then writes to a Kinesis Data Firehose delivery stream in the Security account. Firehose natively buffers the logs, handles OpenSearch ingestion, and writes failed deliveries to an S3 backup bucket in the same Security account, avoiding complex cross-account S3 write permissions.

Step-by-Step Solution

Specify the wildcard log path `/var/log/app/transaction.log*` in the CloudWatch agent configuration.

The CloudWatch agent continuously monitors both the active transaction log and any newly rotated log files, preventing log loss during rotation.

Log rotation renames active files, which would cause a static configuration path to miss logs during transition.

Publish logs from the EC2 instances to a local CloudWatch log group in the Production account, and create a cross-account CloudWatch Logs destination in the Security account.

Logs are buffered locally in the Production account, and a secure cross-account subscription path is established to the Security account.

This isolates account-level operational data and provides a native, secure transfer mechanism using AWS service-to-service IAM permissions.

Create a subscription filter in the Production account pointing to the Security account's destination ARN, routing logs to Kinesis Data Firehose and Amazon OpenSearch Service in the Security account.

Logs are streamed in real time to Kinesis Data Firehose, which buffers them and delivers them to the OpenSearch Service domain. Failed deliveries are captured in a local S3 backup bucket in the Security account.

This ensures that OpenSearch Service scaling or outages do not lead to log loss, as Firehose buffers and retries, eventually backing up failures to S3 without cross-account write complexities.

Key Concept

Cross-account centralized logging using CloudWatch Logs subscription filters, CloudWatch Logs destinations, and Kinesis Data Firehose backup paths.

Question 1015Question →

A financial services provider hosts a core trading application in the us-east-1 Region across three VPCs: TradeExecution, AccountLedger, and MarketData. The VPCs must exchange high-throughput, low-latency messages with each other, and also communicate with an on-premises datacenter over a 10 Gbps AWS Direct Connect connection. The application instances run in private subnets across multiple Availability Zones (AZs).

During high-volume events, the provider experiences several issues:
1. High packet loss and latency during sudden, massive traffic spikes on the front-end application layer, which runs behind Application Load Balancers (ALBs).
2. DNS resolution failures when on-premises systems attempt to resolve the private DNS names of the services hosted within the Route 53 Private Hosted Zone (PHZ).
3. Outbound security updates and third-party API calls fail or incur high latency when an AZ hosting the primary NAT Gateway experiences network degradation.
4. Latency-sensitive inter-VPC communication is currently routed via an on-premises firewall, causing a massive latency penalty.

Which set of actions should the solutions architect implement to optimize network performance, minimize latency, and resolve these issues?

Connect all three VPCs directly to the Direct Connect Gateway using private virtual interfaces to allow direct inter-VPC transitive routing and on-premises connectivity. Deploy Route 53 Resolver Inbound Endpoints in the Shared Services VPC and associate the Private Hosted Zone with all VPCs. Deploy redundant NAT Gateways in each Availability Zone for each VPC. Replace the front-end Application Load Balancers with Network Load Balancers.

Establish an AWS Transit Gateway to route inter-VPC and on-premises traffic via a Direct Connect Gateway. Deploy Route 53 Resolver Inbound Endpoints in the Shared Services VPC to handle DNS requests from on-premises, but omit associating the Private Hosted Zone with the other application VPCs to avoid DNS loop configurations. Deploy redundant NAT Gateways in each Availability Zone for each VPC. Replace the front-end Application Load Balancers with Network Load Balancers.

Establish an AWS Transit Gateway to route inter-VPC and on-premises traffic via a Direct Connect Gateway, enabling high-throughput, low-latency transitive routing. Associate the Route 53 Private Hosted Zone with all three VPCs and deploy Route 53 Resolver Inbound Endpoints in the Shared Services VPC. Deploy redundant NAT Gateways in each Availability Zone for each VPC to keep outbound traffic local to the Availability Zone. Replace the front-end Application Load Balancers with Network Load Balancers.

Establish an AWS Transit Gateway to route inter-VPC and on-premises traffic via a Direct Connect Gateway. Associate the Route 53 Private Hosted Zone with all three VPCs and deploy Route 53 Resolver Inbound Endpoints in the Shared Services VPC. Deploy a single central NAT Gateway in the Shared Services VPC and update the route tables of the other VPCs to route outbound internet traffic through this single gateway to reduce NAT Gateway hourly charges. Replace the front-end Application Load Balancers with Network Load Balancers.

Show answer & explanation

Answer: Establish an AWS Transit Gateway to route inter-VPC and on-premises traffic via a Direct Connect Gateway, enabling high-throughput, low-latency transitive routing. Associate the Route 53 Private Hosted Zone with all three VPCs and deploy Route 53 Resolver Inbound Endpoints in the Shared Services VPC. Deploy redundant NAT Gateways in each Availability Zone for each VPC to keep outbound traffic local to the Availability Zone. Replace the front-end Application Load Balancers with Network Load Balancers.

Answer

The correct solution uses AWS Transit Gateway to enable low-latency transitive routing between the VPCs and the on-premises network via a Direct Connect Gateway. It correctly associates the Route 53 Private Hosted Zone with all VPCs and deploys Route 53 Resolver Inbound Endpoints in the Shared Services VPC to allow on-premises systems to resolve internal DNS names. Redundant NAT Gateways deployed in each Availability Zone ensure that outbound traffic does not cross Availability Zones, avoiding latency penalties and removing single points of failure. Finally, replacing the Application Load Balancers with Network Load Balancers ensures the architecture can handle instantaneous traffic spikes without pre-warming.

Step-by-Step Solution

Analyze inter-VPC routing requirements

Identify that inter-VPC traffic must bypass the on-premises firewall and that Direct Connect Gateway alone does not support transitive routing between VPCs. AWS Transit Gateway is selected to act as the central hub.

To achieve high-throughput and low-latency inter-VPC and hybrid communications, transitive routing via AWS Transit Gateway is the industry-standard architecture.

Address private DNS resolution from on-premises

Determine that a Route 53 Private Hosted Zone must be explicitly associated with each VPC in the network mesh, and Route 53 Resolver Inbound Endpoints must be deployed to receive DNS queries from on-premises DNS forwarders.

Without explicit association of the Private Hosted Zone to all member VPCs, resolution of private DNS names fails outside the hosting VPC.

Resolve outbound internet latency and single point of failure

Deploy NAT Gateways in every Availability Zone within each VPC, rather than routing outbound traffic through a single central NAT Gateway.

Cross-AZ traffic to a single NAT Gateway incurs latency fees and creates a single point of failure. Redundant NAT Gateways keep traffic local to the Availability Zone.

Address traffic spike handling

Replace Application Load Balancers with Network Load Balancers (NLBs) at the front-end layer.

Application Load Balancers scale gradually and require pre-warming to handle sudden, massive traffic spikes. Network Load Balancers scale instantaneously to millions of requests per second.

Key Concept

Optimizing hybrid and multi-VPC networks using Transit Gateway, localized Route 53 Resolver endpoints, redundant Availability Zone-specific NAT Gateways, and high-performance Network Load Balancers.

Question 1016Question →

An enterprise is designing a high-availability, multi-account network architecture in the us-east-1 Region. The architecture consists of three VPCs:

1. vpc-app-prod (Application Account): Distributed across Availability Zones us-east-1a and us-east-1b, containing private subnets hosting critical workloads.
2. vpc-shared-services (Shared Services Account): Hosts internal shared services and a Route 53 Private Hosted Zone (PHZ) named services.corp.internal.
3. vpc-net-egress (Network Account): A centralized VPC designed to handle all outbound internet traffic.

An AWS Transit Gateway (tgw-central) in the Network Account interconnects all three VPCs. The architecture must satisfy the following constraints:
- Workloads in vpc-app-prod must resolve hostnames under the services.corp.internal domain.
- All outbound internet traffic from vpc-app-prod must route through vpc-net-egress for centralized network address translation (NAT).
- The network design must be resilient to a single Availability Zone outage. A failure in us-east-1a must not interrupt internet access or DNS resolution for workloads running in us-east-1b.

Which design configuration meets these requirements while ensuring maximum resiliency?

Deploy a NAT Gateway in a public subnet in us-east-1a and another NAT Gateway in a public subnet in us-east-1b within vpc-net-egress. In vpc-net-egress, configure the route tables associated with the Transit Gateway attachment subnets to direct traffic destined for 0.0.0.0/0 to the local NAT Gateway in the same Availability Zone. Authorize the association of vpc-app-prod with the services.corp.internal Private Hosted Zone from the Shared Services Account, then associate the VPC from the Application Account. Configure the private subnet route tables in vpc-app-prod to route 0.0.0.0/0 to tgw-central, and configure the Transit Gateway route table associated with vpc-app-prod to route 0.0.0.0/0 to the vpc-net-egress attachment.

Deploy a single NAT Gateway in the us-east-1a public subnet of vpc-net-egress to minimize ongoing Gateway charges. In vpc-net-egress, configure the route tables of all Transit Gateway attachment subnets to route 0.0.0.0/0 to this single NAT Gateway. Authorize the association of vpc-app-prod with the services.corp.internal Private Hosted Zone from the Shared Services Account, then associate the VPC from the Application Account. Configure the private subnet route tables in vpc-app-prod to route 0.0.0.0/0 to tgw-central, and configure the Transit Gateway route table associated with vpc-app-prod to route 0.0.0.0/0 to the vpc-net-egress attachment.

Deploy a NAT Gateway in a public subnet in both us-east-1a and us-east-1b within vpc-net-egress. Configure tgw-central with a single route table where route propagation is enabled for all VPC attachments. Configure a static route in tgw-central for 0.0.0.0/0 pointing directly to the Internet Gateway of vpc-net-egress. Configure the Route 53 Resolver in the Application Account to use an outbound resolver endpoint in vpc-app-prod that forwards DNS queries for services.corp.internal to the inbound resolver endpoint in vpc-shared-services.

Deploy a NAT Gateway in a public subnet in both us-east-1a and us-east-1b within vpc-net-egress. In vpc-net-egress, configure the route tables associated with the Transit Gateway attachment subnets to direct traffic destined for 0.0.0.0/0 to the local NAT Gateway in the same Availability Zone. Configure the private subnet route tables in vpc-app-prod to route 0.0.0.0/0 to tgw-central. Rely on the active Transit Gateway attachments to automatically forward DNS queries for services.corp.internal from vpc-app-prod to the DNS servers in vpc-shared-services without explicit cross-account VPC association.

Show answer & explanation

Answer: Deploy a NAT Gateway in a public subnet in us-east-1a and another NAT Gateway in a public subnet in us-east-1b within vpc-net-egress. In vpc-net-egress, configure the route tables associated with the Transit Gateway attachment subnets to direct traffic destined for 0.0.0.0/0 to the local NAT Gateway in the same Availability Zone. Authorize the association of vpc-app-prod with the services.corp.internal Private Hosted Zone from the Shared Services Account, then associate the VPC from the Application Account. Configure the private subnet route tables in vpc-app-prod to route 0.0.0.0/0 to tgw-central, and configure the Transit Gateway route table associated with vpc-app-prod to route 0.0.0.0/0 to the vpc-net-egress attachment.

Answer

Deploy redundant NAT Gateways across Availability Zones in the egress VPC, perform cross-account Private Hosted Zone association using hosted zone association authorization, and route outbound traffic from the application VPC through the Transit Gateway to the egress VPC.

The correct configuration establishes high availability by deploying a NAT Gateway in both Availability Zones in the egress VPC. It also correctly addresses DNS resolution requirements by authorizing and performing a cross-account association of the Private Hosted Zone with the application VPC. Outbound routing is properly set up by pointing the application VPC's default route to the Transit Gateway, routing to the egress VPC attachment, and mapping the attachment subnet route tables to the respective NAT Gateways in each Availability Zone.

Step-by-Step Solution

Ensure Multi-AZ NAT Gateway redundancy.

Two NAT Gateways are deployed in vpc-net-egress, one in us-east-1a and one in us-east-1b.

This guarantees that an outage in one Availability Zone does not disrupt internet connectivity for workloads in the other Availability Zone.

Establish cross-account DNS resolution.

The Shared Services Account authorizes the association of vpc-app-prod with services.corp.internal, and the Application Account accepts the association.

Route 53 Private Hosted Zones require explicit VPC association to allow resolution within consumer VPCs. Simple IP connectivity over Transit Gateway does not automatically enable PHZ DNS resolution.

Configure egress routing through Transit Gateway.

Route tables in vpc-app-prod point 0.0.0.0/0 to tgw-central, the Transit Gateway route table routes 0.0.0.0/0 to the vpc-net-egress attachment, and the TGW attachment subnets in vpc-net-egress route to their local NAT Gateways.

This forces all outbound traffic from the application subnets through the centralized egress VPC where traffic is processed by the NAT Gateways.

Key Concept

Centralized egress and cross-account DNS design using AWS Transit Gateway and Route 53 Private Hosted Zones.

Estimated Time:3m 0s

Question 1017Question →

A media processing platform uses Amazon EC2 instances in an Auto Scaling group to transcode videos. The transcoder fleet retrieves raw video segments from an Amazon S3 bucket and updates metadata about the transcoding progress in an Amazon RDS for PostgreSQL database configured in a Multi-AZ deployment. During peak processing windows, a solutions architect identifies the following bottlenecks:

1. The S3 bucket experiences occasional HTTP 503 (Slow Down) errors due to a high volume of concurrent GET requests for the same popular raw video segments.
2. The EC2 instances, currently running on m6g.2xlarge instances, suffer from high CPU utilization and severe disk write queues when writing large temporary transcoded segments to their EBS gp3 boot volumes.
3. The RDS database CPU utilization spikes due to a large volume of read queries checking the status of transcoding tasks.

Which combination of actions will resolve these performance bottlenecks? (Select TWO.)

Select all that apply

Replace the m6g.2xlarge instances with c6gd.2xlarge instances, and configure the application to write the temporary transcoded segments to the local NVMe instance store volumes.

Deploy an Amazon CloudFront distribution with the Amazon S3 bucket as the origin to cache the raw video segments, and modify the application to retrieve the segments through the CloudFront edge locations.

Direct the read queries checking transcoding progress to the standby instance of the RDS PostgreSQL Multi-AZ deployment to distribute the database read load.

Deploy an Application Load Balancer (ALB) in front of the S3 bucket, and request AWS Support to pre-warm the ALB before peak windows to handle the rate of GET requests.

Configure Amazon ElastiCache for Memcached to replicate and persist the transcoding progress data across multiple Availability Zones to offload the RDS database.

Show answer & explanation

Answer: Replace the m6g.2xlarge instances with c6gd.2xlarge instances, and configure the application to write the temporary transcoded segments to the local NVMe instance store volumes.; Deploy an Amazon CloudFront distribution with the Amazon S3 bucket as the origin to cache the raw video segments, and modify the application to retrieve the segments through the CloudFront edge locations.

Answer

Replace the m6g.2xlarge instances with c6gd.2xlarge instances to use local NVMe instance store volumes for temporary files, and deploy an Amazon CloudFront distribution in front of S3 to cache the raw video segments.

Replacing the instances with c6gd.2xlarge instances optimizes compute-heavy workloads and leverages high-speed local NVMe instance store volumes to bypass EBS gp3 bottleneck limitations. Additionally, caching raw segments using Amazon CloudFront eliminates S3 HTTP 503 errors by preventing excessive direct request rates to the origin bucket.

Step-by-Step Solution

Analyze the EC2 compute and storage bottleneck.

Transcoding is a CPU-intensive operation, and writing temporary files to EBS gp3 boot volumes causes high write queue lengths. Switching to c6gd (compute-optimized with local NVMe SSDs) addresses both bottlenecks by offering faster CPU and local NVMe storage for scratch data.

Resolves local storage write queue limits and improves CPU processing efficiency.

Analyze the S3 throttling issue.

The HTTP 503 (Slow Down) error indicates S3 request limits per prefix have been exceeded due to redundant downloads of popular video segments. Introducing CloudFront to cache these segments reduces the S3 request load.

Prevents S3 rate limiting by serving popular content from edge locations.

Evaluate database scaling options and eliminate invalid choices.

Directing queries to an RDS standby instance is not possible because standard RDS Multi-AZ standbys are passive. Using Memcached for persistent replication is invalid as Memcached does not support persistence or replication.

Eliminates configurations that violate AWS database design constraints.

Key Concept

Optimizing compute, scratch disk, and S3 request performance by using instance store volumes and CDN caching.

Question 1018Question →

An enterprise hosts an application on Amazon EC2 instances inside a private subnet of a VPC. The instances need to download software updates and configurations from Amazon S3. Currently, the subnet route table directs all internet-bound traffic, including requests to Amazon S3, through a NAT Gateway. The security team requires that all data transit to Amazon S3 must remain within the AWS internal network and must not traverse the public internet or the NAT Gateway. Additionally, access to the S3 bucket must be restricted to allow access only from this specific VPC. Which two actions should a solutions architect take to meet these requirements? (Select TWO.)

Select all that apply

Create a gateway VPC endpoint for Amazon S3 in the VPC and associate it with the route tables of the private subnet.

Apply a bucket policy to the Amazon S3 bucket that denies all operations unless the request originates from the specified VPC using the aws:sourceVpc condition.

Enable default encryption on the S3 bucket using the AWS-managed KMS key (aws/s3) and modify the key policy to restrict decryption operations to the EC2 instance role.

Attach the VPC to an AWS Transit Gateway and configure a static route in the subnet route tables pointing the S3 prefix list to the Transit Gateway.

Add a bucket policy to the Amazon S3 bucket that restricts access to requests originating from the public IP address of the NAT Gateway using the aws:SourceIp condition.

Show answer & explanation

Answer: Create a gateway VPC endpoint for Amazon S3 in the VPC and associate it with the route tables of the private subnet.; Apply a bucket policy to the Amazon S3 bucket that denies all operations unless the request originates from the specified VPC using the aws:sourceVpc condition.

Answer

Create a gateway VPC endpoint for Amazon S3 in the VPC and associate it with the route tables of the private subnet. Apply a bucket policy to the Amazon S3 bucket that denies all operations unless the request originates from the specified VPC using the aws:sourceVpc condition.

To route traffic to Amazon S3 internally and avoid the NAT Gateway, a gateway VPC endpoint is required. To restrict S3 bucket access to the VPC, a bucket policy using the aws:sourceVpc condition must be applied. These two actions ensure network isolation and resource security.

Step-by-Step Solution

Configure internal routing for Amazon S3.

Create a gateway VPC endpoint for S3 and associate it with the private subnet's route table.

This updates the route table with a prefix list pointing to the S3 endpoint, routing all traffic internally and bypassing the NAT Gateway.

Apply a resource-based security control to the S3 bucket.

Add an S3 bucket policy that uses the aws:sourceVpc condition to deny access to any requests originating outside the VPC.

This satisfies the requirement to restrict bucket access to only requests coming from the specified VPC.

Key Concept

Gateway VPC endpoints and S3 bucket policies for network isolation

Question 1019Question →

A healthcare provider runs a legacy patient management portal on Amazon EC2 instances managed by an Auto Scaling group across multiple member accounts in an AWS Organization. The portal's web server writes diagnostic audit logs to `/var/log/portal/audit.log`. The portal uses an automated hourly log rotation utility that renames the active file to `/var/log/portal/audit.log.YYYYMMDD-HH` and creates a new empty `/var/log/portal/audit.log` file. The company must centralize these rotated logs in near real-time into an Amazon S3 bucket located in a dedicated Auditing AWS account. The S3 bucket is configured with default encryption using an AWS Key Management Service (AWS KMS) customer managed key (CMK) to comply with health regulations. The logs must first be captured via CloudWatch Logs in each member account and then streamed to the centralized S3 bucket using Amazon Kinesis Data Firehose. Which two actions should the Solutions Architect take to implement this logging architecture while ensuring operational continuity during log rotation and adhering to the principle of least privilege?

Select all that apply

Configure the CloudWatch agent on the EC2 instances by specifying the file path as `/var/log/portal/audit.log*` in the agent configuration file to ensure both active and rotated logs are collected.

Configure Kinesis Data Firehose in each member account to deliver logs to the Auditing account's S3 bucket. Update the S3 bucket policy in the Auditing account to grant `s3:PutObject` permissions to the Firehose IAM role ARN from each member account, and update the KMS CMK policy in the Auditing account to grant `kms:GenerateDataKey` permissions to the same roles.

Configure the CloudWatch agent on the EC2 instances by specifying the static file path as `/var/log/portal/audit.log` in the agent configuration file, relying on the agent's file descriptor tracking to capture rotated files.

Configure Kinesis Data Firehose in each member account to write to the S3 bucket using the AWS-managed KMS key `aws/s3` for encryption, and grant the wildcard principal `*` cross-account access via the S3 bucket policy.

Configure the S3 bucket policy in the Auditing account to allow cross-account writes from the member accounts' roles, but omit modifications to the KMS key policy, relying on S3 bucket key encryption to automatically authorize cross-account write requests.

Show answer & explanation

Answer: Configure the CloudWatch agent on the EC2 instances by specifying the file path as `/var/log/portal/audit.log*` in the agent configuration file to ensure both active and rotated logs are collected.; Configure Kinesis Data Firehose in each member account to deliver logs to the Auditing account's S3 bucket. Update the S3 bucket policy in the Auditing account to grant `s3:PutObject` permissions to the Firehose IAM role ARN from each member account, and update the KMS CMK policy in the Auditing account to grant `kms:GenerateDataKey` permissions to the same roles.

Answer

To implement this architecture successfully, the Solutions Architect must configure the CloudWatch agent with a wildcard path pattern to track rotated files, configure Kinesis Data Firehose to stream the logs, and update both the S3 bucket policy and the KMS customer managed key policy in the Auditing account to allow permissions to the Kinesis Data Firehose roles from the member accounts.

The correct options involve configuring the CloudWatch agent on the EC2 instances with a wildcard path to monitor rotated files, and configuring Kinesis Data Firehose with the required permissions in the Auditing account. The Auditing account's S3 bucket policy must allow writing from the member accounts' Firehose IAM roles, and the customer managed KMS key policy must grant key generation permissions to those same roles to allow encryption of logs upon delivery.

Step-by-Step Solution

Configure the CloudWatch agent config file to use a wildcard pattern for log path tracking.

Ensures that when log rotation occurs hourly and renames the file, the agent continues to read the rotated log and begins reading the new log file without duplicate delivery or log loss.

A static path will only monitor the active file and fail to capture data that was in the process of being sent or rotated, or fail when the file handle changes.

Configure cross-account permissions on the destination S3 bucket in the Auditing account.

Allows Kinesis Data Firehose roles in the member accounts to write log files directly to the S3 bucket.

S3 buckets do not allow cross-account writes by default; a bucket policy must explicitly permit write permissions for the specific IAM role principals.

Configure cross-account permissions on the KMS Customer Managed Key policy in the Auditing account.

Allows Kinesis Data Firehose to generate data keys for encrypting objects during delivery.

Because the S3 bucket is encrypted with a customer managed key, the writing IAM role must have key generation permissions on the key policy. AWS-managed keys cannot be modified and thus cannot support this cross-account configuration.

Key Concept

Aggregating rotated application logs across multiple AWS accounts to a centralized, KMS-encrypted S3 bucket using CloudWatch Agent and Kinesis Data Firehose under the principle of least privilege.

Question 1020Question →

An enterprise is optimizing the disaster recovery (DR) and reliability of a critical multi-tier application. The application is deployed across multiple AWS accounts within an AWS Organization:

* Account A (Application): Hosts the application tier on Amazon EC2 instances inside private subnets of VPC-Prod (in us-east-1) and VPC-DR (in us-west-2).
* Account B (Network): Hosts a centralized Egress-VPC in us-east-1. Outbound traffic from VPC-Prod to third-party payment APIs is routed through an AWS Transit Gateway to the Egress-VPC, which contains a single NAT Gateway.
* Account C (Data): Hosts an Amazon Aurora PostgreSQL Global Database. The primary cluster is in us-east-1 (VPC-Data-Primary), and the secondary cluster is in us-west-2 (VPC-Data-DR). Account C also hosts the Route 53 Private Hosted Zone (PHZ) db.corp.local containing the database endpoints. VPC-Prod is associated with this PHZ.

During a recent regional disaster recovery simulation, the team observed the following failures:
1. A single Availability Zone (AZ) outage in the Egress-VPC caused all outbound payment API requests from VPC-Prod to fail, even though the application instances in other AZs were healthy.
2. The failover of the application tier to us-west-2 exceeded the 15-minute Recovery Time Objective (RTO) because database promotion was triggered manually and DNS updates took too long to propagate.
3. The standby application instances in VPC-DR failed to resolve the database endpoints in db.corp.local.

The enterprise requires an RTO of under 10 minutes and a Recovery Point Objective (RPO) of under 1 minute.

Which combination of actions will resolve these issues and meet the target RTO and RPO?

In Account B, deploy a NAT Gateway in each Availability Zone of the Egress-VPC. Configure the route tables of the Transit Gateway subnets in each AZ to route outbound internet traffic to the local NAT Gateway. Create an AWS Lambda function triggered by a CloudWatch Alarm every 15 minutes to monitor replication lag, delete the global database, promote the secondary cluster, and update Route 53. In Account C, share the PHZ db.corp.local with Account A using AWS Resource Access Manager (RAM) and associate it.

In Account B, maintain the single NAT Gateway and configure a VPC peering connection between VPC-Prod and Egress-VPC to bypass the Transit Gateway. Use AWS Backup to perform daily cross-Region backups of the Aurora PostgreSQL database, restore the database from the backup in us-west-2 during a failover, and update Route 53. In Account A, authorize the association of VPC-DR with the PHZ db.corp.local. In Account C, associate VPC-DR with db.corp.local.

In Account B, deploy a NAT Gateway in each Availability Zone of the Egress-VPC. Configure the route tables of the Transit Gateway subnets in each AZ to route outbound internet traffic to the NAT Gateway in the same AZ. Use AWS Route 53 Application Recovery Controller (ARC) routing controls to manage application traffic failover, and initiate an Aurora Global Database managed failover to promote the secondary database cluster. In Account C, authorize the association of VPC-DR with db.corp.local. In Account A, associate VPC-DR with db.corp.local.

In Account B, configure a Route 53 resolver endpoint in the Egress-VPC to perform active-passive failover between NAT Gateways. Configure Amazon Route 53 active-passive failover routing policies with basic Route 53 health checks directly monitoring the Aurora cluster's primary endpoint. In Account A, create a duplicate Private Hosted Zone named db.corp.local and manually replicate the database CNAME records to point to the secondary cluster's endpoints.

Show answer & explanation

Answer: In Account B, deploy a NAT Gateway in each Availability Zone of the Egress-VPC. Configure the route tables of the Transit Gateway subnets in each AZ to route outbound internet traffic to the NAT Gateway in the same AZ. Use AWS Route 53 Application Recovery Controller (ARC) routing controls to manage application traffic failover, and initiate an Aurora Global Database managed failover to promote the secondary database cluster. In Account C, authorize the association of VPC-DR with db.corp.local. In Account A, associate VPC-DR with db.corp.local.

Answer

Deploy a NAT Gateway per Availability Zone in the Egress-VPC, configure Transit Gateway subnet route tables for AZ affinity, use AWS Route 53 Application Recovery Controller (ARC) and Aurora managed failover to orchestrate rapid recovery, and perform a proper cross-account Private Hosted Zone association by creating an authorization in the hosted zone's account and accepting it in the application's account.

The correct solution resolves all three failure points. First, it eliminates the egress single point of failure by deploying redundant NAT Gateways per AZ and configuring local route tables. Second, it utilizes Route 53 ARC to handle rapid DNS-level failover for the application tier, coupled with Aurora Global Database managed failover to promote the secondary database cluster, satisfying the strict RTO and RPO. Third, it correctly sets up cross-account Private Hosted Zone association using the authorize-and-associate workflow, enabling VPC-DR to resolve database endpoints securely.

Step-by-Step Solution

Ensure egress redundancy by deploying a NAT Gateway in each Availability Zone of the centralized Egress-VPC in Account B and mapping subnet route tables locally.

VPC-Prod outbound traffic continues to function even if a single NAT Gateway or AZ in the Egress-VPC fails.

This isolates AZ failures and prevents an outage in one zone from affecting egress traffic generated by healthy application instances in other zones.

Orchestrate disaster recovery failover by utilizing Route 53 Application Recovery Controller (ARC) routing controls for the application layer and initiating an Aurora Global Database managed failover.

Application routing is redirected within seconds, and the secondary database cluster in us-west-2 is promoted to primary with minimal data loss.

Route 53 ARC provides high-availability routing controls that update DNS routing without TTL delay. Aurora managed failover promotes the standby database cluster safely to meet the under 10-minute RTO and under 1-minute RPO.

Associate VPC-DR in Account A with the Route 53 Private Hosted Zone db.corp.local in Account C by running create-vpc-association-authorization in Account C, and then running associate-vpc-with-hosted-zone in Account A.

Standby application instances in VPC-DR can resolve internal database endpoints using the central PHZ.

For cross-account Private Hosted Zone association, the owner of the hosted zone must explicitly authorize the target VPC before the owner of the VPC can complete the association.

Key Concept

Cross-Region Disaster Recovery, NAT Gateway Redundancy, and Cross-Account Route 53 Private Hosted Zone Association

Estimated Time:3m 0s

PreviousPage 51 / 99Next

All practice questions

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept