Accelerate Workload Migration and Modernization practice questions

AWS Application Migration Service (MGN) to Amazon EC2, and AWS DMS to Amazon DynamoDB

Why wrong: DynamoDB is NoSQL; the application expects SQL Server, requiring significant changes.

AWS Server Migration Service (SMS) to Amazon EC2, and AWS DMS to Amazon RDS for SQL Server

Why wrong: AWS SMS is deprecated; AWS MGN is the recommended migration service.

AWS CloudFormation to provision EC2 instances, and AWS DMS to Amazon RDS for SQL Server

Why wrong: CloudFormation is for automation, not migration; the question requires minimal changes, not re-provisioning.

Use Amazon Route 53 weighted routing to shift traffic to new EC2 instances, and store session state in Amazon S3

Why wrong: S3 is not designed for low-latency session state; Route 53 alone doesn't share state between on-prem and AWS.

Use AWS CloudFront to cache static content, and use Amazon DynamoDB for session state

Why wrong: CloudFront is for content delivery, not traffic shifting for dynamic stateful apps.

Use AWS Global Accelerator to shift traffic, and deploy AWS WAF to protect the application

Why wrong: WAF is for web application firewall, not session state management.

AWS Serverless Application Model (SAM)

Why wrong: SAM is for serverless applications, not for containerizing legacy .NET apps.

AWS Copilot

Why wrong: Copilot simplifies container operations but does not convert existing applications.

AWS Migration Hub

Why wrong: Migration Hub tracks progress, does not perform containerization.

Increase the memory on the source Oracle database

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

Change the DMS task to use change data capture (CDC) only and skip the full load

Why wrong: CDC only will not migrate existing data; a full load is needed.

Split the migration into multiple smaller tasks

Why wrong: Splitting would require starting over and may increase total downtime.

AWS OpsWorks for Chef Automate

Why wrong: OpsWorks manages configurations but does not perform the migration.

AWS Server Migration Service (SMS)

Why wrong: SMS is deprecated and does not support replatforming to Linux.

AWS CloudFormation templates to provision new EC2 instances and migrate data manually

Why wrong: Manual migration is not automated; CloudFormation alone does not perform replatforming.

Refactor the Node.js frontend to run on AWS Lambda with Amazon API Gateway

Why wrong: Lambda is suitable for Node.js, but the question asks for TWO strategies; the Java backend and database are better candidates for modernization.

Migrate the database to Amazon DynamoDB

Why wrong: DynamoDB is NoSQL and would require application changes.

Deploy the Java backend on Amazon EC2 with Auto Scaling

Why wrong: EC2 requires managing servers; not as modernized as Fargate.

Migrate the proprietary storage to Amazon S3

Why wrong: S3 is object storage, not suitable as a direct replacement for file-based or relational storage.

Refactor the application into microservices and deploy on Amazon EKS

Why wrong: Refactoring to microservices requires significant code changes, not minimal.

Refactor the application to .NET Core and use Amazon RDS for MySQL to eliminate Windows licensing.

Why wrong: Refactoring is significant and MySQL may not support all stored procedures.

Rearchitect the application to microservices and use Amazon DynamoDB for the database.

Why wrong: Rearchitecting is too disruptive for minimizing refactoring.

Replatform the database to Amazon Aurora with PostgreSQL compatibility to reduce licensing costs.

Why wrong: Aurora PostgreSQL would require rewriting stored procedures and may not be compatible.

The DMS task is configured to replicate DDL changes, which are not supported for Oracle to Aurora PostgreSQL.

Why wrong: DDL replication is supported for some changes; this would not cause unresponsiveness.

The DMS task is using full LOB mode, which is not supported with ongoing replication.

Why wrong: Full LOB mode is supported for ongoing replication.

The target Aurora instance's storage is full and cannot accept new writes.

Why wrong: Aurora storage auto-scales; storage full is unlikely.

Take regular backups and restore them in AWS during cutover.

Why wrong: This is backup and restore, not pilot light.

Run a scaled-down but fully functional version of the environment in AWS at all times.

Why wrong: This describes warm standby.

Run the application simultaneously in both environments and route traffic to both.

Why wrong: This describes multi-site active-active.

Refactor the SOAP web services to RESTful APIs and deploy on Amazon API Gateway and AWS Lambda.

Why wrong: Requires significant refactoring.

Containerize the application and deploy it on Amazon ECS using Fargate.

Why wrong: Containerization requires changes and adds complexity.

Use AWS Database Migration Service (DMS) to migrate the database and redeploy the application manually.

