All practice questions

1964 questions

All types1,964 Multiple choice1,006 Multiple select931 Ordering27

An organization is migrating its on-premises inventory databases to AWS using AWS Application Migration Service (MGN). The on-premises data center is connected to AWS via a 10 Gbps AWS Direct Connect (DX) connection terminating on a Transit Gateway in a central Shared Services VPC. The staging area subnets are deployed in this VPC and must remain isolated from the public internet due to security compliance rules. All migration replication traffic must travel securely over the private DX connection. Which of the following configuration steps must be performed to establish replication and ensure control plane communication under these constraints? (Select TWO.)

Select all that apply

Configure the AWS MGN Replication Template to use private IP addresses for data routing, and ensure that the staging area security groups and on-premises firewalls allow replication traffic on TCP port 1500.

Establish interface VPC endpoints (AWS PrivateLink) for the AWS MGN service in the staging VPC, and ensure that the on-premises DNS resolves the MGN service endpoints to these private IP addresses.

Configure the AWS MGN Replication Template to route replication traffic over HTTPS (TCP port 443) to the staging area subnets, allowing the security groups to block all other custom TCP ports.

Associate a Route 53 Private Hosted Zone (PHZ) containing the MGN service endpoint records with the Shared Services VPC, relying on automatic PHZ inheritance to resolve DNS queries in all Transit Gateway-attached spoke VPCs without manual association.

Deploy a single NAT Gateway in one Availability Zone of the Shared Services VPC to route all outbound MGN agent control traffic to the public MGN API endpoints, and update all staging subnet route tables to use this NAT Gateway as their default route.

Show answer & explanation

Answer: Configure the AWS MGN Replication Template to use private IP addresses for data routing, and ensure that the staging area security groups and on-premises firewalls allow replication traffic on TCP port 1500.; Establish interface VPC endpoints (AWS PrivateLink) for the AWS MGN service in the staging VPC, and ensure that the on-premises DNS resolves the MGN service endpoints to these private IP addresses.

Answer

Configure the AWS MGN Replication Template to use private IP addresses for data routing with TCP port 1500 open, and establish interface VPC endpoints for AWS MGN with appropriate DNS resolution.

To migrate workloads privately using AWS Application Migration Service (MGN) without internet access, you must configure the MGN Replication Template to use private IPs for replication, and ensure firewalls/security groups allow TCP port 1500 traffic. Additionally, interface VPC endpoints (PrivateLink) must be created for AWS MGN so that the replication agent can communicate with the control plane securely over the Direct Connect connection using private DNS resolution.

Step-by-Step Solution

Configure the replication template in AWS MGN to use private IP addresses for data replication, ensuring replication traffic traverses the private Direct Connect link instead of public routes.

The AWS MGN agent will attempt to connect to the replication servers in the staging area using their private IP addresses.

This is required because the staging area subnets do not have public IP routing and all traffic must remain private.

Ensure TCP port 1500 is allowed outbound from the on-premises source servers and inbound at the security group of the replication servers in the staging area subnets.

The replication agent can successfully establish a data channel to send block-level writes to the replication servers.

AWS MGN uses TCP port 1500 for the continuous data replication stream.

Deploy interface VPC endpoints (PrivateLink) for the AWS MGN service (com.amazonaws.<region>.mgn) inside the staging VPC.

Private IP addresses are allocated within the staging subnets for the MGN control plane API.

The replication agent needs to communicate with the MGN control plane for orchestration, which is otherwise unreachable from an isolated network.

Configure DNS resolution so that the on-premises source servers can resolve the public MGN service DNS name to the private IP addresses of the interface endpoints.

The replication agent resolves the service endpoint to the PrivateLink interface IPs, enabling secure control plane communication.

This ensures the agent can register and receive migration instructions without public internet access.

Key Concept

Configuring AWS MGN for private replication over AWS Direct Connect using private IPs, custom ports (TCP 1500), and interface VPC endpoints for control plane access.

Question 1422Question →

A company is migrating a critical on-premises Oracle database to an Amazon Aurora PostgreSQL-Compatible Edition DB cluster. The database contains several tables with high-volume transaction writes and columns containing Large Objects (LOBs) that average $64\text{ KB}$ but can reach up to $10\text{ MB}$ in size. To minimize downtime, the solutions architect plans to use the AWS Schema Conversion Tool (AWS SCT) and AWS Database Migration Service (AWS DMS) for Change Data Capture (CDC). The migration must minimize the CPU overhead on the production Oracle source database and ensure that no LOB data is truncated during the replication. Which configuration should the solutions architect implement to meet these requirements?

Configure AWS DMS to use the Binary Reader method for CDC, ensuring that the replication user has appropriate access to the Oracle directories containing the redo and archive logs, and enable supplemental logging at both the database and table levels. In the DMS task settings, enable inline LOBs by setting SupportLobs to true and specifying an InlineLobMaxSize of

128\text{ KB}

Configure AWS DMS to use the Oracle LogMiner method for CDC to process transaction logs, and enable supplemental logging only at the table level for the primary key columns. In the DMS task settings, configure the task to use Limited LOB mode with a LobMaxSize of

64\text{ KB}

to ensure high performance and prevent memory exhaustion on the replication instance.

Configure AWS DMS to use the Binary Reader method for CDC to read redo logs. In the DMS task settings, configure the task to use Full LOB mode to prevent truncation of any large columns. Rely on the AWS SCT agent to capture database changes and stream them to the DMS replication instance without enabling database-level supplemental logging.

Configure AWS DMS to use the Oracle LogMiner method for CDC, and enable database-level minimal supplemental logging. In the DMS task settings, disable LOB support during the initial load, and configure an AWS Lambda function triggered by Amazon S3 event notifications to manually sync LOB updates using the AWS SCT extension pack.

Show answer & explanation

Answer: Configure AWS DMS to use the Binary Reader method for CDC, ensuring that the replication user has appropriate access to the Oracle directories containing the redo and archive logs, and enable supplemental logging at both the database and table levels. In the DMS task settings, enable inline LOBs by setting SupportLobs to true and specifying an InlineLobMaxSize of $128\text{ KB}$ .

Answer

The configuration that uses AWS DMS Binary Reader for CDC with supplemental logging enabled at the database and table levels, combined with inline LOB settings in the task configuration.

To migrate a high-volume Oracle database to Amazon Aurora PostgreSQL with minimal source CPU overhead and no data truncation, the Solutions Architect should use the AWS DMS Binary Reader method. Unlike LogMiner, which queries the database engine directly and consumes CPU, Binary Reader reads the redo and archive logs directly from the file system or ASM. Additionally, AWS DMS CDC requires supplemental logging to be enabled at both the database and table levels. To handle LOB columns where the average size is small (

64\text{ KB}

) but maximum size is large (

10\text{ MB}

), inline LOB mode (InlineLobMaxSize) should be used. This allows DMS to transfer LOBs smaller than the threshold inline with table rows for maximum performance, while performing a full lookup only for larger LOBs to prevent truncation.

Step-by-Step Solution

Evaluate the CPU overhead of log mining methods on the source Oracle database.

Oracle LogMiner runs SQL queries on the source DB and incurs high CPU overhead, whereas AWS DMS Binary Reader reads redo and archive logs directly from the file system or ASM, significantly reducing CPU load on the production database.

The migration must minimize source database CPU overhead.

Determine the CDC logging prerequisites for AWS DMS.

AWS DMS requires supplemental logging to be enabled at both the database level (minimal supplemental logging) and the table level (for primary keys and LOB columns) to capture transaction log changes.

Failing to enable supplemental logging prevents AWS DMS CDC from tracking row modifications.

Analyze the LOB replication requirements to optimize performance and prevent data truncation.

Using Inline LOB mode with an InlineLobMaxSize of

128\text{ KB}

allows DMS to transfer LOBs below the threshold inline for optimal performance, while using a full lookup for larger LOBs up to

10\text{ MB}

to prevent truncation.

LOBs average

64\text{ KB}

but can reach

10\text{ MB}

. Limited LOB mode would truncate data, while Full LOB mode would degrade performance.

Key Concept

Optimizing AWS DMS CDC performance and LOB replication during heterogeneous migrations from Oracle to Amazon Aurora.

Estimated Time:3m 0s

Question 1423Question →

An enterprise runs a distributed data processing application in Account A. The application runs on Amazon EC2 instances in a VPC in the $us-west-2$ (Oregon) Region across three Availability Zones. Every month, the EC2 instances retrieve $600\text{ TB}$ of raw telemetry data from an Amazon S3 bucket located in the $us-west-2$ Region in Account B (Shared Services). After processing, the application writes $150\text{ TB}$ of transformed data to a central analytics S3 bucket in the $us-east-1$ (N. Virginia) Region in Account C (Analytics).

Currently, the VPC in Account A has a single NAT Gateway in one Availability Zone. All traffic to S3 is routed through this NAT Gateway. A Solutions Architect notices that the monthly AWS bill shows extremely high NAT Gateway data processing charges and inter-Region data transfer costs. The company wants to minimize these costs while maintaining a secure and highly available architecture.

Which configuration is the most cost-effective and architecturally sound?

Configure an Amazon S3 Interface VPC Endpoint (AWS PrivateLink) in each Availability Zone in Account A's VPC. Configure the application to route all S3 traffic (both downloads from Account B and uploads to Account C) through these Interface VPC Endpoints to bypass the NAT Gateway.

Configure an Amazon S3 Gateway VPC Endpoint in Account A's VPC and associate it with the route tables for all three Availability Zones. Create a local S3 staging bucket in

us-west-2

in Account A, and configure an S3 Lifecycle policy to transition objects to S3 Glacier Deep Archive after 24 hours. Configure the application to write the transformed data directly to the S3 bucket in

us-east-1

via a VPC Peering connection established between Account A and Account C.

Configure an Amazon S3 Gateway VPC Endpoint in Account A's VPC and associate it with the route tables for all three Availability Zones. Create a local S3 staging bucket in

us-west-2

in Account A. Configure the application to write the transformed data to the local staging bucket, and use an S3 Lifecycle policy to delete the objects after 1 day. Enable S3 Cross-Region Replication (CRR) on the staging bucket to replicate the processed data to the destination S3 bucket in

us-east-1

in Account C.

Deploy a NAT Gateway in each of the three Availability Zones in Account A's VPC to ensure high availability. For the

150\text{ TB}

of processed data, write the output to a local AWS Snowball Edge Storage Optimized device positioned in the local data center, and physically ship it to the AWS analytics center in

us-east-1

weekly to eliminate all inter-Region network data transfer charges.

Show answer & explanation

