All practice questions

1964 questions

All types1,964 Multiple choice1,006 Multiple select931 Ordering27

An enterprise is designing a highly available, multi-account hybrid network architecture across two AWS Regions: `us-east-1` (the primary region with 50 spoke VPCs) and `us-west-2` (the secondary region with 30 spoke VPCs). A Shared Services VPC in `us-east-1` hosts a Route 53 Private Hosted Zone (PHZ) for `corp.internal` and an outbound Route 53 Resolver endpoint to resolve on-premises queries.

The enterprise has a 10 Gbps AWS Direct Connect (DX) connection at their on-premises data center (CIDR ` $10.0.0.0/8$ `). They want to use the DX connection as the primary path and deploy an AWS Site-to-Site VPN as a backup path. The solution must minimize latency for both regions under normal conditions, prevent asymmetric routing, support automatic failover, and ensure that resources in all spoke VPCs across both regions can resolve `corp.internal` and on-premises domain queries.

Which combination of steps meets these requirements?

Deploy an AWS Transit Gateway in `us-east-1` (TGW-East). Peer all spoke VPCs in `us-west-2` directly to TGW-East using inter-region VPC peering. Associate the Direct Connect Gateway (DXGW) only with TGW-East, and terminate the Site-to-Site VPN on TGW-East. Configure static routing in TGW-East for `

10.0.0.0/8

` pointing to the DXGW. Associate the Route 53 PHZ only with the Shared Services VPC, and configure the spoke VPCs to use the Shared Services VPC's DNS servers as forwarders.

Deploy TGW-East and TGW-West and peer them. Associate the DXGW with TGW-East and TGW-West. Terminate the Site-to-Site VPN on TGW-East. To prevent asymmetric routing and secure egress, route all on-premises traffic from all VPCs through a single NAT Gateway deployed in a single Availability Zone in the Shared Services VPC. Recreate the `corp.internal` PHZ in each AWS account to ensure local resolution.

Deploy an AWS Transit Gateway in each region (TGW-East and TGW-West) and peer them. Associate the DXGW with both TGW-East and TGW-West. Terminate the Site-to-Site VPN on TGW-East. Configure BGP on-premises to advertise `

10.0.0.0/8

` over both paths, prepending the AS path on the VPN session from AWS to on-premises. Authorize and associate the PHZ `corp.internal` with all spoke VPCs in both regions. Share the Route 53 Resolver forwarding rules via AWS Resource Access Manager (RAM) and associate them with all spoke VPCs.

Deploy TGW-East and TGW-West. Associate the DXGW with TGW-East and terminate the Site-to-Site VPN on TGW-West. Peer TGW-East and TGW-West. Route all `us-west-2` traffic to on-premises via TGW-East's DXGW association, and route all `us-east-1` traffic via TGW-West's VPN as a primary path to balance load. On the on-premises customer gateway, use BGP Local Preference to prefer the VPN connection. For DNS, associate the Route 53 PHZ only with the Shared Services VPC.

Show answer & explanation

Answer: Deploy an AWS Transit Gateway in each region (TGW-East and TGW-West) and peer them. Associate the DXGW with both TGW-East and TGW-West. Terminate the Site-to-Site VPN on TGW-East. Configure BGP on-premises to advertise ` $10.0.0.0/8$ ` over both paths, prepending the AS path on the VPN session from AWS to on-premises. Authorize and associate the PHZ `corp.internal` with all spoke VPCs in both regions. Share the Route 53 Resolver forwarding rules via AWS Resource Access Manager (RAM) and associate them with all spoke VPCs.

Answer

Deploy Transit Gateways in both regions, peer them, and associate the Direct Connect Gateway with both. Use BGP AS path prepending on the VPN connection to make it less preferred, and associate the Private Hosted Zone and shared Resolver rules with all spoke VPCs in both regions.

The correct architecture deploys Transit Gateways in both regions peered together, with the Direct Connect Gateway associated with both TGWs to allow direct, low-latency paths. The backup Site-to-Site VPN terminates on TGW-East. To prevent asymmetric routing, BGP AS path prepending is applied to the VPN connection, ensuring that the on-premises router prefers the Direct Connect path. For DNS, the centralized Route 53 Private Hosted Zone is associated with all spoke VPCs across all accounts and regions, and the Route 53 Resolver forwarding rules are shared via AWS Resource Access Manager, allowing seamless name resolution of both AWS and on-premises resources.

Step-by-Step Solution

Configure the core network connectivity by deploying Transit Gateways (TGW-East and TGW-West) in both regions and peering them. Associate the DXGW with both TGWs to allow direct, low-latency hybrid access for all VPCs during normal operations.

Direct Connect traffic travels directly between on-premises and both regions without transiting the inter-region peering connection, minimizing latency and data transfer costs.

Associating the DXGW with multiple TGWs is the standard multi-region design pattern for Direct Connect.

Establish the backup VPN connection terminating on TGW-East, and configure BGP advertisements. Prepend the AS path on the VPN session advertised from AWS to on-premises.

The on-premises router prefers the Direct Connect path for inbound traffic because the VPN path has a longer AS path. AWS TGW-East prefers the DX path because it has a shorter AS path.

AS path prepending on the VPN connection ensures symmetric routing by making the VPN path less preferred for traffic in both directions.

Authorize and associate the centralized Private Hosted Zone `corp.internal` with all spoke VPCs in both regions using cross-account VPC association.

Spoke VPCs can resolve names in the `corp.internal` domain directly using the Route 53 Resolver.

Route 53 Private Hosted Zones must be associated with consumer VPCs to allow DNS resolution across accounts.

Share the Route 53 Resolver forwarding rules for on-premises domains using AWS Resource Access Manager (RAM) and associate them with all spoke VPCs.

Spoke VPCs forward queries for on-premises domains to the outbound resolver endpoint in the Shared Services VPC, which sends them to on-premises DNS servers.

Sharing forwarding rules via RAM allows consistent DNS resolution across a multi-account environment without duplicating resolver endpoints.

Key Concept

Multi-region hybrid connectivity using Direct Connect Gateway associated with multiple Transit Gateways, backup Site-to-Site VPN, BGP path selection, and cross-account DNS resolution using Route 53 PHZ association and RAM shared Resolver rules.

Estimated Time:3m 0s

Question 862Question →

A connected vehicle manufacturer is launching a real-time performance analytics platform for a global endurance racing event. The platform must ingest telemetry data from $50,000$ vehicles streaming $100\text{ KB}$ JSON payloads once per second, resulting in an aggregate write throughput of $5\text{ GB/s}$ . During the starting lap of the race, the traffic pattern exhibits an instantaneous flash spike, rising from a baseline of $100\text{ requests/sec}$ to the peak load of $50,000\text{ requests/sec}$ within a $30\text{ second}$ window. The platform must ingest this telemetry with sub- $100\text{ ms}$ latency, update real-time leaderboards, and archive all raw payloads for post-race batch analytics. Which three architectural actions should a Solutions Architect recommend to achieve the required performance and scalability under these conditions?

Select all that apply

Deploy a Network Load Balancer to distribute the incoming HTTPS traffic, as it scales to millions of requests per second instantly without pre-warming.

Ingest the telemetry stream into an Amazon Kinesis Data Stream in provisioned mode with

5,000

shards, using the Amazon Kinesis Producer Library on the ingestion targets to aggregate and batch writes.

Maintain and update the real-time leaderboard statistics in Amazon ElastiCache for Redis configured with a replication group and Multi-AZ to support sub-millisecond query performance.

Deploy an Application Load Balancer and configure target tracking scaling policies based on request count per target, relying on the Application Load Balancer's native scaling to absorb the starting-lap traffic spike.

Write incoming telemetry directly to an Amazon Aurora MySQL database cluster, and configure Aurora Auto Scaling to dynamically provision reader replicas to handle the initial write surge during the starting lap.

Configure an Auto Scaling group for the EC2-based ingestion layer with a step scaling policy, reducing the scaling cooldown period to 15 seconds to allow continuous instance launches during the 30-second traffic burst.

Show answer & explanation

Answer: Deploy a Network Load Balancer to distribute the incoming HTTPS traffic, as it scales to millions of requests per second instantly without pre-warming.; Ingest the telemetry stream into an Amazon Kinesis Data Stream in provisioned mode with $5,000$ shards, using the Amazon Kinesis Producer Library on the ingestion targets to aggregate and batch writes.; Maintain and update the real-time leaderboard statistics in Amazon ElastiCache for Redis configured with a replication group and Multi-AZ to support sub-millisecond query performance.

Answer

Deploy a Network Load Balancer to handle the sudden flash spike without pre-warming, ingest the stream into a provisioned Amazon Kinesis Data Stream with 5,000 shards using the Kinesis Producer Library, and maintain the real-time leaderboard in Amazon ElastiCache for Redis.

The correct architecture separates the load balancing, ingestion stream, and cache layers. A Network Load Balancer handles sudden, volatile spikes of millions of requests per second natively without requiring pre-warming. Scaling Kinesis Data Streams to 5,000 shards provides the necessary write capacity (

5\text{ GB/s}

) at the streaming ingestion layer, and using the Kinesis Producer Library optimizes performance via client-side batching. Real-time leaderboard updates require high-performance, low-latency data structures, which are best accommodated by Amazon ElastiCache for Redis.

Step-by-Step Solution

Analyze load balancing scaling characteristics for flash traffic.

Identify that Application Load Balancers require pre-warming for immediate 500x spikes, whereas Network Load Balancers route TCP/UDP traffic and handle sudden bursts natively.

Choosing the correct load balancer prevents dropped requests during the 30-second start-of-race spike.

Calculate Kinesis Data Streams capacity requirements.

50,000 \text{ vehicles} \times 100 \text{ KB/s} = 5,000,000 \text{ KB/s} = 5 \text{ GB/s}

