All practice questions

1964 questions

All types1,964 Multiple choice1,006 Multiple select931 Ordering27

A company is setting up its multi-account structure in AWS Organizations. They have created a dedicated 'Security' Organizational Unit (OU) containing several member accounts. The security team wants to ensure that no IAM user or role within the member accounts, including the root user, can delete or disable AWS Config rules that are deployed for compliance monitoring. Which mechanism should the solutions architect use to enforce this restriction across the Organizational Unit (OU)?

Apply a Service Control Policy (SCP) with a Deny effect on AWS Config API actions at the Organizational Unit (OU) level.

Attach a Service Control Policy (SCP) to the Organizational Unit (OU) that explicitly grants Allow permissions for AWS Config actions to replace local IAM policies.

Configure an Amazon S3 bucket policy in a centralized security account to restrict all write and delete operations for the Config configuration recorder files.

Deploy an AWS KMS customer managed key to encrypt Config data and use the key policy to block all decryption requests from the member accounts.

Show answer & explanation

Answer: Apply a Service Control Policy (SCP) with a Deny effect on AWS Config API actions at the Organizational Unit (OU) level.

Answer

Apply a Service Control Policy (SCP) with a Deny effect on AWS Config API actions at the Organizational Unit (OU) level.

Applying a Service Control Policy (SCP) with a Deny effect at the Organizational Unit (OU) level enforces permission boundaries across all member accounts within that OU, including the root user. This prevents any IAM identity in those accounts from deleting or modifying AWS Config rules.

Step-by-Step Solution

Identify the requirement to enforce a multi-account compliance guardrail that overrides local administrative actions.

This requires a mechanism that operates at the AWS Organizations level, such as Service Control Policies (SCPs).

Local IAM policies and boundaries cannot prevent the root user or local administrators with FullAccess from disabling services.

Determine the correct policy type and scope for the guardrail.

Create an SCP with a Deny effect targeting Config actions (such as config:DeleteConfigRule and config:StopConfigurationRecorder) and attach it to the target OU.

SCPs apply to all users and roles in member accounts, including the root user, ensuring the constraint cannot be bypassed.

Key Concept

AWS Organizations Service Control Policies (SCPs) act as permission guardrails that restrict maximum available permissions in member accounts, overriding local administrators.

Question 522Question →

A solutions architect is managing a multi-account environment using AWS Organizations. The organizational unit (OU) hierarchy is structured as follows:

* Root
* Workloads (OU)
* Production (OU)
* Account-A (Production member account)

The security team has removed the default FullAWSAccess Service Control Policy (SCP) from both the Workloads and Production OUs to implement a custom allow-list model. The Root OU still has FullAWSAccess attached.

The following custom SCPs are attached:

SCP-1 (attached to Workloads OU):

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowCoreServices",
"Effect": "Allow",
"Action": [
"ec2:*",
"s3:*",
"iam:*",
"sts:*"
],
"Resource": "*"
}
]
}

SCP-2 (attached to Production OU):

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowStorageAndCompute",
"Effect": "Allow",
"Action": [
"ec2:*",
"s3:*"
],
"Resource": "*"
},
{
"Sid": "DenyUnsecureStorage",
"Effect": "Deny",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::*",
"Condition": {
"Bool": {
"aws:SecureTransport": "false"
}
}
}
]
}

In Account-A, an IAM user named PlatformAdmin has an IAM policy attached that grants administrator access ("Action": "*", "Resource": "*").

PlatformAdmin attempts to perform two actions in Account-A:
1. Create a new IAM role.
2. Upload a log file to an Amazon S3 bucket using HTTPS.

Which of the following describes the outcomes of these actions?

The IAM role creation fails because IAM actions are not allowed by the SCP at the Production OU level. The S3 bucket upload succeeds because S3 actions are allowed by the SCPs at all levels and the secure transport condition in the Deny statement is not met.

Both actions succeed because the local IAM policy grants full administrator access, and there is no explicit Deny statement for IAM actions in any of the attached SCPs.

Both actions fail because the default FullAWSAccess SCP was removed from the OUs, which implicitly denies all actions at the member account level unless the FullAWSAccess SCP is explicitly re-applied at the account level.

The IAM role creation succeeds because IAM actions are allowed by the SCP at the parent Workloads OU level. The S3 bucket upload fails because the Deny statement in SCP-2 blocks all S3 PutObject actions regardless of the transport protocol.

Show answer & explanation

Answer: The IAM role creation fails because IAM actions are not allowed by the SCP at the Production OU level. The S3 bucket upload succeeds because S3 actions are allowed by the SCPs at all levels and the secure transport condition in the Deny statement is not met.

Answer

The correct answer is that the IAM role creation fails while the S3 upload succeeds. In AWS Organizations, if the default FullAWSAccess SCP is detached to implement an allow-list strategy, any action must be allowed by SCPs at every node of the path from the Root to the member account. Since the Production OU SCP (SCP-2) only allows EC2 and S3 actions, the permission chain for IAM actions is broken, causing an implicit deny for the IAM role creation. S3 actions are allowed at all levels, and the explicit Deny statement for s3:PutObject in SCP-2 does not apply because the upload is performed securely via HTTPS, failing to trigger the condition where secure transport is false.

Step-by-Step Solution

Evaluate the permissions path for IAM role creation (iam:CreateRole).

Allowed at Root (FullAWSAccess) -> Allowed at Workloads OU (SCP-1 allows iam:*) -> NOT allowed at Production OU (SCP-2 does not allow iam:*) -> Implicitly Denied.

For any action to succeed in a member account, it must be explicitly allowed at every level of the Organization path from the Root down to the target account when the default FullAWSAccess SCP is not present.

Evaluate the permissions path for S3 bucket upload (s3:PutObject) over HTTPS.

Allowed at Root (FullAWSAccess) -> Allowed at Workloads OU (SCP-1 allows s3:*) -> Allowed at Production OU (SCP-2 allows s3:*).

Confirm that S3 actions are permitted across all OUs in the path.

Evaluate Deny statements in SCP-2 for the S3 bucket upload.

The Deny statement blocks s3:PutObject only when aws:SecureTransport is false. Since HTTPS is used, the condition is false, and the Deny is not applied.

Explicit Deny statements with conditions must be checked to ensure they do not override the allowed path.

Verify local IAM permissions in the member account.

PlatformAdmin has administrator access (*:*), which permits both IAM and S3 actions locally.

Local IAM policies must also grant the required permissions, as the final access is the intersection of SCPs and local IAM policies.

Key Concept

AWS Organizations Service Control Policies (SCPs) authorization boundary and inheritance behavior in an allow-list governance model.

Question 523Question →

A technology firm is configuring single sign-on access to its AWS member accounts using an external SAML 2.0 Identity Provider (IdP). An administrator has successfully configured the external IdP and created a SAML provider entity in the target AWS account. However, when users try to log in, they receive an error stating that the federated role cannot be assumed. Which configuration is required in the target AWS account to resolve this issue?

Configure the trust policy of the target IAM role to list the SAML provider's Amazon Resource Name (ARN) as the principal and specify the sts:AssumeRoleWithSAML action.

Configure the trust policy of the target IAM role to use the external IdP's metadata URL as the principal and specify the standard sts:AssumeRole action.

Attach a Service Control Policy (SCP) to the target account's Organizational Unit (OU) that explicitly grants sts:AssumeRoleWithSAML access to the external identity provider.

Configure the target IAM role's trust policy to trust the management account of the organization and use sts:AssumeRoleWithWebIdentity to federate the SAML users.

Show answer & explanation

Answer: Configure the trust policy of the target IAM role to list the SAML provider's Amazon Resource Name (ARN) as the principal and specify the sts:AssumeRoleWithSAML action.

Answer

Configure the trust policy of the target IAM role to list the SAML provider's Amazon Resource Name (ARN) as the principal and specify the sts:AssumeRoleWithSAML action.

The correct configuration is to define the trust relationship on the target IAM role to trust the SAML provider entity's Amazon Resource Name (ARN) in IAM, and to allow the sts:AssumeRoleWithSAML action. This allows the Security Token Service (STS) to validate the SAML assertion and issue temporary security credentials.

Step-by-Step Solution

Identify the authentication protocol being used.

SAML 2.0 protocol is used for federation.

Selecting the correct AWS Security Token Service (STS) action requires knowing whether SAML 2.0 or OIDC is in use.

Verify the role trust policy configuration requirements.

The target role trust policy must specify the SAML provider ARN as the principal and allow sts:AssumeRoleWithSAML.

This establishes trust between the external identity provider (represented by the SAML provider in IAM) and the IAM role that users will assume.

Key Concept

SAML 2.0 Identity Federation Trust Policies

Question 524Question →

A multinational corporation operates a multi-account AWS environment. VPCs in the 'us-east-1' region use the CIDR block $10.10.0.0/16$ , while VPCs in the 'us-west-2' region use the CIDR block $10.20.0.0/16$ . Each region has an AWS Transit Gateway (TGW) managing local VPC traffic, and the two TGWs are peered.

The company is setting up hybrid connectivity to its on-premises data center (CIDR $172.16.0.0/12$ ) with the following requirements:
- A $10\text{ Gbps}$ AWS Direct Connect (DX) connection with a Transit VIF terminates on a Direct Connect Gateway (DXGW) associated with the 'us-east-1' TGW. This is the primary path.
- An AWS Site-to-Site VPN connection is terminated on the 'us-west-2' TGW as a backup.
- Under normal operations, all traffic between both AWS regions and the data center must use the DX connection.
- If the DX connection or the 'us-east-1' TGW fails, all traffic must automatically fail over to the VPN connection.
- Active-active asymmetric routing must be prevented; the on-premises routers must prefer the DX path over the VPN path for all inbound AWS traffic.

Which two configurations should a solutions architect implement to meet these requirements? (Select TWO.)

Select all that apply

