Examkin

All practice questions

1964 questions

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

A company is designing a hybrid network architecture for its multi-account AWS environment consisting of 20 VPCs spread across two AWS Regions. The architecture must enable any-to-any VPC-to-VPC communication and connect all VPCs to the company's on-premises data center. The connectivity design requires AWS Direct Connect as the primary connection, with a backup connection over the internet that automatically handles failover. The company wants to minimize administrative overhead. Which hybrid connectivity design meets these requirements?

Show answer & explanation

Answer: Deploy an AWS Transit Gateway in each AWS Region, peer the two Transit Gateways, and connect them to a centralized Direct Connect Gateway using Transit Virtual Interfaces. Establish backup Site-to-Site VPN connections to the Transit Gateways, configuring dynamic routing with BGP and AS-Path prepending to prefer the Direct Connect path.

Answer

Deploy peered AWS Transit Gateways connected to a Direct Connect Gateway via Transit VIFs, and set up backup Site-to-Site VPNs to the Transit Gateways using BGP with AS-Path prepending to prefer the Direct Connect path.
The correct design uses AWS Transit Gateways peered across Regions to enable scalable any-to-any VPC-to-VPC routing. By connecting the Transit Gateways to a centralized Direct Connect Gateway using Transit Virtual Interfaces, hybrid connectivity is established. Deploying Site-to-Site VPNs to the Transit Gateways with BGP dynamic routing and AS-Path prepending ensures the Direct Connect path is preferred during normal operation, while enabling automatic failover to the VPN backup when necessary.

Step-by-Step Solution

1
Analyze routing requirements for multi-region VPC-to-VPC and hybrid connectivity.
Identify that AWS Transit Gateway is required because it natively supports transitive routing (any-to-any VPC communication), whereas a Direct Connect Gateway alone does not route traffic between attached VPCs.
To satisfy the requirement of any-to-any VPC communication across both AWS Regions.
2
Determine the configuration for primary and backup hybrid connections.
Connect the regional Transit Gateways to a centralized Direct Connect Gateway using Transit Virtual Interfaces (Transit VIFs) for the primary connection, and deploy AWS Site-to-Site VPN connections directly to the Transit Gateways for the backup connection.
Transit VIFs allow Transit Gateways to attach to a Direct Connect Gateway. Site-to-Site VPN attachments on the Transit Gateways allow backup hybrid traffic to scale across all associated VPCs.
3
Configure failover routing policy.
Use Border Gateway Protocol (BGP) dynamic routing on both the Direct Connect and VPN connections, and configure AS-Path prepending on the VPN connection on-premises.
AS-Path prepending makes the VPN path look longer, ensuring AWS prefers the Direct Connect path under normal operating conditions while facilitating automatic dynamic failover if the Direct Connect link fails.

Key Concept

Hybrid and Multi-Account Network Connectivity Design using AWS Transit Gateway, Direct Connect Gateway, and dynamic VPN failover.
Estimated Time:2m 0s
Question 442Question →

A company is implementing a multi-account strategy using AWS Organizations. The network infrastructure team has created a central VPC and wants to share specific subnets with various application development teams whose accounts reside in a separate Organizational Unit (OU). The goal is to allow application teams to deploy their EC2 instances into the shared subnets, consolidating network resources. A network engineer attempts to create a resource share in AWS Resource Access Manager (RAM) to share these subnets with the target OU, but the operation fails with an error indicating that sharing is restricted. Which of the following is the most likely cause of this failure and the correct resolution?

Show answer & explanation

Answer: Sharing with AWS Organizations has not been enabled in the AWS RAM settings from the organization's management account. To resolve this, the management account administrator must enable sharing within the organization in the AWS RAM console or via the AWS CLI.

Answer

Sharing with AWS Organizations has not been enabled in the AWS RAM settings from the organization's management account. To resolve this, the management account administrator must enable sharing within the organization in the AWS RAM console or via the AWS CLI.
The correct answer is the option stating that sharing with AWS Organizations has not been enabled in the AWS RAM settings from the management account. In AWS Organizations, sharing resources with accounts or OUs within the organization requires the organization's management account to explicitly enable integration with AWS Organizations in AWS RAM. Once enabled, resources like subnets can be shared, and invitations are automatically accepted by member accounts. If this setting is disabled, attempts to share resources with OUs or accounts inside the organization will fail.

Step-by-Step Solution

1
Identify the sharing scope and target.
The target is an Organizational Unit (OU) within the same AWS Organization.
Understanding the boundary helps determine the required permissions and configuration settings.
2
Check the AWS Resource Access Manager (RAM) organization sharing setting.
By default, sharing within AWS Organizations is disabled in AWS RAM.
Before you can share resources with OUs or accounts in your organization, the management account must enable integration with AWS Organizations.
3
Enable the organization sharing setting in the management account.
The setting is enabled, allowing cross-account sharing within the organization boundary.
This allows resource sharing to succeed and automatically accepts the resource share invitations for member accounts.

Key Concept

Consolidated resource sharing in a multi-account AWS Organization using AWS Resource Access Manager (RAM).
Question 443Question →

An enterprise manages its multi-account environment using AWS Organizations. The security team has configured an on-premises SAML 2.0 Identity Provider (IdP) for federated access. The enterprise wants to allow external developers authenticated via this IdP to assume a specific troubleshooting role in a target member account. The Solutions Architect configures the SAML identity provider object inside the member account. However, when developers attempt to federate directly into the target member account via the identity provider's portal, they receive an explicit access denied error before they can choose a role. Which configuration change will successfully resolve this authentication failure and establish the trust relationship?

Show answer & explanation

Answer: Update the IAM role trust policy in the target member account to set the local SAML provider as the Principal, specify the sts:AssumeRoleWithSAML action, and add a condition that the SAML:aud attribute matches the AWS SAML endpoint.

Answer

Update the IAM role trust policy in the target member account to set the local SAML provider as the Principal, specify the sts:AssumeRoleWithSAML action, and add a condition that the SAML:aud attribute matches the AWS SAML endpoint.
Direct SAML 2.0 federation into a member account requires configuring a SAML identity provider resource inside that specific member account. The trust policy of the IAM role to be assumed must list this local SAML provider as the principal and explicitly allow the sts:AssumeRoleWithSAML action. Adding a condition verifying that the SAML:aud attribute matches the standard AWS SAML endpoint ensures the assertion is intended for the correct AWS environment.

Step-by-Step Solution

1
Analyze the authentication flow for direct SAML federation into an AWS member account.
Identify that the federation portal attempts to execute the sts:AssumeRoleWithSAML API call directly against the target account's STS endpoint.
Direct federation bypassing the management account requires the target member account to have its own trust relationship established with the SAML identity provider.
2
Evaluate the IAM role trust policy requirements for SAML federation.
Determine that the trust policy must explicitly declare the local SAML provider as the principal and authorize the sts:AssumeRoleWithSAML action.
Standard sts:AssumeRole is only used for IAM identity delegation (users, roles, services), not for federated SAML assertions, which require a specialized STS action.
3
Assess the effect of Service Control Policies (SCPs) on cross-account federation trust.
Confirm that SCPs can only deny permissions as guardrails and cannot grant trust or replace the trust policy of an IAM role.
SCPs act as a filter on permissions and do not grant access directly; the local IAM role trust policy must still explicitly permit the federation action.

