Part of an ongoing series walking domain by domain through the Cybersecurity Architect's Handbook, Second Edition — and the companion labs that ship with it. This is the last stop.
If you've been following along, you know the rhythm by now. I've been working through the second edition of the Cybersecurity Architect's Handbook's "secret menu" one domain at a time — taking the book's concepts, pairing them with the hands-on labs that live alongside it, and then writing up what each domain is really trying to teach once you stop reading and start typing commands. We've climbed through the rings of the architecture: detection, prevention, monitoring, the automation that ties a SOC together, the innermost ring of identity and encryption, the vulnerability and configuration management hygiene the fancier controls all quietly depend on, the morning-after discipline of incident response and the forensics underneath it, and last time the furthest move upstream the series makes — application security testing, finding the flaw in the code before there's even a host to harden.
This installment goes the opposite direction. Where the last post zoomed all the way in — past the running host, past the alert, down to a single line of source — this one pulls all the way back. It steps away from individual controls entirely and asks about the environment every one of them now runs inside: the cloud, and the distributed, multi-platform enterprise the cloud produced. It's a fitting place to end the series, because it's the widest lens we'll point at anything. Every domain so far defended something running on infrastructure. This one defends the infrastructure's shape.
And here is the conceptual heart of the domain, the thing the labs exist to make you feel rather than read: the migration to AWS, Azure, and Google Cloud didn't just relocate the data center — it dissolved the perimeter, multiplied the attack surface, and introduced an entirely new category of risk in misconfiguration. The single most common cause of a cloud breach isn't a clever exploit. It's a storage bucket left public, an IAM role granted far more than it needs, or a security group open to the entire internet. The whole alphabet soup that's grown up around cloud security — CSPM, CWPP, CIEM, and the CNAPP platforms now consolidating all of them — exists to catch exactly that, on your side of the shared-responsibility line, before an attacker does. And the lesson I wanted readers to internalize before they ever license a commercial product is that every one of those platforms is ultimately checking for the same handful of fundamentals you can learn by hand.
Two Books, One Cover Price
For anyone joining the series here, the same thing is true of this domain as every other one I've covered: the book is only half of what you get.
The printed second edition runs to nearly 700 pages, providing the concepts and frameworks a cybersecurity architect needs to understand and address. That's the framework. But the companion GitHub repository carries another 700-plus pages of step-by-step, build-it-yourself lab content — material that never had to fit inside a print binding and so could go as deep as the hands-on work demanded. For this domain, that means hardening a real cloud account by hand, scanning it with an open-source posture tool the way a commercial CSPM would, and then defining the whole thing as code so the misconfiguration is caught before it's ever deployed.
Concepts you can read about in an afternoon. The instinct for what a CNAPP actually adds over the native controls — and what stays your responsibility no matter what you buy — you can only build by hardening an account yourself and then watching a scanner find everything you missed.
What the Labs Actually Build
The labs in this domain are sequenced to walk the full arc — from hardening a live environment by hand, to assessing it systematically the way a platform would, to shifting the whole problem left into code — but each stands on its own if you only need one piece.
Native AWS hardening — the controls every CNAPP checks for. The first lab works directly in a live AWS account, driven entirely from the browser-based CloudShell so there's nothing to install. You lock down the root user with MFA and confirm it has no access keys. You create a scoped, least-privilege administrator and stop using root for daily work. You stand up an immutable audit trail with CloudTrail — the account's flight recorder, logging every API call, who made it, from where, and when. You turn on the native detective services where your plan allows. Then you deliberately do the single dumbest, most common thing in cloud security: open SSH to 0.0.0.0/0, watch the platform flag it, remediate it, and confirm the fix. That scan-find-remediate-verify loop is the same cycle from the vulnerability-management domain, applied here to cloud configuration. By the end you've practiced the most transferable cloud-security skill there is — fluency in a real provider's identity, logging, and networking primitives.
Prowler — what the platform does, for free. The second lab points Prowler, the most widely used open-source cloud-security scanner, at the same account you just hardened. With one command it evaluates the environment against more than a thousand checks mapped to CIS, PCI-DSS, HIPAA, NIST, and SOC 2, then hands back a prioritized, framework-aligned report. This is where the lesson lands. Prowler confirms everything you fixed by hand as a PASS — and then surfaces dozens more findings you never reached. No human reviews every setting in every region of a real account; a scanner does, every day. That breadth is CSPM, and running it after a manual pass shows you precisely what Wiz or Prisma Cloud add at enterprise scale: not different checks, but breadth, correlation, attack-path graphing, and the machinery to act across thousands of accounts. The mental model transfers directly, and you built it for nothing.
Terraform — moving the problem before deployment. The domain closes with an infrastructure-as-code supplement that installs Terraform on a Debian 13 host and walks the full init → plan → apply → destroy workflow on a self-contained lab — no cloud account, no cost. The point isn't the HCL syntax. It's the architect's primary lever against that entire class of misconfiguration failure: when infrastructure is code, every change is reviewed before it's built, diffed before it's changed, and checked against policy before it ever reaches the cloud. Security stops being something you discover after an incident and becomes something you can read, test, and enforce. I close the section with the comparison every practitioner eventually asks for — Terraform versus Ansible, provisioning versus configuration management, and exactly where the boundary between them falls.
The Architect's-Eye Throughline
What I wanted these labs to teach isn't "how to drive the AWS console" or "how to write a Terraform file." Tools change. The patterns underneath them don't — and if you've read the earlier posts in this series, you'll recognize every one of these moves, because it's the same instinct each domain rewards.
Misconfiguration is the threat, not the exploit. Readers of the vulnerability-and-configuration post will feel the echo directly: that domain's whole argument was that hygiene — patching, configuration baselines, the unglamorous discipline — prevents more breaches than any clever defense. This is that lesson scaled to the cloud, where the configuration is the infrastructure and a single open security group is the entire compromise. The deliberate 0.0.0.0/0 rule in Lab 1 exists to make you feel it: an open SSH port is the cloud equivalent of leaving the front door wide open, and automated attackers find it within minutes of exposure.
Free tooling teaches the discipline the commercial product sells. This is the same move the application-security post landed on — SonarQube onto Veracode, ZAP onto Burp Professional, TruffleHog onto GitGuardian. Here it's the native AWS controls and Prowler onto Wiz, Prisma Cloud, and Microsoft Defender for Cloud. You learn the discipline on tooling you can run for free, then carry that fluency into whatever your organization standardized on. You cannot design a cloud-security program you have never operated, and the architect who has hardened an account by hand knows exactly what value the enterprise platform adds — and exactly what it doesn't.
Shift it left, before there's anything to defend. The application-security post's defining move was pulling testing out of a pre-release gate and into the editor and the pipeline. Terraform is the same instinct applied to infrastructure: a machine-readable plan, checked against policy before anything is provisioned, blocks a non-compliant change at the source rather than remediating it in production. Catching the public bucket in a pull request is cheaper and safer than catching it in a breach report — the same economics that justify shifting code analysis left justify shifting infrastructure analysis left too.
The payoff is the one the domain overview names directly. The practitioner who has hardened a real account, scanned it with Prowler, and codified it in Terraform understands what a mature cloud program actually assembles: native detective controls as the always-on baseline, a CNAPP for unified posture and attack-path analysis across multiple clouds, and IaC scanning shifted left so misconfigurations never deploy. The native controls are the baseline; the platform supplies the scale and the single pane of glass. You learn which is which by building both.
Tested on Real Infrastructure
These aren't aspirational walkthroughs — and that, too, has been the through-line of the whole series. Every step was executed on a live AWS account and on actual Debian 13 "Trixie" hosts, and the lab tells you when something breaks and why.
Prowler is the marquee example. AWS CloudShell ships only Python 3.13 and gives you a single gigabyte of persistent home storage, and Prowler — a multi-cloud tool with a 220-package dependency tree — won't run on 3.13 at all. The lab handles it up front: bring a compatible interpreter with uv tool install prowler --python 3.12, then push uv's cache and temp work onto the roomier ephemeral filesystem so the 1 GB home volume doesn't fill mid-install. CloudTrail has its own trap — create-trail fails with an InsufficientS3BucketPolicyException because, unlike the console wizard, the CLI doesn't write the bucket policy for you, and you have to confirm both the bucket and account-ID variables are populated before you apply it. On AWS's newer credit-based Free Plan, GuardDuty, Security Hub, and Config can't be enabled at all — they return a SubscriptionRequiredException rather than a charge — so the lab is written to run the identity, audit, and network layers unchanged regardless of which plan you're on. And Terraform won't install cleanly from HashiCorp's APT repository the obvious way, because as of 2026 that repo still publishes no trixie suite: $(lsb_release -cs) returns trixie, which 404s, so you pin the previous stable codename bookworm instead — the binary is statically linked and runs identically.
That's the difference between reading about a control and being able to defend it in a design review.
Put Your Hands On It
If you want to actually walk the full set — harden a real AWS account by hand, watch Prowler surface everything your manual pass missed, and codify the whole thing in Terraform so the next misconfiguration is caught before it ships — that's all waiting in the lab repository, the 700-plus pages that ship alongside the book.
Grab the Cybersecurity Architect's Handbook, Second Edition here: Amazon
And that closes the loop. We started inside individual controls — a single detection, a single host — and worked outward ring by ring, all the way to the environment that holds every one of them. If you build something with these labs, harden an account and find something that surprises you, or spot a flaw I didn't, I'd genuinely like to hear about it. You can find me at secdoc.tech. Thanks for walking the whole menu with me.
