SCS-C02 Question #119: Real Exam Question with Answer & Explanation

Question

A company uses infrastructure as code (IaC) to create AWS infrastructure. The company writes the code as AWS CloudFormation templates to deploy the infrastructure. The company has an existing CI/CD pipeline that the company can use to deploy these templates. After a recent security audit, the company decides to adopt a policy-as-code approach to improve the company's security posture on AWS. The company must prevent the deployment of any infrastructure that would violate a security policy, such as an unencrypted Amazon Elastic Block Store (Amazon EBS) volume. Which solution will meet these requirements?

Options

• ATurn on AWS Trusted Advisor. Configure security notifications as webhooks in the preferences
• BTurn on AWS Config. Use the prebuilt rules or customized rules. Subscribe tile CI/CD pipeline to
• CCreate rule sets in AWS CloudFormation Guard. Run validation checks for CloudFormation
• DCreate rule sets as SCPs. Integrate the SCPs as a part of validation control in a phase of the

Explanation

AWS CloudFormation Guard is purpose-built for policy-as-code validation of CloudFormation templates - it lets you define rule sets (e.g., "EBS volumes must have encryption enabled") and run those checks as a gate in your CI/CD pipeline before any infrastructure is deployed, which is exactly what the question requires.

Why the distractors are wrong:

• A (Trusted Advisor) is a best-practice advisory tool that analyzes existing deployed resources, not a pre-deployment gate - it can't prevent violating deployments.
• B (AWS Config) also evaluates already-deployed resources against rules reactively; it detects drift after the fact but cannot block a CloudFormation deployment from happening.
• D (SCPs) are Service Control Policies that restrict IAM permissions at the AWS Organizations level - they're not designed to parse and validate CloudFormation template syntax or integrate as a CI/CD pipeline validation phase.

Memory tip: Think of the keyword "prevent" - the only option that stops bad infrastructure before it exists is Guard running in the pipeline. Config and Trusted Advisor are reactive (they find problems after deployment); Guard is proactive (it blocks deployment). The name itself helps: a "guard" blocks entry, while a "config checker" inspects what already got through.

No community discussion yet for this question.