GitHub Secrets and Secure Workflow Practices Quiz Quiz

Assess your knowledge on managing secrets and implementing secure automated workflows in the modern tools ecosystem. This quiz covers best practices, configurations, and security considerations for safeguarding credentials and sensitive data within automation pipelines.

1. Environment Secrets Usage

   Which statement best describes how secrets stored in an environment are accessed within a workflow, such as when deploying to production?

   1. Secrets must be explicitly referenced in workflow steps to be accessible.
   2. Secrets are exposed to all jobs automatically once they are created.
   3. Secrets can only be accessed by administrators regardless of workflow permissions.
   4. Secrets with the same name as environment variables are automatically overwritten.

   Explanation: Secrets stored in environments are not made available globally; they must be specifically referenced in a job or step to be accessed. The idea is to minimize unnecessary exposure of sensitive information. The claim that secrets are available to all jobs automatically is incorrect, as access is scoped and controlled. Restricting secrets only to administrators misunderstands workflow permissions, as jobs with correct rights can access them. Having the same name as existing environment variables does not cause secrets to overwrite those variables automatically.

2. Protecting Sensitive Data in Logs

   When designing a workflow that uses secrets to access an external database, what is the recommended method to prevent secrets from being leaked in the logs?

   1. Avoid logging commands that output secrets and use built-in masking features.
   2. Disable all logs for workflow runs by default.
   3. Store secrets as plain text variables for transparency.
   4. Print secrets to logs only in failed steps for troubleshooting.

   Explanation: The best practice is to never log outputs that contain secrets and to utilize features that automatically mask secrets in logs. Workflows should not disable all logs, as this hinders transparency and debugging. Storing secrets as plain text variables compromises security. Printing secrets during failures still poses risk, as anyone with log access could retrieve sensitive information.

3. Secrets Scope and Workflow Triggers

   If a public repository uses secrets in a workflow triggered by pull requests from external contributors, what happens to those secrets?

   1. Secrets are not available to workflows run from forks for security reasons.
   2. All secrets are automatically exposed to all pull request workflows.
   3. Secrets are available only if their names end with '_PUBLIC'.
   4. Secrets are only available if stored as encrypted files in the repository.

   Explanation: For security, secrets are withheld from workflows run on code originating from forks to prevent leaks by untrusted code. They are not universally exposed to all triggers, which would present a major vulnerability. The suggestion about names ending with '_PUBLIC' does not correlate with how secrets work. Storing secrets as encrypted files is a separate concept and does not control availability in workflows.

4. Revoking Compromised Secrets

   What is the most effective immediate action if you suspect that a workflow secret has been exposed or leaked?

   1. Revoke the secret and replace it with a new value as soon as possible.
   2. Delete the workflow that used the secret.
   3. Wait to see if any suspicious activity occurs before taking action.
   4. Change unrelated workflow permissions for other jobs.

   Explanation: The safest response is to invalidate and rotate the affected secret without delay. Deleting the workflow does not prevent the secret from being misused if already leaked. Waiting for suspicious activity is risky, as attackers may act before detection. Changing unrelated workflow permissions does not address the compromised secret directly.

5. Best Practices for Secret Storage

   Where should you store credentials needed for workflow automation to reduce security risks, assuming direct in-file storage is not allowed?

   1. Store them in the native secrets management functionality of the automation platform.
   2. Define them as custom input parameters in the workflow file.
   3. Add them as unencrypted environment variables in the code repository.
   4. Include them in comments for easy reference.

   Explanation: Using the platform's dedicated secrets management system ensures credentials are stored securely, with granular access controls and automatic masking. Placing credentials as workflow inputs or unencrypted variables risks accidental exposure. Including secrets in comments is highly insecure and can be retrieved easily. These methods do not provide the level of protection needed for sensitive information.