All practice questions

1964 questions

All types1,964 Multiple choice1,006 Multiple select931 Ordering27

An enterprise has a multi-account AWS Organizations structure. An application hosted on Amazon EC2 instances in private subnets of a production VPC needs to read and write sensitive files in an Amazon S3 bucket. Currently, the S3 bucket is configured with default encryption using the AWS-managed key (aws/s3). The production VPC is connected to an on-premises data center via AWS Transit Gateway.

The security team has established the following new security mandates for this workload:
1. All S3 bucket access must be restricted to the production VPC, preventing public internet access or access from other VPCs.
2. The S3 data must be encrypted using a key that supports rotation and cross-account access delegated to a central security account.
3. On-premises client machines must be able to securely access the S3 bucket through the Transit Gateway connection and resolve the bucket's DNS names.

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

Select all that apply

Create an S3 Interface VPC endpoint in the production VPC. Set up a Route 53 Resolver Inbound Endpoint in the production VPC to allow the on-premises DNS servers to resolve the private DNS names of the S3 endpoint.

In the central security account, create a Customer Managed KMS key. Configure the key policy to allow the production account's application IAM role to perform cryptographic operations. Update the S3 bucket's default encryption configuration to use this key.

Configure the S3 bucket's default encryption to use the AWS-managed key (aws/s3) in the central security account, and grant the application IAM role access to the key using an IAM policy in the production account.

Create an S3 Gateway VPC endpoint in the production VPC. Associate the gateway endpoint with the production VPC's route tables, and configure Route 53 Resolver Outbound Endpoints to forward S3 DNS queries from on-premises to the VPC.

Create a Service Control Policy (SCP) in the central security Organization root that explicitly allows the production account's IAM role to perform cryptographic operations on the AWS-managed S3 key, and attach this SCP to the production OU.

Show answer & explanation

Answer: Create an S3 Interface VPC endpoint in the production VPC. Set up a Route 53 Resolver Inbound Endpoint in the production VPC to allow the on-premises DNS servers to resolve the private DNS names of the S3 endpoint.; In the central security account, create a Customer Managed KMS key. Configure the key policy to allow the production account's application IAM role to perform cryptographic operations. Update the S3 bucket's default encryption configuration to use this key.

Answer

Create an S3 Interface VPC endpoint combined with a Route 53 Resolver Inbound Endpoint, and create a Customer Managed KMS key in the central security account with a key policy allowing the production account's application IAM role access.

To satisfy both network and identity security requirements: First, S3 Interface VPC endpoints (PrivateLink) are required for on-premises client access over AWS Transit Gateway because S3 Gateway VPC endpoints do not support routing from on-premises networks. A Route 53 Resolver Inbound Endpoint must be created in the VPC to allow on-premises DNS servers to forward queries to resolve S3 endpoint names. Second, a Customer Managed KMS key in the central security account must be used because AWS-managed keys (such as aws/s3) cannot be shared across accounts. A key policy on the Customer Managed KMS key must explicitly grant permissions to the production account's application IAM role.

Step-by-Step Solution

Evaluate S3 access path and connectivity requirements from on-premises.

Determine that S3 Gateway VPC endpoints cannot handle traffic originating from on-premises via VPN or Transit Gateway. Select an S3 Interface VPC endpoint (PrivateLink) instead, which generates private IPs in the VPC that are routable over Transit Gateway.

Ensures that on-premises clients can reach S3 privately and securely.

Address DNS resolution for on-premises clients.

Configure a Route 53 Resolver Inbound Endpoint in the production VPC and configure on-premises DNS forwarders.

Allows on-premises DNS queries to resolve the private IP addresses of the S3 Interface VPC endpoint.

Analyze cross-account KMS encryption requirement.

Recognize that AWS-managed KMS keys (aws/s3) cannot be shared cross-account because their policies cannot be edited. Decide to use a Customer Managed Key (CMK) in the central security account.

Satisfies the security mandate of using a key with cross-account access and custom rotation rules.

Configure cross-account KMS permissions.

Add the production application's IAM role ARN as a key user in the central account's CMK policy, and configure default encryption on the S3 bucket to target this KMS key.

Grants the necessary encrypt/decrypt permissions securely across accounts.

Key Concept

Cross-account KMS key sharing and private hybrid connectivity to S3 via Interface VPC Endpoints and Route 53 Resolver Inbound Endpoints

Question 1182Question →

A company runs a high-traffic e-commerce application on Amazon EC2 instances in an Auto Scaling group behind an Application Load Balancer (ALB). The application uses an Amazon RDS for PostgreSQL DB instance configured in a Multi-AZ deployment. During scheduled flash sale events, the application experiences severe performance issues. Database metrics show that CPU utilization on the primary DB instance spikes to $95\%$ and read latency increases significantly. Additionally, during the first few minutes of a flash sale, users experience HTTP 502 Bad Gateway and 504 Gateway Timeout errors, even though the Auto Scaling group begins launching new instances. Which combination of actions will resolve these performance bottlenecks?

Deploy Amazon RDS for PostgreSQL Read Replicas to offload read queries from the primary database instance, and contact AWS Support to pre-warm the Application Load Balancer before the scheduled flash sale events.

Configure the application to route read queries to the secondary Amazon RDS standby instance in the other Availability Zone to distribute the load, and set up an Auto Scaling Warm Pool for the EC2 instances.

Deploy Amazon RDS for PostgreSQL Read Replicas to offload read queries, and configure the Application Load Balancer with cross-zone load balancing enabled to handle the sudden traffic spikes without requiring manual pre-warming.

Deploy Amazon RDS for PostgreSQL Read Replicas to offload read queries, and reduce the Auto Scaling group's scaling cooldown period to a duration shorter than the instance initialization time to accelerate the launch of new instances.

Show answer & explanation

Answer: Deploy Amazon RDS for PostgreSQL Read Replicas to offload read queries from the primary database instance, and contact AWS Support to pre-warm the Application Load Balancer before the scheduled flash sale events.

Answer

Deploying Amazon RDS for PostgreSQL Read Replicas to offload read queries from the primary database instance, and contacting AWS Support to pre-warm the Application Load Balancer before the scheduled flash sale events.

Deploying Read Replicas offloads the heavy read load from the primary RDS PostgreSQL instance, reducing its CPU and storage I/O utilization. Pre-warming the Application Load Balancer ensures that its internal nodes are pre-provisioned to handle the massive, sudden spike in traffic, avoiding HTTP 502 and 504 errors caused by scaling latency.

Step-by-Step Solution

Identify database bottleneck.

The primary DB instance has

95\%

CPU utilization and high read latency due to handling both read and write workloads.

Read traffic needs to be offloaded to separate compute/storage resources.

Choose appropriate database scaling option.

Deploy RDS Read Replicas to handle read queries, leaving the primary instance to handle writes.

RDS Multi-AZ standby instances cannot serve read traffic.

Address the ALB scaling latency.

Request AWS Support to pre-warm the ALB to the expected traffic volume before the flash sale.

Auto-scaling triggers are too slow for instant flash traffic spikes, leading to dropped connections.

Key Concept

Scaling database read capacity using Read Replicas and managing sudden traffic spikes on load balancers via ELB pre-warming.

Question 1183Question →

A global telematics SaaS platform has a multi-account AWS architecture. The core application backend runs on Amazon EC2 instances in private subnets across multiple Availability Zones in a Spoke VPC in ` $us-east-1$ `. The application is deployed behind an Application Load Balancer (ALB). The Spoke VPC connects to a Shared Services VPC and an on-premises data center via an AWS Transit Gateway.

The application resolves internal endpoints using a Route 53 Private Hosted Zone (PHZ) hosted in the Shared Services VPC.

The platform experiences two recurring issues:
1. Every morning at ` $9:00\text{ AM}$ `, a sudden burst of vehicle telemetry data causes immediate connection timeouts and latency spikes for users, which gradually resolve after ` $10\text{ to }15$ ` minutes.
2. Intermittent DNS resolution failures occur when the application attempts to resolve service names in the Shared Services VPC.

The company requires a solution that minimizes latency, prevents dropped connections during traffic spikes, and ensures highly available, private DNS resolution.

Which TWO actions should the Solutions Architect recommend to optimize performance and resolve these issues?

Select all that apply

Request AWS Support to pre-warm the Application Load Balancer in the Spoke VPC before the daily peak traffic window to handle the sudden surge in connections without latency or dropouts.

Associate the Route 53 Private Hosted Zone from the Shared Services VPC with the Spoke VPC to enable direct and low-latency DNS resolution of internal services.

Direct all outbound traffic from the Spoke VPC to a single NAT Gateway located in one Availability Zone to minimize latency by avoiding cross-AZ routing for outbound internet traffic.

Establish a Direct Connect Gateway to route VPC-to-VPC traffic transitively between multiple Spoke VPCs to bypass the Transit Gateway and reduce latency.

Deploy a Route 53 Resolver outbound endpoint in the Spoke VPC to query the Shared Services VPC DNS endpoints instead of associating the Private Hosted Zone with the Spoke VPC.

Show answer & explanation

Answer: Request AWS Support to pre-warm the Application Load Balancer in the Spoke VPC before the daily peak traffic window to handle the sudden surge in connections without latency or dropouts.; Associate the Route 53 Private Hosted Zone from the Shared Services VPC with the Spoke VPC to enable direct and low-latency DNS resolution of internal services.

Answer

To optimize network performance and resolve the latency and DNS issues, the architect must request AWS Support to pre-warm the Application Load Balancer before the daily peak traffic window, and associate the Route 53 Private Hosted Zone from the Shared Services VPC with the Spoke VPC.

