Examkin

All practice questions

1964 questions

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

A company wants to connect multiple AWS VPCs to their on-premises data center using a hub-and-spoke topology with AWS Transit Gateway. Which of the following components or configurations are required to establish this network connectivity? (Select TWO).

Select all that apply

Show answer & explanation

Answer: Transit Gateway attachments created for each VPC to connect them to the Transit Gateway.; A Transit Gateway attachment to a VPN connection or Direct Connect gateway to establish the hybrid link to the on-premises network.

Answer

Transit Gateway attachments created for each VPC to connect them to the Transit Gateway, and a Transit Gateway attachment to a VPN connection or Direct Connect gateway to establish the hybrid link to the on-premises network.
Establishing a hub-and-spoke hybrid network with Transit Gateway requires attaching the spoke VPCs directly to the Transit Gateway, and establishing a hybrid connectivity attachment (such as VPN or Direct Connect) to bridge the Transit Gateway to the on-premises data center.

Step-by-Step Solution

1
Identify the requirement for connecting spoke VPCs to the central hub.
Create Transit Gateway VPC attachments for each spoke VPC.
VPC attachments enable the Transit Gateway to act as a router for the VPC resources.
2
Identify the requirement for connecting the central hub to the on-premises network.
Create a hybrid attachment, such as an AWS Site-to-Site VPN attachment or a Direct Connect gateway attachment on the Transit Gateway.
This establishes physical or virtual encrypted tunnels between AWS and the on-premises customer gateway.

Key Concept

AWS Transit Gateway acts as a cloud router to simplify hybrid and multi-account hub-and-spoke networking by using attachments to connect VPCs and hybrid paths.
Question 482Question →

A financial services firm is migrating its transactional applications to a multi-account AWS environment managed under AWS Organizations. The architecture includes a central Network VPC in a Shared Services account and multiple application VPCs in separate production accounts. A Route 53 Private Hosted Zone (PHZ) named `corp.internal` is hosted in the Shared Services account. Network connectivity between the central Network VPC, production VPCs, and the on-premises datacenter is established using AWS Transit Gateway. On-premises DNS servers manage the `onprem.corp` domain. An outbound Route 53 Resolver endpoint is deployed in the Network VPC to forward queries for `onprem.corp` to the datacenter. Which combination of actions should a solutions architect recommend to enable DNS resolution of both `corp.internal` and `onprem.corp` from the production VPCs with the least administrative overhead?

Show answer & explanation

Answer: Associate the `corp.internal` PHZ with the production VPCs by submitting a cross-account association authorization from the Shared Services account and accepting it in the production accounts. Share the `onprem.corp` Route 53 Resolver rule from the Shared Services account to the production accounts using AWS Resource Access Manager (RAM), and associate the shared rule with the production VPCs.

Answer

Associate the `corp.internal` PHZ with the production VPCs by submitting a cross-account association authorization from the Shared Services account and accepting it in the production accounts. Share the `onprem.corp` Route 53 Resolver rule from the Shared Services account to the production accounts using AWS Resource Access Manager (RAM), and associate the shared rule with the production VPCs.
The correct configuration uses Route 53 cross-account Private Hosted Zone (PHZ) association to resolve `corp.internal` and Route 53 Resolver rules shared via AWS Resource Access Manager (RAM) to resolve `onprem.corp`. This architecture centralizes DNS outbound endpoints in the Shared Services Network VPC, significantly reducing costs and management overhead while avoiding the duplication of private hosted zones.

Step-by-Step Solution

1
Authorize cross-account association of the Private Hosted Zone.
The Shared Services account submits an authorization allowing the production VPCs to associate with the `corp.internal` private hosted zone.
By default, Route 53 Private Hosted Zones cannot be associated with VPCs in other accounts without explicit cross-account authorization.
2
Accept the association in the production accounts.
Each production account runs an association command via the AWS CLI or API to link their VPCs to the centralized `corp.internal` hosted zone.
This establishes private DNS resolution for `corp.internal` inside the production VPCs without duplicating records.
3
Share the Route 53 Resolver outbound rule via AWS RAM.
The forwarding rule for `onprem.corp` associated with the central outbound endpoint is shared with the AWS Organization's production accounts.
Sharing the rule allows spoke VPCs to use the central Network VPC's outbound resolver endpoint for forwarding on-premises DNS queries, eliminating the need to provision redundant outbound endpoints.
4
Associate the shared rule with production VPCs.
Each production account associates the shared Route 53 Resolver forwarding rule with their respective VPCs.
This automatically routes DNS requests for `onprem.corp` from the production VPCs to the central outbound endpoint and across Transit Gateway to the datacenter.

Key Concept

Multi-account Private Hosted Zone association combined with centralized hybrid Route 53 Resolver rule sharing via AWS RAM.
Estimated Time:2m 30s
Question 483Question →

A logistics enterprise is deploying a multi-account AWS environment and wants to federate access for its administrative operations team using an external OpenID Connect (OIDC) identity provider. The administrators need to assume specific roles to access resources across multiple target member accounts. The solutions architect must configure OIDC federation directly with AWS IAM for these member accounts. Which of the following configuration steps are required to establish this trust relationship? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: In each target member account, create an IAM OpenID Connect (OIDC) identity provider that points to the external identity provider.; In each target member account, create an IAM role with a trust policy that specifies the OIDC identity provider as the principal and allows the sts:AssumeRoleWithWebIdentity action.

Answer

To establish trust with an external OpenID Connect (OIDC) identity provider, you must create an IAM OIDC identity provider in the target member accounts and configure IAM roles with a trust policy allowing the sts:AssumeRoleWithWebIdentity action.
Establishing OIDC federation requires registering the OIDC provider in the IAM configuration of the member accounts and defining IAM roles with trust policies that specifically authorize the sts:AssumeRoleWithWebIdentity API action. This allows users authenticated by the external IdP to assume the roles.

Step-by-Step Solution

