A public-safety analytics contract requires all related datasets to remain within a named metropolitan area. Which placement requirement is that?
Select an answer to reveal the explanation.
Short Explanation
Locality is the 'keep it in this zip code' rule on the contract. The datasets stay in the named metro's approved facilities—not sprayed across distant regions or a global CDN.
Full Explanation
Data locality constrains where data may be stored and processed—here, within a named metropolitan area required by a public-safety analytics contract. Placement of datasets must stay inside that agreed metro rather than drifting to distant regions for convenience. Locality protects contractual, latency, or jurisdictional expectations tied to that metro.
Unlimited cross-region replication that ignores the contract breaks locality. Storing data only on administrator laptops outside the metro fails both locality and sound custody. Publishing raw datasets to a global CDN to "meet locality" does the opposite of keeping data in-metro.
Exam caveat: locality ≠ encryption; locality ≠ sovereignty (though they can overlap). Exam stems that name a city/metro/region as a placement requirement point to locality.
Operational check: pin storage and processing resources to approved metro regions/zones, disable noncompliant replication, verify analytics job regions, and retain configuration screenshots for contract audits. Re-validate after any DR design change so failover targets remain in-contract.
Contract reviews for public-safety analytics should explicitly list allowed metro regions and forbidden replication targets; architecture diagrams must match those clauses so operators do not “fix” locality during an incident.