Examkin

All practice questions

1964 questions

All types1,964Multiple choice1,006Multiple select931Ordering27
Question 801Question →

A retail company is designing a hybrid network to connect its on-premises corporate offices to a multi-account environment on AWS in the us-west-2 Region. The AWS environment contains a central network services account, a Production account, and a Development account. The Production and Development accounts each contain one spoke VPC.

The company has deployed an AWS Transit Gateway (TGW) in the central network services account and attached the spoke VPCs. To establish connectivity to the corporate offices, the company provisions a 1 Gbps AWS Direct Connect (DX) connection with a transit virtual interface (VIF) attached to a Direct Connect Gateway (DXGW), which is associated with the TGW. For high availability, they also configure a backup IPsec Site-to-Site VPN over the internet to the same TGW.

The company has the following requirements:
- The DX connection must serve as the primary path, and the Site-to-Site VPN must serve as a standby path that only handles traffic if the DX connection is down.
- Workloads in the spoke VPCs must be able to resolve DNS names of on-premises resources.
- All outbound internet traffic from the spoke VPCs must route through a centralized egress VPC in the network services account in a highly available manner.

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

Select all that apply

Show answer & explanation

Answer: On the customer gateway device, set a higher BGP Local Preference for routes received from AWS via the Direct Connect Transit VIF compared to the Site-to-Site VPN, and advertise the identical corporate network CIDR block over both paths.; In the central network services account, create a Route 53 Resolver outbound endpoint, define a Resolver rule for the on-premises domain pointing to corporate DNS servers, and associate the rule with the Production and Development spoke VPCs.

Answer

The correct actions are to configure a higher BGP Local Preference on the customer gateway for routes received via the Direct Connect Transit VIF than the Site-to-Site VPN (advertising identical CIDRs over both), and to create a Route 53 Resolver outbound endpoint in the central network services account, defining a Resolver rule for the on-premises domain, and associating this rule with the Production and Development spoke VPCs.
The correct options are to configure a higher BGP Local Preference on the customer gateway for routes received via the Direct Connect Transit VIF compared to the Site-to-Site VPN while advertising identical CIDRs over both, and to create a Route 53 Resolver outbound endpoint in the central account with Resolver rules associated with both spoke VPCs. The identical prefix advertisement ensures Transit Gateway (which automatically prefers DXGW over VPN for identical prefixes) routes traffic via Direct Connect for the AWS-to-on-premises direction. Setting local preference on the customer gateway ensures the on-premises router prefers the Direct Connect link for the on-premises-to-AWS direction. Creating a central Route 53 Resolver outbound endpoint and sharing/associating the forwarding rule allows spoke VPCs to resolve on-premises hostnames without needing duplicate endpoints.

Step-by-Step Solution

1
Establish routing priority for primary/backup.
On the on-premises customer gateway, set local preference to prefer routes learned via the DX Transit VIF, and advertise identical CIDR blocks over both DX and VPN.
Ensures symmetric routing where DX is preferred for both ingress and egress, as TGW naturally prefers DX over VPN for identical prefixes. This prevents asymmetric routing and provides automatic failover.
2
Establish hybrid DNS resolution.
Set up Route 53 Resolver outbound endpoints in the hub VPC and define forwarding rules for the corporate domain. Associate these rules with the Production and Development spoke VPCs.
Queries from spoke VPCs for the corporate domain are forwarded to the on-premises DNS servers. Enables private name resolution of on-premises resources across the multi-account network.

Key Concept

Configuring high availability routing over AWS Transit Gateway using Direct Connect (Transit VIF) and VPN failover, combined with cross-account DNS resolution using Route 53 Resolver rules.
Estimated Time:2m 0s
Question 802Question →

A multinational corporation is designing its AWS multi-account governance strategy using AWS Organizations. The organizational structure has a Workloads Organizational Unit (OU) containing separate Production and Non-Production child OUs. The security team requires that AWS CloudTrail and AWS Config remain enabled and unaltered across all member accounts within the Workloads OU. Additionally, developers operating in these accounts must be prevented from deleting or modifying a centralized IAM role named SecurityComplianceRole. However, a central deployment pipeline that assumes an IAM role named PipelineExecutionRole in each member account must be permitted to modify these governance resources and update the SecurityComplianceRole during scheduled deployments. Which of the following governance strategies should a solutions architect recommend to meet these requirements with the least administrative effort?

Show answer & explanation

Answer: Apply a Service Control Policy (SCP) at the Workloads OU level that denies iam:* actions targeting the SecurityComplianceRole, and config:* and cloudtrail:* write actions. Add a Condition to the SCP that exempts the principal ARN of the PipelineExecutionRole from the Deny rule. Rely on local IAM policies in the member accounts to grant developers their necessary daily operational permissions.

Answer

Apply a Service Control Policy (SCP) at the Workloads OU level that denies modification of the SecurityComplianceRole, AWS Config, and CloudTrail, while using a Condition to exempt the PipelineExecutionRole. Local IAM policies must be configured in member accounts to grant developers their permissions.
The correct strategy uses an SCP at the Workloads OU level to restrict modifications of AWS Config, AWS CloudTrail, and the specific SecurityComplianceRole. By adding a condition that checks the 'aws:PrincipalARN' and exempts the PipelineExecutionRole ARN, the security team ensures the pipeline can perform updates while blocking developers and local administrators. Local IAM policies are still used to grant developers their daily operational permissions, as SCPs are guardrails that limit the maximum available permissions rather than granting them.

Step-by-Step Solution

1
Analyze the requirements for restricting actions on CloudTrail, AWS Config, and the SecurityComplianceRole across all member accounts in the Workloads OU.
Identify that Service Control Policies (SCPs) attached to OUs are the most operationally efficient way to enforce organization-wide guardrails on all member account principals.
SCPs allow centralized restriction of actions across multiple accounts, preventing even local administrators from bypassing security controls.
2
Identify the exception requirement for the PipelineExecutionRole assumed by the central pipeline.
Determine that the SCP must include a condition block using the 'StringNotLike' operator for the 'aws:PrincipalARN' context key to exempt the PipelineExecutionRole ARN from the Deny actions.
This allows the pipeline to modify the restricted resources during deployments while blocking all other users, including local admins.
3
Evaluate the mechanism of SCPs versus local IAM policies.
Understand that SCPs act as guardrails (implicit deny / explicit deny overrides any allow) and do not grant permissions. Local IAM policies are still required to grant permissions.
This ensures the solution is secure and functions correctly, avoiding the misconception that SCPs grant permissions.

Key Concept

AWS Organizations Service Control Policies (SCPs) act as permission boundaries/guardrails rather than permission-granting mechanisms, and they can utilize condition keys like 'aws:PrincipalARN' to implement administrative exemptions.
Question 803Question →

A company is designing a deployment pipeline for a containerized microservice that will run on Amazon ECS with AWS Fargate behind an Application Load Balancer (ALB). The application requires zero downtime during updates. The deployment strategy must route exactly 10% of the production traffic to the new version of the microservice, maintain this traffic share for a soak period of exactly 10 minutes, and then shift all remaining traffic to the new version. If any Amazon CloudWatch alarms trigger during this 10-minute soak period, the deployment must automatically roll back immediately. Which strategy and configuration will meet these requirements with the least operational overhead?

Show answer & explanation

Answer: Configure AWS CodeDeploy with a blue/green deployment. Create a custom CodeDeploy deployment configuration for ECS with a TimeBasedCanary routing type, specifying 10% traffic for a 10-minute interval. Associate the CloudWatch alarms with the deployment group to manage the rollback.

