AZ-400 Practice Test 33 — 15 Questions

Question 1

Your Azure DevOps project uses a self-hosted agent pool. Users report that builds are randomly failing with a 'disk full' error. The agents have 50 GB of disk space. What is the most effective way to mitigate this issue?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

Enable the 'Clean after build' option on the build pipeline. Enabling 'Clean after build' ensures workspace cleanup after each run, reclaiming disk space to prevent failures. Option A is wrong because adding more agents doesn't free disk space on existing agents. Option B is wrong because 'Clean all build directories' cleans before builds, which may not prevent mid-build disk full errors and can disrupt parallel builds. Option D is wrong because limiting parallel jobs doesn't free disk space; a single build can still consume all available disk space.

Answer

Add more agents to the pool

Answer

Use the 'Clean all build directories' option in the agent configuration

Answer

Set 'Maximum number of parallel jobs' to 1

Question 2

Refer to the exhibit. A developer queues a build manually but notices the build status remains 'notStarted' for an extended period. The pipeline has no demands and priority is normal. Which is the most likely cause?

Accepted Answer

All agents in the pool are currently busy.. When a build remains in 'notStarted' status for an extended period, it typically means the pipeline is waiting for an available agent. Since the pipeline has no demands and priority is normal, the most likely cause is that all agents in the specified agent pool are currently busy executing other jobs, so the build is queued until an agent becomes free.

Answer

The variable 'BuildConfiguration' is misspelled.

Answer

The branch 'main' does not exist.

Answer

The pipeline definition ID is incorrect.

Question 3

Your team uses Azure Pipelines to build a .NET Core application. You notice that the build takes too long because it restores NuGet packages every time. What is the best way to improve build performance?

Accepted Answer

Enable the 'Cache' task to cache the NuGet packages folder. The best way to improve build performance is to cache the NuGet packages folder using the 'Cache' task in Azure Pipelines. This avoids re-downloading packages on each run. Option A (self-hosted agent) is not guaranteed to cache the packages folder across builds unless caching is explicitly configured. Option B (faster network) may help but doesn't eliminate the restore time. Option C (larger SKU) improves CPU/memory but does not cache packages. Therefore, option D is correct.

Answer

Configure the build to use a self-hosted agent with previously restored packages

Answer

Use a private agent with a faster network connection

Answer

Use a Microsoft-hosted agent with a larger SKU

Question 4

A developer reports that their Azure DevOps pipeline is failing with 'Access denied' when trying to push to a protected branch. The branch policy requires a successful build and approval from the 'Code Owners' group. The developer is a member of 'Contributors' but not 'Code Owners'. What is the most likely cause?

Accepted Answer

The developer is not in the 'Code Owners' group allowed to bypass the policy.. The branch policy requires membership in the 'Code Owners' group to push directly to the branch. The developer is not a member, so they get 'Access denied'. Option A (invalid characters) would cause a different error. Option B (pipeline service principal lacking permission) is unrelated to the developer's push. Option C (lacking 'Contribute' permissions at project level) is less specific and would result in a different error; the error here is specifically due to branch policy enforcement.

Answer

The branch name contains invalid characters.

Answer

The pipeline's service principal lacks 'Create Branch' permission.

Answer

The developer lacks 'Contribute' permissions at the project level.

Question 5

A developer accidentally committed a sensitive password to a Git repository. The commit has already been pushed to the remote. What is the first step to remediate the situation?

Accepted Answer

Immediately notify the security team and rotate the password. Once a secret is pushed to a remote Git repository, it must be considered compromised because the commit may already be fetched by others, and old commits remain in reflogs and other clones. The first step is to immediately notify the security team and rotate/revoke the password to prevent unauthorized use. Only after the credential is invalidated should you attempt to remove it from Git history (e.g., by amending, rebasing, or using filter-repo) and force push, understanding that history rewriting may not fully eliminate all copies.

Answer

Delete the file from the repository and commit the deletion

Answer

Remove the password from the file, amend the commit, and force push

Answer

Revert the commit that introduced the password

Question 6

Which TWO actions can you take to improve the security of secrets in Azure Pipelines? (Choose two.)

Accepted Answer