Key Concept

Direct multi-account SAML federation requires configuring local SAML provider objects and matching trust policies using the sts:AssumeRoleWithSAML action in each target account.
Question 444Question →

A financial enterprise is designing its multi-account governance structure using AWS Organizations. The security team wants to ensure that developers operating within the Sandbox Organizational Unit (OU) are restricted to using only Amazon EC2, Amazon S3, and Amazon DynamoDB. The developers must be blocked from using any other AWS services, even if they have administrative privileges in their local accounts. This control must be enforced centrally with the least administrative overhead. How should the Solutions Architect implement this governance control?

Show answer & explanation

Answer: Attach a Service Control Policy (SCP) to the Sandbox OU that uses a Deny effect with a NotAction element specifying ec2:*, s3:*, dynamodb:*, and organizations:*, while keeping the default FullAWSAccess SCP attached. Grant developers access locally using IAM policies.

Answer

Attach a Service Control Policy (SCP) to the Sandbox OU that uses a Deny effect with a NotAction element specifying ec2:*, s3:*, dynamodb:*, and organizations:*, while keeping the default FullAWSAccess SCP attached. Grant developers access locally using IAM policies.
The correct solution attaches a Service Control Policy (SCP) using a Deny effect with a NotAction element to the Sandbox OU. This acts as a centralized guardrail, blocking all services except EC2, S3, DynamoDB, and Organizations. Since SCPs do not grant permissions, developers must still be granted access locally via IAM policies.

Step-by-Step Solution

1
Identify the mechanism for central permission guardrails in AWS Organizations.
Service Control Policies (SCPs) are identified as the correct tool for restricting services across accounts.
SCPs allow administrators to set the maximum available permissions for member accounts at the OU or account level.
2
Formulate the SCP structure to permit only EC2, S3, and DynamoDB with minimal overhead.
A Deny policy with a NotAction clause for ec2:*, s3:*, dynamodb:*, and organizations:* is created, keeping the default FullAWSAccess SCP in place.
Using Deny with NotAction avoids the complexity of removing and recreating the default FullAWSAccess policy, which would require defining every allowed action explicitly.
3
Determine the local account requirements to allow developers to perform work.
Local IAM policies must be created in the sandbox accounts to explicitly grant permissions to EC2, S3, and DynamoDB.
SCPs restrict permissions but do not grant them; an IAM policy is still required within the local account to allow access.

Key Concept

Service Control Policies (SCPs) act as filters that limit the maximum permissions of IAM users and roles in member accounts, but they do not grant permissions directly. A common pattern for whitelisting specific services with minimal maintenance is using a Deny effect with a NotAction block.
Question 445Question →

A logistics company is designing its multi-account architecture using AWS Organizations. The architecture includes a billing management account, a centralized infrastructure account, and several development accounts. The company runs workloads on Amazon EC2, AWS Fargate, and AWS Lambda.

The architecture must support the following requirements:
1. Maximize compute cost savings across all accounts using a single commitment-based contract.
2. Share a centralized Transit Gateway in the infrastructure account with the development accounts and an external partner's AWS account that is not part of the organization.
3. Securely share common S3 data buckets in the billing management account with application servers in the development accounts using KMS encryption.

Which TWO actions should a solutions architect recommend to meet these requirements?

Select all that apply

Show answer & explanation

Answer: Purchase Compute Savings Plans in the billing management account to automatically apply discounts to Amazon EC2, AWS Fargate, and AWS Lambda workloads across all member accounts, and verify that billing discount sharing is enabled in the organization's billing preferences.; In AWS Resource Access Manager (RAM) in the infrastructure account, create a resource share for the Transit Gateway, enable sharing with external principals, and add the development accounts' Organization Unit (OU) path and the partner's external AWS account ID as principals.

Answer

To meet the requirements, the solutions architect must recommend purchasing Compute Savings Plans in the billing management account with discount sharing enabled, and sharing the Transit Gateway via AWS Resource Access Manager by enabling external principals and adding the external partner's AWS account ID along with the internal OUs.
Purchasing Compute Savings Plans in the billing management account with discount sharing enabled successfully covers EC2, Fargate, and Lambda workloads across all member accounts. Sharing the Transit Gateway via AWS Resource Access Manager (RAM) with external sharing enabled allows both internal OUs and external accounts to access the gateway.

Step-by-Step Solution

1
Analyze the compute cost saving requirements for a hybrid environment containing Amazon EC2, AWS Fargate, and AWS Lambda.
Determine that Compute Savings Plans must be used because EC2 Instance Savings Plans do not cover Fargate or Lambda. The savings plan should be purchased in the management account with discount sharing enabled to apply to all member accounts.
This maximizes savings across the entire organization's diverse compute fleet under a single contract.
2
Determine the sharing constraints for Transit Gateways and VPC subnets via AWS Resource Access Manager (RAM).
Identify that Transit Gateways can be shared externally by enabling external principals in RAM, whereas VPC subnets cannot be shared outside the organization.
This allows sharing the Transit Gateway with both the internal organization's OUs and the external partner's account ID safely, while discarding subnet sharing options.
3
Evaluate the cross-account S3 data sharing and encryption requirements.
Determine that AWS-managed KMS keys (aws/s3) cannot be shared across accounts. A customer managed key with appropriate key policies and bucket policies is required.
This rules out options recommending the use of the default AWS-managed KMS key for cross-account S3 sharing.

Key Concept

AWS Organizations billing sharing, AWS Resource Access Manager sharing boundaries, and cross-account KMS restrictions.
Question 446Question →

A company is executing a corporate migration where multiple business units are split into separate AWS accounts, and their on-premises network is connected to AWS. Under strict compliance guidelines, DNS queries for the shared internal domain `corp.local` must remain private. A Route 53 Private Hosted Zone (PHZ) for `corp.local` is hosted in a central Shared Services account. To enable a production VPC in a separate AWS account to resolve domain names in `corp.local` without exposing the records publicly, which configuration is required?

Show answer & explanation

Answer: Authorize the association of the Private Hosted Zone with the production VPC from the Shared Services account, and then associate the production VPC with the Private Hosted Zone from the production account.

Answer

To resolve the Private Hosted Zone in a cross-account VPC, the owner account must authorize the association, and the consumer account must then associate the VPC with the Private Hosted Zone.
The correct approach is to authorize the association of the Private Hosted Zone with the production VPC from the Shared Services account, and then associate the production VPC with the Private Hosted Zone from the production account. This allows the production VPC to resolve queries in the Private Hosted Zone directly.