Answer

Configure AWS CodeDeploy with a blue/green deployment. Create a custom CodeDeploy deployment configuration for ECS with a TimeBasedCanary routing type, specifying 10% traffic for a 10-minute interval. Associate the CloudWatch alarms with the deployment group to manage the rollback.
The correct strategy uses a custom AWS CodeDeploy deployment configuration because AWS does not provide a predefined canary configuration for exactly 10 minutes (only 5-minute and 15-minute options are available). By defining a custom TimeBasedCanary routing configuration with a 10% canary percentage and a 10-minute interval, the system keeps traffic at 10% for the required soak duration before shifting the rest. Associating CloudWatch alarms with the CodeDeploy deployment group enables automatic, zero-downtime rollbacks if the alarms trigger.

Step-by-Step Solution

1
Determine the deployment type for ECS tasks under CodeDeploy.
Identify that CodeDeploy only supports blue/green deployments for ECS compute platforms.
ECS deployments require registering a replacement task set (green) and shifting traffic from the original task set (blue).
2
Identify the required traffic routing pattern and match against predefined AWS configurations.
Note that the business requires a canary pattern (10% traffic for 10 minutes). Recognize that there is no predefined CodeDeployDefault.ECSCanary10Percent10Minutes configuration (only 5-minute and 15-minute versions exist).
AWS provides a limited set of default configurations. Any non-standard duration requires defining a custom configuration.
3
Define a custom CodeDeploy deployment configuration.
Create a custom configuration with a TimeBasedCanary routing type, setting canaryPercentage to 10 and canaryInterval to 10.
This matches the exact business requirement of holding a 10% traffic share for a 10-minute soak period.
4
Configure the automated rollback mechanism.
Associate the CloudWatch alarms monitoring error rates with the CodeDeploy deployment group.
CodeDeploy natively monitors these alarms during the deployment and triggers an immediate traffic rollback to the original task set if any alarm enters the ALARM state.

Key Concept

Custom ECS deployment configurations and canary routing in AWS CodeDeploy
Question 804Question →

A financial services company is designing a highly available, multi-region disaster recovery (DR) architecture for a critical transactional analytics application. The primary environment runs in the us-east-1 Region, and the DR environment will be located in the us-west-2 Region. The application uses Amazon Aurora PostgreSQL as its database. The application's microservices communicate internally using a Route 53 Private Hosted Zone (PHZ). The dashboard workers in private subnets require continuous outbound internet access for third-party API validation.

The solution must meet an RTO of less than 1010 minutes, an RPO of less than 11 minute, and minimize resource costs in the DR region during normal operations.

Which two actions should a solutions architect take to meet these requirements?

Select all that apply

Show answer & explanation

Answer: Deploy an Amazon Aurora Global Database with the primary cluster in us-east-1 and a secondary cluster in us-west-2, configuring the secondary cluster with a single low-instance-class reader node. In both regions, deploy a NAT Gateway in each Availability Zone and associate them with the route tables of their respective private subnets.; Associate the Route 53 Private Hosted Zone (PHZ) with the application VPCs in both us-east-1 and us-west-2. Use Route 53 failover routing policy with health checks associated with public endpoints to manage external client traffic routing between regions.

Answer

Deploy an Amazon Aurora Global Database with a secondary cluster containing a single low-instance-class reader node to satisfy RPO and RTO requirements while minimizing costs, and deploy a NAT Gateway in each Availability Zone for high availability. Associate the Route 53 Private Hosted Zone with the VPCs in both regions, and use Route 53 failover routing with health checks to manage public client traffic routing.
Deploying an Amazon Aurora Global Database with a secondary cluster containing a single low-instance-class reader node satisfies the RPO of less than 11 minute due to low-latency storage-based replication, and satisfies the RTO of less than 1010 minutes as the secondary cluster can be promoted quickly. Redundant NAT Gateways deployed in each Availability Zone prevent outbound network outages during an Availability Zone failure. Furthermore, associating the Route 53 Private Hosted Zone with the VPCs in both regions ensures internal DNS resolution remains functional after a regional failover, while Route 53 failover routing handles client traffic redirection.

Step-by-Step Solution

1
Analyze the database HA/DR requirements.
An RPO of less than 11 minute and RTO of less than 1010 minutes requires continuous, low-latency cross-region replication. Amazon Aurora Global Database uses storage-based replication with replication lag typically under 11 second and can be promoted to a primary cluster in less than 1010 minutes, satisfying the recovery objectives. A single low-instance-class reader node in the secondary region minimizes baseline resource costs.
Ensures the database layer meets both business recovery objectives and cost-efficiency constraints.
2
Address the NAT Gateway high availability requirement.
Deploying a NAT Gateway in each Availability Zone in both regions ensures that an outage in a single Availability Zone does not impact outbound internet access for resources in other zones.
Prevents a single point of failure in the network egress path, satisfying high availability constraints.
3
Configure internal DNS resolution for cross-region failover.
Associate the Route 53 Private Hosted Zone (PHZ) with the VPCs in both us-east-1 and us-west-2.
A Private Hosted Zone must be explicitly associated with a VPC in order for resources in that VPC to resolve the domain names defined within it.
4
Implement external routing failover.
Configure Route 53 failover routing policy with health checks associated with public endpoints to manage client traffic routing between the primary and secondary regions.
Automatically redirects client traffic to the secondary region when the primary region is determined to be unhealthy.

Key Concept

Designing multi-region disaster recovery and high availability architectures using Amazon Aurora Global Database, redundant NAT Gateways, and Route 53 DNS routing and Private Hosted Zone VPC associations under strict RTO, RPO, and cost constraints.
Question 805Question →

An IoT service provider is designing a new multi-tenant telemetry ingestion platform on AWS. The core ingestion application runs on Amazon ECS in a shared services AWS account (Account A) and must write incoming telemetry data directly to Amazon S3 buckets located in various customer-owned AWS accounts. A key requirement is that a retail customer (using Account B) must control the encryption keys used for their data at rest and have the ability to immediately revoke the ingestion application's write access to their bucket without modifying any S3 bucket policies. Which of the following configuration strategies meets these security and architectural requirements?

Show answer & explanation

Answer: Configure the S3 bucket in Account B to use default Server-Side Encryption with AWS KMS (SSE-KMS) utilizing a Customer Managed Key (CMK) created in Account B. Update the CMK key policy in Account B to grant kms:GenerateDataKey permissions to the ingestion IAM role from Account A. Configure the S3 bucket policy in Account B to grant s3:PutObject permissions to the ingestion IAM role. In Account A, attach an IAM policy to the ingestion role that allows s3:PutObject on Account B's bucket and kms:GenerateDataKey on Account B's CMK.

Answer

Configure the S3 bucket in Account B to use a Customer Managed Key (CMK), grant the ingestion role in Account A both s3:PutObject and kms:GenerateDataKey permissions via Account B's resource policies, and configure corresponding IAM policies in Account A to permit these actions.
The correct strategy involves configuring the S3 bucket in the customer's account (Account B) to encrypt data using a Customer Managed Key (CMK). By granting the ingestion IAM role in Account A permission to generate data keys on Account B's CMK, and granting write access via the S3 bucket policy, the ingestion role is authorized to perform cross-account writes. The customer can immediately revoke access by disabling the CMK or changing the key policy, which blocks key generation and halts S3 uploads without needing to modify S3 bucket policies.

