All practice questions

1964 questions

All types1,964 Multiple choice1,006 Multiple select931 Ordering27

A global e-commerce analytics enterprise is designing a transaction logging platform. The primary infrastructure must run in us-east-1 with a disaster recovery (DR) site in us-west-2. The business requirements specify a Recovery Time Objective (RTO) of 5 minutes, a Recovery Point Objective (RPO) of 1 minute, and a strict requirement that public client traffic be routed based on user geolocation under normal circumstances, with automated failover if a regional endpoint degrades. The solution must minimize cost where possible while ensuring high availability across Availability Zones for outbound regulatory compliance logging. Which two of the following architectural configurations must the Solutions Architect implement to satisfy these requirements?

Select all that apply

Deploy an Amazon Aurora Global Database with the primary cluster in us-east-1 and a secondary cluster in us-west-2. In a disaster recovery event, use AWS Route 53 Application Recovery Controller (ARC) to initiate a failover and promote the secondary cluster to primary write status.

Create Route 53 Geolocation routing records at the root domain level pointing to Route 53 Failover routing records for each region. Configure the failover records to direct traffic to regional Application Load Balancers, associated with Route 53 health checks of the local application stack.

Deploy a single NAT Gateway in one public subnet of each region's VPC, configuring the route tables of all private subnets across multiple Availability Zones to route egress traffic through this gateway to reduce costs.

Configure a Route 53 Private Hosted Zone for the public domain and associate it with the VPCs in both regions, using latency-based routing policies to distribute incoming external client requests to the nearest regional load balancer.

Establish a Multi-AZ Amazon RDS PostgreSQL instance in us-east-1 with cross-region read replicas in us-west-2. Enable Aurora replica auto-scaling on the standby database instances to handle write transactions immediately after failover.

Utilize a Pilot Light disaster recovery strategy by scheduling database snapshots every hour, replicating them to us-west-2, and maintaining a stopped set of Amazon EC2 application instances in us-west-2 that are started via AWS Lambda during failover.

Show answer & explanation

Answer: Deploy an Amazon Aurora Global Database with the primary cluster in us-east-1 and a secondary cluster in us-west-2. In a disaster recovery event, use AWS Route 53 Application Recovery Controller (ARC) to initiate a failover and promote the secondary cluster to primary write status.; Create Route 53 Geolocation routing records at the root domain level pointing to Route 53 Failover routing records for each region. Configure the failover records to direct traffic to regional Application Load Balancers, associated with Route 53 health checks of the local application stack.

Answer

Deploy an Amazon Aurora Global Database with Route 53 Application Recovery Controller (ARC) for database failover, and configure nested Route 53 Geolocation and Failover routing records to direct traffic to regional Application Load Balancers.

The correct architecture uses Amazon Aurora Global Database to achieve sub-second data replication across regions, meeting the 1-minute RPO, and relies on AWS Route 53 Application Recovery Controller (ARC) to quickly promote the secondary cluster during a failover to meet the 5-minute RTO. For routing, nesting Geolocation routing records to point to regional Failover records ensures traffic is routed by location under normal operations while enabling failover to the alternate region if the local ALB health check fails.

Step-by-Step Solution

Analyze RTO and RPO limits to select the database replication strategy.

Amazon Aurora Global Database provides asynchronous replication with lag under 1 second, matching the 1-minute RPO. Coordinated failover using Route 53 Application Recovery Controller ensures the secondary cluster can be promoted in under a minute, matching the 5-minute RTO.

Standard replication methods or snapshot copies fail the RPO and RTO bounds.

Evaluate global DNS routing and failover requirements.

Configure root Geolocation records pointing to nested regional Failover records. Associate health checks with the regional Application Load Balancers.

This setup allows Route 53 to perform geolocation routing under normal operation, but dynamically fail over to the secondary region if a whole region becomes degraded.

Determine the high availability requirements for NAT Gateways.

To ensure high availability across Availability Zones, a NAT Gateway must be deployed in each Availability Zone where outbound egress is needed.

Deploying a single NAT Gateway introduces a single point of failure for instances running in other Availability Zones.

Key Concept

Multi-region high availability and disaster recovery design combining database replication and DNS failover strategies to meet strict RTO and RPO targets.

Question 302Question →

A global sports streaming service plans to launch a real-time commentary portal for a major tournament finals. The portal will experience a predictable but sudden increase in read traffic, surging from a baseline of $2,000$ requests per minute to over $1,500,000$ requests per minute in less than ten minutes. The backend application runs on Amazon ECS using AWS Fargate, and reads from an Amazon Aurora PostgreSQL database. High performance, sub-second latency, and zero dropped requests are critical requirements during the tournament. Which architecture design optimization should a solutions architect recommend to ensure the system scales efficiently under this load?

Deploy Amazon ElastiCache for Redis to cache database queries, and contact AWS Support to pre-warm the Application Load Balancer (ALB) before the tournament begins.

Configure Amazon Aurora replicas with Auto Scaling to handle the read queries, and rely on the Application Load Balancer (ALB) default auto-scaling to absorb the rapid traffic surge.

Enable Multi-AZ deployment for the Amazon Aurora database, and direct read traffic to the standby DB instance during peak traffic hours.

Configure an Application Load Balancer (ALB) with an ECS Auto Scaling policy that has a scaling cooldown period of 15 seconds to ensure rapid container deployment.

Show answer & explanation

Answer: Deploy Amazon ElastiCache for Redis to cache database queries, and contact AWS Support to pre-warm the Application Load Balancer (ALB) before the tournament begins.

Answer

Deploy Amazon ElastiCache for Redis to cache database queries, and contact AWS Support to pre-warm the Application Load Balancer (ALB) before the tournament begins.

The correct answer combines caching with database query offloading and load balancer pre-warming. Deploying Amazon ElastiCache for Redis offloads high-volume read traffic from the Aurora database, keeping latency sub-second. Requesting ALB pre-warming from AWS Support prepares the load balancer to handle the sudden burst of

1,500,000

requests per minute immediately, ensuring zero dropped requests.

Step-by-Step Solution

Analyze the load profile and traffic requirements.

Identify that the system experiences a massive, instantaneous read traffic spike (

2,000

1,500,000

requests per minute).

This establishes that default elastic scaling of the Application Load Balancer is insufficient and database queries must be cached to prevent bottlenecking.

Select the appropriate caching strategy for database reads.

Introduce Amazon ElastiCache for Redis to offload the read traffic from Amazon Aurora.

Caching read results at the database tier ensures sub-second latency and keeps database CPU usage within bounds.

Address the sudden traffic burst handling at the load balancer tier.

Request ALB pre-warming from AWS Support prior to the event.

ALB pre-warming configures the load balancer to handle the anticipated spike without dropping initial packets while waiting for auto-scaling to trigger.

Key Concept

Handling sudden, massive traffic bursts (flash traffic) requires pre-provisioning or pre-warming load balancers and implementing caching strategies like Amazon ElastiCache to offload reads from database engines.

Estimated Time:2m 0s

Question 303Question →

A company is designing a new reporting dashboard that queries a relational database. The application experiences a high volume of read-only queries during business hours. Additionally, at the beginning of each month, the application experiences a sudden, massive spike in users accessing the system within a few minutes. Which two solutions should the solutions architect implement to ensure the application remains scalable and performant during these times? (Select TWO.)

Select all that apply

Deploy database read replicas to handle the high volume of read-only queries.

Request pre-warming of the Application Load Balancer from AWS Support before the scheduled monthly traffic spikes.

Enable Multi-AZ deployment for the database and route read queries to the standby instance.

Rely on standard Application Load Balancer auto-scaling to automatically scale out during the sudden traffic spikes.

Decrease the Auto Scaling group cooldown period to be shorter than the instance initialization time to add instances faster.

Show answer & explanation

Answer: Deploy database read replicas to handle the high volume of read-only queries.; Request pre-warming of the Application Load Balancer from AWS Support before the scheduled monthly traffic spikes.

Answer

Deploy database read replicas to handle the high volume of read-only queries, and request pre-warming of the Application Load Balancer from AWS Support before the scheduled monthly traffic spikes.

Deploying read replicas allows the application to offload read-heavy query traffic from the primary database instance. Requesting Application Load Balancer (ALB) pre-warming ensures that the load balancer has sufficient capacity configured in advance to handle the sudden, massive traffic spike at the start of the month, preventing dropped connections.

Step-by-Step Solution

Analyze the database workload query type.

Identify that the primary bottleneck during business hours is read-only query traffic.

This guides the selection of read-scaling mechanisms, such as read replicas, rather than write-scaling or high-availability features.

Assess the performance characteristics of the load balancer under flash traffic conditions.

Understand that the monthly traffic spike occurs instantly and that standard load balancer auto-scaling takes time to provision capacity.

This establishes the need for pre-warming the Application Load Balancer to avoid dropped requests during sudden spikes.

Combine the database and load balancer scaling strategies.

Implement read replicas for daily performance and ALB pre-warming for scheduled traffic surges.

