All practice questions

1964 questions

All types1,964 Multiple choice1,006 Multiple select931 Ordering27

A company is designing a disaster recovery (DR) architecture for a web application. The business requirements specify a Recovery Time Objective (RTO) of $15$ minutes and a Recovery Point Objective (RPO) of $5$ minutes. The solutions architect needs to minimize ongoing running costs and infrastructure complexity.

Which disaster recovery strategy should the solutions architect select to meet these requirements?

A Pilot Light strategy that replicates the database to the secondary region using Amazon Aurora Global Database, and maintains stopped application servers in the secondary region that are started during a failover event.

A Backup and Restore strategy that performs daily database backups to Amazon S3 in the secondary region, and restores all resources during a disaster.

A Pilot Light strategy that uses Amazon Aurora Global Database for replication, but associates the Route 53 Private Hosted Zone for database endpoint resolution only with the primary region's VPC.

A Warm Standby strategy that uses an Amazon RDS Multi-AZ deployment across regions, and configures the standby database instance in the secondary region to serve active read traffic.

Show answer & explanation

Answer: A Pilot Light strategy that replicates the database to the secondary region using Amazon Aurora Global Database, and maintains stopped application servers in the secondary region that are started during a failover event.

Answer

The Pilot Light strategy that replicates the database using Amazon Aurora Global Database and maintains stopped application servers in the secondary region to be started during failover.

The Pilot Light strategy using Amazon Aurora Global Database is correct. Aurora Global Database handles database replication asynchronously with sub-second lag, ensuring the

5

-minute RPO is met. Keeping the application servers stopped under normal operations minimizes ongoing compute costs, and starting them during a failover event can be completed well within the

15

-minute RTO.

Step-by-Step Solution

Evaluate the RPO requirement against the candidate replication strategies.

The target RPO is

5

minutes. Amazon Aurora Global Database provides sub-second replication lag, meeting this requirement, whereas daily database backups fail to meet it.

Choosing a replication strategy with lag lower than the target RPO is necessary to prevent data loss beyond the business limit.

Evaluate the RTO and cost requirements against the application tier status.

A Pilot Light strategy meets the

15

-minute RTO by keeping the database active in the DR region while avoiding the costs of running active application servers by keeping them stopped until failover.

Maintaining stopped resources or infrastructure templates minimizes active running costs while ensuring they can be provisioned within the target RTO.

Verify DNS and cross-region connectivity requirements for the database.

The Route 53 Private Hosted Zone used for database resolution must be associated with the secondary VPC to ensure the failover application servers can connect to the database.

Failing to link the hosted zone to the secondary VPC prevents resolution of internal database endpoints during a disaster recovery event.

Key Concept

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

Question 722Question →

A software conglomerate uses AWS Organizations with consolidated billing to manage multiple business units, each represented by a distinct set of member AWS accounts. A central Network account manages the shared VPC infrastructure. A Solutions Architect must design a cost management and resource sharing strategy to meet the following requirements:
1. Generate separate, customized monthly billing reports (pro forma bills) for each business unit, applying a 10% markup on all Amazon EC2 usage to cover internal administrative costs.
2. Share public and private subnets from the central Network account with the member accounts of specific business units to allow application deployment.
3. Prevent the sharing of Savings Plans benefits from the management account to a newly acquired business unit's accounts, allowing that business unit to purchase and apply its own Savings Plans exclusively.

Which of the following actions should the Solutions Architect take to meet these requirements? (Select TWO.)

Select all that apply

Create billing groups in AWS Billing Conductor for each business unit. Associate the member accounts of each business unit with their respective billing group, and apply a custom pricing plan containing a 10% markup rate rule for Amazon EC2.

In the AWS Billing console of the management account, disable Savings Plans discount sharing for the member accounts belonging to the newly acquired business unit. In the central Network account, use AWS Resource Access Manager (RAM) to create a resource share for the subnets and share them with the AWS Organizations Organizational Unit (OU) of the target business unit.

Create a Service Control Policy (SCP) that denies the savingsplans:ApplySavingsPlan action, and attach it to the Organizational Unit (OU) of the newly acquired business unit to block the application of organization-level Savings Plans.

In the central Network account, use AWS Resource Access Manager (RAM) to share the subnets. Configure the default AWS-managed KMS key for EBS (aws/ebs) in the Network account to encrypt resources within the shared subnets and delegate usage permissions to the member accounts.

Enable external resource sharing in AWS Resource Access Manager (RAM). Create a resource share for the subnets and share them with the individual AWS account IDs of the newly acquired business unit as external entities to isolate them from the organization's billing scope.

Show answer & explanation

Answer: Create billing groups in AWS Billing Conductor for each business unit. Associate the member accounts of each business unit with their respective billing group, and apply a custom pricing plan containing a 10% markup rate rule for Amazon EC2.; In the AWS Billing console of the management account, disable Savings Plans discount sharing for the member accounts belonging to the newly acquired business unit. In the central Network account, use AWS Resource Access Manager (RAM) to create a resource share for the subnets and share them with the AWS Organizations Organizational Unit (OU) of the target business unit.

Answer

Create billing groups and custom pricing plans in AWS Billing Conductor to apply the markup, disable Savings Plans sharing in the management account's billing preferences for the specific member accounts, and use AWS RAM to share the subnets with the target Organizational Unit.

To generate separate pro forma bills with markups, AWS Billing Conductor should be used to create billing groups and apply custom pricing plans. To selectively prevent Savings Plans benefits from being shared with specific member accounts, Savings Plans discount sharing must be disabled in the AWS Billing console of the management account. Additionally, AWS Resource Access Manager (RAM) allows sharing VPC subnets within the AWS Organization by sharing them with the target Organizational Unit (OU).

Step-by-Step Solution

Address the custom billing markup requirement by configuring AWS Billing Conductor.

Create billing groups for each business unit and attach a custom pricing plan that defines a 10% markup rule on Amazon EC2 services.

AWS Billing Conductor allows generating pro forma monthly billing data with customized pricing rules for target accounts without changing the actual consolidated invoice.

Disable Savings Plans sharing for the newly acquired business unit's accounts in the billing console.

Turn off Savings Plans discount sharing for those member accounts in the management account's billing preferences.

This isolates the subsidiary's billing so they do not receive the organization's shared Savings Plans benefits, allowing them to purchase and apply their own.

Share the subnets from the central Network account with the target business unit's accounts.

Use AWS Resource Access Manager (RAM) to create a resource share for the subnets and target the OU of the business unit.

AWS RAM supports sharing VPC subnets within the AWS Organization to enable multi-account resource sharing under centralized network management.

Key Concept

AWS Billing Conductor is used for pro forma billing custom pricing, AWS Billing preferences manage consolidated billing discount sharing, and AWS RAM supports sharing resources like subnets within an AWS Organization.

Question 723Question →

A smart grid utility company is designing a real-time smart-meter telemetry ingestion platform across two AWS Regions: us-east-1 (primary) and eu-west-1 (secondary). The platform must achieve a Recovery Time Objective (RTO) of less than 5 minutes and a Recovery Point Objective (RPO) of less than 1 minute.

The architecture consists of:
- An ingress tier in each region running containerized applications on AWS Fargate in private subnets, behind an Application Load Balancer (ALB).
- Outbound connections from Fargate tasks to external grid devices that require highly resilient internet access.
- A persistence tier using Amazon Aurora PostgreSQL.
- An internal metadata microservice deployed in a shared services VPC in us-east-1 that resolves via a Route 53 Private Hosted Zone (PHZ) named grid.internal.

During normal operations, global telemetry traffic must be routed to the region with the lowest latency. If a regional outage occurs, all traffic must automatically fail over to the surviving region. The secondary region should operate in a cost-optimized warm standby configuration, scaling up its ECS tasks only during a failover.

Which solution meets these requirements while minimizing cost and operational complexity?

Configure Amazon Aurora Global Database with the primary cluster in us-east-1 and a secondary cluster in eu-west-1. In each region, deploy the Fargate tasks across three Availability Zones (AZs) and provision a NAT Gateway in each AZ. Establish VPC peering between the eu-west-1 application VPC and the shared services VPC, and associate the grid.internal PHZ with both application VPCs. Create Route 53 latency-based routing records pointing to each regional ALB and associate them with Route 53 health checks.

Configure Amazon Aurora Global Database with the primary cluster in us-east-1 and a secondary cluster in eu-west-1. In each region, deploy the Fargate tasks across three Availability Zones (AZs), but provision a single NAT Gateway in the first AZ of each VPC to optimize network resource costs. Establish VPC peering between the eu-west-1 application VPC and the shared services VPC, and associate the grid.internal PHZ with both application VPCs. Create Route 53 latency-based routing records pointing to each regional ALB and associate them with Route 53 health checks.

Configure Amazon Aurora Global Database with the primary cluster in us-east-1 and a secondary cluster in eu-west-1. In each region, deploy the Fargate tasks across three Availability Zones (AZs) and provision a NAT Gateway in each AZ. Establish VPC peering between the eu-west-1 application VPC and the shared services VPC, and enable DNS resolution support on the peering connection. Rely on the peering connection's native DNS features to resolve grid.internal in eu-west-1 without manually associating the PHZ with the secondary VPC. Create Route 53 latency-based routing records pointing to each regional ALB and associate them with Route 53 health checks.

Configure Amazon Aurora Global Database with the primary cluster in us-east-1 and a secondary cluster in eu-west-1. In each region, deploy the Fargate tasks across three Availability Zones (AZs) and provision a NAT Gateway in each AZ. Establish VPC peering between the eu-west-1 application VPC and the shared services VPC, and associate the grid.internal PHZ with both application VPCs. Configure Route 53 latency-based routing records pointing to each regional ALB, but do not associate health checks to prevent split-brain DNS states; instead, implement an AWS Lambda function triggered by Amazon CloudWatch alarms to manually swap DNS records during a regional failover.

