AZ-400 Develop a security and compliance plan Practice Question

Answer analysis

Option-by-option breakdown

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

• ✗

  Configure a branch policy on the main branch to require a specific service connection.

  Why it's wrong here

  Branch policies on the main branch enforce signing, approval, and build validation on pull requests or direct pushes, but they operate at the commit level and have no insight into the runtime parameters of tasks in a pipeline. Once a pipeline is triggered, the policy does not examine or restrict task inputs like the service connection name or ID, and a malicious YAML can set the service connection directly. Thus, branch policies are a code-quality gate, not a service-connection security control.

• ✓

  Use a pipeline decorator to validate the service connection and fail the pipeline if an unauthorized connection is used.

  Why this is correct

  Pipeline decorators are injected into every job at execution time, allowing you to add a validation step that inspects the service connection ID used by tasks such as AzureCLI or AzurePowerShell. Because the decorator runs as part of the job definition, you can compare the connection against an approved list and call an error to fail the pipeline before deployment proceeds. This control is centralized at the organization level and cannot be bypassed by a repository without modifying the decorator itself, making it the only enforceable option.

• ✗

  Restrict the use of PATs by setting an agent pool-level permission.

  Why it's wrong here

  Agent pool-level permissions, such as 'Use' or 'Manage', restrict which agents members of the pool can run jobs on or control pool configuration; they do not govern which service connection a pipeline references. Additionally, PAT restrictions are an organization-level authentication policy that limits personal access token usage, but they do not intercept or validate the service connection being used in a task. As a result, a user with a valid PAT could still define a pipeline that invokes an unauthorized service connection.

• ✗

  Store the service connection ID in a variable group and reference it in each pipeline.

  Why it's wrong here

  Variable groups provide a central place to store values like service connection IDs, but referencing them in a pipeline is purely convention—anyone can hardcode a different connection in their YAML or override the variable value via pipeline variables. Azure DevOps does not validate that the connection used matches the variable; it only substitutes the string at runtime. This approach fails to enforce authorization, since there is no logic that checks the variable and fails on mismatch.

Go deeper

Related to this question