Limit variable group permissions to specific pipelines. Limiting variable group permissions to specific pipelines ensures that only authorized pipelines can access sensitive secrets, reducing the risk of unauthorized exposure. Option D is correct because Azure Key Vault provides a centralized, auditable, and encrypted store for secrets, and mapping them as secret variables in Azure Pipelines prevents the secret values from being exposed in logs or output.

Answer

Log secret values for debugging purposes

Answer

Allow pipeline users to override secret values at queue time

Answer

Store secrets as plain text variables in the pipeline

Question 7

You are designing a release pipeline that deploys to multiple environments (dev, test, prod) sequentially. You need to require manual approval before deploying to prod. The approver should be able to review the changes and approve or reject. Which feature should you use?

Accepted Answer

Pre-deployment conditions.. In Azure DevOps release pipelines, to require manual approval before deploying to a specific stage, you configure the pre-deployment conditions of that stage, specifically assigning pre-deployment approvers. These approvers can review the changes and then approve or reject the deployment. This satisfies the requirement directly.

Answer

Environment checks.

Answer

Approval gates.

Answer

Manual intervention task.

Question 8

Which THREE options are valid strategies for implementing progressive exposure in Azure Pipelines?

Accepted Answer

Ring-based deployment.. Ring-based deployment, canary deployment, and blue-green deployment are all valid strategies for progressive exposure. Ring-based deployment gradually rolls out to increasing groups of users (rings), often using deployment gates and percentage-based rollout. Canary deployment routes a small percentage of traffic to the new version before increasing it, allowing monitoring and rollback. Blue-green deployment runs two identical environments (blue and green) and switches traffic from the old to the new version, enabling immediate rollback. These strategies all provide controlled, incremental exposure to validate changes before full rollout.

Answer

Rolling update.

Answer

Immutable infrastructure.

Question 9

Your organization uses GitHub Actions for CI/CD. You want to ensure that the workflow runs only when a pull request is labeled 'safe-to-deploy'. Which trigger should you use?

Accepted Answer

on:
  pull_request:
    types: [labeled]
    branches: [main]. The `pull_request` trigger with `types: [labeled]` is the correct event to detect label additions. However, it triggers for any label, not just 'safe-to-deploy'. To ensure the workflow runs only when that exact label is applied, you must combine this trigger with a job-level conditional, e.g., `if: github.event.label.name == 'safe-to-deploy'`. The answer option C is still the correct trigger, but the explanation must clarify this additional required condition.

Answer

on:
  workflow_run:
    workflows: ["Build"]
    types: [completed]

Answer

on:
  issue_comment:
    types: [created]

Answer

on:
  pull_request_target:
    types: [opened, synchronize]
    branches: [main]

Question 10

Your team uses Azure DevOps and wants to automatically scan pull requests for secrets before they are merged. Which Azure DevOps feature should you use?

Accepted Answer

GitHub Advanced Security.. GitHub Advanced Security (GHAS) for Azure DevOps provides secret scanning that automatically detects secrets (e.g., API keys, passwords, connection strings) in pull requests before they are merged. This feature is integrated into Azure Repos when Advanced Security is enabled and triggers on PR creation, blocking the merge if secrets are found. Therefore, the correct choice is GitHub Advanced Security, not a separate 'Secret scanning in Azure DevOps' feature, which does not exist as a native built-in feature.

Answer

Azure Policy.

Answer

Secret scanning in Azure DevOps.

Answer

Branch policy with a required reviewer.

Question 11

Which TWO are best practices when configuring alerts in Azure Monitor for a production application?

Accepted Answer

Use dynamic thresholds for metrics with seasonal patterns.. Dynamic thresholds in Azure Monitor use machine learning to automatically detect and adjust alert thresholds based on historical patterns, making them ideal for metrics with seasonal or cyclical behavior (e.g., CPU usage that spikes during business hours). This reduces alert noise and manual tuning effort compared to static thresholds.

Answer

Use metric alerts only for simple threshold-based conditions.

Answer

Create separate alert rules for each condition to avoid complexity.

Answer

Ensure each alert rule uses a unique action group to isolate notifications.

Question 12

