All practice questions

1964 questions

All types1,964 Multiple choice1,006 Multiple select931 Ordering27

A logistics enterprise manages its multi-account environment within AWS Organizations. The enterprise has established SAML 2.0-based federation with its on-premises identity provider (IdP) to allow database administrators to access target AWS member accounts. Once federated, the administrators must access database backups stored in a centralized Amazon S3 bucket within a shared services account. The S3 bucket is encrypted using the default AWS-managed key (aws/s3). Currently, when the administrators federate into their respective member accounts, they are unable to retrieve the backup files from the shared services account. Which combination of configuration adjustments will resolve these access issues?

Configure the S3 bucket in the shared services account to use a customer managed KMS key, and update its key policy to grant decrypt permissions to the member account's federated IAM role. In the member accounts, ensure the IAM role trust policy trusts the SAML provider with the sts:AssumeRoleWithSAML action, and attach a local IAM policy to the role that grants read access to the S3 bucket.

Apply a Service Control Policy (SCP) at the Organizational Unit (OU) level containing the member accounts that explicitly allows s3:GetObject and kms:Decrypt actions on the shared services account's resources. In the member accounts, configure the federated IAM role trust policy to trust the SAML provider with the sts:AssumeRoleWithSAML action, without attaching local IAM policies.

Configure the S3 bucket in the shared services account to use a customer managed KMS key, and update its key policy to grant decrypt permissions to the member account's federated IAM role. In the member accounts, configure the IAM role trust policy to trust the SAML provider with the sts:AssumeRole action, and attach a local IAM policy to the role that grants read access to the S3 bucket.

Modify the key policy of the AWS-managed key (aws/s3) in the shared services account to grant decrypt permissions to the member account's federated IAM role. In the member accounts, ensure the IAM role trust policy trusts the SAML provider with the sts:AssumeRoleWithSAML action, and attach a local IAM policy to the role that grants read access to the S3 bucket.

Show answer & explanation

Answer: Configure the S3 bucket in the shared services account to use a customer managed KMS key, and update its key policy to grant decrypt permissions to the member account's federated IAM role. In the member accounts, ensure the IAM role trust policy trusts the SAML provider with the sts:AssumeRoleWithSAML action, and attach a local IAM policy to the role that grants read access to the S3 bucket.

Answer

Configure the S3 bucket in the shared services account to use a customer managed KMS key, update its key policy to allow the federated role in the member account to decrypt the data, configure the member account's federated IAM role trust policy to allow sts:AssumeRoleWithSAML, and attach a local IAM policy allowing S3 access.

The correct solution involves transitioning the central S3 bucket's encryption to a customer managed KMS key, which allows key policy modification for cross-account access. The member account's federated role trust policy must also be configured with the correct SAML action (sts:AssumeRoleWithSAML) and local S3/KMS permissions must be attached.

Step-by-Step Solution

Change S3 bucket encryption from the default AWS-managed key (aws/s3) to a customer managed KMS key in the shared services account.

Enables the ability to customize the key policy to allow cross-account access, which is prohibited with the default AWS-managed key.

AWS-managed KMS keys cannot have their policies modified and cannot be accessed by external AWS accounts.

Modify the key policy of the customer managed KMS key in the shared services account to permit the federated IAM role in the member account to perform kms:Decrypt operations.

Delegates decryption permissions to the external principal.

For cross-account KMS access, both the key policy in the owning account and the IAM policy in the consuming account must allow the KMS action.

Configure the federated IAM role trust policy in the member accounts to use the sts:AssumeRoleWithSAML action and trust the SAML identity provider (IdP) principal.

Allows users authenticated via the corporate IdP to assume the IAM role using the SAML assertion.

SAML federation requires the specific sts:AssumeRoleWithSAML API action; standard sts:AssumeRole will fail.

Attach a local IAM policy to the federated role in the member accounts granting s3:GetObject on the centralized bucket and kms:Decrypt on the customer managed KMS key.

Gives the federated user identity the active permission to read the files and decrypt them.

An SCP or key policy alone does not grant permissions; the local IAM identity must also explicitly possess the permissions.

Key Concept

Cross-account access to encrypted S3 resources requires a customer managed KMS key combined with a correctly configured SAML trust policy utilizing sts:AssumeRoleWithSAML and local IAM policies.

Question 762Question →

A financial services company is designing a disaster recovery and high availability architecture for its new credit evaluation API. The workload is deployed across two AWS Regions: us-east-1 (primary) and us-west-2 (secondary). The application tier is deployed in private subnets and must query external credit bureaus via the internet. The database tier must use Amazon Aurora PostgreSQL. The business requires a Recovery Time Objective (RTO) of 10 minutes, a Recovery Point Objective (RPO) of 5 minutes, and consistent private DNS resolution for internal microservices across both VPCs. Which architecture meets these requirements with the highest availability and lowest administrative overhead?

Deploy Amazon Aurora PostgreSQL with Multi-AZ in us-east-1 and configure cross-region snapshot replication to us-west-2 every 4 hours. During a failover, restore the database from the latest snapshot, update Route 53 latency routing policies, and deploy a single NAT Gateway in each Availability Zone of both VPCs.

Deploy an Amazon Aurora PostgreSQL Global Database with the primary cluster in us-east-1 and a secondary cluster in us-west-2. Create a Route 53 Private Hosted Zone for internal DNS and associate it only with the us-east-1 VPC. Configure a Route 53 Failover routing policy with health checks pointing to the Application Load Balancers in both regions. Deploy NAT Gateways in multiple Availability Zones in both VPCs.

Deploy an Amazon Aurora PostgreSQL Global Database with the primary cluster in us-east-1 and a secondary cluster in us-west-2. Create a Route 53 Private Hosted Zone for internal DNS and associate it with the VPCs in both regions. Configure a Route 53 Failover routing policy with health checks pointing to the Application Load Balancers in both regions. Deploy NAT Gateways in multiple Availability Zones in both VPCs.

Deploy an Amazon Aurora PostgreSQL Global Database with the primary cluster in us-east-1 and a secondary cluster in us-west-2. Create a Route 53 Private Hosted Zone for internal DNS and associate it with the VPCs in both regions. Configure a Route 53 Failover routing policy with health checks pointing to the Application Load Balancers in both regions. Deploy a single NAT Gateway in a single public subnet in each region's VPC.

Show answer & explanation

Answer: Deploy an Amazon Aurora PostgreSQL Global Database with the primary cluster in us-east-1 and a secondary cluster in us-west-2. Create a Route 53 Private Hosted Zone for internal DNS and associate it with the VPCs in both regions. Configure a Route 53 Failover routing policy with health checks pointing to the Application Load Balancers in both regions. Deploy NAT Gateways in multiple Availability Zones in both VPCs.

Answer

The architecture using Amazon Aurora PostgreSQL Global Database with multi-AZ NAT Gateways in both regions and a Route 53 Private Hosted Zone associated with both VPCs.

The configuration utilizing Amazon Aurora PostgreSQL Global Database, Route 53 Private Hosted Zones associated with both VPCs, Route 53 Active-Passive Failover with health checks, and multi-AZ NAT Gateways correctly addresses all RTO/RPO limits and avoids single points of failure.

Step-by-Step Solution

Evaluate the database replication strategy against RTO and RPO constraints.

Amazon Aurora PostgreSQL Global Database provides sub-second RPO and under 1 minute failover (RTO), whereas restoring from snapshots exceeds the 5-minute RPO and 10-minute RTO.

To ensure database recovery meets strict business SLAs.

Analyze private DNS resolution requirements for the multi-region workload.

The Route 53 Private Hosted Zone must be associated with the VPCs in both the primary and secondary regions.

Without cross-region association, microservices in the disaster recovery region VPC will fail to resolve internal service domains.

Assess outbound network egress configuration for high availability.

NAT Gateways must be deployed in multiple Availability Zones in each VPC.

A single NAT Gateway per VPC creates a single point of failure, violating high availability requirements if that specific zone experiences an outage.

Key Concept

Disaster recovery planning with tight RTO/RPO targets requires cross-region active-passive replication (like Aurora Global Database) combined with robust Route 53 failover health checks, multi-AZ VPC egress paths, and cross-region private hosted zone associations.

Estimated Time:3m 0s

Question 763Question →

A global manufacturing consortium uses AWS Organizations to manage workloads across dozens of AWS accounts. The consortium wants to enable single sign-on (SSO) for its vendor engineers who are managed in an external Active Directory Federation Services (AD FS) instance using SAML 2.0. The vendor engineers must be able to access target AWS resources in individual member accounts using the AWS Command Line Interface (AWS CLI) and the AWS Management Console. Which of the following actions must the Solutions Architect perform to implement this federated access model? (Select TWO.)

Select all that apply

In each target AWS account, create an IAM SAML identity provider and create an IAM role with a trust policy that grants the sts:AssumeRoleWithSAML action to the identity provider principal.

Configure the AD FS identity provider to send SAML assertions that include the Role and RoleSessionName attributes mapped to the user's AD groups and session identifiers.

In each target AWS account, create an IAM role with a trust policy that allows the sts:AssumeRoleWithWebIdentity action and designates the external AD FS provider as an OpenID Connect (OIDC) identity provider.

Apply a Service Control Policy (SCP) to the organization's root that trusts the corporate AD FS endpoint, automatically permitting cross-account role assumption across all member accounts without local identity provider configurations.

Show answer & explanation

Answer: In each target AWS account, create an IAM SAML identity provider and create an IAM role with a trust policy that grants the sts:AssumeRoleWithSAML action to the identity provider principal.; Configure the AD FS identity provider to send SAML assertions that include the Role and RoleSessionName attributes mapped to the user's AD groups and session identifiers.

Answer

Creating an IAM SAML identity provider and role using the sts:AssumeRoleWithSAML action in each target account, and configuring the AD FS provider to send assertions containing the Role and RoleSessionName attributes.

To establish SAML 2.0-based federation, an IAM SAML identity provider must be created in each target AWS account. An IAM role is then configured in each account with a trust policy that explicitly allows the sts:AssumeRoleWithSAML action for that provider. Additionally, the external Identity Provider (such as AD FS) must be configured to pass the mandatory AWS SAML attributes: Role (which lists the ARNs of the role and the identity provider) and RoleSessionName (which specifies the session identifier). Together, these configurations enable federated users to authenticate and assume the correct roles in target accounts.

Step-by-Step Solution

Establish trust within the target AWS accounts

Created an IAM SAML identity provider using the metadata document from the AD FS server, and configured target IAM roles with trust policies using the federated identity provider ARN as the principal.

This establishes a cryptographic trust relationship, allowing the AWS accounts to trust assertions coming from the AD FS server.

Configure SAML assertions on the Identity Provider side