Step-by-Step Solution

1
Determine the encryption key type required for cross-account S3 write operations.
Identify that a Customer Managed Key (CMK) in Account B is required.
AWS managed keys (like aws/s3) cannot be shared cross-account because their key policies are immutable and cannot grant access to external accounts.
2
Configure permissions in the destination account (Account B).
Grant the ingestion IAM role from Account A permissions to call s3:PutObject in the S3 bucket policy, and kms:GenerateDataKey in the Customer Managed Key policy.
Cross-account resource access requires explicit resource-level permission delegation from the owning account.
3
Configure local IAM permissions in the source account (Account A).
Attach an IAM policy to the ingestion role allowing s3:PutObject on Account B's bucket and kms:GenerateDataKey on Account B's CMK.
An IAM entity in one account must be explicitly permitted by its own account's policies to perform cross-account resource operations.
4
Verify key revocation requirements.
Disable the CMK or remove the ingestion role from the key policy to revoke access immediately.
S3 SSE-KMS requires the calling principal to successfully call kms:GenerateDataKey to encrypt the object. Revoking KMS access halts S3 uploads immediately without needing to modify the S3 bucket policy.

Key Concept

Cross-account KMS and S3 permissions delegation
Question 806Question →

An enterprise has a multi-account AWS environment with a Transit Gateway (TGW) deployed in the us−east−1us-east-1 Region. The enterprise requires high-availability hybrid connectivity to its on-premises data center. To achieve this, the enterprise establishes two AWS Direct Connect (DX) connections:
- Connection A: A primary 10 Gbps10\text{ Gbps} DX connection at a Virginia DX location.
- Connection B: A backup 1 Gbps1\text{ Gbps} DX connection at a Chicago DX location.

Both connections terminate on the same customer gateway router on-premises. The Solutions Architect creates a Transit Virtual Interface (Transit VIF) for each connection and associates them with a single Direct Connect Gateway (DXGW), which is attached to the TGW in us−east−1us-east-1.

The enterprise has the following traffic requirements:
- Requirement 1: Traffic from AWS to the on-premises network must prefer Connection A. If Connection A fails, traffic must fail over to Connection B.
- Requirement 2: Traffic from the on-premises network to AWS must prefer Connection A. If Connection A fails, traffic must fail over to Connection B.

Which combination of BGP routing configurations will meet these requirements while preventing asymmetric routing?

Show answer & explanation

Answer: For AWS-to-on-premises traffic, configure the customer gateway to advertise the on-premises prefixes to AWS with the BGP community 7224:73007224:7300 over Connection A, and with the BGP community 7224:71007224:7100 over Connection B. For on-premises-to-AWS traffic, configure the customer gateway to set a higher local preference for routes received over Connection A containing the BGP community 7224:81007224:8100 compared to routes received over Connection B containing the BGP community 7224:82007224:8200.

Answer

Configure the customer gateway to advertise on-premises prefixes with the BGP community 7224:73007224:7300 over Connection A and 7224:71007224:7100 over Connection B, and configure the customer gateway to set a higher local preference for routes received over Connection A containing the BGP community 7224:81007224:8100 compared to routes received over Connection B containing the BGP community 7224:82007224:8200.
The correct configuration uses BGP communities to influence routing in both directions. For AWS-to-on-premises traffic, the customer gateway uses the communities 7224:73007224:7300 (high preference) and 7224:71007224:7100 (low preference) to instruct the AWS Direct Connect Gateway which path to prefer. For on-premises-to-AWS traffic, AWS advertises prefixes with 7224:81007224:8100 (indicating the local region, Virginia/us-east-1) over Connection A and 7224:82007224:8200 (indicating same continent, Chicago) over Connection B. By mapping these communities to a higher local preference on the customer gateway for Connection A, traffic flows symmetrically over Connection A and dynamically fails over to Connection B if Connection A goes offline.

Step-by-Step Solution

1
Configure the customer gateway to advertise the on-premises prefixes with specific BGP communities to AWS.
The customer gateway advertises prefixes with 7224:73007224:7300 over Connection A and 7224:71007224:7100 over Connection B.
This influences the Direct Connect Gateway's path selection for AWS outbound traffic, prioritizing Connection A.
2
Configure the customer gateway to evaluate incoming BGP communities advertised by AWS.
The customer gateway identifies routes with the community 7224:81007224:8100 on Connection A and 7224:82007224:8200 on Connection B.
AWS advertises local region routes with 7224:81007224:8100 and same-continent routes with 7224:82007224:8200 to help the customer determine route proximity.
3
Configure BGP local preference on the customer gateway based on the received communities.
A higher local preference is assigned to routes received with 7224:81007224:8100, directing on-premises-to-AWS traffic over Connection A.
This alignment prevents asymmetric routing and guarantees symmetric traffic flows over the primary connection.

Key Concept

Symmetric hybrid routing using BGP communities over AWS Direct Connect and Transit Gateway
Estimated Time:3m 0s
Question 807Question →

An enterprise manages its applications across 50 AWS accounts organized under AWS Organizations. The security team is designing a federated identity solution using an external SAML 2.0 compliant Identity Provider (IdP). To minimize administrative overhead and centralize user authentication, the team plans to establish the SAML trust relationship in a single dedicated Identity AWS account. Corporate engineers must be able to use the AWS CLI to authenticate via the external IdP and obtain temporary security credentials to access specific target roles in various production and development member accounts. Which combination of configuration steps is required to implement this federated access model? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: In the central Identity account, create a SAML identity provider and a federated IAM role, then configure this role's trust policy to allow the `sts:AssumeRoleWithSAML` action from the SAML identity provider principal.; In the target member accounts, configure the trust policy of each target role to allow the `sts:AssumeRole` action, specifying the Amazon Resource Name (ARN) of the federated IAM role in the central Identity account as the principal.

Answer

In the central Identity account, create a SAML identity provider and a federated IAM role, then configure this role's trust policy to allow the sts:AssumeRoleWithSAML action from the SAML identity provider principal; and in the target member accounts, configure the trust policy of each target role to allow the sts:AssumeRole action, specifying the Amazon Resource Name (ARN) of the federated IAM role in the central Identity account as the principal.
Establishing federated access in a centralized identity account (the 'hop' model) requires a SAML provider resource and a federated IAM role configured with `sts:AssumeRoleWithSAML`. To enable access to target member accounts, those target roles must explicitly trust the central federated role as a principal using `sts:AssumeRole`. This combined structure minimizes identity provider configuration overhead while maintaining strict least-privilege delegation across the organization.

Step-by-Step Solution

1
Configure SAML federation in the central Identity account.
Create an IAM SAML provider and a federated IAM role. Set the trust policy of this federated role to allow the action `sts:AssumeRoleWithSAML` when called by the SAML provider principal.
This establishes the initial trust relationship allowing external IdP users to authenticate into AWS and obtain temporary credentials in the central Identity account.
2
Configure cross-account trust in the target member accounts.
Create target IAM roles in each member account. Set their trust policies to allow the `sts:AssumeRole` action, specifying the federated role's ARN from the central Identity account as the principal.
This establishes cross-account trust, enabling users who have assumed the federated role in the central Identity account to assume the role in the destination accounts.
3
Configure CLI authentication flow.
The CLI helper authenticates to the external SAML IdP, uses the assertion to invoke `sts:AssumeRoleWithSAML` on the central federated role, and then invokes `sts:AssumeRole` on the target member role.
This programmatic flow allows developers to navigate across accounts without needing separate SAML configurations in every single member account.