Why wrong: Does not address the application migration and has higher operational overhead.

Stop the DMS task, take a native backup of the source, restore it to RDS, and then start DMS with ongoing replication.

Why wrong: This adds complexity and may lose changes during backup/restore.

Pause the DMS task, create a larger source instance, and restart the task.

Why wrong: Larger instance may not solve log full issue; DMS still needs log space.

Switch the DMS task to use batch-optimized apply mode.

Why wrong: Batch-optimized applies changes in batches; doesn't affect log capture.

Refactor the application into microservices and use Amazon DynamoDB for data storage.

Why wrong: High refactoring effort; not directly reducing licensing costs.

Rehost the application on Amazon EC2 and use Amazon RDS for Oracle with license-included.

Why wrong: License-included is more expensive.

Rehost the application on Amazon EC2 and use Amazon RDS for Oracle with BYOL.

Why wrong: Still uses Oracle licensing; does not reduce costs.

Replace the current application tier instances with larger instance types.

Why wrong: Vertical scaling is less flexible and may not be cost-effective.

Move the MySQL database to Amazon RDS for MySQL and enable Multi-AZ deployment.

Why wrong: Multi-AZ improves availability, not CPU performance on app tier.

Retire the application and replace it with a SaaS-based solution.

Why wrong: Retiring is not an option since the application is still needed.

Refactor the application to use .NET Core and deploy on Linux containers with Amazon ECS.

Why wrong: Refactoring would require significant code changes and does not minimize re-architecture.

Replatform the application to use AWS Elastic Beanstalk with a SQL Server Express Multi-AZ RDS instance.

Why wrong: Replatforming would still require changes to the database setup and may not minimize re-architecture.

Use AWS SCT to convert the schema, then use AWS DMS with a full load task to migrate the data.

Why wrong: A full load task without CDC will cause downtime because changes made during the migration will be lost.

Use mysqldump to export the database, transfer the dump via AWS Direct Connect, and import into Aurora MySQL.

Why wrong: mysqldump requires taking the application offline during the export to ensure consistency, causing downtime.

Use the AWS Schema Conversion Tool (SCT) to convert the schema, then set up an Aurora Replica from the on-premises source using native MySQL replication.

Why wrong: Native MySQL replication to Aurora is not supported from on-premises; it requires an Amazon RDS MySQL instance as a source.

AWS Database Migration Service (DMS) to continuously replicate schema changes from the source Oracle database.

Why wrong: DMS is for data migration, not for managing schema versions in a new database.

AWS CloudFormation with custom resource Lambda functions to run SQL scripts.

Why wrong: CloudFormation is for infrastructure, not a standard database schema migration tool; custom resources add complexity.

AWS CLI scripts executed in CodeBuild to run SQL commands against the target databases.

Why wrong: Manual scripts are error-prone and not a best-practice for automated schema versioning.

Create an Aurora read replica from the on-premises database using a VPN connection.

Why wrong: Aurora read replicas cannot be created from an external on-premises database; they are for Aurora clusters.

Use AWS Schema Conversion Tool (AWS SCT) to convert the schema and then use AWS Database Migration Service (AWS DMS) with full load only.

Why wrong: AWS SCT handles schema conversion, but full load only does not minimize downtime; ongoing replication is needed.

Perform a full pg_dump of the on-premises database and restore it to Aurora using pg_restore.

Why wrong: This requires significant downtime during dump and restore; not optimal for minimizing downtime.

The DMS task is not configured to use a task log for troubleshooting.

Why wrong: Task log configuration does not cause source log file errors.

The target Redshift table does not have a primary key defined for the DMS task to apply changes.

Why wrong: Primary key is needed for CDC tasks, but missing primary key would cause a different error, not a log file full error.

The DMS task is using a full LOB mode, which is not supported for Redshift targets.

Why wrong: Full LOB mode is supported for Redshift; this would not cause a source log file full error.

Rewrite the entire application as microservices from scratch and deploy them in a new AWS environment. Cut over all traffic at once after testing.

Why wrong: This is a big-bang approach with high risk of downtime and does not leverage existing code; also likely exceeds the 6-month timeline.

Use AWS Blue/Green deployment for the monolith to reduce downtime, then migrate to microservices after the deployment is stable.

Why wrong: Blue/Green is a deployment technique, not a migration pattern from monolith to microservices; it does not address the architectural change.

Perform a lift-and-shift migration of the monolith to EC2 instances, then gradually refactor into microservices over the next year.

Why wrong: Lift-and-shift does not modernize and delays the microservices goal; also does not minimize operational overhead as desired.