Show answer & explanation

Answer: Configure Amazon Aurora Global Database with the primary cluster in us-east-1 and a secondary cluster in eu-west-1. In each region, deploy the Fargate tasks across three Availability Zones (AZs) and provision a NAT Gateway in each AZ. Establish VPC peering between the eu-west-1 application VPC and the shared services VPC, and associate the grid.internal PHZ with both application VPCs. Create Route 53 latency-based routing records pointing to each regional ALB and associate them with Route 53 health checks.

Answer

The configuration using Amazon Aurora Global Database ensures sub-second data replication (meeting the RPO of 1 minute) and enables promotion of the secondary cluster in less than a minute. Utilizing a NAT Gateway in each Availability Zone prevents an AZ outage from disabling outbound internet access for tasks in the other AZs. Associating the Private Hosted Zone with the secondary VPC allows private resolution of grid.internal. Finally, Route 53 latency-based routing records with active health checks ensure that traffic is directed to the lowest-latency healthy endpoint and automatically routed to the secondary region during a failure, satisfying the RTO of 5 minutes.

Step-by-Step Solution

Select the database replication strategy.

Amazon Aurora Global Database provides sub-second replication latency to the secondary region, yielding an RPO of under 1 second, and can be promoted to a primary cluster in under 1 minute, satisfying the RTO constraint.

Standard multi-region deployments require storage-level or database-level replication to guarantee minimal data loss (RPO < 1 minute) and rapid failover (RTO < 5 minutes).

Design the outbound network connectivity for high availability.

Provision a NAT Gateway in each of the three Availability Zones per region.

A single NAT Gateway per VPC represents a single point of failure; an AZ outage would block outbound traffic from the remaining AZs.

Establish cross-region name resolution for the Private Hosted Zone.

Associate the Route 53 Private Hosted Zone (PHZ) grid.internal with the VPCs in both regions.

VPC peering does not automatically resolve private domains across VPC boundaries; the PHZ must be explicitly associated with each VPC that needs to resolve the domain.

Configure the global traffic routing policy.

Create Route 53 latency-based routing records associated with Route 53 health checks.

This setup routes users to the lowest-latency endpoint under normal conditions and automatically redirects traffic to the secondary region if the primary region's ALB health check fails.

Key Concept

Multi-region disaster recovery design integrating storage replication, private DNS resolution across accounts/regions, NAT redundancy, and automated DNS failover.

Question 724Question →

An international non-profit organization is restructuring its AWS multi-account environment under a single AWS Organization with consolidated billing. The organization needs to share a central database subnet in a Transit Gateway-connected network VPC with development accounts. Additionally, they want to utilize their consolidated Savings Plans across the organization but must exclude a newly acquired subsidiary account (Account ID: `111122223333`) that operates under its own budget and cannot share its compute benefits. Which two strategies should the cloud architect implement to meet these requirements?

Select all that apply

In the AWS Billing Console of the Management account, navigate to Billing Preferences and disable Savings Plan discount sharing for the subsidiary account to ensure its compute resources do not consume or contribute to the organization's pooled discounts.

In the Network account, use AWS Resource Access Manager (RAM) to create a resource share for the database subnets, target the AWS Organization ID or specific Organizational Unit (OU) ID, and ensure that resource sharing is enabled within AWS Organizations.

In the Management account, apply a Service Control Policy (SCP) to the subsidiary account's OU that explicitly denies the `savingsplans:ApplyDiscount` and `savingsplans:ShareBenefit` actions to restrict the application of consolidated discounts.

In the Network account, configure AWS RAM to share the database subnets directly with the individual AWS Account ID of the subsidiary without enabling organizational sharing, and configure the subnets' default AWS-managed KMS key (`aws/ec2`) to permit cross-account access.

Show answer & explanation

Answer: In the AWS Billing Console of the Management account, navigate to Billing Preferences and disable Savings Plan discount sharing for the subsidiary account to ensure its compute resources do not consume or contribute to the organization's pooled discounts.; In the Network account, use AWS Resource Access Manager (RAM) to create a resource share for the database subnets, target the AWS Organization ID or specific Organizational Unit (OU) ID, and ensure that resource sharing is enabled within AWS Organizations.

Answer

Disable Savings Plan discount sharing for the subsidiary account in the Billing Preferences of the Management account, and use AWS Resource Access Manager in the Network account to share the subnets to the AWS Organization or OUs while ensuring organizational sharing is enabled.

To exclude the subsidiary account from consuming shared Savings Plans, the Management account must disable discount sharing for that specific account in Billing Preferences. To securely and efficiently share database subnets from the Network account to development accounts, the administrator must use AWS Resource Access Manager, share the subnets with the Organization or OUs, and ensure organizational sharing is enabled in AWS RAM.

Step-by-Step Solution

Disable discount sharing for the subsidiary account.

The subsidiary account is isolated from consolidated Savings Plans benefits.

This prevents the subsidiary's compute resources from consuming consolidated discounts, adhering to their separate budget requirement.

Enable organization sharing in AWS RAM.

AWS RAM is permitted to share resources across the AWS Organization without individual account invitations.

This simplifies administration and enables secure subnet sharing within the Organization boundaries.

Create a resource share for the database subnets.

The database subnets are shared with the target development accounts or OUs.

This allows resources in the development accounts to be launched directly into the shared Network VPC subnets.

Key Concept

AWS Organizations billing consolidated discounts management and AWS Resource Access Manager (RAM) subnet sharing.

Question 725Question →

A financial services company is designing a highly available, multi-region credit scoring application deployed across `us-east-1` (primary) and `us-west-2` (secondary). The application runs on Amazon EC2 instances in private subnets across multiple Availability Zones behind Application Load Balancers. The EC2 instances must fetch external credit bureau data over the internet. The database must support low-latency transactions and scale reads horizontally. The business specifies a disaster recovery (DR) objective of a 15-minute RTO and a 1-minute RPO. Which two of the following architecture choices should the solutions architect make to satisfy these design requirements?

Select all that apply

Configure an Amazon Aurora Global Database with the primary cluster in `us-east-1` and a secondary cluster in `us-west-2` to achieve low-latency cross-region replication and meet the RPO and RTO objectives.

Provision a NAT Gateway in each Availability Zone of the VPCs in both regions, and configure private subnet route tables to target their local NAT Gateway for outbound traffic.

Deploy Amazon RDS for PostgreSQL with Multi-AZ enabled in the primary region, and configure the application to route read-heavy queries directly to the RDS standby replica in the secondary Availability Zone.

Deploy a single NAT Gateway in a single public subnet in the primary region, and point the private route tables of all other Availability Zones to this NAT Gateway to reduce ongoing gateway hourly charges.

Create a Route 53 Private Hosted Zone for the internal API domain, associate it with the primary VPC, and peered regions using AWS Transit Gateway to automatically resolve the domain in the secondary region.

Create a backup plan in AWS Backup to take daily snapshots of the database, copy them to the secondary region, and configure an AWS Lambda function to automatically restore the database during a failover event.

Show answer & explanation

Answer: Configure an Amazon Aurora Global Database with the primary cluster in `us-east-1` and a secondary cluster in `us-west-2` to achieve low-latency cross-region replication and meet the RPO and RTO objectives.; Provision a NAT Gateway in each Availability Zone of the VPCs in both regions, and configure private subnet route tables to target their local NAT Gateway for outbound traffic.

Answer

The correct options are configuring an Amazon Aurora Global Database for cross-region replication and provisioning a NAT Gateway in each Availability Zone for redundant outbound traffic.

Deploying Amazon Aurora Global Database ensures cross-region replication lag is under 1 second, meeting the 1-minute RPO, and failover/promotion takes less than a minute, satisfying the 15-minute RTO. Additionally, placing a NAT Gateway in each Availability Zone eliminates a single point of failure for outbound connections from EC2 instances in private subnets.

Step-by-Step Solution

Analyze RTO and RPO limits to select database replication approach.

Amazon Aurora Global Database provides replication lag under 1 second, fitting the 1-minute RPO, and allows secondary promotion under 1 minute, fitting the 15-minute RTO. Daily backups do not meet these metrics.

To satisfy low-latency transactional and disaster recovery objectives.

Evaluate high availability requirements for outbound traffic routing.

Provisioning a local NAT Gateway in each Availability Zone prevents an outage in one zone from affecting outbound traffic in other zones.

Using a single NAT Gateway across multiple zones introduces a single point of failure.

Identify and eliminate options proposing incorrect architectural assumptions.

Eliminated options using RDS Multi-AZ standbys for read queries (since they are passive), single NAT Gateways, and Route 53 Private Hosted Zones without VPC association.

To ensure correct functionality and high availability.

Key Concept

Designing for multi-region disaster recovery requires low-latency database replication matching RTO/RPO and redundant routing components across Availability Zones to avoid single points of failure.

Estimated Time:2m 30s

Question 726Question →

A company is designing a new session state store for a web application. The session store requires sub-millisecond latency for read and write operations, high availability across multiple Availability Zones, and the ability to persist session data to prevent data loss. Which architecture should the Solutions Architect recommend to meet these requirements?

Deploy an Amazon ElastiCache for Redis cluster with Multi-AZ replication and data persistence enabled.

Deploy an Amazon ElastiCache for Memcached cluster with replication and data persistence enabled.

Deploy a single Amazon RDS for PostgreSQL DB instance with a Multi-AZ deployment configuration, and route the read queries to the standby instance in the secondary Availability Zone.

Deploy an Amazon EC2 Auto Scaling group running local Memcached daemons, and configure the Auto Scaling scale-out cooldown period to 10 seconds to launch instances rapidly as traffic increases.

Show answer & explanation

