All practice questions

1964 questions

All types1,964 Multiple choice1,006 Multiple select931 Ordering27

An enterprise is designing a new multi-region, multi-account AWS environment with the following VPCs:
- In us-east-1: VPC-Retail-Prod and VPC-Retail-Dev (owned by Account A)
- In eu-west-1: VPC-Wholesale-Prod and VPC-Wholesale-Dev (owned by Account B)
- In us-east-1: VPC-Core-Ops (owned by Account C), which hosts a Route 53 Private Hosted Zone (PHZ) named corp.internal

The architectural requirements are:
1. VPC-Retail-Prod and VPC-Wholesale-Prod must have private, bi-directional, lowest-latency, and most cost-effective network connectivity.
2. The development VPCs (VPC-Retail-Dev and VPC-Wholesale-Dev) must remain completely isolated from the production VPCs and from each other.
3. Resources in all four application VPCs must resolve DNS queries for the corp.internal domain.
4. Resources in the private subnets of VPC-Retail-Prod and VPC-Wholesale-Prod must have highly available, redundant outbound IPv4 internet access.

Which solution should a solutions architect recommend to meet these requirements?

Establish an inter-region VPC peering connection between VPC-Retail-Prod and VPC-Wholesale-Prod. In Account C, create VPC association authorizations for corp.internal to authorize associations with the four application VPCs, then accept the associations in Accounts A and B. In each production VPC, deploy a single NAT Gateway in one public subnet, and configure the private subnet route tables in all Availability Zones to route outbound traffic through this single NAT Gateway.

Deploy AWS Transit Gateways in us-east-1 and eu-west-1 and peer them. Attach VPC-Retail-Prod, VPC-Retail-Dev, VPC-Wholesale-Prod, and VPC-Wholesale-Dev to their respective regional Transit Gateways. Use Transit Gateway route tables to allow production-to-production routing and isolate development traffic. Associate the PHZ corp.internal with the Transit Gateways to enable DNS resolution across all VPCs. In each production VPC, deploy NAT Gateways in each public subnet across multiple Availability Zones for internet access.

Establish an inter-region VPC peering connection between VPC-Retail-Prod and VPC-Wholesale-Prod. In Account C, create VPC association authorizations for corp.internal to authorize associations with the four application VPCs, then accept the associations in Accounts A and B. In each production VPC, deploy a NAT Gateway in each public subnet across multiple Availability Zones, and update the private subnet route tables to direct outbound traffic to the NAT Gateway in their respective Availability Zone.

Establish an inter-region VPC peering connection between VPC-Retail-Prod and VPC-Wholesale-Prod, and establish VPC peering from VPC-Core-Ops to all four application VPCs. Deploy Route 53 Resolver inbound endpoints in VPC-Core-Ops and outbound endpoints in each application VPC to forward DNS queries for corp.internal over the peering connections. In each production VPC, deploy a NAT Gateway in each public subnet across multiple Availability Zones.

Show answer & explanation

Answer: Establish an inter-region VPC peering connection between VPC-Retail-Prod and VPC-Wholesale-Prod. In Account C, create VPC association authorizations for corp.internal to authorize associations with the four application VPCs, then accept the associations in Accounts A and B. In each production VPC, deploy a NAT Gateway in each public subnet across multiple Availability Zones, and update the private subnet route tables to direct outbound traffic to the NAT Gateway in their respective Availability Zone.

Answer

The correct solution is to establish an inter-region VPC peering connection between the two production VPCs, perform direct cross-account Private Hosted Zone associations for DNS resolution, and deploy multi-AZ NAT Gateways in the production VPCs for redundant egress.

Establishing an inter-region VPC peering connection provides direct, low-latency communication with no data processing fees, making it the most cost-effective design for this specific topology. Performing direct cross-account Private Hosted Zone association resolves DNS names natively without requiring expensive Route 53 Resolver endpoints. Finally, deploying a NAT Gateway in each public subnet across multiple Availability Zones prevents a single Availability Zone outage from disrupting outbound internet traffic for the entire VPC.

Step-by-Step Solution

Determine the optimal cross-region network connectivity for the production VPCs.

VPC Peering is selected over Transit Gateway because it provides direct, lowest-latency routing and avoids Transit Gateway's hourly attachment and data processing charges.

Since only two production VPCs need to communicate, a complex hub-and-spoke model is unnecessary and less cost-effective.

Design the DNS resolution architecture for the centralized Private Hosted Zone.

Use Route 53 VPC association authorizations in Account C to authorize cross-account associations, and associate the PHZ directly with all four application VPCs.

Direct association allows VPCs to resolve the PHZ without the cost, complexity, and latency of deploying Route 53 Resolver endpoints.

Configure egress routing to support high availability and redundancy.

Deploy a NAT Gateway in each Availability Zone containing active private resources in the production VPCs.

Using a single NAT Gateway creates a single point of failure, violating the redundancy requirement during a zone outage.

Key Concept

Designing cost-effective, high-performance, and resilient multi-region networking by choosing VPC Peering for simple peering topologies, leveraging cross-account Route 53 Private Hosted Zone associations, and deploying redundant multi-AZ NAT Gateways for egress.

Question 342Question →

A genomics research organization runs a batch sequencing data analysis pipeline on AWS. The pipeline runs once a day, processing large genetic sequencing files. The architecture consists of a fleet of Amazon EC2 instances running inside an Auto Scaling group that processes tasks retrieved from an Amazon SQS queue. The raw files are downloaded from Amazon S3 to the instances' local EBS gp3 volumes for processing. During the peak of the daily batch run, the processing times increase significantly, and CloudWatch metrics reveal that the EC2 instances experience high CPU wait times as the gp3 volumes reach their default performance baseline of $3,000$ IOPS and $125\text{ MiB/s}$ throughput. Additionally, a web-based reporting dashboard queries an Amazon RDS for PostgreSQL Multi-AZ database containing metadata about the completed runs. During these batch windows, users experience slow load times on the dashboard due to high database CPU utilization from reporting queries.

Which two actions should a Solutions Architect take to resolve these performance bottlenecks? (Select TWO.)

Select all that apply

Modify the configuration of the gp3 EBS volumes on the EC2 instances to provision higher IOPS and throughput that match the workload's peak I/O demands.

Deploy an Amazon RDS PostgreSQL Read Replica, and configure the web-based reporting dashboard to direct its query traffic to the read replica's endpoint.

Configure the reporting dashboard to direct read-heavy query traffic to the standby instance of the RDS PostgreSQL Multi-AZ database deployment.

Set the Auto Scaling group scaling cooldown period to

10

seconds to allow the EC2 fleet to scale out instantly when the queue size increases.

Submit a request to AWS Support to pre-warm the Application Load Balancer (ALB) servicing the EC2 processing fleet prior to the scheduled daily batch run.

Show answer & explanation

Answer: Modify the configuration of the gp3 EBS volumes on the EC2 instances to provision higher IOPS and throughput that match the workload's peak I/O demands.; Deploy an Amazon RDS PostgreSQL Read Replica, and configure the web-based reporting dashboard to direct its query traffic to the read replica's endpoint.

Answer

Modifying the gp3 EBS volumes to provision higher IOPS and throughput, and deploying an Amazon RDS Read Replica to handle reporting queries.

The correct actions are to provision higher IOPS and throughput for the gp3 volumes on the EC2 instances, which directly addresses the storage performance bottleneck, and to deploy an Amazon RDS PostgreSQL Read Replica to offload reporting queries from the primary database instance.

Step-by-Step Solution

Analyze the storage bottleneck on the EC2 processing fleet.

Identify that the gp3 volumes are hitting their baseline limits (

3,000

IOPS and

125\text{ MiB/s}

), causing high CPU wait states.

Increasing the provisioned IOPS and throughput on the existing gp3 volumes will eliminate the storage throughput bottleneck.

Analyze the database CPU utilization bottleneck.

Identify that read-heavy reporting dashboard queries are saturating the primary RDS instance in a Multi-AZ deployment.

Deploying a Read Replica allows the read queries to be offloaded from the primary write-intensive instance, since Multi-AZ standby instances cannot serve read traffic.

Key Concept

Tuning compute performance by resolving EBS storage throughput limits and offloading database read workloads using replication.

Estimated Time:3m 0s

Question 343Question →

A company is designing a new cloud infrastructure in the us-east-1 Region. The architecture features an application VPC (vpc-prod-app, CIDR $10.10.0.0/16$ ) containing instances distributed across three Availability Zones (us-east-1a, us-east-1b, and us-east-1c) in private subnets. The instances require outbound-only internet access to retrieve security updates. The design must be highly available and resilient to Availability Zone failures, while minimizing data transfer charges. Additionally, the instances must resolve private domain names in the corp.internal Route 53 private hosted zone, which is hosted in a separate centralized AWS Services account. Which of the following designs should a solutions architect recommend to meet these requirements?