1
Register the external OpenID Connect identity provider in the target AWS member accounts.
The member accounts now recognize security tokens issued by the external OIDC provider.
Establishing trust at the account level is a prerequisite for mapping external users to specific AWS IAM roles.
2
Create IAM roles with trust policies that allow the sts:AssumeRoleWithWebIdentity action, specifying the OIDC provider as the trusted entity.
External federated users who present valid OIDC tokens can assume the designated IAM roles in the member accounts.
AWS Security Token Service (STS) requires the sts:AssumeRoleWithWebIdentity API action to perform web identity federation.

Key Concept

OpenID Connect (OIDC) Federation Configuration
Question 484Question →

A healthcare provider operates a multi-account AWS environment with 1515 spoke VPCs in the `us-west-2` Region and 1010 spoke VPCs in the `us-east-1` Region. The provider requires a private, high-bandwidth hybrid network configuration to connect all VPCs to their on-premises data center. The connection must use a primary AWS Direct Connect connection and a backup AWS Site-to-Site VPN connection. The architecture must allow all VPCs to communicate with the on-premises network and with each other. Which architecture and routing strategy will meet these requirements with the least administrative overhead?

Show answer & explanation

Answer: Provision a Transit Gateway in each Region, attach the local VPCs to their respective Transit Gateway, and peer the two Transit Gateways. Link a central Direct Connect Gateway with both Transit Gateways to terminate the primary Direct Connect connection, and establish a Site-to-Site VPN connection to each Transit Gateway as a backup. Advertise on-premises routes via BGP over both paths, prepending the AS path on the VPN to ensure the Direct Connect path is preferred.

Answer

Provision a Transit Gateway in each Region, attach the local VPCs to their respective Transit Gateway, and peer the two Transit Gateways. Link a central Direct Connect Gateway with both Transit Gateways to terminate the primary Direct Connect connection, and establish a Site-to-Site VPN connection to each Transit Gateway as a backup. Advertise on-premises routes via BGP over both paths, prepending the AS path on the VPN to ensure the Direct Connect path is preferred.
The correct architecture uses local Transit Gateways in each Region, peered together to support inter-Region VPC communication. For hybrid connectivity, a central Direct Connect Gateway is linked with both Transit Gateways, and a backup Site-to-Site VPN is configured on each Transit Gateway. By prepending the AS path on the VPN connection, BGP routing naturally prefers the shorter AS path of the Direct Connect connection for outbound and inbound traffic, providing automated failover.

Step-by-Step Solution

1
Deploy regional Transit Gateways and attach local VPCs.
Local VPC communication is established within each Region.
Transit Gateway attachments are regional and cannot span across Regions.
2
Establish a Transit Gateway peering connection between the two Transit Gateways.
Inter-Region VPC-to-VPC routing is enabled.
To allow cross-Region traffic between the 1515 VPCs in us-west-2 and the 1010 VPCs in us-east-1.
3
Link a central Direct Connect Gateway to both Transit Gateways and create backup Site-to-Site VPN connections to each Transit Gateway.
Dual-path hybrid connectivity is established with both Regions.
Direct Connect Gateway supports multi-region associations with Transit Gateways, enabling centralized hybrid connectivity.
4
Advertise on-premises routes via BGP on both connections, and prepend the AS path on the VPN path.
The Direct Connect connection becomes the preferred primary route, with the VPN acting as an automatic failover.
AS path prepending increases the length of the VPN route, making BGP prefer the shorter path over Direct Connect.

Key Concept

Multi-region hybrid network design with Transit Gateway peering, Direct Connect Gateway, and BGP failover.
Question 485Question →

A multinational retailer operates its workloads across multiple AWS accounts managed through AWS Organizations. To enforce consistent networking standards, the cloud engineering team needs to share a central Customer-Managed Prefix List containing verified on-premises data center ranges with all existing and future member accounts. Concurrently, the finance department wants to implement a cost-saving model for their compute usage. The workloads run on a mixture of Amazon EC2, AWS Fargate, and AWS Lambda. The solution must minimize administrative overhead and avoid manual resource acceptance steps.

Which strategy should a solutions architect propose to meet these requirements?

Show answer & explanation

Answer: Enable resource sharing with AWS Organizations in AWS RAM. Create a resource share for the prefix list in the sharing account and target the Organization's ID as the principal. From the management account, commit to Compute Savings Plans.

Answer

Enable resource sharing with AWS Organizations in AWS RAM, create a resource share targeting the Organization's ID, and purchase Compute Savings Plans from the management account.
Enabling resource sharing with AWS Organizations in AWS RAM allows resources to be shared seamlessly with the entire organization or specific OUs without requiring manual invitation acceptance. Since the workloads consist of Amazon EC2, AWS Fargate, and AWS Lambda, Compute Savings Plans are the most appropriate choice because they automatically apply to compute usage across all three services, regardless of instance family, size, or region.

Step-by-Step Solution

1
Configure AWS RAM to enable resource sharing within AWS Organizations.
Enables seamless sharing across accounts within the organization without requiring individual handshake invitation acceptances.
To minimize administrative overhead as required by the organization.
2
Create a resource share for the customer-managed prefix list and assign the Organization ID as the principal.
The prefix list becomes instantly available to all member accounts in the organization.
To distribute the authorized corporate IP ranges to all existing and future member accounts.
3
Acquire Compute Savings Plans in the management account.
Cost savings are automatically applied to eligible EC2, Fargate, and Lambda usage across all consolidated member accounts.
To cover the diverse compute workloads (EC2, Fargate, and Lambda) with maximum flexibility.

Key Concept

AWS Resource Access Manager sharing configurations within AWS Organizations and matching Savings Plans types to compute services (EC2, Fargate, Lambda) for multi-account cost optimization.
Question 486Question →

A global financial payment processor manages its multi-account environment on AWS using AWS Organizations. The network topology consists of a central Network Services Account containing a Shared Services VPC that acts as a hub, connected to multiple application VPCs in member accounts via AWS Transit Gateway. The Shared Services VPC has inbound and outbound Route 53 Resolver endpoints to handle hybrid DNS resolution with an on-premises data center connected via AWS Direct Connect.

