My Last Week at Mak Systems

This was my last week at Mak System Software Solutions. My terminal console tells me I was there for 473 days - from the 10th of June 2024 to the 27th of September 2025. A reasonably successful gig I think!

The place had issues like everywhere else, but overall, great people to work with, a reasonably strong technical culture, and a good product on our Platform side. I particularly enjoyed the trip out to North Macedonia to do some on-site planning and architecture work with the team there. Visiting new places is the best part of any job.

At some point this week now I’ve got some housekeeping to do on the laptop like: removing the VPNs, deleting the links, the code, and tidying up - but just for this one day - I’m gonna catch up on sleep, relax, and maybe do a bit of DIY around the house. Because also last week I had -

A Takehome Assessment For a New Job!

Recently I applied for a permanent job as a Principal Platform / Product Security Engineer role in UK government in London. It’s an organization working at the intersection of AI safety, security, and government policy - exactly the kind of mission I’ve been looking for 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. ;-)

The Challenge

The requirements:

  • 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.

Oh, and 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.

What I 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. And CI/CD makes security invisible and automatic, encouraging adoption rather than resistance.

This was one of the most intense take-home challenges I’ve 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), and keep everything structured enough that a reviewer could follow without getting lost.

I submitted it knowing I’d given it my best. Now we wait - but regardless of outcome, the exercise was genuinely good learning in secure AWS baselines and organizational guardrails. And honestly, a lot of fun!

Security at scale isn’t about slowing teams down - it’s about building the infrastructure where the secure option is the easiest option. That’s what this baseline was all about.

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