All practice questions

1964 questions

All types1,964 Multiple choice1,006 Multiple select931 Ordering27

A multinational enterprise is designing a hybrid network connectivity architecture to connect its on-premises data center (IP range $192.168.0.0/16$ ) to its AWS multi-account environment. The AWS environment consists of dozens of VPCs distributed across $us-east-1$ and $us-west-2$ . The company requires a highly available network design that satisfies the following conditions:

* Primary connectivity must use a $10\text{ Gbps}$ AWS Direct Connect connection terminated at a location associated with $us-east-1$ .
* Backup connectivity must use AWS Site-to-Site VPN connections over the public internet.
* All outbound traffic from both AWS regions to the on-premises data center must prefer the Direct Connect connection under normal conditions, and automatically fail over to the local region's VPN connection if the Direct Connect path becomes unavailable.
* Inbound traffic from the on-premises data center to AWS must prefer the Direct Connect path under normal conditions.
* Administrative overhead and manual route table updates must be minimized.

Which configuration should a solutions architect recommend to meet these requirements?

Establish an AWS Transit Gateway (TGW) in each region and attach the local spoke VPCs. Connect the Direct Connect connection to a Direct Connect Gateway (DXGW) using a Transit Virtual Interface (Transit VIF), and associate the DXGW with the TGW in both regions. Establish BGP-enabled Site-to-Site VPN connections directly to each TGW. Configure the customer gateway to advertise

192.168.0.0/16

over both the Direct Connect and VPN connections. In the TGW route tables, enable route propagation for both the DXGW and VPN attachments. On the customer gateway, configure BGP local preference to prefer routes received over the Direct Connect connection.

192.168.0.0/16

in the TGW route tables pointing to the DXGW attachment, and duplicate static routes with a higher metric pointing to the VPN attachments to enable automatic failover.

Deploy Virtual Private Gateways (VGWs) in all spoke VPCs in both regions and attach them directly to a Direct Connect Gateway (DXGW) via Private Virtual Interfaces (Private VIFs) for primary connectivity. Establish a software-defined VPN mesh between the on-premises customer gateway and EC2 instances running software routers in each VPC for backup. Use BGP on the customer gateway to route transitive traffic between the VPCs in different regions through the DXGW.

Establish an AWS Transit Gateway (TGW) in

us-east-1

and attach all spoke VPCs in both regions to it. Deploy a single NAT Gateway in a central egress VPC in

us-east-1

and establish the Direct Connect connection using a Public Virtual Interface (Public VIF). Set up a single Site-to-Site VPN connection from the customer gateway to the TGW in

us-east-1

as a backup. Configure the on-premises customer gateway to route all traffic to AWS through the NAT Gateway's public IP address.

Show answer & explanation

Answer: Establish an AWS Transit Gateway (TGW) in each region and attach the local spoke VPCs. Connect the Direct Connect connection to a Direct Connect Gateway (DXGW) using a Transit Virtual Interface (Transit VIF), and associate the DXGW with the TGW in both regions. Establish BGP-enabled Site-to-Site VPN connections directly to each TGW. Configure the customer gateway to advertise $192.168.0.0/16$ over both the Direct Connect and VPN connections. In the TGW route tables, enable route propagation for both the DXGW and VPN attachments. On the customer gateway, configure BGP local preference to prefer routes received over the Direct Connect connection.

Answer

The correct configuration uses AWS Transit Gateways associated with a Direct Connect Gateway using a Transit VIF for the primary path, and BGP-enabled Site-to-Site VPNs directly connected to each Transit Gateway for backup. By propagating routes from both paths, Transit Gateway natively prefers the Direct Connect Gateway path due to its built-in route priority. To ensure symmetric routing, BGP Local Preference is configured on the customer gateway to prefer the Direct Connect path for traffic entering AWS.

Step-by-Step Solution

Connect the multi-region Transit Gateways (

TGW-East

and

TGW-West

) to a central Direct Connect Gateway (DXGW) using a Transit VIF to establish the primary hybrid path.

Spoke VPCs in both regions can route traffic to the on-premises data center via their local Transit Gateways and the shared DXGW.

Direct Connect Gateway enables multi-region connectivity to Transit Gateways over a single Transit VIF, minimizing routing complexity and cost.

Establish BGP-enabled AWS Site-to-Site VPN connections from the customer gateway directly to the TGW in each region to serve as the backup path.

Backup paths are available locally in each region, bypassing the Direct Connect path if it fails.

Terminating the VPN directly on the Transit Gateways allows BGP to dynamically propagate backup routes.

Advertise the on-premises summary CIDR (

192.168.0.0/16

) from the customer gateway over both the Direct Connect and VPN BGP sessions, and enable route propagation in the TGW route tables.

TGW automatically prefers the DXGW-propagated route over the VPN-propagated route for outbound traffic.

The AWS Transit Gateway route selection algorithm natively prioritizes Direct Connect Gateway attachments over VPN attachments for identical prefixes.

Configure BGP Local Preference on the on-premises customer gateway to prefer routes received via the Direct Connect Transit VIF over the VPN tunnels.

Inbound traffic from the on-premises data center to AWS VPCs will prefer the Direct Connect path.

AWS BGP advertisements alone do not guarantee customer-side path preference; Local Preference is the standard BGP mechanism to control outbound routing decisions on the customer gateway.

Key Concept

AWS Transit Gateway path selection and BGP path tuning for hybrid and multi-region network failover.

Estimated Time:3m 0s

Question 1882Question →

A financial services organization has a multi-account AWS environment with twenty VPCs in the us-east-1 region and ten VPCs in the us-west-2 region. The backend development teams require private, low-latency connectivity from their on-premises data center to all thirty VPCs. Additionally, applications in us-east-1 must communicate directly with databases in us-west-2. The network design must minimize BGP sessions, scale efficiently for future VPCs, and avoid routing inter-VPC traffic through the on-premises data center. Which network design meets these requirements?

Deploy an AWS Transit Gateway in us-east-1 and another in us-west-2, and attach the local VPCs to their respective Transit Gateway. Create a Direct Connect Gateway, associate it with both Transit Gateways, and connect it to the on-premises network using a Transit Virtual Interface. Establish an inter-region Transit Gateway peering attachment between the two Transit Gateways.

Create a Direct Connect Gateway and connect it to the on-premises network using a Private Virtual Interface. Create Virtual Private Gateways in each of the thirty VPCs and associate all of them with the Direct Connect Gateway. Establish a full mesh of VPC peering connections between all VPCs across both regions to handle inter-region traffic.

Deploy an AWS Transit Gateway in us-east-1 and another in us-west-2, and attach the local VPCs to their respective Transit Gateway. Create a Direct Connect Gateway, associate it with both Transit Gateways, and connect it to the on-premises network using two Private Virtual Interfaces on the Direct Connect connection.

Deploy an AWS Transit Gateway in us-east-1 and another in us-west-2, and attach the local VPCs to their respective Transit Gateway. Create a Direct Connect Gateway, associate it with both Transit Gateways, and connect it to the on-premises network using a Transit Virtual Interface. Configure the on-premises router to route and transit traffic between the two Transit Gateways to enable inter-VPC communication across regions.

Show answer & explanation

Answer: Deploy an AWS Transit Gateway in us-east-1 and another in us-west-2, and attach the local VPCs to their respective Transit Gateway. Create a Direct Connect Gateway, associate it with both Transit Gateways, and connect it to the on-premises network using a Transit Virtual Interface. Establish an inter-region Transit Gateway peering attachment between the two Transit Gateways.

Answer

Deploy regional AWS Transit Gateways connected to a Direct Connect Gateway via a Transit Virtual Interface, and peer the Transit Gateways for inter-region communication.

The correct architecture uses AWS Transit Gateways in each region to aggregate VPC attachments. By connecting both Transit Gateways to a single Direct Connect Gateway using a Transit Virtual Interface, you minimize BGP sessions and establish efficient hybrid routing. Establishing a Transit Gateway peering attachment ensures that cross-region inter-VPC traffic is routed directly over the AWS backbone, satisfying the requirement to avoid hair-pinning traffic through the on-premises router.

Step-by-Step Solution

Determine the scale and routing requirements for the hybrid topology.

Thirty VPCs across two regions require private connectivity to on-premises and direct, low-latency inter-VPC communication.

This rules out Virtual Private Gateways associated with a Direct Connect Gateway due to the 10-association limit.

Choose the correct Direct Connect virtual interface type for Transit Gateway association.

A Transit Virtual Interface (Transit VIF) must be used to connect the Direct Connect Gateway to the regional Transit Gateways.

Private Virtual Interfaces are incompatible with Transit Gateways and cannot be used for transit routing configurations.

Establish direct inter-region VPC routing path.

Configure a Transit Gateway peering attachment between the Transit Gateways in us-east-1 and us-west-2.

This routes cross-region VPC traffic over the AWS global network backbone, avoiding routing through the on-premises data center.

Key Concept

Design of scalable hybrid connectivity using Transit Gateways, Transit VIFs, and Transit Gateway Peering across multiple regions.

Question 1883Question →

Luminary Healthcare is modernizing its legacy patient record indexing engine by migrating it to AWS. The workload consists of a front-end user interface container and a back-end indexing processor container. The legacy code is hardcoded to communicate over the local loopback address ( $127.0.0.1$ ) on port $8080$ . The company wants to deploy this solution to Amazon ECS using the AWS Fargate launch type to eliminate EC2 instance provisioning and minimize operational overhead. Traffic between the two containers must remain private and secure without transiting external load balancers. Which configuration should the Solutions Architect select to meet these requirements?