Step-by-Step Solution

1
Authorize the VPC association from the Shared Services account.
An authorization is created allowing the production VPC to associate with the hosted zone.
Cross-account VPC associations are not permitted by default and must be explicitly authorized by the owner of the Private Hosted Zone.
2
Associate the production VPC with the Private Hosted Zone from the production account.
The production VPC is associated with the Private Hosted Zone.
Once authorized, the consumer VPC owner must submit the association request to complete the link.

Key Concept

Cross-account Private Hosted Zone association in Route 53
Estimated Time:2m 0s
Question 447Question →

A healthcare enterprise is migrating its legacy systems to AWS. The architecture consists of an AWS Organization with a Shared Services VPC in Account A and an Application VPC in Account B. Both VPCs are connected to the on-premises data center via an AWS Transit Gateway and AWS Direct Connect. In Account A, a Route 53 Private Hosted Zone (PHZ) for corp.internal is hosted. The on-premises DNS servers manage the onprem.internal domain. The company needs to establish a DNS resolution strategy where:
1. Resources in the Application VPC can resolve names in corp.internal.
2. On-premises servers can resolve names in corp.internal.
3. Resources in both VPCs can resolve names in onprem.internal.

Which DNS architecture strategy should a Solutions Architect implement to meet these requirements?

Show answer & explanation

Answer: In Account A, submit a cross-account Private Hosted Zone association authorization for Account B's VPC, and then associate the VPC with the corp.internal zone in Account B. Create Route 53 Resolver inbound and outbound endpoints in Account A's VPC. Create a Route 53 Resolver forwarding rule for onprem.internal pointing to on-premises DNS servers, share this rule with Account B using AWS Resource Access Manager, and associate the rule with the VPCs in both accounts. Configure on-premises DNS servers to forward queries for corp.internal to the inbound endpoint IP addresses.

Answer

The correct approach requires authorizing and associating the private hosted zone across accounts, sharing the resolver forwarding rule via AWS Resource Access Manager, and using inbound and outbound endpoints for hybrid DNS resolution.
The correct strategy involves establishing a cross-account Private Hosted Zone association between the zone in Account A and the VPC in Account B. Additionally, deploying Route 53 Resolver Inbound Endpoints in the Shared Services VPC allows on-premises systems to resolve corp.internal by forwarding queries to the inbound endpoint IPs. Deploying Route 53 Resolver Outbound Endpoints in Account A's VPC enables AWS VPCs to forward queries for onprem.internal to the on-premises DNS servers. By sharing this forwarding rule via AWS Resource Access Manager (RAM) with Account B, both accounts can associate their VPCs with the rule and resolve on-premises addresses.

Step-by-Step Solution

1
Authorize and associate the Private Hosted Zone cross-account.
Account B's VPC is associated with corp.internal.
This allows resources in Account B's VPC to resolve DNS records in the corp.internal hosted zone.
2
Create Route 53 Resolver Inbound and Outbound Endpoints in Account A.
DNS resolution paths are established to and from the on-premises network.
Inbound endpoints receive queries from on-premises, while outbound endpoints send queries to on-premises.
3
Create and share the Resolver Forwarding Rule for the on-premises domain.
The forwarding rule for onprem.internal is shared via AWS RAM and associated with both VPCs.
This ensures that both Account A and Account B VPCs can resolve onprem.internal addresses by forwarding queries to on-premises DNS servers.

Key Concept

Multi-Account and Hybrid DNS Architecture Strategy
Estimated Time:2m 0s
Question 448Question →

A solutions architect is designing a resource sharing strategy for a multi-account environment. The architect needs to share a custom VPC subnet from a central network account to a partner company's AWS account, which is not part of the architect's AWS Organization. The architect attempts to use AWS Resource Access Manager (RAM) to share the subnet, but the process fails. Which configuration change is required to successfully share this subnet?

Show answer & explanation

Answer: Enable sharing with principals outside your organization in the AWS Resource Access Manager settings, and then create the resource share specifying the partner's AWS account ID.

Answer

Enable sharing with principals outside your organization in the AWS Resource Access Manager settings, and then create the resource share specifying the partner's AWS account ID.
The correct answer is to enable sharing with principals outside the organization in the AWS Resource Access Manager settings, and then share the subnet by specifying the partner's account ID. By default, AWS RAM only permits sharing within the same AWS Organization to prevent data leakage. Enabling this setting allows the principal to share supported resources with external accounts.

Step-by-Step Solution

1
Identify the sharing boundary restriction.
The target partner account is outside the current AWS Organization.
AWS Resource Access Manager (RAM) restricts resource sharing to the organization boundary by default to prevent accidental external exposure.
2
Enable external sharing in the AWS RAM settings.
External sharing is enabled, allowing resources to be shared with any valid AWS account ID.
Before you can share resources with AWS accounts outside your organization, you must explicitly opt-in by enabling external sharing in the RAM settings.
3
Create the resource share in AWS RAM.
The subnet is successfully shared with the partner's AWS account ID.
With external sharing enabled, you can specify the individual AWS account ID of the partner to complete the resource share.

Key Concept

AWS Resource Access Manager (RAM) allows sharing AWS resources across accounts, but sharing outside the AWS Organization requires enabling external sharing in RAM settings.
Question 449Question →

An enterprise is designing a multi-account compliance structure within AWS Organizations consisting of 250 member accounts. The security team requires all member accounts to deliver AWS CloudTrail logs to a centralized Amazon S3 bucket in a dedicated Security account. The S3 bucket must be encrypted using an AWS KMS Customer Managed Key (CMK) managed by the security team. Furthermore, member accounts must be blocked from deleting the centralized logging resources or disabling CloudTrail. Which implementation strategy meets these requirements with the minimum operational overhead while adhering to the principle of least privilege?

Show answer & explanation

Answer: Attach an SCP at the Organization root that denies cloudtrail:StopLogging, cloudtrail:DeleteTrail, and s3:DeleteBucket. In the Security account, configure the centralized S3 bucket policy to allow s3:PutObject from cloudtrail.amazonaws.com with a condition for aws:PrincipalOrgID. Configure the KMS CMK key policy in the Security account to allow cloudtrail.amazonaws.com to perform kms:GenerateDataKey* and kms:DescribeKey operations with a condition checking that aws:SourceArn matches the organization's trails.

Answer