An application team in Account A (Production) hosts a critical payment service and creates a Route 53 Private Hosted Zone (PHZ) named `prod.payments.internal` associated with the Production VPC in Account A. An on-premises payment gateway needs to resolve hostnames within `prod.payments.internal` via the Direct Connect connection. Additionally, workloads running in other member account VPCs must also be able to resolve these hostnames.

Which configuration strategy must a solutions architect implement to meet these requirements with the least administrative overhead while ensuring that DNS traffic complies with the centralized hybrid network design?

Show answer & explanation

Answer: In Account A, submit a cross-account VPC association authorization to link the private hosted zone with the Shared Services VPC in the Network Services Account. From the Network Services Account, accept the association request using the AWS CLI or Route 53 API. Configure the on-premises DNS servers to forward queries for the domain to the inbound Route 53 Resolver endpoint IP addresses in the Shared Services VPC. Repeat the cross-account authorization and association process for any other member account VPCs requiring resolution.

Answer

Authorize the association of the Private Hosted Zone in Account A with the Shared Services VPC, accept the association from the Network Services Account via the API/CLI, and forward on-premises DNS queries to the inbound Route 53 Resolver endpoints.
The correct strategy involves authorizing the cross-account association of the Private Hosted Zone from Account A using the API or CLI, followed by associating it with the Shared Services VPC in the Network Services Account. Since on-premises queries are forwarded to the inbound resolver endpoint residing in the Shared Services VPC, the endpoint can resolve the queries by accessing the newly associated Private Hosted Zone. Similarly, authorizing and associating the zone with other VPCs enables their native resolvers to resolve the domain without creating loops or forwarding rules.

Step-by-Step Solution

1
Authorize cross-account VPC association from the zone owner account.
From Account A, execute the AWS CLI command `aws route53 create-vpc-association-authorization` targeting the Shared Services VPC ID in the Network Services Account.
Before a VPC in another account can be associated with a Private Hosted Zone, the account owning the hosted zone must explicitly authorize the association.
2
Associate the target VPC with the Private Hosted Zone from the target VPC owner account.
From the Network Services Account, execute the AWS CLI command `aws route53 associate-vpc-with-hosted-zone` targeting the Private Hosted Zone ID and the Shared Services VPC ID.
This establishes the logical link so that the DNS server of the Shared Services VPC (which hosts the inbound resolver endpoint) can query the Private Hosted Zone.
3
Configure hybrid DNS routing on-premises.
On-premises DNS forwarders route queries for the domain to the IP addresses of the inbound Route 53 Resolver endpoints.
Inbound endpoints process incoming queries from on-premises over AWS Direct Connect and resolve them using the associated VPC's DNS resolver.
4
Associate other application VPCs with the hosted zone.
Repeat the authorization and association commands for all other application VPCs requiring name resolution of the domain.
Workloads in other VPCs need direct association to resolve the domain using the VPC's default DNS server (10.0.0.210.0.0.2 or equivalent).

Key Concept

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

An enterprise is designing a multi-account AWS architecture managed under AWS Organizations with consolidated billing. The architecture consists of a Shared Services account, a Billing/Management account, and two application accounts (App-A and App-B) grouped under an Applications Organizational Unit (OU). The enterprise needs to implement a solution that satisfies the following requirements:

1. VPC subnets hosted in the Shared Services account must be shared with App-A and App-B to allow resources to be launched in a centralized network. The subnet sharing must be restricted only to accounts within the organization.
2. The enterprise has purchased a Compute Savings Plan in the Billing/Management account. The cost optimization strategy requires that App-A benefit from this Savings Plan, while App-B's volatile, non-production workloads must be excluded from absorbing the discount.
3. App-A hosts a centralized Amazon S3 bucket that must accept write operations and allow read operations from App-B. All objects in this bucket must be encrypted at rest, and the security policy dictates that App-B must have access to decrypt and write the data.

Which combination of actions will meet these requirements in the most operationally efficient and secure manner?

Show answer & explanation

Answer: Enable sharing within AWS Organizations in the AWS RAM console. In the Shared Services account, create a resource share in AWS RAM, associate the subnets, and share them with the Applications OU. In the Billing/Management account's Billing preferences, disable Savings Plans sharing specifically for App-B. In App-A, configure the S3 bucket to use Server-Side Encryption with a Customer Managed Key (SSE-KMS). Configure the KMS key policy to allow the App-B account's IAM roles to perform the kms:GenerateDataKey and kms:Decrypt actions, and configure the S3 bucket policy to grant read and write access to the App-B roles. In App-B, configure local IAM policies to allow access to the S3 bucket and the KMS key in App-A.

Answer

Enable AWS Organizations sharing in AWS RAM to share subnets with the Applications OU. Disable Savings Plans discount sharing specifically for App-B in the Billing preferences of the Management account. Encrypt the S3 bucket in App-A using a Customer Managed Key (CMK), configure both the S3 bucket policy and the KMS key policy to allow App-B's IAM roles to read, write, and decrypt, and configure App-B's IAM policies to allow these cross-account actions.
The correct solution uses AWS RAM integrated with AWS Organizations to share subnets directly with the Applications OU, ensuring subnet access is restricted to the organization. Selective discount sharing for Savings Plans is managed in the Billing Preferences of the management account, which allows excluding specific accounts (like App-B) from receiving the Compute Savings Plan discounts. For secure cross-account S3 access, a Customer Managed Key (CMK) must be used because its key policy can be modified to trust the external account (App-B), unlike AWS-managed keys. Both the KMS key policy and S3 bucket policy must allow access to the App-B IAM roles, and App-B's IAM policies must grant permissions to the S3 bucket and KMS key in App-A.

Step-by-Step Solution