Associate the Direct Connect Gateway (DXGW) with both Transit Gateways. In each Transit Gateway route table, propagate the routes from both the DXGW attachment and the respective local Site-to-Site VPN attachment.

Use AWS Resource Access Manager (RAM) to share the Direct Connect Transit VIF directly with the spoke VPCs to bypass the Transit Gateways, and configure static route tables in the VPCs for failover.

Configure AS Path prepending on both AWS Site-to-Site VPN connections to advertise the local VPC CIDR with a longer AS path to the on-premises customer gateway.

Configure the customer gateway to advertise more specific subnets of the on-premises network (e.g.,

172.16.0.0/13

) over the VPN connection and a summary subnet (e.g.,

172.16.0.0/12

) over the Direct Connect connection.

Create a Route 53 Private Hosted Zone for the on-premises domain, associate it with all VPCs in both regions, and configure failover routing policies pointing to the VPN public IP addresses as the primary path.

Show answer & explanation

Answer: Associate the Direct Connect Gateway (DXGW) with both Transit Gateways. In each Transit Gateway route table, propagate the routes from both the DXGW attachment and the respective local Site-to-Site VPN attachment.; Configure AS Path prepending on both AWS Site-to-Site VPN connections to advertise the local VPC CIDR with a longer AS path to the on-premises customer gateway.

Answer

The correct configurations are: associating the Direct Connect Gateway (DXGW) with both Transit Gateways and propagating the routes from both the DXGW and VPN attachments; and configuring AS Path prepending on both AWS Site-to-Site VPN connections.

Associating the Direct Connect Gateway (DXGW) with both Transit Gateways and propagating the routes from both the DXGW attachment and the VPN attachment ensures that the Transit Gateways dynamically route outbound traffic. By default, Transit Gateway prefers Direct Connect over VPN when identical prefix lengths are propagated via BGP. Configuring AS Path prepending on the VPN connection causes the on-premises router to receive a longer AS path for VPN routes, forcing it to prefer the Direct Connect path for inbound traffic, thus preventing asymmetric routing.

Step-by-Step Solution

Analyze the path preference requirements from AWS to on-premises.

AWS Transit Gateway route evaluation order prefers Direct Connect Gateway propagated routes over VPN propagated routes for identical prefix lengths.

This allows for automatic, dynamic failover at Layer 3 without static routing or administrative overhead.

Establish DXGW associations for both regions.

Associate the DXGW with the TGW in 'us-east-1' and the TGW in 'us-west-2', enabling direct access to the DX connection from both regions.

This avoids routing 'us-west-2' traffic through the peered TGW to 'us-east-1' under normal operations, reducing cross-region transit charges and eliminating a single point of failure.

Configure path selection on-premises to prevent asymmetric routing.

Apply AS Path prepending on the Site-to-Site VPN connection on the AWS side.

By lengthening the AS Path advertised over the VPN, the customer gateway will prefer the shorter AS Path advertised via Direct Connect, ensuring symmetric routing over the primary link.

Key Concept

Redundant hybrid networking path selection using Direct Connect and VPN with AWS Transit Gateway, utilizing BGP AS Path prepending and TGW route preference rules.

Question 525Question →

An enterprise is designing a multi-account architecture on AWS using AWS Organizations. The company has a central Network account that hosts shared VPCs, a Security account for consolidated compliance monitoring, and multiple application accounts across different Organizational Units (OUs) that run workloads on Amazon EC2, AWS Fargate, and AWS Lambda. The solutions architect must implement a strategy to: 1. Share specific subnets from the Network account to the application accounts automatically as new accounts are vended, minimizing manual administrative overhead. 2. Deliver AWS CloudTrail logs from all accounts to a single S3 bucket in the Security account, ensuring the logs are encrypted at rest with a key that supports cross-account decryption. 3. Optimize compute costs across EC2, Fargate, and AWS Lambda workloads across all member accounts while utilizing consolidated billing. Which of the following strategies should the solutions architect implement to meet these requirements?

Enable resource sharing within the organization in AWS RAM from the management account. In the Network account, create a resource share for the subnets and associate it with the application OUs. In the Security account, create an S3 bucket encrypted with the default AWS-managed KMS key for S3 (aws/s3), and configure the S3 bucket policy to allow the CloudTrail service principal to write logs. Purchase Compute Savings Plans in the management account with discount sharing enabled.

In the Network account, create a resource share for the subnets and manually add the AWS account IDs of the application accounts to the share without enabling sharing within the organization in AWS RAM. In the Security account, create an S3 bucket encrypted with a Customer Managed Key (CMK), and configure both the CMK key policy and the S3 bucket policy to grant permission to the CloudTrail service principal for logging. Purchase Compute Savings Plans in the management account with discount sharing enabled.

Enable resource sharing within the organization in AWS RAM from the management account. In the Network account, create a resource share for the subnets and associate it with the application OUs. In the Security account, create an S3 bucket encrypted with a Customer Managed Key (CMK), and configure both the CMK key policy and the S3 bucket policy to grant permission to the CloudTrail service principal for logging. Purchase Compute Savings Plans in the management account with discount sharing enabled.

Enable resource sharing within the organization in AWS RAM from the management account. In the Network account, create a resource share for the subnets and associate it with the application OUs. In the Security account, create an S3 bucket encrypted with a Customer Managed Key (CMK), and configure both the CMK key policy and the S3 bucket policy to grant permission to the CloudTrail service principal for logging. Purchase EC2 Instance Savings Plans in the management account with discount sharing enabled.

Show answer & explanation

Answer: Enable resource sharing within the organization in AWS RAM from the management account. In the Network account, create a resource share for the subnets and associate it with the application OUs. In the Security account, create an S3 bucket encrypted with a Customer Managed Key (CMK), and configure both the CMK key policy and the S3 bucket policy to grant permission to the CloudTrail service principal for logging. Purchase Compute Savings Plans in the management account with discount sharing enabled.

Answer

The strategy that enables resource sharing within AWS Organizations, uses a Customer Managed Key (CMK) for the S3 bucket with key and bucket policies allowing CloudTrail access, and purchases Compute Savings Plans in the management account.

The correct strategy involves enabling resource sharing with AWS Organizations in AWS RAM to seamlessly share subnets with the application OUs. Additionally, utilizing a Customer Managed Key (CMK) is required because AWS-managed keys cannot be modified to grant cross-account write permissions to the CloudTrail service principal. Finally, purchasing Compute Savings Plans is necessary to cover EC2, Fargate, and Lambda workloads across all member accounts under consolidated billing.

Step-by-Step Solution

Enable resource sharing with AWS Organizations in AWS RAM and share Network subnets with target OUs.

Subnets are automatically shared with new application accounts without manual invitation acceptance.

Enabling sharing with AWS Organizations in the management account is a prerequisite for seamless organization-wide resource sharing.

Create an S3 bucket in the Security account encrypted with a Customer Managed Key (CMK) and configure cross-account policies.

All member accounts can securely write logs to the central bucket, and the logs are encrypted.

AWS-managed KMS keys (like aws/s3) do not support key policy modifications, making a CMK mandatory for cross-account KMS access by CloudTrail.

Purchase Compute Savings Plans in the management account with discount sharing enabled.

Consistent cost optimization is applied to EC2, Fargate, and Lambda workloads across all member accounts.

Compute Savings Plans provide the flexibility to cover EC2, Fargate, and Lambda, unlike EC2 Instance Savings Plans which only cover EC2.

Key Concept

Multi-account resource sharing via AWS RAM, cross-account KMS policies, and Compute Savings Plans design.

Question 526Question →

A global aerospace manufacturer is migrating its engineering CAD workloads to a multi-account AWS environment. The infrastructure consists of a centralized Network VPC in a dedicated Network account, connected to the on-premises engineering headquarters in Munich and Seattle via AWS Direct Connect and AWS Transit Gateway. Multiple Spoke VPCs across different AWS accounts host the CAD rendering engines. The manufacturer has a Route 53 Private Hosted Zone (PHZ) named `engineering.internal` managed in a Shared Services account. Workloads in the Spoke VPCs must resolve records in `engineering.internal` and also resolve local on-premises hosts in `corp.local`. Concurrently, Munich and Seattle on-premises workstations must resolve resources in `engineering.internal` over the Direct Connect connections. Which combination of actions should a Solutions Architect recommend to establish a highly resilient, cost-effective DNS resolution strategy?

Share the `engineering.internal` Private Hosted Zone with the AWS Organization using AWS Resource Access Manager (RAM), and associate the shared hosted zone with all Spoke VPCs and the central Network VPC. Deploy Route 53 Resolver Inbound Endpoints in the Network VPC across multiple Availability Zones, and configure on-premises DNS to forward queries for `engineering.internal` to these Inbound Endpoint IP addresses. Deploy Route 53 Resolver Outbound Endpoints in the Network VPC, create a forward rule for `corp.local` pointing to the on-premises DNS servers, share this rule via RAM, and associate it with all Spoke VPCs.

Authorize the association of only the Spoke VPCs with the `engineering.internal` Private Hosted Zone (PHZ) from the Shared Services account, then associate them in their respective accounts using the Route 53 API. Deploy Route 53 Resolver Inbound Endpoints in the central Network VPC across multiple Availability Zones, and configure on-premises DNS to forward queries for `engineering.internal` to these Inbound Endpoint IP addresses. Deploy Route 53 Resolver Outbound Endpoints in the central Network VPC, create a forward rule for `corp.local` pointing to the on-premises DNS servers, share this rule via AWS Resource Access Manager (RAM) with the AWS Organization, and associate it with all Spoke VPCs.

