A Takehome Assessment For a New Job!

This was Cloud Cauldron’s last week at Mak System Software Solutions. The contract ran for 473 days - from the 10th of June 2024 to the 27th of September 2025. A reasonably successful gig I think!

As such, I’ve been seeking a new contract and applied for a Principal Platform / Product Security Engineer role in UK government in London. It’s an organisation working at the intersection of AI safety, security, and government policy - exactly the kind of mission I’ve been looking for a while now.

As part of the process, I was given a take-home assignment: design and implement a secure day-one AWS baseline in Terraform. The goal was to show how I would bootstrap a new AWS account in a high-risk environment, enforcing security controls from the start and preventing drift.

They recommended I spend around 8 hours on it. I probably spent closer to 16 all told as I wanted to add a solid CI/CD pipeline and a good framework that I could point to if I make it to the 2nd round of interviews.

I also set this all up as open source on GitHub - which you can find already if you know how - but I’ll share the link here maybe in a week’s time for obvious reasons. No need to help any competitors too much. ;-)

This was the gist of it:

The Challenge

The requirements boiled down to:

  • Centralized logging: CloudTrail, VPC Flow Logs, and CloudWatch Logs all routed out of the new account to dedicated Security and Logging accounts.
  • Customer-managed KMS encryption: enforce encryption by default across storage and services.
  • Tagging enforcement: require tags at resource creation for accountability and cost tracking.
  • SCP guardrails: organization-level controls to prevent dangerous misconfigurations (e.g., disabling CloudTrail, creating public buckets, skipping encryption).
  • Documentation: explain the purpose and value of each control and outline how to socialize the baseline with platform teams.

The kicker: the root Terraform needed to apply to the new account, the security account, and the logging account all at once.

My Approach

I broke the problem into modular building blocks of Terraform code:

  1. KMS Module

    • Created customer-managed keys for logs, EBS defaults, and optional data services.
    • Policies kept minimal and auditable, granting only security teams, break-glass, and service principals.

  2. CloudTrail Org Module

    • Multi-region CloudTrail in the Security account.
    • Logs routed to centralized S3 (with lifecycle policies) and CloudWatch (for real-time detection).
    • SNS notifications wired in for alerting.

  3. VPC Flow Logs Module

    • Flow logs from app accounts routed directly to S3 in the Logging account.
    • Ensured logs can’t be tampered with locally.

  4. Tagging Enforcement Module

    • Implemented via SCPs requiring specific tags on every resource.
    • Provides cost accountability, ownership clarity, and the ability to drive security policies from metadata.

  5. SCP Guardrails Module

    • Deny disabling/deleting CloudTrail.
    • Deny public S3 buckets.
    • Require encryption on creation.
    • Restrict regions to approved list.
    • Block cross-org access (deny non-org principals).

CI/CD Integration

This wasn’t defined in the problem statement, but I also wired in CI/CD pipelines with GitHub Actions to show how I would avoid configuration drift:

  • Modules:

    • Pre-commit checks (linting, security scans) run on PRs and manual triggers.
    • On push to main, pre-commit runs first - only if it passes do we create a tag and release.

  • Root Terraform:

    • On PR: pre-commit, then terraform plan, with summaries generated for review.
    • On push to main: pre-commit → terraform plan (to file) → terraform apply → tag and release.

This ensured code quality and security checks were enforced automatically, making adoption easier for platform teams. It also allowed for the modules to be versioned - giving teams flexibility to upgrade when they were ready.

Lessons Learned

  • Centralized logging really is the AWS equivalent of a CCTV system: you need logs somewhere attackers can’t reach.
  • KMS everywhere isn’t just about encryption; it’s about auditable key usage and least privilege.
  • Tagging is underrated - it’s as much about security ownership as it is about costs.
  • SCPs are blunt, but they’re powerful: they enforce preventive guardrails across accounts consistently.
  • CI/CD makes security invisible and automatic, encouraging adoption rather than resistance.

Reflections

This was one of the most intense take-home challenges I’ve ever worked on. Not because the technology was unfamiliar, but because the scope was broad and the stakes felt high. I had to:

  • Balance clarity vs. completeness.
  • Think about real-world adoption, not just code.
  • Keep everything structured enough that a reviewer could follow without getting lost.

I submitted it knowing I’d given it my best. Now it’s in the lap of the gods - but regardless of outcome, the exercise was epic learning in secure AWS baselines, organizational guardrails, and frankly, a lot of fun!

Closing Thought

Security at scale isn’t about slowing teams down. It’s about building paved roads where the secure option is the easiest option. That’s what this baseline was all about - and that’s exactly the kind of work I want to do more of.

But now, I’m off to relax for a bit before the next adventure begins.

As always, you can add my RSS feed to your reader of choice and if you made it this far thanks for reading!

Chris