Managing Secrets u0026 Environment Variables in GitHub Actions Quiz Quiz

Enhance your understanding of securely managing secrets and environment variables within automated workflows. This quiz covers key concepts, practical scenarios, and recommended methods to safeguard sensitive data in continuous integration and deployment pipelines.

1. Masking Sensitive Information

   Which approach ensures that a secret, such as an API key, does not appear in the workflow logs even if a step attempts to print it?

   1. Store the secret as a secret variable and reference it using safe syntax
   2. Set the secret as a regular environment variable in the YAML file
   3. Export the secret using unquoted syntax
   4. Define the secret in plaintext inside the script section

   Explanation: Storing a secret as a secret variable and referencing it using the dedicated safe syntax ensures automatic masking in logs. Regular environment variables or plaintext definitions do not hide values if printed. Exporting secrets without proper syntax may expose them. Only specially managed secret variables are masked to protect sensitive information.

2. Secret Scope and Usage

   In a workflow where both global and job-specific secrets are set, which one takes precedence for a job that defines both a global and its own secret named 'TOKEN'?

   1. The global 'TOKEN' always overrides any job-specific secret
   2. The job-specific 'TOKEN' overrides the global one within the job
   3. Both secrets merge, and their values are concatenated
   4. The job fails due to conflicting secret names

   Explanation: Job-specific secrets with the same name as a global secret will override the global version within that job's scope. Merging or concatenation does not occur, as only one value is allowed. The global secret does not override the job-level one, and defining the same name is valid and does not cause the job to fail.

3. Passing Environment Variables Securely

   How can you provide a non-sensitive environment variable, such as a region name, to all jobs in a workflow in a maintainable and secure way?

   1. Store the variable as a secret even though it is not sensitive
   2. Add the variable value directly within each script step
   3. Declare the variable under the workflow's env key
   4. Set the variable using export commands inside every step

   Explanation: Declaring a non-sensitive environment variable in the workflow's env key sets it for all jobs and improves maintainability. Adding it directly in each step leads to repetition and errors. Storing non-sensitive data as secrets is unnecessary and complicates management. Using export commands in every step is inefficient and harder to maintain.

4. Protecting Secrets from Pull Requests

   Why are secrets not accessible to workflow runs triggered by pull requests from outside contributors by default?

   1. Because secrets are not needed in pull request workflows
   2. As a result of a configuration typo
   3. Since pull requests do not use environment variables
   4. To prevent unauthorized access to sensitive data

   Explanation: Disallowing secrets in workflows from outside contributors prevents untrusted users from accessing sensitive information. Pull requests might require secrets, but security is prioritized. Environment variables can still be used, even in pull requests, but secret exposure risk necessitates this restriction. This default is intentional and not the result of a configuration mistake.

5. Updating and Rotating Workflow Secrets

   When updating a long-lived secret, such as a token, which step should be performed to ensure workflow runs use the new value?

   1. Add the new secret as an environment variable inside a step
   2. Update the secret in the management settings and rerun or trigger the workflow
   3. Delete the old secret and do not add a new one
   4. Only change the secret in the codebase without updating management settings

   Explanation: After updating the secret in management settings, workflow runs use the latest value when they execute. Changing the secret in code without updating the configuration will not take effect. Deleting the secret without a replacement will cause workflow failures. Adding the secret as an environment variable does not integrate it securely or ensure masking.