Authorize the association of the central Network VPC and all Spoke VPCs with the `engineering.internal` Private Hosted Zone (PHZ) from the Shared Services account, then associate them in their respective accounts using the Route 53 API. Deploy Route 53 Resolver Inbound Endpoints in the Network VPC across multiple Availability Zones, and configure on-premises DNS to forward queries for `engineering.internal` to these Inbound Endpoint IP addresses. Deploy Route 53 Resolver Outbound Endpoints in the Network VPC, create a forward rule for `corp.local` pointing to the on-premises DNS servers, share this rule via AWS Resource Access Manager (RAM) with the AWS Organization, and associate it with all Spoke VPCs.

Authorize the association of the central Network VPC and all Spoke VPCs with the `engineering.internal` Private Hosted Zone (PHZ) from the Shared Services account, then associate them in their respective accounts using the Route 53 API. Deploy Route 53 Resolver Inbound Endpoints in the central Network VPC, and configure on-premises DNS to forward queries for `engineering.internal` to these Inbound Endpoint IP addresses. Deploy Route 53 Resolver Outbound Endpoints in each Spoke VPC directly to avoid cross-VPC transit charges, create local forward rules for `corp.local` pointing to the on-premises DNS servers, and route the traffic directly through the Direct Connect Gateway.

Show answer & explanation

Answer: Authorize the association of the central Network VPC and all Spoke VPCs with the `engineering.internal` Private Hosted Zone (PHZ) from the Shared Services account, then associate them in their respective accounts using the Route 53 API. Deploy Route 53 Resolver Inbound Endpoints in the Network VPC across multiple Availability Zones, and configure on-premises DNS to forward queries for `engineering.internal` to these Inbound Endpoint IP addresses. Deploy Route 53 Resolver Outbound Endpoints in the Network VPC, create a forward rule for `corp.local` pointing to the on-premises DNS servers, share this rule via AWS Resource Access Manager (RAM) with the AWS Organization, and associate it with all Spoke VPCs.

Answer

Authorize the cross-account association of the Private Hosted Zone with both the spoke VPCs and the central Network VPC, deploy inbound endpoints in the Network VPC for on-premises forwarding, and share a centralized outbound forwarding rule via AWS RAM.

The correct solution involves using the Route 53 API to authorize and associate both the Spoke VPCs and the central Network VPC with the private hosted zone in the Shared Services account. Since Private Hosted Zones cannot be shared via AWS RAM, this API-based cross-account association is mandatory. The central Network VPC must be associated because Route 53 Resolver Inbound Endpoints resolve queries based on the PHZs associated with the VPC in which they are deployed. For outbound resolution, a centralized Outbound Resolver Endpoint in the Network VPC with a forward rule shared via RAM with the AWS Organization is the most cost-effective and operationally efficient configuration.

Step-by-Step Solution

Create association authorizations for the central Network VPC and all Spoke VPCs to the private hosted zone in the Shared Services account.

Association authorizations are established cross-account.

Route 53 Private Hosted Zones cannot be shared via AWS RAM, so API authorization is required to associate them across different AWS accounts.

Associate the Spoke VPCs and the Network VPC with the private hosted zone in their respective accounts using the Route 53 API.

The VPCs are associated with the private hosted zone.

Both Spoke VPCs and the Network VPC must be associated; the Network VPC association is critical because the central Inbound Endpoints query the local resolver of the VPC they reside in.

Deploy Route 53 Resolver Inbound Endpoints in the Network VPC across multiple Availability Zones and configure on-premises conditional forwarders.

On-premises clients can resolve names in the private hosted zone via the inbound endpoint IPs.

This establishes hybrid resolution from on-premises to AWS over Direct Connect/VPN without traversing the public internet.

Deploy Route 53 Resolver Outbound Endpoints in the Network VPC, create a forward rule for the on-premises domain, share it via RAM, and associate it with all Spoke VPCs.

AWS workloads in all Spoke VPCs can resolve on-premises DNS names cost-effectively.

Sharing a centralized forward rule via RAM is far more cost-effective than deploying outbound endpoints in each spoke VPC.

Key Concept

Centralized Hybrid DNS Architecture with Cross-Account Private Hosted Zone Associations and Shared Resolver Rules

Estimated Time:3m 0s

Question 527Question →

A multinational enterprise manages a multi-account AWS environment under AWS Organizations. The enterprise integrates its on-premises SAML 2.0 Identity Provider (IdP) directly with target AWS member accounts to federate corporate directories. The security team wants to implement a global Attribute-Based Access Control (ABAC) strategy using the corporate attributes `CostCenter` and `Project`. The IdP is configured to send these attributes as SAML assertions mapped to AWS principal tags (`PrincipalTag:CostCenter` and `PrincipalTag:Project`).

The security team creates a standard IAM role named `ProjectContributorRole` in each member account. The local permission policies are configured to allow actions only when the resource's `CostCenter` tag matches the user's `CostCenter` principal tag. However, during initial testing, corporate users receive an error and are unable to log in to AWS when attempting to federate.

Which combination of configurations will resolve the login failures and securely enforce the cross-account ABAC boundaries across all organization accounts?

Ensure the trust policy of `ProjectContributorRole` in each member account permits both the `sts:AssumeRoleWithSAML` and `sts:TagSession` actions for the SAML Identity Provider ARN. Implement an Organization-wide Service Control Policy (SCP) at the root level that explicitly denies any action if the request does not carry the `aws:PrincipalTag/CostCenter` tag or if it does not match the target resource's `aws:ResourceTag/CostCenter` tag.

Ensure the trust policy of `ProjectContributorRole` in each member account permits only the `sts:AssumeRoleWithSAML` action for the SAML Identity Provider ARN. Modify the SAML assertion in the IdP to map the `CostCenter` and `Project` attributes to standard SAML Session Attributes rather than principal tags, thereby bypassing the requirement for `sts:TagSession` authorization.

Ensure the trust policy of `ProjectContributorRole` in each member account permits both the `sts:AssumeRoleWithSAML` and `sts:TagSession` actions. Create an Organization-wide Service Control Policy (SCP) that explicitly grants read and write access to resources when `aws:PrincipalTag/CostCenter` matches `aws:ResourceTag/CostCenter`, allowing you to delete the local permission policies from the role in each member account to simplify management.

Ensure the trust policy of `ProjectContributorRole` in each member account permits the `sts:AssumeRole` action for the SAML Identity Provider principal. Configure an IAM Policy at the Organization level that maps the SAML assertion attributes to transient IAM policy variables, and attach it to the root of the organization.

Show answer & explanation

Answer: Ensure the trust policy of `ProjectContributorRole` in each member account permits both the `sts:AssumeRoleWithSAML` and `sts:TagSession` actions for the SAML Identity Provider ARN. Implement an Organization-wide Service Control Policy (SCP) at the root level that explicitly denies any action if the request does not carry the `aws:PrincipalTag/CostCenter` tag or if it does not match the target resource's `aws:ResourceTag/CostCenter` tag.

Answer

Ensure the trust policy of the IAM role permits both the sts:AssumeRoleWithSAML and sts:TagSession actions for the SAML Identity Provider, and use an Organization-wide Service Control Policy (SCP) to deny operations when the CostCenter principal tag does not match the resource tag.

The correct option correctly identifies that to pass session tags (principal tags) via SAML federation, the role's trust policy must authorize both the sts:AssumeRoleWithSAML and sts:TagSession actions. Furthermore, it correctly utilizes a Service Control Policy (SCP) to deny operations when the principal tag does not match the resource tag, serving as a secure guardrail while local IAM policies in target accounts grant the actual permissions.

Step-by-Step Solution

Analyze the federation failure when using principal tags.

Identify that passing principal tags (ABAC attributes) via SAML requires authorization to tag the session.

By default, sts:AssumeRoleWithSAML only allows role assumption. Passing tags requires the sts:TagSession action in the role's trust policy.

Determine the correct trust policy modification.

Add both sts:AssumeRoleWithSAML and sts:TagSession to the Action element of the IAM role's trust policy in each member account.

This allows the external Identity Provider to pass the corporate attributes as session tags during the federation process.

Evaluate the mechanism for enforcing organizational boundaries.

Use a Service Control Policy (SCP) at the Organization root with a Deny effect to prevent operations when tags do not match.

SCPs cannot grant permissions, but they act as guardrails. Combining local IAM allow policies with an organizational deny guardrail ensures secure enforcement across all accounts.

Key Concept

SAML 2.0 federation with Session Tags requires the trust policy to authorize the sts:TagSession action in addition to sts:AssumeRoleWithSAML.

Estimated Time:3m 0s

Question 528Question →

A company is designing a multi-account architecture using AWS Organizations. The network team needs to share a set of private subnets from a central Network VPC in a dedicated Network account with application teams operating in different member accounts within specific Organizational Units (OUs). The security team requires that all VPC Flow Logs from the shared subnets be consolidated into a central Amazon S3 bucket in a Security account, encrypted using a Customer Managed Key (CMK) in AWS Key Management Service (AWS KMS). Additionally, the finance team wants to ensure that Compute Savings Plans purchased in the Management account are applied to all member accounts, except for a specific OU containing sandbox accounts used for third-party contractor testing, which must pay standard On-Demand rates for chargeback reporting. Which strategy should a Solutions Architect recommend to meet these requirements with the least administrative overhead?

Enable resource sharing with AWS Organizations in the AWS Resource Access Manager (RAM) console. Create a resource share in the Network account for the subnets and share it with the application OUs. In the Security account, create an S3 bucket and a KMS Customer Managed Key (CMK) with a key policy allowing the VPC Flow Logs service principal (delivery.logs.amazonaws.com) to generate data keys and decrypt. Configure the S3 bucket policy to allow log delivery. In the Network account, configure VPC Flow Logs to publish to the S3 bucket. In AWS Billing Conductor, create a billing group containing only the sandbox accounts, ensuring the Management account is excluded from this group.

