6.2 - Secure and consistent deployment (CloudFormation, StackSets, Service Catalog)
AWS Certified Security Specialty objective 6.2 covers deploying the same hardened infrastructure everywhere and keeping it that way. CloudFormation drift detection reveals a security group widened by hand outside the stack, a change set shows whether an update will replace a database before you apply it, a stack policy shields a KMS key from replacement during updates, DeletionPolicy Retain and termination protection survive an accidental delete, and a failed rollback stuck in UPDATE_ROLLBACK_FAILED is cleared by continuing the rollback while skipping the blocking resources. Templates fetch a database password through a dynamic reference to Secrets Manager rather than a plaintext parameter, a pipeline scan rejects a public bucket before deployment, and CloudFormation Hooks reject a noncompliant resource such as an unencrypted volume at provisioning time without relying on a pipeline. StackSets deploy at scale: self-managed permissions fail when the execution role or its trust is missing in the target account, service-managed permissions with automatic deployment reach every account newly vended into a target organizational unit, failure tolerance and maximum concurrency control how far a bad update spreads, and removing a stack instance can retain its resources. Service Catalog adds a launch constraint role, portfolio sharing per department, tag options and hidden templates. Expect deployment control scenarios.
Reject a noncompliant resource before it is created, without a pipeline = CloudFormation Hooks. Deploy automatically to every account added to an OU = StackSets with service-managed permissions and auto-deployment. Users launch a product that creates IAM roles they cannot create = Service Catalog launch constraint role.
Practice questions
1. A security team must deploy the same hardened logging stack into forty accounts across three regions, and into every account added later to the same OU. Which mechanism fits?
- A shell script that loops over the account list and runs create-stack in each one, re-executed manually whenever a new account appears in the organization
- CloudFormation StackSets with service managed permissions and automatic deployment (correct answer)
- A single CloudFormation stack in the management account with cross account resource references
- An AMI baked with the logging agent and shared with the organization
StackSets deploy one template to many accounts and regions, and with service managed permissions plus automatic deployment enabled, any account joining the target OU receives the stack without human action. A loop script has to be rerun and drifts, a single stack cannot create resources inside other accounts, and an AMI only covers instances, not the account level configuration.
2. Developers must be able to create databases themselves, but only from configurations the security team has vetted. Which service fits this need?
- AWS Service Catalog (correct answer)
- AWS Config, which continuously records resource configurations and reports any database that departs from the approved parameters
- AWS Systems Manager Parameter Store
- Amazon EventBridge
Service Catalog publishes approved CloudFormation products in a portfolio that users launch on demand, so self service happens inside a vetted template. Config only reports after the fact and cannot prevent a bad launch, Parameter Store holds configuration values rather than provisioning logic, and EventBridge routes events without provisioning anything.
3. Someone widened a security group by hand although it was created by a CloudFormation stack. Which native feature reveals that the live resource no longer matches the template?
- Stack policies
- Change sets
- Termination protection, which blocks any operation that would remove resources managed by the stack and reports the ones that were altered outside it
- Drift detection (correct answer)
Drift detection compares each managed resource with the properties declared in the template and lists the differences. Stack policies restrict what an update may touch, change sets preview an update you are about to apply, and termination protection only prevents stack deletion and reports nothing about manual edits.
4. A StackSet uses self managed permissions. Deployment to a target account fails with an access error. What is the most likely cause?
- The execution role is missing in the target account or does not trust the administration role (correct answer)
- The StackSet template references a resource type that is not available in the target region, which the service reports as a permission failure rather than as an unsupported type
- Self managed permissions only work inside the management account
- Automatic deployment was left disabled on the StackSet
With self managed permissions you create both roles yourself: an administration role in the source account and an execution role in every target account whose trust policy names the administration role. A missing region resource type raises an unsupported type error, not an access error, self managed permissions are precisely the mode used outside Organizations, and automatic deployment is a service managed feature that governs new accounts rather than access.
5. A pipeline must reject an infrastructure template that declares a public S3 bucket, before anything is deployed. Which approach fits?
- An AWS Config rule evaluating buckets after the stack is created
- Static analysis of the template with CloudFormation Guard in the build stage (correct answer)
- A CloudWatch alarm on the number of objects served publicly by the bucket, wired to a notification topic that pages the security on call engineer
- A monthly manual review of the templates stored in the repository
CloudFormation Guard evaluates the template as a file against policy rules, so the build fails and nothing is ever provisioned. A Config rule, a CloudWatch alarm and a monthly review all act after the public bucket exists, which is exactly the window the requirement asks to eliminate.
6. A CloudFormation template needs a database password. How should the template obtain it without exposing the value?
- With a dynamic reference to AWS Secrets Manager (correct answer)
- With a template parameter whose default value holds the password, since parameter defaults are stored encrypted at rest by the CloudFormation service itself
- With a Mappings section listing one password per environment
- By hard coding the password and restricting who can read the S3 bucket holding the template
A dynamic reference resolves the secret at deployment time, so the value never sits in the template, in the repository or in the stack history. Parameter defaults are stored and visible in plain text, Mappings are plain text too, and restricting bucket access still leaves the secret written in a file that anyone with the stack description may recover.