Secure IaC Deployment: CloudFormation, StackSets, and Service Catalog

Consistency is a security property. A control that exists in most accounts is a finding waiting to happen in the rest, and hand-built infrastructure guarantees inconsistency. Infrastructure as code fixes this at the root: when every resource comes from a CloudFormation template, the template — not the console — is where security is defined, reviewed, and versioned. A template in a Git repository gets the same treatment as application code: pull-request review by security engineers, a full change history showing who changed which security group and when, and rollback to a known-good configuration. The exam expects you to frame IaC this way — templates as reviewed, versioned security artifacts, not merely automation.

The counterpart to declared state is detecting departure from it. Drift detection compares a stack's actual resource configuration against its template and reports resources as IN_SYNC, MODIFIED, or DELETED. Drift on an ordinary stack is a hygiene problem; drift on a security stack — an IAM role's trust policy widened, a security group rule added out-of-band — is a potential incident. Drift detection tells you what changed, not who: for attribution you pivot to CloudTrail, which records the API call, the principal, and the source IP behind the modification.

Note the boundary: CloudFormation drift and template review govern deployment consistency. Continuously evaluating whether deployed resources comply with rules is AWS Config's job, which belongs to Task 6.3. And where accounts, OUs, and SCPs come from is Task 6.1 — this lesson assumes that structure exists and deploys into it.

Once a security stack is deployed, CloudFormation gives you three distinct protections, and the exam tests whether you know which does what.

A stack policy is a JSON document attached to a stack that controls which resources can be modified during stack updates. The pattern: deny Update:* on critical logical resources — the CloudTrail trail, the central logging bucket, the audit IAM roles — so a routine template update cannot accidentally replace or delete them. Updating a protected resource requires an explicit, temporary policy override, which turns a silent mistake into a deliberate act.

The DeletionPolicy attribute works per resource: Retain keeps the resource when its stack is deleted, and Snapshot (for supported types) captures a final snapshot first. Security-relevant stores — log buckets, KMS keys, audit tables — should carry DeletionPolicy: Retain so evidence survives a stack deletion; the companion UpdateReplacePolicy gives the same protection when an update forces resource replacement. Stack-level termination protection additionally blocks whole-stack deletion.

A service role answers the question of who deploys what. Instead of CloudFormation acting with the caller's credentials, it assumes a dedicated IAM role scoped to exactly the resource types a template legitimately creates. The deploying human or pipeline then needs only CloudFormation permissions plus iam:PassRole for that specific role — they never hold the underlying resource permissions themselves. That separation is the load-bearing idea of this whole task, and it returns in Service Catalog launch roles and pipeline design below.

CloudFormation StackSets deploy one template as stack instances across many accounts and Regions from a single administration point — the mechanism behind the exam's favorite requirement: every account gets the same security stack. The baseline StackSet typically carries the resources Task 6.1 decided every account needs: GuardDuty detector configuration, the AWS Config recorder and delivery channel, standard IAM roles for security tooling, and log-forwarding plumbing.

The two permission models are a guaranteed exam discriminator:

• Self-managed permissions — you create the roles yourself: an administration role in the admin account and an execution role (by default named AWSCloudFormationStackSetExecutionRole) in every target account, trusting the administration role. Flexible, works outside an organization, but every missing or mangled execution role is a failed deployment.
• Service-managed permissions — StackSets integrates with AWS Organizations through trusted access and creates the necessary roles itself. You target OUs rather than account lists, and — the key feature — automatic deployment: when a new account joins a targeted OU, the stack instance deploys to it automatically, and when an account leaves, its instances can be removed.

When a scenario says "deploy the security baseline to every current and future account," the answer is service-managed StackSets with automatic deployment enabled — no distractor involving scripts, manual enrollment, or self-managed roles matches "future accounts." StackSets also supports a delegated administrator account, keeping baseline operations out of the management account, consistent with Task 6.1 discipline. Deployment order, failure tolerance, and Region concurrency are operational preferences; the security substance is the permission model and auto-deployment.

A misconfiguration caught before deployment costs a failed pipeline stage; caught after, it costs an incident. Task 6.2 names the pre-deployment toolchain explicitly.

cfn-lint validates templates against the CloudFormation resource specification plus best-practice rules — malformed properties, invalid values, structural mistakes. It is correctness linting, not policy. CloudFormation Guard (cfn-guard) is the policy-as-code layer: you write rules in a declarative DSL asserting what templates must and must not contain — every S3 bucket encrypted, no security group open to 0.0.0.0/0 on port 22, all IAM policies free of "Action": "*" — and evaluate templates against those rules in the pipeline, failing the build on violation. Guard rules are how a security team's requirements become machine-enforceable instead of living in a wiki. The same rule language backs proactive evaluation hooks, which is why Control Tower's proactive controls feel familiar here. For CDK shops, cdk-nag plays the equivalent role, applying rule packs to synthesized output; remember that CDK apps ultimately synthesize to CloudFormation templates, so every template-level control in this lesson still applies downstream.