Answer: Deploy an Amazon ElastiCache for Redis cluster with Multi-AZ replication and data persistence enabled.

Answer

Deploy an Amazon ElastiCache for Redis cluster with Multi-AZ replication and data persistence enabled.

An Amazon ElastiCache for Redis cluster with Multi-AZ replication and data persistence enabled provides sub-millisecond response times, automated failover for high availability, and persistent data storage to prevent session loss.

Step-by-Step Solution

Analyze the application requirements: sub-millisecond latency, high availability across multiple AZs, and data persistence to prevent session loss.

Identified that the solution must support replication, persistent storage, and memory-speed access.

This establishes the constraints for database/caching selection.

Compare caching engines: ElastiCache for Redis vs ElastiCache for Memcached.

ElastiCache for Redis supports both replication (Multi-AZ) and persistence (AOF/RDB), whereas Memcached is purely in-memory and does not support replication.

This rules out Memcached-based solutions.

Evaluate the database tier alternatives, such as Amazon RDS for PostgreSQL with Multi-AZ.

RDS Multi-AZ standby instances cannot be read from or written to, and a relational database will not consistently guarantee sub-millisecond latency for session state.

This rules out the RDS standby read strategy.

Key Concept

Selecting high-performance, durable, and highly available caching solutions

Estimated Time:2m 0s

Question 727Question →

An enterprise is establishing a centralized logging architecture across its multi-account environment managed by AWS Organizations. The security team requires that all API activity across all current and future member accounts be logged to a central, read-only Amazon S3 bucket, and that member accounts be prevented from disabling or altering these logging configurations. Arrange the steps in the correct sequence to implement this centralized logging solution in accordance with AWS best practices.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins with creating the Log Archive account, followed by creating the central S3 bucket with the appropriate bucket policy, then creating the organization-level CloudTrail trail, and finally applying a Service Control Policy to prevent member accounts from tampering with the CloudTrail configuration.

The correct sequence ensures that resource dependencies are satisfied chronologically. The Log Archive account must exist first to host the destination S3 bucket. The S3 bucket must then be created with a policy that allows the CloudTrail service principal to write logs from the organization; without this policy, creating the organization trail will fail. After the bucket is ready, the organization trail is created to deliver logs from all accounts. Finally, an SCP is applied to prevent member accounts from altering the trail, securing the auditing setup.

Step-by-Step Solution

Provision the Log Archive account.

A dedicated, isolated account exists under the Security OU for storing audit logs.

The destination account must be created first to own the central S3 logging bucket.

Create the S3 bucket and attach a CloudTrail-compliant bucket policy.

An S3 bucket is configured in the Log Archive account, granting write permissions to the CloudTrail service principal.

AWS CloudTrail validates the bucket's existence and permissions when the organization trail is created. If the bucket or correct policy is missing, trail creation will fail.

Create the organization trail in the management account.

A multi-region organization trail is deployed to all current and future member accounts.

This establishes centralized logging for all API activity across the entire organization.

Deploy a Service Control Policy restricting CloudTrail modifications.

Member accounts are blocked from disabling CloudTrail, deleting the trail, or changing S3 settings.

This enforces governance and prevents local administrators from tampering with the audit logs.

Key Concept

Centralized multi-account logging and guardrails using AWS Organizations and CloudTrail

Estimated Time:2m 0s

Question 728Question →

A financial technology company is implementing a multi-account AWS environment using AWS Organizations. The security team wants to establish federated access for internal developers using their corporate Active Directory Federation Services (AD FS) identity provider via SAML 2.0. The developers must be able to directly authenticate and access the AWS Management Console in multiple member accounts with specific permissions. Which TWO configurations are required to establish this trust relationship and enable federated access?

Select all that apply

Create a SAML 2.0 identity provider in each AWS member account, and create federated IAM roles with a trust policy that allows the sts:AssumeRoleWithSAML action for the SAML provider principal.

Configure the corporate AD FS to send SAML assertions that map LDAP attributes to the AWS-defined claims for the role and the role session name.

Create a federated IAM role in the member accounts with a trust policy that permits the sts:AssumeRoleWithWebIdentity action pointing to the AD FS metadata endpoint.

Apply a Service Control Policy (SCP) at the root level of the AWS Organization that allows the sts:AssumeRoleWithSAML action for the external identity provider.

Configure the SAML 2.0 identity provider solely in the AWS Organizations management account, and configure AD FS to assume roles in the member accounts using the sts:AssumeRole action.

Show answer & explanation

Answer: Create a SAML 2.0 identity provider in each AWS member account, and create federated IAM roles with a trust policy that allows the sts:AssumeRoleWithSAML action for the SAML provider principal.; Configure the corporate AD FS to send SAML assertions that map LDAP attributes to the AWS-defined claims for the role and the role session name.

Answer

The configurations requiring a SAML 2.0 identity provider in each member account with the sts:AssumeRoleWithSAML action, and configuring AD FS to send the specific AWS-defined SAML claims are required.

The correct configurations involve setting up a SAML 2.0 identity provider in each target member account and creating IAM roles with trust policies that allow the sts:AssumeRoleWithSAML action. Furthermore, the external identity provider (AD FS) must be configured to pass the mandatory SAML claims containing the role mapping and session name so that AWS can authorize the federated session.

Step-by-Step Solution

Identify the federation protocol and the required IAM actions.

The company uses AD FS (SAML 2.0), which requires the sts:AssumeRoleWithSAML action in the role trust policy.

Using the correct security token service action is mandatory for AWS to validate the SAML assertion.

Determine the account scope for identity provider configuration.

A SAML identity provider must be created in each target member account, rather than only in the management account, to allow direct console login.

Federating directly to member accounts requires local trust configuration unless utilizing IAM Identity Center.

Map identity claims from the Identity Provider to AWS attributes.

The AD FS server must send the Role and RoleSessionName attributes in the SAML assertion.

AWS relies on these attributes to map the authenticated federated user to the target IAM role.

Key Concept

Establishing trust and attribute mapping in direct multi-account SAML 2.0 federation.

Question 729Question →

A multinational pharmaceutical company is designing a highly available, multi-region hybrid network. The company has $45$ spoke VPCs in the `eu-west-2` Region and $25$ spoke VPCs in the `ap-southeast-1` Region, all managed under a single AWS Organization. The company requires primary connectivity to on-premises data centers in London and Singapore via dedicated $10\text{ Gbps}$ AWS Direct Connect (DX) connections using Transit virtual interfaces (VIFs) connected to a shared Direct Connect Gateway (DXGW). An IPsec VPN over the public internet must serve as the backup connection for each region. A centralized Route 53 Private Hosted Zone (PHZ) for internal tooling (`corp.internal`) is hosted in a shared services account in `eu-west-2` and must be resolvable by all spoke VPCs in both regions.

The design must satisfy the following requirements:
* On-premises traffic must always prefer the Direct Connect path over the backup VPN when the Direct Connect connection is healthy.
* Spoke VPCs must route to their local regional data center but must be restricted from using the cross-region Transit Gateway peering connection to reach the remote regional data center.
* In the event of a regional Direct Connect outage, traffic must fail over to the local IPsec VPN instead of routing transitively through the peer region's Direct Connect.
* DNS resolution for `corp.internal` must be available in all spoke VPCs without exposing the zone to the public internet.

Which two configurations should a Solutions Architect implement to meet these requirements?

Select all that apply

In each region, associate a Spoke VPC Route Table with all spoke VPC attachments. In this route table, add a route for the local on-premises CIDR pointing to the local Transit Gateway (TGW) attachment to the DXGW, and propagate the local VPN attachment. In the TGW peering route table, only propagate or add routes for the remote VPC CIDR blocks, excluding the remote on-premises network prefixes.

On the on-premises customer gateway routers, configure BGP local preference to prefer routes received via the Direct Connect Transit VIFs over those received via the backup VPN tunnels. For outbound traffic from AWS, rely on the Transit Gateway's default path selection, which automatically prefers the Direct Connect Gateway attachment over the VPN attachment for the same propagated prefix.

Use the Direct Connect Gateway to perform transitive routing between the two regional Transit Gateways. In the Direct Connect Gateway, configure prefix filters to allow VPC-to-VPC routing across regions while blocking cross-region traffic from reaching the remote on-premises networks.

Associate the central Route 53 Private Hosted Zone (PHZ) in the shared services account with the Transit Gateway in each region, allowing all spoke VPCs connected to the Transit Gateways to resolve the hosted zone's records without further association.

Deploy a single shared transit VPC in each region containing a single NAT Gateway. Route all hybrid outbound traffic and backup VPN traffic from the spoke VPCs through the Transit Gateway to this NAT Gateway to centralize egress routing and reduce NAT Gateway hourly charges.

Show answer & explanation

Answer: In each region, associate a Spoke VPC Route Table with all spoke VPC attachments. In this route table, add a route for the local on-premises CIDR pointing to the local Transit Gateway (TGW) attachment to the DXGW, and propagate the local VPN attachment. In the TGW peering route table, only propagate or add routes for the remote VPC CIDR blocks, excluding the remote on-premises network prefixes.; On the on-premises customer gateway routers, configure BGP local preference to prefer routes received via the Direct Connect Transit VIFs over those received via the backup VPN tunnels. For outbound traffic from AWS, rely on the Transit Gateway's default path selection, which automatically prefers the Direct Connect Gateway attachment over the VPN attachment for the same propagated prefix.

Answer

Configure separate Transit Gateway route tables to restrict remote on-premises routing over the peering attachment, configure BGP local preference on-premises to prefer Direct Connect for inbound traffic, rely on Transit Gateway's native preference of Direct Connect over VPN for outbound traffic, and associate the Route 53 Private Hosted Zone with each spoke VPC.