This provides a comprehensive optimization architecture that addresses both database and traffic scalability concerns.

Key Concept

Scaling read-heavy database workloads and handling sudden flash traffic load balancing spikes.

Alternative Method

For database read scaling, Amazon ElastiCache could be deployed in front of the database to cache common query results, reducing the query load on the database engine. However, implementing database read replicas is a more direct database-native solution for offloading read traffic.

Estimated Time:2m 0s

Question 304Question →

A municipal utility provider is deploying a new smart-meter data collection platform. The architecture resides in two AWS Regions, using us-east-1 as primary and us-west-2 as secondary. The backend database requires a Recovery Point Objective (RPO) of 1 minute and a Recovery Time Objective (RTO) of 15 minutes. The web application tier runs on Amazon EC2 instances in private subnets, which require continuous egress to public external APIs for device validation. Which multi-region configuration meets these requirements while minimizing operational complexity and cost?

Deploy Amazon Aurora Global Database with the primary writer in us-east-1 and a read replica in us-west-2. Deploy redundant NAT Gateways across multiple Availability Zones in each Region's VPC. Use Route 53 Failover routing policies with active health checks to manage DNS failover.

Deploy Amazon Aurora Global Database with the primary writer in us-east-1 and a read replica in us-west-2. Deploy a single NAT Gateway in each Region to route egress traffic from all private subnets. Use Route 53 Failover routing policies with active health checks to manage DNS failover.

Deploy a single-region Amazon Aurora cluster in us-east-1 and configure hourly AWS Backup copies to us-west-2. Deploy redundant NAT Gateways across multiple Availability Zones in each Region's VPC. Configure Route 53 Failover routing policies to redirect traffic to us-west-2 where the database will be restored from backup during an outage.

Show answer & explanation

Answer: Deploy Amazon Aurora Global Database with the primary writer in us-east-1 and a read replica in us-west-2. Deploy redundant NAT Gateways across multiple Availability Zones in each Region's VPC. Use Route 53 Failover routing policies with active health checks to manage DNS failover.

Answer

The correct solution combines Amazon Aurora Global Database to achieve low-latency replication (meeting the 1-minute RPO) and fast failover (meeting the 15-minute RTO), redundant NAT Gateways across Availability Zones to avoid a single point of failure for outbound internet traffic, and Route 53 Failover routing policies with active health checks to automate the redirection of user traffic.

Step-by-Step Solution

Select the database replication strategy based on RPO and RTO.

Amazon Aurora Global Database provides millisecond-level replication lag to the secondary region and supports rapid promotion of the secondary cluster (typically under 1 minute), which satisfies both the 1-minute RPO and 15-minute RTO.

Traditional backup-and-restore or standard cross-region snapshot copy methods cannot meet the 1-minute RPO or the 15-minute RTO.

Ensure outbound connectivity redundancy for the application tier in private subnets.

Redundant NAT Gateways must be deployed in each Availability Zone in both regions.

A single NAT Gateway per VPC is a single point of failure; if the Availability Zone containing the NAT Gateway fails, resource connectivity to external APIs from other Availability Zones is lost.

Configure DNS routing and automated failover mechanics.

Use Route 53 Failover routing policies configured with health checks pointing to the application endpoints.

Active health checks allow Route 53 to automatically detect a regional outage and reroute traffic without manual intervention, helping to ensure the 15-minute RTO is met.

Key Concept

Disaster Recovery pattern selection combined with multi-AZ network redundancy and DNS routing failover configurations.

Question 305Question →

A logistics company is launching a real-time parcel routing and verification system. The system must process coordinates and tracking updates from delivery agents. The system expects a baseline load of $2,000$ requests per second, which instantly surges to $45,000$ requests per second during shift-change windows at 08:00 and 17:00 daily. The application runs on Amazon ECS Fargate behind an Application Load Balancer. The system requires a low-latency, replication-enabled cache to store persistent session states, and writes are recorded to an Amazon Aurora PostgreSQL database. Which combination of architectural decisions will optimize the system's performance and scalability for these spikes? (Select TWO.)

Select all that apply

Request AWS Support to pre-warm the Application Load Balancer to the expected peak of

45,000

requests per second before the scheduled shift-change windows.

Use Amazon ElastiCache for Redis with Multi-AZ enabled to store the persistent session states.

Deploy Amazon ElastiCache for Memcached with multi-AZ replication enabled to store the persistent session states.

Rely on the Application Load Balancer's default dynamic scaling to handle the instant spike from

2,000

45,000

requests per second.

Configure Aurora Auto Scaling to dynamically provision additional Multi-AZ standby database instances to distribute the read query load.

Show answer & explanation

Answer: Request AWS Support to pre-warm the Application Load Balancer to the expected peak of $45,000$ requests per second before the scheduled shift-change windows.; Use Amazon ElastiCache for Redis with Multi-AZ enabled to store the persistent session states.

Answer

The solutions architect should request AWS Support to pre-warm the Application Load Balancer before the shift-change windows and deploy Amazon ElastiCache for Redis with Multi-AZ enabled to store the persistent session states.

To handle instantaneous spikes from

2,000

45,000

requests per second, the Application Load Balancer must be pre-warmed by AWS Support, as normal auto-scaling is too slow. Additionally, Amazon ElastiCache for Redis is the correct caching technology to store persistent session states because it supports both data persistence and Multi-AZ replication.

Step-by-Step Solution

Analyze the load profile and caching requirements.

The traffic spikes instantly from

2,000

45,000

requests per second. The session store requires persistence, low-latency, and multi-AZ replication.

This establishes the constraints for load balancing scaling speed and the cache engine choice.

Select the appropriate caching technology.

Amazon ElastiCache for Redis is selected because Memcached does not support persistence or replication.

Ensures the cache can persist data and remain highly available across multiple Availability Zones.

Address the sudden traffic spike at the load balancer layer.

Requesting ELB pre-warming is selected over relying on dynamic scaling.

Standard ELB auto-scaling is too slow to handle massive, instantaneous spikes, which leads to dropped connections during the scaling delay.

Key Concept

Handling massive, instantaneous traffic spikes with ELB pre-warming and choosing the correct replication-capable caching layer.

Estimated Time:2m 0s

Question 306Question →

An enterprise is designing a highly available hybrid network architecture for its multi-account AWS environment across two regions: $us-east-1$ (primary) and $us-west-2$ (secondary). The network architecture consists of an AWS Transit Gateway in each region, connected via a Transit Gateway peering attachment. The on-premises network has two data centers: one in New York and one in Chicago.

The New York data center connects to the $us-east-1$ Transit Gateway via a 10 Gbps AWS Direct Connect connection using a Transit VIF terminated on a central Direct Connect Gateway. The Chicago data center connects to the $us-west-2$ Transit Gateway in the same manner. To ensure disaster recovery capability, the enterprise deploys redundant IPsec VPN connections from both data centers to the Transit Gateways in their respective local regions.

The company's routing policy has the following constraints:
- Under normal operating conditions, all traffic between the VPCs in $us-east-1$ and the New York data center must use the local Direct Connect path.
- If the Direct Connect connection in $us-east-1$ fails, traffic between $us-east-1$ and the New York data center must immediately fail over to the local IPsec VPN connection. It must NOT route through the peered Transit Gateway in $us-west-2$ to avoid high inter-region data transfer charges and latency.
- Only if both the local Direct Connect and the local IPsec VPN connections in $us-east-1$ fail should traffic fail over transitively through the Transit Gateway peering connection to use the hybrid paths in $us-west-2$ .

Which TWO configurations must the Solutions Architect implement to satisfy these routing requirements?

Select all that apply

On the on-premises routers, advertise specific subnets (such as /24 prefixes) via BGP over both the local Direct Connect Transit VIFs and the local IPsec VPN tunnels, and configure a static route for the summary corporate network range (such as a /16 prefix) pointing to the Transit Gateway peering attachment in each region's Transit Gateway route table.

Configure the customer gateway routers to assign the highest BGP Local Preference to routes for the local AWS region's VPC CIDR received over the local Direct Connect path, a medium Local Preference to routes received over the local IPsec VPN, and the lowest Local Preference to routes received via the remote region's Direct Connect and VPN paths.

Enable dynamic BGP route propagation across the Transit Gateway peering attachment, and configure BGP Local Preference attributes within the Transit Gateway route tables to prioritize the Direct Connect path over the local IPsec VPN path.

Deploy a single, non-redundant NAT Gateway in a shared services VPC in us-east-1 to route all outbound corporate traffic, and configure the on-premises routers to prioritize the IPsec VPN tunnels by advertising more specific subnets over the VPN than over the Direct Connect Transit VIFs.

Create a single Route 53 Private Hosted Zone (PHZ) in the network account, associate it with the Transit Gateway peering attachment, and rely on the peered Transit Gateways to automatically route DNS queries and VPC-to-VPC traffic without associating the PHZ with the VPCs in the spoke accounts.

Show answer & explanation