Deploy a NAT Gateway in a public subnet in each of the three Availability Zones. Configure the route table of each private subnet to route outbound internet traffic (

0.0.0.0/0

) to the NAT Gateway in the same Availability Zone. Create a VPC association authorization from the centralized AWS Services account, and associate the corp.internal private hosted zone with vpc-prod-app.

Deploy a single NAT Gateway in a public subnet in us-east-1a. Configure the route tables of all private subnets to route outbound internet traffic (

0.0.0.0/0

) to this single NAT Gateway. Create a VPC association authorization from the centralized AWS Services account, and associate the corp.internal private hosted zone with vpc-prod-app.

Deploy a NAT Gateway in a public subnet in each of the three Availability Zones. Configure the route table of each private subnet to route outbound internet traffic (

0.0.0.0/0

) to the NAT Gateway in the same Availability Zone. In the centralized AWS Services account, deploy Route 53 Resolver outbound endpoints, and configure a forwarding rule for corp.internal pointing to the AWS-provided DNS IP address (

10.10.0.2

) of vpc-prod-app without associating the private hosted zone.

Deploy a single NAT Gateway in a centralized transit VPC. Connect vpc-prod-app to the transit VPC using an AWS Transit Gateway, and route all outbound internet traffic (

0.0.0.0/0

) through the Transit Gateway. Rely on the default AWS-provided DNS (

10.10.0.2

) in vpc-prod-app to resolve corp.internal without performing any cross-account associations.

Show answer & explanation

Answer: Deploy a NAT Gateway in a public subnet in each of the three Availability Zones. Configure the route table of each private subnet to route outbound internet traffic ( $0.0.0.0/0$ ) to the NAT Gateway in the same Availability Zone. Create a VPC association authorization from the centralized AWS Services account, and associate the corp.internal private hosted zone with vpc-prod-app.

Answer

Deploy a NAT Gateway in a public subnet in each of the three Availability Zones, configure the private subnets to route outbound traffic to their local NAT Gateway, and create a cross-account VPC association for the Route 53 private hosted zone.

The correct design deploys a NAT Gateway in each Availability Zone to ensure high availability and prevent cross-AZ data transfer charges for egress traffic. For DNS resolution, a cross-account Route 53 Private Hosted Zone association is established by authorizing the association from the owner account and accepting/associating it from the VPC owner account.

Step-by-Step Solution

Design the outbound internet routing for high availability and low cost.

Deploying a NAT Gateway in each Availability Zone avoids cross-AZ data transfer fees and ensures that an outage in one AZ does not affect internet connectivity in the other AZs.

Outbound traffic must not cross Availability Zones unnecessarily due to data transfer fees, and high resiliency is a key requirement.

Configure private DNS resolution across separate AWS accounts.

Create a VPC association authorization in the AWS Services account where the private hosted zone is defined, and then associate the zone with the application VPC using the AWS CLI, SDK, or Console.

Route 53 Private Hosted Zones are not automatically resolvable by other VPCs unless they are explicitly associated, even across accounts.

Key Concept

Multi-AZ NAT Gateway routing and cross-account Route 53 Private Hosted Zone association.

Question 344Question →

A regional retail chain wants to migrate its custom inventory management system to AWS. The system is composed of three components: a stateless PHP web interface running on Apache, an Oracle 19c database, and a legacy reporting daemon that is bound to a physical hardware dongle on-premises.

The migration must satisfy the following requirements:
- The PHP web interface must be migrated with minimal changes, but the team wants to eliminate operating system administration and patching overhead.
- The Oracle database must be migrated to Amazon Aurora PostgreSQL to eliminate licensing costs, which requires converting the database schema and rewriting complex stored procedures.
- The reporting daemon must continue to generate weekly reports, but cannot be virtualized or migrated to the cloud due to the hardware lock.

Which combination of migration strategies from the 7 Rs framework should the company select for these components?

Replatform the web interface, refactor the database, and retain the reporting daemon.

Rehost the web interface, replatform the database, and retain the reporting daemon.

Replatform the web interface, replatform the database, and retire the reporting daemon.

Refactor the web interface, refactor the database, and relocate the reporting daemon.

Show answer & explanation

Answer: Replatform the web interface, refactor the database, and retain the reporting daemon.

Answer

Replatform the web interface, refactor the database, and retain the reporting daemon.

The correct strategy combination is Replatforming the web interface, Refactoring the database, and Retaining the reporting daemon. Replatforming the web interface to a managed service like AWS Elastic Beanstalk or Amazon ECS minimizes code changes while eliminating operating system administration. Refactoring the database is necessary because switching engines from Oracle to Aurora PostgreSQL requires database schema conversion and code rewrites. Retaining the reporting daemon is the only viable option since the physical hardware lock prevents virtualization or cloud migration, while the reports remain a business necessity.

Step-by-Step Solution

Analyze the web interface requirements: minimal changes and no OS administration.

Identify that a managed service (such as AWS Elastic Beanstalk or AWS Fargate) satisfies these requirements without a complete code rewrite, which maps to the Replatform strategy.

Replatforming allows the migration of workloads to managed cloud platforms with minor optimizations but no changes to core application architecture.

Analyze the database requirements: heterogeneous engine migration (Oracle to Aurora PostgreSQL) and code changes.

Identify that migrating across database engines and modifying database logic (stored procedures) maps to the Refactor (Re-architect) strategy.

Refactoring is required when changing the core architecture, database engines, or application code to utilize cloud-native features.

Analyze the reporting daemon requirements: bound to a physical hardware dongle on-premises but still required.

Identify that the system cannot be moved to the cloud, meaning it must be kept on-premises, which maps to the Retain strategy.

Retain is used for applications that cannot be migrated to the cloud due to technical, regulatory, or business constraints.

Key Concept

Selecting migration strategies using the 7 Rs framework based on application dependencies, code change requirements, database engines, and operational overhead constraints.

Estimated Time:2m 0s

Question 345Question →

A solutions architect is planning a heterogeneous database migration from an on-premises Oracle database to Amazon Aurora PostgreSQL using the AWS Schema Conversion Tool (SCT) and AWS Database Migration Service (DMS). To optimize the performance of the initial DMS full load phase and reduce target write latency, which action should the solutions architect take?

Deploy a single NAT Gateway in the public subnet and route all replication traffic from multiple Availability Zones through it to consolidate network bandwidth.

Provision an Amazon ElastiCache for Memcached cluster to act as a persistent replication cache between the source and target databases.

Disable secondary indexes, foreign key constraints, and triggers on the target database before starting the full load, and re-enable them after completion.

Enable supplemental logging or binary logging on the source database to accelerate the data transfer rate of the initial full load.

Show answer & explanation

Answer: Disable secondary indexes, foreign key constraints, and triggers on the target database before starting the full load, and re-enable them after completion.

Answer

Disable secondary indexes, foreign key constraints, and triggers on the target database before starting the full load, and re-enable them after completion.

Disabling secondary indexes, foreign key constraints, and triggers on the target database before beginning a full load operation is a standard best practice to reduce write latency and maximize ingestion throughput. These components can be re-enabled and rebuilt once the full load phase completes.

Step-by-Step Solution

Identify the primary source of target database write latency during a bulk data load phase.

Secondary indexes, foreign keys, and triggers add significant write overhead for every inserted row.

By understanding that target database constraints and indexes slow down bulk inserts, we can plan to temporarily remove them.

Determine the configuration strategy to minimize target database overhead.

Disabling these constraints and indexes on the target before starting the full load task.

This allows DMS to perform high-speed bulk inserts without waiting for index updates or constraint validation.

Determine the post-load cleanup steps.

Re-enable foreign keys, triggers, and rebuild secondary indexes.

This ensures data integrity and query performance are restored once the bulk load is complete.

Key Concept

AWS Database Migration Service (DMS) full load optimization strategies

Question 346Question →

A financial services company is designing a new cloud infrastructure in the eu-west-3 Region. The architecture requires two application spoke VPCs (vpc-payment-processing and vpc-user-portal) to access the internet for software updates and third-party API integration. The solution must prevent direct inbound connections from the internet to the application instances. Additionally, the company has a centralized shared services VPC (vpc-shared-core) hosting a Route 53 Private Hosted Zone named internal.fintech.aws. The application instances in both spoke VPCs must resolve names within this Private Hosted Zone. An AWS Transit Gateway named tgw-central connects all three VPCs. The solution must be highly available across two Availability Zones (eu-west-3a and eu-west-3b) and minimize latency and cross-AZ data transfer costs. Which two configurations should the solutions architect implement to meet these requirements?

