Citizen PII for a municipal benefits system must remain in-country, and several destination regions fail that rule. What migration constraint is this?
Select an answer to reveal the explanation.
Short Explanation
Picture a passport that says the files have to stay home—no overseas vacation for that data. Locality and residency rules decide which regions are even on the shortlist before you talk about cool deploy tricks.
Full Explanation
Regulatory and compliance locality rules constrain which cloud regions may host regulated citizen data such as benefits PII that must remain in-country. When several destination regions fail that residency rule, region eligibility—not latency marketing—governs migration target selection. Spot capacity preferences override all data residency laws fails because cost optimizations cannot supersede legal locality constraints. Blue-green deployment automatically satisfies sovereignty requirements fails; deployment strategy does not place data in-country by itself. Content delivery networks place PII only where latency is lowest fails and is dangerous: CDNs optimize delivery, not residency guarantees for primary PII stores. Exam caveat: residency and sovereignty are hard constraints that filter regions and providers before architecture flourishes. Operational check: map data classes to legal requirements, allowlist compliant regions in IaC policies, prevent peer replication to disallowed geographies, and evidence controls for civic auditors. In municipal platform operations, record the chosen control and the rejected alternatives in the change record so future on-call engineers understand the failure modes avoided for citizen services. Re-check the decision after the next provider feature change or compliance update to ensure the same answer still holds for the city's estate.