All practice questions

1964 questions

All types1,964 Multiple choice1,006 Multiple select931 Ordering27

A company operates a critical telemetry analytics platform across multiple AWS accounts. The primary ingestion workload runs in a VPC in the us-west-2 Region, containing Amazon EKS clusters that write to an Amazon Aurora PostgreSQL DB cluster. The database contains proprietary configurations encrypted with an AWS KMS customer managed key. The disaster recovery (DR) target is the us-east-1 Region. The company needs to configure a DR solution that meets an RPO of less than 1 minute and an RTO of less than 15 minutes. Additionally, internal EKS microservices in both regions must resolve the internal database endpoint using a shared Route 53 Private Hosted Zone (PHZ) named corp.internal. Which TWO actions should the Solutions Architect take to meet these requirements? (Select TWO.)

Select all that apply

Configure Amazon Aurora Global Database with the primary cluster in us-west-2 and a secondary cluster in us-east-1, performing a managed failover to the secondary region during an outage.

Associate the Route 53 Private Hosted Zone corp.internal from the primary account with the VPCs in both us-west-2 and us-east-1 using cross-account VPC association authorization.

Configure AWS Backup to take hourly snapshots of the Aurora PostgreSQL database in us-west-2, copy them to us-east-1, and restore them during a disaster.

Create a separate Route 53 Private Hosted Zone named corp.internal in the us-east-1 account, and configure a custom synchronization lambda function to mirror DNS records.

Configure a Route 53 failover routing policy pointing to database endpoints in both regions, omitting health checks to allow default connection-drop failover routing.

Show answer & explanation

Answer: Configure Amazon Aurora Global Database with the primary cluster in us-west-2 and a secondary cluster in us-east-1, performing a managed failover to the secondary region during an outage.; Associate the Route 53 Private Hosted Zone corp.internal from the primary account with the VPCs in both us-west-2 and us-east-1 using cross-account VPC association authorization.

Answer

Configure Amazon Aurora Global Database with the primary cluster in us-west-2 and a secondary cluster in us-east-1, and associate the Route 53 Private Hosted Zone corp.internal from the primary account with the VPCs in both regions.

The correct configuration integrates Amazon Aurora Global Database to achieve low-latency replication (sub-second lag) and quick promotion capability during disaster recovery. This satisfies the RPO of less than 1 minute and RTO of less than 15 minutes. To allow microservices in both EKS clusters to resolve internal endpoints consistently, the Solutions Architect associates the primary Private Hosted Zone with the VPCs in both regions, leveraging AWS cross-account and cross-region PHZ sharing capabilities.

Step-by-Step Solution

Evaluate replication technologies that can support the target RPO and RTO constraints.

Aurora Global Database is selected because it provides replication latencies under 1 second (meeting the RPO of < 1 minute) and failover/promotion speeds under 15 minutes (meeting the RTO of < 15 minutes). AWS Backup and snapshot replication are eliminated as they fail these target metrics.

Aligning database replication strategy with business recovery objectives is critical for disaster recovery planning.

Establish cross-region and cross-account DNS resolution configuration for internal workloads.

The existing Route 53 Private Hosted Zone is associated with the VPCs in both regions using cross-account VPC association authorization.

This allows EKS workloads in both regions to resolve internal resource names directly and securely without maintaining redundant zones or custom sync tools.

Key Concept

Enhancing Disaster Recovery and Multi-Region DNS Resolution using Aurora Global Database and Route 53 Private Hosted Zone Association

Estimated Time:3m 0s

Question 1402Question →

An enterprise is migrating its core on-premises transaction processing systems to AWS using AWS Application Migration Service (MGN). The architecture utilizes a 10 Gbps AWS Direct Connect connection terminating at an AWS Transit Gateway in a centralized Network Services VPC. The replication traffic is directed to a dedicated Staging Area VPC. While the MGN replication agent was successfully installed on all on-premises servers using HTTPS port 443, the replication status on the AWS Migration Hub console remains in a 'Stalled' state, and no data blocks are being synchronized. The network team confirms that the Transit Gateway has active attachments to the Staging Area VPC and routing tables are properly configured. Which combination of network and security configurations will resolve this replication stall while maintaining high availability and AWS best practices?

Configure the on-premises firewall to allow outbound traffic over TCP port 1500 to the Staging Area VPC CIDR, configure the Staging Area VPC security groups to allow inbound traffic over TCP port 1500 from the on-premises subnet, and deploy redundant NAT Gateways across all active Availability Zones in the Staging Area VPC to route outbound control plane communication.

Modify the local firewall to allow outbound HTTPS traffic on TCP port 443 only, and configure the replication servers in the Staging Area VPC to accept inbound traffic on TCP port 443, as the replication agent tunnels all block-level data replication blocks through the control plane endpoint.

Establish a Transit Gateway Peering connection directly between the on-premises router and the Staging Area VPC, bypass the central Transit Gateway routing tables to prevent transitive routing delays, and allow inbound TCP port 1500 on the replication servers.

Configure the on-premises firewall and the Staging Area VPC security groups to allow traffic over TCP port 1500, and deploy a single NAT Gateway in one Availability Zone of the Staging Area VPC, pointing all subnet route tables to this gateway to handle outbound status updates to the MGN control plane.

Show answer & explanation

Answer: Configure the on-premises firewall to allow outbound traffic over TCP port 1500 to the Staging Area VPC CIDR, configure the Staging Area VPC security groups to allow inbound traffic over TCP port 1500 from the on-premises subnet, and deploy redundant NAT Gateways across all active Availability Zones in the Staging Area VPC to route outbound control plane communication.

Answer

The correct option addresses the direct cause of the data replication stall by opening TCP port 1500 outbound on the on-premises firewall and inbound on the replication server security groups in the Staging Area VPC. Simultaneously, it maintains high availability by deploying redundant NAT Gateways across all active Availability Zones for the replication servers to communicate with the MGN control plane.

Step-by-Step Solution

Identify the ports required for replication by the AWS Application Migration Service (MGN) agent.

TCP Port 443 is used for control plane communication and agent installation, while TCP Port 1500 is used for replicating the actual data blocks to the replication servers in the staging area.

Resolving the stall requires establishing the replication channel on TCP Port 1500.

Ensure firewall and security group settings permit TCP Port 1500.

The local on-premises firewall must allow outbound TCP 1500, and the Staging Area VPC security groups must allow inbound TCP 1500 from the on-premises subnet.

This allows the replication agent to push data blocks to the replication EC2 instances.

Design the outbound communication path for the replication servers in the Staging Area VPC.

Deploy redundant NAT Gateways across all active Availability Zones in the Staging Area VPC to provide highly available outbound routes to the MGN control plane.

Ensures that a single Availability Zone outage does not interrupt control plane status updates for all replication servers.

Key Concept

AWS MGN network architecture requires TCP port 1500 for replication data transport, separate from the HTTPS TCP port 443 control plane path, along with redundant NAT Gateways for multi-AZ staging environment resilience.

Question 1403Question →

An enterprise SaaS provider hosts a subscription management billing application on AWS. The application uses an Amazon Aurora PostgreSQL database cluster to manage subscriber billing profiles, transaction history, and subscription statuses. During monthly recurring billing runs and peak customer login windows, the Aurora DB cluster experiences significant CPU utilization spikes (over 90%) and database connection limits are frequently reached, leading to transaction timeouts. Analysis reveals two main issues: first, the application performs frequent read queries to retrieve static plan definitions and subscriber metadata that rarely change; second, high-volume write transactions update subscriber payment status, but subsequent immediately-triggered customer notifications trigger read queries seeking the newly updated subscription status, which requires absolute data consistency and must be highly available with automatic failover. Which TWO actions should the Solutions Architect recommend to improve database and caching efficiency? (Select TWO.)

Select all that apply

Deploy an Amazon ElastiCache for Redis cluster with Multi-AZ and automatic failover, and configure the application to cache static plan definitions and use a write-through caching strategy for subscription statuses.

Deploy an Amazon RDS Proxy instance between the billing application and the Aurora DB cluster, and configure the application to route database connections through the proxy.

Deploy an Amazon ElastiCache for Memcached cluster to cache the subscriber billing metadata, and configure multi-AZ replication to ensure session persistence and automatic failover.

Configure Amazon Aurora Auto Scaling to dynamically provision additional read replicas, and configure the application to send subscription write updates directly to the reader endpoint to distribute write capacity.

Deploy an Amazon ElastiCache for Memcached cluster using a write-behind strategy to queue billing transaction updates and synchronize them with the Aurora database asynchronously.

Show answer & explanation

Answer: Deploy an Amazon ElastiCache for Redis cluster with Multi-AZ and automatic failover, and configure the application to cache static plan definitions and use a write-through caching strategy for subscription statuses.; Deploy an Amazon RDS Proxy instance between the billing application and the Aurora DB cluster, and configure the application to route database connections through the proxy.

Answer

Deploying an Amazon ElastiCache for Redis cluster with Multi-AZ and automatic failover, using a write-through caching strategy for subscription statuses, and deploying an Amazon RDS Proxy instance to manage application database connections.

Deploying an Amazon ElastiCache for Redis cluster with Multi-AZ replication ensures high availability and automatic failover. Utilizing a write-through strategy for subscription status updates ensures that any reads immediately following a write will retrieve the latest consistent state from the cache. Deploying Amazon RDS Proxy resolves the connection scaling issues by pooling connections and reducing the CPU overhead on the Aurora DB cluster caused by high-concurrency connection spikes.

