Accelerate Workload Migration and Modernization practice questions

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

Why it fails: 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 it fails: 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 it fails: WAF is for web application firewall, not session state management.

AWS OpsWorks for Chef Automate

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

AWS Server Migration Service (SMS)

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

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

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

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

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

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

Why it fails: Rearchitecting is too disruptive for minimizing refactoring.

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

Why it fails: 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 it fails: Incorrect. DDL changes are not fully replicated by DMS, but this typically causes task failures or errors, not target unresponsiveness. The task would usually fail rather than cause the target to become unresponsive.

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

Why it fails: Incorrect. Full LOB mode is supported with ongoing replication for Oracle to Aurora PostgreSQL. It may affect performance but does not cause the target to become unresponsive.

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

Why it fails: Incorrect. Storage full would cause write failures, but typically not immediate unresponsiveness. Additionally, Aurora auto-scales storage, making this less likely unless storage limits are reached.

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

Why it fails: A native backup and restore moves the bulk data, but DMS ongoing replication cannot resume from that restored state without the log sequence continuity, so change tracking breaks. It is tempting because native backup and restore is the standard minimal-downtime bulk migration method for large SQL Server databases.

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

Why it fails: Resizing the source instance does not clear the full transaction log; the log fills because DMS replication holds transactions open, so a larger instance changes nothing. It is tempting as vertical scaling addresses resource exhaustion, which would be correct for genuine CPU or memory pressure.

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

Why it fails: Batch-optimized apply mode changes how DMS writes to the target, not how it reads the source log, so the source transaction log still fills. It is tempting because batch-optimized apply genuinely improves target-side throughput during large migrations, which is a different bottleneck.

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

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

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

Why it fails: License-included is more expensive.

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

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

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

Why it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: Native MySQL replication to Aurora is not supported from on-premises; it requires an Amazon RDS MySQL instance as a source.

Amazon EC2: Run code without provisioning or managing servers, event-driven execution.

Why it fails: Incorrect — this describes AWS Lambda, not EC2. EC2 requires server provisioning and management.

VPC: A service that provides a dedicated physical network for your account.

Why it fails: Incorrect — VPC is a virtual network, not a physical one. This describes a hypothetical dedicated physical network.

Internet Gateway: Allows instances in a private subnet to access the internet.

Why it fails: Incorrect — this describes a NAT Gateway, not an Internet Gateway. Internet Gateway is used for public subnets.

Create an AMI of the instance every 15 minutes and launch a new instance from the latest AMI in case of failure.

Why it fails: AMI snapshots every 15 minutes cannot deliver a 15-minute RPO, since recovery restores the last completed AMI and loses all data written since it was taken. It is tempting because AMIs are simple and low-overhead, and they suit coarse RTO/RPO targets, but continuous replication is required here.

Deploy the workload on Amazon RDS Multi-AZ and enable automatic failover.

Why it fails: The workload runs on EC2 with an EBS volume, so RDS Multi-AZ addresses database failover, not instance or volume recovery. It is tempting because Multi-AZ gives automatic failover with minimal overhead, but that mechanism applies to managed database engines, not a standalone EC2 workload.

Use AWS Elastic Disaster Recovery to continuously replicate the EC2 instance to another Region.

Why it fails: AWS Elastic Disaster Recovery continuously replicates to a staging area, but recovery requires launching instances in the target Region, which typically completes within minutes yet demands ongoing replication-server management and drill maintenance. It suits cross-Region disaster recovery for large fleets, not a single instance needing 15-minute RPO with least operational overhead.

The security group for the application servers does not allow inbound traffic on port 389.

Why it fails: Port 389 blocking would prevent LDAP binds, but AWS Managed Microsoft AD requires the application to resolve the domain via the directory's DNS servers; authentication failures typically stem from DNS misconfiguration, not the security group. Port 389 rules matter when a client must reach a directory over LDAP.

AWS Managed Microsoft AD does not support LDAP queries.

Why it fails: AWS Managed Microsoft AD is a genuine Microsoft AD implementation and does support LDAP queries, so this claim is factually false. It is tempting because managed services often restrict protocols, but LDAP is a core AD capability the service exposes.

The application is not configured to use the correct DNS servers for the AWS Managed Microsoft AD domain.

Why it fails: DNS is typically correctly configured during setup.

Use the Amazon Redshift COPY command to load data directly from the on-premises storage.

Why it fails: The COPY command loads delimited or columnar files but cannot read a proprietary columnar format directly, so transformation is still required. COPY is the right choice when source data already sits in a supported format such as CSV, JSON, or Parquet.

Use AWS Database Migration Service (DMS) to migrate the data directly to Redshift.

Why it fails: DMS replicates rows between supported database engines and does not translate a proprietary columnar storage format, so transformation effort remains. DMS is correct when migrating between compatible relational databases where schema conversion, not file format, is the concern.

Use Amazon Kinesis Data Firehose to stream the data to Redshift.

Why it fails: Kinesis Data Firehose ingests streaming data, not static files from a proprietary columnar format, so it cannot directly load the existing on-premises dataset without first converting it into a stream-compatible format, which contradicts the requirement to minimise transformation effort. It is tempting because Firehose is commonly used for near-real-time ingestion into Redshift, and would be correct if the source were a continuous stream of structured records rather than a bulk migration of pre-existing columnar data.

Rehost the application, but replace the database with a SaaS alternative.

Why it fails: Replacing the database with SaaS does not rehost the application; the proprietary schema and queries would break unless the app is rewritten, which is replatforming. SaaS substitution fits scenarios where the database is generic and the business accepts vendor-managed data.