Select all that apply

In vpc-shared-core, deploy a NAT Gateway in a public subnet in each Availability Zone (eu-west-3a and eu-west-3b). Configure the Transit Gateway attachment subnets in vpc-shared-core with route tables that direct egress traffic to the local NAT Gateway in the same Availability Zone.

Associate the Route 53 Private Hosted Zone internal.fintech.aws with the spoke VPCs (vpc-payment-processing and vpc-user-portal) as well as the shared services VPC (vpc-shared-core).

In vpc-shared-core, deploy a single NAT Gateway in eu-west-3a and configure all Transit Gateway attachment subnet route tables to route outbound traffic to this single NAT Gateway.

Associate the Route 53 Private Hosted Zone internal.fintech.aws only with vpc-shared-core, and rely on the Transit Gateway route propagation to transitively resolve DNS queries from the spoke VPCs.

Establish VPC peering connections between vpc-payment-processing and vpc-user-portal, and configure the spoke VPC route tables to route all outbound internet traffic transitively through the peering connection to vpc-shared-core.

Show answer & explanation

Answer: In vpc-shared-core, deploy a NAT Gateway in a public subnet in each Availability Zone (eu-west-3a and eu-west-3b). Configure the Transit Gateway attachment subnets in vpc-shared-core with route tables that direct egress traffic to the local NAT Gateway in the same Availability Zone.; Associate the Route 53 Private Hosted Zone internal.fintech.aws with the spoke VPCs (vpc-payment-processing and vpc-user-portal) as well as the shared services VPC (vpc-shared-core).

Answer

Deploy a NAT Gateway in each Availability Zone in the shared services VPC and associate the Private Hosted Zone with all VPCs.

To satisfy the requirements of high availability, minimized latency, and reduced cross-AZ data transfer costs, a solutions architect should deploy a NAT Gateway in a public subnet within each Availability Zone in the centralized egress VPC. The routing for the Transit Gateway attachment subnets in the egress VPC must point to the local NAT Gateway in the same Availability Zone. Furthermore, to enable DNS resolution of private domain names hosted in a Private Hosted Zone (PHZ) in other VPCs, the PHZ must be explicitly associated with each VPC that needs to perform DNS resolution. Transitive DNS resolution is not supported natively over Transit Gateway attachments without PHZ association or Route 53 Resolver endpoints.

Step-by-Step Solution

Configure the centralized egress routing infrastructure by deploying a NAT Gateway in a public subnet in both Availability Zones (eu-west-3a and eu-west-3b) of the shared services VPC.

Redundant NAT gateways are available, ensuring high availability and local AZ egress routes.

To satisfy high availability and prevent cross-AZ data transfer costs, traffic must stay within its local AZ.

Configure the Transit Gateway attachment subnets' route tables in the shared services VPC to point their default route (0.0.0.0/0) to the NAT Gateway in their respective Availability Zone.

Egress traffic from the Transit Gateway is routed to the local NAT Gateway within the same AZ.

This guarantees that outbound internet traffic from the spoke VPCs is processed by the local NAT Gateway, preventing cross-AZ charges.

Associate the Route 53 Private Hosted Zone internal.fintech.aws with vpc-payment-processing and vpc-user-portal in addition to vpc-shared-core.

Private DNS resolution for internal.fintech.aws works successfully across all spoke VPCs.

Route 53 Private Hosted Zones require explicit association with consumer VPCs to resolve records inside them.

Key Concept

Centralized VPC egress architecture and Route 53 Private Hosted Zone cross-VPC association.

Estimated Time:3m 0s

Question 347Question →

A company operates a critical media processing application with a primary environment in the eu-west-1 Region and a standby disaster recovery environment in the eu-central-1 Region. The database tier utilizes Amazon Aurora PostgreSQL Global Database, where the primary cluster is in eu-west-1 and the secondary cluster is in eu-central-1. Microservices in both regions resolve database endpoints using a private hosted zone in Route 53. The application instances in both regions are deployed across multiple Availability Zones in private subnets and require outbound internet access to call external APIs. During a disaster recovery drill, the administrator observed that secondary region instances failed to resolve database endpoints, outbound API calls failed when one Availability Zone in eu-central-1 experienced an outage, and client traffic did not automatically redirect to the secondary region. Which combination of actions will resolve these reliability and disaster recovery issues?

Associate the existing database Route 53 private hosted zone with the VPC in eu-central-1. Deploy a NAT Gateway in each Availability Zone of the eu-central-1 VPC, updating the corresponding route tables. Configure Route 53 Failover routing records pointing to the Application Load Balancers in both regions, and enable Evaluate Target Health on the alias records.

Create a duplicate Route 53 private hosted zone with the same domain name in the eu-central-1 VPC. Deploy a NAT Gateway in each Availability Zone of the eu-central-1 VPC, updating the corresponding route tables. Configure Route 53 Failover routing records pointing to the Application Load Balancers in both regions, and enable Evaluate Target Health on the alias records.

Associate the existing database Route 53 private hosted zone with the VPC in eu-central-1. Deploy a single NAT Gateway in one Availability Zone of the eu-central-1 VPC, updating all private subnet route tables to point to it. Configure Route 53 Failover routing records pointing to the Application Load Balancers in both regions, and enable Evaluate Target Health on the alias records.

Associate the existing database Route 53 private hosted zone with the VPC in eu-central-1. Deploy a NAT Gateway in each Availability Zone of the eu-central-1 VPC, updating the corresponding route tables. Configure Route 53 simple routing records pointing to the Application Load Balancers in both regions with a low Time to Live (TTL) value, planning for manual updates during a failover event.

Show answer & explanation

Answer: Associate the existing database Route 53 private hosted zone with the VPC in eu-central-1. Deploy a NAT Gateway in each Availability Zone of the eu-central-1 VPC, updating the corresponding route tables. Configure Route 53 Failover routing records pointing to the Application Load Balancers in both regions, and enable Evaluate Target Health on the alias records.

Answer

Associate the existing database Route 53 private hosted zone with the VPC in eu-central-1, deploy a NAT Gateway in each Availability Zone of the eu-central-1 VPC, and configure Route 53 Failover routing records pointing to the Application Load Balancers in both regions with Evaluate Target Health enabled.

Associating the existing database Route 53 private hosted zone with the VPC in eu-central-1 allows the standby instances to resolve database endpoints. Deploying a NAT Gateway in each Availability Zone of the secondary VPC ensures that outbound API calls remain highly available even if one Availability Zone experiences an outage. Configuring Route 53 Failover records with Evaluate Target Health enabled ensures automated client redirection when the primary Application Load Balancer becomes unhealthy.

Step-by-Step Solution

Associate the existing Route 53 Private Hosted Zone (PHZ) with the secondary VPC in eu-central-1.

Standby application instances in eu-central-1 can resolve the database endpoints locally.

Private Hosted Zones must be explicitly associated with any VPC that requires resolution of those records.

Deploy a NAT Gateway in each Availability Zone within the eu-central-1 VPC and configure private subnet route tables accordingly.

Outbound traffic remains operational and redundant during an Availability Zone failure.

Deploying a NAT Gateway per Availability Zone removes the single point of failure for outbound internet traffic.

Configure Route 53 Failover routing records with the Evaluate Target Health parameter enabled on the alias records.

Traffic automatically redirects to the secondary region if the primary region Application Load Balancer fails health checks.

Evaluate Target Health enables Route 53 to inherit the health status of the load balancer backend, facilitating automated failover.

Key Concept

Multi-region disaster recovery architectures must ensure that private DNS resolution, redundant outbound gateways, and automatic failover records are properly configured to prevent single points of failure.

Question 348Question →

An enterprise utilizes AWS CloudFormation to manage its web application infrastructure, which includes Amazon EC2 Auto Scaling groups and Amazon VPC security groups. To comply with security policies, the security team requires that any configuration drift—specifically unauthorized manual modifications to security groups and EC2 instances—must be automatically detected and remediated. The operations team also requires that remediation actions must not disrupt existing application traffic and must be audit-compliant. Which two of the following options should the Solutions Architect recommend to automate drift detection and remediation while maintaining operational stability? (Select TWO.)

Select all that apply

Implement AWS Config rules to monitor security group configurations, and associate an AWS Systems Manager Automation runbook to automatically revert unauthorized rule changes.

Use AWS CloudFormation drift detection on a scheduled basis via Amazon EventBridge, and configure notifications to alert administrators to reconcile legitimate configuration changes via stack updates.