The correct architecture uses AWS Transit Gateway to manage multi-VPC and hybrid connectivity, and configures the TGW route tables to isolate local on-premises routes from the cross-region peering connection. For path preference, Transit Gateway naturally prefers Direct Connect Gateway attachments over VPN attachments for the same prefix, and BGP local preference on the customer gateways ensures the same preference for the reverse path. The Private Hosted Zone must be associated with the individual VPCs to enable DNS resolution.

Step-by-Step Solution

Configure the Transit Gateway (TGW) route tables in each region to control traffic flow.

By creating a dedicated Spoke VPC Route Table that only contains routes for the local on-premises network (via DX/VPN) and the remote VPCs (via TGW Peering), you prevent spoke VPCs from routing traffic to the remote on-premises data center over the peering connection.

This satisfies the requirement to restrict cross-region transit traffic to remote on-premises data centers.

Configure BGP routing parameters on the customer gateway routers for inbound traffic to AWS.

On-premises routers will prefer the Direct Connect path over the backup VPN because of the higher BGP local preference configured on the Direct Connect interfaces.

This ensures that traffic from the on-premises networks to AWS prefers the high-speed Direct Connect connection under normal operations.

Rely on AWS Transit Gateway's default route selection for outbound traffic from AWS.

AWS Transit Gateway automatically selects the Direct Connect Gateway path over the VPN path when the same prefix is propagated by both attachments.

This achieves automatic failover and failback for outbound AWS-to-on-premises traffic with zero additional BGP path tuning on the AWS side.

Associate the Route 53 Private Hosted Zone (PHZ) with all consumer spoke VPCs.

Cross-account authorization and association allow all spoke VPCs to resolve resources in the shared services zone.

Route 53 PHZs cannot be associated with Transit Gateways; they must be associated directly with VPCs.

Key Concept

AWS Transit Gateway route table design and path selection priority for hybrid networks using Direct Connect and backup VPNs.

Question 730Question →

An online media streaming enterprise manages its AWS environment using AWS Organizations. The architecture consists of a `Shared-Network` account hosting a central Transit Gateway (TGW) and a Hub VPC, and a `Content-Delivery` account hosting a Spoke VPC containing application workloads. The Spoke VPC and Hub VPC are attached to the TGW, and the TGW connects to the enterprise's on-premises network via an AWS Direct Connect connection.

The on-premises network hosts local servers using the domain `corp.internal`. The `Content-Delivery` account hosts a Route 53 Private Hosted Zone (PHZ) for `stream.aws.internal` associated with its Spoke VPC. The `Shared-Network` account hosts a PHZ for `common.aws.internal` associated with its Hub VPC. The enterprise requires that:
1. On-premises clients must be able to resolve DNS records in both `stream.aws.internal` and `common.aws.internal`.
2. EC2 instances in both the Hub VPC and the Spoke VPC must be able to resolve DNS records in `corp.internal`.
3. Administrative overhead and costs must be minimized by avoiding redundant endpoints and ensuring DNS query loops are prevented.

Which of the following configuration strategies should a solutions architect implement to meet these requirements?

Deploy Route 53 Resolver Inbound and Outbound Endpoints in the Hub VPC. In the `Shared-Network` account, create an Outbound Resolver forwarding rule for `corp.internal` pointing to the on-premises DNS servers, share this rule with the Organization via AWS Resource Access Manager (RAM), and associate it with both VPCs. Share the `stream.aws.internal` Private Hosted Zone from the `Content-Delivery` account with the `Shared-Network` account using AWS RAM, and associate it with the Hub VPC. Configure on-premises DNS servers to forward queries for `aws.internal` to the Inbound Endpoints.

Deploy Route 53 Resolver Inbound and Outbound Endpoints in the Hub VPC. In the `Shared-Network` account, create an Outbound Resolver forwarding rule for `corp.internal` pointing to the on-premises DNS servers, share this rule with the Organization via AWS Resource Access Manager (RAM), and associate it with both VPCs. Keep the `stream.aws.internal` Private Hosted Zone associated only with the Spoke VPC in the `Content-Delivery` account. Configure on-premises DNS servers to forward queries for `aws.internal` to the Inbound Endpoints.

Deploy Route 53 Resolver Inbound and Outbound Endpoints in the Hub VPC. In the `Shared-Network` account, create an Outbound Resolver forwarding rule for `corp.internal` pointing to the on-premises DNS servers, share this rule with the Organization via AWS Resource Access Manager (RAM), and associate it with both VPCs. In the `Content-Delivery` account, authorize the association of `stream.aws.internal` with the Hub VPC, and then associate the zone from the `Shared-Network` account. Configure on-premises DNS servers to forward queries for `aws.internal` to the Inbound Endpoints.

Deploy Route 53 Resolver Inbound Endpoints in the Hub VPC and Outbound Endpoints in the Spoke VPC. In the `Content-Delivery` account, create an Outbound Resolver rule for `stream.aws.internal` pointing to the Inbound Endpoints in the Hub VPC. Configure on-premises DNS servers to forward queries for `aws.internal` to the Outbound Endpoints in the Spoke VPC using the Direct Connect Gateway's public virtual interface for routing.

Show answer & explanation

Answer: Deploy Route 53 Resolver Inbound and Outbound Endpoints in the Hub VPC. In the `Shared-Network` account, create an Outbound Resolver forwarding rule for `corp.internal` pointing to the on-premises DNS servers, share this rule with the Organization via AWS Resource Access Manager (RAM), and associate it with both VPCs. In the `Content-Delivery` account, authorize the association of `stream.aws.internal` with the Hub VPC, and then associate the zone from the `Shared-Network` account. Configure on-premises DNS servers to forward queries for `aws.internal` to the Inbound Endpoints.

Answer

Deploy Route 53 Resolver Inbound and Outbound Endpoints in the Hub VPC. In the Shared-Network account, create an Outbound Resolver forwarding rule for corp.internal pointing to the on-premises DNS servers, share this rule with the Organization via AWS Resource Access Manager (RAM), and associate it with both VPCs. In the Content-Delivery account, authorize the association of stream.aws.internal with the Hub VPC, and then associate the zone from the Shared-Network account. Configure on-premises DNS servers to forward queries for aws.internal to the Inbound Endpoints.

The correct configuration centralizes Route 53 Resolver Inbound and Outbound Endpoints within the Hub VPC to optimize architecture and minimize costs. To allow on-premises clients to resolve records in a Private Hosted Zone owned by another AWS account, the zone must be associated with the Hub VPC containing the Inbound Endpoints. This requires submitting a cross-account hosted zone association authorization from the owning account, and then associating the zone from the Network Services account. Outbound resolution for the on-premises domain is resolved by creating a forwarding rule and sharing it using AWS Resource Access Manager (RAM).

Step-by-Step Solution

Configure central Route 53 Resolver Inbound and Outbound Endpoints in the Shared-Network account's Hub VPC.

Establishes a single network ingress and egress point for hybrid DNS queries, minimizing resource costs.

Centralizing endpoints in a Hub VPC avoids deploying duplicate endpoints in every spoke VPC.

Create an Outbound forwarding rule for corp.internal in the Shared-Network account pointing to the on-premises DNS servers.

A Resolver forwarding rule is created and subsequently shared with the entire AWS Organization using AWS Resource Access Manager (RAM).

Allows both the Hub VPC and the Spoke VPC to forward on-premises DNS queries via the shared rule and the central Outbound Endpoints.

Authorize and associate the stream.aws.internal Private Hosted Zone (PHZ) with the Hub VPC.

The Content-Delivery account authorizes the cross-account association, and the Shared-Network account associates the hosted zone with the Hub VPC.

Route 53 Inbound Endpoints can only resolve PHZs associated with the VPC they reside in. Associating stream.aws.internal with the Hub VPC enables the Inbound Endpoints to resolve its records for on-premises clients.

Key Concept

Cross-account Private Hosted Zone association and Route 53 Resolver rule sharing in a hub-and-spoke hybrid network

Question 731Question →

A retail company is designing a disaster recovery (DR) and high availability architecture for its inventory management application. The primary environment runs in the eu-west-1 Region, and the DR environment will be deployed in the eu-central-1 Region. The application uses Amazon Aurora MySQL for database storage. The business requirements specify a Recovery Time Objective (RTO) of 15 minutes and a Recovery Point Objective (RPO) of 5 minutes. The application instances in both VPCs need to resolve internal endpoints using a Route 53 private hosted zone named inventory.internal. Additionally, application instances in the active Region must maintain redundant, highly available outbound internet connectivity to communicate with external supplier APIs, even during an Availability Zone outage. Which configuration meets these requirements with the least administrative complexity?

Configure an Amazon Aurora Global Database with the primary cluster in eu-west-1 and a secondary cluster in eu-central-1. Associate the inventory.internal private hosted zone with the VPCs in both Regions. In each VPC, deploy a single NAT Gateway in one Availability Zone, routing outbound internet traffic from all private subnets across all Availability Zones to this single NAT Gateway.

Configure an Amazon Aurora Global Database with the primary cluster in eu-west-1 and a secondary cluster in eu-central-1. Create the inventory.internal private hosted zone in eu-west-1 and rely on a Route 53 public resolver to resolve the endpoints from eu-central-1. In each VPC, deploy a NAT Gateway in each Availability Zone and update the route tables accordingly.

Configure an Amazon Aurora Global Database with the primary cluster in eu-west-1 and a secondary cluster in eu-central-1. Associate the inventory.internal private hosted zone with the VPCs in both Regions. In each VPC, deploy a NAT Gateway in each Availability Zone and update the route tables to route outbound internet traffic through the local NAT Gateway in the respective zone.

Set up daily Amazon Aurora snapshots in eu-west-1, copy them to eu-central-1 every 4 hours, and restore them in the event of a disaster. Associate the inventory.internal private hosted zone with the VPCs in both Regions. In each VPC, deploy a single NAT Gateway in one Availability Zone to route outbound internet traffic.

