Compliance means keeping infrastructure, configurations, and operations aligned with applicable security, industry, regulatory, and organizational requirements. Treating it as a late audit concern can force disruptive fixes, delay delivery, or break functionality. section 8.0
A policy expresses the rules and standards used to achieve compliance. Policy as code turns those rules into repeatable tests that inspect infrastructure configuration or system state before production. section 8.0 section 8.3.1
Build compliance into infrastructure delivery by:
- Evaluating resource metadata and failing when actual field values differ from expected compliant values. section 8.3.1
- Combining platform security tests, industry or regulatory standards, and custom policies because no single engine covers every use case. section 8.3.1
- Writing detailed test names and error messages so teammates understand the requirement and how to correct noncompliant configuration. section 8.3.4
- Modularizing database and firewall tests, then sharing them through repositories that teams can reference and security teams can update centrally. section 8.3.4
- Classifying enforcement as hard mandatory, soft mandatory, or advisory to distinguish blocking failures from review items and best practices. section 8.4
Preventing a late compliance failure
A retail team building a GCP frontend discovers one month before launch that an audit rejects its infrastructure. Running security and compliance tests while developing would expose the violations earlier, allowing planned remediation instead of a delivery delay. section 8.0
Figure 8.4 Tests for security and policy parse the configuration or state of the system for the correct field values and fail if they do not match an expected value.
Trace how policy tests parse configuration or system state, inspect expected field values, and fail when the values do not comply. section 8.3.1