. Since 1 shard supports

1 \text{ MB/s}

write,

5,000

shards are required.

Ensures the ingestion stream has sufficient partitioned throughput to handle the write volume without throttling.

Select high-throughput database layer for real-time leaderboard updates.

Choose Amazon ElastiCache for Redis over relational replicas.

In-memory data stores provide the sub-millisecond write and read performance required for real-time updates under heavy load, whereas relational read replicas do not scale writes.

Key Concept

Handling rapid flash-traffic spikes at the ingestion layer using Network Load Balancers, scaling decoupled stream ingestion using Provisioned Kinesis shards, and leveraging in-memory databases for high-velocity real-time metrics.

Question 863Question →

An enterprise is designing a secure centralized log collection system. Application servers running on Amazon EC2 instances in a Production account ( $111122223333$ ) must write transaction logs directly to an Amazon S3 bucket located in a central Security account ( $444455556666$ ). The solutions architect must enforce the following security and compliance controls:

- Data Encryption: All log objects uploaded to the S3 bucket must be encrypted at rest using an AWS KMS key that supports automatic annual rotation.
- Access Control: The EC2 instance IAM role in the Production account must have permission to write objects to the S3 bucket and encrypt them, but must be prevented from reading, downloading, or decrypting any objects stored in the bucket.
- Data Loss Prevention: No users or roles within the AWS Organization, including administrators, are allowed to delete objects in the S3 bucket, with the sole exception of a central `SecurityAuditRole` in the Security account.

Which combination of configuration steps will satisfy these compliance requirements?

Configure the S3 bucket in the Security account to use the default AWS-managed KMS key (`aws/s3`) for encryption. In the S3 bucket policy in the Security account, allow `s3:PutObject` from the Production EC2 role. Attach an SCP to the Organization root that denies `s3:DeleteObject*` with a condition block specifying `"ArnNotEquals": {"aws:PrincipalArn": "arn:aws:iam::444455556666:role/SecurityAuditRole"}`.

Create a Customer Managed Key (CMK) in the Security account with automatic key rotation enabled. Attach an SCP to the OUs containing the Production and Security accounts that allows `s3:PutObject` and `kms:GenerateDataKey` actions from the Production EC2 role to the Security account S3 bucket and CMK. Deny `s3:DeleteObject*` in the SCP with a condition block specifying `"ArnNotEquals": {"aws:PrincipalArn": "arn:aws:iam::444455556666:role/SecurityAuditRole"}`.

Create a Customer Managed Key (CMK) in the Security account with automatic key rotation enabled. In the CMK key policy, grant the Production EC2 role permissions for `kms:GenerateDataKey`. In the S3 bucket policy in the Security account, allow `s3:PutObject` from the Production EC2 role. Attach an SCP to the Organization root that denies `s3:DeleteObject*` with a condition block specifying `"ArnNotEquals": {"aws:PrincipalArn": "arn:aws:iam::444455556666:role/SecurityAuditRole"}`.

Create a Customer Managed Key (CMK) in the Security account with automatic key rotation enabled. In the CMK key policy, grant the Production EC2 role permissions for `kms:GenerateDataKey`. Configure the S3 bucket policy in the Security account using a wildcard principal (`"Principal": "*"`) with an `"aws:PrincipalOrgID"` condition to allow write access, and omit the specific Production EC2 role ARN. Attach an SCP to the Organization root that denies `s3:DeleteObject*` with a condition block specifying `"ArnNotEquals": {"aws:PrincipalArn": "arn:aws:iam::444455556666:role/SecurityAuditRole"}`.

Show answer & explanation

Answer: Create a Customer Managed Key (CMK) in the Security account with automatic key rotation enabled. In the CMK key policy, grant the Production EC2 role permissions for `kms:GenerateDataKey`. In the S3 bucket policy in the Security account, allow `s3:PutObject` from the Production EC2 role. Attach an SCP to the Organization root that denies `s3:DeleteObject*` with a condition block specifying `"ArnNotEquals": {"aws:PrincipalArn": "arn:aws:iam::444455556666:role/SecurityAuditRole"}`.

Answer

Create a Customer Managed Key (CMK) in the Security account with automatic key rotation enabled, allowing the Production EC2 role only `kms:GenerateDataKey` permissions. Set the S3 bucket policy to allow the Production EC2 role `s3:PutObject` access, and deny deletion using an Organization-wide Service Control Policy (SCP) that exempts the central audit role.

The correct solution uses a Customer Managed Key (CMK) in the Security account with key rotation enabled, allowing the Production EC2 role to perform `kms:GenerateDataKey` (which allows encryption during upload) but withholding `kms:Decrypt` permissions. The S3 bucket policy explicitly allows the Production EC2 role to perform `s3:PutObject`. Finally, the SCP uses an `ArnNotEquals` condition to deny deletion for all users except the designated security audit role.

Step-by-Step Solution

Select the correct KMS key type for cross-account encryption.

Choose a Customer Managed Key (CMK) in the Security account instead of an AWS-managed key.

AWS-managed KMS keys (like `aws/s3`) cannot have their key policies modified and cannot be shared across accounts.

Configure the CMK key policy in the Security account.

Grant the Production EC2 role `kms:GenerateDataKey` but do not grant `kms:Decrypt`.

This allows the application to encrypt logs during upload but prevents it from reading or decrypting any existing logs.

Configure the S3 bucket policy in the Security account.

Explicitly allow the Production EC2 role ARN to perform `s3:PutObject`.

Cross-account S3 access requires explicit permissions in the resource-based policy of the receiving account.

Implement the data loss prevention control at the Organization level.

Create an SCP denying `s3:DeleteObject*` actions, with a condition block that excludes the `SecurityAuditRole` using `ArnNotEquals` against `aws:PrincipalArn`.

SCPs apply to all member accounts (including administrators) and are the correct way to enforce organization-wide boundaries.

Key Concept

Cross-account resource access control using resource-based policies combined with KMS Customer Managed Keys and Service Control Policies.

Estimated Time:3m 0s

Question 864Question →

A financial technology company is designing a new multi-region web application for electronic contract signatures. The application requires a Recovery Time Objective (RTO) of 15 minutes and a Recovery Point Objective (RPO) of 1 minute. The primary infrastructure is located in the eu-west-2 (London) region, and the disaster recovery (DR) region is eu-west-1 (Ireland). The application tier consists of Amazon EC2 instances in private subnets that must access the internet to download software updates and contact external identity validation APIs. The database layer uses Amazon Aurora PostgreSQL. A private DNS endpoint db.internal.contract.com is managed in a Route 53 Private Hosted Zone for database connection strings. Which configuration should a Solutions Architect recommend to meet these requirements with high availability?

Deploy an Aurora Global Database with the primary cluster in eu-west-2 and a secondary cluster in eu-west-1. Deploy the EC2 instances in Auto Scaling groups across multiple Availability Zones in both regions. Deploy a single NAT Gateway in one public subnet in eu-west-2 and a single NAT Gateway in eu-west-1 to route outbound traffic for all private subnets. Associate the Route 53 Private Hosted Zone with the VPCs in both regions. Configure Route 53 Failover routing for the public application endpoint.

Deploy an Aurora PostgreSQL cluster in eu-west-2 and schedule automated snapshots every 4 hours, copying them to eu-west-1. Deploy the EC2 instances in Auto Scaling groups in eu-west-2, and configure an AWS CloudFormation template to deploy the application stack in eu-west-1 during a disaster. Associate the Route 53 Private Hosted Zone with both VPCs. Configure Route 53 Failover routing for the public application endpoint.

Deploy an Aurora Global Database with the primary cluster in eu-west-2 and a secondary cluster in eu-west-1. Deploy the EC2 instances in Auto Scaling groups across multiple Availability Zones in both regions, with redundant NAT Gateways in each Availability Zone where private subnets are deployed. Associate the Route 53 Private Hosted Zone with the VPCs in both eu-west-2 and eu-west-1. Configure Route 53 Failover routing for the public application endpoint pointing to the Application Load Balancers in both regions.

Deploy an Aurora Global Database with the primary cluster in eu-west-2 and a secondary cluster in eu-west-1. Deploy the EC2 instances in Auto Scaling groups across multiple Availability Zones in both regions, with redundant NAT Gateways in each Availability Zone where private subnets are deployed. Associate the Route 53 Private Hosted Zone only with the VPC in eu-west-2. Configure Route 53 Failover routing for the public application endpoint pointing to the Application Load Balancers in both regions.

Show answer & explanation

Answer: Deploy an Aurora Global Database with the primary cluster in eu-west-2 and a secondary cluster in eu-west-1. Deploy the EC2 instances in Auto Scaling groups across multiple Availability Zones in both regions, with redundant NAT Gateways in each Availability Zone where private subnets are deployed. Associate the Route 53 Private Hosted Zone with the VPCs in both eu-west-2 and eu-west-1. Configure Route 53 Failover routing for the public application endpoint pointing to the Application Load Balancers in both regions.

Answer

The correct configuration is to deploy an Aurora Global Database, associate the Private Hosted Zone with the VPCs in both regions, deploy redundant NAT Gateways in each Availability Zone, and configure Route 53 Failover routing.

Deploying an Aurora Global Database ensures that data is continuously replicated across regions to satisfy the 1-minute RPO, while providing fast regional failovers to satisfy the 15-minute RTO. Redundant NAT Gateways across multiple Availability Zones in each region ensure that outbound internet connections remain available even during a single Availability Zone outage. Associating the Private Hosted Zone containing the database DNS endpoints with both VPCs ensures that the application tier in both the active and standby regions can resolve the database connection hostname.

Step-by-Step Solution

Evaluate target RTO and RPO against replication methods.

