GitHub Actions for Continuous Deployment (CD) Quiz Quiz

Explore core concepts and best practices of continuous deployment workflows using automation pipelines. Assess your understanding of triggers, environment security, deployment strategies, and workflow configuration in modern code delivery processes.

1. Workflow Triggers

   Which event should you specify to automatically deploy your application when code is merged into the main branch?

   1. push
   2. deployment
   3. issue_comment
   4. pull_request

   Explanation: Selecting 'push' allows your workflow to run whenever new commits reach the main branch, which is ideal for deploying after merges. 'pull_request' only triggers workflows on proposed changes before merging. 'deployment' is used for deployment APIs and isn't a direct trigger for code changes. 'issue_comment' triggers when comments are made on issues and is unrelated to code deployment.

2. Environment Protection

   What is the main purpose of using protected environments during continuous deployment?

   1. To automate code reviews for all pull requests
   2. To ensure only authorized workflows can deploy to production
   3. To enable syntax highlighting in configuration files
   4. To optimize build speed by caching dependencies

   Explanation: Protected environments prevent unauthorized or unintended deployments by requiring approval or specific workflow conditions, enhancing security. Caching dependencies focuses on build optimization, not environment protection. Code reviews are unrelated to deployment environments, and syntax highlighting has no effect on deployment safety.

3. Deployment Strategy

   When aiming for zero-downtime deployment of a web service, which approach is most appropriate in an automated workflow?

   1. Manual SSH update
   2. Commenting out the server start command
   3. Blue-green deployment
   4. Rolling back to the previous version

   Explanation: Blue-green deployment minimizes service outages by switching traffic between two environments, enabling zero-downtime releases. Manual SSH updates are error-prone and cannot guarantee continuous availability. Rolling back is addressed after a failed deployment, not as a strategy to avoid downtime. Commenting out startup commands would prevent service operation, not achieve zero downtime.

4. Secrets Management

   How should sensitive deployment credentials be stored and accessed within a deployment workflow?

   1. Include them in the job’s log output for reference
   2. Commit them directly to the version control repository
   3. Write them into plaintext files on the server
   4. Add them as encrypted secrets referenced in the workflow

   Explanation: Encrypted secrets allow controlled, secure access to sensitive credentials within workflows, preventing exposure. Committing sensitive information to version control is unsafe, as it risks exposure to anyone with access. Storing credentials in plaintext files is vulnerable to unauthorized access. Logging secrets exposes them in build logs, making them easily accessible to others.

5. Workflow Syntax Errors

   If your deployment workflow fails with a syntax error, what is the recommended method to test changes before pushing them again?

   1. Add more comments to the workflow file
   2. Rename the main branch to troubleshoot
   3. Use local workflow linting or validation tools before committing
   4. Increase the timeout setting for the deployment job

   Explanation: Local linting or validation tools help identify and fix syntax errors before code is pushed, reducing failed runs. Extending the timeout does not address syntax issues. Adding comments aids readability but doesn't fix errors. Renaming the main branch is unrelated to resolving workflow syntax problems and can introduce further complications.