Step-by-Step Solution

Analyze database CPU and connection bottlenecks.

Identify that CPU spikes are caused by connection limits being reached and redundant reads of static metadata.

Understanding the source of performance issues determines whether connection pooling or caching is required.

Select the appropriate caching engine for data requiring replication and failover.

Choose ElastiCache for Redis rather than Memcached.

Memcached does not support replication, Multi-AZ, or failover, making it unsuitable for highly available state caching.

Design cache strategy for data consistency.

Select a write-through caching strategy for updated subscription statuses.

Write-through ensures that the database and cache are updated simultaneously, satisfying the requirement for immediate read consistency after a status write.

Implement database connection pooling.

Introduce Amazon RDS Proxy in front of the database cluster.

RDS Proxy pools connections, shielding the Aurora DB cluster from CPU spikes caused by frequent connection setups during login surges.

Key Concept

Improving relational database and caching efficiency under high connection load and strict consistency/availability requirements using RDS Proxy and ElastiCache for Redis.

Question 1404Question →

A SaaS-based marketing automation platform stores tenant campaign configurations in a single-instance Amazon RDS for PostgreSQL database. During peak campaign execution windows, read query volume increases significantly, causing the database CPU utilization to exceed 90% and campaign delivery latencies to rise. The Solutions Architect must implement a caching solution to reduce the database load. The cached configuration data must survive cache node failures without causing a cache miss storm on the database, and the cache layer must support automatic failover. Which of the following caching strategies should the Solutions Architect implement to meet these requirements?

Deploy an Amazon ElastiCache for Redis cluster in a Multi-AZ replication group with automatic failover enabled, and configure the application to read from the cache before querying the database.

Deploy an Amazon ElastiCache for Memcached cluster across multiple Availability Zones, and configure the application to cache campaign configurations to distribute the read load.

Modify the RDS for PostgreSQL database to a Multi-AZ deployment, and configure the application to route marketing campaign read queries to the standby database instance.

Create an Amazon Aurora PostgreSQL Global Database secondary cluster in another AWS Region, and configure the application to route read queries to the secondary region to distribute the query load.

Show answer & explanation

Answer: Deploy an Amazon ElastiCache for Redis cluster in a Multi-AZ replication group with automatic failover enabled, and configure the application to read from the cache before querying the database.

Answer

Deploy an Amazon ElastiCache for Redis cluster in a Multi-AZ replication group with automatic failover enabled, and configure the application to read from the cache before querying the database.

The correct solution uses Amazon ElastiCache for Redis with Multi-AZ replication. This pattern offloads read queries from the backend database, handles failover automatically to prevent cache stampedes, and ensures cache availability.

Step-by-Step Solution

Analyze performance metrics to identify database CPU bottleneck.

Determine that the database is read-heavy on campaign configuration data.

Validates the need for caching rather than write-scaling options.

Evaluate caching requirements for high availability and automatic failover.

Establish that the cache must survive node outages without cache stampedes.

Filters out caching engines that lack replication and failover support.

Select the appropriate Amazon ElastiCache engine.

ElastiCache for Redis is selected over Memcached.

Redis supports Multi-AZ replication and automatic failover, whereas Memcached is a simple, non-replicated partitioning engine.

Key Concept

Improving database efficiency by using an ElastiCache Redis cluster with Multi-AZ replication for resilient caching.

Question 1405Question →

A retail company is designing a new cloud infrastructure on AWS. The design requires two VPCs in the us-west-2 region: vpc-app-prod, which hosts application servers across two Availability Zones (us-west-2a and us-west-2b), and vpc-egress-shared, which is dedicated to centralized outbound internet traffic. An AWS Transit Gateway (tgw-main) is deployed to interconnect the VPCs. Additionally, a Route 53 Private Hosted Zone (PHZ) named prod.corp.internal is hosted in the AWS account managing vpc-egress-shared. The company requires a highly available network design that prevents single points of failure for outbound traffic, supports private DNS resolution of prod.corp.internal from the application servers, and minimizes operational complexity. Which of the following designs best meets these requirements?

Deploy a NAT Gateway in both us-west-2a and us-west-2b within vpc-egress-shared. Configure the private subnet route tables of vpc-app-prod to route 0.0.0.0/0 to tgw-main. Configure Transit Gateway route tables to route internet-bound traffic to vpc-egress-shared and return traffic back to vpc-app-prod. Associate the prod.corp.internal Private Hosted Zone directly with vpc-app-prod using the Route 53 console or AWS CLI.

Deploy a single NAT Gateway in us-west-2a within vpc-egress-shared to minimize cost. Configure the private subnet route tables of vpc-app-prod to route 0.0.0.0/0 to tgw-main, directing all egress traffic to the single NAT Gateway. Associate the prod.corp.internal Private Hosted Zone directly with vpc-app-prod using the Route 53 console or AWS CLI.

Deploy a NAT Gateway in both us-west-2a and us-west-2b within vpc-egress-shared. Configure the private subnet route tables of vpc-app-prod to route 0.0.0.0/0 to tgw-main. Configure Transit Gateway route tables to route internet-bound traffic to vpc-egress-shared. Rely on Transit Gateway’s built-in DNS support to automatically propagate and resolve records from prod.corp.internal across all attached VPCs.

Deploy a NAT Gateway in both us-west-2a and us-west-2b within vpc-egress-shared. Establish a VPC Peering connection between vpc-app-prod and vpc-egress-shared. Configure the private subnet route tables of vpc-app-prod to route 0.0.0.0/0 through the VPC Peering connection to the NAT Gateways in vpc-egress-shared. Associate the prod.corp.internal Private Hosted Zone directly with vpc-app-prod using the Route 53 console or AWS CLI.

Show answer & explanation

Answer: Deploy a NAT Gateway in both us-west-2a and us-west-2b within vpc-egress-shared. Configure the private subnet route tables of vpc-app-prod to route 0.0.0.0/0 to tgw-main. Configure Transit Gateway route tables to route internet-bound traffic to vpc-egress-shared and return traffic back to vpc-app-prod. Associate the prod.corp.internal Private Hosted Zone directly with vpc-app-prod using the Route 53 console or AWS CLI.

Answer

Deploy a NAT Gateway in both us-west-2a and us-west-2b within vpc-egress-shared, configure vpc-app-prod to route 0.0.0.0/0 to tgw-main, and associate the prod.corp.internal Private Hosted Zone directly with vpc-app-prod.

The correct design ensures high availability for egress traffic by deploying redundant NAT Gateways across two Availability Zones in the shared egress VPC. Traffic from the application VPC is routed to the Transit Gateway, which forwards it to the egress VPC. Additionally, the Route 53 Private Hosted Zone is associated directly with the application VPC to allow native DNS resolution.

Step-by-Step Solution

Design highly available egress architecture.

NAT Gateways are deployed in both us-west-2a and us-west-2b in vpc-egress-shared to eliminate any single point of failure.

Ensures that an Availability Zone outage in us-west-2a does not disrupt egress traffic originating from us-west-2b.

Configure routing for centralized egress.

The default route (0.0.0.0/0) in vpc-app-prod route tables points to the Transit Gateway, which routes the traffic to vpc-egress-shared, and then out through the local NAT Gateways.

Allows vpc-app-prod to route outbound internet traffic through the centralized egress VPC without relying on unsupported peering configurations.

Configure DNS resolution for the Private Hosted Zone.

The Route 53 Private Hosted Zone (PHZ) prod.corp.internal is associated directly with vpc-app-prod.

Enables instances in the application VPC to query the Amazon-provided DNS server (Route 53 Resolver) and resolve private resource records in the hosted zone without requiring custom DNS infrastructure.

Key Concept

Multi-VPC architecture using Transit Gateway for centralized egress with redundant NAT Gateways and explicit Route 53 Private Hosted Zone associations.

Question 1406Question →

A company is migrating an on-premises self-managed MySQL $8.0$ database to an Amazon Aurora PostgreSQL-Compatible Edition DB cluster. The source database contains critical application data and tables with binary files stored in `LONGBLOB` columns, with the largest record sized at $8\text{ MB}$ . A solutions architect uses the AWS Schema Conversion Tool (AWS SCT) to convert the database schema and custom functions, which are then successfully applied to the target Aurora DB cluster. The architect then configures an AWS Database Migration Service (AWS DMS) task with Full Load and Ongoing Replication (Change Data Capture) enabled to migrate the data. Shortly after the task starts, the full load completes successfully, but the task immediately fails when entering the ongoing replication phase. The task logs indicate that AWS DMS is unable to read the transaction logs from the source database. Which of the following configurations should the solutions architect apply to resolve this failure and optimize the transfer of the `LONGBLOB` data with minimal downtime?

Configure the source MySQL database parameters by setting `binlog_format` to `STATEMENT` and `binlog_row_image` to `MINIMAL`, and restart the MySQL service. For the AWS DMS task, set the LOB support configuration to Full LOB mode to dynamically handle the large payloads.

Configure the source MySQL database parameters by setting `binlog_format` to `ROW` and `binlog_row_image` to `FULL`, and restart the MySQL service. For the AWS DMS task, set the LOB support configuration to Limited LOB mode and specify a Max LOB size of

