AWS Solutions Architect Professional Accelerate Workload Migration and Modernization: 205 practice questions

12 of the 205 Accelerate Workload Migration and Modernization questions in the Certsqill AWS Solutions Architect Professional bank, shown in full below. Each one carries an explanation for every option, not just the correct one — the wrong answers are where the marks go.

Preparing for AWS Solutions Architect Professional? Take the free 5-min readiness check →

1. Deploy recommendations separately: Which architecture best limits migration scope?

1. Deploy recommendations separately, route calls there, and queue viewing events. ✓

   A separate service enables independent deployment, selective routing preserves the monolith, and a queue handles delay-tolerant events.
2. Publish recommendation calls to SNS and have playback clients consume the topic.

   SNS supports asynchronous notification, not the required synchronous recommendation request-response path.
3. Replicate the monolith and shift all traffic with weighted DNS.

   This broad cutover does not isolate recommendations and can affect unrelated playback functions.
4. Move the monolith to Lambda while keeping synchronous recommendation database calls.

   This expands migration scope and leaves recommendation processing coupled to synchronous application behavior.

Extract recommendations behind a service boundary and queue delay-tolerant events.

2. Separate applications into waves using dependency groups: Which TWO actions should the architect require befor

Select two. More than one option is correct — every correct one is ticked below.

1. Separate applications into waves using dependency groups, with explicit cutover and rollback criteria. ✓

   Dependency-based waves reduce coupled failure domains and make success, rollback, and validation decisions measurable.
2. Place all database users in one wave so shared credentials migrate together.

   Credential grouping does not prove transactional compatibility, network reachability, or application sequencing requirements.
3. Group applications by operating-system version, then migrate each group independently.

   Operating-system similarity does not establish application dependency boundaries or prove that shared data and batch prerequisites are ready.
4. Approve the existing wave after owners confirm that every server has current operating-system patches.

   Patching improves readiness but does not resolve undocumented dependencies, shared data sequencing, or rollback boundaries.
5. Inventory runtime, data, batch, and hostname dependencies, recording owners and validation evidence. ✓

   Dependency inventory exposes hidden prerequisites and assigns accountability for validating each relationship before migration.

Dependency evidence and dependency-based waves are both required to expose boundaries and support reversible cutovers.

3. Authentication still depends on reachable directory: Which residual risk should the architect identify?

1. Encryption at rest prevents concurrent file sharing.

   Encryption protects stored data and does not prevent authorized clients from sharing files concurrently.
2. Authentication still depends on reachable directory services during outages. ✓

   SMB authentication and authorization depend on Active Directory, so a directory-service disruption can block access even when FSx remains healthy.
3. Multi-AZ deployment prevents access from another Availability Zone.

   A Multi-AZ FSx deployment supports highly available access across Availability Zones.
4. Scheduled backups guarantee recovery from every accidental overwrite without data loss.

   Backups provide recovery points, but their schedule and restoration process do not guarantee zero data loss.

SMB access still depends on reachable Active Directory.

4. Configure prerequisites: Which TWO actions form the appropriate sequence?

Select two. More than one option is correct — every correct one is ticked below.

1. Use an untested read replica as the rollback target.

   A replica without compatibility, application, and rollback testing does not satisfy the tested rollback requirement.
2. Configure prerequisites, run full load and CDC, validate counts and lag, then briefly pause writes for cutover. ✓

   Connectivity, permissions, log retention, and compatibility enable DMS; full load plus CDC and validation establish convergence before a controlled write pause and cutover.
3. Rehearse rollback to the preserved source or target point before cutover. ✓

   A documented and tested rollback rehearsal establishes the required rollback point rather than assuming replication alone is reversible.
4. Cut over when replication starts, then repair historical gaps with CDC.

   Replication startup does not prove full-load completeness, and post-cutover repair risks inconsistent data.
5. Stop writes immediately and copy the database with DataSync.

   DataSync is not general relational transaction replication, and an immediate stop violates the minimal-downtime requirement.

Rehearse rollback, then validate DMS full load and CDC before cutover.

5. Write the order and event intent transactionally: Which change best addresses this limitation?

1. Write the order and event intent transactionally, then process reservations idempotently. ✓

   A transactional outbox closes the local database-publication gap, while idempotent reservation handling makes duplicate delivery safe.
2. Publish through EventBridge and rely on target retries to prevent duplicate inventory reservations.

   Target retries can produce repeated delivery attempts, so inventory processing still needs idempotency and the raw dual-write gap remains.
3. Use a distributed transaction across the marketplace database and the independently owned inventory service.

   The asynchronous service boundary does not automatically provide a shared distributed transaction, and this approach does not represent the stated decoupled pattern.
4. Use FIFO delivery and remove consumer retries to minimize duplicate reservations.

   FIFO ordering and deduplication do not close the database-to-publication failure window or guarantee exactly-once external inventory effects.

Use a transactional outbox and idempotent inventory processing.

6. Add a shared durable session store and configure: Which missing component should the architect add?

1. Increase each instance’s local-disk capacity.

   More local capacity does not preserve sessions when instances are replaced or requests reach another Availability Zone.
2. Add a shared durable session store and configure the application to use it. ✓

   Externalized sessions let replacement instances serve users consistently while preserving the low-change rehost approach.
3. Run another Auto Scaling group with the same image in a second Availability Zone.

   Additional instances improve capacity but retain isolated local sessions and reproduce the measured failure.
4. Add weighted DNS records to shift checkout traffic between instances.

   DNS distribution changes routing but cannot provide shared session state or reliable replacement behavior.

Externalize sessions into shared durable state before enabling instance replacement.

7. Permit NFS from application nodes to EFS mount targets: Which TWO actions should the architect take?

Select two. More than one option is correct — every correct one is ticked below.

1. Replace files with S3 objects and rewrite file operations.

   S3 is object storage and requires application changes excluded by the requirements.
2. Use One Zone EFS in its single Availability Zone.

   One Zone EFS can provide file semantics but cannot provide the required cross-zone resilience.
3. Permit NFS from application nodes to EFS mount targets. ✓

   Security groups must allow NFS traffic, after which the nodes can mount the Regional EFS file system.
4. Create Regional EFS and mount it from application nodes. ✓

   Regional EFS provides shared NFS/POSIX-style access across Availability Zones without changing file semantics.
5. Attach one EBS volume to each node for shared access.

   EBS is AZ-scoped block storage and separate volumes do not provide shared filesystem semantics.

Use Regional EFS and permit NFS access.

8. Assess and convert the schema: Which prerequisite should occur before configuring production full load and CDC

1. Increase target capacity so incompatible SQL runs unchanged.

   Capacity cannot resolve incompatible data types, stored procedures, or engine-specific SQL semantics.
2. Start CDC and fix issues after cutover.

   CDC moves changes but does not convert incompatible schema objects or application code.
3. Copy database files with DataSync for target-engine interpretation.

   DataSync transfers supported storage data; it does not perform engine-aware schema conversion or transaction replication.
4. Assess and convert the schema, remediate issues, and validate behavior. ✓

   Assessment and conversion expose engine differences so schema objects and application behavior can be remediated and tested before production migration.

Assess and convert engine-specific schema elements before production DMS replication.

9. Use Step Functions with service-owned: Which architecture best meets these constraints?

1. Use Step Functions with service-owned, idempotent compensations. ✓

   Step Functions provides one orchestration mechanism for progress, retries, and error handling, while services own safe compensating actions and idempotency.
2. Use distributed transactions across all service databases.

   Separate service databases do not establish a practical shared transaction boundary, and failures still require recovery behavior.
3. Use larger instances and retry failed requests in each application thread.

   More compute and local retries do not track completed steps, coordinate compensation, or prevent repeated side effects.
4. Use SNS fan-out and let services infer required compensation.

   Independent inference lacks centralized workflow state and makes compensation ownership ambiguous after timeouts or partial completion.

Use Step Functions with idempotent, service-owned compensations.

10. Retire it after approval: After documenting the evidence, archiving any required records, and obtaining owner

1. Rehost the unused deployment on EC2 to preserve a migration option.

   Rehosting preserves an unused workload and its operational burden despite the approved replacement and absent dependencies.
2. Retire it after approval. ✓

   Verified inactivity, absent dependencies, preserved records, and owner approval support auditable retirement.
3. Replatform the unused application onto containers to reduce its operational burden.

   Modernization effort is unjustified for a verified-unused application.
4. Retain the deployment for a year despite the documented absence of dependencies.

   An arbitrary retention period adds cost without evidence of a remaining requirement.

Retire the verified-unused application after documenting evidence and preserving required records.

11. Use ECS Fargate with Regional EFS for shared files: Select TWO actions that together meet the requirements.

Select two. More than one option is correct — every correct one is ticked below.

1. Use ECS on EC2, mount EBS, and run the database on one EC2 instance.

   EBS is Availability Zone scoped, and a single database instance does not provide database durability through host or Availability Zone failure.
2. Use ECS Fargate with Regional EFS for shared files. ✓

   Fargate removes host administration, and Regional EFS provides shared Linux file access across Availability Zones. The database action must also be selected.
3. Use an RDS Multi-AZ DB instance deployment. ✓

   Classic RDS Multi-AZ DB instance deployment synchronously maintains a standby for high availability and managed failover, without making the standby readable.
4. Use EKS managed nodes, One Zone EFS, and an RDS read replica.

   Managed nodes add administration, One Zone EFS lacks cross-zone resilience, and a read replica is not the required automatic primary failover design.
5. Use Fargate ephemeral storage and DynamoDB for relational state.

   Ephemeral storage does not survive task replacement, and DynamoDB does not provide the required relational transaction model automatically.

Use Fargate with Regional EFS and a classic RDS Multi-AZ DB instance deployment.

12. Use MGN, group dependencies, test launch, sync, and cut: Which action best satisfies the rehearsal requirement

1. Use DMS to replicate operating-system volumes before switching traffic.

   DMS supports database migration and change data capture, not replication of operating-system volumes and complete application servers.
2. Copy files with DataSync and test them.

   DataSync transfers supported files, not complete server state, dependencies, or ongoing block-level changes.
3. Copy AMIs, restore them, and then switch traffic.

   AMIs are static images and do not provide continuous replication or a final synchronization from active sources.
4. Use MGN, group dependencies, test launch, sync, and cut over. ✓

   MGN supports block-level replication, dependency groups, test launches, final synchronization, and controlled cutover while sources remain available.

Use MGN with dependency groups, test launches, synchronization, and cutover.

Other AWS Solutions Architect Professional domains

• Design for New Solutions — 297 questions →
• Design Solutions for Organizational Complexity — 266 questions →
• Continuous Improvement for Existing Solutions — 256 questions →
• All 1024 AWS Solutions Architect Professional questions →
• AWS Solutions Architect Professional certification: requirements, cost and exam format →