The correct strategy is to attach an SCP at the Organization root to deny disabling CloudTrail and deleting S3 resources. In the Security account, configure the S3 bucket policy to allow s3:PutObject from cloudtrail.amazonaws.com with an aws:PrincipalOrgID condition, and configure the Customer Managed Key policy to permit cloudtrail.amazonaws.com to perform kms:GenerateDataKey* and kms:DescribeKey operations restricted by the aws:SourceArn of the organization's trails.
The correct strategy combines SCPs, S3 bucket policies, and KMS CMK key policies to satisfy all requirements securely. The SCP enforces the guardrails at the Organization level, preventing any member account administrator from stopping the trail or deleting the logging resources. Since CloudTrail needs to write to a centralized bucket in a different account, the S3 bucket policy must allow `s3:PutObject` from the `cloudtrail.amazonaws.com` principal, limited to the organization by `aws:PrincipalOrgID`. Furthermore, because the bucket is encrypted with KMS, and default AWS-managed keys cannot be shared across accounts, a Customer Managed Key (CMK) must be used. Its key policy must explicitly allow the `cloudtrail.amazonaws.com` service principal to use `kms:GenerateDataKey*` and `kms:DescribeKey` to encrypt the logs before delivery.

Step-by-Step Solution

1
Enforce deletion and configuration guardrails at the Organization level.
Attach an SCP to the root of AWS Organizations to deny cloudtrail:StopLogging, cloudtrail:DeleteTrail, and s3:DeleteBucket.
This guarantees that no user or administrator in any member account can disable logging or delete the centralized S3 bucket resources.
2
Configure the centralized S3 bucket policy in the Security account to allow cross-account delivery.
Add an S3 bucket policy that allows s3:PutObject with the principal set to cloudtrail.amazonaws.com and a condition evaluating aws:PrincipalOrgID.
This allows the CloudTrail service writing on behalf of any account in the organization to deliver logs to the central bucket while blocking external accounts.
3
Set up a Customer Managed Key (CMK) for bucket encryption.
Create a symmetric Customer Managed Key in the Security account instead of using the AWS-managed aws/s3 key.
AWS-managed keys cannot be shared cross-account, meaning CloudTrail in member accounts would not be able to encrypt logs during delivery.
4
Configure the CMK key policy to authorize CloudTrail.
Grant the cloudtrail.amazonaws.com principal permissions to perform kms:GenerateDataKey* and kms:DescribeKey, restricted by the aws:SourceArn condition.
This allows CloudTrail to encrypt logs using the CMK before writing them to the S3 bucket, preventing access denial failures.

Key Concept

Cross-account centralized CloudTrail logging requires a combination of organizational SCP guardrails, resource-level S3 bucket policies, and Customer Managed Keys (CMKs) with explicit service principal delegations.
Estimated Time:3m 0s
Question 450Question →

An enterprise manages its multi-account environment using AWS Organizations. Users authenticate using a corporate SAML 2.0 Identity Provider (IdP) federated with a central Identity AWS account. From the Identity account, administrators use cross-account IAM roles to access target member accounts. A team of engineers requires continuous access to database migration tools in a specific member account for up to 8 hours. The Solutions Architect configures the maximum session duration for the cross-account role in the member account to 12 hours. However, engineers find that their sessions consistently expire and terminate after exactly 1 hour. Which solution should the Solutions Architect implement to allow the engineers to work uninterrupted for the required 8 hours?

Show answer & explanation

Answer: Implement AWS IAM Identity Center integrated with the corporate IdP, create a permission set configured with an 8-hour session duration, and assign it to the engineers' group for the target member account.

Answer

Implement AWS IAM Identity Center integrated with the corporate IdP, create a permission set configured with an 8-hour session duration, and assign it to the engineers' group for the target member account.
The correct answer is to implement AWS IAM Identity Center integrated with the corporate IdP, configure a permission set with an 8-hour session duration, and assign it to the target account. This works because AWS IAM Identity Center handles federation directly to target accounts and provisions local roles without relying on cross-account role chaining. Consequently, the session duration defined in the permission set (up to 12 hours) is fully honored.

Step-by-Step Solution

1
Analyze the current multi-account federation pattern.
Identify that users federate into a central Identity account and then perform cross-account role assumption to access target member accounts.
This establishes that the flow relies on role chaining (assuming one role from another assumed-role session).
2
Evaluate the session duration limitations of the role-chaining pattern.
Confirm that when assuming a role from an assumed-role session (role chaining), AWS enforces a hard limit of 1 hour on the session duration.
This explains why the session expires after 1 hour despite the target role's Maximum Session Duration being configured to 12 hours.
3
Identify a solution that avoids role-chaining limitations.
Select AWS IAM Identity Center (successor to AWS Single Sign-On) integrated with the corporate IdP.
IAM Identity Center directly provisions roles in the member accounts and federates users into those accounts. Because it does not use role chaining, it honors the session duration configured in the permission set (up to 12 hours).

Key Concept

AWS STS Role Chaining Session Duration Limits and Multi-Account Federation Patterns
Question 451Question →

A multinational financial corporation has established a multi-account AWS environment using AWS Organizations. A Shared Services account contains a central VPC (vpc−sharedvpc-shared, CIDR 10.100.0.0/1610.100.0.0/16) and hosts a Route 53 Private Hosted Zone (PHZ) for the domain corp.internalcorp.internal. A Production account contains a core workload VPC (vpc−prodvpc-prod, CIDR 10.200.0.0/1610.200.0.0/16). Both VPCs are interconnected via an AWS Transit Gateway. The on-premises corporate network is connected to the Transit Gateway using AWS Direct Connect with a Transit VIF and utilizes local DNS servers at 192.168.10.10192.168.10.10 and 192.168.10.11192.168.10.11 for the domain onprem.internalonprem.internal.

The company requires name resolution between vpc−prodvpc-prod and onprem.internalonprem.internal, and also requires that resources in both vpc−prodvpc-prod and on-premises resolve records in corp.internalcorp.internal. The solution must minimize costs and administrative overhead by avoiding redundant endpoints.

Which design strategy should a solutions architect implement to meet these requirements?

Show answer & explanation

Answer: In the Shared Services account, authorize the association of the private hosted zone with the production VPC. In the Production account, associate the production VPC with the private hosted zone. Create Route 53 Resolver inbound and outbound endpoints in the shared services VPC. In the Shared Services account, create a Resolver forwarding rule for the on-premises domain pointing to the on-premises DNS servers, share this rule with the Production account via AWS Resource Access Manager (RAM), and associate it with the production VPC. Configure the on-premises DNS servers to forward queries for the corporate domain to the inbound endpoint IP addresses.

Answer

The correct strategy is to authorize the association of the Private Hosted Zone with the production VPC cross-account, associate them, centralize Route 53 Resolver inbound and outbound endpoints in the shared services VPC, create a forwarding rule for the on-premises domain and share it using AWS Resource Access Manager (RAM), and forward on-premises queries to the inbound endpoints.
The correct strategy leverages the cross-account VPC association API to link the Private Hosted Zone (PHZ) in the Shared Services account to the production VPC, ensuring local resolution. It optimizes cost by centralizing Route 53 Resolver endpoints in the shared services VPC, using AWS RAM to share the outbound resolver rules with the Production account. Lastly, it resolves the reachability constraint from on-premises by utilizing Route 53 Resolver inbound endpoints to accept queries from the corporate network over the Direct Connect transit connection.

Step-by-Step Solution