Key Concept

Cross-account IAM delegation combined with centralized SAML federation (the 'hop' model).
Estimated Time:3m 0s
Question 808Question →

A company is deploying a new service in a multi-account environment. An Amazon ECS task running in Account B must retrieve a database credential stored in AWS Secrets Manager in Account A. The secret is encrypted using the default AWS-managed KMS key (aws/secretsmanager). A resource-based policy has been attached to the secret in Account A, granting read permissions to the IAM role of the ECS task in Account B. However, the ECS task still receives an access denied error when attempting to retrieve the credential. Which action must the Solutions Architect take to resolve this issue?

Show answer & explanation

Answer: Re-encrypt the secret in Account A using a customer managed KMS key, configure the key policy of the customer managed KMS key to allow cross-account access from Account B, and grant KMS decrypt permissions to the ECS task IAM role in Account B.

Answer

Re-encrypt the secret in Account A using a customer managed KMS key, configure the key policy of the customer managed KMS key to allow cross-account access from Account B, and grant KMS decrypt permissions to the ECS task IAM role in Account B.
Re-encrypting the secret with a customer managed KMS key is required because AWS-managed KMS keys (like aws/secretsmanager) cannot be shared across accounts. A customer managed KMS key's policy can be updated to trust Account B, and the IAM role in Account B can then be granted decrypt permissions.

Step-by-Step Solution

1
Identify the encryption configuration of the Secrets Manager secret.
The secret is encrypted with the default AWS-managed KMS key (aws/secretsmanager).
AWS-managed KMS keys cannot be shared across accounts, meaning any cross-account access will fail regardless of resource policies.
2
Create a customer managed KMS key in Account A and re-encrypt the secret with it.
The secret is now encrypted with a key whose policy can be modified.
Customer managed KMS keys support policy modifications, allowing cross-account access delegation.
3
Update the customer managed KMS key policy in Account A and the IAM role in Account B.
The KMS key policy allows Account B to use the key, and the ECS task's IAM role permits the kms:Decrypt action.
Both the key policy and the consumer's IAM policy must explicitly allow the decryption operation to complete the cross-account permission chain.

Key Concept

Cross-account AWS KMS access constraints and differences between AWS-managed keys and customer managed keys.
Question 809Question →

An enterprise is establishing a new multi-account governance strategy using AWS Organizations. The security team requires that all API activity across all accounts is centrally logged to a secure Amazon S3 bucket in a dedicated Log Archive account, encrypted with a customer-managed KMS key, and protected against deletion or modification by any account administrator. What is the correct sequence of steps to configure this centralized logging and governance structure?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

To establish centralized and protected logging, first create the AWS Organization and OUs. Second, provision the dedicated Log Archive account under the Security OU. Third, set up the secure S3 bucket and KMS key within the Log Archive account. Fourth, enable trusted access for CloudTrail and deploy the organization trail. Finally, enforce security by attaching an SCP at the organization Root or OU level to prevent modification of these logging resources.
The correct order establishes a logical progression of dependencies: defining the organizational structure first, provisioning the dedicated account, setting up the destination S3 bucket and KMS keys inside that account, deploying the organization-wide CloudTrail to stream data to that bucket, and finally securing the setup using Service Control Policies (SCPs) to prevent tampering.

Step-by-Step Solution

1
Create the AWS Organization and define the OU hierarchy.
An AWS Organization is initialized with management control, and logical OUs (such as Security and Workloads) are available for grouping accounts.
You cannot deploy accounts or apply policies structurally without first establishing the Organization and its OUs.
2
Provision the Log Archive account under the Security OU.
A clean, isolated member account is created specifically for storing logs and audit records.
The destination account must exist in the organization before configuring localized destination resources.
3
Configure the S3 bucket and customer-managed KMS key inside the Log Archive account.
An S3 bucket is configured with bucket policies allowing the CloudTrail service to write logs, and a KMS key is configured to allow encryption of those logs.
The trail deployment in the next step will fail if the specified target S3 bucket or KMS key does not exist or lacks correct permission policies.
4
Enable trusted access for AWS CloudTrail in the Organizations management account and deploy the organization trail.
A single organization-wide trail automatically starts delivering encrypted API activity logs from all member accounts to the centralized S3 bucket.
This establishes the logging mechanism across the entire Organization.
5
Attach an SCP to the Root of the organization to prevent modification of the logging resources.
Root and administrator users in all member accounts are blocked from disabling the trail, deleting the S3 bucket, or modifying the KMS key policies.
Applying the SCP secures the logging configuration against tampering, fulfilling the compliance and governance requirements.

Key Concept

Establishing multi-account governance involves a precise sequence of setting up the AWS Organization structure, isolating resources in dedicated accounts (such as a Log Archive account), configuring destination storage and encryption keys, deploying organization-wide services via trusted access, and securing the configuration using Service Control Policies (SCPs).
Question 810Question →

A professional certification organization is launching a high-stakes synchronous online exam. The platform must support 850,000850,000 candidates logging in and downloading their customized exam profiles within a 55-minute window starting at exactly 14:00 UTC. The current architecture consists of an Application Load Balancer (ALB) routing to an Auto Scaling group (ASG) of Amazon EC2 instances, with an Amazon Aurora PostgreSQL database cluster containing one writer and two reader instances. During a load simulation, the reactive scaling policies failed to provision EC2 instances in time, the ALB dropped connection requests, and the database reader instances experienced CPU exhaustion and query timeouts. Which strategy should a solutions architect recommend to ensure the platform scales and maintains performance during the exam launch?

Show answer & explanation

Answer: Request ALB pre-warming from AWS Support for the expected traffic profile. Set up a scheduled scaling policy on the ASG to launch the required number of EC2 instances 3030 minutes before the exam starts. Pre-provision additional Aurora Replicas in the cluster before the exam begins, and configure an Aurora Auto Scaling policy to handle any additional read queries during the test.

Answer

Request ALB pre-warming from AWS Support, set up a scheduled scaling policy on the ASG to launch the required number of EC2 instances in advance, pre-provision additional Aurora Replicas before the exam starts, and use Aurora Auto Scaling to handle extra queries during the test.
The correct option addresses all scaling bottlenecks in advance. Because the traffic surge occurs instantly within a 55-minute window, reactive scaling is ineffective. Pre-warming the ALB prevents initial connection drops. Scheduled scaling ensures the EC2 instances are fully booted and ready. Pre-provisioning Aurora Replicas ensures the database read layer can handle the immediate load spike, as database instance creation takes too long for reactive scaling policies to respond.

Step-by-Step Solution

1
Address the entry point scaling bottleneck by contacting AWS Support to pre-warm the Application Load Balancer.
The ALB is configured with sufficient capacity in advance to prevent dropped connection requests during the initial 55-minute surge.
Standard ALB scaling algorithms adjust capacity based on traffic growth over time; immediate surges of 850,000850,000 concurrent connections will exceed standard thresholds and result in HTTP 503 or connection drop errors before the ALB can scale out.
2
Implement a scheduled scaling policy for the EC2 Auto Scaling group to launch instances 3030 minutes prior to the exam start.
The compute layer is fully scaled and warmed up before the spike occurs.
Reactive scaling policies (such as target tracking or step scaling) require metrics to violate thresholds for a sustained period, after which the EC2 instances must boot, configure, and register. This process takes several minutes, making reactive scaling ineffective for instantaneous flash events.
3
Pre-provision additional Aurora Replicas in the database cluster and configure an Aurora Auto Scaling policy for dynamic load adjustments.
The database read capacity is scaled beforehand to handle the massive peak query rate.
Creating new database replicas takes several minutes to provision. Pre-provisioning ensures capacity is immediately available at 14:00 UTC, while the auto-scaling policy helps accommodate subsequent fluctuations during the exam.

