City auditors ask whether every AWS migration must be a blind lift-and-shift of every server. How should the Cloud Practitioner respond about migration strategies?
Select an answer to reveal the explanation.
Short Explanation
Lift-and-shift is one tool in the toolbox, not the only wrench in the shop. Some systems rehost cleanly; others need data or database replication patterns, refactoring, or a different path. Auditors hear “we pick the strategy that fits,” not “we chant one slogan for every rack.”
Full Explanation
Migration strategies should fit the workload—including rehosting when appropriate and data or database replication patterns—not one slogan for every system. City auditors should hear that Cloud Practitioner guidance rejects a blind lift-and-shift mandate for every server.
Only lift-and-shift allowed with replication out of scope is false. Rewriting every server as a mobile app before cutover is not required. Forbidding all migrations until hardware depreciates to zero is a finance extreme, not an AWS migration rule.
Exam caveat: Multiple migration approaches exist; match strategy to workload. Operational check: classify municipal systems (rehost, replatform, refactor, retire, retain, etc. at an appropriate depth), pick data movement patterns per class, and document auditor-facing rationale.
Municipal teams should keep a one-page decision record linking this Cloud Practitioner concept to resident outcomes, revisit it after major traffic or compliance changes, and ensure runbooks still match the chosen design.
Municipal teams should keep a one-page decision record linking this Cloud Practitioner concept to resident outcomes, revisit it after major traffic or compliance changes, and ensure runbooks still match the chosen design.