Examkin

All practice questions

1964 questions

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

A logistics company is designing its AWS Organizations multi-account structure. To enforce compliance, the security team requires that in all development member accounts:
1. Developers must not be able to delete any Amazon S3 buckets.
2. Developers must not be able to delete or modify the configuration of the centralized IT security roles (which are named with a 'SecurityAdmin-' prefix).
3. Developers must still be able to create and manage their own test S3 buckets and IAM roles for daily tasks.
The company uses AWS IAM Identity Center to federate developer access.
Which solution should a solutions architect implement to meet these requirements with the least operational overhead?

Show answer & explanation

Answer: Attach a Service Control Policy (SCP) to the Development Organizational Unit (OU) that denies the 's3:DeleteBucket' action on all resources, and denies IAM role modification and deletion actions if the resource path matches 'arn:aws:iam::*:role/SecurityAdmin-*'. Configure the developers' IAM Identity Center permission sets to allow S3 and IAM administrative actions.

Answer

The correct solution is to attach a Service Control Policy (SCP) to the Development Organizational Unit (OU) that denies bucket deletion globally and restricts modification of roles with the 'SecurityAdmin-' prefix, while using IAM Identity Center permission sets to grant developers active permissions to manage S3 and IAM.
The correct solution uses an SCP to restrict the deletion of S3 buckets and modification of specific IAM roles starting with 'SecurityAdmin-' across the member accounts in the Development OU. Because SCPs do not grant permissions, the developers' active permissions to create and manage their resources are assigned via IAM Identity Center permission sets.

Step-by-Step Solution

1
Define a Service Control Policy (SCP) to centrally enforce security guardrails across the Organizational Unit (OU).
A policy is defined that denies 's3:DeleteBucket' on all resources and denies write actions on IAM roles matching 'arn:aws:iam::*:role/SecurityAdmin-*'.
SCPs are the most operationally efficient tool to restrict permissions across member accounts without managing policies in each account individually.
2
Associate the SCP with the Development OU.
The policy is inherited by all development member accounts in that OU.
This ensures consistent application of the guardrail to all current and future accounts under the OU.
3
Configure developer permissions in IAM Identity Center.
Permission sets allow developers to perform daily tasks like creating S3 buckets and managing non-security IAM roles.
SCPs do not grant permissions, so local IAM permissions must still be granted for the developers to perform their duties.

Key Concept

Multi-Account Governance using Service Control Policies (SCPs) and IAM Identity Center
Estimated Time:2m 0s
Question 622Question →

An enterprise is designing a secure hybrid and multi-account network topology. The architecture consists of 1010 spoke VPCs distributed across 22 AWS accounts in the `eu-west-1` Region, and a Shared Services VPC in a central account. Hybrid connectivity to the on-premises datacenter is established via AWS Direct Connect using an AWS Transit Gateway.

The configuration must satisfy the following requirements:
- All spoke VPCs must be able to communicate with the on-premises datacenter.
- Spoke VPCs must not be able to communicate with each other.
- All spoke VPCs must be able to resolve domain names in a Route 53 Private Hosted Zone (`aws.internal`) hosted in the Shared Services account.

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

Select all that apply

Show answer & explanation

Answer: Configure two Transit Gateway route tables: associate the spoke VPC attachments with a route table that routes traffic only to the Direct Connect Gateway attachment, and associate the Direct Connect Gateway attachment with a route table that has propagations enabled for all spoke VPC attachments.; Authorize and associate the Route 53 Private Hosted Zone in the Shared Services account with each of the spoke VPCs in the consumer accounts.

Answer

To meet the requirements, the Solutions Architect must configure two Transit Gateway route tables (one for spokes routing to the Direct Connect Gateway without propagation, and one for the Direct Connect Gateway propagating spoke routes) and authorize/associate the Route 53 Private Hosted Zone from the Shared Services account with each spoke VPC.
To restrict inter-spoke communication while allowing spoke-to-on-premises traffic, a hub-and-spoke routing isolation pattern is used with two Transit Gateway route tables. Spoke VPC attachments are associated with a route table that only has a route to the Direct Connect Gateway. The Direct Connect Gateway attachment is associated with a route table that propagates routes from the spoke VPCs, allowing return traffic. For DNS resolution, a Private Hosted Zone cannot be shared via AWS Resource Access Manager (RAM); instead, cross-account association authorization must be created, allowing each spoke VPC to be associated with the Private Hosted Zone directly.

Step-by-Step Solution

1
Create a Transit Gateway route table for spoke VPCs and associate the spoke attachments to it. Add a route pointing to the Direct Connect Gateway attachment to allow outbound traffic to on-premises. Do not enable propagation from spoke VPCs to this table to prevent inter-spoke routing.
Spokes can route traffic to on-premises but remain isolated from one another.
This establishes the outbound path of the hub-and-spoke isolation model.
2
Create a second Transit Gateway route table for the Direct Connect Gateway attachment, and enable route propagation for all spoke VPC attachments.
On-premises return traffic is successfully routed back to the appropriate spoke VPC.
This establishes the inbound path of the hub-and-spoke isolation model.
3
Authorize cross-account VPC association for the Route 53 Private Hosted Zone in the Shared Services account using the AWS CLI or SDK, and then associate the private hosted zone with each of the spoke VPCs in the consumer accounts.
All spoke VPCs can resolve DNS queries for the private hosted zone directly.
Private Hosted Zones do not support sharing via AWS RAM and require explicit cross-account VPC association.

Key Concept

Hub-and-spoke network routing isolation with AWS Transit Gateway and cross-account Route 53 Private Hosted Zone association.
Estimated Time:2m 0s
Question 623Question →

An enterprise is establishing a multi-region landing zone using AWS Organizations and AWS Control Tower to govern a rapidly growing portfolio of application accounts. The solutions architect must establish a secure multi-account structure, centralize security operations, apply service control policies (SCPs), and configure automated account provisioning. In what sequence should the solutions architect perform these setup steps to establish the environment while maintaining operational security and ensuring all new accounts are compliant upon creation?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence begins with provisioning the landing zone using AWS Control Tower, followed by enabling AWS IAM Identity Center for administrative access, delegating security administration to the Audit account, attaching custom Service Control Policies (SCPs) to organizational units, and finally configuring the Account Factory Customizer for automated account provisioning.
Establishing the AWS landing zone must follow a strict dependencies-first approach. First, the management account must initialize AWS Control Tower to spin up the Security OU along with the Log Archive and Audit accounts. Second, federated access via AWS IAM Identity Center is configured to secure cross-account administration. Third, security and compliance administration is delegated to the Audit account. Fourth, custom SCPs are attached to the OUs to define strict guardrails. Finally, the Account Factory Customizer is configured to automate compliant workload provisioning.

Step-by-Step Solution

1
Provision the landing zone via AWS Control Tower.
Creates the Log Archive account, Audit account, and Security OU.
Establishes the multi-account structure and core AWS accounts required by all subsequent setup steps.
2
Enable and configure AWS IAM Identity Center.
Establishes federated user access and administrative roles mapped to identity groups.
Allows secure administrative access to core security and member accounts without utilizing root credentials or local IAM users.
3
Delegate administration of security services to the Audit account.
Centralizes compliance monitoring, security findings, and AWS Config aggregation in the Audit account.
Adheres to the principle of least privilege by separating security monitoring duties from management account operations.
4
Author and attach Service Control Policies (SCPs) to parent OUs.
Applies top-down guardrails restricting AWS regions and preventing security service disabling.
Establishes a hardened governance boundary that applies automatically to existing and future member accounts.
5
Configure AWS Control Tower Account Factory Customizer.
Enables automated deployment of baseline networking (VPCs) and local configurations.
Ensures that newly provisioned workload accounts are compliant from day one by deploying them under established guardrails.