8192\text{ KB}

32\text{ KB}

Configure the source MySQL database parameters by setting `binlog_format` to `ROW` and `binlog_row_image` to `FULL`. Migrate the database using AWS Application Migration Service (MGN) to block-replicate the MySQL server to Amazon EC2, then perform an in-place conversion to Aurora PostgreSQL using AWS SCT.

Show answer & explanation

Answer: Configure the source MySQL database parameters by setting `binlog_format` to `ROW` and `binlog_row_image` to `FULL`, and restart the MySQL service. For the AWS DMS task, set the LOB support configuration to Limited LOB mode and specify a Max LOB size of $8192\text{ KB}$ .

Answer

Configure the source MySQL parameters to ROW format and FULL row image, restart the service, and set the AWS DMS task to Limited LOB mode with a Max LOB size of 8192 KB.

To perform ongoing replication (CDC) from a MySQL source, AWS DMS requires binary logging to be enabled with `binlog_format` set to `ROW` and `binlog_row_image` set to `FULL`. Since the source database contains LOB columns up to

8\text{ MB}

, using Limited LOB mode with a Max LOB size of

8192\text{ KB}

(

8\text{ MB}

) is the most performant choice because it allocates memory up to the specified size and prevents truncation of LOBs. Full LOB mode would incur significant performance overhead by fetching LOBs in separate queries.

Step-by-Step Solution

Configure binary logging on the source MySQL database.

Setting `binlog_format = ROW` and `binlog_row_image = FULL` in the MySQL configuration file ensures that the transaction changes are logged at the row level with all column values.

AWS DMS CDC requires row-level binary logs to capture and replicate ongoing transactions from MySQL source databases.

Restart the MySQL database service to apply the configuration changes.

The MySQL instance begins generating binary logs in the correct format.

These parameter changes are static in MySQL and require a service restart to take effect.

Configure LOB settings in the AWS DMS task.

Setting Limited LOB mode with a Max LOB size of `

8192\text{ KB}

` (

8\text{ MB}

) allows DMS to allocate adequate memory buffers for the `LONGBLOB` data without truncating the records.

Limited LOB mode is faster than Full LOB mode, but it truncates any LOB data exceeding the configured threshold. Setting the threshold to the maximum known LOB size avoids truncation while maximizing migration speed.

Key Concept

Replication prerequisites and LOB optimization settings for AWS DMS CDC tasks during database migration.

Question 1407Question →

A logistics enterprise is planning the migration of its application portfolio to AWS. During the assessment phase, the solutions architect identifies the following systems:

1. A proprietary Java-based order processing system. The business wants to modernize this application by breaking the monolith into independent, serverless microservices to support rapid scaling.
2. A commercial off-the-shelf billing application that runs on Microsoft SQL Server. The application vendor supports Amazon RDS, and the operations team wants to eliminate database administration tasks such as operating system patching and hardware provisioning. No changes to the database schema or application code are allowed.
3. A legacy inventory tracking system that is fully redundant and has already been replaced by a modern Software-as-a-Service (SaaS) solution.

Which migration strategies should the solutions architect select for these systems under the 7 Rs framework? (Select TWO.)

Select all that apply

Refactor the Java-based order processing system by rewriting it as serverless microservices.

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

Rehost the billing application by migrating the database to Amazon RDS for SQL Server.

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

Retain the legacy inventory tracking system by migrating it to a low-cost Amazon EC2 instance.

Show answer & explanation

Answer: Refactor the Java-based order processing system by rewriting it as serverless microservices.; Replatform the billing application by migrating the database to Amazon RDS for SQL Server.

Answer

Refactor the Java-based order processing system by rewriting it as serverless microservices, and Replatform the billing application by migrating the database to Amazon RDS for SQL Server.

Modernizing a monolithic Java application by rewriting it into independent, serverless microservices modifies the architecture and represents a Refactor (Rearchitect) strategy. Moving a database to a managed service like Amazon RDS without modifying the application code or database schema is a Replatform strategy, as it optimizes the database platform while keeping the core architecture unchanged.

Step-by-Step Solution

Analyze the Java-based order processing system migration requirement.

The requirement is to break a monolith into serverless microservices, which involves significant application architecture and code changes.

This corresponds to the Refactor (Rearchitect) strategy under the 7 Rs framework.

Analyze the billing application migration requirement.

The database needs to migrate to a managed database service (Amazon RDS) to reduce administrative overhead without altering the database schema or application code.

This corresponds to the Replatform strategy under the 7 Rs framework, as we are optimizing the hosting platform without changing the core application code.

Analyze the legacy inventory tracking system requirement.

The system is fully redundant and has already been replaced by a modern SaaS solution, meaning it has no further operational utility.

This corresponds to the Retire strategy (decommissioning), and should not be migrated or retained.

Key Concept

Selecting migration strategies under the 7 Rs framework based on architecture, operational overhead, and business constraints.

Question 1408Question →

An enterprise is planning to migrate a business-critical inventory management and dispatch system to AWS. The system consists of three distinct application components:

1. Order Processing Core: A monolithic Java application running on Red Hat Enterprise Linux (RHEL). It relies on a proprietary local message queuing middleware. The business wants to break down this monolith into microservices, containerize it using AWS Fargate, and replace the proprietary middleware with Amazon Simple Queue Service (SQS) to improve scalability and eliminate licensing costs. The company has assigned a dedicated team with a 6-month timeline for this work.
2. Inventory Database: An Oracle Database 19c Enterprise Edition instance running on-premises, using advanced PL/SQL stored procedures. To avoid high migration risk and schema conversion complexity, the database engine must remain unchanged, but the business wants to eliminate hardware provisioning, backups, and OS patching overhead.
3. Legacy Shipping Label Generator: A legacy 32-bit application running on an old Windows Server 2008 R2 server. The source code is lost, and the software vendor is out of business, but the utility must be kept running as-is. It has no external dependencies. The enterprise plans to use AWS Application Migration Service (MGN) to copy the server block-by-block to an Amazon EC2 instance with minimal downtime and no software changes.

Which of the following migration strategies represent the correct alignment with the AWS 7 Rs framework for these components? (Select TWO)

Select all that apply

Classify the Order Processing Core migration as Refactor (Re-architect), because the application architecture is being modified to adopt microservices, containers, and cloud-native messaging services like Amazon SQS.

Classify the Inventory Database migration as Replatform (Re-platform), because it is moving to a managed service (Amazon RDS for Oracle) to optimize operational tasks without altering the underlying database engine or schema.

Classify the Inventory Database migration as Refactor (Re-architect), because migrating to Amazon RDS for Oracle constitutes a Refactoring strategy due to the architectural changes in database high availability and automated backups.

Classify the Legacy Shipping Label Generator migration as Replatform (Re-platform), because utilizing AWS Application Migration Service (MGN) to migrate the virtual machine to Amazon EC2 is defined as a replatforming activity.

Classify the Order Processing Core migration as Replatform (Re-platform), because containerizing the application onto AWS Fargate and shifting to Amazon SQS represents a platform optimization that does not alter the core business logic.

Show answer & explanation

Answer: Classify the Order Processing Core migration as Refactor (Re-architect), because the application architecture is being modified to adopt microservices, containers, and cloud-native messaging services like Amazon SQS.; Classify the Inventory Database migration as Replatform (Re-platform), because it is moving to a managed service (Amazon RDS for Oracle) to optimize operational tasks without altering the underlying database engine or schema.

Answer

The Order Processing Core should be migrated using the Refactor (Re-architect) strategy because it involves architectural changes to adopt microservices, containers, and Amazon SQS, and the Inventory Database should be migrated using the Replatform (Re-platform) strategy because it moves the workload to Amazon RDS for Oracle without changing the database engine or schema.

The migration of the Order Processing Core involves changing the application architecture from a monolith to microservices and replacing proprietary middleware with Amazon SQS, which is classified as a Refactor (Re-architect) strategy. The migration of the Inventory Database to Amazon RDS for Oracle moves the workload to a managed database service without changing the engine or code, which is classified as a Replatform strategy.

Step-by-Step Solution

Analyze the migration strategy for the Order Processing Core.

The core is being decomposed into microservices, containerized on ECS Fargate, and its middleware is being replaced with Amazon SQS.

This level of architectural and code change represents a Refactor (Re-architect) migration strategy because it shifts the system design toward cloud-native capabilities.

Analyze the migration strategy for the Inventory Database.

The database is moving to Amazon RDS for Oracle to offload administration without modifying the DB engine or schema.

Moving a database to a managed service with the same engine is a Replatform (Re-platform) strategy because the platform is optimized while keeping the application code/database interface intact.

Analyze the migration strategy for the Legacy Shipping Label Generator.

The server is being copied block-by-block to AWS EC2 using AWS MGN with no configuration or application changes.

This lift-and-shift pattern is a Rehost migration strategy because the server is migrated without any optimizations or architectural alterations.

Identify the correct options based on the analysis.

The options identifying the Order Processing Core as Refactor and the Inventory Database as Replatform are correct.

These options accurately match the 7 Rs definitions based on the requirements and constraints given.

Key Concept

Distinguishing between Rehost, Replatform, and Refactor (Re-architect) migration strategies within the AWS 7 Rs framework based on architecture modifications, managed service adoption, and code rewrite requirements.

Estimated Time:3m 0s