1
Enable AWS Organizations sharing in AWS RAM and share subnets with the Applications OU.
App-A and App-B gain access to launch resources in the Shared Services VPC subnets, restricting sharing solely to the AWS Organization.
AWS RAM requires enabling integration with AWS Organizations to allow resource sharing with OUs or the entire organization.
2
Configure Billing Preferences in the Management account to disable Savings Plans sharing specifically for App-B.
The Compute Savings Plan discount purchased in the Management account is shared with App-A but is blocked from being applied to App-B's volatile workloads.
Discount sharing is a consolidated billing feature managed under Billing Preferences. Turning off sharing for specific accounts is the only supported way to exclude them from consolidated savings.
3
Create a Customer Managed Key (CMK) in App-A and configure the S3 bucket to use SSE-KMS with this key.
S3 objects are encrypted using a key whose policy can be modified to allow cross-account access.
AWS-managed keys (such as aws/s3) do not support policy modification and cannot be used for cross-account S3 decryption.
4
Configure the S3 bucket policy and the KMS key policy in App-A to grant App-B's IAM roles access, and update App-B's IAM policies.
App-B is fully authorized to write and read/decrypt objects in App-A's S3 bucket.
Cross-account access to encrypted S3 resources requires explicit permissions on the S3 bucket policy, the KMS key policy, and the caller's local IAM policy.

Key Concept

Multi-account resource sharing via AWS RAM, selective Savings Plans discount allocation, and cross-account S3 access with Customer Managed Key encryption.
Estimated Time:3m 0s
Question 488Question →

A financial services organization is establishing a federated identity solution to allow corporate directory users to log in directly to 100+ AWS member accounts within an AWS Organization. The company is using an on-premises SAML 2.0 compliant Identity Provider (IdP). The Solutions Architect must configure the environment to map corporate group memberships to specific IAM roles in each member account while ensuring federated access is secure and follows AWS best practices. Which of the following actions must the Solutions Architect take to successfully establish this federation? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Create a SAML Identity Provider entity in each member account and configure IAM roles with a trust policy that specifies the sts:AssumeRoleWithSAML action and references the SAML provider ARN as the Principal.; Configure the external IdP to send SAML assertions containing the https://aws.amazon.com/SAML/Attributes/Role attribute populated with the ARN of the IAM role and the ARN of the SAML provider, along with the RoleSessionName attribute.

Answer

To configure direct SAML 2.0 federation, the Solutions Architect must create a SAML Identity Provider in each member account and configure IAM roles with a trust policy allowing the sts:AssumeRoleWithSAML action. Additionally, the external IdP must be configured to pass the Role and RoleSessionName attributes in the SAML assertion.
Establishing a trust relationship with a SAML 2.0 IdP requires defining a SAML identity provider within each member account that users need to access. Roles in these accounts must trust this provider using the sts:AssumeRoleWithSAML action. The external IdP must also send the AWS-specific SAML attributes (Role and RoleSessionName) to allow AWS to validate and map the incoming assertion to the correct IAM role.

Step-by-Step Solution

1
Establish trust in member accounts
Create a SAML identity provider in each AWS member account using the IdP's XML metadata document.
This allows each individual account to recognize and trust assertions signed by the corporate Identity Provider.
2
Create target IAM roles and define trust policies
Configure IAM roles in the member accounts with a trust policy that permits the sts:AssumeRoleWithSAML action and designates the local SAML provider ARN as the Principal.
This enables federated users to assume these roles when presenting valid assertions from the trusted provider.
3
Configure SAML assertions at the IdP
Configure the IdP to map user attributes to AWS-specific SAML attributes, specifically Role (combining role and provider ARNs) and RoleSessionName.
These attributes are required by the AWS sign-in endpoint to determine which role to assume and how to identify the user session.

Key Concept

Direct SAML 2.0 federation to multiple AWS accounts requires a local SAML identity provider, a trust policy utilizing sts:AssumeRoleWithSAML, and the mapping of required AWS SAML attributes at the IdP.
Question 489Question →

A health-tech corporation is designing a hybrid DNS architecture across its on-premises data centers and a multi-account AWS environment managed via AWS Organizations. The AWS footprint consists of a central Network Services VPC hosting inbound and outbound Route 53 Resolver endpoints, and multiple Application VPCs in separate member accounts. A Route 53 Private Hosted Zone (PHZ) for `prod.healthtech.internal` is created in a Shared Services account. The on-premises DNS servers must resolve `prod.healthtech.internal`, and the Application VPCs must resolve the on-premises domain `corp.healthtech.local`. Connectivity is established using AWS Transit Gateway.

Which TWO steps are required to achieve secure, minimal-latency DNS resolution across this hybrid environment? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Authorize the association of the Route 53 Private Hosted Zone with the Application VPCs and the Network Services VPC from the Shared Services account, and then associate the VPCs with the Private Hosted Zone from their respective member accounts.; Create Route 53 Resolver outbound rules for the on-premises domain in the Network Services account, share the rules with the AWS Organization using AWS Resource Access Manager (RAM), associate them with all VPCs, and configure on-premises conditional forwarders pointing to the inbound resolver endpoint IP addresses.

Answer

Authorize the association of the Route 53 Private Hosted Zone with the Application VPCs and the Network Services VPC from the Shared Services account, then associate the VPCs with the Private Hosted Zone from their respective accounts; create Route 53 Resolver outbound rules in the Network Services account, share them via AWS Resource Access Manager, associate them with all VPCs, and configure on-premises DNS to forward to the inbound resolver endpoints.
To implement hybrid and cross-account DNS, you must establish trust between the accounts owning the VPCs and the account owning the Private Hosted Zone. This is achieved by authorizing the association from the owner account and then submitting the association request from the target accounts. Additionally, to route queries between on-premises and AWS, Route 53 Resolver inbound endpoints receive on-premises queries, and outbound rules shared via AWS RAM route VPC queries back to the on-premises servers.

Step-by-Step Solution

1
Authorize and associate the Private Hosted Zone across AWS accounts.
The Application VPCs and the Network Services VPC can now resolve names in the `prod.healthtech.internal` zone.
Because Private Hosted Zones cannot be shared via AWS RAM, you must authorize and accept associations across account boundaries using the Route 53 APIs.
2
Configure hybrid outbound DNS forwarding via Route 53 Resolver outbound rules.
VPCs can resolve the `corp.healthtech.local` domain hosted on-premises.
Creating outbound rules in the central network account and sharing them via RAM allows spoke VPCs to route on-premises DNS queries to the outbound endpoints.
3
Configure hybrid inbound DNS forwarding from the on-premises DNS servers.
On-premises clients can resolve names in the `prod.healthtech.internal` zone.
On-premises servers forward conditional queries to the Route 53 Resolver inbound endpoint IP addresses, which are reachable over the Transit Gateway connection.