An RPO of 1 minute and RTO of 15 minutes require continuous cross-region database replication. Amazon Aurora Global Database provides physical replication with typical lag under 1 second, meeting the RPO, and cluster promotion within a minute, meeting the RTO.

Backup-and-restore strategies utilizing snapshots cannot meet low RPO targets and require longer restore operations that exceed the RTO.

Evaluate NAT Gateway configurations for high availability.

NAT Gateways must be deployed in each Availability Zone containing private subnets that require outbound internet connectivity.

Deploying a single NAT Gateway in an Availability Zone creates a single point of failure. If that Availability Zone fails, instances in other zones lose outbound connectivity.

Configure DNS resolution for the private database endpoint across regions.

Associate the Route 53 Private Hosted Zone with the VPCs in both the primary (eu-west-2) and secondary (eu-west-1) regions.

Without this cross-VPC association, the EC2 instances in the secondary region will not be able to resolve the database's custom private domain name during a disaster recovery scenario.

Key Concept

Cross-region database replication, Private Hosted Zone VPC association, and Availability Zone redundant NAT Gateways for disaster recovery design.

Question 865Question →

A logistics company is designing a hybrid network architecture to connect its on-premises inventory system with 12 spoke VPCs across three AWS accounts in the us-west-2 Region. The architecture must support dynamic routing, provide high availability with automatic failover, and minimize administrative overhead. The company has provisioned an AWS Direct Connect connection at a partner colocation facility.

Which TWO configurations must the solutions architect implement to establish this connectivity in accordance with AWS best practices? (Select TWO.)

Select all that apply

Deploy a centralized AWS Transit Gateway in a dedicated network services account, and use AWS Resource Access Manager (RAM) to share it with the spoke VPC accounts.

Create an AWS Direct Connect Gateway, attach it to the Transit Gateway using a Transit Gateway association, and configure a backup IPSec VPN connection from the on-premises router to the Transit Gateway.

Establish an AWS Direct Connect Gateway and attach it directly to all 12 spoke VPCs via Virtual Private Gateways (VGWs) to bypass the Transit Gateway.

Create a Route 53 Private Hosted Zone in the network services account and associate it only with a central Shared Services VPC to enable cross-account DNS resolution automatically for all spoke VPCs.

Deploy a single NAT Gateway in one Availability Zone of the network services account to route outbound internet traffic from all spoke VPCs.

Show answer & explanation

Answer: Deploy a centralized AWS Transit Gateway in a dedicated network services account, and use AWS Resource Access Manager (RAM) to share it with the spoke VPC accounts.; Create an AWS Direct Connect Gateway, attach it to the Transit Gateway using a Transit Gateway association, and configure a backup IPSec VPN connection from the on-premises router to the Transit Gateway.

Answer

The correct configurations are deploying a centralized AWS Transit Gateway in a dedicated network services account shared via AWS Resource Access Manager (RAM), and creating an AWS Direct Connect Gateway attached to the Transit Gateway with a backup VPN connection.

Deploying a centralized Transit Gateway and sharing it via AWS Resource Access Manager (RAM) establishes a scalable, hub-and-spoke architecture that simplifies routing across multiple accounts. Attaching the Transit Gateway to a Direct Connect Gateway routes the primary traffic over the Direct Connect connection, while configuring a backup VPN connection to the Transit Gateway provides highly available path redundancy with automatic failover.

Step-by-Step Solution

Select a hub-and-spoke topology to connect the 12 spoke VPCs across multiple accounts.

Deploy an AWS Transit Gateway in a central account and share it with the spoke accounts using AWS RAM.

This establishes a single point of connectivity for all VPCs, reducing administrative overhead and supporting scaling beyond the 10 VPC limit of Direct Connect Gateway.

Connect the on-premises system to the Transit Gateway using the primary and backup connections.

Attach the Transit Gateway to an AWS Direct Connect Gateway for the primary connection, and set up a backup Site-to-Site VPN directly to the Transit Gateway.

This ensures dynamic routing with failover capabilities between the high-speed Direct Connect and the backup VPN path.

Key Concept

Centralized hub-and-spoke networking using AWS Transit Gateway, AWS Direct Connect Gateway, and AWS RAM for multi-account hybrid environments.

Question 866Question →

A logistics company is launching a new real-time package tracking API. During holiday seasons, the API experiences sudden, massive spikes in traffic (increasing by $15$ -fold within $2$ minutes) as users refresh their dashboards. The backend reads tracking data from an Amazon Aurora PostgreSQL database. The system must maintain low read latency during these spikes without impacting database write performance. Which strategy should the solutions architect recommend to handle these spikes at both the load balancer and database layers?

Rely on the Application Load Balancer's (ALB) native automatic scaling to adjust to traffic surges, and deploy Amazon Aurora Replicas with Aurora Auto Scaling to distribute the query load.

Request Application Load Balancer (ALB) pre-warming from AWS Support prior to the holiday season, and deploy Amazon Aurora Replicas with Aurora Auto Scaling to distribute the query load.

Request Application Load Balancer (ALB) pre-warming from AWS Support prior to the holiday season, and configure an Amazon RDS PostgreSQL Multi-AZ deployment to route read-only query traffic to the standby replica.

Rely on the Application Load Balancer's (ALB) native automatic scaling to adjust to traffic surges, and configure an Amazon RDS PostgreSQL Multi-AZ deployment to route read-only query traffic to the standby replica.

Show answer & explanation

Answer: Request Application Load Balancer (ALB) pre-warming from AWS Support prior to the holiday season, and deploy Amazon Aurora Replicas with Aurora Auto Scaling to distribute the query load.

Answer

Request Application Load Balancer (ALB) pre-warming from AWS Support prior to the holiday season, and deploy Amazon Aurora Replicas with Aurora Auto Scaling to distribute the query load.

The correct strategy requires pre-warming the ALB to handle the immediate

15

-fold spike in traffic, combined with deploying Aurora Replicas and using Aurora Auto Scaling to handle the read query load without affecting the primary writer instance.

Step-by-Step Solution

Analyze the load balancer scaling characteristics.

Identify that the Application Load Balancer (ALB) scales in response to traffic over time but cannot handle an instantaneous

15

-fold spike within

2

minutes. AWS Support must pre-warm the ALB to prevent dropped connections.

Sudden traffic spikes exceed the normal rate of ALB scaling.

Analyze the database read scalability requirements.

Select Amazon Aurora Replicas with Aurora Auto Scaling to handle the increased read load, rather than relying on RDS Multi-AZ standbys which cannot serve traffic.

Aurora Replicas support read scaling and Aurora Auto Scaling dynamically adds and removes replicas as needed.

Key Concept

Scaling Application Load Balancers for flash traffic and scaling relational database reads using Aurora Replicas.

Question 867Question →

A logistics company is preparing to launch a real-time package tracking portal for a global shopping festival. The portal expects a sudden surge of up to $12\text{ million}$ tracking requests per minute from users during peak hours. Read queries checking package status account for $98\%$ of the database traffic. The architecture consists of an Application Load Balancer (ALB) routing requests to an Amazon Elastic Container Service (ECS) cluster running on AWS Fargate, backed by an Amazon RDS for MySQL database. Load testing reveals that the database CPU reaches $100\%$ utilization and the ALB drops incoming connections under the sudden surge of traffic.

Which two actions should the solutions architect take to optimize the performance and scalability of the architecture? (Select two.)

Select all that apply

Submit a support case to AWS to pre-warm the Application Load Balancer to the expected peak request rate.

Migrate the database to an Amazon Aurora MySQL DB cluster, deploy Aurora Replicas, and direct the read queries to the reader endpoint.

Configure the Application Load Balancer to automatically scale dynamically in response to the sudden connection spike without pre-warming.

Enable Multi-AZ deployment on the RDS for MySQL database and route the read queries to the standby DB instance.

Deploy an Amazon ElastiCache for Memcached cluster in a Multi-AZ replication configuration to cache package status.

Show answer & explanation

Answer: Submit a support case to AWS to pre-warm the Application Load Balancer to the expected peak request rate.; Migrate the database to an Amazon Aurora MySQL DB cluster, deploy Aurora Replicas, and direct the read queries to the reader endpoint.

Answer

Submit a support case to AWS to pre-warm the Application Load Balancer to the expected peak request rate, and migrate the database to an Amazon Aurora MySQL DB cluster, deploying Aurora Replicas to handle read queries via the reader endpoint.

Pre-warming the Application Load Balancer prepares the load balancer to handle sudden connection spikes without dropping requests. Migrating the database to Amazon Aurora MySQL and using Aurora Replicas allows the application to scale read operations horizontally by offloading read queries to the reader endpoint.

Step-by-Step Solution

Address the load balancer bottleneck for sudden traffic surges.

Determine that the Application Load Balancer must be pre-warmed by AWS Support to handle the immediate peak rate of

12\text{ million}

requests per minute without dropping connections.

Dynamic scaling of the load balancer is too slow to react to near-instantaneous bursts of this scale.

Scale the database tier to handle the read-heavy workload.

Select Amazon Aurora MySQL with read replicas to distribute the

98\%

read traffic horizontally.

Aurora read replicas can serve read traffic via the reader endpoint, unlike Amazon RDS Multi-AZ standby instances which do not accept read traffic.

Evaluate caching options for high availability.

Reject ElastiCache for Memcached for Multi-AZ replication requirements.

Memcached does not support Multi-AZ replication or clustering for failover; Redis is the correct choice if caching is implemented with Multi-AZ.

Key Concept

Handling sudden massive spikes in network connection and database read loads by pre-warming application load balancers and horizontally scaling read-heavy relational databases using replicas.

Question 868Question →

