Design and implement build and release pipelines →hardMultiple ChoiceObjective-mapped

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

Exhibit

Refer to the exhibit.
```yaml
- task: AzureKeyVault@2
  inputs:
    azureSubscription: 'MyServiceConnection'
    KeyVaultName: 'mykv'
    SecretsFilter: '*'
    RunAsPreJob: false
```

You have the above YAML task in a pipeline. The task runs but no secrets are available in subsequent tasks. What is the most likely cause?

⚠ Common exam trap

Many exam-takers assume downloading secrets automatically makes them available as environment variables in all subsequent tasks, but Azure DevOps requires explicit mapping via `$(secretName)` or the `env` keyword to prevent accidental leakage.

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

✓

The secrets are not automatically mapped to environment variables; you must reference them using $(secretName).

By default, secrets downloaded from Azure Key Vault in a pipeline task are not automatically mapped to environment variables for subsequent tasks. You must explicitly reference them using the macro syntax `$(secretName)` or map them as environment variables with the `env` keyword. Without this explicit mapping, the secret values remain inaccessible to later tasks, even though the download task succeeds.

Answer analysis

Option-by-option breakdown

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

✓
The secrets are not automatically mapped to environment variables; you must reference them using $(secretName).
Why this is correct
The Azure Key Vault task downloads secrets as pipeline variables, but it does not automatically export them to the environment of subsequent tasks. To use a secret inside a script or tool, you must reference it explicitly with the macro syntax $(secretName) or map it into the `env` section of a task. Without such explicit mapping, the secret is not visible as an environment variable, even though the task itself completed successfully.
✗
The SecretsFilter is set to '*' which is invalid.
Why it's wrong here
The wildcard '*' is a valid SecretFilter value in the Azure Key Vault task; it fetches all secrets in the vault. Therefore, setting SecretsFilter to '*' is not an error and will not prevent the task from running successfully.
✗
The service principal does not have 'Get' permission on the key vault.
Why it's wrong here
The Azure Key Vault task requires the service principal to have at least 'Get' and 'List' permissions on the vault's secrets. If those permissions were missing, the task would throw an authorization error, so a successful run indicates the principal is properly authorized.
✗
The key vault name 'mykv' does not exist.
Why it's wrong here
If the named key vault 'mykv' did not exist, the task would fail with an error indicating the vault was not found. Since the task runs without such an error, the vault name is valid and exists in the subscription.

Go deeper

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

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question