Key Concept

Multi-Account and Hybrid DNS Architecture Strategy using Route 53 Resolver endpoints and cross-account Private Hosted Zone association.
Question 490Question →

An enterprise is designing a multi-account AWS environment using AWS Organizations. The security team has defined the following governance requirements that must be enforced across all member accounts:
1. Prevent any member account from leaving the organization.
2. Ensure that AWS CloudTrail trails and AWS Config configuration recorders or delivery channels cannot be deleted or disabled by any user, including administrative and root users.
3. Restrict resource creation to only the `us-east-1` and `eu-west-1` regions, while ensuring that global services (such as IAM, Amazon CloudFront, and Amazon Route 53) remain fully operational.

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

Select all that apply

Show answer & explanation

Answer: Apply a Service Control Policy (SCP) to the organization root that denies organizations:LeaveOrganization, cloudtrail:StopLogging, cloudtrail:DeleteTrail, cloudtrail:UpdateTrail, config:DeleteConfigurationRecorder, and config:DeleteDeliveryChannel.; Apply a Service Control Policy (SCP) to the target OUs that denies all actions if the aws:RequestedRegion condition key does not match us-east-1 or eu-west-1, except for actions matching global services (such as iam:*, cloudfront:*, and route53:*) inside a NotAction block.

Answer

The correct configurations are to apply an SCP at the organization root that denies leaving the organization and deleting configuration recorders, delivery channels, trails, or stopping logging; and to apply another SCP that denies all regional actions outside of the allowed regions unless the actions match global services within a NotAction block.
The correct options properly leverage SCPs to enforce boundaries. The SCP that denies leaving the organization and disabling auditing tools prevents administrative override in member accounts, securing the compliance baseline. The region-restriction SCP uses the Deny-NotAction pattern to restrict regional activities to us-east-1 and eu-west-1 while allowing essential global API operations to function.

Step-by-Step Solution

1
Address the requirement to prevent organization departure and disablement of monitoring tools.
Identify that Service Control Policies (SCPs) with an explicit Deny are required to prevent member accounts (including root users) from calling organizations:LeaveOrganization, cloudtrail:StopLogging, and config:DeleteConfigurationRecorder.
SCPs define the maximum permissions for an account. An explicit Deny in an SCP overrides any administrative or root-level permissions in member accounts.
2
Address the geographical restriction requirement without breaking global services.
Formulate a policy with a Deny effect targeting the aws:RequestedRegion key for all regions except us-east-1 and eu-west-1, while nesting global services in a NotAction block.
Global services do not have regional endpoints or execute in us-east-1, meaning a blanket region lock would disrupt core IAM, CloudFront, and Route 53 operations.

Key Concept

Using Service Control Policies (SCPs) to enforce organization-wide governance, regional boundaries, and audit protection without granting permissions directly.
Question 491Question →

A company is configuring identity federation using an external SAML 2.0 Identity Provider (IdP) to allow corporate users to log directly into a specific AWS member account. A Solutions Architect creates the SAML Identity Provider in IAM and defines an IAM role for the federated users. However, during testing, users receive an Access Denied error when attempting to assume the role via SAML assertion. Which configuration issue is the most likely cause of this error?

Show answer & explanation

Answer: The trust policy of the IAM role specifies the action sts:AssumeRole instead of sts:AssumeRoleWithSAML for the SAML provider principal.

Answer

The trust policy of the IAM role specifies the action sts:AssumeRole instead of sts:AssumeRoleWithSAML for the SAML provider principal.
The correct answer is that the trust policy must use the sts:AssumeRoleWithSAML action for SAML-based identity federation. Using sts:AssumeRole is incorrect because it is only for standard cross-account or direct assume role requests using IAM credentials.

Step-by-Step Solution

1
Verify the Identity Provider configuration in the IAM console.
Confirm the SAML metadata document from the external IdP is successfully uploaded.
Ensure AWS can validate assertions sent from the IdP.
2
Inspect the trust relationship policy document of the target IAM role.
Locate the Action element and the Principal element in the policy.
To verify that the role designates the SAML provider as the trusted entity and permits the correct API call.
3
Change the Action element to sts:AssumeRoleWithSAML.
The federation flow completes successfully, granting the user temporary security credentials.
SAML assertion logins require the specialized sts:AssumeRoleWithSAML action rather than standard sts:AssumeRole.

Key Concept

SAML 2.0 Federation Trust Policy Configuration
Estimated Time:45s
Question 492Question →

An enterprise manages a multi-account environment using AWS Organizations. The cloud engineering team is designing a resource sharing, key management, and cost optimization strategy with the following requirements:
- A centralized network account needs to share subnets with other member accounts so they can deploy application workloads in a common VPC.
- A centralized security account needs to share a KMS key with all member accounts to encrypt S3 buckets and EBS volumes.
- The organization wants to purchase Savings Plans from the management account to maximize discounts, but must allow specific member accounts to opt out of sharing their unused Savings Plans.

Which of the following actions should the Solutions Architect take to implement this strategy? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Share the subnets from the network account with the organization using AWS Resource Access Manager (RAM). Member accounts can then launch resources in these subnets and will be billed directly for the EC2 and data transfer costs they generate.; Create a Customer Managed Key (CMK) in the security account and configure its key policy to grant usage permissions to the member accounts' IAM principals. Member accounts can then create IAM policies to allow their resources to use the key.

Answer

Share the subnets using AWS Resource Access Manager (RAM) so that member accounts are billed for their own resources, and share a Customer Managed Key (CMK) from the security account by updating its key policy to allow usage by member accounts.
The correct architecture uses AWS Resource Access Manager (RAM) to share subnets from the network account, which ensures that member accounts are billed directly for the EC2 and data transfer costs of the resources they create in the shared subnets. It also uses a Customer Managed Key (CMK) in the security account with a custom key policy that allows IAM principals in member accounts to utilize the key, which is the correct and only way to share KMS keys across accounts.

Step-by-Step Solution

1
Evaluate subnet sharing requirements.
Determine that VPC sharing via AWS Resource Access Manager (RAM) allows the network account to share subnets while ensuring consumer accounts pay for their own resources.
This guarantees isolation of resource costs and maintains administrative control over the network configuration.
2
Evaluate KMS key sharing requirements.
Determine that AWS-managed KMS keys cannot be shared across accounts, so a Customer Managed Key (CMK) must be created in the security account and configured with a cross-account key policy.
Key policies are the primary mechanism for delegating KMS permissions cross-account, and IAM policies in the member accounts must also trust the key.
3
Evaluate Savings Plans configuration.
Identify that the management account can control Savings Plans discount sharing using Billing Preferences to allow member accounts to opt out of sharing.
By default, Savings Plans discounts apply organization-wide, but this can be customized in the consolidated billing preferences.

Key Concept

Multi-account resource sharing enables organizations to centralize governance (like networking and security) while delegating workload deployment and cost management to individual member accounts using AWS RAM, Customer Managed KMS Keys, and billing preferences.
Question 493Question →

An enterprise is designing a highly resilient hybrid network architecture to connect their on-premises data center (network range 172.16.0.0/16172.16.0.0/16) to AWS resources across two regions: `us-east-1` and `us-west-2`. In each region, they have deployed an AWS Transit Gateway (TGW), and the two TGWs are connected via inter-region peering. A 10 Gbps10\text{ Gbps} AWS Direct Connect (DX) connection is established to a Direct Connect Gateway (DXGW) that is associated with both TGWs. For redundancy, Site-to-Site VPN connections are established from the on-premises customer gateway (CGW) to both TGWs.

The enterprise has the following routing requirements:
1. Outbound traffic from AWS VPCs to on-premises must always prefer the local region's DX connection.
2. If the local DX connection fails, traffic must fail over to the local region's VPN connection.
3. Traffic must only traverse the inter-region TGW peering link to use the remote region's DX or VPN connection as a last resort if both local paths fail.

Which of the following routing configurations meets these requirements while preventing routing loops?

Show answer & explanation

Answer: Configure the CGW to advertise specific subnets (for example, 172.16.1.0/24172.16.1.0/24 and 172.16.2.0/24172.16.2.0/24) over both DX and VPN connections. Enable route propagation from the DXGW and VPN attachments in both TGW route tables. In each TGW route table, configure a static route for the summary range 172.16.0.0/16172.16.0.0/16 pointing to the inter-region TGW peering attachment.

Answer

Advertising specific subnets over both Direct Connect and VPN connections, propagating them to Transit Gateway route tables, and adding a static route for the summary range pointing to the inter-region peering attachment.
The correct answer configuration utilizes the longest prefix match behavior to ensure correct routing priority. By advertising specific /24/24 subnets locally over both Direct Connect and VPN, the Transit Gateway will prefer these local paths for destination IPs within those ranges over the /16/16 static route pointing to the peering connection. Between the local Direct Connect and local VPN, AWS Transit Gateway naturally prefers the propagated Direct Connect routes over the propagated VPN routes for the same prefix length. If the local Direct Connect fails, the propagated /24/24 route is withdrawn, and traffic fails over to the local VPN. Only if both local paths fail are the /24/24 routes withdrawn, forcing traffic to fall back to the static /16/16 route pointing to the inter-region TGW peering link.

Step-by-Step Solution

1
Analyze Transit Gateway route selection order.
Transit Gateway route selection order prioritizes the longest prefix match first, then static routes, then propagated routes. If two propagated routes are identical, Direct Connect is preferred over VPN.
This is critical to understanding why a static route for the same prefix as a propagated route will override it, causing sub-optimal routing or routing loops.
2
Implement longest prefix match bypass for static routes.
By advertising more specific subnets (e.g., /24/24) over the local paths and configuring a summary static route (e.g., /16/16) over the peering path, local traffic uses local paths due to longest prefix match.
This prevents the static route on the peering attachment from overriding the local paths under normal operations.
3
Determine path selection between local Direct Connect and VPN.
Since both DX and VPN propagate identical /24/24 routes, the Transit Gateway automatically prefers the DXGW attachment over the VPN attachment.
This satisfies the requirement to always prefer the local region's DX connection under normal conditions.
4
Verify failover behavior.
If local DX fails, the local TGW routes via the local VPN /24/24 propagated route. If both fail, both /24/24 routes are withdrawn, and the local TGW routes via the static summary /16/16 route to the peering attachment.
This ensures the inter-region peering link is only used as a last resort.

Key Concept

AWS Transit Gateway route evaluation priorities (Longest Prefix Match > Static > Propagated) and path selection between Direct Connect Gateway and VPN.
Question 494Question →

A company has three VPCs in the same AWS Region connected to a single AWS Direct Connect gateway to access their on-premises data center. The company now needs to enable direct VPC-to-VPC communication between all three VPCs. Which of the following solutions should the solutions architect implement to meet this requirement?

Show answer & explanation

Answer: Attach the VPCs to an AWS Transit Gateway and configure routing to allow communication between the VPCs through the Transit Gateway.

Answer

Attach the VPCs to an AWS Transit Gateway and configure routing to allow communication between the VPCs through the Transit Gateway.
AWS Transit Gateway acts as a central router to allow transitive routing between attached VPCs. This fulfills the requirement to enable direct VPC-to-VPC communication efficiently.

Step-by-Step Solution

1
Identify the limitation of the existing network connectivity.
The Direct Connect gateway does not support transitive VPC-to-VPC routing.
This is a limitation of AWS Direct Connect gateway architecture.
2
Select a service that supports routing between multiple VPCs in a hub-and-spoke model.
AWS Transit Gateway allows transitive routing among all attached VPCs.
Transit Gateway acts as a regional network transit hub.

Key Concept

Transitive VPC-to-VPC routing in a hybrid network architecture using AWS Transit Gateway.
Question 495Question →

A company has two AWS accounts: Account A (Shared Services) and Account B (Production). Account A hosts a Route 53 Private Hosted Zone (PHZ) named corp.internal associated with its own VPC. The company establishes network connectivity between Account A and Account B. A solutions architect needs to enable resources in Account B's VPC to resolve DNS queries for corp.internal. Which approach should the solutions architect take to resolve these queries with the least administrative effort and cost?