A global company is setting up federated access to multiple member accounts in an AWS Organization using an external SAML 2.0 Identity Provider (IdP) and AWS IAM Identity Center (AWS Single Sign-On). The solutions architect must automate user provisioning from the external IdP to AWS IAM Identity Center and configure attribute-based access control (ABAC) using the department user attribute. Which TWO configurations must the solutions architect implement to meet these requirements? (Select TWO.)

Select all that apply

Enable automatic provisioning in AWS IAM Identity Center and configure SCIM synchronization from the external Identity Provider to synchronize user identities and attributes.

Configure the identity source in AWS IAM Identity Center to use the external SAML IdP, and configure permission sets to utilize the aws:PrincipalTag/department key in the IAM policy condition elements.

Create a Service Control Policy (SCP) at the root of the organization that defines the mapping between SAML attributes and AWS resource tags to automatically grant permissions across all accounts.

Manually create an IAM role in each member account with a trust policy that permits the sts:AssumeRole action with the SAML IdP as the principal.

Configure an IAM OpenID Connect (OIDC) identity provider in the organization management account and use the sts:AssumeRoleWithWebIdentity action in the trust policies of the roles in the member accounts.

Show answer & explanation

Answer: Enable automatic provisioning in AWS IAM Identity Center and configure SCIM synchronization from the external Identity Provider to synchronize user identities and attributes.; Configure the identity source in AWS IAM Identity Center to use the external SAML IdP, and configure permission sets to utilize the aws:PrincipalTag/department key in the IAM policy condition elements.

Answer

Configure automatic provisioning via SCIM from the external Identity Provider to AWS IAM Identity Center, and configure permission sets in AWS IAM Identity Center to use the department attribute passed in the principal tag (aws:PrincipalTag/department) for attribute-based access control.

The correct solution involves configuring SAML federation in AWS IAM Identity Center and setting up SCIM (System for Cross-domain Identity Management) synchronization from the external IdP to automate user provisioning. Once user attributes like department are synchronized, they can be utilized as principal tags (aws:PrincipalTag/department) in the IAM policy conditions of IAM Identity Center permission sets to enforce attribute-based access control (ABAC).

Step-by-Step Solution

Set up SAML 2.0 federation and user provisioning in AWS IAM Identity Center.

AWS IAM Identity Center is configured to use the external SAML IdP as its identity source, and System for Cross-domain Identity Management (SCIM) is enabled to synchronize users, groups, and attributes automatically.

SCIM is the industry standard for automating user provisioning and metadata synchronization (such as user attributes) from external directory sources to AWS IAM Identity Center.

Enable Attribute-Based Access Control (ABAC) in AWS IAM Identity Center.

The department attribute synced from the IdP is mapped as a principal tag for access control, making it available as aws:PrincipalTag/department during authorization.

AWS IAM Identity Center supports using attributes passed from the identity provider as principal tags in IAM policies to implement dynamic access control.

Configure permission sets in AWS IAM Identity Center with attribute-based conditions.

Permission sets are created with IAM policy conditions that compare the principal's department tag to resource tags (e.g., aws:ResourceTag/department).

This allows a single permission set to dynamically grant access to resources matching the user's department without creating separate permission sets or roles for each department.

Key Concept

AWS IAM Identity Center supports SAML 2.0 federation and automatic user provisioning via SCIM. By enabling the attributes for access control feature, user attributes synced via SCIM are passed as session tags (aws:PrincipalTag) in AWS security tokens, enabling dynamic attribute-based access control (ABAC) across member accounts.

Estimated Time:2m 0s

Question 869Question →

An enterprise is designing a new cloud infrastructure on AWS. The design consists of a central Shared Services VPC and two spoke VPCs (Spoke-A and Spoke-B) in the `us-east-1` Region, all connected via an AWS Transit Gateway. The application servers in the spoke VPCs must resolve internal domain names registered in a Route 53 Private Hosted Zone (`corp.internal`) that is hosted in the Shared Services AWS account. Additionally, all spoke VPCs must route outbound internet traffic through the Shared Services VPC, which must be highly resilient against an Availability Zone outage.

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

Select all that apply

Associate the Route 53 Private Hosted Zone `corp.internal` with both Spoke-A VPC and Spoke-B VPC.

Deploy a NAT Gateway in each Availability Zone of the Shared Services VPC, and route outbound traffic from each private subnet to its corresponding local NAT Gateway.

Configure a single Direct Connect Gateway to establish transitive routing for internet-bound traffic from the spoke VPCs to the Shared Services VPC.

Rely on the AWS Transit Gateway to automatically propagate DNS records from the `corp.internal` Private Hosted Zone to all attached spoke VPCs without manual VPC association.

Deploy a single NAT Gateway in the Shared Services VPC to reduce cost, and point the default route `0.0.0.0/0` of all subnets across all Availability Zones to this single NAT Gateway.

Show answer & explanation

Answer: Associate the Route 53 Private Hosted Zone `corp.internal` with both Spoke-A VPC and Spoke-B VPC.; Deploy a NAT Gateway in each Availability Zone of the Shared Services VPC, and route outbound traffic from each private subnet to its corresponding local NAT Gateway.

Answer

Associate the Route 53 Private Hosted Zone with the spoke VPCs, and deploy a NAT Gateway in each Availability Zone of the Shared Services VPC.

To satisfy the requirements, the solutions architect must configure Route 53 Private Hosted Zone associations and highly available NAT Gateways. First, the Private Hosted Zone `corp.internal` must be associated with both spoke VPCs to allow Route 53 to resolve internal domain names within those networks. Second, deploying a NAT Gateway in each Availability Zone of the Shared Services VPC ensures that outbound traffic routes to a local gateway, eliminating cross-AZ dependencies and ensuring high availability during an Availability Zone outage.

Step-by-Step Solution

Associate the Private Hosted Zone `corp.internal` in the Shared Services account with the spoke VPCs (Spoke-A and Spoke-B).

DNS queries for the `corp.internal` domain originating from the spoke VPCs can be resolved by AWS Route 53 resolver endpoints.

By default, a Private Hosted Zone is only accessible within the VPCs to which it is explicitly associated.

Deploy multiple NAT Gateways, one in each public subnet across the Availability Zones in the Shared Services VPC.

Availability Zone redundancy is established for outbound traffic, ensuring no single AZ outage disrupts internet egress for the entire VPC mesh.

A single NAT Gateway deployment introduces an AZ-level single point of failure.

Configure the route tables in the private subnets of the Shared Services VPC to route outbound traffic to their local NAT Gateways, and configure Transit Gateway route tables to route spoke VPC egress traffic to the Shared Services VPC.

Outbound traffic from all spoke VPCs is routed to the Shared Services VPC and egresses highly available NAT Gateways.

This establishes the complete end-to-end egress path through Transit Gateway and ensures AZ-independent routing paths.

Key Concept

Multi-VPC DNS resolution with Private Hosted Zones and highly available centralized egress architecture using AWS Transit Gateway and NAT Gateways.

Estimated Time:2m 0s

Question 870Question →

An enterprise is migrating its multi-account identity strategy to AWS IAM Identity Center to centralize user access management. The security team wants to ensure that all human user access to member accounts is routed exclusively through IAM Identity Center. They must prevent administrators in member accounts from establishing or using direct SAML 2.0 or OpenID Connect (OIDC) federation bypasses directly to their individual accounts. The solution must not impact normal cross-account IAM role assumption used by internal applications and AWS services. Which approach should the solutions architect implement to meet these requirements with the least administrative overhead?

Apply a Service Control Policy (SCP) at the Organization root that denies the sts:AssumeRoleWithSAML and sts:AssumeRoleWithWebIdentity actions.

Apply a Service Control Policy (SCP) to all member account OUs that explicitly allows sts:AssumeRole for the sso.amazonaws.com principal, which implicitly denies all other STS actions across the organization.

Configure the trust policies of all IAM roles in the member accounts to use the sts:AssumeRole action and restrict the principal to the central IAM Identity Center SAML provider ARN.

Apply a Service Control Policy (SCP) at the Organization root that denies the sts:AssumeRole action for all non-administrative sessions, forcing all federation to use sts:AssumeRoleWithSAML managed by IAM Identity Center.

Show answer & explanation

Answer: Apply a Service Control Policy (SCP) at the Organization root that denies the sts:AssumeRoleWithSAML and sts:AssumeRoleWithWebIdentity actions.

Answer

Apply a Service Control Policy (SCP) at the Organization root that denies the sts:AssumeRoleWithSAML and sts:AssumeRoleWithWebIdentity actions.

The correct option is correct because direct SAML 2.0 and OIDC federation depend on the 'sts:AssumeRoleWithSAML' and 'sts:AssumeRoleWithWebIdentity' actions respectively. Denying these actions in a Service Control Policy (SCP) at the Organization root prevents any direct federation bypasses from being established or used in member accounts. Because AWS IAM Identity Center uses service-controlled roles assumed via 'sso.amazonaws.com' using the standard 'sts:AssumeRole' action, it remains fully functional, as does normal cross-account role assumption.

Step-by-Step Solution

Analyze how direct federation and AWS IAM Identity Center authenticate to member accounts.

Direct SAML federation uses sts:AssumeRoleWithSAML, direct OIDC uses sts:AssumeRoleWithWebIdentity, and AWS IAM Identity Center uses sts:AssumeRole via the sso.amazonaws.com service principal.

Understanding the specific STS actions used by each access method is necessary to target the correct actions for restriction without disrupting legitimate traffic.

Determine the effect of Service Control Policies (SCPs) on these actions.

SCPs act as guardrails. An explicit deny of sts:AssumeRoleWithSAML and sts:AssumeRoleWithWebIdentity at the Organization root will prevent anyone in member accounts from using direct federation.

Using an explicit deny in an SCP is the most effective and centralized way to enforce this security guardrail across all member accounts with minimal administrative overhead.

Verify that normal operations are not impacted by the SCP restrictions.