Pre-warming the Application Load Balancer ensures that sufficient processing capacity is provisioned ahead of the telemetry burst, eliminating the connection timeouts caused by scaling lag. Associating the Route 53 Private Hosted Zone directly with the Spoke VPC ensures that DNS queries for internal services are resolved locally with minimal latency, bypassing any external DNS forwarding overhead.

Step-by-Step Solution

Analyze the telemetry ingest bottleneck at peak times.

Identify that the sudden burst of connection requests causes ALB scaling lag, leading to timeouts.

ALB scaling requires time to provision additional capacity during sharp traffic spikes; pre-warming ensures capacity is ready in advance.

Analyze the intermittent DNS resolution failures for shared services.

Identify that the Spoke VPC is not associated with the Private Hosted Zone in the Shared Services VPC.

A Route 53 Private Hosted Zone must be explicitly associated with a VPC to allow instances in that VPC to resolve the private DNS names.

Key Concept

Optimizing network performance for sudden traffic spikes requires proactive load balancer scaling (pre-warming), while private DNS resolution across multiple VPCs requires correct Private Hosted Zone association.

Question 1184Question →

A financial services firm hosts its transactional ledger on Amazon DynamoDB tables within a Production AWS account. The tables currently use AWS owned keys for encryption at rest. To meet new compliance requirements, the solutions architect must enhance data protection by implementing customer-managed keys with automatic key rotation, and automated cross-account backups to a centralized, read-only Security account within AWS Organizations. The design must ensure that administrators in the Production account cannot modify or delete the copied backups. Which combination of actions should the solutions architect take to meet these compliance requirements? (Select TWO.)

Select all that apply

Update the DynamoDB tables to use a customer managed KMS key in the Production account, and enable automatic key rotation on the key.

In the Security account, create an AWS Backup vault encrypted with a customer managed KMS key, and apply a vault policy that allows the Production account to copy backups into it. In the Production account, configure an AWS Backup plan to back up the tables to a source vault encrypted with a customer managed KMS key, and configure a copy action to the Security account vault.

Modify the DynamoDB tables to use the AWS-managed KMS key aws/dynamodb. In the Security account, create an AWS Backup vault encrypted with the AWS-managed key aws/backup, and use AWS Backup to copy the backups from the Production account directly into this vault.

Create a Service Control Policy (SCP) at the organization root that explicitly allows the backup:CopyIntoBackupVault action for the Production account. Rely on this SCP to grant the necessary write permissions to the destination vault in the Security account without modifying the destination vault's access policy.

Export the DynamoDB tables to Amazon S3 in the Security account using Amazon DynamoDB features. Configure the destination S3 bucket policy to allow the s3:PutObject action using a wildcard principal with an aws:PrincipalOrgID condition, omitting the specific root principal of the Production account.

Show answer & explanation

Answer: Update the DynamoDB tables to use a customer managed KMS key in the Production account, and enable automatic key rotation on the key.; In the Security account, create an AWS Backup vault encrypted with a customer managed KMS key, and apply a vault policy that allows the Production account to copy backups into it. In the Production account, configure an AWS Backup plan to back up the tables to a source vault encrypted with a customer managed KMS key, and configure a copy action to the Security account vault.

Answer

Update the DynamoDB tables to use a customer managed KMS key in the Production account with automatic rotation. In the Security account, create a backup vault encrypted with a customer managed KMS key and configure its vault policy to allow copy actions from the Production account. In the Production account, configure an AWS Backup plan to back up the tables to a vault encrypted with a customer managed key, and add a copy action targeting the Security account vault.

Updating the DynamoDB tables to use a customer managed KMS key satisfies the requirement for encryption with automatic rotation. Furthermore, using AWS Backup with customer managed KMS keys in both the source Production account and the destination Security account enables cross-account backup replication within AWS Organizations. The destination vault policy in the Security account is configured to grant copy permissions to the Production account, which is secure and fully supported.

Step-by-Step Solution

Enable Customer Managed KMS Keys for DynamoDB

DynamoDB table encryption is updated from AWS owned keys to a Customer Managed KMS key in the Production account, and automatic rotation is enabled.

This satisfies the requirement to use customer-managed encryption keys with automatic annual rotation.

Create Centralized Destination Backup Vault

A destination backup vault is configured in the Security account, encrypted with a Customer Managed KMS key owned by the Security account.

AWS Backup cross-account copy operations require a customer managed KMS key in the destination account because AWS-managed keys (like aws/backup) cannot be shared or modified with cross-account access policies.

Configure Cross-Account Access Policy and Copy Jobs

A vault policy is attached to the destination vault allowing copy actions from the Production account. An AWS Backup plan in the Production account is configured to copy backups to the Security account vault.

This establishes the secure, automated path for replication while allowing the Security account to lock down access permissions.

Key Concept

Cross-account copying using AWS Backup requires the destination backup vault to be encrypted with a Customer Managed KMS key (CMK). AWS-managed KMS keys cannot be shared across accounts or have their key policies edited.

Alternative Method

While AWS Backup is the standard and recommended tool for managing compliance backups, another method involves using DynamoDB global tables replicated to a replica table in the Security account, though this does not yield point-in-time recovery backups isolated from Production delete actions as effectively as AWS Backup.

Estimated Time:3m 0s

Question 1185Question →

An online education SaaS provider manages its multi-account environment using AWS Organizations. Student record archives containing personally identifiable information (PII) are stored in an Amazon S3 bucket within each regional business unit's AWS account. Currently, these S3 buckets are encrypted using the default AWS managed key (aws/s3). The compliance team in a centralized Security account needs to audit these records by running read-only analysis tools that access the buckets directly. The solutions architect must enhance the data protection strategy to enforce encryption using keys that support automatic rotation, while allowing the compliance team's read-only tools to decrypt and audit the data. Which combination of actions will meet these requirements? (Select TWO.)

Select all that apply

Create a customer managed KMS key in each business unit's AWS account with automatic key rotation enabled. Update the KMS key policy in each account to grant the centralized Security account's audit IAM role the kms:Decrypt permission.

Update the S3 bucket policy in each business unit's AWS account to grant the centralized Security account's audit IAM role the s3:GetObject permission. Configure the S3 default bucket encryption to use the newly created customer managed KMS key.

Configure the existing S3 buckets to continue using the AWS managed key (aws/s3) for encryption, and add cross-account trust permissions for the Security account's audit role inside the aws/s3 key policy.

Apply a Service Control Policy (SC) at the AWS Organizations Root level that grants the centralized Security account's audit IAM role read permissions to all S3 buckets and KMS keys in the member accounts.

Enable AWS CloudTrail in each business unit account to log S3 data events, directing the trails to a centralized S3 bucket in the Security account, while relying on the default S3 bucket policy of the centralized bucket without adding explicit cross-account permissions for CloudTrail.

Show answer & explanation

Answer: Create a customer managed KMS key in each business unit's AWS account with automatic key rotation enabled. Update the KMS key policy in each account to grant the centralized Security account's audit IAM role the kms:Decrypt permission.; Update the S3 bucket policy in each business unit's AWS account to grant the centralized Security account's audit IAM role the s3:GetObject permission. Configure the S3 default bucket encryption to use the newly created customer managed KMS key.

Answer

To enhance data protection and allow cross-account auditing, create a customer managed KMS key in each business unit account with automatic key rotation enabled, grant the Security account's audit role decryption permissions in the key policy, and update the S3 bucket policies in the business unit accounts to grant object read access to the audit role while configuring default encryption to use the new customer managed key.

For cross-account access to S3 objects encrypted with SSE-KMS, permissions must be granted on both the S3 bucket (via bucket policy) and the KMS key (via key policy). Using a customer managed KMS key is necessary because AWS managed keys (aws/s3) cannot be shared across accounts. Enabling automatic rotation on the customer managed keys fulfills the compliance requirement, and the key policy must grant decrypt permissions to the audit role.

Step-by-Step Solution

Evaluate the current encryption configuration and recognize key sharing constraints.

Confirm that the default AWS managed key (aws/s3) cannot be shared across accounts due to the inability to modify its key policy.

This establishes the requirement to provision customer managed KMS keys.

Configure encryption keys with compliance and access permissions.

Create customer managed KMS keys in the business unit accounts, enable automatic key rotation, and update their key policies to allow the Security account's audit IAM role to decrypt.

This satisfies the automatic rotation requirement and delegates cross-account decryption rights.

Configure the S3 bucket access permissions.

Configure default bucket encryption to use the new customer managed key and update the bucket policy to grant the Security account's audit IAM role s3:GetObject permissions.

This completes the permission chain required for cross-account S3 object retrieval.

Key Concept

Cross-account access to S3 objects encrypted with customer managed KMS keys

Estimated Time:2m 0s

Question 1186Question →

A company is designing a new global relational Online Transaction Processing (OLTP) application. The application will be deployed in a primary AWS Region (us-east-1) and a secondary AWS Region (us-west-2). The database must support a local write latency of less than 20 ms in the primary region, and a read latency of less than 5 ms in both regions. The disaster recovery strategy must achieve a Recovery Time Objective (RTO) of less than 1 minute and a Recovery Point Objective (RPO) of less than 2 seconds. Additionally, all database storage must be encrypted at rest using encryption keys that support automatic rotation and can be shared with a central auditing AWS account.

Which database and storage strategy meets these requirements with the lowest operational overhead?

Deploy Amazon RDS for PostgreSQL in us-east-1 in a Multi-AZ deployment. Create a cross-region read replica in us-west-2. Configure the standby instance of the us-east-1 Multi-AZ deployment to serve local read traffic to meet the read latency target. Encrypt the database instances using the default AWS managed key (aws/rds), and update its key policy to grant access to the central auditing AWS account.