Configure AWS CloudFormation to perform an automatic rolling update deployment of the stack whenever drift is detected, ensuring immediate restoration of the desired state with minimal downtime.

Configure AWS Systems Manager State Manager to execute a script that directly modifies the running EC2 instances and security groups in the live environment to match the target configuration, bypassing updates to the CloudFormation template.

Attach a Service Control Policy (SCP) at the Organizational Unit (OU) level that explicitly permits AWS Config and Systems Manager to modify security groups, assuming this grants the necessary execution permissions across all member accounts without local IAM policies.

Show answer & explanation

Answer: Implement AWS Config rules to monitor security group configurations, and associate an AWS Systems Manager Automation runbook to automatically revert unauthorized rule changes.; Use AWS CloudFormation drift detection on a scheduled basis via Amazon EventBridge, and configure notifications to alert administrators to reconcile legitimate configuration changes via stack updates.

Answer

The correct options are: implementing AWS Config rules paired with Systems Manager Automation runbooks to revert changes, and utilizing scheduled AWS CloudFormation drift detection to alert administrators to reconcile legitimate modifications via stack updates.

Implementing AWS Config rules paired with Systems Manager Automation runbooks allows for non-disruptive, automated detection and remediation of specific resources like security groups. Furthermore, setting up scheduled CloudFormation drift detection ensures that any changes to managed stacks are identified, allowing administrators to reconcile them through proper template updates instead of out-of-band manual changes.

Step-by-Step Solution

Analyze the drift detection requirements for CloudFormation-managed resources.

Identify that manual resource modifications bypass the CloudFormation control plane, and configuration drift must be resolved via template updates to prevent future deployment failures.

Standard practice dictates that resources managed by CloudFormation should only be modified through the CloudFormation template to maintain state consistency.

Evaluate mechanisms for automated configuration compliance and remediation.

Determine that AWS Config rules can continuously evaluate resources (such as security groups) and trigger Systems Manager Automation runbooks to safely revert unauthorized changes.

AWS Config integrates natively with Systems Manager Automation to provide automated, resource-level compliance remediation.

Design the permissions boundary and execution roles required for remediation.

Define local IAM roles inside member accounts to delegate permissions to the remediation services, recognizing that SCPs only restrict rather than grant permissions.

SCPs act as guardrails and do not replace IAM policies for granting access to AWS services.

Key Concept

Automating configuration drift detection and remediation using AWS Config, AWS Systems Manager, and AWS CloudFormation while maintaining stack integrity.

Question 349Question →

A company is planning to migrate an on-premises Microsoft SQL Server database to an Amazon Aurora MySQL-Compatible Edition DB cluster. The migration must support ongoing replication to minimize cutover downtime. The source database contains several tables with VARBINARY(MAX) columns storing documents, where some individual records exceed 2 MB in size. A Solutions Architect is setting up AWS Schema Conversion Tool (AWS SCT) and AWS Database Migration Service (AWS DMS) to execute this migration.

Which TWO configurations must the Solutions Architect implement to ensure successful data replication with minimal downtime? (Select TWO.)

Select all that apply

Enable Microsoft Change Data Capture (MS-CDC) on the source SQL Server database and the tables selected for migration.

Configure the AWS DMS replication task to use Limited LOB mode and set the Max LOB size parameter to at least 4096 KB.

Configure the source SQL Server endpoint in AWS DMS to read directly from active transaction logs without enabling database-level MS-CDC.

Configure the AWS DMS replication task to use Full LOB mode with inline LOBs enabled to replicate all VARBINARY(MAX) columns.

Install the AWS SCT agent on the replication instance to handle the translation of LOB data types dynamically during the replication phase.

Show answer & explanation

Answer: Enable Microsoft Change Data Capture (MS-CDC) on the source SQL Server database and the tables selected for migration.; Configure the AWS DMS replication task to use Limited LOB mode and set the Max LOB size parameter to at least 4096 KB.

Answer

Enable Microsoft Change Data Capture (MS-CDC) on the source SQL Server database and the tables selected for migration, and configure the AWS DMS replication task to use Limited LOB mode with the Max LOB size parameter set to at least 4096 KB.

To support continuous replication (CDC) from Microsoft SQL Server, Microsoft Change Data Capture (MS-CDC) must be enabled on the source database and tables so AWS DMS can read ongoing changes from the transaction logs. Additionally, to handle Large Objects (LOBs) such as documents in VARBINARY(MAX) columns that exceed 2 MB, the AWS DMS task should be configured with Limited LOB mode and a Max LOB size set to at least 4096 KB to accommodate the largest files without truncation or task failure, while preserving replication performance.

Step-by-Step Solution

Enable Microsoft Change Data Capture (MS-CDC) on the source database.

Ongoing changes can be tracked in the SQL Server transaction logs.

AWS DMS requires MS-CDC to capture ongoing changes (Change Data Capture) from a SQL Server source database.

Configure LOB settings in the AWS DMS replication task.

Limited LOB mode is selected with a Max LOB size of 4096 KB.

Since the source database contains LOB data (documents in VARBINARY(MAX) columns) that exceed 2 MB (2048 KB), the Max LOB size must be set higher than the largest LOB (e.g., 4096 KB) to prevent truncation errors while maintaining optimal performance.

Key Concept

Continuous replication with AWS DMS requires enabling source-side logging (MS-CDC for SQL Server) and configuring task parameters (such as LOB settings) to handle large data types appropriately.

Question 350Question →

An enterprise is designing a new multi-account network topology in the us-east-1 region. The architecture requires connecting three spoke VPCs (vpc-spoke-a in Account A, vpc-spoke-b in Account B, and vpc-spoke-c in Account C) to a central egress VPC (vpc-egress-shared) in a Shared Services Account to enable outbound internet access and shared DNS resolution. The spoke VPCs contain private workloads that must resolve a private hosted zone (PHZ) corp.internal hosted in the Shared Services Account. The design must be highly available across two Availability Zones and minimize administrative overhead. Which of the following actions should the Solutions Architect perform to implement this architecture? (Select TWO.)

Select all that apply

Deploy an AWS Transit Gateway named tgw-central-egress in the Shared Services account, share it with the spoke accounts using AWS Resource Access Manager, and attach the spoke and egress VPCs. In the egress VPC vpc-egress-shared, deploy a NAT Gateway in each of the two Availability Zones, and configure the spoke VPC route tables to route all outbound traffic (0.0.0.0/0) to the Transit Gateway.

For the private hosted zone corp.internal in the Shared Services account, create a VPC association authorization for each spoke VPC (vpc-spoke-a, vpc-spoke-b, and vpc-spoke-c), and then associate the hosted zone with the spoke VPCs using the AWS CLI, SDK, or API.

Deploy a single NAT Gateway in one Availability Zone of the egress VPC vpc-egress-shared, and configure all spoke VPC route tables to route outbound internet traffic to this NAT Gateway via the Transit Gateway to minimize operational costs.

Establish VPC Peering connections between each spoke VPC (vpc-spoke-a, vpc-spoke-b, vpc-spoke-c) and the egress VPC vpc-egress-shared, and configure the spoke route tables to route 0.0.0.0/0 traffic through the peering connections to the NAT Gateways.

Associate the Private Hosted Zone corp.internal with the spoke VPCs (vpc-spoke-a, vpc-spoke-b, and vpc-spoke-c) directly from the Route 53 console within Accounts A, B, and C to enable cross-account DNS resolution.

Show answer & explanation

Answer: Deploy an AWS Transit Gateway named tgw-central-egress in the Shared Services account, share it with the spoke accounts using AWS Resource Access Manager, and attach the spoke and egress VPCs. In the egress VPC vpc-egress-shared, deploy a NAT Gateway in each of the two Availability Zones, and configure the spoke VPC route tables to route all outbound traffic (0.0.0.0/0) to the Transit Gateway.; For the private hosted zone corp.internal in the Shared Services account, create a VPC association authorization for each spoke VPC (vpc-spoke-a, vpc-spoke-b, and vpc-spoke-c), and then associate the hosted zone with the spoke VPCs using the AWS CLI, SDK, or API.

Answer

Deploying a shared AWS Transit Gateway with multi-AZ NAT Gateways in the egress VPC, and establishing cross-account Private Hosted Zone associations using VPC association authorizations.

The correct solutions involve configuring an AWS Transit Gateway to act as a hub for transitive routing and setting up cross-account VPC associations for the Private Hosted Zone. By sharing the Transit Gateway via AWS Resource Access Manager and attaching the spoke VPCs and the central egress VPC, all spoke VPCs can route internet-bound traffic to the egress VPC. Deploying NAT Gateways in multiple Availability Zones in the egress VPC ensures high availability. To resolve DNS queries for the private hosted zone in the spoke VPCs, a VPC association authorization must be created in the Shared Services account, allowing the spoke VPCs to be associated with the hosted zone.

Step-by-Step Solution

Deploy and share the AWS Transit Gateway using AWS Resource Access Manager (RAM).

Spoke VPCs and the central egress VPC can attach to the Transit Gateway, enabling centralized connectivity.

This establishes the physical and logical hub-and-spoke networking foundation for transitive traffic.

Deploy NAT Gateways in multiple Availability Zones of the central egress VPC and update route tables.

Outbound internet traffic is routed from spokes through the Transit Gateway to the NAT Gateways in a highly available manner.

This satisfies the requirement for resilient internet egress across two Availability Zones.

Create VPC association authorizations for the Private Hosted Zone (PHZ) and associate the spoke VPCs.

The spoke VPCs are associated with the PHZ in the Shared Services account.

This allows workloads in spoke VPCs to resolve DNS queries for the corp.internal domain.

Key Concept

Designing multi-account network architectures with centralized egress, resilient routing, and cross-account DNS resolution.

Question 351Question →

A company has a multi-VPC architecture in the `us-east-1` Region. VPC A contains a fleet of EC2 instances in three Availability Zones processing telemetry data. These instances stream $300\text{ TB}$ of data monthly to a centralized analytics platform running in VPC B (also in `us-east-1` across three Availability Zones). Currently, both VPCs are attached to an AWS Transit Gateway, and all traffic between VPC A and VPC B is routed through the Transit Gateway. The company wants to reduce the data transfer costs for this traffic without sacrificing performance or security. Which solution is the most cost-effective way to achieve this goal?

Deploy a single NAT Gateway in one Availability Zone of VPC A, and configure the VPC A route tables to route all traffic destined for VPC B through this NAT Gateway. Configure the Application Load Balancer in VPC B to have public IP addresses and accept traffic over the internet.

Keep the AWS Transit Gateway connection but enable appliance mode on the Transit Gateway VPC attachments for both VPCs. Implement Transit Gateway Connect peers using Generic Routing Encapsulation (GRE) tunnels to compress the data before transmission.

Establish a VPC Peering connection between VPC A and VPC B. Update the route tables in both VPCs to route the traffic between VPC A and VPC B through the peering connection. Associate the Route 53 Private Hosted Zone for the ingestion service in VPC B with VPC A to enable DNS resolution over the peered connection.

Establish a VPC Peering connection between VPC A and VPC B. Update the route tables in both VPCs to route the traffic between VPC A and VPC B through the peering connection. Create a Route 53 Private Hosted Zone for the ingestion service in VPC B, but do not associate it with VPC A, relying instead on standard public DNS resolution.

Show answer & explanation

Answer: Establish a VPC Peering connection between VPC A and VPC B. Update the route tables in both VPCs to route the traffic between VPC A and VPC B through the peering connection. Associate the Route 53 Private Hosted Zone for the ingestion service in VPC B with VPC A to enable DNS resolution over the peered connection.

Answer

Establish a VPC Peering connection between VPC A and VPC B, update the route tables to route traffic through the peering connection, and associate the Route 53 Private Hosted Zone in VPC B with VPC A to enable DNS resolution.

Establishing a VPC Peering connection is the most cost-effective solution because VPC Peering does not charge any data processing fees. For

300\text{ TB}

of data transfer monthly, this eliminates the $0.02 per GB data processing charge imposed by AWS Transit Gateway. Furthermore, data transfer over VPC Peering within the same Region is free if it remains within the same Availability Zone. Associating the Route 53 Private Hosted Zone in VPC B with VPC A allows the instances in VPC A to resolve the private DNS names of the ingestion service.

Step-by-Step Solution

Analyze the current data transfer costs using AWS Transit Gateway.

The current architecture incurs a data processing fee of

0.02 per GB for all traffic traversing the Transit Gateway. For

300\text{ TB}

(

307,200\text{ GB}

) of monthly data transfer, this amounts to

307,200 \times 0.02 = 6,144$ USD per month in data processing fees alone.

To establish a cost baseline and identify the primary cost driver that needs to be minimized or eliminated.

Evaluate alternative regional routing options to reduce data processing charges.

Establish a VPC Peering connection between VPC A and VPC B. Unlike Transit Gateway or Interface VPC Endpoints (which charge

0.01 per GB), VPC Peering has

0$ data processing fees. Data transfer over VPC Peering is free when traffic remains within the same Availability Zone.

VPC Peering is the most cost-effective connection type for high-volume data transfer between two VPCs in the same Region.

Configure DNS resolution across the peered VPCs.

Associate the Route 53 Private Hosted Zone in VPC B with VPC A.

Instances in VPC A must be able to resolve the private DNS hostnames of the ingestion service in VPC B. Without this association, DNS resolution will fail, preventing connectivity even if routing is established.

Key Concept

VPC Peering vs. Transit Gateway costs and Route 53 Private Hosted Zone multi-VPC association

Estimated Time:3m 0s

Question 352Question →

A solutions architect is planning the migration of an on-premises MySQL database to an Amazon Aurora MySQL-Compatible Edition DB cluster. The migration must minimize application downtime, so the architect decides to use AWS Database Migration Service (AWS DMS) with a Full Load plus Ongoing Replication (CDC) task. The source database is highly active. During testing, the CDC replication task fails shortly after starting because updates and deletes on the source cannot be fully resolved by the replication task. Which configuration must be applied to the source MySQL database to resolve this issue and support continuous replication?

Configure the source database to use ROW-based binary logging format and set the binary log row image parameter (binlog_row_image) to FULL.

Configure the source database to use STATEMENT-based binary logging and set the binary log checksum parameter to CRC32.

Configure the source database to use MIXED-based binary logging and enable Global Transaction Identifiers (GTIDs) for replication.

Configure the source database to use ROW-based binary logging and call the mysql.rds_set_configuration procedure to set the binary log retention hours to 24.

Show answer & explanation

Answer: Configure the source database to use ROW-based binary logging format and set the binary log row image parameter (binlog_row_image) to FULL.

Answer

Configure the source database to use ROW-based binary logging format and set the binary log row image parameter (binlog_row_image) to FULL.

Configuring the source MySQL database to use ROW-based binary logging format (`binlog_format = ROW`) and setting the binary log row image parameter (`binlog_row_image = FULL`) is a mandatory prerequisite for AWS DMS Change Data Capture (CDC) from a MySQL source. This ensures that the binary logs contain complete information about before and after states for update and delete events, allowing the DMS replication task to apply the changes to the target database.

Step-by-Step Solution

Analyze the failure mode of the AWS DMS CDC task.

The failure is related to updates and deletes on the source database not being fully resolvable by the replication task.

AWS DMS needs to capture both the before and after states of rows to replicate updates and deletes correctly.

Evaluate the database logging format requirements for AWS DMS CDC.

DMS requires ROW-based binary logging (`binlog_format = ROW`). STATEMENT or MIXED formats do not provide the necessary row-level changes.

This filters out options involving STATEMENT-based or MIXED-based logging.

Verify row image requirements and database environment constraints.

Setting `binlog_row_image = FULL` ensures that all columns are logged, which resolves issues with missing column data during updates. The on-premises constraint makes the RDS-specific procedure call invalid.

This confirms that row image configuration is the direct solution and eliminates the RDS-specific management procedure.

Key Concept

AWS DMS MySQL Source CDC Prerequisites

Question 353Question →

A retail platform is launching a high-profile limited-edition sneaker release. Traffic is projected to jump instantly from $800$ requests per second to over $120,000$ requests per second within 60 seconds of the launch. The platform architecture consists of an Application Load Balancer (ALB) routing traffic to an Auto Scaling group of Amazon EC2 instances. The database tier is an Amazon RDS for PostgreSQL Multi-AZ DB instance. The primary performance bottleneck during the launch is retrieving product availability status. Which configuration should the Solutions Architect implement to scale the system and maintain low latency during the launch?

Submit a request to AWS Support to pre-warm the Application Load Balancer to the expected throughput, and implement Amazon ElastiCache for Redis to cache and serve the product availability queries.

Configure the Application Load Balancer with target tracking scaling policies to handle the traffic surge, and deploy Amazon RDS Read Replicas to offload product availability queries from the primary DB instance.

Submit a request to AWS Support to pre-warm the Application Load Balancer to the expected throughput, and configure the application to direct product availability read queries to the RDS standby DB instance in the secondary Availability Zone.

Submit a request to AWS Support to pre-warm the Application Load Balancer to the expected throughput, and deploy an Amazon ElastiCache for Memcached cluster with Multi-AZ replication enabled to cache product availability queries.

Show answer & explanation

Answer: Submit a request to AWS Support to pre-warm the Application Load Balancer to the expected throughput, and implement Amazon ElastiCache for Redis to cache and serve the product availability queries.

Answer

Request AWS Support to pre-warm the Application Load Balancer to the expected capacity, and cache product availability queries using Amazon ElastiCache for Redis.

The correct answer combines requesting ELB pre-warming from AWS Support with deploying Amazon ElastiCache for Redis. Pre-warming is required because standard ALB scaling cannot keep up with an instantaneous jump from

800

120,000

requests per second. ElastiCache for Redis successfully offloads the product availability queries from the RDS DB instance, providing high availability through Multi-AZ replication and sub-millisecond query response times.

Step-by-Step Solution

Evaluate the load balancer scaling requirements for flash traffic.

The traffic scales from

800

to over

120,000

requests per second in 60 seconds. This sudden volume requires ELB pre-warming because the default scaling rate of an Application Load Balancer cannot keep up with this rate of acceleration.

To prevent HTTP 502/504 gateways errors caused by the load balancer's inability to scale fast enough to meet instant demand.

Determine the optimal database read scaling and caching approach.

Amazon RDS standby instances cannot serve read traffic. While RDS Read Replicas can scale reads, ElastiCache for Redis is better suited to handle the highly repetitive queries for product availability at this extreme scale with sub-millisecond latencies.

To offload high-volume read traffic from the primary database engine and optimize response times.

Validate replication requirements for the caching layer.

ElastiCache for Redis supports Multi-AZ replication, ensuring high availability during the critical launch event, whereas ElastiCache for Memcached does not.

To ensure resiliency and scalability under high load.

Key Concept

Handling sudden flash traffic surges requires pre-warming the load balancer and offloading read traffic from the primary database using an appropriate caching layer like Amazon ElastiCache for Redis.

Question 354Question →

An enterprise manages a multi-account environment under AWS Organizations with consolidated billing enabled. In member Account A, the production environment runs a containerized microservice on Amazon ECS on AWS Fargate that scales dynamically throughout the day, and several AWS Lambda functions that process real-time streaming data. In member Account B, a legacy application runs on Amazon EC2 $m6i.large$ instances 24/7 with a constant baseline CPU utilization of $80\%$ . The solutions architect needs to optimize resource costs for these workloads while maximizing the savings rate. Which two options represent the most cost-effective and architecturally sound actions to achieve this objective?

Select all that apply

Purchase Compute Savings Plans in the payer account of the organization to cover the Amazon ECS on AWS Fargate tasks and AWS Lambda functions.

Purchase EC2 Instance Savings Plans in Account B for the

m6i

instance family in the target AWS Region to cover the legacy application servers.

Purchase EC2 Instance Savings Plans in the payer account to cover the dynamically scaling Amazon ECS on AWS Fargate tasks and AWS Lambda functions.

Use AWS Resource Access Manager (RAM) to share the Amazon EC2 instances in Account B with the payer account, and purchase EC2 Instance Savings Plans in the payer account.

Consolidate the outbound internet traffic from both Account A and Account B through a single NAT Gateway in Account B to minimize hourly NAT charges.

Show answer & explanation

Answer: Purchase Compute Savings Plans in the payer account of the organization to cover the Amazon ECS on AWS Fargate tasks and AWS Lambda functions.; Purchase EC2 Instance Savings Plans in Account B for the $m6i$ instance family in the target AWS Region to cover the legacy application servers.

Answer

The most cost-effective and architecturally sound actions are to purchase Compute Savings Plans in the payer account to cover the AWS Fargate and AWS Lambda workloads, and to purchase EC2 Instance Savings Plans in Account B for the

m6i

instance family in the target AWS Region to cover the legacy application servers.

Purchasing Compute Savings Plans in the payer account allows the discount to automatically apply to the dynamically scaling ECS Fargate tasks and Lambda functions in Account A. Purchasing EC2 Instance Savings Plans in Account B for the

m6i

instance family provides the maximum discount for the steady-state, 24/7 legacy EC2 instances. Buying them in the specific member account ensures the local instances consume the commitment first before any excess is shared.

Step-by-Step Solution

Analyze the workload characteristics of Account A and Account B.

Account A contains dynamically scaling Amazon ECS on AWS Fargate tasks and AWS Lambda functions. Account B contains steady-state Amazon EC2

m6i.large

instances running 24/7.

Understanding the execution model (serverless/dynamic vs. steady-state EC2) is necessary to map them to the correct Savings Plan type.

Select the appropriate Savings Plan type for Account A's serverless and containerized workloads.

Compute Savings Plans must be selected because EC2 Instance Savings Plans do not cover AWS Fargate or AWS Lambda.

Compute Savings Plans offer the flexibility needed for dynamic workloads and cover EC2, Fargate, and Lambda.

Select the appropriate Savings Plan type for Account B's steady-state EC2 workloads.

EC2 Instance Savings Plans for the

m6i

instance family in the target AWS Region must be selected.

EC2 Instance Savings Plans offer the deepest discounts (up to

72\%

) compared to Compute Savings Plans (up to

66\%

) for steady-state workloads that do not change instance families or regions.

Key Concept

Optimizing compute costs by combining Compute Savings Plans for dynamic, serverless workloads with EC2 Instance Savings Plans for steady-state, family-specific EC2 instances across a multi-account organization.

Question 355Question →

A solutions architect is planning the migration of an on-premises IBM Db2 database to an Amazon Aurora PostgreSQL-Compatible Edition database cluster. The architect has already converted the schema using the AWS Schema Conversion Tool (SCT) and applied it to the target database, which includes custom indexes, triggers, and foreign keys. The architect is now configuring an AWS Database Migration Service (DMS) replication task to perform a full load followed by continuous replication using Change Data Capture (CDC). Which combination of DMS task configuration and source database settings must the architect apply to ensure the SCT-converted schema is preserved and CDC functions correctly?

Configure the DMS task target table preparation mode to 'Truncate', enable database-level archive logging on the source Db2 database, and enable data capture changes for the tables selected for replication.

Configure the DMS task target table preparation mode to 'Drop tables on target', and rely on AWS DMS to automatically recreate the table structures and indexes during the full load phase.

Configure the DMS task target table preparation mode to 'Truncate', and use the default Db2 circular logging configuration to allow AWS DMS to read change logs without enabling additional table-level attributes.

Configure the DMS task target table preparation mode to 'Do nothing', and classify the migration as a Replatforming strategy where DMS dynamically translates incompatible Db2 SQL queries during the CDC replication phase.

Show answer & explanation

Answer: Configure the DMS task target table preparation mode to 'Truncate', enable database-level archive logging on the source Db2 database, and enable data capture changes for the tables selected for replication.

Answer

Selecting the 'Truncate' option for target table preparation clears the data from the target tables while keeping the pre-created schema structures, indexes, constraints, and triggers intact. For ongoing CDC replication from an IBM Db2 database, archive logging must be enabled (circular logging is insufficient for CDC) and the 'DATA CAPTURE CHANGES' attribute must be enabled on the source tables to allow AWS DMS to capture data changes.

Step-by-Step Solution

Select the correct DMS target table preparation mode.

Choosing 'Truncate' instead of 'Drop tables on target' preserves the schema structure, indexes, and keys created by the AWS Schema Conversion Tool (SCT).

If the table preparation mode is set to 'Drop tables on target', DMS will recreate the tables with only basic attributes, wiping out the optimized index configurations and database triggers generated by SCT.

Configure Db2 database-level logging settings.

Enable archival logging instead of the default circular logging on the source Db2 database.

AWS DMS requires transaction logs to be archived so it can read changes asynchronously. Circular logging overwrites logs quickly, which causes replication to fail when there is any lag.

Enable table-level logging attributes in the source database.

Run the SQL command to enable DATA CAPTURE CHANGES for the replicated tables.

Without this setting, the Db2 transaction logs will not contain the full before-and-after image data necessary for AWS DMS to parse and construct replication transactions during the CDC phase.

Key Concept

Database Migration and Schema Conversion using DMS and SCT

Estimated Time:2m 0s

Question 356Question →

An enterprise manages a multi-account environment under AWS Organizations with consolidated billing enabled. The workload is distributed as follows:
- Member Account A runs a containerized web application on Amazon ECS on AWS Fargate and several Amazon EC2 m6i instances.
- Member Account B runs event-driven processing pipelines using AWS Lambda and several Amazon EC2 c6i instances.

A Solutions Architect needs to implement a cost-optimization strategy to reduce compute costs while maintaining high availability and minimizing operational overhead. Which two actions should the Solutions Architect recommend?

Select all that apply

Purchase a Compute Savings Plan at the AWS Organizations management account level to apply flexible savings across the EC2 instances, ECS Fargate tasks, and Lambda functions.

Use AWS Compute Optimizer to evaluate the utilization metrics of the ECS Fargate tasks and EC2 instances, and then downsize the over-provisioned tasks and instances to match their actual resource demands.

Purchase an EC2 Instance Savings Plan for the m6i instance family to maximize discount rates for both the EC2 instances and the ECS Fargate tasks in the member accounts.

Share the compute cost savings by using AWS Resource Access Manager (RAM) to distribute the Savings Plan benefits from the management account to the individual member accounts.

Deploy a single central NAT Gateway in a shared services VPC and route all private subnet traffic from both member accounts through it to eliminate multi-AZ NAT Gateway hourly costs.

Show answer & explanation

Answer: Purchase a Compute Savings Plan at the AWS Organizations management account level to apply flexible savings across the EC2 instances, ECS Fargate tasks, and Lambda functions.; Use AWS Compute Optimizer to evaluate the utilization metrics of the ECS Fargate tasks and EC2 instances, and then downsize the over-provisioned tasks and instances to match their actual resource demands.

Answer

Purchasing a Compute Savings Plan at the AWS Organizations management account level and using AWS Compute Optimizer to identify and resize over-provisioned ECS Fargate tasks and EC2 instances.

Purchasing a Compute Savings Plan at the management account level provides the necessary coverage for a mixed workload of EC2, Fargate, and Lambda across all member accounts. Using AWS Compute Optimizer allows the team to right-size the ECS Fargate tasks and EC2 instances based on actual usage history before making a financial commitment, achieving the most cost-effective and operationally efficient configuration.

Step-by-Step Solution

Analyze resource utilization and right-size the existing compute workloads.

AWS Compute Optimizer recommendations are applied to ECS Fargate tasks and EC2 instances, sizing them to meet actual demands.

Right-sizing workloads prior to committing to any Savings Plans ensures the organization does not over-commit financial resources for excess capacity.

Determine the appropriate Savings Plan type to cover the hybrid compute environment.

Compute Savings Plans are selected because they cover EC2 instances, AWS Fargate, and AWS Lambda across all regions and families.

EC2 Instance Savings Plans are limited to specific EC2 families and regions, and do not apply to Fargate or Lambda.

Purchase the Savings Plan from the AWS Organizations management account.

The discount benefits automatically float and apply to eligible compute usage across all member accounts via consolidated billing.

Management account purchases allow sharing benefits across consolidated accounts natively without requiring additional sharing tools like Resource Access Manager.

Key Concept

Optimizing compute resource costs in a multi-account environment through AWS Compute Optimizer and Compute Savings Plans.

Estimated Time:2m 0s

Question 357Question →

A healthcare provider is planning to migrate its legacy patient portal and billing system from an on-premises VMware vCenter environment to AWS. The security compliance policy strictly prohibits the installation of any software agents on the virtual machines (VMs) hosting the billing system due to regulatory constraints. However, the legacy patient portal runs on physical bare-metal Linux servers where network dependency mapping is required to identify all upstream and downstream database connections. The architect wants to centralize the discovery and track the migration status in a single dashboard.

Which of the following approaches should the Solutions Architect implement? (Select TWO.)

Select all that apply

Deploy the AWS Application Discovery Agentless Collector as an Open Virtualization Archive (OVA) template on VMware vCenter to discover the billing system VMs.

Install the AWS Application Discovery Agent on the physical Linux servers hosting the patient portal to collect network dependencies.

Install the AWS Application Discovery Agent on the billing system VMs to capture detailed disk configuration and OS process details.

Deploy the AWS Application Discovery Agentless Collector on the physical Linux servers to perform agentless discovery of the patient portal database dependencies.

Show answer & explanation

Answer: Deploy the AWS Application Discovery Agentless Collector as an Open Virtualization Archive (OVA) template on VMware vCenter to discover the billing system VMs.; Install the AWS Application Discovery Agent on the physical Linux servers hosting the patient portal to collect network dependencies.

Answer

Deploy the AWS Application Discovery Agentless Collector as an OVA template on VMware vCenter to discover the billing system VMs, and install the AWS Application Discovery Agent on the physical Linux servers hosting the patient portal.

The correct approach is to deploy the AWS Application Discovery Agentless Collector as an OVA template on VMware vCenter, and install the AWS Application Discovery Agent on the physical Linux servers. The Agentless Collector runs at the vCenter hypervisor level, which retrieves configuration and utilization data for the billing VMs without installing any software on the guest operating systems, thereby complying with security rules. The Application Discovery Agent is required on the physical servers because they are bare-metal systems, and only the agent can capture the necessary network dependency mappings for the patient portal.

Step-by-Step Solution

Analyze the discovery requirements and constraints for the billing system VMs.

The security policy forbids agent installation on the billing VMs, and they run on VMware vCenter. Therefore, the VMware-compatible AWS Application Discovery Agentless Collector must be used.

The Agentless Collector gathers configuration and performance metrics at the hypervisor level without requiring guest operating system access or agent installation.

Analyze the discovery requirements for the patient portal on physical servers.

The portal runs on physical bare-metal servers (not VMware) and requires network dependency mapping. Therefore, the agentless collector cannot be used, and the AWS Application Discovery Agent must be installed on these servers.

The Application Discovery Agent is required for physical servers and is the only mechanism that can capture TCP/UDP port connections and network dependencies.

Select the correct combination of options.

The solution requires deploying the Agentless Collector as an OVA on vCenter and installing the Agent on the physical Linux servers.

This dual approach respects both the VM security policies and the requirement to map network dependencies on the physical servers.

Key Concept

Selecting the appropriate AWS Application Discovery Service tool (Agent-based vs. Agentless Collector) based on physical vs. virtual infrastructure and compliance constraints.

Question 358Question →

An enterprise manages its multi-account AWS environment using AWS Organizations. The central DevOps team uses AWS CloudFormation StackSets to deploy and update application infrastructure, including security groups and Amazon S3 buckets, across multiple member accounts. The deployment artifacts are stored in a central S3 bucket and encrypted using a Customer Managed Key (CMK) in the central DevOps account.

Recently, several stack updates failed because local administrators in the member accounts had manually modified security group rules and S3 bucket policies, causing configuration drift. Additionally, the member accounts are unable to access the deployment artifacts due to KMS decryption failures.

Which two actions should the Solutions Architect take to automate drift remediation and resolve the cross-account decryption failures? (Select two.)

Select all that apply

Update the key policy of the Customer Managed Key in the central DevOps account to grant decrypt permissions (kms:Decrypt) to the IAM execution roles in the member accounts, and ensure these roles also have local IAM policies allowing the KMS decrypt action.

Deploy AWS Config rules across the member accounts to monitor security groups and S3 bucket configurations, and configure AWS Systems Manager Automation as a remediation action to automatically restore drifted resources to their compliant configurations.

Enable the AWS-managed KMS key (aws/s3) in the central DevOps account to encrypt the artifacts, and modify its key policy to delegate cross-account decrypt permissions to the IAM execution roles in the member accounts.

Enable automatic drift remediation directly within the AWS CloudFormation StackSet configuration parameters to automatically detect configuration changes and perform a stack update to overwrite manual modifications in target accounts.

Attach a Service Control Policy (SCP) to the member account Organizational Units (OUs) that grants the kms:Decrypt permission for the central DevOps account's KMS key, eliminating the need for local IAM policy configurations in the member accounts.

Show answer & explanation

Answer: Update the key policy of the Customer Managed Key in the central DevOps account to grant decrypt permissions (kms:Decrypt) to the IAM execution roles in the member accounts, and ensure these roles also have local IAM policies allowing the KMS decrypt action.; Deploy AWS Config rules across the member accounts to monitor security groups and S3 bucket configurations, and configure AWS Systems Manager Automation as a remediation action to automatically restore drifted resources to their compliant configurations.

Answer

Update the Customer Managed Key policy in the central DevOps account to grant decrypt permissions to the member accounts' IAM roles and configure matching local IAM policies, and deploy AWS Config rules with AWS Systems Manager Automation to automatically remediate resource configuration drift.

For cross-account KMS decryption, the Customer Managed Key policy in the owning account must delegate permissions to the external accounts, and the IAM policies in those external accounts must grant the roles permission to call the KMS decrypt action. For drift remediation, deploying AWS Config rules combined with AWS Systems Manager Automation allows the environment to continuously detect unauthorized configuration changes and automatically execute a remediation runbook to restore resources to their defined configurations, ensuring smooth deployment pipeline operations.

Step-by-Step Solution

Configure cross-account KMS access.

The key policy of the Customer Managed Key (CMK) in the central DevOps account is updated to include the member accounts' IAM execution roles as authorized principals for the kms:Decrypt action, and local IAM policies in the member accounts are configured to allow those roles to perform the decrypt operation.

This establishes the necessary trust relationship and permissions for cross-account resource access, which is required because AWS-managed keys cannot be shared cross-account.

Implement automated drift detection and remediation.

AWS Config rules are deployed to monitor resource configurations (security groups and S3 buckets). When drift is detected, AWS Config automatically triggers an AWS Systems Manager Automation runbook that applies the compliant configuration.

This automates the remediation of unauthorized configuration changes, preventing future stack update failures due to configuration drift.

Key Concept

Cross-account KMS key sharing requires both key policy delegation and local IAM permissions, while configuration drift is best managed using AWS Config combined with AWS Systems Manager Automation for remediation.

Estimated Time:3m 0s

Question 359Question →

A medical healthcare provider hosts a critical real-time telemedicine and remote patient monitoring platform on Amazon EC2 instances. The instances are deployed within an Auto Scaling group (ASG) across three Availability Zones ( $AZ\text{-}A$ , $AZ\text{-}B$ , and $AZ\text{-}C$ ) in private subnets. Outbound internet access is required for downloading updates and communicating with third-party medical API endpoints. A single Application Load Balancer (ALB) distributes incoming traffic to the EC2 instances.

During seasonal scheduling windows, the platform experiences sudden, near-instantaneous traffic spikes of up to $25\text{ times}$ the baseline volume within a $3\text{-minute}$ window. During these surges, the following issues are observed:
- The ALB drops a significant portion of incoming requests during the initial minutes of the surge.
- The EC2 instances take approximately $10\text{-minutes}$ to bootstrap (install medical compliance agents and load local cache files). During this startup period, the ASG continues to launch additional unnecessary instances, leading to extreme over-provisioning.
- A transient outage in $AZ\text{-}A$ disabled its NAT Gateway, which subsequently caused all outbound API calls from instances in $AZ\text{-}B$ and $AZ\text{-}C$ to fail because their route tables directed all internet-bound traffic through the NAT Gateway in $AZ\text{-}A$ .

Which two actions should a Solutions Architect implement to resolve these scaling and reliability issues? (Select TWO.)

Select all that apply

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

Create a custom Amazon Machine Image (AMI) containing the compliance agents and pre-loaded cache files, and configure an Auto Scaling group warm pool with instances in the Stopped state to serve as pre-initialized capacity.

Decrease the default cooldown period of the Auto Scaling group to 60 seconds to allow the scaling policy to quickly launch new instances in response to the sudden CPU utilization spikes.

Configure a single NAT Gateway in a shared services VPC, and establish VPC peering connections from the application VPC to route all outbound traffic through the shared NAT Gateway to ensure centralized redundancy.

Rely on the ALB's default elastic scaling behavior to dynamically adjust to the traffic spikes, and configure the Auto Scaling group's target tracking policy with a low CPU utilization threshold of 20% to trigger earlier scaling.

Show answer & explanation

Answer: Deploy a NAT Gateway in a public subnet in each Availability Zone, and configure the route tables of the private subnets to route outbound traffic through the NAT Gateway in their respective Availability Zone.; Create a custom Amazon Machine Image (AMI) containing the compliance agents and pre-loaded cache files, and configure an Auto Scaling group warm pool with instances in the Stopped state to serve as pre-initialized capacity.

Answer

The Solutions Architect should deploy a NAT Gateway in a public subnet in each Availability Zone and route outbound traffic locally, and create a custom AMI paired with an Auto Scaling group warm pool containing stopped instances.

Deploying a dedicated NAT Gateway per Availability Zone removes cross-AZ dependencies and prevents single points of failure for outbound traffic. Using a custom AMI with pre-installed agents and dependencies eliminates bootstrap delays, and using an Auto Scaling group warm pool with stopped instances keeps pre-initialized resources ready to launch immediately during sudden surges without causing scaling thrashing or over-provisioning.

Step-by-Step Solution

Address the outbound connectivity failure by establishing multi-AZ NAT Gateway redundancy.

Deploying a NAT Gateway in each Availability Zone and routing outbound traffic from private subnets to the local NAT Gateway prevents a single AZ outage from affecting outbound connectivity for the entire VPC.

This removes the single point of failure where all private subnets depended on a single NAT Gateway in one AZ.

Optimize the instance startup time and scaling behavior to prevent over-provisioning.

Baking compliance agents and cache files into a custom AMI reduces bootstrap latency. Using an Auto Scaling group warm pool with stopped instances maintains pre-initialized capacity that can quickly scale out when needed.

Keeping pre-initialized instances in a warm pool stops the ASG from launching excessive instances due to a long bootstrap period.

Address the ALB dropped connections by planning for scheduled flash traffic.

For expected flash traffic surges, AWS Support should be contacted to pre-warm the ALB.

The ALB's default scaling cannot keep pace with near-instantaneous 25x bursts, leading to dropped requests unless pre-warmed.

Key Concept

High availability, fault tolerance, and scaling optimization in AWS environments, specifically focusing on multi-AZ NAT Gateway redundancy, minimizing ASG bootstrapping delays using warm pools and custom AMIs, and resolving Application Load Balancer scaling limitations for sudden traffic bursts.

Question 360Question →

A company has a multi-VPC architecture in the `eu-west-1` Region. VPC A contains a fleet of Amazon EC2 instances running in private subnets that process and upload $150 \text{ TB}$ of data monthly to an Amazon S3 bucket in the same Region. VPC A is connected to a central egress VPC via an AWS Transit Gateway. Currently, all outbound traffic from VPC A, including S3 traffic, is routed through the Transit Gateway to the egress VPC, which routes the traffic to the internet through a pair of NAT Gateways. This architecture has resulted in very high data transfer and processing charges. A solutions architect must implement a solution to minimize these costs.

Which solution is the most cost-effective?

Create an Amazon S3 Gateway VPC Endpoint in VPC A. Update the route tables of the private subnets in VPC A to direct traffic destined for S3 to the S3 Gateway VPC Endpoint.

Create an Amazon S3 Gateway VPC Endpoint in the central egress VPC. Configure the Transit Gateway route tables to route all S3-destined traffic from VPC A to the central egress VPC's endpoint.

Create Amazon S3 Interface VPC Endpoints (AWS PrivateLink) in the private subnets of VPC A. Configure the EC2 instances to route S3 traffic through these interface endpoints.

Purchase Compute Savings Plans to cover the data processing and transfer charges of the Transit Gateway and the NAT Gateways in the central egress VPC.

Show answer & explanation

Answer: Create an Amazon S3 Gateway VPC Endpoint in VPC A. Update the route tables of the private subnets in VPC A to direct traffic destined for S3 to the S3 Gateway VPC Endpoint.

Answer

Create an Amazon S3 Gateway VPC Endpoint in VPC A and update the route tables of the private subnets in VPC A to direct S3 traffic to it.

Creating a Gateway VPC Endpoint for Amazon S3 directly in VPC A is the most cost-effective solution. Gateway VPC Endpoints are offered at no cost (no hourly or data processing fees). By directing S3 traffic through the gateway endpoint locally in VPC A, the traffic bypasses both the Transit Gateway and the central NAT Gateways, completely eliminating the associated processing charges for the

150 \text{ TB}

of S3 data transfer.

Step-by-Step Solution

Analyze the existing traffic path and identify cost drivers.

The upload of

150 \text{ TB}

of data monthly travels through both the Transit Gateway and the NAT Gateways, incurring high data processing charges.

Identifying the current network flow reveals which components are causing high data transfer charges.

Evaluate local VPC routing options for regional Amazon S3 traffic.

Creating an S3 Gateway VPC Endpoint in VPC A allows direct, private access to S3. Gateway VPC Endpoints do not charge hourly or data processing fees.

Using S3 Gateway VPC Endpoints is the standard best practice to eliminate data transfer charges to S3 within the same Region.

Assess transitive routing constraints of S3 Gateway VPC Endpoints.

An S3 Gateway VPC Endpoint cannot be accessed transitively across a Transit Gateway from another VPC. Therefore, the endpoint must be created locally within VPC A.

This rules out centralized S3 Gateway VPC Endpoint architectures and ensures correct VPC-local routing configurations.

Key Concept

Using Gateway VPC Endpoints to optimize data transfer costs for Amazon S3 traffic within the same AWS Region while respecting transitive routing limitations.

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