Define both the front-end and back-end containers in a single Amazon ECS task definition, and deploy it to a service using the AWS Fargate launch type. Because AWS Fargate requires the awsvpc network mode, the containers will share the task network namespace and communicate over the loopback interface.

Define the front-end and back-end containers in separate Amazon ECS task definitions, configure the task definitions to use the host network mode, and deploy them to the same ECS cluster using the AWS Fargate launch type to bind the containers directly to the underlying host interface.

Define the front-end and back-end containers in separate Amazon ECS task definitions, deploy them to separate ECS services using the awsvpc network mode, and route traffic between them using an Application Load Balancer with a Route 53 Private Hosted Zone that is created in the AWS account but not associated with the VPC.

Define both the front-end and back-end containers in a single Amazon ECS task definition, configure the task definition to use the bridge network mode, and map the containers using Docker links to allow direct port communication over the bridge network interface on AWS Fargate.

Show answer & explanation

Answer: Define both the front-end and back-end containers in a single Amazon ECS task definition, and deploy it to a service using the AWS Fargate launch type. Because AWS Fargate requires the awsvpc network mode, the containers will share the task network namespace and communicate over the loopback interface.

Answer

Defining both containers in a single task definition on AWS Fargate allows them to share the task's network namespace (due to the mandatory awsvpc network mode) and communicate over the local loopback interface (

127.0.0.1

Defining both containers in a single task definition under the AWS Fargate launch type is correct because AWS Fargate mandates the awsvpc network mode. Under awsvpc, all containers within the same task share the same elastic network interface (ENI) and network namespace, allowing them to communicate via localhost (

127.0.0.1

) on their respective ports, fulfilling the hardcoded configuration without external load balancers.

Step-by-Step Solution

Analyze the legacy application communication requirements.

The application expects front-end and back-end containers to communicate over localhost (

127.0.0.1

) on port

8080

Identifying the networking constraints dictates that the containers must share a network namespace.

Evaluate AWS Fargate launch type networking options.

AWS Fargate only supports the awsvpc network mode.

Understanding that other modes like host or bridge are unavailable is critical for filtering out incorrect architectural designs.

Determine the task structure that enables localhost sharing under awsvpc.

Placing both containers in the same ECS task definition allows them to share the same Elastic Network Interface (ENI) and communicate over the loopback interface.

This matches the localhost communication constraint while using Fargate's required networking model.

Key Concept

Fargate Task Networking

Question 1884Question →

A technology company has configured a centralized Active Directory Federation Services (AD FS) portal to authenticate internal engineers. The portal is integrated with multiple AWS target accounts in an AWS Organization using SAML 2.0. However, during the initial deployment, engineers receive authentication failures when attempting to log in to target AWS accounts from the AD FS landing page. Which configuration must be applied to the IAM roles in the target AWS accounts to successfully establish federation with the corporate Identity Provider (IdP)?

The IAM role trust policy in each target account must specify the ARN of the SAML identity provider as the Principal, declare the 'sts:AssumeRoleWithSAML' action, and include a condition that evaluates the 'SAML:aud' attribute to verify it matches the standard AWS SAML endpoint.

The IAM role trust policy in each target account must specify the ARN of the SAML identity provider as the Principal, declare the 'sts:AssumeRole' action, and trust the root principal of the target account as a secondary trust relationship.

The IAM role trust policy in each target account must specify the ARN of the SAML identity provider as the Principal, declare the 'sts:AssumeRoleWithWebIdentity' action, and evaluate the OpenID Connect audience attribute in the condition block.

A Service Control Policy (SCP) must be attached to the root of the AWS Organization that allows the 'sts:AssumeRole' action for the corporate identity provider, which automatically enables trust propagation across all member accounts without modifying individual role trust policies.

Show answer & explanation

Answer: The IAM role trust policy in each target account must specify the ARN of the SAML identity provider as the Principal, declare the 'sts:AssumeRoleWithSAML' action, and include a condition that evaluates the 'SAML:aud' attribute to verify it matches the standard AWS SAML endpoint.

Answer

The trust policy of the target IAM roles must specify the SAML provider ARN as the Principal, use the 'sts:AssumeRoleWithSAML' action, and evaluate the 'SAML:aud' condition attribute.

For SAML 2.0-based federation, the target IAM role's trust policy must trust the SAML provider ARN as the principal and allow the 'sts:AssumeRoleWithSAML' action. Additionally, validating the 'SAML:aud' attribute inside the condition block ensures that the SAML token was generated specifically for the AWS SAML sign-in endpoint, preventing unauthorized reuse.

Step-by-Step Solution

Identify the federation protocol in use.

The target system uses SAML 2.0 via Active Directory Federation Services (AD FS).

The federation protocol dictates which Security Token Service (STS) action and principal type must be used in the IAM trust relationship.

Determine the correct STS action for SAML 2.0 integration.

The correct action is 'sts:AssumeRoleWithSAML'.

Only the AssumeRoleWithSAML action is capable of validating and exchanging SAML assertions for temporary security credentials.

Configure the Principal and Condition sections of the role trust policy.

Set the Principal to the ARN of the SAML provider in the target account, and set the condition key 'SAML:aud' to 'https://signin.aws.amazon.com/saml'.

This establishes a cryptographic trust relationship with the SAML provider object and validates that the audience of the SAML assertion is indeed the AWS login service.

Key Concept

SAML 2.0 Federation Trust Policies

Estimated Time:1m 30s

Question 1885Question →

An international maritime shipping corporation is designing a high-availability and disaster recovery solution for its core cargo routing system on AWS. The system is deployed in a VPC in us-east-1 (primary) and must failover to a VPC in us-west-2 (secondary). The business requires a recovery time objective (RTO) of 15 minutes and a recovery point objective (RPO) of 2 minutes.

The application tier consists of Amazon EC2 instances in an Auto Scaling group in private subnets, which make outbound API calls to external customs agencies via NAT Gateways. For internal microservices communication, the corporation uses a Route 53 Private Hosted Zone (PHZ) named internal.cargo.platform to resolve service endpoints. The database tier uses Amazon Aurora PostgreSQL.

Which architecture will meet these requirements with the lowest RTO and RPO while maintaining database and network redundancy in the secondary region?

Deploy Amazon Aurora Global Database with the primary cluster in us-east-1 and a secondary cluster in us-west-2. In us-west-2, deploy the application tier using an Auto Scaling group running at a minimal scale, and provision redundant NAT Gateways across multiple Availability Zones. Associate the Route 53 Private Hosted Zone internal.cargo.platform only with the VPC in us-east-1. Configure Route 53 public Failover routing records pointing to the Application Load Balancers in both regions, associated with Application Load Balancer health checks.

Deploy Amazon Aurora Global Database with the primary cluster in us-east-1 and a secondary cluster in us-west-2. In us-west-2, deploy the application tier using an Auto Scaling group running at a minimal scale, and provision redundant NAT Gateways across multiple Availability Zones. Associate the Route 53 Private Hosted Zone internal.cargo.platform with the VPCs in both regions. Configure Route 53 public Failover routing records pointing to the Application Load Balancers in both regions, associated with Application Load Balancer health checks.

Deploy Amazon Aurora Global Database with the primary cluster in us-east-1 and a secondary cluster in us-west-2. In us-west-2, deploy the application tier using an Auto Scaling group running at a minimal scale, and provision a single NAT Gateway in one Availability Zone to optimize standby costs. Associate the Route 53 Private Hosted Zone internal.cargo.platform with the VPCs in both regions. Configure Route 53 public Failover routing records pointing to the Application Load Balancers in both regions, associated with Application Load Balancer health checks.

Configure AWS Backup to take hourly snapshots of the Aurora PostgreSQL database in us-east-1 and copy them to us-west-2. In us-west-2, deploy the application tier using an Auto Scaling group set to a minimum capacity of zero, and provision redundant NAT Gateways across multiple Availability Zones. Associate the Route 53 Private Hosted Zone internal.cargo.platform with the VPCs in both regions. Configure Route 53 public Failover routing records pointing to the Application Load Balancers in both regions, associated with Application Load Balancer health checks.

Show answer & explanation

Answer: Deploy Amazon Aurora Global Database with the primary cluster in us-east-1 and a secondary cluster in us-west-2. In us-west-2, deploy the application tier using an Auto Scaling group running at a minimal scale, and provision redundant NAT Gateways across multiple Availability Zones. Associate the Route 53 Private Hosted Zone internal.cargo.platform with the VPCs in both regions. Configure Route 53 public Failover routing records pointing to the Application Load Balancers in both regions, associated with Application Load Balancer health checks.

Answer

The correct design utilizes Amazon Aurora Global Database for sub-second cross-region replication, maintains redundant NAT Gateways in the secondary region to avoid outbound single points of failure, associates the Private Hosted Zone with both regional VPCs to ensure internal name resolution works upon failover, and implements Route 53 Failover routing for automated public ingress redirection.

The correct architecture uses Amazon Aurora Global Database to guarantee sub-second data replication across regions, satisfying the 2-minute RPO. It deploys the application tier in a warm standby configuration in us-west-2 and configures Route 53 Failover routing records to dynamically redirect public traffic when an outage is detected in us-east-1, meeting the 15-minute RTO. Redundancy is preserved by deploying NAT Gateways in multiple Availability Zones in the secondary VPC, and internal microservice names are kept resolvable by associating the Route 53 Private Hosted Zone with both regional VPCs.

Step-by-Step Solution

Select a cross-region database replication mechanism that meets the RPO and RTO bounds.