Key Concept

AWS multi-account governance setup lifecycle using AWS Control Tower, IAM Identity Center, delegated administration, Service Control Policies, and Account Factory automation.
Question 624Question →

An automotive manufacturing corporation uses AWS Organizations to manage its multi-account environment. A central Transit Gateway in a dedicated Network Services account connects the on-premises factory network (domain `factory.internal`) and multiple Line-of-Business (LOB) VPCs in separate member accounts. A Private Hosted Zone (PHZ) named `corp.internal` is hosted in a Shared Services account. The corporation requires a hybrid DNS strategy that allows systems in the LOB VPCs to resolve resources in the `factory.internal` domain, systems in the LOB VPCs to resolve resources in the `corp.internal` PHZ, and on-premises factory systems to resolve resources in the `corp.internal` PHZ. Which configuration meets these requirements with the least administrative effort and cost?

Show answer & explanation

Answer: Create Route 53 Resolver inbound endpoints in the Network Services VPC. Configure on-premises DNS servers to forward queries for `corp.internal` to the inbound endpoint IP addresses. Authorize and associate the `corp.internal` PHZ in the Shared Services account with the LOB VPCs. Create a Route 53 Resolver outbound endpoint in the Network Services VPC, configure an outbound rule for `factory.internal` pointing to on-premises DNS servers, share the rule via AWS Resource Access Manager (RAM), and associate it with all LOB VPCs.

Answer

The correct configuration is to create Route 53 Resolver inbound endpoints in the Network Services VPC for on-premises resolution, authorize and associate the `corp.internal` Private Hosted Zone with the Line-of-Business VPCs across accounts, and create a Route 53 Resolver outbound endpoint in the Network Services VPC with a shared outbound rule for `factory.internal`.
The correct configuration leverages Route 53 Resolver inbound endpoints to allow on-premises systems to resolve AWS-hosted resources. Since Route 53 Private Hosted Zones (PHZs) are not automatically transitively accessible over Transit Gateway, they must be associated with each VPC that needs to resolve them. Using a centralized Route 53 Resolver outbound endpoint in the Network Services VPC, coupled with outbound rules shared via AWS Resource Access Manager (RAM), allows all LOB VPCs to resolve on-premises names with minimal configuration and cost.

Step-by-Step Solution

1
Enable on-premises resolution of AWS-hosted resources by creating Route 53 Resolver inbound endpoints.
On-premises DNS servers can forward queries for the `corp.internal` zone to the inbound endpoint IP addresses.
Inbound endpoints act as the entry point for DNS queries originating from outside the AWS network.
2
Configure cross-account Private Hosted Zone (PHZ) association for the Line-of-Business (LOB) VPCs.
The LOB VPCs can directly resolve names in `corp.internal` using local VPC resolver endpoints.
VPC DNS resolution is isolated; a PHZ must be explicitly associated with each VPC that needs to resolve its records.
3
Deploy a central Route 53 Resolver outbound endpoint and configure outbound forwarding rules.
An outbound rule for `factory.internal` is shared via AWS Resource Access Manager (RAM) and associated with the LOB VPCs.
Sharing a single set of outbound rules from a centralized network account reduces endpoint costs and simplifies administration.

Key Concept

Centralized hybrid DNS architecture using Route 53 Resolver endpoints and cross-account Private Hosted Zone association.
Estimated Time:2m 0s
Question 625Question →

A company runs a critical web application on AWS with a primary deployment in the us-east-1 Region. The company wants to establish a disaster recovery (DR) solution in the us-west-2 Region. The application requires a Recovery Time Objective (RTO) of less than 15 minutes and a Recovery Point Objective (RPO) of less than 5 minutes. The solution must minimize monthly running costs. Which DR architecture should a solutions architect recommend to meet these requirements?

Show answer & explanation

Answer: Implement a Warm Standby DR pattern. Deploy a scaled-down fleet of application instances in the us-west-2 Region. Replicate the database to us-west-2 using Amazon Aurora Global Database. Configure Amazon Route 53 active-passive failover routing with health checks to automatically redirect traffic to us-west-2 if the primary Region becomes unhealthy.

Answer

Implement a Warm Standby DR pattern with scaled-down instances in us-west-2, database replication using Amazon Aurora Global Database, and Amazon Route 53 active-passive failover routing with health checks.
The correct answer is the Warm Standby DR pattern. A Warm Standby pattern meets the 15-minute RTO requirement by having a scaled-down fleet of application instances already running in the recovery Region, allowing them to scale up quickly. Amazon Aurora Global Database provides cross-region replication with an RPO of under 1 second, satisfying the 5-minute RPO requirement. Amazon Route 53 failover routing with health checks ensures that traffic is automatically redirected to the secondary Region when the primary Region's endpoints fail.

Step-by-Step Solution

1
Analyze RTO and RPO requirements
An RTO of less than 15 minutes rules out Backup and Restore, while an RPO of less than 5 minutes requires continuous cross-region database replication.
To identify which DR architectures can meet the time-bound objectives.
2
Evaluate the database replication options
Amazon Aurora Global Database provides cross-region replication with sub-second lag, while Amazon RDS Multi-AZ does not replicate across Regions.
To select a valid cross-region database replication mechanism that meets the RPO constraint.
3
Assess Route 53 routing policies and cost constraints
Active-passive failover routing with health checks redirects traffic within minutes, meeting the RTO. Running a scaled-down application fleet in the standby region minimizes running costs compared to a fully scaled active-active setup.
To ensure traffic redirection is automated and complies with the cost optimization constraint.

Key Concept

Disaster recovery strategy selection (Warm Standby vs. Backup & Restore) and DNS failover configuration based on RTO and RPO constraints.
Question 626Question →

An enterprise is implementing identity federation using an external SAML 2.0 Identity Provider (IdP) to enable single sign-on (SSO) to multiple member accounts within their AWS Organization. The solutions architect configures a SAML provider object in each member account and creates an IAM role named 'FederatedOperationsRole' in those accounts. However, when users attempt to federate into the member accounts from the IdP portal, they receive an error indicating that they are not authorized to perform the assume role action. Which of the following configurations is required in the trust policy of the 'FederatedOperationsRole' in the member accounts to resolve this issue?

Show answer & explanation

Answer: Define the Principal as the Amazon Resource Name (ARN) of the SAML provider created in the member account, and set the Action to sts:AssumeRoleWithSAML.

Answer

Define the Principal as the Amazon Resource Name (ARN) of the SAML provider created in the member account, and set the Action to sts:AssumeRoleWithSAML.
To successfully federate using SAML 2.0, the IAM role trust policy in the target member account must trust the SAML provider. This is accomplished by setting the Principal to the ARN of the SAML provider created in the account and specifying the Action as sts:AssumeRoleWithSAML. This allows the AWS STS service to accept the SAML assertion and issue temporary security credentials.

Step-by-Step Solution

1
Identify the authentication protocol being used.
The scenario specifies SAML 2.0 identity federation.
Choosing the correct API call depends on whether SAML 2.0 or OIDC/Web Identity is used.
2
Verify the correct Security Token Service (STS) action for SAML 2.0.
The correct action is sts:AssumeRoleWithSAML.
AWS Security Token Service provides specialized actions for different federation types.
3
Configure the trust policy Principal field.
Set the Principal to the Federated provider ARN of the local SAML provider.
This establishes a trust relationship between the IAM role and the external identity provider.

Key Concept

