All practice questions

1964 questions

All types1,964 Multiple choice1,006 Multiple select931 Ordering27

A company is planning to migrate a highly transactional Microsoft SQL Server database located on-premises to an Amazon Aurora PostgreSQL-Compatible Edition DB cluster. The migration must be completed with minimal downtime. The source database includes several tables that do not have primary keys, as well as multiple tables containing PDF documents stored in `VARBINARY(MAX)` columns. The solutions architect is designing the replication strategy using AWS Database Migration Service (DMS) and schema conversion using the AWS Schema Conversion Tool (SCT). Which combination of actions should the solutions architect take to meet these requirements? (Select two.)

Select all that apply

Enable MS-CDC on the source SQL Server database and the tables without primary keys, and ensure the SQL Server Agent is running on the source database server.

Create two separate AWS DMS replication tasks: one for tables containing `VARBINARY(MAX)` columns configured with Limited LOB mode and a defined maximum LOB size, and another task for the remaining tables.

Enable MS-Replication on the source SQL Server database to capture Change Data Capture (CDC) modifications for the tables without primary keys.

Configure a single AWS DMS replication task using Full LOB mode for all tables, and increase the LOB chunk size parameter to match the size of the largest PDF file.

Install the AWS SCT database extraction agent on the source SQL Server instance to capture transaction log changes and stream them to the target cluster.

Show answer & explanation

Answer: Enable MS-CDC on the source SQL Server database and the tables without primary keys, and ensure the SQL Server Agent is running on the source database server.; Create two separate AWS DMS replication tasks: one for tables containing `VARBINARY(MAX)` columns configured with Limited LOB mode and a defined maximum LOB size, and another task for the remaining tables.

Answer

To perform a near-zero downtime migration of a SQL Server database containing tables without primary keys and LOB columns to Aurora PostgreSQL, enable MS-CDC on the database and tables without primary keys with SQL Server Agent running, and split the migration into two separate AWS DMS tasks: one using Limited LOB mode with a defined maximum LOB size for the tables with LOB columns, and another for the remaining tables.

The correct strategy involves enabling MS-CDC on the source SQL Server database and tables without primary keys, ensuring the SQL Server Agent is running. MS-Replication cannot support tables without primary keys. Additionally, creating two separate AWS DMS tasks—one with Limited LOB mode for tables with large LOBs and one for standard tables—prevents LOB processing bottlenecks from slowing down the entire replication stream.

Step-by-Step Solution

Address the replication of tables without primary keys by configuring MS-CDC.

MS-CDC is enabled on the SQL Server database and the tables lacking primary keys, and the SQL Server Agent is running to read the transaction logs.

AWS DMS requires MS-CDC for replication of tables without primary keys, as MS-Replication strictly requires primary keys.

Configure separate replication tasks to optimize LOB handling.

Two tasks are created: one containing tables with LOBs configured with Limited LOB mode, and another containing the remaining tables.

Splitting tables prevents the slow transfer of large LOBs from blocking or delaying replication of the rest of the database, while Limited LOB mode ensures optimal throughput.

Key Concept

Replicating SQL Server databases with tables lacking primary keys and containing LOBs requires selecting MS-CDC over MS-Replication, and separating LOB tables into a distinct task using Limited LOB mode for performance optimization.

Estimated Time:2m 30s

Question 362Question →

A financial services company is migrating its core ledger application servers from an on-premises data center to AWS using AWS Application Migration Service (MGN). The replication traffic must be routed over a dedicated AWS Direct Connect connection and must not traverse the public internet. The staging area is configured within a dedicated VPC. Which of the following configuration steps must be performed to establish secure, private data replication from the on-premises servers to the staging area? (Select TWO.)

Select all that apply

Configure the replication template to use a private IP address for replication, and ensure the staging area security groups allow inbound traffic on TCP port 1500 from the on-premises subnet range.

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

Configure the staging area security group to only allow inbound traffic on TCP port 443, as the MGN replication agent compresses and tunnels all volume blocks over HTTPS to the staging area.

Configure a Direct Connect Gateway to establish a transitive path between the on-premises data center and the staging VPC, routing all replication traffic directly through the Direct Connect Gateway without configuring a virtual private gateway or Transit Gateway.

Deploy a single NAT Gateway in the public subnet of the staging VPC's primary Availability Zone to route all replication control plane traffic, accepting that any failure of that Availability Zone will temporarily halt replication until manual failover occurs.

Show answer & explanation

Answer: Configure the replication template to use a private IP address for replication, and ensure the staging area security groups allow inbound traffic on TCP port 1500 from the on-premises subnet range.; Establish interface VPC endpoints (AWS PrivateLink) for the MGN service in the staging VPC, and ensure that the on-premises DNS resolves the MGN API endpoints to these private IP addresses.

Answer

The correct configurations are allowing inbound traffic on TCP port 1500 from the on-premises range to the staging area security groups with private IP replication enabled, and creating interface VPC endpoints for AWS Application Migration Service in the staging VPC while resolving the API endpoints via on-premises DNS.

To perform private replication using AWS Application Migration Service (MGN) without internet traversal, the replication servers must communicate over the private connection. The replication data is sent over TCP port 1500, requiring security groups to allow inbound port 1500 from on-premises sources. Additionally, the replication agent must communicate with the MGN control plane API over HTTPS (TCP port 443). Since the traffic must not traverse the internet, interface VPC endpoints (AWS PrivateLink) for MGN must be established in the staging VPC, and the on-premises DNS must be configured to resolve the MGN service endpoints to these private endpoint IPs.

Step-by-Step Solution

Identify the networking requirements for MGN replication data.

Determine that replication data is transferred over TCP port 1500, which requires the target security groups in the staging area to permit inbound traffic on TCP port 1500 from the source subnet.

Data replication in AWS Application Migration Service occurs directly from the agent to replication servers in the staging area over TCP port 1500.

Determine the control plane communication path for private migrations.

Establish interface VPC endpoints for MGN in the staging VPC and map on-premises DNS to resolve the API endpoints to these private IPs.

The MGN replication agent requires access to the MGN control plane API over HTTPS (port 443). To prevent internet routing, AWS PrivateLink interface endpoints must be used and resolved privately.

Evaluate routing and replication template configuration.

Enable private IP replication in the MGN replication template to ensure data flows over the Direct Connect connection using the private IP addresses.

Without enabling private IP replication, MGN will attempt to use public IPs for data replication, which would violate the requirement to not traverse the public internet.

Key Concept

Private infrastructure replication using AWS Application Migration Service (MGN) over Direct Connect requiring TCP port 1500 for data replication and interface VPC endpoints for control plane API.

Question 363Question →

An enterprise is planning to migrate its legacy on-premises Oracle database to an Amazon Aurora PostgreSQL-Compatible DB cluster. The database contains complex PL/SQL packages with custom functions that do not have direct equivalents in PostgreSQL. The migration must minimize downtime for the dependent applications. Which of the following represents the correct sequence of steps to successfully perform this migration while ensuring application compatibility and data consistency?

Convert the database schema and PL/SQL code using the AWS Schema Conversion Tool (SCT), apply the AWS SCT extension pack to the target Aurora PostgreSQL DB cluster, enable supplemental logging on the source Oracle database, and run an AWS DMS replication task configured for full load and Change Data Capture (CDC).

Convert the database schema and PL/SQL code using the AWS Schema Conversion Tool (SCT), apply the AWS SCT extension pack to the target Aurora PostgreSQL DB cluster, and run an AWS DMS replication task configured for full load and Change Data Capture (CDC), relying on default Oracle logging configurations to capture ongoing transactional changes.

Classify the migration as a database replatforming path, bypass the AWS Schema Conversion Tool (SCT) by running the native pg_restore utility on the target Aurora PostgreSQL DB cluster, and configure an AWS DMS replication task with Change Data Capture (CDC) to capture ongoing transactions.

Convert the database schema and PL/SQL code using the AWS Schema Conversion Tool (SCT), apply the AWS SCT extension pack to the target Aurora PostgreSQL DB cluster, configure AWS DMS to write full load data to the primary DB instance and CDC updates to the Aurora Replicas to optimize performance, and enable supplemental logging on the source database.

Show answer & explanation

Answer: Convert the database schema and PL/SQL code using the AWS Schema Conversion Tool (SCT), apply the AWS SCT extension pack to the target Aurora PostgreSQL DB cluster, enable supplemental logging on the source Oracle database, and run an AWS DMS replication task configured for full load and Change Data Capture (CDC).

Answer

The correct answer states that the schema and code must be converted using AWS SCT, the SCT extension pack applied to the target Aurora DB cluster, supplemental logging enabled on the source Oracle database, and an AWS DMS replication task run with full load and Change Data Capture (CDC).

Converting the schema and code via the AWS Schema Conversion Tool (SCT) and applying the extension pack ensures that proprietary PL/SQL functions are emulated correctly in PostgreSQL. Enabling supplemental logging on the source Oracle database is a mandatory requirement for AWS DMS to read redo and archive logs during Change Data Capture (CDC). Running a DMS task with full load and CDC ensures that the target database is fully populated and kept in sync, minimizing cutover downtime.