Choose Amazon Aurora Global Database, which offers sub-second cross-region replication latency and can be promoted to a primary cluster in under a minute.

This guarantees compliance with the 2-minute RPO and 15-minute RTO, whereas snapshot copy and restore mechanisms cannot.

Ensure internal DNS names remain resolvable after failover.

Associate the Route 53 Private Hosted Zone (PHZ) internal.cargo.platform with the VPCs in both us-east-1 and us-west-2.

Route 53 PHZ domain names are only resolvable within VPCs that have been explicitly associated with the hosted zone.

Design highly available outbound internet access in the secondary VPC.

Deploy NAT Gateways in multiple Availability Zones in us-west-2.

Using a single NAT Gateway introduces a single point of failure, risking complete loss of outbound carrier API connectivity in the event of an AZ outage.

Configure DNS failover for external traffic incoming to the Application Load Balancers.

Use Route 53 Failover routing policies targeting the Application Load Balancers in both regions and tie them to health checks.

This automatically redirects ingress public traffic to the secondary region if the primary region's ALB or application endpoints become degraded.

Key Concept

Designing multi-region active-passive architectures using Aurora Global Database, Route 53 Failover routing, redundant NAT Gateways, and multi-VPC Private Hosted Zone association.

Question 1886Question →

A financial technology company manages 45 member accounts in an AWS Organization. A solutions architect is designing a solution to centralize VPC Flow Logs from all VPCs in the member accounts into a single Amazon S3 bucket located in a dedicated Log Archive account. Security policy dictates that all logs must be encrypted at rest using SSE-KMS. What configuration must the solutions architect implement to allow the logs to be successfully delivered to the centralized S3 bucket?

Configure a Customer Managed Key (CMK) in the Log Archive account with a key policy that grants the AWS Log Delivery service (delivery.logs.amazonaws.com) the kms:GenerateDataKey permission. Apply an S3 bucket policy to the destination bucket that allows the Log Delivery service to perform s3:PutObject actions, restricted by the AWS Organization ID.

Enable default encryption on the destination S3 bucket using the AWS-managed KMS key (aws/s3) in the Log Archive account. Apply a bucket policy to the S3 bucket that allows the Log Delivery service (delivery.logs.amazonaws.com) to perform s3:PutObject actions.

Create an IAM role in each member account that has permissions to write to the S3 bucket and use the Customer Managed Key (CMK). Configure the VPC Flow Logs in the member accounts to assume this cross-account IAM role to deliver the logs to the central S3 bucket.

Attach a Service Control Policy (SCP) at the Organization root that explicitly allows all member accounts to write to the central S3 bucket and use the Customer Managed Key (CMK). Configure the VPC Flow Logs to publish to the central S3 bucket.

Show answer & explanation

Answer: Configure a Customer Managed Key (CMK) in the Log Archive account with a key policy that grants the AWS Log Delivery service (delivery.logs.amazonaws.com) the kms:GenerateDataKey permission. Apply an S3 bucket policy to the destination bucket that allows the Log Delivery service to perform s3:PutObject actions, restricted by the AWS Organization ID.

Answer

The correct answer correctly identifies that cross-account VPC Flow Logs delivery to Amazon S3 uses the AWS Log Delivery service (delivery.logs.amazonaws.com). Since SSE-KMS encryption is required, a Customer Managed Key (CMK) is necessary because the default AWS-managed key (aws/s3) cannot be modified to grant key access to the Log Delivery service. The bucket policy must also explicitly allow the Log Delivery service to write objects, restricted by the Organization ID.

Step-by-Step Solution

Identify the service delivering VPC Flow Logs to Amazon S3.

The AWS Log Delivery service (delivery.logs.amazonaws.com) is used for direct S3 log delivery.

Knowing which principal performs the delivery determines who needs permissions in the bucket and key policies.

Determine S3 bucket policy requirements.

The destination S3 bucket policy must allow s3:PutObject for delivery.logs.amazonaws.com, secured by aws:PrincipalOrgID.

This grants the Log Delivery service access to write the log files while preventing unauthorized external delivery.

Determine KMS encryption requirements.

Create a Customer Managed Key (CMK) and grant kms:GenerateDataKey to delivery.logs.amazonaws.com in its policy.

AWS-managed KMS keys (aws/s3) cannot be modified to grant permissions to the Log Delivery service, making a Customer Managed Key necessary.

Key Concept

Cross-account log delivery using the AWS Log Delivery service requires granting S3 bucket policy permissions and Customer Managed KMS Key (CMK) permissions to the service principal delivery.logs.amazonaws.com, since AWS-managed KMS keys cannot be shared or modified for service-specific cross-account access.

Estimated Time:2m 0s

Question 1887Question →

An enterprise is implementing a multi-account strategy using AWS Organizations. The solutions architect is setting up SAML 2.0-based federation to allow users from the corporate identity provider (IdP) to access resources in the target member accounts. Which of the following configurations are required to successfully establish this federated access? (Select TWO.)

Select all that apply

In each target AWS account, create an IAM role with a trust policy that specifies the SAML provider's ARN as the federated principal and allows the sts:AssumeRoleWithSAML action.

Configure the identity provider (IdP) to include a SAML attribute named https://aws.amazon.com/SAML/Attributes/Role that specifies the ARN of the IAM role and the ARN of the SAML provider.

Attach a Service Control Policy (SCP) at the organizational unit (OU) level that grants the sts:AssumeRoleWithSAML action to the identity provider principal.

In each target AWS account, create an IAM role with a trust policy that allows the sts:AssumeRole action and specifies the AWS Organization ID as the principal.

Configure the identity provider (IdP) to include a SAML attribute named https://aws.amazon.com/SAML/Attributes/RoleSessionName that matches the Organization ID.

Show answer & explanation

Answer: In each target AWS account, create an IAM role with a trust policy that specifies the SAML provider's ARN as the federated principal and allows the sts:AssumeRoleWithSAML action.; Configure the identity provider (IdP) to include a SAML attribute named https://aws.amazon.com/SAML/Attributes/Role that specifies the ARN of the IAM role and the ARN of the SAML provider.

Answer

To configure SAML 2.0-based federation across multiple AWS accounts, you must create an IAM role in each target account with a trust policy allowing the sts:AssumeRoleWithSAML action from the SAML provider principal. Additionally, the identity provider must send a SAML assertion containing the role and provider ARNs mapped to the https://aws.amazon.com/SAML/Attributes/Role attribute.

Establishing federated access via SAML 2.0 requires configuration on both the Identity Provider (IdP) side and the AWS side. On the AWS side, each target account must have an IAM role whose trust policy designates the SAML provider as the trusted federated principal and permits the sts:AssumeRoleWithSAML action. On the IdP side, the assertion must include the specific role attribute mapping containing both the target IAM role ARN and the SAML provider ARN.

Step-by-Step Solution

Configure the trust relationship on the target IAM role in the destination AWS account.

An IAM role is created with a trust policy pointing to the SAML provider ARN as the federated principal and allowing the sts:AssumeRoleWithSAML action.

This establishes the necessary trust relationship in the target account so AWS Security Token Service (STS) can validate and issue federated credentials.

Configure SAML assertions and attribute mappings within the corporate Identity Provider (IdP).

The IdP outputs SAML assertions containing the required attributes, specifically https://aws.amazon.com/SAML/Attributes/Role (mapping user groups to target IAM roles and providers) and https://aws.amazon.com/SAML/Attributes/RoleSessionName.

AWS Sign-In relies on these attributes to map the incoming federated user to the correct IAM role and identity provider pair.

Key Concept

Multi-Account SAML 2.0 federation requires establishing trust on the destination IAM role using sts:AssumeRoleWithSAML and passing the target role and provider ARNs in the SAML assertion.

Question 1888Question →

A company is designing a deployment pipeline for an internal microservices-based application running on Amazon ECS with AWS App Mesh. The development team wants to implement a canary deployment strategy for a critical microservice. The strategy must initially route $10\%$ of traffic to the new version and automatically roll back to the stable version if the HTTP 5xx error rate or latency exceeds predefined thresholds on the new version. The solutions architect must design a solution that minimizes management overhead and ensures immediate rollback. Which two actions should the solutions architect recommend to implement this deployment strategy? (Select two.)

Select all that apply

Define two App Mesh virtual nodes representing the stable version and the canary version, and configure a virtual route with weighted targets of

90\%

and

10\%

respectively.

Configure Amazon CloudWatch alarms to monitor the HTTP 5xx error rate and latency of the canary virtual node, and configure an AWS Lambda function to revert the virtual route weights to

100\%

for the stable virtual node if the alarms are triggered.

Configure an AWS CodeDeploy deployment group with the ECSLinear10PercentEvery10Minutes configuration and associate it with the App Mesh virtual router.

Configure the Amazon ECS service to use rolling updates, set the minimum healthy percent to

90\%

, and use Route 53 weighted routing to split traffic between the ECS tasks.

Create separate Application Load Balancers (ALBs) for the stable and canary versions, and configure Route 53 weighted routing with a

9:1

ratio to split traffic between them.

Show answer & explanation

Answer: Define two App Mesh virtual nodes representing the stable version and the canary version, and configure a virtual route with weighted targets of $90\%$ and $10\%$ respectively.; Configure Amazon CloudWatch alarms to monitor the HTTP 5xx error rate and latency of the canary virtual node, and configure an AWS Lambda function to revert the virtual route weights to $100\%$ for the stable virtual node if the alarms are triggered.

Answer

Configure two AWS App Mesh virtual nodes representing the stable and canary versions with a virtual route weight split of

90\%

and

10\%