Key Concept

Handling massive flash traffic workloads requires scaling all architectural layers in advance using pre-warming, scheduled scaling, and resource pre-provisioning rather than relying on reactive scaling mechanisms.
Estimated Time:3m 0s
Question 811Question →

A corporate payroll provider is launching a self-service year-end tax document portal. On the day tax forms are released, the portal expects an immediate traffic spike from 100100 requests per second to 120000120{}000 requests per second. The application consists of a read-heavy reporting dashboard hosted on an Auto Scaling Group of Amazon EC2 instances behind an Application Load Balancer (ALB). The dashboard queries an Amazon RDS for PostgreSQL database in a Multi-AZ deployment. Which two actions should the solutions architect recommend to optimize performance and scalability during this spike?

Select all that apply

Show answer & explanation

Answer: Contact AWS Support to pre-warm the Application Load Balancer to the expected traffic rate of 120000120{}000 requests per second.; Create Amazon RDS read replicas and configure the application to send read-heavy dashboard queries to the read replica endpoints.

Answer

Contact AWS Support to pre-warm the Application Load Balancer to the expected traffic rate, and create Amazon RDS read replicas to handle the read-heavy dashboard queries.
To handle a sudden, massive traffic spike (from 100100 to 120000120{}000 requests per second), the Application Load Balancer must be pre-warmed by AWS Support because its automatic scaling cannot react instantly. To handle the read-heavy load on the database layer, RDS read replicas must be used since the secondary standby DB instance in a Multi-AZ deployment is passive and cannot serve read traffic.

Step-by-Step Solution

1
Analyze the load balancer scaling behavior during a sudden 1200×1200\times traffic spike.
The Application Load Balancer cannot scale its capacity quickly enough, causing dropped connections and service timeouts.
ALB auto-scaling is designed to handle gradual increases in traffic, not instantaneous spikes of this magnitude.
2
Address the load balancer scaling limitation.
Submit a support ticket to pre-warm the Application Load Balancer to the expected 120000120{}000 requests per second.
Pre-warming ensures the load balancer has sufficient capacity provisioned before the traffic spike begins.
3
Evaluate read query scaling on the database layer.
Deploy RDS read replicas to offload read-heavy traffic from the primary DB instance.
The standby instance in an RDS Multi-AZ deployment is passive and cannot process read queries, making read replicas necessary for read scaling.
4
Assess the Auto Scaling Group cooldown configuration.
Avoid reducing the cooldown period below the instance launch and bootstrapping time.
A cooldown period that is too short causes the Auto Scaling group to launch unnecessary instances continuously before the previously launched instances can register as healthy.

Key Concept

Handling sudden flash traffic spikes requires pre-warming the load balancing layer and utilizing read replicas to scale read-heavy database workloads.
Estimated Time:2m 0s
Question 812Question →

An energy conglomerate is migrating its legacy power grid monitoring applications to AWS across multiple member accounts under AWS Organizations. The central network architecture uses an AWS Transit Gateway to connect several application VPCs to a central Shared Services VPC. The Shared Services VPC has a Direct Connect connection to the on-premises data center. The company has a Route 53 Private Hosted Zone (PHZ) named `grid.internal` in the Shared Services account, while on-premises servers use the domain `substation.internal` managed by on-premises DNS servers. The cloud engineering team must establish bidirectional DNS resolution between all VPCs and the on-premises environment.

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

Select all that apply

Show answer & explanation

Answer: Create Route 53 Resolver inbound endpoints in the Shared Services VPC to receive DNS queries for `grid.internal` from the on-premises DNS servers, and create Route 53 Resolver outbound endpoints with forwarding rules for `substation.internal` shared with the application accounts via AWS Resource Access Manager (RAM).; Authorize the association of the `grid.internal` Private Hosted Zone in the Shared Services account with the application VPCs in the member accounts, and then associate the Private Hosted Zone with each application VPC.

Answer

The solutions architect must create Route 53 Resolver inbound endpoints in the Shared Services VPC to receive queries from on-premises DNS servers, create Route 53 Resolver outbound endpoints with forwarding rules shared via AWS Resource Access Manager for the on-premises domain, and associate the central Private Hosted Zone with all member VPCs using cross-account Private Hosted Zone association authorization.
Establishing hybrid bidirectional DNS resolution requires two main configurations. First, to allow AWS VPCs to query the on-premises domain and on-premises servers to query AWS domains, Route 53 Resolver inbound and outbound endpoints are established in the Shared Services VPC, with rules shared across accounts via AWS Resource Access Manager. Second, to allow application VPCs in member accounts to resolve private DNS records from the centralized Private Hosted Zone, the zone must be explicitly associated with those VPCs through a cross-account authorization process.

Step-by-Step Solution

1
Set up inbound DNS resolution from on-premises to AWS.
Create Route 53 Resolver inbound endpoints in the Shared Services VPC. Configure on-premises DNS servers to forward queries for the internal domain to the inbound endpoint IP addresses.
This enables on-premises clients to resolve resource records in the AWS Private Hosted Zone.
2
Set up outbound DNS resolution from AWS to on-premises.
Create Route 53 Resolver outbound endpoints in the Shared Services VPC. Define a Resolver rule forwarding queries for the on-premises domain to the on-premises DNS servers. Share this rule with member accounts using AWS Resource Access Manager, and associate it with all VPCs.
This allows resource lookup for the on-premises domain from any VPC in the organization.
3
Configure cross-account Private Hosted Zone association.
Authorize the association of the internal Private Hosted Zone with the application VPCs using the Shared Services account credentials, and then associate the zone from each member account.
VPCs in member accounts cannot resolve records in the central Private Hosted Zone unless it is associated with those VPCs.

Key Concept

Multi-Account and Hybrid DNS Architecture Strategy using Route 53 Resolver and cross-account Private Hosted Zone associations
Question 813Question →

A company is implementing a multi-account strategy using AWS Organizations. They want to set up federated access for their enterprise users to log into the AWS Management Console of various member accounts using their on-premises SAML 2.0 Identity Provider (IdP). The Solutions Architect has created an IAM SAML identity provider in each member account and defined an IAM role for the federated users. However, during testing, users receive an error indicating that they are not authorized to assume the role.

Which configuration issue is the most likely cause of this error?

Show answer & explanation

Answer: The trust policy of the IAM role in the member accounts specifies the sts:AssumeRole action instead of the sts:AssumeRoleWithSAML action.

Answer

The trust policy of the IAM role in the member accounts specifies the sts:AssumeRole action instead of the sts:AssumeRoleWithSAML action.
To enable SAML 2.0 federation, the IAM role's trust policy must trust the SAML provider as the principal and allow the sts:AssumeRoleWithSAML action. If the trust policy incorrectly specifies sts:AssumeRole (which is used for standard cross-account access or IAM user role assumption), the AWS Security Token Service (STS) will reject the federation request because the correct API endpoint (AssumeRoleWithSAML) is not authorized by the trust policy.

Step-by-Step Solution