Answer: On the on-premises routers, advertise specific subnets (such as /24 prefixes) via BGP over both the local Direct Connect Transit VIFs and the local IPsec VPN tunnels, and configure a static route for the summary corporate network range (such as a /16 prefix) pointing to the Transit Gateway peering attachment in each region's Transit Gateway route table.; Configure the customer gateway routers to assign the highest BGP Local Preference to routes for the local AWS region's VPC CIDR received over the local Direct Connect path, a medium Local Preference to routes received over the local IPsec VPN, and the lowest Local Preference to routes received via the remote region's Direct Connect and VPN paths.

Answer

Configure on-premises routers to advertise specific subnets via BGP over both local Direct Connect and local VPN connections, and configure a static route for the summary corporate network range pointing to the Transit Gateway peering attachment in each region. Additionally, configure the customer gateway routers to assign BGP Local Preference hierarchically, prioritizing the local Direct Connect, followed by the local VPN, and setting the lowest preference for the remote region's paths.

The correct answer combines BGP local preference on-premises and longest prefix match (LPM) routing in AWS Transit Gateway. By advertising specific /24 subnets over the local Direct Connect and IPsec VPN, the local Transit Gateway will prefer these local paths because their prefixes are more specific than the static summary /16 route pointing to the Transit Gateway peering attachment. If both local paths fail, the /24 prefixes are withdrawn, allowing traffic to fail over to the /16 summary route via the peered Transit Gateway. The customer gateway configuration ensures that return traffic from the on-premises network prefers the local Direct Connect, then the local VPN, and only uses the remote region's paths when all local options are exhausted.

Step-by-Step Solution

Configure BGP Local Preference on the on-premises customer gateway (CGW) routers.

On-premises routers will prefer the local Direct Connect first, local IPsec VPN second, and the remote region's Direct Connect/VPN paths only as a last resort for outbound traffic to AWS VPCs.

This guarantees correct failover order and avoids asymmetric routing for traffic entering AWS.

Advertise specific subnets (e.g., /24 prefixes) via BGP from the on-premises routers over both the local Direct Connect Transit VIF and the local IPsec VPN.

These specific prefixes are dynamically propagated to the local Transit Gateway's spoke VPC route table.

By propagating specific subnets, we ensure that the local Transit Gateway prefers local paths over any summary static routes due to Longest Prefix Match (LPM) rules.

Configure a static summary route (e.g., /16 prefix) pointing to the Transit Gateway peering attachment in the spoke VPC route tables of both Transit Gateways.

A backup path is established across the peering connection for times when local routes are unavailable.

Since the static route is for a broader CIDR block (/16) than the dynamically propagated local routes (/24), it remains inactive for local traffic. It only becomes active if both local paths fail, causing the specific /24 routes to be withdrawn.

Key Concept

Combining Longest Prefix Match (LPM) with dynamic BGP propagation and summary static routing to implement selective failover across peered Transit Gateways.

Estimated Time:3m 0s

Question 307Question →

An enterprise is designing a serverless deployment pipeline for a critical payment gateway service. The service is built using AWS Lambda and Amazon API Gateway, and it persists transactions in an Amazon DynamoDB table. The deployment strategy must satisfy the following constraints:

* Deployments must be fully automated with zero downtime.
* Traffic must shift gradually: $10\%$ of the traffic must route to the new version of the Lambda function for a $20$ -minute evaluation period. If no issues are detected, the remaining $90\%$ must shift immediately.
* If the API Gateway $5\text{xx}$ error rate or the Lambda function error rate exceeds $1\%$ during the evaluation period, the deployment must automatically roll back within minutes.
* The DynamoDB schema updates must not disrupt the active or deploying versions of the Lambda function.

Which two actions should the Solutions Architect take to implement this deployment strategy? (Select two.)

Select all that apply

Configure the AWS CodeDeploy deployment group to use a custom deployment configuration on the Lambda compute platform, specifying a canary traffic shifting type with a

10\%

traffic percentage and a

20

-minute evaluation time.

Configure the Amazon API Gateway integration to point to a specific Lambda function alias, and associate CloudWatch alarms monitoring Lambda errors and API Gateway

5\text{xx}

errors as rollback triggers in the AWS CodeDeploy deployment group.

Configure the Amazon API Gateway integration to point to the Lambda function's LATEST version, and use API Gateway stage canary deployment settings to route

10\%

of the traffic to a new deployment stage for a

20

-minute evaluation.

Configure AWS CodePipeline to invoke an AWS Step Functions state machine that loops for

20

minutes, using the AWS SDK to incrementally update the traffic weight of the API Gateway stage variable mapping to the LATEST version.

Deploy an Application Load Balancer (ALB) to target two separate target groups, each referencing a different version of the Lambda function, and use AWS CodeDeploy with the EC2 compute platform to manage weight shifting between target groups.

Show answer & explanation

Answer: Configure the AWS CodeDeploy deployment group to use a custom deployment configuration on the Lambda compute platform, specifying a canary traffic shifting type with a $10\%$ traffic percentage and a $20$ -minute evaluation time.; Configure the Amazon API Gateway integration to point to a specific Lambda function alias, and associate CloudWatch alarms monitoring Lambda errors and API Gateway $5\text{xx}$ errors as rollback triggers in the AWS CodeDeploy deployment group.

Answer

Configure the AWS CodeDeploy deployment group to use a custom deployment configuration on the Lambda compute platform, specifying a canary traffic shifting type with a 10% traffic percentage and a 20-minute evaluation time. Also, configure the Amazon API Gateway integration to point to a specific Lambda function alias, and associate CloudWatch alarms monitoring Lambda errors and API Gateway 5xx errors as rollback triggers in the AWS CodeDeploy deployment group.

To achieve a custom 20-minute canary deployment with automated rollbacks for an API Gateway and Lambda application, the Solutions Architect must use AWS CodeDeploy. API Gateway must point to a specific Lambda alias because CodeDeploy manages traffic shifting at the alias level. Because there is no default 20-minute canary deployment configuration in CodeDeploy, a custom deployment configuration on the Lambda compute platform must be created. CloudWatch alarms monitoring Lambda errors and API Gateway 5xx errors must be attached to the CodeDeploy deployment group as rollback triggers to automate the rollback process if thresholds are crossed.

Step-by-Step Solution

Select the correct integration target for API Gateway to support traffic shifting.

API Gateway must be integrated with a Lambda function alias rather than the mutable LATEST reference, allowing AWS CodeDeploy to control the traffic distribution between the old and new versions.

Traffic routing weights can only be applied to Lambda aliases, and CodeDeploy relies on these aliases to shift traffic during deployment.

Define a deployment configuration that meets the custom shifting window.

Since AWS CodeDeploy does not provide a pre-defined 20-minute canary configuration, a custom deployment configuration must be created specifying a canary type with 10% shifted for 20 minutes.

This directly meets the business requirement of a 20-minute canary evaluation phase before routing the remaining traffic.

Configure the monitoring and rollback mechanisms.

Attach CloudWatch alarms that monitor API Gateway 5xx errors and Lambda execution errors to the CodeDeploy deployment group's rollback triggers.

This guarantees that if the error rates exceed the defined 1% threshold, CodeDeploy will automatically roll back the deployment and restore all traffic to the previous version immediately.

Key Concept

AWS Lambda deployment traffic shifting using CodeDeploy and Lambda aliases with automated CloudWatch rollbacks.

Question 308Question →

An enterprise is designing a centralized identity federation strategy for its multi-account AWS environment managed under AWS Organizations. The security team is configuring an external SAML 2.0 Identity Provider (IdP) to allow corporate users to authenticate and assume IAM roles in member accounts. The architecture must support Attribute-Based Access Control (ABAC) by dynamically passing user department tags from the IdP to the target AWS sessions. Additionally, central administrators must enforce guardrails that prevent member account administrators from altering the federation setup, while still requiring member account administrators to manage local resource permissions. Which combination of actions must the solutions architect perform to meet these requirements? (Select TWO.)

Select all that apply

Configure the external SAML IdP to pass the department attribute as a session tag using the claim name 'https://aws.amazon.com/SAML/Attributes/PrincipalTag:Department'. In the member accounts, configure the trust policy of the target IAM roles to allow the 'sts:AssumeRoleWithSAML' and 'sts:TagSession' actions for the SAML provider principal.

Configure the external SAML IdP to pass the department attribute as a session tag using the claim name 'https://aws.amazon.com/SAML/Attributes/PrincipalTag:Department'. In the member accounts, configure the trust policy of the target IAM roles to allow 'sts:AssumeRole' and 'sts:TagSession' actions for the SAML provider principal.

Create a Service Control Policy (SCP) and attach it to the organization's root to deny 'iam:DeleteSAMLProvider' and 'iam:UpdateSAMLProvider' actions. Ensure that local IAM policies in the member accounts explicitly grant resource-level permissions to the federated roles.

Create a Service Control Policy (SCP) and attach it to the Organizational Unit (OU) containing the member accounts to allow resource access for federated roles containing the 'aws:PrincipalTag/Department' condition, eliminating the need for local IAM policies to grant permissions.

