A building-permit system needs permissions that match clerk job duties rather than one-off exceptions. Which authorization model should be implemented?
Select an answer to reveal the explanation.
Short Explanation
Permit clerks need a job-shaped keyring, not a master key or a free-for-all. RBAC hangs the right permissions on the clerk role so everyone in that job gets a consistent, least-privilege set. Per-desk DAC favors, blanket admin, or intelligence MAC labels on permit PDFs are the wrong tools for this counter.
Full Explanation
Role-based access control maps job functions such as permitting clerk to the permissions those jobs require, then assigns users to roles. For a building-permit system that needs permissions matching clerk duties rather than one-off exceptions, RBAC delivers consistent least privilege, reviewable membership, and scalable authorization as staff join, move, and leave. Roles become the durable policy objects instead of scattered discretionary exceptions.
Discretionary access where each clerk privately decides who else may approve permits fragments policy and invites conflict-of-interest and audit failures. Unconditional administrator rights for every clerk to avoid help-desk tickets over-privileges routine work and erases separation of duties. Mandatory access control labels designed only for national intelligence classifications, applied unchanged to permit PDFs, misapplies a label-driven model built for different environments; MAC has valid uses, but transplanting intelligence schemes onto ordinary civic permitting is the wrong tool.
Exam caveat: choose the authorization model that fits the problem—RBAC for job-function municipal apps is the standard CISSP-aligned answer versus DAC sprawl, blanket admin, or misapplied MAC. Operational check: define permitting-clerk (and related) roles with least-privilege permissions, assign users via roles not one-offs, review membership, and avoid universal admin or informal discretionary approval chains.