Deploying to AWS with GitHub Actions Quiz Quiz

Enhance your understanding of deploying cloud applications using GitHub Actions workflows. This quiz covers cloud integration, deployment best practices, and troubleshooting common automation scenarios in continuous delivery pipelines.

1. Workflow Triggering

   Which event would most appropriately trigger a deployment workflow that automatically pushes code changes to a cloud environment after a successful review?

   1. pull_request merged into main
   2. push to a feature branch
   3. pull_request opened
   4. issue closed

   Explanation: The correct answer is 'pull_request merged into main' because deployments should typically occur after code changes are reviewed and merged into the main branch to ensure stability. 'push to a feature branch' and 'pull_request opened' happen before code review is complete, risking unstable code being deployed. 'issue closed' is unrelated to code changes and would not trigger a deployment workflow.

2. Credentials Management

   When configuring a workflow to deploy to a cloud service, which practice ensures your deployment credentials remain secure within the automation process?

   1. Including credentials in environment variables within the codebase
   2. Hardcoding credentials in the workflow
   3. Placing credentials in plaintext in a public file
   4. Using encrypted secrets stored in the repository settings

   Explanation: Using encrypted secrets in repository settings is the safest way to manage credentials in automation, as it prevents unauthorized access and keeps secrets out of your codebase. Hardcoding credentials and including them in plaintext or in environment variables within the code exposes them to all users with code access. Proper secrets management is essential for security best practices.

3. Deployment Rollbacks

   Suppose a deployment fails due to a misconfiguration in the workflow; what is a commonly recommended first step to ensure service continuity?

   1. Rollback to the previous stable release
   2. Delete the current repository
   3. Permanently disable all future deployments
   4. Ignore the failure and redeploy

   Explanation: Rolling back to the previous stable release restores service to a known good state, which minimizes downtime and disruption. Ignoring failures and redeploying without analysis can perpetuate issues. Disabling all deployments or deleting the repository are extreme, unnecessary measures that do not address service continuity or troubleshooting best practices.

4. Build Artifact Handling

   Which method is best practice for sharing build artifacts between jobs in a multi-job workflow for cloud deployment?

   1. Passing via environment variables
   2. Modifying the repository's main branch directly
   3. Uploading and downloading artifacts within the workflow
   4. Manually copying files after success

   Explanation: Uploading and downloading artifacts within the workflow is the preferred method for sharing files securely and efficiently between jobs. Passing artifacts through environment variables is not feasible for binary files, and manual copying is not possible between separate jobs. Modifying the repository directly is not necessary and risks introducing unintended changes.

5. IAM Permissions

   If your workflow fails with a permission error while deploying to a cloud environment, what is the most likely cause?

   1. Incorrect application port
   2. Outdated dependency installed
   3. Typo in the application code function
   4. Insufficient privileges in the role or credentials used

   Explanation: Permission errors usually indicate that the credentials provided to the workflow do not have adequate privileges to perform deployment actions. Incorrect ports or outdated dependencies would trigger different error messages, while a typo in the code function would likely be caught at build or test time rather than during deployment.