Configure the SAML assertion to include the user's department in the Subject NameID attribute. In the member accounts, construct local IAM policies that use the 'aws:username' policy variable to dynamically restrict access based on the department value.

Show answer & explanation

Answer: Configure the external SAML IdP to pass the department attribute as a session tag using the claim name 'https://aws.amazon.com/SAML/Attributes/PrincipalTag:Department'. In the member accounts, configure the trust policy of the target IAM roles to allow the 'sts:AssumeRoleWithSAML' and 'sts:TagSession' actions for the SAML provider principal.; Create a Service Control Policy (SCP) and attach it to the organization's root to deny 'iam:DeleteSAMLProvider' and 'iam:UpdateSAMLProvider' actions. Ensure that local IAM policies in the member accounts explicitly grant resource-level permissions to the federated roles.

Answer

Configure the external SAML IdP to pass the department attribute as a session tag under the PrincipalTag namespace, update target IAM role trust policies to allow the 'sts:AssumeRoleWithSAML' and 'sts:TagSession' actions, and create an SCP at the organization's root to prevent modification of the SAML provider while relying on local member account IAM policies to grant access.

The correct solution involves mapping the department attribute to the 'https://aws.amazon.com/SAML/Attributes/PrincipalTag:Department' claim in the SAML assertion, updating the trust policy of the IAM roles in member accounts to permit both 'sts:AssumeRoleWithSAML' and 'sts:TagSession', and applying an SCP at the organization's root to prevent modification of the SAML provider while leaving local resource permission configuration to local IAM policies. This satisfies all administrative and Attribute-Based Access Control (ABAC) requirements.

Step-by-Step Solution

Enable session tags in the SAML assertion by configuring the Identity Provider.

Attributes are mapped to the 'https://aws.amazon.com/SAML/Attributes/PrincipalTag:Department' claim.

This specific namespace tells AWS to ingest the SAML attributes as session tags, which can then be evaluated dynamically via the 'aws:PrincipalTag/Department' condition key in policies.

Update the IAM role trust policy in the target member accounts to authorize the federation process and tag ingestion.

The trust policy allows the 'sts:AssumeRoleWithSAML' action for the SAML provider and includes the 'sts:TagSession' action.

SAML federation requires the trust policy to permit the 'sts:AssumeRoleWithSAML' action, and passing principal tags requires the 'sts:TagSession' action to be explicitly authorized in the trust relationship.

Implement organization-wide guardrails using a Service Control Policy (SCP) at the root level.

A policy is applied that denies modification or deletion of the SAML provider ('iam:DeleteSAMLProvider', 'iam:UpdateSAMLProvider').

This prevents administrators in the member accounts from bypassing or deleting the identity federation setup, ensuring compliance with central security requirements.

Define local permissions in the member accounts.

IAM policies are attached to the federated roles in member accounts to grant access to specific AWS resources based on the department session tag.

Since SCPs can only restrict permissions and do not grant them, local IAM policies are required in each member account to provide the actual access.

Key Concept

Centralized SAML 2.0 Identity Federation with Session Tags (ABAC) and SCP Guardrails

Estimated Time:3m 0s

Question 309Question →

A company is designing a disaster recovery (DR) architecture on AWS for a mission-critical web application. The application requires a Recovery Time Objective (RTO) of 15 minutes and a Recovery Point Objective (RPO) of 5 minutes. The architecture must minimize ongoing standby infrastructure costs while still meeting the RTO and RPO. Which strategy should a solutions architect recommend to meet these requirements?

Configure a Warm Standby DR pattern in a secondary AWS Region by running a scaled-down deployment of the application tier and continuously replicating the database tier. Use Route 53 Failover routing with health checks to redirect traffic to the secondary region during an outage, and scale up the application tier upon failover.

Configure a Pilot Light DR pattern in a secondary AWS Region by replicating the database tier but keeping the application tier completely shut down. Use Route 53 Latency routing with health checks to automatically provision the application tier from Amazon Machine Images (AMIs) during a failover event.

Configure a Backup and Restore DR pattern using cross-region Amazon Aurora snapshots scheduled every 4 hours. Configure Route 53 Failover routing to direct users to a static website hosted in Amazon S3 until the database and application are fully restored in the secondary region.

Configure a Multi-Region Active-Active DR pattern by deploying identical, fully-scaled application tiers in both regions. Configure Route 53 Geolocation routing to distribute traffic, and use Amazon RDS Multi-AZ standby instances in the secondary region to serve read traffic during normal operations to offset standby costs.

Show answer & explanation

Answer: Configure a Warm Standby DR pattern in a secondary AWS Region by running a scaled-down deployment of the application tier and continuously replicating the database tier. Use Route 53 Failover routing with health checks to redirect traffic to the secondary region during an outage, and scale up the application tier upon failover.

Answer

The Warm Standby disaster recovery strategy meets the RPO of 5 minutes by continuously replicating the database to a secondary region. It satisfies the 15-minute RTO by maintaining a pre-provisioned, scaled-down application tier that can quickly scale up under load. This approach minimizes ongoing costs compared to a fully-scaled Active-Active deployment, and utilizes Route 53 Failover routing to automate redirection when the primary region is degraded.

Step-by-Step Solution

Analyze the RPO requirement to determine database replication needs.

An RPO of 5 minutes necessitates real-time or continuous database replication. This rules out Backup and Restore strategies that rely on periodic snapshots.

Periodic backups cannot guarantee a maximum data loss window of 5 minutes.

Analyze the RTO requirement to determine application-tier readiness.

An RTO of 15 minutes requires application servers to be already running (even at a reduced scale) so they can handle traffic quickly. This rules out Pilot Light, which requires provisioning and bootstrapping instances from scratch.

Bootstrapping instances from AMIs during a failover event typically exceeds 15 minutes.

Evaluate the remaining options based on cost and architectural validity.

Warm Standby runs at a reduced scale, minimizing cost compared to Active-Active which runs fully-scaled environments. Additionally, RDS Multi-AZ replication cannot span across regions or serve read traffic, making the Active-Active option architecturally invalid.

Warm Standby is the most cost-effective valid strategy that meets all constraints.

Key Concept

Disaster recovery pattern selection based on RTO, RPO, and cost constraints.

Question 310Question →

An enterprise is planning to establish a governed, multi-account AWS environment. The security team requires that all workload accounts inherit custom security baseline policies immediately upon creation or enrollment. The solutions architect decided to implement AWS Control Tower to manage this environment. The architect needs to initialize the landing zone, prepare the account hierarchy, configure custom guardrails, and onboard an existing standalone AWS account into the environment. Arrange the following steps in the correct chronological sequence to implement this architecture while ensuring no account is left temporarily un-governed.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence is: first, initialize AWS Control Tower in the management account to set up the baseline landing zone; second, create or register a custom Organizational Unit (OU) for workloads; third, apply custom Service Control Policies (SCPs) to the custom OU to establish the security boundaries; and fourth, enroll the existing standalone account into the pre-configured custom OU.

Initializing AWS Control Tower first is necessary to establish the landing zone. Next, the custom OU must be created to hold the workload accounts. Attaching the custom SCPs to this OU before enrolling accounts is a critical security best practice, ensuring that the target environment is already secure. Finally, enrolling the account ensures it immediately inherits all landing zone baselines and custom SCPs without any governance gaps.

Step-by-Step Solution

Initialize the AWS Control Tower landing zone in the AWS Organizations management account.

Creates the core infrastructure, including the Security OU, Log Archive account, and Audit account, and enables Account Factory.

You cannot enroll accounts or manage OUs under AWS Control Tower governance until the landing zone is initialized.

Create or register a custom Organizational Unit (OU).

Establishes a container for workload accounts under AWS Control Tower governance.

Workload accounts require a separate OU container to segregate them from the core security and management accounts.

Attach custom Service Control Policies (SCPs) to the custom OU.

Establishes preventive guardrails on the OU before any member accounts are added.

Applying policies to the OU before enrolling accounts prevents a security gap where an account is active in the organization but not yet subject to the custom restrictions.

Enroll the existing standalone AWS account into the custom OU.

The existing account is brought under AWS Control Tower governance and immediately inherits the custom SCPs.

Enrolling the account is the final step, ensuring it is securely governed from the exact moment it joins the OU.

Key Concept

Chronological onboarding and policy application sequence in AWS Control Tower multi-account governance.

Question 311Question →

An enterprise is designing a secure storage solution where an application running in Account B must read encrypted objects from an Amazon S3 bucket located in Account A. The objects in the S3 bucket must be encrypted at rest using AWS KMS.

Which two configuration steps are required to enable this cross-account access? (Select TWO.)

Select all that apply

Create a customer managed key in Account A, and configure its key policy to allow the IAM role in Account B to perform the kms:Decrypt action.

Configure the IAM policy attached to the application's IAM role in Account B to allow the kms:Decrypt action on the ARN of the KMS key in Account A.

Use the default AWS-managed key for Amazon S3 (aws/s3) in Account A and modify its key policy to grant decrypt permissions to the IAM role in Account B.