SAML 2.0 Federation Trust Relationships
Estimated Time:2m 0s
Question 627Question →

An enterprise is deploying a mission-critical consumer portal on AWS across two Regions: eu-west-1 (primary) and ap-southeast-1 (secondary). The architecture requires a Recovery Time Objective (RTO) of 15 minutes and a Recovery Point Objective (RPO) of 1 minute. The database tier must run on Amazon Aurora PostgreSQL. To achieve high availability, outbound traffic from private subnets in both Regions to external SaaS providers must have no single point of failure within each Region. For internal service discovery, the application components use a Route 53 Private Hosted Zone (PHZ) named internal.example.com hosted in the primary Region's VPC. Which combination of architectural decisions meets these requirements?

Show answer & explanation

Answer: Deploy Amazon Aurora Global Database with the primary cluster in eu-west-1 and a secondary cluster in ap-southeast-1. Deploy a NAT Gateway in each Availability Zone in both VPCs. Associate the Route 53 Private Hosted Zone internal.example.com with both the eu-west-1 VPC and the ap-southeast-1 VPC.

Answer

Deploying Amazon Aurora Global Database with a primary cluster in the primary region and a secondary cluster in the failover region meets the low RTO and RPO requirements. Highly available outbound traffic is ensured by deploying a NAT Gateway in each Availability Zone within each VPC, removing single points of failure. Associating the Route 53 Private Hosted Zone with both VPCs guarantees name resolution works locally in both environments.
The correct solution meets all constraints: Aurora Global Database satisfies the 1-minute RPO and 15-minute RTO through low-latency replication and managed failovers; deploying a NAT Gateway per Availability Zone removes the single point of failure for outbound traffic; and associating the Private Hosted Zone with both VPCs ensures that service discovery DNS names resolve successfully in both Regions.

Step-by-Step Solution

1
Analyze the database RTO and RPO constraints.
The RPO is 1 minute and the RTO is 15 minutes. A cross-Region backup-and-restore strategy using daily snapshots cannot achieve an RPO of 1 minute or an RTO of 15 minutes. Aurora Global Database uses storage-based replication with a replication lag typically under 1 second, and supports managed planned failovers within a few minutes, satisfying both targets.
To select the appropriate disaster recovery pattern based on defined business limits.
2
Evaluate the outbound connectivity requirements for private subnets.
To ensure there is no single point of failure for outbound SaaS communication within a Region, a NAT Gateway must be provisioned in each Availability Zone where resources reside. If a single NAT Gateway is shared across multiple Availability Zones, an outage in that specific zone would sever outbound internet access for all private subnets.
To design redundant outbound network pathing within each Region's VPC architecture.
3
Determine the Route 53 Private Hosted Zone (PHZ) configuration.
Route 53 Private Hosted Zones resolve queries only for associated VPCs. To resolve internal domain names in both VPCs, the PHZ must be explicitly associated with the VPCs in both Regions.
To ensure service discovery names resolve correctly and locally within both VPC environments.

Key Concept

Multi-Region High Availability and Disaster Recovery Design with Aurora Global Database, Private Hosted Zones, and NAT Gateway redundancy.
Question 628Question →

An enterprise manages its multi-account AWS environment using AWS Organizations. The environment consists of a Management account, a Core-Network OU, a Production OU, and a Development OU. The Core-Network OU contains a Shared-VPC account where VPC subnets are shared with the Production and Development OUs using AWS Resource Access Manager (RAM).

The workloads in the Production OU consist of a mixture of Amazon EC2 instances, AWS Lambda functions, and Amazon ECS tasks running on AWS Fargate. These workloads mount Amazon EFS file systems that are located in the Shared-VPC account and must be encrypted at rest.

The finance team wants to reduce compute costs for the Production OU workloads using Savings Plans, but wants to ensure that these discount benefits are never applied to the Development OU.

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

Select all that apply

Show answer & explanation

Answer: Purchase Compute Savings Plans in the Production OU member accounts, and disable Savings Plans sharing in the Billing Preferences of the Management account.; Create a Customer Managed Key (CMK) in the Shared-VPC account to encrypt the EFS file systems, and configure its key policy to allow the IAM roles in the Production OU accounts to perform KMS decrypt and generate data key operations.

Answer

Purchase Compute Savings Plans in the Production OU member accounts and disable Savings Plans sharing in the Billing Preferences of the Management account; and create a Customer Managed Key (CMK) in the Shared-VPC account to encrypt the EFS file systems, configuring its key policy to allow the IAM roles in the Production OU accounts to use the key.
Purchasing Compute Savings Plans directly in the Production OU accounts and disabling sharing in the Management account ensures that only the production workloads benefit from the savings. Additionally, using a Customer Managed Key (CMK) with a cross-account key policy allows the ECS Fargate tasks in the Production OU accounts to mount and access the encrypted EFS file systems created in the shared VPC subnets.

Step-by-Step Solution

1
Select the correct Savings Plan type for the heterogeneous compute workload.
Compute Savings Plans are selected because they cover EC2, AWS Lambda, and AWS Fargate, whereas EC2 Instance Savings Plans only cover EC2.
The production workload includes Lambda and Fargate in addition to EC2, requiring the flexible Compute Savings Plans.
2
Isolate the Savings Plans benefits to the Production OU.
Savings Plans sharing is disabled in the Billing Preferences of the Management account, and the Compute Savings Plans are purchased directly within the Production OU member accounts.
By default, Savings Plans benefits are shared across all accounts in the Organization. Disabling sharing ensures they only apply to the account that purchased them.
3
Establish cross-account encryption capability for shared EFS file systems.
A Customer Managed Key (CMK) is created in the Shared-VPC account, and its key policy is configured to trust the application IAM roles in the Production OU.
AWS-managed keys cannot be shared across accounts because their key policies cannot be modified. A CMK must be used to delegate cross-account access.

Key Concept

To share encrypted resources across accounts in an AWS Organization, a Customer Managed Key (CMK) must be used because AWS-managed keys cannot be shared. To prevent Savings Plans benefits from applying to specific accounts, Savings Plans sharing must be disabled in the Management account, and the plans must be purchased directly in the targeted accounts.
Question 629Question →

A shipping company is designing a disaster recovery (DR) solution for its package tracking application across two AWS Regions: us-east-1 (primary) and us-west-2 (secondary). The company requires a Recovery Point Objective (RPO) of 15 minutes and a Recovery Time Objective (RTO) of 30 minutes, while minimizing baseline infrastructure costs. The primary database must be replicated to the secondary region. Which disaster recovery strategy and Route 53 routing configuration should the solutions architect select?

Show answer & explanation

Answer: A Pilot Light strategy with Amazon Aurora Global Database replicating data to the secondary region, using Route 53 Failover routing to direct user traffic during a disaster.

Answer

The Pilot Light strategy using Amazon Aurora Global Database for replication combined with Route 53 Failover routing meets the RPO, RTO, and cost-optimization requirements.
The Pilot Light strategy with Amazon Aurora Global Database meets the 15-minute RPO requirement because Aurora Global Database replicates data across regions with latency typically under a second. The 30-minute RTO allows enough time to spin up application servers in the secondary region when a disaster is declared, while keeping compute costs minimal during normal operations. Route 53 Failover routing is the standard policy for active-passive disaster recovery configurations.

Step-by-Step Solution

