SOA-C02 Deployment, Provisioning, and Automation 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.

• ✗

  Define the file in an AWS CloudFormation template using the AWS::OpsWorks::App resource.

  Why it's wrong here

  The AWS::OpsWorks::App CloudFormation resource is used to register an application (e.g., code in a repository) with an OpsWorks stack, not to manage instance-level configuration files like /etc/nginx/nginx.conf. This resource drives Deploy lifecycle events for application code, but it does not provide a mechanism to write arbitrary configuration files to instances. The file in question needs to be present and managed on the instance outside the app deployment flow, so CloudFormation's OpsWorks::App resource is the wrong tool for this job.

• ✓

  Create a custom cookbook and assign it to the layer.

  Why this is correct

  Custom cookbooks are Chef cookbooks (recipes, templates, and files) that you store in a repository such as S3 or Git and assign to an OpsWorks layer. OpsWorks runs these cookbooks automatically during lifecycle events (Setup, Configure, Deploy, Undeploy), so you can use a template resource inside a recipe to render configuration files consistently on every instance in the layer. This is the native, supported way to manage configuration files in OpsWorks, and it is the correct answer because it integrates with the layer lifecycle and ensures ongoing convergence.

• ✗

  Use AWS Systems Manager Run Command to execute a script on each instance.

  Why it's wrong here

  AWS Systems Manager Run Command executes a script or command on one or more EC2 instances, but it is not integrated with OpsWorks layer lifecycle events. OpsWorks does not automatically invoke Run Command when instances are created, updated, or when the stack configuration changes. Using Run Command would be a manual out-of-band operation: you would have to track which instances need the file, push updates separately, and you would not get the centralized state management that OpsWorks provides. Thus it is a possible but non-integrated and operationally fragile approach, so it is incorrect for a requirement tied into OpsWorks configuration management.

• ✗

  Add the configuration file as user data in the layer's Auto Scaling group.

  Why it's wrong here

  User data is executed only once when an EC2 instance is first launched, making it suitable for initial bootstrap tasks but not for ongoing configuration management. In an Auto Scaling group associated with an OpsWorks layer, user data would not run on subsequent lifecycley events or when the configuration file needs to change. Furthermore, OpsWorks manages instances via its own layers and does not expose the layer's Auto Scaling group user data as a mechanism for updating configuration files on already-running instances. Because the file needs to be kept in sync over time, user data alone is insufficient and therefore incorrect.

Go deeper

Related to this question