A municipal cloud team assigns permissions by job role—billing viewer, network admin, backup operator—rather than writing unique ACL entries for every individual user. Which access model are they implementing?
Select an answer to reveal the explanation.
Short Explanation
Picture name badges for 'billing viewer' or 'network admin' instead of rewriting the lock list for every new hire. Stick people in the right role and they inherit the permissions that go with the job. That is RBAC—scalable, predictable, and way less messy than one-off ACLs everywhere.
Full Explanation
Role-based access control maps permissions to job functions and assigns users to those roles rather than maintaining unique per-person ACL snowflakes. A municipal cloud team that defines billing viewer, network admin, and backup operator roles is implementing RBAC so joiner/mover/leaver changes become role assignment updates. RBAC scales civic IAM with clearer audit semantics.
Mandatory physical keycards as the only control for API and portal actions ignore logical cloud authorization models. Per-object discretionary ACLs edited by hand for each new hire do not match role-centric design. Anonymous public roles that grant every citizen write access to management planes are catastrophic misconfiguration.
Exam caveat: RBAC vs ABAC vs ACL are distinct models; exam stems that emphasize job functions and reusable roles indicate RBAC. Roles should still follow least privilege.
Operational check: define a role catalog tied to municipal job functions, attach policies, assign users/groups to roles only, review quarterly for privilege creep, and avoid direct user-attached broad policies. Evidence role assignments during access audits.
Resist one-off “temporary” user policy attachments outside the role catalog; if an exception is unavoidable for a civic project, time-box it and convert it into a named role before the next access review.