Building a Compliant AWS S3 Module with Terraform (CGE-P Lab 2.3)

2026-07-13T00:00:00+00:00

Summary</h2>
I am working through the Certified GRC Engineer - Practitioner (CGE-P)</a> course. This is the first lab on Policy-as-Code (PaC) where I build my first Terraform compliant module. This is a learning-in-public post, so expect rough edges. Here's what I built and what I noticed along the way.</p>
Code for this lab is in my CGE-P Capstone repo</a>.</p>

Lab 2.3: Building Your First Compliant Resource (AWS S3)</h2>

We are building a Terraform module called compliant-s3</code>. It is a reusable building block that creates an AWS S3 bucket pre-wired with compliance controls from NIST SP 800-53 Rev 5, implemented from the start.</p>

The "primitives" directory is called by other configurations. A primitive here means a small, self-contained module that other configurations reference instead of rewriting. The idea is you build the compliance logic once, in one place, and every future bucket in the project inherits it instead of someone copy-pasting Terraform and forgetting a control.</p>

terraform/primitives/compliant-s3/</span></span>
├── variables.tf   (inputs)</span></span>
├── main.tf        (resources)</span></span>
└── outputs.tf     (exports)</span></span></code></pre>
variables.tf</strong></p>
All callers must provide: project_name</code>, environment</code>, bucket_suffix</code></p>
These are validation rules for CM-6 (Configuration Management) control. They prevent misconfiguration starting at deployment.</p>
main.tf</strong></p>
It creates two S3 buckets with compliance attached to each. The two buckets have a dependency: the primary data bucket logs into the log bucket. The log bucket must exist first.</p>
Code block</th> NIST Control</th> What it does</th></tr></thead>

aws_s3_bucket_server_side_encryption_configuration</code></td> SC-28</td> AES-256 encryption at rest on both buckets</td></tr>
aws_s3_bucket_versioning</code></td> CM-6</td> Preserves all object versions for audit/recovery</td></tr>
aws_s3_bucket_public_access_block</code></td> AC-3</td> Denies all four public access vectors</td></tr>
aws_s3_bucket.log</code> + aws_s3_bucket_logging</code></td> AU-3 / AU-6</td> Dedicated audit log bucket that collects S3 access logs</td></tr>
Default provider tags</td> CM-6</td> Forces compliance tags onto every resource automatically</td></tr>
</tbody></table>
Here, each row is a control satisfied by writing the resource correctly. No separate policy engine checking anything yet. The Terraform code is the policy.</p>
outputs.tf</strong></p>
The return values: bucket_arn</code>, bucket_name</code>, log_bucket_arn</code> and encryption_algorithm</code> which acts as attestation that SC-28 is active.</p>
Two Red Flags I Noticed</h2>
This is just a learning exercise on creating policy as code. However, two red flags stood out to me as I read through the instructions.</p>


Exporting credentials into shell environment variables is rarely a good idea. These are readable by any process running under your account. If anything is compromised (e.g. an npm package, VS Code extension, etc.), it can read AWS_SECRET_ACCESS_KEY</code> directly from the environment.</p>
I opted to use AWS CloudShell and ran Terraform inside the AWS console instead. Nothing touches my laptop at all. There is no aws configure</code> or keys to manage. CloudShell ships with AWS CLI v2 already configured, though Terraform isn't preinstalled. I installed it in the session. I then uploaded my three .tf</code> files and ran the lab as written, minus all the credential setup, then downloaded a zip of the evidence at the end.</p>
</li>

The log bucket lives in the same AWS account as the data bucket. In the real world, this creates a critical weakness. Any IAM principal (user, role, or admin) with broad account permissions can delete the log bucket and overwrite/expire log objects to erase their own tracks after a security incident.</p>
This violates AU-9: Protection of Audit Information, which requires audit logs to be protected from the principals being audited.</p>
How to improve this:</p>


At the very least, use a strict IAM policy that denies DeleteObject</code> and DeleteBucket</code> to everyone, and enable S3 Object Lock in Compliance mode. Set an S3 Lifecycle policy for cleanups depending on compliance frameworks (the minimum values), legal and regulatory requirements, and GRC/Security teams.</p>
</li>

Separate AWS accounts with a dedicated logging account that the data account writes to via a cross-account bucket policy. This is recommended by the AWS Well-Architected Framework for compliance workloads.</p>
</li>

Separate AWS Organizations with SCPs. The logging account is governed by SCPs that prevent its own admins from disabling logging.</p>
</li>
</ol>
</li>
</ol>
This is the part that stuck with me as someone new to Terraform and PaC. The module technically satisfies every control on the checklist, yet still has a hole a real auditor would flag on sight. Writing the policy is not the same as thinking like the bad actor the policy is supposed to stop.</p>
The question I'm carrying into the next lab: what does "compliant" actually mean if the checklist can be satisfied while the threat model isn't?</p>

Code block</th>	NIST Control</th>	What it does</th></tr></thead>
`aws_s3_bucket_server_side_encryption_configuration</code></td>`	SC-28</td>	AES-256 encryption at rest on both buckets</td></tr>
`aws_s3_bucket_versioning</code></td>`	CM-6</td>	Preserves all object versions for audit/recovery</td></tr>
`aws_s3_bucket_public_access_block</code></td>`	AC-3</td>	Denies all four public access vectors</td></tr>
`aws_s3_bucket.log</code> + aws_s3_bucket_logging</code></td>`	AU-3 / AU-6</td>	Dedicated audit log bucket that collects S3 access logs</td></tr>
Default provider tags</td>	CM-6</td>	Forces compliance tags onto every resource automatically</td></tr> </tbody></table> Here, each row is a control satisfied by writing the resource correctly. No separate policy engine checking anything yet. The Terraform code is the policy.</p> outputs.tf</strong></p> The return values: `bucket_arn</code>, bucket_name</code>, log_bucket_arn</code> and encryption_algorithm</code> which acts as attestation that SC-28 is active.</p>` Two Red Flags I Noticed</h2> This is just a learning exercise on creating policy as code. However, two red flags stood out to me as I read through the instructions.</p> Exporting credentials into shell environment variables is rarely a good idea. These are readable by any process running under your account. If anything is compromised (e.g. an npm package, VS Code extension, etc.), it can read AWS_SECRET_ACCESS_KEY</code> directly from the environment.</p> I opted to use AWS CloudShell and ran Terraform inside the AWS console instead. Nothing touches my laptop at all. There is no aws configure</code> or keys to manage. CloudShell ships with AWS CLI v2 already configured, though Terraform isn't preinstalled. I installed it in the session. I then uploaded my three .tf</code> files and ran the lab as written, minus all the credential setup, then downloaded a zip of the evidence at the end.</p> </li> The log bucket lives in the same AWS account as the data bucket. In the real world, this creates a critical weakness. Any IAM principal (user, role, or admin) with broad account permissions can delete the log bucket and overwrite/expire log objects to erase their own tracks after a security incident.</p> This violates AU-9: Protection of Audit Information, which requires audit logs to be protected from the principals being audited.</p> How to improve this:</p> At the very least, use a strict IAM policy that denies DeleteObject</code> and DeleteBucket</code> to everyone, and enable S3 Object Lock in Compliance mode. Set an S3 Lifecycle policy for cleanups depending on compliance frameworks (the minimum values), legal and regulatory requirements, and GRC/Security teams.</p> </li> Separate AWS accounts with a dedicated logging account that the data account writes to via a cross-account bucket policy. This is recommended by the AWS Well-Architected Framework for compliance workloads.</p> </li> Separate AWS Organizations with SCPs. The logging account is governed by SCPs that prevent its own admins from disabling logging.</p> </li> </ol> </li> </ol> This is the part that stuck with me as someone new to Terraform and PaC. The module technically satisfies every control on the checklist, yet still has a hole a real auditor would flag on sight. Writing the policy is not the same as thinking like the bad actor the policy is supposed to stop.</p> The question I'm carrying into the next lab: what does "compliant" actually mean if the checklist can be satisfied while the threat model isn't?</p>

Janita Madramootoo - GRC Engineering

Building a Compliant AWS S3 Module with Terraform (CGE-P Lab 2.3)