Enable resource sharing with AWS Organizations in the AWS RAM console. Create a resource share in the Network account for the subnets and share it with the application OUs. In the Security account, create an S3 bucket encrypted with the default AWS-managed KMS key (aws/s3) and configure the bucket policy to allow log delivery from the Network account. In the Network account, configure VPC Flow Logs to publish to the S3 bucket. In the Billing Preferences of the Management account, disable Savings Plans sharing for the sandbox OU by applying an IAM policy.

Enable resource sharing with AWS Organizations in the AWS RAM console. Create a resource share in the Network account for the subnets and share it with the application OUs. In the Security account, create an S3 bucket and a KMS CMK with a key policy allowing the VPC Flow Logs service principal. Configure the S3 bucket policy and enable VPC Flow Logs. In the Billing Preferences of the Management account, disable Savings Plans sharing globally. Use Amazon Athena queries on the Cost and Usage Report (CUR) to manually calculate and apply the Savings Plans discounts to all non-sandbox member accounts.

In the Network account, create an AWS RAM resource share for the subnets. Create a Service Control Policy (SCP) in the Management account and attach it to the application OUs to grant permissions for the shared subnets. In the Security account, create an S3 bucket and a KMS CMK. Configure VPC Flow Logs to write to the S3 bucket. Create an AWS Glue ETL job to process the consolidated Cost and Usage Report (CUR) hourly, filtering out the sandbox accounts and manually recalculating the Savings Plans discounts for all other accounts.

Show answer & explanation

Answer: Enable resource sharing with AWS Organizations in the AWS Resource Access Manager (RAM) console. Create a resource share in the Network account for the subnets and share it with the application OUs. In the Security account, create an S3 bucket and a KMS Customer Managed Key (CMK) with a key policy allowing the VPC Flow Logs service principal (delivery.logs.amazonaws.com) to generate data keys and decrypt. Configure the S3 bucket policy to allow log delivery. In the Network account, configure VPC Flow Logs to publish to the S3 bucket. In AWS Billing Conductor, create a billing group containing only the sandbox accounts, ensuring the Management account is excluded from this group.

Answer

The correct strategy leverages AWS RAM to share the subnets within the AWS Organization, uses a Customer Managed Key (CMK) with policy modifications to allow the VPC Flow Logs service principal to write encrypted logs across accounts, and utilizes AWS Billing Conductor to isolate the sandbox accounts in their own billing group. Since the sandbox accounts are separated from the Management account that purchased the Compute Savings Plans, the pro-forma invoices generated by AWS Billing Conductor will model the sandbox accounts' usage at standard On-Demand rates, automating chargebacks with minimal administrative overhead.

Step-by-Step Solution

Configure AWS RAM organization-wide sharing from the AWS Organizations Management account, then create a resource share for the private subnets in the Network account and target the application OUs.

The application OUs can now provision resources within the shared private subnets of the central VPC.

This allows secure resource sharing within the organization boundary using AWS RAM.

Create an S3 bucket and a KMS Customer Managed Key (CMK) in the Security account, configuring the KMS key policy and S3 bucket policy to allow the delivery.logs.amazonaws.com service principal to write and encrypt objects.

A secure centralized logging target is established.

VPC Flow Logs use the log delivery service principal, which requires cross-account KMS permissions that can only be configured on Customer Managed Keys, not AWS-managed keys.

Enable VPC Flow Logs in the Network account pointing to the Security S3 bucket and specifying the KMS CMK for encryption.

Consolidated and encrypted network flow logs are delivered to the Security account.

This fulfills the logging and security audit requirement.

Create a billing group in AWS Billing Conductor containing the sandbox accounts, ensuring the Management account (which purchased the Compute Savings Plans) is not in this group.

The sandbox accounts' pro-forma invoices show standard On-Demand rates, while the consolidated actual invoice still realizes the Savings Plans benefits.

AWS Billing Conductor isolates pro-forma billing reports, applying RIs and Savings Plans only within the billing groups they reside in, thereby automating the chargeback requirement without changing actual payment configurations.

Key Concept

AWS Billing Conductor allows organizations to define custom billing groups for pro-forma billing, enabling selective exclusion of global Savings Plans and Reserved Instances discounts for specific accounts. Meanwhile, AWS RAM enables secure cross-account subnet sharing within AWS Organizations, and Customer Managed Keys (CMKs) are required for cross-account service principal encryption tasks (such as VPC Flow Logs delivery).

Estimated Time:2m 30s

Question 529Question →

A financial services corporation is establishing a multi-account AWS environment managed via AWS Organizations. The architecture consists of a centralized Network Services VPC in a Shared Services account, and multiple Spoke VPCs in separate Business Unit (BU) accounts. A Route 53 Private Hosted Zone (PHZ) for corp.internal is hosted in the Shared Services account. The on-premises data centers use local DNS servers for the onprem.internal domain, connected to the Network Services VPC via AWS Direct Connect and an AWS Transit Gateway. The corporation requires seamless, bidirectional hybrid DNS resolution: all AWS VPCs must resolve onprem.internal, and on-premises systems must resolve resources in the corp.internal PHZ, as well as resources in local PHZs associated with each Spoke VPC. Which TWO actions must the solutions architect take to implement this hybrid DNS resolution strategy? (Select TWO.)

Select all that apply

In the Shared Services account, create a Route 53 Resolver inbound endpoint in the Network Services VPC. Configure the on-premises DNS servers to forward DNS queries for corp.internal and the Spoke VPC local domains to the IP addresses of this inbound endpoint.

Create a Route 53 Resolver outbound endpoint in the Network Services VPC. Define a Route 53 Resolver forwarding rule for onprem.internal pointing to the on-premises DNS servers, associate the rule with the Network Services VPC, and share the rule across the AWS Organization using AWS Resource Access Manager (RAM) to allow Spoke VPCs to associate with it.

Share the corp.internal Private Hosted Zone with the Business Unit accounts using AWS Resource Access Manager (RAM), and then associate the hosted zone with the Spoke VPCs from the Business Unit accounts.

Create a Route 53 Resolver outbound endpoint in each Spoke VPC, and configure a forwarding rule for onprem.internal pointing to the Direct Connect Gateway (DXGW) virtual interface IP addresses to route DNS queries without traversing AWS Transit Gateway.

Configure the on-premises DNS servers to forward queries for corp.internal directly to the IP address of the AWS Transit Gateway attachment, utilizing the Transit Gateway's native DNS forwarding services.

Show answer & explanation

Answer: In the Shared Services account, create a Route 53 Resolver inbound endpoint in the Network Services VPC. Configure the on-premises DNS servers to forward DNS queries for corp.internal and the Spoke VPC local domains to the IP addresses of this inbound endpoint.; Create a Route 53 Resolver outbound endpoint in the Network Services VPC. Define a Route 53 Resolver forwarding rule for onprem.internal pointing to the on-premises DNS servers, associate the rule with the Network Services VPC, and share the rule across the AWS Organization using AWS Resource Access Manager (RAM) to allow Spoke VPCs to associate with it.

Answer

In the Shared Services account, create a Route 53 Resolver inbound endpoint in the Network Services VPC, configuring the on-premises DNS servers to forward queries to it; and create a Route 53 Resolver outbound endpoint in the Network Services VPC with a forwarding rule for onprem.internal shared across the AWS Organization using AWS Resource Access Manager (RAM).

The correct strategy combines a centralized Route 53 Resolver inbound endpoint to receive DNS queries from on-premises servers, and a centralized Route 53 Resolver outbound endpoint in the Network Services VPC to route queries to on-premises servers. Sharing the outbound resolver rule via AWS RAM allows Spoke VPCs to leverage the central outbound endpoint, avoiding the cost of provisioning endpoints in every Spoke VPC.

Step-by-Step Solution

Set up inbound DNS resolution from on-premises.

Create a Route 53 Resolver inbound endpoint in the Network Services VPC and configure on-premises DNS forwarders to target these inbound IP addresses for corp.internal and Spoke VPC domains.

This allows on-premises systems to resolve AWS-internal names by querying the inbound endpoint, which queries the Route 53 Resolver.

Set up outbound DNS resolution from AWS to on-premises.

Create a Route 53 Resolver outbound endpoint in the Network Services VPC and configure a forwarding rule for onprem.internal pointing to on-premises DNS servers.

This establishes the path for DNS queries originating in AWS to exit the AWS network and reach the on-premises DNS servers.

Share and associate the forwarding rule with Spoke VPCs.

Use AWS Resource Access Manager (RAM) to share the forwarding rule, and associate it with each Spoke VPC in the Business Unit accounts.

This ensures that resources in the Spoke VPCs automatically use the centralized outbound endpoint in the Network Services VPC to resolve onprem.internal without needing their own outbound endpoints.

Key Concept

Centralized Hybrid DNS Architecture with Route 53 Resolver Endpoints and RAM Shared Rules

Estimated Time:3m 0s

Question 530Question →

An organization plans to establish a secure, multi-account AWS environment using AWS Control Tower. The solutions architect must prepare the account, launch the landing zone, establish centralized access, register organizational units, enroll new member accounts under governance, and deploy custom policies across the entire organization. Arrange the steps in the correct chronological order to implement this governance solution.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct chronological sequence is to first disable any pre-existing AWS Config configuration recorders and delivery channels, second set up and launch the AWS Control Tower landing zone, third configure AWS IAM Identity Center for federated administrative access, fourth create and register custom OUs with Control Tower, fifth provision new workload accounts using Account Factory, and finally deploy the Customizations for AWS Control Tower (CfCT) framework to apply custom Service Control Policies (SCPs).

Establishing a secure multi-account environment with AWS Control Tower requires a strict ordering. First, pre-existing AWS Config configuration recorders must be disabled in the management account to avoid setup conflicts. Next, the AWS Control Tower landing zone is launched to create core accounts (logging, security) and OUs. Once the environment is initialized, AWS IAM Identity Center is configured to define federated access. Following this, custom OUs must be created and registered under AWS Control Tower governance. Member accounts can then be provisioned using the Account Factory so that they inherit these guardrails from the start. Finally, custom policies and resources are deployed using the Customizations for AWS Control Tower (CfCT) framework once the organizational structure and accounts are in place.