1
Authorize the association of the Route 53 Private Hosted Zone (PHZ) in the Shared Services account with the VPC in the Production account using the Route 53 API (create-vpc-association-authorization).
The Production account VPC is authorized to associate with the PHZ.
Route 53 Private Hosted Zones cannot be shared using AWS Resource Access Manager (RAM); cross-account association is the required mechanism to allow the production VPC to resolve the corporate domain locally without extra network hops.
2
Associate the production VPC with the Private Hosted Zone from the Production account using the Route 53 API (associate-vpc-with-hosted-zone).
Resources inside the production VPC can now resolve the corporate domain directly.
This establishes the logical link between the production VPC and the private DNS records hosted in the Shared Services account.
3
Deploy Route 53 Resolver outbound endpoints in the shared services VPC, create a forwarding rule for the on-premises domain pointing to the on-premises DNS servers, and share the rule with the Production account using AWS Resource Access Manager (RAM).
The production VPC can resolve on-premises domains using the shared rule.
Centralizing outbound endpoints in the shared services VPC and sharing rules via RAM avoids deploying duplicate outbound endpoints in the Production account, minimizing operational complexity and hourly endpoint charges.
4
Deploy Route 53 Resolver inbound endpoints in the shared services VPC and configure the on-premises DNS forwarders to target these inbound endpoint IP addresses for the corporate domain.
On-premises resources can resolve the corporate domain records.
The default Route 53 Resolver IP address (the default gateway IP plus two) only accepts queries originating within the local VPC. To resolve names from on-premises over Direct Connect, queries must be directed to an inbound endpoint.

Key Concept

Multi-Account and Hybrid Route 53 Resolver Architecture
Question 452Question →

An enterprise is designing a multi-account architecture on AWS using AWS Organizations. The network engineering team has created a central transit VPC in a dedicated Network account and needs to share specific private subnets with application development teams in separate accounts. The application teams must be able to deploy Amazon EC2 instances and AWS Fargate tasks into these shared subnets but must not be allowed to modify VPC resources.

The finance department wants to maximize cost savings across all EC2, Fargate, and AWS Lambda workloads across all accounts under consolidated billing. Additionally, security compliance dictates that all application logs must be centrally written to a single Amazon S3 bucket in a Security account, encrypted using a customer-managed KMS key, and no member account should be able to alter the central logging configuration.

Which architectural strategy should a Solutions Architect recommend to meet these requirements?

Show answer & explanation

Answer: Enable sharing within AWS Organizations in the AWS Resource Access Manager (RAM) console. In the Network account, create a resource share for the subnets and associate it with the target OUs. Purchase Compute Savings Plans in the consolidated billing management account. In the Security account, configure an S3 bucket policy allowing s3:PutObject from the Organization's member accounts, and create a KMS Customer Managed Key (CMK) with a key policy allowing the member accounts' IAM roles kms:GenerateDataKey and kms:Decrypt permissions.

Answer

Enable sharing within AWS Organizations, share the subnets via AWS RAM to the target OUs, purchase Compute Savings Plans, configure S3 bucket policies for member account access, and create a customer managed KMS key with a key policy allowing cross-account access.
The correct strategy uses AWS Resource Access Manager (RAM) with organization sharing enabled to securely distribute subnets to target OUs. It uses Compute Savings Plans to cover the diverse compute portfolio of EC2, Fargate, and Lambda. Finally, it uses a Customer Managed Key (CMK) in the Security account with a key policy allowing kms:GenerateDataKey and kms:Decrypt alongside S3 bucket policies, which is the only valid way to handle cross-account KMS-encrypted writes.

Step-by-Step Solution

1
Configure AWS RAM to share subnets.
Enable organization-wide sharing in AWS RAM, then create a resource share in the Network account pointing to the private subnets and target the application OUs.
This grants application accounts the ability to deploy instances and tasks into the subnets without giving them administrative privileges over the VPC structure.
2
Select the correct cost optimization model.
Purchase Compute Savings Plans in the management account of the AWS Organization.
Compute Savings Plans are required to cover compute usage across EC2, Fargate, and Lambda dynamically, whereas EC2 Instance Savings Plans are restricted to EC2.
3
Establish secure cross-account logging and encryption.
Create an S3 bucket in the Security account with a bucket policy allowing s3:PutObject from the organization. Encrypt the bucket with a Customer Managed Key (CMK), configuring its key policy to allow member accounts kms:GenerateDataKey access.
AWS-managed KMS keys cannot be shared cross-account, so a CMK is required. Both the bucket policy and the key policy must grant permissions for cross-account S3 KMS writes.

Key Concept

Billing, Cost Management, and Resource Sharing Strategy
Estimated Time:2m 30s
Question 453Question →

An enterprise manages a multi-account environment using AWS Organizations with consolidated billing. A solutions architect is designing a shared networking and security architecture with the following requirements:
* Subnets from a single VPC in a central Network account must be shared with multiple Application accounts inside specific Organizational Units (OUs) to run a combination of Amazon EC2 instances and AWS Fargate tasks.
* All Amazon EBS volumes launched within the Application accounts must be encrypted at rest using a Key Management Service (KMS) key managed in a centralized Shared Services account.
* API activity across all organizational accounts must be logged to a central S3 bucket in a Security account using an organizational trail.
* The enterprise wants to maximize discount coverage across both the EC2 instances and Fargate tasks.

Which of the following strategies should the solutions architect implement?

Show answer & explanation

Answer: Enable sharing with AWS Organizations in AWS Resource Access Manager (RAM). In the Network account, create a resource share for the subnets and associate it with the Application OUs. In the Shared Services account, create a Customer Managed Key (CMK) and configure its key policy to allow the Application accounts' IAM roles to perform key operations and create grants. In the Security account, configure the S3 bucket policy to allow the cloudtrail.amazonaws.com service principal to perform s3:PutObject with a condition matching aws:PrincipalOrgID. Purchase Compute Savings Plans in the Management account.

Answer

The correct strategy involves enabling Organization sharing in RAM to share subnets, creating a Customer Managed Key (CMK) in the Shared Services account with key policy delegations, using an S3 bucket policy in the Security account to permit the CloudTrail service principal to perform write operations, and purchasing Compute Savings Plans to cover both EC2 and Fargate workloads.
The correct strategy correctly integrates AWS RAM subnet sharing with Customer Managed Keys (CMKs) for cross-account EBS encryption, sets up a secure S3 bucket policy allowing cross-account CloudTrail log delivery from the organization, and uses Compute Savings Plans to cover both EC2 and Fargate compute costs.

Step-by-Step Solution

1
Configure subnet sharing using AWS Resource Access Manager (RAM).
AWS Organizations sharing is enabled in RAM, allowing the Network account to share its subnets with the target application OUs.
VPC sharing via RAM requires organization-level sharing to be enabled to target OUs or the entire organization.
2
Set up centralized cross-account EBS encryption.
A Customer Managed Key (CMK) is created in the Shared Services account, with a key policy allowing spoke accounts to perform cryptographic operations and create grants.
AWS-managed keys (like aws/ebs) cannot be shared across accounts or have their policies modified, meaning a custom CMK is required for cross-account KMS delegation.
3
Configure the central S3 bucket policy for organizational CloudTrail logging.
An S3 bucket policy is configured in the Security account allowing the cloudtrail.amazonaws.com service principal to write logs, restricted by the aws:PrincipalOrgID condition.
CloudTrail writes logs directly to the target bucket using its service principal, so a resource-based S3 bucket policy must grant cross-account write permissions.
4
Purchase the correct Savings Plan type in the management account.
Compute Savings Plans are purchased to maximize cost savings across both EC2 and Fargate tasks.
Compute Savings Plans apply to EC2, Fargate, and Lambda, whereas EC2 Instance Savings Plans only apply to EC2 instances, leaving Fargate tasks uncovered.

Key Concept

Multi-account resource sharing, cross-account KMS access control, centralized S3 logging for CloudTrail, and compute cost optimization strategy.
Question 454Question →

An enterprise is designing a multi-account AWS environment with 2020 spoke VPCs in the `us-east-1` Region across multiple AWS accounts under an AWS Organization. The network requirements are:

- Low-latency, bi-directional network communication between all spoke VPCs.
- Hybrid connectivity to an on-premises datacenter via an AWS Direct Connect connection with a speed of 10 Gbps10\text{ Gbps}.
- Centralized, highly available internet egress filtering for all spoke VPCs to download software patches.
- DNS resolution of a shared services domain (`corp.internal`) hosted in a central Network services account.

Which architecture should a solutions architect design to meet these requirements while ensuring high availability, scalable routing, and proper DNS resolution?

Show answer & explanation

Answer: Create an AWS Transit Gateway (TGW) in the Network services account, share it with the spoke accounts using AWS Resource Access Manager (RAM), and attach all spoke VPCs to the TGW. Associate the TGW with an AWS Direct Connect Gateway (DXGW) using a Transit Virtual Interface (Transit VIF). Deploy a centralized egress VPC with NAT Gateways in multiple Availability Zones attached to the TGW. Create a Route 53 Private Hosted Zone (PHZ) for `corp.internal` in the Network account, and associate the PHZ with the spoke VPCs in all accounts using cross-account VPC association authorizations.

Answer

The correct architecture uses AWS Transit Gateway to route traffic between spoke VPCs and hybrid locations, employs a centralized egress VPC with NAT Gateways in multiple Availability Zones for highly available internet egress, and associates the Route 53 Private Hosted Zone in the central account with all spoke VPCs using cross-account VPC authorizations.
The correct architecture uses AWS Transit Gateway to achieve transitive inter-VPC and hybrid routing, while integrating a centralized egress VPC with redundant NAT Gateways across multiple Availability Zones to prevent a single point of failure. It also ensures that the central Private Hosted Zone is explicitly associated with all spoke VPCs using cross-account VPC association authorizations.

Step-by-Step Solution

1
Evaluate routing options for inter-VPC and hybrid connectivity.
Identify that AWS Transit Gateway is required to enable scalable, low-latency, transitive routing between the spoke VPCs and the on-premises datacenter via a Direct Connect Gateway.
Direct Connect Gateway alone does not support transitive VPC-to-VPC routing.
2
Select Direct Connect Gateway attachment type for hybrid networking.
Associate the Direct Connect Gateway with the Transit Gateway using a Transit Virtual Interface (Transit VIF).
A Transit VIF is required to connect a Direct Connect connection to an AWS Transit Gateway.
3
Configure centralized internet egress with redundancy.
Establish an egress VPC with NAT Gateways distributed across multiple Availability Zones connected to the Transit Gateway.
Deploying NAT Gateways in multiple AZs ensures that there is no single point of failure for outbound traffic across all spoke VPCs.
4
Configure DNS resolution for the shared services domain.
Create a Route 53 Private Hosted Zone in the central account and associate it with the spoke VPCs across all accounts via cross-account VPC association authorizations.
Private Hosted Zones are not automatically shared over Transit Gateway attachments, so explicit cross-account association is mandatory.

Key Concept

Multi-account and hybrid network routing with Transit Gateway, Direct Connect Gateway, redundant centralized egress, and cross-account Private Hosted Zone association.
Estimated Time:3m 0s
Question 455Question →

A health-tech corporation is migrating its legacy pharmacy management system to AWS. The multi-account architecture is managed under AWS Organizations. A central Core Services account hosts a Shared Services VPC, which is connected to an on-premises data center via an AWS Direct Connect connection and an AWS Transit Gateway. The Shared Services VPC contains Route 53 Resolver Inbound and Outbound Endpoints. A Route 53 Private Hosted Zone (PHZ) named pharmacy.internal is created in the Core Services account. The production workloads are deployed in a Production VPC within a separate Production account, connected to the Shared Services VPC via the same Transit Gateway. On-premises clients must be able to resolve records in pharmacy.internal. EC2 instances in the Production VPC must be able to resolve records in pharmacy.internal and on-premises DNS records in the corp.local domain. Which configuration will meet these requirements with the least administrative overhead while ensuring that DNS traffic does not traverse the public internet?

Show answer & explanation

Answer: In the Core Services account, authorize the association of the pharmacy.internal PHZ with the Production VPC, and then associate the PHZ from the Production account. Configure on-premises DNS servers to forward queries for pharmacy.internal to the Inbound Resolver Endpoint IP addresses in the Shared Services VPC. In the Core Services account, create a Route 53 Resolver Outbound rule for corp.local pointing to the on-premises DNS servers, share this rule with the Production account using AWS Resource Access Manager (RAM), and associate the shared rule with the Production VPC.

Answer

In the Core Services account, authorize the association of the private hosted zone with the Production VPC, and then associate the zone from the Production account. Configure on-premises DNS servers to forward queries for the private zone to the Inbound Resolver Endpoint in the Shared Services VPC. Create an Outbound Resolver rule for the on-premises domain in the Core Services account, share it via AWS Resource Access Manager (RAM), and associate it with the Production VPC.
The correct configuration uses cross-account Private Hosted Zone association to allow the Production VPC to resolve the zone. Hybrid resolution is achieved by pointing on-premises DNS forwarders to the Route 53 Resolver Inbound Endpoint in the Shared Services VPC. For outbound resolution to on-premises, a Route 53 Resolver Outbound rule is created centrally in the Core Services account, shared via AWS RAM, and associated with the Production VPC.

Step-by-Step Solution

1
Authorize the Private Hosted Zone association from the Core Services account to the Production VPC using the AWS CLI or SDK, and then associate the zone from the Production account.
The Production VPC is associated with the pharmacy.internal Private Hosted Zone, enabling native resolution within the VPC.
Cross-account private hosted zone association is required because Private Hosted Zones cannot be directly associated across accounts via the AWS Console or shared via AWS RAM.
2
Configure the on-premises DNS servers to forward queries for the pharmacy.internal domain to the Inbound Resolver Endpoint IP addresses in the Shared Services VPC.
On-premises clients can resolve names in the pharmacy.internal domain over the Direct Connect connection.
The Inbound Resolver Endpoint is associated with the Shared Services VPC, which can resolve the Private Hosted Zone.
3
Create a Route 53 Resolver Outbound rule for corp.local in the Core Services account, pointing to the on-premises DNS servers. Share this rule with the Production account via AWS RAM, and associate it with the Production VPC.
EC2 instances in the Production VPC can resolve on-premises domains using the shared rule and the central Outbound Resolver Endpoint.
Sharing the Outbound Resolver rule avoids the cost and administrative overhead of deploying separate Outbound Resolver Endpoints in every consumer VPC.

Key Concept

Centralized Hybrid and Cross-Account Route 53 Resolver and Private Hosted Zone Architecture
Estimated Time:3m 0s
Question 456Question →

A health-tech company has a multi-account AWS environment connected to an on-premises data center via AWS Transit Gateway. The Shared Services account hosts a Route 53 Private Hosted Zone (PHZ) named corp.internal that is associated with the Shared Services VPC. Applications in the Production VPC and servers in the on-premises data center must resolve domain names in corp.internal. Which actions should a Solutions Architect take to enable this DNS resolution? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Submit a cross-account private hosted zone association authorization from the Shared Services account for the Production VPC, and then associate the VPC using the Production account's credentials.; Deploy a Route 53 Resolver inbound endpoint in the Shared Services VPC, and configure the on-premises DNS servers to forward queries for corp.internal to the inbound endpoint IP addresses.

Answer

Submit a cross-account private hosted zone association authorization from the Shared Services account for the Production VPC, then associate the VPC using the Production account's credentials, and deploy a Route 53 Resolver inbound endpoint in the Shared Services VPC while configuring the on-premises DNS servers to forward queries to the inbound endpoint IP addresses.
Enabling cross-account resolution of a Private Hosted Zone requires creating an association authorization from the zone owner account and then associating the consumer VPC from its own account. Enabling on-premises resolution of the same private zone requires setting up a Route 53 Resolver inbound endpoint in a VPC associated with the zone and forwarding on-premises DNS queries to the inbound endpoint's IP addresses.

Step-by-Step Solution

1
Authorize cross-account association of the Private Hosted Zone.
The Production VPC is authorized to associate with the corp.internal Private Hosted Zone hosted in the Shared Services account.
VPCs in other accounts cannot resolve resources in a Private Hosted Zone without a direct VPC association, which requires a cross-account authorization step.
2
Associate the Production VPC with the Private Hosted Zone.
The Production VPC is associated with the corp.internal Private Hosted Zone.
This allows resources in the Production VPC to resolve DNS queries using the Private Hosted Zone's records.
3
Set up a Route 53 Resolver inbound endpoint in the Shared Services VPC.
An inbound endpoint is created with IP addresses in the Shared Services VPC.
This endpoint receives DNS queries from the on-premises DNS servers over the Transit Gateway connection.
4
Configure on-premises forwarders.
On-premises DNS servers are configured to forward corp.internal queries to the inbound endpoint IP addresses.
This ensures queries originating from on-premises for the corp.internal domain are routed to AWS Route 53 Resolver.

Key Concept

Multi-Account and Hybrid DNS resolution using Route 53 Private Hosted Zones, cross-account associations, and Route 53 Resolver inbound endpoints.
Question 457Question →

A company is designing a multi-account strategy using AWS Organizations. The solutions architect needs to share specific VPC subnets from a central network account with application accounts, and also wants to ensure that compute discounts are shared globally across all member accounts to optimize costs. Which of the following actions should the solutions architect take to meet these requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Enable resource sharing within AWS Organizations in the AWS Resource Access Manager (RAM) settings, and share the VPC subnets with the organization or specific organizational units.; Enable consolidated billing under AWS Organizations, allowing Compute Savings Plans purchased in the management account to apply to eligible compute usage across all member accounts.

Answer

Enable resource sharing within AWS Organizations in the AWS Resource Access Manager (RAM) settings, and enable consolidated billing under AWS Organizations to share Compute Savings Plans across member accounts.
To share subnets across accounts in the organization, the integration between AWS Resource Access Manager (RAM) and AWS Organizations must be enabled. Additionally, to leverage compute discount benefits globally, consolidated billing should be configured, allowing Compute Savings Plans to automatically apply to eligible EC2, Fargate, and Lambda usage across all member accounts under the billing family.

Step-by-Step Solution

1
Enable AWS Organizations integration within AWS Resource Access Manager (RAM) in the management account.
This allows subnets to be shared with organizational units or the entire organization without requiring individual handshakes.
VPC subnet sharing via RAM requires AWS Organizations integration to be enabled for seamless intra-org sharing.
2
Configure Consolidated Billing in AWS Organizations and purchase Compute Savings Plans.
Aggregated billing enables cost benefits to flow down, allowing Compute Savings Plans purchased in the management account to apply to eligible EC2, Fargate, and Lambda instances across all member accounts.
Compute Savings Plans provide the flexibility to cover multiple compute services across the entire organization.

Key Concept

AWS RAM subnet sharing and organization-wide application of Compute Savings Plans
Question 458Question →

An enterprise is establishing a secure, automated multi-account landing zone using AWS Organizations and AWS Control Tower. The solutions architect needs to design a governance structure that automatically deploys custom Service Control Policies (SCPs) and baseline resources to all new accounts, while securing federated access for developers.

Arrange the following steps in the correct chronological sequence to implement this governance architecture from scratch according to AWS best practices.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct chronological sequence is: first launch AWS Control Tower to set up the landing zone; second, define the workload Organizational Units; third, deploy the Customizations for AWS Control Tower (CfCT) pipeline; fourth, provision member accounts via the Account Factory; and fifth, configure and map AWS IAM Identity Center permissions to the newly created accounts.
The correct sequence starts with launching AWS Control Tower to initialize the landing zone and establish the core logging and security accounts. Next, custom OUs must be created in AWS Organizations to house future workloads. Then, the CfCT framework is deployed so it is active and ready to handle account lifecycle events. Afterwards, accounts are provisioned or enrolled via Account Factory, automatically receiving CfCT customizations. Finally, IAM Identity Center is configured to grant users federated access to the newly active accounts.

Step-by-Step Solution

