An application running on a set of Amazon EC2 instances in an Auto Scaling group requires a configuration file to operate. The instances are created and maintained with AWS CloudFormation. A DevOps…

Question

Options

• AIn the CloudFormation template, add an AWS Config rule. Place the configuration file content in the
• BIn the CloudFormation template, add an EC2 launch template resource. Place the configuration file
• CIn the CloudFormation template, add an EC2 launch template resource. Place the configuration file
• DIn the CloudFormation template, add CloudFormation init metadata. Place the configuration file

• A
  18% (9)
• B
  4% (2)
• C
  8% (4)
• D
  70% (35)

Explanation

Option D is correct because AWS::CloudFormation::Init metadata (used with the cfn-init helper) embeds configuration file content directly inside the CloudFormation template, satisfying the source-control co-location requirement. When instances launch, cfn-init reads and applies the config from the stack metadata. Critically, the cfn-hup daemon running on each instance polls for stack updates and re-runs cfn-init when the template changes, pushing updates to already-running instances with minimal delay - no instance replacement needed.

Why the distractors fail:

• A is wrong because AWS Config rules are a compliance/auditing service that evaluates resource configurations - they cannot deploy files to EC2 instances.
• B & C both use EC2 launch templates, which only apply configuration to newly launched instances. Changes to a launch template do not propagate to running instances, so the "minimal delay" requirement is not met for the existing fleet.

Memory tip: Associate cfn-init + cfn-hup with the phrase "init launches it, hup updates it" - cfn-init configures the instance at birth, and cfn-hup keeps it in sync with the template over its lifetime.

No community discussion yet for this question.