The platform team wants security controls to travel with infrastructure and app deployments automatically. Which approach fits?
Select an answer to reveal the explanation.
Short Explanation
If the platform can rebuild itself from code, security rules should hitch the same ride. Policy-as-code keeps guardrails versioned, reviewable, and repeatable across city environments. Manual quarterly folklore does not scale.
Full Explanation
Encoding security policy as code in infrastructure and application platforms—policy-as-code—lets guardrails version, review, test, and deploy alongside the systems they protect. When platforms rebuild from code, security rules for encryption, network exposure, identity bindings, and deployment constraints should travel automatically rather than depending on quarterly tribal knowledge. This approach fits municipal platform teams seeking consistent, repeatable enforcement across environments.
Relying only on quarterly manual spreadsheet reviews of firewall rules is slow, error-prone, and drifts from actual deployed state between reviews.
Carving exceptions permanently into production with no expiry accumulates technical debt and silent risk; exceptions need owners and time boxes.
Disabling automated policy checks to accelerate every merge removes the very guardrails policy-as-code provides and recreates snowflake drift.
Exam caveat: policy-as-code is the modern expression of embedding security into automated delivery—not manual periodic spreadsheet control alone. Operational check: express critical baselines in OPA/Sentinel/cloud policy or equivalent, gate merges and deploys on policy results, review policy changes like application code, and sunset temporary exceptions with calendar reminders for city platform owners.