Step-by-Step Solution

Use AWS Schema Conversion Tool (SCT) to convert Oracle schema and PL/SQL code, then apply the generated extension pack to the target Aurora PostgreSQL cluster.

The database schema is created on the target, and custom PL/SQL functions are emulated via the extension pack SQL routines.

Ensures schema and code compatibility for the heterogeneous migration.

Enable supplemental logging on the source Oracle database.

Oracle database starts writing necessary supplemental information to the redo logs.

AWS DMS CDC requires supplemental logging to reconstruct changes from the database logs.

Create and execute an AWS DMS replication task configured for 'Full load + CDC' pointing to the primary writer endpoint of the Aurora PostgreSQL cluster.

The target database is seeded with initial data and kept continuously updated with ongoing source transactions.

Minimizes cutover downtime by keeping the target database in sync with the source.

Key Concept

Heterogeneous database migration sequence using AWS SCT and AWS DMS with Change Data Capture (CDC)

Question 364Question →

A financial technology company operates a stock portfolio analysis platform. The platform uses a single-node Amazon RDS for PostgreSQL DB instance to store user portfolio holdings and real-time stock price cache data. During periods of high market volatility, user dashboard page load times degrade significantly. Database metrics show CPU utilization at $95\%$ and write IOPS hitting disk limits due to the constant updates of stock prices. The stock price cache data requires replication across multiple Availability Zones to ensure high availability and sub-millisecond read latency, but does not need complex relational queries. The database must also scale to handle peak read queries for portfolio holdings without impacting write operations.

Which combination of actions should the Solutions Architect recommend to improve database and caching efficiency? (Select TWO.)

Select all that apply

Migrate the stock price cache data to an Amazon ElastiCache for Redis cluster with Multi-AZ enabled.

Deploy Amazon RDS Read Replicas for the PostgreSQL database and configure the application to direct dashboard read queries for portfolio holdings to the read replica endpoints.

Migrate the stock price cache data to an Amazon ElastiCache for Memcached cluster with Multi-AZ replication enabled.

Enable Multi-AZ deployment on the existing Amazon RDS for PostgreSQL DB instance and configure the application to route read queries for portfolio holdings to the standby DB instance.

Deploy an Amazon DynamoDB Accelerator (DAX) cluster in front of the Amazon RDS for PostgreSQL DB instance to cache the stock price data.

Show answer & explanation

Answer: Migrate the stock price cache data to an Amazon ElastiCache for Redis cluster with Multi-AZ enabled.; Deploy Amazon RDS Read Replicas for the PostgreSQL database and configure the application to direct dashboard read queries for portfolio holdings to the read replica endpoints.

Answer

Migrate the stock price cache data to an Amazon ElastiCache for Redis cluster with Multi-AZ enabled, and deploy Amazon RDS Read Replicas for the PostgreSQL database to offload read queries for portfolio holdings.

Migrating the stock price cache data to Amazon ElastiCache for Redis offloads high-frequency updates from the primary RDS instance, while satisfying the need for replication and low latency. Deploying RDS Read Replicas successfully offloads the read-heavy portfolio queries from the primary instance, reducing CPU usage and solving the database performance bottleneck.

Step-by-Step Solution

Analyze the database bottlenecks and workload characteristics.

Identified two issues: write IOPS limits and high CPU (

95\%

) due to a mix of write-heavy stock price updates and read-heavy portfolio queries on a single-node database.

Understanding the workload split allows us to address caching and database scaling independently.

Select a caching engine for stock price cache data requiring replication and sub-millisecond latency.

Chose Amazon ElastiCache for Redis over Memcached.

ElastiCache for Redis supports Multi-AZ replication and persistence features required for high availability, while Memcached does not.

Choose a method to scale read queries for portfolio holdings.

Deployed RDS Read Replicas and configured the application to route read traffic there.

RDS Read Replicas handle read horizontal scaling, whereas the RDS Multi-AZ standby is purely passive and cannot serve read traffic.

Key Concept

Offloading read-heavy operations using read replicas and offloading write/cache latency using replicated in-memory caching (ElastiCache for Redis).

Question 365Question →

A maritime shipping company is migrating its legacy Terminal Operating System (TOS) consisting of $8$ physical telemetry servers to AWS using AWS Application Migration Service (MGN). The on-premises data center connects to AWS via an AWS Direct Connect connection terminated on an AWS Transit Gateway in a hub VPC. Due to strict security compliance, all replication traffic must be kept entirely private and cannot traverse the public internet. The staging area VPC has no Internet Gateway or NAT Gateway configured. Which TWO configurations are required to ensure the replication agent can communicate with the AWS MGN control plane and successfully replicate block-level data? (Select TWO.)

Select all that apply

Configure the AWS MGN replication template to use private IP routing, and ensure the staging subnet security groups and network access control lists (NACLs) permit inbound TCP port 1500 traffic from the on-premises source servers.

Create Interface VPC Endpoints (AWS PrivateLink) for the AWS MGN and Amazon EC2 services in the staging VPC, and associate the Route 53 Private Hosted Zones with both the staging VPC and the Transit Gateway hub VPC, ensuring on-premises DNS can resolve these service endpoints to their private IP addresses.

Configure the AWS MGN replication template to route data over public IP addresses, and establish a Transit Gateway public peering connection to route replication traffic through a NAT Gateway in the shared services VPC.

Install the AWS MGN replication agent on the source servers and configure the replication template to route all block-level replication traffic exclusively over HTTPS on TCP port 443 directly to the MGN control plane.

Deploy AWS PrivateLink interface endpoints in the staging VPC and establish a Route 53 Private Hosted Zone for the MGN service, but limit its association strictly to the staging VPC to ensure isolation of control plane DNS queries.

Show answer & explanation

Answer: Configure the AWS MGN replication template to use private IP routing, and ensure the staging subnet security groups and network access control lists (NACLs) permit inbound TCP port 1500 traffic from the on-premises source servers.; Create Interface VPC Endpoints (AWS PrivateLink) for the AWS MGN and Amazon EC2 services in the staging VPC, and associate the Route 53 Private Hosted Zones with both the staging VPC and the Transit Gateway hub VPC, ensuring on-premises DNS can resolve these service endpoints to their private IP addresses.

Answer

To achieve private migration using AWS Application Migration Service (MGN) without internet access, you must configure the MGN replication template to use private IP routing and allow TCP port 1500 inbound from on-premises to the staging subnet. You must also create VPC interface endpoints for the MGN and EC2 services in the staging VPC and associate the Route 53 Private Hosted Zones with both the staging VPC and the Transit Gateway hub VPC to enable resolution from the on-premises environment.

The correct options are to configure the AWS MGN replication template to route data over private IPs while opening inbound TCP port 1500 in the staging security group, and to configure Interface VPC Endpoints for the MGN and EC2 APIs with Route 53 Private Hosted Zones associated with both the staging and hub VPCs. Together, these steps satisfy both the data-plane replication requirements (private routing over TCP port 1500) and control-plane communication requirements (private API access via PrivateLink with functioning DNS resolution from on-premises).

Step-by-Step Solution

Configure the replication template to route data over private IP addresses.

The replication agent installed on-premises will target the private IP addresses of the replication servers in the staging subnet instead of attempting to connect to public IPs.

This is a prerequisite for private replication over hybrid networks such as Direct Connect or VPN.

Allow inbound traffic on TCP port 1500 in the staging subnet security group and network ACLs.

The replication agent can establish a data connection to send block-level replication data to the replication servers.

AWS MGN uses TCP port 1500 exclusively for block-level data transmission between the agent and the replication servers.

Create interface VPC endpoints (PrivateLink) for AWS MGN and Amazon EC2 in the staging VPC and associate the Route 53 Private Hosted Zones with the staging and hub VPCs.

Both the replication servers (in the staging VPC) and the replication agents (on-premises) can communicate with the MGN control plane and EC2 APIs via private network paths.

This establishes private endpoints for API communication and ensures proper cross-VPC DNS resolution for queries coming from the on-premises environment via the Direct Connect connection.

Key Concept

AWS Application Migration Service (MGN) private replication requires configuring the replication template to use private IPs, opening TCP port 1500 for data transfer, and using Route 53 Private Hosted Zones associated with all VPCs handling on-premises traffic to resolve interface VPC endpoints (PrivateLink) privately.

Question 366Question →

A financial enterprise is migrating an on-premises Oracle database to an Amazon Aurora PostgreSQL-Compatible Edition DB cluster. The migration must achieve the lowest possible downtime and ensure that schema customizations, secondary indexes, and referential integrity constraints are preserved. The database size is 8 TB, and the application generates a high volume of daily transactions. The Solutions Architect has already run the AWS Schema Conversion Tool (SCT) to generate the target PostgreSQL DDL. Which migration strategy will meet these requirements with the shortest replication cutover window and the highest performance during the initial load?

Apply the table structures and primary keys from the SCT DDL to the Aurora DB cluster. Enable supplemental logging on the source Oracle database. Configure the AWS DMS replication task to use the 'Do nothing' table preparation mode, and execute the Full Load phase. After the Full Load phase completes, apply the secondary indexes, foreign key constraints, and triggers from the SCT DDL to the Aurora database, then initiate the Change Data Capture (CDC) replication phase.

Apply the complete SCT DDL, including all tables, indexes, and constraints, to the target Aurora DB cluster. Configure a single AWS DMS task to perform both Full Load and Change Data Capture (CDC) replication with 'Do nothing' table preparation mode, leaving supplemental logging disabled on the source Oracle database to avoid source performance impact.

Skip the AWS SCT process to save time, and directly configure an AWS DMS replication task with 'Drop tables on target' preparation mode. Rely on AWS DMS to automatically convert the source Oracle database schemas, data types, and PL/SQL packages into PostgreSQL format on the fly during the Full Load and Change Data Capture (CDC) phases.

Apply the complete SCT DDL to the target Aurora DB cluster. To scale the write performance of the initial load, configure the AWS DMS task to write data concurrently to the Aurora PostgreSQL primary writer instance and its Multi-AZ standby instance. Enable supplemental logging on the source Oracle database, and run the DMS task with 'Truncate' preparation mode.

Show answer & explanation

Answer: Apply the table structures and primary keys from the SCT DDL to the Aurora DB cluster. Enable supplemental logging on the source Oracle database. Configure the AWS DMS replication task to use the 'Do nothing' table preparation mode, and execute the Full Load phase. After the Full Load phase completes, apply the secondary indexes, foreign key constraints, and triggers from the SCT DDL to the Aurora database, then initiate the Change Data Capture (CDC) replication phase.

Answer

Apply only table structures and primary keys from the SCT DDL to the Aurora DB cluster, enable supplemental logging on the source Oracle database, run the DMS Full Load with 'Do nothing' table preparation, and then apply secondary indexes, foreign keys, and triggers before initiating the CDC phase.

Applying only table structures and primary keys before the full load prevents index maintenance and constraint verification overhead. Enabling supplemental logging on the source Oracle database is required for AWS DMS to perform CDC replication. Applying the secondary indexes, foreign keys, and triggers after the full load completes ensures optimal performance and preserves referential integrity.

Step-by-Step Solution

Apply the base schema DDL (tables and primary keys only) from SCT to the target Aurora DB cluster.

The target database contains empty tables with primary keys, but no secondary indexes, foreign keys, or triggers.

This avoids write overhead and constraint failures during the high-speed data migration.

Configure supplemental logging on the source Oracle database.

The source Oracle database logs the necessary columns in its redo logs for update and delete statements.

This is a prerequisite for AWS DMS CDC replication to track and apply ongoing changes.

Run the AWS DMS Full Load task with target table preparation mode set to 'Do nothing'.

Data is populated into the target tables quickly without constraint violations or index maintenance latency.

Ensures the pre-created schema structures are preserved and not dropped by DMS.

Apply secondary indexes, foreign keys, and triggers, and start the DMS Change Data Capture (CDC) replication phase.

The database index structure is created, referential integrity is established, and incremental changes are replicated.

Completes the schema migration and synchronizes the target with the source for cutover.

Key Concept

Heterogeneous database migration optimization using AWS SCT and AWS DMS

Question 367Question →

An enterprise has an existing solution where an application running on Amazon EC2 instances in Account A writes log files to an Amazon S3 bucket in Account B. The S3 bucket is configured with default encryption using the AWS-managed KMS key (aws/s3). The IAM role attached to the EC2 instances has the necessary permissions to write to the S3 bucket, and the bucket policy in Account B allows write access from the IAM role. However, the application's write requests are failing with an Access Denied error. Which solution should the Solutions Architect implement to resolve the write failures and strengthen the security of the cross-account data transfer?

Configure the S3 bucket to use a Customer Managed Key (CMK) in Account B for default encryption. Update the key policy of the CMK in Account B to allow the IAM role in Account A to perform kms:GenerateDataKey and kms:Decrypt actions, and update the IAM role policy in Account A to allow the same kms actions on the CMK in Account B.

Modify the key policy of the default AWS-managed KMS key (aws/s3) in Account B to grant kms:GenerateDataKey and kms:Decrypt permissions to the IAM role in Account A, and verify that the S3 bucket policy allows cross-account access.

Create a Service Control Policy (SCP) at the organizational level that allows cross-account S3 and KMS permissions. Attach the SCP to Account A and Account B to override the default access boundaries for the AWS-managed KMS key (aws/s3).

Configure the S3 bucket default encryption to use a Customer Managed Key (CMK) in Account A. Grant the S3 service principal in Account B permission to use the CMK, and configure the IAM role in Account A to perform kms:GenerateDataKey on the Account A CMK.

Show answer & explanation

Answer: Configure the S3 bucket to use a Customer Managed Key (CMK) in Account B for default encryption. Update the key policy of the CMK in Account B to allow the IAM role in Account A to perform kms:GenerateDataKey and kms:Decrypt actions, and update the IAM role policy in Account A to allow the same kms actions on the CMK in Account B.

Answer

Configure the S3 bucket to use a Customer Managed Key (CMK) in Account B for default encryption, grant the IAM role in Account A the required KMS permissions in both its IAM policy and the CMK key policy in Account B, and ensure the S3 bucket policy allows cross-account write access.

To perform cross-account writes to an S3 bucket that uses KMS encryption, the KMS key must be a Customer Managed Key (CMK) in the destination account (Account B) because AWS-managed keys (like `aws/s3`) cannot be shared across accounts. The key policy of the CMK in Account B must explicitly grant permissions (`kms:GenerateDataKey` and `kms:Decrypt`) to the principal in Account A (the IAM role). Additionally, the IAM role in Account A must also have IAM permissions to use that specific CMK in Account B. Finally, the S3 bucket policy must allow `s3:PutObject` from the Account A IAM role.

Step-by-Step Solution

Create a Customer Managed Key (CMK) in the destination account (Account B).

A custom KMS key exists in Account B that can be shared across accounts.

AWS-managed KMS keys (like `aws/s3`) cannot be used for cross-account operations.

Update the KMS key policy of the CMK in Account B to trust the IAM role in Account A.

The CMK key policy allows Account A's IAM role to perform `kms:GenerateDataKey` and `kms:Decrypt` actions.

Key policies must explicitly grant cross-account permissions for external IAM principals to use the key.

Update the IAM policy of the role in Account A to allow permissions on the CMK in Account B.

The IAM role in Account A is granted authorization to invoke `kms:GenerateDataKey` and `kms:Decrypt` using the Account B CMK.

For cross-account access, permissions must be granted on both the trust side (key policy) and the client side (IAM policy).

Modify the default encryption configuration of the S3 bucket in Account B to use the newly created CMK.

Objects uploaded to the bucket will be encrypted with the CMK instead of the AWS-managed key.

This allows the external writer in Account A to use the shared CMK to generate data keys during the upload process.

Key Concept

Cross-Account KMS Key Sharing for Amazon S3 Encryption

Estimated Time:2m 0s

Question 368Question →

A bioinformatics research institute is migrating 24 local physical servers running genomic analysis pipelines to AWS using AWS Application Migration Service (MGN). The on-premises network is connected to AWS via a 2 Gbps AWS Direct Connect connection using a Transit Virtual Interface (Transit VIF) terminating at a Direct Connect Gateway, which is associated with an AWS Transit Gateway. The Transit Gateway connects a Shared Services VPC and a dedicated Migration Staging VPC. In compliance with strict genomic data privacy regulations, all migration and replication traffic must traverse the private Direct Connect path and cannot route over the public internet. No internet gateway or NAT gateway is permitted in the Migration Staging VPC. Which configuration strategy should the Solutions Architect implement to establish secure, private replication while minimizing operational overhead?

Configure the AWS MGN replication template to use private IP routing. Deploy VPC interface endpoints for AWS MGN (com.amazonaws.us-east-1.mgn) in the Migration Staging VPC, and ensure private DNS is enabled. Configure the on-premises firewalls and Migration Staging security groups to allow outbound TCP Port 443 from the on-premises servers to the MGN interface endpoints, and outbound TCP Port 1500 from the on-premises servers to the replication servers' subnet in the Migration Staging VPC.

Configure the AWS MGN replication template to use private IP routing. Deploy VPC interface endpoints for AWS MGN (com.amazonaws.us-east-1.mgn) in the Shared Services VPC. Associate the Amazon Route 53 Private Hosted Zone (PHZ) for MGN with the Migration Staging VPC. Configure on-premises firewalls to allow outbound TCP Port 443 and TCP Port 1500 only to the Shared Services VPC, relying on Transit Gateway transit routing to forward the replication blocks to the Migration Staging VPC.

Configure the AWS MGN replication template to use private IP routing. Deploy VPC interface endpoints for AWS MGN (com.amazonaws.us-east-1.mgn) in the Migration Staging VPC. Configure the on-premises firewall and Migration Staging security groups to allow outbound TCP Port 443 from on-premises to the interface endpoints. Block TCP Port 1500 at the perimeter firewall to enforce SSL/TLS encryption for all data transit, allowing MGN to tunnel replication traffic over HTTPS.

Configure the AWS MGN replication template to use public IP routing. Establish an AWS Direct Connect Public Virtual Interface (Public VIF) on the connection to route replication traffic to the public AWS MGN endpoints. Deploy NAT Gateways in the Migration Staging VPC to translate the replication servers' private IP addresses to public IPs for on-premises communication.

Show answer & explanation

Answer: Configure the AWS MGN replication template to use private IP routing. Deploy VPC interface endpoints for AWS MGN (com.amazonaws.us-east-1.mgn) in the Migration Staging VPC, and ensure private DNS is enabled. Configure the on-premises firewalls and Migration Staging security groups to allow outbound TCP Port 443 from the on-premises servers to the MGN interface endpoints, and outbound TCP Port 1500 from the on-premises servers to the replication servers' subnet in the Migration Staging VPC.

Answer

Configure the AWS MGN replication template to use private IP routing. Deploy VPC interface endpoints for AWS MGN in the Migration Staging VPC, and configure the on-premises firewalls and Migration Staging security groups to allow outbound TCP Port 443 from the on-premises servers to the MGN interface endpoints, and outbound TCP Port 1500 from the on-premises servers to the replication servers' subnet in the Migration Staging VPC.

The correct configuration establishes a fully private replication path. By setting the replication template to use private IP routing and provisioning interface VPC endpoints (PrivateLink) for MGN in the Migration Staging VPC, the replication agent can communicate with the control plane over TCP Port 443. Crucially, the replication agent must also have direct access to the replication servers in the staging subnet over TCP Port 1500 to transmit data blocks. This design fulfills the security requirement of avoiding the public internet and NAT Gateways while satisfying all network port prerequisites.

Step-by-Step Solution

Select private IP routing in the AWS Application Migration Service (MGN) Replication Template.

Configures MGN to allocate private IP addresses to replication servers and expect replication traffic over the private network path.

Allows replication traffic to route over the AWS Direct Connect connection instead of the public internet, satisfying the security and regulatory constraints.

Deploy Interface VPC Endpoints (AWS PrivateLink) for the AWS MGN service in the Migration Staging VPC.

Enables the on-premises MGN replication agent to securely communicate with the MGN control plane API over the Direct Connect path using private IP addresses.

Provides a private route to the MGN control plane, resolving the lack of public internet access (no Internet Gateway or NAT Gateway) in the staging environment.

Configure network security groups and on-premises firewalls to allow TCP Port 443 and TCP Port 1500.

Establishes connectivity for both the control plane (Port 443 to the VPC endpoints) and the data plane (Port 1500 directly to the replication servers' subnet).

Ensures the replication agent can register with the control plane and successfully stream compressed, encrypted replication blocks to the staging area.

Key Concept

AWS Application Migration Service (MGN) supports data replication over private networks (VPN or Direct Connect) by utilizing private IP routing and Interface VPC Endpoints (PrivateLink) for control plane communication. In this topology, control traffic uses TCP Port 443 to the endpoints, and data replication traffic uses TCP Port 1500 directly to the replication servers in the staging subnet.

Question 369Question →

A healthcare diagnostics company is planning to migrate its hybrid application portfolio to AWS. The on-premises environment consists of 100 VMware vSphere VMs running supported Linux and Windows operating systems, and 15 legacy physical bare-metal servers running IBM AIX that host core databases. A strict corporate compliance policy prohibits installing any third-party agent software on the bare-metal database servers. The migration team needs to map network dependencies (such as active TCP connections and process-level interactions) for the entire application portfolio and track the migration progress in a centralized dashboard. Which strategy should the solutions architect recommend to collect the necessary discovery data while complying with all constraints?

Deploy the AWS Agentless Collector as an OVA on VMware vCenter to discover both the VMs and the physical AIX servers, then configure network dependency mapping from the vCenter logs.

Install the AWS Application Discovery Agent on both the VMware VMs and the physical AIX servers, and configure them to route traffic through an on-premises HTTPS proxy with SSL decryption to meet the security requirements.

Deploy the AWS Application Discovery Agent on the VMware vSphere VMs to collect configuration, performance, and network connection data. For the bare-metal AIX servers, use the AWS Migration Hub Import template to manually upload server specification and dependency data, and track the migration of all servers in AWS Migration Hub.

Deploy the AWS Agentless Collector on VMware vCenter for VM discovery. For the bare-metal AIX servers, install the AWS Application Discovery Agent by utilizing the compatibility mode, and configure AWS Migration Hub to automatically merge the data.

Show answer & explanation

Answer: Deploy the AWS Application Discovery Agent on the VMware vSphere VMs to collect configuration, performance, and network connection data. For the bare-metal AIX servers, use the AWS Migration Hub Import template to manually upload server specification and dependency data, and track the migration of all servers in AWS Migration Hub.

Answer

The AWS Application Discovery Agent supports Windows and Linux operating systems running on VMware VMs and gathers system configuration, performance metrics, and network connection details (TCP dependencies), which is required to map network dependencies. Because the AWS Application Discovery Agent does not support IBM AIX and the database security policy prohibits installing agents on those servers, the migration team must use the AWS Migration Hub Import template to manually upload the server specifications and dependency details for the AIX servers. Both discovered and imported servers can then be tracked centrally within AWS Migration Hub.

Step-by-Step Solution

Determine the data collection requirements for mapping network dependencies across the application portfolio.

Identify that process-level network connection data (TCP relationships) is required.

Mapping network dependencies requires TCP connection details, which are collected by the Application Discovery Agent but not by the Agentless Collector.

Evaluate tool compatibility and constraints for the VMware vSphere VMs.

Select the AWS Application Discovery Agent for installation on the VMs.

The VMs run supported Linux and Windows operating systems, allowing the Application Discovery Agent to be installed to gather the required network connection details.

Evaluate tool compatibility and constraints for the IBM AIX bare-metal database servers.

Select the AWS Migration Hub Import template (CSV) for the AIX database servers.

The Application Discovery Agent does not support IBM AIX, and the database security policy prohibits agent installation. Utilizing the import template allows manual entry of server specs and dependencies.

Key Concept

AWS Application Discovery Service supports agent-based discovery for gathering network connection details on supported operating systems, and manual CSV imports for unsupported operating systems or environments with strict agent restrictions, both of which integrate with AWS Migration Hub for centralized tracking.

Estimated Time:2m 0s

Question 370Question →

A media production company is building a document collaboration platform that manages transactional metadata (OLTP workload) and shared creative files (File storage workload). The file system must scale to handle millions of small, frequently accessed media assets while maintaining POSIX compliance, and must be replicated to a secondary AWS region with a Recovery Point Objective (RPO) of less than 15 minutes. Additionally, the metadata database must support high-performance transactional updates in the primary region, while providing read capabilities in the secondary region for reporting queries with replication latency under 1 second. Which two strategies should the solutions architect select to meet these requirements?

Select all that apply

Deploy Amazon EFS file systems in both the primary and secondary regions, and configure Amazon EFS Replication to copy data to the destination file system.

Provision an Amazon Aurora Global Database with the primary database cluster in the primary region and a secondary database cluster in the backup region to serve reporting queries.

Deploy Amazon EFS in the primary region and create a scheduled AWS Backup job to replicate backups to a backup vault in the secondary region every 12 hours.

Configure an Amazon RDS for PostgreSQL database with a Multi-AZ deployment, and configure the standby DB instance in the secondary Availability Zone to serve read traffic for reporting queries.

Deploy Amazon ElastiCache for Memcached with multi-AZ replication enabled across both regions to cache database query results and media asset metadata.

Show answer & explanation

Answer: Deploy Amazon EFS file systems in both the primary and secondary regions, and configure Amazon EFS Replication to copy data to the destination file system.; Provision an Amazon Aurora Global Database with the primary database cluster in the primary region and a secondary database cluster in the backup region to serve reporting queries.

Answer

The solutions architect should deploy Amazon EFS file systems in both regions with EFS Replication configured, and provision an Amazon Aurora Global Database with a secondary read cluster in the backup region.

To satisfy the POSIX-compliant file storage requirement with an RPO of less than 15 minutes, the architecture must use Amazon Elastic File System (EFS) with Amazon EFS Replication. EFS Replication replicates file system data to another AWS Region continuously with an RPO of minutes. To support transactional OLTP metadata with secondary region reads and sub-second latency, Amazon Aurora Global Database is the ideal choice. Aurora Global Database uses dedicated storage replication to duplicate data to secondary regions with a latency of less than 1 second, and the secondary cluster can actively serve read queries.

Step-by-Step Solution

Analyze the file storage requirements: POSIX compliance, millions of files, and a cross-region RPO of less than 15 minutes.

Determine that Amazon EFS provides POSIX compliance and scales to millions of files, and EFS Replication satisfies the RPO requirement since it operates continuously and typically replicates data in minutes.

Standard backup mechanisms like AWS Backup scheduled at 12-hour intervals cannot meet the strict 15-minute RPO target.

Analyze the database requirements: high-performance OLTP transactional updates, secondary region reads, and replication lag under 1 second.

Identify Amazon Aurora Global Database as the correct solution because it utilizes storage-based replication to replicate data to secondary regions with a typical latency of less than 1 second.

Amazon RDS Multi-AZ standby instances are passive and cannot accept read connections, and ElastiCache for Memcached lacks the required replication and persistence capabilities.

Key Concept

Selecting multi-region storage and database replication strategies to meet POSIX compliance, RPO, and read performance targets.

Estimated Time:2m 0s

Question 371Question →

An organization is establishing a secure deployment pipeline from an external OIDC-compliant CI/CD platform to multiple target AWS member accounts within their AWS Organization. A solutions architect must design a federation trust model that allows runners to assume a deployment role (DeployRole) only when executing workflows from a specific repository (org/repo-a) and branch (main), without relying on long-lived credentials. Which of the following configuration steps must the solutions architect perform to establish this federation model? (Choose TWO.)

Select all that apply

Create an IAM OpenID Connect (OIDC) identity provider in each target AWS account, using the external CI/CD platform's issuer URL and setting the client ID configured to match the audience string.

Configure the trust policy of the deployment role in the target AWS accounts with the sts:AssumeRoleWithWebIdentity action, setting the principal to the IAM OIDC provider's ARN and adding a condition that filters the subject claim (sub) for the authorized repository and branch.

Configure the deployment role trust policy in the target AWS accounts to allow the sts:AssumeRole action, specifying the ARN of the IAM OIDC provider as the principal.

Create an IAM SAML 2.0 identity provider in the target accounts and configure the deployment role trust policy to use the sts:AssumeRoleWithSAML action, while using a Service Control Policy (SCP) to filter the subject claim.

Create a centralized IAM OIDC identity provider in the AWS Organizations management account, and attach a Service Control Policy (SCP) to target OUs that grants member accounts trust to assume roles via the management account's OIDC provider.

Show answer & explanation

Answer: Create an IAM OpenID Connect (OIDC) identity provider in each target AWS account, using the external CI/CD platform's issuer URL and setting the client ID configured to match the audience string.; Configure the trust policy of the deployment role in the target AWS accounts with the sts:AssumeRoleWithWebIdentity action, setting the principal to the IAM OIDC provider's ARN and adding a condition that filters the subject claim (sub) for the authorized repository and branch.

Answer

To establish OIDC federation with an external CI/CD platform, you must create an IAM OIDC identity provider in each target account using the platform's issuer URL and audience client ID, and then configure the deployment role's trust policy in the target accounts to allow the sts:AssumeRoleWithWebIdentity action with a condition filtering on the repository and branch subject claim.

The correct options are: creating an IAM OIDC provider in each target account using the issuer URL and client ID, and configuring the deployment role trust policy with sts:AssumeRoleWithWebIdentity while filtering the subject claim. Registering the OIDC identity provider establishes the trust anchor in the target accounts. Configuring the trust policy with the correct action and claim filtering allows authentication to succeed securely for the specific repository and branch.

Step-by-Step Solution

An IAM OIDC identity provider resource is created in each member account pointing to the external provider's issuer URL and configured with the correct client ID.

Establishing the OIDC identity provider resource within each local account registers the trust anchor for validating JWTs signed by the external provider.

Define the IAM role trust policy configuration

The target role trust policy is set up with the sts:AssumeRoleWithWebIdentity action and the OIDC provider as the principal.

OIDC token exchange requires the AssumeRoleWithWebIdentity API operation, and specifying the OIDC provider ARN maps the external identity validation to this local IAM role.

Add claim conditions to limit authorization

A StringEquals or StringLike condition evaluates the OIDC subject (sub) claim to match the repository name and branch.

Without this condition, any runner authenticated by the external OIDC provider (including other repositories) could assume the role, creating a security vulnerability.

Key Concept

Establishing direct OIDC federation in a multi-account environment requires creating local IAM OIDC providers and configuring trust policies with sts:AssumeRoleWithWebIdentity and subject claim filters.

Question 372Question →

An enterprise is planning to migrate a $3.2\text{ PB}$ unstructured dataset from an on-premises high-performance NFS file system to Amazon S3. The migration must be completed within a strict timeline of $14\text{ days}$ during an upcoming datacenter decommissioning event. The company has a dedicated $10\text{ Gbps}$ AWS Direct Connect connection, but only $2.5\text{ Gbps}$ of this connection can be allocated for migration traffic due to concurrent production workloads. Post-migration, the data must be encrypted at rest using a Key Management Service (KMS) key that is shared across multiple AWS accounts to support cross-account collaborative analytics. Furthermore, on-premises applications will continue reading and writing to the NFS share until the final cutover, meaning that any changes written during the bulk data transfer phase must be synchronized to AWS. Which of the following migration strategies is the most efficient and compliant?

Deploy AWS DataSync agents on-premises and configure a Transit Gateway with a Direct Connect gateway to route migration traffic over a Transit Gateway Connect attachment. Run multiple concurrent DataSync tasks to copy the entire

3.2\text{ PB}

dataset directly to the destination Amazon S3 bucket over the dedicated link within the

14\text{-day}

window.

Order AWS Snowball Edge Storage Optimized devices to execute the bulk migration. Set up the target Amazon S3 bucket to use the default AWS-managed KMS key (`aws/s3`) for encryption at rest to simplify security configuration. Deploy AWS DataSync agents to perform incremental delta syncs over the Direct Connect connection, and modify the key policy of the default key to grant cross-account permissions.

Provision an AWS Transfer Family SFTP endpoint configured to write directly to the target Amazon S3 bucket. Package the

3.2\text{ PB}

dataset into compressed archives on-premises and use a custom script to parallelize SFTP uploads over the Direct Connect link via a Transit Gateway that lacks a Transit Gateway route table association for the target VPC.

Order AWS Snowball Edge Storage Optimized devices to perform the initial bulk transfer. Configure the target Amazon S3 bucket to use a Customer Managed Key (CMK) for encryption at rest and configure its key policy to allow cross-account access. Once the bulk data is imported into Amazon S3, deploy AWS DataSync agents on-premises to sync the active delta updates over the Direct Connect connection, ensuring the DataSync task execution role has decrypt and encrypt permissions for the CMK.

Show answer & explanation

Answer: Order AWS Snowball Edge Storage Optimized devices to perform the initial bulk transfer. Configure the target Amazon S3 bucket to use a Customer Managed Key (CMK) for encryption at rest and configure its key policy to allow cross-account access. Once the bulk data is imported into Amazon S3, deploy AWS DataSync agents on-premises to sync the active delta updates over the Direct Connect connection, ensuring the DataSync task execution role has decrypt and encrypt permissions for the CMK.

Answer

The correct strategy is to use AWS Snowball Edge Storage Optimized devices for the initial bulk transfer, encrypt the target Amazon S3 bucket with a Customer Managed Key (CMK) that allows cross-account permissions, and use AWS DataSync over the Direct Connect connection to sync the delta updates before cutover.

The correct strategy uses AWS Snowball Edge Storage Optimized devices to bypass the network bottleneck for the initial

3.2\text{ PB}

bulk data transfer, which is the only way to meet the

14\text{-day}

limit. It correctly implements a Customer Managed Key (CMK) to allow cross-account sharing of the encrypted data, and uses AWS DataSync to copy the changes made to the NFS share during the Snowball transfer process.

Step-by-Step Solution

Calculate the theoretical maximum data transfer capacity over the available network link.

2.5\text{ Gbps}

throughput, the maximum data that can be transferred in

24\text{ hours}

2.5 \times 10^9 \times 86400 / 8 \approx 27\text{ TB}

per day. Over

14\text{ days}

, this allows a maximum transfer of

\approx 378\text{ TB}

, which is far below the

3.2\text{ PB}

requirement.

This step determines whether an online network migration or an offline physical shipment is required.

Select the appropriate AWS transfer service for bulk data transfer based on the time constraints.

Identify that AWS Snowball Edge Storage Optimized devices must be ordered to parallelize and handle the initial offline bulk migration of

3.2\text{ PB}

Offline transport is the only mechanism that can complete the bulk migration within the

14\text{-day}

decommission window.

Evaluate key management options for cross-account data access.

Choose a Customer Managed Key (CMK) in AWS KMS because AWS-managed keys (`aws/s3`) cannot be shared across multiple AWS accounts or have their policies modified.

This satisfies the requirement to support post-migration cross-account collaborative analytics.

Establish a delta synchronization mechanism for active writes.

Deploy AWS DataSync agents on-premises to sync active updates over the Direct Connect connection after the Snowball devices are imported. Ensure the DataSync execution role has permissions to use the CMK.

DataSync can identify and copy only the changed files (deltas) over the network, which fits easily within the

2.5\text{ Gbps}

bandwidth limit.

Key Concept

Selecting data transfer tools based on network constraints and configuring Customer Managed Keys for cross-account compliance.

Question 373Question →

A logistics company is preparing to migrate its hybrid workload portfolio to AWS. The on-premises infrastructure consists of 250 VMware vSphere VMs, 40 physical Linux servers, and 10 legacy physical servers running IBM AIX. Outbound internet access from the application subnets is blocked, but an outbound proxy server is available in a management subnet. The company must discover server system configurations, network dependencies, and performance characteristics for migration planning. They also want to track the overall migration progress using AWS Migration Hub.

Which combination of actions will meet these requirements while minimizing administrative overhead? (Select TWO.)

Select all that apply

Install the AWS Application Discovery Agent on the VMware VMs and physical Linux servers, configuring the agents to route outbound traffic through the management subnet proxy.

Import the configuration and dependency data of the IBM AIX physical servers manually by uploading a formatted CSV file to the AWS Application Discovery Service.

Deploy the AWS Application Discovery Agentless Collector on VMware vSphere, configuring it to scan the physical Linux servers and IBM AIX servers remotely via SSH.

Install the AWS Application Discovery Agent on the IBM AIX physical servers, configuring the local daemon to communicate with the Application Discovery Service via the proxy.

Use AWS Resource Access Manager (RAM) to share the on-premises discovery data with the AWS Migration Hub in the target migration account.

Show answer & explanation

Answer: Install the AWS Application Discovery Agent on the VMware VMs and physical Linux servers, configuring the agents to route outbound traffic through the management subnet proxy.; Import the configuration and dependency data of the IBM AIX physical servers manually by uploading a formatted CSV file to the AWS Application Discovery Service.

Answer

Install the AWS Application Discovery Agent on the VMware VMs and physical Linux servers, configuring the agents to route outbound traffic through the management subnet proxy, and import the configuration and dependency data of the IBM AIX physical servers manually by uploading a formatted CSV file to the AWS Application Discovery Service.

The correct actions involve installing the AWS Application Discovery Agent on the supported environments (VMware VMs and physical Linux servers) to capture both system configuration and network dependency mappings, while using the management proxy. For the unsupported IBM AIX operating system, the configuration and dependency details must be imported manually using the Application Discovery Service CSV template.

Step-by-Step Solution

Determine the discovery mechanism for the VMware VMs and physical Linux servers where network dependencies must be mapped.

Identify that the AWS Application Discovery Agent is required because the Agentless Collector does not capture network connection mappings (dependencies). Configure these agents to route traffic through the allowed management subnet proxy.

Agents must be deployed to capture network dependencies, and security policies require using the outbound HTTPS proxy.

Determine the discovery mechanism for the IBM AIX servers.

Identify that IBM AIX is not supported by either the Discovery Agent or the Agentless Collector. Prepare a CSV file using the AWS Application Discovery Service import template containing the configuration and dependency data for the AIX servers, and upload it.

Manual CSV import is the only method to feed configuration and dependency data for unsupported operating systems into the discovery service.

Group the discovered servers into applications within AWS Migration Hub.

Track the overall migration progress of the defined applications using Migration Hub's dashboard.

Allows centralized tracking and grouping of discovered systems for planning migration waves.

Key Concept

AWS Application Discovery Service supports agent-based collection (which captures system dependencies and supports proxy configuration) and manual CSV import for unsupported operating systems like IBM AIX.

Question 374Question →

A retail enterprise is migrating its legacy inventory management systems, which include $12$ on-premises application servers, to AWS using AWS Application Migration Service (MGN). The enterprise connects its on-premises network to AWS via an AWS Direct Connect connection terminated at an AWS Transit Gateway in a central Transit VPC. The Transit VPC connects to the target Migration VPC. Due to strict corporate security compliance, no internet access is permitted from either the on-premises network or the target Migration VPC. The Solutions Architect has installed the AWS Replication Agent on the on-premises servers, but the replication status shows that the agents are unable to communicate with the AWS MGN replication servers and are failing to register with the service. Which of the following configuration steps must the Solutions Architect take to establish connectivity and ensure successful data replication? (Select TWO.)

Select all that apply

Configure the on-premises firewalls and the security group of the Replication Staging Area to allow outbound traffic from the on-premises servers and inbound traffic to the replication servers over TCP port 1500.

Create an interface VPC endpoint (AWS PrivateLink) for the MGN service (com.amazonaws.region.mgn) in the target VPC, associate it with the target VPC, and configure a Route 53 Resolver inbound endpoint to resolve the service domain name from the on-premises DNS.

Configure the staging area security groups to permit inbound HTTPS traffic on TCP port 443 from the on-premises servers to the replication servers for the continuous data replication stream.

Create a Route 53 Private Hosted Zone (PHZ) for the MGN endpoint in the Migration VPC and rely on Transit Gateway routing tables to transitively resolve the DNS names for the on-premises servers.

Provision a single NAT Gateway in the migration staging subnet to route all replication traffic over a Direct Connect public virtual interface (VIF) to the public AWS MGN endpoints.

Show answer & explanation

Answer: Configure the on-premises firewalls and the security group of the Replication Staging Area to allow outbound traffic from the on-premises servers and inbound traffic to the replication servers over TCP port 1500.; Create an interface VPC endpoint (AWS PrivateLink) for the MGN service (com.amazonaws.region.mgn) in the target VPC, associate it with the target VPC, and configure a Route 53 Resolver inbound endpoint to resolve the service domain name from the on-premises DNS.

Answer

The Solutions Architect must configure the on-premises firewalls and staging area security group to allow TCP port 1500 for replication data, and create an interface VPC endpoint for the MGN service in the target VPC combined with a Route 53 Resolver inbound endpoint for DNS resolution.

The option allowing TCP port 1500 is correct because AWS MGN uses TCP port 1500 to stream replicated blocks to replication servers. The option creating the interface VPC endpoint for MGN and configuring Route 53 Resolver inbound endpoints is correct because it resolves the private DNS for MGN control plane endpoints, enabling the agent to register securely without exposing traffic to the public internet.

Step-by-Step Solution

Ensure the replication data path is open.

TCP port 1500 is permitted outbound on the on-premises firewall and inbound on the replication staging area security groups.

The AWS Replication Agent replicates data blocks directly to the replication servers using TCP port 1500.

Enable private control plane access.

An interface VPC endpoint for the MGN service is provisioned in the target VPC.

This allows the agent on-premises to communicate with the MGN control plane without using the public internet.

Configure DNS resolution for the private endpoints.

Route 53 Resolver inbound endpoints are configured to forward DNS queries from on-premises to the private hosted zone associated with the VPC.

On-premises servers must resolve the public MGN service DNS names to the private IP addresses of the interface VPC endpoints.

Key Concept

Establishing hybrid connectivity and DNS resolution for AWS Application Migration Service (MGN) in a private network architecture.

Question 375Question →

A company has two core applications deployed in separate VPCs (`VPC-A` and `VPC-B`) within the `us-east-1` Region. The application in `VPC-A` processes telemetry data and replicates approximately $300\text{ TB}$ of data monthly to a database cluster in `VPC-B`. Both VPCs are connected via an existing AWS Transit Gateway, which also provides hybrid connectivity to the company's on-premises data center. The finance department has flagged high Transit Gateway data processing charges associated with this inter-VPC replication traffic. Which of the following is the most cost-effective routing architecture to reduce data transfer costs while maintaining the existing hybrid connectivity?

Establish a VPC Peering connection between VPC-A and VPC-B, and update the route tables in both VPCs to route the database replication traffic through the peering connection while keeping the Transit Gateway for hybrid traffic.

Replace the Transit Gateway with an AWS Direct Connect Gateway to handle both the inter-VPC database replication traffic and the hybrid connectivity to the on-premises data center.

Create a VPN connection over the internet between the virtual private gateways of VPC-A and VPC-B, and deploy a single NAT Gateway in VPC-A to route replication traffic through the VPN.

Use AWS Resource Access Manager (RAM) to share the Transit Gateway attachment of VPC-B with the AWS account hosting VPC-A to enable direct subnet-to-subnet routing and bypass Transit Gateway data processing charges.

Show answer & explanation

Answer: Establish a VPC Peering connection between VPC-A and VPC-B, and update the route tables in both VPCs to route the database replication traffic through the peering connection while keeping the Transit Gateway for hybrid traffic.

Answer

Establishing a VPC Peering connection for high-volume inter-VPC replication traffic is the most cost-effective approach. AWS Transit Gateway charges

0.02 per GB for data processing in the `us-east-1` Region, which results in

6,000 of unnecessary monthly overhead for $300 TB of data. Since VPC Peering has no data processing fees, migrating the replication traffic to a peering connection eliminates this charge entirely. The Transit Gateway can still be kept active to handle hybrid routing to the on-premises data center.

Step-by-Step Solution

Analyze current costs and traffic paths.

Database replication traffic (

300\text{ TB}

monthly) is routed over an AWS Transit Gateway, which charges a data processing fee of

0.02/\text{GB}

in the `us-east-1` Region, resulting in

300,000 \times \$0.02 = \$6,000

in monthly data processing charges.

Identifying the baseline cost and source of the charges is necessary to evaluate the potential savings of alternative architectures.

Evaluate VPC Peering as a cost-optimization alternative.

VPC Peering does not charge any data processing fees. Inter-AZ traffic incurs

0.01/\text{GB}

in each direction, and intra-AZ traffic is free. Replacing the Transit Gateway path with VPC Peering for this traffic eliminates the

0.02/\text{GB}

processing fee.

VPC Peering is the most cost-effective way to connect two VPCs in the same Region when high data throughput is required.

Ensure architectural compatibility with hybrid networking requirements.

The Transit Gateway remains active for handling hybrid connectivity to the on-premises data center, while specific route table entries redirect the inter-VPC replication traffic to the VPC Peering connection.

This guarantees that the cost-optimization measure does not disrupt the existing connection to the on-premises network.

Key Concept

Optimizing inter-VPC data transfer costs by leveraging VPC Peering instead of Transit Gateway for high-volume localized traffic.

Question 376Question →

An enterprise manages its multi-account environment using AWS Organizations. The environment is structured with a Root OU, a Security OU containing a dedicated security auditing account, and a Workloads OU containing production application accounts. The enterprise's security posture mandates that:

- Development teams must be blocked from modifying, disabling, or deleting security services (Amazon GuardDuty, AWS CloudTrail, and AWS Config) within their workload accounts.
- The central security team must be able to perform emergency maintenance and updates on these configurations within the workload accounts using a pre-deployed IAM role named SecurityAdmin.
- Operational operations must be delegated away from the management account to maintain isolation.

Which solution meets these requirements with the least operational overhead?

Deploy an IAM permission boundary to all workload accounts. Require that all developer IAM users and roles have this boundary attached, which explicitly denies modifications to GuardDuty, CloudTrail, and AWS Config. Exclude the SecurityAdmin role from this boundary. Use AWS CloudFormation StackSets to deploy and update the boundary across all accounts.

Attach a Service Control Policy (SCP) to the Workloads OU that explicitly allows GuardDuty, CloudTrail, and AWS Config operations only for the SecurityAdmin role, and denies them to all other roles. Rely on this SCP to grant the necessary administrative permissions to the central security team without configuring local IAM policies in the workload accounts.

Register the security auditing account as the delegated administrator for Amazon GuardDuty, AWS CloudTrail, and AWS Config. Apply a Service Control Policy (SCP) to the Workloads OU that denies modification and deletion of these security services, using a condition block with the ArnNotEquals key to exclude the SecurityAdmin role's ARN. Ensure local developer roles do not have permissions to assume or modify the SecurityAdmin role.

Configure cross-account IAM roles in the workload accounts that trust the organization's management account. Use the management account to centrally deploy and manage the security configurations. Attach an SCP to the Workloads OU that denies all modifications and deletions of GuardDuty, CloudTrail, and AWS Config for all principals within the OU.

Show answer & explanation

Answer: Register the security auditing account as the delegated administrator for Amazon GuardDuty, AWS CloudTrail, and AWS Config. Apply a Service Control Policy (SCP) to the Workloads OU that denies modification and deletion of these security services, using a condition block with the ArnNotEquals key to exclude the SecurityAdmin role's ARN. Ensure local developer roles do not have permissions to assume or modify the SecurityAdmin role.

Answer

Register the security auditing account as the delegated administrator for GuardDuty, CloudTrail, and AWS Config. Apply a Service Control Policy (SCP) to the Workloads OU that denies modification and deletion of these security services, using a condition block with the ArnNotEquals key to exclude the SecurityAdmin role's ARN. Ensure local developer roles do not have permissions to assume or modify the SecurityAdmin role.

Registering the security auditing account as the delegated administrator isolates the management account from operational duties, satisfying a core AWS architectural best practice. Applying a Service Control Policy (SCP) at the Workloads OU level ensures the policy is applied to all member accounts globally. Using the 'ArnNotEquals' condition key on 'aws:PrincipalARN' allows the central 'SecurityAdmin' role to perform maintenance, while restricting developers and local administrators. Keeping local developers from assuming or modifying the security role ensures they cannot bypass the restriction.

Step-by-Step Solution

Register the dedicated security auditing account as the delegated administrator for the required AWS services (GuardDuty, CloudTrail, Config).

Enables the security auditing account to configure and manage these services organization-wide, keeping the management account isolated from operational tasks.

AWS best practices dictate isolating the management account and delegating service administration to dedicated operational accounts.

Draft a Service Control Policy (SCP) that restricts destructive and modification actions for GuardDuty, CloudTrail, and Config.

Creates a centralized guardrail that applies to all accounts within the target OU.

SCPs provide organization-wide restrictions that cannot be bypassed by local administrators in member accounts.

Incorporate a condition block in the SCP using the 'ArnNotEquals' key and the 'aws:PrincipalARN' global condition key to exclude the 'SecurityAdmin' role.

Exempts the 'SecurityAdmin' role from the deny effect, allowing the central security team to perform authorized modifications.

This conditional logic prevents the SCP from locking out authorized administrators while still restricting developers.

Attach the SCP to the Workloads OU and ensure developers are blocked from assuming or modifying the 'SecurityAdmin' role.

Enforces the policy across all target workload accounts and prevents developers from bypassing the restriction.

SCPs act as filters and do not grant permissions; ensuring local configuration controls prevent unauthorized privilege escalation is necessary to preserve the governance structure.

Key Concept

Delegated Administration and Service Control Policies with Conditional Exemptions

Estimated Time:2m 30s

Question 377Question →

A company is planning to migrate its on-premises Microsoft SQL Server database to an Amazon Aurora MySQL-Compatible Edition DB cluster. The migration must occur with minimal downtime, requiring continuous data replication via Change Data Capture (CDC). The source database contains tables with complex foreign key constraints, and several columns contain VARCHAR(MAX) data with sizes up to 128 KB. A Solutions Architect will use the AWS Schema Conversion Tool (SCT) to convert the schema and AWS Database Migration Service (DMS) for the data migration.

Which of the following actions should the Solutions Architect take to ensure a successful and optimized migration? (Select two.)

Select all that apply

Configure the target Amazon Aurora MySQL endpoint in AWS DMS with the extra connection attribute AfterConnectScript=SET foreign_key_checks=0;

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

Enable Change Data Capture (CDC) on the source SQL Server database, and ensure that the SQL Server Agent service is stopped to release locks on the active transaction log.

Configure the AWS DMS replication task to use Full LOB mode with a LOB chunk size of 128 KB to optimize data transfer for the VARCHAR(MAX) columns.

Install and apply the AWS SCT extension pack directly on the source Microsoft SQL Server database to emulate MySQL-compatible SQL functions.

Show answer & explanation

Answer: Configure the target Amazon Aurora MySQL endpoint in AWS DMS with the extra connection attribute AfterConnectScript=SET foreign_key_checks=0;; Configure the AWS DMS replication task to use Limited LOB mode and set the Max LOB size parameter to 128 KB.

Answer

To ensure a successful and optimized migration, the Solutions Architect should configure the target Amazon Aurora MySQL endpoint in AWS DMS with the extra connection attribute AfterConnectScript=SET foreign_key_checks=0; to disable foreign key checks during migration, and configure the AWS DMS replication task to use Limited LOB mode with the Max LOB size parameter set to 128 KB.

Disabling foreign key constraints on the target database during the migration prevents referential integrity violations during parallel table loads. Using Limited LOB mode with the Max LOB size set to 128 KB ensures LOB data is transferred inline with the rest of the row data without being truncated, providing optimal performance.

Step-by-Step Solution

Identify the LOB requirements and performance constraints.

Recognize that Limited LOB mode is optimal for known small LOB sizes (up to 128 KB) to avoid the separate lookup overhead of Full LOB mode.

To optimize replication throughput for VARCHAR(MAX) fields.

Address target foreign key constraints during parallel load.

Set the AfterConnectScript target endpoint attribute to SET foreign_key_checks=0;.

AWS DMS loads tables in parallel, which can cause foreign key constraint violations if child rows are inserted before parent rows.

Verify source CDC prerequisites.

Ensure MS-CDC is enabled and the SQL Server Agent is running.

SQL Server Agent runs the CDC capture jobs required by AWS DMS.

Key Concept

Optimizing heterogeneous migrations with AWS DMS using custom target endpoint connection attributes and LOB mode settings.

Question 378Question →

A financial institution is migrating a core banking application consisting of $15$ physical servers from an on-premises data center to AWS. The replication traffic must flow privately over an existing AWS Direct Connect connection to a staging area VPC, which is connected to a shared services VPC via an AWS Transit Gateway. The Solutions Architect has installed the AWS Replication Agent on the source servers, but the replication status shows that the agents are unable to communicate with the replication servers in the staging area VPC, preventing the initialization of the data replication process.

Which action should the Solutions Architect take to resolve this connectivity issue and allow data replication to begin?

Associate the Route 53 Private Hosted Zone for the MGN endpoints only with the shared services VPC, and rely on default DNS resolution in the staging area VPC without associating the zone to it.

Configure the on-premises firewall to allow outbound traffic on TCP port 1500 to the staging area VPC, and update the staging area's security groups to allow inbound traffic on TCP port 1500 from the on-premises CIDR block.

Modify the staging area security group to permit inbound TCP port 443 traffic from the on-premises environment, as the replication agent tunnels all data blocks and control signals through HTTPS.

Configure a Direct Connect Gateway to perform transitive routing directly between the staging area VPC and a shared transit VPC to bypass the need for an AWS Transit Gateway.

Show answer & explanation

Answer: Configure the on-premises firewall to allow outbound traffic on TCP port 1500 to the staging area VPC, and update the staging area's security groups to allow inbound traffic on TCP port 1500 from the on-premises CIDR block.

Answer

The correct action is to ensure that TCP port 1500 is open in both the on-premises network firewall (outbound) and the staging area security groups (inbound). AWS Application Migration Service (MGN) uses TCP port 1500 for the actual replication data stream between the AWS Replication Agent on the source servers and the replication servers in the staging area VPC.

Step-by-Step Solution

Identify the network requirements for AWS Application Migration Service (MGN) data plane replication.

Determine that the AWS Replication Agent replicates data blocks to the replication servers in the staging area VPC over TCP port 1500.

Replication data does not use port 443, which is reserved for the control plane.

Analyze the on-premises firewall and AWS security group configurations.

Confirm that outbound TCP port 1500 must be open from on-premises servers and inbound TCP port 1500 must be open in the staging area security groups.

Without these rules, replication packets cannot reach the replication servers in the staging area VPC.

Implement the necessary security group and firewall changes.

Allow TCP port 1500 outbound on the on-premises firewall and inbound on the staging area VPC security group.

This establishes the necessary connection path for the data replication streams to start.

Key Concept

Data replication traffic in AWS Application Migration Service (MGN) requires TCP port 1500 to be open between the source servers and the replication servers in the staging area VPC.

Question 379Question →

A multinational retail e-commerce company is planning to migrate its core inventory management system and order processing services to AWS. The on-premises infrastructure consists of 350 VMware vSphere virtual machines (VMs) running supported versions of Red Hat Enterprise Linux (RHEL) and Windows Server, and 20 bare-metal physical servers running IBM AIX for legacy transaction ledger processing. Security compliance policies strictly prohibit direct outbound internet access from database and application subnets, requiring all outbound traffic to traverse a centralized forward proxy. The migration team needs to gather detailed configuration, performance metrics (CPU, RAM, disk I/O), network connection dependencies, and process-level information for planning. Additionally, they must track the migration status dynamically in AWS Migration Hub using both AWS and partner migration tools. Which two actions should a solutions architect recommend to collect the discovery data and configure tracking?

Select all that apply

Deploy the AWS Application Discovery Agent on the VMware VMs, configure the agents to use the centralized forward proxy for outbound communication, and associate the discovered servers with applications in AWS Migration Hub.

Use the Application Discovery Service import template to upload a CSV file with the configuration and performance details of the IBM AIX bare-metal servers, and integrate supported third-party migration tools with AWS Migration Hub to track the migration.

Deploy the Application Discovery Agentless Collector on the VMware vSphere environment to discover both the VMware VMs and the IBM AIX bare-metal servers, bypassing the need for any local agent installation or CSV import.

Deploy the AWS Application Discovery Agent on all VMware VMs and IBM AIX bare-metal servers, and configure on-premises firewalls to allow direct outbound traffic over TCP port 1500 to the AWS Application Migration Service endpoint.

Configure the Application Discovery Agentless Collector to collect network connection dependencies and process-level information for the VMware VMs, and establish an AWS Direct Connect gateway connection to route this metadata to AWS Migration Hub.

Show answer & explanation

Answer: Deploy the AWS Application Discovery Agent on the VMware VMs, configure the agents to use the centralized forward proxy for outbound communication, and associate the discovered servers with applications in AWS Migration Hub.; Use the Application Discovery Service import template to upload a CSV file with the configuration and performance details of the IBM AIX bare-metal servers, and integrate supported third-party migration tools with AWS Migration Hub to track the migration.

Answer

Deploy the AWS Application Discovery Agent on the VMware VMs configured to use the forward proxy, and import the IBM AIX bare-metal server data via a CSV file using the import template, while integrating third-party tools with AWS Migration Hub.

The correct actions involve using the AWS Application Discovery Agent on supported VMware VMs because they require detailed process and network connection mapping, and routing their traffic via the centralized forward proxy. Since the IBM AIX bare-metal servers are not supported by the agent or the Agentless Collector, their data must be imported via a CSV file. AWS Migration Hub can then be configured to aggregate migration status updates from both AWS and supported third-party tools.

Step-by-Step Solution

Evaluate the discovery requirements for the VMware virtual machines.

Since detailed performance metrics, network connection dependencies, and process-level information are needed, the agent-based AWS Application Discovery Agent must be selected (the Agentless Collector only collects basic VM-level metrics and does not map dependencies or processes). Configured the agents to use the proxy.

Meets security compliance guidelines prohibiting direct outbound internet access.

Evaluate the discovery requirements for the IBM AIX bare-metal servers.

The AWS Application Discovery Agent does not support IBM AIX, and the Agentless Collector only runs on VMware vSphere. Therefore, configuration and performance data for these servers must be imported using the CSV file template.

Allows capturing legacy bare-metal server inventory without unsupported agent installations.

Determine the tracking mechanism for both AWS and third-party tools.

Integrate supported third-party tools with AWS Migration Hub and associate the discovered servers with applications.

Provides a single console to track all migration progress.

Key Concept

Differentiating between AWS Application Discovery Service Agent-based and Agentless discovery mechanisms based on OS compatibility, virtualization environment, network connectivity requirements, and the depth of data (process and network dependencies) needed, and using Migration Hub to integrate and track migrations.

Question 380Question →

A company uses a centralized tooling account to host AWS CodePipeline, which automates application infrastructure deployments across multiple target AWS accounts in an AWS Organization. The pipeline uses AWS CloudFormation to deploy resources, using templates stored in an Amazon S3 bucket in the tooling account. To secure database credentials, the CloudFormation template references secret values stored in AWS Secrets Manager in the tooling account.

During a deployment run, the pipeline fails. The pipeline execution logs indicate that the CloudFormation deployment role in the target accounts cannot retrieve the template artifacts from the S3 bucket, and cannot decrypt the database credentials stored in Secrets Manager.

Which two actions should the Solutions Architect take to resolve these deployment failures? (Select two.)

Select all that apply

Update the S3 bucket policy in the tooling account to allow the deployment IAM role in the target accounts to perform the s3:GetObject action.

Use a Customer Managed Key (CMK) to encrypt the Secrets Manager secrets in the tooling account, and configure its key policy to allow the deployment IAM role in the target accounts to perform the kms:Decrypt action.

Share the default AWS-managed KMS key (aws/secretsmanager) in the tooling account with the target accounts by attaching a cross-account IAM policy to the target deployment roles.

Attach a Service Control Policy (SCP) to the target accounts' Organizational Unit (OU) that grants the deployment IAM roles permissions to read the S3 bucket in the tooling account.

Configure AWS Systems Manager State Manager to automatically perform manual API updates on the target account resources to resolve configuration errors and bypass the pipeline blocks.

Show answer & explanation

Answer: Update the S3 bucket policy in the tooling account to allow the deployment IAM role in the target accounts to perform the s3:GetObject action.; Use a Customer Managed Key (CMK) to encrypt the Secrets Manager secrets in the tooling account, and configure its key policy to allow the deployment IAM role in the target accounts to perform the kms:Decrypt action.

Answer

To resolve the deployment failures, the S3 bucket policy in the tooling account must be updated to allow the deployment roles in the target accounts to retrieve templates. Additionally, the secrets must be encrypted with a Customer Managed Key (CMK) in the tooling account, and its key policy must grant decryption permissions to the target accounts' deployment roles.

The correct options involve resolving the cross-account access issues using native IAM and resource sharing mechanisms. First, the S3 bucket policy in the tooling account must explicitly allow the target accounts' deployment roles to perform s3:GetObject to fetch the deployment templates. Second, because default AWS-managed KMS keys cannot be shared cross-account, a Customer Managed Key (CMK) must be used to encrypt the database credentials, and its key policy must be updated to allow the target accounts' deployment roles to perform kms:Decrypt.

Step-by-Step Solution

Address the template retrieval failure.

The target accounts need read access to the S3 bucket in the tooling account. This requires updating the S3 bucket policy to allow cross-account access.

Since the S3 bucket is in a different account, a resource-based bucket policy must explicitly permit the IAM roles in the target accounts to perform s3:GetObject.

Address the secret decryption failure.

Create a Customer Managed Key (CMK) in the tooling account, encrypt the secrets with it, and update the key policy to allow kms:Decrypt for the target accounts' deployment roles.

AWS-managed KMS keys (like aws/secretsmanager) are restricted to their local account and cannot be shared cross-account. A Customer Managed Key is required to delegate access.

Verify that incorrect cross-account access and drift-inducing options are eliminated.

Eliminated options using SCPs for cross-account access, AWS-managed keys for cross-account decryption, or direct configuration modification.

SCPs cannot grant cross-account permissions, AWS-managed keys are non-sharable, and direct API changes lead to CloudFormation stack drift.

Key Concept

Cross-account resource sharing, secure configuration management, and deployment automation boundaries.

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