All practice questions

1964 questions

All types1,964 Multiple choice1,006 Multiple select931 Ordering27

A company is designing a new portal that will experience highly variable read traffic to its relational database. The database tier must scale horizontally and automatically to handle peak read loads while maintaining high availability. Which configuration should a solutions architect recommend to scale the database's read capacity?

Deploy Amazon Aurora MySQL with Aurora Replicas and configure an Application Auto Scaling policy to dynamically scale the number of replicas based on CPU utilization.

Deploy Amazon Aurora MySQL in a Multi-AZ configuration and configure the application to send read queries to the standby writer instance in the secondary Availability Zone during peak hours.

Deploy an Application Load Balancer in front of the database and request AWS Support to pre-warm it before peak hours to handle the increased read query volume.

Configure Aurora Auto Scaling to add Aurora Replicas, setting the scale-out cooldown period to 10 seconds so that the cluster launches multiple replicas immediately during a traffic spike before the first replica finishes provisioning.

Show answer & explanation

Answer: Deploy Amazon Aurora MySQL with Aurora Replicas and configure an Application Auto Scaling policy to dynamically scale the number of replicas based on CPU utilization.

Answer

Deploy Amazon Aurora MySQL with Aurora Replicas and configure an Application Auto Scaling policy to dynamically scale the number of replicas based on CPU utilization.

Deploying Amazon Aurora MySQL with Aurora Replicas and configuring an Application Auto Scaling policy based on CPU utilization is the standard AWS best practice for handling highly variable read workloads. Aurora Replicas share the same underlying storage volume as the writer instance, resulting in sub-10ms replication lag, and can be dynamically scaled up and down based on target tracking policies.

Step-by-Step Solution

Identify the primary performance bottleneck and scaling requirements.

The workload is read-heavy and highly variable, requiring dynamic horizontal read scaling for a relational database with high availability.

This establishes that the solution must support scaling reads independently of writes and react to fluctuating utilization.

Select a database engine and topology that supports read replicas.

Amazon Aurora MySQL with Aurora Replicas is selected as it supports up to 15 low-latency reader endpoints.

Unlike traditional active-passive standby databases, Aurora reader nodes are fully active and capable of serving read queries.

Configure the scaling mechanism and policy settings.

An Application Auto Scaling policy is applied to the Aurora reader fleet using CPU utilization as the scaling metric, with a reasonable cooldown period.

This automates the provisioning of reader nodes to handle peaks and deletes them during low-traffic periods to optimize costs, while a proper cooldown prevents rapid, redundant scaling events.

Key Concept

Horizontal read scaling in Amazon Aurora using reader replicas and Application Auto Scaling.

Question 282Question →

A multinational retail company is designing a federated authentication solution for its multi-account AWS environment managed via AWS Organizations. The company utilizes an external SAML 2.0 compliant Identity Provider (IdP) for identity management. The solutions architect needs to establish federated single sign-on (SSO) so that corporate employees can access resources in various AWS member accounts according to their corporate group memberships. The security team mandates that identity federation must be established directly using IAM SAML identity providers in the member accounts, without deploying AWS IAM Identity Center. Which of the following configuration steps must the solutions architect perform to successfully set up this federation? (Select TWO.)

Select all that apply

Create a SAML identity provider entity in each AWS member account by uploading the XML metadata document obtained from the corporate Identity Provider.

In each AWS member account, create IAM roles containing a trust policy that lists the SAML provider as the principal and allows the sts:AssumeRoleWithSAML action.

In each AWS member account, create IAM roles containing a trust policy that lists the SAML provider as the principal and allows the sts:AssumeRole action.

Configure a Service Control Policy (SCP) at the root level of the AWS Organization that automatically delegates identity provider trust down to all member accounts, eliminating the need to create local SAML provider entities.

Show answer & explanation

Answer: Create a SAML identity provider entity in each AWS member account by uploading the XML metadata document obtained from the corporate Identity Provider.; In each AWS member account, create IAM roles containing a trust policy that lists the SAML provider as the principal and allows the sts:AssumeRoleWithSAML action.

Answer

Creating a SAML identity provider entity in each member account with the corporate metadata, and creating local IAM roles in those accounts with trust policies allowing the sts:AssumeRoleWithSAML action.

Establishing SAML-based federation directly to member accounts requires creating a SAML provider entity in each target account using the IdP's metadata XML document, and configuring IAM roles in those accounts that grant trust to the SAML provider using the sts:AssumeRoleWithSAML action.

Step-by-Step Solution

Establish trust on the AWS side by creating a SAML 2.0 Identity Provider (IdP) in each AWS member account.

Each member account recognizes the corporate IdP as a trusted issuer of assertions.

Before users can federate into an account, AWS must be configured to trust the external provider.

Create target IAM roles in the member accounts with a trust policy pointing to the SAML provider ARN.

The roles are configured with trust policies allowing the sts:AssumeRoleWithSAML action.

The correct API action for SAML-based federation is sts:AssumeRoleWithSAML, which evaluates the SAML assertion claims before returning temporary credentials.

Configure the corporate IdP to send the correct SAML attributes, mapping the users to the appropriate AWS role and provider ARNs.

The corporate IdP sends the Role and RoleSessionName attributes in the SAML assertion.

AWS relies on specific SAML attributes in the assertion to determine which role the user is authorized to assume.

Key Concept

SAML 2.0 Federation Trust Configuration in Multi-Account Environments

Question 283Question →

An organization has configured a multi-account AWS environment using AWS Organizations. They federate their corporate active directory identity provider (IdP) with AWS accounts using SAML 2.0. Users authenticate through the corporate portal and are redirected to the AWS Console, but they receive an error stating that they are not authorized to perform the sts:AssumeRoleWithSAML action. A solutions architect examines the target IAM role in the member account. Which configuration in the IAM role's trust policy is required to resolve this issue?

The trust policy must define the SAML Provider ARN as the Principal, specify the sts:AssumeRoleWithSAML action, and include a condition verifying that the SAML:aud attribute matches the AWS SAML endpoint.

The trust policy must define the root account of the AWS Organization as the Principal, specify the sts:AssumeRole action, and rely on an organization-level Service Control Policy (SCP) to map corporate group names.

The trust policy must define the SAML Provider ARN as the Principal, specify the sts:AssumeRole action, and include a condition checking that the SAML subject matches the user's corporate email address.

The trust policy must define the Web Identity Provider ARN as the Principal, specify the sts:AssumeRoleWithWebIdentity action, and include a condition verifying the OAuth application ID.

Show answer & explanation

Answer: The trust policy must define the SAML Provider ARN as the Principal, specify the sts:AssumeRoleWithSAML action, and include a condition verifying that the SAML:aud attribute matches the AWS SAML endpoint.

Answer

The correct option outlines the required structure for a SAML 2.0 trust policy. The principal must point to the SAML provider ARN, the action must be sts:AssumeRoleWithSAML, and the condition must validate that the SAML:aud attribute matches the AWS SAML sign-in endpoint (https://signin.aws.amazon.com/saml).

Step-by-Step Solution

Identify the authentication protocol being used in the scenario.

The authentication protocol is SAML 2.0 federated with an active directory identity provider (IdP).

Choosing the correct trust policy parameters depends on whether the federation uses SAML 2.0 or OpenID Connect (OIDC).

Determine the required API action and principal type for SAML 2.0 federation.

The API action must be sts:AssumeRoleWithSAML, and the principal must be the ARN of the SAML provider resource created in IAM.

AWS STS requires the specific AssumeRoleWithSAML action when resolving SAML assertions, and the trust policy must explicitly trust the SAML IdP metadata document imported as an IAM provider.

Verify standard trust policy condition blocks for security.

The condition block should verify that the SAML:aud attribute matches 'https://signin.aws.amazon.com/saml'.

This condition ensures that the SAML assertion is intended specifically for AWS sign-in services, preventing man-in-the-middle or replay attacks.

Key Concept

SAML 2.0 Identity Provider Federation and IAM Trust Policies

Estimated Time:1m 30s

Question 284Question →

A Solutions Architect wants to grant a development team in a member account the ability to manage Amazon S3 buckets. The architect attaches a Service Control Policy (SCP) to the Organizational Unit (OU) containing the member account, which explicitly allows all S3 actions. However, the developers in the member account still receive access denied errors when attempting to create a bucket. Which of the following explains this behavior?

SCPs automatically grant S3 permissions to all IAM entities in the member account, but the policy failed to apply because the member account's administrator explicitly blocked the inheritance of the policy.

SCPs act as permission guardrails that define the maximum allowed permissions but do not grant access directly. The developers still require a local IAM policy in their account that explicitly grants S3 permissions.

The S3 actions are allowed by the SCP, but the developers cannot access S3 until the S3 service is shared with the member account using a resource share in AWS Resource Access Manager.

The S3 permissions are allowed by the SCP, but the actions fail because S3 requires a Customer Managed Key (CMK) policy update to allow cross-account bucket access.

Show answer & explanation

Answer: SCPs act as permission guardrails that define the maximum allowed permissions but do not grant access directly. The developers still require a local IAM policy in their account that explicitly grants S3 permissions.

Answer

The correct answer states that SCPs act as permission guardrails that define the maximum allowed permissions but do not grant access directly, and that the developers still require a local IAM policy in their account that explicitly grants S3 permissions.

The correct answer states that SCPs act as permission guardrails and do not grant access directly, meaning the developers still require a local IAM policy in their account. This reflects the core concept that AWS authorization requires an explicit allow in both the SCP and the local IAM policy.

Step-by-Step Solution

Analyze how Service Control Policies (SCPs) interact with local Identity and Access Management (IAM) policies in AWS Organizations.

SCPs act as filters or permission boundaries. They specify the maximum possible permissions for an account but do not grant permissions directly to IAM users, groups, or roles.

To understand the evaluation logic of AWS Organizations permissions.

Determine the requirements for allowing an API action in a member account under an organization.

For an action to succeed, it must be explicitly allowed by both the organization's SCPs (or not explicitly denied) AND explicitly allowed by an IAM policy attached to the IAM principal in the member account.

To identify why S3 access is still denied when the SCP allows S3 actions.

Key Concept

Service Control Policies (SCPs) act as permission boundaries and do not grant permissions directly. Local IAM policies must be configured to grant access.

Estimated Time:1m 0s

Question 285Question →

A digital media corporation is using AWS Organizations to manage multiple member accounts grouped under separate Organizational Units (OUs) for Development, Testing, and Production. The security team has deployed a centralized auditing tool that relies on an IAM role named 'AuditCollectorRole' present in all member accounts. The Solutions Architect must implement a governance strategy to prevent local administrators in member accounts from deleting or modifying this specific IAM role, without restricting their ability to manage other IAM resources. Which of the following governance strategies should the solutions architect implement to meet these requirements with the least administrative overhead?

Attach a Service Control Policy (SCP) to the organization root that denies the 'iam:DeleteRole', 'iam:UpdateAssumeRolePolicy', and 'iam:PutRolePolicy' actions on the resource 'arn:aws:iam::*:role/AuditCollectorRole'.

Define an IAM permission boundary in the management account, and use AWS Resource Access Manager (RAM) to share this permission boundary with all member accounts, requiring local administrators to attach it to their roles.

Deploy a Customer Managed Key (KMS CMK) in the security account, and configure all member accounts to require KMS decryption permissions for modifying the policy document of the AuditCollectorRole.

Create a Service Control Policy (SCP) that grants read-only IAM access to member accounts, assuming that the SCP automatically overrides local IAM policies to protect the AuditCollectorRole while allowing other IAM actions.

Show answer & explanation

Answer: Attach a Service Control Policy (SCP) to the organization root that denies the 'iam:DeleteRole', 'iam:UpdateAssumeRolePolicy', and 'iam:PutRolePolicy' actions on the resource 'arn:aws:iam::*:role/AuditCollectorRole'.

Answer

The correct strategy is to attach a Service Control Policy (SCP) to the organization root that denies specific IAM modification and deletion actions targeting the audit role resource path across all accounts.

Attaching a Service Control Policy (SCP) at the root of the organization allows the security team to enforce a guardrail across all member accounts. The deny policy targeting 'arn:aws:iam::*:role/AuditCollectorRole' prevents anyone, including local root users or administrators, from deleting or modifying the audit role, while still allowing them to manage all other IAM resources.

Step-by-Step Solution

Identify the governance tool capable of enforcing global boundaries across an AWS Organization.

Determine that Service Control Policies (SCPs) are the appropriate mechanism for multi-account governance.

SCPs define the maximum permissions for member accounts and cannot be overridden by local administrators.

Draft the policy statement targeting the specific IAM role.

Create an SCP statement with a Deny effect on actions 'iam:DeleteRole', 'iam:UpdateAssumeRolePolicy', and 'iam:PutRolePolicy' targeting the resource 'arn:aws:iam::*:role/AuditCollectorRole'.

This explicitly prevents deletion and policy modifications on the target role across all accounts while permitting actions on other role paths.

Attach the SCP at the appropriate level in the organization structure.

Attach the SCP to the organization root or to the parent OUs.

Applying the policy at the root or OU level ensures inheritance to all existing and future member accounts.

Key Concept

Using Service Control Policies (SCPs) as permission guardrails to restrict administrative actions on specific IAM resources across a multi-account organization.

Estimated Time:2m 0s

Question 286Question →

An enterprise is designing a multi-account architecture on AWS using AWS Organizations with all features enabled. The networking team has created a centralized VPC in a dedicated Network account and wants to share specific subnets with application development teams operating in separate accounts under an Application Organizational Unit (OU). The application workloads run on a combination of Amazon EC2 instances and AWS Fargate tasks. All EBS volumes and S3 buckets must be encrypted at rest using keys managed in a centralized Security account. The finance team requires that cost optimization benefits are maximized across all compute workloads, and billing is consolidated. Which TWO strategies should the solutions architect implement to meet these requirements securely and cost-effectively?

Select all that apply

Enable resource sharing within AWS Organizations from the management account. In the Network account, use AWS Resource Access Manager (RAM) to create a resource share for the subnets and associate it with the Application OU. Purchase Compute Savings Plans in the Organizations management account to automatically apply discounts to both EC2 instances and Fargate tasks across the consolidated billing family.

In the Security account, create a Customer Managed Key (CMK) and configure its key policy to allow the IAM principals in the Application accounts to perform KMS cryptographic operations and create grants. In the Application accounts, configure IAM policies allowing users to create grants on the Security account's CMK, and specify this key when launching EC2 instances and creating S3 buckets.

In the Security account, configure the AWS-managed KMS key for EBS (aws/ebs) with a cross-account key policy that lists the Application account root users as principals. In the Application accounts, configure the EC2 instances to use this AWS-managed key for encrypting all EBS volumes.

Attach a Service Control Policy (SCP) to the Application OU that explicitly grants ram:AssociateResourceShare permissions. In the Application accounts, configure the local IAM policies to automatically accept the subnet resource share invitations from the Network account.

Purchase EC2 Instance Savings Plans in the Organizations management account to cover the compute usage of both EC2 and Fargate across all member accounts. In the Network account, use AWS RAM to create a resource share for the EC2 Instance Savings Plans and associate it with the Application OU.

Show answer & explanation

Answer: Enable resource sharing within AWS Organizations from the management account. In the Network account, use AWS Resource Access Manager (RAM) to create a resource share for the subnets and associate it with the Application OU. Purchase Compute Savings Plans in the Organizations management account to automatically apply discounts to both EC2 instances and Fargate tasks across the consolidated billing family.; In the Security account, create a Customer Managed Key (CMK) and configure its key policy to allow the IAM principals in the Application accounts to perform KMS cryptographic operations and create grants. In the Application accounts, configure IAM policies allowing users to create grants on the Security account's CMK, and specify this key when launching EC2 instances and creating S3 buckets.

Answer

The solutions architect should enable resource sharing in AWS Organizations, use AWS RAM to share the subnets from the Network account, and purchase Compute Savings Plans in the management account. In addition, they must use a Customer Managed Key in the Security account configured to allow cross-account access and grant creation.

The correct strategy combines AWS RAM subnet sharing with Compute Savings Plans. By enabling resource sharing in AWS Organizations, subnets shared via RAM are accepted automatically. Compute Savings Plans purchased in the management account apply to both EC2 and Fargate across all linked accounts. For centralized encryption, the Security account must use a Customer Managed Key (CMK) configured to allow cross-account access and grant creation so application accounts can encrypt EBS volumes and S3 buckets.

Step-by-Step Solution

Enable Resource Sharing in AWS Organizations

Enables organization-wide resource sharing without manual resource share invitations.

Allows AWS Resource Access Manager (RAM) to automatically share the subnets in the Network VPC with the Application OU.

Select and Purchase Compute Savings Plans

Applies discount rates automatically across the organization's EC2 and Fargate workloads.

Compute Savings Plans are required to cover both EC2 and Fargate workloads, whereas EC2 Instance Savings Plans only apply to EC2.

Create and Share a Customer Managed Key (CMK)

Establishes a key policy in the Security account allowing cross-account cryptographic actions and grant creation.

AWS-managed KMS keys cannot be shared cross-account, requiring a CMK to be created and delegated via key and IAM policies.

Key Concept

Multi-account resource sharing requires enabling Organizations integration in RAM. Cross-account key sharing requires Customer Managed Keys (CMKs) and grant permissions. Cost optimization across Fargate and EC2 requires Compute Savings Plans under consolidated billing.

Question 287Question →

A financial services company is designing a multi-account architecture using AWS Organizations with 50 member accounts. Security policies require that administrators authenticate using the company's on-premises SAML 2.0 compliant Identity Provider (IdP) to access a highly privileged role named AdminAccessRole in each member account. The security requirements are as follows:
- Federated administrative sessions must support a duration of up to 4 hours.
- Administrators must be blocked from assuming the AdminAccessRole if they did not perform Multi-Factor Authentication (MFA) at the corporate IdP.
Which combination of actions must a solutions architect take to meet these requirements? (Select TWO.)

Select all that apply

Create an IAM SAML identity provider in each of the 50 member accounts using the XML metadata document from the corporate IdP. In each member account, create the AdminAccessRole with a trust policy that lists the local SAML provider as the principal and allows the sts:AssumeRoleWithSAML action.

Configure the trust policy of the AdminAccessRole in each member account to include a condition block verifying that the SAML:AuthnContextClassRef key matches multi-factor authentication context classes, and set the role's MaxSessionDuration attribute to 14400 seconds.

Establish a hub-and-spoke model by creating the SAML identity provider and a gateway IAM role in a central identity account. Have users federate into the identity account first, and then perform role chaining to assume the target AdminAccessRole in the member accounts, setting the target role's MaxSessionDuration to 14400 seconds.

Apply a Service Control Policy (SCP) at the root level of the AWS Organization that denies the sts:AssumeRoleWithSAML action unless the aws:MultiFactorAuthPresent condition key is set to true.

Show answer & explanation

Answer: Create an IAM SAML identity provider in each of the 50 member accounts using the XML metadata document from the corporate IdP. In each member account, create the AdminAccessRole with a trust policy that lists the local SAML provider as the principal and allows the sts:AssumeRoleWithSAML action.; Configure the trust policy of the AdminAccessRole in each member account to include a condition block verifying that the SAML:AuthnContextClassRef key matches multi-factor authentication context classes, and set the role's MaxSessionDuration attribute to 14400 seconds.

Answer

To meet the requirements, the solutions architect must create a SAML identity provider in each member account to allow direct federation, configure the trust policies to validate the SAML:AuthnContextClassRef attribute for MFA, and set the MaxSessionDuration to 14400 seconds.

To support a 4-hour session duration, users must federate directly into the target member accounts rather than using a hub-and-spoke role chaining model, which imposes a hard 1-hour limit on session duration. Direct federation requires creating a SAML identity provider in each member account and creating the target role with a trust policy that allows the sts:AssumeRoleWithSAML action. Furthermore, because AWS-managed Multi-Factor Authentication (MFA) is not used for external identity providers, the aws:MultiFactorAuthPresent key evaluates to false or null. Instead, the solutions architect must configure the trust policy to inspect the SAML:AuthnContextClassRef attribute sent in the SAML assertion to verify that MFA occurred at the IdP.

Step-by-Step Solution

Analyze session duration requirements for federated users.

Determine that role chaining limits sessions to 1 hour, meaning users must federate directly to each target account to support a 4-hour session.

AWS enforces a hard 1-hour limit on role sessions assumed via role chaining (AssumeRole).

Establish trust relationships in target member accounts.

Create a SAML identity provider in each of the 50 member accounts and create the target IAM role with a trust policy allowing AssumeRoleWithSAML.

SAML identity providers must exist locally in each account where direct federation is performed.

Configure Multi-Factor Authentication enforcement for federated access.

Use the SAML:AuthnContextClassRef key in the trust policy condition block to check for MFA-specific authentication context classes.

The standard aws:MultiFactorAuthPresent key is not populated for external SAML federated sessions.

Configure the session duration limit on the target roles.

Set the MaxSessionDuration attribute of the AdminAccessRole to 14400 seconds (4 hours).

This allows the federated session to remain valid for the requested 4 hours, assuming the SAML assertion also permits it.

Key Concept

Multi-Account SAML 2.0 Federation Session Limits and MFA Validation

Question 288Question →

A retail company manages its multi-account AWS environment. The core infrastructure team maintains a Route 53 Private Hosted Zone (PHZ) named service.internal in Account 111111111111. A development team in Account 222222222222 has deployed a microservice inside a new VPC and needs resources within this VPC to resolve domain names in service.internal. The VPCs in both accounts are connected via an AWS Transit Gateway. Which process should the Solutions Architect implement to enable name resolution for the microservice VPC in Account 222222222222?

Authorize the cross-account association from Account 111111111111 using the AWS CLI or Route 53 API, and then associate the microservice VPC with the hosted zone from Account 222222222222.

Share the Private Hosted Zone from Account 111111111111 with Account 222222222222 using AWS Resource Access Manager (RAM), and then accept the share in Account 222222222222.

Configure the Transit Gateway route tables to route DNS queries on port 53 from the microservice VPC directly to the Amazon-provided DNS server IP address of the core VPC in Account 111111111111.

Create a Private Hosted Zone named service.internal in Account 222222222222, define a Route 53 Resolver outbound endpoint in the microservice VPC, and configure a forwarding rule pointing to the VPC DNS resolver of Account 111111111111.

Show answer & explanation

Answer: Authorize the cross-account association from Account 111111111111 using the AWS CLI or Route 53 API, and then associate the microservice VPC with the hosted zone from Account 222222222222.

Answer

Authorize the cross-account association from the account owning the Private Hosted Zone using the AWS CLI or API, and then associate the VPC with the hosted zone from the account owning the VPC.

The correct answer describes the standard two-step AWS CLI/API workflow for cross-account Route 53 Private Hosted Zone (PHZ) association. The owner of the PHZ must first authorize the association with the external VPC, and then the owner of the VPC must perform the association.

Step-by-Step Solution

Submit a VPC association authorization from Account 111111111111.

Account 222222222222 is authorized to associate its VPC with the hosted zone service.internal.

VPCs and Private Hosted Zones in different accounts cannot be directly associated without explicit authorization.

Associate the microservice VPC with the service.internal Private Hosted Zone from Account 222222222222.

The microservice VPC is associated with the Private Hosted Zone.

This establishes the DNS resolution path for the resources in the microservice VPC.

Delete the association authorization from Account 111111111111 (optional).

The authorization is removed, but the active association remains intact.

This is a security best practice to clean up unused authorizations.

Key Concept

Cross-account Route 53 Private Hosted Zone association requires a two-step process: authorization from the hosted zone owner account, followed by the association request from the VPC owner account.

Estimated Time:1m 0s

Question 289Question →

An enterprise manages a multi-account environment using AWS Organizations with consolidated billing. The architecture includes a management account, a shared networking account, and multiple member accounts for application teams.

The solutions architect must design a resource sharing and cost management strategy with the following requirements:
- Share VPC subnets from the networking account to application member accounts to allow application deployments.
- Ensure EBS volumes created by application teams in their respective accounts are encrypted using a centralized KMS key managed by the Security team in a dedicated Security account.
- Maximize cost savings across the organization, which runs a combination of Amazon EC2 instances, AWS Fargate tasks, and AWS Lambda functions across all application accounts.
- Ensure the sharing of VPC subnets is restricted strictly to accounts within the AWS Organization.

Which of the following strategies represents the most secure, operationally efficient, and cost-effective solution to meet these requirements?

In the networking account, create an AWS Resource Access Manager (RAM) resource share for the subnets, selecting the AWS Organization ID as the principal, without enabling resource sharing in the AWS Organizations management account. In the Security account, create a KMS Customer Managed Key (CMK) with a key policy allowing cross-account access. In the management account, purchase Compute Savings Plans, and disable billing sharing in the consolidated billing settings to force the discount application to be calculated individually in each member account's console.

In the networking account, create an AWS RAM resource share for the subnets, selecting the individual application account IDs as principals. In the Security account, use the AWS managed key (aws/ebs) and update its policy to allow the application accounts to perform cryptographic operations. In the management account, purchase EC2 Instance Savings Plans to maximize discounts for the EC2, Fargate, and Lambda workloads.

Enable resource sharing in the AWS Organizations management account. In the networking account, create an AWS Resource Access Manager (RAM) resource share for the subnets, selecting the AWS Organization ID as the principal. In the Security account, create a KMS Customer Managed Key (CMK) with a key policy that allows root-level principal access from the application accounts, and configure local IAM policies in the application accounts to delegate permissions. In the management account, purchase Compute Savings Plans to cover EC2, Fargate, and Lambda usage across all consolidated accounts.

Enable resource sharing in the AWS Organizations management account. In the networking account, create an AWS RAM resource share for the subnets, selecting the AWS Organization ID as the principal. In the Security account, create a KMS Customer Managed Key (CMK). Attach a Service Control Policy (SCP) to the application accounts' OU that explicitly grants kms:Decrypt and kms:GenerateDataKeyWithoutPlaintext permissions to all local IAM users, assuming this grants permissions without local IAM policies. In the management account, purchase EC2 Instance Savings Plans.

Show answer & explanation

Answer: Enable resource sharing in the AWS Organizations management account. In the networking account, create an AWS Resource Access Manager (RAM) resource share for the subnets, selecting the AWS Organization ID as the principal. In the Security account, create a KMS Customer Managed Key (CMK) with a key policy that allows root-level principal access from the application accounts, and configure local IAM policies in the application accounts to delegate permissions. In the management account, purchase Compute Savings Plans to cover EC2, Fargate, and Lambda usage across all consolidated accounts.

Answer

The correct strategy enables resource sharing in the AWS Organizations management account, creates an AWS RAM resource share for the subnets targeting the AWS Organization ID, uses a KMS Customer Managed Key (CMK) in the Security account with delegated policy access to application accounts, and purchases Compute Savings Plans in the management account.

The correct strategy enables resource sharing at the organization level to allow seamless sharing of subnets using the Organization ID as the principal. It utilizes a Customer Managed Key (CMK) in the Security account since AWS-managed keys cannot be shared across accounts. The CMK key policy delegates permission to the member accounts, which then use local IAM policies to grant access. Finally, purchasing Compute Savings Plans in the consolidated billing management account ensures discounts are applied to EC2, Fargate, and Lambda across all member accounts.

Step-by-Step Solution

Enable resource sharing in the AWS Organizations management account and share the subnets via AWS RAM.

Subnets are successfully shared with member accounts within the AWS Organization without requiring manual invitations.

AWS RAM requires organizational sharing to be enabled in the management account to share resources using Organization or OU IDs as principals; otherwise, the sharing operation will fail or require external invitations.

Create a Customer Managed Key (CMK) in the Security account and delegate permissions to the application accounts.

The application accounts can use the CMK to encrypt and decrypt their EBS volumes.

AWS-managed KMS keys (like aws/ebs) cannot be shared across accounts because their key policies cannot be modified. A Customer Managed Key must be used with a key policy that delegates access to root in the application accounts, allowing local IAM policies to grant permissions to local roles.

Purchase Compute Savings Plans in the consolidated billing management account.

Cost savings are maximized and automatically applied to EC2, Fargate, and Lambda usage across all member accounts.

Compute Savings Plans apply to EC2, Fargate, and Lambda usage across the entire consolidated billing family, whereas EC2 Instance Savings Plans only apply to EC2 instances of a specific family and do not cover Fargate or Lambda.

Key Concept

Consolidated billing, cross-account resource sharing via AWS Resource Access Manager (RAM), cross-account KMS encryption, and organization-wide Savings Plans mapping.

Estimated Time:3m 0s

Question 290Question →

A shipping logistics enterprise is setting up centralized logging for all member accounts within its AWS Organizations structure. The security team requires that AWS CloudTrail logs from all accounts be delivered to a single Amazon S3 bucket in a dedicated Logging account. The logs must be encrypted using AWS KMS. The architecture must ensure that member accounts cannot modify CloudTrail settings or access the centralized S3 bucket directly. Which configuration meets these requirements?

Create an organization trail in the Organizations management account that delivers logs to the S3 bucket in the Logging account. Configure the S3 bucket policy to allow write access to the CloudTrail service principal for the Organization. Create a customer managed KMS key in the Logging account with a key policy allowing the CloudTrail service principal to generate data keys, and use this key to encrypt the trail. Attach an SCP to the Organization root that denies member accounts from disabling CloudTrail or accessing the Logging account's S3 bucket.

Create an organization trail in the Organizations management account that delivers logs to the S3 bucket in the Logging account. Configure the S3 bucket policy to allow write access to the CloudTrail service principal for the Organization. Enable encryption on the trail using the default AWS-managed KMS key (aws/cloudtrail) in the Logging account, and update the default key policy to allow cross-account usage. Attach an SCP to the Organization root that denies member accounts from disabling CloudTrail or accessing the Logging account's S3 bucket.

Create a local CloudTrail trail in each member account that delivers logs to the S3 bucket in the Logging account. Attach an SCP to the Organization root that grants the member accounts' CloudTrail service principal write permissions to the Logging account's S3 bucket and decrypt permissions for the KMS key. Remove the bucket policy from the S3 bucket in the Logging account to simplify administration, and deny member accounts from disabling CloudTrail.

Create an organization trail in the Organizations management account that delivers logs to the S3 bucket in the Logging account. Configure the S3 bucket policy in the Logging account to grant read/write access to the Organization's management account IAM users, assuming CloudTrail inherits these management account permissions during log delivery. Create a customer managed KMS key in the Logging account with a key policy allowing the management account to generate data keys. Attach an SCP to the Organization root that denies member accounts from disabling CloudTrail.

Show answer & explanation

Answer: Create an organization trail in the Organizations management account that delivers logs to the S3 bucket in the Logging account. Configure the S3 bucket policy to allow write access to the CloudTrail service principal for the Organization. Create a customer managed KMS key in the Logging account with a key policy allowing the CloudTrail service principal to generate data keys, and use this key to encrypt the trail. Attach an SCP to the Organization root that denies member accounts from disabling CloudTrail or accessing the Logging account's S3 bucket.

Answer

The correct configuration is to create an organization trail in the management account, write to an S3 bucket in the Logging account using a customer managed KMS key, configure resource-based policies to allow the CloudTrail service principal access, and apply an SCP to prevent modification of the trail and direct access to the logging bucket.

The correct solution involves setting up an organization trail, which centralizes management and automatically includes all member accounts. Because the logs are encrypted and stored in a different account, a Customer Managed Key (CMK) must be used since AWS-managed KMS keys do not support policy modification to allow cross-account access. The S3 bucket policy and KMS key policy must grant permissions specifically to the CloudTrail service principal (cloudtrail.amazonaws.com). Finally, an SCP is used as a guardrail to prevent member accounts from stopping logging or accessing the logging bucket directly.

Step-by-Step Solution

Configure the destination S3 bucket and a Customer Managed Key (CMK) in the dedicated Logging account.

An S3 bucket is created with a bucket policy allowing 's3:PutObject' from the CloudTrail service principal, restricted by the Organization ID condition. A CMK is created with a key policy allowing the CloudTrail service principal to perform 'kms:GenerateDataKey*' and 'kms:DescribeKey'.

CloudTrail requires explicit permissions in the destination account's resource policies to deliver encrypted logs across accounts.

Create an Organization-wide CloudTrail trail in the AWS Organizations management account.

A multi-region organization trail is created, which automatically starts logging events from all current and future member accounts to the central S3 bucket using the specified Logging account's KMS key.

Organization trails ensure governance by automatically capturing API activity from all member accounts without manual configuration in individual accounts.

Attach a Service Control Policy (SCP) to the organization root.

An SCP is applied that denies member accounts from running 'cloudtrail:UpdateTrail', 'cloudtrail:DeleteTrail', or 'cloudtrail:StopLogging', and prevents them from accessing the centralized logging S3 bucket directly.

SCPs act as guardrails to prevent member account administrators from altering auditing controls or tampering with logs.

Key Concept

Centralized cross-account logging with AWS CloudTrail, KMS Customer Managed Keys, and Service Control Policies.

Estimated Time:2m 0s

Question 291Question →

A retail corporation has configured a multi-account AWS environment using AWS Organizations. The security team is setting up federated single sign-on (SSO) using an on-premises SAML 2.0-compliant Identity Provider (IdP). The solutions architect needs to configure the IAM roles in the member accounts to trust the SAML IdP. When external users attempt to log in through the IdP portal, they receive access denied errors before they can select a role. Which of the following configurations must the solutions architect apply to the IAM roles in the target member accounts to successfully establish the trust relationship?

Configure the IAM role trust policy to specify the SAML provider ARN as the Principal, and set the Action to sts:AssumeRole.

Configure the IAM role trust policy to specify the SAML provider ARN as the Principal, and set the Action to sts:AssumeRoleWithSAML.

Attach a Service Control Policy (SCP) to the target member accounts that allows the sts:AssumeRoleWithSAML action for the SAML provider ARN.

Configure the IAM role trust policy to trust the SAML provider ARN, and configure the default AWS-managed KMS key (aws/iam) in the target account to allow decryption of the SAML assertion.

Show answer & explanation

Answer: Configure the IAM role trust policy to specify the SAML provider ARN as the Principal, and set the Action to sts:AssumeRoleWithSAML.

Answer

Configure the IAM role trust policy to specify the SAML provider ARN as the Principal, and set the Action to sts:AssumeRoleWithSAML.

The correct configuration establishes a direct trust relationship between the IAM role in the member account and the SAML Identity Provider. This is achieved by specifying the SAML provider's ARN as the Principal and setting the Action to sts:AssumeRoleWithSAML in the role's trust policy. This action permits AWS STS to return temporary security credentials to users authenticated by the external IdP.

Step-by-Step Solution

Identify the authentication flow requirement.

The authentication flow uses SAML 2.0 federation from an external Identity Provider (IdP) to access target AWS accounts.

This requires the Security Token Service (STS) to validate SAML assertions and issue temporary security credentials.

Determine the correct API action for SAML-based federation.

The correct API action is sts:AssumeRoleWithSAML.

Unlike standard role assumption (sts:AssumeRole) which is used for IAM users or cross-account roles, sts:AssumeRoleWithSAML is specifically designed for SAML 2.0 identity federation.

Configure the trust relationship policy on the target IAM roles.

The trust policy specifies the SAML Identity Provider's ARN as the Principal and allows the Action sts:AssumeRoleWithSAML.

This establishes the necessary trust relationship, allowing federated users to successfully assume the target roles.

Key Concept

SAML 2.0 federation requires the sts:AssumeRoleWithSAML action in the IAM role's trust policy.

Question 292Question →

An enterprise is designing a centralized egress inspection architecture using AWS Transit Gateway (TGW) to connect 50 spoke VPCs (CIDR range $10.0.0.0/8$ ) to a central Inspection VPC (CIDR range $172.16.0.0/16$ ). The Inspection VPC contains a Gateway Load Balancer (GWLB) backed by stateful firewalls to inspect all outbound traffic before it goes to the internet through NAT Gateways. The Inspection VPC is deployed across multiple Availability Zones, with each zone containing a TGW subnet, a GWLB endpoint (GWLBe) subnet, and a NAT Gateway subnet. Which configuration of Transit Gateway (TGW) route tables and Inspection VPC route tables must the solutions architect implement to ensure that all egress traffic is inspected and returned symmetrically without routing loops or dropping packets?

Associate the spoke VPCs with a Spoke TGW Route Table containing a default route (

0.0.0.0/0

) to the Inspection VPC attachment. Associate the Inspection VPC with an Inspection TGW Route Table containing a route for

10.0.0.0/8

pointing to the spoke VPC attachments. In the Inspection VPC, configure the TGW subnet route tables with

0.0.0.0/0 \rightarrow GWLBe

; the GWLBe subnet route tables with

0.0.0.0/0 \rightarrow NAT\ Gateway

and

10.0.0.0/8 \rightarrow TGW

; and the NAT Gateway subnet route tables with

0.0.0.0/0 \rightarrow IGW

and

10.0.0.0/8 \rightarrow GWLBe

Associate all spoke VPCs and the Inspection VPC with a single TGW Route Table containing a default route (

0.0.0.0/0

) pointing to the Inspection VPC attachment. In the Inspection VPC, configure the TGW subnet route tables with

0.0.0.0/0 \rightarrow GWLBe

; the GWLBe subnet route tables with

0.0.0.0/0 \rightarrow NAT\ Gateway

and

10.0.0.0/8 \rightarrow TGW

; and the NAT Gateway subnet route tables with

0.0.0.0/0 \rightarrow IGW

and

10.0.0.0/8 \rightarrow TGW

Associate the spoke VPCs with a Spoke TGW Route Table containing a default route (

0.0.0.0/0

) to the Inspection VPC attachment. Associate the Inspection VPC with an Inspection TGW Route Table containing a route for

10.0.0.0/8

pointing to the spoke VPC attachments. In the Inspection VPC, route the TGW subnet route tables with

0.0.0.0/0 \rightarrow NAT\ Gateway

deployed in a single Availability Zone. Configure the GWLBe subnet route tables with

0.0.0.0/0 \rightarrow TGW

, and the NAT Gateway subnet route tables with

0.0.0.0/0 \rightarrow IGW

and

10.0.0.0/8 \rightarrow TGW

Associate the spoke VPCs with a Spoke TGW Route Table containing a default route (

0.0.0.0/0

) to the Inspection VPC attachment. Associate the Inspection VPC with an Inspection TGW Route Table containing a route for

10.0.0.0/8

pointing to the spoke VPC attachments. In the Inspection VPC, configure the TGW subnet route tables with

0.0.0.0/0 \rightarrow GWLBe

; the GWLBe subnet route tables with

0.0.0.0/0 \rightarrow NAT\ Gateway

and associate a Route 53 Private Hosted Zone (PHZ) for name resolution; and the NAT Gateway subnet route tables with

0.0.0.0/0 \rightarrow IGW

and no explicit routes for

10.0.0.0/8

, relying on the local VPC route.

Show answer & explanation

Answer: Associate the spoke VPCs with a Spoke TGW Route Table containing a default route ( $0.0.0.0/0$ ) to the Inspection VPC attachment. Associate the Inspection VPC with an Inspection TGW Route Table containing a route for $10.0.0.0/8$ pointing to the spoke VPC attachments. In the Inspection VPC, configure the TGW subnet route tables with $0.0.0.0/0 \rightarrow GWLBe$ ; the GWLBe subnet route tables with $0.0.0.0/0 \rightarrow NAT\ Gateway$ and $10.0.0.0/8 \rightarrow TGW$ ; and the NAT Gateway subnet route tables with $0.0.0.0/0 \rightarrow IGW$ and $10.0.0.0/8 \rightarrow GWLBe$ .

Answer

Associate the spoke VPCs with a TGW route table that routes default traffic (

0.0.0.0/0

) to the Inspection VPC, and associate the Inspection VPC with a separate TGW route table containing routes for the spoke CIDR (

10.0.0.0/8

) pointing to the spoke attachments. In the Inspection VPC, configure the TGW subnets to route

0.0.0.0/0

to the GWLBe; the GWLBe subnets to route

0.0.0.0/0

to the NAT Gateway and

10.0.0.0/8

to the TGW; and the NAT Gateway subnets to route

0.0.0.0/0

to the IGW and

10.0.0.0/8

to the GWLBe.

The correct configuration uses two separate TGW route tables to prevent routing loops. In the Inspection VPC, traffic from the TGW is directed to the GWLBe for inspection. Once inspected, it is sent to the NAT Gateway and then the IGW. For return traffic, the NAT Gateway subnet routes the spoke CIDR (

10.0.0.0/8

) back to the GWLBe to maintain stateful symmetry, and the GWLBe subnet routes that traffic back to the TGW, which forwards it to the correct spoke VPC.

Step-by-Step Solution

Separate the Transit Gateway route tables for the spoke VPCs and the Inspection VPC.

Two distinct TGW route tables: Spoke TGW Route Table with a default route (

0.0.0.0/0

) pointing to the Inspection VPC, and Inspection TGW Route Table with routes for

10.0.0.0/8

pointing to the spoke VPCs.

This prevents routing loops when return traffic is sent from the Inspection VPC back to the Transit Gateway.

Configure the outbound routing in the Inspection VPC subnets.

TGW subnet routes

0.0.0.0/0

to the GWLBe. GWLBe subnet routes

0.0.0.0/0

to the NAT Gateway. NAT Gateway subnet routes

0.0.0.0/0

to the IGW.

This forces all outbound traffic arriving from the spokes to go through the GWLB endpoints for firewall inspection before reaching the NAT Gateway and the internet.

Configure the inbound (return) routing in the Inspection VPC subnets for symmetric flow.

NAT Gateway subnet routes

10.0.0.0/8

to the GWLBe. GWLBe subnet routes

10.0.0.0/8

to the TGW.

This ensures that return traffic from the internet is sent back through the same stateful firewalls via the GWLBe before being sent back to the TGW and the spoke VPCs, maintaining flow symmetry.

Key Concept

Centralized egress security inspection with Gateway Load Balancer and AWS Transit Gateway

Question 293Question →

An organization wants to ensure that its developers can create resources in a sandbox Organizational Unit (OU) but are strictly prevented from using any AWS services outside the us-east-1 and us-west-2 Regions. The solutions architect wants to apply this guardrail centrally across all accounts in the sandbox OU without modifying individual IAM roles or users. Which approach should the solutions architect use to meet these requirements?

Define an IAM policy in the organization's management account that denies actions outside us-east-1 and us-west-2, expecting it to be inherited by all local IAM users and roles in member accounts.

Attach a Service Control Policy (SCP) to the sandbox Organizational Unit that denies all actions unless the requested region is us-east-1 or us-west-2.

Use AWS Resource Access Manager (RAM) to share a region-restricting IAM policy from the management account to all member accounts in the sandbox Organizational Unit.

Configure a Customer Managed Key in AWS Key Management Service with a key policy that restricts access to us-east-1 and us-west-2, and enforce its use for all services in the sandbox Organizational Unit.

Show answer & explanation

Answer: Attach a Service Control Policy (SCP) to the sandbox Organizational Unit that denies all actions unless the requested region is us-east-1 or us-west-2.

Answer

Attach a Service Control Policy (SCP) to the sandbox Organizational Unit that denies all actions unless the requested region is us-east-1 or us-west-2.

Attaching a Service Control Policy (SCP) to the sandbox Organizational Unit (OU) allows the organization to define permission guardrails that centrally restrict member accounts. An SCP containing a Deny rule with a condition evaluating the requested region ensures that no API requests can be executed outside the specified regions, regardless of local administrator permissions.

Step-by-Step Solution

Identify the requirement to apply a centralized regional guardrail across all accounts in a specific Organizational Unit.

Determine that Service Control Policies (SCPs) are the primary AWS feature used to apply guardrails across member accounts in an organization.

SCPs act as filters to restrict the maximum permissions available to member accounts in an OU.

Formulate a policy with a Deny effect that targets the NotEquals condition for the aws:RequestedRegion key with values us-east-1 and us-west-2.

Create an SCP that blocks actions outside the approved regions.

This ensures any API request made to a region other than the specified ones is blocked.

Attach the SCP to the target sandbox Organizational Unit (OU) rather than individual member accounts or local IAM identities.

All accounts inside the sandbox OU immediately inherit the regional restriction.

Attaching the policy at the OU level provides centralized governance with minimal operational overhead.

Key Concept

Service Control Policies (SCPs) in AWS Organizations are used to establish security and compliance guardrails across multiple accounts at the OU or account level.

Estimated Time:45s

Question 294Question →

A health-tech company is migrating its electronic health record (EHR) platform to AWS. The target topology consists of a central Network account containing a hub VPC, and multiple application accounts containing spoke VPCs, all interconnected via AWS Transit Gateway. The on-premises data center is connected to the hub VPC via an AWS Direct Connect connection. A Private Hosted Zone (PHZ) for the domain aws.healthtech.internal is created in a central Shared Services account. AWS resources in the spoke VPCs and servers on-premises must be able to resolve records in aws.healthtech.internal. Which of the following actions should the Solutions Architect take to establish this hybrid DNS resolution? (Select TWO.)

Select all that apply

Create Route 53 Resolver inbound endpoints in the Network account's hub VPC. On the on-premises DNS servers, configure conditional forwarders for the aws.healthtech.internal domain pointing to the inbound endpoint IP addresses.

In the Shared Services account, authorize the association of the aws.healthtech.internal Private Hosted Zone with each spoke VPC. In each application account, associate the spoke VPCs with the Private Hosted Zone.

Share the aws.healthtech.internal Private Hosted Zone with the AWS Organization using AWS Resource Access Manager (RAM) to automatically enable DNS resolution for all spoke VPCs.

Configure the spoke VPCs to use the Direct Connect Gateway as their primary DNS server to route all queries for the aws.healthtech.internal domain transitively to the on-premises DNS servers.

Create Route 53 Resolver outbound endpoints in each application account's spoke VPC, and configure them to forward all DNS queries directly to the inbound endpoints in the Network account.

Show answer & explanation

Answer: Create Route 53 Resolver inbound endpoints in the Network account's hub VPC. On the on-premises DNS servers, configure conditional forwarders for the aws.healthtech.internal domain pointing to the inbound endpoint IP addresses.; In the Shared Services account, authorize the association of the aws.healthtech.internal Private Hosted Zone with each spoke VPC. In each application account, associate the spoke VPCs with the Private Hosted Zone.

Answer

Create Route 53 Resolver inbound endpoints in the Network account's hub VPC, configure on-premises conditional forwarders pointing to these endpoints, and perform cross-account Private Hosted Zone association for the spoke VPCs.

To achieve DNS resolution for the private hosted zone from on-premises, you must deploy Route 53 Resolver inbound endpoints in the hub VPC and configure on-premises DNS servers to forward queries to those endpoints. For the spoke VPCs to resolve the zone, they must be associated with the Private Hosted Zone, which requires authorizing the association from the zone's owner account and associating the VPC from the spoke accounts.

Step-by-Step Solution

Enable on-premises resolution of the private hosted zone.

Route 53 Resolver inbound endpoints are created in the hub VPC. The on-premises DNS servers forward queries for aws.healthtech.internal to the inbound endpoint IP addresses over Direct Connect.

Inbound endpoints act as forwarding targets within the AWS network that have access to Route 53 private resolution.

Establish cross-account VPC association with the Private Hosted Zone.

The Shared Services account owner runs the authorization command for the spoke VPCs, and the application account owners associate their VPCs with the Private Hosted Zone.

This allows resources in the spoke VPCs to query Route 53 directly and resolve names in the shared private hosted zone.

Key Concept

Cross-account Private Hosted Zone association and hybrid name resolution using Route 53 Resolver endpoints.

Estimated Time:2m 0s

Question 295Question →

A multinational enterprise is designing a centralized logging architecture across its AWS Organizations structure, which consists of over 200 member accounts. A solutions architect is setting up an organization-wide AWS CloudTrail trail that delivers log files to a single Amazon S3 bucket located in a dedicated Security account. The log files must be encrypted using AWS Key Management Service (AWS KMS).

The solutions architect needs to configure the S3 bucket policy and the KMS key policy in the Security account to allow CloudTrail to write logs and encrypt them, ensuring that the configurations scale dynamically as new accounts are added or removed from the organization.

Which combination of configurations will meet these requirements? (Select TWO.)

Select all that apply

Configure the Amazon S3 bucket policy in the Security account to grant s3:PutObject permissions to the cloudtrail.amazonaws.com service principal, restricting the resource path to arn:aws:s3:::my-central-bucket/AWSLogs/o-organizationid/*, and requiring the s3:x-amz-acl condition to be set to bucket-owner-full-control.

Create a Customer Managed Key (CMK) in the Security account and configure its key policy to grant the cloudtrail.amazonaws.com service principal kms:GenerateDataKey* and kms:Decrypt permissions, restricted by a condition that evaluates kms:EncryptionContext:aws:cloudtrail:arn against the organization trail ARN.

Configure the Amazon S3 bucket policy in the Security account to grant s3:PutObject permissions to the principal arn:aws:iam::*:root for all accounts in the organization by using the aws:PrincipalOrgID condition.

Configure the organization trail to use the default AWS-managed KMS key (aws/cloudtrail) in the management account, and update its key policy to allow cross-account access for all member accounts within the organization.

Attach a Service Control Policy (SCP) to the organization root that grants the cloudtrail.amazonaws.com service principal permission to assume the default OrganizationAccountAccessRole in the Security account to write logs.

Show answer & explanation

Answer: Configure the Amazon S3 bucket policy in the Security account to grant s3:PutObject permissions to the cloudtrail.amazonaws.com service principal, restricting the resource path to arn:aws:s3:::my-central-bucket/AWSLogs/o-organizationid/*, and requiring the s3:x-amz-acl condition to be set to bucket-owner-full-control.; Create a Customer Managed Key (CMK) in the Security account and configure its key policy to grant the cloudtrail.amazonaws.com service principal kms:GenerateDataKey* and kms:Decrypt permissions, restricted by a condition that evaluates kms:EncryptionContext:aws:cloudtrail:arn against the organization trail ARN.

Answer

Configure the S3 bucket policy to allow the CloudTrail service principal using the organization ID in the path and requiring the bucket-owner-full-control ACL, and create a Customer Managed Key (CMK) in the Security account with a key policy allowing the CloudTrail service principal to generate data keys and decrypt logs restricted by the trail's encryption context.

The correct configurations are the ones that configure the Amazon S3 bucket policy to allow the CloudTrail service principal to perform s3:PutObject using the Organization ID prefix and a requirement for bucket-owner-full-control ACL, along with configuring a Customer Managed Key policy to allow the CloudTrail service principal to perform kms:GenerateDataKey* and kms:Decrypt constrained by the trail's encryption context ARN. The S3 bucket policy dynamically scales using the Organization ID path without hardcoding individual accounts, and requiring the bucket-owner-full-control ACL guarantees that the central account owns the written objects. Using a Customer Managed Key is required because AWS-managed KMS keys cannot be shared cross-account, and restricting it via the encryption context ensures only the designated organization trail can utilize the key.

Step-by-Step Solution

Identify the writer of the log files in an organization trail.

Determine that the writer is the AWS CloudTrail service principal (cloudtrail.amazonaws.com), not the individual member accounts.

Bucket policies must grant write permissions directly to the CloudTrail service principal.

Design the S3 bucket policy path for scalability.

Use the prefix AWSLogs/o-organizationid/* to dynamically cover all member accounts within the organization without listing them individually.

Hardcoding over 200 account IDs is not operationally efficient and will exceed bucket policy size limits.

Address KMS encryption requirements for cross-account log delivery.

Create a Customer Managed Key (CMK) because the default AWS-managed KMS key (aws/cloudtrail or aws/s3) cannot be shared across accounts due to non-modifiable policies.

Member accounts need permissions to use the KMS key when writing logs, which is only possible via a Customer Managed Key policy.

Secure the KMS key by restricting its usage context.

Add a policy condition that validates kms:EncryptionContext:aws:cloudtrail:arn against the specific organization trail ARN.

Prevents unauthorized accounts outside the organization or unauthorized trails from utilizing the KMS key.

Key Concept

Cross-account centralized logging using AWS CloudTrail and AWS KMS in a multi-account organization structure.

Question 296Question →

An enterprise is expanding its AWS environment by migrating several regional e-commerce workloads into separate AWS accounts under a single organization in AWS Organizations. The security team has defined the following requirements:

1. Workloads must only be deployed within a set of approved AWS Regions.
2. Member accounts must not be able to disable or modify the compliance monitoring rules established by the security team.
3. Developers must maintain administrative privileges within their dedicated development accounts.

Which two actions should a Solutions Architect take to implement these controls? (Select TWO.)

Select all that apply

Create and attach a Service Control Policy (SCP) to the organization's root or relevant Organizational Units (OUs) that denies resource creation in non-approved Regions and denies modification of AWS Config resources.

Deploy the compliance monitoring rules as AWS Config organizational rules from the organization's management account.

Create an IAM policy with permissions boundaries and rely on IAM permission inheritance to automatically restrict local administrator roles in the member accounts.

Configure an Amazon S3 bucket policy in a centralized logging account that denies all write operations originating from non-approved AWS Regions.

Use AWS Resource Access Manager (RAM) to share the central security account's IAM roles and AWS Config configurations with the member accounts.

Show answer & explanation

Answer: Create and attach a Service Control Policy (SCP) to the organization's root or relevant Organizational Units (OUs) that denies resource creation in non-approved Regions and denies modification of AWS Config resources.; Deploy the compliance monitoring rules as AWS Config organizational rules from the organization's management account.

Answer

Deploy the compliance monitoring rules as AWS Config organizational rules from the organization's management account, and create and attach a Service Control Policy (SCP) to the organization's root or relevant Organizational Units (OUs) that denies resource creation in non-approved Regions and denies modification of AWS Config resources.

Deploying AWS Config rules as organizational rules ensures that they are automatically created in all member accounts and can only be modified or deleted by the organization's management account. Attaching an SCP at the OU or organization root level enforces absolute regional restrictions and prevents modification of Config resources, acting as a guardrail that local administrators cannot override.

Step-by-Step Solution

Analyze the constraints placed on developer accounts and compliance enforcement.

Developers must retain administrator privileges, meaning they can bypass local IAM controls and modify local resources. Therefore, organization-level guardrails must be utilized.

Local IAM policies or boundaries are insufficient because local administrators can alter them.

Address region lock and local resource protection requirements.

Identify that a Service Control Policy (SCP) attached to the OU or root is needed to enforce regional constraints and block modification of AWS Config.

SCPs apply to all principles in member accounts (including root and administrators) and cannot be overridden locally.

Ensure compliance rules cannot be modified by member accounts.

Identify that AWS Config rules should be deployed as organizational rules from the management account.

Rules deployed at the organization level are read-only in member accounts and cannot be deleted or edited by local administrators.

Key Concept

Enforcing multi-account governance requires utilizing Service Control Policies (SCPs) to set global guardrails (such as regional restrictions and resource protection) and AWS Config organizational rules to deploy tamper-proof compliance rules across all accounts.

Estimated Time:2m 0s

Question 297Question →

An automotive manufacturer is establishing a multi-account AWS landing zone. A central Shared Services account hosts a Route 53 Private Hosted Zone (PHZ) for `factory.internal` associated with the Shared Services VPC. Workloads in a Production VPC in a separate Production account need to resolve domains in `factory.internal`. Additionally, on-premises assembly line systems, connected via AWS Direct Connect and AWS Transit Gateway, must resolve domains in `factory.internal`. Which combination of actions will allow both the Production VPC workloads and the on-premises systems to resolve domains in `factory.internal`?

In the Shared Services account, authorize the association of the `factory.internal` Private Hosted Zone with the Production VPC. In the Production account, associate the Production VPC with the `factory.internal` Private Hosted Zone. Create a Route 53 Resolver Inbound Endpoint in the Shared Services VPC, and configure the on-premises DNS servers to forward queries for `factory.internal` to the Inbound Endpoint IP addresses.

Share the `factory.internal` Private Hosted Zone with the Production account and the on-premises network using AWS Resource Access Manager (RAM). In the Production VPC, accept the resource share. Create a Route 53 Resolver Inbound Endpoint in the Shared Services VPC, and configure the on-premises DNS servers to forward queries for `factory.internal` to the Inbound Endpoint IP addresses.

Rely on the AWS Transit Gateway connection between the Shared Services VPC and the Production VPC to route DNS traffic. Configure the Production VPC's DHCP options set to point to the Route 53 Resolver Inbound Endpoint in the Shared Services VPC. Forward the on-premises DNS queries for `factory.internal` directly to a Route 53 Resolver Outbound Endpoint in the Shared Services VPC.

In the Shared Services account, associate the `factory.internal` Private Hosted Zone with the Production VPC using the Route 53 console. Create a Route 53 Resolver Outbound Endpoint in the Shared Services VPC, and configure the on-premises DNS servers to route DNS traffic for `factory.internal` over an AWS Direct Connect public virtual interface directly to the Route 53 link-local DNS IP address (

169.254.169.253

Show answer & explanation

Answer: In the Shared Services account, authorize the association of the `factory.internal` Private Hosted Zone with the Production VPC. In the Production account, associate the Production VPC with the `factory.internal` Private Hosted Zone. Create a Route 53 Resolver Inbound Endpoint in the Shared Services VPC, and configure the on-premises DNS servers to forward queries for `factory.internal` to the Inbound Endpoint IP addresses.

Answer

The correct answer outlines the proper steps for cross-account Private Hosted Zone (PHZ) association and hybrid inbound resolution. Because Route 53 PHZs are account-bound, associating a VPC in another account requires an authorization step from the owner account before the association can be executed in the consumer account. To resolve these DNS records from on-premises, a Route 53 Resolver Inbound Endpoint must be created in a VPC associated with the PHZ. On-premises DNS servers are then configured to forward requests to the Inbound Endpoint's IP addresses.

Step-by-Step Solution

Authorize cross-account association of the Private Hosted Zone.

The Shared Services account runs `create-vpc-association-authorization` targeting the Production VPC ID.

Before a member VPC can associate with a PHZ owned by another account, the owner account must explicitly authorize the relationship.

Associate the Private Hosted Zone with the consumer VPC.

The Production account runs `associate-vpc-with-hosted-zone` using the authorized PHZ ID.

The association completes the connection, allowing resources in the Production VPC to resolve names defined in `factory.internal`.

Deploy an Inbound Resolver Endpoint in the Shared Services VPC.

IP addresses are assigned to the Inbound Endpoint within the Shared Services VPC subnets.

This endpoint receives external DNS queries from the on-premises environment over Direct Connect or VPN.

Configure on-premises forwarders.

On-premises DNS servers forward queries for `factory.internal` to the Inbound Resolver Endpoint IP addresses.

This routes the query into AWS Route 53 Resolver, which resolves it using the PHZ associated with the Shared Services VPC.

Key Concept

Cross-account Private Hosted Zone association requires explicit CLI/API authorization followed by association, while hybrid inbound DNS resolution relies on Route 53 Resolver Inbound Endpoints.

Question 298Question →

A software company manages its multi-account environment using AWS Organizations. The security team wants to permit developers in the Development Organizational Unit (OU) to use Amazon DynamoDB, while blocking access to all other AWS services. A solutions architect creates a Service Control Policy (SCP) that allows all DynamoDB actions and denies all other service actions, then attaches this SCP to the Development OU. After the policy is applied, developers in the Development OU report that they cannot access DynamoDB tables. Which of the following explains the cause of this issue?

The developers have not been granted the necessary DynamoDB permissions via local IAM policies in their respective member accounts.

The Service Control Policy successfully grants the DynamoDB permissions to the member accounts, but the developers are blocked because they have not been added to a local IAM group that explicitly inherits the Organization's SCP.

The DynamoDB tables are encrypted using AWS-managed KMS keys, which cannot be accessed by member accounts under the SCP due to policy delegation limits of AWS-managed keys.

The IAM roles assumed by the developers do not have the proper SAML trust relationship configured with the sts:AssumeRoleWithSAML action to allow federated access to the member accounts.

Show answer & explanation

Answer: The developers have not been granted the necessary DynamoDB permissions via local IAM policies in their respective member accounts.

Answer

The developers have not been granted the necessary DynamoDB permissions via local IAM policies in their respective member accounts.

In AWS Organizations, Service Control Policies (SCPs) define the maximum permissions for the affected member accounts. They act as filters (guardrails) and do not grant permissions directly to any user or role. For a user or role in a member account to perform an action, the action must be permitted by both the SCP and the local IAM policy. Therefore, even if the SCP permits DynamoDB actions, the developers will be denied access unless they have local IAM policies granting them the necessary DynamoDB permissions.

Step-by-Step Solution

Understand the role of Service Control Policies (SCPs) in AWS Organizations.

SCPs act as guardrails that specify the maximum permissions for the affected accounts but do not grant any permissions directly.

This establishes the fundamental behavior of AWS Organizations policies.

Identify the relationship between SCPs and local IAM policies.

For an action to be allowed, it must be permitted by BOTH the SCP (at the Organization/OU level) and the IAM policy (within the member account).

This is the core evaluation logic of AWS IAM and Organizations policies.

Analyze why developers are denied access to DynamoDB.

Since the SCP allows DynamoDB, the deny must be coming from the lack of a local IAM policy granting permission, as SCPs do not grant permissions by themselves.

This resolves the discrepancy between the SCP configuration and the developers' access issues.

Key Concept

AWS Organizations Service Control Policies (SCPs) act as permission filters rather than permission grantors.

Estimated Time:1m 30s

Question 299Question →

A digital media startup is setting up its AWS multi-account environment using AWS Organizations. The environment consists of a management account, a core networking account, a production workload account, and a development account. The startup has the following requirements:
1. Private subnets created in the core networking account must be shared with the production and development accounts to deploy application resources.
2. Database instances in the production account must be encrypted using an AWS KMS key that can be centrally managed and audited by the security team in the core account.
3. Compute Savings Plans discounts must be applied exclusively to the production account's workloads (which consist of a mix of Amazon EC2 and AWS Fargate) without being consumed by the development account's resources.

Which strategy should a solutions architect recommend to satisfy these requirements?

Enable resource sharing with AWS Organizations in the AWS Resource Access Manager (RAM) settings. Create a resource share in the core networking account for the private subnets, and associate it with the production and development accounts. Create a Customer Managed Key (CMK) in the core account, and configure its key policy to allow the production account to use the key for cryptographic operations. In the Billing Preferences of the management account, turn off Savings Plans discount sharing, and then purchase the Compute Savings Plans directly in the production account.

Enable resource sharing with AWS Organizations in the AWS Resource Access Manager (RAM) settings. Create a resource share in the core networking account for the private subnets, and associate it with the production and development accounts. Configure encryption on the database instances in the production account using the default AWS-managed KMS key for Amazon RDS (aws/rds), and update the default key policy to trust the production account. In the Billing Preferences of the management account, turn off Savings Plans discount sharing, and then purchase the Compute Savings Plans directly in the production account.

Enable resource sharing with AWS Organizations in the AWS Resource Access Manager (RAM) settings. Create a resource share in the core networking account for the private subnets, and associate it with the production and development accounts. Create a Customer Managed Key (CMK) in the core account, and configure its key policy to allow the production account to use the key for cryptographic operations. Purchase EC2 Instance Savings Plans in the management account, and use Service Control Policies (SCPs) to block the development account from utilizing the savings benefits.

Create a resource share in the AWS Resource Access Manager (RAM) console of the core networking account for the private subnets, and associate it with the production and development accounts, without enabling organization-wide sharing in the AWS RAM settings. Create a Customer Managed Key (CMK) in the core account, and configure its key policy to allow the production account to use the key. In the Billing Preferences of the management account, turn off Savings Plans discount sharing, and then purchase the Compute Savings Plans directly in the production account.

Show answer & explanation

Answer: Enable resource sharing with AWS Organizations in the AWS Resource Access Manager (RAM) settings. Create a resource share in the core networking account for the private subnets, and associate it with the production and development accounts. Create a Customer Managed Key (CMK) in the core account, and configure its key policy to allow the production account to use the key for cryptographic operations. In the Billing Preferences of the management account, turn off Savings Plans discount sharing, and then purchase the Compute Savings Plans directly in the production account.

Answer

To meet all requirements, the solutions architect must enable sharing with AWS Organizations in AWS RAM and share the subnets, use a Customer Managed Key (CMK) in the core account and modify its key policy for cross-account access, and disable Savings Plans discount sharing in the management account while purchasing Compute Savings Plans directly in the production workload account.

The correct strategy involves enabling AWS Organizations sharing in AWS RAM to distribute subnets, using a Customer Managed Key (CMK) with cross-account permissions for secure key management, and turning off Savings Plans discount sharing in the management account while purchasing Compute Savings Plans directly in the production account to restrict the discount application.

Step-by-Step Solution

Enable organization sharing in AWS Resource Access Manager (RAM) and share the subnets.

Allows subnets from the core networking account to be shared and accessed by the production and development accounts.

By default, AWS RAM cannot share resources within the Organization unless organization-wide sharing is enabled in the RAM settings.

Create a Customer Managed Key (CMK) and grant cross-account key permissions.

Enables the production account to use the KMS key in the core account for database encryption.

AWS-managed keys (like aws/rds) cannot be shared or modified. A customer managed key must be used to delegate cross-account permissions via its key policy.

Disable Savings Plans sharing in the management account and purchase Compute Savings Plans in the production account.

Ensures that the Savings Plans discounts apply only to the production account's workloads (EC2 and Fargate) and are not consumed by the development account's resources.

Disabling discount sharing at the management account level localizes the discount benefits to the specific account that purchased the Savings Plan. Compute Savings Plans are required to cover both EC2 and Fargate.

Key Concept

Multi-account resource sharing, cross-account KMS key access delegation, and selective application of AWS Savings Plans discounts.

Question 300Question →

An enterprise is designing a secure governance framework for its AWS Organizations structure, which consists of multiple organizational units (OUs) and a dedicated centralized Logging account. To comply with regulatory standards, a solutions architect must establish an organizational CloudTrail that logs all API activity across all member accounts. The architecture must adhere to the principle of least privilege by avoiding the use of the Management account for daily auditing tasks, and it must prevent any modifications or deletions of logging resources by member accounts.

What is the correct sequence of steps to configure this centralized, secure auditing solution?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

Register the Security Audit account as the delegated administrator for CloudTrail from the Organizations management account, configure the S3 bucket and KMS key resource policies in the Logging account, create the organizational trail from the Security Audit account, and then apply the Service Control Policy from the management account to the organization root.

The correct order begins with registering the Security Audit account as the delegated administrator for AWS CloudTrail from the management account. Next, the target resources (Amazon S3 bucket and KMS customer managed key) must be created and their resource policies configured in the central Logging account. This is mandatory before trail creation because CloudTrail validates the destination policies upon setup. The organizational trail is then created from the newly registered delegated administrator account. Finally, a Service Control Policy is attached to the organization root from the management account to prevent any member accounts from disabling or modifying the trail.

Step-by-Step Solution

Enable CloudTrail trusted access and register the Security Audit account as the delegated administrator from the Organizations management account.

The Security Audit account is authorized to create and manage organizational trails.

Security principles dictate delegating operations away from the management account, but only the management account holds the authority to perform this registration.

Create the Amazon S3 bucket and KMS customer managed key in the centralized Logging account, and update their policies to allow CloudTrail service principal access.

A secure, centralized storage location is prepared to receive and encrypt organization-wide logs.

CloudTrail validates destination S3 bucket permissions and KMS key accessibility at the time of trail creation. If these are not configured first, the trail setup will fail.

Create the organization-wide CloudTrail from the Security Audit account, linking it to the destination S3 bucket and KMS key.

The organizational trail starts collecting and delivering logs from all accounts to the central S3 bucket.

This establishes the active auditing mechanism across the entire Organization using the delegated administrator permissions.

Attach a Service Control Policy (SCP) at the Organization root from the management account.

Member accounts are blocked from disabling, modifying, or deleting the organizational trail.

This finalizes the governance structure by ensuring the audit baseline cannot be compromised by member account administrators.

Key Concept

Delegated Administration and Centralized Resource Control in AWS Organizations

PreviousPage 15 / 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