Attach a Service Control Policy (SCP) to the AWS Organization root that grants Account B direct access to Account A's KMS keys, removing the need for local IAM or KMS policies.

Create a trust relationship on Account A's KMS key policy using the sts:AssumeRoleWithSAML action to federate the Account B identity directly.

Show answer & explanation

Answer: Create a customer managed key in Account A, and configure its key policy to allow the IAM role in Account B to perform the kms:Decrypt action.; Configure the IAM policy attached to the application's IAM role in Account B to allow the kms:Decrypt action on the ARN of the KMS key in Account A.

Answer

To configure cross-account access to KMS-encrypted objects, you must create a Customer Managed Key in Account A, configure its key policy to allow the IAM role in Account B to decrypt, and attach an IAM policy to the IAM role in Account B that permits the decrypt action on the KMS key.

Cross-account AWS KMS access requires configuring permissions on both the resource policy (the KMS key policy in Account A) and the identity-based policy (the IAM policy in Account B). Additionally, you must use a Customer Managed Key (CMK) because the default AWS-managed keys (such as aws/s3) cannot be shared across accounts as their key policies are immutable.

Step-by-Step Solution

Select a customer managed key for encryption in Account A.

You have a key that supports custom key policy modifications, unlike the default AWS-managed aws/s3 key.

AWS-managed keys cannot be shared across accounts because their key policies cannot be modified.

Modify the customer managed key policy in Account A.

The key policy explicitly lists Account B's IAM role as an authorized principal for the kms:Decrypt action.

For cross-account access, the resource-based policy (the key policy) must explicitly authorize the external account principal.

Configure the IAM policy for the application's role in Account B.

The application's role has permission to call kms:Decrypt on Account A's KMS key ARN.

For cross-account access, permissions must be granted on both sides: the key policy in the trust/source account and the identity-based policy in the trusted/destination account.

Key Concept

Cross-account access to KMS keys requires using Customer Managed Keys (CMKs) and configuring permissions on both the KMS key policy in the source account and the IAM policy in the destination account.

Question 312Question →

An automated smart warehouse fulfillment system orchestrates robotic picking paths across multiple physical distribution centers. The coordination engine runs on Amazon EC2 instances in an Auto Scaling group behind an Application Load Balancer (ALB) in the primary AWS Region. The application tier writes state data to an Amazon Aurora PostgreSQL database and requires outbound internet connectivity to send API commands to the physical warehouses. The solutions architect must design a multi-region disaster recovery (DR) solution with a Recovery Time Objective (RTO) of 15 minutes and a Recovery Point Objective (RPO) of 1 minute. The design must ensure that outbound connectivity is resilient to Availability Zone (AZ) failures in both regions and minimize administrative overhead during failover. Which combination of actions should the solutions architect recommend to meet these requirements? (Select TWO.)

Select all that apply

Deploy Amazon Aurora Global Database, designating the primary region as the writer and the standby region as a read replica. Configure Route 53 Failover routing records pointing to the Application Load Balancer in each region, and associate the primary record with a Route 53 health check that monitors the primary region's application health.

Deploy a NAT Gateway in each Availability Zone of the public subnets in both the primary and standby regions. Configure the route tables of the private subnets in each Availability Zone to route outbound internet traffic through the NAT Gateway located in that same zone.

Deploy a single NAT Gateway in the primary Availability Zone of each region's public subnets. Configure all private subnets across all Availability Zones in both regions to route outbound internet traffic through this single NAT Gateway.

Configure Amazon Aurora Auto Scaling in the standby region to dynamically scale replica instances to handle the primary write workload during failover, and configure Route 53 Latency-based routing to direct write requests directly to the reader endpoints in the standby region.

Configure a Route 53 Private Hosted Zone (PHZ) in the primary account and associate it with the VPC in the standby region. Use Route 53 Geolocation routing policies to route regional internal service requests to the standby database endpoints during a failover event.

Show answer & explanation

Answer: Deploy Amazon Aurora Global Database, designating the primary region as the writer and the standby region as a read replica. Configure Route 53 Failover routing records pointing to the Application Load Balancer in each region, and associate the primary record with a Route 53 health check that monitors the primary region's application health.; Deploy a NAT Gateway in each Availability Zone of the public subnets in both the primary and standby regions. Configure the route tables of the private subnets in each Availability Zone to route outbound internet traffic through the NAT Gateway located in that same zone.

Answer

The correct options are deploying Amazon Aurora Global Database along with Route 53 Failover routing records, and deploying a NAT Gateway in each Availability Zone within both regions' public subnets.

To satisfy the RPO of 1 minute and RTO of 15 minutes, deploying Amazon Aurora Global Database is required as it replicates transactions within seconds. Combining this with Route 53 Failover routing records linked to a health check ensures that client requests are dynamically redirected to the standby region without manual DNS intervention. To ensure outbound connectivity is resilient against Availability Zone failures, a NAT Gateway must be deployed in every Availability Zone within the public subnets of both regions. This setup keeps the outbound paths isolated per zone and prevents a single AZ outage from interrupting outbound internet traffic from other healthy zones.

Step-by-Step Solution

Evaluate the database replication strategy to satisfy the RPO constraint.

Select Amazon Aurora Global Database, which offers sub-second cross-region replication, fitting the RPO requirement of 1 minute.

Traditional backup-and-restore or manual cross-region snapshot copying cannot consistently meet a 1-minute RPO with low operational overhead.

Establish an automated DNS failover mechanism.

Create Route 53 Failover routing records pointing to the respective Application Load Balancers in the primary and standby regions, and attach a health check to the primary record.

This automatically redirects user and automation traffic to the disaster recovery region's ALB when the primary region is unhealthy, keeping RTO under 15 minutes.

Ensure outbound connectivity is highly available and zone-resilient in both regions.

Provision a NAT Gateway in each Availability Zone in both regions and configure corresponding route tables to point outbound traffic to the zone-local NAT Gateway.

A single NAT Gateway in a region is a single point of failure. Deploying one per AZ prevents an AZ outage from causing a complete outbound internet black-out for resources in other zones.

Key Concept

Designing multi-region disaster recovery for transactional database workloads requires high-speed replication like Amazon Aurora Global Database combined with automated DNS-level failover. Outbound traffic paths must be built with zone-redundant NAT Gateways to avoid single points of failure.

Question 313Question →

A retail company is expanding its AWS footprint across a multi-account environment in the `eu-west-1` and `eu-central-1` Regions. The architecture consists of $40$ spoke VPCs spread across both regions, all managed under a AWS Organizations structure. The company must establish highly resilient hybrid connectivity to its on-premises corporate offices in Dublin and Frankfurt.

The connectivity requirements are as follows:
- Traffic from the Dublin corporate office must primarily use a $10\text{ Gbps}$ AWS Direct Connect (DX) connection to `eu-west-1`, with a backup Site-to-Site VPN connection.
- Traffic from the Frankfurt corporate office must primarily use a $10\text{ Gbps}$ AWS Direct Connect (DX) connection to `eu-central-1`, with a backup Site-to-Site VPN connection.
- Inter-VPC traffic across the two regions must be routed securely through peered AWS Transit Gateways (TGWs) located in each region.
- Spoke VPCs in both regions must resolve internal domain names hosted in a centralized Route 53 Private Hosted Zone (PHZ) created in a shared services AWS account.

Which TWO configurations must a Solutions Architect implement to meet these requirements with high availability and minimal administrative overhead?

Select all that apply

Create a full mesh of VPC Peering connections across all

40

spoke VPCs to handle cross-region and inter-VPC traffic. Deploy a Direct Connect Gateway in each region, establish Direct Connect Gateway peering between them, and route all hybrid traffic through these peered gateways.

Attach a Transit Virtual Interface (Transit VIF) from each Direct Connect connection to a single Direct Connect Gateway, and associate this Direct Connect Gateway with the Transit Gateways in both regions. Configure AWS Site-to-Site VPN connections from each corporate office to the local Transit Gateway as a backup path.

Deploy Route 53 Resolver outbound endpoints in each spoke VPC. In the shared services account, create a Route 53 Resolver forwarding rule for the private hosted zone domain, and share it with the spoke accounts using AWS Resource Access Manager (RAM) to redirect queries to the spoke VPCs.

Authorize the cross-account association of the Route 53 Private Hosted Zone in the shared services account with the spoke VPCs in both regions using the AWS CLI or SDK, and then complete the association in each spoke account.

Deploy a single NAT Gateway in a single public subnet in each spoke VPC, and configure the route tables of all private subnets in that VPC to route outbound internet traffic through this NAT Gateway to minimize cost.

Show answer & explanation

Answer: Attach a Transit Virtual Interface (Transit VIF) from each Direct Connect connection to a single Direct Connect Gateway, and associate this Direct Connect Gateway with the Transit Gateways in both regions. Configure AWS Site-to-Site VPN connections from each corporate office to the local Transit Gateway as a backup path.; Authorize the cross-account association of the Route 53 Private Hosted Zone in the shared services account with the spoke VPCs in both regions using the AWS CLI or SDK, and then complete the association in each spoke account.