Show answer & explanation

Answer: Authorize the cross-account association of Account B's VPC from Account A, and then associate the VPC with the Private Hosted Zone from Account B.

Answer

Authorize the cross-account association of Account B's VPC from Account A, and then associate the VPC with the Private Hosted Zone from Account B.
To resolve a Route 53 Private Hosted Zone (PHZ) in Account A from a VPC in Account B, the architecture requires cross-account association. This is a two-step process: first, the owner of the PHZ (Account A) authorizes the association using the AWS CLI or API. Second, the owner of the VPC (Account B) associates the VPC with the PHZ. This is the most cost-effective and operationally simple method because it avoids deploying Route 53 Resolver endpoints.

Step-by-Step Solution

1
Submit a cross-account VPC association authorization.
Account A authorizes Account B's VPC to associate with the corp.internal Private Hosted Zone.
Security boundaries in Route 53 prevent unauthorized accounts from associating their VPCs with private hosted zones in other accounts.
2
Associate the VPC from Account B.
Account B's VPC is associated with the corp.internal Private Hosted Zone.
This establishes the logical link so that Route 53 Resolver inside Account B's VPC can query the private zone.

Key Concept

Cross-account Route 53 Private Hosted Zone association requires authorization from the zone owner and association by the VPC owner.
Question 496Question →

An enterprise is designing a multi-account access strategy for its workloads managed under AWS Organizations. The security team wants to implement Attribute-Based Access Control (ABAC) to restrict access to resources within member accounts. Enterprise users reside in an external SAML 2.0 Identity Provider (IdP). Users must federate directly to target IAM roles in member accounts and be authorized dynamically based on their department attribute. The department name must be passed as a session tag during federation. Which of the following configuration steps must be performed to meet these requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Configure the SAML Identity Provider to release the user's department attribute as a SAML attribute named `https://aws.amazon.com/SAML/Attributes/PrincipalTag:Department`.; In each target member account, configure the trust policy of the federated IAM role to allow both the `sts:AssumeRoleWithSAML` and `sts:TagSession` actions for the SAML identity provider principal.

Answer

Configure the SAML Identity Provider to release the user's department attribute as a SAML attribute named with the PrincipalTag prefix, and configure the target federated IAM role trust policy to allow both the sts:AssumeRoleWithSAML and sts:TagSession actions.
To configure Attribute-Based Access Control (ABAC) using SAML federation, the SAML Identity Provider must send user attributes as session tags. This is achieved by naming the attribute in the SAML assertion with the prefix `https://aws.amazon.com/SAML/Attributes/PrincipalTag:Department`. Furthermore, the IAM role trust policy in the target accounts must explicitly allow both the `sts:AssumeRoleWithSAML` action (to perform the federation) and the `sts:TagSession` action (to allow the role to accept the incoming session tags).

Step-by-Step Solution

1
Configure the SAML Identity Provider (IdP) to release the department attribute as a session tag.
The SAML assertion contains a SAML attribute named `https://aws.amazon.com/SAML/Attributes/PrincipalTag:Department` containing the user's department.
AWS Security Token Service (STS) expects session tags to be prefixed with `https://aws.amazon.com/SAML/Attributes/PrincipalTag:` in the SAML assertion.
2
Configure the federated IAM role trust policy in the target member accounts to trust the central Identity Provider and allow session tagging.
The trust policy has its Principal set to the SAML provider ARN and allows both `sts:AssumeRoleWithSAML` and `sts:TagSession` actions.
The `sts:AssumeRoleWithSAML` action is required to authenticate SAML assertions, and the `sts:TagSession` action is required to authorize the ingestion of session tags during federation.
3
Define an ABAC authorization policy on resources inside the member accounts.
IAM policies evaluate access permissions by comparing the session tag `aws:PrincipalTag/Department` to the resource tag `Department`.
Once the session tags are ingested via SAML federation, they can be referenced in IAM policy conditions for fine-grained resource access control.

Key Concept

Multi-Account Identity and Access Management Federation using SAML session tags for Attribute-Based Access Control (ABAC).
Question 497Question →

A solutions architect is planning to implement standardized multi-account governance using AWS Control Tower for a new organization. Arrange the steps in the correct chronological order to establish and extend the landing zone.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence is: first, designate the root management account; second, configure and launch AWS Control Tower; third, provision the core shared accounts (Log Archive and Security Audit); and finally, use the Account Factory to provision individual workload accounts.
The correct chronological process begins with establishing the management account. Next, the solutions architect launches AWS Control Tower from that account. Following that, core security accounts (Log Archive and Audit) are automatically provisioned. Lastly, standard workload accounts are spawned via the Account Factory.

Step-by-Step Solution

1
Select a clean AWS account to act as the root management account.
The root management account is established to serve as the administrative anchor of AWS Organizations.
Centralized governance requires an authoritative parent account to host AWS Organizations and AWS Control Tower.
2
Navigate to AWS Control Tower in the management account and initiate landing zone setup.
AWS Control Tower starts orchestrating the multi-account setup from the root account.
Enabling Control Tower initiates the automated creation of the organization, organizational units (OUs), and basic guardrails.
3
Ensure the deployment of core shared accounts under the Security OU.
The Log Archive account and Security Audit account are successfully deployed.
Centralized logging and security auditing configurations must be baseline-integrated before any end-user workloads are deployed.
4
Access the AWS Control Tower Account Factory via Service Catalog.
Workload-specific AWS accounts (such as development or production accounts) are provisioned under standardized templates.
Account Factory is the mechanism to safely scale member account deployment while maintaining organizational compliance.

Key Concept

Establishing an AWS Control Tower Landing Zone requires configuring administrative management, deploying core security and logging structures, and then scaling through standardized account provisioning.
Estimated Time:1m 0s
Question 498Question →

An enterprise is designing a hybrid network architecture to connect its multi-account AWS environment with an on-premises data center. The company has deployed a central Transit Gateway in a shared services account to interconnect multiple spoke VPCs. The network design must utilize a 10 Gbps AWS Direct Connect connection as the primary path, with an IPsec VPN over the internet serving as an automated backup. The solution must support dynamic routing, automatically failover during a Direct Connect outage, and minimize ongoing administrative overhead. Which two configuration steps should the solutions architect perform to establish this hybrid connectivity? (Select two.)

Select all that apply

Show answer & explanation

Answer: Create a Transit Virtual Interface (VIF) on the Direct Connect connection, associate it with a Direct Connect gateway, and attach the Direct Connect gateway to the central Transit Gateway.; Create a Site-to-Site VPN attachment on the central Transit Gateway, enable BGP dynamic routing, and advertise the on-premises routes via the VPN with a longer AS path than the Direct Connect path.

Answer

The correct configurations are to establish primary connectivity by creating a Transit Virtual Interface (VIF) on the Direct Connect connection, associating it with a Direct Connect gateway, and attaching it to the Transit Gateway; and to configure backup connectivity by creating a Site-to-Site VPN attachment on the Transit Gateway with BGP dynamic routing and a longer AS path.
Establishing hybrid connectivity with Transit Gateway requires creating a Transit VIF on the AWS Direct Connect connection and associating it with a Direct Connect gateway attached to the Transit Gateway. This allows all attached VPCs to route traffic to the on-premises network. For failover, attaching an IPsec Site-to-Site VPN directly to the Transit Gateway using BGP dynamic routing with a longer AS path ensures the Direct Connect path is preferred under normal conditions while automating failover if the primary path becomes unavailable.

Step-by-Step Solution

1
Establish the primary hybrid connection using AWS Direct Connect.
A Transit VIF is created, associated with a Direct Connect gateway, and attached to the central Transit Gateway.
This provides the required high-throughput dynamic routing from on-premises to the central hub, enabling transitive routing to all spoke VPCs.
2
Configure the backup path using Site-to-Site VPN.
An IPsec VPN is attached to the Transit Gateway with BGP enabled, prepending the AS path for VPN routes.
This configures the VPN as a backup route that is only preferred if the primary Direct Connect connection fails, satisfying the failover and dynamic routing requirements.

Key Concept

Hybrid network connectivity with AWS Transit Gateway, Direct Connect Gateway, and Site-to-Site VPN backup using BGP routing preferences.
Question 499Question →

An administrator is establishing a single sign-on integration between a third-party Identity Provider (IdP) and AWS accounts. Which of the following configuration steps are required to allow external directory users to assume specific IAM roles directly? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Create a SAML provider entity in IAM using the XML metadata document from the Identity Provider.; Configure the IAM role's trust policy to trust the SAML provider entity and permit the sts:AssumeRoleWithSAML action.

Answer

Create a SAML provider entity in IAM using the XML metadata document from the Identity Provider, and configure the IAM role's trust policy to trust the SAML provider entity and permit the sts:AssumeRoleWithSAML action.
To set up SAML 2.0 federation, you must first register the Identity Provider in IAM using its XML metadata document to allow AWS to verify assertions. Second, you must create a role whose trust policy specifically allows the sts:AssumeRoleWithSAML action for the SAML provider principal.

Step-by-Step Solution

1
Register the external identity provider inside the AWS IAM system.
A SAML provider entity is created containing the metadata and signing keys of the Identity Provider.
AWS needs to verify the authenticity of the SAML assertions sent by the Identity Provider during login.
2
Create an IAM role and write its trust policy to trust the SAML provider.
The IAM role trust policy allows the action sts:AssumeRoleWithSAML when the principal is the SAML provider.
Federated users cannot assume a role unless the role explicitly permits the sts:AssumeRoleWithSAML action from that provider.

Key Concept

SAML 2.0 federation trust configuration in AWS IAM
Estimated Time:1m 0s
Question 500Question →

A solutions architect is designing a multi-account federation solution for a company using AWS Organizations. The company wants to allow its corporate directory users to log in to the AWS Management Console of various member accounts using their existing credentials via an external SAML 2.0 Identity Provider (IdP). The IdP is already configured, and the SAML provider object has been created in each member account. Which of the following configuration steps must be performed to establish this federated access? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Configure the external IdP to send SAML assertions containing attributes for https://aws.amazon.com/SAML/Attributes/Role and https://aws.amazon.com/SAML/Attributes/RoleSessionName.; In each target AWS member account, create an IAM role with a trust policy that specifies the SAML provider ARN as the principal and allows the sts:AssumeRoleWithSAML action.

Answer

To configure multi-account SAML federation, the external IdP must be configured to pass the Role and RoleSessionName attributes in the SAML assertion, and each target AWS member account must contain an IAM role configured with a trust policy that permits the sts:AssumeRoleWithSAML action from the IAM SAML provider principal.
Establishing federated access via SAML 2.0 requires configuration at both the Identity Provider (IdP) and AWS levels. The IdP must send assertions containing the required attributes (Role and RoleSessionName) so AWS can authorize the session. On the AWS side, each member account must have an IAM role that explicitly trusts the SAML provider ARN and allows the sts:AssumeRoleWithSAML action.

Step-by-Step Solution

1
Configure assertion mappings in the external Identity Provider (IdP).
The IdP sends SAML assertions containing the mandatory AWS-specific attributes: Role (mapping user to Role ARN and SAML Provider ARN) and RoleSessionName (identifying the user session).
AWS STS requires these specific SAML attributes in the assertion to determine which role to assume and how to name the federated console session.
2
Create or configure the IAM roles in the member accounts.
Roles are created with trust policies where the Principal points to the local SAML provider's ARN and the Action allows 'sts:AssumeRoleWithSAML'.
This establishes the necessary trust relationship, enabling users authenticated by the external IdP to exchange their SAML assertion for temporary security credentials in the target member account.

Key Concept

SAML 2.0 federation in a multi-account environment requires both metadata-based trust on the AWS side (role trust policy using sts:AssumeRoleWithSAML) and claim-based configuration on the IdP side (Role and RoleSessionName attributes).
PreviousPage 25 / 99Next
All practice questions — AWS Certified Solutions Architect - Professional | Examkin