Infrastructure as code at scale
Lesson 1 of 3 in Consistent, Secure Deployment.
A template deploys a stack into one account in one Region. An organization needs the same bucket policy, the same log destination, the same IAM role, the same Config recorder in every account and every Region it operates in — including the account somebody creates next month.
CloudFormation StackSets is the primitive for that. You define one template in an administrator account and target a set of accounts × Regions; CloudFormation creates a stack instance in each combination and tracks it. One update to the stack set rolls out everywhere; one delete cleans up everywhere. For a security engineer this is the deployment mechanism behind nearly every "ensure this control exists in all accounts" answer — the recorder, the trail, the IAM roles your responders assume, the EventBridge rule that forwards findings.
The permission model is where the exam lives, because the two options answer very different questions.
| Self-managed permissions | Service-managed permissions | |
|---|---|---|
Targets | A list of account ids you maintain | Organizational units, or the whole organization |
Roles | You create them: an administration role in the admin account and a matching execution role in every target account | Service-managed — CloudFormation uses service-linked roles, nothing for you to deploy first |
Prerequisites | None beyond the roles — works across unrelated accounts | AWS Organizations with all features, plus trusted access for StackSets |
New accounts | Not covered until you add the account id and deploy the execution role | Automatic deployment: an account entering a target OU is deployed to automatically |
Who runs it | Whoever holds the administration role | The management account, or a registered delegated administrator for StackSets |
The exam tell | “Accounts not in our organization”, “a partner’s account” | “All accounts, including those created in the future”, “target the OU” |
Two more StackSets details that show up in scenarios. When an account leaves a target OU, the account-removal behaviour decides whether its stacks are deleted or retained — retaining them orphans a control nobody manages, deleting them can strip a control from an account mid-migration, and the exam expects you to notice the choice exists. And drift detection on a stack set is an operation you run (or schedule), not a live watch: it reports which stack instances no longer match the template, which is how you find the security group somebody widened by hand in the console.
Now shift left. Deploying consistently is worth little if the template itself describes something non-compliant, so the control moves into the pipeline — the resource is never created because the template never passes.
CloudFormation Guard
CloudFormation Guard (cfn-guard) is policy-as-code: you write rules in its own declarative language and evaluate structured files against them — CloudFormation templates, and also JSON configuration such as Terraform plans.
let s3_buckets = Resources.*[ Type == 'AWS::S3::Bucket' ]
rule encryption_required when %s3_buckets !empty {
%s3_buckets.Properties.BucketEncryption exists
<<Violation: every bucket must declare BucketEncryption>>
}
The same engine appears in three places the exam cares about: in your pipeline as a CLI gate, behind AWS Config custom policy rules (a Config rule with no Lambda function to maintain), and as the implementation of Control Tower proactive controls — which is why a proactive control can fail a stack operation before provisioning.
cfn-lint
cfn-lint is a linter, not a policy engine, and the distinction is the exam question. It validates a template against the CloudFormation resource specification: property names that do not exist, required properties missing, invalid intrinsic function usage, values outside allowed enumerations, Region-specific availability. It catches the deploy that would have failed at 70% rollout.
Guard answers is this template allowed by our policy? cfn-lint answers is this template valid at all? A mature pipeline runs lint first — there is no point policy-checking a template that cannot deploy.
Third-party IaC
The exam guide names third-party IaC tools explicitly, and the shape of the answer does not change. Terraform, Pulumi and the CDK all produce the same outcome — declared infrastructure under version control, reviewed by a pull request, validated by policy-as-code before apply.
What to carry: a reviewed, versioned definition is the control (an auditor can read what production is supposed to be), the pipeline is the enforcement point, and drift between definition and reality is the thing you must detect — Config and StackSets drift detection for CloudFormation, terraform plan in CI for Terraform. A tool choice that skips any of the three is the weak answer.
Where the gates sit
A pipeline that deploys consistently and securely across accounts, in order:
- cfn-lint — is the template valid?
- cfn-guard — does it satisfy our policy? (encryption, no public access, approved AMIs, required tags)
- Static analysis of application code and dependencies — the Domain 3 half of the pipeline.
- Deploy via StackSet or pipeline role, scoped to exactly what it may create.
- Proactive controls at the CloudFormation boundary — a second net, enforced by the platform rather than by the pipeline the team controls.
- Config rules and conformance packs afterwards — because console and CLI changes never went through any of the above.
The last line is the one to remember: pipeline gates only bind people who use the pipeline.
Key terms: CloudFormation StackSet, Service-managed permissions (StackSets), AWS CloudFormation Guard, cfn-lint, Proactive control
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.