Answer

The correct configurations are to associate the Transit Gateways in both regions with a single Direct Connect Gateway using Transit VIFs with backup Site-to-Site VPNs, and to perform cross-account Private Hosted Zone associations for all spoke VPCs.

To build a highly available and scalable hybrid network architecture, we associate the Transit Gateways in both regions with a single Direct Connect Gateway. Using Transit VIFs allows traffic to flow over the Direct Connect connections to both regions. Backup Site-to-Site VPNs terminate directly on the Transit Gateways. For DNS resolution, authorizing and completing the cross-account association of the Private Hosted Zone ensures spoke VPCs can resolve domains natively without the overhead of Route 53 Resolver endpoints.

Step-by-Step Solution

Configure hybrid connectivity using a single Direct Connect Gateway and Transit VIFs.

A single Direct Connect Gateway is associated with the Transit Gateways in both regions, enabling hybrid traffic routing between on-premises and all spoke VPCs.

Direct Connect Gateway supports transitive routing between on-premises and multiple regional Transit Gateways, simplifying hybrid routing.

Establish backup VPN paths terminating on the regional Transit Gateways.

Site-to-Site VPN connections from Dublin and Frankfurt offices terminate on their respective regional Transit Gateways.

Provides high availability and automatic failover from the Direct Connect path using BGP dynamic routing.

Associate the Route 53 Private Hosted Zone across accounts.

The Private Hosted Zone in the shared services account is associated with all spoke VPCs in the spoke accounts.

Allows spoke VPCs to resolve internal domain names natively without the cost and management overhead of Route 53 Resolver endpoints.

Key Concept

Hybrid network connectivity with multi-region Transit Gateways, Direct Connect Gateways, and cross-account DNS resolution using Route 53 Private Hosted Zones.

Question 314Question →

An HR-tech SaaS company is deploying a multi-account AWS architecture managed under AWS Organizations. A central `Network-Hub` account hosts a Transit Gateway (TGW) and a shared services VPC. Several consumer VPCs reside in separate production and development accounts, all connected to the TGW. The company maintains an on-premises Active Directory DNS server ( $10.100.10.10$ ) in their local datacenter, which is connected to the TGW via an AWS Direct Connect connection. The architecture requires a hybrid DNS resolution strategy where:

1. EC2 instances in the consumer VPCs must resolve internal on-premises domains (`corp.local`).
2. On-premises servers must resolve AWS private domains (`aws.payroll.internal`) hosted in a Route 53 Private Hosted Zone (PHZ) in the `Network-Hub` account.

Which of the following architectures meets these DNS resolution requirements with the least administrative overhead?

Create Route 53 Resolver inbound and outbound endpoints in the shared services VPC. Associate the `aws.payroll.internal` PHZ with the shared services VPC. Create an outbound resolver rule for `corp.local` forwarding to

10.100.10.10

, associate it with the shared services VPC, and share the rule with the consumer accounts using AWS Resource Access Manager (RAM). In the `Network-Hub` account, authorize the association of the consumer VPCs with the PHZ. In the consumer accounts, associate the consumer VPCs with the PHZ and with the shared resolver rule.

Create Route 53 Resolver inbound and outbound endpoints in the shared services VPC. Associate the `aws.payroll.internal` PHZ with the shared services VPC. Share the PHZ with the consumer accounts using AWS Resource Access Manager (RAM) to automatically enable DNS resolution in all VPCs. Create an outbound resolver rule for `corp.local` forwarding to

10.100.10.10

, and associate it directly with the Transit Gateway to apply it globally across all connected VPCs.

Create a Route 53 Resolver outbound endpoint in the shared services VPC. Create an outbound resolver rule for `corp.local` forwarding to

10.100.10.10

, and share it with the consumer accounts using AWS Resource Access Manager (RAM). For on-premises query resolution of the `aws.payroll.internal` zone, configure the Transit Gateway to route DNS traffic directed to

169.254.169.253

over the Direct Connect connection to the on-premises environment.

10.100.10.10

, and share it with the consumer accounts using AWS Resource Access Manager (RAM). In the `Network-Hub` account, create an outbound resolver rule for `aws.payroll.internal` pointing to the inbound endpoint IP addresses, and share it with the consumer accounts via AWS RAM instead of associating the PHZ with each consumer VPC.

Show answer & explanation

Answer: Create Route 53 Resolver inbound and outbound endpoints in the shared services VPC. Associate the `aws.payroll.internal` PHZ with the shared services VPC. Create an outbound resolver rule for `corp.local` forwarding to $10.100.10.10$ , associate it with the shared services VPC, and share the rule with the consumer accounts using AWS Resource Access Manager (RAM). In the `Network-Hub` account, authorize the association of the consumer VPCs with the PHZ. In the consumer accounts, associate the consumer VPCs with the PHZ and with the shared resolver rule.

Answer

Create Route 53 Resolver inbound and outbound endpoints in the shared services VPC, associate the Private Hosted Zone with the shared services VPC, share the outbound rule via AWS RAM, and authorize/associate the Private Hosted Zone across accounts to the consumer VPCs.

The correct architecture uses Route 53 Resolver inbound endpoints to receive on-premises queries, outbound endpoints to forward queries to on-premises, and shares the outbound resolver rules via AWS Resource Access Manager (RAM) for cross-account availability. For private hosted zone resolution, the private hosted zone is associated with the shared services VPC (so the inbound endpoint can resolve names) and with the consumer VPCs via cross-account VPC association authorization, allowing all AWS VPCs to perform local, low-latency resolution.

Step-by-Step Solution

Deploy Route 53 Resolver inbound and outbound endpoints in the shared services VPC of the Network-Hub account.

The inbound endpoints receive queries from the on-premises Active Directory DNS server, while the outbound endpoints send queries from AWS to the on-premises DNS server.

This establishes the physical entry and exit points for hybrid DNS traffic between AWS and the on-premises network.

Create an outbound Route 53 Resolver rule for the `corp.local` domain pointing to the on-premises DNS server IP (

10.100.10.10

). Share this rule with the consumer accounts using AWS Resource Access Manager (RAM) and associate it with the consumer VPCs.

DNS queries for `corp.local` originating from any associated VPC are forwarded to the on-premises DNS server.

VPC instances need a path to forward queries for non-AWS domains to the on-premises DNS infrastructure.

Associate the Private Hosted Zone `aws.payroll.internal` with the shared services VPC. Authorize the cross-account association of the consumer VPCs with the PHZ from the Network-Hub account, and then perform the association from each consumer account.

Both the inbound resolver endpoint (in the shared services VPC) and the EC2 instances in the consumer VPCs can resolve `aws.payroll.internal` queries locally.

On-premises queries hitting the inbound endpoint require the hosted zone to be associated with the inbound endpoint's VPC, and consumer instances require local VPC association to resolve the PHZ without hairpinning queries through endpoints.

Key Concept

Multi-Account and Hybrid DNS routing using Route 53 Resolver Endpoints and cross-account Private Hosted Zone association.

Question 315Question →

An enterprise is configuring a multi-account governance model using AWS Organizations. The security team wants to restrict the member accounts in the Applications Organizational Unit (OU) to a subset of approved AWS services. A cloud engineer proposes attaching a Service Control Policy (SCP) to the Applications OU that lists only the approved services in an Allow statement, and then removing the default FullAWSAccess policy from the OU. Which of the following describes the effect of this configuration on the permissions of users in the member accounts, and the required next steps?

The SCP directly grants permissions to the approved services to all IAM users and roles in the Applications OU, allowing them to access the services without needing local IAM policies.

The SCP will block all access to the approved services unless a trust relationship is configured on the local IAM roles to allow the sts:AssumeRoleWithSAML action from the organization's management account.

The SCP acts as a guardrail that defines the maximum allowed permissions, meaning users in the Applications OU will have no access until local IAM policies in their respective accounts are configured to grant permissions to those approved services.

The SCP will block access to the services unless a Route 53 Private Hosted Zone for the approved services is associated with every VPC in the member accounts under the Applications OU.

Show answer & explanation

Answer: The SCP acts as a guardrail that defines the maximum allowed permissions, meaning users in the Applications OU will have no access until local IAM policies in their respective accounts are configured to grant permissions to those approved services.

Answer

The correct option is the one stating that the SCP acts as a guardrail defining the maximum allowed permissions. SCPs do not grant permissions directly; they only set the boundaries. Therefore, local IAM policies in the member accounts must still explicitly grant access to the approved services for any user or role to interact with them.

Step-by-Step Solution

Analyze the role of Service Control Policies (SCPs) in AWS Organizations.

SCPs specify the maximum permissions for the affected member accounts but do not grant permissions.

To determine how the proposed configuration affects authorization, we must distinguish between guardrails and authorization.

Analyze the interaction between the SCP and local IAM policies.

For an action to be authorized, it must be allowed by both the SCP (or not explicitly denied) and the local IAM policy.

This intersection determines the effective permissions of any principal in a member account.