Show answer & explanation

Answer: Configure an Amazon Aurora Global Database with the primary cluster in eu-west-1 and a secondary cluster in eu-central-1. Associate the inventory.internal private hosted zone with the VPCs in both Regions. In each VPC, deploy a NAT Gateway in each Availability Zone and update the route tables to route outbound internet traffic through the local NAT Gateway in the respective zone.

Answer

Configure an Amazon Aurora Global Database with the primary cluster in eu-west-1 and a secondary cluster in eu-central-1. Associate the inventory.internal private hosted zone with the VPCs in both Regions. In each VPC, deploy a NAT Gateway in each Availability Zone and update the route tables to route outbound internet traffic through the local NAT Gateway in the respective zone.

The correct configuration implements Amazon Aurora Global Database to achieve low-latency cross-Region replication that easily satisfies the 5-minute RPO. It associates the private hosted zone with both VPCs to enable seamless private DNS resolution in both regions, and deploys multiple NAT Gateways (one per Availability Zone) to ensure that outbound internet connectivity to supplier APIs survives an Availability Zone outage.

Step-by-Step Solution

Evaluate the database replication strategy against RTO and RPO requirements.

Amazon Aurora Global Database provides asynchronous replication with typical latency of less than 1 second, fulfilling the 5-minute RPO requirement. Snapshot-based solutions fail this limit.

Choosing the appropriate database tier replication is critical to meeting strict recovery objectives.

Configure DNS resolution for the private domain.

Associate the Route 53 private hosted zone with the VPCs in both the primary and recovery Regions.

VPCs must be explicitly associated with a private hosted zone to resolve its DNS records.

Architect the NAT Gateway topology for outbound connectivity.

Deploy one NAT Gateway per Availability Zone in each VPC and update route tables to use the zone-local NAT Gateway.

This configuration guarantees that an outage in a single Availability Zone does not impact outbound internet traffic in the remaining zones.

Key Concept

Multi-region disaster recovery replication combined with private DNS VPC association and highly available NAT Gateway architectures.

Question 732Question →

An enterprise is configuring federated access to its multi-account AWS environment using an external SAML 2.0 Identity Provider (IdP). The Solutions Architect needs to establish trust and enable users authenticated by the external IdP to assume a specific read-only IAM role in multiple member accounts managed under AWS Organizations. Which of the following configuration steps are required to establish this federation trust relationship and allow users to access the member accounts? (Select TWO.)

Select all that apply

Configure the external IdP to output SAML assertions that include the https://aws.amazon.com/SAML/Attributes/Role attribute mapping the IAM role ARN to the SAML provider ARN, and the https://aws.amazon.com/SAML/Attributes/RoleSessionName attribute.

In each member account, create an IAM role with a trust policy that allows the standard sts:AssumeRole action and sets the principal to the AWS SAML service endpoint URL.

Create a Service Control Policy (SCP) at the root of the AWS Organization that allows the sts:AssumeRoleWithSAML action, which automatically propagates the SAML identity provider metadata and roles to all member accounts.

Register the SAML identity provider only in the AWS Organizations management account, and configure member accounts to trust the management account's IAM service principal using sts:AssumeRole.

Show answer & explanation

Answer: In each member account, create an IAM SAML identity provider using the SAML metadata document from the external IdP, and create an IAM role with a trust policy that allows the sts:AssumeRoleWithSAML action for the SAML provider ARN.; Configure the external IdP to output SAML assertions that include the https://aws.amazon.com/SAML/Attributes/Role attribute mapping the IAM role ARN to the SAML provider ARN, and the https://aws.amazon.com/SAML/Attributes/RoleSessionName attribute.

Answer

In each member account, create an IAM SAML identity provider using the SAML metadata document from the external IdP, and create an IAM role with a trust policy that allows the sts:AssumeRoleWithSAML action for the SAML provider ARN; and configure the external IdP to output SAML assertions that include the https://aws.amazon.com/SAML/Attributes/Role attribute mapping the IAM role ARN to the SAML provider ARN, and the https://aws.amazon.com/SAML/Attributes/RoleSessionName attribute.

Establishing a SAML 2.0 federation to multiple member accounts requires configuring trust on both sides. On the AWS side, each member account must have a registered IAM SAML identity provider and an IAM role configured with a trust policy that references that provider and permits the sts:AssumeRoleWithSAML action. On the identity provider side, the IdP must issue assertions containing the mandatory AWS SAML attributes: the Role attribute (specifying the role and provider ARN pair) and the RoleSessionName attribute (providing a session identifier for logging).

Step-by-Step Solution

Set up the identity trust inside the AWS member accounts.

An IAM SAML identity provider is created in each target account, establishing a cryptographic trust between AWS and the external IdP.

Each member account must recognize the external IdP as a trusted issuer of security assertions.

Create the IAM roles with trust policies referencing the SAML provider.

IAM roles are configured with a trust policy that allows the sts:AssumeRoleWithSAML action, targeted to the specific SAML provider ARN.

This grants permission to the federated users to assume the specific IAM role.

Configure the IdP claims mapping.

The IdP sends the mandatory AWS-specific SAML attributes (Role and RoleSessionName) in its SAML assertions.

AWS relies on these attributes to map the incoming user to the correct IAM role and SAML provider in the target account.

Key Concept

Direct SAML 2.0 federation configuration requires both trust registration in the target AWS account (using the sts:AssumeRoleWithSAML action in the role trust policy) and correct mapping of SAML attributes (Role and RoleSessionName) within the external Identity Provider.

Question 733Question →

A company is designing a high availability and disaster recovery architecture for a critical logistics fleet tracking application. The application runs on Amazon EC2 instances in private subnets behind an Application Load Balancer (ALB) in a primary VPC in us-east-1. The database layer uses Amazon Aurora PostgreSQL with auto-scaled Aurora Replicas for read queries. Private EC2 instances must access external mapping APIs via a NAT Gateway. The design must support a secondary VPC in us-west-2 for disaster recovery. The solution must achieve a Recovery Point Objective (RPO) of 15 minutes, a Recovery Time Objective (RTO) of 1 hour, and minimize operational costs. Which two actions should the solutions architect take to meet these requirements?

Select all that apply

Configure Amazon Aurora Global Database to replicate data from the primary VPC in us-east-1 to the secondary VPC in us-west-2, and provision a low-cost, scaled-down Aurora Replica in us-west-2.

Configure Amazon Route 53 with an active-passive failover routing policy, using Route 53 health checks tied to the primary ALB to automatically redirect public traffic to the secondary ALB during a failover event.

Maintain a single NAT Gateway in one Availability Zone of the primary Region, and configure all private subnets across both Availability Zones to route outbound internet traffic through this single gateway to minimize hourly charges.

Use AWS Backup to create daily snapshots of the database, copy them to the secondary Region, and restore the database to a new cluster in the secondary Region during a disaster recovery event.

Deploy an Amazon RDS PostgreSQL database in a Multi-AZ configuration in the primary Region, and configure the application to send read-heavy traffic to the standby instance in the secondary Availability Zone to scale read capacity.

Create a Route 53 Private Hosted Zone in the us-west-2 VPC to resolve the database's regional endpoint, without associating it with the primary us-east-1 VPC, and use it to route application database traffic.

Show answer & explanation

Answer: Configure Amazon Aurora Global Database to replicate data from the primary VPC in us-east-1 to the secondary VPC in us-west-2, and provision a low-cost, scaled-down Aurora Replica in us-west-2.; Configure Amazon Route 53 with an active-passive failover routing policy, using Route 53 health checks tied to the primary ALB to automatically redirect public traffic to the secondary ALB during a failover event.

Answer

Configure Amazon Aurora Global Database with a scaled-down replica in the secondary Region, and set up Route 53 active-passive failover routing with health checks pointing to the Application Load Balancers.

To meet the RPO of 15 minutes, database replication must be fast and reliable. Amazon Aurora Global Database provides sub-second replication latency to a secondary Region, and using a scaled-down instance class minimizes running costs while meeting the objectives. To meet the 1-hour RTO, DNS failover must be automated. Amazon Route 53 active-passive failover with health checks automatically detects a primary region failure and redirects traffic to the secondary Application Load Balancer.

Step-by-Step Solution

Analyze RPO and RTO requirements to select database replication and failover mechanisms.

Identify that a sub-second replication latency database (like Aurora Global Database) and automated DNS failover are required to meet the 15-minute RPO and 1-hour RTO.

Standard backups fail the RPO/RTO target, so active-passive replication is necessary.

Determine the database deployment strategy in the secondary Region.

Select Aurora Global Database with a scaled-down instance class in the target disaster recovery region to minimize cost.

This keeps costs low during normal operations while guaranteeing that replication remains up to date.

Set up external routing and health checks.

Configure Route 53 active-passive failover routing associated with Application Load Balancer health checks.

This automates the failover to the secondary Region within the 1-hour RTO without manual intervention.

Key Concept

Disaster Recovery strategies (Warm Standby/Pilot Light) require low-latency replication for short RPOs and automated DNS routing failover for low RTOs.

Question 734Question →

An enterprise is implementing a hub-and-spoke identity architecture across a multi-account environment managed by AWS Organizations. The central Hub account (Account A) hosts a SAML 2.0 Identity Provider (IdP) configuration. Users must authenticate via the IdP and assume a federated broker role named IdP-Broker-Role in Account A. From there, users must perform cross-account role assumption to access a target role named Application-Admin-Role in a member Production account (Account B). The security team requires that CostCenter attributes from the IdP be dynamically passed as session tags to enforce Attribute-Based Access Control (ABAC) in Account B. Additionally, an organizational guardrail must ensure that only federated access is permitted in Account B, with no direct IAM user access. During testing, users can log into Account A but receive an 'AccessDenied' error when attempting to assume the Application-Admin-Role in Account B. The session tags are also not propagating. Which configuration changes are required to successfully establish this federated access and session tag propagation while respecting organizational guardrails?