Answer: Configure an Amazon S3 Gateway VPC Endpoint in Account A's VPC and associate it with the route tables for all three Availability Zones. Create a local S3 staging bucket in $us-west-2$ in Account A. Configure the application to write the transformed data to the local staging bucket, and use an S3 Lifecycle policy to delete the objects after 1 day. Enable S3 Cross-Region Replication (CRR) on the staging bucket to replicate the processed data to the destination S3 bucket in $us-east-1$ in Account C.

Answer

Configure an Amazon S3 Gateway VPC Endpoint in Account A's VPC across all route tables. Save the processed data to a local staging S3 bucket in

us-west-2

, and use S3 Cross-Region Replication (CRR) to replicate the data to

us-east-1

in Account C, using an S3 Lifecycle policy to delete the local staging objects after 1 day.

The correct configuration uses an S3 Gateway VPC Endpoint to route all local S3 traffic (downloads from the raw bucket and uploads to the staging bucket) directly to S3 without passing through the NAT Gateway, costing

0

in data processing fees. By utilizing S3 Cross-Region Replication (CRR) from the staging bucket in

us-west-2

to the destination bucket in

us-east-1

, the data transfer is managed entirely within the S3 service. This avoids NAT Gateway data processing charges for the cross-Region write, while keeping inter-Region transfer costs identical to direct uploads. The 1-day S3 Lifecycle expiration policy ensures staging data is cleaned up immediately, preventing unnecessary storage charges.

Step-by-Step Solution