Evaluate the outcome of replacing the default FullAWSAccess policy with a custom Allow-list SCP.

Only the listed services are permitted in the member accounts, but local IAM policies must still explicitly grant access to these services.

Since the SCP only restricts the ceiling of permissions, explicit local grants are required to authorize actions.

Key Concept

Interaction between Service Control Policies (SCPs) and local IAM Policies

Estimated Time:2m 0s

Question 316Question →

An enterprise manages its multi-account environment using AWS Organizations. The architecture consists of a Management account, a central Network account, and multiple member accounts grouped into a Production Organizational Unit (OU) and a Development OU. The Solutions Architect needs to implement a resource-sharing and cost-optimization strategy. The strategy must allow the Network account to share private subnets with the Development OU. Additionally, Compute Savings Plans purchased in the Management account must apply only to the Production OU accounts, and the Development OU accounts must be excluded to keep development costs separated. Which of the following actions should the Solutions Architect perform to meet these requirements? (Select TWO.)

Select all that apply

Enable resource sharing with AWS Organizations in the AWS RAM console of the Management account. In the Network account, create a resource share for the subnets and share them with the Development OU.

In the Management account, open the Billing preferences in the AWS Billing and Cost Management console, and disable Savings Plans sharing for all member accounts within the Development OU.

Attach a Service Control Policy (SCP) to the Development OU that denies the savingsplans:Apply action to block the application of Savings Plans discounts to the resources running in the development accounts.

In the Network account, create a resource share in AWS RAM for the subnets, set the principal to the Development OU, and enable sharing with external entities in AWS RAM to bypass AWS Organizations integration.

Purchase EC2 Instance Savings Plans in the Management account instead of Compute Savings Plans, as EC2 Instance Savings Plans do not support cross-account sharing and will automatically remain isolated to the Management account.

Show answer & explanation

Answer: Enable resource sharing with AWS Organizations in the AWS RAM console of the Management account. In the Network account, create a resource share for the subnets and share them with the Development OU.; In the Management account, open the Billing preferences in the AWS Billing and Cost Management console, and disable Savings Plans sharing for all member accounts within the Development OU.

Answer

Enable resource sharing with AWS Organizations in the AWS RAM console of the Management account and create the resource share in the Network account to share subnets with the Development OU; and disable Savings Plans sharing for the Development OU member accounts in the Billing Preferences of the Management account.

To share subnets within the AWS Organization, resource sharing must be enabled in the Management account's AWS RAM console. Subnets can then be shared directly with the Development OU from the owner account (the Network account). To exclude the Development OU from the Compute Savings Plans discounts while allowing other accounts to benefit, Savings Plans sharing must be disabled for those specific development accounts within the Billing Preferences of the Management account.

Step-by-Step Solution

Enable Organizations integration for resource sharing.

Allows RAM to share resources with organizational elements like OUs.

By default, resource sharing across accounts within an organization using OUs requires the Organizations integration to be enabled in the Management account.

Create and configure the AWS RAM resource share.

The subnets in the Network account are shared with the Development OU.

The Network account owns the subnets, so the share must be created there and target the Development OU.

Manage Savings Plans sharing settings in the Management account.

Disables the automatic application of the Management account's Savings Plans discounts to the Development OU accounts.

Savings Plans sharing preferences are managed globally or per-account in the Billing preferences of the Management account, not via IAM/SCPs.

Key Concept

AWS Organizations billing preferences and AWS Resource Access Manager sharing controls

Question 317Question →

A global gaming publisher is launching a real-time multiplayer matchmaking platform. The session coordination system must handle a baseline load of $5,000$ requests per second, which is expected to spike to $750,000$ requests per second within $3$ minutes during the launch event. The matchmaking state is highly transient, read-and-write intensive, and requires sub-millisecond latency. The architecture must guarantee high availability across multiple Availability Zones. Which architecture represents the most performant, scalable, and operationally efficient design to meet these requirements?

An Application Load Balancer (ALB) that has been pre-warmed via an AWS Support request, routing traffic to Amazon ECS tasks running on AWS Fargate. Matchmaking state is stored in an Amazon ElastiCache for Redis cluster running in a Multi-AZ configuration with automatic failover enabled.

An Application Load Balancer (ALB) routing traffic to an Amazon ECS service running on AWS Fargate with aggressive target tracking scaling policies. Matchmaking state is stored in an Amazon ElastiCache for Redis cluster running in a Multi-AZ configuration. The ALB scales automatically using default capacity scaling.

An Application Load Balancer (ALB) that has been pre-warmed via an AWS Support request, routing traffic to Amazon ECS tasks running on AWS Fargate. Matchmaking state is stored in a multi-node Amazon ElastiCache for Memcached cluster to leverage multi-threaded performance and cross-Availability Zone replication.

An Application Load Balancer (ALB) that has been pre-warmed via an AWS Support request, routing traffic to Amazon ECS tasks running on AWS Fargate. Matchmaking state is stored in an Amazon RDS for PostgreSQL database running in a Multi-AZ deployment, where read queries are routed to the standby replica to distribute the read load.

Show answer & explanation

Answer: An Application Load Balancer (ALB) that has been pre-warmed via an AWS Support request, routing traffic to Amazon ECS tasks running on AWS Fargate. Matchmaking state is stored in an Amazon ElastiCache for Redis cluster running in a Multi-AZ configuration with automatic failover enabled.

Answer

The architecture using a pre-warmed Application Load Balancer, Amazon ECS on AWS Fargate, and Amazon ElastiCache for Redis in a Multi-AZ configuration.

The correct answer combines an AWS Support pre-warmed Application Load Balancer to absorb the immediate traffic surge with Amazon ECS on Fargate for containerized computation. It utilizes Amazon ElastiCache for Redis in a Multi-AZ configuration to support high-throughput, low-latency transient state storage with automated replication and failover.

Step-by-Step Solution

Evaluate the routing tier scalability under sudden spike conditions.

The platform requires handling a massive jump from

5,000

750,000

requests per second in

3

minutes. Standard Application Load Balancers scale gradually. A flash spike of this magnitude requires requesting ELB pre-warming from AWS Support to prevent connection timeouts and packet loss.

ELB pre-warming pre-allocates the underlying capacity necessary to handle the instantaneous load.

Determine the optimal database technology for highly transient, sub-millisecond matchmaking state.

Matchmaking state is highly transient and requires sub-millisecond latencies. In-memory databases are the correct choice. Amazon ElastiCache for Redis provides the required latency and data structure support.

Relational databases like PostgreSQL introduce unnecessary transactional overhead and cannot reliably meet sub-millisecond read/write latency requirements at this scale.

Ensure database high availability and replication characteristics match requirements.

Amazon ElastiCache for Redis supports Multi-AZ replication with automatic failover, satisfying the high availability requirement. Amazon ElastiCache for Memcached only supports horizontal scaling through partitioning without built-in replication or automatic failover.

Multi-AZ replication ensures durability and availability of active session keys in the event of an Availability Zone outage.

Key Concept

Handling sudden high-volume traffic spikes on ALB and selecting appropriate high-performance, replicated in-memory storage.

Question 318Question →

An enterprise is establishing a hybrid network to connect its on-premises data center with 10 spoke VPCs and a Shared Services VPC in the `us-east-1` Region. The on-premises environment connects via an AWS Direct Connect connection. The architecture must support transitive VPC-to-VPC routing, access to the on-premises data center, and resolution of resources in a centralized Route 53 Private Hosted Zone. Which architecture meets these requirements with the lowest administrative overhead?

Deploy an AWS Transit Gateway, and attach the spoke VPCs and the Shared Services VPC to it. Associate the Direct Connect Gateway with the Transit Gateway using a transit virtual interface. Associate the Route 53 Private Hosted Zone in the Shared Services VPC with all the spoke VPCs and the Shared Services VPC.

Attach a Virtual Private Gateway to each spoke VPC and the Shared Services VPC. Connect all the Virtual Private Gateways to the Direct Connect Gateway using private virtual interfaces, and configure the Direct Connect Gateway to route transitive traffic between the spoke VPCs.

Deploy an AWS Transit Gateway, and attach the spoke VPCs and the Shared Services VPC to it. Associate the Direct Connect Gateway with the Transit Gateway using a transit virtual interface. Associate the Route 53 Private Hosted Zone only with the Shared Services VPC, and configure the spoke VPCs to route DNS queries to the Shared Services VPC resolver over the Transit Gateway.

Deploy an AWS Transit Gateway, and attach the spoke VPCs to it. Route all egress internet traffic from the spoke VPCs through a centralized egress VPC containing a single NAT Gateway deployed in a single Availability Zone, and use a full mesh of VPC peering connections for transitive routing between the spokes.

Show answer & explanation

Answer: Deploy an AWS Transit Gateway, and attach the spoke VPCs and the Shared Services VPC to it. Associate the Direct Connect Gateway with the Transit Gateway using a transit virtual interface. Associate the Route 53 Private Hosted Zone in the Shared Services VPC with all the spoke VPCs and the Shared Services VPC.

