Municipal CI service accounts should follow a Zero Trust-aligned secrets stance. Which choice best reflects that?
Select an answer to reveal the explanation.
Short Explanation
Zero Trust for CI means every job proves who it is and only gets the keys for its task—like badge readers on every floor, not a master key under the mat. Shared domain-admin is the opposite.
Full Explanation
Municipal CI service accounts aligned with Zero Trust should use least-privilege, continuously verified CI identities with narrow scopes. Zero Trust rejects standing broad trust based on network location or a one-time login; each pipeline identity proves itself and receives only the permissions required for its job. City automation should prefer per-pipeline roles, short-lived credentials, and ongoing verification rather than shared superuser cloud roles.
Granting every pipeline a shared domain-admin cloud role fails by concept: it maximizes blast radius and violates least privilege for convenience. Disabling identity checks after the first successful job of the day fails continuous verification—the “trusted for the rest of the day” model is the opposite of Zero Trust. Storing one root credential in plaintext on all runners fails both secrecy and identity separation.
Exam caveat: Zero Trust for CI does not mean blocking all automation; it means authenticating and authorizing every action with minimal scope. Do not equate “lots of IAM roles” alone with Zero Trust if those roles are still wildly over-privileged.
Operational check: inventory CI service accounts, replace shared admin roles with job-scoped roles, require federation or short-lived tokens, alert on privilege escalation and root credential presence on runners, and review municipal pipeline permissions on a fixed cadence.