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.

• ✗

  The security group does not allow inbound traffic from CodeDeploy.

  Why it's wrong here

  The CodeDeploy service does not initiate inbound connections to instances. Instead, the CodeDeploy agent on each instance continuously polls the CodeDeploy endpoints over HTTPS (outbound) to check for pending deployments, download revisions, and report status. Therefore, even if the security group were configured to block inbound traffic from CodeDeploy, it would have no impact on the deployment workflow, because all communication originates from the instance. The absence of an inbound rule for CodeDeploy is irrelevant; the real cause is that the agent is not installed to perform that outbound polling.

• ✗

  The instances do not have the correct IAM role to allow CodeDeploy to access them.

  Why it's wrong here

  While an IAM role with the appropriate permissions for CodeDeploy is absolutely required—it allows the agent to authenticate and call the CodeDeploy API—a missing or misconfigured IAM role is not the direct cause of the reported symptom. If the instance were missing the correct IAM role, the agent (if installed) would fail during its registration or when attempting to fetch deployment tasks, and you would typically see a different error, such as an authorization failure. The scenario states the instances simply do not report to CodeDeploy at all, which is the classic symptom of the agent not being installed, not an IAM issue. Without the agent, no IAM role can make the instance reachable or visible to the deployment service.

• ✗

  The application is not running on the instances.

  Why it's wrong here

  The status of the application running on the instance is separate from the CodeDeploy agent's reporting process. During a deployment, CodeDeploy tracks the execution of AppSpec lifecycle hooks (e.g., ApplicationStart) based on their exit codes, not on the actual runtime health of the application afterward. Even if the application fails to start or is not running, the agent still executes the hooks and reports the deployment result to the CodeDeploy service. Thus, the application not running would not cause the instance to be missing from the deployment console or to be marked as unreachable; that symptom is exclusively tied to the absence of the agent itself.

• ✓

  The CodeDeploy agent is not installed on the instances.

  Why this is correct

  The CodeDeploy agent is the on-instance software component responsible for all communication with the CodeDeploy service. It polls the CodeDeploy endpoint for queued deployments, downloads the application revision, runs the lifecycle event scripts defined in the AppSpec file, and reports success or failure back to the service. Without the agent installed on an instance, the instance cannot receive any deployment commands, and CodeDeploy will report that no instances are connected or that the deployment is stuck with zero healthy instances. This is the exact, direct reason why the deployment is not progressing; installing and starting the agent on each target instance would resolve the issue.

Go deeper

Related to this question