1
Initialize AWS Control Tower
The AWS Organizations management structure is configured, and the core Log Archive and Audit accounts are created.
This establishes the control plane and foundational account structure required for all subsequent steps.
2
Create Custom Organizational Units (OUs)
A structured OU hierarchy is established to group workloads based on security and operational requirements.
Target OUs must exist before we can attach policies or enroll member accounts into them.
3
Deploy Customizations for AWS Control Tower (CfCT)
A pipeline is deployed in the management account that listens to Control Tower lifecycle events.
Deploying CfCT beforehand ensures that custom resources and guardrails are automatically deployed when new accounts are provisioned.
4
Provision/Enroll Accounts
Member accounts are successfully created under the correct OUs and automatically receive custom baselines via CfCT.
Account provisioning triggers lifecycle events, prompting the CfCT pipeline to configure the new accounts.
5
Assign Federated Access
Users can federate into the new accounts with appropriate roles and permission sets.
Access assignments require the target account IDs and OUs to be fully active and provisioned.

Key Concept

Establishing multi-account governance using AWS Organizations, AWS Control Tower, CfCT customization pipeline, and AWS IAM Identity Center.
Estimated Time:3m 0s
Question 459Question →

A solutions architect is establishing a multi-account governance structure using AWS Organizations. The security architecture requires that corporate permission guardrails are active and applied to all member accounts immediately upon their inclusion in the organization, preventing any temporary window of non-compliance. What is the correct sequence of steps to configure this organizational structure?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence is to first enable AWS Organizations, design and create the Organizational Unit hierarchy, author the Service Control Policies, attach these policies to the target Organizational Units, and finally provision or move member accounts into their respective Organizational Units.
The correct order establishes the management boundary (AWS Organizations), creates the logical containment structure (OUs), authors the policy guardrails (SCPs), applies the policies to the containers (OUs), and finally populates the containers with member accounts. This workflow ensures that no account exists in an OU without the governance policy already active and inherited, eliminating any window of vulnerability.

Step-by-Step Solution

1
Enable AWS Organizations.
The multi-account organization is initialized and the management account is established.
An organization must exist to act as the boundary for OUs, accounts, and policies.
2
Create Organizational Units (OUs).
Logical grouping containers are established within the organization.
OUs act as the logical target for policy application and account segregation.
3
Author Service Control Policies (SCPs).
SCPs are saved as policy documents in the management account.
SCPs must be defined in the organization before they can be attached to containers.
4
Attach SCPs to OUs.
Guardrails are active on the OUs.
Attaching SCPs to OUs before moving accounts ensures that security guardrails are applied immediately on account entry, avoiding any security gaps.
5
Move or provision accounts into OUs.
Accounts are active and governed by the inherited SCPs.
Member accounts inherit the policies attached to their parent OUs instantly, ensuring compliance from day one.

Key Concept

Enforcing immediate policy inheritance in AWS Organizations by attaching Service Control Policies (SCPs) to Organizational Units (OUs) prior to moving or provisioning member accounts.
Estimated Time:2m 0s
Question 460Question →

An enterprise is implementing a multi-account AWS architecture with a hub-and-spoke transit network design using AWS Transit Gateway in the us-east-1 Region. The network consists of 80 spoke VPCs (aggregating under the 10.128.0.0/9 CIDR block) and a centralized Inspection VPC (10.0.0.0/16) containing a cluster of next-generation firewalls behind an AWS Gateway Load Balancer (GWLB). The security policy requires that all traffic between the spoke VPCs (east-west traffic) and all traffic from the spoke VPCs to the internet (north-south traffic) must be inspected by the firewall cluster. Outbound internet egress must occur via NAT Gateways deployed inside the Inspection VPC. The spoke VPCs must not have direct paths to the internet or to each other. Which routing configuration on the AWS Transit Gateway and within the Inspection VPC correctly implements this architecture while preventing routing loops and ensuring all spoke-to-spoke and egress traffic is inspected?

Show answer & explanation

Answer: On the Transit Gateway, create two route tables: Spoke-RT and Inspection-RT. Associate all spoke VPC attachments with Spoke-RT, disable route propagation from the spoke VPCs, and add a static route for 0.0.0.0/0 pointing to the Inspection VPC attachment. Associate the Inspection VPC attachment with Inspection-RT and enable route propagation from all spoke VPC attachments. Within the Inspection VPC, configure the Transit Gateway subnet route table to route 0.0.0.0/0 to the Gateway Load Balancer endpoint (GWLBe) in the same Availability Zone. Configure the GWLBe subnet route table to route 10.128.0.0/9 to the Transit Gateway and 0.0.0.0/0 to the NAT Gateway.

Answer

Associate spoke attachments with a non-propagating route table that has a static default route to the Inspection VPC. Associate the Inspection VPC attachment with a separate route table that has route propagation enabled from the spoke VPCs. Inside the Inspection VPC, configure the TGW subnet to route to the GWLBe, and the GWLBe subnet to route 10.128.0.0/9 to the TGW and 0.0.0.0/0 to the NAT Gateway.
The correct routing pattern separates the inbound (spoke) and outbound (inspection return) traffic paths on the Transit Gateway using two distinct route tables (Spoke-RT and Inspection-RT). By disabling propagation on Spoke-RT and adding a static default route to the Inspection VPC, all traffic is forced through the firewalls. Associating the Inspection VPC attachment with Inspection-RT (which has propagation enabled) allows the Transit Gateway to route inspected traffic to the final spoke destination. Within the Inspection VPC, separate subnet route tables for the TGW attachment and GWLBe subnets prevent loops by ensuring that incoming traffic is sent to the firewall, while inspected traffic is either returned to the Transit Gateway (for spoke-to-spoke destinations) or sent to the NAT Gateways (for internet egress).

Step-by-Step Solution

1
Configure the Transit Gateway Spoke Route Table (Spoke-RT).
All traffic originating from spoke VPCs matches the static 0.0.0.0/0 route pointing to the Inspection VPC attachment.
By disabling route propagation on Spoke-RT, we prevent the Transit Gateway from learning specific spoke CIDRs, ensuring that both spoke-to-spoke and egress traffic are forced to the Inspection VPC instead of routing directly.
2
Configure the Transit Gateway Inspection Route Table (Inspection-RT).
The Inspection-RT learns all specific spoke VPC CIDRs through propagation.
This allows traffic that has been returned to the Transit Gateway from the Inspection VPC to be correctly routed to the destination spoke VPC.
3
Configure the Inspection VPC routing for incoming traffic.
Traffic arriving from the Transit Gateway at the TGW attachment subnet is routed to the local GWLBe.
This forwards all incoming packets to the Gateway Load Balancer and the associated firewall cluster for inspection.
4
Configure the Inspection VPC routing for post-inspection traffic.
Traffic returning to the GWLBe subnet is routed based on destination: 10.128.0.0/9 goes to the Transit Gateway, and 0.0.0.0/0 goes to the NAT Gateway.
This ensures that clean spoke-to-spoke traffic is sent back to the Transit Gateway to reach its destination, while clean internet-bound traffic is forwarded to the NAT Gateway for egress.

Key Concept

Centralized network security inspection using AWS Transit Gateway and Gateway Load Balancer (GWLB) with separate route tables to prevent routing loops.
PreviousPage 23 / 99Next
All practice questions — AWS Certified Solutions Architect - Professional | Examkin