Janita Madramootoo - CGE-AUD

Catching Up: Labs 2.5 - 4.3, and Passing the CGE-AUD Auditor Exam

Janita — Mon, 27 Jul 2026 00:00:00 +0000

Summary</h2>
My last post left off at Lab 2.4</a>. Since then, I've completed: Labs 2.5, 3.3, 3.4, and 4.3, plus the GRC Auditor</a> exam. This is a quick summary with the main takeaway per lab.</p>
Code for these labs is in my CGE-P Capstone repo</a>.</p>
The GRC Auditor</a> exam was also launched in the meantime, recommended as a prerequisite to the CGE-P exam. My engineering background helped me knock it out in two days. Grateful for quick wins!</p>

Lab 2.5: IaC as Compliance Evidence (AWS)</h2>
This lab turns a Terraform plan into signed, retained evidence rather than just a deployment artifact. The module, `evidence-vault</code>, is an S3 bucket with Object Lock in GOVERNANCE mode. A capture script (scripts/capture-evidence.sh</code>) runs against a target workspace (in my case,` `Lab 2.3's compliant-s3</code></a>) and writes a receipt into the vault.</p>`
Step</th> What it proves</th></tr></thead>

Capture evidence against `compliant-s3</code></td>` The plan output itself becomes the evidence artifact</td></tr>
Verify `RetainUntilDate</code> under GOVERNANCE mode</td>` Retention is enforced, not just configured</td></tr>
Attempt `delete-object</code> on the locked object</td>` Confirms the lock actually blocks deletion with AccessDenied</code> as expected</td></tr> </tbody></table> Labs 3.3 & 3.4: Writing Compliance Policies in Rego, GCP to AWS</h2> Lab 3.3 writes the policy library. Lab 3.4 proves it doesn't have to be tied to one cloud provider.</p> Lab 3.3: Writing Compliance Policies in Rego (GCP)</h3> Three Rego policies, three NIST controls, checked against a GCP Terraform plan:</p> Control</th> File</th> Enforces</th></tr></thead> SC-28</td> sc28_encryption.rego</code></td> Every google_storage_bucket</code> has a populated encryption { default_kms_key_name }</code> block</td></tr> AC-3</td> ac3_no_public.rego</code></td> Buckets have uniform_bucket_level_access = true</code> and public_access_prevention = "enforced"</code>; firewalls don't expose 22 or 3389 to 0.0.0.0/0</code></td></tr> CM-6</td> cm6_required_tags.rego</code></td> Every taggable resource carries the four required labels: project</code>, environment</code>, managed_by</code>, compliance_scope</code></td></tr> </tbody></table> Lab 3.4: Integrating PaC with Terraform via Conftest (AWS)</h3> This was my first exposure to Conftest</a>, Rego, and Open Policy Agent</a>.</p> This lab does two things: runs the Lab 3.3 GCP policies against an AWS plan (they pass with zero coverage since there were no GCP resource types to check), and adds AWS-typed variants of the same three controls into the library. The point is that a control ID is portable across cloud providers while a Rego rule hardcoded to google_storage_bucket</code> is not.</p> Control</th> GCP file (3.3)</th> AWS file (3.4)</th></tr></thead> SC-28</td> sc28_encryption.rego</code></td> sc28_encryption_aws.rego</code></td></tr> AC-3</td> ac3_no_public.rego</code></td> ac3_no_public_aws.rego</code></td></tr> CM-6</td> cm6_required_tags.rego</code></td> cm6_required_tags_aws.rego</code></td></tr> </tbody></table> Lab 4.3: Building a GRC Evidence Pipeline (AWS + GitHub Actions)</h2> Lab 4.3 wires the Lab 3.4 Conftest gate into GitHub Actions. Every PR now runs terraform plan</code>, Conftest, and tfsec, and uploads a named evidence artifact regardless of pass or fail. The workflow file itself is the CM-3/CM-6/CA-2/RA-5/AU-9 audit evidence.</p> Setting up IAM Identity Center</h3> This was my first time setting up IAM Identity Center (SSO) on my personal AWS account. Up to this point, I've been working on the lab in CloudShell to avoid saving keys on my laptop. This has caused some headaches because AWS CloudShell only allows for 1 GB of persistent storage per AWS Region. I kept getting "No space left on device" errors on the AWS labs because every terraform init</code> re-downloads its own full copy. Claude helped me find the Terraform plugin-cache and delete old files to make room for each new AWS lab, but it felt like I was just putting off the inevitable of setting up IAM Identity Center.</p> With OIDC, my sessions are short-lived and expire, which means occasionally re-authenticating, but nothing durable to leak and no forgetting about keys on my computer.</p> The guide's reference oidc/main.tf</code> trusts the role to repo:OWNER/REPO:*</code>, so basically any branch, any event. In my repo, I tightened up both the subject claim and the permissions granted.</p> Since my repo has no remote backend configured, my state stays local. There's no diff for testing drift against real infrastructure. The plan always shows a full "create," not a diff against what's actually live.</p> With identity and OIDC sorted, here's the gate itself in action:</p> The two-PR demonstration</h3> Green</strong>: PR #6</a>, merged. All checks passing.</p> </li> Red</strong>: branch lab-4-3-red</code>, opened, not merged. Conftest failed with:</p> [SC-28] aws_s3_bucket.primary: aws_s3_bucket has no matching aws_s3_bucket_server_side_encryption_configuration. Remediation: add one referencing this bucket.</code></p> </blockquote> </li> </ul> That message contains the control ID, resource, and remediation all in one line. The whole point of the gate is that this failure surfaces on the PR, before merge, instead of turning up as a finding in a later audit.</p> Takeaway</h2> Every gotcha I came across in these labs traced back to two things: my AWS CloudShell setup and that the guides are written for a flat, single-purpose repo. My repo has real structure, which means every path, working directory, and relative reference in the lab guides needed debugging (e.g. TF_WORKING_DIR</code> pointed three levels deep so every ../</code> in the guide's Conftest/tfsec steps needed to become ../../../</code>).</p>