A parks GIS tool must call AWS APIs while respecting data residency expectations for a specific Region. How should the architect think about Regions in secure access and residency design?
Select an answer to reveal the explanation.
Short Explanation
A Region is a geographic fence for many services and much of your data plane—not a suggestion. Put the GIS workloads and data where residency requires, and use normal IAM/roles for API access. There is no magic shared root password between Regions.
Full Explanation
For a parks GIS tool that must call AWS APIs while respecting data residency for a specific Region, treat Regions as isolation and placement boundaries. Choose the Region that meets residency and latency expectations, create resources there, and point SDK clients at that Region's endpoints. Identities remain IAM roles or federated principals—global IAM directory with Region-scoped resources—not a fictional global password file. Cross-Region access uses normal credentials and resource policies where supported; it does not require sharing root between Regions.
Claiming all Regions share one global IAM password file that applications download invents a non-existent mechanism. Saying Region choice has no relationship to where data and service endpoints reside ignores the fundamental geographic isolation of most AWS data planes. Asserting that cross-Region access always requires sharing root credentials is false and dangerous.
Exam caveat: some services and features are regional, some global (IAM, Route 53, CloudFront); know which is which for residency discussions. Replication (S3 CRR, Aurora Global) explicitly moves or copies data—enable only with policy approval. Operational check: deploy the GIS stack in the approved Region; confirm bucket and database ARNs include that Region; attempt creation in a disallowed Region and block via SCP (aws:RequestedRegion) if residency must be enforced preventively.