Exams / SCS-C03 / Study guide / Secure infrastructure as code (StackSets, CloudFormation Guard, Hooks)
Secure infrastructure as code (StackSets, CloudFormation Guard, Hooks): SCS-C03 study notes and practice questions
What to know about Secure infrastructure as code (StackSets, CloudFormation Guard, Hooks) for the SCS-C03 exam, from the Security Foundations and Governance domain (14% of the exam guide), then 1 free question to test it. Part of the SCS-C03 study guide.
These questions describe a need to put the same security baseline into many accounts, stop insecure resources from reaching production, or keep stacks matching their approved templates. Match each tool to the moment it has to act.
What decides the answer
StackSets deploy one template to many accounts and Regions from a management or delegated administrator account. With service-managed permissions and AWS Organizations, StackSets deploys to OUs and can deploy automatically to accounts that join later. Self-managed permissions require you to create the administrator and execution roles in each account yourself.
Automatic deployment to new accounts is the answer when the requirement says every new account gets the baseline.
CloudFormation Guard evaluates templates against rules that you write in its declarative language. Run it in a pipeline before deployment, and the build fails when a template has, for example, an unencrypted bucket.
CloudFormation Hooks run during stack operations, before a resource is created or updated. They can fail the operation when the configuration is noncompliant, so the resource never exists. Guard rules can be packaged as hooks.
Stack policies prevent updates to specific resources in a stack, such as a KMS key that must not be replaced. They guard against accidents, not against people with permission to edit the policy.
Service roles let a stack create resources only as far as a role you pass to it allows, which keeps the template within least privilege.
Drift detection finds resources that someone changed outside CloudFormation.
Runtime enforcement of a rule belongs to SCPs or AWS Config. IaC tools act on templates and on stack operations, not on console or API changes made outside them.
How to choose
Scenario wording
Pick
The same baseline in every account, including new ones
StackSets with service-managed permissions on OUs
Reject a noncompliant template before it is deployed by the pipeline
CloudFormation Guard in the pipeline
Block a noncompliant resource during any stack create or update
CloudFormation Hooks
Protect one resource from accidental replacement
Stack policy
Find a change someone made outside the template
Drift detection, plus AWS Config for ongoing checks
Stop any account from using a service at all
SCP, not IaC
Common traps
Treating Guard as runtime enforcement. It checks templates. It does not stop a console change.
Self-managed StackSets when the requirement is automatic deployment to new accounts. Service-managed permissions are the answer there.
Giving the StackSet administrator or execution role broad permissions. A template can create anything those roles allow.
Relying on a stack policy as a security control. Anyone who can change the policy can remove it.
Missing drift that happened outside the template and then reverting it in the next deploy without review.
Hooks used for everything. Hooks check resource configuration during stack operations; they are not an account-wide guardrail.
Read the StackSets guide and the CloudFormation Guard overview. The first covers permission models and deployment targets, and the second explains how rules are written and run in a pipeline.
A retail chain creates a new AWS account for each store-systems project, and the organization's account process places each one in the right OU. Every new account must get a baseline of CloudTrail logging, a GuardDuty detector, and an IAM role that the security team uses for audits, all before the first developer signs in.
The security team does not want to run a script after each account is created, and it does not want to store long-term deployment keys. New accounts placed in the OU should receive the baseline automatically.
Which solution meets these requirements?
Choose one answer.
AA. Create a self-managed CloudFormation StackSet from the management account, and create deployment roles in each member account with a script that runs after each account is created. Target the StackSet at the OU account IDs.
BB. Create a service-managed CloudFormation StackSet from the organization management account, target the OU, and turn on automatic deployment. New accounts moved into that OU then receive the stacks without a manual step.
CC. Deploy the baseline with Terraform from a central pipeline that runs every night. The pipeline discovers new accounts through the Organizations API, and applies the baseline using access keys for each new account.
DD. Add the baseline as a launch template in each store project account, and ask developers to launch it on their first day. The security team checks compliance with an AWS Config rule each week.
Show the answer and explanation
Answer: B
A. Wrong: Self-managed StackSets need deployment roles in every account, created by a script that runs after each account is made. The security team wants no per-account step, and this script is exactly that step.
B. Right: Correct. Service-managed StackSets create the roles needed in each account, and automatic deployment applies the stacks to accounts that join the target OU. No long-term keys or per-account scripts are required. Learn more: Enable automatic deployment for StackSets (opens in a new tab)
C. Wrong: A nightly pipeline leaves new accounts unprotected for hours, which misses the before-first-sign-in requirement. Storing access keys for each account breaks the rule against long-term deployment keys.
D. Wrong: A launch template configures instances, not account-level logging or detection, and it depends on developers acting. Weekly checks find gaps after the first sign-in, which the requirement forbids.
Explanation
Service-managed StackSets deploy stacks to accounts in target OUs, including accounts that join later, without per-account deployment roles or scripts. The self-managed script, the nightly pipeline with access keys, and the launch template each leave a gap or need long-term keys.
Want more on Secure infrastructure as code (StackSets, CloudFormation Guard, Hooks)? The 5 full-length practice sets have 5 more Secure infrastructure as code (StackSets, CloudFormation Guard, Hooks) questions, 325 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →
Study Secure infrastructure as code (StackSets, CloudFormation Guard, Hooks)