Building a Compliant GCP Storage Module with Terraform (CGE-P Lab 2.4)

2026-07-15T00:00:00+00:00

Summary</h2>
Continuing through the Certified GRC Engineer - Practitioner (CGE-P)</a> course. Lab 2.3 built a single compliant S3 bucket on AWS. Lab 2.4 moves to GCP and shifts from writing one bucket to writing a module that deploys buckets, with compliance sitting inside the module where a consumer can't reach it.</p>
Code for this lab is in my CGE-P Capstone repo</a>.</p>

Lab 2.4: Terraform Modules for Compliance (GCP)</h2>

The module is called compliant-gcs-bucket</code>. It is a reusable building block that creates a GCS bucket pre-wired with NIST SP 800-53 controls, plus its own Cloud KMS keyring and key for encryption. Two consumers, dev</code> and prod</code>, call the same module with different environment and retention values. Both get the same security posture either way.</p>

terraform/</span></span>
├── modules/</span></span>
│   └── compliant-gcs-bucket/</span></span>
│       ├── main.tf</span></span>
│       ├── variables.tf</span></span>
│       ├── outputs.tf</span></span>
│       └── README.md</span></span>
└── primitives/</span></span>
    └── compliant-gcs/</span></span>
        ├── main.tf</span></span>
        └── variables.tf</span></span></code></pre>
The module has three files:</p>

main.tf</code> hardcodes anything compliance-relevant. A consumer cannot turn it off.</li>
variables.tf</code> exposes only what business actually changes: project, environment, retention, naming.</li>
outputs.tf</code> returns evidence, including a computed compliance_attestation</code> map.</li>
</ul>
The shift from Lab 2.3 is that compliance stops being something you remember to add per-resource, and becomes something the module forces on every consumer by construction.</p>
Code block</th> NIST Control</th> What it does</th></tr></thead>

google_kms_key_ring</code> + google_kms_crypto_key</code></td> SC-12</td> The module owns its own encryption key instead of relying on Google-managed encryption</td></tr>
encryption { default_kms_key_name = ... }</code> on the bucket</td> SC-13 / SC-28</td> Customer-managed encryption key (CMEK) applied at rest</td></tr>
versioning</code> + retention_policy</code></td> AU-11</td> Object versions preserved, retention period enforced per environment</td></tr>
uniform_bucket_level_access</code> + public_access_prevention = "enforced"</code></td> AC-3</td> IAM-only access, no ACLs, no accidental public exposure</td></tr>
locals.required_labels</code> merged into labels</code></td> CM-6</td> Compliance labels forced onto every bucket; a consumer can add labels but not remove the required four</td></tr>
</tbody></table>
Gotchas I Hit</h2>
Unlike Lab 2.3, the issue I ran into wasn't a compliance gap in the design, it was drift in the documentation. If a compliance module's own supporting docs can drift from its code, what does that imply about trusting a vendor module's documentation without reading the .tf</code> files directly? A vendor module's README makes compliance claims too ("this enforces encryption at rest"). The lesson here is: don't treat a README as proof of what a module does. Read the resource blocks yourself before you rely on the claim.</p>

Code block</th>	NIST Control</th>	What it does</th></tr></thead>
`google_kms_key_ring</code> + google_kms_crypto_key</code></td>`	SC-12</td>	The module owns its own encryption key instead of relying on Google-managed encryption</td></tr>
`encryption { default_kms_key_name = ... }</code> on the bucket</td>`	SC-13 / SC-28</td>	Customer-managed encryption key (CMEK) applied at rest</td></tr>
`versioning</code> + retention_policy</code></td>`	AU-11</td>	Object versions preserved, retention period enforced per environment</td></tr>
`uniform_bucket_level_access</code> + public_access_prevention = "enforced"</code></td>`	AC-3</td>	IAM-only access, no ACLs, no accidental public exposure</td></tr>
`locals.required_labels</code> merged into labels</code></td>`	CM-6</td>	Compliance labels forced onto every bucket; a consumer can add labels but not remove the required four</td></tr> </tbody></table> Gotchas I Hit</h2> Unlike Lab 2.3, the issue I ran into wasn't a compliance gap in the design, it was drift in the documentation. If a compliance module's own supporting docs can drift from its code, what does that imply about trusting a vendor module's documentation without reading the `.tf</code> files directly? A vendor module's README makes compliance claims too ("this enforces encryption at rest"). The lesson here is: don't treat a README as proof of what a module does. Read the resource blocks yourself before you rely on the claim.</p>`

Janita Madramootoo - GCP

Building a Compliant GCP Storage Module with Terraform (CGE-P Lab 2.4)