1
Analyze the authentication flow for SAML 2.0 federation to AWS.
Identify that the identity provider (IdP) sends a SAML assertion to the AWS STS service, which calls the AssumeRoleWithSAML API operation.
This establishes that the role's trust policy must specifically authorize the AssumeRoleWithSAML action.
2
Examine the trust policy requirements of the target IAM role.
The principal must be set to the ARN of the IAM SAML identity provider, and the action must be set to sts:AssumeRoleWithSAML.
Standard role assumption (sts:AssumeRole) is restricted to AWS principals and does not support SAML federated assertions.
3
Evaluate the cause of the authorization failure during federation.
Specifying sts:AssumeRole instead of sts:AssumeRoleWithSAML in the trust policy prevents the trust relationship from matching the incoming AssumeRoleWithSAML request.
Correcting the action in the trust policy allows the identity provider to exchange the SAML assertion for temporary credentials.

Key Concept

SAML 2.0 federation trust policies require the sts:AssumeRoleWithSAML action to allow external identity provider assertions to be exchanged for temporary security credentials.
Estimated Time:2m 0s
Question 814Question →

A metropolitan public transit agency is designing a contactless fare validation system on AWS. The application tier runs on Amazon EC2 instances in private subnets across multiple Availability Zones in both the us-east-1 and us-west-2 Regions. The application must connect securely to external fare settlement endpoints on the public internet. Internal microservices rely on private DNS resolution for service discovery across all VPCs. Validation requests from devices must be routed to the closest Region with active failover capabilities to ensure high availability and low latency. The architecture must achieve a Recovery Time Objective (RTO) of less than 5 minutes and a Recovery Point Objective (RPO) of less than 1 minute.

Which two of the following configuration options should the Solutions Architect implement to meet these requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Deploy NAT Gateways in each Availability Zone of the VPCs in both Regions, updating the private subnet route tables to route outbound internet traffic to the local NAT Gateway in the same Availability Zone.; Configure Route 53 Latency routing records with active health checks to route public validation traffic to the Application Load Balancers in both Regions, automatically routing traffic away from a degraded Region.

Answer

Deploy NAT Gateways in each Availability Zone of the VPCs in both Regions to ensure redundant outbound internet connectivity, and configure Route 53 Latency routing records with active health checks to route public validation traffic with low latency and automatic failover.
Deploying NAT Gateways in each Availability Zone provides fault tolerance for outbound traffic, ensuring that the loss of one Availability Zone does not impact outbound traffic from the other zones. Additionally, configuring Route 53 Latency routing with active health checks allows the agency to route validation traffic to the closest Region to minimize latency, while providing automatic failover within the 5-minute RTO boundary by detecting regional degradation and redirecting traffic to the remaining healthy Region.

Step-by-Step Solution

1
Evaluate the outbound connectivity requirements for high availability across Availability Zones.
Identified that deploying a NAT Gateway in each Availability Zone prevents an AZ outage from blocking outbound traffic in other zones.
Outbound connectivity to external fare settlement partners must remain highly available, requiring redundant NAT Gateways per AZ.
2
Evaluate the routing requirements for global validation requests.
Selected Route 53 Latency-based routing to ensure requests are routed to the closest Region to minimize validation latency.
The system requires low-latency routing to the closest Region while maintaining active failover capability.
3
Configure health checks on the Route 53 records.
Ensured that Route 53 can detect a regional outage and automatically fail over to the other Region within the 5-minute RTO.
Without health checks associated with the routing records, Route 53 cannot perform automatic DNS-level failover during an outage.

Key Concept

Designing multi-region disaster recovery and high availability with low-latency routing, redundant outbound gateways, and automated failover.
Question 815Question →

A television broadcasting company is launching a live interactive voting platform for a popular singing competition. During the 1010-minute voting window, the application expects an immediate surge from 100100 requests per second to over 80,00080,000 requests per second. The application runs on Amazon EC2 instances behind an Application Load Balancer (ALB) and uses an Amazon RDS for PostgreSQL database. Initial testing shows the ALB drops incoming requests during the sudden spike, and the database experiences severe read contention from checking participant metadata.

Which two actions should the Solutions Architect take to optimize the performance and scalability of the platform under these conditions?

Select all that apply

Show answer & explanation

Answer: Submit a support case to AWS to pre-warm the Application Load Balancer with the expected traffic rate.; Migrate the database to Amazon Aurora PostgreSQL and configure Aurora Replicas with Auto Scaling to handle the read query load.

Answer

To optimize the platform's performance and scalability, the Solutions Architect should submit a support case to pre-warm the Application Load Balancer and migrate the database to Amazon Aurora PostgreSQL to use Aurora Replicas with Auto Scaling.
The correct choices are pre-warming the Application Load Balancer and migrating the database to Amazon Aurora PostgreSQL to use Aurora Replicas with Auto Scaling. Pre-warming prepares the load balancer for the immediate volume, preventing packet loss. Aurora Replicas with Auto Scaling allow the application to handle high volumes of read queries by spreading them across dynamically scaled replicas.

Step-by-Step Solution

1
Address the load balancer bottleneck for sudden traffic surges.
Identify that the Application Load Balancer requires pre-warming to handle an immediate rise from 100100 to over 80,00080,000 requests per second.
Standard ELB auto-scaling is reactive and cannot scale fast enough for instant, massive spikes.
2
Resolve the database read contention bottleneck.
Select Amazon Aurora PostgreSQL as the database target to support horizontal read scaling.
Aurora Replicas support auto-scaling to distribute read traffic and reduce CPU load on the primary DB instance.
3
Eliminate invalid architecture options.
Discard RDS Multi-AZ standbys for read traffic and Memcached for multi-AZ replication scenarios.
RDS standby instances cannot serve read traffic, and ElastiCache for Memcached lacks multi-AZ replication support.

Key Concept

Performance and scalability optimization under flash traffic conditions
Question 816Question →

A logistics company is designing a hybrid DNS architecture for its AWS multi-account environment. A central Network account manages a Transit Gateway that connects spoke VPCs in multiple member accounts, as well as an on-premises datacenter via an AWS Direct Connect gateway. The on-premises network uses DNS servers that host the domain `onprem.logistics.local`. The company has created a Route 53 Private Hosted Zone (PHZ) for `aws.logistics.local` in a Shared Services AWS account. Spoke VPCs must be able to resolve records in both `aws.logistics.local` and `onprem.logistics.local`, and on-premises servers must be able to resolve records in `aws.logistics.local`. Which combination of actions should a Solutions Architect take to achieve this hybrid DNS resolution? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Configure Route 53 Resolver inbound endpoints in the central Network VPC. Configure the on-premises DNS servers to forward queries for the domain `aws.logistics.local` to the IP addresses of these inbound endpoints.; Authorize the cross-account association of the `aws.logistics.local` Private Hosted Zone from the Shared Services account to the spoke VPCs using the AWS CLI or SDK, and then perform the association from each member account.

Answer

Configure Route 53 Resolver inbound endpoints in the central Network VPC and configure on-premises DNS forwarders to point to them. Additionally, authorize the cross-account association of the Private Hosted Zone from the Shared Services account using the AWS CLI or SDK, and associate the spoke VPCs from the member accounts.
Configuring Route 53 Resolver inbound endpoints in the central Network VPC provides private IP addresses that receive DNS queries from the on-premises network. Configuring on-premises DNS forwarders to point to these IPs enables datacenter hosts to resolve internal AWS domains. Programmatic authorization of cross-account Private Hosted Zone association from the owning Shared Services account, followed by associating the spoke VPCs from the member accounts, allows all spoke VPCs to natively resolve records in the private zone.

Step-by-Step Solution

1
Configure inbound resolver endpoints in the central Network VPC.
IP addresses are assigned to the inbound endpoints within the private subnet space.
This provides a target destination for the on-premises DNS servers to forward queries for AWS resources.
2
Configure on-premises DNS servers to forward requests for `aws.logistics.local` to the inbound resolver endpoint IPs.
On-premises servers route DNS queries for AWS domains over Direct Connect to AWS.
This establishes outbound DNS resolution from the datacenter to AWS.
3
Authorize the spoke VPCs to associate with the `aws.logistics.local` Private Hosted Zone (PHZ) from the Shared Services account.
The target spoke VPCs in the member accounts are authorized to establish cross-account associations with the PHZ.
VPCs in other member accounts cannot resolve resources in a PHZ owned by another account without explicit cross-account authorization.
4
Associate the spoke VPCs with the authorized PHZ from the member accounts.
Instances in the spoke VPCs can now resolve DNS records within the `aws.logistics.local` zone.
This completes the cross-account PHZ association process.

Key Concept

Cross-Account Private Hosted Zone Association and Hybrid Route 53 Inbound Resolution
Question 817Question →

An enterprise is designing a highly available, multi-account hybrid network architecture. The architecture consists of a Shared Services AWS account and 5050 spoke VPCs deployed across 33 Availability Zones (AZs) in the us-east-1 Region. The Shared Services account hosts a central Route 53 Private Hosted Zone (PHZ) for internal service discovery. The enterprise requires secure, transitive routing between the spoke VPCs and its on-premises data center, which will be connected via a 10 Gbps10\text{ Gbps} AWS Direct Connect connection with a backup AWS Site-to-Site VPN. Additionally, all outbound internet traffic from the spoke VPCs must be routed through a centralized egress VPC in the Shared Services account for security inspection. The solution must ensure high availability across all AZs, support internal DNS resolution, and prevent single points of failure. Which of the following designs meets these requirements?

Show answer & explanation

Answer: Deploy an AWS Transit Gateway in the Shared Services account and share it with the spoke VPC accounts using AWS Resource Access Manager (RAM). Attach the spoke VPCs and the centralized egress VPC to the Transit Gateway. In the egress VPC, deploy redundant NAT Gateways across all 33 Availability Zones and route internet-bound traffic through them. Associate the Route 53 Private Hosted Zone in the Shared Services account with all 5050 spoke VPCs. Attach the Direct Connect connection via a transit virtual interface (transit VIF) to a Direct Connect Gateway (DXGW) associated with the Transit Gateway, and establish a backup Site-to-Site VPN connection attached directly to the Transit Gateway.

Answer

The configuration utilizing AWS Transit Gateway shared via RAM, redundant NAT Gateways across all Availability Zones in the egress VPC, Route 53 Private Hosted Zone associated with all 5050 spoke VPCs, and a Direct Connect Gateway using a transit VIF with a backup VPN attached directly to the Transit Gateway.
AWS Transit Gateway acts as a central hub to connect multiple VPCs and on-premises networks, enabling transitive routing. By sharing it via AWS Resource Access Manager (RAM), all spoke VPCs can attach to it. Redundant NAT Gateways across all 33 Availability Zones in the egress VPC guarantee high availability. Explicitly associating the Route 53 Private Hosted Zone with all 5050 spoke VPCs ensures they can resolve DNS queries. Connecting the Direct Connect via a transit VIF to a DXGW associated with the Transit Gateway, alongside a backup Site-to-Site VPN, provides a highly available hybrid network with automatic failover.

Step-by-Step Solution

1
Determine the transitive routing model for the 5050 spoke VPCs and the hybrid connection.
Select AWS Transit Gateway shared via AWS Resource Access Manager (RAM) to allow multi-account spoke VPCs to communicate with each other and the on-premises environment.
AWS Transit Gateway acts as a cloud router, supporting transitive spoke-to-spoke and hybrid routing, which is not supported by Direct Connect Gateway alone.
2
Design the centralized egress path for outbound internet traffic.
Route outbound traffic from the spoke VPCs through the Transit Gateway to a centralized egress VPC containing redundant NAT Gateways deployed across all 33 Availability Zones.
Redundant NAT Gateways across Availability Zones prevent a single Availability Zone outage from disrupting outbound internet access for the entire network.
3
Configure DNS resolution for the Private Hosted Zone (PHZ) in the multi-account architecture.
Explicitly associate the Route 53 PHZ in the Shared Services account with all 5050 spoke VPCs.
Transit Gateway does not route DNS resolution queries transitively; each VPC must be associated with the PHZ to resolve its DNS records.
4
Establish high-availability hybrid connectivity with failover.
Attach the Direct Connect connection via a transit virtual interface (transit VIF) to a DXGW associated with the Transit Gateway, and establish a backup Site-to-Site VPN connection directly to the Transit Gateway.
Transit VIF is required to connect Direct Connect to a Transit Gateway, and the VPN provides a cost-effective, high-availability backup path.

Key Concept

Hybrid and Multi-Account Network Connectivity Design
Question 818Question →

A global commercial aviation company is designing a new flight operations dispatch platform. The application tier runs on Amazon EC2 instances in an Auto Scaling group behind an Application Load Balancer (ALB). The application requires outbound internet access to retrieve real-time weather feeds. Internal microservices communicate using a Private Hosted Zone (PHZ) named `dispatch.internal`. The database tier uses Amazon Aurora PostgreSQL. The primary deployment is in `us-east-1`. The company requires a disaster recovery (DR) architecture in `us-west-2` that is highly available across multiple Availability Zones in both regions. The DR plan must meet a Recovery Time Objective (RTO) of 15 minutes15\text{ minutes} and a Recovery Point Objective (RPO) of 1 minute1\text{ minute}, while minimizing ongoing costs. During normal operations, all user traffic must be routed to `us-east-1`. Which design strategy meets these requirements?

Show answer & explanation

Answer: Provision an Amazon Aurora Global Database with the primary cluster in `us-east-1` and a secondary cluster in `us-west-2`. In both regions, deploy NAT Gateways in each Availability Zone used by the application. Link the `dispatch.internal` Private Hosted Zone with the VPCs in both regions. Configure a Route 53 Failover routing policy with an active record pointing to the `us-east-1` ALB and a passive record pointing to the `us-west-2` ALB, associated with Route 53 active health checks. Set the `us-west-2` Auto Scaling group minimum capacity to 22.

Answer

The correct strategy uses Amazon Aurora Global Database for cross-region replication, deploys NAT Gateways in all Availability Zones of both regions, associates the internal Private Hosted Zone with both VPCs, uses Route 53 Failover routing with health checks, and configures the secondary Auto Scaling group with a minimum capacity of 2.
The correct strategy utilizes Amazon Aurora Global Database to achieve near-zero replication lag, satisfying the 1-minute RPO. The secondary database cluster can be promoted in less than 15 minutes, satisfying the RTO. Route 53 Failover routing ensures all traffic goes to the primary region under normal circumstances and automatically redirects to the backup region if the primary health checks fail. Deploying NAT Gateways in every Availability Zone in both regions prevents outbound connectivity from becoming a single point of failure in either region. Finally, associating the internal Private Hosted Zone with both VPCs ensures that microservices can resolve internal names regardless of which region is active.

Step-by-Step Solution

1
Evaluate the database replication strategy to satisfy the Recovery Point Objective (RPO) of 1 minute1\text{ minute} and Recovery Time Objective (RTO) of 15 minutes15\text{ minutes}.
Amazon Aurora Global Database provides sub-second physical replication lag and allows secondary cluster promotion in under 15 minutes15\text{ minutes}. Snapshot-based restore options fail both constraints.
An RPO of 1 minute1\text{ minute} necessitates continuous database replication, while an RTO of 15 minutes15\text{ minutes} makes snapshot restoration models too slow.
2
Analyze internal DNS name resolution behavior across AWS Regions.
Confirm that the internal Private Hosted Zone must be associated with VPCs in both regions, as Route 53 Private Hosted Zones do not automatically share resolution boundaries transitively over peered VPC networks.
Correct internal resolution of microservices in the secondary region requires explicit Private Hosted Zone association.
3
Ensure outbound connectivity infrastructure is highly available across Availability Zones.
Provision NAT Gateways in each Availability Zone of both regions rather than using a single NAT Gateway in the secondary region.
High availability requires removing single points of failure, meaning each active Availability Zone must have its own path to the internet.
4
Configure the DNS routing policy to ensure proper active-passive failover transitions.
Select Route 53 Failover routing with active health checks to direct all user traffic to the primary region during normal operations.
Latency-based routing does not guarantee a strict active-passive traffic flow as specified by the business constraints.

Key Concept

High Availability and Disaster Recovery Design
Estimated Time:3m 0s
Question 819Question →

An enterprise manages a microservices application hosted on Amazon ECS with AWS Fargate behind an Application Load Balancer (ALB). The infrastructure is managed using AWS CloudFormation. The team needs to implement a deployment strategy for new service versions that routes 10% of traffic to the new version, monitors the application for 15 minutes using a CloudWatch alarm tracking HTTP 5XX response codes, and automatically rolls back to the previous version with zero downtime if the alarm triggers. If no alarms are triggered, all traffic must transition to the new version. The entire deployment strategy and workflow must be defined as Infrastructure as Code within the CloudFormation template. Which design meets these requirements?

Show answer & explanation

Answer: Add the AWS::CodeDeployBlueGreen transform to the CloudFormation template. Configure the template with blue and green target groups, and define an AWS::ECS::Service resource. Specify the CodeDeployDefault.ECSCanary10Percent15Minutes deployment configuration and the CloudWatch alarm as a rollback trigger in the BlueGreenDeployment properties of the template.

Answer

Configure the CloudFormation template using the AWS::CodeDeployBlueGreen transform, defining the BlueGreenDeployment properties with the CodeDeployDefault.ECSCanary10Percent15Minutes deployment configuration and linking the CloudWatch alarm to the deployment group.
The correct option utilizes the native AWS::CodeDeployBlueGreen transform in AWS CloudFormation. This transform automates the blue/green deployment process on Amazon ECS by delegating the deployment execution to AWS CodeDeploy. By configuring the BlueGreenDeployment section with the CodeDeployDefault.ECSCanary10Percent15Minutes deployment configuration and linking the CloudWatch alarm, CodeDeploy manages the traffic shift (10% to green, then 90% after 15 minutes) and monitors the alarm. If the alarm triggers, CodeDeploy immediately and safely rolls back the traffic to the blue target group, satisfying all zero-downtime, automation, and Infrastructure as Code requirements.

Step-by-Step Solution

1
Use the AWS::CodeDeployBlueGreen transform at the top of the CloudFormation template.
Enables CloudFormation to perform blue/green and canary deployments for ECS services by generating the necessary CodeDeploy resources under the hood.
Allows native integration between CloudFormation stack updates and CodeDeploy ECS deployments.
2
Define the blue and green target groups, the production and test ALB listeners, and the AWS::ECS::Service resource in the template.
Establishes the traffic routing endpoints and container configuration required for blue/green shifting.
CodeDeploy needs distinct target groups and listeners to manage traffic redirection between the old (blue) and new (green) versions.
3
Specify the CodeDeployDefault.ECSCanary10Percent15Minutes configuration and the CloudWatch rollback alarm in the BlueGreenDeployment properties of the template.
Automates the 10% canary traffic shift and configures CodeDeploy to monitor the alarm for 15 minutes before completing the deployment or triggering an immediate rollback.
Fulfills the business requirement of canary shifting, duration-based monitoring, and automated rollback.

Key Concept

Orchestrating canary deployments on Amazon ECS through AWS CloudFormation using the AWS::CodeDeployBlueGreen transform.
Question 820Question →

A medical device company is designing a disaster recovery (DR) architecture for a critical patient monitoring application on AWS. The application runs on Amazon EC2 instances in private subnets across multiple Availability Zones in us-east-1 and must connect to external healthcare registries over the internet to update records. The database tier requires an Amazon Aurora PostgreSQL database. The business requires a Recovery Time Objective (RTO) of less than 15 minutes, a Recovery Point Objective (RPO) of less than 1 minute, and high availability for outbound connectivity within each region. Which of the following designs meets these requirements with the lowest operational overhead?

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 both regions, deploy the EC2 instances across multiple Availability Zones and deploy a NAT Gateway in each Availability Zone. Configure Amazon Route 53 with an Active-Passive Failover routing policy using health checks linked to the Application Load Balancer in each region, and promote the secondary Aurora cluster during a failover.

Answer

Deploy Amazon Aurora Global Database with the primary cluster in us-east-1 and a secondary cluster in us-west-2. In both regions, deploy the EC2 instances across multiple Availability Zones and deploy a NAT Gateway in each Availability Zone. Configure Amazon Route 53 with an Active-Passive Failover routing policy using health checks linked to the Application Load Balancer in each region, and promote the secondary Aurora cluster during a failover.
The correct design utilizes Amazon Aurora Global Database to achieve near-zero RPO (asynchronous replication is fast and storage-based) and meets the RTO of under 15 minutes through promotion of the secondary cluster in the recovery region. To maintain high availability for outbound connectivity (required to connect to external registries), a NAT Gateway is deployed in each Availability Zone in both regions. This prevents a single AZ outage from interrupting outbound internet connectivity for the surviving AZs within a region. Lastly, Route 53 Failover routing records point to the local Application Load Balancers, routing traffic to the primary region during normal operations and failing over to the secondary region during a disaster.

Step-by-Step Solution

1
Determine the database configuration needed to support RPO < 1 minute and RTO < 15 minutes across regions.
Amazon Aurora Global Database provides storage-based asynchronous replication with sub-second RPO, and the secondary cluster can be promoted in a few minutes, satisfying both targets.
Standard Backup and Restore methods do not meet these tight RTO and RPO limits.
2
Evaluate the outbound connectivity high availability requirements.
Deploying a NAT Gateway in each Availability Zone of the VPC ensures that an Availability Zone outage does not disrupt outbound internet access for resources in other Availability Zones.
A single NAT Gateway per region is a single point of failure.
3
Define the DNS routing mechanism for cross-region disaster recovery.
Use Amazon Route 53 with an Active-Passive Failover routing policy, associating health checks with the primary region Application Load Balancer to automatically detect health degradation.
This setup dynamically routes user traffic to the secondary region when the primary region is determined to be unhealthy.

Key Concept

Multi-region disaster recovery using Amazon Aurora Global Database and Route 53 Failover routing while maintaining multi-AZ NAT Gateway redundancy.
PreviousPage 41 / 99Next
All practice questions — AWS Certified Solutions Architect - Professional | Examkin