All practice questions

1964 questions

All types1,964 Multiple choice1,006 Multiple select931 Ordering27

A solutions architect is designing a deployment strategy for a new microservice that will run on AWS Fargate. The business requirements state that any new version of the microservice must receive traffic gradually to monitor for initial errors before all traffic is shifted. If the new version fails health checks, the deployment must automatically roll back. Which two AWS CodeDeploy deployment configurations should the solutions architect choose to meet these requirements? (Select two.)

Select all that apply

CodeDeployDefault.ECSCanary10Percent5Minutes

CodeDeployDefault.ECSLinear10PercentEvery1Minute

CodeDeployDefault.ECSAllAtOnce

CodeDeployDefault.OneAtATime

CodeDeployDefault.HalfAtATime

Show answer & explanation

Answer: CodeDeployDefault.ECSCanary10Percent5Minutes; CodeDeployDefault.ECSLinear10PercentEvery1Minute

Answer

The correct options are CodeDeployDefault.ECSCanary10Percent5Minutes and CodeDeployDefault.ECSLinear10PercentEvery1Minute because they are natively supported ECS deployment configurations that shift traffic gradually and support automatic rollbacks.

The correct options represent native ECS deployment configurations. Canary10Percent5Minutes shifts 10 percent of traffic and waits 5 minutes before shifting the remaining traffic. Linear10PercentEvery1Minute shifts 10 percent of traffic every minute until 100 percent is reached. Both configurations allow for monitoring and trigger automatic rollback if CloudWatch alarms or health checks fail during the deployment.

Step-by-Step Solution

Identify the compute platform and deployment requirements.

The microservice runs on AWS Fargate (ECS) and requires gradual traffic shifting with automatic rollbacks.

This narrows the choice of CodeDeploy configurations to those compatible with Amazon ECS and Fargate.

Filter out configurations that are incompatible with the compute platform.

Configurations like 'OneAtATime' and 'HalfAtATime' are for EC2/On-Premises and are discarded.

CodeDeploy has distinct configurations for EC2/On-Premises, AWS Lambda, and Amazon ECS.

Evaluate the remaining ECS configurations against the gradual routing requirement.

Canary and linear configurations route traffic gradually, whereas 'AllAtOnce' shifts all traffic immediately.

Only Canary and Linear configurations satisfy the requirement to shift traffic gradually to allow monitoring.

Key Concept

AWS CodeDeploy deployment configurations for Amazon ECS support gradual traffic shifting (canary and linear) to validate new container versions before shifting all traffic.

Estimated Time:1m 30s

Question 542Question →

A retail corporation is designing a hybrid DNS infrastructure across its on-premises data centers and multiple AWS accounts. The network architecture uses an AWS Transit Gateway to interconnect all VPCs. In the Network Services account, the team has configured a Route 53 Private Hosted Zone (PHZ) named `retail.internal` and associated it with a Hub VPC. The Hub VPC contains a Route 53 Resolver Inbound Endpoint. The team wants to ensure that all spoke VPCs in different member accounts and the on-premises servers can resolve DNS queries for `retail.internal`. Which of the following is the most operationally efficient method to satisfy these resolution requirements?

Associate the spoke VPCs with the `retail.internal` Private Hosted Zone by submitting cross-account association authorizations from the Network Services account and then associating the spoke VPCs from the member accounts. Configure the on-premises DNS servers to forward queries for `retail.internal` to the Route 53 Resolver Inbound Endpoint IPs in the Hub VPC.

Create a Route 53 Resolver Outbound Endpoint in each spoke VPC, and use AWS Resource Access Manager (RAM) to share the `retail.internal` Private Hosted Zone directly with all spoke VPCs in the AWS Organization.

Configure Route 53 Resolver Rules in each spoke VPC to forward queries for `retail.internal` to the Transit Gateway, and use a Direct Connect Gateway to route all DNS traffic directly to the on-premises DNS servers.

Share the Route 53 Resolver Inbound Endpoint with the entire AWS Organization using AWS Resource Access Manager (RAM), and configure the spoke VPCs' DHCP options sets to use the IP addresses of the Inbound Endpoint as their primary DNS servers.

Show answer & explanation

Answer: Associate the spoke VPCs with the `retail.internal` Private Hosted Zone by submitting cross-account association authorizations from the Network Services account and then associating the spoke VPCs from the member accounts. Configure the on-premises DNS servers to forward queries for `retail.internal` to the Route 53 Resolver Inbound Endpoint IPs in the Hub VPC.

Answer

Associate the spoke VPCs with the private hosted zone using cross-account association authorizations, and configure on-premises DNS servers to forward queries to the Route 53 Resolver Inbound Endpoint IPs.

The correct method involves establishing cross-account Private Hosted Zone associations for the spoke VPCs, which allows them to resolve the hosted zone directly. For hybrid resolution from on-premises, using a Route 53 Resolver Inbound Endpoint in the Hub VPC and configuring conditional forwarding on the on-premises DNS servers is the standard and most efficient pattern.

Step-by-Step Solution

Authorize the association of the Private Hosted Zone with the spoke VPCs.

The Network Services account submits an authorization request to associate the `retail.internal` PHZ with each spoke VPC ID in the other AWS accounts.

By default, Route 53 Private Hosted Zones cannot be associated with VPCs in other AWS accounts without explicit owner authorization.

Associate the spoke VPCs with the Private Hosted Zone.

The member accounts accept the authorization and associate their spoke VPCs with the `retail.internal` PHZ.

This allows EC2 instances and resources inside the spoke VPCs to resolve records in `retail.internal` directly via the Route 53 Resolver at the reserve VPC network address.

Configure forwarding on-premises.

On-premises DNS servers are configured with a conditional forwarder for `retail.internal` pointing to the IP addresses of the Inbound Resolver Endpoint in the Hub VPC.

This allows on-premises clients to traverse the hybrid connectivity (such as Direct Connect or VPN) to query the Hub VPC's resolver, which can resolve the PHZ.

Key Concept

Cross-account Private Hosted Zone association and hybrid DNS resolution using Route 53 Resolver Inbound Endpoints.

Question 543Question →

An enterprise manages a multi-account environment under AWS Organizations with consolidated billing. The environment contains a Management account, a Shared Services Network account, a Security account, and several Line of Business (LOB) member accounts grouped into Production and Development/Test Organizational Units (OUs). A solutions architect must design a solution to meet the following requirements:
1. Share VPC subnets from the central Shared Services Network account to the LOB member accounts to enable application deployments while preventing LOBs from creating their own VPCs or internet gateways.
2. Centrally log all API activity across all accounts to a single S3 bucket in the Security account, ensuring all logs are encrypted at rest using a customer-controlled KMS key and that log integrity is validated.
3. Apply Compute Savings Plans purchased in the Management account only to production workloads in the Production OU, ensuring development and testing workloads in the Development/Test OU do not receive the discount benefits.

Which TWO architectural steps must the solutions architect take to meet these requirements?

Select all that apply

In the Billing Console of the Management account, navigate to Preferences and disable Savings Plans discount sharing for the member accounts under the Development/Test OU. In the Shared Services Network account, create resource shares in AWS Resource Access Manager (RAM) to share specific VPC subnets with the Development/Test and Production OUs, ensuring RAM sharing is enabled in the Management account.

In the Management account, create an organization trail in AWS CloudTrail and configure it to deliver log files to an Amazon S3 bucket in the Security account. Configure the S3 bucket policy to allow the CloudTrail service principal to perform s3:PutObject with an Organization ID condition, and encrypt the logs using a Customer Managed Key (CMK) in the Security account with a key policy allowing CloudTrail to generate data keys and decrypt.

In the Management account, create a Service Control Policy (SCP) and attach it to the Development/Test OU with a deny rule for the action savingsplans:ApplyDiscount. In the Shared Services Network account, use AWS Resource Access Manager (RAM) to share the entire VPC resource with the LOB member accounts, and configure the LOB accounts to automatically deploy resources into the shared VPC's default subnets.

In the Management account, create an organization trail in AWS CloudTrail and configure it to deliver logs to an S3 bucket in the Security account. Encrypt the log files using the AWS-managed KMS key for S3 (aws/s3) in the Security account to simplify key management, and configure the S3 bucket policy in the Security account to trust all accounts within the organization structure using a wildcard principal.

In the Management account, set up AWS Billing Conductor to create custom billing groups for each OU. Apply a global billing rule that blocks the application of Savings Plans discounts to any pro-forma bills generated for the Development/Test billing group, and configure AWS Resource Access Manager to share the Shared Services VPC with external entities.

Show answer & explanation

Answer: In the Billing Console of the Management account, navigate to Preferences and disable Savings Plans discount sharing for the member accounts under the Development/Test OU. In the Shared Services Network account, create resource shares in AWS Resource Access Manager (RAM) to share specific VPC subnets with the Development/Test and Production OUs, ensuring RAM sharing is enabled in the Management account.; In the Management account, create an organization trail in AWS CloudTrail and configure it to deliver log files to an Amazon S3 bucket in the Security account. Configure the S3 bucket policy to allow the CloudTrail service principal to perform s3:PutObject with an Organization ID condition, and encrypt the logs using a Customer Managed Key (CMK) in the Security account with a key policy allowing CloudTrail to generate data keys and decrypt.

Answer

Disable Savings Plans discount sharing for the Development/Test OU member accounts under Billing Preferences in the Management account, and use AWS Resource Access Manager to share subnets from the Network account. Create an organization trail in the Management account delivering logs to an S3 bucket in the Security account, using a Customer Managed Key with cross-account access policies for encryption.

The correct solution uses AWS Resource Access Manager to share specific VPC subnets from the Network account, enabling centralized control of networking while allowing LOB accounts to run workloads. It turns off Savings Plans discount sharing for non-production accounts under Billing Preferences in the Management account, which is the only way to selectively apply the discount. To meet the centralized logging requirement, it creates an organization trail delivering logs to an S3 bucket in the Security account, utilizing a Customer Managed Key (CMK) with a key policy configured to allow cross-account encryption because AWS-managed keys cannot be shared cross-account.

Step-by-Step Solution

Disable Savings Plans discount sharing for selected development/test accounts.

Savings Plans discounts purchased in the Management account will only apply to the remaining accounts (such as production workloads).

By default, Savings Plans discounts are shared across all accounts in an organization; disabling sharing for specific accounts is managed via Billing Preferences in the Management account.

Share specific subnets from the Shared Services Network account using AWS Resource Access Manager (RAM).

LOB accounts can deploy resources into the shared subnets but cannot modify the VPC configuration or create internet gateways.

AWS RAM allows sharing of subnets to other accounts in the organization, enforcing segregation of duties and keeping VPC control centralized.

Create an Organization Trail in AWS CloudTrail from the Management account.

API activity from all member accounts is captured and centralized.

An Organization Trail ensures that log collection is enabled globally and cannot be modified by member accounts.

Configure the centralized S3 bucket and a Customer Managed KMS Key (CMK) in the Security account.

Logs are securely delivered and encrypted using a key whose policy allows cross-account access from the organization trail.

AWS-managed KMS keys do not support cross-account operations, making a Customer Managed Key mandatory for this setup.

Key Concept

Multi-account resource sharing, centralized logging, and cost optimization strategy

Question 544Question →

An enterprise manages its multi-account environment using AWS Organizations. The solutions architect needs to restrict member accounts in the 'Workloads' Organizational Unit (OU) so they can only launch EC2 instances of type `t3.micro` or `t3.small`. Developers in these member accounts already have the `AdministratorAccess` managed IAM policy attached to their roles. The solutions architect wants to implement this restriction with minimal administrative overhead. Which of the following approaches should the solutions architect implement?

Attach a Service Control Policy (SCP) to the 'Workloads' OU that denies the `ec2:RunInstances` action if the instance type is neither `t3.micro` nor `t3.small`, and rely on the existing local IAM policies to grant the launch permissions.

Replace the default `FullAWSAccess` SCP on the 'Workloads' OU with a custom SCP that explicitly allows the `ec2:RunInstances` action for `t3.micro` and `t3.small` instance types, then remove local IAM permissions.

Attach an SCP to the 'Workloads' OU that allows `ec2:RunInstances`, and share the AWS-managed KMS key `aws/ebs` from the management account to encrypt the EC2 volumes in the member accounts.

Configure an SCP to deny non-compliant instances, and configure a centralized S3 bucket policy in a logging account with a wildcard principal to collect CloudTrail logs from the member accounts.

Show answer & explanation

Answer: Attach a Service Control Policy (SCP) to the 'Workloads' OU that denies the `ec2:RunInstances` action if the instance type is neither `t3.micro` nor `t3.small`, and rely on the existing local IAM policies to grant the launch permissions.

Answer

The correct approach uses an SCP with an explicit deny for all instance types except the permitted ones. Because SCPs serve as permission filters rather than direct permission providers, they do not grant access on their own. Since the member account developers already possess the AdministratorAccess IAM policy, they already have local authorization to run instances. The deny SCP restricts this local capability only for non-compliant instance types, accomplishing the goal with zero modification of local IAM policies.

Step-by-Step Solution

Analyze how SCPs and IAM policies interact in AWS Organizations.

SCPs act as filters and define the maximum allowable permissions, but they do not grant permissions. Local IAM policies must still grant the permission for an action to succeed.

To ensure developers can run the permitted instances, they need both an SCP that does not deny the action and a local IAM policy that explicitly allows it.

Determine the most operationally efficient way to enforce the restriction.

Creating an SCP with an explicit Deny for all instance types except the allowed ones, while keeping the default FullAWSAccess SCP, blocks the non-compliant types without affecting other allowed services.

An explicit Deny overrides any Allow. Using a Deny SCP ensures non-compliant instances cannot be run, regardless of the admin permissions locally.

Verify if local IAM changes are required.

Since developers already have the AdministratorAccess policy, they already have permissions to run EC2 instances. No changes to member accounts are needed.

This minimizes administrative overhead by keeping the policy changes centralized at the OU level.

Key Concept

SCPs define permission boundaries (filters) and do not grant permissions directly. The effective permission is the intersection of the SCP and local IAM policies.

Estimated Time:2m 0s

Question 545Question →

A company is using AWS Organizations to manage multiple AWS accounts. The security team wants to centralize auditing by collecting AWS CloudTrail logs from all member accounts into a single Amazon S3 bucket located in a dedicated Security account. The logs must be encrypted at rest, and the configuration must minimize management overhead.

Which of the following steps are required to implement this solution? (Select TWO.)

Select all that apply

Create the trail in the organization management account and configure it as an organization trail.

Configure the Amazon S3 bucket policy in the Security account to grant write permissions to the CloudTrail service principal.

Create a local IAM role in each member account that allows the CloudTrail service to assume it and write to the Security account S3 bucket.

Encrypt the S3 bucket using the default AWS-managed KMS key (aws/s3) and grant cross-account permissions on this key to the member accounts.

Attach a Service Control Policy (SCP) to the organization root that explicitly grants permission for member accounts to write to the central S3 bucket.

Show answer & explanation

Answer: Create the trail in the organization management account and configure it as an organization trail.; Configure the Amazon S3 bucket policy in the Security account to grant write permissions to the CloudTrail service principal.

Answer

Create the trail in the organization management account as an organization trail, and configure the S3 bucket policy in the Security account to grant write permissions to the CloudTrail service principal.

To centralize CloudTrail logs from multiple accounts in an AWS Organization, an organization trail should be created in the management account. This automatically deploys the trail across all member accounts. The centralized S3 bucket must have a bucket policy that grants write permissions (s3:PutObject) to the CloudTrail service principal (cloudtrail.amazonaws.com) to allow cross-account delivery.

Step-by-Step Solution

Enable centralized trail creation.

By creating an organization trail in the management account, CloudTrail logs events from all current and future member accounts automatically without configuring trails manually in each account.

This minimizes operational overhead and ensures comprehensive coverage across the AWS Organization.

Configure destination bucket access.

The S3 bucket policy in the Security account is updated to allow the 'cloudtrail.amazonaws.com' principal to perform 's3:PutObject' actions, restricted by the organization ID condition.

CloudTrail requires explicit permission to write logs to a cross-account S3 bucket, which is managed via S3 bucket policies.

Key Concept

Centralized CloudTrail Logging in AWS Organizations

Question 546Question →

A corporate retail conglomerate is designing a hybrid DNS architecture across a multi-account AWS environment managed by AWS Organizations. The environment is connected to an on-premises network via AWS Transit Gateway. A central Shared Services account hosts a Route 53 Private Hosted Zone (PHZ) for `shared.retail.internal`. The on-premises servers host the DNS zone `onprem.retail.internal`. Spoke VPCs in multiple member AWS accounts host individual application workloads and need to resolve both `shared.retail.internal` and `onprem.retail.internal`. Additionally, on-premises clients must be able to resolve `shared.retail.internal`. The company wants to minimize resource duplication, endpoint costs, and administrative overhead. Which combination of steps will meet these requirements?

Create Route 53 Resolver inbound and outbound endpoints in the Shared Services VPC. In the Shared Services account, authorize the association of the `shared.retail.internal` PHZ with the spoke VPCs. In each member account, associate the spoke VPCs with the PHZ. In the Shared Services account, create a Route 53 Resolver outbound rule for `onprem.retail.internal` pointing to the on-premises DNS servers, share the rule with the organization using AWS Resource Access Manager (RAM), and associate the shared rule with each spoke VPC. Configure on-premises DNS forwarders to route queries for `shared.retail.internal` to the inbound Resolver endpoint IP addresses.

Create Route 53 Resolver inbound and outbound endpoints in the Shared Services VPC. Share the `shared.retail.internal` PHZ with the organization using AWS Resource Access Manager (RAM), and associate the hosted zone with the spoke VPCs in each member account. In the Shared Services account, create a Route 53 Resolver outbound rule for `onprem.retail.internal` pointing to the on-premises DNS servers, share the rule with the organization using AWS RAM, and associate the shared rule with each spoke VPC. Configure on-premises DNS forwarders to route queries for `shared.retail.internal` to the inbound Resolver endpoint IP addresses.

Create a Route 53 Resolver outbound endpoint in the Shared Services VPC. In the Shared Services account, authorize the association of the `shared.retail.internal` PHZ with the spoke VPCs. In each member account, associate the spoke VPCs with the PHZ. In the Shared Services account, create a Route 53 Resolver outbound rule for `onprem.retail.internal` pointing to the on-premises DNS servers, share the rule with the organization using AWS Resource Access Manager (RAM), and associate the shared rule with each spoke VPC. Configure on-premises DNS forwarders to route queries for `shared.retail.internal` to the Route 53 Resolver system IP address (

169.254.169.253

) via the Transit Gateway.

Create Route 53 Resolver inbound and outbound endpoints in the Shared Services VPC. In the Shared Services account, authorize the association of the `shared.retail.internal` PHZ with the spoke VPCs. In each member account, associate the spoke VPCs with the PHZ. In the Shared Services account, create a Route 53 Resolver outbound rule for `onprem.retail.internal` pointing to the on-premises DNS servers, and associate the outbound rule directly with the Transit Gateway to apply it to all spoke VPCs. Configure on-premises DNS forwarders to route queries for `shared.retail.internal` to the inbound Resolver endpoint IP addresses.

Show answer & explanation

Answer: Create Route 53 Resolver inbound and outbound endpoints in the Shared Services VPC. In the Shared Services account, authorize the association of the `shared.retail.internal` PHZ with the spoke VPCs. In each member account, associate the spoke VPCs with the PHZ. In the Shared Services account, create a Route 53 Resolver outbound rule for `onprem.retail.internal` pointing to the on-premises DNS servers, share the rule with the organization using AWS Resource Access Manager (RAM), and associate the shared rule with each spoke VPC. Configure on-premises DNS forwarders to route queries for `shared.retail.internal` to the inbound Resolver endpoint IP addresses.

Answer

Create Route 53 Resolver inbound and outbound endpoints in the Shared Services VPC. Authorize the cross-account association of the Private Hosted Zone with the spoke VPCs and associate them. Create a Route 53 Resolver outbound rule for the on-premises domain, share it via AWS Resource Access Manager (RAM), and associate it with each spoke VPC. Configure on-premises DNS forwarders to target the inbound Resolver endpoint IP addresses.

The correct solution uses a centralized Shared Services VPC to host Route 53 Resolver inbound and outbound endpoints, minimizing costs and duplicate endpoints. Spoke VPCs can resolve the Private Hosted Zone (PHZ) in the Shared Services account via cross-account VPC association, which is authorized by the owning account and then associated by the target account. Outbound resolution to the on-premises network is handled by a Route 53 Resolver outbound rule shared via AWS Resource Access Manager (RAM) and associated with the spoke VPCs. Inbound queries from on-premises to AWS are routed to the central inbound Resolver endpoint IP addresses, which can be reached via Transit Gateway routing.

Step-by-Step Solution

Configure cross-account Private Hosted Zone (PHZ) resolution for the spoke VPCs.

Authorized association using the `create-vpc-association-authorization` CLI/API call in the Shared Services account, and completed the association using the `associate-vpc-with-private-hosted-zone` call in the member accounts.

This allows instances in the spoke VPCs to resolve resources in the `shared.retail.internal` zone directly using the default Route 53 VPC resolver.

Configure outbound DNS resolution from the spoke VPCs to the on-premises network.

Created a central Route 53 Resolver outbound endpoint in the Shared Services VPC and an outbound rule for `onprem.retail.internal` pointing to the on-premises DNS servers. Shared this rule with the organization using AWS Resource Access Manager (RAM) and associated it with the spoke VPCs.

This centralizes the outbound DNS endpoint costs and administration while allowing workloads in the spoke VPCs to resolve on-premises hostnames.

Configure inbound DNS resolution from the on-premises network to AWS.

Created a central Route 53 Resolver inbound endpoint in the Shared Services VPC. Configured on-premises DNS servers to forward queries for `shared.retail.internal` to the inbound endpoint IP addresses.

This enables on-premises servers to resolve resources in the AWS private hosted zone via Transit Gateway routing to the inbound endpoint IPs.

Key Concept

Centralized hybrid DNS architecture using Route 53 Resolver endpoints, cross-account Private Hosted Zone association, and Resource Access Manager sharing of outbound rules.

Question 547Question →

An administrator is configuring single sign-on (SSO) integration between an on-premises SAML 2.0 Identity Provider (IdP) and an AWS account. The administrator creates an IAM role to represent the federated users. Which action must be specified in the trust policy of this IAM role to allow the SAML provider to authenticate users?

sts:AssumeRoleWithSAML

sts:AssumeRoleWithWebIdentity

sts:AssumeRole

sts:AssumeRole with a Service Control Policy (SCP) attached to the root of the organization that allows access to the SAML provider

Show answer & explanation

Answer: sts:AssumeRoleWithSAML

Answer

The trust policy of the IAM role must specify the action 'sts:AssumeRoleWithSAML' to allow the SAML 2.0 Identity Provider to federate users.

The correct action to configure in the trust policy for SAML 2.0 federation is 'sts:AssumeRoleWithSAML'. This allows AWS Security Token Service (STS) to validate the SAML assertion and return temporary security credentials.

Step-by-Step Solution

Identify the type of identity federation being configured.

The identity provider uses SAML 2.0.

SAML 2.0 federation uses a specific STS API action that differs from OIDC or basic cross-account trust.

Select the correct AWS Security Token Service (STS) action for the trust policy.

The action 'sts:AssumeRoleWithSAML' is chosen.

This is the only action that allows STS to exchange SAML assertions for temporary AWS security credentials.

Key Concept

SAML 2.0 federation trust policies require the specific STS action 'sts:AssumeRoleWithSAML' to authorize external SAML identity providers.

Alternative Method

If AWS IAM Identity Center is used, the configuration of IAM role trust policies is managed automatically by the service, eliminating the need to write custom trust policies manually.

Estimated Time:45s

Question 548Question →

A solutions architect is configuring a multi-account environment using AWS Organizations. The architect wants to prevent users in member accounts from stopping or deleting AWS CloudTrail. The architect attaches a Service Control Policy (SCP) to the organization's Root OU that explicitly denies the `cloudtrail:StopLogging` and `cloudtrail:DeleteTrail` actions. Which of the following is required for an IAM user in a member account to successfully create and manage a new CloudTrail trail in their own account?

The IAM user must be explicitly granted the permission by an IAM policy attached to their identity in the member account, and the action must not be denied by any Service Control Policy.

No local IAM policy is required in the member account because attaching the SCP to the Root OU automatically grants the necessary CloudTrail permissions to all users within the organization.

The IAM user must configure an S3 bucket policy in the management account that explicitly permits cross-account trail configuration.

The IAM user must encrypt the new trail using an AWS-managed KMS key to delegate organization-wide management permissions.

Show answer & explanation

Answer: The IAM user must be explicitly granted the permission by an IAM policy attached to their identity in the member account, and the action must not be denied by any Service Control Policy.

Answer

The IAM user must be explicitly granted the permission by an IAM policy attached to their identity in the member account, and the action must not be denied by any Service Control Policy.

The correct answer is that the user must be explicitly granted the permission by an IAM policy in the member account, and the action must not be denied by any Service Control Policy. SCPs act as guardrails that limit the maximum permissions available in an account but do not grant permissions directly. Therefore, local IAM policies are still required.

Step-by-Step Solution

Analyze the impact of the Service Control Policy (SCP) attached to the Root OU.

The SCP denies `cloudtrail:StopLogging` and `cloudtrail:DeleteTrail` across all member accounts, meaning these actions can never be performed, but it does not grant permissions for any other action.

SCPs act as filters (guardrails) defining the maximum allowed permissions but do not grant access directly.

Determine how permissions are granted in a member account under AWS Organizations.

An IAM identity (user or role) in the member account must have an attached IAM policy that explicitly allows the required action (e.g., `cloudtrail:CreateTrail`).

Both the local IAM policy and the SCP must allow the action for the request to succeed.

Key Concept

Interaction between Service Control Policies (SCPs) and IAM Policies

Question 549Question →

A global financial technology enterprise manages a large multi-account environment using AWS Organizations. The company has a strict governance policy for its Compliance_OU, which houses accounts processing payment transactions, and its Developer_OU, which hosts sandbox environments. The Solutions Architect must enforce the following security requirements:
1. No user or role within the member accounts may delete or disable corporate AWS Config rules.
2. Developers in the Developer_OU must be allowed to create IAM roles and policies for testing, but they must be prevented from accessing any resources tagged with Confidentiality: High.
3. Accounts in the Compliance_OU must only be permitted to run services in the us-east-1 and us-west-2 regions, and must be restricted to using Amazon EC2, Amazon RDS, and Amazon DynamoDB.

Which combination of Service Control Policies (SCPs) and IAM configurations must the Solutions Architect implement to meet these requirements with the least administrative overhead?

Apply an SCP at the root level that denies deleting or disabling AWS Config rules. Apply an SCP to the Developer_OU that denies all actions on resources with the tag Confidentiality: High. Apply an SCP to the Compliance_OU that allows all actions for Amazon EC2, Amazon RDS, and Amazon DynamoDB, while restricting access to us-east-1 and us-west-2. Instruct local administrators that developers in the Compliance_OU accounts do not require local IAM policies, as this SCP automatically grants them access to these three services.

Apply an SCP at the root level to deny AWS Config rule modifications. In the Developer_OU accounts, configure IAM policies on every individual IAM user and role to deny access to resources tagged with Confidentiality: High. For the Compliance_OU accounts, use AWS Resource Access Manager (RAM) to share a pre-configured IAM role from the management account to all member accounts, allowing access only to EC2, RDS, and DynamoDB in us-east-1 and us-west-2.

Apply a Service Control Policy (SCP) at the root level of the organization that denies config:DeleteConfigRule, config:DeleteConfigurationRecorder, and config:StopConfigurationRecorder. Apply an SCP to the Developer_OU that denies all actions on resources with the tag Confidentiality: High. Apply an SCP to the Compliance_OU that denies access to all AWS services except Amazon EC2, Amazon RDS, and Amazon DynamoDB (plus supporting services like IAM, KMS, and CloudWatch) and denies all actions outside us-east-1 and us-west-2 except for global services. Require local administrators to configure local IAM policies to grant users and roles permissions to access the approved services.

Apply an SCP at the root level to deny AWS Config rule modifications. Attach an IAM policy to the Organization Root that denies access to resources with the tag Confidentiality: High. For the Compliance_OU accounts, restrict service access by configuring an AWS-managed KMS key (aws/s3) policy in the logging account to deny encrypt and decrypt actions for all services other than EC2, RDS, and DynamoDB, and apply this KMS key across all Compliance_OU accounts.

Show answer & explanation

Answer: Apply a Service Control Policy (SCP) at the root level of the organization that denies config:DeleteConfigRule, config:DeleteConfigurationRecorder, and config:StopConfigurationRecorder. Apply an SCP to the Developer_OU that denies all actions on resources with the tag Confidentiality: High. Apply an SCP to the Compliance_OU that denies access to all AWS services except Amazon EC2, Amazon RDS, and Amazon DynamoDB (plus supporting services like IAM, KMS, and CloudWatch) and denies all actions outside us-east-1 and us-west-2 except for global services. Require local administrators to configure local IAM policies to grant users and roles permissions to access the approved services.

Answer

The correct answer is the solution that applies a Service Control Policy (SCP) at the root level to deny AWS Config modifications, applies an SCP to the Developer_OU using resource tags, applies an SCP to the Compliance_OU utilizing an allowlist pattern for specific services and regions, and requires local administrators to configure local IAM policies to grant actual permissions.

The correct option establishes organizational guardrails using Service Control Policies (SCPs) at the appropriate hierarchy levels (Root, Developer_OU, and Compliance_OU) while correctly recognizing that SCPs do not grant permissions directly. Local administrators must still create IAM policies to grant permissions to users and roles, adhering to the shared administration model in AWS Organizations.

Step-by-Step Solution

Analyze the AWS Config rule protection requirement.

Since AWS Config rules must be protected across all member accounts, a Service Control Policy (SCP) attached at the Organization Root is the most operationally efficient way to enforce this globally.

SCPs apply to all member accounts beneath the node where they are attached.

Evaluate how to prevent access to resources tagged as Confidentiality: High in the Developer_OU.

Apply an SCP to the Developer_OU that denies all actions on resources when the condition evaluates the tag Confidentiality: High.

This allows developers to create roles/policies locally but prevents those roles from accessing protected resources, overriding any local administrator permissions.

Evaluate the Compliance_OU restrictions on regions and services.

Apply an SCP to the Compliance_OU that denies any action if the region is not us-east-1 or us-west-2 (with global service exceptions), and denies actions for services other than EC2, RDS, DynamoDB, IAM, KMS, and CloudWatch.

This acts as a strict guardrail for both region and service usage.

Determine the relationship between SCPs and IAM policies.

Ensure local administrators configure local IAM policies to grant developers access to the approved services.

SCPs are authorization boundaries and do not grant permissions; access is only allowed when both the SCP and the local IAM policy permit it.

Key Concept

Understanding SCP inheritance, tag-based resource restriction, and integration with local IAM policies within AWS Organizations.

Question 550Question →

A logistics company is implementing a centralized identity strategy for its AWS multi-account environment. The company hosts its user directory in a third-party SAML $2.0$ Identity Provider (IdP). To streamline administrative overhead, they want to establish direct console federation to target AWS member accounts. An administrator configures the SAML metadata in the member accounts and defines an IAM role named `LogisticsOperatorRole` for the users. However, when operators attempt to log in through the IdP portal, they are blocked with an authentication error. An analysis of the trust relationships reveals that the authentication handshake is failing at the Security Token Service (STS) endpoint. Which configuration must the administrator apply to the `LogisticsOperatorRole` trust policy to resolve this issue?

Set the trust policy's `Principal` to the ARN of the SAML provider created in the member account, set the `Action` to `sts:AssumeRole`, and add a `Condition` block that evaluates the `SAML:iss` context key to match the IdP entity ID.

Set the trust policy's `Principal` to the ARN of the SAML provider created in the member account, set the `Action` to `sts:AssumeRoleWithSAML`, and add a `Condition` block that evaluates `SAML:aud` to match `https://signin.aws.amazon.com/saml`.

Attach a Service Control Policy (SCP) to the member accounts' Organizational Unit that authorizes `sts:AssumeRoleWithSAML` for the external IdP's domain, which dynamically creates the temporary credentials without requiring an IAM role trust policy.

Set the trust policy's `Principal` to reference the IdP's metadata endpoint URL directly, set the `Action` to `sts:AssumeRoleWithWebIdentity`, and configure the policy to use the default AWS-managed KMS key (`aws/kms`) for decrypting the assertion token.

Show answer & explanation

Answer: Set the trust policy's `Principal` to the ARN of the SAML provider created in the member account, set the `Action` to `sts:AssumeRoleWithSAML`, and add a `Condition` block that evaluates `SAML:aud` to match `https://signin.aws.amazon.com/saml`.

Answer

Configure the trust policy of the target IAM role to specify the SAML provider ARN as the principal, use the `sts:AssumeRoleWithSAML` action, and ensure the condition evaluates the SAML audience parameter against the standard AWS sign-in URL.

The correct configuration establishes a SAML federation model. The trust policy must trust the SAML provider ARN created in the member account, authorize the `sts:AssumeRoleWithSAML` action to allow authentication without pre-existing AWS credentials, and enforce a security condition where the SAML audience claim (`SAML:aud`) matches the AWS console sign-in URL.

Step-by-Step Solution

Identify the authentication protocol and API endpoint mismatch.

The company uses SAML

2.0

, which requires the target IAM role trust policy to use the specialized API action `sts:AssumeRoleWithSAML` instead of standard `sts:AssumeRole` or `sts:AssumeRoleWithWebIdentity`.

Standard role assumption does not accept SAML assertions, and web identity federation is intended for OIDC providers.

Establish the trust relationship using the SAML provider metadata object.

The principal of the IAM trust policy must point to the SAML provider resource ARN that represents the IdP inside the AWS account.

This establishes trust between AWS IAM and the external Identity Provider metadata document.

Add the audience validation condition key.

Add a condition verifying that `SAML:aud` matches `https://signin.aws.amazon.com/saml`.

This guarantees that the token was explicitly issued for the AWS console login endpoint, preventing credential misuse.

Key Concept

SAML 2.0 Identity Federation Trust Policies

Estimated Time:2m 30s

Question 551Question →

A company uses AWS Organizations to manage a multi-account environment. The Network team has created a central VPC in a dedicated Network account. They need to share several private subnets from this VPC with application teams in other member accounts of the organization. The application teams deploy workloads consisting of Amazon EC2 instances, Amazon ECS tasks running on AWS Fargate, and AWS Lambda functions. All workloads must encrypt their data at rest, and the encryption keys must be managed centrally in a Security account. Additionally, the company wants to optimize compute costs across all accounts, including the serverless runtimes. Which of the following architectural strategies should the Solutions Architect implement to meet these requirements?

Enable sharing with AWS Organizations in AWS RAM. In the Network account, create a resource share for the subnets and associate it with the Organization. In the Security account, create KMS Customer Managed Keys and configure key policies that grant cross-account access to the application roles. In the organization's management account, purchase Compute Savings Plans.

Enable sharing with AWS Organizations in AWS RAM. In the Network account, create a resource share for the subnets and associate it with the Organization. In the Security account, use AWS-managed KMS keys (such as aws/ebs and aws/s3) and modify their key policies to grant cross-account access to the application roles. In the organization's management account, purchase Compute Savings Plans.

In the Network account, create a resource share in AWS RAM for the subnets and target the account IDs of external partner accounts, without enabling the setting to allow sharing with external entities in the AWS RAM console. In the Security account, create KMS Customer Managed Keys and configure key policies that grant cross-account access. In the organization's management account, purchase Compute Savings Plans.

Show answer & explanation

Answer: Enable sharing with AWS Organizations in AWS RAM. In the Network account, create a resource share for the subnets and associate it with the Organization. In the Security account, create KMS Customer Managed Keys and configure key policies that grant cross-account access to the application roles. In the organization's management account, purchase Compute Savings Plans.

Answer

The architectural strategy that enables sharing with AWS Organizations in AWS RAM, utilizes KMS Customer Managed Keys for cross-account encryption, and purchases Compute Savings Plans to cover EC2, Fargate, and Lambda workloads.

The correct strategy enables AWS Organizations sharing in AWS RAM to distribute subnets seamlessly, uses Customer Managed Keys since AWS-managed KMS keys cannot be shared or modified for cross-account access, and purchases Compute Savings Plans to cover both EC2 and serverless (Fargate and Lambda) compute usage.

Step-by-Step Solution

Configure AWS Resource Access Manager (RAM) in the Network account to share subnets with the AWS Organization.

The subnets are shared securely without requiring individual invitations to be accepted.

AWS RAM allows central sharing of network resources to avoid IP space fragmentation and simplify multi-account network design.

Create and configure a Customer Managed Key (CMK) in the Security account with a key policy allowing access from application account roles.

Workloads can perform encryption and decryption operations using a central key.

AWS-managed KMS keys cannot have their key policies modified and cannot be shared across different AWS accounts.

Purchase Compute Savings Plans in the organization's management account.

Compute discounts apply automatically to EC2, AWS Fargate, and AWS Lambda workloads across all member accounts.

EC2 Instance Savings Plans do not cover serverless compute types like Fargate and Lambda, whereas Compute Savings Plans do.

Key Concept

Cross-account resource sharing, centralized encryption key management, and cost optimization via Compute Savings Plans within AWS Organizations.

Question 552Question →

A company implements a multi-account strategy using AWS Organizations. The IT security team wants to configure federation with an external SAML 2.0 Identity Provider (IdP) to allow users to authenticate and directly access resources in a shared services account and multiple production accounts. The solutions architect needs to create an IAM role in each AWS account that will be assumed by the federated users. Which configuration must the solutions architect apply to the trust relationship of the IAM roles to establish trust with the SAML IdP and ensure that only authenticated federated users from the company's IdP can assume these roles?

Create a SAML identity provider in the organization's management account. Configure the trust policy of the target IAM roles in each member account by setting the Principal to the management account's SAML provider and the Action to sts:AssumeRoleWithWebIdentity.

Attach a Service Control Policy (SCP) to the organization's root that allows access from the corporate SAML provider's identity URL, and configure the member account IAM roles to inherit this federated access without defining local trust policies.

Create a SAML identity provider in each AWS account's IAM. Configure the trust policy of the target IAM roles in each account by setting the Principal to the ARN of the local SAML identity provider and the Action to sts:AssumeRoleWithSAML.

Create a SAML identity provider in each AWS account's IAM. Configure the trust policy of the target IAM roles in each account by setting the Principal to the corporate Identity Provider's external metadata endpoint and the Action to sts:AssumeRole.

Show answer & explanation

Answer: Create a SAML identity provider in each AWS account's IAM. Configure the trust policy of the target IAM roles in each account by setting the Principal to the ARN of the local SAML identity provider and the Action to sts:AssumeRoleWithSAML.

Answer

The correct configuration requires creating a SAML 2.0 identity provider object in each target AWS account where the federated roles reside. The trust policy of these roles must reference the ARN of the local SAML provider object as the federated Principal and specify the sts:AssumeRoleWithSAML action to allow authentication from the external identity provider.

Step-by-Step Solution

Create a SAML 2.0 identity provider (IdP) object in the IAM console of each AWS account where the federated users need access, uploading the XML metadata document provided by the corporate IdP.

A SAML provider resource is created in each account with a unique ARN (e.g., arn:aws:iam::<AccountID>:saml-provider/<ProviderName>).

AWS IAM requires a local representation of the external identity provider to establish trust and evaluate assertions.

Create or configure the IAM roles that the federated users will assume, specifying the local SAML provider's ARN as the federated principal in the trust policy.

The role's trust relationship is established with the local SAML provider resource.

This allows AWS STS to trust assertions signed by the configured external identity provider when attempting to assume this specific role.

Set the Action in the trust policy's statement to sts:AssumeRoleWithSAML and configure appropriate conditions such as mapping the SAML:aud attribute.

The role trust policy is complete and validates SAML assertion exchanges.

The sts:AssumeRoleWithSAML action is the specific AWS Security Token Service (STS) API call required to exchange SAML assertions for temporary AWS credentials.

Key Concept

Multi-Account SAML 2.0 Federation configuration using AWS IAM and AWS STS

Estimated Time:2m 0s

Question 553Question →

A retail company has three AWS accounts, each with a single VPC in the us-east-1 Region. The company wants to establish hybrid connectivity between all three VPCs and its on-premises data center using a single AWS Direct Connect connection. The architecture must allow the VPCs to communicate with the on-premises network and with each other. Which architecture achieves this with the least administrative effort?

Create an AWS Direct Connect Gateway, attach a Virtual Private Gateway to each VPC, and associate the Direct Connect Gateway with all three Virtual Private Gateways to enable routing between the VPCs and the on-premises environment.

Create a full mesh of VPC peering connections between all three VPCs to enable inter-VPC traffic. Create a Direct Connect Gateway, attach a Virtual Private Gateway to each VPC, and connect it using a private virtual interface (private VIF).

Create an AWS Transit Gateway, attach the three VPCs, associate the Transit Gateway with an AWS Direct Connect Gateway, and connect the Direct Connect Gateway to the on-premises environment using a transit virtual interface (transit VIF).

Deploy a single NAT Gateway in one of the VPCs, establish a VPN connection from that NAT Gateway to the on-premises data center, and route all traffic from the other two VPCs through the NAT Gateway.

Show answer & explanation

Answer: Create an AWS Transit Gateway, attach the three VPCs, associate the Transit Gateway with an AWS Direct Connect Gateway, and connect the Direct Connect Gateway to the on-premises environment using a transit virtual interface (transit VIF).

Answer

AWS Transit Gateway functions as a centralized cloud router that simplifies network topologies. By attaching the three VPCs to a Transit Gateway, inter-VPC traffic is enabled natively. Connecting the Transit Gateway to an AWS Direct Connect Gateway using a transit virtual interface (transit VIF) allows all attached VPCs to access the on-premises data center over a single Direct Connect connection, minimizing both administrative overhead and configuration complexity.

Step-by-Step Solution

Evaluate the requirement for VPC-to-VPC and VPC-to-on-premises transitive routing.

Identify that AWS Transit Gateway is the appropriate service to enable transitive routing across multiple VPCs and a hybrid connection.

Direct Connect Gateway alone does not support routing traffic between attached virtual private gateways (VPCs).

Determine the connection type required between AWS Transit Gateway and AWS Direct Connect Gateway.

Select a transit virtual interface (transit VIF) for the Direct Connect connection.

A transit VIF is required to carry traffic between a Direct Connect Gateway and an AWS Transit Gateway.

Key Concept

Hybrid network design using AWS Transit Gateway and AWS Direct Connect Gateway for transitive multi-VPC routing.

Estimated Time:1m 0s

Question 554Question →

A company is designing a network architecture to connect $12$ spoke VPCs spread across $3$ AWS accounts in a single AWS Region. The architecture must support low-latency, any-to-any communication between the VPCs and provide a highly available, dedicated connection to their on-premises data center. The solutions architect must minimize administrative overhead and ensure that routing scales easily as new spoke VPCs are added. Which of the following architectures meets these requirements?

Deploy a centralized AWS Direct Connect Gateway and associate it directly with the virtual private gateways of all

12

spoke VPCs using private virtual interfaces, relying on the Direct Connect Gateway to route traffic between the spoke VPCs and the on-premises data center.

Establish a full mesh of VPC peering connections between all

12

spoke VPCs to handle inter-VPC communication. Connect the on-premises data center to a central hub VPC using a Direct Connect Gateway and a transit virtual interface, and configure a Route

53

Private Hosted Zone in the hub VPC without associating it with the spoke VPCs.

Provision an AWS Transit Gateway in a centralized network account, share it with the other accounts using AWS Resource Access Manager (RAM), and attach the spoke VPCs. Associate the Transit Gateway with an AWS Direct Connect Gateway connected to the on-premises data center via a transit virtual interface.

Create a hub-and-spoke topology by sharing a Transit Gateway across accounts. Connect the Transit Gateway to the on-premises data center using a Site-to-Site VPN. Route all outbound internet and hybrid traffic through a single NAT Gateway located in a central egress VPC's single Availability Zone to minimize NAT charges.

Show answer & explanation

Answer: Provision an AWS Transit Gateway in a centralized network account, share it with the other accounts using AWS Resource Access Manager (RAM), and attach the spoke VPCs. Associate the Transit Gateway with an AWS Direct Connect Gateway connected to the on-premises data center via a transit virtual interface.

Answer

The correct architecture leverages AWS Transit Gateway to act as a cloud router, providing any-to-any connectivity among the

12

spoke VPCs. Sharing the Transit Gateway via AWS Resource Access Manager (RAM) allows the spoke VPCs in different accounts to attach to the same gateway seamlessly. To connect to the on-premises data center, a Direct Connect Gateway is associated with the Transit Gateway using a transit virtual interface (Transit VIF), which supports routing to multiple VPCs via the Transit Gateway over a dedicated, low-latency connection.

Step-by-Step Solution

Evaluate the requirement for any-to-any spoke VPC communication.

Identify that a hub-and-spoke routing mechanism is required. AWS Transit Gateway is the standard service for interconnecting multiple VPCs transitively, whereas Direct Connect Gateway or VPC Peering do not scale well or support transitive inter-VPC routing natively.

Transit Gateway simplifies the network topology and eliminates the need to manage a complex full mesh of VPC peering connections.

Determine the resource sharing mechanism for the multi-account setup.

Use AWS Resource Access Manager (RAM) to share the central Transit Gateway with the other

2

AWS accounts.

This allows spoke VPCs in different accounts to be attached to the same Transit Gateway, maintaining centralized network management while separating account boundaries.

Select the correct hybrid connectivity configuration for high-performance dedicated access.

Associate the Transit Gateway with an AWS Direct Connect Gateway connected via a transit virtual interface (Transit VIF).

Transit VIF is the only virtual interface type that supports Transit Gateway, enabling traffic from all attached spoke VPCs to flow to the on-premises data center via the Direct Connect Gateway.

Key Concept

Hub-and-Spoke hybrid network design using Transit Gateway, RAM, and Direct Connect Gateway with a Transit VIF to achieve scale, transitive routing, and high availability.

Estimated Time:2m 0s

Question 555Question →

A company has multiple AWS accounts in an AWS Organization. A Solutions Architect needs to design a hybrid network architecture that connects all VPCs to the company's on-premises data center using an existing AWS Direct Connect connection. The architecture must minimize administrative overhead and support transitive routing between all VPCs and the on-premises network. Which two configuration steps should the Solutions Architect perform to meet these requirements? (Select TWO.)

Select all that apply

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

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

Create a private virtual interface (Private VIF) on the Direct Connect connection, associate it with a Direct Connect Gateway, and attach the Direct Connect Gateway directly to Virtual Private Gateways in each spoke VPC.

Associate a Route 53 Private Hosted Zone containing on-premises DNS records directly with the Direct Connect Gateway.

Deploy a single NAT Gateway in a shared services VPC and configure all spoke VPC route tables to route on-premises traffic through VPC Peering connections to this NAT Gateway.

Show answer & explanation

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

Answer

Create an AWS Transit Gateway, share it with the spoke accounts using AWS Resource Access Manager (RAM), attach the spoke VPCs to the Transit Gateway, and create a transit virtual interface (Transit VIF) on the Direct Connect connection associated with a Direct Connect Gateway attached to the Transit Gateway.

To achieve scalable hybrid connectivity with transitive routing (VPC-to-VPC and VPC-to-on-premises) and minimal administrative overhead, a hub-and-spoke transit network is required. This is implemented by creating an AWS Transit Gateway and sharing it across the organization using AWS Resource Access Manager (RAM) so that spoke VPCs can attach to it. To connect this setup to an on-premises network via Direct Connect, a transit virtual interface (Transit VIF) is configured on the Direct Connect connection, associated with a Direct Connect Gateway, and attached to the Transit Gateway.

Step-by-Step Solution

Configure AWS Transit Gateway and sharing.

Create a central Transit Gateway and share it with member accounts using AWS Resource Access Manager (RAM), allowing them to attach their VPCs.

This establishes the hub-and-spoke topology required for multi-account scalability and transitive routing.

Configure Direct Connect hybrid connectivity.

Set up a Transit VIF on the Direct Connect connection, associate it with a Direct Connect Gateway, and attach the Direct Connect Gateway to the Transit Gateway.

This connects the on-premises network to the Transit Gateway, enabling transitive routing to all attached VPCs.

Key Concept

AWS Transit Gateway simplifies network topology by acting as a cloud router, enabling transitive routing between spoke VPCs and on-premises networks via a Direct Connect Gateway and a Transit VIF.

Question 556Question →

A multinational enterprise is building a multi-account landing zone using AWS Organizations. The solutions architect must establish a governance framework that enforces security guardrails while maintaining operational delegation. The requirements are as follows:
- Centralized security services, such as Amazon GuardDuty, must be managed by a designated Security team account, avoiding any administrative actions in the Organization's management account.
- Service Control Policies (SCPs) must restrict member accounts in the 'Workloads' Organizational Unit (OU) from deploying resources in unauthorized AWS Regions, while ensuring that the SCPs do not inadvertently grant permissions to local IAM identities.

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

Select all that apply

Designate the Security account as the delegated administrator for Amazon GuardDuty from the AWS Organizations management account.

Attach a Service Control Policy (SCP) to the Workloads OU that uses a Deny effect for all actions with a condition restricting operations to the approved Regions, excluding global services, and configure local IAM policies within member accounts to grant developer permissions.

Attach an SCP to the Workloads OU that explicitly allows deployment permissions only within the approved Regions, thereby granting those permissions directly to all IAM entities in the member accounts.

Establish cross-account federated roles by configuring a SAML trust policy in the Security account with the sts:AssumeRole action, rather than using AWS Organizations delegated administration.

Enable resource sharing outside the organization via AWS Resource Access Manager (RAM) in the management account to share GuardDuty configuration data with the Security account.

Show answer & explanation

Answer: Designate the Security account as the delegated administrator for Amazon GuardDuty from the AWS Organizations management account.; Attach a Service Control Policy (SCP) to the Workloads OU that uses a Deny effect for all actions with a condition restricting operations to the approved Regions, excluding global services, and configure local IAM policies within member accounts to grant developer permissions.

Answer

The solutions architect should designate the Security account as the delegated administrator for Amazon GuardDuty and attach a Deny-based SCP to the Workloads OU to restrict regions, while continuing to configure local IAM policies to grant permissions.

Delegated administration allows organizations to decouple service management from the management account. Using a Deny-based SCP to restrict regions ensures that unauthorized operations are blocked at the boundary, while local IAM policies actually grant permissions to users.

Step-by-Step Solution

Enable delegated administration for security services.

The designated Security account has the authority to manage GuardDuty detectors and member account associations across the Organization.

This avoids performing operational tasks in the Organization's management account, aligning with AWS best practices for multi-account management.

Implement a Deny-based SCP for Region restrictions.

API calls to deploy resources in unauthorized regions are blocked at the OU boundary, while allowed global services continue to function.

SCPs act as filters rather than direct permission providers. A Deny policy ensures that even if local IAM policies permit global deployments, unauthorized regions are blocked.

Define local IAM policies within the member accounts.

Developer roles are granted access to specific resources and services locally within the boundaries permitted by the SCP.

Because SCPs do not grant permissions, local IAM policies must still be present to allow actions to succeed.

Key Concept

Delegating administration for organizational services and using SCPs as permission boundaries (filters) rather than direct permission grants.

Question 557Question →

An enterprise manages a multi-account environment under AWS Organizations. The environment consists of a Management account, a Security Logging account, a Shared Network account, and several Core Application accounts grouped under a Production OU, as well as Non-Production accounts under a Non-Production OU. The architecture team must implement a solution that satisfies the following requirements:

1. Network Sharing: The Shared Network account must host a central VPC. Subnets from this VPC must be shared with the Core Application accounts using AWS Resource Access Manager (RAM). The application teams must be able to deploy Amazon EC2 instances and AWS Fargate tasks into these subnets, but they must be prevented from modifying any subnet configurations or sharing resources themselves.
2. Centralized Auditing: AWS CloudTrail must be configured organization-wide to deliver logs to a single Amazon S3 bucket in the Security Logging account. The logs must be encrypted at rest using an encryption key that satisfies compliance standards requiring key rotation and granular cross-account access control.
3. Cost Optimization: The company has purchased Compute Savings Plans in the Management account. To maximize cost efficiency, these savings must only apply to workloads running in the Management account and the Production OU (Core Application accounts). Under no circumstances should the savings apply to the Non-Production OU accounts.
4. Data Protection: The S3 bucket policy in the Security Logging account must enforce that only CloudTrail can write logs, and only from within the AWS Organization.

Which of the following strategies must a Solutions Architect implement to meet these requirements?

Implement the following configuration:
1. In the Shared Network account, create the VPC and subnets. Use AWS RAM to create a resource share containing the subnets, associate it with the Production OU, and ensure organization sharing is enabled in the AWS RAM settings. Attach a Service Control Policy (SCP) to the Production OU that denies 'ec2:DeleteSubnet', 'ec2:ModifySubnetAttribute', and 'ram:CreateResourceShare' to prevent unauthorized modifications or resource sharing.
2. In the Security Logging account, create an Amazon S3 bucket and a customer managed KMS key (CMK). Configure the S3 bucket policy to allow 's3:PutObject' from the CloudTrail service principal with a condition checking that the 'aws:PrincipalOrgID' matches the Organization ID. Configure the KMS key policy to allow 'kms:GenerateDataKey*' and 'kms:Decrypt' to the CloudTrail service principal with the same organization condition. Create an organization trail in the Management account that logs to this central bucket using the CMK.
3. In the Billing Preferences of the Management account, disable Savings Plans discount sharing for all member accounts in the Non-Production OU, while keeping discount sharing enabled for the Management account and the accounts in the Production OU.

Implement the following configuration:
1. In the Shared Network account, create the VPC and subnets. Use AWS RAM to create a resource share for the subnets and associate it with the Production OU. Attach an SCP to the Production OU that uses an Allow effect for the 'ram:AssociateResourceShare' and 'ec2:RunInstances' actions to grant the application teams the required permissions.
2. Configure an organization-wide CloudTrail trail in the Management account to deliver logs to an S3 bucket in the Security Logging account. Enable default S3 bucket encryption using the AWS managed KMS key (aws/s3) to simplify cross-account KMS key access and avoid custom key policy management.
3. Purchase EC2 Instance Savings Plans in the Management account. In the Management account's Billing Preferences, disable Savings Plans discount sharing globally, and purchase Compute Savings Plans directly in the Non-Production OU accounts, expecting the EC2 Instance Savings Plans to still apply to Fargate tasks in the Production OU.

Implement the following configuration:
1. In the Shared Network account, create the VPC and subnets. Use AWS RAM to share the subnets with the Production OU. Attach an SCP to the Production OU that denies 'ec2:DeleteSubnet' and 'ec2:ModifySubnetAttribute'.
2. In the Security Logging account, create an S3 bucket and a customer managed KMS key (CMK). Configure the S3 bucket policy to grant write access only to the Management account's root user principal, expecting the Management account to transitively authorize CloudTrail to deliver logs from all member accounts. Configure the organization-wide CloudTrail trail to log to this bucket using the CMK.
3. Purchase EC2 Instance Savings Plans in the Management account. In the Billing Preferences of the Management account, disable Savings Plans discount sharing for the Non-Production OU accounts, expecting the EC2 Instance Savings Plans to automatically apply to the EC2 and Fargate workloads in the Production OU.

Implement the following configuration:
1. In the Shared Network account, create the VPC and subnets. Use AWS RAM to create a resource share for the subnets, and attempt to share them with external partner accounts by specifying their AWS Account IDs, without enabling the sharing with external entities setting in the AWS RAM console settings.
2. In the Security Logging account, create an S3 bucket and a customer managed KMS key (CMK). Configure the S3 bucket policy to authorize the IAM roles of all individual application accounts to write directly to the bucket path. Configure each application account to run its own local CloudTrail trail that delivers logs to this S3 bucket using the CMK.
3. Disable consolidated billing in AWS Organizations. Purchase Compute Savings Plans in the Management account and configure cross-account IAM roles to allow production application accounts to consume the compute discounts.

Show answer & explanation

Answer: Implement the following configuration:
1. In the Shared Network account, create the VPC and subnets. Use AWS RAM to create a resource share containing the subnets, associate it with the Production OU, and ensure organization sharing is enabled in the AWS RAM settings. Attach a Service Control Policy (SCP) to the Production OU that denies 'ec2:DeleteSubnet', 'ec2:ModifySubnetAttribute', and 'ram:CreateResourceShare' to prevent unauthorized modifications or resource sharing.
2. In the Security Logging account, create an Amazon S3 bucket and a customer managed KMS key (CMK). Configure the S3 bucket policy to allow 's3:PutObject' from the CloudTrail service principal with a condition checking that the 'aws:PrincipalOrgID' matches the Organization ID. Configure the KMS key policy to allow 'kms:GenerateDataKey*' and 'kms:Decrypt' to the CloudTrail service principal with the same organization condition. Create an organization trail in the Management account that logs to this central bucket using the CMK.
3. In the Billing Preferences of the Management account, disable Savings Plans discount sharing for all member accounts in the Non-Production OU, while keeping discount sharing enabled for the Management account and the accounts in the Production OU.

Answer

The correct strategy is to create a resource share in AWS RAM within the Shared Network account, share the subnets with the Production OU, and use an SCP to deny modification/sharing actions. For auditing, a customer managed KMS key and an S3 bucket in the Security Logging account must be configured with policies that allow the CloudTrail service principal based on the Organization ID condition. For billing, the Management account's Billing Preferences should be modified to disable discount sharing for the Non-Production OU while keeping it enabled for the Production OU.

The correct strategy utilizes AWS RAM to share subnets with the Production OU, and secures the configuration by applying an SCP that restricts modification and creation of resource shares. To support centralized logging, it configures a Customer Managed Key (CMK) with a key policy allowing the CloudTrail service principal, which is required because AWS-managed keys cannot be shared cross-account. Lastly, it restricts Savings Plans discount application by turning off discount sharing specifically for the Non-Production OU accounts within the Billing Preferences of the Management account.

Step-by-Step Solution

Set up subnet sharing in the Shared Network account using AWS Resource Access Manager (RAM).

A resource share is created with the subnets and associated with the Production OU, enabling Fargate and EC2 deployments.

This allows the application teams to use the subnets without having administrative privileges over the VPC and network configurations.

Attach a Service Control Policy (SCP) to the Production OU to enforce security boundaries.

The policy denies network modifications (ec2:DeleteSubnet, ec2:ModifySubnetAttribute) and unauthorized RAM sharing (ram:CreateResourceShare).

This prevents application teams from altering the central network setup or sharing their own resources.

Configure the central S3 bucket and customer managed KMS key (CMK) in the Security Logging account.

An S3 bucket policy and KMS key policy are configured to trust the 'cloudtrail.amazonaws.com' service principal with a condition matching the 'aws:PrincipalOrgID'.

CloudTrail requires a Customer Managed Key to encrypt cross-account logs since AWS managed keys (aws/s3 or aws/cloudtrail) do not support the cross-account policy delegation needed for organization-wide logging.

Configure the Billing Preferences in the Management account to control Savings Plans discount application.

Savings Plans discount sharing is turned off for the Non-Production OU accounts while remaining active for the Production OU and Management account.

By default, Savings Plans discounts apply to the purchasing account first and then propagate. Disabling sharing for specific OUs ensures that only production workloads consume the compute discounts.

Key Concept

Multi-account resource sharing via AWS RAM, centralized organization-level CloudTrail encryption using customer managed KMS keys, and granular Savings Plans discount sharing controls in AWS Billing.

Estimated Time:3m 0s

Question 558Question →

A financial enterprise is designing a multi-account hybrid network to connect its on-premises data center to $20$ spoke VPCs distributed equally across the `us-east-1` and `us-west-2` Regions. The design must satisfy the following requirements:
- Hybrid Connectivity: Primary high-bandwidth path via a $10\text{ Gbps}$ AWS Direct Connect (DX) connection terminating near `us-east-1`. Backup connectivity using an AWS Site-to-Site VPN over the internet. Traffic must automatically fail over to the VPN if the DX connection fails.
- Routing: Inter-VPC communication across both regions must use the AWS private backbone. On-premises must access VPCs in both regions, preferring the DX path.
- Centralized Egress: All internet-bound traffic from all spoke VPCs must route through a centralized Security VPC in `us-east-1`. The egress path must be highly available and resilient to Availability Zone (AZ) failures.
- DNS Resolution: A single Route 53 Private Hosted Zone (PHZ) in a Shared Services account must be resolvable by all AWS resources in all VPCs and by on-premises clients.

Which architecture meets these requirements while ensuring correct routing, high availability, and DNS resolution?

Deploy an AWS Transit Gateway in `us-east-1` (TGW-East) and `us-west-2` (TGW-West), and peer them. Create a Direct Connect Gateway (DXGW) associated only with TGW-East, terminating a Transit VIF from the DX connection. Deploy a Site-to-Site VPN from on-premises only to TGW-East. Configure TGW-East to route `us-west-2` hybrid traffic over the TGW peering connection. In `us-east-1`, deploy a Security VPC with a NAT Gateway in each of the three active AZs, routing outbound traffic through TGW-East. Associate the Route 53 PHZ with all spoke VPCs in both regions, deploy Route 53 Inbound Resolvers in the Security VPC, and point on-premises DNS forwarders to these endpoints.

Deploy an AWS Transit Gateway in `us-east-1` (TGW-East) and `us-west-2` (TGW-West), and peer them. Create a Direct Connect Gateway (DXGW) associated with both TGWs, terminating a Transit VIF from the DX connection. Configure Site-to-Site VPNs from on-premises to both TGWs. In `us-east-1`, deploy a Security VPC with a NAT Gateway in each of the three active AZs, routing outbound traffic through TGW-East. Associate the Route 53 PHZ only with the Shared Services VPC. Rely on Transit Gateway routing to forward DNS queries from all other VPCs to the Shared Services VPC. Deploy Route 53 Inbound Resolvers in the Security VPC, and point on-premises DNS forwarders to these endpoints.

0.0.0.0/0

traffic to the Security VPC, where subnet route tables route traffic to the local NAT Gateway in the same AZ. Configure TGW-West to route

0.0.0.0/0

traffic via the peering connection to TGW-East. Associate the Route 53 PHZ with all spoke and transit VPCs in both regions, deploy Route 53 Inbound Resolvers in the Security VPC, and point on-premises DNS forwarders to these endpoints.

Deploy an AWS Transit Gateway in `us-east-1` (TGW-East) and `us-west-2` (TGW-West), and peer them. Create a Direct Connect Gateway (DXGW) associated with both TGWs, terminating a Transit VIF from the DX connection. Configure Site-to-Site VPNs from on-premises to both TGWs. In `us-east-1`, deploy a Security VPC with TGW attachments, private subnets, and public subnets containing a single NAT Gateway in one AZ to minimize NAT Gateway hourly charges. Configure TGW-East to route all

0.0.0.0/0

traffic to the Security VPC, where subnet route tables in all AZs point to this single NAT Gateway. Configure TGW-West to route

0.0.0.0/0

Show answer & explanation

