SCS-C02 Infrastructure Security Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Use a CloudFormation template that includes the KMS key ID as a hardcoded value.

  Why it's wrong here

  Hardcoding the KMS key ID directly into a CloudFormation template provides only a default value, not an enforceable control. Any IAM user allowed to create or update stacks can copy the template, edit the key ID to a different value, and deploy it, since CloudFormation performs no inherent validation that the key is the approved one. The template content is not cryptographically pinned, so a modified template is indistinguishable from the original during deployment, making this approach purely a matter of convention, not security enforcement.

• ✗

  Use a CloudFormation parameter to accept the KMS key ID and validate it with a rule.

  Why it's wrong here

  Parameter validation rules in CloudFormation are evaluated only at the moment a stack is created or updated, and they can be circumvented by calling the create-stack API directly or by editing the template to remove or weaken the rule. Even a rule that uses an allowed-values list or a regex pattern will pass if the user supplies a different key ID that still matches the rule criteria, and the rule cannot reference an external policy or dynamically check the key's approval status. This is a soft, pass-through guard that cannot guarantee the deployed stack actually uses the designated KMS key after the initial input is accepted.

• ✓

  Use AWS CloudFormation StackSets with a service-managed permission model to deploy stacks from a centrally managed template that includes the KMS key.

  Why this is correct

  AWS CloudFormation StackSets with a service-managed permission model centralizes template management in the management account, and the StackSets service automatically creates and manages IAM roles in every target account within the AWS Organization, so end users cannot alter the template or the KMS key reference during deployment. Stack instances are deployed with identical configuration, and updates are controlled by the administrator, ensuring the approved KMS key is consistently used across all accounts. This is an enforceable control because the template content is immutable to users in target accounts, and StackSets provides auditable, repeatable deployments through the Organizations integration.

• ✗

  Use an AWS Organizations service control policy (SCP) to deny all CloudFormation actions unless a specific KMS key is used.

  Why it's wrong here

  An organization SCP can deny CloudFormation actions at the account or OU level, but it cannot inspect the content of a stack template to verify which KMS key is being used. CloudFormation does not expose a condition key that indicates the KMS key ID for all resources a stack will create; you cannot write an SCP condition such as 'only allow if the stack uses key arn:aws:kms:us-east-1:123456789012:key/abc'. Moreover, denying all CloudFormation operations based on a condition that is never satisfied would block all legitimate stack deployments, so the SCP would be too broad and ultimately ineffective for this specific enforcement need.

Go deeper

Related to this question