Resilience, Migration, and Business Continuity practice questions

Dependency mapping should rest on observed network connections; inventories and interviews miss undocumented calls.

The failure came from a dependency nobody documented. Only data that observes server-to-server connections over time (from a discovery tool such as the AWS Transform discovery tool, or a third-party tool's network data imported into AWS Transform) exposes such calls before cutover. Refreshing RVTools adds no connection data, boot-level status checks don't exercise application traffic, and another questionnaire relies on the same memory that already failed.

1. Identify the root cause: a dependency missing from the planning data.
2. Ask which data source would have shown it: observed network connections.
3. Prefer fixing the planning input over adding checks that cannot see application traffic.

Exam tip: Undocumented dependencies are found by watching the network, not by asking owners or re-exporting inventories.

Waves are built from dependency groups and sequenced from low risk to high risk.

Hundreds of synchronous queries per transaction over a 25 ms link would add seconds to each transaction, so the payments application and its database form one move group. The requirement to validate runbooks first calls for a pilot wave of simple, low-dependency applications. Moving databases first or grouping by OS splits dependency groups; starting with the most valuable system skips the validation step.

1. Find chatty, latency-sensitive dependencies and keep each group together.
2. Sequence waves from low-risk pilots to business-critical systems.
3. Reject groupings by technology attribute that ignore dependencies.

Exam tip: Keep chatty dependency groups in one wave, and let a low-risk pilot wave prove the runbooks first.

Wave size is adjusted by moving independent servers, never by splitting a tightly coupled dependency group.

Two facts decide it: splitting a chatty dependency group across Direct Connect is unacceptable here, and the capacity problem comes from unrelated servers that can go anywhere. Removing them keeps the group intact and fits the weekend. Staggering applications or the database creates cross-link latency in one direction or the other. DMS bidirectional replication is meant for limited scenarios and does not resolve write conflicts, so keeping three writable copies of one transactional database is a data-integrity risk.

1. Identify the dependency group that cannot be split (applications plus shared database).
2. Find what else in the wave is independent and can move.
3. Reject designs that leave chatty traffic across the link or create conflicting writable copies.

Exam tip: Fit a wave to the cutover window by moving independent servers out, not by splitting a chatty dependency group.

Repurchase (drop and shop) moves a workload to a SaaS product when one meets the business need.

The vendor offers a SaaS edition that covers every feature in use, and the requirement is to stop operating the application. Repurchase does that. Rehost and replatform both leave the company running the CRM software, and retain changes nothing.

1. Check whether a SaaS product already meets the business need.
2. Check the operational goal: stop patching and running the software.
3. Pick the strategy that removes the software from the company's estate.

Exam tip: A SaaS edition that covers the need plus a wish to stop operating the software means repurchase.

Retire applications that are unused or duplicated, keeping only the data that must be retained.

No sign-ins for 120 days, a replacement already in place and owner confirmation point to retire. The seven-year rule applies to the data, which can be archived to low-cost storage such as an S3 archive storage class. Retain, rehost and replatform all keep spending on an application with no users.

1. Check usage and whether another system already provides the function.
2. Separate the data retention requirement from the application itself.
3. Retire the application and archive only the data.

Exam tip: Unused and duplicated: retire the application and archive its data, don't migrate it.

A migration can mix strategies per workload: rehost for speed, replatform where a managed service removes work at little change.

The deadline favours rehosting the bulk of the estate. The database goal is met only by moving the databases to a managed engine, and the stem removes the usual blockers: the extensions are supported by Aurora PostgreSQL and the endpoint is configurable, so it is a low-change replatform. Refactoring everything risks the deadline, rehosting the databases leaves the admin work, and retaining is impossible once the lease ends.

1. Identify the hard constraint (eight-month exit) and the secondary goal (less database administration).
2. Apply the fastest strategy to the bulk of the estate.
3. Apply a managed-service replatform only where the stem shows it needs no code change.

Exam tip: Rehost to hit the exit date; replatform the pieces where a managed service removes work without code change.