Answer: Deploy an AWS Transit Gateway in `us-east-1` (TGW-East) and `us-west-2` (TGW-West), and peer them. Create a Direct Connect Gateway (DXGW) associated with both TGWs, terminating a Transit VIF from the DX connection. Configure Site-to-Site VPNs from on-premises to both TGWs. In `us-east-1`, deploy a Security VPC with TGW attachments, private subnets, and public subnets containing a NAT Gateway in each of the three active AZs. Configure TGW-East to route all $0.0.0.0/0$ traffic to the Security VPC, where subnet route tables route traffic to the local NAT Gateway in the same AZ. Configure TGW-West to route $0.0.0.0/0$ traffic via the peering connection to TGW-East. Associate the Route 53 PHZ with all spoke and transit VPCs in both regions, deploy Route 53 Inbound Resolvers in the Security VPC, and point on-premises DNS forwarders to these endpoints.

Answer

The correct architecture associates the Direct Connect Gateway with both Transit Gateways, deploys redundant NAT Gateways across all active Availability Zones in the Security VPC, and associates the Private Hosted Zone with all VPCs.

The correct architecture establishes direct associations between the Direct Connect Gateway (DXGW) and both regional Transit Gateways (TGWs), ensuring that on-premises traffic to both regions is routed natively rather than crossing the TGW peering connection. It also implements high availability by deploying a NAT Gateway per Availability Zone within the Security VPC to avoid a single point of failure. Finally, it ensures DNS resolution by explicitly associating the Route 53 Private Hosted Zone (PHZ) with all spoke and transit VPCs and deploying Route 53 Inbound Resolvers for on-premises clients.

Step-by-Step Solution

Address the transit routing limitation of Transit Gateway Peering.

Since Transit Gateway peering does not support transitive routing for Direct Connect Gateway (DXGW) or VPN connections, the DXGW and Site-to-Site VPNs must be associated with both regional Transit Gateways (TGW-East and TGW-West) directly.

This ensures that on-premises traffic can reach both regions without relying on transit across the peering link, which AWS prohibits.

Design a highly available centralized internet egress architecture.

Deploy a Security VPC in `us-east-1` with TGW attachments in multiple Availability Zones (AZs) and a dedicated NAT Gateway in each active AZ.

Routing traffic to a local NAT Gateway in the same AZ prevents inter-AZ dependency and avoids introducing a single point of failure.

Establish the private DNS resolution across all accounts and regions.

Associate the Route 53 Private Hosted Zone (PHZ) with all spoke and transit VPCs across both regions.

A VPC must be explicitly associated with a PHZ for its instances to resolve queries for the private domain name, regardless of network connectivity.

Enable on-premises clients to resolve the private DNS domain.

Deploy Route 53 Inbound Resolvers in the central Security VPC and configure on-premises DNS servers to forward conditional queries for the private domain to the resolver endpoints.

On-premises clients cannot query the Route 53 private resolver IP directly without Inbound Resolvers acting as entry points.

Key Concept

AWS Transit Gateway transitive routing restrictions, high availability NAT Gateway patterns, and multi-region Route 53 Private Hosted Zone association.

Question 559Question →

An enterprise uses AWS Organizations to manage a multi-account structure including Production, Development, and Security member accounts. The identity team wants to implement single sign-on (SSO) using their on-premises Shibboleth SAML 2.0 Identity Provider (IdP) to allow database administrators (DBAs) to manage Amazon Aurora clusters across all member accounts. The solution must support dynamic session duration requests up to 12 hours specified by the IdP. The security department has attached Service Control Policies (SCPs) to all member Organizational Units (OUs) that permit rds:* actions. Which configuration strategy must the solutions architect implement to successfully authenticate the DBAs and grant them the required permissions?

Establish a SAML Identity Provider pointing to the Shibboleth metadata in each member account. Create an IAM role in each member account with a trust policy that allows the sts:AssumeRoleWithSAML action from the local SAML provider. Configure the Shibboleth IdP to release assertions mapping the DBAs to these member account roles. Set the maximum session duration for each role to 12 hours, and attach an IAM policy to each role that explicitly grants rds:* permissions.

Establish a SAML Identity Provider and an IAM role in a central Shared Services account with a trust policy allowing sts:AssumeRoleWithSAML. Have the DBAs federate into this central role, and then use role chaining to assume target DBA roles in the member accounts via sts:AssumeRole with a requested 12-hour duration. Rely on the trust policies in the member accounts to permit access from the central role, without creating SAML providers in those accounts.

Establish a SAML Identity Provider and an IAM role in each member account with a trust policy allowing the sts:AssumeRoleWithSAML action. Set the maximum session duration for each role to 12 hours. Leave the permissions policies of these IAM roles blank, relying on the organization-level Service Control Policies (SCPs) that permit rds:* actions to implicitly grant the necessary permissions to the federated roles.

Establish a SAML Identity Provider and an IAM role in each member account. Configure the IAM role's trust policy to trust the Shibboleth SAML provider using the sts:AssumeRole action instead of sts:AssumeRoleWithSAML to bypass session duration restrictions. Set the maximum session duration for each role to 12 hours, and attach an IAM policy to each role that explicitly grants rds:* permissions.

Show answer & explanation

Answer: Establish a SAML Identity Provider pointing to the Shibboleth metadata in each member account. Create an IAM role in each member account with a trust policy that allows the sts:AssumeRoleWithSAML action from the local SAML provider. Configure the Shibboleth IdP to release assertions mapping the DBAs to these member account roles. Set the maximum session duration for each role to 12 hours, and attach an IAM policy to each role that explicitly grants rds:* permissions.

Answer

The correct strategy requires configuring a SAML identity provider and role in each member account because role chaining (authenticating to a central role and then assuming member roles) limits the session duration to a maximum of 1 hour, failing the 12-hour requirement. Additionally, the trust policy must use the sts:AssumeRoleWithSAML action to allow SAML-based federation, and the IAM role must have an explicit policy granting rds:* since Service Control Policies (SCPs) act only as guardrails and do not grant permissions.

Step-by-Step Solution

Analyze the session duration requirement of 12 hours.

Identify that role chaining limits the session duration to a maximum of 1 hour, meaning federated users must assume their target roles in member accounts directly rather than chaining from a central hub role.

AWS restricts role chaining sessions to a maximum of 1 hour, regardless of the target role's MaxSessionDuration configuration.

Determine the proper trust policy action for direct SAML federation.

The target IAM roles in each member account must trust the SAML Identity Provider using the 'sts:AssumeRoleWithSAML' action.

SAML federation requires the use of the STS API operation AssumeRoleWithSAML; using standard AssumeRole will cause federation requests to fail.

Evaluate the relation between SCPs and IAM policies.

SCPs act as guardrails (filters) and do not grant permissions. Explicit permissions must be granted by the IAM policies attached to the federated roles in each member account.

An empty IAM policy results in an implicit deny, even if an SCP explicitly permits the action at the OU level.

Key Concept

SAML 2.0 Federation and Session Duration Limits in Multi-Account Architectures

Question 560Question →

An organization has multiple member accounts managed under AWS Organizations. The security team wants to enable a single AWS CloudTrail trail that automatically collects API activity logs across all current and future member accounts, delivering them to a centralized Amazon S3 bucket located in a dedicated Security account. Which configuration steps must a solutions architect perform to implement this centralized logging solution?

Create an organization trail from the management account. Enable S3 server-side encryption on the destination S3 bucket using the AWS-managed KMS key (aws/s3) to ensure all member account logs are encrypted.

Create a separate CloudTrail trail in each member account. Apply a Service Control Policy (SCP) at the Organization root that grants the s3:PutObject permission to all member accounts to allow delivery to the centralized S3 bucket.

Create an organization trail from the management account or a delegated administrator account. Configure the S3 bucket policy in the Security account to allow the CloudTrail service principal (cloudtrail.amazonaws.com) to write logs, using a condition that restricts access to the organization's ID.

Create an organization trail from the management account. Configure the destination S3 bucket policy in the Security account to grant s3:PutObject permissions exclusively to the AWS account ID of the management account.

Show answer & explanation

Answer: Create an organization trail from the management account or a delegated administrator account. Configure the S3 bucket policy in the Security account to allow the CloudTrail service principal (cloudtrail.amazonaws.com) to write logs, using a condition that restricts access to the organization's ID.

Answer

To centralize CloudTrail logs across an AWS Organization, an organization trail should be created in the management account or a delegated administrator account. The destination S3 bucket policy in the central Security account must trust the CloudTrail service principal (cloudtrail.amazonaws.com) and permit it to perform s3:PutObject operations. Restricting the write access to the specific Organization ID using the aws:PrincipalOrgID condition ensures that only trails from within the organization can write to the bucket.

Step-by-Step Solution

Configure the destination S3 bucket policy in the central Security account.

The bucket policy allows the cloudtrail.amazonaws.com service principal to write objects (s3:PutObject), using the aws:PrincipalOrgID condition to restrict access to the organization.

This establishes the cross-account permission boundary required for the CloudTrail service to write logs from any account within the organization to the central bucket.

Deploy the trail as an organization trail in the management account or a delegated administrator account.

The trail is automatically created in all member accounts, and any future accounts added to the organization will also have the trail applied.

Creating the trail at the organization level simplifies governance and ensures centralized auditing without manual trail creation in each individual account.

Key Concept

Centralized Organization Trail Delivery to S3

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

Alternative Method

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