Step-by-Step Solution

Prepare the management account by disabling existing AWS Config configuration recorders and delivery channels.

Potential landing zone initialization failures due to duplicate AWS Config recorders are avoided.

AWS Control Tower manages its own AWS Config recorders, and existing ones will cause the landing zone deployment to fail.

Launch the AWS Control Tower landing zone.

The core Organization structure, Security OU, Sandbox OU, Log Archive account, and Security Audit account are deployed.

This establishes the foundational multi-account framework and default guardrails.

Configure AWS IAM Identity Center.

Federated identity access is established and permission sets are mapped to users and groups.

Administrators must be able to log in to the newly generated core accounts before configuring additional resources.

Create and register custom OUs.

Custom OUs are registered under AWS Control Tower governance.

Workload segregation requires custom OUs, which must be registered with Control Tower to receive guardrails.

Enroll accounts via Account Factory.

New member accounts are provisioned, linked to the registered OUs, and standard VPCs are set up.

Provisioning accounts through Account Factory ensures they are automatically governed and compliant from creation.

Deploy the Customizations for AWS Control Tower (CfCT) framework.

Custom SCPs and CloudFormation resources are automatically deployed to the target OUs.

Customizations are applied as the final layer of governance once accounts and OUs are established.

Key Concept

AWS Control Tower Landing Zone Setup and Governance Customization Sequence

Estimated Time:2m 0s

Question 531Question →

An organization plans to deploy a new version of a stateless web application on Amazon EC2 instances managed by an Auto Scaling group. The primary requirement is to verify the new version in a completely isolated environment before routing any production traffic to it, and to support immediate rollback to the original version if any issues are detected. Which deployment strategy should the solutions architect choose to meet these requirements?

Blue/green deployment

Rolling deployment

All-at-once deployment

Canary deployment

Show answer & explanation

Answer: Blue/green deployment

Answer

Blue/green deployment

A blue/green deployment strategy creates two identical environments. The current version runs in the 'blue' environment, and the new version is deployed to the 'green' environment. This allows the solutions architect to test the green environment in isolation without affecting production traffic. Once verified, traffic is redirected to the green environment. If issues occur, traffic can be immediately switched back to the blue environment, meeting the requirement for rapid rollback.

Step-by-Step Solution

Analyze the requirement for isolated validation before routing any production traffic.

The strategy must allow deploying the new version to a separate environment where it can be tested without receiving public traffic.

This rules out in-place, rolling, and canary deployments which direct production traffic to the new version during the deployment phase.

Evaluate the rollback requirement.

The strategy must support immediate rollback to the previous version.

A blue/green deployment maintains the old version (blue) alongside the new version (green). If validation fails, traffic can be instantly routed back to the blue environment.

Key Concept

Selecting the appropriate deployment strategy to meet isolation and rollback speed requirements.

Question 532Question →

A financial technology company is setting up a multi-account environment on AWS using AWS Organizations. The company has a Shared Services AWS account containing a central VPC that hosts a Route 53 Private Hosted Zone (PHZ) named `fintech.local`. The company also has multiple production accounts, each containing an application VPC connected to the central VPC via an AWS Transit Gateway. The on-premises data center is connected to the Transit Gateway via AWS Direct Connect. On-premises servers and instances within the application VPCs must be able to resolve domain names in `fintech.local`. Which of the following actions should a solutions architect perform to meet these requirements? (Select TWO.)

Select all that apply

Authorize the association of the `fintech.local` private hosted zone with the application VPCs from the Shared Services account, and then associate the private hosted zone with the application VPCs from each production account.

Create a Route 53 Resolver inbound endpoint in the Shared Services central VPC, and configure the on-premises DNS servers to forward queries for the `fintech.local` domain to the IP addresses of this inbound endpoint.

Share the `fintech.local` private hosted zone with the production accounts using AWS Resource Access Manager (RAM), and then configure the application VPCs to automatically associate with the shared resource.

Create a Route 53 Resolver outbound endpoint in the Shared Services central VPC, and configure AWS Transit Gateway route tables to forward DNS traffic (destination port 53) directly to the outbound endpoint's IP addresses.

Associate the `fintech.local` private hosted zone with the AWS Transit Gateway itself, which automatically propagates the DNS zones to all attached spoke VPCs and the on-premises Direct Connect gateway.

Show answer & explanation

Answer: Authorize the association of the `fintech.local` private hosted zone with the application VPCs from the Shared Services account, and then associate the private hosted zone with the application VPCs from each production account.; Create a Route 53 Resolver inbound endpoint in the Shared Services central VPC, and configure the on-premises DNS servers to forward queries for the `fintech.local` domain to the IP addresses of this inbound endpoint.

Answer

To resolve the private hosted zone from both on-premises and the production VPCs, you must authorize the cross-account association of the private hosted zone with the application VPCs and perform the association, and deploy a Route 53 Resolver inbound endpoint in the central VPC to accept forwarded queries from the on-premises DNS servers.

To allow the application VPCs in the production accounts to resolve names in the Shared Services account's Private Hosted Zone (PHZ), the Solutions Architect must perform a cross-account association. This is done by creating an association authorization in the Shared Services account and then associating the VPC in the production account. To allow the on-premises servers to resolve names in the PHZ, a Route 53 Resolver inbound endpoint must be created in the central VPC, and the on-premises DNS servers must be configured to forward queries for `fintech.local` to the inbound endpoint's IP addresses.

Step-by-Step Solution

Configure cross-account Private Hosted Zone association for the spoke VPCs.

The application VPCs in the production accounts can resolve names within the `fintech.local` zone.

Since the Private Hosted Zone is owned by the Shared Services account, cross-account association must be authorized by the owner and then accepted by the spoke VPC accounts.

Deploy Route 53 Resolver inbound endpoints in the central VPC.

An IP address is allocated in the central VPC to receive DNS queries.

On-premises servers need a target IP address within the AWS network to forward DNS queries for resolution by Route 53.

Configure on-premises DNS forwarding rules.

Queries for `fintech.local` originating from on-premises are routed to the inbound endpoint.

This establishes the hybrid DNS resolution path from on-premises to AWS.

Key Concept

Hybrid and multi-account DNS resolution using Route 53 Private Hosted Zones and Resolver endpoints

Question 533Question →

An enterprise with a multi-account AWS environment managed under AWS Organizations uses an external SAML 2.0 Identity Provider (IdP) to authenticate corporate users. The security team wants users to federate first into a central Identity account ( $111111111111$ ) and then assume a target role named WorkloadDeveloperRole in a member Production account ( $222222222222$ ) to manage resources.

To scale administration, the security team enforces Attribute-Based Access Control (ABAC). Users must only manage resources in the Production account where the resource tag CostCenter matches the user's CostCenter attribute from the corporate directory. This attribute must be securely propagated from the IdP through the federation session to the cross-account role.

Which two configurations must the solutions architect implement to establish this trust relationship and ensure compliant access? (Select two.)

Select all that apply

Configure the SAML assertion in the corporate IdP to map the user's CostCenter attribute to https://aws.amazon.com/SAML/Attributes/PrincipalTag:CostCenter. In the Identity account (

111111111111

), configure the trust policy of the federated IAM role to allow both the sts:AssumeRoleWithSAML and sts:TagSession actions for the SAML provider principal.

In the Production account (

222222222222

), configure the trust policy of WorkloadDeveloperRole to allow both the sts:AssumeRole and sts:TagSession actions for the Identity account's federated role principal. In the Identity account, configure the federated role's permissions policy to allow sts:AssumeRole on the target role, and configure the cross-account role assumption to pass the CostCenter tag as a transitive session tag.

Configure the trust policy of the initial federated role in the Identity account (

111111111111

) to allow only the sts:AssumeRole action for the SAML provider principal, and configure the corporate IdP to sign the SAML assertion with a private key registered in AWS IAM.

Attach a Service Control Policy (SCP) to the Organizational Unit (OU) containing the Production account (

222222222222

) that allows the sts:AssumeRole and sts:TagSession actions for the federated role in the Identity account (

111111111111

), thereby overriding the need to define a local trust policy on the WorkloadDeveloperRole in the Production account.

In the Identity account (

111111111111

), configure the trust policy of the federated role to allow only sts:AssumeRoleWithSAML. In the Production account (

222222222222

), configure the trust policy of WorkloadDeveloperRole to allow sts:AssumeRole from the SAML provider principal directly, bypassing the Identity account for the cross-account step.

Show answer & explanation

Answer: Configure the SAML assertion in the corporate IdP to map the user's CostCenter attribute to https://aws.amazon.com/SAML/Attributes/PrincipalTag:CostCenter. In the Identity account ( $111111111111$ ), configure the trust policy of the federated IAM role to allow both the sts:AssumeRoleWithSAML and sts:TagSession actions for the SAML provider principal.; In the Production account ( $222222222222$ ), configure the trust policy of WorkloadDeveloperRole to allow both the sts:AssumeRole and sts:TagSession actions for the Identity account's federated role principal. In the Identity account, configure the federated role's permissions policy to allow sts:AssumeRole on the target role, and configure the cross-account role assumption to pass the CostCenter tag as a transitive session tag.

Answer

Configuring the corporate IdP to map the CostCenter attribute to the AWS principal tag namespace and allowing both sts:AssumeRoleWithSAML and sts:TagSession in the Identity account's federated role trust policy, combined with configuring the Production account's WorkloadDeveloperRole trust policy to allow sts:AssumeRole and sts:TagSession from the Identity account's federated role, and passing the tag as a transitive session tag during cross-account role assumption.