Normal cross-account role assumption and IAM Identity Center federation rely on the sts:AssumeRole action, which remains allowed under the proposed SCP.

Ensures that application integration and the desired central identity solution function correctly while achieving the security objective.

Key Concept

Multi-Account Identity Federation Security Guardrails

Question 871Question →

A logistics corporation manages $30$ AWS accounts under a single organization in AWS Organizations. The security team needs to implement centralized aggregation of VPC Flow Logs from all VPCs in all member accounts into a single, highly secure Amazon S3 bucket located in a dedicated Security account. The solution must ensure that log transmission is encrypted in transit and at rest using a Customer Managed Key (CMK) in AWS Key Management Service (AWS KMS), and that member accounts cannot delete or modify the centralized logs or the logging configurations. Which TWO configurations must the solutions architect implement to achieve these requirements?

Select all that apply

Create an Amazon S3 bucket in the Security account. Configure the S3 bucket policy to allow the delivery.logs.amazonaws.com service principal to perform s3:PutObject operations.

Create a customer managed key (CMK) in the Security account. Configure the KMS key policy to grant the delivery.logs.amazonaws.com service principal permission to perform kms:GenerateDataKey operations, and enable S3 Bucket Key on the destination S3 bucket.

Configure the VPC Flow Logs in the member accounts to encrypt the logs at rest using the AWS-managed key for Amazon S3 (aws/s3) located in the Security account.

Create an S3 bucket policy in the Security account that grants write access to the AWSServiceRoleForVPCDelivery service-linked role from each member account.

Apply a Service Control Policy (SCP) at the Organization root that grants s3:PutObject and kms:GenerateDataKey permissions to the member accounts to authorize log delivery to the Security account.

Show answer & explanation

Answer: Create an Amazon S3 bucket in the Security account. Configure the S3 bucket policy to allow the delivery.logs.amazonaws.com service principal to perform s3:PutObject operations.; Create a customer managed key (CMK) in the Security account. Configure the KMS key policy to grant the delivery.logs.amazonaws.com service principal permission to perform kms:GenerateDataKey operations, and enable S3 Bucket Key on the destination S3 bucket.

Answer

Create an S3 bucket in the Security account and configure its bucket policy to allow the delivery.logs.amazonaws.com service principal to perform s3:PutObject operations, and create a customer managed key in the Security account with a policy that allows the delivery.logs.amazonaws.com service principal to perform kms:GenerateDataKey operations.

Centralized VPC Flow Logs delivery to S3 requires S3 bucket policies to allow the delivery.logs.amazonaws.com service principal to write objects. If encryption is required using a Customer Managed Key, the key policy must also authorize the delivery.logs.amazonaws.com service principal to generate data keys.

Step-by-Step Solution

Configure the S3 bucket policy in the destination Security account.

Allows the VPC Flow Logs service principal (delivery.logs.amazonaws.com) to write log objects into the bucket.

Since the logs are delivered across accounts, resource-based policies must authorize the delivery service principal.

Configure a Customer Managed Key (CMK) in the Security account with a key policy authorizing the delivery service.

Enables the delivery.logs.amazonaws.com service principal to request data keys (kms:GenerateDataKey) to encrypt objects delivered to S3.

AWS-managed keys cannot be shared cross-account or configured with custom resource policies to authorize external service principals.

Key Concept

Cross-account centralized VPC Flow Logs delivery requires configuring S3 bucket policies and Customer Managed KMS key policies to authorize the delivery.logs.amazonaws.com service principal.

Estimated Time:1m 30s

Question 872Question →

A healthcare organization is designing a telemetry processing system. An ingestion application running on Amazon EC2 instances in an Ingestion account (Account ID $222233334444$ ) must write sensitive telemetry data to an Amazon S3 bucket located in a dedicated Audit account (Account ID $555566667777$ ). The organization's compliance policy requires all data to be encrypted at rest using a key managed by the security team. The solutions architect must configure the cross-account permissions and encryption controls to allow this transmission. Which two actions must the solutions architect take to meet these requirements? (Select TWO.)

Select all that apply

Create a Customer Managed Key (CMK) in AWS KMS within the Audit account. Configure the KMS key policy in the Audit account to allow the Ingestion account's IAM role to perform kms:GenerateDataKey and kms:Decrypt operations.

Configure the S3 bucket policy in the Audit account to grant s3:PutObject permissions to the specific IAM role ARN from the Ingestion account.

Configure the S3 bucket in the Audit account to use the AWS-managed KMS key for Amazon S3 (aws/s3), and modify its key policy to grant the Ingestion account's IAM role kms:GenerateDataKey permissions.

Attach a Service Control Policy (SCP) at the Organization Unit (OU) level containing both accounts that grants s3:PutObject permissions to the Ingestion account's IAM role for the destination S3 bucket.

Configure the S3 bucket policy in the Audit account to grant s3:PutObject permissions using a wildcard principal (Principal: "*") without specifying any organizational conditions or principal AWS account IDs.

Show answer & explanation

Answer: Create a Customer Managed Key (CMK) in AWS KMS within the Audit account. Configure the KMS key policy in the Audit account to allow the Ingestion account's IAM role to perform kms:GenerateDataKey and kms:Decrypt operations.; Configure the S3 bucket policy in the Audit account to grant s3:PutObject permissions to the specific IAM role ARN from the Ingestion account.

Answer

Create a Customer Managed Key (CMK) in AWS KMS within the Audit account, configure its policy to allow the Ingestion account's IAM role to perform kms:GenerateDataKey and kms:Decrypt operations, and configure the S3 bucket policy in the Audit account to grant s3:PutObject permissions to the specific IAM role ARN from the Ingestion account.

The correct options are configuring a Customer Managed Key (CMK) in the Audit account with a policy allowing the Ingestion account's IAM role to perform kms:GenerateDataKey and kms:Decrypt, and configuring the S3 bucket policy in the Audit account to grant s3:PutObject permissions to the Ingestion account's IAM role. This combination ensures that the ingestion application has both S3 write permissions and KMS key permissions to encrypt and upload objects securely across accounts using a Customer Managed Key, which is required since AWS-managed KMS keys do not support policy modification.

Step-by-Step Solution

Determine key management strategy for cross-account S3 uploads.

AWS-managed KMS keys cannot be used because they do not support cross-account access. A Customer Managed Key (CMK) is created in the Audit account.

Only Customer Managed Keys support policy edits required to allow cross-account access.

Configure the KMS key policy in the Audit account.

Update the key policy to grant the Ingestion account's IAM role permissions for kms:GenerateDataKey and kms:Decrypt.

The ingestion application needs kms:GenerateDataKey to encrypt the object during upload, and kms:Decrypt is required for multipart uploads and validation.

Configure the destination S3 bucket policy.

Apply a bucket policy in the Audit account granting s3:PutObject to the Ingestion account's IAM role.

S3 cross-account access requires explicit permission in the resource-based policy of the receiving account.

Key Concept

Cross-account KMS key and S3 bucket policy configuration

Question 873Question →

A logistics company is designing a new multi-region web application on AWS for real-time fleet tracking. The application must run in two AWS Regions: us-east-1 (Primary) and us-west-2 (Secondary). The business requires a Recovery Time Objective (RTO) of 15 minutes and a Recovery Point Objective (RPO) of 1 minute. The architecture must minimize ongoing running costs in the secondary region while ensuring that outbound APIs (e.g., to external GPS telemetry providers) remain highly available within the primary region.

Which architecture meets these requirements?

Deploy the application in us-east-1 using Application Load Balancers (ALBs) and Auto Scaling Groups (ASGs). Configure a cross-region backup strategy using AWS Backup to copy EBS snapshots and Aurora database snapshots from us-east-1 to us-west-2 once every 24 hours. In the event of a regional disaster in us-east-1, use AWS CloudFormation to deploy the ALBs and ASGs in us-west-2, restore the Aurora database from the copied snapshots, and update Route 53 simple routing records to point to the new load balancer.

Deploy the application in us-east-1 (Primary) and us-west-2 (Secondary) using Application Load Balancers (ALBs) and Auto Scaling Groups (ASGs). Set up Amazon Aurora Global Database with the primary writer in us-east-1 and a secondary read replica in us-west-2. Configure Route 53 with Failover routing policies pointing to the ALBs in both regions, and associate Route 53 health checks with the primary ALB. To minimize running costs, deploy a single NAT Gateway in one Availability Zone in the primary region's VPC, routing all outbound API traffic from private subnets across all Availability Zones through it.

Deploy the application in us-east-1 (Primary) and us-west-2 (Secondary) using Application Load Balancers (ALBs) and Auto Scaling Groups (ASGs). Set up Amazon Aurora Global Database with the primary writer in us-east-1 and a secondary read replica in us-west-2. In us-west-2, set the ASG capacity to minimum scale to reduce standby costs. Configure Route 53 with Failover routing policies pointing to the ALBs in both regions, and associate Route 53 health checks with the primary ALB. Ensure the primary VPC has redundant NAT Gateways deployed across multiple Availability Zones for outbound API connectivity.

Deploy the application in us-east-1 (Primary) and us-west-2 (Secondary) using Application Load Balancers (ALBs) and Auto Scaling Groups (ASGs). Set up Amazon Aurora Global Database with the primary writer in us-east-1 and a secondary read replica in us-west-2. Configure Route 53 with Latency routing policies pointing to the ALBs in both regions, and enable health checks on both endpoints. In the event of a regional outage in us-east-1, Route 53 Latency routing will automatically promote the secondary database cluster in us-west-2 to a writer and redirect all write traffic without operational intervention.

Show answer & explanation