In Account A, configure the trust policy of IdP-Broker-Role to trust the SAML provider with sts:AssumeRoleWithSAML and sts:TagSession. In Account B, configure a Service Control Policy (SCP) at the OU level that explicitly allows sts:AssumeRole and sts:TagSession from Account A's IdP-Broker-Role to the Application-Admin-Role. This SCP configuration grants the necessary cross-account permissions, eliminating the need to manage individual trust policies on roles in Account B.

In Account A, configure the trust policy of IdP-Broker-Role to trust the SAML provider with sts:AssumeRoleWithWebIdentity and sts:TagSession. Attach a permissions policy to IdP-Broker-Role allowing sts:AssumeRole and sts:TagSession on the Application-Admin-Role in Account B. In Account B, configure the trust policy of Application-Admin-Role to trust the IdP-Broker-Role ARN with sts:AssumeRole, but omit sts:TagSession as session tags are automatically verified by the SAML assertion.

In Account A, configure the trust policy of IdP-Broker-Role to trust the SAML provider with sts:AssumeRoleWithSAML and sts:TagSession actions. Attach a permissions policy to IdP-Broker-Role allowing sts:AssumeRole and sts:TagSession on the Application-Admin-Role in Account B. In Account B, configure the trust policy of Application-Admin-Role to trust the IdP-Broker-Role ARN with sts:AssumeRole and sts:TagSession actions. Ensure the Service Control Policy (SCP) allows these actions and restricts access based on principal path or role ARN rather than relying on the aws:FederatedProvider key in Account B.

In Account A, configure the trust policy of IdP-Broker-Role to trust the SAML provider with the sts:AssumeRole action. Attach a permissions policy to IdP-Broker-Role allowing sts:AssumeRole on the Application-Admin-Role in Account B. In Account B, configure the trust policy of Application-Admin-Role to trust Account A's root principal, and rely on AWS Organizations' resource tag propagation to automatically carry the CostCenter attributes without enabling sts:TagSession.

Show answer & explanation

Answer: In Account A, configure the trust policy of IdP-Broker-Role to trust the SAML provider with sts:AssumeRoleWithSAML and sts:TagSession actions. Attach a permissions policy to IdP-Broker-Role allowing sts:AssumeRole and sts:TagSession on the Application-Admin-Role in Account B. In Account B, configure the trust policy of Application-Admin-Role to trust the IdP-Broker-Role ARN with sts:AssumeRole and sts:TagSession actions. Ensure the Service Control Policy (SCP) allows these actions and restricts access based on principal path or role ARN rather than relying on the aws:FederatedProvider key in Account B.

Answer

The correct option correctly configures the trust policies in both the Identity Account and the member Production Account to support SAML federation and session tagging. The SAML broker role trust policy requires the sts:AssumeRoleWithSAML action to allow IdP federation and the sts:TagSession action to ingest the CostCenter attribute as a session tag. For the cross-account transition, the target role in the member account must trust the broker role and also allow sts:TagSession so the tags carry over. Lastly, it recognizes that the aws:FederatedProvider context key is not present in cross-account role sessions assumed via AssumeRole, meaning the SCP must restrict access using alternative attributes like the principal path or role ARN.

Step-by-Step Solution

Configure SAML federation trust in the Hub account (Account A).

Update the trust policy of IdP-Broker-Role to target the SAML provider as the principal with the sts:AssumeRoleWithSAML and sts:TagSession actions.

This allows successful federation from the IdP and maps the SAML attributes (such as CostCenter) as session tags within the initial broker session.

Enable cross-account role assumption with session tags in the member account (Account B).

Configure the trust policy of Application-Admin-Role in Account B to trust the IdP-Broker-Role ARN from Account A, and explicitly allow both the sts:AssumeRole and sts:TagSession actions.

This allows the federated session to transition across accounts while preserving and accepting the CostCenter session tag for ABAC evaluation.

Grant permission in the Hub account to perform the cross-account transition.

Attach an IAM permissions policy to IdP-Broker-Role in Account A that allows sts:AssumeRole and sts:TagSession targeting the ARN of Application-Admin-Role in Account B.

The broker session must have permission to call AssumeRole and transmit session tags to the target member account.

Align the Service Control Policy (SCP) with the cross-account context.

Ensure the SCP permits the necessary STS actions, and avoid restricting member account operations using the aws:FederatedProvider condition key since it is null for cross-account assumed roles.

SCPs must act as guardrails without blocking legitimate cross-account federation paths that rely on sts:AssumeRole rather than direct SAML authentication inside the member account.

Key Concept

Hub-and-spoke SAML federation requires sts:AssumeRoleWithSAML for the initial broker session, sts:AssumeRole and sts:TagSession for cross-account propagation, and proper understanding of SCP evaluation context boundaries.

Question 735Question →

An organization manages a multi-account AWS environment with $12$ spoke VPCs in the `eu-west-1` Region and $8$ spoke VPCs in the `eu-central-1` Region. Spoke VPCs in each region are connected to a regional AWS Transit Gateway (TGW), and the two TGWs are peered. The organization is setting up hybrid connectivity to their on-premises data center. They want to implement a highly resilient design using a $10\text{ Gbps}$ AWS Direct Connect (DX) connection as the primary path and an AWS Site-to-Site VPN connection as an active-passive backup. The design must ensure that the VPN connection only carries traffic if the DX connection fails, and it must avoid asymmetric routing.

Which TWO configurations must a Solutions Architect implement to meet these requirements?

Select all that apply

Associate the Direct Connect Gateway (DXGW) with the Transit Gateway in each region, and configure BGP sessions over a Transit Virtual Interface (Transit VIF).

Establish Site-to-Site VPN connections to the Transit Gateways, and configure the on-premises router to set a higher BGP Local Preference for routes received via Direct Connect compared to the VPN.

Configure static routes in the Transit Gateway route tables pointing to the VPN attachments, while enabling BGP route propagation for the Direct Connect Gateway association.

Associate the Direct Connect Gateway with the Transit Gateway peering attachment to enable transitive cross-region routing.

Configure the on-premises router to prepend its autonomous system (AS) path multiple times when advertising prefixes over the Direct Connect connection.

Show answer & explanation

Answer: Associate the Direct Connect Gateway (DXGW) with the Transit Gateway in each region, and configure BGP sessions over a Transit Virtual Interface (Transit VIF).; Establish Site-to-Site VPN connections to the Transit Gateways, and configure the on-premises router to set a higher BGP Local Preference for routes received via Direct Connect compared to the VPN.

Answer

Associate the Direct Connect Gateway with the Transit Gateway in each region, and configure the on-premises router to set a higher BGP Local Preference for routes received via Direct Connect compared to the VPN.

The correct architecture uses a Direct Connect Gateway associated with regional Transit Gateways via a Transit VIF. For traffic leaving the on-premises data center to AWS, setting a higher BGP Local Preference for prefixes received over Direct Connect ensures that the data center router prefers the Direct Connect path. For traffic leaving AWS to on-premises, AWS automatically prefers Direct Connect over VPN for identical BGP-propagated prefixes, avoiding asymmetric routing.

Step-by-Step Solution

Analyze how to establish multi-region, multi-account hybrid connectivity for the Transit Gateways.

Associate the Direct Connect Gateway (DXGW) with the Transit Gateway in each region using a Transit Virtual Interface (Transit VIF) to support scalable routing across regions.

Direct Connect Gateway allows a single DX connection to be shared across multiple Transit Gateways in different AWS Regions.

Determine the proper configuration to ensure that the on-premises data center prefers sending traffic via the Direct Connect connection rather than the VPN.

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

Local Preference is the primary BGP attribute used to influence outbound traffic paths from an autonomous system. Setting a higher value for DX routes ensures they are preferred over VPN routes.

Ensure that AWS prefers sending traffic to on-premises via Direct Connect rather than VPN.

Ensure BGP route propagation is enabled for both connections without static route overrides.

AWS naturally prefers Direct Connect paths over VPN paths when identical prefixes are received via BGP, so no additional AWS-side route prepending or path tuning is strictly required, provided static routes do not override the BGP path.

Key Concept

To establish a highly available hybrid network with AWS Transit Gateway, a Direct Connect Gateway associated with Transit Gateways via a Transit VIF provides primary routing, while a Site-to-Site VPN provides backup. Proper BGP configuration (such as Local Preference on-premises) is required to control traffic symmetry and failover priority without relying on static route overrides which would disrupt dynamic failover.

Question 736Question →

An automotive technology enterprise has established a multi-account AWS environment using AWS Organizations. The network topology consists of a Shared Services VPC and several spoke VPCs in different member accounts, all interconnected via an AWS Transit Gateway. The Shared Services VPC contains Route 53 Resolver inbound and outbound endpoints connected to the on-premises corporate network over an AWS Direct Connect connection. A Private Hosted Zone (PHZ) for auto.internal is hosted in a dedicated DevOps AWS account. A Solutions Architect must configure the architecture so that resources in the spoke VPCs can resolve DNS queries for the on-premises domain corp.local and the AWS Private Hosted Zone auto.internal.

Which TWO actions should the Solutions Architect take to configure DNS resolution for this architecture? (Select TWO.)

Select all that apply

Create cross-account VPC association authorizations for the auto.internal private hosted zone in the DevOps account for each spoke VPC, and then associate the private hosted zone with each spoke VPC from their respective accounts.