Your organization uses GitHub Enterprise and wants to enforce that all repositories have a consistent CODEOWNERS file. Which approach should you use to centrally manage this?

Accepted Answer

Create a CODEOWNERS file at the organization level. In GitHub Enterprise, you can create a special repository named `.github` at the organization level. A CODEOWNERS file stored in that repository is applied as a default to all repositories in the organization, providing centralized management. Repository rulesets cannot require that a file exists; they enforce branch/tag rules such as required reviews and status checks, but not file existence.

Answer

Use repository rulesets to require that the CODEOWNERS file exists and has a specified pattern

Answer

Use a script to push CODEOWNERS to each repo manually

Answer

Create a GitHub Actions workflow that runs on push to check CODEOWNERS

Question 13

You see the above YAML pipeline trigger configuration in an Azure Pipeline. The repository uses Git Flow with branches: feature/new-feature, develop, release/v1.0, and main. A developer pushes a commit to the branch feature/new-feature. Which action will trigger the pipeline?

Accepted Answer

No trigger will start.. The YAML trigger configuration (shown) explicitly lists the branches that trigger CI. Since feature/new-feature is not included in the branch filter, a push to that branch does not start a CI run. PR triggers are separate and require an actual PR to be created, not a push.

Answer

A CI trigger will start because the branch name starts with 'feature/'.

Answer

A PR trigger will start because the branch name contains 'feature'.

Answer

A CI trigger will start for all branches because batch is set to true.

Question 14

You are the DevOps lead for a large enterprise that uses GitHub for source control and Azure Pipelines for CI/CD. The organization has hundreds of repositories, each with its own pipeline. Recently, the security team mandated that all pipelines must use a centralized set of tasks for secret scanning and compliance checks before any deployment. You need to design a solution that enforces these mandatory tasks across all pipelines without modifying each pipeline individually. The solution should allow pipeline authors to add their own custom steps after the mandatory steps. The mandatory steps must be versioned and updated centrally. You also need to ensure that the mandatory steps are not bypassed by pipeline authors. What should you do?

Accepted Answer

Create a custom Azure DevOps extension that adds the mandatory tasks to all pipelines using a pre-job hook.. D is correct. A custom Azure DevOps extension with a pre-job hook (pipeline decorator) automatically injects mandatory steps into every pipeline without requiring changes to individual pipelines. It is centrally managed and versioned, and cannot be bypassed by pipeline authors. A is incorrect because it requires adding a template reference to each pipeline and the template inclusion is optional; branch protection only prevents tampering with the template, not its omission. B is invalid because Azure DevOps has no global task list injection. C is invalid because a single pipeline cannot run across all repositories with custom steps.

Answer

Store the mandatory tasks as a YAML template in a central repository. In each pipeline, use the 'template' reference to include the mandatory steps. Use branch protection rules on the central repository to require approval for changes to the template.

Answer

Use a global list of tasks in the Azure DevOps organization settings that automatically get injected into every pipeline.

Answer

Create a single pipeline that runs across all repositories and include the mandatory tasks in that pipeline.

Question 15

Your team uses Azure Pipelines to build a .NET application. You need to implement a secure build pipeline that meets the following requirements:
- Secrets must be injected at build time without being exposed in logs or YAML files.
- The build must use Microsoft-hosted agents.
- All builds must be auditable.
Which TWO actions should you take? (Choose two.)

Accepted Answer

Use a variable group linked to Azure Key Vault to store secrets, and reference the variable group in the pipeline.. To securely inject secrets without exposing them in logs or YAML, use a variable group linked to Azure Key Vault (B) to store secrets, and then use a token replacement task like Replace Tokens (D) to inject those secret variables into configuration files during the build. This avoids putting secrets in YAML, masks them in logs, and is auditable via Azure Key Vault and Azure DevOps audit logs. Option A, while the token is masked, is for Azure DevOps API access, not secret injection, and enabling it increases exposure risk.

Answer

Enable 'Allow scripts to access the OAuth token' on the agent job and use the token in scripts.

Answer

Store secrets as plain-text environment variables in the pipeline YAML file.

Answer

Deploy a self-hosted agent on-premises to keep secrets within the corporate network.