Answer: Deploy the application in us-east-1 (Primary) and us-west-2 (Secondary) using Application Load Balancers (ALBs) and Auto Scaling Groups (ASGs). Set up Amazon Aurora Global Database with the primary writer in us-east-1 and a secondary read replica in us-west-2. In us-west-2, set the ASG capacity to minimum scale to reduce standby costs. Configure Route 53 with Failover routing policies pointing to the ALBs in both regions, and associate Route 53 health checks with the primary ALB. Ensure the primary VPC has redundant NAT Gateways deployed across multiple Availability Zones for outbound API connectivity.

Answer

Deploying the application in both regions, using Amazon Aurora Global Database for sub-minute data replication, configuring Route 53 Failover routing, running the secondary Auto Scaling Group at minimal scale, and provisioning redundant NAT Gateways across multiple Availability Zones in the primary region.

The correct architecture uses Route 53 Failover routing to direct traffic to the primary region (us-east-1) under normal operation and failover to the secondary region (us-west-2) during an outage. Aurora Global Database provides sub-minute replication to meet the 1-minute RPO. Outbound API high availability is maintained in the primary region by deploying redundant NAT Gateways across multiple Availability Zones. Running the secondary Application Auto Scaling Group at minimal scale satisfies the cost optimization constraint while remaining ready to scale up upon failover.

Step-by-Step Solution

Assess database replication requirements for the RPO of 1 minute.

Choose Amazon Aurora Global Database, which offers cross-region replication lag of typically less than 1 second.

Traditional backup and restore methods from snapshots cannot meet the 1-minute RPO constraint.

Assess DNS routing and region management for the active-passive cost constraint.

Configure Route 53 Failover routing to direct all traffic to us-east-1 and failover to us-west-2, keeping the secondary region's Auto Scaling Group at minimal scale to save costs.

Latency routing would active-active route traffic, necessitating active servers in both regions and increasing costs, while Route 53 also cannot promote the database automatically.

Design outbound NAT redundancy in the primary VPC.

Deploy one NAT Gateway per Availability Zone in the public subnets of us-east-1.

A single NAT Gateway creates a single point of failure; if the zone hosting the NAT Gateway goes down, all private subnets lose outbound internet connectivity.

Key Concept

Multi-Region Active-Passive (Warm Standby) disaster recovery with Route 53 Failover, Aurora Global Database, and high availability NAT Gateway design.

Question 874Question →

A global logistics corporation uses AWS Organizations with multiple member accounts. Security analysts must authenticate using the company's on-premises SAML 2.0 Identity Provider (IdP) to assume an IAM role named SecurityAuditorRole in a centralized Identity account ( $111122223333$ ). From this role, the analysts run query analyses using Amazon Athena on regulatory compliance logs stored in an Amazon S3 bucket within a separate Security Logging account ( $444455556666$ ). The S3 bucket requires all objects to be encrypted at rest using server-side encryption with AWS KMS (SSE-KMS). Which combination of configurations must a solutions architect implement to securely grant the security analysts the access required to retrieve and decrypt the logs?

In the Identity account, configure the trust policy of SecurityAuditorRole to allow the sts:AssumeRole action from the SAML provider. Attach an IAM policy to SecurityAuditorRole that allows s3:GetObject on the S3 bucket and kms:Decrypt on a Customer Managed Key (CMK) in the Security Logging account. In the Security Logging account, configure the S3 bucket policy to allow s3:GetObject for the SecurityAuditorRole ARN, and configure the CMK's key policy to allow kms:Decrypt for the SecurityAuditorRole ARN.

In the Identity account, configure the trust policy of SecurityAuditorRole to allow the sts:AssumeRoleWithSAML action from the SAML provider. Attach an IAM policy to SecurityAuditorRole that allows s3:GetObject on the S3 bucket and kms:Decrypt on the AWS managed key (aws/s3) in the Security Logging account. In the Security Logging account, configure the S3 bucket policy to allow s3:GetObject for the SecurityAuditorRole ARN.

In the Identity account, configure the trust policy of SecurityAuditorRole to allow the sts:AssumeRoleWithSAML action from the SAML provider. Attach an IAM policy to SecurityAuditorRole that allows s3:GetObject on the S3 bucket and kms:Decrypt on a Customer Managed Key (CMK) in the Security Logging account. In the Security Logging account, configure the S3 bucket policy to allow s3:GetObject for the SecurityAuditorRole ARN, and configure the CMK's key policy to allow kms:Decrypt for the SecurityAuditorRole ARN.

In the Identity account, configure the trust policy of SecurityAuditorRole to allow the sts:AssumeRoleWithSAML action from the SAML provider. In the AWS Organizations management account, attach a Service Control Policy (SCP) to the Organizational Unit (OU) containing both accounts that explicitly permits the SecurityAuditorRole ARN to perform s3:GetObject on the S3 bucket and kms:Decrypt on the KMS key in the Security Logging account.

Show answer & explanation

Answer: In the Identity account, configure the trust policy of SecurityAuditorRole to allow the sts:AssumeRoleWithSAML action from the SAML provider. Attach an IAM policy to SecurityAuditorRole that allows s3:GetObject on the S3 bucket and kms:Decrypt on a Customer Managed Key (CMK) in the Security Logging account. In the Security Logging account, configure the S3 bucket policy to allow s3:GetObject for the SecurityAuditorRole ARN, and configure the CMK's key policy to allow kms:Decrypt for the SecurityAuditorRole ARN.

Answer

In the Identity account, configure the trust policy of SecurityAuditorRole to allow the sts:AssumeRoleWithSAML action from the SAML provider. Attach an IAM policy to SecurityAuditorRole that allows s3:GetObject on the S3 bucket and kms:Decrypt on a Customer Managed Key (CMK) in the Security Logging account. In the Security Logging account, configure the S3 bucket policy to allow s3:GetObject for the SecurityAuditorRole ARN, and configure the CMK's key policy to allow kms:Decrypt for the SecurityAuditorRole ARN.

The correct configuration uses the sts:AssumeRoleWithSAML action in the IAM role's trust policy to support federation from the SAML IdP. It encrypts the target S3 bucket with a Customer Managed Key (CMK) to allow modification of its key policy. It then configures cross-account access by granting outbound permissions in the source IAM role policy and inbound permissions in both the target S3 bucket policy and the target KMS key policy.

Step-by-Step Solution

Configure SAML 2.0 federation trust policy for the IAM role.

