Design and implement build and release pipelines →mediumMultiple SelectObjective-mapped

AZ-400 Practice Question: Design and implement build and release pipelines

Which TWO are valid strategies for managing secrets in a GitHub Actions workflow?

⚠ Common exam trap

Watch out — candidates often confuse Base64 encoding with encryption, mistakenly believing it provides security, or they think environment variables on the runner are isolated per job, when in fact they can leak across steps or be read by other processes on the same runner.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Use OpenID Connect to authenticate to Azure without storing any credentials.

OpenID Connect (OIDC) allows GitHub Actions to exchange a short-lived token directly with Azure without storing any long-lived credentials as secrets. This eliminates the need to manage and rotate client secrets or service principal passwords, reducing the risk of credential leakage. The workflow uses the `azure/login` action with `client-id`, `tenant-id`, and `subscription-id` parameters, and Azure trusts the OIDC token issued by GitHub. Alternatively, storing the secret as an encrypted GitHub secret is also a valid strategy: GitHub encrypts secrets at rest and injects them into the workflow runtime only when referenced via `${{ secrets.SECRET_NAME }}`. This prevents hardcoding secrets in the YAML and keeps them out of logs, though it still requires managing the secret value and rotation.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✓
Use OpenID Connect to authenticate to Azure without storing any credentials.
Why this is correct
OpenID Connect (OIDC) allows GitHub Actions workflows to request short-lived tokens from Azure AD by exchanging a signed JWT from GitHub's OIDC provider, eliminating the need to store static credentials like client secrets or service principal passwords. This is a valid strategy because it reduces secret exposure and enables automatic credential rotation.
✗
Hardcode the secret in the YAML file.
Why it's wrong here
Hardcoding secrets directly into YAML workflow files places plaintext credentials in version control, making them visible to anyone with repository access and permanently embedded in git history. This is invalid because it violates secret management best practices and cannot be safely rotated without rewriting history.
✗
Set the secret as an environment variable in the runner's shell profile.
Why it's wrong here
Setting secrets as environment variables in a runner's shell profile (e.g., ~/.bashrc) makes them accessible to all processes and users on the runner, and they are not scoped to the repository or pipeline. This is invalid because it offers no encryption, persists on the runner, and can be exposed to unauthorized code execution.
✗
Base64-encode the secret and include it directly in the workflow file.
Why it's wrong here
Base64 encoding is an encoding scheme, not encryption, so the secret can be trivially decoded by anyone with the workflow file, and it remains in plaintext in git history. This is invalid as it gives a false sense of security and does not protect the secret from exposure.
✓
Store the secret as an encrypted GitHub secret and reference it using ${{ secrets.SECRET_NAME }}.
Why this is correct
GitHub Secrets are encrypted at rest and injected into the workflow runtime only when referenced, so they never appear in logs or in the workflow source. This is a valid strategy because it centralizes secret storage, supports rotation, and restricts access to authorized workflows.

Go deeper

AZ-400 Practice Question: Design and implement build and release pipelines

Why each option matters

Option-by-option breakdown

Related to this question