The last gate is human: a change set previews exactly what a stack update will do — which resources are added, modified with or without replacement, or deleted — before anything executes. Requiring a reviewed change set for production stacks turns "deploy and hope" into an explicit approval step, and it pairs naturally with the pipeline approval actions covered later. Order matters and is testable: lint and Guard run in CI on every commit; change-set review guards the production apply.

The classic Task 6.2 scenario: a security review finds a database password visible in a CloudFormation template or in the stack's parameter history. The exam wants you to rank the mitigations correctly.

Plaintext secrets in templates are always wrong. Templates live in Git, flow through pipelines, and are readable via cloudformation:GetTemplate — a secret in a template is a secret published to everyone with repository or stack read access, preserved forever in version history.

The NoEcho parameter attribute is the half-measure candidates are tempted by: it masks the parameter's value (as asterisks) in console and describe-API output. It does not encrypt anything, does not remove the value from what was submitted, and does nothing if a default value sits in the template itself. Treat NoEcho as display hygiene, never as secrets management.

The correct pattern is a dynamic reference: the template stores a pointer, and CloudFormation resolves the value at deployment time from the secret store. {{resolve:secretsmanager:MySecret:SecretString:password}} pulls from AWS Secrets Manager — the right home for credentials because it adds automatic rotation; {{resolve:ssm-secure:ParameterName}} pulls a SecureString from Systems Manager Parameter Store for supported resource properties. The secret never appears in the template, the repository, or the stack's stored parameters, and access to it is separately governed by IAM and the secret's resource policy. Even better, resources like AWS::RDS::DBInstance can reference a Secrets Manager-managed master password so no human ever supplies one. Trigger phrasing to recognize: "secret visible in template" → dynamic references, with rotation favoring Secrets Manager over Parameter Store.

AWS Service Catalog packages approved CloudFormation templates as products in portfolios, giving teams a golden path: they launch vetted, pre-hardened stacks instead of authoring their own. The security win is the launch constraint: a product launches under a designated launch role that holds the permissions to create the underlying resources, while the end user needs only Service Catalog permissions. Users launch what they could never build by hand — provisioning without permission sprawl, the same separation as a CloudFormation service role but productized for self-service. Template constraints go further, restricting which parameter values a user may choose (instance types, CIDR ranges). Portfolios are shared across the organization via Organizations integration, so one security-owned catalog serves every account; Control Tower's Account Factory itself is built on Service Catalog, and Terraform-based products are supported for shops standardized on third-party IaC.

AWS RAM (Resource Access Manager) solves a different sharing problem: not templates, but live resources. RAM shares resources such as VPC subnets, Transit Gateways, and Route 53 Resolver rules with specific accounts or entire OUs — so a network account can own the inspected, centrally managed VPC fabric while workload accounts deploy into shared subnets they cannot alter. Sharing beats duplicating and beats loosening resource policies.

AWS Firewall Manager is central enforcement for network protections: from a delegated administrator account, it deploys and continuously maintains AWS WAF rules, security group policies, Shield Advanced protections, and Network Firewall deployments across all accounts — automatically covering new accounts and new resources, and remediating drift from the policy. When the requirement is "WAF on every ALB in every account, including future ones," Firewall Manager is the answer, not a StackSet.

Four services in this lesson all "deploy things to many accounts." The exam separates them by what is standardized and who initiates:

Tagging is the other consistency requirement the guide names: tags group resources by department, cost center, and environment, and they drive attribute-based access control and cost allocation — so untagged resources are a governance failure, not a cosmetic one. Enforce at two layers. Tag policies (an Organizations management policy) standardize tag keys and permitted values, report noncompliance, and can optionally prevent noncompliant tagging operations on supported resource types. Baking required tags into StackSet templates and Service Catalog products makes correct tagging the default; a detective required-tags AWS Config rule then catches stragglers — evaluation of which is Task 6.3's business.

The pipeline that deploys infrastructure is itself infrastructure to secure. The pattern: the CI/CD system holds almost nothing, and assumes a scoped deploy role per environment — a cross-account role in each target account (dev, staging, prod), each trusting only the pipeline's principal and each scoped to the resource types its templates create. Production adds a manual approval gate reviewing the change set before execute. External CI systems authenticate via OIDC federation — the provider's identity is trusted to assume a role directly, so no long-term access keys sit in pipeline configuration (the federation mechanics live in Domain 4). Artifact integrity closes the loop at concept level: the template that was reviewed and scanned must be the template that deploys, so artifacts flow through access-controlled stores and pipeline stages consume them immutably rather than re-fetching from a mutable branch.

Walkthrough. Your organization's baseline StackSet reports FAILED for one member account. First diagnosis: the permission model. Under self-managed permissions, the usual cause is the AWSCloudFormationStackSetExecutionRole missing from that account or its trust policy not naming the administration account — recreate the role and retry the stack instance. Second: the account's OU carries an SCP denying an action the execution role needs — the role's identity policy allows it, but the SCP caps it; check the deny in CloudTrail's errorCode and fix the guardrail exemption or the template. Third case: drift detection later shows the account's Config recorder MODIFIED. Drift names the change; CloudTrail names the actor — query for the modifying API call, identify the principal, then re-apply the template and close the gap (an SCP denying recorder modification, per Task 6.1) so the out-of-band path is shut, not just repaired.