Three Measures That Protect API Keys and Passwords in Pipelines
Which THREE measures should you implement to protect secrets (e.g., API keys, passwords) used in Azure Pipelines?
Quick Answer
Protecting secrets in Azure Pipelines comes down to three habits: mark pipeline variables as Secret so they're masked in logs, use service connections backed by managed identity instead of personal access tokens, and store the actual values in Azure Key Vault referenced through a Key Vault task. Plain-text secrets in a repo or unencrypted environment variables are never safe, however restricted access looks.
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
✓
Mark variables as 'Secret' in pipeline YAML or UI definitions
To protect secrets like API keys and passwords in Azure Pipelines, you should implement three key measures. First, mark variables as 'Secret' in pipeline YAML or UI definitions (Option B). This prevents the secret from being displayed in logs or output. Second, use service connections with managed identity instead of personal access tokens (Option D). Managed identities eliminate the need to store credentials and reduce secret exposure. Third, store secrets in Azure Key Vault and reference them via a Key Vault task (Option E). This centralizes secret management and allows fine-grained access control. Option A is incorrect because storing secrets as plain text in a Git repo, even with restricted access, is insecure—secrets should never be committed to source control. Option C is incorrect because environment variables are not encrypted by default and can be exposed in logs or to other pipeline tasks, making them unsafe for secret passing.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Store secrets as plain text in a secure Git repo with restricted access
Why it's wrong here
Storing secrets in Git, even with restricted access, is not secure.
- ✓
Mark variables as 'Secret' in pipeline YAML or UI definitions
Why this is correct
Secret variables are masked in logs and output.
- ✗
Use environment variables in the pipeline to pass secrets at runtime
Why it's wrong here
Environment variables can be logged if not properly handled.
- ✓
Use service connections with managed identity instead of personal access tokens
Why this is correct
Managed identities eliminate the need for stored credentials.
- ✓
Store secrets in Azure Key Vault and reference them via a Key Vault task
Why this is correct
Key Vault provides secure storage and access control.
Go deeper
Related to this question
Learn chapter
Introduction to DevOps and Azure DevOps
Key term
Least privilege
Least privilege is a security principle that means giving users, systems, or programs only the minimum permissions they need to do their job and nothing more.
Key term
Azure Key Vault
Azure Key Vault is a cloud service for securely storing and managing sensitive information like passwords, encryption keys, and certificates.
About these practice questions
Courseiva writes every AZ-400 question from scratch — 823 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way this is tested on AZ-400
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. Which THREE measures should you implement to protect secrets used in GitHub Actions workflows? (Choose three.)
hard- A.Use hardcoded secrets in workflow files for simplicity.
- ✓ B.Enable secret scanning to detect secrets in code pushes.
- C.Use the same secret across all environments to reduce management overhead.
- ✓ D.Use OpenID Connect (OIDC) to authenticate to Azure without storing credentials.
- ✓ E.Store secrets as GitHub repository secrets or organization secrets.
Why B: GitHub secret scanning automatically detects and alerts on secrets (like API keys and tokens) pushed to repositories, preventing accidental exposure. This is a proactive security measure that integrates with GitHub's push protection to block commits containing known secret patterns. Additionally, storing secrets as GitHub repository secrets or organization secrets ensures they are encrypted and available only to authorized workflows, avoiding hardcoded values. Using OpenID Connect (OIDC) to authenticate to Azure without storing credentials is also a valid measure because it removes the need to store secrets altogether.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This AZ-400 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the AZ-400 exam.