SAML claim rules are configured in AD FS to map LDAP attributes (such as memberOf and sAMAccountName) to the AWS-defined SAML attributes: 'https://aws.amazon.com/SAML/Attributes/Role' and 'https://aws.amazon.com/SAML/Attributes/RoleSessionName'.

AWS requires these specific attributes within the SAML assertion to determine which IAM role the user is authorized to assume and to identify the session.

Key Concept

Establishing SAML 2.0 federation in a multi-account environment requires creating local IAM SAML identity providers, defining roles with trust policies using the sts:AssumeRoleWithSAML action, and configuring the external IdP to pass the required Role and RoleSessionName attributes in the SAML assertion.

Question 764Question →

A financial institution uses AWS Organizations to manage $150$ member accounts. The security engineering team is designing a centralized logging and auditing solution. They require all AWS CloudTrail management events from all regions across all accounts to be aggregated into a single Amazon S3 bucket in a dedicated Security account. The architecture must enforce the following requirements:
- All logs must be encrypted at rest using a customer managed key (CMK) in AWS KMS.
- The KMS CMK must be managed within the Security account, and its key policy must enforce least privilege.
- Log integrity validation must be enabled.
- Member account administrators must be blocked from disabling, modifying, or deleting the logging configuration.
- The configuration must scale automatically when new member accounts are added to the organization.

Which of the following configurations meets these requirements while ensuring compliance and operational efficiency?

Create an organization trail from the organization's management account and configure it to deliver logs to the S3 bucket in the Security account. In the Security account, configure the S3 bucket policy to grant s3:GetBucketAcl and s3:PutObject permissions to cloudtrail.amazonaws.com, restricting the write permission to the path corresponding to the Organization ID and requiring the s3:x-amz-acl condition to be bucket-owner-full-control. Create a customer managed KMS key in the Security account with a key policy that allows cloudtrail.amazonaws.com to perform kms:GenerateDataKey* and kms:Decrypt under the condition that the kms:EncryptionContext:aws:cloudtrail:arn matches the organization trail ARN.

Create an organization trail from the organization's management account. Deliver the logs to the S3 bucket in the Security account. In the Security account, configure the S3 bucket policy to grant s3:PutObject to the cloudtrail.amazonaws.com service principal. For encryption, configure CloudTrail to use the default AWS-managed KMS key for Amazon S3 (aws/s3) in the Security account, ensuring all member accounts automatically inherit encryption capabilities without additional key policies.

Create an organization trail in the management account. Deliver logs to the S3 bucket in the Security account. In the Security account, configure a customer managed KMS key. To authorize member accounts to write logs and use the key, create a Service Control Policy (SCP) at the organization's root that allows s3:PutObject and kms:GenerateDataKey* for the cloudtrail.amazonaws.com principal, and attach an IAM policy to each member account administrator role allowing access to the Security account S3 bucket.

Create an organization trail in the management account. Deliver logs to the S3 bucket in the Security account. Configure the S3 bucket policy in the Security account to grant s3:PutObject permissions to the IAM roles and root users of all 150 member accounts. Configure the KMS customer managed key policy to grant kms:GenerateDataKey* permissions to the IAM roles of all member accounts, updating the policy programmatically each time a new member account is created.

Show answer & explanation

Answer: Create an organization trail from the organization's management account and configure it to deliver logs to the S3 bucket in the Security account. In the Security account, configure the S3 bucket policy to grant s3:GetBucketAcl and s3:PutObject permissions to cloudtrail.amazonaws.com, restricting the write permission to the path corresponding to the Organization ID and requiring the s3:x-amz-acl condition to be bucket-owner-full-control. Create a customer managed KMS key in the Security account with a key policy that allows cloudtrail.amazonaws.com to perform kms:GenerateDataKey* and kms:Decrypt under the condition that the kms:EncryptionContext:aws:cloudtrail:arn matches the organization trail ARN.

Answer

The configuration that uses an organization trail with a customer-managed KMS key in the Security account, configuring the S3 bucket policy and KMS key policy to permit the cloudtrail.amazonaws.com service principal to write logs and generate data keys respectively, while restricting access using the organization ID and trail ARN conditions.

The correct configuration implements an organization trail in the management account to ensure centralization and scalability. The target S3 bucket policy correctly allows the cloudtrail.amazonaws.com service principal to write to the bucket under the bucket owner full control condition. The customer managed KMS key policy grants the cloudtrail.amazonaws.com service principal kms:GenerateDataKey* and kms:Decrypt permissions with a condition that scopes the usage to the specific trail ARN using the encryption context. This setup adheres to least-privilege principles and scales automatically as new accounts are added.

Step-by-Step Solution

Establish the logging mechanism using AWS Organizations.

Creating an organization trail in the management account automatically deploys the trail across all regions in all member accounts, including new accounts as they join.

This meets the scalability and administrator restriction requirements, as member accounts cannot modify or delete organization trails.

Configure the centralized Amazon S3 bucket policy in the Security account.

The bucket policy allows cloudtrail.amazonaws.com to execute s3:PutObject to the path '/AWSLogs/o-orgid/*' and s3:GetBucketAcl, requiring the 'bucket-owner-full-control' ACL.

This enables CloudTrail to write the log files cross-account while ensuring that the central Security account retains ownership of the delivered logs.

Configure the KMS Customer Managed Key (CMK) policy in the Security account.

The key policy allows cloudtrail.amazonaws.com to perform kms:GenerateDataKey* and kms:Decrypt, with a condition verifying that kms:EncryptionContext:aws:cloudtrail:arn matches the organization trail ARN.

This permits CloudTrail to generate the unique data keys needed to encrypt logs per account, while preventing unauthorized entities from using the key.

Key Concept

Centralized multi-account logging with AWS CloudTrail, cross-account S3 bucket policies, and cross-account KMS key policies.

Question 765Question →

A healthcare technology company has a multi-account AWS environment managed under AWS Organizations. The architecture consists of a central `Network-Shared` account containing a Hub VPC, which connects to the on-premises datacenter via AWS Direct Connect. Two consumer accounts, `Clinical-Apps` and `Data-Analytics`, contain Spoke VPCs connected to the Hub VPC using an AWS Transit Gateway. The on-premises environment hosts legacy health systems in the `corp.internal` DNS domain. The company has created a Route 53 Private Hosted Zone (PHZ) named `aws.internal` in the `Network-Shared` account.

The company needs to establish a DNS resolution strategy that meets the following requirements:
- On-premises servers must be able to resolve resources within `aws.internal`.
- EC2 instances in the Spoke VPCs must be able to resolve names in the on-premises `corp.internal` domain.

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

Select all that apply

In the `Network-Shared` account, create a Route 53 Resolver inbound endpoint in the Hub VPC. Configure the on-premises DNS servers to forward queries for the `aws.internal` domain to the IP addresses of this inbound endpoint.

In the `Network-Shared` account, create a Route 53 Resolver outbound endpoint in the Hub VPC. Create a Resolver forwarding rule for the `corp.internal` domain pointing to the on-premises DNS servers. Share the rule with the other accounts using AWS Resource Access Manager (RAM), and associate the rule with the Spoke VPCs in the `Clinical-Apps` and `Data-Analytics` accounts.

Use AWS Resource Access Manager (RAM) to share the `aws.internal` Private Hosted Zone from the `Network-Shared` account to the consumer accounts, then associate the shared hosted zone with the Spoke VPCs in the `Clinical-Apps` and `Data-Analytics` accounts.

Create a Route 53 Resolver outbound endpoint in each Spoke VPC. Configure the outbound endpoints to forward queries for `aws.internal` to the AWS Transit Gateway, and configure a static route in the Transit Gateway to redirect these queries to the Hub VPC's Route 53 Resolver.

In the `Network-Shared` account, create a Route 53 Resolver inbound endpoint in the Hub VPC. Associate the `aws.internal` Private Hosted Zone with the Direct Connect Gateway (DXGW) to allow the on-premises DNS servers to resolve records transitively without configuring forwarders.

Show answer & explanation

Answer: In the `Network-Shared` account, create a Route 53 Resolver inbound endpoint in the Hub VPC. Configure the on-premises DNS servers to forward queries for the `aws.internal` domain to the IP addresses of this inbound endpoint.; In the `Network-Shared` account, create a Route 53 Resolver outbound endpoint in the Hub VPC. Create a Resolver forwarding rule for the `corp.internal` domain pointing to the on-premises DNS servers. Share the rule with the other accounts using AWS Resource Access Manager (RAM), and associate the rule with the Spoke VPCs in the `Clinical-Apps` and `Data-Analytics` accounts.

Answer

To establish the DNS resolution strategy, the solutions architect must configure a Route 53 Resolver inbound endpoint in the Hub VPC to receive queries for `aws.internal` forwarded from the on-premises DNS servers. Additionally, the architect must configure a Route 53 Resolver outbound endpoint in the Hub VPC along with a forwarding rule for `corp.internal` pointing to the on-premises DNS servers, share this rule with the consumer accounts using AWS Resource Access Manager (RAM), and associate the rule with the Spoke VPCs.

The correct architecture requires a Route 53 Resolver inbound endpoint in the Hub VPC to process incoming queries from the on-premises DNS servers for `aws.internal`. For outbound resolution, a Route 53 Resolver outbound endpoint in the Hub VPC combined with a forwarding rule for `corp.internal` is shared with the spoke accounts via AWS Resource Access Manager (RAM). This allows instances in the Spoke VPCs to resolve the on-premises domain names through the shared rule association.

Step-by-Step Solution

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

On-premises servers can resolve records in `aws.internal`.

By creating a Route 53 Resolver inbound endpoint in the Hub VPC, the AWS side exposes IP addresses. The on-premises DNS servers can then forward queries for `aws.internal` to these IP addresses.

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

Hub VPC is capable of forwarding queries for `corp.internal` to on-premises.

Creating a Route 53 Resolver outbound endpoint in the Hub VPC allows AWS to forward queries to external DNS servers. A forwarding rule defines that queries for `corp.internal` must go to the on-premises DNS server IPs.

Extend outbound DNS resolution to the Spoke VPCs in the consumer accounts.

Spoke VPCs can resolve records in `corp.internal`.

Sharing the Resolver forwarding rule using AWS Resource Access Manager (RAM) allows the `Clinical-Apps` and `Data-Analytics` accounts to associate their Spoke VPCs with the rule, enabling them to use the Hub VPC's outbound endpoint.

Key Concept

Multi-Account Hybrid DNS Resolution using Route 53 Resolver Endpoints and Shared Rules

Question 766Question →

An enterprise is designing a multi-account architecture using AWS Organizations. The security team wants to establish a governance framework where member accounts are prevented from leaving the organization or disabling AWS Config. Additionally, a central compliance auditing application hosted in a dedicated Security account must be able to periodically assess resource configurations across all member accounts.

Which two configurations should a Solutions Architect implement to meet these requirements?

Select all that apply

Attach a Service Control Policy (SCP) to the organization root that denies the organizations:LeaveOrganization and config:StopConfigurationRecorder actions.