Question 1409Question →

A sports broadcasting network hosts a live streaming platform where real-time game metadata is stored in an Amazon RDS for PostgreSQL DB instance. During major sporting events, concurrent user requests spike tenfold, causing CPU utilization on the database to reach $98\%$ and metadata query response times to degrade from $50$ milliseconds to over $5$ seconds. The application team notes that the query workload is highly repetitive and read-heavy. The solutions architect must implement a caching solution that achieves sub-millisecond query latency, supports automatic replication and node failover across multiple Availability Zones, and provides the ability to persist cache snapshots to Amazon S3. Which architecture should the solutions architect implement to resolve the performance bottleneck?

Deploy an Amazon ElastiCache for Redis replication group in a Multi-AZ configuration with automatic failover enabled.

Deploy an Amazon ElastiCache for Memcached cluster with nodes distributed across multiple Availability Zones.

Deploy an Amazon RDS Multi-AZ standby instance in a secondary Availability Zone and configure the application to load-balance read queries to the standby instance.

Deploy a single-node Amazon ElastiCache for Redis instance with automated backups, and configure an AWS Lambda function to restore the cache from snapshots in a secondary Availability Zone upon node failure.

Show answer & explanation

Answer: Deploy an Amazon ElastiCache for Redis replication group in a Multi-AZ configuration with automatic failover enabled.

Answer

Deploy an Amazon ElastiCache for Redis replication group in a Multi-AZ configuration with automatic failover enabled.

The correct solution uses Amazon ElastiCache for Redis in a Multi-AZ replication group. This deployment model provides the sub-millisecond query performance required by the platform, replicates data across multiple Availability Zones, supports automatic failover if the primary node fails, and enables snapshot persistence directly to Amazon S3.

Step-by-Step Solution

Analyze the workload requirements and identify that the database is experiencing read-heavy performance degradation due to repetitive metadata queries.

Confirming that an in-memory caching layer is the correct pattern to offload reads from the database and achieve sub-millisecond latency.

Caching addresses the high CPU utilization caused by repetitive read queries.

Evaluate ElastiCache engines (Redis vs. Memcached) against the requirements of replication, automatic failover, and snapshot persistence.

ElastiCache for Redis is selected because ElastiCache for Memcached does not support replication, Multi-AZ failover, or persistence features.

Redis provides the required high availability, failover capabilities, and S3 snapshot integration.

Design the Redis deployment topology using a Multi-AZ configuration with automatic failover.

A multi-node replication group distributed across Availability Zones is selected.

This configuration satisfies the requirement for automatic node failover and high availability with minimal operational overhead.

Key Concept

Selecting the appropriate caching engine and configuration to support high availability, replication, and persistence under high read loads.

Estimated Time:2m 30s

Question 1410Question →

A company is migrating a high-throughput, on-premises Oracle database to an Amazon Aurora PostgreSQL-Compatible Edition DB cluster. The migration strategy requires minimal downtime, and a solutions architect has configured AWS DMS with a Change Data Capture (CDC) replication task. During testing, the source Oracle database experiences extremely high CPU utilization, and the DMS task cannot keep up with the volume of changes. Which of the following solutions should the solutions architect implement to reduce CPU utilization on the source database and improve CDC performance?

Configure AWS DMS to use the Binary Reader method instead of the default Oracle LogMiner to read the redo and archived log files directly.

Enable supplemental logging on all source Oracle tables and configure the AWS DMS task to use Oracle LogMiner with the useLogminerReader task setting set to true.

Modify the AWS DMS replication task settings to disable transaction-based replication and switch to statement-level logging on the source Oracle database.

Perform a replatforming migration using AWS SCT to continuously extract transaction logs directly to Amazon S3, and load them into Aurora PostgreSQL using pg_restore.

Show answer & explanation

Answer: Configure AWS DMS to use the Binary Reader method instead of the default Oracle LogMiner to read the redo and archived log files directly.

Answer

Configure AWS DMS to use the Binary Reader method instead of the default Oracle LogMiner to read the redo and archived log files directly.

The correct solution is to configure the AWS DMS task to use the Binary Reader method. When migrating from a high-throughput Oracle database, the default LogMiner method consumes significant CPU resources because it operates within the database engine to reconstruct changes. The Binary Reader method reads the redo and archived logs directly from the database file system or Automatic Storage Management (ASM), which minimizes the resource footprint on the source Oracle database and enhances replication performance.

Step-by-Step Solution

Analyze the impact of the default Oracle LogMiner mechanism on the source database.

Confirm that Oracle LogMiner reconstructs database changes using SQL queries, which causes high CPU usage under heavy transactional workloads.

To determine the root cause of the performance bottleneck on the source Oracle database.

Select a highly performant alternative CDC reading method suitable for high-volume Oracle databases.

Identify that AWS DMS Binary Reader reads the redo and archived logs directly from the OS file system or ASM disks, avoiding the SQL engine query overhead.

To choose a replication architecture that offloads processing from the source database instance.

Implement configuration changes on the source Oracle database and AWS DMS endpoint settings.

Grant AWS DMS the necessary permissions to read the Oracle directories containing the redo and archived logs, and enable the Binary Reader settings in the DMS source endpoint configuration.

To apply the Binary Reader method configuration to successfully complete CDC with minimal CPU utilization on the source database.

Key Concept

AWS DMS replication methods (LogMiner vs. Binary Reader) for Oracle CDC

Question 1411Question →

A healthcare enterprise is planning to migrate its patient portal and billing system to AWS. The migration must be completed within 3 months, and the team has minimal developer resources to modify application code. An assessment of the current architecture reveals three primary components:

1. A web frontend running on Windows Server 2012 R2. The enterprise wants to eliminate OS-level licensing and patching overhead, but the .NET application code cannot be rewritten.
2. A backend database running on Oracle Database 19c Enterprise Edition. The database relies heavily on complex PL/SQL stored procedures that are tightly coupled with the frontend. A database downtime window of less than 2 hours is required, and administrative overhead must be minimized.
3. A legacy reporting engine running on IBM AIX that requires a physical USB licensing dongle connected to the server.

Which combination of migration strategies represents the most appropriate alignment with the 7 Rs framework?

Replatform the web frontend to AWS Lambda; Replatform the database to Amazon Aurora PostgreSQL; Retain the legacy reporting engine on-premises.

Replatform the web frontend to containers on AWS Fargate; Replatform the database to Amazon RDS for Oracle; Retain the legacy reporting engine on-premises.

Rehost the web frontend to Amazon EC2; Replatform the database to Amazon RDS for Oracle; Rehost the legacy reporting engine to Amazon EC2.

Refactor the web frontend to run on AWS Fargate; Rehost the database to Oracle on Amazon EC2; Relocate the legacy reporting engine to VMware Cloud on AWS.

Show answer & explanation

Answer: Replatform the web frontend to containers on AWS Fargate; Replatform the database to Amazon RDS for Oracle; Retain the legacy reporting engine on-premises.

Answer

Replatform the web frontend to containers on AWS Fargate; Replatform the database to Amazon RDS for Oracle; Retain the legacy reporting engine on-premises.

The correct strategy involves containerizing the web frontend using a tool like AWS App2Container and deploying it to AWS Fargate, which represents a Replatform strategy. This eliminates OS licensing and patching overhead without code modification. Migrating the Oracle database to Amazon RDS for Oracle is also a Replatform strategy that reduces administrative overhead while maintaining compatibility with the existing PL/SQL stored procedures. The legacy reporting engine cannot be migrated to AWS due to its dependency on IBM AIX and a physical USB licensing dongle, making Retain the only viable option.

Step-by-Step Solution

Analyze the constraints for the web frontend tier.

The frontend requires eliminating OS-level licensing and patching overhead without code modification. Rehosting on EC2 does not remove OS management. Refactoring to Lambda requires rewriting code, which violates the constraint of minimal developer resources. Replatforming the frontend to containers on AWS Fargate meets all constraints.

To identify a strategy that optimizes the platform runtime without modifying core application logic.

Analyze the constraints for the database tier.

The database relies on proprietary Oracle PL/SQL stored procedures and requires a downtime window of less than 2 hours. Changing the database engine to Aurora PostgreSQL requires refactoring (schema conversion and PL/SQL rewriting), violating the resource constraint. Rehosting to EC2 does not minimize administrative overhead. Replatforming to Amazon RDS for Oracle preserves the PL/SQL database engine while reducing operational overhead, and AWS DMS can execute the replication to meet the low-downtime constraint.

To find a database migration strategy that minimizes administration while avoiding schema conversion.

Analyze the constraints for the legacy reporting engine.

The reporting engine runs on IBM AIX and requires a physical USB licensing dongle. AWS EC2 instances and VMware Cloud on AWS run on x86 architectures and do not support attaching physical USB keys. Consequently, this component cannot be migrated to AWS.

To evaluate migration feasibility for workloads with hard operating system or hardware licensing dependencies.

Synthesize the individual tier strategies into a unified migration plan.

Frontend: Replatform (Fargate). Database: Replatform (RDS for Oracle). Legacy reporting engine: Retain on-premises.

To map the individual component decisions to the correct multi-tier migration pattern.

Key Concept

Selecting migration strategies (7 Rs) involves aligning technical and operational constraints, such as developer resource availability, OS support, and hardware dependencies, to determine the optimal path (Rehost, Replatform, Refactor, Retain, etc.) for each application tier.