Refactor the application to use a different database engine that is supported by Amazon RDS.

Why it fails: Refactoring forces a database engine change, which the proprietary schema and application code cannot support without substantial redevelopment. It is tempting because refactoring suits applications being modernised for cloud-native features, such as replacing an unsupported engine when rewriting is already planned. Here the goal is minimising licensing costs, not re-engineering the CRM.

Use AWS Database Migration Service (DMS) to migrate the database to Amazon RDS.

Why it fails: DMS cannot migrate to RDS a proprietary engine RDS does not support; no compatible target exists. DMS is correct when source and target engines are both supported, such as Oracle or SQL Server into Amazon RDS or Aurora.

VPC Peering.

Why it fails: VPC peering connects two VPCs privately; it cannot route traffic to an on-premises network over Direct Connect. A virtual private gateway or transit gateway terminates the Direct Connect link. Peering is correct when joining VPCs across accounts or Regions, not for hybrid on-premises connectivity.

Internet Gateway (IGW).

Why it fails: An internet gateway routes traffic between a VPC and the public internet, not across a Direct Connect connection to on-premises systems. Using it would expose traffic publicly rather than keeping it on the private dedicated link. An IGW is correct for public-facing subnets hosting internet-accessible resources.

AWS Transit Gateway.

Why it fails: Transit Gateway is for connecting multiple VPCs.

Enable Multi-AZ deployment for the RDS instance to automatically failover.

Why it fails: Multi-AZ failover addresses availability of the database instance, not the hard-coded IP problem; the application still points at one address. Multi-AZ is the right step when resilience against AZ failure is the requirement, independent of connection abstraction.

Assign an Elastic IP address to the RDS instance for consistent connectivity.

Why it fails: An Elastic IP is a static public address tied to one instance, so failover still breaks connectivity and the hard-coded address remains. Elastic IPs suit publicly reachable instances needing a fixed address, not internal database endpoints behind DNS.

Amazon S3 with S3 File Gateway.

Why it fails: S3 File Gateway presents S3 buckets over NFS or SMB, so it can replace the NFS server for file access. However, it still requires deploying and managing a gateway appliance, which conflicts with the requirement to minimise operational overhead; the fully managed alternative removes that appliance entirely. It suits hybrid access to S3 data from on-premises clients.

AWS Storage Gateway File Gateway.

Why it fails: AWS Storage Gateway File Gateway provides NFS and SMB access with local caching, but it runs as a virtual or hardware appliance the company must deploy, patch and monitor. That operational burden contradicts the minimise-overhead requirement, which a fully managed file service satisfies without any gateway infrastructure to maintain.

Amazon EBS with a shared snapshot.

Why it fails: EBS volumes attach to a single EC2 instance in one Availability Zone, and snapshots are point-in-time copies, not a concurrently mounted shared file system. Multiple batch nodes cannot read and write the same files through a snapshot, so it cannot replace NFS. EBS suits single-instance block storage, not shared file access.

The EC2 instance does not have an IAM instance profile.

Why it fails: The stem states the IAM role is already attached to the instance, so a missing instance profile is not the cause. It is tempting because a missing instance profile is a common reason EC2 applications cannot assume a role, and would be correct if no role were attached at all.

The policy does not allow the s3:ListBucket action.

Why it fails: s3:ListBucket governs listing bucket contents, not reading individual objects, so its absence does not block GetObject calls. It is tempting because ListBucket is often paired with read access, and would be correct if the application needed to enumerate objects before reading them.

The S3 bucket policy denies access.

Why it fails: The IAM policy alone governs the role's permissions; a bucket policy is a separate resource-based control that can explicitly deny access even when IAM allows it, so this is a genuine possible cause rather than the most likely one. It is tempting because cross-account or explicit-deny bucket policies do override IAM, but the stem gives no evidence of one.

The CloudFormation template has a syntax error.

Why it fails: A syntax error would fail template validation before any resources are provisioned, so no stack events would appear. It is tempting because malformed YAML is a common CloudFormation failure, but the exhibit shows resources being created and then failing during provisioning.

The IAM role for the Lambda function does not have sufficient permissions.

Why it fails: Insufficient Lambda execution role permissions would surface as an AccessDenied error from the function's own API calls, not as a resource creation failure. It is tempting because IAM misconfiguration is frequent, but the events point to a different resource failing during stack provisioning.

The Lambda function code exceeds the maximum size limit.

Why it fails: Lambda code size limits are enforced at deployment; an oversized package fails during upload or update, not mid-stack creation. It is tempting because deployment packaging errors are common, but the exhibit's events indicate a different resource failing, not a code-size rejection.

The lifecycle policy has a filter that excludes these objects.

Why it fails: A lifecycle filter scoping the rule to specific prefixes or tags would leave unmatched objects in S3 Standard indefinitely. The option tempts because filters commonly cause transitions to be skipped, but the exhibit would need to show one. Without evidence of a filter, this explanation is unsupported.

The lifecycle policy is not enabled for the bucket.

Why it fails: S3 lifecycle rules are active once saved; there is no separate enablement step for a bucket policy. The option tempts because disabled rules are a common misconfiguration elsewhere, but S3 applies lifecycle configurations immediately. The exhibit's actual cause lies in the rule's filter or transition timing.

The S3 bucket versioning is disabled, so lifecycle rules do not apply.

Why it fails: Versioning is not required for lifecycle transitions.