City shared services must host AWS Directory Service once so assessor, permitting, and fleet accounts can join domain resources without each building its own directory. Which multi-account pattern is appropriate?

City shared services should host AWS Directory Service once so assessor, permitting, and fleet accounts can join domain resources without each building its own directory. Place Managed Microsoft AD or the chosen Directory Service option in a shared services account and let workload accounts consume it through approved networking such as shared VPC attachments, Transit Gateway, or directory sharing patterns without duplicating directories. One authoritative directory reduces cost, inconsistency, and password-policy drift across municipal departments that all need domain join.

Creating a separate Managed Microsoft AD in every workload account and never trusting shared services multiplies cost and creates identity islands that break cross-department access patterns. Storing all directory passwords in a public S3 bucket that every account downloads at boot is a critical secret exposure and not a directory architecture. Replacing Directory Service with local password files on each instance abandons centralized domain join, Group Policy, and municipal identity operations that auditors expect.

Exam caveat: a shared-services account for directory is a standard multi-account pattern; workloads consume rather than recreate Active Directory. Operational check: deploy Directory Service in shared services, route workload VPCs to it, domain-join a pilot instance in assessor and permitting accounts, and confirm DNS and authentication succeed without per-account directories.