1
Analyze RPO and cost constraints to select the disaster recovery strategy.
An RPO of 15 minutes requires continuous or near-continuous database replication, which rules out backup and restore with nightly/hourly snapshots. Minimizing baseline costs rules out Warm Standby and Active-Active strategies, indicating that a Pilot Light strategy is the most suitable pattern.
The Pilot Light strategy keeps database replication active (sub-second RPO) while keeping application compute resources turned off or at zero capacity until a failover occurs, minimizing costs.
2
Analyze RTO constraints to ensure application resource provisioning is feasible.
An RTO of 30 minutes allows sufficient time to launch application servers (e.g., via Auto Scaling groups or CloudFormation templates) in the secondary region during failover.
Since the compute resources are not running during normal operations, the recovery process must fit within the 30-minute window.
3
Select the appropriate Route 53 routing policy for active-passive disaster recovery.
Route 53 Failover routing must be configured to point to the primary region as active and the secondary region as passive.
Active-passive failover routing automatically directs public traffic to the secondary region if Route 53 health checks determine that the primary region's endpoints are unhealthy.

Key Concept

Disaster Recovery Patterns and Route 53 Routing Policies
Question 630Question →

A multinational logistics enterprise is designing a hybrid network architecture for its multi-account environment on AWS. The setup consists of 2020 spoke VPCs in the `us-east-1` Region, all connected via an AWS Transit Gateway (TGW). The primary hybrid connection is a 10 Gbps10\text{ Gbps} AWS Direct Connect (DX) connection terminating at an on-premises data center, routed via a Direct Connect Gateway (DXGW) associated with the TGW. A backup 1.25 Gbps1.25\text{ Gbps} AWS Site-to-Site VPN is established between the on-premises data center and the TGW. The spoke VPCs also require highly available outbound internet access routed through a centralized Shared Services VPC. During initial testing, the operations team observes that outbound traffic from AWS to the on-premises network correctly prefers the Direct Connect path. However, inbound traffic from the on-premises network to the spoke VPCs is routed over the backup VPN connection, causing asymmetric routing and firewall packet drops. Additionally, all internet-bound traffic from the spoke VPCs is currently routed through a single NAT Gateway in the Shared Services VPC. Which combination of actions should the Solutions Architect take to resolve the routing asymmetry and ensure a highly available egress architecture?

Show answer & explanation

Answer: Configure the on-premises edge routers to assign a higher BGP local preference attribute to the prefixes received from AWS over the Direct Connect connection compared to the Site-to-Site VPN. In the Shared Services VPC, deploy a NAT Gateway in each Availability Zone where Transit Gateway attachments are present. Configure the subnet route tables containing the Transit Gateway attachments in the Shared Services VPC to route outbound 0.0.0.0/00.0.0.0/0 traffic to the NAT Gateway in the same Availability Zone.

Answer

Configure the on-premises edge routers to assign a higher BGP local preference attribute to the prefixes received from AWS over the Direct Connect connection compared to the Site-to-Site VPN. In the Shared Services VPC, deploy a NAT Gateway in each Availability Zone where Transit Gateway attachments are present. Configure the subnet route tables containing the Transit Gateway attachments in the Shared Services VPC to route outbound traffic to the NAT Gateway in the same Availability Zone.
The correct solution addresses both the hybrid routing asymmetry and the egress high availability requirements. By default, AWS Transit Gateway prefers Direct Connect paths over VPN paths for outbound traffic. To resolve the inbound asymmetry, the on-premises network must be configured to prefer the Direct Connect path when sending traffic to AWS. Configuring a higher BGP local preference on the on-premises edge routers for prefixes received via Direct Connect achieves this. For the egress path, deploying NAT Gateways in multiple Availability Zones and configuring Transit Gateway attachment subnets to route traffic to the local NAT Gateway in the same zone provides a highly available, fault-tolerant egress architecture.

Step-by-Step Solution

1
Analyze the asymmetric routing behavior.
AWS Transit Gateway automatically prefers the Direct Connect path over VPN for outbound traffic to on-premises because it evaluates propagated routes in the following order of preference: VPC, Direct Connect, VPN. However, the on-premises routers are choosing the VPN path for inbound traffic to AWS.
To ensure symmetric routing, we must influence the BGP path selection on the on-premises side so that the Direct Connect path is preferred for traffic entering AWS.
2
Configure BGP attributes on the on-premises routers.
By assigning a higher BGP local preference to routes received over the Direct Connect connection and a lower local preference to routes received over the VPN connection, the on-premises routers will always select the Direct Connect path as primary.
Local preference is a standard BGP attribute propagated within an Autonomous System to determine the preferred exit point for outbound traffic (which is inbound to AWS).
3
Design highly available egress in the Shared Services VPC.
Deploy a NAT Gateway in each Availability Zone inside the Shared Services VPC.
A single NAT Gateway represents a single point of failure. Deploying one in each Availability Zone provides redundancy.
4
Configure routing for the Shared Services VPC TGW attachments.
Configure the route tables of the subnets containing the Transit Gateway attachments to point the default route to the NAT Gateway within the same Availability Zone.
This keeps egress traffic within the same Availability Zone, avoiding cross-AZ traffic charges and dependency on the availability of a single zone.

Key Concept

BGP route optimization for hybrid routing symmetry and multi-AZ egress design via Transit Gateway
Estimated Time:3m 0s
Question 631Question →

A health-tech company manages a multi-account AWS environment using AWS Organizations. Workloads running in spoke VPCs in multiple member accounts must access on-premises systems under the hospital.local domain, which are connected via an AWS Transit Gateway and an AWS Direct Connect connection. Additionally, these workloads must resolve internal service endpoints hosted in a central Private Hosted Zone (PHZ) named clinical.platform.aws in a Shared Services AWS account. Which architecture provides the most operationally efficient and secure DNS resolution across the hybrid and multi-account environment?

Show answer & explanation

Answer: In the Shared Services account, deploy Route 53 Resolver outbound endpoints in the central VPC, and create an outbound resolver rule for hospital.local pointing to the on-premises DNS servers. Share the resolver rule with the organization using AWS Resource Access Manager (RAM), and associate it with the spoke VPCs. Authorize cross-account VPC associations for the clinical.platform.aws private hosted zone (PHZ) from the Shared Services account, and associate the PHZ with the spoke VPCs in each member account.

Answer

In the Shared Services account, deploy Route 53 Resolver outbound endpoints in the central VPC, and create an outbound resolver rule for hospital.local pointing to the on-premises DNS servers. Share the resolver rule with the organization using AWS Resource Access Manager (RAM), and associate it with the spoke VPCs. Authorize cross-account VPC associations for the clinical.platform.aws private hosted zone (PHZ) from the Shared Services account, and associate the PHZ with the spoke VPCs in each member account.
The correct architecture leverages native cross-account Private Hosted Zone (PHZ) association, which allows instances in spoke VPCs to resolve the clinical.platform.aws domain locally and securely. For hybrid resolution, deploying outbound resolver endpoints in a central Shared Services VPC and sharing the resolver rule via AWS Resource Access Manager (RAM) allows spoke VPCs to query the on-premises hospital.local domain efficiently while keeping costs and operational overhead to a minimum.

Step-by-Step Solution

1
Authorize cross-account VPC associations for the private hosted zone.
The clinical.platform.aws PHZ in the Shared Services account is authorized to be associated with the spoke VPCs in the member accounts.
Cross-account authorization is required before a VPC in a different AWS account can be associated with a Private Hosted Zone.
2
Associate the spoke VPCs with the private hosted zone in the member accounts.
Spoke VPCs resolve clinical.platform.aws records locally without routing queries through a central inbound endpoint.
Associating the PHZ directly with each spoke VPC allows the native Route 53 Resolver (.2) to answer queries directly, eliminating network hops and extra costs.
3
Deploy centralized Route 53 Resolver outbound endpoints and configure rules.
An outbound endpoint is created in the Shared Services VPC, and an outbound rule for hospital.local is mapped to forward queries to the on-premises DNS servers.
This centralizes hybrid DNS configuration, reducing the need for costly outbound endpoints in every spoke VPC.
4
Share the outbound resolver rule via AWS RAM and associate it with the spoke VPCs.
Spoke VPCs automatically forward queries for hospital.local to the Shared Services VPC's outbound endpoint.
Sharing the rule via AWS RAM allows spoke VPCs to reuse the central outbound endpoint, providing consistent resolution for on-premises domains.