Estimated Time:3m 0s

Question 1412Question →

A financial services company runs a transaction processing workload in a dedicated member account of an AWS Organization. The architecture consists of the following components:

- An Amazon ECS cluster running tasks on AWS Fargate across two Availability Zones (AZs) for stateless APIs.
- A fleet of Amazon EC2 instances ( $c6i.2xlarge$ instances: $8\text{ vCPU}$ , $16\text{ GiB}$ memory) in an Auto Scaling group across two AZs for message processing.
- Outbound traffic to external payment gateways routed through redundant NAT Gateways (one per AZ).

Performance monitoring over the past $30\text{ days}$ reveals the following utilization metrics:

Resource Type	Current Specification	Average CPU Utilization	Peak Memory Utilization
ECS Fargate Tasks	Dynamic	$10\%$	$15\%$
EC2 Instances	$c6i.2xlarge$ ( $8\text{ vCPU}$ , $16\text{ GiB}$ memory)	$40\%$	$13.5\text{ GiB}$

The company wants to optimize resource costs while maintaining high availability, ensuring zero application downtime during configuration changes, and securing a $3\text{-year}$ discount commitment. Which of the following strategies should a Solutions Architect recommend to optimize resource costs while meeting all performance, high availability, and operational requirements?

Downsize the Fargate task CPU and memory configurations. Migrate the EC2 instances to

m6i.xlarge

(

4\text{ vCPU}

16\text{ GiB}

memory) using a rolling update in the Auto Scaling group. Purchase a 3-year Compute Savings Plan in the management account of the AWS Organization.

Downsize the Fargate task CPU and memory configurations. Migrate the EC2 instances to

c6i.xlarge

(

4\text{ vCPU}

8\text{ GiB}

memory) using a rolling update in the Auto Scaling group. Purchase a 3-year EC2 Instance Savings Plan for the

c6i

family in the member account.

Downsize the Fargate task CPU and memory configurations. Migrate the EC2 instances to

m6i.xlarge

(

4\text{ vCPU}

16\text{ GiB}

memory). Replace the redundant NAT Gateways with a single NAT Gateway in one Availability Zone to eliminate hourly NAT charges. Purchase a 3-year EC2 Instance Savings Plan for the

m6i

family in the management account.

Downsize the Fargate task CPU and memory configurations. Migrate the EC2 instances to

c6i.xlarge

(

4\text{ vCPU}

8\text{ GiB}

memory). Create a centralized NAT Gateway in a shared services VPC and share it with the member account using AWS Resource Access Manager (RAM). Purchase a 3-year Compute Savings Plan in the management account.

Show answer & explanation

Answer: Downsize the Fargate task CPU and memory configurations. Migrate the EC2 instances to $m6i.xlarge$ ( $4\text{ vCPU}$ , $16\text{ GiB}$ memory) using a rolling update in the Auto Scaling group. Purchase a 3-year Compute Savings Plan in the management account of the AWS Organization.

Answer

Downsize the Fargate task configurations, migrate the EC2 instances to

m6i.xlarge

(

4\text{ vCPU}

16\text{ GiB}

memory) using a rolling update, and purchase a 3-year Compute Savings Plan in the management account of the AWS Organization.

The correct strategy involves downsizing the Fargate tasks to match their low average utilization (

10\%

CPU,

15\%

memory). For the EC2 fleet, because the peak memory utilization is

13.5\text{ GiB}

, downsizing to

c6i.xlarge

(

8\text{ GiB}

memory) is not feasible as it would lead to out-of-memory errors. The best approach is to switch to a general-purpose

m6i.xlarge

instance (

4\text{ vCPU}

16\text{ GiB}

memory), which accommodates both the CPU and memory requirements while lowering cost. To apply discounts to both Fargate and EC2, a Compute Savings Plan must be purchased in the management account. A rolling update (instance refresh) guarantees zero downtime.

Step-by-Step Solution

Analyze Fargate utilization metrics and downsize configurations.

The Fargate tasks run at

10\%

CPU and

15\%

memory, meaning they are over-provisioned. Downsizing their configurations directly reduces compute costs.

Aligns resource limits with actual workload demands to eliminate waste.

Determine the optimal sizing for the EC2 instances based on peak memory requirements.

The

c6i.2xlarge

instances run at

40\%

average CPU (

3.2\text{ vCPU}

) and

13.5\text{ GiB}

peak memory. Changing to

c6i.xlarge

(

8\text{ GiB}

memory) would cause out-of-memory failures. Transitioning to

m6i.xlarge

(

4\text{ vCPU}

16\text{ GiB}

memory) provides sufficient CPU and memory capacity at a lower cost.

Ensures that performance is not degraded during peaks while optimizing instance costs.

Select the correct Savings Plan type to cover the hybrid Fargate and EC2 environment.

A Compute Savings Plan covers both EC2 instances (regardless of family or region) and AWS Fargate tasks across all member accounts when purchased in the management account. An EC2 Instance Savings Plan would not cover the Fargate tasks and lacks flexibility across families.

Maximizes the discount coverage for the entire organization's compute footprint.

Key Concept

Compute Resource Right-Sizing and Savings Plans Optimization

Question 1413Question →

A company is reviewing the security configuration of an application running on Amazon EC2 instances in a production VPC in Account A. The application reads daily transaction files from an Amazon S3 bucket in a shared services VPC in Account B. Both accounts belong to the same AWS Organization. Currently, the S3 bucket is encrypted using the default AWS-managed KMS key (`aws/s3`). The application accesses the S3 bucket over the public internet using an IAM role in Account A. The security team requires that all network traffic between the application and the S3 bucket must remain within the AWS private network, S3 bucket access must be restricted to only traffic originating from the production VPC, and cross-account decryption capability must follow the principle of least privilege. Which combination of configuration changes will meet these security requirements?

Create a Gateway VPC endpoint for S3 in Account A and associate it with the subnet route tables. In Account B, keep the S3 bucket encrypted with the AWS-managed KMS key (`aws/s3`) and grant decryption permissions to Account A's IAM role by modifying the default key policy. Configure the S3 bucket policy in Account B to allow read access to Account A's IAM role only when the request originates from Account A's VPC endpoint ID.

Create a Gateway VPC endpoint for S3 in Account A and associate it with the subnet route tables. In Account B, configure a customer managed KMS key and grant decryption permissions to Account A's IAM role in the key policy. Configure the S3 bucket policy in Account B to allow read access to Account A's IAM role only when the request originates from Account A's VPC endpoint ID.

Create a Gateway VPC endpoint for S3 in Account A and associate it with the subnet route tables. In Account B, configure a customer managed KMS key. Attach a Service Control Policy (SCP) to the Organizational Unit that grants the decryption permission on the KMS key directly to Account A's IAM role, and configure the S3 bucket policy in Account B to allow read access from Account A.

Create a Gateway VPC endpoint for S3 in Account A and associate it with the subnet route tables. In Account B, configure a customer managed KMS key. Create a Route 53 Private Hosted Zone for S3 in Account B and associate it with Account A's VPC, relying on this association to authorize and route cross-account decryption requests to the key without modifying its policy.

Show answer & explanation

Answer: Create a Gateway VPC endpoint for S3 in Account A and associate it with the subnet route tables. In Account B, configure a customer managed KMS key and grant decryption permissions to Account A's IAM role in the key policy. Configure the S3 bucket policy in Account B to allow read access to Account A's IAM role only when the request originates from Account A's VPC endpoint ID.

Answer

Create a Gateway VPC endpoint for S3 in Account A, use a customer managed KMS key in Account B with a key policy allowing access to Account A's IAM role, and restrict the S3 bucket policy in Account B to the VPC endpoint ID.

The correct option is the one that creates a Gateway VPC endpoint for S3 in Account A, configures a customer managed KMS key in Account B with decryption permissions for Account A's IAM role, and configures the S3 bucket policy in Account B to restrict access to the VPC endpoint. AWS-managed keys (like aws/s3) do not support policy modification and cannot be shared across accounts, necessitating a customer managed KMS key. A Gateway VPC endpoint ensures S3 traffic stays within the AWS network and can be restricted in the S3 bucket policy using the VPC endpoint ID.

Step-by-Step Solution

Configure network isolation using a Gateway VPC endpoint in Account A.

A Gateway VPC endpoint for S3 is created and associated with Account A's subnet route tables, routing S3 traffic internally within the AWS network.

To satisfy the requirement that all traffic stays within the AWS network without exposing endpoints to the public internet.

Set up a customer managed KMS key in Account B and configure cross-account decryption access.

A new customer managed key is created in Account B with its key policy allowing Account A's IAM role to perform kms:Decrypt. S3 default encryption in Account B is updated to use this key.

AWS-managed KMS keys do not support policy modification and cannot be shared across accounts; therefore, a customer managed key is required to authorize the cross-account decrypt operation.

Configure the S3 bucket policy in Account B to grant access restricted to the VPC endpoint.

The S3 bucket policy allows s3:GetObject to Account A's IAM role, with a condition block requiring aws:sourceVpce to match Account A's VPC endpoint ID.

To implement least privilege access and restrict S3 bucket reads to only requests originating from the authorized VPC.

Key Concept

Cross-account access with KMS encryption and VPC endpoint restriction

Estimated Time:2m 0s

Question 1414Question →

