DVA-C02 Deployment 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.

• ✗

  Add a DependsOn attribute to the EC2 instance resource.

  Why it's wrong here

  The `DependsOn` attribute in CloudFormation only dictates the order in which resources are created, ensuring that a specified resource exists before another resource that depends on it is initiated. It does not, however, provide any mechanism to wait for the completion of an EC2 instance's user data script or for applications within the instance to become fully operational. CloudFormation considers the EC2 instance resource 'created' once the underlying EC2 API call to launch the instance is successful, regardless of its internal boot and configuration status.

• ✗

  Use a CloudFormation WaitCondition and a WaitConditionHandle.

  Why it's wrong here

  While technically possible to use `AWS::CloudFormation::WaitCondition` and `AWS::CloudFormation::WaitConditionHandle` to pause stack creation until an EC2 instance signals completion, this approach is generally considered an older and more complex pattern for EC2 instance initialization. It requires creating a separate `WaitConditionHandle` resource and manually constructing `curl` or `Invoke-WebRequest` commands within the user data to send signals. The `CreationPolicy` with `cfn-signal` offers a more streamlined and purpose-built solution for EC2 instances.

• ✓

  Add a CreationPolicy with a timeout to the EC2 instance resource and use cfn-signal in the user data.

  Why this is correct

  Adding a `CreationPolicy` with a `ResourceSignal` property, including a `Timeout` and `Count`, to an EC2 instance resource instructs CloudFormation to wait for a specified number of success signals from the instance before marking its creation as complete. The `cfn-signal` helper script, executed within the instance's user data, sends these signals back to CloudFormation, indicating the successful completion of the user data script and any application setup. This ensures the instance is fully configured and ready before the stack proceeds.

• ✗

  Configure the EC2 instance to run the user data script as a service.

  Why it's wrong here

  Configuring an EC2 instance's user data script to run as a service (e.g., using `systemd` on Linux or a scheduled task on Windows) ensures that the script's processes are managed, persistent, and can restart automatically. However, merely running a script as a service does not inherently provide a feedback mechanism to CloudFormation to indicate when the *initial setup* performed by that script has completed successfully. CloudFormation requires an explicit signal, such as that provided by `cfn-signal` in conjunction with a `CreationPolicy`, to determine the instance's readiness.

Go deeper

Related to this question