Create a Route 53 Resolver forwarding rule for corp.local in the Shared Services account pointing to the on-premises DNS servers via the outbound resolver endpoint, share the rule with the spoke accounts using AWS Resource Access Manager (RAM), and associate the rule with each spoke VPC.

Associate the auto.internal private hosted zone with the Shared Services VPC only, and configure the spoke VPCs' DHCP options sets to use the Route 53 Resolver inbound endpoint IP addresses in the Shared Services VPC.

Share the Route 53 Resolver outbound endpoint directly with the spoke accounts using AWS Resource Access Manager (RAM), and create local resolver rules in each spoke account that route DNS traffic through the Direct Connect Gateway.

Show answer & explanation

Answer: Create cross-account VPC association authorizations for the auto.internal private hosted zone in the DevOps account for each spoke VPC, and then associate the private hosted zone with each spoke VPC from their respective accounts.; Create a Route 53 Resolver forwarding rule for corp.local in the Shared Services account pointing to the on-premises DNS servers via the outbound resolver endpoint, share the rule with the spoke accounts using AWS Resource Access Manager (RAM), and associate the rule with each spoke VPC.

Answer

Create cross-account VPC association authorizations for the private hosted zone in the DevOps account and associate it with the spoke VPCs, and create a Route 53 Resolver forwarding rule for the on-premises domain in the Shared Services VPC account, share it via AWS RAM, and associate it with each spoke VPC.

The correct solution involves two distinct parts: first, establishing resolution for the AWS private hosted zone across accounts by creating VPC association authorizations in the owner account and then executing the association in the member accounts; second, enabling resolution for the on-premises domain by creating a resolver forwarding rule in the Shared Services account, sharing that rule via AWS RAM, and associating it with the spoke VPCs.

Step-by-Step Solution

Authorize the cross-account association of the private hosted zone with each spoke VPC from the DevOps account where the zone resides.

Association authorizations are created and registered for the spoke VPCs.

Before a VPC in another account can be associated with a private hosted zone, the hosted zone owner must authorize the cross-account association.

Associate the private hosted zone with the spoke VPCs from each of the spoke VPC accounts.

The private hosted zone is associated with all spoke VPCs.

This allows resources inside the spoke VPCs to perform local DNS lookups for the hosted zone domain directly.

Create a Route 53 Resolver forwarding rule for the corporate domain pointing to the on-premises DNS servers, share this rule with the spoke accounts using AWS RAM, and associate it with each spoke VPC.

The spoke VPCs can now forward queries for the corporate domain to the outbound endpoint in the Shared Services VPC.

This allows spoke VPCs to utilize the centralized hybrid network path for resolving corporate on-premises DNS queries.

Key Concept

Centralized and cross-account DNS resolution in a hybrid, multi-account AWS environment using Route 53 Resolver endpoints and cross-account Private Hosted Zone association.

Question 737Question →

A financial services company is designing a federated access model for its multi-account AWS environment managed by AWS Organizations. The company utilizes a centralized identity account (Hub) to federate users from an external SAML 2.0 Identity Provider (IdP). Federated users must assume cross-account IAM roles in various destination member accounts (Spokes). The security team requires that federated session tags (such as CostCenter and Department) passed by the SAML IdP are propagated transitively to the destination roles in the member accounts to support Attribute-Based Access Control (ABAC). Additionally, member account roles must restrict access to only those sessions that originated from the central federation role in the Hub account.

Which configuration strategy correctly establishes this federated trust chain while meeting the security requirements?

Configure the SAML identity provider in the Hub account. Create an IAM role in the Hub account with a trust policy that permits sts:AssumeRoleWithSAML and sts:TagSession for the SAML provider. In the Spoke accounts, configure the trust policy of the destination IAM roles to permit sts:AssumeRole and sts:TagSession for the Hub account's IAM role, and enforce tag presence using aws:PrincipalTag condition keys.

Configure the SAML identity provider in the Hub account. Create an IAM role in the Hub account with a trust policy that permits sts:AssumeRole and sts:TagSession for the SAML provider principal. In the Spoke accounts, configure the trust policy of the destination IAM roles to permit sts:AssumeRoleWithSAML and sts:TagSession for the Hub account's IAM role, relying on SAML assertion forwarding.

Configure the SAML identity provider in the Hub account. Create an IAM role in the Hub account with a trust policy permitting sts:AssumeRoleWithSAML. Apply a Service Control Policy (SCP) at the Root organizational level that explicitly allows sts:AssumeRole and tag propagation across all member accounts, thereby bypassing the need to configure individual trust policies or permissions on the destination IAM roles in the Spoke accounts.

Configure the SAML identity provider in the Hub account. Create an IAM role in the Hub account with a trust policy that permits sts:AssumeRoleWithSAML for the SAML provider. For the destination roles in the Spoke accounts, enable resource sharing via AWS Resource Access Manager (RAM) to share the Hub role with the Spoke accounts, allowing users to assume the role directly without configuring trust policies.

Show answer & explanation

Answer: Configure the SAML identity provider in the Hub account. Create an IAM role in the Hub account with a trust policy that permits sts:AssumeRoleWithSAML and sts:TagSession for the SAML provider. In the Spoke accounts, configure the trust policy of the destination IAM roles to permit sts:AssumeRole and sts:TagSession for the Hub account's IAM role, and enforce tag presence using aws:PrincipalTag condition keys.

Answer

The correct configuration establishes a secure trust chain that supports transitive tag propagation. By permitting both sts:AssumeRoleWithSAML and sts:TagSession on the Hub role, the SAML assertions and their associated attributes are correctly ingested as session tags. Subsequently, by permitting sts:AssumeRole and sts:TagSession on the Spoke roles for the Hub role principal, those session tags are carried over to the destination role session, allowing for ABAC using aws:PrincipalTag condition keys.

Step-by-Step Solution

Configure the identity federation in the Hub account by creating a SAML Identity Provider resource and an IAM role representing the federated users.

The Hub role's trust policy permits sts:AssumeRoleWithSAML and sts:TagSession, allowing SAML assertions to be converted into AWS security credentials containing session tags.

The sts:TagSession action is required in the trust policy to permit the SAML IdP to pass session tags (such as CostCenter and Department) during the federation process.

Configure the cross-account trust relationship on the target roles in the Spoke accounts.

The target roles in the Spoke accounts trust the Hub role ARN and allow the sts:AssumeRole and sts:TagSession actions.

To propagate session tags transitively during a cross-account role assumption, the target role's trust policy must explicitly permit sts:TagSession in addition to sts:AssumeRole.

Enforce Attribute-Based Access Control (ABAC) in the Spoke accounts using policies with PrincipalTag condition keys.

Access is granted or denied dynamically based on the session tags matching resource tags or specific values.

Propagating the session tags transitively ensures they are present as principal tags (aws:PrincipalTag/TagKey) when evaluating policies in the Spoke accounts.

Key Concept

Transitive session tag propagation in multi-account SAML federation

Estimated Time:3m 0s

Question 738Question →

A media streaming enterprise manages its multi-account environment using AWS Organizations with consolidated billing. A central Infrastructure account hosts a shared VPC. The solutions architect must enable several Production Application accounts to deploy Amazon ECS tasks within the private subnets of this shared VPC. The architect must also ensure that the Production Application accounts cannot view, create, or modify network configurations such as Route Tables or Network ACLs. Additionally, the enterprise has purchased Savings Plans in the Management account. These Savings Plans discounts must apply to all Production Application accounts, but must not apply to a designated Test account. Which architectural and billing strategy should the solutions architect implement?

In the Infrastructure account, use AWS Resource Access Manager (RAM) to share the private subnets with the Production Application accounts. In the AWS Billing console of the Management account, disable Savings Plan discount sharing for the Test account.

In the Infrastructure account, use AWS Resource Access Manager (RAM) to share the entire VPC with the Production Application accounts. In the AWS Billing console of the Management account, disable Savings Plan discount sharing for the Test account.

In the Infrastructure account, use AWS Resource Access Manager (RAM) to share the private subnets with the Production Application accounts. Apply a Service Control Policy (SCP) to the Test account's Organizational Unit (OU) that denies the savingsplans:ApplySavingsPlans action.

Deploy VPC peering connections between the Infrastructure VPC and the Production Application VPCs. In the AWS Billing console of the Infrastructure account, disable Savings Plan discount sharing for the Test account.

Show answer & explanation

Answer: In the Infrastructure account, use AWS Resource Access Manager (RAM) to share the private subnets with the Production Application accounts. In the AWS Billing console of the Management account, disable Savings Plan discount sharing for the Test account.

Answer

The correct strategy uses AWS Resource Access Manager (RAM) in the Infrastructure account to share subnets with the Production Application accounts. This allows them to run workloads without having visibility or control over VPC routing and security configurations. To selectively exclude the Test account from the consolidated Savings Plans benefit, the architect must disable Savings Plan discount sharing for the Test account within the AWS Billing preferences of the Organizations Management account.

Step-by-Step Solution

Evaluate the sharing mechanism for VPC resources.

Identify that AWS Resource Access Manager (RAM) supports sharing VPC subnets, but not the entire VPC resource. Sharing subnets restricts resource management permissions in member accounts, meaning they can launch resources but cannot modify VPC route tables, internet gateways, or network ACLs.

This satisfies the requirement to allow resource deployment while restricting control over the network configuration.

Determine the control plane for billing discount sharing.

Confirm that Savings Plans discounts are shared across accounts under AWS Organizations by default, and this preference can only be modified from the Management (payer) account billing preferences console.

Only the Management account has administrative control over consolidated billing features and discount distribution preferences.

Assess the capabilities of Service Control Policies (SCPs) regarding billing.

Recognize that SCPs restrict API actions, but do not affect consolidated billing discount distribution rules.

This rules out using SCPs to deny the application of Savings Plans discounts.

Key Concept

