Migrated county department apps still depend on corporate identities and group policies after cutover. What identity approach should architects decide as part of the migration plan?
Select an answer to reveal the explanation.
Short Explanation
Apps that suddenly cannot log anyone in are not 'migrated'—they are broken. Nail IAM Identity Center and Directory Service plans before cutover so badges still open doors in the new building.
Full Explanation
Migrated county department apps that still depend on corporate identities and group policies after cutover require an explicit identity decision in the migration plan. Decide IAM Identity Center and AWS Directory Service strategies so authentication keeps working for migrated apps and staff retain familiar AD-backed access patterns across departments. Deleting all directories and forcing every user onto shared local OS accounts fails security, auditability, and operational sanity for a county workforce. Hard-coding IAM user passwords into each application configuration file fails secret hygiene and does not replace directory group policy needs. Postponing all identity decisions until six months after production cutover fails because cutover night is when authentication breaks become citizen-facing outages. Exam caveat: identity and directory strategy is part of migration planning, not a post-go-live optional. Operational check: choose Identity Center for AWS access federation, select Directory Service or AD Connector patterns for app domain join needs, pilot with one department account, validate group policies and MFA, then apply the pattern before subsequent waves. Document the decision in the municipal architecture decision record and re-verify controls after the first production wave so auditors see continuous improvement, not one-time tribal knowledge.