Key Concept

Cross-account Route 53 Private Hosted Zone association and centralized hybrid DNS routing using Route 53 Resolver rules shared via AWS RAM.
Question 632Question →

An enterprise is designing a centralized compliance and auditing architecture using AWS Organizations. The organization consists of a management account, a dedicated Logging account, and multiple member accounts. A solutions architect must configure a single AWS CloudTrail trail at the organization level that automatically aggregates log files from all current and future member accounts into an Amazon S3 bucket located in the Logging account.

The architecture must enforce the following security requirements:
- All log files stored in the S3 bucket must be encrypted at rest using a customer managed key (CMK) in AWS KMS that is managed by the Logging account.
- The member accounts must have no ability to read, decrypt, or delete the aggregated logs.
- The Logging account's security team must have exclusive permission to decrypt and analyze the logs.
- The solution must ensure that log delivery is secure and follows the principle of least privilege.

Which TWO configuration steps should the solutions architect perform to meet these requirements?

Select all that apply

Show answer & explanation

Answer: Configure a key policy for the customer managed key in the Logging account that grants `kms:GenerateDataKey*` and `kms:DescribeKey` permissions to the `cloudtrail.amazonaws.com` service principal with a condition restricting `aws:SourceArn` to the Organization Trail ARN, and restrict `kms:Decrypt` permissions to authorized security roles in the Logging account.; Configure an S3 bucket policy on the destination bucket in the Logging account that grants `s3:PutObject` and `s3:GetBucketAcl` permissions to the `cloudtrail.amazonaws.com` service principal, requiring the `s3:x-amz-acl` header to be set to `bucket-owner-full-control`, and restricting the S3 resource path to `AWSLogs/o-orgid/*` where `o-orgid` is the organization ID.

Answer

Configure a key policy for the customer managed key in the Logging account that allows the CloudTrail service principal to generate data keys under the trail's context while restricting decryption to authorized roles in the Logging account, and configure an S3 bucket policy on the destination bucket that permits the CloudTrail service principal to write log objects using the bucket-owner-full-control ACL constraint under the organization's logs prefix.
To centralize CloudTrail logs across an organization using a customer managed KMS key, the key policy in the Logging account must permit the CloudTrail service principal to generate data keys and describe the key under the trail's context. At the same time, the S3 bucket policy in the Logging account must authorize the CloudTrail service principal to write objects under the organization prefix and read bucket ACLs, ensuring log delivery succeeds while maintaining least privilege.

Step-by-Step Solution

1
Analyze AWS CloudTrail cross-account logging requirements.
Identify that CloudTrail delivers logs using the service principal `cloudtrail.amazonaws.com` rather than local IAM roles.
This establishes that the destination S3 bucket and KMS key policies must trust the CloudTrail service principal, not individual member account principals.
2
Determine the encryption key requirements.
Conclude that a Customer Managed Key (CMK) is required because AWS-managed keys cannot be shared across accounts or have their policies customized.
The KMS key policy must explicitly allow the CloudTrail service principal to perform `kms:GenerateDataKey*` and `kms:DescribeKey` operations for cross-account log delivery.
3
Formulate the S3 bucket policy.
Define an S3 bucket policy that permits `s3:PutObject` and `s3:GetBucketAcl` for the CloudTrail service principal with constraints on the Organization ID prefix and the `bucket-owner-full-control` ACL.
This ensures that CloudTrail has permissions to deliver logs to the bucket while giving the Logging account full ownership of the written files.
4
Define the decryption access control.
Ensure the KMS key policy does not grant `kms:Decrypt` to the CloudTrail service principal or the member accounts, restricting it only to security roles in the Logging account.
This guarantees that member accounts can write encrypted logs but cannot decrypt or read them once they are stored.

Key Concept

Centralized cross-account logging configuration using AWS Organizations, S3 bucket policies, and KMS key policies.
Estimated Time:3m 0s
Question 633Question →

An enterprise is designing its multi-account governance strategy using AWS Organizations. The security team wants to achieve the following:

1. Prevent all member accounts under the "Development" Organizational Unit (OU) from deploying resources outside of us-east-1 and us-west-2.
2. Restrict the "Production" OU so that only a specific list of approved EC2 instance types can be launched, while ensuring that administrators in individual production accounts can still manage their own local IAM permissions for launching those instances.

Which TWO of the following configurations must the Solutions Architect implement to meet these requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Attach a Service Control Policy (SCP) to the Development OU that denies access to all AWS actions if the request is made outside of us-east-1 and us-west-2, using the aws:RequestedRegion condition key with a StringNotEquals operator.; Attach a Service Control Policy (SCP) to the Production OU that denies the ec2:RunInstances action if the ec2:InstanceType condition key does not match the approved list, and configure local IAM policies in the production accounts to explicitly grant the ec2:RunInstances permission.

Answer

Attach a Service Control Policy (SCP) to the Development OU that denies access to all AWS actions if the request is made outside of us-east-1 and us-west-2 using the aws:RequestedRegion key with a StringNotEquals operator, and attach an SCP to the Production OU that denies the ec2:RunInstances action if the ec2:InstanceType condition key does not match the approved list, while configuring local IAM policies in the production accounts to explicitly grant the ec2:RunInstances permission.
The correct strategy combines a regional restriction SCP using aws:RequestedRegion at the Development OU level with a instance-type filtering SCP at the Production OU level. The regional restriction SCP effectively blocks API calls outside us-east-1 and us-west-2. The instance-type restriction SCP acts as a guardrail, while local IAM policies in the production accounts explicitly grant permissions to launch the allowed instance types, conforming to the policy evaluation logic where an action is allowed only if both the SCP and IAM policies permit it.

Step-by-Step Solution

1
Evaluate the regional restriction requirement for the Development OU.
Identify that a Deny-based SCP using the aws:RequestedRegion condition key with a StringNotEquals operator must be applied to the Development OU to block non-approved regions.
This establishes a robust guardrail that prevents resource creation in unapproved regions, while allowing normal operations within us-east-1 and us-west-2.
2
Determine the proper relationship between SCPs and IAM policies for the Production OU EC2 restriction.
Understand that SCPs set the maximum permissions (guardrails) and do not grant permissions directly. An SCP denying unauthorized instance types must be paired with local IAM policies that explicitly grant ec2:RunInstances.
To adhere to the principle of least privilege, the local administration team must be granted access locally, while the organization-level SCP ensures they cannot exceed the guardrails set by the security team.

Key Concept

Service Control Policies (SCPs) define permission guardrails but do not grant permissions directly; they must be paired with local IAM policies to allow actions.
Question 634Question →

An enterprise runs a critical application on Amazon EC2 instances managed by an Auto Scaling group (ASG) behind an Application Load Balancer (ALB). The application must maintain at least 90% of its normal capacity (10 instances) at all times during updates. The solutions architect must design a deployment strategy that routes 10% of incoming traffic to a new version of the application for a 20-minute evaluation period, with the remaining 90% routed to the current version. If HTTP 5xx errors exceed a specified threshold during this period, the deployment must automatically roll back. Due to strict vCPU service quotas in the AWS Region, the organization cannot provision a duplicate ASG of the same size to perform a standard CodeDeploy blue/green deployment. Which two actions should the solutions architect recommend to meet these requirements?

Select all that apply

Show answer & explanation

Answer: Configure the Application Load Balancer with two target groups: a primary target group pointing to the existing production Auto Scaling group, and a canary target group pointing to a new, separate Auto Scaling group provisioned with 10% of the production group's capacity.; Configure the Application Load Balancer listener rule to use weighted target group routing, directing 90% of traffic to the primary target group and 10% to the canary target group, and use an AWS Lambda function triggered by CloudWatch alarms to reset the canary target group weight to 0% upon failure.

Answer

The solutions architect should configure the Application Load Balancer with two target groups (one for the primary ASG and one for the 10% canary ASG) and configure the ALB listener rule with weighted target group routing combined with an AWS Lambda function triggered by CloudWatch alarms to reset the weight to 0% on failure.
To achieve a 10% canary deployment on EC2 without duplicating the entire ASG (which would violate vCPU service quotas), the Solutions Architect must design a custom deployment strategy. This is done by creating a separate target group and a smaller Auto Scaling group sized to 10% of the primary ASG (1 instance). An ALB listener rule with weighted target groups is used to shift 10% of the traffic to the canary group. If a failure occurs, a Lambda function triggered by CloudWatch alarms can automatically reset the weight to 0%, executing a rollback without affecting the primary production fleet.

Step-by-Step Solution

1
Analyze deployment constraints
Determine that native CodeDeploy blue/green deployments cannot be used because they copy the entire Auto Scaling group, which violates the regional vCPU quota constraint. Also, realize that CodeDeploy canary/linear traffic shifting is not supported on EC2.
This rules out native CodeDeploy options and establishes the need for a custom deployment strategy.
2
Design the target groups and Auto Scaling groups
Define a primary target group for the existing 10-instance ASG, and provision a separate, smaller ASG (with 1 instance, representing 10% capacity) mapped to a canary target group.
This satisfies the requirement to maintain 90% capacity during deployments without exceeding the region's vCPU quota.
3
Configure load balancer routing
Configure the ALB listener rule with weighted target group routing, mapping 90% weight to the primary target group and 10% weight to the canary target group.
This implements the 10% canary traffic split required for evaluation.
4
Implement automated rollback monitoring
Set up a CloudWatch alarm for HTTP 5xx errors and configure it to trigger an AWS Lambda function that resets the canary target group weight to 0% and scales down the canary ASG if error thresholds are exceeded.
This guarantees a fast, automated rollback within the required time window.

Key Concept

Custom canary deployment design on AWS EC2 when native CodeDeploy deployment options are limited by region quotas or platform capabilities.
Question 635Question →

A financial services company is designing a hybrid network connectivity solution for its multi-account AWS environment. The environment consists of 3030 spoke VPCs spread across two AWS Regions: `us-east-1` and `us-west-2`. The company needs to connect these VPCs to their on-premises data center using an existing 10 Gbps10\text{ Gbps} AWS Direct Connect connection at a co-location facility. The solution must support dynamic routing, secure any-to-any VPC communication within and across Regions, provide automatic failover via an AWS Site-to-Site VPN, and minimize administrative overhead.

Which of the following configuration steps must the company implement to meet these requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Deploy an AWS Transit Gateway in each Region, peer the two Transit Gateways, and connect them to the on-premises data center via a Direct Connect Gateway using transit virtual interfaces (VIFs).; Establish an AWS Site-to-Site VPN connection terminating on the Transit Gateways as a backup path, and use Border Gateway Protocol (BGP) routing with AS Path prepending to prefer the Direct Connect path.

Answer

Deploying an AWS Transit Gateway in each Region, peering them, and connecting them to a Direct Connect Gateway using transit virtual interfaces (VIFs), combined with establishing an AWS Site-to-Site VPN terminating on the Transit Gateways as a backup path configured with AS Path prepending.
Establishing AWS Transit Gateways in both Regions, peering them, and connecting them to a Direct Connect Gateway utilizing transit VIFs provides a fully transitive, scalable architecture that connects multiple accounts and Regions. Supplementing this with an AWS Site-to-Site VPN that terminates on the Transit Gateways with BGP and AS Path prepending ensures high-availability failover while preventing asymmetric routing and ensuring the Direct Connect path is preferred.

Step-by-Step Solution

1
Deploy Transit Gateways in the target Regions and peer them.
Establishes a regional transit hub that supports cross-Region transitive routing between spoke VPCs.
Direct VPC peering does not scale for 3030 VPCs, and Transit Gateway is required to enable cross-Region any-to-any communication.
2
Connect the Transit Gateways to the Direct Connect Gateway.
Links the hybrid on-premises connectivity to the transit network using transit VIFs.
Allows all spoke VPCs attached to the Transit Gateways to route traffic to the on-premises data center via the high-speed Direct Connect connection.
3
Configure AWS Site-to-Site VPN on the Transit Gateways with BGP routing and AS Path prepending.
Creates a backup route that is only active if the Direct Connect link fails.
Prevents asymmetric routing and ensures that high-speed Direct Connect is prioritized over the backup VPN link under normal operation.

Key Concept

Designing hybrid and multi-account transit networking using AWS Transit Gateway and Direct Connect Gateway with VPN failover.
Estimated Time:2m 0s
Question 636Question →

A healthcare provider is designing a multi-region disaster recovery (DR) architecture for a critical patient telemetry application. The application's web and ingestion layers run on AWS Fargate behind Application Load Balancers (ALBs) in both the primary region (`us-east-1`) and the recovery region (`us-west-2`). The ingestion tasks in both regions must query a shared metadata store and resolve the internal microservice address `api.telemetry.local` using a Route 53 Private Hosted Zone (PHZ) created in the primary VPC. The application must also send outbound alert notifications to external clinical endpoints via the internet. The architecture must support a Recovery Time Objective (RTO) of 1010 minutes and a Recovery Point Objective (RPO) of 11 minute. The recovery region must run as a cost-efficient warm standby, keeping running resources to a minimum until a failover is declared. The solution must also remain highly available within each region, ensuring no single Availability Zone (AZ) failure can disrupt telemetry ingestion or outbound alerting. Which configuration meets these requirements while minimizing cost?

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, running a single db.r6g.large reader instance in the secondary cluster. Associate the api.telemetry.local Private Hosted Zone with both the primary and secondary VPCs. In each VPC, deploy a NAT Gateway in each of the two utilized Availability Zones. Configure Route 53 Active-Passive Failover routing policy with health checks to route public traffic to the primary ALB, failing over to the secondary ALB if health checks fail.

Answer

The configuration using Amazon Aurora Global Database, associating the Private Hosted Zone with both VPCs, deploying NAT Gateways across multiple Availability Zones in each region, and routing traffic using Route 53 Active-Passive Failover with health checks.
The correct solution leverages Amazon Aurora Global Database to achieve cross-region sub-second data replication and quick managed failovers, satisfying the 1-minute RPO and 10-minute RTO. It ensures local name resolution for the microservice endpoint by associating the Route 53 Private Hosted Zone with both VPCs. Furthermore, it protects outbound alerting availability by deploying multi-AZ NAT Gateways in each region.

Step-by-Step Solution

1
Select a database disaster recovery pattern that supports the RPO of 1 minute and RTO of 10 minutes.
Identify Amazon Aurora Global Database as the correct choice since its storage-based physical replication is asynchronous but achieves sub-second lag, and managed regional failover can be executed within a few minutes.
Traditional backup and restore or simple cross-region read replicas may require manual promotion processes or snapshot restoration that violate the aggressive RPO/RTO bounds.
2
Ensure name resolution for the internal microservice endpoint works in both the primary and recovery regions.
Associate the Route 53 Private Hosted Zone created in the primary VPC with the secondary VPC in the recovery region.
VPC peering does not automatically share Private Hosted Zone name resolution; the hosted zone must be explicitly associated with each VPC that needs to resolve the private DNS names.
3
Design highly available internet egress routing for outbound telemetry alerts in each region.
Deploy a NAT Gateway in each Availability Zone in both regions.
Using a single NAT Gateway per VPC creates a single point of failure. If the Availability Zone containing the NAT Gateway experiences an outage, all resources in other Availability Zones lose outbound internet access.
4
Establish global routing that automatically detects failures and redirects traffic.
Configure Route 53 Active-Passive Failover routing using health checks linked to the Application Load Balancer in each region.
Active-Passive failover routes all traffic to the primary region under normal operations and dynamically switches traffic to the recovery region when the primary endpoint health check fails.

Key Concept

Designing multi-region disaster recovery for low RTO/RPO, ensuring cross-VPC DNS resolution, and maintaining multi-AZ redundant egress paths.
Question 637Question →

A company is designing a hybrid network architecture for its multi-account AWS environment in the `us-east-1` Region. The setup includes 1515 spoke VPCs that must connect to an on-premises data center. The design requires a primary 10 Gbps10\text{ Gbps} AWS Direct Connect connection and a backup IPsec VPN connection over the internet, both supporting dynamic routing and automatic failover. Additionally, all spoke VPCs must route their outbound internet traffic through a centralized egress VPC. Which configuration meets these requirements while ensuring high availability and minimizing administrative overhead?

Show answer & explanation

Answer: Deploy a central AWS Transit Gateway (TGW). Create a Direct Connect Gateway (DXGW) with a transit virtual interface and associate it with the TGW. Create an IPsec VPN attachment on the TGW. Create a centralized egress VPC with redundant NAT Gateways deployed across multiple Availability Zones, and attach it to the TGW. Configure the spoke VPC route tables to direct all 0.0.0.0/00.0.0.0/0 traffic to the TGW, and configure the TGW route tables to route egress traffic to the egress VPC and on-premises traffic to both the DXGW and VPN attachments, using BGP dynamic routing to prefer the Direct Connect path.

Answer

Deploy a central AWS Transit Gateway, connect it to the on-premises data center via a Direct Connect Gateway with a transit virtual interface and an IPsec VPN attachment, and use a centralized egress VPC with redundant NAT Gateways across multiple Availability Zones. Configure dynamic BGP routing to automatically failover from Direct Connect to VPN.
The correct architecture leverages AWS Transit Gateway to simplify multi-account connectivity. By attaching both the Direct Connect Gateway (using a transit VIF) and the IPsec VPN to the Transit Gateway and advertising the same BGP routes, the Transit Gateway automatically selects the Direct Connect path as primary and the VPN as backup. Centralizing egress through a multi-AZ NAT Gateway pool in an egress VPC attached to the Transit Gateway ensures high availability and cost-effective outbound traffic routing.

Step-by-Step Solution

1
Centralize VPC connectivity using AWS Transit Gateway (TGW) to simplify the routing topology and avoid scale limitations.
All 1515 spoke VPCs and the egress VPC are attached to the same TGW, eliminating the need for complex VPC peering meshes.
Transit Gateway acts as a cloud router, enabling hub-and-spoke transit network routing at scale.
2
Connect the on-premises network to the TGW using a Direct Connect Gateway (DXGW) with a transit virtual interface and a backup VPN attachment.
The TGW has paths to on-premises via both Direct Connect and VPN.
A transit virtual interface is required to connect a Direct Connect Gateway to a Transit Gateway.
3
Configure BGP dynamic routing on both the Direct Connect and VPN connections, advertising identical on-premises prefixes.
AWS Transit Gateway automatically prefers the Direct Connect Gateway path over the VPN path because Direct Connect Gateway attachments are higher in the Transit Gateway route evaluation order than VPN attachments for identical prefixes.
This guarantees automatic failover to the backup VPN if the primary Direct Connect connection is lost, without manual routing updates.
4
Deploy redundant NAT Gateways across multiple Availability Zones in a central egress VPC, and configure default routes.
All spoke VPCs direct 0.0.0.0/00.0.0.0/0 traffic to the TGW, which forwards it to the egress VPC containing the NAT Gateway pool.
This setup secures and centralizes internet egress while eliminating single points of failure.

Key Concept

AWS Transit Gateway acts as a regional hub to simplify multi-account hybrid routing and centralize egress traffic. When identical prefixes are advertised over both a Direct Connect Gateway and an IPsec VPN, the Transit Gateway automatically prefers the Direct Connect path, enabling seamless, automatic failover.
Question 638Question →

An enterprise is designing a high-availability hybrid network using a multi-account AWS environment across two Regions: `us-east-1` (Primary) and `us-west-2` (Secondary). Each Region contains a Transit Gateway (TGW) connecting local spoke VPCs. The TGW in `us-east-1` and the TGW in `us-west-2` are peered to allow inter-Region VPC-to-VPC traffic. The enterprise has an on-premises data center with a 10 Gbps10\text{ Gbps} AWS Direct Connect (DX) connection terminating at a DX location associated with `us-east-1`. A Direct Connect Gateway (DXGW) is configured with a Transit Virtual Interface (VIF) to connect to the on-premises router. The network team has the following requirements:
- Spoke VPCs in both `us-east-1` and `us-west-2` must have primary hybrid connectivity to the on-premises data center via the DX connection.
- A backup AWS Site-to-Site VPN must provide automated failover with minimum latency if the DX connection or Transit VIF goes down.
- Asymmetric routing between the data center and the AWS Regions must be prevented.

Which TWO configuration steps should the solutions architect implement to meet these requirements?

Select all that apply

Show answer & explanation

Answer: Associate the Direct Connect Gateway with the Transit Gateways in both `us-east-1` and `us-west-2`. Terminate the backup Site-to-Site VPN connections directly on the Transit Gateway in each respective Region.; Configure BGP over the Direct Connect Transit VIF and the VPN connections. On the on-premises router, set a higher local preference for prefixes received via the Direct Connect Gateway to ensure outbound traffic to AWS prefers the Direct Connect path.

Answer

To establish a high-availability hybrid network across two Regions without asymmetric routing, associate the Direct Connect Gateway with the Transit Gateways in both Regions and establish Site-to-Site VPN connections terminating directly on each local Transit Gateway. On the on-premises router, configure BGP local preference to prioritize the routes received via the Direct Connect Gateway over the backup VPN connections.
Associating the Direct Connect Gateway with both Transit Gateways and establishing VPN connections terminating on each TGW ensures that both Regions have a direct path to the on-premises network, satisfying the non-transitive routing rule of Transit Gateway peering. Configuring BGP local preference on-premises ensures that outbound traffic to AWS prefers the Direct Connect path. This matches the inbound behavior where TGW route tables automatically prioritize Direct Connect gateway routes over VPN routes for identical prefixes, preventing asymmetric routing.

Step-by-Step Solution

1
Analyze Transit Gateway peering transitive routing limitations.
Identify that spoke VPCs in the secondary region cannot transit the peering connection to reach a Direct Connect Gateway or VPN in the primary region.
AWS Transit Gateway does not support transitive routing between peering connections and hybrid connections.
2
Design the hybrid connectivity attachments for both Regions.
Associate the Direct Connect Gateway with both Transit Gateways and terminate VPN connections in both Regions.
Direct association and attachment are required to allow local egress and ingress for both Regions.
3
Address outbound routing from on-premises to AWS to prefer Direct Connect.
Configure BGP local preference on the customer gateway to prefer routes received via Direct Connect.
Prevent on-premises from routing traffic to AWS over the lower-bandwidth backup VPN connections.
4
Verify return path routing from AWS to on-premises.
AWS TGW route tables automatically prioritize Direct Connect gateway routes over VPN routes for the same prefix.
Ensures symmetric path alignment without requiring complex prefix prepending on the AWS side.

Key Concept

AWS Transit Gateway does not support transitive routing over peering connections to Direct Connect Gateways or VPNs; therefore, hybrid attachments must exist in each Region. BGP routing configuration is required to align inbound and outbound paths to prevent asymmetric routing.
Question 639Question →

An insurance provider is designing a multi-account landing zone using AWS Organizations. The security team has established two strict compliance requirements for the new structure:
1. All Amazon S3 buckets created in member accounts must be encrypted using a specific customer managed key (CMK) hosted in a central Security account.
2. AWS Config compliance rules must be managed and deployed centrally across all member accounts from a dedicated Compliance account, without utilizing the Organizations management account for operational tasks.

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

Select all that apply

Show answer & explanation

Answer: In the central Security account, create a Customer Managed Key (CMK) and configure its key policy to allow encryption and decryption actions for the AWS Organization's principal. In AWS Organizations, apply a Service Control Policy (SCP) to the member accounts' organizational units (OUs) that denies s3:PutBucketEncryption if the encryption algorithm is not aws:kms or if the KMS key ARN does not match the CMK in the Security account.; Enable trusted access for AWS Config in the AWS Organizations management account. Register the Compliance account as a delegated administrator for AWS Config, and deploy organizational conformance packs from the Compliance account to distribute the compliance rules to all member accounts.

Answer

Configure a Customer Managed Key (CMK) in the Security account with a key policy allowing organization-wide access, and use an SCP to deny S3 bucket encryption configurations that do not use this key. Additionally, register the Compliance account as a delegated administrator for AWS Config and deploy organizational conformance packs.
The correct solution involves creating a Customer Managed Key (CMK) in the Security account and granting cross-account permissions via its key policy, while applying an SCP to enforce its use for S3 bucket encryption. It also involves enabling trusted access for AWS Config and registering the Compliance account as a delegated administrator to deploy organizational conformance packs centrally.

Step-by-Step Solution

1
Set up cross-account S3 encryption enforcement.
A Customer Managed Key (CMK) is created in the Security account with a key policy that grants permissions to the organization's member accounts. An SCP is attached to the OUs to prevent S3 bucket creation/updates unless they reference this specific key ARN.
AWS-managed keys (like aws/s3) cannot be shared across accounts, meaning a Customer Managed Key is required. The key policy must explicitly allow cross-account access, and the SCP restricts member account actions to only use this key.
2
Establish delegated administration for compliance monitoring.
Trusted access for AWS Config is enabled in the Organizations management account, and the Compliance account is registered as a delegated administrator.
This adheres to the principle of least privilege by avoiding the use of the Organizations management account for operational tasks while permitting the Compliance account to manage organization-wide Config resources.
3
Deploy AWS Config rules organization-wide.
Organizational conformance packs are created and deployed from the Compliance account to all member accounts in the organization.
Organizational conformance packs automatically deploy the defined Config rules and remediation actions across all current and future accounts under the organization.

Key Concept

Multi-Account Governance using Service Control Policies and Delegated Administration
Question 640Question →

A multinational corporation uses AWS Organizations to manage a multi-account environment. The organization consists of a Management account, a central Shared Services account, a Production Organizational Unit (OU) containing several application accounts, and a Development OU containing several testing accounts.

The corporation wants to implement a cost optimization and resource sharing architecture with the following requirements:
* A set of VPC subnets created in the Shared Services account must be shared with all application and testing accounts to enable standardized network routing.
* The finance team has purchased a Compute Savings Plan in the Management account. The discount benefits must be applied to the accounts in the Production OU first, but must be completely blocked from applying to any accounts in the Development OU to ensure development teams pay standard On-Demand rates for budgeting.
* The AWS Cost and Usage Report (CUR) is written to an Amazon S3 bucket in the Shared Services account. Data analysts in the application and testing accounts must run Amazon Athena queries in their local accounts to read this billing data directly. The S3 bucket must be encrypted at rest, and the architecture must support secure cross-account queries.

Which combination of actions will meet these requirements?

Show answer & explanation

Answer: Configure AWS Resource Access Manager (RAM) in the Shared Services account to share the subnets, enabling organization sharing and selecting the Production and Development OUs as principals. In the AWS Billing console of the Management account, enable discount sharing, but selectively turn off Reserved Instance (RI) and Savings Plans (SP) sharing for all individual accounts in the Development OU. Encrypt the S3 bucket in the Shared Services account using a Customer Managed Key (CMK) in AWS KMS, configure the KMS key policy to allow the IAM roles in the application and testing accounts to perform kms:Decrypt and kms:GenerateDataKey, and update the S3 bucket policy to grant s3:GetObject and s3:ListBucket permissions to those cross-account roles.

Answer

Configure AWS Resource Access Manager (RAM) in the Shared Services account to share the subnets, enabling organization sharing and selecting the Production and Development OUs as principals. In the AWS Billing console of the Management account, enable discount sharing, but selectively turn off Reserved Instance (RI) and Savings Plans (SP) sharing for all individual accounts in the Development OU. Encrypt the S3 bucket in the Shared Services account using a Customer Managed Key (CMK) in AWS KMS, configure the KMS key policy to allow the IAM roles in the application and testing accounts to perform kms:Decrypt and kms:GenerateDataKey, and update the S3 bucket policy to grant s3:GetObject and s3:ListBucket permissions to those cross-account roles.
The correct solution uses AWS RAM to share the subnets directly with the target OUs (Production and Development OUs) after enabling Organization sharing. It selectively disables RI/SP discount sharing in the Management account's Billing Preferences for the development accounts, satisfying the business requirement to keep development workloads on On-Demand rates while maximizing production savings. Finally, it uses a Customer Managed Key (CMK) in AWS KMS to allow cross-account access, granting permissions via both the KMS key policy and S3 bucket policy so that application accounts can query the bucket directly using Amazon Athena.

Step-by-Step Solution

1
Configure AWS RAM for subnet sharing.
VPC subnets from the central Shared Services account are securely shared with the application and testing accounts without requiring manual invitations, by targeting the OUs as principals and enabling Organization sharing.
AWS RAM allows sharing VPC subnets across accounts in an AWS Organization to build a standardized network topology.
2
Configure Billing preferences for Selective Savings Plans sharing.
The Compute Savings Plan discount is applied to the Production accounts while the Development accounts are billed at the standard On-Demand rates.
AWS Organizations consolidated billing preferences allow the management account to disable discount sharing for specific member accounts to satisfy chargeback/cost segregation requirements.
3
Set up secure S3 bucket and KMS Key Policies.
Data analysts can query the central S3 bucket directly from their local accounts using Amazon Athena.
AWS-managed keys (aws/s3) do not support cross-account sharing because their key policies cannot be modified. A Customer Managed Key (CMK) is required, along with S3 bucket policies that allow cross-account access.

Key Concept

Multi-account resource sharing via AWS RAM, consolidated billing discount sharing management, and cross-account KMS/S3 access controls.
Estimated Time:2m 30s
PreviousPage 32 / 99Next
All practice questions — AWS Certified Solutions Architect - Professional | Examkin