Deploy Amazon Aurora PostgreSQL in us-east-1. Set up an AWS Database Migration Service (DMS) task with Change Data Capture (CDC) to replicate data to a separate Aurora cluster in us-west-2. Encrypt the database clusters in both regions using the default AWS managed key (aws/rds), and update the key policy to grant cross-account decryption permissions to the central auditing account.

Deploy an Amazon Aurora PostgreSQL Global Database with the primary cluster in us-east-1 and a secondary cluster in us-west-2. Enable Aurora Auto Scaling for readers in both clusters. Encrypt the database clusters using an AWS KMS customer managed key, and configure its key policy to delegate access to the central auditing account.

Deploy Amazon RDS for PostgreSQL in us-east-1 in a Multi-AZ deployment. Replicate DB snapshots hourly to us-west-2. In the event of a primary region disaster, use AWS CloudFormation to restore the database in us-west-2 from the latest replicated snapshot. Encrypt the database using an AWS KMS customer managed key, and delegate access to the central auditing account via its key policy.

Show answer & explanation

Answer: Deploy an Amazon Aurora PostgreSQL Global Database with the primary cluster in us-east-1 and a secondary cluster in us-west-2. Enable Aurora Auto Scaling for readers in both clusters. Encrypt the database clusters using an AWS KMS customer managed key, and configure its key policy to delegate access to the central auditing account.

Answer

The correct strategy utilizes Amazon Aurora Global Database to achieve low-latency cross-region replication (RPO < 2 seconds) and rapid failover capabilities (RTO < 1 minute). To scale reads dynamically and maintain latency under 5 ms, Aurora Auto Scaling is used to adjust reader replica counts. For security compliance, a Customer Managed Key (CMK) in AWS KMS is required because its key policy can be modified to delegate cross-account access to the central auditing account, whereas AWS managed keys cannot be shared cross-account.

Step-by-Step Solution

Evaluate the disaster recovery requirements (RPO < 2 seconds, RTO < 1 minute).

Identify that standard backup-and-restore or snapshot replication strategies are insufficient, and native database replication (such as Amazon Aurora Global Database) is required to meet these targets.

Ensures the selected replication mechanism satisfies the near-zero data loss and rapid recovery time requirements.

Assess the read latency constraint of less than 5 ms in both regions under dynamic traffic.

Recognize that read replicas with auto-scaling are needed to scale read capacity horizontally. Standby instances in RDS Multi-AZ deployments do not support read traffic.

Guarantees read requests are served locally in each region within the latency threshold, scaling dynamically as load changes.

Evaluate key management options in AWS KMS for database storage encryption at rest.

Determine that an AWS KMS customer managed key must be used instead of an AWS managed key.

AWS managed keys cannot be modified and do not support cross-account sharing, which is required to delegate decrypt access to the central auditing account.

Key Concept

Designing multi-region database replication, read scaling, and access control policies using Amazon Aurora Global Database and AWS KMS Customer Managed Keys.

Estimated Time:3m 0s

Question 1187Question →

An enterprise is planning to migrate a three-tier application to AWS within a strict 6-month timeline. The application components and constraints are as follows:

* Web Tier: IIS web servers currently running on Windows Server 2012 R2. The enterprise wants to upgrade the operating system to Windows Server 2022 during the migration to maintain support, but lacks developer capacity to perform any application code modifications.
* Database Tier: An on-premises Oracle Database 12c instance. To eliminate licensing costs, the enterprise wants to migrate to Amazon Aurora PostgreSQL and has hired a systems integrator to rewrite the stored procedures and application database access code.
* Reporting Tier: A proprietary application running on legacy Solaris SPARC hardware. The vendor is defunct, the application cannot run on x86 architectures, and rebuilding it will take 18 months. The application is only used to generate historical quarterly archives, and the enterprise can extend the physical hardware lease on-premises.

Which combination of migration strategies (7 Rs) represents the most appropriate path for each tier?

Replatform the web tier, Refactor the database tier, and Retain the reporting tier

Replatform the web tier, Replatform the database tier, and Retain the reporting tier

Rehost the web tier, Refactor the database tier, and Retire the reporting tier

Refactor the web tier, Refactor the database tier, and Rehost the reporting tier

Show answer & explanation

Answer: Replatform the web tier, Refactor the database tier, and Retain the reporting tier

Answer

Replatform the web tier, Refactor the database tier, and Retain the reporting tier

The correct strategy maps Replatform to the web tier, Refactor to the database tier, and Retain to the reporting tier. Upgrading the OS to Windows Server 2022 without modifying application code constitutes a Replatform strategy. A heterogeneous migration from Oracle to Aurora PostgreSQL involves converting database schemas and rewriting application-level code, which constitutes Refactoring. Retaining the reporting tier on-premises is appropriate because the SPARC architecture cannot be migrated directly to AWS x86 infrastructure, rebuilding it violates the 6-month timeline, and the business still requires its outputs.

Step-by-Step Solution

Evaluate the Web Tier requirements.

Identify that the OS must be upgraded (Windows Server 2012 R2 to 2022) but the code cannot be modified.

Upgrading the underlying operating system or platform version without changing the core application architecture or code is a classic Replatform (lift-tinker-and-shift) migration path.

Evaluate the Database Tier requirements.

Identify that a heterogeneous migration is planned (Oracle to Amazon Aurora PostgreSQL) requiring schema conversion and code rewrites.

Moving from Oracle to PostgreSQL requires changing the database engine, converting schemas, and rewriting application queries/stored procedures, which constitutes a Refactor (re-architect) strategy.

Evaluate the Reporting Tier requirements.

Identify that the tier runs on Solaris SPARC (non-x86), cannot run on standard AWS x86 platforms, rebuilding takes 18 months (exceeding the 6-month window), and the system is still needed for quarterly reporting.

Since the workload cannot be migrated to AWS due to hardware architecture constraints and timeline, but must remain operational, the system should be kept on-premises, representing a Retain strategy.

Key Concept

Selecting migration strategies based on the AWS 7 Rs framework (Rehost, Replatform, Refactor, Repurchase, Retain, Retire, Relocate) by analyzing workload constraints, platform architecture, and target architectures.

Question 1188Question →

A financial technology company has an existing application running in a production AWS account. The application stores daily payment transaction audit files in an Amazon S3 bucket. Currently, the bucket is configured with default server-side encryption using the AWS managed key (`aws/s3`). For audit compliance, a third-party auditing firm needs to retrieve these files daily from their own AWS account using a dedicated IAM role. A solutions architect must configure the environment to allow this cross-account access while maintaining data protection standards. Which configuration changes will meet these requirements?

Transition the S3 bucket default encryption to a new Customer Managed Key (CMK) in the production account. Configure the KMS key policy of the CMK to grant `kms:Decrypt` and `kms:GenerateDataKey` permissions to the external auditing firm's IAM role, and update the S3 bucket policy in the production account to allow the auditing role read access to the objects.

Configure the default AWS managed key (`aws/s3`) key policy in the production account to grant `kms:Decrypt` permissions to the external auditing firm's IAM role. Modify the S3 bucket policy in the production account to grant read access to the auditing role.

Keep using the AWS managed key (`aws/s3`) for default encryption. Attach a Service Control Policy (SCP) at the Organizational Unit (OU) level of the production account that explicitly grants `kms:Decrypt` and `s3:GetObject` permissions to the external auditing firm's IAM role.

Create a new Customer Managed Key (CMK) in the production account and configure its key policy to grant the external auditing firm's IAM role `kms:Decrypt` and `kms:GenerateDataKey` permissions. Do not modify the S3 bucket policy, relying on the KMS key policy to delegate the cross-account access.

Show answer & explanation

Answer: Transition the S3 bucket default encryption to a new Customer Managed Key (CMK) in the production account. Configure the KMS key policy of the CMK to grant `kms:Decrypt` and `kms:GenerateDataKey` permissions to the external auditing firm's IAM role, and update the S3 bucket policy in the production account to allow the auditing role read access to the objects.

Answer

Transition the S3 bucket default encryption to a new Customer Managed Key (CMK) in the production account, configure the KMS key policy of the CMK to grant permissions to the external auditing firm's IAM role, and update the S3 bucket policy to allow the auditing role read access.

The correct option outlines the required architectural change: transitioning from the immutable AWS managed KMS key to a Customer Managed KMS key (CMK). The key policy of the CMK must explicitly delegate decrypt permissions to the external auditing firm's IAM role, and the S3 bucket policy must also explicitly allow the external role to perform the read actions (`s3:GetObject`). This dual-authorization mechanism is required for cross-account S3 access involving KMS encryption.

Step-by-Step Solution

Evaluate the encryption key type used for S3 default encryption.

The current configuration uses the AWS managed key (`aws/s3`), which cannot be shared across accounts because its key policy is immutable.

To support cross-account decryption, the encryption key must be transitioned to a Customer Managed Key (CMK).

Create and configure a Customer Managed Key (CMK) in the source production account.

A new CMK is created, and its key policy is modified to grant `kms:Decrypt` and `kms:GenerateDataKey` permissions to the external auditing firm's IAM role principal.

This enables the external role to decrypt the data keys used to encrypt the S3 objects when retrieving them.

Modify the S3 bucket policy in the production account.

An S3 bucket policy is attached/updated to grant `s3:GetObject` and related read permissions to the external auditing firm's IAM role.

For cross-account S3 access, the destination account's principal must be explicitly allowed by the source bucket policy.

Key Concept

