All practice questions

1964 questions

All types1,964 Multiple choice1,006 Multiple select931 Ordering27

An enterprise is migrating its identity architecture to a federated model. The solutions architect has established a SAML 2.0 federation between the corporate Identity Provider (IdP) and AWS Organizations. Users must federate directly into a shared services member AWS account and assume a specific role called NetworkEngineer to manage network resources. However, when users attempt to federate from the corporate portal, they receive an error indicating they are not authorized to perform the role assumption. Which configuration change is required to resolve this federation error?

Modify the trust policy of the NetworkEngineer role in the shared services account to allow the action sts:AssumeRole, and set the Principal to the external SAML provider's metadata URL.

Update the trust policy of the NetworkEngineer role in the shared services account to allow the action sts:AssumeRoleWithSAML, and set the Principal to the ARN of the SAML provider created in the shared services account.

Create a Service Control Policy (SCP) that allows the sts:AssumeRoleWithSAML action, and attach it to the Organizational Unit containing the shared services account.

Configure the trust policy of the NetworkEngineer role in the shared services account to trust the root user of the AWS Organizations management account and allow the sts:AssumeRole action.

Show answer & explanation

Answer: Update the trust policy of the NetworkEngineer role in the shared services account to allow the action sts:AssumeRoleWithSAML, and set the Principal to the ARN of the SAML provider created in the shared services account.

Answer

For direct SAML 2.0 federation to succeed, the target IAM role's trust policy must explicitly trust the SAML provider created in that specific AWS account by referencing its ARN as the principal and permitting the sts:AssumeRoleWithSAML action.

Step-by-Step Solution

Analyze the authentication error to determine the failure point.

The error indicates that the federated identity is not authorized to assume the role, pointing to an issue in the role's trust policy configuration.

Before troubleshooting individual claims, the trust relationship between the identity provider and the IAM role must be properly defined.

Configure the trust policy action for SAML federation.

The action in the IAM role trust policy is set to sts:AssumeRoleWithSAML.

Standard role assumption uses sts:AssumeRole, but SAML 2.0 identity federation requires the specific sts:AssumeRoleWithSAML action.

Define the trusted principal in the trust policy.

The Principal is set to Federated and references the ARN of the SAML provider resource inside the member account's IAM configuration.

AWS trust policies require an IAM SAML provider resource ARN as the principal to validate the SAML assertion sent by the IdP.

Key Concept

SAML 2.0 Role Trust Policy Configuration

Question 742Question →

A company is designing a new web application that is expected to experience sudden, massive spikes in traffic during promotional campaigns. The application's database tier will also face high read traffic. Which of the following actions should the Solutions Architect recommend to ensure the application remains highly performant and scalable? (Select TWO.)

Select all that apply

Submit a support case to request pre-warming of the Application Load Balancers prior to the start of the promotional campaigns.

Deploy Amazon Aurora Replicas and configure Aurora Auto Scaling to dynamically adjust reader instances based on CPU utilization.

Configure the Application Load Balancers to automatically scale out based on CPU utilization metrics of the backend EC2 instances without requesting pre-warming.

Configure the application to route read-intensive queries to the Amazon RDS Multi-AZ standby instance in the secondary Availability Zone.

Deploy an Amazon ElastiCache for Memcached cluster to replicate session data across multiple Availability Zones to ensure high availability and read scalability.

Show answer & explanation

Answer: Submit a support case to request pre-warming of the Application Load Balancers prior to the start of the promotional campaigns.; Deploy Amazon Aurora Replicas and configure Aurora Auto Scaling to dynamically adjust reader instances based on CPU utilization.

Answer

Requesting pre-warming of the Application Load Balancers (ALBs) before the promotional campaigns, and deploying Amazon Aurora Replicas with Aurora Auto Scaling to handle read capacity.

To handle sudden, massive spikes in web traffic, requesting pre-warming of the Application Load Balancers is necessary because the default auto-scaling mechanism of the load balancer may not scale quickly enough, resulting in dropped requests. To optimize database performance for read-heavy workloads, deploying Amazon Aurora Replicas and configuring Aurora Auto Scaling allows the database tier to horizontally scale read capacity dynamically as traffic demands increase.

Step-by-Step Solution

Address the sudden traffic spike requirement for the load balancing tier.

Determine that standard ALB scaling is too slow for instantaneous spikes and requires pre-warming.

Requesting pre-warming ensures that the ALB has pre-allocated resources to handle the massive surge of traffic immediately.

Address the high read volume requirement for the database tier.

Identify that horizontal read scaling is needed for the database.

Deploying Amazon Aurora Replicas allows the read workload to be offloaded from the primary instance, and Aurora Auto Scaling dynamically scales reader instances to match the load.

Key Concept

Scaling web and database tiers to handle sudden traffic spikes and high read volume using ELB pre-warming and database read replicas.

Question 743Question →

A global manufacturing corporation operates a multi-account AWS environment in the `us-east-1` Region, managed under AWS Organizations, with all VPCs connected to a central AWS Transit Gateway. The corporation must design a highly resilient hybrid network to connect its AWS resources to two on-premises facilities: a primary factory in Detroit (representing the $172.16.0.0/16$ IP range) and a secondary backup warehouse in Nashville (representing the $172.17.0.0/16$ IP range).

The connectivity requirements are as follows:
- The Detroit factory connects via a $10 \text{ Gbps}$ AWS Direct Connect (DX) connection using a Transit VIF through a Direct Connect Gateway (DXGW) attached to the Transit Gateway. A Site-to-Site VPN connection from the Detroit factory to the Transit Gateway serves as a backup.
- The Nashville warehouse connects via a $1 \text{ Gbps}$ AWS Direct Connect connection using a Transit VIF through the same DXGW.
- Traffic from AWS to the Detroit factory must prefer the Detroit DX link, and fail over to the Site-to-Site VPN only if the Detroit DX link is unavailable.
- Traffic from AWS to the Nashville warehouse must prefer the Nashville DX link. If the Nashville DX link fails, traffic to Nashville must traverse the Detroit DX link and route via the company's internal private WAN.
- For all traffic from on-premises to the AWS network ( $10.0.0.0/8$ ), both facilities must prefer their respective Direct Connect paths over the Site-to-Site VPN.

Which of the following routing configurations should the Solutions Architect implement to meet these requirements? (Select TWO.)

Select all that apply

Advertise the

172.16.0.0/16

prefix from the Detroit factory over the Direct Connect connection, and advertise the same prefix with AS-Path prepending over the Site-to-Site VPN. Additionally, advertise the Nashville

172.17.0.0/16

prefix with AS-Path prepending from the Detroit factory over its Direct Connect connection.

Configure the customer routers at both Detroit and Nashville to assign a higher BGP Local Preference value to the AWS prefix (

10.0.0.0/8

) received via the Direct Connect connections than the same prefix received via the Site-to-Site VPN.

Configure the AWS Transit Gateway route table with a static route for

172.16.0.0/16

pointing to the Direct Connect Gateway attachment, and another static route for

172.16.0.0/16

pointing to the VPN attachment with a higher metric.

Configure the Transit Gateway to enable Equal-Cost Multi-Path (ECMP) routing, and advertise both the

172.16.0.0/16

and

172.17.0.0/16

prefixes from both locations without AS-Path prepending over all Direct Connect and VPN links.

Associate the Direct Connect Gateway and the Site-to-Site VPN with separate Transit Gateway route tables, and configure a Route 53 Resolver outbound endpoint to dynamically route traffic based on path latency.

Show answer & explanation

Answer: Advertise the $172.16.0.0/16$ prefix from the Detroit factory over the Direct Connect connection, and advertise the same prefix with AS-Path prepending over the Site-to-Site VPN. Additionally, advertise the Nashville $172.17.0.0/16$ prefix with AS-Path prepending from the Detroit factory over its Direct Connect connection.; Configure the customer routers at both Detroit and Nashville to assign a higher BGP Local Preference value to the AWS prefix ( $10.0.0.0/8$ ) received via the Direct Connect connections than the same prefix received via the Site-to-Site VPN.

Answer

To establish the desired routing preferences: first, advertise the Detroit prefix over Detroit Direct Connect and with AS-Path prepending over the VPN, while also advertising the Nashville prefix with AS-Path prepending over the Detroit Direct Connect link. Second, configure the on-premises routers to assign a higher BGP Local Preference to the AWS prefix received via the Direct Connect connections.

The correct options ensure optimal BGP routing and failover behavior. Advertising the local Detroit network over the Direct Connect link and with AS-Path prepending over the VPN connection ensures that AWS Transit Gateway prefers the high-bandwidth Direct Connect link under normal operations, and only uses the VPN as a backup. Advertising the Nashville prefix with AS-Path prepending over the Detroit Direct Connect connection provides a backup path to Nashville via the Detroit factory's connection. On the other hand, configuring a higher BGP Local Preference on the customer routers for routes received via the Direct Connect links ensures that on-premises-to-AWS traffic always traverses the Direct Connect path instead of the VPN.

Step-by-Step Solution

Influence inbound AWS-to-on-premises routing for the Detroit site.