Address the local S3 read costs (

600\text{ TB}

Create an S3 Gateway VPC Endpoint in Account A and associate it with all subnet route tables.

Gateway Endpoints are free and route traffic directly to S3 within the same Region, saving

600\text{ TB} \times 1024\text{ GB/TB} \times \$0.045/\text{GB} = \$27,648

per month in NAT Gateway processing fees.

Address the cross-Region S3 write costs (

150\text{ TB}

Avoid writing directly to

us-east-1

via NAT Gateway, which would cost

150\text{ TB} \times 1024\text{ GB/TB} \times \$0.045/\text{GB} = \$6,912

in processing fees.

Gateway VPC Endpoints only route traffic to S3 buckets in the same Region. Writing directly to another Region's S3 bucket bypasses the Gateway Endpoint and goes through the NAT Gateway.

Optimize the cross-Region data path using S3 staging and replication.

Upload processed data to a staging bucket in

us-west-2

via the Gateway VPC Endpoint, and configure S3 Cross-Region Replication (CRR) to replicate it to the destination bucket in

us-east-1

The upload to the local staging bucket incurs no data processing fees due to the Gateway Endpoint. S3 CRR replicates the data directly from S3

us-west-2

to S3

us-east-1

, bypassing the VPC's NAT Gateway entirely and avoiding the processing charges, while only charging standard inter-Region data transfer rates.

Configure storage cleanup.

Add an S3 Lifecycle rule to the local staging bucket to expire/delete objects after 1 day.

This prevents duplicate storage costs in the source Region while ensuring enough time for replication to complete successfully.

Key Concept

Bypassing NAT Gateway data processing charges for cross-Region S3 access by writing to a local S3 staging bucket via a Gateway Endpoint and utilizing S3 Cross-Region Replication (CRR).

Alternative Method

If CRR is not desired, another option would be to write the data to an EC2 instance hosted in the destination region via a VPC Peering connection, and have that instance upload the data to the destination S3 bucket. However, this introduces extra compute costs, management overhead, and potential performance bottlenecks compared to native S3 CRR.

Estimated Time:3m 0s

Question 1424Question →

An enterprise manages a multi-account environment under AWS Organizations with consolidated billing enabled. The production workloads must maintain high availability across three Availability Zones with minimal administrative overhead. The current infrastructure includes the following components:

* Compute: An Auto Scaling group in Account A running $12$ Linux x86_64 Amazon EC2 `m6i.4xlarge` instances 24/7. Monitoring shows CPU utilization is consistently between $15\%$ and $20\%$ , and memory utilization is under $30\%$ . No code changes or recompilations are permitted.
* Serverless: Containerized microservices running on AWS Fargate in Account A. The tasks are allocated $4$ vCPUs and $16\text{ GB}$ of RAM, with average CPU and memory utilization at $22\%$ .
* Database: A transactional write-heavy Amazon Aurora PostgreSQL DB cluster in Account B running on a single `db.r6g.4xlarge` instance. The database CPU utilization averages $10\%$ but spikes to $85\%$ daily for a 1-hour batch ingestion process.
* Network: Outbound traffic to the internet from private subnets in Account C is routed through a single NAT Gateway in Availability Zone `us-east-1a` to minimize processing costs.

Which two of the following recommendations should the Solutions Architect make to optimize resource costs and sizing without introducing code changes, risking service downtime, or compromising high availability? (Select TWO.)

Select all that apply

Downsize the EC2 instances to `m6i.2xlarge`, and purchase Compute Savings Plans in the organization's management account to maximize savings across both the EC2 instances and the Fargate tasks.

Downsize the Fargate tasks to

1\text{ vCPU}

and

4\text{ GB}

of RAM, and migrate the Aurora database to Aurora Serverless v2 configured with a capacity range of

4

64

Aurora Capacity Units (ACUs).

Downsize the EC2 instances to `c6i.2xlarge` to optimize compute efficiency, and purchase EC2 Instance Savings Plans in the organization's management account to cover the EC2 instances and Fargate tasks.

Share the single NAT Gateway in Account C with Account A and Account B using AWS Resource Access Manager (RAM) to eliminate cross-AZ data transfer fees.

Keep the Fargate tasks at their current capacity, and route all outbound traffic in Account A and Account B through the single NAT Gateway in Availability Zone `us-east-1a` to avoid the hourly charges of additional NAT Gateways.

Show answer & explanation

Answer: Downsize the EC2 instances to `m6i.2xlarge`, and purchase Compute Savings Plans in the organization's management account to maximize savings across both the EC2 instances and the Fargate tasks.; Downsize the Fargate tasks to $1\text{ vCPU}$ and $4\text{ GB}$ of RAM, and migrate the Aurora database to Aurora Serverless v2 configured with a capacity range of $4$ to $64$ Aurora Capacity Units (ACUs).

Answer

Downsize the EC2 instances to m6i.2xlarge and purchase Compute Savings Plans in the management account; downsize the Fargate tasks to 1 vCPU and 4 GB RAM, and migrate the Aurora database to Aurora Serverless v2 with a capacity range of 4 to 64 ACUs.

Downsizing the EC2 instances to `m6i.2xlarge` reduces the provisioned resources to half, perfectly fitting the observed utilization (under 3.2 vCPUs and 19.2 GB RAM) while maintaining the x86_64 architecture without code changes. Purchasing Compute Savings Plans at the management account level allows the discount to cover both EC2 and Fargate tasks across the organization. Additionally, downsizing the Fargate tasks to 1 vCPU and 4 GB RAM aligns resources with the actual 22% utilization, and migrating the Aurora DB cluster to Aurora Serverless v2 enables dynamic scaling up to 64 ACUs during batch ingestion, eliminating provisioned idle capacity costs.

Step-by-Step Solution

Analyze EC2 metrics and right-size the compute instances.

Downsizing from `m6i.4xlarge` (16 vCPUs, 64 GB RAM) to `m6i.2xlarge` (8 vCPUs, 32 GB RAM) is safe since peak CPU usage is <3.2 vCPUs and memory usage is <19.2 GB. A compute-optimized instance like `c6i.2xlarge` is ruled out because its 16 GB RAM would lead to memory starvation.

Ensures that compute sizing matches actual resource requirements without risking application stability or requiring code changes.

Analyze Fargate metrics and right-size task allocations.

The Fargate tasks utilize 22% of 4 vCPUs (~0.88 vCPUs) and 16 GB RAM (~3.52 GB). Downsizing the task definition to 1 vCPU and 4 GB RAM optimizes utilization and significantly reduces Fargate costs.

Prevents over-provisioning of serverless compute resources.

Analyze database patterns and migrate to a dynamic scaling model.

The Aurora PostgreSQL database is highly underutilized for 23 hours a day (10% CPU) but spikes to 85% during ingestion. Migrating to Aurora Serverless v2 with a range of 4 to 64 ACUs (8 GB to 128 GB RAM) allows the database to scale up automatically to handle ingestion spikes and scale back down, saving substantial database provisioning costs.

Provides automated cost-effective sizing for variable and bursty database workloads.

Evaluate Savings Plans options for multi-account coverage.

Compute Savings Plans purchased in the management account cover both EC2 and Fargate across the organization. EC2 Instance Savings Plans are incorrect because they do not cover Fargate compute.

Applies the most flexible and comprehensive discount program across the multi-account AWS Organization.

Key Concept

Right-sizing compute (EC2 and Fargate) and database (Aurora) workloads based on performance metrics, combined with selecting the correct Savings Plans type (Compute vs. EC2 Instance) for multi-account serverless environments while maintaining high availability.

Question 1425Question →

A sports media company runs a live game-tracking application that uses an Amazon RDS for MySQL Multi-AZ DB instance as its data store. During major tournaments, the application experiences a surge in read traffic, with users frequently querying match statistics that do not change often. This read traffic causes the database CPU utilization to exceed $80\%$ , resulting in latency and connection timeouts. The architecture requires a highly available caching layer that supports replication to offload read traffic and reduce database latency. Which TWO actions should the Solutions Architect take to optimize database and caching efficiency while meeting these requirements? (Select TWO.)

Select all that apply

Deploy an Amazon ElastiCache for Redis replication group with Multi-AZ and automatic failover enabled, and configure the application to cache frequently queried statistics.

Create Amazon RDS read replicas and update the application to route read-only queries for match statistics to the read replica endpoints.

Deploy an Amazon ElastiCache for Memcached cluster and configure multi-AZ replication to cache the statistics.

Configure the application to route read queries to the standby instance of the Amazon RDS MySQL Multi-AZ deployment during peak hours.

Implement an Application Load Balancer in front of the Amazon RDS MySQL DB instance and request pre-warming to handle the read query spikes.

Show answer & explanation

Answer: Deploy an Amazon ElastiCache for Redis replication group with Multi-AZ and automatic failover enabled, and configure the application to cache frequently queried statistics.; Create Amazon RDS read replicas and update the application to route read-only queries for match statistics to the read replica endpoints.

Answer

To optimize database and caching efficiency, the Solutions Architect should deploy an Amazon ElastiCache for Redis replication group with Multi-AZ and automatic failover to cache frequently queried statistics, and create Amazon RDS read replicas to offload read-heavy query traffic from the primary database instance.

Deploying an Amazon ElastiCache for Redis replication group with Multi-AZ and automatic failover, combined with creating Amazon RDS read replicas, represents the optimal solution. ElastiCache for Redis offloads repeat queries for static match statistics using a highly available, replicated caching layer. Read replicas offload general read query traffic from the primary database instance, reducing CPU utilization.

Step-by-Step Solution

Analyze database performance metrics and bottleneck root cause.

Identify that the database CPU bottleneck is driven by high read volume for mostly static data during tournaments.

Determining the query patterns helps distinguish between write-heavy and read-heavy performance issues.

Evaluate caching solutions against high availability and replication requirements.

Select Amazon ElastiCache for Redis because it supports replication, Multi-AZ failover, and persistence, whereas Memcached does not.

The requirement explicitly demands replication support and high availability in the caching layer.

Configure read replication for database-level offloading.

Deploy Amazon RDS read replicas to absorb queries that cannot be served by the cache, routing them away from the primary DB instance.

Directing read traffic to replicas reduces the processing load on the primary DB instance, lowering CPU utilization.

Key Concept

Offloading read-heavy workloads from relational databases using a combination of high-availability caching tiers and read replicas.

Estimated Time:2m 0s

Question 1426Question →

An enterprise wants to enforce a consistent configuration baseline across all Amazon EC2 instances in its AWS Organization. The baseline configuration requires that a specific third-party security daemon is installed and continuously running on all instances. During routine troubleshooting, developers occasionally stop this daemon, creating security non-compliance. A solutions architect needs to design an automated solution that detects and automatically remediates this configuration drift with the least operational overhead. Which of the following is the most efficient and compliant solution to meet these requirements?

Deploy an AWS Systems Manager (SSM) State Manager association targeted at the instances. Configure the association to run a custom SSM document on a recurring schedule that checks the status of the security daemon and starts the service if it is stopped.

Deploy a Service Control Policy (SCP) at the root of the AWS Organization to deny permissions for stopping or disabling the security daemon service within the operating system of the EC2 instances.

Deploy the EC2 instances using AWS CloudFormation templates. Enable native CloudFormation drift detection to monitor the instances and configure the templates to automatically perform a stack update with a rollback configuration if the daemon stops.

Use AWS Config to monitor the status of the security daemon. If the daemon is stopped, trigger an AWS Systems Manager Automation runbook that uses the default AWS-managed KMS key for Systems Manager (aws/ssm) to securely decrypt configuration files and restart the service across accounts.

Show answer & explanation

Answer: Deploy an AWS Systems Manager (SSM) State Manager association targeted at the instances. Configure the association to run a custom SSM document on a recurring schedule that checks the status of the security daemon and starts the service if it is stopped.

Answer

The correct answer is the solution that uses an AWS Systems Manager (SSM) State Manager association to execute an SSM document on a schedule. SSM State Manager is specifically designed to enforce configuration baselines on EC2 instances. By targeting the instances and running a check on a schedule, State Manager can detect if the daemon has stopped and run the commands to restart it, remediating the OS-level drift automatically with minimal operational overhead.

Step-by-Step Solution

Determine if the drift detection and remediation requirement applies to the AWS API level or the operating system level.

The requirement is to detect and remediate a stopped security daemon (OS-level process), which requires OS-level automation.

This rules out AWS API-level compliance mechanisms such as Service Control Policies (SCPs) and native CloudFormation drift detection.

Evaluate AWS Systems Manager (SSM) State Manager for managing OS-level configurations.

SSM State Manager is identified as a service that can target instances via tags and run configurations (like SSM documents) on a schedule to enforce a desired state.

State Manager automatically restarts the stopped daemon when the association runs, enforcing the configuration baseline without manual intervention.

Evaluate the key restrictions for cross-account or multi-account KMS access.

Cross-account access requires a Customer Managed Key (CMK) with a modified key policy; default AWS-managed keys like aws/ssm cannot be shared across accounts.

This rules out solutions that attempt to use default AWS-managed KMS keys for cross-account execution.

Key Concept

AWS Systems Manager State Manager is a configuration management service that automates the process of keeping your EC2 and hybrid infrastructure in a defined state, enabling native remediation of OS-level configuration drift.

Question 1427Question →

An enterprise has a multi-account AWS environment. Account A (Shared Services) hosts a private Amazon API Gateway API. Account B (Production) has Amazon EC2 instances running in a private subnet that must invoke this private API. Network connectivity between Account A's VPC and Account B's VPC is established via an AWS Transit Gateway. A Solutions Architect must strengthen the identity and network security posture of this existing integration. The traffic must remain private, be restricted to Account B's VPC, and the API must only be invocable by a specific IAM role (API-Invoker-Role) assigned to the EC2 instances in Account B. Which of the following actions should the Solutions Architect take to meet these requirements? (Select two.)

Select all that apply

Enable AWS_IAM authorization on the private API Gateway API. Apply a resource policy to the API Gateway API that permits the execute-api:Invoke action for the API-Invoker-Role ARN from Account B, and denies all requests that do not originate from the interface VPC endpoint.

Create an Interface VPC Endpoint for API Gateway (com.amazonaws.region.execute-api) in Account A's VPC. Authorize the association of the automatically generated Route 53 private hosted zone in Account A with Account B's VPC, and then associate the private hosted zone with Account B's VPC.

Attach a Service Control Policy (SCP) at the Organization root that grants the API-Invoker-Role in Account B the execute-api:Invoke permission to the private API in Account A, ensuring the local IAM policies in Account B do not require modification.

Create an Interface VPC Endpoint for API Gateway (com.amazonaws.region.execute-api) in Account A's VPC, and rely on default Route 53 Resolver settings to resolve the private API endpoint DNS name across the Transit Gateway connection.

Configure a Direct Connect Gateway attached to the Transit Gateway to perform transitive routing of API Gateway traffic, and add a static route pointing to the regional public IP address of the API Gateway.

Show answer & explanation

Answer: Enable AWS_IAM authorization on the private API Gateway API. Apply a resource policy to the API Gateway API that permits the execute-api:Invoke action for the API-Invoker-Role ARN from Account B, and denies all requests that do not originate from the interface VPC endpoint.; Create an Interface VPC Endpoint for API Gateway (com.amazonaws.region.execute-api) in Account A's VPC. Authorize the association of the automatically generated Route 53 private hosted zone in Account A with Account B's VPC, and then associate the private hosted zone with Account B's VPC.

Answer

Configure the private API Gateway to use AWS_IAM authorization and apply a resource policy that allows the IAM role in Account B while restricting access to the VPC Endpoint. Additionally, deploy the execute-api VPC endpoint in Account A and associate its Route 53 private hosted zone with the VPC in Account B.

To securely integrate the private API Gateway in Account A with Account B, the solutions architect must configure AWS_IAM authorization on the API Gateway and define a resource policy that allows the IAM role in Account B while denying any traffic not originating from the Interface VPC Endpoint. Because the VPC endpoint is deployed in Account A, Route 53 Private Hosted Zone (PHZ) associations must be authorized and created for Account B's VPC. This allows the EC2 instances in Account B's VPC to resolve the private DNS endpoint names directly to the private IPs of the interface endpoint over the Transit Gateway connection.

Step-by-Step Solution

Configure identity-based access control for the API Gateway API.

By enabling AWS_IAM authorization, requests must be signed with AWS SigV4. The resource policy permits the specific IAM role from Account B to invoke the API, while a Deny block restricts traffic to the Interface VPC Endpoint ID to ensure network isolation.

This strengthens both identity and network security at the API Gateway boundary.

Set up private network connectivity and cross-account DNS resolution.

Creating an Interface VPC Endpoint in Account A provides a private entry point. Authorizing and accepting the Route 53 Private Hosted Zone (PHZ) association for Account B's VPC allows EC2 instances in Account B to resolve the API's private DNS name to the endpoint's private IP addresses.

This enables secure, private DNS resolution across the Transit Gateway connection without traversing the public internet.

Key Concept

Cross-account private API Gateway access requires combining Interface VPC Endpoints, cross-account Route 53 Private Hosted Zone associations, and API Gateway resource policies containing IAM and network conditions.

Estimated Time:2m 30s

Question 1428Question →

A global financial enterprise manages a multi-account environment using AWS Organizations. The central security team mandates that a security monitoring agent must run continuously on all Amazon EC2 instances across all member accounts. The installation and configuration of this agent are automated using AWS Systems Manager State Manager associations. Recently, the security team discovered that local administrators in several member accounts have manually disabled the Systems Manager agent on their instances or deleted the State Manager associations to bypass monitoring. A solutions architect must design an automated solution to detect and remediate this configuration drift while restricting member accounts from tampering with the security configurations. Which TWO actions should the solutions architect take to meet these requirements? (Select TWO.)

Select all that apply

Deploy an AWS Config organization rule using the systems-manager-association-compliance-status managed rule, and configure an AWS Systems Manager Automation runbook as the remediation target to reapply the association and restart the Systems Manager agent.

Store the Systems Manager State Manager configurations in a centralized Amazon S3 bucket encrypted with the AWS-managed KMS key (aws/s3), and modify the key policy to allow cross-account decryption permissions for member account IAM roles.

Attach a Service Control Policy (SCP) to the member account Organizational Units (OUs) that explicitly allows the AmazonSSMManagedInstanceCore role permissions to execute State Manager documents, bypassing the need for local IAM role configurations.

Instruct member account administrators to manually re-run the CloudFormation templates in the local console to remediate any configuration drift detected, ensuring they perform a rolling update to avoid downtime.

Configure an AWS CodeDeploy deployment group with a Canary 10% 5 Minutes deployment strategy to redeploy the State Manager configuration, and set up a CloudWatch alarm to trigger a rollback if any instance agent becomes inactive.

Show answer & explanation

Answer: Deploy a Service Control Policy (SCP) at the organization root level that denies the actions ssm:DeleteAssociation, ssm:UpdateAssociation, and ssm:CreateAssociation unless the principal is the central security administration role.; Deploy an AWS Config organization rule using the systems-manager-association-compliance-status managed rule, and configure an AWS Systems Manager Automation runbook as the remediation target to reapply the association and restart the Systems Manager agent.

Answer

Deploy a Service Control Policy (SCP) at the organization root level that denies the actions ssm:DeleteAssociation, ssm:UpdateAssociation, and ssm:CreateAssociation unless the principal is the central security administration role; and deploy an AWS Config organization rule using the systems-manager-association-compliance-status managed rule, and configure an AWS Systems Manager Automation runbook as the remediation target to reapply the association and restart the Systems Manager agent.

The correct options implement a robust control loop for security configurations. Denying association changes via an SCP enforces organizational boundaries, ensuring local admins cannot modify security settings. Concurrently, using the AWS Config organization rule 'systems-manager-association-compliance-status' paired with an SSM Automation runbook provides automated detection and remediation of configuration drift at the OS level.

Step-by-Step Solution

Evaluate access control mechanisms to prevent local modifications of Systems Manager State Manager associations.

Identify that a Service Control Policy (SCP) attached to the organization root can restrict member accounts from executing ssm:DeleteAssociation, ssm:UpdateAssociation, or ssm:CreateAssociation, while allowing the central team to manage configurations.

This guarantees that member account administrators cannot disable or alter the State Manager security baselines.

Determine the optimal drift detection and automated remediation strategy for a multi-account organization.

Use AWS Config organization rules, specifically the systems-manager-association-compliance-status managed rule, to monitor compliance status across all accounts.

AWS Config organization rules centralize compliance reporting and trigger automatic remediations at scale.

Configure the automated remediation action using AWS Systems Manager.

Link the AWS Config rule to an AWS Systems Manager Automation runbook that targets the non-compliant EC2 instances to restart the agent and reapply the association.

SSM Automation runbooks are the native and scalable mechanism for executing remediation scripts in response to AWS Config non-compliance findings.

Key Concept

Automated Drift Detection and Remediation in Multi-Account Governance

Estimated Time:3m 0s

Question 1429Question →

A media broadcasting platform operates a real-time interactive audience response system on Amazon EC2 instances in an Auto Scaling Group (ASG) behind an Application Load Balancer (ALB). The instances run in private subnets across two Availability Zones (AZ-A and AZ-B). A single NAT Gateway is deployed in AZ-A to enable outbound internet access for API integrations.

During a scheduled live broadcast, traffic spikes instantly from 500 requests per second to over 80,000 requests per second within 90 seconds. The application experiences elevated latencies, HTTP 503 Service Unavailable errors, and connection timeouts. A review of CloudWatch metrics shows:
1. The ALB drops connections immediately at the start of the traffic surge due to capacity constraints before it can scale.
2. The ASG launches new instances in response to CPU utilization metrics, but because the custom application initialization script takes 150 seconds to complete, the ASG continues to launch additional, unnecessary instances every 60 seconds.
3. An infrastructure outage in AZ-A causes outbound API calls on instances in AZ-B to fail.

Which combination of actions will resolve the scalability and fault-tolerance issues while preventing the provisioning of unnecessary instances?

Submit a request to AWS Support to pre-warm the Application Load Balancer prior to the scheduled broadcast. Deploy a NAT Gateway in AZ-B, and update the route table of the private subnets in AZ-B to route outbound traffic to the local NAT Gateway. Configure the Auto Scaling Group's scaling policy with an instance warmup period of 180 seconds.

Rely on the Application Load Balancer's automatic scaling behavior to handle the traffic surge. Deploy a NAT Gateway in AZ-B, and update the route table of the private subnets in AZ-B to route outbound traffic to the local NAT Gateway. Configure the Auto Scaling Group's scaling policy with an instance warmup period of 180 seconds.

Submit a request to AWS Support to pre-warm the Application Load Balancer prior to the scheduled broadcast. Deploy a NAT Gateway in AZ-B, and update the route table of the private subnets in AZ-B to route outbound traffic to the local NAT Gateway. Configure the Auto Scaling Group to use simple scaling policies with a cooldown period of 60 seconds to rapidly provision resources.

Submit a request to AWS Support to pre-warm the Application Load Balancer prior to the scheduled broadcast. Retain the single NAT Gateway in AZ-A to optimize costs, and establish a cross-AZ route from the private subnets in AZ-B to the NAT Gateway in AZ-A. Configure the Auto Scaling Group's scaling policy with an instance warmup period of 180 seconds.

Show answer & explanation

Answer: Submit a request to AWS Support to pre-warm the Application Load Balancer prior to the scheduled broadcast. Deploy a NAT Gateway in AZ-B, and update the route table of the private subnets in AZ-B to route outbound traffic to the local NAT Gateway. Configure the Auto Scaling Group's scaling policy with an instance warmup period of 180 seconds.

Answer

The correct configuration resolves all three architectural issues. Pre-warming the ALB ensures that the load balancer is scaled to the expected capacity beforehand, eliminating initial connection drops. Deploying a NAT Gateway in each Availability Zone removes the single point of failure, enabling fault-tolerant outbound connectivity. Setting the instance warmup period to 180 seconds prevents the Auto Scaling Group from launching unnecessary instances by allowing the custom bootstrap script to complete initialization before evaluating further scaling.

Step-by-Step Solution

Address the immediate ALB scaling bottleneck.

By pre-warming the ALB via AWS Support before the scheduled live broadcast, the ALB is pre-provisioned with adequate capacity to handle the sudden surge to 80,000 requests per second without dropping connections.

Standard ALB auto-scaling is reactive and cannot scale fast enough to meet an instantaneous surge of this magnitude.

Resolve the multi-AZ outbound routing fault tolerance issue.

Deploying a separate NAT Gateway in AZ-B and updating the local private subnet route table ensures that instances in AZ-B route outbound internet traffic through their local NAT Gateway.

This removes the dependency on AZ-A, ensuring high availability and local outbound routing even if AZ-A suffers a failure.

Optimize the Auto Scaling Group configuration to prevent over-provisioning.

Setting the instance warmup period to 180 seconds ensures that the ASG waits for the newly launched instances to complete their 150-second initialization and registration process before evaluating metrics for further scaling.

This prevents the ASG from launching redundant, unnecessary instances while existing instances are still bootstrapping.

Key Concept

Designing highly available, fault-tolerant, and cost-optimized scaling architectures for unpredictable or rapid traffic surges on AWS.

Question 1430Question →

A smart home IoT provider runs an ingestion service on Amazon EC2 instances in an Auto Scaling group (ASG) behind a Network Load Balancer (NLB) across two Availability Zones. The EC2 instances reside in private subnets and must access the internet to verify device firmware signatures. Outbound internet traffic is routed through a single NAT Gateway in one of the public subnets. During scheduled device update windows, traffic increases instantly by $400\%$ . The ASG fails to launch new instances quickly enough to handle the sudden load, causing connection timeouts. Additionally, any outage in the Availability Zone hosting the NAT Gateway halts firmware verification for all instances. Which two actions should a solutions architect take to resolve these issues?

Select all that apply

Deploy a NAT Gateway in each Availability Zone and update the route tables of the private subnets to route outbound traffic through the NAT Gateway in their respective Availability Zone.

Configure an Auto Scaling group warm pool with instances in the Stopped state to quickly scale out and handle the traffic spikes during updates.

Deploy a secondary NAT Gateway in the second Availability Zone and configure a custom script to dynamically update route tables if the primary NAT Gateway fails.

Configure target tracking scaling policies on the Auto Scaling group and set the instance warmup period to 15 seconds to ensure the group continuously adds new instances during the spike.

Submit a support ticket to AWS to pre-warm the Network Load Balancer (NLB) prior to the scheduled device update windows to prevent dropped requests.

Show answer & explanation

Answer: Deploy a NAT Gateway in each Availability Zone and update the route tables of the private subnets to route outbound traffic through the NAT Gateway in their respective Availability Zone.; Configure an Auto Scaling group warm pool with instances in the Stopped state to quickly scale out and handle the traffic spikes during updates.

Answer

To resolve these issues, the solutions architect should deploy a NAT Gateway in each Availability Zone and configure the route tables of the private subnets to route outbound traffic through their local NAT Gateway. In addition, they should configure an Auto Scaling group warm pool with instances in the Stopped state to handle the traffic spikes rapidly.

Deploying a NAT Gateway in each Availability Zone ensures that if one zone experiences an outage, instances in the remaining zone can still verify firmware signatures. Configuring an Auto Scaling group warm pool with instances in the Stopped state reduces scale-out latency because the instances are already pre-booted and bootstrapped, allowing them to transition to the running state and start serving traffic within seconds.

Step-by-Step Solution

Address the outbound connectivity single point of failure.

Deploy a NAT Gateway in each Availability Zone and update the route tables of the private subnets so that instances in each zone route traffic through their local NAT Gateway.

This configuration removes cross-Availability Zone dependency and ensures that an outage in one Availability Zone does not affect outbound traffic in the other.

Address the scaling latency under flash traffic surges.

Implement an Auto Scaling group warm pool with instances in the Stopped state.

A warm pool allows instances to complete their boot and initialization scripts beforehand, so they can transition to the active fleet almost instantly when needed.

Evaluate the non-viable configurations.

Rule out custom scripting for route tables, setting invalid warmup periods that cause over-provisioning, and requesting unnecessary pre-warming for the Network Load Balancer.

These alternatives either fail to resolve the root cause of the latency or introduce unnecessary operational complexity and architectural risk.

Key Concept

Deploying multi-AZ NAT Gateway redundancy and using Auto Scaling group warm pools to mitigate boot latency during sudden traffic spikes.

Question 1431Question →

A company is designing a new multi-VPC architecture on AWS in the eu-central-1 region. The architecture consists of vpc-app-prod (hosting production workloads across two Availability Zones) and vpc-shared-services (hosting centralized security tooling). The company has an on-premises data center that requires high-performance, private network connectivity to both VPCs using a dedicated AWS Direct Connect connection. Workloads in both VPCs must have outbound internet connectivity for software updates while maintaining high availability.

The DNS resolution requirements are as follows:
- Workloads in both VPCs must resolve private DNS names in the on-premises domain corp.internal.
- Workloads in vpc-app-prod must resolve private DNS hostnames for resources in vpc-shared-services hosted in a Route 53 Private Hosted Zone (PHZ) named shared.aws.internal.

Which design option meets these requirements with the lowest operational complexity while ensuring high availability and complete connectivity?

Connect both vpc-app-prod and vpc-shared-services directly to an AWS Direct Connect Gateway (DXGW) using Private Virtual Interfaces (Private VIFs), relying on the DXGW to route traffic between the VPCs. Associate the PHZ shared.aws.internal with vpc-shared-services only. Deploy a Route 53 Resolver outbound endpoint in vpc-shared-services across multiple Availability Zones, and associate the corp.internal forwarding rule with both VPCs. Deploy a NAT Gateway in each Availability Zone in both VPCs for outbound internet traffic.

Create an AWS Transit Gateway and attach both VPCs. Associate the Transit Gateway with an AWS Direct Connect Gateway (DXGW) connected via a Transit Virtual Interface (Transit VIF). Associate the PHZ shared.aws.internal with vpc-shared-services only, relying on Transit Gateway routing for resolution from vpc-app-prod. Deploy a Route 53 Resolver outbound endpoint in vpc-shared-services across multiple Availability Zones, and associate the corp.internal forwarding rule with both VPCs. Deploy a NAT Gateway in each Availability Zone in both VPCs for outbound internet traffic.

Create an AWS Transit Gateway and attach both VPCs. Associate the Transit Gateway with an AWS Direct Connect Gateway (DXGW) connected via a Transit Virtual Interface (Transit VIF). Associate the PHZ shared.aws.internal with both vpc-app-prod and vpc-shared-services. Deploy a Route 53 Resolver outbound endpoint in vpc-shared-services across multiple Availability Zones, and configure a forwarding rule for corp.internal associated with both VPCs. Deploy a NAT Gateway in each Availability Zone in both VPCs for outbound internet traffic.

Create an AWS Transit Gateway and attach both VPCs. Associate the Transit Gateway with an AWS Direct Connect Gateway (DXGW) connected via a Transit Virtual Interface (Transit VIF). Associate the PHZ shared.aws.internal with both vpc-app-prod and vpc-shared-services. Deploy a Route 53 Resolver outbound endpoint in vpc-shared-services across multiple Availability Zones, and configure a forwarding rule for corp.internal associated with both VPCs. Deploy a single NAT Gateway in a single Availability Zone in each VPC, routing all outbound traffic from all private subnets within that VPC through the single NAT Gateway.

Show answer & explanation

Answer: Create an AWS Transit Gateway and attach both VPCs. Associate the Transit Gateway with an AWS Direct Connect Gateway (DXGW) connected via a Transit Virtual Interface (Transit VIF). Associate the PHZ shared.aws.internal with both vpc-app-prod and vpc-shared-services. Deploy a Route 53 Resolver outbound endpoint in vpc-shared-services across multiple Availability Zones, and configure a forwarding rule for corp.internal associated with both VPCs. Deploy a NAT Gateway in each Availability Zone in both VPCs for outbound internet traffic.

Answer

The design utilizing AWS Transit Gateway with a Transit VIF to a Direct Connect Gateway, associating the Route 53 Private Hosted Zone with both VPCs, deploying Route 53 Resolver outbound endpoints across multiple Availability Zones, and deploying a NAT Gateway in each Availability Zone in both VPCs for high-availability egress.

The correct design utilizes an AWS Transit Gateway to interconnect the VPCs and routes hybrid traffic over a Transit VIF to the Direct Connect Gateway. It associates the Route 53 Private Hosted Zone with both VPCs to enable cross-VPC name resolution, and uses redundant NAT Gateways in each Availability Zone to eliminate single points of failure for outbound internet traffic.

Step-by-Step Solution

Configure hybrid connectivity using AWS Transit Gateway.

Connect both VPCs to an AWS Transit Gateway (TGW). Associate the TGW with an AWS Direct Connect Gateway (DXGW) attached via a Transit VIF to route traffic privately between both VPCs and the on-premises data center.

Direct Connect Gateway alone does not support transitive VPC-to-VPC routing; a Transit Gateway is required for multi-VPC routing over Direct Connect.

Configure cross-VPC DNS resolution.

Associate the Route 53 Private Hosted Zone shared.aws.internal with both vpc-app-prod and vpc-shared-services.

Route 53 Private Hosted Zones require explicit association with every VPC that needs to resolve records within that hosted zone.

Configure outbound DNS resolution for the on-premises domain.

Deploy an outbound Route 53 Resolver endpoint in multiple Availability Zones in vpc-shared-services. Create a forwarding rule for corp.internal pointing to on-premises DNS servers, and associate the rule with both VPCs.

This allows resources in both VPCs to forward queries for corp.internal to the on-premises network securely and with high availability.

Establish highly available internet egress.

Deploy a NAT Gateway in each Availability Zone's public subnet in both VPCs, updating private subnet route tables to route 0.0.0.0/0 traffic to the local zone's NAT Gateway.

Deploying one NAT Gateway per Availability Zone ensures that an outage in a single Availability Zone does not disrupt outbound internet connectivity for workloads running in other zones.

Key Concept

Design of a highly available, multi-VPC hybrid network architecture utilizing AWS Transit Gateway, Direct Connect Gateway, Route 53 Resolver endpoints, and multi-AZ NAT Gateways.

Estimated Time:3m 0s

Question 1432Question →

A financial technology company operates a stock trading platform where user portfolios and real-time transaction histories are stored in an Amazon Aurora MySQL database cluster. During periods of high market volatility, the database writer node experiences performance degradation due to high CPU utilization from a surge in application connection requests, and the read replicas experience significant replication lag. This replication lag causes users to view stale portfolio balances, leading to duplicate transaction attempts. The platform requires real-time read access to portfolio data with sub-millisecond latency, transaction session state persistence, and minimal database load.

Which combination of actions will resolve these issues while meeting the requirements? (Select TWO.)

Select all that apply

Implement Amazon ElastiCache for Redis in a Multi-AZ replication group to cache portfolio balances, utilizing a write-through strategy to keep the cache updated.

Deploy Amazon RDS Proxy between the application layer and the Aurora MySQL cluster to pool and share database connections, reducing CPU overhead on the primary writer.

Implement Amazon ElastiCache for Memcached to store user portfolio balances and session states, configuring multi-region replication to ensure data persistence during failovers.

Direct read-heavy portfolio valuation queries to the RDS Multi-AZ standby instance of the database cluster to offload read traffic from the primary writer node.

Configure an Amazon ElastiCache for Memcached cluster to act as a write-through cache for transaction histories, enabling Append Only File (AOF) persistence to prevent data loss.

Show answer & explanation

Answer: Implement Amazon ElastiCache for Redis in a Multi-AZ replication group to cache portfolio balances, utilizing a write-through strategy to keep the cache updated.; Deploy Amazon RDS Proxy between the application layer and the Aurora MySQL cluster to pool and share database connections, reducing CPU overhead on the primary writer.

Answer

Deploy Amazon ElastiCache for Redis in a Multi-AZ replication group using a write-through strategy, and deploy Amazon RDS Proxy between the application layer and the Aurora MySQL cluster.

Implementing ElastiCache for Redis provides the required sub-millisecond read latency, high availability (via Multi-AZ), and support for data persistence and replication. A write-through caching strategy ensures that portfolio balances are updated in the cache synchronously when written to the database, preventing stale reads. Deploying Amazon RDS Proxy pools database connections, which significantly reduces the CPU load on the database writer node during application connection surges.

Step-by-Step Solution

Analyze the database performance bottlenecks and technical requirements.

Identify that the primary writer is CPU-constrained due to connection surges, and the read replicas have replication lag causing stale reads.

This defines the target areas for improvement: connection pooling for the writer and caching for read-heavy operations.

Select the appropriate caching technology and strategy for portfolio balances.

Choose Amazon ElastiCache for Redis with Multi-AZ replication and a write-through caching strategy.

Redis supports Multi-AZ replication and data persistence, which are required for portfolio balances and session state, while write-through ensures cache consistency.

Select a solution to handle connection surges and reduce writer CPU usage.

Introduce Amazon RDS Proxy between the application layer and the Aurora MySQL cluster.

RDS Proxy manages connection pools to prevent CPU spikes on the database cluster, ensuring efficient resource utilization during high volatility.

Key Concept

Improving database and caching efficiency involves using Redis for persistent, highly-available caching and RDS Proxy for connection pooling under high write and connection loads.

Question 1433Question →

A fleet telematics platform for a global shipping company tracks container location, internal temperature, and humidity sensors. The telemetry data ingestion service writes updates to an Amazon RDS for PostgreSQL DB instance. A fleet dashboard application frequently queries the database to retrieve the latest state configurations for thousands of active containers. During shift handovers, query volume to retrieve container state configurations spikes dramatically, causing the RDS DB instance to reach 98% CPU utilization and leading to timeout errors in the dashboard. The container state configuration data is highly repetitive, must survive cache node restarts, and requires high availability with sub-millisecond read latency and automatic failover across multiple Availability Zones. Which of the following database and caching strategies should a Solutions Architect implement to resolve the performance bottleneck while meeting the availability and latency requirements?

Configure the Amazon RDS for PostgreSQL DB instance to use a Multi-AZ deployment. Modify the dashboard application's read database connection strings to target the secondary standby DB instance's endpoint during query spikes, offloading the primary DB instance.

Deploy an Amazon ElastiCache for Memcached cluster with nodes distributed across multiple Availability Zones. Configure the dashboard application to use client-side hashing to partition the container state configuration data across the nodes, and enable automatic multi-AZ replication to ensure the configuration data survives node failures.

Deploy an Amazon ElastiCache for Redis replication group with Multi-AZ and automatic failover enabled. Modify the dashboard application to use a cache-aside pattern to read container configurations from ElastiCache, falling back to the PostgreSQL database on cache misses and writing updates to the cache when the database is updated.

Set up a pilot light disaster recovery database environment in a secondary AWS Region with a smaller instance class using cross-region replication. During peak shift handovers, configure the dashboard application to route all container state queries to the secondary region's database to offload the primary database.

Show answer & explanation

Answer: Deploy an Amazon ElastiCache for Redis replication group with Multi-AZ and automatic failover enabled. Modify the dashboard application to use a cache-aside pattern to read container configurations from ElastiCache, falling back to the PostgreSQL database on cache misses and writing updates to the cache when the database is updated.

Answer

Deploy an Amazon ElastiCache for Redis replication group with Multi-AZ and automatic failover enabled, and use a cache-aside pattern in the fleet dashboard application.

Deploying Amazon ElastiCache for Redis with replication and Multi-AZ enabled provides sub-millisecond read latency, handles high read-traffic spikes, ensures high availability with automatic failover, and maintains cached data across node restarts because Redis supports data persistence and replication.

Step-by-Step Solution

Analyze database requirements and workload characteristics

Identified high CPU utilization on RDS PostgreSQL due to read spikes of static container state configurations, requiring sub-millisecond response times, persistence, and high availability with automatic failover.

To select the appropriate caching or database scaling mechanism that satisfies all constraints.

Evaluate ElastiCache engines (Redis vs. Memcached)

ElastiCache for Redis supports replication, Multi-AZ with automatic failover, and persistence (data surviving node restarts), whereas Memcached does not support replication or persistence.

To ensure the caching layer meets the high availability and survival requirements.

Evaluate RDS architecture options (Multi-AZ vs. Read Replicas)

RDS Multi-AZ standby instances are passive and cannot serve reads. RDS Read Replicas can serve reads but have higher latency than ElastiCache and do not solve the sub-millisecond requirement as efficiently.

To rule out invalid database routing configurations.

Select the correct pattern

Deploying ElastiCache for Redis with Multi-AZ and applying a cache-aside pattern in the fleet dashboard application resolves the bottleneck.

To achieve sub-millisecond read latency, high availability, and database load reduction.

Key Concept

Improving Database and Caching Efficiency using ElastiCache for Redis

Estimated Time:2m 0s

Question 1434Question →

A logistics enterprise is designing a real-time global shipment tracking system. The system must process high-frequency status updates (OLTP NoSQL) from delivery agents across two primary regions: $us-east-1$ and $eu-west-1$ . Read and write operations must be supported locally in both regions with sub- $10\text{ ms}$ latency, automatically resolving write conflicts based on the latest physical timestamp. The disaster recovery requirements specify a Recovery Time Objective (RTO) of less than $1\text{ minute}$ and a Recovery Point Objective (RPO) of less than $10\text{ seconds}$ . Furthermore, the raw tracking telemetry must be exported hourly to an Amazon S3 bucket located in a centralized analytics AWS account within a separate AWS organization. Corporate security policies require all data at rest to be encrypted. To prevent unauthorized access, the encryption keys must support cross-account policy delegation, and the destination S3 bucket must enforce secure transport. Which database and storage architecture meets these requirements with the lowest operational complexity?

Deploy Amazon DynamoDB global tables replicated between

us-east-1

and

eu-west-1

, encrypted using regional Customer Managed Keys (CMKs) in AWS KMS. Configure an Amazon EventBridge Scheduler rule to trigger an AWS Lambda function hourly that reads from DynamoDB and writes to the centralized S3 bucket. Ensure the S3 bucket in the analytics account is encrypted using a Customer Managed Key (CMK) owned by the analytics account with a key policy allowing cross-account access, and its bucket policy denies `s3:PutObject` requests without secure transport or the correct KMS encryption headers.

Deploy Amazon Aurora Global Database PostgreSQL with write forwarding enabled from

eu-west-1

us-east-1

. Encrypt the database clusters using default AWS-managed KMS keys (`aws/rds`). Configure Aurora Auto Scaling on the reader instances in the secondary region to handle scaling and write latency. Export data hourly to the centralized S3 bucket encrypted with the AWS-managed KMS key (`aws/s3`) by delegating cross-account access through an IAM role policy in the source account.

Deploy a single-region Amazon DynamoDB table in

us-east-1

encrypted with a Customer Managed Key (CMK). Configure Amazon S3 Cross-Region Replication (CRR) to replicate hourly table backups to

eu-west-1

to implement a Pilot Light disaster recovery strategy. Run a cron job on an Amazon EC2 instance to export the DynamoDB table data hourly, encrypt it using the default AWS-managed S3 key (`aws/s3`), and transfer it to the S3 bucket in the centralized analytics account.

Deploy Amazon DynamoDB global tables replicated between

us-east-1

and

eu-west-1

, encrypted using the default AWS-managed KMS key (`aws/dynamodb`). Configure a centralized S3 bucket in the analytics account encrypted with the AWS-managed KMS key (`aws/s3`). Configure an AWS Glue ETL job to run hourly, fetching data from DynamoDB and writing to the S3 bucket. Add a cross-account IAM policy to the Glue execution role in the source account to allow access to the target S3 bucket and its AWS-managed KMS key.

Show answer & explanation

Answer: Deploy Amazon DynamoDB global tables replicated between $us-east-1$ and $eu-west-1$ , encrypted using regional Customer Managed Keys (CMKs) in AWS KMS. Configure an Amazon EventBridge Scheduler rule to trigger an AWS Lambda function hourly that reads from DynamoDB and writes to the centralized S3 bucket. Ensure the S3 bucket in the analytics account is encrypted using a Customer Managed Key (CMK) owned by the analytics account with a key policy allowing cross-account access, and its bucket policy denies `s3:PutObject` requests without secure transport or the correct KMS encryption headers.

Answer

Deploy Amazon DynamoDB global tables with regional Customer Managed Keys (CMKs), and export the data hourly to the centralized S3 bucket encrypted with an analytics-account-owned CMK configured for cross-account access.

The correct design uses Amazon DynamoDB global tables to satisfy the OLTP NoSQL requirement, achieving sub-10 ms read/write latency in both regions with active-active write capability and near-zero RPO. For the cross-organization S3 export, using Customer Managed Keys (CMKs) in the target account is necessary because their key policies can be modified to grant cross-account permissions. Enforcing secure transport via S3 bucket policies fulfills the security requirement.

Step-by-Step Solution

Analyze the database requirements for latency, workload type, and replication.

The system requires an OLTP NoSQL database with local read/write access under 10 ms in both regions, conflict resolution, RTO < 1 minute, and RPO < 10 seconds. Amazon DynamoDB global tables meet all of these criteria by providing multi-region active-active replication with low latency and default last-write-wins physical timestamp conflict resolution.

Eliminates single-region options (which fail latency/DR metrics) and relational databases like Aurora (where cross-region write forwarding violates the latency requirement).

Evaluate the encryption and cross-organization sharing constraints.

Exporting data to an S3 bucket in a separate AWS organization requires cross-account permissions. This applies to both the S3 bucket policy and the KMS key policy used to encrypt the S3 objects.

AWS-managed KMS keys (such as `aws/s3` or `aws/dynamodb`) cannot be shared cross-account because their key policies are read-only and cannot be modified. Thus, Customer Managed Keys (CMKs) must be used.

Verify compliance and transport controls.

The destination S3 bucket policy must enforce encryption at rest and secure transport (SSL/TLS) via `aws:SecureTransport` denials, and use a CMK owned by the destination account with policy delegation to the source account role.

Ensures that security policies are met while allowing authorized cross-account writes to succeed.

Key Concept

Multi-region active-active database design using DynamoDB Global Tables, combined with secure cross-account data sharing using AWS KMS Customer Managed Keys (CMKs) and S3 bucket policies.

Estimated Time:2m 30s

Question 1435Question →

A global energy trading firm is designing a high-throughput settlement ledger system (OLTP workload) that must span two AWS Regions: us-east-1 (primary) and us-west-2 (secondary) to support near-real-time transactions. The database requires strict ACID compliance and must handle high-volume write transactions in the primary region, while read traffic must scale horizontally in both regions to support analyst dashboards. The architecture must satisfy a Recovery Point Objective (RPO) of 1 minute and a Recovery Time Objective (RTO) of 5 minutes. Additionally, security compliance mandates that the database be encrypted at rest using Customer Managed Keys (CMKs) and all database audit logs must be securely centralized in an Amazon S3 bucket located in a dedicated, separate security account. Which design strategy meets these database performance, disaster recovery, and security compliance requirements?

Deploy an Amazon Aurora PostgreSQL Global Database with the primary cluster in us-east-1 and a secondary cluster in us-west-2. Configure Aurora Auto Scaling on the reader instances in both regions. Encrypt the clusters using regional Customer Managed Keys (CMKs) in their respective regions. Configure PostgreSQL audit logs (pgAudit) to publish to Amazon CloudWatch Logs, and use an Amazon Kinesis Data Firehose stream in each region to deliver the logs to the centralized S3 bucket, ensuring the security account's S3 bucket policy grants s3:PutObject permissions to the Firehose IAM roles.

Deploy a Multi-AZ Amazon RDS for PostgreSQL DB instance in us-east-1 and configure a cross-region read replica in us-west-2. Configure target tracking scaling policies to dynamically add standby instances to the Multi-AZ deployment during read spikes. Encrypt the primary database and replica using the default AWS-managed KMS key (aws/rds). Configure a script on an Amazon EC2 instance to periodically copy PostgreSQL audit logs to the centralized S3 bucket using cross-account IAM roles.

Deploy an Amazon Aurora PostgreSQL Global Database with the primary cluster in us-east-1 and a secondary cluster in us-west-2. Encrypt both the primary and secondary clusters using a single, shared Customer Managed Key (CMK) ARN created in us-east-1 to ensure cryptographic parity during replication. Configure Aurora to export logs directly to the security account's S3 bucket using an S3 VPC endpoint, without modifying the destination bucket policy since both accounts belong to the same AWS Organization.

Deploy an Amazon Aurora PostgreSQL DB cluster in us-east-1. Configure AWS Backup to take continuous backups and copy them to us-west-2. Set up a pilot light environment in us-west-2 consisting of an inactive Aurora DB cluster. In the event of a primary region failure, restore the latest backup to the pilot light cluster. Configure the database to write audit logs to a local S3 bucket, and use S3 Cross-Region Replication (CRR) to replicate the log files to the centralized security account's S3 bucket without configuring a destination bucket 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. Configure Aurora Auto Scaling on the reader instances in both regions. Encrypt the clusters using regional Customer Managed Keys (CMKs) in their respective regions. Configure PostgreSQL audit logs (pgAudit) to publish to Amazon CloudWatch Logs, and use an Amazon Kinesis Data Firehose stream in each region to deliver the logs to the centralized S3 bucket, ensuring the security account's S3 bucket policy grants s3:PutObject permissions to the Firehose IAM roles.

Answer

Deploy an Amazon Aurora PostgreSQL Global Database with regional Customer Managed Keys (CMKs) in each region, configuring Aurora Auto Scaling on reader instances, publishing audit logs to CloudWatch Logs, and using Kinesis Data Firehose to stream them to the centralized S3 bucket with a bucket policy that permits s3:PutObject.

The correct answer leverages Amazon Aurora PostgreSQL Global Database, which offers cross-region replication latency under 1 second (satisfying the 1-minute RPO) and can be promoted to a primary cluster in less than 1 minute (satisfying the 5-minute RTO). Readers in both regions can scale horizontally using Aurora Auto Scaling. Encryption compliance is maintained by utilizing regional Customer Managed Keys (CMKs) in each region. Centralized logging is achieved by exporting database audit logs to CloudWatch Logs and streaming them to the security account's S3 bucket using Kinesis Data Firehose, with proper cross-account s3:PutObject permissions defined in the destination S3 bucket policy.

Step-by-Step Solution

Determine the optimal database replication architecture for OLTP and RTO/RPO targets.

Amazon Aurora Global Database provides sub-second replication lag (meeting the RPO of 1 minute) and supports regional failover within 1 minute (meeting the RTO of 5 minutes).

Traditional RDS read replicas or AWS Backup restore mechanisms cannot meet the strict 5-minute RTO.

Analyze options for scaling read capacity dynamically in both regions.

Aurora reader instances (replicas) in both the primary and secondary clusters can scale horizontally using Aurora Auto Scaling.

RDS Multi-AZ standby instances are passive and cannot serve read traffic or auto-scale horizontally.

Determine KMS key replication constraints across regions.

AWS KMS keys are regional resource types. To encrypt the Aurora Global Database, regional Customer Managed Keys (CMKs) must be created in both us-east-1 and us-west-2.

A single KMS key ARN cannot be shared or referenced across different AWS regions.

Evaluate cross-account log centralization and security controls.

Exporting logs to CloudWatch and streaming them via Kinesis Data Firehose allows secure, cross-account delivery to S3, provided the target S3 bucket policy explicitly allows s3:PutObject for the Firehose roles.

Logs cannot write cross-account without explicit permission policies on the target S3 bucket.

Key Concept

Multi-region database architectures with strict RTO/RPO requirements, KMS multi-region boundary limitations, and secure cross-account log centralization.

Estimated Time:3m 0s

Question 1436Question →

An enterprise is planning to migrate an on-premises Oracle 19c database containing several tables with large binary objects (LOBs) and complex PL/SQL packages to Amazon Aurora PostgreSQL-Compatible Edition. The migration must minimize downtime and maintain transactional consistency. Which actions should the Solutions Architect recommend to achieve this? (Select two.)

Select all that apply

Enable database-level and table-level supplemental logging on the source Oracle database, and run an AWS DMS replication task using Limited LOB mode with an optimized max LOB size to replicate the data and capture changes.

Deploy AWS Application Migration Service (MGN) to perform a block-level replication of the source Oracle server directly to the Aurora PostgreSQL DB cluster to automate the migration and bypass schema conversion.

Configure the AWS DMS replication task to target the reader endpoint of the Aurora PostgreSQL DB cluster to offload write operations during the migration and prevent performance degradation of the primary writer instance.

Configure the AWS DMS replication task to use Full LOB mode to replicate all binary data without truncation, and configure the replication task to automatically capture changes without modifying source logging settings.

Show answer & explanation

Answer: Use the AWS Schema Conversion Tool (AWS SCT) to convert the Oracle database schemas and PL/SQL code to PostgreSQL-compatible formats, and install the AWS SCT extension pack on the target Aurora PostgreSQL DB cluster to emulate unsupported functions.; Enable database-level and table-level supplemental logging on the source Oracle database, and run an AWS DMS replication task using Limited LOB mode with an optimized max LOB size to replicate the data and capture changes.

Answer

Use the AWS Schema Conversion Tool (AWS SCT) to convert the Oracle database schemas and PL/SQL code to PostgreSQL-compatible formats, and install the AWS SCT extension pack on the target Aurora PostgreSQL DB cluster to emulate unsupported functions. Additionally, enable database-level and table-level supplemental logging on the source Oracle database, and run an AWS DMS replication task using Limited LOB mode with an optimized max LOB size to replicate the data and capture changes.

The correct options are to use the AWS Schema Conversion Tool (AWS SCT) with its extension pack to convert and emulate the schema, and to enable supplemental logging on the source Oracle database while utilizing Limited LOB mode in the AWS DMS task. AWS SCT converts the schema to PostgreSQL format, and the extension pack provides emulation of features not native to PostgreSQL. Enabling supplemental logging is mandatory for AWS DMS to parse redo logs during Change Data Capture (CDC). Limited LOB mode optimizes replication performance by pre-allocating memory buffers for LOB columns.

Step-by-Step Solution

Assess the source database schemas and convert them to the target engine format.

The Oracle schemas, including PL/SQL packages, are converted using the AWS Schema Conversion Tool (AWS SCT). An extension pack is applied to the target Aurora PostgreSQL DB cluster to emulate features like Oracle-specific functions.

Heterogeneous migrations require schema conversion before data migration. SCT handles the translation and provides an extension pack for compatibility.

Prepare the source Oracle database for Change Data Capture (CDC).

Database-level and table-level supplemental logging are enabled on the source Oracle database.

AWS DMS CDC requires supplemental logging on Oracle to identify which columns changed and to reconstruct the transaction logs.

Configure and run the AWS DMS task.

An AWS DMS task is created with Limited LOB mode configured to capture changes and perform the initial full load efficiently.

Limited LOB mode is optimal for migration performance, and setting a max LOB size prevents task performance degradation while ensuring LOB columns are migrated within defined limits.

Key Concept

Heterogeneous database migration using AWS Schema Conversion Tool (SCT) for schema conversion and AWS Database Migration Service (DMS) with Change Data Capture (CDC) and LOB configuration.

Question 1437Question →

An enterprise manages a multi-account environment under AWS Organizations with consolidated billing enabled. In one member account, a critical production workload consists of:

* An Amazon ECS on AWS Fargate application running 20 tasks continuously across three Availability Zones (AZs). Each task is configured with 4 vCPU and 16 GB of memory. CloudWatch metrics over the past 90 days show that CPU utilization averages $15\%$ , while memory utilization peaks at $92\%$ during daily traffic spikes.
* A stateful processing layer consisting of 6 self-managed EC2 instances in an Auto Scaling group running on `m6i.2xlarge` instances ( $8$ vCPU, $32$ GiB RAM) across two AZs. CloudWatch metrics show average CPU utilization at $12\%$ and memory utilization at $18\%$ , but the application experiences occasional, unpredictable network throughput bursts.
* Outbound internet traffic for both the ECS tasks and the EC2 instances is routed through a single NAT Gateway located in a public subnet in AZ-A to minimize running costs.

The company wants to optimize its infrastructure costs while maintaining high availability, ensuring performance during peak loads, and maximizing the discount from Savings Plans across the entire AWS Organization.

Which set of actions will achieve the maximum cost optimization while satisfying all availability and performance requirements?

Downsize the Amazon ECS Fargate tasks to 2 vCPU and 16 GB of memory. Downsize the EC2 instances to `m6i.xlarge`. Deploy a NAT Gateway in each of the three Availability Zones and update the route tables. Purchase Compute Savings Plans at the AWS Organizations management account level with sharing enabled.

Downsize the Amazon ECS Fargate tasks to 2 vCPU and 16 GB of memory. Downsize the EC2 instances to `m6i.xlarge`. Deploy a NAT Gateway in each of the three Availability Zones and update the route tables. Purchase EC2 Instance Savings Plans for the `m6i` family at the AWS Organizations management account level with sharing enabled.

Downsize the Amazon ECS Fargate tasks to 2 vCPU and 16 GB of memory. Downsize the EC2 instances to `m6i.xlarge`. Retain the single NAT Gateway in AZ-A to avoid additional NAT Gateway hourly charges. Purchase Compute Savings Plans at the AWS Organizations management account level with sharing enabled.

Downsize the Amazon ECS Fargate tasks to 2 vCPU and 16 GB of memory. Share the EC2 instances across the other member accounts using AWS Resource Access Manager (RAM) to consolidate idle capacity. Deploy a NAT Gateway in each of the three Availability Zones and update the route tables. Purchase Compute Savings Plans at the AWS Organizations management account level with sharing enabled.

Show answer & explanation

Answer: Downsize the Amazon ECS Fargate tasks to 2 vCPU and 16 GB of memory. Downsize the EC2 instances to `m6i.xlarge`. Deploy a NAT Gateway in each of the three Availability Zones and update the route tables. Purchase Compute Savings Plans at the AWS Organizations management account level with sharing enabled.

Answer

Downsize the Amazon ECS Fargate tasks to 2 vCPU and 16 GB of memory, downsize the EC2 instances to `m6i.xlarge`, deploy a NAT Gateway in each of the three Availability Zones, and purchase Compute Savings Plans at the AWS Organizations management account level with sharing enabled.

The correct solution reduces CPU on ECS Fargate from 4 vCPU to 2 vCPU while retaining the 16 GB of memory, which matches the memory-bound workload requirements. It downsizes the EC2 instances to `m6i.xlarge` to cut compute costs while preserving sufficient RAM and network burst capability. To satisfy high availability, it deploys a NAT Gateway in each Availability Zone. Finally, purchasing Compute Savings Plans at the AWS Organizations management account level ensures that both the EC2 instances and ECS Fargate tasks across all member accounts receive the discount.

Step-by-Step Solution

Analyze the Amazon ECS Fargate task metrics to determine right-sizing requirements.

The tasks are CPU-idle (

15\%

of 4 vCPU is

0.6

vCPU) but memory-constrained (peaking at

92\%

of 16 GB is

14.72

GB). The tasks can be downsized to 2 vCPU and 16 GB memory, which is a supported configuration, reducing CPU cost by 50% while fully accommodating memory peaks.

To optimize ECS costs without degrading performance during traffic bursts.

Analyze the EC2 instances' metrics and network performance requirements.

The current `m6i.2xlarge` instances (

8

vCPU,

32

GiB RAM) have low CPU and memory utilization (

12\%

CPU,

18\%

memory). Downsizing to `m6i.xlarge` (

4

vCPU,

16

GiB RAM) leaves ample CPU and memory headroom (

16

GiB is greater than the

5.76

GiB needed) and preserves up to 12.5 Gbps network burst capability, keeping costs to a minimum.

To scale down the EC2 instances while retaining capacity for network throughput spikes.

Review the outbound network routing and high availability architecture.

A single NAT Gateway in AZ-A is a single point of failure. To maintain high availability across the three AZs, a NAT Gateway must be deployed in each AZ, and the private subnet route tables must be updated to route traffic locally.

To ensure that an outage in a single Availability Zone does not disrupt outbound traffic for resources in other zones.

Select the correct Savings Plan type and scope for a multi-account organization.

Compute Savings Plans apply to EC2, Fargate, and Lambda across all accounts under consolidated billing. Purchasing Compute Savings Plans at the management account level maximizes the coverage and utilization of the discount. EC2 Instance Savings Plans would exclude the Fargate workloads.

To optimize savings across both EC2 and ECS Fargate workloads within the AWS Organization.

Key Concept

Multi-dimensional resource right-sizing (compute vs. memory constraints), high availability network routing design, and the distinction between Compute and Instance Savings Plans in multi-account AWS Organizations.

Estimated Time:3m 0s

Question 1438Question →

An enterprise is planning to migrate its application portfolio to AWS. During the discovery phase, a solutions architect assesses the following workloads and constraints:

* Supply Chain Portal: An IIS-based web application running on Windows Server 2016. The team wants to migrate the application with minimal changes, but wants to eliminate the overhead of operating system patching and infrastructure management by utilizing a managed service.
* Inventory Database: A business-critical Oracle Database Enterprise Edition with extensive PL/SQL stored procedures. The enterprise wants to eliminate commercial database licensing costs by migrating to Amazon Aurora PostgreSQL.
* Historical Document Archive: A 150 TB network-attached storage (NAS) share containing PDF documents. The migration must complete within a strict 10-day maintenance window. The company's outbound internet connection is limited to 50 Mbps.

Which of the following migration strategies or approaches should the solutions architect select? (Select TWO.)

Select all that apply

Classify the migration of the IIS-based web application to AWS Elastic Beanstalk as a Replatform strategy.

Classify the migration of the Oracle Database to Amazon Aurora PostgreSQL as a Refactor (Re-architect) strategy.

Classify the migration of the Oracle Database to Amazon Aurora PostgreSQL as a Replatform strategy.

Migrate the 150 TB Historical Document Archive over the 50 Mbps internet connection using AWS DataSync to meet the 10-day window.

Classify the migration of the IIS-based web application to AWS Elastic Beanstalk as a Rehost strategy.

Show answer & explanation

Answer: Classify the migration of the IIS-based web application to AWS Elastic Beanstalk as a Replatform strategy.; Classify the migration of the Oracle Database to Amazon Aurora PostgreSQL as a Refactor (Re-architect) strategy.

Answer

Classifying the migration of the IIS-based web application to AWS Elastic Beanstalk as a Replatform strategy, and classifying the migration of the Oracle Database to Amazon Aurora PostgreSQL as a Refactor (Re-architect) strategy.

The correct strategies are Replatform for the web tier and Refactor for the database tier. Migrating the web application to AWS Elastic Beanstalk allows the organization to avoid OS management overhead while keeping the core application intact, which is the definition of a Replatform strategy. Migrating the Oracle Database to Aurora PostgreSQL requires a heterogeneous database conversion, involving rewriting PL/SQL stored procedures and altering application logic, which represents a Refactor/Re-architect strategy.

Step-by-Step Solution

Analyze the Supply Chain Portal migration path.

The target is AWS Elastic Beanstalk, which is a platform-as-a-service (PaaS). Since it reduces OS administrative overhead without requiring application code changes, it is classified as Replatform.

To distinguish between Rehost (lift-and-shift to EC2) and Replatform (lift, tinker, and shift to a managed service).

Analyze the Inventory Database migration path.

The target is Amazon Aurora PostgreSQL, which requires moving from a commercial engine (Oracle) to an open-source engine. This necessitates schema conversion and code rewrite of PL/SQL, classifying it as Refactor (Re-architect).

To identify that heterogeneous database migrations require refactoring/re-architecting rather than simple replatforming.

Analyze the network bandwidth constraint for the Historical Document Archive.

150 TB of data over a 50 Mbps connection takes approximately

150 \times 10^{12} \times 8 / (50 \times 10^6 \times 3600 \times 24) \approx 277

days. This exceeds the 10-day constraint, making network transfer infeasible and requiring AWS Snowball Edge.

To calculate transfer time constraints and rule out network-based transfer options.

Key Concept

Selecting and classifying workload migration strategies using the 7 Rs framework based on operational, architectural, and resource constraints.

Question 1439Question →

An enterprise manages its multi-account environment using AWS Organizations. The central platform team maintains a dedicated CI/CD tooling account, while applications run in separate member accounts. A critical microservice hosted on Amazon ECS (Fargate) in a member application account needs its deployment process automated.

The platform team designs a cross-account pipeline in the tooling account using AWS CodePipeline. The pipeline builds the container image, pushes it to Amazon ECR, and triggers AWS CodeDeploy in the member application account to perform a blue/green deployment. The deployment must meet these requirements:
- Shift $10\%$ of traffic to the new version, wait exactly $10$ minutes, and then shift the remaining $90\%$ of traffic.
- Automatically roll back the deployment if the HTTP $5\text{XX}$ error count on the production listener spikes during traffic shifting.
- Maintain a secure, cross-account artifact sharing model with minimal operational overhead.

Which configuration will meet these requirements?

Encrypt the S3 artifact bucket in the tooling account with a Customer Managed Key (CMK). Grant the cross-account execution role in the application account decrypt and read permissions on the CMK and S3 bucket. In the application account, configure the CodeDeploy deployment group to use the predefined ECSLinear10PercentEvery1Minute deployment configuration, and associate the deployment group with a CloudWatch alarm monitoring HTTPCode_Target_5XX_Count on the Application Load Balancer's production listener.

Encrypt the S3 artifact bucket in the tooling account with a Customer Managed Key (CMK). Grant the cross-account execution role in the application account decrypt and read permissions on the CMK and S3 bucket. In the application account, create a custom CodeDeploy deployment configuration with a traffic routing type of TimeBasedCanary, a CanaryPercentage of 10%, and a CanaryInterval of 10 minutes. Associate the CodeDeploy deployment group with a CloudWatch alarm monitoring HTTPCode_Target_5XX_Count on the Application Load Balancer's production listener.

Encrypt the S3 artifact bucket in the tooling account with the default AWS-managed KMS key (aws/s3). Grant the cross-account execution role in the application account read permissions on the S3 bucket. In the application account, create a custom CodeDeploy deployment configuration with a traffic routing type of TimeBasedCanary, a CanaryPercentage of 10%, and a CanaryInterval of 10 minutes. Associate the CodeDeploy deployment group with a CloudWatch alarm monitoring HTTPCode_Target_5XX_Count on the Application Load Balancer's production listener.

Encrypt the S3 artifact bucket in the tooling account with a Customer Managed Key (CMK). Apply a Service Control Policy (SCP) to the Organizational Unit of the application account that allows the cross-account execution role to access the S3 bucket and decrypt using the CMK. In the application account, create a custom CodeDeploy deployment configuration with a traffic routing type of TimeBasedCanary, a CanaryPercentage of 10%, and a CanaryInterval of 10 minutes. Associate the CodeDeploy deployment group with a CloudWatch alarm monitoring HTTPCode_Target_5XX_Count on the Application Load Balancer's production listener.

Show answer & explanation

Answer: Encrypt the S3 artifact bucket in the tooling account with a Customer Managed Key (CMK). Grant the cross-account execution role in the application account decrypt and read permissions on the CMK and S3 bucket. In the application account, create a custom CodeDeploy deployment configuration with a traffic routing type of TimeBasedCanary, a CanaryPercentage of 10%, and a CanaryInterval of 10 minutes. Associate the CodeDeploy deployment group with a CloudWatch alarm monitoring HTTPCode_Target_5XX_Count on the Application Load Balancer's production listener.

Answer

The correct solution encrypts the central S3 bucket using a Customer Managed Key (CMK), grants the member account's cross-account execution role explicit read and decrypt permissions, creates a custom CodeDeploy deployment configuration of type TimeBasedCanary with a 10% percentage and 10-minute interval, and configures a CloudWatch alarm on the load balancer's production listener HTTPCode_Target_5XX_Count metric.

The correct solution resolves the cross-account encryption requirements by using a Customer Managed Key (CMK) with appropriate resource-level permissions (since AWS-managed keys cannot be shared). It handles the custom traffic shifting rules by creating a custom CodeDeploy configuration of type TimeBasedCanary (shifting 10% and pausing for 10 minutes). Finally, it monitors the Production Listener for HTTP 5xx errors using a CloudWatch alarm linked to the deployment group, achieving automated rollback.

Step-by-Step Solution

Configure artifact encryption and cross-account access rules.

Encrypt the central S3 bucket in the tooling account with a Customer Managed Key (CMK) instead of the default AWS-managed key, update the CMK key policy to allow key access to the member account's IAM role, and configure the S3 bucket policy to allow the member role read permissions.

Default AWS-managed keys cannot be shared across different accounts because their key policies cannot be modified.

Define custom traffic routing behavior in CodeDeploy.

Create a custom deployment configuration in the member account with traffic routing set to TimeBasedCanary, specifying a CanaryPercentage of 10% and a CanaryInterval of 10 minutes.

The standard pre-defined canary configurations in CodeDeploy do not include a 10-minute wait interval (only 5-minute and 15-minute intervals exist), requiring a custom configuration.

Set up automated rollback monitoring.

Configure a CloudWatch alarm based on HTTPCode_Target_5XX_Count on the Application Load Balancer's production listener and map it to the CodeDeploy deployment group's alarm triggers.

This guarantees that if errors spike on the shifted traffic stream, CodeDeploy will detect the alarm status and automatically roll back the deployment.

Key Concept

Cross-account IAM and KMS permissions coupled with custom deployment configuration design for automated Blue/Green rollbacks.

Question 1440Question →

A retail company is planning to migrate its self-managed MySQL database running on an on-premises server to an Amazon Aurora PostgreSQL-Compatible Edition DB cluster. The solutions architect needs to configure the source MySQL database to support ongoing replication (Change Data Capture) using AWS Database Migration Service (DMS). Which configurations must be applied to the source MySQL database to enable AWS DMS CDC? (Select two.)

Select all that apply

Enable binary logging on the source MySQL instance by setting the log_bin configuration parameter.

Set the binlog_format parameter to ROW to record row-level changes.

Enable supplemental logging at the database level and table level for all replicated tables.

Set the wal_level parameter to logical and create a logical replication slot.

Ensure the SQL Server Agent service is running and configure the database for the Full Recovery model.

Show answer & explanation

Answer: Enable binary logging on the source MySQL instance by setting the log_bin configuration parameter.; Set the binlog_format parameter to ROW to record row-level changes.

Answer

The correct configurations are to enable binary logging on the source MySQL instance by setting the log_bin parameter, and to set the binlog_format parameter to ROW.

To support Change Data Capture (CDC) from a MySQL source database, AWS Database Migration Service (DMS) reads the MySQL binary logs. Therefore, binary logging must be enabled on the source database using the log_bin parameter. Additionally, the binary log format (binlog_format) must be set to ROW to ensure that row-level modifications are written to the binary logs in a structured format that AWS DMS can interpret.

Step-by-Step Solution

Identify the source database engine and the replication requirements.

The source database is MySQL and requires Change Data Capture (CDC) for ongoing replication.

AWS DMS requires different log-based configuration settings depending on the source database engine type.

Determine the required binary logging settings for MySQL CDC in AWS DMS.

Binary logging must be enabled using the log_bin parameter, and the binlog_format must be set to ROW.

AWS DMS parses MySQL's binary logs in row-level format to replicate changes to the target database.

Filter out configurations belonging to other database engines.

Supplemental logging is for Oracle, wal_level is for PostgreSQL, and SQL Server Agent/Full Recovery is for Microsoft SQL Server.

Applying prerequisites for the wrong database engine will not enable CDC on the MySQL source.

Key Concept

Configuring source database log settings (such as binary logs for MySQL) is a mandatory prerequisite for AWS DMS to perform Change Data Capture (CDC) replication.

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

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

Key Concept

Common Mistakes

Answer

Step-by-Step Solution