A regional shared-services proposal would store citizen identity attributes in a cloud region outside the jurisdiction’s residency rules. How should architecture treat that constraint?
Select an answer to reveal the explanation.
Short Explanation
Where the filing cabinet sits is part of the design, not a footnote. Residency rules are hard constraints—architecture has to place citizen data where the law allows.
Full Explanation
Data residency and regulatory constraints are first-class architecture inputs for citizen identity attributes, not optional preferences. When a regional shared-services proposal would place identity data outside the jurisdiction’s residency rules, architecture must shape storage location, processor selection, and replication topology to remain compliant. Treating residency early prevents non-compliant designs, emergency migrations, and loss of public trust. Ignoring residency because latency benchmarks look attractive subordinates legality to performance theater. Treating residency as a soft preference procurement can waive silently undermines policy controls and creates hidden legal exposure. Moving all citizen data offshore first and negotiating legality afterward inverts due diligence and can create irreversible compliance failures. Exam caveat: residency rules vary by jurisdiction and data class; architecture must map the specific obligation to eligible regions and controls rather than assuming “cloud” automatically satisfies local policy. Operational check: document residency requirements for citizen identity attributes, verify proposed regions and subprocessors against that matrix before design approval, block replication paths that exit allowed boundaries, and retain evidence in the architecture package for audit.