The correct configuration combines mapping the directory attribute to the AWS principal tag namespace and allowing both sts:AssumeRoleWithSAML and sts:TagSession in the Identity account role's trust policy (enabling the session tag to be set initially), with configuring the Production account's WorkloadDeveloperRole trust policy to allow sts:AssumeRole and sts:TagSession from the Identity account's federated role principal, while specifying the tag as transitive to maintain the attribute across the role boundary.

Step-by-Step Solution

Map the identity directory attributes to AWS principal tags in the SAML assertion.

The CostCenter attribute is sent to AWS in the SAML assertion under the prefix https://aws.amazon.com/SAML/Attributes/PrincipalTag:CostCenter.

This tells AWS to automatically parse the attribute and apply it as a session tag to the federated IAM session.

Configure the trust policy of the federated IAM role in the Identity account (

111111111111

) to trust the SAML provider and allow both sts:AssumeRoleWithSAML and sts:TagSession.

The user successfully federates into the Identity account role, and the CostCenter session tag is successfully attached to the temporary session credentials.

The sts:AssumeRoleWithSAML action allows the token exchange, and sts:TagSession allows session tags to be set during federation.

Configure the trust policy of the WorkloadDeveloperRole in the Production account (

222222222222

) to trust the federated IAM role in the Identity account and allow both sts:AssumeRole and sts:TagSession.

The target role is prepared to receive session tags from the caller in the Identity account.

For cross-account role assumption with session tags, the target role's trust policy must explicitly allow both sts:AssumeRole (to permit the caller) and sts:TagSession (to permit propagating the session tags).

In the Identity account, invoke sts:AssumeRole pointing to the Production account role, marking the CostCenter tag as transitive.

The CostCenter tag is propagated to the assumed role session in the Production account, enabling ABAC validation against local resource tags.

Transitive tags ensure that session tags carry over to subsequent roles in the role chain.

Key Concept

Cross-Account Session Tag Propagation and Trust Configuration

Estimated Time:2m 30s

Question 534Question →

A multinational enterprise is designing a hybrid network architecture to connect $15$ spoke VPCs across multiple AWS accounts in the `us-east-1` Region to an on-premises data center. The company has the following requirements:
1. High availability for all outbound internet traffic from the spoke VPCs.
2. Secure private DNS resolution of resources in a centralized Shared Services VPC from all other spoke VPCs.
3. High-bandwidth primary connectivity via AWS Direct Connect with an IPsec VPN failover for on-premises hybrid traffic, using dynamic routing with automatic failover.

Which of the following actions should the solutions architect take to implement this architecture? (Select TWO.)

Select all that apply

Associate the AWS Transit Gateway with a Direct Connect Gateway using a transit virtual interface for the primary path, establish an AWS Site-to-Site VPN connection directly to the Transit Gateway as the backup path, and advertise the same on-premises routes via BGP over both paths.

Deploy a NAT Gateway in each Availability Zone of a centralized egress VPC, and associate the centralized Route 53 Private Hosted Zone with all spoke VPCs using cross-account VPC associations.

Connect the spoke VPCs directly to the Direct Connect Gateway using Virtual Private Gateways to route VPC-to-VPC traffic transitively, and configure a Site-to-Site VPN with static routing on the Transit Gateway as the backup path.

Create a centralized Route 53 Private Hosted Zone in the Shared Services AWS account, and configure a Transit Gateway route table rule to automatically forward DNS queries on port

53

from the spoke VPCs to the Shared Services VPC.

Deploy a single NAT Gateway in a public subnet of one Availability Zone in a centralized egress VPC, and configure the route tables of all private subnets in the spoke VPCs to route

0.0.0.0/0

traffic to this NAT Gateway.

Show answer & explanation

Answer: Associate the AWS Transit Gateway with a Direct Connect Gateway using a transit virtual interface for the primary path, establish an AWS Site-to-Site VPN connection directly to the Transit Gateway as the backup path, and advertise the same on-premises routes via BGP over both paths.; Deploy a NAT Gateway in each Availability Zone of a centralized egress VPC, and associate the centralized Route 53 Private Hosted Zone with all spoke VPCs using cross-account VPC associations.

Answer

To implement this architecture, the solutions architect should associate the AWS Transit Gateway with a Direct Connect Gateway using a transit virtual interface for the primary path, establish an AWS Site-to-Site VPN connection to the Transit Gateway for the backup path, advertise the same routes via BGP over both paths, deploy a NAT Gateway in each Availability Zone of a centralized egress VPC, and associate the centralized Route 53 Private Hosted Zone with all spoke VPCs using cross-account VPC associations.

Associating the AWS Transit Gateway with a Direct Connect Gateway using a transit virtual interface establishes the high-bandwidth primary path. Terminating the Site-to-Site VPN on the same Transit Gateway and advertising the same BGP routes over both paths enables dynamic failover, as AWS Transit Gateway automatically prefers the Direct Connect gateway attachment over the VPN attachment for identical prefixes. For outbound high availability, deploying a NAT Gateway in each Availability Zone of a centralized egress VPC prevents a single Availability Zone outage from disrupting outbound traffic. Associating the centralized Route 53 Private Hosted Zone with all spoke VPCs enables seamless cross-account private DNS resolution.

Step-by-Step Solution

Establish the hybrid connectivity primary and backup paths using AWS Transit Gateway.

An AWS Transit Gateway is associated with a Direct Connect Gateway using a transit VIF for the primary path, and a Site-to-Site VPN is terminated on the Transit Gateway as the backup path.

This configuration supports scale for multiple VPCs and enables dynamic failover by advertising identical prefixes over BGP, allowing the Transit Gateway to prefer the Direct Connect path.

Design the high availability outbound routing architecture.

A centralized egress VPC is created with a NAT Gateway deployed in each Availability Zone.

Deploying NAT Gateways across multiple Availability Zones ensures that outbound traffic is highly available and resilient to single-AZ failures.

Configure private DNS resolution across all VPCs in the multi-account environment.

The Route 53 Private Hosted Zone in the Shared Services account is associated with all spoke VPCs using cross-account VPC associations.

This allows resources in all spoke VPCs to securely resolve private domain names in the Shared Services VPC without routing DNS queries over Transit Gateway route tables.

Key Concept

Designing highly available, scalable hybrid network connectivity and centralized services routing using AWS Transit Gateway, multi-AZ NAT Gateways, and cross-account Route 53 Private Hosted Zone associations.

Question 535Question →

An automotive manufacturer is establishing a hybrid network to connect its on-premises assembly plant's industrial control systems to a multi-account AWS environment consisting of $25$ spoke VPCs in the `us-east-1` region under an AWS Organization. The network architecture requires: (1) High-speed, low-latency primary connectivity using a $10\text{ Gbps}$ AWS Direct Connect (DX) connection terminating at a Direct Connect Gateway (DXGW). (2) An IPsec Site-to-Site VPN connection terminating on an AWS Transit Gateway (TGW) to serve as a passive backup. (3) Transitive routing between all $25$ spoke VPCs and the on-premises network. (4) Minimal administrative overhead for routing table updates. (5) Symmetrical routing where the DX path is strictly preferred for both inbound and outbound traffic, and the VPN is only utilized during a DX outage. Which configuration meets these requirements?

Share the central Transit Gateway (TGW) with the spoke accounts using AWS Resource Access Manager (RAM), and attach the spoke VPCs to the TGW. Associate the TGW with the Direct Connect Gateway (DXGW) using a transit virtual interface (Transit VIF), and attach the Site-to-Site VPN to the TGW. Enable BGP propagation for both attachments in the TGW route table. On the customer gateway, prepend the autonomous system number (ASN) on the VPN BGP path advertised to AWS, and set a higher BGP local preference for AWS routes received via the Direct Connect connection.

Associate the

25

spoke VPCs directly with the DXGW, and configure a Site-to-Site VPN connection using a Virtual Private Gateway (VGW) in each spoke VPC. Enable BGP routing on all VGWs and the DXGW. On the customer gateway, configure the BGP community values to prioritize the Direct Connect path over the VPN paths for inbound and outbound traffic.

Share the central Transit Gateway (TGW) with the spoke accounts using AWS Resource Access Manager (RAM), and attach the spoke VPCs to the TGW. Associate the TGW with the DXGW, and attach the Site-to-Site VPN to the TGW. To enable on-premises DNS resolution, associate the central account's Route 53 Private Hosted Zone (PHZ) with the Transit Gateway, relying on TGW propagation to share the DNS records with all spoke VPCs.

Attach the spoke VPCs to the TGW. Create a central egress VPC with a single NAT Gateway to handle outbound internet traffic and peer the egress VPC with the TGW. Associate the TGW with the DXGW and configure static routes in the TGW route table pointing to the DXGW with a metric of 10, and static routes pointing to the VPN attachment with a metric of 50 to establish the primary and backup path relationship.

Show answer & explanation

Answer: Share the central Transit Gateway (TGW) with the spoke accounts using AWS Resource Access Manager (RAM), and attach the spoke VPCs to the TGW. Associate the TGW with the Direct Connect Gateway (DXGW) using a transit virtual interface (Transit VIF), and attach the Site-to-Site VPN to the TGW. Enable BGP propagation for both attachments in the TGW route table. On the customer gateway, prepend the autonomous system number (ASN) on the VPN BGP path advertised to AWS, and set a higher BGP local preference for AWS routes received via the Direct Connect connection.

Answer

The correct configuration leverages AWS RAM to share a central TGW, which satisfies the requirement for transitive routing between all 25 spoke VPCs and the on-premises network while keeping administrative overhead low. To establish active/passive symmetric routing with BGP, path attributes must be configured on both sides: prepending the customer gateway ASN on the VPN path ensures that AWS TGW prefers the shorter AS_PATH of the Direct Connect path for outbound traffic, while setting a higher Local Preference on the customer gateway ensures on-premises routers prefer the Direct Connect path for inbound traffic.

Step-by-Step Solution

Evaluate spoke-to-spoke and hybrid transit requirements.