Create an IAM role in each member account with the necessary read-only permissions and a trust policy that allows the Security account's compliance application role to assume it.

Attach a Service Control Policy (SCP) to the member accounts' Organizational Unit (OU) that explicitly allows the sts:AssumeRole action for the Security account's role to grant cross-account access.

Encrypt the configuration logs in the member accounts using the default AWS managed key for AWS Config (aws/config) and update its key policy to allow cross-account access from the Security account.

Use AWS Resource Access Manager (RAM) to share the AWS Config delivery channels and configuration recorders from each member account with the Security account.

Show answer & explanation

Answer: Attach a Service Control Policy (SCP) to the organization root that denies the organizations:LeaveOrganization and config:StopConfigurationRecorder actions.; Create an IAM role in each member account with the necessary read-only permissions and a trust policy that allows the Security account's compliance application role to assume it.

Answer

The correct configurations are attaching a Service Control Policy (SCP) to the organization root to deny organizations:LeaveOrganization and config:StopConfigurationRecorder, and creating an IAM role in each member account with read-only permissions and a trust policy that allows the Security account's compliance application role to assume it.

Attaching a Service Control Policy (SCP) at the root level of the organization ensures that guardrails are applied globally to prevent member accounts from leaving the organization or stopping the AWS Config recorder. Additionally, cross-account access is established by creating IAM roles in the member accounts that trust the compliance application's role in the Security account, allowing the compliance application to assume those roles and read resource configuration data.

Step-by-Step Solution

Enforce organization membership and config guardrails.

Attach an SCP at the root level of the AWS Organization to prevent member accounts from leaving the organization and disabling AWS Config.

SCPs act as organizational guardrails that define the maximum available permissions for member accounts.

Establish cross-account access.

Create a read-only IAM role in each member account and configure its trust policy to trust the compliance role in the Security account.

SCPs do not grant permissions; IAM roles and policies must be explicitly configured in the target accounts to grant cross-account access.

Key Concept

AWS Organizations Service Control Policies act as permission guardrails (not permission granters), and cross-account access must be explicitly authorized using IAM roles and trust policies.

Alternative Method

Instead of manual IAM role creation, AWS Control Tower or AWS Organizations StackSets can be used to automatically deploy the compliance IAM roles to all new and existing member accounts.

Estimated Time:3m 0s

Question 767Question →

A financial services company is designing a hybrid network connectivity solution for its multi-account environment on AWS. The environment consists of $10$ AWS accounts managed under AWS Organizations, with each account containing a single VPC in the `us-east-1` Region. The company also has an on-premises data center that must be securely connected to all VPCs. The solution must support transitive routing between the VPCs and the on-premises environment, minimize routing table management complexity, and support future expansion to new accounts. Which two actions should a solutions architect take to meet these requirements?

Select all that apply

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

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

Establish VPC peering connections between all VPCs in a full-mesh configuration, and configure a private virtual interface (private VIF) on the Direct Connect connection to connect directly to each VPC.

Create a Direct Connect gateway, associate it directly with the virtual private gateways (VGWs) of all

10

spoke VPCs, and use the Direct Connect gateway to route traffic transitively between the VPCs.

Deploy a single NAT Gateway in a shared network VPC, route all VPC-to-VPC traffic through it, and associate a Route 53 Private Hosted Zone with the shared VPC without associating it with the spoke VPCs.

Show answer & explanation

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

Answer

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

The correct approach uses AWS Transit Gateway shared via AWS Resource Access Manager (RAM) to connect the spoke VPCs in a hub-and-spoke topology, minimizing routing complexity. To connect this setup to the on-premises network via AWS Direct Connect, a transit virtual interface (transit VIF) is configured and connected to a Direct Connect gateway, which is then associated with the Transit Gateway. This enables full transitive routing between the VPCs and the on-premises data center.

Step-by-Step Solution

Set up a centralized hub-and-spoke network topology.

Create an AWS Transit Gateway in a dedicated network account and share it via AWS RAM with the spoke VPC accounts.

This simplifies routing table management and supports scaling to new accounts without configuring manual peering connections.

Configure hybrid connectivity using AWS Direct Connect.

Establish a transit virtual interface (transit VIF) on the Direct Connect connection, terminate it at a Direct Connect gateway, and associate the Direct Connect gateway with the Transit Gateway.

A transit VIF is required to connect Direct Connect to an AWS Transit Gateway, enabling transitive routing to all attached spoke VPCs.

Key Concept

AWS Transit Gateway and Direct Connect Gateway integration with transit VIF for multi-account transitive routing.

Question 768Question →

A financial services company is designing a deployment pipeline for a high-volume payment processing application. The application runs as an Amazon ECS service on AWS Fargate behind an Application Load Balancer (ALB) and connects to an Amazon Aurora PostgreSQL Serverless v2 database cluster. The deployment process must meet the following requirements:

1. The update must be rolled out with zero downtime.
2. Initial deployment validation must route exactly $10\%$ of live traffic to the new version, with the remaining $90\%$ routed only after the new version remains stable for $15$ minutes.
3. If the HTTP 5xx error rate exceeds $0.05\%$ during the validation period, the deployment must immediately and automatically roll back.
4. Database schema updates must be applied and verified before any client traffic is routed to the new tasks, without impacting the currently running tasks.

Which two actions should a Solutions Architect take to satisfy these requirements? (Select two.)

Select all that apply

Configure an AWS CodeDeploy deployment group for the ECS service using the ECSCanary10Percent15Minutes traffic-shifting configuration, and configure the deployment group to monitor a CloudWatch alarm for the ALB HTTP 5xx metric to trigger automatic rollback.

Design the database schema updates using the expand-and-contract pattern, and execute the migration scripts via a dedicated AWS CodeBuild step in the CI/CD pipeline prior to starting the ECS CodeDeploy deployment.

Configure the ECS service to use the ECS rolling update deployment type with minimumHealthyPercent set to

100\%

and maximumPercent set to

200\%

, and configure a CloudWatch alarm on the ALB HTTP 5xx metric to trigger an automatic rollback of the service update.

Configure an AWS CodeDeploy deployment group for the ECS service using the ECSLinear10PercentEvery15Minutes traffic-shifting configuration, and include the database schema migration script in the ECS task definition's container entrypoint script.

Configure an AWS CodeDeploy deployment group for the ECS service using the ECSAllAtOnce traffic-shifting configuration, and execute the database schema migrations via a Lambda function triggered by the AfterAllowTraffic lifecycle hook.

Show answer & explanation

Answer: Configure an AWS CodeDeploy deployment group for the ECS service using the ECSCanary10Percent15Minutes traffic-shifting configuration, and configure the deployment group to monitor a CloudWatch alarm for the ALB HTTP 5xx metric to trigger automatic rollback.; Design the database schema updates using the expand-and-contract pattern, and execute the migration scripts via a dedicated AWS CodeBuild step in the CI/CD pipeline prior to starting the ECS CodeDeploy deployment.

Answer

The correct strategy is to configure an AWS CodeDeploy deployment group using the canary deployment configuration with automated CloudWatch rollbacks, while executing backward-compatible database migrations in the CI/CD pipeline prior to the deployment.

The correct strategy uses the CodeDeploy canary deployment configuration to handle the precise traffic shifting requirement, combined with a CloudWatch alarm on Application Load Balancer metrics for automatic rollback. For the database migrations, using the expand-and-contract pattern in a separate CI/CD pipeline step (such as AWS CodeBuild) ensures the database schema remains backward-compatible with the active version, preventing downtime and avoiding concurrent migration execution issues.

Step-by-Step Solution

Select the traffic-shifting model that routes

10\%

of traffic to the replacement task set and then shifts the remaining

90\\%

after a

15

-minute validation period.

The ECSCanary10Percent15Minutes deployment configuration is identified as the matching AWS-native configuration.

This satisfies the requirement to shift exactly

10\%

of live traffic initially and transition the rest after

15

minutes.

Configure automated rollback based on the HTTP 5xx error rate.

A CloudWatch alarm is created for the Application Load Balancer's HTTPCode_Target_5XX_Count metric with a

1

-minute evaluation window, and associated with the CodeDeploy deployment group.

This ensures that if the error rate exceeds the

0.05\%

threshold during the canary phase, CodeDeploy automatically halts the deployment and rolls back immediately.

Determine the appropriate time and mechanism for database migrations to prevent lock contention and downtime.

The migrations are executed as a separate AWS CodeBuild step in the pipeline before CodeDeploy starts, using a backward-compatible (expand-and-contract) database schema design.

Executing the migration in the pipeline prevents container startup race conditions, and using the expand-and-contract pattern ensures the currently running tasks (which still receive

100\\%

of traffic initially) are not impacted by the database changes.

Key Concept

AWS CodeDeploy Canary configuration and backward-compatible database migration patterns in blue/green deployments.

Question 769Question →

A financial services company is designing a multi-account hub-and-spoke network architecture in a single AWS Region using an AWS Transit Gateway (TGW). The architecture consists of $50$ spoke VPCs (IP ranges within $10.0.0.0/16$ to $10.49.0.0/16$ ) and a Centralized Inspection VPC. The Centralized Inspection VPC hosts a fleet of third-party firewalls behind a Gateway Load Balancer (GWLB) and NAT Gateways. The company's on-premises datacenters use a primary AWS Direct Connect (DX) connection with a Transit VIF terminated on a Direct Connect Gateway (DXGW), and a backup IPsec Site-to-Site VPN connection terminated directly on the TGW. The design must meet the following requirements: all traffic between spoke VPCs, traffic between spokes and the on-premises network, and internet-bound egress traffic from the spokes must be inspected by the firewalls in the Centralized Inspection VPC; if the primary DX connection fails, traffic must fail over automatically to the Site-to-Site VPN, preferring the DX connection when it is healthy; and administrative overhead must be minimized while preventing routing loops. Which configuration will meet these requirements?

Configure a single TGW route table named `Transit-RT` associated with all spoke VPC, Centralized Inspection VPC, DXGW, and VPN attachments. Enable route propagation for all attachments in `Transit-RT`. In the spoke VPC route tables, point `

0.0.0.0/0

` and the on-premises ranges to the TGW. In `Transit-RT`, add a static route for `

0.0.0.0/0

` pointing to the Centralized Inspection VPC attachment to direct all traffic to the firewall fleet.

Configure three TGW route tables: `Spoke-RT`, `OnPrem-RT`, and `Inspection-RT` with the required associations and static routes. To enable domain name resolution across the environment, create a Route 53 Private Hosted Zone (PHZ) in a shared services account and associate it only with the Centralized Inspection VPC. Configure on-premises and spoke VPC DNS clients to resolve internal domains transitively through the Centralized Inspection VPC's Route 53 Resolver.

Configure three TGW route tables: `Spoke-RT`, `OnPrem-RT`, and `Inspection-RT`. Associate `Spoke-RT` with all spoke VPC attachments and add a static route for `

0.0.0.0/0

` pointing to the Centralized Inspection VPC attachment. Associate `OnPrem-RT` with the DXGW and VPN attachments and add a static route for `

10.0.0.0/8

` pointing to the Centralized Inspection VPC attachment. Associate `Inspection-RT` with the Centralized Inspection VPC attachment and enable route propagation from the spoke VPC, DXGW, and VPN attachments. Configure BGP on the customer gateways to advertise on-premises prefixes with a shorter AS path over the DX connection than over the VPN.

Configure two TGW route tables: `Spoke-RT` and `Inspection-RT`. Associate `Spoke-RT` with all spoke VPC, DXGW, and VPN attachments, and add a static route for `

0.0.0.0/0

` pointing to the Centralized Inspection VPC. Associate `Inspection-RT` with the Centralized Inspection VPC. Deploy a single NAT Gateway in a single Availability Zone in the Centralized Inspection VPC to handle all egress traffic. Configure the TGW attachment subnets in the Centralized Inspection VPC to route all incoming traffic directly to this NAT Gateway, bypassing the GWLB.

Show answer & explanation

Answer: Configure three TGW route tables: `Spoke-RT`, `OnPrem-RT`, and `Inspection-RT`. Associate `Spoke-RT` with all spoke VPC attachments and add a static route for ` $0.0.0.0/0$ ` pointing to the Centralized Inspection VPC attachment. Associate `OnPrem-RT` with the DXGW and VPN attachments and add a static route for ` $10.0.0.0/8$ ` pointing to the Centralized Inspection VPC attachment. Associate `Inspection-RT` with the Centralized Inspection VPC attachment and enable route propagation from the spoke VPC, DXGW, and VPN attachments. Configure BGP on the customer gateways to advertise on-premises prefixes with a shorter AS path over the DX connection than over the VPN.

Answer

Configure three separate Transit Gateway route tables to isolate the routing domains, using static routes in the spoke and on-premises route tables to forward traffic to the Centralized Inspection VPC, and route propagation in the inspection route table to return traffic to its destination. Use BGP AS path prepending on the customer gateway to prefer the Direct Connect connection over the VPN.

The correct configuration implements three separate Transit Gateway route tables. The spoke route table directs all non-local traffic to the inspection VPC. The on-premises route table directs all incoming hybrid traffic to the inspection VPC. The inspection route table uses propagated routes to safely deliver inspected traffic to its final destination without loops. BGP routing configuration on the customer gateways ensures that the Direct Connect path is preferred while allowing automatic failover to the VPN.

Step-by-Step Solution

Isolate routing domains by creating three Transit Gateway route tables: `Spoke-RT`, `OnPrem-RT`, and `Inspection-RT`.

Prevents routing loops and allows fine-grained control over pre-inspection and post-inspection traffic flows.

A single route table cannot handle both forwarding traffic to the inspection VPC and routing it to the final destination without causing loops or bypassing the firewall.

Associate `Spoke-RT` with the spoke VPC attachments and add a static route for `

0.0.0.0/0

` pointing to the Centralized Inspection VPC attachment.

Forces all outbound, inter-spoke, and spoke-to-on-premises traffic from the spokes to be sent to the Centralized Inspection VPC.

Ensures that all traffic originating from application workloads undergoes firewall inspection before going to the internet, other spokes, or on-premises.

Associate `OnPrem-RT` with the DXGW and VPN attachments and add a static route for `

10.0.0.0/8

` pointing to the Centralized Inspection VPC attachment.

Ensures that any incoming traffic from on-premises to the AWS spoke networks is redirected to the Centralized Inspection VPC.

Meets the security requirement to inspect all traffic between the on-premises network and the AWS spokes.

Associate `Inspection-RT` with the Centralized Inspection VPC attachment, and enable route propagation from the spokes, DXGW, and VPN attachments.

Populates the route table with the exact prefixes for the spokes and on-premises networks.

Allows the Transit Gateway to correctly route traffic to its final destination after it has been inspected and returned by the firewall fleet.

Configure the customer gateways to advertise on-premises networks via BGP over both paths, prepending the AS path on the VPN connection.

AWS TGW prefers the shorter AS path on the DX connection, only failing over to the VPN if the DX connection becomes unavailable.

Provides automatic failover while maintaining a deterministic preference for the higher-bandwidth Direct Connect link.

Key Concept

Multi-table Transit Gateway routing for centralized security inspection and hybrid failover

Estimated Time:3m 0s

Question 770Question →

A financial technology enterprise manages its multi-account environment using AWS Organizations. The security team mandates that all human operators must access AWS member accounts exclusively via SAML 2.0 federation with the corporate Identity Provider (IdP). To prevent backdoors, the architect must ensure that no external AWS accounts outside the organization o-1234567890 can perform cross-account role assumption into the member accounts, while internal cross-account role assumption between member accounts remains fully functional. The corporate SAML provider CorporateIdP has already been created in the member accounts.

Which combination of an IAM role trust policy in the member accounts and a Service Control Policy (SCP) at the Organization root will securely achieve this goal?

Configure the IAM role trust policy in the member accounts with the Action set to "sts:AssumeRoleWithSAML" and the Principal set to the CorporateIdP SAML provider ARN. Apply an SCP at the Organization root that denies the Action "sts:AssumeRole" for all resources with a condition of StringNotEqualsIfExists for "aws:PrincipalOrgID" set to "o-1234567890".

Configure the IAM role trust policy in the member accounts with the Action set to "sts:AssumeRole" and the Principal set to the CorporateIdP SAML provider ARN. Apply an SCP at the Organization root that denies the Action "sts:AssumeRole" for all resources with a condition of StringNotEqualsIfExists for "aws:PrincipalOrgID" set to "o-1234567890".

Configure the IAM role trust policy in the member accounts with the Action set to "sts:AssumeRoleWithSAML" and the Principal set to the CorporateIdP SAML provider ARN. Apply an SCP at the Organization root that denies the Actions "sts:AssumeRole" and "sts:AssumeRoleWithSAML" for all resources with a condition of StringNotEqualsIfExists for "aws:PrincipalOrgID" set to "o-1234567890".

Show answer & explanation

Answer: Configure the IAM role trust policy in the member accounts with the Action set to "sts:AssumeRoleWithSAML" and the Principal set to the CorporateIdP SAML provider ARN. Apply an SCP at the Organization root that denies the Action "sts:AssumeRole" for all resources with a condition of StringNotEqualsIfExists for "aws:PrincipalOrgID" set to "o-1234567890".

Answer

Configure the IAM role trust policy in the member accounts to use the "sts:AssumeRoleWithSAML" action for the SAML provider principal. To restrict cross-account access, apply a root-level SCP that denies the "sts:AssumeRole" action using the StringNotEqualsIfExists condition operator for the "aws:PrincipalOrgID" context key.

The correct option outlines the appropriate configuration where the IAM role trust policy allows the "sts:AssumeRoleWithSAML" action for the federated SAML provider. Furthermore, the Service Control Policy at the Organization root blocks external "sts:AssumeRole" requests by asserting that any caller whose "aws:PrincipalOrgID" is not equal to the company's Organization ID is denied. By using the "StringNotEqualsIfExists" operator, the policy ensures that external standalone accounts, which completely lack the "aws:PrincipalOrgID" key in their requests, are also evaluated as a match for the condition and successfully denied access.

Step-by-Step Solution

Analyze SAML 2.0 trust relationship requirement

Identify that the trust policy of IAM roles designed for direct SAML federation must specify the principal as the SAML provider ARN and use the "sts:AssumeRoleWithSAML" action.

SAML federation authentication bypasses the standard AWS principal framework and uses a dedicated security token service API.

Evaluate the behavior of aws:PrincipalOrgID in Service Control Policies

Determine that aws:PrincipalOrgID identifies the Organization to which the calling principal belongs. If the caller is external or not part of an organization (such as a standalone account), this key will not be present in the request context.

This is critical for preventing cross-account access from unauthorized external accounts.

Select the correct conditional evaluation operator

Choose the StringNotEqualsIfExists operator rather than StringNotEquals.

If StringNotEquals is used, a request lacking the aws:PrincipalOrgID key (like one from a standalone external account) will evaluate to false and bypass the Deny. StringNotEqualsIfExists evaluates to true when the key is missing, securing the endpoint.

Validate the SCP action scope against SAML federation

Ensure the SCP only restricts the "sts:AssumeRole" action and does not include "sts:AssumeRoleWithSAML".

Including sts:AssumeRoleWithSAML would block federation because the incoming SAML request does not contain the aws:PrincipalOrgID key at the time of evaluation.

Key Concept

Using Multi-Account IAM Federation with SAML 2.0 alongside Service Control Policies requires aligning the sts:AssumeRoleWithSAML API with condition key evaluations. In SCPs, using conditional operators like StringNotEqualsIfExists prevents authentication bypasses by ensuring missing context keys (such as those from standalone external accounts) trigger the Deny rule.

Question 771Question →

A multinational logistics provider manages its multi-account environment using AWS Organizations. The environment is organized into several Organizational Units (OUs), including Workloads-OU and Security-OU. The Cloud Security team must implement a security and compliance governance framework that satisfies the following requirements:
1. Audit Centralization: AWS Config must be configured using a delegated administrator account (Auditor-Account) inside Security-OU to manage and deploy compliance rules across all member accounts.
2. Guardrails: Prevent any user or role in the Workloads-OU (including administrators) from modifying, deleting, or stopping AWS Config configuration recorders or delivery channels.
3. Log Integrity: AWS CloudTrail must deliver organizational trails to a central Amazon S3 bucket in the Auditor-Account with Server-Side Encryption with AWS KMS (SSE-KMS) enabled.
4. Data Protection: Application workloads in the Workloads-OU must encrypt their application secrets in AWS Systems Manager (SSM) Parameter Store using the same KMS key managed in the Auditor-Account.

Which of the following configurations represents the most secure and operationally efficient architecture to meet these requirements?

Register the Auditor-Account as the delegated administrator for AWS Config. Attach an SCP to the Workloads-OU that denies the config:DeleteConfigurationRecorder, config:DeleteDeliveryChannel, and config:StopConfigurationRecorder actions. In the Auditor-Account, create a KMS Customer Managed Key (CMK) and configure its key policy to allow workload IAM roles in the Workloads-OU to perform cryptographic operations. Configure the S3 bucket policy in the Auditor-Account to allow the cloudtrail.amazonaws.com service principal to write logs.

Register the Auditor-Account as the delegated administrator for AWS Config. Attach an SCP to the Workloads-OU that denies the config:DeleteConfigurationRecorder, config:DeleteDeliveryChannel, and config:StopConfigurationRecorder actions. In the Auditor-Account, configure the S3 bucket policy to allow the cloudtrail.amazonaws.com service principal to write logs. Encrypt the SSM parameters using the default AWS-managed KMS key 'aws/ssm' in the Auditor-Account and grant permissions to the workloads in the Workloads-OU.

Register the Auditor-Account as the delegated administrator for AWS Config. Attach an SCP to the Workloads-OU that explicitly allows the required AWS Config operations for compliance roles, assuming this grants the necessary permissions. In the Auditor-Account, create a KMS Customer Managed Key (CMK) and configure its key policy to allow workload IAM roles in the Workloads-OU to perform cryptographic operations. Configure the S3 bucket policy in the Auditor-Account to allow the cloudtrail.amazonaws.com service principal to write logs.

Register the Auditor-Account as the delegated administrator for AWS Config. Attach an SCP to the Workloads-OU that denies the config:DeleteConfigurationRecorder, config:DeleteDeliveryChannel, and config:StopConfigurationRecorder actions. In the Auditor-Account, create a KMS Customer Managed Key (CMK) and configure its key policy to allow workload IAM roles in the Workloads-OU to perform cryptographic operations. Configure the S3 bucket policy in the Auditor-Account to rely on default S3 bucket Access Control Lists (ACLs) and the management account's administrative role to deliver CloudTrail logs.

Show answer & explanation

Answer: Register the Auditor-Account as the delegated administrator for AWS Config. Attach an SCP to the Workloads-OU that denies the config:DeleteConfigurationRecorder, config:DeleteDeliveryChannel, and config:StopConfigurationRecorder actions. In the Auditor-Account, create a KMS Customer Managed Key (CMK) and configure its key policy to allow workload IAM roles in the Workloads-OU to perform cryptographic operations. Configure the S3 bucket policy in the Auditor-Account to allow the cloudtrail.amazonaws.com service principal to write logs.

Answer

The configuration that registers the Auditor-Account as the delegated administrator, uses an SCP to deny AWS Config changes on the Workloads-OU, creates a Customer Managed Key with cross-account access, and configures the S3 bucket policy to allow the CloudTrail service principal to deliver logs.

The correct solution registers the Auditor-Account as the delegated administrator for AWS Config, isolates audit functions, and uses an SCP to restrict changes in the Workloads-OU. For cross-account encryption, a Customer Managed Key (CMK) is used with a key policy granting access to workload roles. Finally, the centralized S3 bucket policy is configured to allow the CloudTrail service principal to deliver logs successfully.

Step-by-Step Solution

Set up Delegated Administrator for AWS Config.

Allows Auditor-Account to deploy and monitor rules organization-wide without accessing the Organizations management account directly.

Aligns with AWS best practices for multi-account security governance by decoupling configuration monitoring from administrative privileges.

Create and attach the Service Control Policy (SCP).

Ensures that member accounts under Workloads-OU cannot stop or delete AWS Config recorders and delivery channels, even if they have administrative privileges.

Maintains baseline auditability across the workloads environment.

Create and configure a Customer Managed Key (CMK) in the Auditor-Account.

Enables cross-account parameter encryption in SSM Parameter Store.

AWS-managed keys (like aws/ssm) cannot be shared across AWS accounts, making CMKs mandatory for cross-account encryption requirements.

Configure the S3 bucket policy in the Auditor-Account.

Allows CloudTrail to successfully deliver log files from member accounts to the central logging bucket.

CloudTrail service principal must be explicitly permitted via S3 bucket policy for cross-account log delivery.

Key Concept

Multi-account governance using AWS Organizations, SCPs, Delegated Administrators, and cross-account resource access.

Estimated Time:3m 0s

Question 772Question →

A retail company is hosting a high-traffic REST API on Amazon EC2 instances within an Auto Scaling group behind an Application Load Balancer (ALB). The API's launch template needs to be updated with a new AMI. The company has strict cost constraints and cannot run a parallel environment or double its EC2 instance count during the deployment. However, they must maintain at least 60% of the normal serving capacity during the update. Additionally, if the ALB 5XX error rate increases during the deployment or within a 10-minute monitoring window after the update completes, the deployment must automatically roll back to the previous AMI. Which deployment strategy meets these requirements with the lowest operational overhead?

Configure a AWS CodeDeploy Blue/Green deployment. Set up CodeDeploy to copy the Auto Scaling group, deploy the updated AMI, and use a weighted Application Load Balancer target group to shift traffic. Configure automatic rollbacks based on the ALB 5XX error rate CloudWatch alarm.

Configure an EC2 Auto Scaling Instance Refresh with a rolling strategy. Set the minimum healthy percentage to 60%. Specify the ALB 5XX error rate CloudWatch alarm in the alarm specification of the deployment preferences, and enable auto-rollback.

Configure a AWS CodeDeploy In-Place deployment for the Auto Scaling group. Use a custom deployment configuration to update 40% of the instances at a time, and configure triggers to roll back when the ALB 5XX error rate CloudWatch alarm is activated. Manually update the Auto Scaling group launch template after the deployment completes.

Update the launch template in a AWS CloudFormation template and perform a stack update. Set the AutoScalingRollingUpdate policy's MinInstancesInService to 60%. Configure a CloudFormation rollback trigger pointing to the ALB 5XX error rate CloudWatch alarm.

Show answer & explanation

Answer: Configure an EC2 Auto Scaling Instance Refresh with a rolling strategy. Set the minimum healthy percentage to 60%. Specify the ALB 5XX error rate CloudWatch alarm in the alarm specification of the deployment preferences, and enable auto-rollback.

Answer

Configure an EC2 Auto Scaling Instance Refresh with a rolling strategy, set the minimum healthy percentage to 60%, specify the ALB 5XX error rate CloudWatch alarm in the alarm specification of the deployment preferences, and enable auto-rollback.

The correct answer is the strategy using EC2 Auto Scaling Instance Refresh with an alarm specification. This strategy updates the instances in-place within the same Auto Scaling group, meeting the requirement of not running a parallel environment or doubling instance costs, while maintaining the required 60% capacity. It natively supports configuring CloudWatch alarms in the alarm specification and performing an automatic rollback to the previous launch template version if these alarms are triggered during the update or the post-deployment monitoring window.

Step-by-Step Solution

Analyze the capacity and cost constraints.

Since the client cannot double the EC2 instance count or run a parallel environment, blue/green deployments that duplicate the fleet (like CodeDeploy Blue/Green) are ruled out. The update must be performed in-place or as a rolling update within the existing Auto Scaling group.

To satisfy the budget constraint and ensure that at least 60% of the serving capacity is maintained during the deployment.

Evaluate the rollback and monitoring window requirement.

The system requires monitoring application-level error metrics (ALB 5XX errors) during the update and for a 10-minute post-deployment window, triggering an automatic rollback if thresholds are breached. CloudFormation rollback triggers only monitor during stack update execution, making them unsuitable for post-deployment monitoring.

To ensure that any issues arising shortly after the update finishes will trigger an automatic rollback.

Analyze Auto Scaling Group launch template synchronization.

Using CodeDeploy In-Place does not update the underlying Auto Scaling group launch template. A scale-out event would provision instances with the old template, causing drift. In contrast, EC2 Auto Scaling Instance Refresh natively updates the launch template first, ensuring that any scale-out events use the correct configuration.

To maintain launch template consistency and prevent configuration drift during auto-scaling events.

Select the optimal strategy.

EC2 Auto Scaling Instance Refresh with a rolling strategy, a minimum healthy percentage of 60%, and an alarm specification meets all constraints natively with the lowest operational overhead.

It handles the rolling update, respects capacity limits, updates the launch template, and manages the rollback window automatically.

Key Concept

EC2 Auto Scaling Instance Refresh allows rolling updates of instances within an Auto Scaling group based on a new launch template or AMI, supporting minimum healthy capacity controls and automatic rollbacks via CloudWatch alarms during both the deployment and post-deployment monitoring phases.

Question 773Question →

A financial services firm is consolidating VPC Flow Logs from $150$ AWS accounts into a centralized Amazon S3 bucket within a dedicated Security account. The architecture must ensure that flow logs are encrypted at rest using a customer managed AWS KMS key. The Security team wants to enforce that no member account can modify or delete the flow log configurations, while ensuring log delivery succeeds across all accounts.

Which combination of configuration steps will satisfy these requirements with the least operational complexity?

In the Security account, create the S3 bucket and a customer managed KMS key. Configure the S3 bucket policy to allow s3:PutObject for each member account's IAM root principal, and configure the KMS key policy to trust the member accounts. In each member account, create a cross-account IAM role with s3:PutObject permissions, and configure VPC Flow Logs to assume this IAM role to write to the S3 bucket. In the management account, apply an SCP denying ec2:DeleteFlowLogs to all member accounts.

In the Security account, create the S3 bucket and enable default encryption using the AWS managed key aws/s3. Configure the S3 bucket policy to allow s3:PutObject and s3:GetBucketAcl for delivery.logs.amazonaws.com. Enable VPC Flow Logs in the member accounts pointing to the Security account S3 bucket. In the management account, apply an SCP denying ec2:DeleteFlowLogs to all member accounts.

In the Security account, create the S3 bucket and a customer managed KMS key. Configure the S3 bucket policy to allow s3:PutObject and s3:GetBucketAcl for delivery.logs.amazonaws.com, and configure the KMS key policy to allow delivery.logs.amazonaws.com to perform kms:GenerateDataKey* and kms:Decrypt. Enable VPC Flow Logs in the member accounts pointing to the Security account S3 bucket, specifying the KMS key ARN. In the management account, apply an SCP denying ec2:DeleteFlowLogs to all member accounts.

In the Security account, create the S3 bucket and a customer managed KMS key. Configure the S3 bucket policy and KMS key policy to allow access to delivery.logs.amazonaws.com. Enable VPC Flow Logs in the member accounts. In the management account, apply an SCP that explicitly allows ec2:CreateFlowLogs and ec2:DescribeFlowLogs while denying ec2:DeleteFlowLogs to member accounts, relying on the SCP to grant the necessary permissions to create the flow logs.

Show answer & explanation

Answer: In the Security account, create the S3 bucket and a customer managed KMS key. Configure the S3 bucket policy to allow s3:PutObject and s3:GetBucketAcl for delivery.logs.amazonaws.com, and configure the KMS key policy to allow delivery.logs.amazonaws.com to perform kms:GenerateDataKey* and kms:Decrypt. Enable VPC Flow Logs in the member accounts pointing to the Security account S3 bucket, specifying the KMS key ARN. In the management account, apply an SCP denying ec2:DeleteFlowLogs to all member accounts.

Answer

The correct solution uses a customer managed KMS key to support cross-account resource sharing, which is required because AWS managed keys (such as aws/s3) cannot be shared across accounts. It configures both the S3 bucket policy and the KMS key policy to permit the Log Delivery service principal (delivery.logs.amazonaws.com), which is the principal responsible for writing VPC Flow Logs. Additionally, it implements an SCP with a deny effect to prevent member accounts from modifying or deleting flow logs, without mistakenly relying on the SCP to grant permissions.

Step-by-Step Solution

Configure the S3 bucket policy in the Security account.

Allow delivery.logs.amazonaws.com to perform s3:PutObject and s3:GetBucketAcl.

VPC Flow Logs deliver logs via the Log Delivery service principal, which requires these bucket-level permissions to write logs and check bucket configuration.

Configure the KMS key policy for the customer managed key in the Security account.

Grant delivery.logs.amazonaws.com permissions for kms:GenerateDataKey* and kms:Decrypt.

Since the bucket uses KMS encryption, the cross-account Log Delivery service principal must have access to generate data keys to encrypt the log objects before writing.

Apply a Service Control Policy (SCP) to the member accounts.

Deny ec2:DeleteFlowLogs.

This establishes a governance guardrail that prevents users in the member accounts from disabling the security monitoring mechanism.

Key Concept

Cross-Account VPC Flow Logs with KMS Encryption and SCP Guardrails

Question 774Question →

An enterprise is designing a multi-Region, multi-account hybrid network architecture for its AWS Organizations environment. The workload consists of $40$ production spoke VPCs in the `us-east-1` Region and $20$ development spoke VPCs in the `us-west-2` Region. The architecture must satisfy the following requirements:

* Outbound internet traffic from all spoke VPCs in both Regions must be routed through centralized NAT Gateways to minimize costs. A failure of a NAT Gateway in one Availability Zone (AZ) must not impact outbound traffic from other AZs.
* Hybrid connectivity to the on-premises network ( $172.16.0.0/12$ ) must use a dedicated $10\text{ Gbps}$ AWS Direct Connect (DX) connection in `us-east-1` as the primary path. A backup AWS Site-to-Site VPN connection in `us-east-1` must be used only if the DX connection fails.
* All spoke VPCs in both Regions must resolve private DNS queries for resources in a Route 53 Private Hosted Zone (PHZ) named `corp.internal` hosted in a centralized Shared Services account.

Which of the following architectures meets these requirements while ensuring high availability, minimizing costs, and preventing asymmetric routing?

Deploy a Transit Gateway (TGW) in each Region (`tgw-east` and `tgw-west`) and establish a peering attachment between them. Deploy a centralized Egress VPC in each Region, each containing a NAT Gateway in each AZ. Configure the spoke VPC route tables to route internet-bound traffic to their local TGW and then to the local Egress VPC. Associate `tgw-east` with the DXGW. Establish the backup Site-to-Site VPN on `tgw-east`. Advertise the

172.16.0.0/12

prefix over both BGP sessions. On the customer gateway, prepend the local autonomous system (AS) path multiple times on the Direct Connect BGP session to ensure it is preferred over the VPN. Associate the `corp.internal` PHZ with the Shared Services VPC, and rely on TGW Peering to transitively resolve DNS queries for all spoke VPCs without individual VPC associations.

Deploy a Transit Gateway (TGW) in each Region (`tgw-east` and `tgw-west`) and establish a peering attachment between them. Deploy a centralized Egress VPC in each Region, each containing a NAT Gateway in each AZ. Configure the spoke VPC route tables to route internet-bound traffic (`0.0.0.0/0`) to their local TGW, which routes it to the local Egress VPC. In the Egress VPC, route traffic from each subnet to the NAT Gateway in the same AZ. Associate `tgw-east` with a Direct Connect Gateway (DXGW) connected to the DX connection. Establish the backup Site-to-Site VPN terminating on `tgw-east`. Advertise the

172.16.0.0/12

prefix over both BGP sessions, and configure the customer gateway to assign a higher Local Preference to routes received via the DX connection. Authorize and associate the `corp.internal` Private Hosted Zone in the Shared Services account with all spoke VPCs in both Regions.

Deploy a Transit Gateway (TGW) in each Region and peer them. Deploy a single centralized Egress VPC in `us-east-1` with one NAT Gateway. Route all internet-bound traffic from both Regions to `tgw-east` and then to the Egress VPC. Configure the backup Site-to-Site VPN to advertise a more specific prefix (

172.16.0.0/13

) than the Direct Connect connection (

172.16.0.0/12

) to ensure the VPN is preferred for backup routing. Create Route 53 Resolver inbound and outbound endpoints in each spoke VPC to forward queries for `corp.internal` to the Shared Services account.

Connect all spoke VPCs in both Regions directly to the DXGW to enable transitive VPC-to-VPC routing. Deploy a centralized Egress VPC in `us-east-1` with a NAT Gateway in each AZ, routing all internet traffic from both Regions to this VPC via the DXGW. Establish the backup VPN on the DXGW, and advertise the

172.16.0.0/12

prefix over both BGP sessions. In the Shared Services account, share the `corp.internal` zone via AWS Resource Access Manager (RAM) to all accounts, and associate it locally.

Show answer & explanation

Answer: Deploy a Transit Gateway (TGW) in each Region (`tgw-east` and `tgw-west`) and establish a peering attachment between them. Deploy a centralized Egress VPC in each Region, each containing a NAT Gateway in each AZ. Configure the spoke VPC route tables to route internet-bound traffic (`0.0.0.0/0`) to their local TGW, which routes it to the local Egress VPC. In the Egress VPC, route traffic from each subnet to the NAT Gateway in the same AZ. Associate `tgw-east` with a Direct Connect Gateway (DXGW) connected to the DX connection. Establish the backup Site-to-Site VPN terminating on `tgw-east`. Advertise the $172.16.0.0/12$ prefix over both BGP sessions, and configure the customer gateway to assign a higher Local Preference to routes received via the DX connection. Authorize and associate the `corp.internal` Private Hosted Zone in the Shared Services account with all spoke VPCs in both Regions.

Answer

The architecture that uses Regional Transit Gateways, local Egress VPCs with multi-AZ NAT Gateways, equal prefix BGP routing with Local Preference, and direct multi-account Private Hosted Zone association.

The correct architecture uses Regional Transit Gateways with peered connections and local Egress VPCs to comply with TGW routing rules and avoid inter-Region NAT charges. Deploying a NAT Gateway in each AZ prevents cross-AZ dependencies and ensures high availability. Using the same prefix (

172.16.0.0/12

) over both BGP sessions allows standard path selection, and assigning a higher Local Preference on the customer gateway for Direct Connect routes ensures inbound traffic prefers Direct Connect. For outbound traffic, AWS naturally prefers Direct Connect over VPN for equal prefix lengths. Finally, authorizing and associating the Private Hosted Zone directly with all spoke VPCs across accounts and Regions provides a cost-effective and highly available DNS resolution mechanism.

Step-by-Step Solution

Deploy Transit Gateways in both Regions and peer them, and deploy local Egress VPCs in each Region with a NAT Gateway in each AZ.

Ensures scalable multi-account VPC routing and high availability for internet egress while avoiding single points of failure and cross-AZ charges.

TGW Peering does not support cross-Region transitive routing to a single Region's NAT Gateways efficiently, and a single NAT Gateway is a single point of failure.

Configure BGP routing on the customer gateway to advertise the same

172.16.0.0/12

prefix on both Direct Connect and VPN connections, and set a higher BGP Local Preference on the customer gateway for routes received over Direct Connect.

Symmetric routing is achieved where both inbound and outbound traffic prefer the Direct Connect connection under normal operations.

Equal prefix lengths prevent longest prefix match overrides. Prepending the AS path or using different prefixes on the VPN would cause asymmetric routing or incorrect failover.

Authorize the Route 53 Private Hosted Zone in the Shared Services account and associate it with all spoke VPCs in both Regions.

Enables seamless and cost-effective private DNS resolution across all accounts and Regions.

PHZs must be explicitly associated with each VPC to resolve queries; transitive DNS resolution over VPC or TGW peering does not happen automatically.

Key Concept

Design of resilient, multi-region hybrid networks using Transit Gateway, Direct Connect, VPN failover routing, and cross-account Private Hosted Zone associations.

Question 775Question →

A financial analytics firm uses AWS Organizations to manage 100 member accounts grouped under a single Production Organizational Unit (OU). The firm wants to implement single sign-on (SSO) using its on-premises SAML 2.0-compliant Identity Provider (IdP). The Solutions Architect must establish federation to grant a group of data analysts read-only access to specific Amazon S3 buckets located across the member accounts. A Service Control Policy (SCP) is applied at the Production OU level to prevent any modification of S3 buckets and objects. Federated users must assume an IAM role in each member account to perform their duties. Which of the following configuration steps must the Solutions Architect perform to successfully establish the federation and ensure the analysts have the necessary access? (Select TWO.)

Select all that apply

In each member account, configure the trust policy of the IAM role with the local SAML provider as the Principal, and set the Action to sts:AssumeRoleWithSAML with a Condition checking the SAML:aud attribute.

In each member account, attach an IAM permission policy to the federated IAM role that explicitly allows the required S3 read actions, ensuring the policy does not exceed the boundaries set by the OU-level SCP.

In each member account, configure the trust policy of the IAM role with the external Identity Provider as the Principal, and set the Action to sts:AssumeRole to allow federation tokens to be exchanged.

Rely on the SCP attached at the Organizational Unit (OU) level to grant the S3 read-only permissions to the federated users, without attaching an IAM permission policy to the role in the member accounts.

Configure the external Identity Provider as an OpenID Connect (OIDC) provider in the management account, and set the Action in the member account trust policies to sts:AssumeRoleWithWebIdentity.

Show answer & explanation

Answer: In each member account, configure the trust policy of the IAM role with the local SAML provider as the Principal, and set the Action to sts:AssumeRoleWithSAML with a Condition checking the SAML:aud attribute.; In each member account, attach an IAM permission policy to the federated IAM role that explicitly allows the required S3 read actions, ensuring the policy does not exceed the boundaries set by the OU-level SCP.

Answer

Establish SAML-based federation by configuring the IAM role trust policy in each member account to use the local SAML provider as the principal and allow the sts:AssumeRoleWithSAML action, and attach local IAM permission policies to the roles to grant S3 read access, since the organizational Service Control Policy (SCP) only acts as a filter and does not grant permissions directly.

To successfully federate with an external SAML 2.0 Identity Provider (IdP) in a multi-account setup, each member account must have a local SAML identity provider created, and the IAM role's trust policy must specify the local SAML provider as the principal and use the sts:AssumeRoleWithSAML action. Furthermore, because Service Control Policies (SCPs) act as permission boundaries and do not grant permissions directly, the federated IAM roles in the member accounts must have explicit local IAM permission policies attached that grant the required S3 read permissions.

Step-by-Step Solution

Configure the trust relationship for the IAM role in each member account.

The trust policy is updated to specify the local SAML Identity Provider as the principal and allow the sts:AssumeRoleWithSAML action.

This is required to allow the on-premises Identity Provider to authenticate users and assume the specified role in the member account via SAML token exchange.

Attach a local IAM permissions policy to the IAM role in the member accounts.

The IAM role has a policy that explicitly allows the required S3 read actions.

SCPs only restrict permissions and do not grant them. A local IAM policy is necessary to explicitly grant the permissions to the role principal.

Key Concept

Multi-Account SAML Federation and Service Control Policy interaction

Question 776Question →

A live sports streaming platform is launching a new pay-per-view service. The registration and stream-start portal is expected to experience a sudden burst of traffic, rising from a baseline of $100\text{ requests per second}$ to $300\text{}000\text{ requests per second}$ within $3\text{ minutes}$ of a major match starting. The backend microservices are hosted on Amazon ECS tasks using AWS Fargate, and the session metadata is stored in an Amazon Aurora PostgreSQL database. Read operations account for $90\%$ of the database workload, and Fargate tasks require approximately $90\text{ seconds}$ to bootstrap and pass health checks. The platform requires a highly scalable architecture that ensures zero dropped requests and sub-second latency for all users. Which combination of actions should a Solutions Architect recommend to optimize the performance and scalability of this architecture?

Submit a request to AWS Support to pre-warm the Application Load Balancer (ALB) to handle the target throughput, configure the Amazon ECS service auto-scaling policy with a scale-out cooldown period of 120 seconds, and deploy Amazon Aurora Replicas with Aurora Auto Scaling enabled to handle the read traffic.

Rely on the Application Load Balancer's (ALB) default elastic scaling capabilities to dynamically adjust to the incoming traffic, configure the Amazon ECS service auto-scaling policy with a scale-out cooldown period of 120 seconds, and configure Aurora Auto Scaling with read replicas to handle the read traffic.

Submit a request to AWS Support to pre-warm the Application Load Balancer (ALB) to handle the target throughput, configure the Amazon ECS service auto-scaling policy with a scale-out cooldown period of 120 seconds, and enable Multi-AZ replication on the Amazon Aurora cluster, configuring the application to route read queries to the standby instance in the secondary Availability Zone.

Submit a request to AWS Support to pre-warm the Application Load Balancer (ALB) to handle the target throughput, configure the Amazon ECS service auto-scaling policy with a scale-out cooldown period of 5 seconds to rapidly scale up Fargate tasks, and deploy Amazon Aurora Replicas with Aurora Auto Scaling enabled to handle the read traffic.

Show answer & explanation

Answer: Submit a request to AWS Support to pre-warm the Application Load Balancer (ALB) to handle the target throughput, configure the Amazon ECS service auto-scaling policy with a scale-out cooldown period of 120 seconds, and deploy Amazon Aurora Replicas with Aurora Auto Scaling enabled to handle the read traffic.

Answer

The correct solution addresses all performance and scalability requirements under a sudden traffic burst. First, submitting an AWS Support request to pre-warm the ALB ensures the entry point handles the immediate

3000\times

traffic increase without dropping connections. Second, setting a scale-out cooldown of

120\text{ seconds}

for Amazon ECS prevents service thrashing because Fargate tasks require

90\text{ seconds}

to boot and pass health checks. Finally, utilizing Amazon Aurora Replicas with Aurora Auto Scaling is the standard, best-practice method to scale a database read-heavy workload horizontally.

Step-by-Step Solution

Address the entry point of the traffic spike by pre-warming the ALB.

The Application Load Balancer is pre-provisioned to handle the instant jump from

100\text{ requests per second}

300\text{}000\text{ requests per second}

without dropping connections.

By default, ELBs scale gradually based on traffic trends, which is too slow for sudden, extreme traffic spikes.

Configure ECS service auto-scaling cooldown times based on task bootstrap latency.

The scale-out cooldown is set to

120\text{ seconds}

, which is greater than the

90\text{ seconds}

needed to bootstrap a Fargate task and pass health checks.

If the cooldown is too short (e.g.,

5\text{ seconds}

), ECS will launch additional tasks before the previously launched tasks become healthy and register, causing resource over-provisioning and thrashing.

Deploy Aurora Replicas and enable Aurora Auto Scaling for the database tier.

The database scale-out handles the

90\%

read workload horizontally.

Aurora Multi-AZ standby instances do not serve read traffic; read queries must be routed to Aurora Replicas which support horizontal scaling.

Key Concept

Handling rapid, massive traffic spikes on AWS requires pre-warming load balancers, configuring auto-scaling cooldown periods to exceed resource bootstrap times, and using read replicas rather than standby instances for horizontal database read scaling.

Question 777Question →

A financial services enterprise is establishing a hybrid environment connecting its on-premises datacenter to a multi-account AWS environment. A central network account contains a Transit VPC with Route 53 Resolver inbound and outbound endpoints, connected to the on-premises DNS servers via AWS Direct Connect and AWS Transit Gateway. The Transit VPC also hosts a Route 53 Private Hosted Zone (PHZ) for corp.internal. Multiple application accounts run workloads in separate VPCs connected via Transit Gateway. The company needs on-premises servers to resolve names in corp.internal, and AWS workloads in the application VPCs to resolve both corp.internal and on-premises domains ending in onprem.internal. Which configuration achieves this hybrid DNS resolution with the minimum number of endpoints?

Share the corp.internal private hosted zone directly with the application accounts using AWS Resource Access Manager, and associate the application VPCs with the shared hosted zone. Configure Route 53 Resolver outbound rules in the network account to forward queries for onprem.internal to the on-premises DNS servers, and share these rules with the application accounts using AWS Resource Access Manager.

Associate the corp.internal private hosted zone with the application VPCs by authorizing the association from the central network account and creating the association from the member accounts. Configure Route 53 Resolver outbound rules in the network account to forward queries for onprem.internal to the on-premises DNS servers, but route the outbound DNS queries directly via a Direct Connect Gateway, bypassing Transit Gateway routing.

Associate the corp.internal private hosted zone with the application VPCs by authorizing the association from the central network account and creating the association from the member accounts. Configure Route 53 Resolver outbound rules in the network account to forward queries for onprem.internal to the on-premises DNS servers, and share these rules with the application accounts using AWS Resource Access Manager. Configure the on-premises DNS servers to forward queries for corp.internal to the inbound resolver endpoint in the Transit VPC.

Create Route 53 Resolver inbound and outbound endpoints in each application VPC. Configure the on-premises DNS servers to forward queries for corp.internal to each application VPC's inbound endpoint. Configure local forwarding rules in each application VPC to send queries for onprem.internal directly to the on-premises DNS servers.

Show answer & explanation

Answer: Associate the corp.internal private hosted zone with the application VPCs by authorizing the association from the central network account and creating the association from the member accounts. Configure Route 53 Resolver outbound rules in the network account to forward queries for onprem.internal to the on-premises DNS servers, and share these rules with the application accounts using AWS Resource Access Manager. Configure the on-premises DNS servers to forward queries for corp.internal to the inbound resolver endpoint in the Transit VPC.

Answer

Associate the private hosted zone with the application VPCs via cross-account association, share the outbound resolver rules via AWS Resource Access Manager, and forward on-premises queries to the inbound resolver endpoint in the Transit VPC.

The correct configuration associates the Private Hosted Zone with the application VPCs by authorizing the cross-account association from the network account and completing the association from the application accounts. It utilizes Route 53 Resolver outbound rules configured in the central network VPC, shared via AWS Resource Access Manager to the application accounts, to forward queries for the on-premises domain to the on-premises DNS servers. On-premises DNS servers are configured to forward queries for the AWS domain to the central inbound resolver endpoint. This setup minimizes costs and complexity by sharing endpoints and avoiding redundant DNS forwarding hops.

Step-by-Step Solution

Enable cross-account Private Hosted Zone resolution.

Authorize the association of the corp.internal Private Hosted Zone with the application VPCs from the central network account using the AWS CLI or SDK, and then associate the VPCs with the hosted zone from the member accounts.

This allows instances in the application VPCs to resolve records in corp.internal locally without routing queries through resolver endpoints, minimizing costs and latency.

Configure outbound DNS resolution from AWS to on-premises.

Create a Route 53 Resolver outbound endpoint in the central network Transit VPC. Define a resolver rule to forward queries for onprem.internal to the on-premises DNS servers. Share the rule with application accounts using AWS Resource Access Manager (RAM) and associate it with the application VPCs.

Sharing a single outbound endpoint and rule across the organization avoids the cost and administrative overhead of deploying outbound endpoints in every VPC.

Configure inbound DNS resolution from on-premises to AWS.

Create a Route 53 Resolver inbound endpoint in the central network Transit VPC. Configure the on-premises DNS servers to conditionally forward queries for corp.internal to the IP addresses of the inbound endpoint.

This allows on-premises systems to resolve resources hosted inside the AWS multi-account environment through the hybrid connection.

Key Concept

Cross-account Private Hosted Zone association and sharing central Route 53 Resolver rules via AWS Resource Access Manager to optimize costs and architecture in a hybrid environment.

Question 778Question →

A university's bioinformatics division uses AWS Organizations to manage multiple research projects. A central engineering AWS account hosts a shared VPC with high-performance computing (HPC) subnets. The division needs to distribute these subnets to various project-specific member accounts for scratch space. They plan to purchase Compute Savings Plans to lower the run costs of their containerized workloads on AWS Fargate across all project accounts. However, a specific sandbox account used for external guest researchers must be excluded from receiving any Savings Plans discounts to keep its billing independent and clean. Which TWO actions should the Solutions Architect perform to implement this strategy? (Select TWO.)

Select all that apply

Navigate to the Billing Preferences page in the AWS Billing console of the management account, turn off discount sharing for the sandbox account, and purchase the Compute Savings Plans in the management account.

Create a Service Control Policy that denies the savingsplans:ApplyDiscount action, and attach the policy to the organizational unit containing the sandbox account.

Use AWS Resource Access Manager to share the subnets with the sandbox account, and encrypt the container storage using an AWS-managed KMS key to ensure cross-account data security.

Create a resource share in the engineering account for the subnets, set the principal to the external sandbox account ID, and enable external sharing in AWS Resource Access Manager without configuring AWS Organizations.

Show answer & explanation

Answer: Enable sharing within AWS Organizations in the AWS Resource Access Manager console of the management account, then create a resource share for the subnets in the engineering account and associate it with the target organizational unit containing the project accounts.; Navigate to the Billing Preferences page in the AWS Billing console of the management account, turn off discount sharing for the sandbox account, and purchase the Compute Savings Plans in the management account.

Answer

Enable sharing within AWS Organizations in the AWS Resource Access Manager console of the management account, then create a resource share for the subnets in the engineering account and associate it with the target organizational unit containing the project accounts. Additionally, turn off discount sharing for the sandbox account in the Billing Preferences page in the AWS Billing console of the management account, and purchase the Compute Savings Plans in the management account.

To share subnets, sharing within the organization must be enabled in AWS Resource Access Manager (RAM) from the management account. Once enabled, subnets can be shared from the resource owner account (engineering) to other accounts or OUs. To prevent the guest sandbox account from benefiting from the Compute Savings Plans purchased at the management level, discount sharing must be disabled specifically for that sandbox account in the Billing Preferences section of the AWS Billing console in the management account.

Step-by-Step Solution

Enable sharing within AWS Organizations in the AWS Resource Access Manager console using the management account.

Allows resources to be shared across organizational accounts without individual handshake requests.

AWS RAM requires organizational sharing to be enabled globally before subnets can be shared with member accounts.

Create a resource share for the subnets in the engineering account and share it with the target organizational unit containing the project accounts.

Project accounts receive access to the VPC subnets for launch configuration.

Enables multi-account resource sharing of network infrastructure (VPC subnets).

In the AWS Billing console of the management account, navigate to Billing Preferences, select discount sharing preferences, and uncheck the sandbox account.

Excludes the sandbox account from receiving Savings Plans and Reserved Instances discounts.

Ensures the guest sandbox account continues to be billed at standard on-demand rates without applying the organizational savings plan benefits.

Key Concept

AWS RAM allows sharing specific resources like subnets within an AWS Organization. Automated billing discounts such as Savings Plans apply globally by default in consolidated billing but can be selectively disabled per account using Billing Preferences in the management account.

Question 779Question →

An energy utility company is designing a disaster recovery architecture for its smart grid control system. The application's primary deployment is in us-west-2 and consists of microservices running on Amazon EC2 instances inside private subnets, outbound traffic routed via NAT Gateways, and a backend Amazon Aurora MySQL database. The company needs to design a disaster recovery solution in us-east-1 that achieves a Recovery Time Objective (RTO) of 10 minutes and a Recovery Point Objective (RPO) of 1 minute, while minimizing cost and avoiding active-active write workloads. Which TWO configurations should a Solutions Architect implement to meet these requirements?

Select all that apply

Create an Amazon Aurora Global Database with the primary database cluster in us-west-2 and a secondary database cluster in us-east-1 to replicate data with sub-second replication latency.

Deploy the application servers in us-east-1 using Auto Scaling groups configured with minimum running instances, and configure Route 53 active-passive failover routing to redirect traffic to the secondary region when the primary region is unhealthy.

Implement hourly database snapshots in us-west-2, copy them to us-east-1 via cross-region snapshot copy, and restore them to a new database cluster during a failover event.

Deploy a single NAT Gateway in a single Availability Zone in us-east-1 to route outbound telemetry verification requests from all recovery private subnets to the internet.

Configure the application servers in the secondary region to write directly to the read-only standby instance of a standard Amazon RDS Multi-AZ deployment located in the primary region.

Show answer & explanation

Answer: Create an Amazon Aurora Global Database with the primary database cluster in us-west-2 and a secondary database cluster in us-east-1 to replicate data with sub-second replication latency.; Deploy the application servers in us-east-1 using Auto Scaling groups configured with minimum running instances, and configure Route 53 active-passive failover routing to redirect traffic to the secondary region when the primary region is unhealthy.

Answer

Creating an Amazon Aurora Global Database to achieve sub-second data replication and deploying the application servers in us-east-1 in a warm standby state with Route 53 active-passive failover routing.

To meet the 1-minute RPO and 10-minute RTO constraints while avoiding active-active complexity, a Solutions Architect should implement an Amazon Aurora Global Database for sub-second database replication across regions, and deploy a warm standby application stack in us-east-1. The warm standby uses Auto Scaling groups with minimum capacity to control cost, and Route 53 active-passive failover routing automatically or manually redirects traffic during a failover event.

Step-by-Step Solution

Analyze RPO requirements to determine the database replication strategy.

An RPO of 1 minute requires continuous or near-continuous data replication. Amazon Aurora Global Database uses storage-level replication to achieve sub-second cross-region replication lag, satisfying the 1-minute RPO.

Traditional backup and restore methods or snapshot replication are hourly or daily processes that violate the 1-minute data loss threshold.

Analyze RTO and cost requirements to determine the compute failover strategy.

An RTO of 10 minutes requires application infrastructure to be pre-provisioned but can be scaled down (warm standby) to minimize costs. Route 53 active-passive failover routing routes traffic to the recovery region when health checks fail.

Starting instances from scratch or redeploying infrastructure during a disaster would likely exceed the 10-minute recovery window, whereas active-active setups are too costly and complex.

Verify high availability constraints in the networking and compute paths of the recovery region.

Ensure NAT Gateways are deployed in each Availability Zone where EC2 instances reside to avoid a single point of failure.

A single NAT Gateway shared across multiple Availability Zones creates a non-redundant network path that can cause total outbound traffic loss if that Availability Zone goes down.

Key Concept

Designing multi-region disaster recovery using warm standby compute configurations and low-latency storage replication mechanisms like Aurora Global Database.

Question 780Question →

A logistics company is designing a multi-account hybrid AWS network in the `us-east-1` Region. The network consists of $12$ spoke VPCs, a centralized egress VPC, and a hybrid connection to an on-premises data center via AWS Direct Connect. The architecture must satisfy the following constraints:
- Spoke VPCs must not be able to communicate with each other.
- All spoke VPCs must route their outbound internet traffic ( $0.0.0.0/0$ ) through the egress VPC, which hosts a redundant cluster of NAT Gateways.
- Spoke VPC workloads must resolve on-premises DNS records hosted on local Active Directory servers.
- Administrative and routing table configuration overhead must be minimized.

Which combination of configuration steps should a Solutions Architect recommend to meet these requirements?

Create two AWS Transit Gateway route tables: a Spoke Route Table and an Egress/Hybrid Route Table. Associate the spoke VPC attachments with the Spoke Route Table, adding static routes for

0.0.0.0/0

pointing to the egress VPC attachment and the on-premises CIDR pointing to the Direct Connect gateway attachment. Disable route propagation from the spoke VPCs in this table. Associate the egress VPC and Direct Connect gateway attachments with the Egress/Hybrid Route Table, and propagate the spoke VPC routes. Deploy a Route 53 Resolver outbound endpoint in the egress VPC and associate a forwarding rule for the on-premises domain with all spoke VPCs.

Associate the Direct Connect Gateway directly with the Virtual Private Gateways (VGWs) of all

12

spoke VPCs to bypass Transit Gateway for hybrid traffic. For internet traffic, associate all spoke VPCs and the egress VPC with a single Transit Gateway route table, propagating all routes to allow spoke VPCs to route

0.0.0.0/0

to the egress VPC. Deploy a Route 53 Resolver outbound endpoint in the egress VPC and associate a forwarding rule for the on-premises domain with all spoke VPCs.

Create two AWS Transit Gateway route tables: a Spoke Route Table and an Egress/Hybrid Route Table. Associate the spoke VPC attachments with the Spoke Route Table, and add static routes for

0.0.0.0/0

pointing to the egress VPC attachment and the on-premises CIDR pointing to the Direct Connect gateway attachment. Create a Route 53 Private Hosted Zone (PHZ) for the on-premises domain in the egress VPC's account, associate the PHZ only with the egress VPC, and rely on Transit Gateway to route DNS resolution traffic transitively from the spoke VPCs to the egress VPC.

Create two AWS Transit Gateway route tables: a Spoke Route Table and an Egress/Hybrid Route Table. Associate the spoke VPC attachments with the Spoke Route Table, and add static routes for

0.0.0.0/0

pointing to the egress VPC attachment and the on-premises CIDR pointing to the Direct Connect gateway attachment. In the egress VPC, deploy a single NAT Gateway in one Availability Zone to act as a centralized egress point for all spoke VPCs. Deploy a Route 53 Resolver outbound endpoint in the egress VPC and associate a forwarding rule for the on-premises domain with all spoke VPCs.

Show answer & explanation

Answer: Create two AWS Transit Gateway route tables: a Spoke Route Table and an Egress/Hybrid Route Table. Associate the spoke VPC attachments with the Spoke Route Table, adding static routes for $0.0.0.0/0$ pointing to the egress VPC attachment and the on-premises CIDR pointing to the Direct Connect gateway attachment. Disable route propagation from the spoke VPCs in this table. Associate the egress VPC and Direct Connect gateway attachments with the Egress/Hybrid Route Table, and propagate the spoke VPC routes. Deploy a Route 53 Resolver outbound endpoint in the egress VPC and associate a forwarding rule for the on-premises domain with all spoke VPCs.

Answer

Create two Transit Gateway route tables (Spoke and Egress/Hybrid) to achieve network isolation. Associate spoke VPCs with the Spoke Route Table with static routes to egress and hybrid attachments without propagation. Associate egress and hybrid attachments with the Egress/Hybrid Route Table and propagate spoke routes. Deploy a Route 53 Resolver outbound endpoint in the egress VPC and associate a forwarding rule for the on-premises domain with all spoke VPCs.

The correct architecture uses AWS Transit Gateway with route table isolation to prevent spoke-to-spoke communication. By placing spoke VPC attachments in a route table that does not propagate spoke routes, spokes cannot reach each other. Outbound internet traffic and on-premises traffic are directed via static routes to the egress VPC and Direct Connect gateway respectively. For DNS, a Route 53 Resolver outbound endpoint with a forwarding rule associated with all spoke VPCs enables DNS resolution for the on-premises domain across all accounts.

Step-by-Step Solution

Set up Transit Gateway and route tables to isolate spoke traffic.

Two route tables are created: a Spoke Route Table and an Egress/Hybrid Route Table.

Separating route domains prevents spoke VPCs from learning routes to each other, ensuring isolation.

Configure the Spoke Route Table with static routes.

Spoke attachments are associated with the Spoke Route Table. Static routes are added for

0.0.0.0/0

(pointing to the egress VPC) and the on-premises CIDR (pointing to the Direct Connect gateway). Route propagation from the spokes is disabled.

This directs outbound and on-premises traffic to the appropriate attachments while blocking spoke-to-spoke routing.

Configure the Egress/Hybrid Route Table with route propagation.

The egress VPC and Direct Connect gateway attachments are associated with the Egress/Hybrid Route Table. Spoke VPC routes are propagated here.

This allows return traffic from the internet egress point and the on-premises data center to find paths back to the spokes.

Configure hybrid DNS resolution.

A Route 53 Resolver outbound endpoint is deployed in the egress VPC, and a forwarding rule for the on-premises domain is created and associated with all 12 spoke VPCs.

This allows workloads in all spoke VPCs to forward DNS queries for the on-premises domain to the local Active Directory servers.

Key Concept

Multi-account network isolation and hybrid DNS routing using AWS Transit Gateway and Route 53 Resolver.

Estimated Time:2m 0s

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

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

Key Concept

Common Mistakes

Answer

Step-by-Step Solution