AWS VPC sharing via RAM allows secure multi-tenant network partitioning, while Savings Plans discount sharing preferences must be managed in the Organizations Management account.

Question 739Question →

An enterprise manages its multi-account environment using AWS Organizations. The architecture consists of a Management account, a central Network account, a dedicated Log Archive account, and multiple Application accounts. A solutions architect is designing a resource sharing and cost management strategy with the following requirements:

* Subnets from a central VPC in the Network account must be shared with the Application accounts to run EC2 instances and ECS tasks on AWS Fargate.
* Application teams must be able to control network traffic to their resources within these shared subnets.
* AWS CloudTrail logs from all accounts must be consolidated into a single S3 bucket in the Log Archive account. These logs must be encrypted using a KMS key that the security team can rotate manually.
* The company wants to maximize cost savings for both EC2 and Fargate workloads across all accounts in the organization.

Which strategy should the solutions architect implement to meet these requirements?

Enable resource sharing within the organization in the Management account. In the Network account, use AWS Resource Access Manager (RAM) to share the private subnets with the Application accounts. Instruct the application teams to create and associate their own security groups locally within their accounts. In the Log Archive account, create an S3 bucket and a customer managed KMS key. Configure the S3 bucket policy to allow the CloudTrail service principal to write logs using the aws:PrincipalOrgID condition, and allow the service principal to use the KMS key. Configure CloudTrail in all accounts to send logs to this bucket. Purchase Compute Savings Plans in the Management account with sharing enabled.

Enable resource sharing within the organization in the Management account. In the Network account, use AWS RAM to share the private subnets and central security groups with the Application accounts. In the Log Archive account, create an S3 bucket and encrypt it using the default AWS-managed S3 key (aws/s3). Modify the key policy of aws/s3 to permit cross-account CloudTrail access. Configure CloudTrail in all accounts to send logs to this bucket. Purchase Compute Savings Plans in the Management account with sharing enabled.

Enable resource sharing within the organization in the Management account. In the Network account, use AWS RAM to share the private subnets with the Application accounts. Instruct the application teams to create their own security groups. In the Log Archive account, create an S3 bucket. Apply a Service Control Policy (SCP) at the root level of the organization that grants s3:PutObject permission on the Log Archive S3 bucket to all member accounts. Purchase EC2 Instance Savings Plans in the Management account with sharing enabled.

Enable resource sharing within the organization in the Management account. In the Network account, use AWS RAM to share the private subnets with the Application accounts. Instruct the application teams to create their own security groups. In the Log Archive account, create an S3 bucket and a customer managed KMS key. Configure the S3 bucket policy to allow access only to the Management account's root principal. Configure CloudTrail in all accounts to send logs to this bucket. Purchase Compute Savings Plans in the Management account with sharing disabled, and manually transfer the Savings Plans credits to the member accounts.

Show answer & explanation

Answer: Enable resource sharing within the organization in the Management account. In the Network account, use AWS Resource Access Manager (RAM) to share the private subnets with the Application accounts. Instruct the application teams to create and associate their own security groups locally within their accounts. In the Log Archive account, create an S3 bucket and a customer managed KMS key. Configure the S3 bucket policy to allow the CloudTrail service principal to write logs using the aws:PrincipalOrgID condition, and allow the service principal to use the KMS key. Configure CloudTrail in all accounts to send logs to this bucket. Purchase Compute Savings Plans in the Management account with sharing enabled.

Answer

The solutions architect should enable resource sharing in the Management account, share private subnets using AWS RAM, and have application teams create their own local security groups. To centralize logs, they should use a customer managed KMS key and an S3 bucket policy with the aws:PrincipalOrgID condition. To maximize savings across both EC2 and Fargate, they should purchase Compute Savings Plans in the Management account with sharing enabled.

The correct strategy coordinates AWS RAM, custom KMS encryption, and Compute Savings Plans properly. AWS Resource Access Manager (RAM) allows sharing VPC subnets within an AWS Organization. Security groups cannot be shared using RAM, so participant accounts must create their own security groups locally. For centralized logging, a customer managed KMS key is necessary because AWS-managed keys (like aws/s3) cannot be shared or modified. Finally, Compute Savings Plans purchased in the Management account automatically apply to EC2 and Fargate across the organization when billing sharing is enabled.

Step-by-Step Solution

Configure VPC sharing using AWS Resource Access Manager (RAM).

Private subnets from the Network account are shared with the Application accounts. Application teams can deploy EC2 instances and ECS Fargate tasks in these subnets but must create their own local security groups, as security groups cannot be shared via RAM.

This establishes shared network infrastructure while maintaining isolation of security group management within the application teams.

Set up centralized CloudTrail logging in the Log Archive account.

An S3 bucket is created with a bucket policy allowing the cloudtrail.amazonaws.com service principal to write logs, restricted to the organization using the aws:PrincipalOrgID condition. A customer managed KMS key is created with a policy permitting CloudTrail access.

AWS-managed KMS keys (like aws/s3) do not support policy modification and cannot be used for cross-account CloudTrail encryption. A customer managed key is required.

Implement the cost management strategy using Savings Plans.

Compute Savings Plans are purchased in the Management account, and sharing is enabled in the consolidated billing configuration.

Compute Savings Plans cover both EC2 and Fargate workloads. Having sharing enabled allows unused savings from the Management account to apply to member accounts, maximizing cost efficiency.

Key Concept

Multi-account resource sharing with AWS RAM, cross-account log consolidation with customer managed KMS keys, and cost optimization via Compute Savings Plans.

Estimated Time:3m 0s

Question 740Question →

A financial technology company is designing a new multi-region transaction processing platform. The platform must serve users in both the United States and Europe with minimal latency. Outbound transactions must connect to external payment processors via public APIs. The recovery objectives for the architecture are:
- Recovery Point Objective (RPO): Less than 1 second for database transactions.
- Recovery Time Objective (RTO): Less than 2 minutes for a complete regional outage.

The application tier runs on Amazon ECS on AWS Fargate in private subnets and connects to an Amazon Aurora MySQL database cluster. The network architecture must also ensure that the loss of a single Availability Zone (AZ) does not disrupt outbound connection capability to external payment gateways, and that internal API microservices deployed in separate VPCs within both regions can resolve the private DNS names of the database endpoints.

Which two options should a Solutions Architect select to meet these requirements?

Select all that apply

Deploy an Amazon Aurora Global Database with the primary writer cluster in us-east-1 and a secondary reader cluster in eu-west-1. Use Route 53 failover routing policy with health checks linked to the Application Load Balancers for traffic management, and execute a managed failover of the Aurora Global Database during a regional outage.

Deploy a NAT Gateway in each Availability Zone within each region, configuring the route tables of the private subnets to use the local NAT Gateway. Associate the database's Route 53 Private Hosted Zone with the application VPCs in both regions.

Deploy a single NAT Gateway in the primary Availability Zone of each region to optimize outbound data transfer costs. Create a single Route 53 Private Hosted Zone in the primary database VPC, and configure the secondary region VPC to resolve endpoints using Transit Gateway routes.

Deploy Amazon Aurora multi-region read replicas using cross-region snapshot copy and restore. During a disaster recovery event, promote the replica database in eu-west-1, modify the database endpoint, and redeploy the Fargate tasks with updated environment variables.

Enable Aurora Auto Scaling replicas in the secondary region to automatically scale the reader endpoints to handle primary write traffic in active-active mode, using Route 53 Latency-based routing to direct write requests directly to the nearest regional database endpoint.

Show answer & explanation

Answer: Deploy an Amazon Aurora Global Database with the primary writer cluster in us-east-1 and a secondary reader cluster in eu-west-1. Use Route 53 failover routing policy with health checks linked to the Application Load Balancers for traffic management, and execute a managed failover of the Aurora Global Database during a regional outage.; Deploy a NAT Gateway in each Availability Zone within each region, configuring the route tables of the private subnets to use the local NAT Gateway. Associate the database's Route 53 Private Hosted Zone with the application VPCs in both regions.

Answer

Deploy an Amazon Aurora Global Database with failover routing policies, deploy a NAT Gateway in each Availability Zone within each region, and associate the Route 53 Private Hosted Zone with the application VPCs in both regions.

The correct architecture uses Amazon Aurora Global Database to achieve the required sub-second database RPO and supports managed failover under the 2-minute RTO. Route 53 active-passive failover routing ensures traffic is correctly rerouted to the secondary region's ALBs during a regional disaster. High availability for outbound payment processing is achieved by deploying a NAT Gateway in each Availability Zone, isolating zone failures. Finally, associating the Route 53 Private Hosted Zone with the consumer VPCs in both regions allows proper DNS resolution of database endpoints across the network boundary.

Step-by-Step Solution

Select the multi-region database replication and failover mechanism.

Amazon Aurora Global Database provides physical replication lag of less than 1 second (meeting the RPO) and managed failover in under a minute (meeting the RTO).

Standard replication or snapshot recovery techniques do not provide the necessary replication speed or failover automation to meet the RPO and RTO constraints.

Ensure outbound HA by designing NAT Gateway placement.

Place a NAT Gateway in each Availability Zone so that an outage in one zone does not disrupt outbound egress from other zones.

Using a single NAT Gateway per region introduces a single point of failure (SPOF) for the entire VPC's outbound connections.

Configure DNS resolution for private database endpoints across VPCs.

Associate the Route 53 Private Hosted Zone of the database with all application VPCs in both regions.

Private Hosted Zones are only resolvable from VPCs that have been explicitly associated with them.

Determine global traffic routing policy.

Use Route 53 active-passive failover routing linked to Application Load Balancer health checks.

This setup ensures incoming client requests are redirected to the secondary region if the primary region's application tier is impaired.

Key Concept

High Availability and Disaster Recovery Design for Multi-Region Multi-AZ Architectures

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