Answer

Deploying an AWS Transit Gateway to attach all VPCs, associating the Direct Connect Gateway using a transit virtual interface, and associating the Route 53 Private Hosted Zone with all VPCs.

The correct architecture leverages AWS Transit Gateway to act as a cloud router, enabling transitive routing between all attached spoke VPCs and the Shared Services VPC. Using an AWS Direct Connect Gateway associated with the Transit Gateway via a transit virtual interface (Transit VIF) allows all VPCs to access the on-premises network. Finally, Route 53 Private Hosted Zones (PHZs) must be explicitly associated with each VPC that requires DNS resolution for the zone; DNS queries are link-local (sent to the VPC resolver at the .2 address) and cannot traverse Transit Gateway attachments to reach a hosted zone associated only with a remote VPC.

Step-by-Step Solution

Evaluate routing requirements.

Identify that VPC-to-VPC transitive routing and hybrid connectivity can be achieved centrally using AWS Transit Gateway.

VPC peering does not support transitive routing, and Direct Connect Gateway alone does not route traffic between connected VPCs.

Configure hybrid connectivity via Direct Connect.

Associate the Direct Connect Gateway with the Transit Gateway using a transit virtual interface (Transit VIF).

A transit VIF is the only virtual interface type that supports AWS Transit Gateway association with a Direct Connect Gateway.

Address DNS resolution requirements.

Associate the Route 53 Private Hosted Zone (PHZ) created in the Shared Services VPC with all 10 spoke VPCs.

Since VPC DNS resolvers (.2 address) only resolve query requests locally and do not forward queries over Transit Gateway, the PHZ must be explicitly associated with each VPC.

Key Concept

Transitive routing and centralized DNS resolution in multi-account hybrid AWS networks.

Estimated Time:2m 0s

Question 319Question →

An advertising technology platform is preparing to launch a real-time bidding service that receives bid requests from thousands of publishers. The service is expected to experience a baseline traffic of $20,000$ requests per second (RPS), with immediate spikes up to $300,000$ RPS during scheduled regional shopping events. The backend runs on Amazon Elastic Container Service (ECS) on AWS Fargate behind an Application Load Balancer (ALB). The application queries an Amazon Aurora PostgreSQL database for campaigns and user profiles. To ensure sub-second response times and high availability during these flash traffic events, which two architectural optimization strategies should a Solutions Architect recommend?

Select all that apply

Submit a support case to AWS to pre-warm the Application Load Balancer (ALB) with the expected traffic profile and rate of increase before the scheduled shopping events.

Configure Application Auto Scaling for Aurora Replicas to dynamically scale read capacity based on average CPU utilization, and configure the application to use the Aurora reader endpoint for read queries.

Rely on the Application Load Balancer's (ALB) built-in automatic scaling to handle the sudden

300,000

RPS traffic spikes without pre-warming, as ALBs dynamically scale to any load instantly.

Configure the Amazon Aurora database with a Multi-AZ deployment and configure the application to route read queries to the passive standby instance to offload the primary instance.

Set the scale-out cooldown period for the ECS service's Auto Scaling policy to

10

seconds to ensure tasks scale out rapidly without waiting for previous tasks to finish launching.

Show answer & explanation

Answer: Submit a support case to AWS to pre-warm the Application Load Balancer (ALB) with the expected traffic profile and rate of increase before the scheduled shopping events.; Configure Application Auto Scaling for Aurora Replicas to dynamically scale read capacity based on average CPU utilization, and configure the application to use the Aurora reader endpoint for read queries.

Answer

To handle sudden, massive traffic spikes and maintain database performance, the solutions architect should request ALB pre-warming from AWS Support to prevent initial connection drops, and configure dynamic Application Auto Scaling for Aurora Replicas to scale read queries distributed through the Aurora reader endpoint.

Requesting ALB pre-warming prepares the load balancer infrastructure to accept

300,000

RPS without dropping connections due to rapid traffic surges. Using Aurora Replicas with Auto Scaling and targeting the reader endpoint dynamically spreads the query load across active readers, preventing database bottlenecking.

Step-by-Step Solution

Evaluate the ingress layer scaling characteristics during instantaneous flash traffic.

The traffic spikes instantly from

20,000

300,000

RPS, exceeding the standard ALB scaling rate limit. AWS Support must pre-warm the ALB.

Prevents dropped connections and

502

503

errors during the initial phase of the flash traffic event.

Address read scalability constraints at the database tier.

Determine that Aurora Replicas can scale horizontally and handle read traffic using the cluster's reader endpoint.

Offloads the primary database writer node and scales query capacity dynamically using CPU utilization as the target metric.

Analyze ECS Fargate auto-scaling policies for transient periods.

Ensure the scale-out cooldown period is configured to accommodate Fargate task provisioning and bootstrapping times.

Prevents rapid, redundant scale-out alarms (thrashing) that happen when the cooldown expires before the new task is fully active and taking load.

Key Concept

Handling massive flash traffic spikes requires pre-warming load balancing resources, scaling read replicas dynamically using correct database endpoints, and configuring container scaling metrics with realistic cooldown targets.

Question 320Question →

A startup is deploying a new web application on AWS that handles customer order processing. The primary architecture is deployed in `us-east-1` and consists of an Application Load Balancer (ALB), an Auto Scaling group of Amazon EC2 instances, and an Amazon Aurora PostgreSQL database cluster. The startup needs to establish a disaster recovery (DR) strategy in `us-west-2` that achieves a Recovery Time Objective (RTO) of $15$ minutes and a Recovery Point Objective (RPO) of $1$ minute. The DR strategy must minimize ongoing infrastructure costs and operational complexity. Which combination of actions should a Solutions Architect implement to meet these requirements? (Select TWO.)

Select all that apply

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

Deploy an Amazon Aurora Global Database with the primary cluster in `us-east-1` and a secondary cluster in `us-west-2` containing zero DB instances. During a failover event, promote the secondary cluster to a standalone cluster and add an Aurora DB instance.

Configure Amazon Route 53 with a latency-based routing policy to distribute traffic to both Regions. Set up an Amazon EventBridge rule in `us-east-1` to delete the DNS record pointing to `us-east-1` if the primary application health check fails.

Configure cross-Region snapshot copies for the Aurora cluster to copy snapshots from `us-east-1` to `us-west-2` every

15

minutes. During a failover event, restore the database cluster in `us-west-2` from the latest copied snapshot.

Associate a Route 53 Private Hosted Zone created in the primary VPC with the VPC in `us-west-2`, and configure weighted routing records to direct public user traffic to the healthy endpoints.

Show answer & explanation

Answer: Configure an Amazon Route 53 failover routing policy. Create a primary failover record pointing to the Application Load Balancer in `us-east-1` with an active Route 53 health check, and a secondary failover record pointing to the Application Load Balancer in `us-west-2`.; Deploy an Amazon Aurora Global Database with the primary cluster in `us-east-1` and a secondary cluster in `us-west-2` containing zero DB instances. During a failover event, promote the secondary cluster to a standalone cluster and add an Aurora DB instance.

Answer

The correct options are to configure an Amazon Route 53 failover routing policy with active health checks to the load balancers, and to deploy an Amazon Aurora Global Database with a secondary cluster containing zero DB instances that can be scaled up and promoted during failover.

To achieve the

1

-minute RPO and

15

-minute RTO while keeping costs low, the architecture must utilize a high-performance replication mechanism and an automated DNS routing strategy. Deploying an Amazon Aurora Global Database with a secondary cluster that has no database instances provides sub-second replication lag (meeting the RPO) with zero active compute costs in the secondary region. During a failover, a DB instance can be added to the secondary cluster, and the cluster promoted to primary, which fits well within the

15

-minute RTO. Additionally, configuring an Amazon Route 53 failover routing policy with health checks ensures that public traffic is automatically rerouted to the secondary Application Load Balancer once the primary endpoint is detected as unhealthy.

Step-by-Step Solution

Evaluate the RPO requirement of

1

minute.

Eliminate snapshot-based replication options because copying snapshots at a minimum

15

-minute interval violates the

1

-minute RPO constraint, making Aurora Global Database the appropriate replication mechanism due to its sub-second replication lag.

To ensure data loss is kept within the

1

-minute RPO limit.

Evaluate the RTO requirement of

15

minutes and the cost-optimization constraint.

Select an Aurora Global Database configuration with zero DB instances in the secondary region's cluster to avoid ongoing compute costs, since a DB instance can be provisioned and the secondary cluster promoted within the

15

-minute RTO.

To minimize compute costs in the passive region while still meeting recovery time objectives.

Route public traffic to the active Region.

Configure Route 53 failover routing with active health checks pointing to the ALBs in both regions, rather than private routing policies or latency routing without automatic failover.

To automatically detect primary region failure and redirect users to the backup region.

Key Concept

Designing Multi-Region Disaster Recovery using Aurora Global Database (Pilot Light model with zero DB instances) and Route 53 active-passive DNS failover.

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

Alternative Method

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

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