A digital payment processing company hosts its core transaction API on Amazon EC2 instances within an Auto Scaling Group (ASG) behind an Application Load Balancer (ALB). The instances are deployed across three Availability Zones in private subnets, and outbound calls to external financial endpoints are routed to the internet. The EC2 instances require approximately $6$ minutes to fully bootstrap, install security agents, and download application assets before they are ready to handle traffic.

During periodic flash-sale events, the system experiences the following issues:
- The transaction rate increases from $1,000$ requests per second (RPS) to $150,000$ RPS in less than $2$ minutes, leading to high packet loss and $502$ Gateway Timeout errors at the ALB level.
- During scale-out events, the ASG launches a large number of EC2 instances that far exceed the required capacity, resulting in significant over-provisioning and increased compute costs.
- If one Availability Zone experiences a localized outage, outbound API requests to external financial endpoints fail for web instances located in all Availability Zones.

Which three actions should the solutions architect take to resolve these scaling, reliability, and connectivity issues?

Select all that apply

Deploy a NAT Gateway in each of the three Availability Zones, and configure the route tables of the private subnets in each zone to route outbound traffic to the local NAT Gateway.

Configure the Auto Scaling Group's default cooldown period and the scaling policy's instance warmup time to

420

seconds.

Submit a ticket to AWS Support to pre-warm the Application Load Balancer with the expected traffic volume prior to the scheduled flash-sale events.

Configure a single NAT Gateway in a public subnet of one Availability Zone, and update the route tables of all private subnets across all three zones to use this NAT Gateway to minimize operational overhead.

Decrease the default cooldown period to

120

seconds to enable the Auto Scaling Group to launch new instances more frequently when traffic rises rapidly.

Rely on the Application Load Balancer's native automatic scaling to handle the immediate

150

-fold traffic increase by configuring a target tracking policy based on Average Request Count per Target.

Show answer & explanation

Answer: Deploy a NAT Gateway in each of the three Availability Zones, and configure the route tables of the private subnets in each zone to route outbound traffic to the local NAT Gateway.; Configure the Auto Scaling Group's default cooldown period and the scaling policy's instance warmup time to $420$ seconds.; Submit a ticket to AWS Support to pre-warm the Application Load Balancer with the expected traffic volume prior to the scheduled flash-sale events.

Answer

Deploy a NAT Gateway in each of the three Availability Zones with local routing, set the Auto Scaling Group's cooldown and instance warmup times to

420

seconds, and request AWS Support to pre-warm the Application Load Balancer prior to scheduled events.

Deploying redundant NAT Gateways per Availability Zone ensures fault-tolerant outbound connectivity, avoiding a single point of failure. Adjusting the Auto Scaling Group's cooldown and warmup times to exceed the

6

-minute (

360

seconds) bootstrapping duration prevents over-provisioning by letting newly launched instances come online before additional capacity is evaluated. Requesting Application Load Balancer pre-warming from AWS Support prepares the load balancer to handle the sudden traffic surge from

1,000

150,000

RPS without dropping requests.

Step-by-Step Solution

Address the single point of failure for outbound internet traffic by deploying a NAT Gateway in each Availability Zone and updating subnet route tables accordingly.

Outbound connectivity is fault-tolerant, preventing a single Availability Zone outage from affecting outbound API calls from instances in other zones.

Routing all outbound traffic through a single NAT Gateway introduces a single point of failure.

Align the Auto Scaling Group's default cooldown period and instance warmup time with the

6

-minute bootstrapping duration of the instances.

The Auto Scaling Group will pause subsequent scaling actions until the newly launched instances are active and taking load, preventing over-provisioning.

If cooldown and warmup periods are shorter than the bootstrap time, metrics will remain high and cause unnecessary scale-out actions.

Request Application Load Balancer pre-warming from AWS Support prior to the scheduled flash-sale events.

The Application Load Balancer is pre-provisioned with the necessary capacity to handle the sudden, massive traffic spike without dropping connections.

An Application Load Balancer cannot scale up from

1,000

RPS to

150,000

RPS in less than

2

minutes without pre-warming.

Key Concept

Designing fault-tolerant outbound connectivity and aligning Auto Scaling cooldown metrics and load balancer scaling characteristics with workload requirements.

Question 1415Question →

A global logistics provider is designing a high-volume, multi-region track-and-trace system. The application consists of an OLTP database for package lifecycle events and an object storage component for proof-of-delivery signature images. The system must run across us-west-2 as the primary region and us-east-1 as the secondary region. The business requires a Recovery Time Objective (RTO) of less than 5 minutes and a Recovery Point Objective (RPO) of less than 10 seconds for all components. The security team mandates encryption at rest using AWS KMS Customer Managed Keys (CMKs). A separate audit account must have direct access to read database logs and S3 bucket access logs for compliance verification.

Which database and storage configurations should a solutions architect recommend to satisfy these requirements? (Select TWO.)

Select all that apply

Deploy an Amazon Aurora Global Database with the primary cluster in us-west-2 and a secondary cluster in us-east-1, using regional KMS Customer Managed Keys for cluster encryption. Configure Aurora Auto Scaling for replicas in the secondary region to handle read traffic spikes.

Configure an Amazon S3 bucket in us-west-2 with S3 cross-region replication (CRR) to a destination bucket in us-east-1. Encrypt both buckets using regional KMS Customer Managed Keys, and configure a cross-account key policy and bucket policy that grants the auditing account read access to S3 server access logs.

Deploy a Multi-AZ Amazon RDS for PostgreSQL instance in us-west-2 with cross-region read replicas in us-east-1. Configure the RDS Multi-AZ standby instance in us-west-2 to serve local read traffic to minimize read latency, and rely on RDS automated cross-region failover to meet the RTO.

Configure Amazon S3 cross-region replication between the two buckets using AWS KMS AWS-managed keys (aws/s3) to simplify key management. Use the default S3 bucket policy to grant cross-account read access to the audit account.

Deploy an Amazon Aurora PostgreSQL DB cluster in us-west-2 and configure an AWS Lambda-based scheduled snapshot copy to us-east-1 every hour. In the event of a primary region failure, restore the DB cluster from the copied snapshot in us-east-1.

Configure the Amazon S3 bucket in us-west-2 to write server access logs directly to a bucket in the centralized audit account. Set the destination bucket policy in the audit account to allow write access to cloudtrail.amazonaws.com as the primary service principal while denying all other principals.

Show answer & explanation

Answer: Deploy an Amazon Aurora Global Database with the primary cluster in us-west-2 and a secondary cluster in us-east-1, using regional KMS Customer Managed Keys for cluster encryption. Configure Aurora Auto Scaling for replicas in the secondary region to handle read traffic spikes.; Configure an Amazon S3 bucket in us-west-2 with S3 cross-region replication (CRR) to a destination bucket in us-east-1. Encrypt both buckets using regional KMS Customer Managed Keys, and configure a cross-account key policy and bucket policy that grants the auditing account read access to S3 server access logs.

Answer

The correct architecture consists of deploying an Amazon Aurora Global Database encrypted with regional Customer Managed Keys (CMKs) and configuring Aurora Auto Scaling in the secondary region, combined with Amazon S3 cross-region replication encrypted with regional Customer Managed Keys and configuring cross-account permissions for log auditing.

The correct solution leverages Amazon Aurora Global Database to achieve the required sub-second replication latency (RPO) and quick failover (RTO), and supports replica auto-scaling in the secondary region to handle read traffic. It uses S3 cross-region replication for object storage. Crucially, it utilizes KMS Customer Managed Keys (CMKs) to enable cross-account policy delegation, allowing the centralized audit account to access the required logs.

Step-by-Step Solution

Analyze RTO/RPO and scaling requirements for the OLTP workload.

Amazon Aurora Global Database provides replication latency under 1 second (meeting the RPO of less than 10 seconds) and promotion in under 5 minutes (meeting the RTO). Aurora Replicas support horizontal read scaling.

This establishes why RDS Multi-AZ with cross-region read replicas or snapshot copies fail to meet the service level agreements.

Evaluate key management and cross-account access requirements for auditing.

AWS KMS Customer Managed Keys (CMKs) are required because their key policies can be modified to grant cross-account read access, whereas AWS-managed keys (aws/s3 or aws/rds) cannot be modified or shared.

This addresses the security compliance mandate for cross-account log auditing.

Verify S3 replication and logging mechanisms.

S3 cross-region replication (CRR) copies objects asynchronously. S3 server access logs are delivered by the Log Delivery group, requiring correct bucket and key policies for cross-account access.

This avoids misconfiguring the bucket policy for CloudTrail instead of S3 logging.

Key Concept

Designing multi-region database and storage architectures that meet strict RTO/RPO targets, leverage KMS Customer Managed Keys for cross-account access, and scale read workloads.

Question 1416Question →

A retail company operates a mobile shopping application. The application's backend is hosted on Amazon EC2 instances in an Auto Scaling group (ASG) across three Availability Zones. Outbound API calls to external payment gateways are routed from private subnets through a single NAT Gateway located in one public subnet. During a simulated flash sale, traffic increases from $200$ to $80,000$ requests per minute in less than $2$ minutes. During testing, the Availability Zone containing the NAT Gateway experienced a simulated outage, which disrupted all external payment processing. Additionally, the EC2 instances require $8$ minutes to complete bootstrapping and application initialization, but the ASG's cooldown period is set to $300$ seconds, causing the ASG to launch redundant instances before the previously launched instances can begin serving traffic and reduce metric load. Which combination of actions should the solutions architect take to resolve these scaling and reliability issues with the lowest operational overhead?

Provision a NAT Gateway in each of the three Availability Zones and update the route tables for each private subnet to point to the local NAT Gateway. Increase the Auto Scaling group scaling cooldown period to

600

seconds to exceed the instance initialization time. Request AWS Support to pre-warm the Application Load Balancer prior to the scheduled flash sale.

Provision a NAT Gateway in each of the three Availability Zones and update the route tables for each private subnet to point to the local NAT Gateway. Retain the Auto Scaling group scaling cooldown period at

300

seconds, but switch the scaling policy to target tracking based on average CPU utilization. Request AWS Support to pre-warm the Application Load Balancer prior to the scheduled flash sale.

Maintain a single NAT Gateway in one public subnet but configure a Route 53 active-passive DNS failover record pointing to a secondary NAT Gateway in another Availability Zone. Increase the Auto Scaling group scaling cooldown period to

600

seconds. Request AWS Support to pre-warm the Application Load Balancer prior to the scheduled flash sale.

600

seconds. Rely on the Application Load Balancer's native automatic scaling to handle the instant flash sale traffic spike without requesting pre-warming.

Show answer & explanation

Answer: Provision a NAT Gateway in each of the three Availability Zones and update the route tables for each private subnet to point to the local NAT Gateway. Increase the Auto Scaling group scaling cooldown period to $600$ seconds to exceed the instance initialization time. Request AWS Support to pre-warm the Application Load Balancer prior to the scheduled flash sale.

Answer

600

seconds to exceed the instance initialization time. Request AWS Support to pre-warm the Application Load Balancer prior to the scheduled flash sale.

The correct solution resolves the single point of failure by establishing localized NAT Gateways in each Availability Zone. It addresses the over-scaling issue by setting a cooldown period (

600

seconds) that exceeds the

8

-minute (

480

-second) bootstrap time, ensuring the ASG waits long enough for new instances to start handling load. Finally, it prevents ALB bottlenecks during the sharp traffic surge by requesting pre-warming from AWS Support.

Step-by-Step Solution

Deploy a NAT Gateway in each Availability Zone and associate them with the respective private subnets' route tables.

This establishes redundant, localized outbound paths, eliminating the single point of failure for internet-facing payment calls.

Outbound traffic from a private subnet to the internet is governed by local VPC route tables, not DNS. Redundant NAT Gateways across AZs ensure fault tolerance.

Increase the Auto Scaling group scaling cooldown period from

300

seconds to

600

seconds.

The cooldown period now exceeds the

8

-minute (

480

seconds) bootstrapping and initialization time.

A cooldown period longer than the initialization time prevents the group from scaling out prematurely and launching unnecessary instances before previous ones can process load.

Contact AWS Support to pre-warm the Application Load Balancer prior to the flash sale.

The ALB is provisioned with sufficient capacity upfront to handle the sudden surge in traffic.

An instantaneous increase from

200

80,000

requests per minute is too rapid for the Application Load Balancer's default scaling response, making pre-warming essential to prevent service denial.

Key Concept

Ensuring fault tolerance and scalable performance by configuring multi-AZ NAT Gateways, matching Auto Scaling cooldowns to instance bootstrap times, and pre-warming Application Load Balancers for flash traffic.

Estimated Time:2m 0s

Question 1417Question →

A healthcare provider is deploying a patient management platform across multiple AWS accounts in the us-east-1 region. The platform requires high-speed, secure, and private connectivity between three Application VPCs (vpc-app-a, vpc-app-b, vpc-app-c) and a Shared Services VPC (vpc-shared). The application instances must resolve internal domain names registered in a Route 53 Private Hosted Zone (PHZ) hosted in vpc-shared. Additionally, instances in the Application VPCs must access the internet for software updates, but they do not have public IP addresses and cannot receive inbound connections from the internet. The architecture must minimize latency, ensure high availability across Availability Zones, and avoid single points of failure.

Which combination of networking actions should a Solutions Architect implement to meet these requirements? (Select TWO.)

Select all that apply

Associate the Route 53 Private Hosted Zone in the Shared Services account with vpc-app-a, vpc-app-b, and vpc-app-c by creating VPC associations.

Create an AWS Transit Gateway, attach all four VPCs, and route egress traffic from the Application VPCs to a centralized egress VPC containing a NAT Gateway in each Availability Zone.

Create an AWS Transit Gateway, attach all four VPCs, and route egress traffic from the Application VPCs to a centralized egress VPC containing a single NAT Gateway in one Availability Zone to minimize NAT hourly costs.

Rely on the Transit Gateway to automatically propagate DNS queries from the Application VPCs to the Shared Services VPC where the Private Hosted Zone is located, without creating VPC associations.

Configure VPC Peering connections between the Application VPCs and the Shared Services VPC, and use a Direct Connect Gateway to enable transitive VPC-to-VPC routing and internet egress.

Show answer & explanation

Answer: Associate the Route 53 Private Hosted Zone in the Shared Services account with vpc-app-a, vpc-app-b, and vpc-app-c by creating VPC associations.; Create an AWS Transit Gateway, attach all four VPCs, and route egress traffic from the Application VPCs to a centralized egress VPC containing a NAT Gateway in each Availability Zone.

Answer

The correct actions are to associate the Route 53 Private Hosted Zone in the Shared Services account with all Application VPCs, and to deploy an AWS Transit Gateway with a centralized egress VPC that contains redundant NAT Gateways across multiple Availability Zones.

Associating the Route 53 Private Hosted Zone with each Application VPC allows the instances inside those VPCs to resolve internal domain names hosted in the Shared Services account. Deploying an AWS Transit Gateway and using a centralized egress VPC with multiple NAT Gateways (one per Availability Zone) provides high availability and eliminates single points of failure for outbound internet traffic.

Step-by-Step Solution

Configure DNS resolution for the private hosted zone across VPC boundaries.

Create VPC associations between the Route 53 Private Hosted Zone and vpc-app-a, vpc-app-b, and vpc-app-c.

This allows instances in the application VPCs to use the local Route 53 Resolver to resolve the custom domains hosted in the shared services VPC.

Establish transitive routing across the multi-account mesh.

Deploy an AWS Transit Gateway and attach all four VPCs to it.

Transit Gateway enables scalable, hub-and-spoke connectivity between multiple VPCs without the limitation of non-transitive VPC peering.

Configure resilient internet egress routing.

Deploy a NAT Gateway in each Availability Zone of the centralized egress VPC and update Transit Gateway route tables to send outbound traffic through them.

Using multiple NAT Gateways distributed across Availability Zones ensures that an outage in one zone does not disrupt internet egress for the rest of the application VPCs.

Key Concept

Multi-VPC Route 53 Private Hosted Zone association and high-availability centralized NAT egress routing using AWS Transit Gateway.

Question 1418Question →

A media streaming company uses AWS Organizations to manage its multi-account environment. The security team enforces that all VPC security groups in member accounts are deployed and updated exclusively via a centralized CI/CD pipeline using AWS CloudFormation StackSets from a central Administration account. The security team must implement a solution to detect any manual modifications to these security groups, automatically revert the resources to their template-defined state, and log the remediation details to a centralized Amazon S3 bucket in a Security account. The S3 bucket must be encrypted, and all operations must adhere to the principle of least privilege. Which strategy should a solutions architect implement to meet these requirements?

Apply a Service Control Policy (SCP) at the Organizational Unit (OU) level that denies ec2:AuthorizeSecurityGroupIngress and ec2:RevokeSecurityGroupIngress for all IAM identities except the CloudFormation execution role, assuming this SCP will automatically revert any unauthorized manual changes to the security groups and write log entries to the central S3 bucket.

Deploy an AWS Config rule to monitor the security groups for drift. Configure the AWS Config rule to trigger an AWS Systems Manager (SSM) Automation runbook. Store the SSM execution logs in the Security account's Amazon S3 bucket encrypted with the default AWS-managed KMS key (aws/s3), and configure the bucket policy to delegate cross-account access to the member account roles.

Deploy an AWS Config rule to monitor the security groups for drift. Configure the AWS Config rule to trigger an AWS Systems Manager (SSM) Automation runbook. The runbook assumes a cross-account IAM role to execute remediation. Store the SSM execution logs in the Security account's Amazon S3 bucket encrypted with a KMS Customer Managed Key (CMK) whose key policy grants kms:GenerateDataKey and kms:Decrypt permissions to the member account roles.

Configure an Amazon EventBridge rule that detects manual security group modifications in AWS CloudTrail logs, and trigger an AWS Systems Manager Run Command script to run local AWS CLI commands in the member accounts to overwrite rules, bypassing the CloudFormation stack's state.

Show answer & explanation

Answer: Deploy an AWS Config rule to monitor the security groups for drift. Configure the AWS Config rule to trigger an AWS Systems Manager (SSM) Automation runbook. The runbook assumes a cross-account IAM role to execute remediation. Store the SSM execution logs in the Security account's Amazon S3 bucket encrypted with a KMS Customer Managed Key (CMK) whose key policy grants kms:GenerateDataKey and kms:Decrypt permissions to the member account roles.

Answer

Deploying an AWS Config rule to monitor security groups and triggering an AWS Systems Manager Automation runbook enables automated detection and remediation of configuration drift. For the cross-account logging to succeed, the target Amazon S3 bucket must be encrypted with a Customer Managed Key (CMK). A Customer Managed Key's policy can be modified to grant the necessary KMS permissions to external member accounts. This satisfies both the automated remediation and security requirements.

Step-by-Step Solution

Detect configuration drift using AWS Config rules.

Active monitoring detects when any VPC security group deviates from the CloudFormation StackSets template configuration.

AWS Config provides a managed way to continuously evaluate compliance of resources against declared configurations.

Automate remediation using Systems Manager Automation.

An SSM Automation runbook is triggered to restore the security group back to the template state using a cross-account IAM role.

Ensures drift is resolved quickly and programmatically without manual operator intervention.

Configure a Customer Managed Key (CMK) for cross-account S3 bucket logging.

Allows external member accounts to write execution logs to the central Security account S3 bucket.

AWS-managed KMS keys do not support policy modifications and cannot be shared across account boundaries, requiring a CMK instead.

Key Concept

Cross-account drift remediation and secure log aggregation using Customer Managed Keys (CMKs).

Estimated Time:2m 30s

Question 1419Question →

An enterprise operates a high-throughput data analytics platform on AWS in the `us-east-1` Region. The architecture consists of a production VPC (`VPC-Prod`) spanning three Availability Zones (AZ-a, AZ-b, and AZ-c) containing a fleet of Amazon EC2 instances in private subnets. These instances upload approximately $300\text{ TB}$ of raw data monthly to an Amazon S3 bucket located in the same Region. Currently, the EC2 instances route all outbound internet and S3 traffic through NAT Gateways deployed in each AZ.

Additionally, the EC2 instances perform daily synchronization tasks with a shared PostgreSQL database cluster hosted in a central services VPC (`VPC-Shared`) in `us-east-1`. This database synchronization transfers $150\text{ TB}$ of data monthly. Currently, this traffic is routed through an AWS Transit Gateway, with the Transit Gateway attachment configured only in a single subnet in AZ-a within `VPC-Prod`.

A Solutions Architect needs to optimize the architecture to achieve the maximum possible reduction in data transfer and processing costs without compromising availability or security.

Which combination of actions should the Solutions Architect take to meet these requirements? (Select TWO.)

Select all that apply

Create an Amazon S3 Gateway VPC Endpoint in `VPC-Prod`, and associate it with the route tables of the private subnets containing the EC2 instances.

Establish a VPC Peering connection between `VPC-Prod` and `VPC-Shared`, update the route tables to route the database synchronization traffic over the peering connection, and configure the application to resolve the database endpoints to local Availability Zone IP addresses.

Deploy an S3 Interface VPC Endpoint (AWS PrivateLink) in each Availability Zone of `VPC-Prod`, and update the private subnet route tables to target the interface endpoints.

Configure Transit Gateway attachments in `VPC-Prod` across all three Availability Zones, and enable Appliance Mode on the Transit Gateway to load-balance traffic and eliminate cross-AZ charges.

Use AWS Resource Access Manager (RAM) to share the database network interfaces from `VPC-Shared` to `VPC-Prod`, routing traffic locally within the subnets of `VPC-Prod`.

Establish an AWS Direct Connect gateway with a Transit Virtual Interface (VIF) between `VPC-Prod` and `VPC-Shared` to bypass the Transit Gateway data processing charges.

Show answer & explanation

Answer: Create an Amazon S3 Gateway VPC Endpoint in `VPC-Prod`, and associate it with the route tables of the private subnets containing the EC2 instances.; Establish a VPC Peering connection between `VPC-Prod` and `VPC-Shared`, update the route tables to route the database synchronization traffic over the peering connection, and configure the application to resolve the database endpoints to local Availability Zone IP addresses.

Answer

To optimize storage and data transfer costs, the Solutions Architect should create an Amazon S3 Gateway VPC Endpoint in the production VPC to bypass NAT Gateways for S3 uploads, and establish a VPC Peering connection between the production and shared services VPCs with local Availability Zone routing for the database synchronization traffic.

The correct solution uses an Amazon S3 Gateway VPC Endpoint to bypass the NAT Gateways for the S3 upload traffic, saving the

\$0.045\text{ per GB}

processing charge (about

\$13,500\text{ monthly}

). For the database synchronization traffic, establishing a VPC Peering connection bypasses the Transit Gateway's

\$0.02\text{ per GB}

data processing charge (saving

\$3,000\text{ monthly}

). Routing the database traffic locally within the same Availability Zone over the VPC Peering connection ensures that no inter-AZ data transfer charges are incurred, removing the remaining routing costs.

Step-by-Step Solution

Calculate the NAT Gateway processing costs for the S3 upload traffic.

300\text{ TB}

of data uploads monthly through NAT Gateways costs

\$13,500

in processing fees (

300,000\text{ GB} \times \$0.045/\text{GB}

To identify the largest cost driver in S3 data transfer.

Identify a free replacement for the S3 NAT Gateway path.

Creating an S3 Gateway VPC Endpoint provides a free route that bypasses NAT Gateways completely.

To eliminate the

\$13,500

monthly processing cost.

Analyze the Transit Gateway data processing and routing costs for the database synchronization.

150\text{ TB}

of data routed through Transit Gateway costs

\$3,000

in processing fees (

150,000\text{ GB} \times \$0.02/\text{GB}

) plus approximately

\$1,000

in cross-AZ transfer charges due to the single-AZ attachment.

To evaluate the financial impact of the database synchronization routing.

Replace the Transit Gateway routing for high-volume database traffic with a free peering alternative.

Establishing a VPC Peering connection removes the processing fee entirely, and local AZ routing makes intra-AZ traffic free, saving

\$4,000

monthly.

To achieve the maximum possible reduction in VPC-to-VPC data transfer costs.

Key Concept

Optimizing data transfer costs using S3 Gateway VPC Endpoints instead of NAT Gateways, and using VPC Peering instead of Transit Gateway for high-volume intra-Region VPC-to-VPC traffic.

Question 1420Question →

A media streaming company manages three AWS accounts (Development, Staging, and Production) under an AWS Organization with consolidated billing. The Production account runs a steady-state application on a fleet of EC2 instances, with supplementary microservices deployed on AWS Fargate and AWS Lambda. The private subnets in the Production VPC route all outbound traffic through a pair of NAT Gateways (one in each Availability Zone) to access Amazon S3 and Amazon DynamoDB. The Development account contains several EC2 instances that run continuously but are only needed during working hours ( $9\text{ AM} - 5\text{ PM}$ ). The Solutions Architect needs to implement cost-optimization strategies that reduce overall expenditure without compromising the high availability of production workloads. Which of the following actions should the Solutions Architect recommend? (Select TWO.)

Select all that apply

Purchase Compute Savings Plans in the organization's management account to apply cost discounts across the EC2, Fargate, and Lambda workloads in all member accounts.

Deploy VPC Gateway Endpoints for Amazon S3 and Amazon DynamoDB in the Production VPC, and configure route tables to direct this traffic through the endpoints.

Purchase EC2 Instance Savings Plans in the Production account to apply cost discounts to the AWS Fargate tasks and AWS Lambda functions.

Replace the dual NAT Gateways in the Production VPC with a single NAT Gateway deployed in a single public subnet to reduce hourly NAT Gateway provisioning costs.

Use AWS Resource Access Manager (RAM) to share Savings Plans with member accounts to ensure the discount is applied to Development and Staging workloads.

Show answer & explanation

Answer: Purchase Compute Savings Plans in the organization's management account to apply cost discounts across the EC2, Fargate, and Lambda workloads in all member accounts.; Deploy VPC Gateway Endpoints for Amazon S3 and Amazon DynamoDB in the Production VPC, and configure route tables to direct this traffic through the endpoints.

Answer

Purchasing Compute Savings Plans in the organization's management account and deploying VPC Gateway Endpoints for Amazon S3 and Amazon DynamoDB in the Production VPC.

Compute Savings Plans applied at the organization level automatically distribute discounts across all member accounts and cover EC2, Fargate, and Lambda workloads. Setting up VPC Gateway Endpoints for S3 and DynamoDB routes traffic through private AWS endpoints rather than NAT Gateways, eliminating data processing fees while retaining high availability.

Step-by-Step Solution

Analyze the workload characteristics and compute requirements across the organization.

Workloads include steady-state EC2 instances, ephemeral Fargate tasks, and Lambda functions across multiple accounts.

Understanding the compute footprint helps select the appropriate discount vehicle.

Evaluate the types of Savings Plans against the compute requirements.

Compute Savings Plans are selected because they apply to EC2, Fargate, and Lambda across all member accounts, whereas EC2 Instance Savings Plans only apply to EC2 and are restricted by family and region.

This maximizes the discount coverage for the diverse compute stack.

Examine the network traffic routing and cost components for S3 and DynamoDB data transfer.

VPC Gateway Endpoints are chosen for S3 and DynamoDB.

This routes traffic locally without NAT Gateway data processing charges, maintaining high availability and security.

Key Concept

AWS cost optimization using Compute Savings Plans and VPC Gateway Endpoints to reduce NAT Gateway and compute costs.

PreviousPage 71 / 99Next

All practice questions

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept