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

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

Which TWO actions should be taken to secure secrets in Azure Pipelines? (Choose two.)

⚠ Common exam trap

It's easy for candidates to think disabling CI triggers (Option E) reduces secret exposure, but it only affects build automation, not the security of the secrets themselves, which is a common misconception about pipeline security controls.

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 secret variables with the 'secret' input type to mask them in logs.

Azure Pipelines allows you to mark variables as secret by using the 'secret' input type in the pipeline settings UI or by setting `secret: true` in YAML. This ensures the variable's value is masked with asterisks in all logs and output, preventing accidental exposure during build or release execution. Additionally, storing secrets in a variable group linked to Azure Key Vault provides a secure, centralized way to manage secrets, with access control, versioning, and auditability, making it a best practice for protecting sensitive data.

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 secret variables with the 'secret' input type to mask them in logs.
Why this is correct
In Azure Pipelines, defining variables with the `secret` input type (e.g., via the pipeline UI or YAML `${{ variables.secret }}`) ensures they are encrypted at rest and automatically masked in all pipeline logs, preventing accidental exposure. This is a fundamental practice for handling sensitive data in CI/CD, as it protects against log leakage while still allowing tasks to reference the variable securely.
✗
Use a variable group without Key Vault integration for easier management.
Why it's wrong here
While variable groups centralize variable management, storing secrets in a variable group without Azure Key Vault integration keeps them as plaintext within Azure DevOps, increasing the attack surface. Secrets should be stored in Key Vault and linked to the variable group so that access is controlled by Azure AD and managed identities, and the secrets never appear in plaintext in the pipeline definition.
✗
Store secrets directly in the YAML pipeline file.
Why it's wrong here
Hardcoding secrets directly in YAML pipeline files is a critical security flaw because the file is often committed to source control, making secrets visible to anyone with repository access and leaving them in version history indefinitely. Pipeline files are not encrypted, and such exposure can lead to unauthorized access to production resources. Instead, use Azure Key Vault or secret variables.
✓
Store secrets in a variable group linked to Azure Key Vault.
Why this is correct
By linking a variable group to Azure Key Vault, the pipeline retrieves secret values at runtime via a securely authenticated connection, ensuring secrets are never stored in plaintext within the pipeline definition or logs. This approach leverages Key Vault's access policies and audit capabilities, providing a centralized, secure way to manage and rotate secrets across pipelines.
✗
Disable CI triggers to reduce exposure.
Why it's wrong here
Disabling CI triggers only prevents automatic pipeline runs on code changes; it does not affect how secrets are stored, handled, or masked in logs, so it provides no direct improvement to secret security. Secret exposure risks stem from insecure storage, logging, or access control, not from trigger configuration. Regularly reviewing and restricting permissions is more effective.

Visual reference

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