Passing the CGE-P and Building infra-modules

Janita — Mon, 21 Sep 2026 00:00:00 +0000

I passed the GRC Engineer Practitioner</a> (CGE-P) exam and finished the capstone project</a>!</p>

The most useful thing I built was not part of the course. Partway through, I started infra-modules</a> for a client project, and it ended up doing most of the work in my capstone. One capstone pull request put a storage bucket back on default encryption. The pipeline blocked it before anything was built:</p>

GAP-01 (SOC2-CC6.1): S3 bucket "aws_s3_bucket.uploads" is not encrypted with SSE-KMS using a customer-managed key</code></p> </blockquote>
This post covers how that works.</p>
Why I built infra-modules</h2>The labs had me write a compliant S3 module (Lab 2.3</a>), a compliant GCS module (Lab 2.4</a>), and Rego policies that check a Terraform plan against NIST controls. Then I started building Look At These Birds</a>, a birding blog for a client. The client wanted a secure blog where they owned the code, plus a CMS to add new posts. That ruled out an off-the-shelf CMS, since those providers store the content on their own backend. So I built a lightweight CMS and admin portal on Next.js and AWS.</p> My site design used S3, CloudFront, WAF, Cognito, SES, DynamoDB, Lambda, and Route 53. Since I was working through the CGE-P labs at the time, I wanted to apply what I was learning in a real project. I made a repo called infra-modules. It started with an S3 module and a policy. It now has 16 AWS modules.</p> How the modules work</h2> Two things live in the repo, and they follow different versioning rules.</p> Modules are pinned. A project references a tag, like ?ref=v1.25.0</code>, and upgrades when it chooses to. Each project also commits an infra-modules.yml</code> that declares its version, and CI checks that every module reference matches it.</li> Policies are not pinned. CI clones the repo at main</code>, runs terraform plan</code>, and checks the plan with Conftest. apply</code> only runs if the check passes.</li> </ul> The unpinned policy clone is on purpose. Every project is held to the current rules, so nothing drifts. The cost is that a new rule can fail an existing project's next build. That works for me as a solo developer.</p> The Rego rules are organized by security intent, like encryption at rest or auditable account activity, not by module. One intent can cover S3 and DynamoDB in a single section. The rules check the plan itself, so they also catch a resource someone wrote by hand outside a module.</p> I also chose not to write cloud-agnostic modules. A module that abstracts over S3 and GCS hides the provider-specific settings, and those are the settings the policies need to inspect. What I share across clouds is the pattern, not the resource code.</p> The repo has its own gates. Every Rego rule has an allow</code> fixture and a deny</code> fixture. Module logic is covered by terraform test</code> with a mocked provider. Checkov runs as a blocking check. main</code> is protected, and that applies to me too.</p> What a real project found</h2> As I built the blog, I discovered changes the modules needed. I used Claude Code to work across both repos in parallel and make those changes as I went. Three examples:</p> The SES bounce topic failed on apply with InvalidSNSDestination: Access denied to KMS key</code>. The module defaulted to the AWS-managed SNS key, and AWS does not let you edit that key's policy, so SES could never publish to the topic. The plan looked fine and only a real apply caught it. The module now creates its own customer-managed key with a policy that lets SES publish.</li> My first CloudTrail rule failed any plan without a trail. That would have broken every other project's build, so the rule now checks a trail's properties instead.</li> My DynamoDB and SNS encryption rules fired on resources being destroyed. A deleted resource has no after</code> state in the plan, so every deleted table looked newly non-compliant. I added a helper that skips resources being destroyed and still checks replacements. A rule that fires on false positives gets disabled, and then the gate protects nothing.</li> </ol> The capstone</h2> The capstone project is a patient intake API for a fictional company, "Acme Health". It shipped with eight known compliance gaps. I chose SOC 2 as the framework instead of HIPAA, the obvious choice for a healthcare app. SOC 2 is the standard software companies get asked about most, and its Type II audits look at whether controls are working over time. A pipeline that signs evidence on every merge produces that kind of proof. SOC 2 does not replace HIPAA, but the two overlap. The starter maps seven of the eight gaps to both a SOC 2 criterion and a HIPAA Security Rule section, so most of the same fixes support both.</p> I added four layers:</p> Terraform fixes for six of the eight gaps.</li> Rego policies that block five of those from coming back.</li> A GitHub Actions pipeline that plans, checks policy, applies, signs the evidence with Cosign, and uploads it to an Object Lock vault.</li> An OSCAL component that traces each control to a Terraform resource and to signed evidence.</li> </ol> The brief requires at least five policies, each detecting a real gap. Here is how my eight gaps came out, with the SOC 2 criterion each one maps to:</p> Fixed, with a policy:</strong> GAP-01 and GAP-02 (encryption with my own KMS key, CC6.1), GAP-03 (deny non-TLS requests, CC6.7), GAP-05 (Lambda in the VPC, CC6.6), and GAP-07 (least-privilege IAM, CC6.3).</li> Fixed, no policy:</strong> GAP-04, bucket versioning (A1.2). It is one setting, so there is no useful bad change to test against.</li> Not fixed:</strong> GAP-06 (Lambda concurrency, dead-letter queue, tracing) and GAP-08 (API logging, throttling, firewall). Both map to CC7.2, monitoring. The OSCAL file documents them as planned, not implemented, and a real SOC 2 audit would flag CC7.2 because of them.</li> </ul> The write-up in the repo lists the trade-offs I accepted and what I did not get to.</p> The evidence vault and the DynamoDB table both come from infra-modules. Both needed to use my own KMS key, and the modules did not support that yet. I extended them and released v1.25.0</code>.</p> The live apply also caught two mistakes of mine. My notes said GAP-01 and GAP-04 were closed. The KMS key was never wired into the uploads bucket, and the versioning fix sat on a branch that never merged. I fixed both and confirmed with a plan that showed no drift. Now I check the live resources instead of my notes.</p> The evidence backs up the gate.</p> PR #12</a> passed and merged, and its run signed the evidence bundle and uploaded it to the vault.</li> PR #13</a> is the blocked one from the top of this post.</li> </ul> The exam</h2> The exam was 60 multiple-choice questions with 90 minutes to complete it. I finished in about 40 minutes. It costs $350, or it is free for members of the GRC Engineering Club, which I am.</p> I started the course a couple of months ago and worked on other things in between, so I leaned on the study guide</a> to remember the earlier sections. Because I built the labs as I went, and infra-modules on the side, the concepts stuck and the exam was much easier than I expected.</p>

Janita Madramootoo - OPA

Passing the CGE-P and Building infra-modules

The exam</h2> The exam was 60 multiple-choice questions with 90 minutes to complete it. I finished in about 40 minutes. It costs $350, or it is free for members of the GRC Engineering Club, which I am.</p>