Migration practice questions

Amazon Cognito

Why wrong: Designed for web and mobile identity federation, not Windows Authentication.

AD Connector

Why wrong: Only proxies to on-premises AD, not suitable if on-prem AD is decommissioned.

Simple AD

Why wrong: Does not support Windows Authentication or many AD features needed.

Provision a Direct Connect connection to increase bandwidth

Why wrong: Direct Connect improves bandwidth but still may not transfer 50 TB in 5 days, and provisioning takes time.

Use AWS DMS with full load and change data capture (CDC) online

Why wrong: Online transfer at 100 Mbps would take ~46 days, exceeding the 5-day window.

Use AWS Schema Conversion Tool (SCT) to convert schema, then DMS for data

Why wrong: SCT only handles schema conversion; data transfer still over the wire.

Use an RDS read replica and promote it

Why wrong: RDS read replica requires an existing RDS instance; not suitable for initial migration.

Stop the database, take a mysqldump, and restore to RDS

Why wrong: Requires substantial downtime during dump and restore.

Use AWS Schema Conversion Tool (SCT) to migrate the schema and data

Why wrong: SCT converts schema; data migration still needs a separate tool like DMS.

Disable LOB support in the DMS task

Why wrong: May truncate or lose LOB data, which is not acceptable.

Split the migration into multiple smaller tasks

Why wrong: Reduces per-task load but may still hit memory limits; scaling instance is more direct.

Increase the memory of the source EC2 instance

Why wrong: DMS memory error is on the replication instance, not the source.

Assign an Elastic IP to each EC2 instance

Why wrong: Clients would need to whitelist multiple IPs, and instances behind ALB are not directly accessed.

Use Route 53 latency-based routing to point to the ALB

Why wrong: ALB DNS name resolves to dynamic IPs; not suitable for static whitelisting.

Use AWS Global Accelerator to get two static IP addresses

Why wrong: Possible but overkill; NLB with Elastic IP is simpler and cost-effective.

Use a single DMS task with full LOB mode

Why wrong: Full LOB mode can slow down migration; limited parallelism.

Use S3 multipart upload for the data

Why wrong: DMS does not use S3 internally for data transfer.

Disable transaction logging on the source

Why wrong: Disabling logging would compromise data integrity and CDC.

Retire: Decommission the application as it is no longer needed

Why wrong: The application is critical, so retirement is not appropriate.

Retain: Keep the application on-premises

Why wrong: The company plans to migrate, so retain is not the goal.

Use AWS Database Migration Service (DMS) with a custom endpoint.

Why wrong: DMS only supports specific database engines; a proprietary database is not supported.

Export the database as a flat file, upload to Amazon S3, and import into Amazon RDS.

Why wrong: This approach involves significant downtime and manual steps, not automated.

Use AWS Snowball to transfer database backups, then restore in Amazon RDS.

Why wrong: Snowball is a offline data transfer tool, not suitable for minimal downtime migration.

Revert the migration and keep the application on-premises with a VPN connection to AWS for other services.

Why wrong: This does not solve the migration goal and adds complexity with potential latency.

Provision a Dedicated Host and associate the instance with it to control hardware IDs.

Why wrong: Dedicated Hosts are more expensive and provide physical server control, but not a flexible solution for a single application.

Modify the application's license file to accept the new hardware ID.

Why wrong: This is likely a breach of the license agreement and may cause legal issues.

Amazon CloudFront

Why wrong: CloudFront is a content delivery network, not suitable for routing traffic between environments.

AWS Global Accelerator

Why wrong: Global Accelerator improves performance but does not provide native blue/green routing capabilities.

Application Load Balancer (ALB)

Why wrong: ALB distributes traffic to targets within a single environment, not between blue and green.

Use AWS DataSync over the existing internet connection.

Why wrong: 1 Gbps bandwidth would take too long (approx 48 days) and DataSync is not optimized for such large volumes.

Order a dedicated AWS Direct Connect circuit at 10 Gbps and use AWS DataSync.

Why wrong: Direct Connect setup takes weeks and is expensive; DataSync may still be slower than Snowball for this volume.

Use Amazon S3 Transfer Acceleration to speed up the transfer over the internet.

Why wrong: Transfer Acceleration improves speed but not enough to transfer 500 TB in 3 weeks over 1 Gbps.

Use AWS Database Migration Service (DMS) to migrate to Amazon RDS in a single-AZ deployment, then manually take snapshots.

Why wrong: Single-AZ RDS does not provide automatic failover; manual snapshots lead to longer downtime.

Migrate the database to a single large Amazon EC2 instance using AWS Application Migration Service.

Why wrong: A single instance is a single point of failure, no high availability.

Migrate to Amazon RDS with Multi-AZ deployment and use DMS for initial load.

Why wrong: DMS is used for initial migration, but Multi-AZ provides HA; however, DMS is not needed if using native RDS restore, but this option is plausible but not the best because DMS adds complexity.

Rehost the Oracle database on an Amazon EC2 instance to minimize changes.

Why wrong: Rehosting does not achieve the goal of migrating to Aurora PostgreSQL; it keeps Oracle.

Configure Amazon Aurora PostgreSQL with Multi-AZ for high availability.

Why wrong: Multi-AZ is important but does not address the migration from Oracle to PostgreSQL.

Export Oracle database as dump files and import into Aurora PostgreSQL using native tools.

Why wrong: Native Oracle tools cannot directly import into PostgreSQL; schema conversion is needed.

Convert the application to run on Amazon Linux 2 to simplify future management.

Why wrong: Converting to Amazon Linux would require significant rework and testing, not a simple migration step.

Use AWS Database Migration Service (DMS) to migrate the application server.

Why wrong: DMS is for databases, not for migrating entire servers or applications.

Use AWS Global Accelerator with the Application Load Balancer as an endpoint.

Why wrong: Global Accelerator provides static IPs but is overkill and more expensive for this simple requirement.

Use an Application Load Balancer and assign Elastic IP addresses to it.

Why wrong: ALB does not support Elastic IP assignment; it uses dynamic IP addresses.

Launch EC2 instances with Elastic IPs and place them behind a NAT Gateway.

Why wrong: This does not provide load balancing and high availability; NAT Gateway is for outbound traffic.

Configure binary logging on the target MySQL RDS instance.

Why wrong: The error is about the source Oracle database, not the target MySQL.

Stop and restart the DMS task to clear the error.

Why wrong: Restarting without fixing the logging will cause the same error again.

Switch the target database to Amazon RDS for Oracle to maintain compatibility.

Why wrong: Changing the target engine is not required; the issue is with source logging.

Use AWS DataSync to transfer data over the Direct Connect connection in multiple concurrent tasks.

Why wrong: At 1 Gbps, 500 TB would take approximately 46 days, exceeding the 30-day window.

Use a single AWS Snowball Edge device and copy data incrementally.

Why wrong: A single Snowball Edge device has limited storage (up to 80 TB), requiring multiple shipments; using multiple devices in parallel is more efficient.

Use S3 Transfer Acceleration to speed up transfers over the internet.

Why wrong: Transfer Acceleration optimizes internet paths but still limited by the 1 Gbps Direct Connect; not enough for 500 TB in 30 days.

The RDS instance's backup window is causing database connections to drop.

Why wrong: Backups do not cause frequent disconnections; RDS handles backups transparently.

The application's session timeout setting was reduced during migration.

Why wrong: No code changes were made, so timeout settings remain unchanged.

The security group for the web server is blocking inbound session cookies.

Why wrong: Security groups control network traffic, not application-level session cookies.

Use AWS DMS with a full load only, without ongoing replication, and schedule a cutover window.

Why wrong: Without ongoing replication, changes after the full load are not replicated, causing data loss or extended downtime.

Take a full database dump using mysqldump and import it into an Amazon RDS for MySQL instance during a planned maintenance window.

Why wrong: This causes significant downtime during the export/import process.

Create an Amazon RDS for MySQL read replica from the on-premises database.

Why wrong: RDS read replica does not support replication from an on-premises database; it only works within AWS.

The instance was stopped instead of terminated, and the persistent data volume was detached during the stop.

Why wrong: Stopping an instance does not delete volumes; the volume would still exist.

The persistent data volume (vol-0f1e2d3c4b5a67890) had DeleteOnTermination set to false, but the administrator inadvertently changed it before termination.

Why wrong: The exhibit shows DeleteOnTermination is false for that volume, so it should not be deleted upon termination.

The persistent data volume was not properly attached to the instance before termination.

Why wrong: The exhibit shows the volume is attached with status 'attached'.