The SecurityAuditorRole trust policy is set to allow the sts:AssumeRoleWithSAML action for the SAML identity provider in the Identity account (

111122223333

SAML federation requires the sts:AssumeRoleWithSAML API action to exchange SAML assertions for temporary AWS security credentials.

Define encryption using a Customer Managed Key (CMK) in the destination account.

The S3 bucket in the Security Logging account (

444455556666

) is encrypted using a Customer Managed Key (CMK) instead of the default AWS managed key.

AWS managed keys (such as aws/s3) have fixed key policies that cannot be modified to permit access from external accounts. A Customer Managed Key must be used for cross-account decryption.

Grant outbound permissions to the federated IAM role.

Attach an IAM policy to the SecurityAuditorRole in the Identity account allowing s3:GetObject on the S3 bucket ARN and kms:Decrypt on the CMK ARN.

The IAM role must have explicit permission to retrieve objects and perform decrypt operations on the remote KMS key.

Grant inbound permissions in the resource policies of the destination account.

Update the S3 bucket policy to allow s3:GetObject for the SecurityAuditorRole ARN, and update the KMS key policy to allow kms:Decrypt for the SecurityAuditorRole ARN.

For cross-account access, both the IAM policy in the source account and the resource policies (S3 bucket policy and KMS key policy) in the target account must explicitly permit the access.

Key Concept

Cross-account access delegation with SAML federation and custom KMS key policies

Question 875Question →

A retail company wants to share daily transaction logs stored in an Amazon S3 bucket in Account A ( $111111111111$ ) with an analytics application running on Amazon EC2 instances in Account B ( $222222222222$ ). The S3 bucket is configured with default encryption using AWS Key Management Service (AWS KMS). Which of the following describes a mandatory configuration for the KMS key to allow the analytics application in Account B to decrypt the log files?

A customer managed KMS key must be used, and its key policy in Account A must explicitly grant the analytics application's role in Account B permission to use the key.

The default AWS managed KMS key (aws/s3) can be used, provided that a Service Control Policy (SCP) is applied at the organization level to permit cross-account decryption.

The default AWS managed KMS key (aws/s3) can be used, as long as Account B attaches an IAM policy to the EC2 instance role that grants the kms:Decrypt permission.

A customer managed KMS key must be used, and it must be shared with Account B using AWS Resource Access Manager (RAM) to delegate access.

Show answer & explanation

Answer: A customer managed KMS key must be used, and its key policy in Account A must explicitly grant the analytics application's role in Account B permission to use the key.

Answer

A customer managed KMS key must be used, and its key policy in Account A must explicitly grant the analytics application's role in Account B permission to use the key.

To decrypt resources across different AWS accounts, the KMS key must support policy modification. AWS managed KMS keys (such as aws/s3) have fixed policies that cannot be altered to grant cross-account access. Therefore, a customer managed KMS key must be utilized. Its key policy must be updated to explicitly grant the decryption permissions to Account B's IAM role.

Step-by-Step Solution

Determine the type of AWS KMS key being used.

Identify that default S3 encryption often uses AWS managed keys (aws/s3), but these cannot be shared cross-account.

AWS managed KMS keys do not support editing key policies, which is required to delegate permissions to a different account.

Configure a customer managed KMS key.

Create a customer managed key in Account A and configure S3 to use it.

Customer managed keys allow their key policies to be edited to grant cross-account permissions.

Modify the customer managed KMS key policy.

Add a statement to the key policy in Account A that lists the ARN of the analytics IAM role in Account B as a principal and grants kms:Decrypt permissions.

Cross-account access to KMS keys requires explicit trust configuration in the key policy itself, as IAM policies in Account B alone cannot grant access to Account A's resources.

Key Concept

Cross-account access to KMS-encrypted resources requires customer managed keys and explicit key policy delegation.

Estimated Time:1m 30s

Question 876Question →

A global digital publishing platform is designing a highly available, multi-region architecture to host its core subscription system on AWS. The primary environment is deployed in the us-east-1 Region, and the secondary disaster recovery (DR) environment is in the us-west-2 Region. The business requires a Recovery Time Objective (RTO) of 15 minutes and a Recovery Point Objective (RPO) of 1 minute, while minimizing active compute costs and management overhead. The database layer utilizes Amazon Aurora PostgreSQL. The application must support outbound connections to external validation services that remain resilient during Availability Zone (AZ) outages in either Region. Furthermore, internal containerized microservices in both Regions must resolve private DNS names across the peered VPCs. Which combination of actions should the Solutions Architect take to meet these requirements? (Select TWO.)

Select all that apply

Configure an Amazon Aurora Global Database with the primary cluster in us-east-1 and a secondary cluster in us-west-2. Associate the Route 53 Private Hosted Zones containing internal microservice endpoints with the VPCs in both Regions.

Deploy a NAT Gateway in each Availability Zone within the public subnets of both Regions, and configure the route tables of the private subnets to route outbound traffic through the local NAT Gateway in their respective Availability Zone.

Configure a daily snapshot backup policy for Amazon RDS for PostgreSQL in us-east-1, copy the snapshots to us-west-2 using AWS Backup, and restore the database from the snapshot in us-west-2 during failover to minimize active database costs.

Configure Route 53 Private Hosted Zones in us-east-1 and rely on a shared Transit Gateway to automatically route and resolve DNS queries from the us-west-2 VPC without explicitly associating the host zone with the secondary VPC.

Deploy a single NAT Gateway in one public subnet per Region to minimize NAT Gateway hourly costs, and update the route tables of all private subnets across all Availability Zones in that Region to use this single NAT Gateway.

Enable Amazon Aurora Replica Auto Scaling on the reader nodes within the us-west-2 secondary cluster to dynamically scale and automatically accept write operations during a primary Region degradation.

Show answer & explanation

Answer: Configure an Amazon Aurora Global Database with the primary cluster in us-east-1 and a secondary cluster in us-west-2. Associate the Route 53 Private Hosted Zones containing internal microservice endpoints with the VPCs in both Regions.; Deploy a NAT Gateway in each Availability Zone within the public subnets of both Regions, and configure the route tables of the private subnets to route outbound traffic through the local NAT Gateway in their respective Availability Zone.

Answer

Configuring Amazon Aurora Global Database for sub-second database replication and associating Route 53 Private Hosted Zones with all peer VPCs, combined with deploying a NAT Gateway in each Availability Zone in both Regions to ensure highly available outbound connections.

The configuration containing Amazon Aurora Global Database handles database tier high availability and meets the 1-minute RPO because replication lag is measured in sub-seconds. Associating the Route 53 Private Hosted Zones directly with all VPCs in both Regions resolves cross-region private DNS query needs. Deploying a separate NAT Gateway in each public subnet per Availability Zone guarantees that a single zone outage does not compromise internet-bound traffic from private resources residing in other zones.

Step-by-Step Solution

Analyze the database RTO and RPO requirements to choose the correct storage replication tier.

An Amazon Aurora Global Database is chosen because it replicates database updates to the secondary Region with a lag of less than 1 second, fulfilling the 1-minute RPO, whereas snapshot-based approaches fail this constraint.

To ensure replication lag remains within the required bounds during peak write loads.

Establish private DNS resolution across peered VPCs in different AWS Regions.

The Route 53 Private Hosted Zones containing internal microservice endpoints are associated with both the primary and secondary VPCs.

To allow internal container instances in both VPCs to resolve cross-region private endpoints without routing queries over public DNS resolvers.

Design outbound internet connectivity for private subnets that survives Availability Zone failures.

A NAT Gateway is deployed in each Availability Zone's public subnet, and route tables for private subnets are updated to target their zone-specific NAT Gateway.

Deploying a single NAT Gateway creates a single point of failure, whereas zone-specific NAT Gateways ensure high availability for outbound traffic.

Key Concept

Multi-region high availability and disaster recovery planning, combining Aurora Global Database replication, cross-VPC private DNS resolution, and redundant zone-specific NAT gateways.

Estimated Time:3m 0s

Question 877Question →

A company is designing a deployment strategy for a stateful ingestion service running on Amazon EC2 instances within an Auto Scaling group (ASG) behind an Application Load Balancer (ALB). The service maintains long-lived WebSockets connections with millions of IoT devices. The deployment of application updates must satisfy three requirements: first, existing WebSockets connections must not be prematurely terminated and must drain naturally for up to 15 minutes; second, the maximum temporary capacity increase must not exceed 25% of the current fleet size due to strict IP address space constraints in the VPC subnets; and third, the deployment must automatically roll back if the system error rate exceeds 2% during a 30-minute validation period post-deployment. Which deployment configuration will meet these requirements?

Configure the Application Load Balancer target group deregistration delay to 900 seconds. Perform an Auto Scaling group Instance Refresh with the minimum healthy percentage set to 100%, and configure the instance refresh rollback preferences to monitor a CloudWatch alarm that tracks the system error rate, triggering an automatic rollback if the error rate exceeds 2%.

Use AWS CodeDeploy to perform a Blue/Green deployment. Set the target group deregistration delay to 900 seconds, create a new target group and Auto Scaling group, and configure a CodeDeploy deployment configuration to route traffic while monitoring a CloudWatch alarm for system error rates.

Configure the Application Load Balancer target group deregistration delay to 900 seconds. Use AWS CloudFormation to update the stack with an AutoScalingRollingUpdate policy, setting MinInstancesInService to 100% and configuring CloudFormation rollback triggers based on the system error rate CloudWatch alarm.

Configure the Application Load Balancer target group deregistration delay to 180 seconds. Perform an Auto Scaling group Instance Refresh with the minimum healthy percentage set to 75%, and configure a custom AWS Lambda function to monitor the system error rate and call the CancelInstanceRefresh API if the error rate exceeds 2%.

Show answer & explanation

Answer: Configure the Application Load Balancer target group deregistration delay to 900 seconds. Perform an Auto Scaling group Instance Refresh with the minimum healthy percentage set to 100%, and configure the instance refresh rollback preferences to monitor a CloudWatch alarm that tracks the system error rate, triggering an automatic rollback if the error rate exceeds 2%.

Answer

Configure the Application Load Balancer target group deregistration delay to 900 seconds, perform an Auto Scaling group Instance Refresh with the minimum healthy percentage set to 100%, and configure the instance refresh rollback preferences to monitor a CloudWatch alarm tracking the system error rate.

The correct configuration utilizes the Application Load Balancer target group deregistration delay to allow existing WebSockets connections to drain naturally for up to 15 minutes (900 seconds). By using an Auto Scaling group Instance Refresh with a minimum healthy percentage of 100%, the ASG is forced to roll out the update in batches, launching new instances before terminating the old ones. This restricts the maximum capacity increase to the batch size (25% or less), staying within the VPC subnet IP address limits. The native instance refresh rollback preferences then monitor the system error rate CloudWatch alarm, automatically rolling back the deployment if the 2% threshold is exceeded during the deployment and warm-up validation window.

Step-by-Step Solution

Configure the ALB target group attribute for deregistration delay.

The deregistration delay is set to 900 seconds (15 minutes), ensuring existing WebSockets connections are allowed to drain naturally without receiving new traffic.

This directly satisfies the requirement for zero downtime and a 15-minute natural drain time for active connections.

Initiate an Auto Scaling group Instance Refresh with the minimum healthy percentage parameter.

Setting the minimum healthy percentage to 100% forces the ASG to launch new instances before terminating old ones. The maximum capacity increase is determined by the batch size (e.g., 25%), which keeps the temporary capacity increase within the subnet IP limits.

This satisfies the capacity constraint that limits the temporary instance increase to at most 25% while maintaining service availability.

Configure Auto Rollback preferences within the Instance Refresh configuration, specifying the system error rate CloudWatch alarm.

If the error rate alarm triggers during the deployment or the instance warmup validation period, the ASG automatically terminates the refresh and rolls back to the previous launch template.

This satisfies the requirement for an automated rollback based on a post-deployment validation period.

Key Concept

Auto Scaling group Instance Refresh supports rolling updates with native rollback capabilities based on CloudWatch alarms, while ALB target group deregistration delay manages connection draining for stateful connections.

Question 878Question →

An enterprise is designing a hybrid network architecture to connect 10 spoke VPCs in an AWS Organization to their on-premises datacenter. The primary path must use a 10 Gbps AWS Direct Connect connection associated with an AWS Transit Gateway. An IPsec VPN over the internet is configured as a backup path and terminates on the same Transit Gateway. The system must automatically fail over to the VPN if the Direct Connect link fails, and fail back to the Direct Connect link once restored. Which configuration meets these requirements with the least administrative effort?

Configure a Route 53 Private Hosted Zone (PHZ) containing the on-premises endpoint records. Associate the PHZ only with a central hub VPC and configure DNS failover routing to point to the VPN endpoint when the Direct Connect Gateway becomes unreachable.

Configure BGP sessions on both the Direct Connect and VPN connections. Program the on-premises router to advertise the on-premises prefixes to both paths, prepending the Autonomous System (AS) path on the VPN advertisement. Ensure the on-premises router is configured with a higher BGP local preference for routes received via Direct Connect.

Configure VPC peering between all 10 spoke VPCs and a central transit VPC that contains the Direct Connect Gateway. Use static routes within the spoke VPCs to direct on-premises traffic through the peering connections, and use a Transit Gateway-attached VPN as a backup routing target.

Route all on-premises traffic from the spoke VPCs through a single NAT Gateway deployed in a shared services VPC. Configure the NAT Gateway's route table to forward on-premises traffic to the Transit Gateway, relying on static route tracking to switch the target from the Direct Connect Gateway to the VPN.

Show answer & explanation

Answer: Configure BGP sessions on both the Direct Connect and VPN connections. Program the on-premises router to advertise the on-premises prefixes to both paths, prepending the Autonomous System (AS) path on the VPN advertisement. Ensure the on-premises router is configured with a higher BGP local preference for routes received via Direct Connect.

Answer

Configure BGP sessions on both paths, prepending the AS path on the VPN advertisement, and configuring a higher local preference for the Direct Connect routes on the on-premises router.

Configuring BGP sessions on both paths and using AS path prepending on the VPN connection ensures that the Transit Gateway prefers the Direct Connect path for traffic going from AWS to on-premises. Adjusting the local preference on-premises ensures that traffic going from on-premises to AWS also prefers the Direct Connect path. This dynamically manages failover and failback without static routing overhead.

Step-by-Step Solution

Configure BGP routing on both the Direct Connect Gateway association and the Transit Gateway VPN attachment.

Dynamic routing updates are established between AWS and the on-premises router.

BGP allows dynamic exchange of routing information and automated failover.

Prepend the AS path on the VPN BGP advertisement from the on-premises router.

The AWS Transit Gateway receives a longer AS path for the VPN connection compared to the Direct Connect connection.

AWS Transit Gateway selects the route with the shortest AS path, ensuring AWS-to-on-premises traffic prefers the Direct Connect link.

Configure a higher local preference for routes received via Direct Connect on the on-premises router.

The on-premises router prefers the Direct Connect path for outbound traffic targeting AWS.

This establishes symmetric routing, ensuring traffic from on-premises to AWS also prefers the Direct Connect link.

Key Concept

Dynamic hybrid routing failover using BGP AS path prepending and local preference.

Question 879Question →

A company is launching a new version of its monolithic web application. The application is hosted on Amazon EC2 instances inside an Auto Scaling group (ASG) behind an Application Load Balancer (ALB). The update includes minor database schema changes that are backward-compatible.

The deployment process must meet the following criteria:
1. Shift exactly 10% of the user traffic to the new version initially.
2. Monitor the new version for 15 minutes. If the HTTP 5XX error rate or instance CPU utilization exceeds predefined thresholds, the deployment must automatically roll back immediately.
3. If no alarms are triggered during the monitoring period, all traffic must be routed to the new version, and the old instances should be terminated.
4. The deployment and rollback must avoid DNS propagation delays to ensure immediate effect.

Which combination of actions should the solutions architect implement to meet these requirements with the least operational overhead? (Select TWO.)

Select all that apply

Create a new target group and a new Auto Scaling group for the new application version. Configure the ALB listener rule with weighted target groups, routing 90% of traffic to the active target group and 10% to the new target group.

Create a Lambda function triggered by Amazon CloudWatch alarms. Configure the Lambda function to update the ALB listener rule weights to route 100% of traffic back to the original target group if alarms trigger. If no alarms trigger after 15 minutes, update the rule to route 100% of traffic to the new target group and delete the old Auto Scaling group.

Use AWS CodeDeploy to perform a blue/green deployment. Create a deployment group using the Auto Scaling group and configure the ALB. Choose a deployment configuration of CodeDeployDefault.EC2Linear10PercentEvery1Minute to gradually shift traffic.

Create a second ALB and a new Auto Scaling group for the new version. Configure Amazon Route 53 weighted alias records to route 90% of traffic to the existing ALB and 10% to the new ALB. Use Route 53 active-passive failover to automatically route traffic back if the new version's health checks fail.

Use AWS CodeDeploy to perform an in-place deployment with a deployment configuration of CodeDeployDefault.OneAtATime. Configure the deployment group with a CloudWatch alarm to automatically roll back the deployment if the thresholds are exceeded.

Show answer & explanation

Answer: Create a new target group and a new Auto Scaling group for the new application version. Configure the ALB listener rule with weighted target groups, routing 90% of traffic to the active target group and 10% to the new target group.; Create a Lambda function triggered by Amazon CloudWatch alarms. Configure the Lambda function to update the ALB listener rule weights to route 100% of traffic back to the original target group if alarms trigger. If no alarms trigger after 15 minutes, update the rule to route 100% of traffic to the new target group and delete the old Auto Scaling group.

Answer

The solutions architect should create a new target group and a new Auto Scaling group for the new application version, configure the Application Load Balancer (ALB) listener rule with weighted target groups (90% to the active target group and 10% to the new target group), and use an AWS Lambda function triggered by CloudWatch alarms to automate the rollback (by setting the weight back to 100% on the original target group) or completion of the deployment after 15 minutes.

The correct combination involves creating a new target group and a new Auto Scaling group for the new application version, configuring the ALB listener rule to route 90% of traffic to the active target group and 10% to the new target group, and using an AWS Lambda function triggered by CloudWatch alarms to manage the traffic shifting and rollback. Using ALB weighted target groups allows for instant traffic shifting at the load balancer layer, completely avoiding the DNS propagation delays associated with Route 53. Since CodeDeploy does not support gradual traffic shifting on EC2, a Lambda function is the most operationally efficient way to automate the weight adjustment and cleanup/rollback based on CloudWatch alarms.

Step-by-Step Solution

Provision a new target group and a new Auto Scaling group containing the new version of the application.

This establishes a green environment that runs parallel to the existing blue environment without affecting current production traffic.

Isolation of the new deployment prevents unintended impact on the active environment during initialization.

Configure the ALB listener rule to distribute traffic using weights: 90% to the original target group and 10% to the new target group.

Exactly 10% of user traffic is instantly routed to the new version at the load balancer level.

ALB weighted target groups shift traffic immediately without DNS caching or propagation delays, satisfying the zero-downtime and immediate effect criteria.

Deploy an AWS Lambda function triggered by CloudWatch alarms for the HTTP 5XX error rate and instance CPU utilization.

If an alarm triggers, Lambda resets the ALB rule weights to 100% blue and 0% green. If 15 minutes pass without alarms, it updates the weights to 100% green and deletes the blue Auto Scaling group.

This automates the monitoring, promotion, and rollback phases with minimal operational overhead, bypassing the limitations of CodeDeploy on EC2.

Key Concept

Application Load Balancer (ALB) weighted target groups allow for immediate traffic shifting and canary deployments on EC2 instances, bypassing DNS propagation delays and CodeDeploy's EC2 traffic-shifting limitations.

Question 880Question →

An enterprise manages its multi-account cloud environment using AWS Organizations. The security team mandates that no IAM users or roles within the 'Workloads' Organizational Unit (OU) should be able to delete Amazon S3 buckets, with the sole exception of a specific break-glass IAM role named 'EmergencyAdmin' that exists in all member accounts. The security team wants to enforce this governance control centrally with the least operational overhead. Which solution should a Solutions Architect recommend?

Apply a Service Control Policy (SCP) to the Workloads OU that denies the `s3:DeleteBucket` action. In each member account, attach an IAM policy to all roles except `EmergencyAdmin` that explicitly denies the `s3:DeleteBucket` action.

Apply a Service Control Policy (SCP) to the Workloads OU that denies the `s3:DeleteBucket` action. Include a condition in the SCP using `StringNotLike` for `aws:PrincipalARN` that excludes the `EmergencyAdmin` role ARN path `arn:aws:iam::*:role/EmergencyAdmin`.

Apply a Service Control Policy (SCP) to the Workloads OU that denies the `s3:DeleteBucket` action. Use the `NotPrincipal` element within the SCP statement to exclude the `EmergencyAdmin` role from the deny effect.

Create a new OU named 'Diagnostics' for accounts that require emergency access. Apply the S3 deletion restriction SCP only to the Workloads OU, and manage S3 deletion permissions via local IAM policies within the Diagnostics OU.

Show answer & explanation

Answer: Apply a Service Control Policy (SCP) to the Workloads OU that denies the `s3:DeleteBucket` action. Include a condition in the SCP using `StringNotLike` for `aws:PrincipalARN` that excludes the `EmergencyAdmin` role ARN path `arn:aws:iam::*:role/EmergencyAdmin`.

Answer

Apply a Service Control Policy (SCP) to the Workloads OU that denies the `s3:DeleteBucket` action, using a condition with `StringNotLike` for `aws:PrincipalARN` to exclude the `EmergencyAdmin` role path.

The correct answer utilizes a Service Control Policy (SCP) applied to the target OU. By using an explicit Deny with a condition checking that the request's `aws:PrincipalARN` does not match the emergency role path, the policy allows the emergency role to bypass the restriction while denying S3 bucket deletion to all other users and roles centrally.

Step-by-Step Solution

Identify the target control requirement

Central restriction of `s3:DeleteBucket` for all principals in the 'Workloads' OU, except for a specific role named `EmergencyAdmin`.

This establishes the scope of the rule and the exception that must be configured.

Determine the capabilities of Service Control Policies (SCPs)

SCPs apply to all roles and users in member accounts, including root, but do not support the `NotPrincipal` element.

This rules out solutions that attempt to use `NotPrincipal` in the policy structure.

Formulate a policy condition for the exception

Use a `Deny` effect with a condition block containing `StringNotLike` or `ArnNotEquals` evaluating `aws:PrincipalARN` against the role pattern.

This ensures the explicit deny applies to all principals except the designated role ARN across all accounts in the OU.

Key Concept

AWS Organizations Service Control Policies (SCPs) act as guardrails. While they do not support the `NotPrincipal` element, they can implement exceptions using conditions matching the `aws:PrincipalARN` context key.

Estimated Time:2m 0s

PreviousPage 44 / 99Next

All practice questions

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept