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.

• ✗

  Attach an IAM role to the instances that allows CodeDeploy actions.

  Why it's wrong here

  Attaching an IAM role to the instances grants them permissions to call CodeDeploy API actions (such as GetDeployment or PutHostCommand), but the CodeDeploy agent is a separate host-based process that actually performs those calls and runs the deployment lifecycle hooks. Without the agent installed, the instance has the ability to interact with CodeDeploy but no executable component to poll for assignments, download the revision, or execute scripts. The role alone cannot start the agent or make the instance deployable; it only supplies credentials, typically via instance metadata, for the agent to use once it exists.

• ✓

  Install the CodeDeploy agent on the instances.

  Why this is correct

  Installing the CodeDeploy agent places the agent software on the instance (for example, under /opt/codedeploy-agent on Amazon Linux and Ubuntu) and creates the codedeploy-agent service. This agent is a long-running daemon that polls the CodeDeploy service for deployment commands, downloads the application revision artifacts from Amazon S3 or GitHub, and executes the AppSpec file hooks in the correct order. Until the agent binary is present, the instance cannot receive or process any CodeDeploy deployment, which is why this action is a required prerequisite before a deployment can even begin.

• ✓

  Start the CodeDeploy agent service on the instances.

  Why this is correct

  Starting the CodeDeploy agent service (for example, with `service codedeploy-agent start` or `systemctl start codedeploy-agent`) is necessary to make an installed agent operational. Even after installation, the agent may not be running immediately—many install scripts stop at installation, and on some systems the service is not started automatically until the first deployment attempt. Once started, the daemon actively connects to CodeDeploy, registers the instance as available, and begins listening for deployment assignments. For an immediate fix, installing and then starting the service is the correct sequence; installation alone is necessary but not sufficient to trigger an ongoing polling loop.

• ✗

  Reboot the instances.

  Why it's wrong here

  Rebooting an instance does not install the CodeDeploy agent if it is not already present, nor does it start the agent unless the service is configured to launch at boot. On fresh instances where the agent was never installed, a reboot simply restarts the operating system and any services that are already enabled, leaving the instance still unable to communicate with CodeDeploy. Even on instances where the agent exists but is stopped, a reboot may or may not start it, depending on the init system's service enablement, so reboot is not a reliable or sufficient action for the described problem.

• ✗

  Add a script in the Auto Scaling group's launch configuration user data to install the agent.

  Why it's wrong here

  Adding a script to the Auto Scaling group's launch configuration user data only affects instances launched after that configuration is updated; it does nothing to alter the state of instances that are already running. Current instances would need to be manually reprovisioned, replaced, or targeted with a run-command tool to execute the agent installation immediately. Furthermore, user data runs only at first boot, so simply editing the launch configuration will not retroactively apply the script to an existing fleet. This approach is a sound preventative measure for future scale-outs, but it fails as an immediate remediation for the deployment issue at hand.