After a least-privilege IAM change, multiple city staff report access denied to the same portal. Some peers in another group still succeed. How should the team troubleshoot authorization?
Select an answer to reveal the explanation.
Short Explanation
Access denied after a least-privilege pass usually means either the policy is too tight or people landed in the wrong group. Compare a working peer's membership and policy with a failing user's before you hand out admin rights.
Full Explanation
After a least-privilege IAM change, when multiple city staff report access denied to the same portal while some peers in another group still succeed, the team should determine whether the deny comes from an incorrect policy or from users being in the wrong group. Authorization triage separates policy bugs from membership mistakes in municipal identity systems. Granting AdministratorAccess to every municipal user as a permanent fix destroys least privilege. Disabling SSO and distributing shared local passwords regresses security. Rolling back all network ACLs in every VPC addresses the wrong control plane for portal authorization denials. Exam caveat: evaluate explicit denies, SCPs/management guards, and group inheritance—not only the single role document you just edited. Operational check: compare a failing user and a succeeding peer for group membership and policy evaluation, fix membership or policy accordingly, retest portal access, and record the authorization root cause in the change ticket. In municipal cloud operations, record the chosen control and the rejected alternatives in the change or incident ticket so future on-call staff understand which failure modes were avoided for city services. Re-validate after the next maintenance window that the same decision still holds under current provider limits, identity bindings, and application versions used by the civic platform team.