Cross-account access to S3 buckets encrypted with KMS requires Customer Managed Keys (CMKs) because AWS managed KMS keys cannot be shared cross-account, and access must be granted in both the S3 bucket policy and the KMS key policy.

Question 1189Question →

An enterprise manages a web application infrastructure deployed via AWS CloudFormation. The stack includes an Auto Scaling Group (ASG) of Amazon EC2 instances behind an Application Load Balancer (ALB). The instances use AWS Systems Manager State Manager to run an association that installs security agents and configures application dependencies, which takes approximately 8 minutes.

During a recent traffic spike, the enterprise faced two major issues:
1. The ASG rapidly launched multiple new instances. However, because the instance bootstrapping took longer than the default cooldown period, the ASG continuously launched unnecessary instances before the initial ones could start serving traffic, exhausting the regional vCPU quota. Additionally, new instances were registered with the ALB and began receiving traffic before the State Manager association completed, causing client request failures.
2. A subsequent CloudFormation stack update failed and rolled back because operators had manually adjusted security group rules and EC2 instance types directly in the console to mitigate the traffic spike.

Which design strategy should a solutions architect implement to automate deployment, secure configuration compliance, and resolve the drift issues?

Implement an AWS CodePipeline that uses AWS CodeDeploy to perform a rolling update of the application configurations on the EC2 instances. Set the CodeDeploy deployment configuration to use a linear traffic-shifting strategy. To resolve configuration drift, configure AWS Config to trigger a custom AWS Lambda function that automatically terminates any drifted EC2 instance and deletes modified security groups to force CloudFormation to recreate them during the next stack run.

Configure the Application Load Balancer health check grace period to 10 minutes to allow the State Manager association to complete. Decrease the Auto Scaling scaling policy's cooldown period to 3 minutes to ensure the group can respond quickly to traffic spikes. To resolve configuration drift, enable automatic drift remediation in the AWS CloudFormation stack settings so that the service automatically reverts any manual console modifications during subsequent stack updates.

Configure an Auto Scaling lifecycle hook for the transition to pause the instance in a wait state during launch. Update the Systems Manager State Manager association to execute the configuration script and run a command that invokes the complete-lifecycle-action API once configuration is successful. Increase the Auto Scaling group scaling policy's cooldown period to be greater than the 8-minute bootstrapping time. To manage drift, perform CloudFormation drift detection, and manually or programmatically revert the drifted resource attributes to match the template before running stack updates.

Configure an Auto Scaling lifecycle hook for the transition and invoke it via an EC2 User Data script that calls the complete-lifecycle-action API immediately upon instance startup. Set the Auto Scaling group's cooldown period to zero to prevent delayed scaling. To prevent configuration drift, attach a Service Control Policy (SCP) to the organization unit that denies the ec2:ModifyInstanceAttribute and ec2:AuthorizeSecurityGroupIngress actions for all principals, assuming this policy grants exclusive update permissions to the CloudFormation service role.

Show answer & explanation

Answer: Configure an Auto Scaling lifecycle hook for the transition to pause the instance in a wait state during launch. Update the Systems Manager State Manager association to execute the configuration script and run a command that invokes the complete-lifecycle-action API once configuration is successful. Increase the Auto Scaling group scaling policy's cooldown period to be greater than the 8-minute bootstrapping time. To manage drift, perform CloudFormation drift detection, and manually or programmatically revert the drifted resource attributes to match the template before running stack updates.

Answer

Configure an Auto Scaling lifecycle hook to pause the launching instance, update the Systems Manager State Manager association to complete the lifecycle hook upon configuration completion, increase the ASG scaling policy's cooldown period to exceed the bootstrap time, and use CloudFormation drift detection to identify and revert drifted resource attributes prior to running stack updates.

The correct strategy uses an Auto Scaling lifecycle hook to keep the launching instances in a wait state until the State Manager association completes and signals completion via the CLI/API. Increasing the cooldown period beyond the bootstrap time prevents premature scale-out events. Performing drift detection and manually or programmatically aligning the resource configurations with the template prevents stack update failures.

Step-by-Step Solution

Implement an Auto Scaling lifecycle hook for the EC2_INSTANCE_LAUNCHING transition.

Newly launched EC2 instances are paused in the Pending:Wait state, preventing them from registering with the Application Load Balancer and receiving traffic.

This ensures that instances are fully configured before serving production traffic, preventing client request failures.

Configure the State Manager association's script to invoke the complete-lifecycle-action command.

Once the security agents and application dependencies are installed, the lifecycle hook transitions the instance to the InService state.

This automates the configuration flow, ensuring the instance is only marked healthy and active after satisfying all compliance requirements.

Increase the scaling policy's cooldown period to be greater than the 8-minute bootstrap time.

The Auto Scaling Group waits for the newly launched instance to be fully operational and its metric impact to stabilize before initiating another scaling action.

This prevents scaling loops and storms where multiple unnecessary instances are spun up under load.

Run CloudFormation drift detection and align configurations before deploying updates.

Drift is identified, allowing operations to revert manual modifications to match the CloudFormation templates.

This guarantees that subsequent stack updates succeed and prevents failures or resource rollbacks during deployments.

Key Concept

Auto Scaling Lifecycle Hooks and Configuration Management Integration

Estimated Time:3m 0s

Question 1190Question →

A media company runs a critical content delivery application on a fleet of Amazon EC2 instances. The application writes log data to `/var/log/app/access.log`. To manage local disk space, a log rotation utility runs hourly, renaming the active file to `/var/log/app/access-YYYYMMDD-HH.log` and creating a new empty `/var/log/app/access.log` file. The company uses the Unified CloudWatch Agent to stream these logs to Amazon CloudWatch Logs. During testing, log ingestion into CloudWatch Logs stops immediately after the first hourly log rotation completes. Which action should the Solutions Architect take to resolve this issue and ensure continuous log ingestion?

Modify the Unified CloudWatch Agent configuration file by changing the `file_path` parameter under the logs section to `/var/log/app/access*.log`.

Retain the static `/var/log/app/access.log` path in the agent configuration file, and configure a cron job to restart the Unified CloudWatch Agent service immediately after each hourly log rotation.

Modify the S3 bucket policy in the centralized logging account to allow the EC2 instances' IAM role to perform `s3:PutObject` operations using a wildcard for the log file names.

Specify the static `/var/log/app/access.log` path in the agent configuration file, and enable the `auto_reload` parameter in the agent's global settings block.

Show answer & explanation

Answer: Modify the Unified CloudWatch Agent configuration file by changing the `file_path` parameter under the logs section to `/var/log/app/access*.log`.

Answer

Modify the Unified CloudWatch Agent configuration file by changing the `file_path` parameter under the logs section to `/var/log/app/access*.log`.

Modifying the file path to use a wildcard pattern allows the Unified CloudWatch Agent to monitor the directory for new log files matching the pattern. When log rotation occurs, the agent will dynamically discover the newly created active log file and continue ingestion without interruption.

Step-by-Step Solution

Analyze how the log rotation utility modifies files on the EC2 instances.

The active log file `/var/log/app/access.log` is renamed to `/var/log/app/access-YYYYMMDD-HH.log` and a new `/var/log/app/access.log` is created, altering the file descriptor tracked by the agent.

Understanding the rotation mechanism helps identify why a static file path configuration fails after rotation occurs.

Evaluate the Unified CloudWatch Agent's file tracking capabilities.

The agent requires a wildcard pattern to monitor log directories and identify newly created files or rotated files matching the pattern.

Configuring a wildcard pattern like `/var/log/app/access*.log` ensures both active and rotated logs are matched and tracked continuously.

Eliminate options that introduce administrative overhead or target incorrect resources.

Restarts via cron jobs and S3 bucket policy changes do not fix the agent's path matching logic and add operational complexity.

This guarantees a simple, robust, and native cloud architecture configuration.

Key Concept

Configuring the Unified CloudWatch Agent to handle log rotation using wildcard path patterns.

Estimated Time:1m 30s

Question 1191Question →

An enterprise manages its multi-account environment using AWS Organizations. The central DevOps team uses AWS CloudFormation StackSets to deploy baseline logging infrastructure, which consists of an Amazon S3 bucket and an AWS KMS Customer Managed Key (CMK) used to encrypt the bucket, to all member accounts in a specific Organizational Unit (OU). Recently, local administrators in member accounts have manually modified the S3 bucket policies and KMS key policies to grant permissions to local application roles, causing security configuration drift and audit failures. The Solutions Architect must design a solution that automatically detects this configuration drift, remediates the resources to match the approved CloudFormation baseline, and prevents local administrators from disabling the detection or remediation mechanisms. Which two of the following configuration and governance actions should the Solutions Architect implement to achieve this goal?

Select all that apply

Deploy an AWS Config Organization Conformance Pack from the management account containing rules that check S3 bucket and KMS key compliance, and configure auto-remediation using an AWS Systems Manager (SSM) Automation document that executes using a local IAM role with permissions to restore the policies.

Attach a Service Control Policy (SCP) to the member accounts' OU that denies any actions to delete or modify AWS Config recorders, delivery channels, conformance packs, and the local IAM role used for Systems Manager remediation, except when performed by a federated administrator role.

Attach a Service Control Policy (SCP) to the member accounts' OU that explicitly allows the Systems Manager service to perform cross-account remediation of the S3 bucket and KMS key policies, granting the required permissions directly without local IAM role configurations.

Modify the CloudFormation template to use an AWS managed key instead of a Customer Managed Key (CMK) for encrypting the S3 bucket, and use the central DevOps account to update the key policy to delegate permission management to the local applications.

Enable AWS CloudFormation automatic drift detection on the StackSet, and configure an Amazon EventBridge rule in each member account that triggers on stack status changes to run a Systems Manager (SSM) Automation document that executes a local stack update with a ForceUpdate parameter.

Show answer & explanation

Answer: Deploy an AWS Config Organization Conformance Pack from the management account containing rules that check S3 bucket and KMS key compliance, and configure auto-remediation using an AWS Systems Manager (SSM) Automation document that executes using a local IAM role with permissions to restore the policies.; Attach a Service Control Policy (SCP) to the member accounts' OU that denies any actions to delete or modify AWS Config recorders, delivery channels, conformance packs, and the local IAM role used for Systems Manager remediation, except when performed by a federated administrator role.

Answer

To resolve the configuration drift and protect the compliance baseline, the Solutions Architect should deploy an AWS Config Organization Conformance Pack with auto-remediation using an AWS Systems Manager (SSM) Automation document running under a local IAM execution role, and attach a Service Control Policy (SCP) to the OU that denies modifications to the AWS Config and IAM remediation resources.

Deploying an AWS Config Organization Conformance Pack allows the centralized deployment of compliance rules and SSM Automation remediation configurations across all member accounts. The SSM Automation runs in the target account using a local IAM execution role that has permissions to revert the S3 and KMS policy changes. To protect this monitoring and remediation baseline from local administrators, a Service Control Policy (SCP) must be attached to the member accounts' OU. This SCP denies any deletion or modification of the AWS Config resources and the local IAM execution role, securing the enforcement loop.

Step-by-Step Solution

Determine the mechanism for compliance monitoring and remediation at scale.

Identify AWS Config Conformance Packs deployed at the organization level as the ideal tool for pushing standardized config rules and remediation configurations (SSM Automation) to member accounts.

This ensures consistent drift detection and automated remediation across all accounts within the Organizational Unit.

Design the permissions model for the remediation tool.

Create a local IAM role in the member accounts that the SSM Automation document can assume to perform policy updates on S3 and KMS.

SSM Automation requires active IAM permissions to modify target resources, which must be granted in the local account context.

Formulate a policy to secure the compliance baseline from local tampering.

Draft an SCP with a Deny effect on the deletion or modification of AWS Config resources, conformance packs, and the remediation IAM role.

This establishes a governance guardrail that prevents local administrators from bypassing the drift remediation system.

Key Concept

Multi-account configuration drift detection and remediation using Organization Conformance Packs, coupled with SCP guardrails to prevent local tampering.

Question 1192Question →

An enterprise manages its multi-account environment using AWS Organizations. The central DevOps team uses AWS CloudFormation StackSets to deploy and update a standard security baseline OU-wide, which includes configuration for an Amazon S3 logging bucket and approved EC2 instance types. A security audit reveals that several member accounts have manually disabled S3 Block Public Access and launched unauthorized EC2 instance types. The enterprise wants to implement a solution that detects and automatically remediates this configuration drift without affecting other resources, and prevents future unauthorized changes while allowing local administrators to manage approved services. Which two actions should the Solutions Architect take to meet these requirements? (Select TWO.)

Select all that apply

Deploy AWS Config managed rules for S3 public access and approved instance types across the organization using an AWS Config organizational conformance pack, and configure an AWS Systems Manager Automation runbook as the automatic remediation target.

Apply a Service Control Policy (SCP) to the Organizational Unit (OU) that denies s3:PutBucketPublicAccessBlock and s3:DeleteBucketPolicy actions unless the caller is the StackSets execution role, and denies ec2:RunInstances for unauthorized instance types.

Create an OU-level Service Control Policy (SCP) that grants the AWS CloudFormation StackSets execution role permissions to manage the S3 buckets and EC2 instances, thereby overriding any local IAM policies that restrict these administrative operations.

Enable AWS CloudFormation native drift detection on the StackSet, and configure an Amazon EventBridge rule that detects a DRIFTED status to trigger a Lambda function that executes UpdateStackInstances to automatically overwrite manual configuration changes.

Encrypt the S3 logging buckets in each member account using the default AWS-managed KMS key (aws/s3) and attach a custom key policy to grant the central DevOps role cross-account access to verify configuration compliance.

Show answer & explanation

Answer: Deploy AWS Config managed rules for S3 public access and approved instance types across the organization using an AWS Config organizational conformance pack, and configure an AWS Systems Manager Automation runbook as the automatic remediation target.; Apply a Service Control Policy (SCP) to the Organizational Unit (OU) that denies s3:PutBucketPublicAccessBlock and s3:DeleteBucketPolicy actions unless the caller is the StackSets execution role, and denies ec2:RunInstances for unauthorized instance types.

Answer

Deploy AWS Config managed rules across the organization with Systems Manager Automation remediation, and apply a Service Control Policy (SCP) to deny unauthorized S3 and EC2 changes unless performed by the StackSets execution role.

Deploying AWS Config rules across the Organization via conformance packs coupled with Systems Manager Automation provides automatic drift detection and target remediation. Applying an SCP with explicit deny rules restricts unauthorized manual configurations on S3 public access and EC2 instance types while allowing the baseline pipeline (via the StackSets execution role) to manage the resources.

Step-by-Step Solution

Identify the mechanism for Org-wide drift detection and compliance monitoring.

AWS Config managed rules deployed via conformance packs across the Organization monitor baseline configurations.

Config conformance packs ensure consistent compliance checks across all accounts under the OU.

Select an automated remediation method that reverts specific non-compliant resources.

Associate AWS Systems Manager Automation runbooks as remediation targets with the AWS Config rules.

SSM Automation can remediate specific drifted configurations (like public access settings or instance types) without deleting or altering unaffected resources.

Determine the preventive control (guardrail) to restrict manual drift while preserving deployment pipelines.

Deploy a Service Control Policy (SCP) at the OU level that denies modification of these settings unless the principal is the StackSets execution role.

SCPs block local administrative modifications of public access blocks and instance types, acting as a guardrail while keeping the pipeline's CloudFormation StackSets role exempt.

Key Concept

Continuous compliance and drift remediation in a multi-account AWS environment using AWS Config, AWS Systems Manager, and Service Control Policies.

Question 1193Question →

An enterprise operates a legacy web application in a single AWS account. The application's compute tier consists of Amazon ECS tasks running on AWS Fargate across three Availability Zones in the us-east-1 Region. Outbound API requests from the ECS tasks are routed to the internet through a single NAT Gateway located in a public subnet in Availability Zone us-east-1a. The data tier is hosted on a single-region Amazon Aurora MySQL DB cluster.

Recently, an outage in us-east-1a rendered the NAT Gateway unavailable, which disrupted outbound connections for ECS tasks in all three Availability Zones. To prevent future outages and enhance disaster recovery (DR) capabilities, the solutions architect must modify the architecture to achieve a recovery time objective (RTO) of 15 minutes and a recovery point objective (RPO) of 5 minutes in a secondary region (us-west-2).

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

Select all that apply

Deploy a NAT Gateway in a public subnet in each Availability Zone in us-east-1, and configure the route tables of the private subnets in each Availability Zone to route outbound traffic through their respective local NAT Gateway.

Convert the Aurora database cluster to an Aurora Global Database with a secondary cluster in us-west-2. Configure Amazon Route 53 failover routing with health checks associated with the primary Application Load Balancer to redirect traffic to the secondary region during an outage.

Configure an AWS Lambda function triggered by Amazon CloudWatch Alarms to automatically update the private subnet route tables to point to an alternate NAT Gateway in another Availability Zone if the primary NAT Gateway fails.

Configure Amazon Route 53 active-passive failover routing records without health checks, relying on Route 53 to detect the Application Load Balancer's target group health status and automatically initiate DNS failover.

Set up nightly AWS Backup plans to copy database snapshots and S3 backups to us-west-2, and create a cross-region AWS CloudFormation template to restore the Aurora database from the copied snapshot during a failover event.

Show answer & explanation

Answer: Deploy a NAT Gateway in a public subnet in each Availability Zone in us-east-1, and configure the route tables of the private subnets in each Availability Zone to route outbound traffic through their respective local NAT Gateway.; Convert the Aurora database cluster to an Aurora Global Database with a secondary cluster in us-west-2. Configure Amazon Route 53 failover routing with health checks associated with the primary Application Load Balancer to redirect traffic to the secondary region during an outage.

Answer

Deploy a NAT Gateway in each Availability Zone in us-east-1 with local routing, and convert the Aurora cluster to an Aurora Global Database with a secondary cluster in us-west-2 while configuring Route 53 failover routing with health checks.

Deploying a NAT Gateway in each Availability Zone ensures that the failure of a single Availability Zone does not impact outbound traffic for tasks running in other zones, establishing high availability. Converting the Aurora database to an Aurora Global Database meets the RPO of 5 minutes by continuously replicating data to us-west-2 with latency of less than one second. Configuring Route 53 DNS failover with health checks allows automatic detection of primary region degradation and redirects client traffic to the secondary region within the 15-minute RTO.

Step-by-Step Solution

Address the outbound connectivity single point of failure by replacing the single NAT Gateway architecture with a multi-AZ NAT Gateway setup, allocating one NAT Gateway per public subnet in each Availability Zone.

Outbound traffic from private subnets is restricted to the local NAT Gateway in the same Availability Zone, mitigating the risk of cross-AZ network failures.

This aligns with AWS best practices for high availability and ensures that the failure of a single Availability Zone only impacts Fargate tasks within that specific zone.

Evaluate and implement a cross-region database replication strategy that supports the recovery point objective (RPO) of 5 minutes.

Converting the single-region Aurora MySQL cluster to an Aurora Global Database with a secondary cluster in us-west-2 provides physical storage-level replication.

Aurora Global Database replication occurs with sub-second latency, meeting the 5-minute RPO constraint under failover scenarios.

Configure the global DNS routing policy using Route 53 active-passive failover records referencing the primary and secondary Application Load Balancers.

Associating health checks with the primary record allows Route 53 to dynamically monitor the health of the primary region's endpoint.

This configuration automates DNS failover to redirect user traffic to the secondary region within the 15-minute RTO during an outage.

Key Concept

Enhancing reliability and disaster recovery through redundant NAT Gateway architectures and active-passive multi-region database replication with DNS failover.

Question 1194Question →

An enterprise is designing a new multi-VPC environment in the `eu-west-1` Region. The architecture consists of three spoke VPCs (`vpc-finance-prod`, `vpc-hr-prod`, and `vpc-shared-services`) connected via an AWS Transit Gateway. The network design must satisfy the following requirements:
- Establish a primary, high-bandwidth connection using a dedicated AWS Direct Connect connection via a Direct Connect Gateway, and a backup AWS Site-to-Site VPN connection over the internet.
- Prevent asymmetric routing between the on-premises corporate network and AWS.
- Ensure secure, highly available, and cost-effective outbound internet egress for resources in all three VPCs.
- Provide private DNS resolution for a Private Hosted Zone (`corp.internal`) hosted in the `vpc-shared-services` account to all resources across the three VPCs.

Which of the following configuration steps should the solutions architect implement to satisfy these requirements? (Select TWO.)

Select all that apply

Configure the on-premises router to assign a higher BGP Local Preference to routes received via the Direct Connect Gateway compared to the Site-to-Site VPN, and propagate both connections into the AWS Transit Gateway route table.

Deploy a NAT Gateway in each active Availability Zone within the public subnets of the shared services VPC for outbound egress, and perform Route 53 cross-account associations to associate the Private Hosted Zone with each individual spoke VPC.

Deploy a single NAT Gateway in the shared services VPC to route all internet-bound traffic from the spoke VPCs through the Transit Gateway to minimize monthly elastic IP and gateway hourly charges.

Configure the Direct Connect Gateway to act as a transitive router, enabling the spoke VPCs to route inter-VPC traffic directly through the Direct Connect Gateway to optimize network path latency.

Share the Route 53 Private Hosted Zone with the other accounts using AWS Resource Access Manager (RAM) and associate it with the Transit Gateway to enable DNS resolution across all VPCs.

Show answer & explanation

Answer: Configure the on-premises router to assign a higher BGP Local Preference to routes received via the Direct Connect Gateway compared to the Site-to-Site VPN, and propagate both connections into the AWS Transit Gateway route table.; Deploy a NAT Gateway in each active Availability Zone within the public subnets of the shared services VPC for outbound egress, and perform Route 53 cross-account associations to associate the Private Hosted Zone with each individual spoke VPC.

Answer

The correct configuration requires setting a higher BGP Local Preference on the on-premises router for Direct Connect routes, propagating both paths to the Transit Gateway, deploying multi-AZ NAT Gateways in the shared services VPC, and associating the Route 53 Private Hosted Zone with all spoke VPCs using cross-account associations.

The configuration of BGP Local Preference on the customer gateway ensures symmetric routing by directing outbound corporate traffic through the Direct Connect connection. Simultaneously, AWS Transit Gateway naturally prefers Direct Connect Gateway attachments over VPN attachments for returning traffic, preventing asymmetric routing. High availability for egress is achieved by deploying a NAT Gateway in each active Availability Zone, while cross-account Route 53 hosted zone associations allow resources in all spoke VPCs to resolve private domain names.

Step-by-Step Solution

Prevent asymmetric routing for hybrid traffic.

Traffic flows symmetrically over Direct Connect for both inbound and outbound directions, falling back to VPN only when Direct Connect is offline.

Setting a higher BGP Local Preference on the on-premises router controls outbound traffic from on-premises to AWS. On the AWS side, Transit Gateway automatically prioritizes Direct Connect Gateway over VPN for returning traffic.

Design a highly available NAT architecture.

Redundant NAT Gateways are deployed in multiple Availability Zones.

A single NAT Gateway creates a single point of failure, violating high availability design patterns.

Configure cross-account DNS resolution for Private Hosted Zones.

The Private Hosted Zone is associated with all target VPCs.

Private Hosted Zones cannot be shared via AWS RAM or associated with Transit Gateways; they must be associated with each VPC directly.

Key Concept

AWS hybrid connectivity path selection, NAT Gateway redundancy, and cross-account Route 53 Private Hosted Zone associations.

Question 1195Question →

An esports platform manages live matchmaking lobby states and real-time player leaderboards using an Amazon RDS for MySQL Multi-AZ DB instance. During high-concurrency tournament events, the database experiences severe write contention and lock waits on the lobby tables, causing API response times to exceed 5 seconds and dropping active player sessions. The lobby state data is updated frequently, requires sub-millisecond read/write latency, and must remain available across Availability Zones with automatic failover to prevent tournament disruption. The platform also requires advanced sorting capabilities to compute real-time leaderboards.

Which architectural modification most efficiently addresses these performance and availability requirements?

Deploy an Amazon ElastiCache for Memcached cluster with nodes distributed across multiple Availability Zones. Configure the application to write lobby updates to Memcached and read leaderboard queries from the cache.

Migrate the matchmaking lobby state and leaderboard data to an Amazon ElastiCache for Redis cluster running in a multi-node replication group with Multi-AZ enabled. Use Redis sorted sets for the leaderboard sorting.

Deploy an Amazon RDS Multi-AZ DB instance and configure the application to split read and write queries, routing leaderboard reads to the standby DB instance in the secondary Availability Zone to reduce load on the primary DB instance.

Set up two active RDS MySQL DB instances in different regions to handle writes, using Route 53 failover routing to direct users to the nearest database, relying on Route 53 DNS health checks to detect database degradation.

Show answer & explanation

Answer: Migrate the matchmaking lobby state and leaderboard data to an Amazon ElastiCache for Redis cluster running in a multi-node replication group with Multi-AZ enabled. Use Redis sorted sets for the leaderboard sorting.

Answer

The correct answer is the option proposing migrating matchmaking lobby state and leaderboard data to Amazon ElastiCache for Redis with Multi-AZ enabled and using sorted sets. ElastiCache for Redis supports replication, Multi-AZ with automatic failover, sub-millisecond latencies, and advanced data structures (sorted sets/ZSET) which are perfectly suited for real-time leaderboard sorting and transient lobby state management under high write load.

Step-by-Step Solution

Analyze workload characteristics and database bottlenecks.

Identify that the matchmaking lobby state is transient, highly write-intensive, requires sub-millisecond response times, and needs real-time sorting for leaderboards.

This helps determine if standard RDS read replicas are sufficient or if an in-memory caching tier with specific data structure support is required.

Evaluate Amazon ElastiCache engine capabilities (Redis vs. Memcached).

Confirm that Redis is required because it supports replication, Multi-AZ automatic failover, and sorted sets (ZSET) for leaderboards, whereas Memcached lacks these features.

Ensures the selected caching solution meets both the high availability (failover) and functional (sorting) requirements.

Evaluate database-level read scaling options.

Recognize that routing reads to an RDS Multi-AZ standby is impossible because the standby is passive and cannot serve traffic.

Prevents architectural designs that rely on invalid assumptions about RDS standby capabilities.

Key Concept

Selecting ElastiCache Redis over Memcached for workloads requiring replication, Multi-AZ failover, and complex data structures (sorted sets).

Estimated Time:2m 30s

Question 1196Question →

A company provides real-time financial market analytics through a multi-tier API hosted on AWS. The application runs on Amazon EC2 instances managed by an Auto Scaling Group (ASG) behind an Application Load Balancer (ALB). The instances must fetch external market data feeds via the internet, which currently routes through a single NAT Gateway deployed in a public subnet of a single Availability Zone (AZ).

During unscheduled economic announcements, the platform experiences sudden traffic surges of up to $10\times$ the baseline within 2 minutes. This leads to HTTP 503 and 504 errors on the ALB, and outbound API calls fail completely if the AZ containing the NAT Gateway suffers an outage.

An audit of the environment reveals the following:
* The EC2 instances require exactly $300\text{ seconds}$ to download configurations, compile proprietary analytical libraries, and fully initialize.
* The ASG uses a Target Tracking scaling policy based on Average CPU Utilization, with the default cooldown set to $180\text{ seconds}$ and the instance warmup set to $120\text{ seconds}$ .
* The ALB health check is configured as a TCP check on port 80, which succeeds within $30\text{ seconds}$ of instance launch (as soon as the web daemon starts), before library compilation is complete.
* During scaling events, the ASG over-provisions instances rapidly, followed by aggressive scale-in actions that terminate instances before they process any traffic.

Which combination of architectural modifications will resolve the availability, scaling, and fault tolerance issues?

Increase the Auto Scaling group's default cooldown to

300\text{ seconds}

to prevent the group from launching additional instances before bootstrapping completes. Configure the ALB health check grace period to

300\text{ seconds}

to delay traffic delivery. Deploy a standby NAT Gateway in a secondary Availability Zone and configure Route 53 routing policies to fail over outbound internet traffic from the primary NAT Gateway during an outage.

Submit an AWS Support request to pre-warm the Application Load Balancer to handle the sudden flash traffic. Increase the default cooldown to

300\text{ seconds}

and configure the ALB health check grace period to

300\text{ seconds}

to ensure traffic is not sent to instances during bootstrapping. Deploy a single highly available NAT Gateway in a shared services VPC and route all outbound traffic through a Transit Gateway.

Configure a scale-out lifecycle hook to hold instances in a wait state during bootstrapping, and update the target tracking policy's instance warmup to

300\text{ seconds}

. Modify the ALB health check to target an HTTP endpoint that returns success only after initialization completes. Deploy one NAT Gateway per Availability Zone, and update the route tables to route outbound traffic through the local NAT Gateway.

Configure a Step Scaling policy with a cooldown of

300\text{ seconds}

using a custom CloudWatch metric that measures active application sessions. Configure a NAT Instance fleet in an Auto Scaling group across multiple Availability Zones to replace the NAT Gateway, using Route 53 health checks to update the route tables dynamically during a failure.

Show answer & explanation

Answer: Configure a scale-out lifecycle hook to hold instances in a wait state during bootstrapping, and update the target tracking policy's instance warmup to $300\text{ seconds}$ . Modify the ALB health check to target an HTTP endpoint that returns success only after initialization completes. Deploy one NAT Gateway per Availability Zone, and update the route tables to route outbound traffic through the local NAT Gateway.

Answer

The option that configures a scale-out lifecycle hook, sets the instance warmup to 300 seconds, modifies the ALB health check to target an HTTP endpoint, and deploys one NAT Gateway per Availability Zone.

The correct solution involves configuring a scale-out lifecycle hook to pause the instance lifecycle until the bootstrapping script completes, and updating the target tracking policy's instance warmup to 300 seconds to match the actual initialization time. This prevents the ASG from prematurely launching additional instances during the startup phase. Furthermore, modifying the ALB health check to target a custom HTTP endpoint that only returns success after the compilation and initialization processes are finished ensures that the load balancer does not send requests to unready instances. Finally, deploying a NAT Gateway in each Availability Zone removes the single point of failure for outbound traffic, providing full fault tolerance.

Step-by-Step Solution

Analyze the instance bootstrapping duration and its relation to scaling metrics.

Identified that instances require 300 seconds to fully initialize, while the current instance warmup is only 120 seconds and default cooldown is 180 seconds.

Target tracking policies ignore default cooldowns and use the instance warmup duration. If instance warmup is less than the bootstrapping time, the policy will assume launched instances are not contributing to metrics and will continuously launch new instances (over-scaling).

Address the premature traffic routing to uninitialized instances.

Configure a scale-out lifecycle hook to keep instances in the Pending:Wait state during bootstrapping, and configure the ALB health check to use an HTTP endpoint that returns 200 OK only after the initialization process completes.

This prevents the ALB from routing traffic to instances that have only opened port 80 but have not finished library compilation.

Address the fault tolerance of outbound traffic.

Deploy a NAT Gateway in each Availability Zone and configure the route tables to route traffic via the local NAT Gateway.

A single NAT Gateway represents a single point of failure. Deploying a NAT Gateway per AZ ensures that an AZ outage does not disrupt outbound traffic for instances in other AZs.

Evaluate and rule out pre-warming and non-standard failover mechanisms.

Determine that pre-warming is ineffective for unscheduled spikes, and Route 53 cannot fail over local route table entries for active-standby NAT Gateway setups.

Pre-warming requires advance planning, and Route 53 resolves DNS names, which does not help with routing tables configured for outbound IP packets routing to internet destinations.

Key Concept

Aligning Auto Scaling warmup parameters and health checks with instance bootstrapping times, and ensuring outbound high availability via multi-AZ NAT Gateway routing.

Question 1197Question →

An enterprise has a multi-account AWS structure managed via AWS Organizations. The production account hosts an Amazon S3 bucket containing sensitive tracking telemetry. Applications running on Amazon EC2 instances in private subnets of spoke VPCs in separate member accounts need to write data to this bucket. The data must be encrypted at rest using a customer managed AWS KMS key in the production account, and network traffic must not traverse the public internet. Which combination of actions should the Solutions Architect implement to meet these requirements while adhering to the principle of least privilege? (Select TWO.)

Select all that apply

Create a Customer Managed Key (CMK) in the production account, and update its key policy to grant the IAM roles in the spoke accounts permission to perform the kms:GenerateDataKey and kms:Decrypt actions.

Deploy an Amazon S3 Gateway VPC Endpoint in each spoke VPC, and configure the S3 bucket policy in the production account to allow access from the spoke accounts' IAM roles only when the aws:sourceVpce condition matches these endpoints.

Configure the S3 bucket to use the default AWS-managed KMS key (aws/s3) for encryption, and apply a Service Control Policy (SCP) at the Organizational Unit level to grant the spoke accounts permission to use this key.

Deploy a single Amazon S3 Gateway VPC Endpoint in the production VPC, and configure Transit Gateway route tables to forward all outbound S3 traffic from the spoke VPCs to the production VPC's gateway endpoint.

Create a resource share using AWS Resource Access Manager (RAM) to share the S3 bucket and the default KMS key with the spoke accounts, allowing direct cross-account access.

Show answer & explanation

Answer: Create a Customer Managed Key (CMK) in the production account, and update its key policy to grant the IAM roles in the spoke accounts permission to perform the kms:GenerateDataKey and kms:Decrypt actions.; Deploy an Amazon S3 Gateway VPC Endpoint in each spoke VPC, and configure the S3 bucket policy in the production account to allow access from the spoke accounts' IAM roles only when the aws:sourceVpce condition matches these endpoints.

Answer

To securely allow applications in spoke VPCs to write to a centralized S3 bucket in a production account with encryption, a Customer Managed Key (CMK) must be created in the production account with a key policy that allows the spoke IAM roles to generate data keys and decrypt. Additionally, S3 Gateway VPC Endpoints must be created in each spoke VPC, and the production S3 bucket policy must restrict access to those specific VPC endpoints using the aws:sourceVpce condition.

The correct solution involves using a Customer Managed Key (CMK) because AWS-managed keys cannot be shared cross-account. Spoke VPCs can utilize local S3 Gateway Endpoints to route S3 traffic over the private AWS network, and the centralized S3 bucket policy must restrict access to those specific endpoints to ensure network-level isolation.

Step-by-Step Solution

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

Create a Customer Managed Key (CMK) in the production account and grant permissions to the spoke accounts in its key policy.

AWS-managed KMS keys (such as aws/s3) cannot be shared across accounts because their key policies cannot be modified. A Customer Managed Key is required.

Select the appropriate network path for S3 access from private subnets.

Deploy S3 Gateway VPC Endpoints in the spoke VPCs.

S3 Gateway Endpoints allow instances in private subnets to access S3 privately without internet egress. They are free and native to each VPC.

Enforce network-level access control on the S3 bucket.

Update the S3 bucket policy to restrict access to the spoke VPC endpoints using the aws:sourceVpce condition.

This ensures that traffic is only allowed when it originates from the specified private VPC endpoints, preventing public access or access from unauthorized networks.

Key Concept

Cross-account KMS sharing and private S3 network access using VPC endpoints.

Question 1198Question →

An enterprise is auditing its multi-account AWS environment to strengthen network and identity security. The environment consists of a central logging AWS account (Account A) and a production member account (Account B). Applications running in Account B currently write log files to an Amazon S3 bucket located in Account A. The S3 bucket is encrypted using the default AWS managed key (`aws/s3`), and the bucket policy allows wildcard access (`"Principal": "*"`) filtered by a condition restricting access to the organization's ID.

To improve the security posture, the company wants to implement the following changes:
1. Enforce encryption of the logs using a Customer Managed Key (CMK) that supports key rotation and cross-account access.
2. Restrict bucket access strictly to a specific IAM role (`AppLogRole`) in Account B.
3. Ensure all logging traffic is routed privately and securely, preventing access to the bucket from outside a specific VPC interface endpoint (`vpce-12345678`) deployed in Account B.

Which combination of actions will meet these security requirements?

Create a customer managed key in Account A with a key policy that grants kms:GenerateDataKey and kms:Decrypt permissions to the AppLogRole in Account B. Update the S3 bucket policy in Account A to allow s3:PutObject permissions to the AppLogRole in Account B, while adding a policy statement that denies any S3 actions on the bucket if the aws:sourceVpce condition does not match vpce-12345678.

Create a customer managed key in Account A. Apply a Service Control Policy (SCP) to Account B that allows the AppLogRole to perform kms:GenerateDataKey against Account A's key resource. Update the S3 bucket policy in Account A to allow s3:PutObject permissions to the AppLogRole in Account B, while adding a policy statement that denies any S3 actions if the aws:sourceVpc condition does not match the production VPC ID.

Modify the key policy of the default AWS managed S3 key (aws/s3) in Account A to grant kms:GenerateDataKey and kms:Decrypt permissions to the AppLogRole in Account B. Update the S3 bucket policy in Account A to allow s3:PutObject permissions to the AppLogRole in Account B, while adding a policy statement that denies any S3 actions if the aws:sourceVpce condition does not match vpce-12345678.

Create a customer managed key in Account A with a key policy that grants kms:GenerateDataKey and kms:Decrypt permissions to Account B's root account. Update the S3 bucket policy in Account A to allow s3:PutObject permissions to the AppLogRole in Account B, but do not restrict the VPC endpoint in the bucket policy, relying instead on a Service Control Policy (SCP) in Account B to block S3 API calls unless the request originates from vpce-12345678.

Show answer & explanation

Answer: Create a customer managed key in Account A with a key policy that grants kms:GenerateDataKey and kms:Decrypt permissions to the AppLogRole in Account B. Update the S3 bucket policy in Account A to allow s3:PutObject permissions to the AppLogRole in Account B, while adding a policy statement that denies any S3 actions on the bucket if the aws:sourceVpce condition does not match vpce-12345678.

Answer

The correct option addresses all security requirements securely and operationally. First, it implements a customer managed key (CMK) in Account A and grants permissions to the application role in Account B, which is necessary because default AWS managed keys (such as aws/s3) cannot be shared across accounts. Second, it configures the S3 bucket policy in Account A to allow s3:PutObject permissions to the specific IAM role in Account B. Finally, it uses a Deny statement with the aws:sourceVpce condition in the S3 bucket policy to ensure that no traffic can access the S3 bucket from outside the designated VPC interface endpoint (vpce-12345678).

Step-by-Step Solution

Address the encryption requirement by replacing the default AWS managed key (aws/s3) with a customer managed key in Account A.

A customer managed KMS key is created in Account A. Unlike AWS managed keys, its policy can be modified to trust external accounts.

AWS managed keys do not support policy modification and cannot be shared across different AWS accounts.

Configure the customer managed key policy in Account A to allow cross-account access.

The key policy is updated to grant kms:GenerateDataKey and kms:Decrypt permissions to the AppLogRole in Account B.

This allows the application role in the member account to encrypt the logs when uploading them to the S3 bucket.

Configure the S3 bucket policy in Account A to restrict access and enforce the network boundary.

The bucket policy is updated to permit s3:PutObject only to the AppLogRole in Account B and includes a Deny statement for all S3 actions if the aws:sourceVpce condition does not match vpce-12345678.

Enforcing the VPC endpoint restriction at the bucket policy level prevents any traffic from reaching the bucket unless it originates from the specified interface VPC endpoint, securing the resource perimeter.

Key Concept

Cross-account resource access security using customer managed KMS keys and S3 bucket policies with VPC endpoint conditions.

Estimated Time:2m 30s

Question 1199Question →

An enterprise is planning to migrate a three-tier application to AWS. A solutions architect has compiled the following inventory and migration requirements:

1. A legacy billing tool runs on an old on-premises mainframe system. Due to complex physical hardware integrations, this system cannot be virtualized or migrated to the cloud, but the business must continue using it for compliance reporting for the next $2$ years.
2. The main application database runs on an on-premises Microsoft SQL Server. The enterprise wants to reduce database administration overhead, such as patching and backups, but does not want to convert the schema or rewrite any application SQL code. They plan to move this database to Amazon RDS for SQL Server.
3. The web application tier consists of a Java application running on Apache Tomcat. The development team wants to package this application into Docker containers and run it on Amazon ECS on AWS Fargate to simplify scaling and infrastructure management, without modifying the application code.

Which of the following migration strategies represent the correct mappings for these components under the AWS $7\text{ Rs}$ migration framework? (Select TWO.)

Select all that apply

Retain the legacy billing tool on-premises.

Replatform the SQL Server database by migrating it to Amazon RDS for SQL Server.

Refactor the SQL Server database by migrating it to Amazon RDS for SQL Server.

Rehost the legacy billing tool by migrating it using AWS Application Migration Service (AWS MGN).

Refactor the Java web application by containerizing it for Amazon ECS on AWS Fargate.

Show answer & explanation

Answer: Retain the legacy billing tool on-premises.; Replatform the SQL Server database by migrating it to Amazon RDS for SQL Server.

Answer

Retaining the legacy billing tool on-premises and replatforming the SQL Server database to Amazon RDS for SQL Server are the correct strategies.

Retaining the legacy billing tool on-premises is correct because the hardware constraints prevent virtualization or cloud migration. Replatforming the database to Amazon RDS for SQL Server is correct because it adopts a managed service to optimize operations without modifying database engine features or code.

Step-by-Step Solution

Analyze the legacy billing tool's constraints.

Because of physical hardware integrations and compliance requirements, the tool cannot be virtualized or migrated. It must remain on-premises, mapping to a Retain strategy.

Identify the migration constraint for the mainframe tool.

Analyze the SQL Server database requirements.

Moving SQL Server to Amazon RDS for SQL Server reduces administration overhead without changing the engine or code, which represents Replatforming (lift-tinker-and-shift).

Determine the database migration strategy based on operational goals.

Analyze the Java web application requirements.

Containerizing the application for Amazon ECS on AWS Fargate without modifying application code maps to Replatforming, not Refactoring.

Determine the application tier migration strategy based on containerization without code changes.

Key Concept

AWS 7 Rs Migration Framework

Question 1200Question →

An enterprise is designing a new multi-account network topology in the `ap-southeast-1` region. The architecture includes two spoke VPCs, `vpc-ap-southeast1-frontend` (CIDR $172.16.10.0/24$ ) and `vpc-ap-southeast1-backend` (CIDR $172.16.20.0/24$ ), and a centralized egress VPC, `vpc-ap-southeast1-egress` (CIDR $172.16.30.0/24$ ). An on-premises data center must connect to the VPCs via a 10 Gbps AWS Direct Connect connection. The architecture has the following constraints:

1. Spoke VPCs must not have direct internet access; all outbound internet traffic ( $0.0.0.0/0$ ) must route through the egress VPC, which must be resilient to Availability Zone outages.
2. Spoke VPCs must resolve DNS queries for `corp.internal`, which is a Route 53 Private Hosted Zone managed in a separate Shared Services AWS account.
3. Administrative overhead must be minimized.

Which network architecture meets these requirements while satisfying all constraints?

Deploy a Transit Gateway (TGW) and attach `vpc-ap-southeast1-frontend`, `vpc-ap-southeast1-backend`, and `vpc-ap-southeast1-egress` to it. In `vpc-ap-southeast1-egress`, deploy redundant NAT Gateways across two Availability Zones. Share the `corp.internal` Private Hosted Zone from the Shared Services account using AWS Resource Access Manager (RAM) to allow automatic cross-account DNS resolution for the spoke VPCs.

Deploy a Transit Gateway (TGW) and attach `vpc-ap-southeast1-frontend`, `vpc-ap-southeast1-backend`, and `vpc-ap-southeast1-egress` to it. In `vpc-ap-southeast1-egress`, deploy redundant NAT Gateways across two Availability Zones in public subnets. Associate the `corp.internal` Private Hosted Zone in the Shared Services account with the spoke and egress VPCs by creating VPC association authorizations in the Shared Services account and accepting them in the spoke and egress accounts.

Deploy a Transit Gateway (TGW) and attach all VPCs to it. In `vpc-ap-southeast1-egress`, deploy a single NAT Gateway in the `ap-southeast-1a` Availability Zone. Configure the private subnet route tables of the spoke VPCs to route outbound internet traffic (

0.0.0.0/0

) to the TGW. Associate the `corp.internal` Private Hosted Zone in the Shared Services account with the spoke and egress VPCs using cross-account VPC association authorizations.

Deploy a Direct Connect Gateway (DXGW) connected to the on-premises environment. Attach `vpc-ap-southeast1-frontend`, `vpc-ap-southeast1-backend`, and `vpc-ap-southeast1-egress` directly to the DXGW. Configure Virtual Private Gateways (VGWs) in each VPC, and use the DXGW to route spoke-to-spoke, spoke-to-on-premises, and outbound internet traffic through the NAT Gateways in the egress VPC. Associate the `corp.internal` Private Hosted Zone in the Shared Services account with the spoke and egress VPCs using cross-account VPC association authorizations.

Show answer & explanation

Answer: Deploy a Transit Gateway (TGW) and attach `vpc-ap-southeast1-frontend`, `vpc-ap-southeast1-backend`, and `vpc-ap-southeast1-egress` to it. In `vpc-ap-southeast1-egress`, deploy redundant NAT Gateways across two Availability Zones in public subnets. Associate the `corp.internal` Private Hosted Zone in the Shared Services account with the spoke and egress VPCs by creating VPC association authorizations in the Shared Services account and accepting them in the spoke and egress accounts.

Answer

The correct network architecture deploys a Transit Gateway to interconnect the VPCs, deploys redundant NAT Gateways across multiple Availability Zones in the egress VPC to prevent a single point of failure, and utilizes cross-account Private Hosted Zone association authorizations to allow the spoke VPCs to resolve DNS queries managed in the Shared Services account.

The correct answer provides a highly available, transitive, and correct DNS routing topology. Transit Gateway is used to interconnect the VPCs. In the egress VPC, redundant NAT Gateways across two Availability Zones prevent a single point of failure. The Route 53 Private Hosted Zone in the Shared Services account is correctly associated with the spoke VPCs using cross-account association authorizations, which is the only valid way to map a PHZ across multiple accounts without setting up custom DNS forwarding architectures.

Step-by-Step Solution

Determine the routing mechanism for centralized egress and hybrid connectivity.

A Transit Gateway (TGW) must be deployed to interconnect `vpc-ap-southeast1-frontend`, `vpc-ap-southeast1-backend`, and `vpc-ap-southeast1-egress` and route traffic transitively.

Direct Connect Gateway (DXGW) alone does not support transitive VPC-to-VPC routing or VPC-to-internet routing.

Design the high-availability NAT Gateway configuration.

Deploy redundant NAT Gateways in public subnets across two different Availability Zones in the central egress VPC.

Deploying a single NAT Gateway introduces a single point of failure, violating the high-availability constraint during an Availability Zone outage.

Determine the cross-account Private Hosted Zone (PHZ) sharing strategy.

Create a VPC association authorization for the spoke VPCs from the Shared Services account, and then accept the association in the spoke accounts.

Route 53 Private Hosted Zones cannot be shared via AWS Resource Access Manager (RAM).

Key Concept

Centralized egress architectures, transitive routing limitations of Direct Connect Gateway, and cross-account Route 53 Private Hosted Zone associations.

Estimated Time:3m 0s

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

Alternative Method

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution