Two counties will federate a shared 911 platform on AWS. Each county's call-data plane must remain isolated even though some platform services are shared. Which multi-account approach best fits?
Select an answer to reveal the explanation.
Short Explanation
Two counties sharing a 911 platform still need separate evidence lockers. Put each county's data plane in its own accounts and OUs, and share only the agreed platform pieces — not the whole keyring.
Full Explanation
Two counties federating a shared 911 platform on AWS should isolate each county’s call-data plane with separate accounts and an OU strategy while sharing only agreed platform services. Separate accounts keep CAD databases, recordings, and county-specific IAM boundaries apart even when shared services such as common networking or identity components are consumed centrally. That model preserves sovereignty over sensitive call data while still allowing a federated platform team to operate shared capabilities.
Storing both counties’ CAD databases in one shared account with no IAM boundaries collapses isolation and complicates legal and operational ownership during incidents. Using a single OU and identical SCPs with no per-county account isolation fails to express data-plane separation. Granting both counties root on every account in the federation for faster outages maximizes mutual risk rather than containing it.
Exam caveat: multi-account isolation is the default answer when multiple political jurisdictions share a platform but must keep data planes separate. Operational check: place each county’s data accounts in distinct OUs, share only approved platform services via RAM or PrivateLink, verify cross-county database access is denied by default, and rehearse an incident where only one county’s account is in scope.