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.

• ✗

  Upload the cookbook to Amazon S3 and reference the S3 URL

  Why it's wrong here

  Uploading the cookbook to Amazon S3 and referencing the S3 URL is possible because OpsWorks supports S3 as a cookbook source, but this approach requires you to manually rebuild and re-upload the archive every time your Chef recipes change. It also removes the benefits of version control and automated fetching from your Git repository, making it error-prone and operationally heavy. Because the organization's recipes are already in a private GitHub repository, using S3 would introduce a disconnected, manually maintained artifact rather than a synchronized source of truth.

• ✗

  Make the GitHub repository public

  Why it's wrong here

  Making the GitHub repository public would allow OpsWorks to clone it without authentication, but it exposes all of your Chef cookbook code, including any embedded secrets, credentials, or infrastructure logic, to anyone on the internet. This violates the principle of least privilege and could enable attackers to study your environment for targeted exploitation. Even if the code seems non-sensitive, public exposure creates compliance and security risks that far outweigh the convenience of avoiding SSH-key configuration.

• ✓

  Configure an SSH key in the OpsWorks stack to access the private repository

  Why this is correct

  Configuring an SSH key in the OpsWorks stack is the correct method because OpsWorks natively supports private Git repositories by letting you supply a private SSH key in the Repository SSH Key field for custom cookbooks. You add the matching public key as a deploy key on the GitHub repository with read-only access, and OpsWorks uses that key to authenticate when it downloads or updates cookbooks on your instances. This keeps the repository private and avoids storing plaintext credentials, while also allowing Chef to automatically pull the latest cookbook revisions during stack updates and instance setup.

• ✗

  Store the GitHub credentials in the OpsWorks stack settings

  Why it's wrong here

  Storing the GitHub credentials in the OpsWorks stack settings is not supported because OpsWorks does not provide a native field for GitHub usernames or passwords when configuring a cookbook source. OpsWorks instead expects either a publicly reachable URL or an SSH private key for private Git repositories, and it has no mechanism to perform credential-based HTTPS authentication to GitHub. Attempting to place credentials in other stack settings would be non-functional and could accidentally expose sensitive information in stack configuration or logs, which is why the SSH key approach is the recommended alternative.

Go deeper

Related to this question