Determine that AWS Transit Gateway (TGW) shared via AWS Resource Access Manager (RAM) is required to interconnect 25 spoke VPCs transitively and connect them to on-premises networks with minimal administrative overhead.

Direct Connect Gateway alone does not support transitive VPC-to-VPC routing, and managing 25 individual VGWs is administratively complex.

Configure AWS Transit Gateway routing for outbound traffic (AWS to on-premises).

Enable BGP propagation on both the DXGW and VPN attachments. To make TGW prefer the DX path, configure AS Path prepending on the customer gateway's BGP advertisement over the VPN connection.

Since TGW evaluates propagated routes with the same prefix length, it prefers the path with the shortest AS_PATH. Prepending the CGW ASN on the VPN path makes the AS_PATH longer, forcing TGW to prefer the Direct Connect path.

Configure on-premises routing for inbound traffic (on-premises to AWS).

Configure the customer gateway router to assign a higher Local Preference to BGP routes received from the Direct Connect connection compared to those received from the VPN.

Local Preference is a BGP attribute evaluated first by the customer gateway router to determine the exit path from the on-premises network, ensuring that traffic to AWS prefers the DX link.

Key Concept

Symmetric hybrid routing failover using AWS Transit Gateway with Direct Connect and Site-to-Site VPN

Question 536Question →

An enterprise is designing a secure, multi-account governance strategy using AWS Organizations. The security team wants to delegate CloudTrail administration to a dedicated Security Tooling account. All member accounts must have their API activity logged to a centralized Amazon S3 bucket in the Security Tooling account, encrypted with an AWS KMS Customer Managed Key (CMK). The configuration must be enforced across the organization to prevent member accounts from modifying or bypassing the logging structure.

What is the correct sequence of steps to establish this centralized, secure organization trail using the principle of least privilege in the management account?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts by enabling trusted access for CloudTrail from the management account, followed by registering the Security Tooling account as the delegated administrator. Next, the KMS CMK and S3 bucket are created and configured with appropriate resource policies in the Security Tooling account. Then, the organization trail is created from the Security Tooling account. Finally, a Service Control Policy (SCP) is attached from the management account to the organization root to enforce the logging configuration and protect resources from tampering.

The correct sequence begins with enabling trusted access for AWS CloudTrail from the Organizations management account, followed by registering the Security Tooling account as the delegated administrator for CloudTrail. Next, the logging destination (Amazon S3 bucket) and encryption resources (KMS CMK) are created and configured with resource policies in the Security Tooling account to allow CloudTrail access. The organization trail is then created from the Security Tooling account. Finally, an SCP is attached to the organization root from the management account to enforce logging compliance across all member accounts.

Step-by-Step Solution

Enable trusted access for AWS CloudTrail from the Organizations management account.

Allows AWS CloudTrail to integrate with AWS Organizations, which is a prerequisite for creating organization-level trails and delegating administration.

Delegated administration and organization-level resources cannot be managed before trusted access is explicitly enabled.

Grants the Security Tooling account permissions to create, update, and delete organization-level trails.

This establishes the delegation of administrative duties, adhering to the security principle of least privilege by reducing the need to access the management account.

Create the KMS CMK and Amazon S3 bucket in the Security Tooling account, updating their resource-based policies.

Prepares the storage and encryption infrastructure. The S3 bucket policy must allow 's3:PutObject' for CloudTrail with a condition for the organization ID, and the KMS key policy must allow 'kms:GenerateDataKey*' and 'kms:DescribeKey' for the CloudTrail service principal.

The trail creation will fail if the logging destination (S3) and encryption key (KMS) are not pre-configured to accept logs from the CloudTrail service principal across all accounts.

Create the organization trail from the Security Tooling account.

Deploys a multi-region organization trail across all existing and future accounts, sending logs to the central S3 bucket using the KMS key.

Using the delegated administrator permissions, the security team can configure and start the trail without management account access.

Attach a Service Control Policy (SCP) at the root level of the organization from the management account.

Restricts member accounts from disabling CloudTrail, modifying the organization trail, or tampering with the S3 bucket and KMS key in the Security Tooling account.

SCPs must be applied to prevent root and administrator users in member accounts from bypassing security logging and auditing controls.

Key Concept

Delegated administration of AWS CloudTrail and centralizing organization-level logging under AWS Organizations governance.

Question 537Question →

A company has ten spoke VPCs across multiple AWS accounts in the us-east-1 Region. The Solutions Architect needs to design a hybrid network architecture that connects all ten spoke VPCs to the company's on-premises data center using an existing AWS Direct Connect connection. The design must minimize administrative overhead and avoid the need to configure and manage multiple IPSec VPN connections. Which two configuration steps should the Solutions Architect include in the design to meet these requirements? (Select TWO.)

Select all that apply

Create an AWS Transit Gateway in a central network account, share it with the other accounts using AWS Resource Access Manager (RAM), and attach the spoke VPCs to the Transit Gateway.

Create a Direct Connect gateway, associate it with the Transit Gateway, and configure a transit virtual interface (transit VIF) on the Direct Connect connection to connect to the Direct Connect gateway.

Create a virtual private gateway (VGW) in each spoke VPC and associate them directly with the Direct Connect gateway to enable transitive routing between the VPCs and the on-premises network.

Set up a private virtual interface (private VIF) on the Direct Connect connection for each spoke VPC and terminate them directly on the Transit Gateway.

Create a Route 53 Private Hosted Zone (PHZ) in the central network account for internal name resolution, and rely on the Transit Gateway attachments to automatically resolve DNS queries in all spoke VPCs without associating the PHZ with them.

Show answer & explanation

Answer: Create an AWS Transit Gateway in a central network account, share it with the other accounts using AWS Resource Access Manager (RAM), and attach the spoke VPCs to the Transit Gateway.; Create a Direct Connect gateway, associate it with the Transit Gateway, and configure a transit virtual interface (transit VIF) on the Direct Connect connection to connect to the Direct Connect gateway.

Answer

Create an AWS Transit Gateway in a central network account, share it with the other accounts using AWS Resource Access Manager (RAM), attach the spoke VPCs to the Transit Gateway, and configure a Direct Connect gateway associated with the Transit Gateway using a transit virtual interface (transit VIF).

The correct configurations are creating a centralized AWS Transit Gateway shared via AWS Resource Access Manager (RAM) to attach all spoke VPCs, and associating a Direct Connect gateway with the Transit Gateway using a transit virtual interface (transit VIF). This architecture centralizes network management, removes the need for multiple VPN tunnels, and enables scale-efficient hybrid connectivity.

Step-by-Step Solution

Analyze the requirements for connecting multiple spoke VPCs across different accounts to an on-premises network.

Identify that a hub-and-spoke topology using AWS Transit Gateway is the most scalable approach to minimize administrative overhead compared to a full mesh of VPNs or direct VPC peering.

Transit Gateway acts as a cloud router, enabling centralized hub-and-spoke connectivity.

Determine how to share the AWS Transit Gateway with the multiple spoke accounts.

Use AWS Resource Access Manager (RAM) to share the Transit Gateway resource, and then create VPC attachments from each spoke VPC to the shared Transit Gateway.

This allows cross-account connectivity while maintaining central control of the Transit Gateway.

Identify the proper Direct Connect configuration to connect the Transit Gateway to the on-premises data center.

Associate a Direct Connect gateway with the Transit Gateway and configure a transit virtual interface (transit VIF) on the physical Direct Connect connection.

A transit VIF is specifically required to support transitive routing between a Direct Connect gateway and a Transit Gateway.

Key Concept

AWS Transit Gateway integration with Direct Connect Gateway using Transit Virtual Interfaces for multi-account hub-and-spoke hybrid connectivity.

Question 538Question →

A company is setting up identity federation to allow corporate directory users to access resources across multiple member accounts in an AWS Organization. The company is using an external SAML 2.0 Identity Provider (IdP) for user authentication. The solutions architect needs to configure the trust relationship between the external IdP and the target AWS member accounts to allow authenticated users to assume specific IAM roles. Which of the following actions must be taken to successfully configure this trust relationship? (Select TWO.)

Select all that apply

Create an IAM SAML identity provider entity in each target AWS member account using the SAML metadata document obtained from the corporate IdP.

Configure the trust policy of each IAM role in the member accounts to allow the sts:AssumeRoleWithSAML action, specifying the SAML identity provider ARN as the principal.

Configure the trust policy of each IAM role in the member accounts to allow the sts:AssumeRole action, specifying the SAML identity provider ARN as the principal.

Attach a Service Control Policy (SCP) to the target Organizational Units (OUs) that grants the sts:AssumeRoleWithSAML permission directly to the corporate users.

Enable IAM role chaining by configuring the target member account roles to trust the AWS Organizations management account root user principal.

Show answer & explanation

Answer: Create an IAM SAML identity provider entity in each target AWS member account using the SAML metadata document obtained from the corporate IdP.; Configure the trust policy of each IAM role in the member accounts to allow the sts:AssumeRoleWithSAML action, specifying the SAML identity provider ARN as the principal.

Answer

Create an IAM SAML identity provider entity in each target AWS member account using the SAML metadata document obtained from the corporate IdP, and configure the trust policy of each IAM role in the member accounts to allow the sts:AssumeRoleWithSAML action, specifying the SAML identity provider ARN as the principal.

To establish federation trust with an external SAML IdP in a multi-account environment, you must create a SAML identity provider entity in each target account using the IdP's metadata. Then, you configure the trust policy of each target IAM role to allow the sts:AssumeRoleWithSAML action, specifying the SAML identity provider ARN as the trusted principal. This enables users authenticated by the external IdP to assume the target roles in the member accounts.

Step-by-Step Solution

Obtain the SAML metadata document from the external Identity Provider (IdP).

An XML metadata document that describes the IdP's entity ID, keys, and endpoints is ready for import.

