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

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

Your organization uses Azure Pipelines and wants to enforce that all builds must pass a security scan before being deployed to production. The security scan is performed by a third-party tool that is not available as a built-in task. You have installed the tool on a self-hosted agent. What is the best way to integrate the security scan into the pipeline?

⚠ Common exam trap

Test-takers frequently assume a marketplace task or service hook is required for any third-party tool, overlooking the simplicity and directness of using a command-line task when the tool is already installed on a self-hosted agent.

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 a command-line task (e.g., Bash, PowerShell) to execute the security scan tool.

The security scan tool is installed on a self-hosted agent but not available as a built-in task or marketplace extension. Using a command-line task (Bash or PowerShell) allows you to directly invoke the tool's executable from the agent's file system, passing necessary parameters and capturing exit codes to determine success or failure. This approach integrates seamlessly with Azure Pipelines' standard task execution model without requiring custom extensions or external service hooks.

Answer analysis

Option-by-option breakdown

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

✗
Add the tool as a capability of the agent pool and use the 'Install Tool' task.
Why it's wrong here
Agent capabilities only advertise installed software to the pipeline, and the 'Install Tool' task merely provisions a specified tool version onto the agent environment. Neither mechanism executes the security scan itself, so the pipeline would still lack a step that actually invokes the scanner against the code or build artifacts.
✗
Add the 'Run Security Scan' task from the Azure DevOps marketplace.
Why it's wrong here
The Azure DevOps Marketplace does not offer a generic or official task named 'Run Security Scan'; security scanning is provided by vendor-specific extensions (e.g., SonarQube, WhiteSource, Checkmarx) or by running a script that calls the scanner's CLI. Adding a nonexistent generic task would either fail during build or require a specific published extension, not a universal solution.
✗
Create a custom service hook to trigger the scan externally and wait for results.
Why it's wrong here
Service hooks are asynchronous integrations that push Azure DevOps events to external systems, not a mechanism to run tools on the pipeline agent. Even if you triggered an external scan via a hook, you would need additional custom polling or callback logic to wait for results and link them back to the running job, which is an unreliable and overly complex substitute for a direct pipeline task.
✓
Use a command-line task (e.g., Bash, PowerShell) to execute the security scan tool.
Why this is correct
A Command-Line, Bash, or PowerShell task can directly invoke any installed security scanning executable (e.g., Trivy, OWASP ZAP, a custom CLI, or a vendor's command-line tool) with the appropriate arguments, run it against the repository workspace, and fail the pipeline based on the tool's exit code. This is the standard, supported way to integrate command-line-based security scanning into an Azure Pipeline because it runs inside the agent job and can produce actionable results.

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