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 CodeDeploy agent requires ruby and wget, which are not installed by default on Amazon Linux 2.

  Why this is correct

  On Amazon Linux 2, Ruby and wget are not installed by default, and the CodeDeploy agent is a Ruby application that also relies on wget to download deployment artifacts. If these dependencies are missing, the agent process either fails to start or crashes immediately, so the instance never registers with CodeDeploy and the deployment hangs at the 'Stop' or 'BeforeInstall' step. The standard installation procedure requires running `yum install -y ruby wget` before installing the agent, so an AMI that omits them will cause exactly this failure.

• ✗

  The S3 bucket containing the deployment artifacts has a bucket policy that denies access to the instances.

  Why it's wrong here

  A bucket policy that denies access would only matter after the CodeDeploy agent is running and attempts to download the revision from S3; it would produce an 'AccessDenied' error in the deployment logs at the DownloadAppSpec stage. In this scenario, the agent never runs at all because Ruby and wget are absent, so the deployment fails before any S3 API call is made. Even a completely permissive S3 policy would not fix the failure, proving the root cause is the missing dependencies, not the bucket policy.

• ✗

  The deployment configuration is set to 'OneAtATime', causing insufficient healthy instances during the first deployment.

  Why it's wrong here

  The 'OneAtATime' deployment configuration is the default and is not inherently prone to insufficient healthy instances; it reduces risk by shifting traffic to only one instance at a time. On a first deployment, all instances are initially healthy, so there is no reason for the fleet to fall below the minimum healthy host threshold unless the agent is broken on each target. The deployment never begins the instance-by-instance progression because the instances are unregistered, so the deployment configuration is irrelevant to this failure.

• ✗

  The Auto Scaling group has a minimum of 0 instances, so the deployment cannot start.

  Why it's wrong here

  An Auto Scaling group with a minimum of 0 still permits running instances, and CodeDeploy deploys to the current instances that are attached to the group regardless of the minimum capacity value. As long as at least one instance exists in the ASG and has a healthy agent, a deployment will start; the minimum setting only controls scaling behavior, not whether deployments are allowed. If the ASG were empty, the deployment would have no targets, but the presence of instances means the deployment can begin, so a zero minimum is not the blocker.

Go deeper

Related to this question