Advertise the Detroit prefix over both the Direct Connect connection and the VPN connection, but prepend the AS-Path multiple times on the VPN connection.

AWS Transit Gateway path selection will prefer the Direct Connect route because it has a shorter AS-Path than the VPN route.

Establish backup routing for the Nashville site via the Detroit path.

Advertise the Nashville prefix from the Detroit factory over the Detroit Direct Connect connection with AS-Path prepending.

AWS will route Nashville traffic over the direct Nashville Direct Connect link under normal operations (shorter AS-Path). If the Nashville Direct Connect link fails, AWS will select the next best route, which is the Detroit Direct Connect link (longer AS-Path), and route traffic through the internal WAN.

Influence outbound on-premises-to-AWS routing.

Configure the BGP routers at both locations to set a higher BGP Local Preference for the AWS prefix (

10.0.0.0/8

) received via the Direct Connect links.

BGP Local Preference is evaluated first within the customer autonomous system to determine the outbound path, ensuring that Direct Connect is preferred over the backup VPN.

Key Concept

BGP path selection attributes (AS-Path prepending and Local Preference) are used to influence inbound and outbound traffic paths in hybrid AWS networks utilizing Transit Gateway and Direct Connect.

Question 744Question →

A retail corporation manages its AWS environment using AWS Organizations. A central network account contains a Hub VPC, which is connected to several Spoke VPCs in different member accounts via an AWS Transit Gateway. The company has a Route 53 Private Hosted Zone (PHZ) named retail.internal hosted in the central network account. An on-premises datacenter is connected to the Hub VPC via AWS Direct Connect. The security team requires that all DNS queries from the on-premises datacenter for retail.internal must be resolved securely, and resources in the Spoke VPCs must also resolve retail.internal hostnames. Which combination of steps should the solutions architect take to meet these requirements?

Create Route 53 Resolver inbound endpoints in the Hub VPC and configure on-premises DNS servers to forward queries for retail.internal to the inbound endpoint IP addresses. Authorize the association of the retail.internal private hosted zone with the Spoke VPCs from the central network account using the AWS CLI or SDK, and then associate the Spoke VPCs with the hosted zone from each member account.

Create Route 53 Resolver inbound endpoints in the Hub VPC and configure on-premises DNS servers to forward queries for retail.internal to the inbound endpoint IP addresses. Share the retail.internal private hosted zone with the member accounts using AWS Resource Access Manager (RAM), and then associate the zone with the Spoke VPCs in the member accounts.

Create Route 53 Resolver outbound endpoints in the Hub VPC. Configure the AWS Direct Connect Gateway to route DNS queries for retail.internal directly to these outbound endpoints, and associate the Spoke VPCs with the private hosted zone using AWS Organizations Service Control Policies (SCPs).

Create Route 53 Resolver inbound endpoints in the Hub VPC and configure on-premises DNS servers to forward queries to these endpoints. Associate the Spoke VPCs with the private hosted zone directly using the AWS Management Console under the central network account without cross-account authorizations.

Show answer & explanation

Answer: Create Route 53 Resolver inbound endpoints in the Hub VPC and configure on-premises DNS servers to forward queries for retail.internal to the inbound endpoint IP addresses. Authorize the association of the retail.internal private hosted zone with the Spoke VPCs from the central network account using the AWS CLI or SDK, and then associate the Spoke VPCs with the hosted zone from each member account.

Answer

The correct solution involves setting up Route 53 Resolver inbound endpoints in the Hub VPC, which can be reached from on-premises over Direct Connect. For cross-account DNS resolution in Spoke VPCs, the retail.internal Private Hosted Zone must be associated with the Spoke VPCs. Because these VPCs are in different AWS accounts, the central network account must authorize the association using the AWS CLI, SDK, or API, and then each member account must associate their VPC with the hosted zone.

Step-by-Step Solution

Configure DNS resolution from on-premises to AWS.

Create Route 53 Resolver inbound endpoints in the Hub VPC. Configure on-premises DNS servers to forward queries for retail.internal to the inbound endpoint IP addresses.

This allows on-premises DNS requests to reach Route 53 over the Direct Connect connection.

Authorize cross-account Private Hosted Zone association.

Run the create-vpc-association-authorization command using the AWS CLI/SDK from the central network account (owner of the PHZ) for each Spoke VPC in the member accounts.

Before a Private Hosted Zone can be associated with a VPC in a different AWS account, the owner of the PHZ must explicitly authorize the association.

Associate Spoke VPCs with the Private Hosted Zone.

Run the associate-vpc-with-hosted-zone command using the AWS CLI/SDK from the member accounts for each Spoke VPC.

The association must be accepted/created by the account that owns the target VPC to complete the setup.

Key Concept

Cross-account Private Hosted Zone association and Route 53 Resolver inbound endpoints

Estimated Time:2m 0s

Question 745Question →

A financial services company manages its multi-account environment using AWS Organizations. The architecture includes a Workloads Organizational Unit (OU) containing production and development accounts. The security team has deployed a cross-account IAM role named SecurityAuditRole in all member accounts to perform configuration audits.

The company has the following requirements:
1. Local administrators in the Workloads accounts (who possess administrator privileges) must be prevented from deleting or modifying the SecurityAuditRole.
2. All resources in the Workloads accounts must only be created in the us-east-1 and us-west-2 regions.
3. The SecurityAuditRole must be exempt from the regional restriction to allow it to scan for compliance violations in all AWS regions.

Which solution should a solutions architect implement to meet these requirements with the least administrative overhead?

Attach a Service Control Policy (SCP) to the Workloads OU. In the first statement of the SCP, deny iam:* actions on the resource arn:aws:iam::*:role/SecurityAuditRole. In the second statement, deny all actions across all services if the aws:RequestedRegion condition key does not match us-east-1 or us-west-2, unless the aws:PrincipalARN matches arn:aws:iam::*:role/SecurityAuditRole. Ensure the default FullAWSAccess SCP remains attached to the OU, and keep existing local IAM policies in place.

Attach a Service Control Policy (SCP) to the Workloads OU that contains an Allow statement for all services in the us-east-1 and us-west-2 regions, and an Allow statement for the SecurityAuditRole in all regions. Detach the default FullAWSAccess SCP from the OU to enforce these parameters, and remove local IAM policies from the member accounts to ensure the SCP governs all operations.

Configure a SAML 2.0 trust relationship for the SecurityAuditRole in all member accounts but omit the sts:AssumeRole action from the trust policy to prevent local modifications. Apply an IAM permissions boundary to all local administrator roles that denies resource creation outside of us-east-1 and us-west-2 and denies modifications to the SecurityAuditRole. Do not use SCPs since they cannot inspect the principal ARN of cross-account roles.

Attach an SCP to the Workloads OU that denies all actions outside of us-east-1 and us-west-2. To enable the SecurityAuditRole to scan other regions, configure the central security account's AWS-managed KMS key (aws/s3) policy to grant cross-account decrypt permissions to the SecurityAuditRole in all member accounts, and configure local IAM policies to restrict administrators from modifying the audit role.

Show answer & explanation

Answer: Attach a Service Control Policy (SCP) to the Workloads OU. In the first statement of the SCP, deny iam:* actions on the resource arn:aws:iam::*:role/SecurityAuditRole. In the second statement, deny all actions across all services if the aws:RequestedRegion condition key does not match us-east-1 or us-west-2, unless the aws:PrincipalARN matches arn:aws:iam::*:role/SecurityAuditRole. Ensure the default FullAWSAccess SCP remains attached to the OU, and keep existing local IAM policies in place.

Answer

Attach a Service Control Policy (SCP) to the Workloads OU that denies deletion and modification of the SecurityAuditRole, denies all regional actions outside us-east-1 and us-west-2 unless the caller is the SecurityAuditRole, and keeps both the default FullAWSAccess SCP and local IAM policies active.

The correct solution leverages Service Control Policies (SCPs) attached to the Workloads OU to enforce compliance boundaries. Because SCPs act as filters rather than direct grants, keeping the default FullAWSAccess SCP and local IAM policies is required to ensure users still have their granted permissions. An SCP with a Deny effect on iam:* actions for the SecurityAuditRole's ARN successfully prevents local administrators from deleting or modifying it. Additionally, combining a regional Deny on aws:RequestedRegion with a StringNotLike condition for aws:PrincipalARN allows the SecurityAuditRole to bypass regional limits and scan all regions globally.

Step-by-Step Solution

Evaluate how to prevent local administrators in member accounts from deleting or modifying the audit role.

Identify that a Service Control Policy (SCP) attached to the Workloads OU can deny iam:* actions on the SecurityAuditRole resource, which applies even to administrators in the member accounts.

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

Enforce regional constraints while exempting the SecurityAuditRole.

Create an SCP statement that denies actions if the aws:RequestedRegion is not us-east-1 or us-west-2, using a Condition block with StringNotLike for aws:PrincipalARN to exempt the SecurityAuditRole.

This ensures the audit role can query resources globally to check compliance, while blocking developers from launching resources in unapproved regions.

Determine the proper relationship between SCPs and local IAM policies.

Keep the default FullAWSAccess SCP attached to the OU and retain local IAM policies.

SCPs act as filters; they do not grant permissions. Detaching FullAWSAccess or removing local IAM policies would result in an implicit deny for all operations.

Key Concept

Multi-Account Governance using SCPs and IAM Policies

Estimated Time:3m 0s

Question 746Question →

A global e-commerce and retail platform is designing a high availability and disaster recovery (HA/DR) architecture for its new payment processing microservice. The service is being deployed in a primary active region (`us-east-1`) and a standby disaster recovery region (`us-west-2`). The application requires outbound connectivity from its private subnets to external payment gateways via NAT Gateways. The business has specified a Recovery Time Objective (RTO) of $15$ minutes and a Recovery Point Objective (RPO) of $2$ minutes. The architecture must tolerate a complete Availability Zone (AZ) outage in either region, as well as a full regional outage of the primary region. Internal service discovery is managed via a Route 53 Private Hosted Zone. Which of the following architectures meets these requirements with the lowest operational complexity and cost in a normal operating state?

Deploy Amazon RDS for PostgreSQL with a cross-region read replica in us-west-2. Deploy a single NAT Gateway in each region's VPC to manage outbound compliance traffic. Associate the Route 53 Private Hosted Zone with the VPC in us-east-1 only. Configure Route 53 Failover routing pointing to the Application Load Balancers in each region.

Deploy Amazon Aurora Global Database with the primary cluster in us-east-1 and a secondary cluster containing a replica instance in us-west-2. Deploy redundant NAT Gateways across all active Availability Zones in the VPCs of both regions. Associate the Route 53 Private Hosted Zone with the VPCs in both us-east-1 and us-west-2. Configure a Route 53 Failover routing policy pointing to the Application Load Balancers in each region, linked to active health checks.

Configure daily Amazon RDS snapshots of a Multi-AZ PostgreSQL instance in us-east-1 and copy them to us-west-2. Deploy the application servers in us-east-1, and write an AWS CloudFormation template to deploy the application tier in us-west-2 only during a disaster event. Provision redundant NAT Gateways across all Availability Zones in both regions. Associate the Route 53 Private Hosted Zone with the VPCs in both regions.

Deploy Amazon Aurora Global Database with the primary cluster in us-east-1 and a secondary cluster containing a replica instance in us-west-2. Deploy a single NAT Gateway in a single Availability Zone within the VPC of each region to minimize baseline running costs. Associate the Route 53 Private Hosted Zone with the VPCs in both regions. Configure a Route 53 Failover routing policy pointing to the Application Load Balancers in each region, linked to active health checks.

Show answer & explanation

Answer: Deploy Amazon Aurora Global Database with the primary cluster in us-east-1 and a secondary cluster containing a replica instance in us-west-2. Deploy redundant NAT Gateways across all active Availability Zones in the VPCs of both regions. Associate the Route 53 Private Hosted Zone with the VPCs in both us-east-1 and us-west-2. Configure a Route 53 Failover routing policy pointing to the Application Load Balancers in each region, linked to active health checks.

Answer

The correct architecture features Amazon Aurora Global Database for near-zero RPO replication, redundant NAT Gateways across all active Availability Zones in both regions for egress redundancy, a Route 53 Failover routing policy for automatic DNS failover, and associates the Route 53 Private Hosted Zone with both VPCs to preserve internal name resolution.

The correct architecture uses Amazon Aurora Global Database to achieve cross-region replication lag of less than

1

second, which comfortably satisfies the

2

-minute RPO. It utilizes a Warm Standby configuration to keep minimal active compute resources running in the standby region, ensuring a recovery time well under the

15

-minute RTO. Redundant NAT Gateways across all active Availability Zones prevent a single AZ outage from interrupting external network connectivity. Associating the Route 53 Private Hosted Zone with the VPCs in both regions ensures internal name resolution remains functional after failover.

Step-by-Step Solution

Evaluate the database replication strategy to satisfy the

2

-minute RPO.

Amazon Aurora Global Database uses storage-based replication with a typical lag of less than

1

second, which easily satisfies the

2

-minute RPO.

Daily snapshot restoration or manual RDS replication failovers are too slow or do not guarantee this RPO under a regional disaster.

Establish application-tier readiness to meet the

15

-minute RTO.

A Warm Standby deployment in the standby region (us-west-2) with pre-provisioned, scaled-down resources ensures that the recovery time is well within the

15

-minute window.

A Pilot Light deployment starting from scratch would exceed the RTO due to initialization delays.

Design network path redundancy for both inbound and outbound traffic.

Redundant NAT Gateways must be deployed in each AZ in the VPCs of both regions to tolerate a single Availability Zone outage.

Outbound calls to external APIs will fail if only a single NAT Gateway is deployed and its AZ experiences an outage.

Configure DNS routing for internal and external traffic.

Route 53 health-checked Failover routing records must point to the ALBs in both regions, and the internal Route 53 Private Hosted Zone (PHZ) must be associated with the VPCs in both regions.

This maintains service discovery resolution and automatic routing after a failover.

Key Concept

Multi-region disaster recovery and high availability design combining storage replication, DNS routing policies, and VPC service associations.

Estimated Time:3m 0s

Question 747Question →

An utility company is designing an emergency alert system. During a regional power outage, the system must immediately ingest status updates from up to $500\text{,000}$ smart grid sensors within a $30\text{-second}$ window. The ingestion layer consists of an Application Load Balancer (ALB) routing requests to EC2 instances, which validate the sensor's digital signature against a relational database before writing the status to the database. The database currently runs on a single Amazon RDS for PostgreSQL DB instance. Which architecture optimization strategy will meet these scalability and latency requirements under sudden load?

Rely on the default auto-scaling behavior of the Application Load Balancer, and deploy an Amazon RDS for PostgreSQL Read Replica to distribute the validation read queries.

Pre-warm the Application Load Balancer by contacting AWS Support, migrate the database to Amazon Aurora PostgreSQL, and configure Aurora Auto Scaling for the Aurora Replicas to scale read capacity.

Pre-warm the Application Load Balancer by contacting AWS Support, enable Multi-AZ on the RDS for PostgreSQL instance, and configure the EC2 instances to route validation read queries to the standby replica.

Pre-warm the Application Load Balancer by contacting AWS Support, and deploy an Amazon ElastiCache for Memcached replication group across multiple Availability Zones to cache the validation data.

Show answer & explanation

Answer: Pre-warm the Application Load Balancer by contacting AWS Support, migrate the database to Amazon Aurora PostgreSQL, and configure Aurora Auto Scaling for the Aurora Replicas to scale read capacity.

Answer

Pre-warm the Application Load Balancer by contacting AWS Support, migrate the database to Amazon Aurora PostgreSQL, and configure Aurora Auto Scaling for the Aurora Replicas to scale read capacity.

The correct strategy addresses both scaling constraints. First, pre-warming the ALB ensures that the entry point can immediately handle the massive connections from 500,000 smart grid sensors. Second, migrating to Amazon Aurora PostgreSQL and utilizing Aurora Replicas with Aurora Auto Scaling allows the system to scale reads horizontally and dynamic workloads efficiently, which is optimal for validating the sensors' digital signatures during peak events.

Step-by-Step Solution

Address the immediate network traffic spike at the ingestion layer.

Requesting ELB pre-warming from AWS Support configures the ALB with enough capacity to handle the sudden influx of 500,000 sensor connections without triggering throttling or HTTP 503 errors.

Standard ALB auto-scaling is reactive and cannot scale instantly to absorb massive, immediate spikes in traffic.

Select a database engine that supports dynamic horizontal read scaling.

Migrating to Amazon Aurora PostgreSQL enables the deployment of up to 15 Aurora Replicas that share the same underlying storage volume.

Aurora PostgreSQL Replicas have minimal replication lag (typically under 100 milliseconds) and share storage, making them highly efficient for heavy read traffic scaling.

Configure auto-scaling for the database read tier.

Setting up Aurora Auto Scaling dynamically adds or removes Aurora Replicas based on reader CPU utilization or average connections.

This ensures the read capacity automatically adjusts to handle validation queries during emergency events and scales back down afterward to optimize cost.

Key Concept

Handling flash traffic requires pre-warming the load balancer, while scaling relational database reads horizontally requires using replicas rather than passive standby instances.

Estimated Time:2m 0s

Question 748Question →

A logistics company is designing a centralized compliance auditing and log monitoring architecture across its AWS Organization, which currently consists of 120 member accounts. The security team mandates that all AWS CloudTrail logs must be consolidated into a single Amazon S3 bucket located in a dedicated Security account. The architecture must satisfy the following constraints:

- All log data must be encrypted at rest using a customer managed key (CMK) in AWS KMS to meet regulatory requirements.
- The encryption key and S3 bucket must reside in the Security account to isolate auditing assets.
- Administrators in individual member accounts must not be able to modify, disable, or delete the logging configuration, nor should they have access to decrypt or tamper with the logs.
- The configuration must automatically scale to new accounts vended through the organization's automation pipeline.

Which TWO actions should the Solutions Architect take to implement this architecture?

Select all that apply

Create a customer managed KMS key and an S3 bucket in the centralized Security account. Configure the KMS key policy to grant the AWS CloudTrail service principal permissions to perform kms:GenerateDataKey* and kms:Decrypt actions, restricted by a condition matching the organization ID. Configure the S3 bucket policy to allow the CloudTrail service principal to perform s3:PutObject and s3:GetBucketAcl actions, conditional on the organization ID.

Deploy an organization trail from the AWS Organizations management account configured to deliver log files to the centralized S3 bucket, specifying the customer managed KMS key for log encryption. Attach a Service Control Policy (SCP) to the organization root that denies member accounts the permissions to delete, update, or stop CloudTrail configurations.

Configure the S3 bucket in the centralized Security account to use default encryption with the AWS-managed KMS key (aws/s3). Apply a bucket policy that grants s3:PutObject access to the CloudTrail service principal for all AWS accounts within the organization.

Create an IAM role in each member account that grants permission to write log files to the S3 bucket in the Security account. Configure the organization trail to assume these regional IAM roles to authenticate and deliver the logs, and update the S3 bucket policy in the Security account to trust these IAM roles.

Attach a Service Control Policy (SCP) to the organization root that grants the CloudTrail service principal explicit permissions to write to the centralized S3 bucket and generate data keys using the customer managed KMS key, thereby bypassing local resource policy requirements.

Show answer & explanation

Answer: Create a customer managed KMS key and an S3 bucket in the centralized Security account. Configure the KMS key policy to grant the AWS CloudTrail service principal permissions to perform kms:GenerateDataKey* and kms:Decrypt actions, restricted by a condition matching the organization ID. Configure the S3 bucket policy to allow the CloudTrail service principal to perform s3:PutObject and s3:GetBucketAcl actions, conditional on the organization ID.; Deploy an organization trail from the AWS Organizations management account configured to deliver log files to the centralized S3 bucket, specifying the customer managed KMS key for log encryption. Attach a Service Control Policy (SCP) to the organization root that denies member accounts the permissions to delete, update, or stop CloudTrail configurations.

Answer

To implement this secure centralized auditing configuration, you must create a customer managed KMS key and an S3 bucket in the Security account, configuring both of their resource policies to allow the AWS CloudTrail service principal cross-account access conditional on the organization ID. Additionally, deploy an organization trail from the management account and restrict local tampering via a Service Control Policy (SCP) at the organization root.

The correct implementation combines a centralized S3 bucket and a customer managed KMS key in the Security account with policies that trust the CloudTrail service principal conditional on the organization ID. Deploying an organization trail ensures that all accounts are automatically logged, and a Service Control Policy (SCP) applied at the organization root prevents local administrators from disabling or modifying these logging configurations.

Step-by-Step Solution

Set up the destination storage and encryption in the centralized Security account.

An S3 bucket and a customer managed KMS key are created in the Security account.

Regulatory and security requirements mandate isolating log archives and using a customer managed key where key policy modifications are possible.

Configure the S3 bucket policy and KMS key policy to permit cross-account log delivery.

The S3 bucket policy allows s3:PutObject and s3:GetBucketAcl, and the KMS key policy allows kms:GenerateDataKey* and kms:Decrypt for the CloudTrail service principal, conditional on the organization ID.

Since CloudTrail delivers logs from various accounts under the organization, the resource policies must explicitly trust the service principal using the aws:PrincipalOrgID condition.

Create an organization trail in the management account to log events across all member accounts.

An organization trail is deployed that directs logs to the S3 bucket and encrypts them using the customer managed KMS key.

An organization trail automatically applies to all existing and future accounts, ensuring complete coverage without manual configuration for new accounts.

Apply a Service Control Policy (SCP) at the organization root.

An SCP is attached to deny member accounts permission to modify or delete CloudTrail resources.

This prevents local administrators in member accounts from stopping logging, disabling trails, or deleting logging configurations.

Key Concept

Centralized Organization Trail logging with cross-account KMS CMK encryption and S3 bucket policies.

Question 749Question →

A clinical trial organization is designing a real-time clinical patient monitoring platform across two AWS Regions: us-east-1 (primary) and us-west-2 (secondary). The platform processes real-time telemetry from wearable IoT sensors via an API gateway, storing the records in an Amazon Aurora PostgreSQL database. The business requires a Recovery Point Objective (RPO) of 1 minute and a Recovery Time Objective (RTO) of 5 minutes. The internal microservices run in private subnets, resolve external dependencies through interface VPC endpoints, and require private DNS resolution of internal domain names across both regions. Outbound calls to external medical validation endpoints must be highly available and resilient to Availability Zone (AZ) failures. Which architecture meets these requirements while minimizing recovery time and operational complexity?

Deploy Amazon Aurora Global Database with the primary cluster in us-east-1 and a secondary cluster in us-west-2. Deploy the application servers across multiple Availability Zones in private subnets in both regions. In each region, deploy a NAT Gateway in each Availability Zone to manage outbound calls. Associate the Route 53 Private Hosted Zone (PHZ) with the VPCs in both us-east-1 and us-west-2. Configure Route 53 Application Recovery Controller (Route 53 ARC) routing controls with health checks to automate failover of the public API endpoint via Route 53 failover records.

Deploy Amazon Aurora PostgreSQL with cross-region read replicas from us-east-1 to us-west-2. Deploy the application servers across multiple Availability Zones in private subnets in both regions. Deploy a single NAT Gateway in the primary Availability Zone of each region to route outbound traffic. Associate the Route 53 Private Hosted Zone (PHZ) with the VPC in us-east-1 and configure Route 53 Active-Passive failover routing policy pointing to the regional Application Load Balancers (ALBs).

Deploy Amazon Aurora PostgreSQL in us-east-1 and configure AWS Backup to replicate snapshots to us-west-2 daily. Deploy the application servers in us-east-1 and write an AWS CloudFormation template to deploy identical resources in us-west-2. In the event of a failure, restore the database from the replicated snapshot, launch the CloudFormation stack in us-west-2, and update the Route 53 failover routing policy to point to the new Application Load Balancer (ALB).

Deploy Amazon Aurora Global Database with the primary cluster in us-east-1 and a secondary cluster in us-west-2. Enable Aurora Auto Scaling on both the primary and secondary clusters to dynamically scale instances to handle read-write write forwarding workloads during failover. Deploy NAT Gateways in each Availability Zone in both regions. Associate the Route 53 Private Hosted Zone (PHZ) only with the us-east-1 VPC and rely on Route 53 Geolocation routing to automatically direct VPC-to-VPC traffic to the nearest regional database endpoint.

Show answer & explanation

Answer: Deploy Amazon Aurora Global Database with the primary cluster in us-east-1 and a secondary cluster in us-west-2. Deploy the application servers across multiple Availability Zones in private subnets in both regions. In each region, deploy a NAT Gateway in each Availability Zone to manage outbound calls. Associate the Route 53 Private Hosted Zone (PHZ) with the VPCs in both us-east-1 and us-west-2. Configure Route 53 Application Recovery Controller (Route 53 ARC) routing controls with health checks to automate failover of the public API endpoint via Route 53 failover records.

Answer

Deploy Amazon Aurora Global Database, multi-AZ application servers with NAT Gateways in each Availability Zone in both regions, associate the Route 53 Private Hosted Zone with VPCs in both regions, and use Route 53 Application Recovery Controller (ARC) for automated DNS failover.

The correct architecture uses Amazon Aurora Global Database to achieve near-zero recovery point objective (RPO) through sub-second cross-region replication. By having the application stack pre-deployed in both regions, deploying redundant NAT Gateways in each Availability Zone for resilient outbound external API access, associating the Route 53 Private Hosted Zone (PHZ) with both VPCs for cross-region internal name resolution, and utilizing Route 53 Application Recovery Controller (ARC) for automated failover, the solution achieves the strict 5-minute recovery time objective (RTO).

Step-by-Step Solution

Select a database replication strategy that satisfies the sub-minute RPO requirement.

Amazon Aurora Global Database provides physical, sub-second replication latency across regions, meeting the 1-minute RPO constraint.

Standard backup restoration or cross-region read replicas can introduce higher RPO or failover latency.

Design the network egress and internal DNS resolution to support high availability and cross-region failover.

Deploy a NAT Gateway in each Availability Zone within each region's VPC, and associate the Route 53 Private Hosted Zone (PHZ) with the VPCs in both us-east-1 and us-west-2.

A single NAT Gateway per region is a single point of failure for outbound connections. A PHZ must be associated with every VPC that needs to resolve its records, spanning both regions.

Implement an automated region-level failover mechanism that meets the 5-minute RTO constraint.

Use Amazon Route 53 Application Recovery Controller (Route 53 ARC) routing controls with health checks to coordinate the failover of the API entry point.

ARC provides low-latency, deterministic routing controls and automated failover that can redirect traffic within seconds, fulfilling the 5-minute RTO target without manual DNS updates.

Key Concept

High Availability and Multi-Region Disaster Recovery Design with strict RTO/RPO, NAT Gateway redundancy, Route 53 PHZ VPC association, and automated DNS failover.

Estimated Time:3m 0s

Question 750Question →

A company is designing a disaster recovery strategy for a non-critical internal reporting application. The business requirements specify a Recovery Time Objective (RTO) of 24 hours and a Recovery Point Objective (RPO) of 24 hours. The primary objective is to minimize ongoing infrastructure running costs in the secondary region. Which disaster recovery strategy should the solutions architect recommend to meet these requirements?

Backup and Restore, copying EBS snapshots and database backups to the secondary region and provisioning resources only during a failover event

Pilot Light, keeping a minimal version of the application stack running and replicating database transactions to a small standby database in the secondary region

Warm Standby, deploying a scaled-down but fully functional version of the environment in the secondary region that is ready to scale up immediately

Multi-Site Active-Active, running fully scaled duplicate environments in both regions and routing traffic using Route 53 latency-based routing

Show answer & explanation

Answer: Backup and Restore, copying EBS snapshots and database backups to the secondary region and provisioning resources only during a failover event

Answer

Backup and Restore, copying EBS snapshots and database backups to the secondary region and provisioning resources only during a failover event

The correct answer is the strategy that copies backups and snapshots to the destination region and only provisions compute and database resources when a disaster is declared. This meets the 24-hour RTO and RPO requirements with the lowest possible cost because no active AWS infrastructure (like EC2 or RDS instances) is running in the disaster recovery region during normal operations.

Step-by-Step Solution

Analyze the RTO and RPO requirements of 24 hours.

A 24-hour window is sufficient to restore databases from backups and provision virtual machines using automated scripts and AMIs.

Understanding the time limit determines if resources must be pre-warmed or if they can be created on-demand during a disaster.

Evaluate the cost constraint (minimize ongoing infrastructure running costs).

The target strategy must avoid keeping running compute or database instances in the secondary region during normal operations.

Running inactive standby instances increases monthly costs, which violates the cost optimization constraint.

Select the disaster recovery strategy that matches both constraints.

Backup and Restore only incurs storage costs for backups and snapshots in the secondary region, provisioning compute and database capacity only during failover.

Backup and Restore satisfies the 24-hour RTO and RPO while ensuring the lowest baseline operational cost.

Key Concept

Disaster Recovery strategies cost and RTO/RPO trade-offs

Question 751Question →

A biotechnology firm manages its workloads across multiple AWS accounts within an organization in AWS Organizations. The firm wants to implement a federated single sign-on (SSO) solution using their on-premises SAML 2.0-compliant Identity Provider (IdP) to allow researchers and administrators to log in to AWS member accounts. The identity solution must dynamically map corporate users to corresponding AWS IAM roles based on their corporate group membership (e.g., ResearchDataAnalyst, ComplianceAuditor).

The solutions architect must design a secure, scalable federation flow while adhering to the principle of least privilege. Additionally, the security team wants to enforce service-level guardrails across the entire organization using Service Control Policies (SCPs).

Which of the following configurations must be implemented to establish this federation and policy framework? (Select THREE.)

Select all that apply

Create a SAML Identity Provider entity in each member account that references the corporate IdP's metadata XML, and define IAM roles with a trust policy that allows the sts:AssumeRoleWithSAML action for the SAML provider principal.

Configure the corporate IdP to release SAML assertions containing the https://aws.amazon.com/SAML/Attributes/Role attribute, which lists comma-separated pairs of the target IAM role ARN and the SAML provider ARN for the corresponding member account.

Apply Service Control Policies (SCPs) at the Organizational Unit (OU) level to define the maximum permitted permissions for the federated roles, while attaching local IAM policies to the federated roles in each member account to explicitly grant the required AWS service permissions.

Create IAM roles in each member account with a trust policy that permits the sts:AssumeRole action for the SAML provider principal, and configure the corporate IdP to pass the AWS role session name as a SAML attribute.

Define the permissions for each user group directly within Service Control Policies (SCPs) applied to the target OUs, and configure the federated IAM roles with wildcard (*) administrator permissions, relying on the SCPs to grant the actual access.

Register the corporate IdP as an OIDC Identity Provider in the management account, and use the sts:AssumeRoleWithWebIdentity action in the member account trust policies to enable cross-account federation for SAML users.

Show answer & explanation

Answer: Create a SAML Identity Provider entity in each member account that references the corporate IdP's metadata XML, and define IAM roles with a trust policy that allows the sts:AssumeRoleWithSAML action for the SAML provider principal.; Configure the corporate IdP to release SAML assertions containing the https://aws.amazon.com/SAML/Attributes/Role attribute, which lists comma-separated pairs of the target IAM role ARN and the SAML provider ARN for the corresponding member account.; Apply Service Control Policies (SCPs) at the Organizational Unit (OU) level to define the maximum permitted permissions for the federated roles, while attaching local IAM policies to the federated roles in each member account to explicitly grant the required AWS service permissions.

Answer

To configure a multi-account federation and policy framework, you must create a SAML Identity Provider entity in each member account with a trust policy allowing the sts:AssumeRoleWithSAML action; configure the corporate IdP to release assertions mapping the target IAM role and SAML provider ARNs; and apply SCPs at the OU level as guardrails while using local IAM policies to grant permissions.

The correct configurations involve setting up a SAML Identity Provider entity in each target member account with trust policies permitting the sts:AssumeRoleWithSAML action, configuring the corporate IdP to emit the Role attribute containing the role and provider ARN pairs, and using SCPs at the OU level as guardrails while relying on local IAM policies to explicitly grant permissions.

Step-by-Step Solution

Establish SAML trust in member accounts

Each member account has a SAML provider referencing the corporate IdP metadata and IAM roles configured with trust policies.

This establishes trust between each AWS member account and the external corporate Identity Provider.

Configure SAML assertion mapping in the IdP

The corporate IdP is configured to release the Role attribute, listing the Role ARN and SAML Provider ARN pairs.

AWS uses the Role attribute in the SAML assertion to identify which role the federated user is authorized to assume.

Configure permission guardrails and grant policies

SCPs are applied at the OU level to define maximum allowed API calls, while local IAM policies attached to the roles grant the explicit permissions.

SCPs act as organizational-level boundaries, but local IAM policies are required to grant access to resources under the shared-responsibility model.

Key Concept

SAML 2.0 Multi-Account Federation and Governance using SCPs

Question 752Question →

An enterprise manages its multi-account environment using AWS Organizations. The architecture consists of a Management account, a central Network account, and multiple application accounts grouped in a Production Organizational Unit (OU). The enterprise is acquiring a subsidiary that must maintain a separate AWS Organization for compliance reasons.

The Solutions Architect must design a billing and resource sharing strategy to meet these requirements:
- Application accounts in the Production OU must deploy resources into VPC subnets managed centrally by the Network account.
- The subsidiary must access a Transit Gateway managed by the Network account of the main organization.
- Compute Savings Plans purchased in the Management account must apply to all Production accounts except for a designated testing account in the Production OU.

Which TWO of the following configurations are required to implement this strategy? (Select TWO.)

Select all that apply

In the main organization's Management account, enable resource sharing within AWS Organizations in AWS RAM. In the Network account, create a resource share containing the VPC subnets and associate it with the Production OU ID.

In the Network account, create a resource share in AWS RAM containing the VPC subnets, enable sharing with external entities, and associate it with the acquired subsidiary's AWS account IDs.

In the main organization's Management account, configure the Billing Preferences to disable Savings Plan sharing for the testing account. In the Network account, create a resource share containing the Transit Gateway, enable sharing with external entities, and associate it with the subsidiary's AWS account IDs.

Apply a Service Control Policy (SCP) to the testing account that denies the savingsplans:ApplySavingsPlans action to prevent it from utilizing the Management account's Compute Savings Plans.

Show answer & explanation

Answer: In the main organization's Management account, enable resource sharing within AWS Organizations in AWS RAM. In the Network account, create a resource share containing the VPC subnets and associate it with the Production OU ID.; In the main organization's Management account, configure the Billing Preferences to disable Savings Plan sharing for the testing account. In the Network account, create a resource share containing the Transit Gateway, enable sharing with external entities, and associate it with the subsidiary's AWS account IDs.

Answer

Enable resource sharing within AWS Organizations, share the VPC subnets with the Production OU, disable Savings Plan sharing for the testing account in Billing Preferences, and share the Transit Gateway externally using AWS Resource Access Manager (RAM).

The correct strategy combines enabling Organization-level sharing for internal subnet distribution and configuring Billing Preferences in the Management account to exclude specific accounts from Savings Plan sharing. It also utilizes AWS RAM's capability to share Transit Gateways externally with accounts outside the AWS Organization.

Step-by-Step Solution

Enable Organization-level resource sharing in the Management account using AWS RAM, then create a resource share in the Network account containing the subnets and share it with the Production OU ID.

Allows application accounts to deploy resources within the shared subnets while keeping subnet management centralized in the Network account.

VPC subnets can only be shared with accounts within the same AWS Organization.

In the Network account, create a resource share containing the Transit Gateway, enable sharing with external entities, and add the subsidiary's AWS account IDs.

Grants the acquired subsidiary access to the transit gateway across organizational boundaries.

Transit Gateways support cross-organization resource sharing through AWS RAM when external sharing is enabled.

Navigate to Billing Preferences in the main organization's Management account and turn off Savings Plan sharing for the testing account.

Excludes the testing account from receiving the shared Compute Savings Plans discounts.

Savings Plan discount sharing is managed through Billing Preferences in the Management account rather than IAM or SCPs.

Key Concept

AWS RAM sharing capabilities and limits (internal vs. external organization), and management of Savings Plans discount sharing via Billing Preferences.

Question 753Question →

A company has $15$ AWS accounts in an AWS Organization, with each account containing a single VPC in the `us-east-1` Region. The company wants to establish hybrid connectivity between these VPCs and its on-premises data center using an existing $10\text{ Gbps}$ AWS Direct Connect connection. The architecture must meet the following requirements:

- Spoke VPCs must be able to send and receive traffic to and from the on-premises data center.
- Spoke VPCs must be strictly isolated from one another at the network routing level.
- The solution must minimize administrative overhead as new VPCs are added.

Which configuration meets these requirements?

Configure an AWS Transit Gateway (TGW) and attach all spoke VPCs. Attach a Direct Connect Gateway (DXGW) to the TGW using a transit virtual interface. Create two TGW route tables. Associate the spoke VPC attachments with the first TGW route table and configure a route pointing to the DXGW attachment. Associate the DXGW attachment with the second TGW route table and propagate the spoke VPC routes to it.

Associate all

15

spoke VPCs directly to a single Direct Connect Gateway using private virtual interfaces. In the Direct Connect Gateway settings, disable route propagation between the associated VPCs to enforce network isolation.

Configure an AWS Transit Gateway (TGW) and attach all spoke VPCs and the Direct Connect Gateway (DXGW) attachment. Use the default TGW route table to associate and propagate all attachments, allowing full routing. In each spoke VPC, configure security groups to block inbound and outbound traffic originating from the CIDR ranges of all other spoke VPCs.

Establish VPC peering connections between each spoke VPC and a centralized Transit VPC. Connect the Transit VPC to the on-premises data center using a Direct Connect Gateway. Configure the route tables in the Transit VPC to route traffic between the spoke VPCs and the on-premises environment.

Show answer & explanation

Answer: Configure an AWS Transit Gateway (TGW) and attach all spoke VPCs. Attach a Direct Connect Gateway (DXGW) to the TGW using a transit virtual interface. Create two TGW route tables. Associate the spoke VPC attachments with the first TGW route table and configure a route pointing to the DXGW attachment. Associate the DXGW attachment with the second TGW route table and propagate the spoke VPC routes to it.

Answer

Configure an AWS Transit Gateway (TGW) with two route tables. Associate the spoke VPC attachments with the first TGW route table, and add a static route pointing to the Direct Connect Gateway (DXGW) attachment. Associate the DXGW attachment with the second TGW route table, and enable route propagation from the spoke VPCs to this second table.

The correct architecture uses AWS Transit Gateway route domains. By creating two TGW route tables, you can isolate routing. Spoke VPC attachments associate with the first route table and have a route only to the Direct Connect Gateway (DXGW) attachment, preventing them from seeing each other's routes. The DXGW attachment associates with the second route table, which gets populated with the spoke VPC routes via propagation, enabling bidirectional hybrid connectivity with on-premises while maintaining isolation.

Step-by-Step Solution

Deploy AWS Transit Gateway (TGW) in the central network account and share it with the spoke accounts using AWS Resource Access Manager (RAM).

The TGW is available for attachments in all spoke accounts.

Centralizing the transit hub reduces administrative overhead and enables multi-account connectivity.

Attach all

15

spoke VPCs to the TGW and associate the Direct Connect Gateway (DXGW) with the TGW via a transit virtual interface (transit VIF).

Network attachments are established between the TGW, the spoke VPCs, and the on-premises environment.

Allows physical routing paths to be defined between all endpoints.

Create two Transit Gateway route tables. Associate the spoke VPC attachments with the first table and add a route to the DXGW. Associate the DXGW attachment with the second table and enable propagation from the spoke VPCs.

The spoke VPCs can only resolve routes to the DXGW (on-premises), while the DXGW can resolve routes to all spoke VPCs.

This establishes route domain isolation, preventing spoke VPCs from routing traffic to each other while ensuring bidirectional communication with the on-premises data center.

Key Concept

AWS Transit Gateway Route Table Isolation (Route Domains) for Hybrid Connectivity

Question 754Question →

A global retail and supply chain enterprise manages its hybrid IT environment across multiple AWS accounts using AWS Organizations. The infrastructure includes a central Shared Services VPC in a Network account and several Application VPCs in member accounts. Network connectivity to the on-premises datacenter is established via AWS Transit Gateway and AWS Direct Connect. The on-premises DNS servers host the zone `corp.internal`, while a Route 53 Private Hosted Zone (PHZ) for `aws.corp.internal` is hosted in the Shared Services account. The enterprise requires resources in all VPCs to resolve `corp.internal` and resources on-premises to resolve `aws.corp.internal`. Which TWO actions should the Solutions Architect perform to implement this hybrid DNS architecture? (Select TWO.)

Select all that apply

In the Shared Services VPC, create Route 53 Resolver outbound endpoints. Create a Resolver forwarding rule for the corp.internal domain pointing to the on-premises DNS servers, share the rule with the organization using AWS Resource Access Manager (RAM), and associate the rule with the Application VPCs.

From the Shared Services account, authorize the association of the aws.corp.internal private hosted zone with the Application VPCs in the member accounts using the AWS CLI or API. In each member account, associate the Application VPCs with the private hosted zone.

Associate the aws.corp.internal private hosted zone with the Application VPCs directly from the Route 53 console in the Shared Services account, as resource sharing for private hosted zones is automatically enabled within AWS Organizations.

In the Shared Services VPC, create Route 53 Resolver inbound endpoints. Configure the on-premises DNS servers to forward queries for aws.corp.internal to the Transit Gateway's link-local IP address

169.254.169.253

, routing traffic through a Direct Connect Gateway.

Create Route 53 Resolver inbound and outbound endpoints in each Application VPC. Set up conditional forwarding rules locally within each member account to forward queries for corp.internal directly to the on-premises DNS servers.

Show answer & explanation

Answer: In the Shared Services VPC, create Route 53 Resolver outbound endpoints. Create a Resolver forwarding rule for the corp.internal domain pointing to the on-premises DNS servers, share the rule with the organization using AWS Resource Access Manager (RAM), and associate the rule with the Application VPCs.; From the Shared Services account, authorize the association of the aws.corp.internal private hosted zone with the Application VPCs in the member accounts using the AWS CLI or API. In each member account, associate the Application VPCs with the private hosted zone.

Answer

Create Route 53 Resolver outbound endpoints and a forwarding rule for the corporate domain in the Shared Services VPC, share the rule via AWS Resource Access Manager (RAM) to the Application VPCs, and authorize/associate the cross-account private hosted zone with the Application VPCs using the AWS CLI or API.

The correct options describe the standard, architecturally sound method for establishing hybrid DNS resolution in a multi-account AWS environment. Sharing centralized Route 53 Resolver outbound rules via AWS Resource Access Manager (RAM) allows member accounts to forward on-premises DNS queries without the cost of deploying outbound endpoints in every VPC. For cross-account Private Hosted Zones, using the AWS CLI or API to authorize and then associate the VPCs ensures that the Application VPCs can resolve the private DNS records hosted in the central Network account.

Step-by-Step Solution

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

Create outbound Route 53 Resolver endpoints in the central Shared Services VPC. Create a forwarding rule for the `corp.internal` domain pointing to the on-premises DNS servers.

This enables DNS queries targeting the on-premises network to be forwarded over the Direct Connect connection.

Share the outbound Resolver rule across the organization.

Use AWS Resource Access Manager (RAM) to share the forwarding rule with the member accounts, and associate the rule with the Application VPCs.

This centralizes outbound resolver endpoints and rule configuration, reducing operational complexity and cost.

Enable DNS resolution of the AWS Private Hosted Zone (PHZ) in the Application VPCs.

Authorize the association of the `aws.corp.internal` PHZ with the Application VPCs using the AWS CLI/API in the Shared Services account, then associate them in the member accounts.

VPCs can only resolve names in a PHZ if the zone is associated with them. Since the PHZ and VPCs are in different accounts, cross-account association authorization is required.

Key Concept

Centralized Route 53 Resolver endpoints combined with cross-account Private Hosted Zone association authorization are required to build a scalable and secure hybrid DNS architecture.

Question 755Question →

An enterprise is planning to establish a governed, multi-account AWS environment using AWS Organizations and AWS Control Tower. The strategy requires centralized logging, centralized security operations, environment segregation, and service control guardrails before workloads are deployed. Arrange the following steps in the correct chronological sequence to implement this multi-account governance strategy according to AWS best practices.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order is: Initialize AWS Organizations, deploy AWS Control Tower, designate the Security Tooling account as the delegated administrator, establish custom OUs, and attach custom Service Control Policies (SCPs).

The correct sequence begins with initializing the AWS Organization to build the administrative root. Next, deploying AWS Control Tower provisions the Security OU along with the Log Archive and Security Tooling accounts. Once these core accounts are active, the Security Tooling account is designated as the delegated administrator for security services. Custom OUs are then created to group future workload accounts, and finally, custom SCPs are attached to these OUs to enforce boundaries before the member accounts are provisioned.

Step-by-Step Solution

Initialize AWS Organizations

The administrative root is created, enabling multi-account management features.

This establishes the organizational structure and API capabilities required by orchestration tools.

Deploy AWS Control Tower

A multi-account landing zone is created with dedicated Security OUs containing Log Archive and Security Tooling accounts.

Control Tower sets up the foundational security baseline and logs account before custom workloads or configurations can be applied.

Designate Delegated Administrator

Security services are centralized in the Security Tooling account rather than the Management account.

Best practices dictate delegating administration to security-specific accounts rather than performing daily security operations in the management account.

Establish Custom OUs

New OUs (e.g., Workloads, Sandbox) are added to the hierarchy.

OUs must exist in the hierarchy before you can assign accounts or attach policies to them.

Attach Service Control Policies (SCPs)

Custom guardrails are applied to target OUs.

Enforcing policies at the OU level before accounts are provisioned guarantees that new accounts are immediately governed by the guardrails.

Key Concept

Foundational multi-account setup sequence and delegation of administrative control under AWS Organizations.

Alternative Method

An alternative approach is using Infrastructure as Code (IaC) with AWS Control Tower Account Factory for Terraform (AFT) to automate this pipeline, where the organization bootstrap, landing zone deployment, and customized OU policies are defined declaratively.

Estimated Time:3m 0s

Question 756Question →

A logistics company is designing a High Availability and Disaster Recovery (HA/DR) architecture for its new central supply chain inventory auditing platform. The system processes inventory updates from international warehouses and has a strict Recovery Time Objective (RTO) of 30 minutes and a Recovery Point Objective (RPO) of 5 minutes. The application runs on Amazon ECS Fargate tasks behind an Application Load Balancer (ALB) and relies on Amazon Aurora PostgreSQL for data storage. Outbound inventory sync calls must be routed securely to third-party vendors. The architect chooses us-east-1 as the primary region and us-west-2 as the disaster recovery region. Which two configurations should the solutions architect implement to achieve these HA/DR objectives? (Select TWO.)

Select all that apply

Create an Amazon Aurora Global Database with the primary database cluster in us-east-1 and a secondary database cluster in us-west-2 to support sub-second physical replication and satisfy the Recovery Point Objective (RPO) requirement.

Configure Amazon Route 53 active-passive failover routing by creating a primary record pointing to the Application Load Balancer in us-east-1 associated with an active health check, and a secondary record pointing to the Application Load Balancer in us-west-2.

Enable Amazon Aurora Auto Scaling on the reader instances in us-west-2 to automatically promote a reader instance to primary based on write connection load, and configure Route 53 multi-value routing to distribute write traffic across both regions.

Configure Amazon Route 53 latency-based routing to direct write requests to the lowest latency region, relying on application-level retries and default Aurora asynchronous cross-region replication to resolve write conflicts across both regions.

Deploy a single NAT Gateway in us-east-1 to route outbound traffic for both regions to third-party vendors, and configure a Route 53 Private Hosted Zone (PHZ) in the primary VPC without associating it with the secondary VPC.

Show answer & explanation

Answer: Create an Amazon Aurora Global Database with the primary database cluster in us-east-1 and a secondary database cluster in us-west-2 to support sub-second physical replication and satisfy the Recovery Point Objective (RPO) requirement.; Configure Amazon Route 53 active-passive failover routing by creating a primary record pointing to the Application Load Balancer in us-east-1 associated with an active health check, and a secondary record pointing to the Application Load Balancer in us-west-2.

Answer

Configure an Amazon Aurora Global Database with the primary cluster in us-east-1 and a secondary cluster in us-west-2 to support sub-second physical replication, and configure Amazon Route 53 active-passive failover routing to manage traffic switchover between the Application Load Balancers.

The correct architecture uses Amazon Aurora Global Database to achieve sub-second data replication across regions, easily satisfying the 5-minute RPO. Route 53 failover routing policy is used to manage the active-passive application traffic flow, directing user requests to the primary Application Load Balancer in us-east-1 and shifting to us-west-2 within minutes if a failure is detected, satisfying the 30-minute RTO.

Step-by-Step Solution

Select a database replication technology that meets the RPO constraint of 5 minutes.

Amazon Aurora Global Database provides sub-second replication lag, ensuring the RPO is satisfied.

Since standard cross-region read replicas can introduce replication lag or require more manual configuration, Aurora Global Database is the native and optimal solution for cross-region disaster recovery.

Establish the Route 53 routing policy to handle traffic failover within the 30-minute RTO.

Route 53 active-passive failover routing routes all write traffic to the primary ALB in us-east-1 and fails over to us-west-2 if the health check fails.

This prevents clients from attempting to write directly to the read-only secondary database cluster and automates the DNS switchover.

Ensure outbound connectivity and internal name resolution are highly available and properly connected.

Deploy redundant NAT Gateways in each Availability Zone in both regions, and associate the Route 53 Private Hosted Zone with both the primary and secondary VPCs.

This guarantees that outbound API syncs do not suffer from single points of failure and that internal DNS resolution functions correctly after a failover.

Key Concept

Multi-region disaster recovery orchestration using Amazon Aurora Global Database and Route 53 active-passive failover routing.

Question 757Question →

An enterprise manages its multi-account AWS environment under a single AWS Organization with consolidated billing. The network architecture requires sharing a private VPC subnet from a dedicated Network account with two application accounts. These application accounts run auto-scaled Amazon EC2 workloads, AWS Fargate tasks on Amazon ECS, and AWS Lambda functions. The enterprise also wants to purchase a single Savings Plan from the management account to reduce compute costs across all of these workloads, but must exclude two specific development accounts in the organization from receiving the discount benefits. Which of the following strategies should a Solutions Architect implement to meet these requirements?

Enable resource sharing within AWS Organizations in the AWS RAM settings. In the Network account, use AWS Resource Access Manager (RAM) to share the private subnet with the application accounts. Purchase a Compute Savings Plan in the management account, and disable Savings Plan discount sharing for the development accounts under Billing Preferences in the Billing console.

Enable resource sharing within AWS Organizations in the AWS RAM settings. In the Network account, use AWS Resource Access Manager (RAM) to share the private subnet with the application accounts. Purchase an EC2 Instance Savings Plan in the management account, and use AWS Billing Conductor to configure billing groups that exclude the development accounts from the discount sharing.

Create a resource share for the subnet in AWS RAM in the Network account. Share the subnet directly with the individual application accounts by entering their account IDs, without enabling organization sharing in AWS RAM. Purchase a Compute Savings Plan in the management account, and disable Savings Plan discount sharing for the development accounts.

Attach a Service Control Policy (SCP) to the organization's root to allow AWS RAM subnet sharing and to automatically apply Compute Savings Plans discounts to the application accounts while denying them to the development accounts. In the Network account, share the subnet with the application accounts.

Show answer & explanation

Answer: Enable resource sharing within AWS Organizations in the AWS RAM settings. In the Network account, use AWS Resource Access Manager (RAM) to share the private subnet with the application accounts. Purchase a Compute Savings Plan in the management account, and disable Savings Plan discount sharing for the development accounts under Billing Preferences in the Billing console.

Answer

Enable resource sharing within AWS Organizations, share the subnet via AWS RAM, purchase a Compute Savings Plan in the management account, and disable discount sharing for the development accounts under Billing Preferences in the Billing console.

The correct strategy requires enabling organization sharing in AWS Resource Access Manager (RAM) and creating a resource share in the Network account to distribute the subnet to the application accounts. To cover EC2, Fargate, and Lambda, a Compute Savings Plan must be purchased in the management account. The exclusion of specific accounts from receiving the Savings Plan discounts must be configured in the Billing Preferences of the management account, which allows fine-grained control over discount sharing.

Step-by-Step Solution

Enable sharing within AWS Organizations in the AWS RAM console of the management account, then create a resource share for the subnet in the Network account targeting the application accounts.

The application accounts are successfully able to launch resources (EC2, Fargate) into the shared subnet.

AWS RAM subnet sharing is only supported between accounts within the same AWS Organization and requires enabling the organization sharing setting.

Determine the correct Savings Plan type and purchase it in the management account.

Purchase a Compute Savings Plan.

Compute Savings Plans are the only type that applies to EC2, AWS Fargate, and AWS Lambda workloads combined. EC2 Instance Savings Plans only cover EC2.

Configure Billing Preferences in the Billing console of the management account to disable discount sharing for the development accounts.

Savings Plans discounts are applied to the management account and all other member accounts except the excluded development accounts.

By default, Savings Plans discounts are shared across all accounts in the billing family. Disabling sharing for specific accounts allows you to control which accounts benefit from the discount.

Key Concept

Multi-account resource sharing via AWS Resource Access Manager (RAM) and cost optimization using Compute Savings Plans under AWS Organizations.

Estimated Time:1m 30s

Question 758Question →

A telematics system processes telemetry data from a large fleet of commercial delivery vehicles. The architecture consists of an Application Load Balancer (ALB) routing traffic to an Auto Scaling group of EC2 instances, which perform write operations and heavy lookup queries against an Amazon Aurora PostgreSQL database. Every morning at 08:00 UTC, the fleet boots up simultaneously, causing telemetry traffic to spike instantly from $100$ requests per second to $150,000$ requests per second. During this time, database read latency increases significantly, causing API request timeouts. Which TWO steps should the solutions architect take to optimize the performance and scalability of this solution? (Select TWO.)

Select all that apply

Contact AWS Support to pre-warm the Application Load Balancer to handle the scheduled daily volume of

150,000

requests per second.

Deploy Aurora Replicas to offload read traffic, configure the application to use the reader endpoint for lookup queries, and apply an Aurora Auto Scaling policy.

Allow the Application Load Balancer to scale automatically using its default behavior, and set the Auto Scaling group cooldown period to

10

seconds to accelerate backend instance launching.

Configure the application to redirect lookup queries to the Amazon RDS Multi-AZ secondary standby instance during peak traffic hours.

Deploy Amazon ElastiCache for Memcached with multi-AZ replication enabled to cache the lookup results and maintain session state persistence.

Show answer & explanation

Answer: Contact AWS Support to pre-warm the Application Load Balancer to handle the scheduled daily volume of $150,000$ requests per second.; Deploy Aurora Replicas to offload read traffic, configure the application to use the reader endpoint for lookup queries, and apply an Aurora Auto Scaling policy.

Answer

To optimize the performance and scalability, the solutions architect should contact AWS Support to pre-warm the Application Load Balancer to handle the sudden morning spike, and deploy Aurora Replicas with Aurora Auto Scaling while directing lookup queries to the reader endpoint.

To successfully handle the sudden daily telemetry spike, two key bottlenecks must be addressed: the load balancer capacity and the database read load. First, the Application Load Balancer must be pre-warmed by contacting AWS Support, as the default scaling algorithm cannot scale up fast enough to handle an instantaneous

1,500\text{-fold}

increase in requests. Second, lookup query performance must be scaled by using Aurora Replicas. By configuring the application to target the Aurora reader endpoint and applying an Aurora Auto Scaling policy, the database tier can handle the read-heavy morning traffic without degrading the performance of the write operations on the primary instance.

Step-by-Step Solution

Analyze the load balancer scaling characteristics for flash traffic.

The traffic spikes from

100

150,000

requests per second instantaneously, which is a

1,500\text{-fold}

increase. The default ALB scaling mechanism is gradual and cannot keep pace, resulting in connection timeouts and dropped packets unless the ALB is pre-warmed.

Pre-warming the load balancer configures the underlying resources in advance to handle the expected spike volume.

Analyze the database performance bottleneck under heavy lookup queries.

Read operations against the primary instance increase query latency and cause API timeouts. Moving the lookup queries to read-only instances scales read operations horizontally.

Aurora Replicas allow the reader capacity to scale dynamically through the reader endpoint without impacting the primary writer instance.

Identify best practices for scaling read-heavy database architectures in AWS.

Configuring Aurora Auto Scaling to dynamically provision Aurora Replicas based on CPU utilization or connection count ensures performance during peak demand while managing cost during off-peak hours.

This provides automated scalability that matches the load profile of the morning spike.

Key Concept

Load Balancer Pre-warming and Database Read Scaling

Question 759Question →

A digital marketing firm is launching a flash sale campaign for a major retail event. The campaign website is expected to receive an immediate burst of $5 \times 10^6$ page views within the first $10$ minutes of the launch. The current architecture consists of an Application Load Balancer (ALB) routing traffic to an Auto Scaling group of Amazon EC2 instances. What pre-launch action should the solutions architect take to ensure the application does not experience dropped connections or latency spikes at the start of the event?

Contact AWS Support to pre-warm the Application Load Balancer with the expected traffic profile, and configure scheduled scaling actions for the Auto Scaling group.

Rely on the default auto-scaling behavior of the Application Load Balancer to dynamically scale out as the traffic arrives during the first few minutes.

Deploy an Amazon RDS Multi-AZ database and route the read traffic directly to the RDS standby replica during the initial traffic spike.

Configure a very short cooldown period on the Auto Scaling group's target tracking scaling policy to ensure instances scale out as fast as possible.

Show answer & explanation

Answer: Contact AWS Support to pre-warm the Application Load Balancer with the expected traffic profile, and configure scheduled scaling actions for the Auto Scaling group.

Answer

Contact AWS Support to pre-warm the Application Load Balancer with the expected traffic profile, and configure scheduled scaling actions for the Auto Scaling group.

The correct action is to contact AWS Support to pre-warm the Application Load Balancer and schedule scaling for the Auto Scaling group. This combination ensures that both the ingress tier (ALB) and the application tier (EC2) have sufficient capacity provisioned in advance of the flash sale, avoiding latency and connection drop issues.

Step-by-Step Solution

Analyze the traffic pattern.

The application expects an immediate, massive burst of

5 \times 10^6

page views within

10

minutes, which is a classic flash-crowd scenario.

Understanding the flash nature of the traffic helps rule out reactive scaling mechanisms which are too slow to respond.

Evaluate the ingress tier scaling requirements.

The Application Load Balancer (ALB) must be pre-warmed by AWS Support to handle the immediate burst without dropping connections.

ALBs scale automatically but require time to handle multi-million request spikes. Pre-warming prepares the ALB capacity in advance.

Evaluate the backend tier scaling requirements.

Configure scheduled scaling actions to launch backend EC2 instances in the Auto Scaling group prior to the event start.

Scheduled scaling ensures capacity is online and bootstrapped before the traffic spike begins, preventing latency during instance startup.

Key Concept

ELB Pre-warming and Scheduled Scaling for Flash Traffic

Question 760Question →

A company is designing a disaster recovery (DR) strategy for its internal HR portal. The application runs on Amazon EC2 instances behind an Application Load Balancer in a Multi-AZ configuration, using an Amazon RDS for PostgreSQL database. The business requires a Recovery Time Objective (RTO) of 4 hours and a Recovery Point Objective (RPO) of 24 hours. The solutions architect must design a cost-effective solution that minimizes ongoing idle resource costs. Which two actions should the solutions architect take to meet these requirements?

Select all that apply

Configure daily automated backups of the Amazon RDS database and copy the snapshots to a secondary AWS Region.

Store the application server configuration as an Amazon Machine Image (AMI), copy the AMI to a secondary AWS Region, and maintain an AWS CloudFormation template to provision the application infrastructure in the secondary Region only during a disaster.

Deploy a cross-region Amazon RDS Read Replica in the secondary AWS Region and configure Amazon Aurora Replica Auto Scaling to dynamically adjust replica capacity.

Configure a Route 53 Private Hosted Zone for the portal in the secondary Region's VPC without associating it with the primary Region's VPC, relying on default cross-VPC DNS inheritance.

Deploy a single NAT Gateway in one Availability Zone in the primary Region and route all outbound internet traffic from all private subnets through it to reduce gateway hourly charges.

Show answer & explanation

Answer: Configure daily automated backups of the Amazon RDS database and copy the snapshots to a secondary AWS Region.; Store the application server configuration as an Amazon Machine Image (AMI), copy the AMI to a secondary AWS Region, and maintain an AWS CloudFormation template to provision the application infrastructure in the secondary Region only during a disaster.

Answer

Configure daily automated backups of the Amazon RDS database and copy the snapshots to a secondary AWS Region, and store the application server configuration as an Amazon Machine Image (AMI), copy the AMI to a secondary AWS Region, and maintain an AWS CloudFormation template to provision the application infrastructure in the secondary Region only during a disaster.

The correct strategy combines daily database snapshots copied to a secondary region with on-demand infrastructure provisioning using AMIs and CloudFormation. Since the database is backed up daily, the 24-hour RPO is met. Restoring the database from a snapshot and deploying the application tier using CloudFormation can easily be completed within the 4-hour RTO. This minimizes ongoing idle costs since no compute or database resources run in the secondary region during normal operations.

Step-by-Step Solution

Evaluate the RTO and RPO constraints against the disaster recovery options.

An RTO of 4 hours and RPO of 24 hours can be achieved using a cost-effective Backup and Restore strategy, which does not require active resources to run in the secondary region.

This step determines the most appropriate DR pattern to meet the customer's cost-efficiency goal.

Determine the database backup and transfer strategy.

Daily snapshots meet the 24-hour RPO requirement, and copying them to a secondary region ensures data durability without ongoing database instance costs.

This step secures the database data according to the RPO constraint.

Determine the compute tier restoration strategy.

Storing application server configurations as AMIs and using CloudFormation templates allows the environment to be constructed on-demand within the 4-hour RTO.

This step ensures that the compute resources can be deployed quickly during a disaster without incurring costs during normal operations.

Key Concept

For applications with non-critical RTO (hours) and RPO (24 hours or more), a Backup and Restore disaster recovery pattern is the most cost-effective solution. It avoids ongoing running costs in the recovery region by copying offline assets (database snapshots and AMIs) and deploying the environment using automation (CloudFormation) only when a failover is initiated.

Estimated Time:2m 0s

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

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