respectively, and use Amazon CloudWatch alarms monitoring the canary node to trigger an AWS Lambda function to revert route weights to

100\%

for the stable node upon failure.

The correct strategy uses AWS App Mesh's native routing controls. By defining two virtual nodes (one for the stable version and one for the canary version) and adjusting the virtual route weights under the virtual router to

90\%

and

10\%

, traffic is precisely shifted at the application level. Monitoring the canary virtual node with CloudWatch alarms and using a Lambda function to update the virtual route weights back to

100\%

for the stable node ensures automated, low-latency rollback without client-side DNS caching delays or the overhead of multiple load balancers.

Step-by-Step Solution

Define separate virtual nodes in App Mesh for the stable and canary versions of the microservice, referencing their respective ECS task group endpoints.

This isolates traffic destinations within the mesh so that they can be controlled independently.

Before routing traffic, App Mesh needs to know the specific destinations for each version.

Update the App Mesh virtual route under the virtual router to route

90\%

of requests to the stable virtual node and

10\%

of requests to the canary virtual node.

The service mesh splits incoming traffic dynamically at the client-side proxy level, ensuring a precise

90/10

traffic distribution.

This establishes the canary testing phase as requested.

Create CloudWatch alarms based on the Envoy proxy metrics of the canary virtual node to monitor 5xx errors and latency.

The deployment environment can now detect when the new version fails to meet operational standards.

Automated rollback requires continuous monitoring of target metrics on the canary version.

Configure an AWS Lambda function triggered by the CloudWatch alarms to execute an App Mesh API call that resets the virtual route weight of the stable node to

100\%

If the canary version exhibits errors, traffic is immediately redirected back to the stable version, achieving a zero-downtime rollback.

This automates the rollback step and minimizes management overhead.

Key Concept

Canary deployment and traffic shifting using AWS App Mesh virtual routing and CloudWatch-driven rollback automation.

Estimated Time:2m 0s

Question 1889Question →

A company is modernizing a legacy, on-premises payment settlement service by migrating it to a serverless architecture on AWS. The solution must expose a private API to external financial partners connecting via AWS Direct Connect. The partners authenticate using JSON Web Tokens (JWT) issued by a third-party Identity Provider (IdP). The backend consists of AWS Lambda functions that query an Amazon Aurora PostgreSQL database cluster.

The architecture must satisfy the following requirements:
- Partners must access the API securely over the private network connection without exposing traffic to the public internet.
- The database must be protected from connection exhaustion during sudden traffic spikes.
- The application must prevent the payment settlement workload from exhausting the regional unreserved Lambda concurrency pool, which would starve other critical services in the same AWS account.

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

Select all that apply

Create a private Amazon API Gateway REST API associated with interface VPC endpoints. Configure an API Gateway Lambda authorizer to validate the JWT tokens from the external Identity Provider.

Deploy an Amazon RDS Proxy between the Lambda functions and the Aurora PostgreSQL database cluster. Configure a reserved concurrency limit on the Lambda functions.

Create a regional Amazon API Gateway REST API and configure a custom domain name. Integrate it with the Lambda functions configured with unlimited unreserved concurrency to handle sudden partner traffic spikes without throttling.

Modify the default AWS-managed KMS key (aws/apigateway) key policy to delegate decrypt permissions to the partner AWS accounts to allow secure payload decryption.

Deploy the Lambda functions in a single private subnet and route all database-bound traffic through a single NAT Gateway in a public subnet to ensure static IP routing to the database.

Show answer & explanation

Answer: Create a private Amazon API Gateway REST API associated with interface VPC endpoints. Configure an API Gateway Lambda authorizer to validate the JWT tokens from the external Identity Provider.; Deploy an Amazon RDS Proxy between the Lambda functions and the Aurora PostgreSQL database cluster. Configure a reserved concurrency limit on the Lambda functions.

Answer

The correct architecture uses a private Amazon API Gateway REST API associated with interface VPC endpoints to secure traffic over AWS Direct Connect, combined with an API Gateway Lambda authorizer to validate JWT tokens. Downstream, an Amazon RDS Proxy pools database connections to protect Aurora PostgreSQL, and setting a reserved concurrency limit on the Lambda functions protects the account's regional concurrency pool.

The correct solution uses a private API Gateway REST API with interface VPC endpoints to satisfy the private network access requirement, combined with a custom Lambda authorizer to validate JWTs. To prevent database connection exhaustion during high-volume spikes, Amazon RDS Proxy manages connection pooling. A reserved concurrency limit on the Lambda function prevents it from consuming the entire account's regional concurrency pool, satisfying the concurrency protection requirement.

Step-by-Step Solution

Expose the private API securely over AWS Direct Connect.

Create a private Amazon API Gateway REST API and associate it with interface VPC endpoints (AWS PrivateLink) inside the VPC connected to Direct Connect.

This ensures partners can access the API endpoint over the private connection without exposing endpoints to the public internet.

Implement authentication using external JWTs.

Deploy an API Gateway Lambda authorizer to extract and validate the JWT tokens issued by the external Identity Provider.

API Gateway REST APIs require a Lambda authorizer to process and validate custom OAuth/JWT tokens from external, non-Cognito IdPs.

Protect the Aurora PostgreSQL database from connection exhaustion.

Deploy an Amazon RDS Proxy between the Lambda functions and the Aurora PostgreSQL database cluster.

RDS Proxy pools database connections and mitigates connection limits being exceeded during Lambda scaling spikes.

Prevent regional Lambda concurrency starvation.

Configure a reserved concurrency limit on the payment settlement Lambda functions.

This caps the maximum concurrency the functions can consume, ensuring that a surge in partner requests does not exhaust the account's unreserved concurrency pool.

Key Concept

Serverless modernization pattern using private API Gateway, custom Lambda authorizers, database connection pooling with RDS Proxy, and concurrency management safeguards.

Estimated Time:3m 0s

Question 1890Question →

A financial services company is designing a new multi-region web portal that spans two AWS accounts (Account A in us-east-1 and Account B in us-west-2). The workload type is an OLTP database for user sessions and Object storage for secure audit logs. The system must support active-passive disaster recovery with a recovery time objective (RTO) of less than $1\text{ minute}$ and a recovery point objective (RPO) of less than $1\text{ second}$ . Audit logs generated in Account A must be stored in Amazon S3 in Account A and instantly replicated to a centralized auditing bucket in Account B. Read scaling must be supported on the database in the primary region to handle sudden traffic spikes without affecting write throughput. Which two database and storage designs should a Solutions Architect implement to meet these requirements? (Select TWO.)

Select all that apply

Deploy Amazon Aurora PostgreSQL in us-east-1 with Aurora Replicas, and configure Aurora Auto Scaling to dynamically adjust reader replicas based on metric thresholds.

Configure Amazon S3 cross-account replication from Account A to Account B, using a customer managed key (CMK) in AWS KMS to encrypt the objects, and allow the replication role access to the CMK in Account A and the target bucket policy in Account B.

Deploy Amazon RDS for PostgreSQL in us-east-1 with a Multi-AZ standby deployment, and configure the client application to balance read queries across the standby node to handle peak traffic.

Implement AWS Backup with cross-region backup copy enabled from us-east-1 to us-west-2, scheduling backup copies every

24\text{ hours}

to support disaster recovery.

Configure Amazon S3 cross-account replication using the default AWS managed key (aws/s3) in Account A to encrypt the objects, and allow the Account B IAM role to access this key by updating the bucket policy in Account B.

Show answer & explanation

Answer: Deploy Amazon Aurora PostgreSQL in us-east-1 with Aurora Replicas, and configure Aurora Auto Scaling to dynamically adjust reader replicas based on metric thresholds.; Configure Amazon S3 cross-account replication from Account A to Account B, using a customer managed key (CMK) in AWS KMS to encrypt the objects, and allow the replication role access to the CMK in Account A and the target bucket policy in Account B.

Answer

Deploy Amazon Aurora PostgreSQL in us-east-1 with Aurora Replicas and configure Aurora Auto Scaling, while configuring Amazon S3 cross-account replication from Account A to Account B using a Customer Managed Key (CMK) in AWS KMS.

Deploying Amazon Aurora PostgreSQL with reader scaling satisfies the requirement to handle read spikes independently from write throughput. Additionally, setting up S3 cross-account replication with a Customer Managed Key (CMK) enables secure replication across different accounts by allowing customization of the key policy for external account access.

Step-by-Step Solution

Evaluate the database read scaling requirements in the primary region.

Identify that standard RDS Multi-AZ standby deployments do not support read queries, whereas Amazon Aurora PostgreSQL supports multiple active Aurora Replicas that scale horizontally.

Ensures read spikes are handled efficiently without degrading write throughput.

Evaluate the recovery point objective (RPO) for the disaster recovery strategy.

Determine that a daily backup copy strategy provides an RPO of

24\text{ hours}

, which is insufficient for the sub-second RPO requirement.

Filters out backup-restore methods in favor of live replication.

Analyze cross-account S3 replication encryption requirements.

Determine that AWS-managed KMS keys cannot be shared cross-account, meaning a customer managed key (CMK) with appropriate key policy delegation is required.

Allows S3 replication to successfully decrypt and replicate objects to the destination bucket in another account.

Key Concept

Selecting appropriate database and storage patterns to meet scalability, cross-account security, and RTO/RPO objectives.

Question 1891Question →

A solutions architect is implementing region-restriction Service Control Policies (SCPs) across an organization in AWS Organizations. The architect needs to ensure that the restrictions do not disrupt existing applications or logging workflows, and that they are applied safely.

Arrange the steps in the correct order to design, test, and safely deploy the SCPs.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins with creating the SCP in the management account, followed by attaching it to a test OU. Next, validation testing is performed within the test OU, after which the policy is applied to the production OUs. Finally, centralized CloudTrail logs are monitored to verify enforcement and detect unexpected access denials.

The correct order ensures that policies are authored centrally, tested in an isolated non-production environment first, verified before being promoted to production accounts, and monitored via centralized logs to catch any unforeseen impacts.

Step-by-Step Solution

Create the SCP in the AWS Organizations management account.

The SCP is stored in the management account and is ready to be attached.

SCPs must be authored centrally in the Organizations management account.

Attach the SCP to a testing OU.

The policy takes effect only on the accounts residing in the testing OU.

Applying guardrails to a test OU prevents accidental outages in production during the testing phase.

Perform validation testing.

Verify that resource creation succeeds in permitted regions and fails in restricted regions.

Active testing verifies that policy logic works as intended and does not block critical infrastructure operations.

Attach the SCP to the production OUs.

The policy is enforced across all production accounts under those OUs.

Once the SCP is proven safe, it is applied to the production environment to meet governance requirements.

Monitor centralized CloudTrail logs.

Analyze blocked API actions to detect misconfigured services or applications.

Continuous auditing helps identify production applications that may require modifications or exemptions.

Key Concept

Phased implementation and validation of Service Control Policies in a multi-account structure

Question 1892Question →

A company is planning to migrate 40 on-premises VMware virtual machines (VMs) to native Amazon EC2 instances in a target VPC using AWS Application Migration Service (MGN). The migration must be completed over a private network connection using an existing AWS Direct Connect connection. The corporate security policy strictly prohibits replication traffic and agent communications from traversing the public internet. The on-premises network is connected to the target VPC via an AWS Transit Gateway. Which of the following configuration strategies should the Solutions Architect implement to meet these requirements?

Create VPC interface endpoints in the replication staging area VPC for the MGN and EC2 services. Create a Route 53 Private Hosted Zone (PHZ) for these service endpoints and associate it with the staging area VPC and the target VPC. Configure the MGN replication template to use private IP addresses for data routing. Ensure the on-premises firewall and the staging area security groups allow outbound and inbound TCP port 1500 traffic, respectively.

Create VPC interface endpoints in the shared services VPC for the MGN and EC2 services. Create a Route 53 Private Hosted Zone for the endpoints but associate it only with the shared services VPC. Set up an inbound Route 53 Resolver endpoint in the shared services VPC and configure on-premises DNS forwarders. Leave the MGN replication template settings at their default values to allow the agent to automatically locate the nearest replication server.

Create VPC interface endpoints in the replication staging area VPC for the MGN and EC2 services. Associate the Route 53 Private Hosted Zone for these endpoints with the staging area VPC. In the MGN replication template, enable the option to use private IP addresses for data routing. Configure the on-premises firewall and the staging VPC security groups to allow only TCP port 443 traffic, while blocking all other ports to maintain a hardened security posture.

Configure a Direct Connect Public Virtual Interface (VIF) to route replication traffic directly to the public AWS MGN service endpoints. Configure the MGN replication template to use public IP addresses. Set up a static route in the AWS Transit Gateway route tables that directs all traffic destined for the public MGN API endpoints to the Transit Gateway's default route, bypassing the staging VPC.

Show answer & explanation

Answer: Create VPC interface endpoints in the replication staging area VPC for the MGN and EC2 services. Create a Route 53 Private Hosted Zone (PHZ) for these service endpoints and associate it with the staging area VPC and the target VPC. Configure the MGN replication template to use private IP addresses for data routing. Ensure the on-premises firewall and the staging area security groups allow outbound and inbound TCP port 1500 traffic, respectively.

Answer

Create VPC interface endpoints in the replication staging area VPC for the MGN and EC2 services, associate the Private Hosted Zone with both the staging area and target VPCs, configure the replication template to use private IP addresses for data routing, and allow TCP port 1500 traffic on the firewalls and security groups.

The correct strategy establishes private endpoints (AWS PrivateLink) in the replication staging area VPC for the AWS MGN and Amazon EC2 services. It associates the Route 53 Private Hosted Zone (PHZ) with the staging and target VPCs to resolve service API calls to private IP addresses. Setting the MGN replication template to use private IP addresses ensures that data replication traffic flows over the private Direct Connect path. Finally, opening TCP port 1500 is critical as it is the port used by the MGN Replication Agent to replicate block-level data to the staging area replication servers.

Step-by-Step Solution

Configure VPC interface endpoints for MGN and EC2 inside the replication staging area VPC.

Enables private DNS hostnames and endpoints for control plane actions within the VPC.

Allows the on-premises replication agents to communicate with MGN and EC2 APIs privately over Direct Connect.

Create and associate a Route 53 Private Hosted Zone (PHZ) for the service endpoints with the staging area and target VPCs, and set up on-premises DNS forwarding.

Enables on-premises systems and resources in both VPCs to resolve the MGN service DNS queries to the private IP addresses of the VPC interface endpoints.

Ensures that DNS traffic does not route to public IP addresses.

Modify the AWS MGN replication template to enable private IP routing.

Instructs the Replication Agent to push data replication blocks directly to the private IPs of the replication servers in the staging area.

Forces the replication data path to go over the private Direct Connect link rather than public internet endpoints.

Open TCP port 1500 on the on-premises firewall (outbound) and the replication staging VPC security group (inbound).

Allows block-level data transfer between the on-premises agent and the replication servers.

Replication data transfer in AWS MGN occurs over TCP port 1500; blocking it halts replication.

Key Concept

Private connectivity and DNS resolution for AWS Application Migration Service (MGN) replication over Direct Connect

Question 1893Question →

An enterprise is migrating its on-premises data center workloads to AWS and needs to transfer two primary datasets within a strict 14-day migration window. The enterprise has a dedicated $500\text{ Mbps}$ AWS Direct Connect connection. The datasets consist of:

* $850\text{ TB}$ of active user documents stored on an on-premises SMB file share, which must be migrated to Amazon FSx for Windows File Server.
* $250\text{ TB}$ of media files stored on an on-premises NFS export, which must be migrated to Amazon S3.

The security policy mandates that all migrated data must be encrypted at rest using an AWS Key Management Service (AWS KMS) customer managed key that is owned and managed by a centralized security account. Additionally, an existing on-premises SFTP server used by external partners to access the media files must be replaced with a fully managed service on AWS, preserving existing credentials and hostnames.

Which combination of actions will meet these requirements within the migration window? (Select TWO.)

Select all that apply

Order multiple AWS Snowball Edge Storage Optimized devices. Copy both the SMB and NFS datasets onto the devices. Configure the Snowball job to encrypt the imported data in Amazon S3 using a customer managed KMS key created in the security account.

Create an AWS DataSync task without an agent to copy the migrated SMB data from the target Amazon S3 bucket to the Amazon FSx for Windows File Server file system. Configure an AWS Transfer for SFTP endpoint backed by AWS Secrets Manager to authenticate external partners using their existing credentials.

Use AWS DataSync to copy both the SMB and NFS datasets directly from on-premises to Amazon FSx and Amazon S3 over the

500\text{ Mbps}

AWS Direct Connect link. Configure the task to run continuously with high bandwidth limits.

Order multiple AWS Snowball Edge Storage Optimized devices. Copy the SMB and NFS datasets to the devices, and configure the import process to encrypt the target S3 buckets using the default AWS-managed KMS key (aws/s3) to enable automatic cross-account decryption by the security account.

Set up an AWS Transit Gateway routed through the Direct Connect gateway to configure transitive VPC-to-VPC routing. Deploy on-premises AWS DataSync agents to stream both datasets over the Transit Gateway directly to AWS to meet the 14-day migration window.

Show answer & explanation

Answer: Order multiple AWS Snowball Edge Storage Optimized devices. Copy both the SMB and NFS datasets onto the devices. Configure the Snowball job to encrypt the imported data in Amazon S3 using a customer managed KMS key created in the security account.; Create an AWS DataSync task without an agent to copy the migrated SMB data from the target Amazon S3 bucket to the Amazon FSx for Windows File Server file system. Configure an AWS Transfer for SFTP endpoint backed by AWS Secrets Manager to authenticate external partners using their existing credentials.

Answer

Ordering multiple AWS Snowball Edge Storage Optimized devices to import the data to Amazon S3 using a customer managed KMS key, and creating an AWS DataSync task to copy the SMB data from Amazon S3 to Amazon FSx for Windows File Server while setting up AWS Transfer for SFTP backed by AWS Secrets Manager.

The correct strategy combines offline physical transfer via AWS Snowball Edge to overcome network limits, combined with post-migration in-cloud copying. Using Snowball Edge to seed Amazon S3 meets the time constraint. A customer managed KMS key satisfies the cross-account encryption requirement. Because Snowball Edge cannot write directly to Amazon FSx, AWS DataSync is run inside AWS to copy data from S3 to FSx for Windows. AWS Transfer for SFTP with Secrets Manager provides a managed replacement that preserves existing partner credentials.

Step-by-Step Solution

Calculate the data transfer volume and timeline constraint.

Total data size =

850\text{ TB} + 250\text{ TB} = 1100\text{ TB}

. Direct Connect bandwidth =

500\text{ Mbps}

. Online transfer would require:

\text{Time} = \frac{1100 \times 10^{12} \times 8}{500 \times 10^6 \times 86400} \approx 203.7\text{ days}

. Therefore, offline transfer using AWS Snowball Edge devices is required.

To determine whether online or offline transfer is feasible within the 14-day window.

Select the appropriate encryption key type for cross-account compliance.

Identify that a customer managed KMS key must be used instead of an AWS-managed key (aws/s3), since the latter's key policies cannot be altered to grant cross-account permissions to the security account.

To satisfy security requirements allowing cross-account decryption.

Map Snowball Edge imports to the final target storage.

Data is imported from the Snowball Edge devices into Amazon S3. For the SMB data, an AWS DataSync task is configured within the AWS Cloud to replicate files from the source S3 bucket to the destination FSx for Windows File Server file system. No DataSync agent is needed for in-cloud transfers.

Because Snowball Edge cannot directly seed data into Amazon FSx for Windows File Server.

Configure the managed SFTP migration strategy.

Provision AWS Transfer for SFTP and integrate it with AWS Secrets Manager as a custom identity provider to handle external partner authentication without credentials modification.

To replace the on-premises SFTP server while preserving existing partner client configurations.

Key Concept

Selecting the optimal data transfer method based on bandwidth, time, storage protocols, and AWS KMS cross-account access capabilities.

Question 1894Question →

A company is deploying a new version of a critical web application that runs on Amazon ECS with the AWS Fargate launch type. The application is behind an Application Load Balancer (ALB). The application handles multi-step transactions and maintains state using session affinity (sticky sessions) stored in the local memory of the containers. The transaction workflow can take up to 20 minutes to complete. The deployment strategy for the new version must meet the following requirements:

* Shift traffic gradually to the new version to minimize the blast radius of potential issues.
* Ensure that users with active sessions are not routed to the new version mid-transaction, which would break their session state.
* Automatically roll back the deployment if the HTTP 5XX error rate or the target response time of the new version exceeds defined thresholds.

Which combination of actions will meet these requirements? (Select TWO.)

Select all that apply

Configure AWS CodeDeploy with a canary deployment configuration (such as CodeDeployDefault.ECSCanary10Percent5Minutes) to route traffic to the green target group, and specify CloudWatch alarms based on the ALB HTTPCode_Target_5XX_Count and TargetResponseTime metrics as rollback triggers in the deployment group.

Enable target group stickiness on the ALB listener rule that routes traffic to the blue and green target groups, and set the stickiness duration to 25 minutes.

Configure the ECS service deployment controller to use ECS rolling updates (ECS), set the minimum healthy percent to 100%, enable ECS deployment circuit breakers with rollback, and use target group stickiness on the ALB.

Configure AWS CodeDeploy with the CodeDeployDefault.ECSAllAtOnce deployment configuration, enable target-level stickiness on both the blue and green target groups, and configure a CloudWatch alarm on the ALB ActiveConnectionCount metric to trigger rollback.

Create a secondary Application Load Balancer for the new ECS service version, configure Amazon Route 53 with weighted routing to split traffic between the two load balancers, and enable Route 53 target health evaluation for automated rollback.

Show answer & explanation

Answer: Configure AWS CodeDeploy with a canary deployment configuration (such as CodeDeployDefault.ECSCanary10Percent5Minutes) to route traffic to the green target group, and specify CloudWatch alarms based on the ALB HTTPCode_Target_5XX_Count and TargetResponseTime metrics as rollback triggers in the deployment group.; Enable target group stickiness on the ALB listener rule that routes traffic to the blue and green target groups, and set the stickiness duration to 25 minutes.

Answer

Configure AWS CodeDeploy with a canary deployment configuration and specify CloudWatch alarms for HTTP 5XX count and target response times as rollback triggers, and enable target group stickiness on the ALB listener rule with a duration of 25 minutes.

The correct solution involves combining AWS CodeDeploy canary deployments with ALB target group stickiness. Configuring CodeDeploy with a canary deployment configuration and specifying CloudWatch alarms for target 5XX counts and response times ensures gradual traffic shifting and automated rollbacks based on application performance. Enabling target group stickiness on the ALB listener rule ensures that users with active sessions are not shifted between the blue and green target groups mid-transaction, preserving local container-based session state.

Step-by-Step Solution

Set up weighted routing and session persistence at the load balancer layer.

By enabling target group stickiness on the ALB listener rule, the load balancer generates a cookie that binds client sessions to either the blue or green target group.

This ensures that once a client session begins on a specific target group (and thus is directed to a specific container version), the user remains bound to that target group for the duration of the multi-step transaction (25 minutes), preventing session state loss even as routing weights change.

Configure the deployment controller and traffic shifting behavior.

AWS CodeDeploy uses an ECS deployment group with a canary traffic-shifting configuration (e.g., CodeDeployDefault.ECSCanary10Percent5Minutes) to gradually shift traffic from the blue target group to the green target group.

This satisfies the requirement to shift traffic gradually, minimizing the blast radius by only routing a small percentage of new sessions to the new version initially.

Configure automated rollback triggers based on application health.

Associate CloudWatch alarms monitoring ALB metrics (HTTPCode_Target_5XX_Count and TargetResponseTime) on the new target group with the CodeDeploy deployment group.

This allows CodeDeploy to automatically detect increased latency or error rates on the new version and trigger an immediate rollback to the original version without human intervention.

Key Concept

AWS CodeDeploy Blue/Green deployment for Amazon ECS with Application Load Balancer target group stickiness.

Question 1895Question →

An automated inventory fulfillment platform is designing a disaster recovery strategy for its core supply chain database and API on AWS. The application currently runs in a primary AWS Region with an Amazon Aurora PostgreSQL DB cluster and Amazon EC2 instances inside private subnets using NAT Gateways. The disaster recovery strategy must achieve a Recovery Time Objective (RTO) of $15$ minutes and a Recovery Point Objective (RPO) of $2$ minutes. The architecture must minimize ongoing running costs while ensuring that the infrastructure in the secondary Region can be scaled up rapidly during a failover event.

Which two configuration steps should the solutions architect implement to meet these requirements? (Select TWO.)

Select all that apply

Configure AWS Backup to replicate database snapshots to the secondary Region every

2

hours, and restore the cluster from the latest snapshot during a failover event.

Deploy an Amazon Aurora Global Database with the primary cluster in the active Region and a secondary cluster in the recovery Region to support sub-second data replication.

Configure Route 53 active-passive failover routing pointing to the active Region Application Load Balancer (ALB) as primary and the recovery Region ALB as secondary, associated with an active health check.

Set up Route 53 Latency-based routing to both Regions without active health checks, allowing client traffic to route to the lowest-latency Region automatically.

Provision a single NAT Gateway in the recovery Region's public subnet and configure the route tables of all private subnets across multiple Availability Zones to route outbound internet traffic through it.

Configure Amazon Aurora Auto Scaling in the recovery Region to scale up the instance size of the primary writer instance when CPU utilization exceeds

70\%

Show answer & explanation

Answer: Deploy an Amazon Aurora Global Database with the primary cluster in the active Region and a secondary cluster in the recovery Region to support sub-second data replication.; Configure Route 53 active-passive failover routing pointing to the active Region Application Load Balancer (ALB) as primary and the recovery Region ALB as secondary, associated with an active health check.

Answer

Implementing an Amazon Aurora Global Database with a secondary cluster in the recovery Region, and configuring Route 53 active-passive failover routing pointing to the active and recovery Region Application Load Balancers with an active health check.

To meet the recovery goals of an RTO of

15

minutes and RPO of

2

minutes, the database must replicate with low latency and the routing layer must automatically shift user traffic. Deploying an Amazon Aurora Global Database offers sub-second replication to the secondary Region and can be promoted to a writer within minutes during a failover. Configuring Route 53 active-passive failover routing with health checks ensures that traffic automatically shifts away from the unhealthy primary Region to the secondary Region within the RTO envelope.

Step-by-Step Solution

Evaluate the database replication strategy to meet the

2

-minute RPO.

Implement Amazon Aurora Global Database.

Aurora Global Database uses fast physical replication with latency typically under

1

second, which easily meets the

2

-minute RPO.

Choose the routing policy to automate failover within the

15

-minute RTO.

Configure Route 53 Active-Passive failover routing with health checks.

Route 53 can automatically route traffic to the secondary Region ALB when the primary Region's endpoint fails the health check.

Verify supporting network and database scaling configurations for high availability.

Identify invalid or non-HA options such as single NAT gateways or invalid dynamic writer scaling configurations.

Ensuring outbound connectivity redundancy and avoiding unsupported operations (like dynamically scaling a writer instance size with Aurora Auto Scaling) prevents single points of failure and operational failures.

Key Concept

Disaster Recovery strategies for multi-region workloads require choosing appropriate database replication methods and automated DNS failover mechanisms that align with targeted RTO and RPO limits.

Question 1896Question →

A financial compliance platform must deploy a transaction auditing application across two AWS Regions: `eu-west-1` (Primary) and `us-east-1` (Secondary). The application tier runs on Amazon EC2 instances in private subnets across three Availability Zones (AZs) in each Region. The architecture must satisfy a Recovery Time Objective ( $RTO$ ) of less than 5 minutes for a regional disaster recovery failover. The Recovery Point Objective ( $RPO$ ) requires zero data loss ( $RPO = 0$ ) within the primary Region during an AZ failure, and less than 10 seconds ( $RPO < 10\text{ seconds}$ ) for a regional failover. Outbound internet connectivity to external payment validation APIs must remain operational in each Region even if an entire Availability Zone or its NAT Gateway experiences an outage. Additionally, private internal DNS names must resolve correctly across VPCs in both Regions. Which architecture meets these requirements while minimizing recovery time and administrative complexity?

Deploy Amazon Aurora PostgreSQL Multi-AZ in eu-west-1 as the primary cluster of an Aurora Global Database, with a secondary cluster in us-east-1. Configure one NAT Gateway in each Availability Zone in both regions, and configure private subnet route tables to direct outbound traffic to the local NAT Gateway. Associate the Route 53 Private Hosted Zone directly with the VPCs in both regions. Use Route 53 Application Recovery Controller (ARC) routing controls and routing control health checks to manage regional failover routing.

Deploy Amazon RDS PostgreSQL Multi-AZ in eu-west-1, and direct read-heavy reporting queries to the standby replica in the second Availability Zone to optimize database performance. Set up an RDS cross-region read replica in us-east-1 for disaster recovery. Deploy a single NAT Gateway in eu-west-1 and a single NAT Gateway in us-east-1 within a single public subnet to centralize outbound internet egress. Associate the Route 53 Private Hosted Zone with the VPC in eu-west-1, and configure Route 53 Resolver endpoints to route DNS queries from us-east-1. Use Route 53 Failover routing policies pointing to the Application Load Balancer health checks for public DNS failover.

Deploy Amazon Aurora PostgreSQL Multi-AZ in eu-west-1. Configure hourly AWS Backup copy jobs to copy database snapshots to us-east-1 to serve as the recovery source. Deploy NAT Gateways in each Availability Zone in both regions. Associate the Route 53 Private Hosted Zone with the VPCs in both regions. Use Route 53 Active-Passive failover routing based on CloudWatch alarms monitoring regional application availability to failover traffic to us-east-1.

Deploy Amazon Aurora PostgreSQL Multi-AZ in eu-west-1 as the primary cluster of an Aurora Global Database, with a secondary cluster in us-east-1. Configure a NAT Gateway in each Availability Zone in both regions. Associate the Route 53 Private Hosted Zone with the primary VPC in eu-west-1 only, and configure a VPC peering connection between the primary and secondary VPCs to allow DNS query forwarding. Use Route 53 Geolocation routing policies to route all traffic to the primary region unless the primary region becomes completely unavailable.

Show answer & explanation

Answer: Deploy Amazon Aurora PostgreSQL Multi-AZ in eu-west-1 as the primary cluster of an Aurora Global Database, with a secondary cluster in us-east-1. Configure one NAT Gateway in each Availability Zone in both regions, and configure private subnet route tables to direct outbound traffic to the local NAT Gateway. Associate the Route 53 Private Hosted Zone directly with the VPCs in both regions. Use Route 53 Application Recovery Controller (ARC) routing controls and routing control health checks to manage regional failover routing.

Answer

Deploy Amazon Aurora PostgreSQL Multi-AZ in the primary region as part of an Aurora Global Database, use Route 53 Application Recovery Controller (ARC) for DNS failover, configure NAT Gateways in each Availability Zone, and associate the Private Hosted Zone directly with VPCs in both regions.

The correct architecture uses Amazon Aurora Global Database to achieve low-latency asynchronous cross-region replication, meeting the sub-10 second RPO requirement. Within the primary region, Multi-AZ deployment provides synchronous replication, ensuring an RPO of 0 for local AZ failures. Route 53 Application Recovery Controller (ARC) routing controls allow rapid, manual or automated failover of DNS records without relying on client-side cache TTLs, satisfying the 5-minute RTO. Having one NAT Gateway per Availability Zone ensures that an AZ failure does not disrupt outbound internet traffic from other AZs. Finally, associating the Private Hosted Zone directly with VPCs in both regions is the standard, highly resilient way to support cross-VPC private DNS resolution without external resolver endpoints.

Step-by-Step Solution

Select the database replication model.

Amazon Aurora Global Database with Multi-AZ in the primary region.

Ensures synchronous replication locally (RPO = 0) and low-latency asynchronous replication (< 1 second) across regions, meeting the RPO < 10 seconds requirement.

Configure NAT Gateway architecture for outbound internet resilience.

Deploy one NAT Gateway per Availability Zone in each VPC.

Prevents outbound internet access failures across the entire VPC if a single Availability Zone containing a NAT Gateway experiences an outage.

Set up private DNS resolution for internal microservices.

Associate the Route 53 Private Hosted Zone directly with the VPCs in both regions.

Allows native, highly available resolution of private domain names across regions without introducing routing or endpoint dependencies.

Implement the regional failover routing mechanism.

Configure Route 53 Application Recovery Controller (ARC) routing controls.

Enables rapid routing shifts during failover within seconds by using highly available health check states, avoiding standard DNS TTL cache propagation delays.

Key Concept

Multi-region disaster recovery design using Aurora Global Database, Route 53 Application Recovery Controller, NAT Gateway redundancy, and cross-region Private Hosted Zone association.

Question 1897Question →

A global logistics firm needs to migrate 120 virtual machines (VMs) from an on-premises VMware vSphere 7.0 environment to a newly provisioned VMware Cloud on AWS (VMC) Software-Defined Data Center (SDDC). The workload consists of 80 stateless web/application servers that must remain online during migration with zero service disruption, and 40 stateful database and backend processing servers that can tolerate a maximum downtime of 10 minutes during a scheduled maintenance window. The on-premises data center is connected to AWS via a 10 Gbps AWS Direct Connect connection. The company has a multi-account AWS architecture where several spoke VPCs are connected via a customer-managed AWS Transit Gateway (TGW) in a central network account. The VMC SDDC is connected via a VMware Transit Connect gateway. The solution must ensure that resources in the spoke VPCs can access the migrated VMs using private DNS names, and that the migration is completed within the downtime constraints. Which two actions should the solutions architect recommend to meet these requirements?

Select all that apply

Configure VMware HCX Replication Assisted vMotion (RAV) to migrate the stateless web and application servers concurrently without downtime, and use HCX Bulk Migration for the stateful database and backend servers to replicate data in the background and execute a scheduled switchover during the maintenance window.

Peer the customer-managed AWS Transit Gateway with the VMware Transit Connect gateway, configure routing propagation between them, and associate the Route 53 Private Hosted Zone containing the SDDC resource records with all the spoke VPCs.

Use HCX Cold Migration for the stateful database and backend servers to guarantee data consistency, and use standard HCX vMotion sequentially for the web and application servers to achieve zero downtime.

Configure the VMC SDDC connectivity by attaching the VMware Transit Connect gateway directly to a Direct Connect Gateway, and configure transitive routing rules on the Direct Connect Gateway to enable communication between the spoke VPCs and the SDDC VMs.

Associate the Route 53 Private Hosted Zone directly with the VMware Transit Connect gateway to enable global resolution, and configure the spoke VPCs to use the on-premises DNS servers as forwarders via the Direct Connect connection.

Show answer & explanation

Answer: Configure VMware HCX Replication Assisted vMotion (RAV) to migrate the stateless web and application servers concurrently without downtime, and use HCX Bulk Migration for the stateful database and backend servers to replicate data in the background and execute a scheduled switchover during the maintenance window.; Peer the customer-managed AWS Transit Gateway with the VMware Transit Connect gateway, configure routing propagation between them, and associate the Route 53 Private Hosted Zone containing the SDDC resource records with all the spoke VPCs.

Answer

To meet the requirements, the solutions architect should use VMware HCX Replication Assisted vMotion (RAV) for the web/application servers, use HCX Bulk Migration for the database servers, peer the customer-managed AWS Transit Gateway with the VMware Transit Connect gateway, and associate the Route 53 Private Hosted Zone with the spoke VPCs.

Using VMware HCX Replication Assisted vMotion (RAV) ensures zero downtime for the concurrent migration of the 80 web/application VMs. Using HCX Bulk Migration for the database VMs allows the bulk replication of data with a controlled switchover within the 10-minute window. Peering the customer-managed AWS Transit Gateway with the VMware Transit Connect gateway provides the necessary network path between the spoke VPCs and the SDDC VMs. Associating the Private Hosted Zone with the spoke VPCs enables seamless DNS resolution of the VMC SDDC resources.

Step-by-Step Solution

Analyze the migration downtime limits and concurrency requirements for the VMs.

The 80 web/application VMs require zero downtime and concurrent migration. The 40 database/backend VMs can tolerate a 10-minute maintenance window.

This establishes the criteria for selecting the appropriate VMware HCX migration method.

Evaluate HCX migration options against the requirements.

HCX RAV is selected for zero-downtime concurrent migration. HCX Bulk Migration is selected for database VMs because it replicates data in the background and allows switchover to be scheduled during the 10-minute window.

HCX RAV prevents downtime for web servers, while HCX Bulk Migration minimizes database cutover downtime.

Determine the network routing architecture between the VMC SDDC and the spoke VPCs.

Establish a transit gateway peering connection between the customer-managed AWS Transit Gateway and the VMware Transit Connect gateway.

Standard Direct Connect Gateway routing does not support transitive VPC-to-VMC routing, so peering the transit gateways is necessary.

Configure DNS resolution for the migrated VMC SDDC resources.

Associate the Route 53 Private Hosted Zone containing the VMC SDDC DNS records with all spoke VPCs.

Private Hosted Zones must be associated with VPCs to allow resources within those VPCs to resolve the DNS records.

Key Concept

VMware Cloud on AWS migration methods (HCX RAV vs Bulk Migration) and hybrid network routing using Transit Gateway peering and Route 53 DNS resolution.

Estimated Time:3m 0s

Question 1898Question →

A company is designing a deployment pipeline for a new microservice running on AWS Lambda behind an Amazon API Gateway. The business requires a deployment strategy that minimizes blast radius by routing a small portion of traffic to the new version initially. The traffic allocation must steadily increase in equal increments of $10\%$ every $3$ minutes until the new version receives all traffic. If any CloudWatch alarms are triggered during the deployment, AWS CodeDeploy must automatically roll back the changes. Which CodeDeploy deployment configuration should the solutions architect select to meet these requirements?

CodeDeployDefault.LambdaLinear10PercentEvery3Minutes

CodeDeployDefault.LambdaCanary10Percent30Minutes

CodeDeployDefault.LambdaLinear10PercentEvery10Minutes

CodeDeployDefault.LambdaCanary10Percent5Minutes

Show answer & explanation

Answer: CodeDeployDefault.LambdaLinear10PercentEvery3Minutes

Answer

CodeDeployDefault.LambdaLinear10PercentEvery3Minutes

The correct configuration is CodeDeployDefault.LambdaLinear10PercentEvery3Minutes because it shifts traffic to the new Lambda function version in equal increments of

10\%

every

3

minutes until the transition is complete. Combining this configuration with CloudWatch alarms associated with the CodeDeploy deployment group enables automated, rapid rollbacks if any issues are detected.

Step-by-Step Solution

Analyze the traffic routing pattern requirement

The requirement specifies a steady, incremental increase of

10\%

every

3

minutes, which points to a linear traffic shifting strategy rather than a canary strategy.

Linear strategies shift traffic in equal increments at regular intervals, while canary strategies shift a fixed percentage for a duration before shifting the rest all at once.

Identify the predefined CodeDeploy configurations for AWS Lambda linear shifting

The predefined linear configuration that matches the

10\%

increment and

3

-minute interval is CodeDeployDefault.LambdaLinear10PercentEvery3Minutes.

This configuration matches the required traffic increment (

10\%

) and time interval (

3

minutes) exactly.

Configure the automated rollback triggers

Associate the CloudWatch alarms with the deployment group in CodeDeploy.

CodeDeploy monitors these alarms during the deployment process and automatically rolls back if any alarm is triggered.

Key Concept

AWS CodeDeploy deployment configurations for AWS Lambda define how traffic is shifted from the old version of a Lambda function to the new version. Linear configurations shift traffic in equal increments at regular intervals, whereas canary configurations shift a small percentage first and the remainder after a set duration.

Question 1899Question →

A national education board is hosting an online portal for high school exam results. The portal experiences virtually no traffic throughout the year, but when results are released, it experiences an immediate influx of $80,000$ requests per second within a $5$ -minute window. The current architecture consists of an Application Load Balancer (ALB) distributing traffic to Amazon EC2 instances in an Auto Scaling Group, with a backend Amazon RDS for MySQL Multi-AZ database. During a mock release, the system failed due to ALB HTTP 503 (Service Unavailable) errors and database exhaustion from read queries. How should the solutions architect redesign the architecture to handle the next release?

Enable read traffic routing to the standby instance of the RDS MySQL Multi-AZ deployment to distribute the read query load. Rely on the default auto-scaling behavior of the Application Load Balancer to scale out as client connections increase.

Deploy Amazon ElastiCache for Memcached to cache database query results, configuring multi-AZ replication to ensure the cache layer is highly available. Rely on target tracking scaling policies on the Application Load Balancer to automatically scale capacity during the event.

Configure Amazon CloudFront in front of the Application Load Balancer to cache static assets. Migrate the backend database to Amazon Aurora MySQL, and configure Aurora Replicas with Auto Scaling to scale read capacity. Contact AWS Support to pre-warm the Application Load Balancer before the results release.

Migrate the database to Amazon Aurora MySQL. Rely on the Application Load Balancer's automatic scaling to handle the incoming request rate, and configure the EC2 Auto Scaling group with a very short cooldown period to launch new instances as quickly as possible during the spike.

Show answer & explanation

Answer: Configure Amazon CloudFront in front of the Application Load Balancer to cache static assets. Migrate the backend database to Amazon Aurora MySQL, and configure Aurora Replicas with Auto Scaling to scale read capacity. Contact AWS Support to pre-warm the Application Load Balancer before the results release.

Answer

Configure Amazon CloudFront in front of the Application Load Balancer to cache static assets, migrate the database to Amazon Aurora MySQL with Auto Scaling Aurora Replicas to handle dynamic reads, and request AWS Support to pre-warm the ALB prior to the release.

The correct solution involves offloading static content caching to Amazon CloudFront to reduce load on the origin, migrating the database to Amazon Aurora MySQL to scale reads horizontally via Aurora Replicas, and pre-warming the Application Load Balancer by contacting AWS Support. Pre-warming ensures the ALB is provisioned with sufficient capacity to handle the sudden, massive traffic spike immediately without dropping connections.

Step-by-Step Solution

Identify the cause of the HTTP 503 errors.

The ALB was unable to scale quickly enough to handle the instantaneous

80,000

requests per second spike.

ALBs scale based on traffic patterns and need time to scale out. Pre-warming is required for sudden, massive spikes.

Address the database read exhaustion.

Migrate to Amazon Aurora MySQL and enable Aurora Replicas with Auto Scaling.

Aurora Replicas scale reads horizontally to handle massive query volumes, whereas RDS Multi-AZ standbys cannot serve read traffic.

Optimize asset delivery and reduce load on the ALB.

Deploy Amazon CloudFront in front of the ALB.

CloudFront caches static content closer to users, reducing the volume of requests hitting the ALB and EC2 instances.

Key Concept

Handling massive, instantaneous traffic spikes by pre-warming load balancers, offloading static content using CloudFront, and scaling database reads horizontally with Aurora Replicas.

Estimated Time:2m 0s

Question 1900Question →

A solutions architect is designing a new document management platform for an enterprise. The platform must store PDF documents and their metadata. The document storage must use a shared file system that supports the NFSv4 protocol and automatically reduces storage costs for files that are not accessed for 30 days, while keeping them immediately available when requested. The metadata database must support an OLTP workload with high read volume, and must dynamically scale read capacity while maintaining low latency. In the event of an Availability Zone outage, the database must have a recovery point objective (RPO) of less than 1 second and a recovery time objective (RTO) of less than 1 minute. Which two database and storage configurations should the solutions architect choose to meet these requirements?

Select all that apply

Deploy an Amazon Aurora PostgreSQL DB cluster with one primary instance and one or more Aurora Replicas, and enable Aurora Auto Scaling for the reader endpoint.

Deploy an Amazon EFS file system configured with Lifecycle Management to transition files to the EFS Infrequent Access (IA) storage class after 30 days.

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

Deploy an Amazon RDS for PostgreSQL DB instance with daily automated backups and use AWS Backup replication to restore the database from snapshots in a new Availability Zone if a failure occurs.

Deploy an Amazon EFS file system encrypted with the AWS-managed KMS key (aws/elasticfilesystem) and replicate files to a backup account using cross-account replication.

Show answer & explanation

Answer: Deploy an Amazon Aurora PostgreSQL DB cluster with one primary instance and one or more Aurora Replicas, and enable Aurora Auto Scaling for the reader endpoint.; Deploy an Amazon EFS file system configured with Lifecycle Management to transition files to the EFS Infrequent Access (IA) storage class after 30 days.

Answer

Deploying an Amazon Aurora PostgreSQL DB cluster with Aurora Replicas and Auto Scaling meets the database requirements, while deploying an Amazon EFS file system with Lifecycle Management to transition files to EFS Infrequent Access (IA) after 30 days meets the shared file system requirements.

Deploying Amazon Aurora PostgreSQL with reader replicas and auto-scaling addresses the relational OLTP workload's high read volume while meeting the strict RTO (< 1 minute) and RPO (< 1 second) targets. Deploying Amazon EFS with Lifecycle Management configured for EFS Infrequent Access (IA) satisfies the NFSv4 storage requirement and optimizes costs for files inactive for more than 30 days while keeping them instantly accessible.

Step-by-Step Solution

Analyze the file system requirements: the system must support NFSv4 and automatically transition files to lower-cost storage after 30 days while keeping them instantly accessible.

Amazon EFS supports NFSv4 and has a Lifecycle Management feature that transitions inactive files to EFS Infrequent Access (IA) after 30 days, keeping them immediately available for reads with low latency.

EFS is a fully managed NFSv4 file system designed to scale dynamically and support life cycle transitions to optimize costs.

Analyze the database requirements: support OLTP workloads with high read volume, dynamic scaling of reads, RPO < 1 second, and RTO < 1 minute during Availability Zone failures.

Amazon Aurora PostgreSQL replicates data across 3 AZs with near-zero lag (RPO < 1 second), supports automated failover within 30 seconds (RTO < 1 minute) to an Aurora Replica, and allows Aurora Auto Scaling on reader endpoints to handle high read volumes dynamically.

Aurora architecture separates compute and storage, facilitating fast replication, quick failovers, and horizontal scaling of read replicas.

Evaluate the incorrect options against the constraints and identify underlying errors.

The option suggesting routing read traffic to the RDS Multi-AZ standby instance fails because standby instances are passive. The option suggesting snapshot recovery fails the 1-minute RTO target. The option using AWS-managed KMS keys for cross-account EFS replication fails because AWS-managed keys cannot be shared across accounts.

Understanding AWS-managed KMS key limitations, RDS Multi-AZ architecture, and RTO capabilities of snapshot restores helps eliminate incorrect options.

Key Concept

Selecting the optimal database and file storage solutions on AWS that align with strict RTO/RPO objectives, read-scaling requirements, NFSv4 protocol compatibility, lifecycle management cost optimizations, and security best practices.

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