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.
⚠ Common exam trap
AZ-400 often tests the misconception that environment variables or restricted Git repos are secure for secrets, tempting candidates to choose options that still expose credentials.
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
Option B is correct because marking variables as 'Secret' in the pipeline YAML (using the secret variable syntax) or in the UI variable group causes Azure Pipelines to encrypt the value at rest, mask it in logs, and avoid exposing it in plain text during runs. Option D is correct because service connections backed by managed identity (or workload identity federation) eliminate long-lived personal access tokens and stored credentials, letting the pipeline authenticate to Azure resources without embedding secrets. Option E is correct because Azure Key Vault centralizes secret storage with access policies/RBAC and auditing, and the AzureKeyVault@2 task (or Key Vault variable group linking) retrieves secrets at runtime so they are never committed to the repo. Option A is not appropriate because storing secrets as plain text in Git—even a restricted repo—leaves them in version history and readable by anyone with repo access. Option C is not a distinct protection measure because environment variables alone do not encrypt, mask, or vault the secret; without the 'Secret' marking or Key Vault integration the value can still leak into logs or process listings.
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
Git history retains every committed value, so plain-text secrets remain recoverable by anyone with repository read access, including across forks and clones. This is tempting because a restricted repository feels controlled. Azure Key Vault with pipeline variable groups is the correct mechanism, since it stores secrets encrypted and outside version control.
- ✓
Mark variables as 'Secret' in pipeline YAML or UI definitions
Why this is correct
Marking variables as secret encrypts their values at rest and masks them in logs, preventing accidental exposure during pipeline runs. This directly satisfies the stem's requirement to protect API keys and passwords stored in Azure Pipelines.
- ✗
Use environment variables in the pipeline to pass secrets at runtime
Why it's wrong here
Plain environment variables are visible in logs, job output and the agent process, and are not masked unless explicitly marked as secrets. This is tempting because variables are the standard way to parameterise pipelines. The correct approach is linking an Azure Key Vault-backed variable group, which keeps values encrypted and masks them in logs.
- ✓
Use service connections with managed identity instead of personal access tokens
Why this is correct
Service connections with managed identities eliminate stored credentials entirely, satisfying the requirement to protect secrets in Azure Pipelines. Microsoft Entra ID issues short-lived tokens automatically, so no API keys or passwords persist in pipeline configuration. This removes the exfiltration risk inherent in personal access tokens, which are long-lived bearer credentials requiring manual rotation and secure storage.
- ✓
Store secrets in Azure Key Vault and reference them via a Key Vault task
Why this is correct
Azure Key Vault centralises secret storage with access policies, auditing and rotation, and the Key Vault task injects values at runtime without persisting them in pipeline definitions. This satisfies the stem's requirement to protect API keys and passwords.
Visual reference
Quick reference
Access Control Model Comparison
| Model | Acronym | Who Controls Access? | Best For |
|---|---|---|---|
| Discretionary Access Control | DAC | Resource owner | Small teams, file shares |
| Mandatory Access Control | MAC | System / security labels | Classified govt / military |
| Role-Based Access Control | RBAC | Administrator (via roles) | Enterprise environments |
| Attribute-Based Access Control | ABAC | Policy engine (user + resource attributes) | Fine-grained, dynamic policies |
| Rule-Based Access Control | RuBAC | System rules / ACLs | Firewall rules, network ACLs |
Go deeper
Related to this question
Learn chapter
Managing Infrastructure as Code Using Azure
Key term
Environment
An environment is a dedicated set of computing resources, configurations, and services used to develop, test, or host software applications in a controlled and repeatable way.
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 — 696 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: Option B is correct because enabling secret scanning (including push protection) lets GitHub detect and block credentials committed to the repository, catching accidental leaks before they are exploited. Option D is correct because configuring OpenID Connect (OIDC) with a federated identity credential allows GitHub Actions to authenticate to Azure via short-lived tokens, eliminating the need to store long-lived cloud credentials as secrets. Option E is correct because storing values as GitHub repository secrets or organization secrets keeps them encrypted at rest, masks them in logs, and injects them only at runtime rather than exposing them in workflow files. Option A is wrong because hardcoding secrets in workflow YAML exposes them in plaintext to anyone with repository read access and in logs. Option C is wrong because reusing one secret across all environments removes isolation, so a compromise in a low-trust environment grants access to production.
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Microsoft exam blueprint
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.