This metadata is necessary to configure the trust relationship in AWS.

Create an IAM SAML identity provider in each target AWS account.

An IAM SAML provider resource is created with a unique ARN.

This establishes the identity provider within the scope of each AWS member account.

Create IAM roles in the member accounts with a trust policy configured for SAML.

IAM roles are configured with a trust policy that allows sts:AssumeRoleWithSAML for the SAML provider principal.

This allows federated users authenticated by the external IdP to assume these roles and obtain temporary credentials.

Key Concept

SAML 2.0 Federation Trust Configuration

Question 539Question →

An enterprise manages a multi-account AWS environment using AWS Organizations. The security team is setting up identity federation with an external SAML 2.0 Identity Provider (IdP) to allow developers to access a role named DeveloperRole in several member accounts. The architecture must meet the following requirements:
1. Developers must authenticate via the corporate IdP and receive a federated session with access rights determined by their department attribute (attribute-based access control, or ABAC).
2. All federated sessions across all accounts must be prohibited from making changes to account billing settings.
3. Administrative overhead should be minimized while adhering to the principle of least privilege.

Which two configuration steps must the solutions architect perform to implement this solution? (Select two.)

Select all that apply

In each member account, create a SAML identity provider resource and a role named DeveloperRole. Configure the trust policy of the DeveloperRole to list the SAML identity provider as the principal, allow the sts:AssumeRoleWithSAML and sts:TagSession actions, and map the department attribute to the aws:PrincipalTag/Department session tag.

Create a Service Control Policy (SCP) that denies billing modification actions, and attach it to the target Organizational Units (OUs) or member accounts. In each member account, attach an IAM policy to the DeveloperRole that grants the necessary permissions for developer activities.

Create a single Service Control Policy (SCP) at the Organization root that defines the external SAML IdP as the principal and allows the sts:AssumeRoleWithSAML action, enabling trust for all member accounts without modifying individual local IAM role trust policies.

In each member account, create a role named DeveloperRole with a trust policy that allows the sts:AssumeRole action for the SAML identity provider. Configure the SAML identity provider to pass the department attribute within the SAML assertion as a standard session policy instead of session tags.

Configure the trust policy of a centralized DeveloperRole in the management account to trust the SAML IdP. Configure a Service Control Policy (SCP) at the organization root that dynamically permits role chaining from the management account to member accounts, bypassing the need for individual trust policies in the member accounts.

Show answer & explanation

Answer: In each member account, create a SAML identity provider resource and a role named DeveloperRole. Configure the trust policy of the DeveloperRole to list the SAML identity provider as the principal, allow the sts:AssumeRoleWithSAML and sts:TagSession actions, and map the department attribute to the aws:PrincipalTag/Department session tag.; Create a Service Control Policy (SCP) that denies billing modification actions, and attach it to the target Organizational Units (OUs) or member accounts. In each member account, attach an IAM policy to the DeveloperRole that grants the necessary permissions for developer activities.

Answer

The correct configuration requires creating a SAML identity provider and the DeveloperRole in each member account with a trust policy allowing both sts:AssumeRoleWithSAML and sts:TagSession to pass the department session tag, while enforcing billing restrictions via a Service Control Policy (SCP) combined with local IAM policies granting developer permissions.

Establishing federated access with ABAC requires configuring a local SAML identity provider and a role in each target member account. The role's trust policy must explicitly allow the action stating sts:AssumeRoleWithSAML to permit federation, as well as the action stating sts:TagSession to allow attributes from the SAML assertion to be mapped as session tags. To enforce billing restrictions across all accounts without administrative overhead, a Service Control Policy is used to deny billing actions globally at the Organization level, while local IAM policies are attached to the federated role to grant the required developer permissions.

Step-by-Step Solution

Configure SAML identity providers and roles locally in each member account.

Each member account has a trust relationship established with the external IdP.

SAML federation is account-specific and requires the SAML provider and IAM roles to be present in each account where users will log in.

Update the trust policy of the DeveloperRole to allow both federation and session tagging.

The role trust policy contains the actions sts:AssumeRoleWithSAML and sts:TagSession.

sts:TagSession must be explicitly allowed alongside sts:AssumeRoleWithSAML to enable the transmission of SAML attributes as session tags for ABAC.

Create and attach an SCP denying billing modifications at the organizational level.

An SCP is attached to the relevant OUs or member accounts, filtering out billing actions.

SCPs act as organizational guardrails to enforce maximum permissions (like denying billing changes) across all users and roles, including federated sessions.

Attach a local IAM permissions policy to the DeveloperRole in each member account.

Federated users have developer permissions that are filtered by the SCP.

Because SCPs do not grant permissions, a local IAM policy must be attached to the role to grant the actual access required by the developers.

Key Concept

Multi-Account SAML federation trust relationships and the interaction of local IAM policies with Service Control Policies.

Estimated Time:3m 0s

Question 540Question →

A financial services company is designing a hybrid DNS architecture across their AWS Organization and an on-premises datacenter. The environment consists of a central Network Services AWS account containing a Shared Services VPC, a Production AWS account containing a Production VPC, and an AWS Transit Gateway connecting both VPCs and the on-premises network. A Private Hosted Zone (PHZ) named prod.internal is created in the Production account and associated with the Production VPC. A Private Hosted Zone (PHZ) named shared.internal is created in the Network Services account and associated with the Shared Services VPC. The on-premises DNS servers manage the corp.local domain. The solutions architect must establish a centralized DNS resolution strategy meeting these requirements:
- On-premises servers must resolve names in prod.internal and shared.internal.
- Resources in the Production VPC must resolve names in corp.local and shared.internal.
- The architecture must minimize the deployment of Route 53 Resolver Endpoints to minimize costs.

Which of the following actions must the solutions architect perform to meet these requirements? (Select THREE.)

Select all that apply

In the Network Services account, create a Route 53 Resolver Outbound Rule for corp.local pointing to the on-premises DNS servers. Share the rule with the Production account using AWS Resource Access Manager (RAM), and associate the rule with the Production VPC.

In the Production account, authorize the association of the prod.internal private hosted zone with the Shared Services VPC. In the Network Services account, associate the Shared Services VPC with the prod.internal private hosted zone.

Configure the on-premises DNS servers to forward queries for prod.internal and shared.internal to the IP addresses of a Route 53 Resolver Inbound Endpoint deployed in the Shared Services VPC.

Use AWS Resource Access Manager (RAM) to share the prod.internal private hosted zone from the Production account to the Network Services account, and associate the shared zone with the Shared Services VPC.

Configure a Route 53 Resolver Outbound Rule in the Network Services account targeting the Direct Connect Gateway's virtual interface (VIF) IP addresses to route queries for corp.local to on-premises.

In the Production account, deploy Route 53 Resolver Inbound and Outbound Endpoints in the Production VPC. Configure on-premises DNS servers to forward queries for prod.internal to the Production VPC's Inbound Endpoint.

Show answer & explanation

Answer: In the Network Services account, create a Route 53 Resolver Outbound Rule for corp.local pointing to the on-premises DNS servers. Share the rule with the Production account using AWS Resource Access Manager (RAM), and associate the rule with the Production VPC.; In the Production account, authorize the association of the prod.internal private hosted zone with the Shared Services VPC. In the Network Services account, associate the Shared Services VPC with the prod.internal private hosted zone.; Configure the on-premises DNS servers to forward queries for prod.internal and shared.internal to the IP addresses of a Route 53 Resolver Inbound Endpoint deployed in the Shared Services VPC.

Answer

To establish the hybrid DNS architecture, the solutions architect must: 1. Create a Route 53 Resolver Outbound Rule for corp.local in the Network Services account, share it via AWS RAM, and associate it with the Production VPC. 2. Authorize the cross-account association of the prod.internal private hosted zone in the Production account and associate it with the Shared Services VPC in the Network Services account. 3. Configure the on-premises DNS servers to forward queries for both prod.internal and shared.internal to the central Route 53 Resolver Inbound Endpoint in the Shared Services VPC.

The correct architecture uses a single central Shared Services VPC to host Route 53 Resolver Inbound and Outbound endpoints to minimize costs. For the Inbound Endpoint to resolve the prod.internal domain hosted in the Production account, the Shared Services VPC must be associated with the prod.internal Private Hosted Zone. Because this is a cross-account association, it requires authorization in the Production account followed by association in the Network Services account. For outbound resolution, a single forwarding rule for corp.local is created in the central account, shared via AWS Resource Access Manager (RAM), and associated with the Production VPC.

Step-by-Step Solution

Centralize Inbound DNS resolution from on-premises.

Create a Route 53 Resolver Inbound Endpoint in the Shared Services VPC and configure on-premises conditional forwarders to point to its IP addresses.

This allows on-premises systems to query AWS DNS. Centralizing this in the Shared Services VPC minimizes costs by avoiding duplicate Inbound Endpoints in other VPCs.

Establish cross-account Private Hosted Zone (PHZ) association for the Production VPC's domain.

Authorize the association of the prod.internal PHZ in the Production account with the Shared Services VPC, then perform the association in the Network Services account.

Inbound Endpoints can only resolve domains for PHZs that are explicitly associated with the VPC housing the Inbound Endpoint. Since prod.internal is in the Production account, a cross-account association is required.

Centralize Outbound DNS resolution to on-premises.

Create a Route 53 Resolver Outbound Endpoint and forwarding rule for corp.local in the Shared Services VPC, share the rule with the Production account via AWS RAM, and associate the rule with the Production VPC.

This enables instances in the Production VPC to resolve the on-premises domain via Transit Gateway using the central Outbound Endpoint, satisfying the cost-minimization and name resolution requirements.

Key Concept

Cross-Account Private Hosted Zone association and centralized Route 53 Resolver Endpoints in a hybrid multi-account environment.

PreviousPage 27 / 99Next

All practice questions

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept