AZ-400 Practice Test 47 — 15 Questions

Question 1

Refer to the exhibit. Your organization has configured an Azure DevOps pipeline security setting that enforces a required template for all pipelines deploying to production and staging. The required template 'security-validation.yml' runs a series of security scans and compliance checks. A developer creates a new pipeline that deploys to a test environment, but the pipeline does not reference the required template. What will happen?

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

Accepted Answer

The pipeline will fail because it does not reference the required template.. The Azure DevOps 'Required template' security setting is configured at the project or organization level and applies to all YAML pipelines, regardless of the deployment target environment. There is no native option to enforce it only for specific environments like production or staging. Therefore, a new pipeline deploying to test without referencing the required template would also fail.

Answer

The pipeline will run normally because the required template enforcement only applies to production and staging environments.

Answer

The pipeline will run but the security scans will be automatically injected.

Answer

The pipeline will prompt the developer to add the required template before running.

Question 2

Your team is designing a build pipeline for a Java application that uses Maven. The pipeline must run unit tests and integration tests separately, and fail the build if integration tests fail. However, integration tests require a running database container. Which approach should you use to ensure the database is available for the integration tests?

Accepted Answer

Use a Docker Compose task in the pipeline to start the database container before running integration tests.. Docker Compose allows you to define and start a database container as a dependency before running integration tests in a build pipeline. By using a Docker Compose task, you can ensure the database container is running in a clean, isolated environment, and the pipeline can fail the build if the integration tests fail. This approach is ideal for CI/CD pipelines where ephemeral, disposable infrastructure is needed for testing.

Answer

Configure the pipeline to use a self-hosted agent that has the database already installed and running.

Answer

Install the database as a service in the pipeline using the Service Fabric task.

Answer

Use a PowerShell script in the pipeline to install and start the database on the build agent.

Question 3

You have an Azure DevOps Pipeline that builds a Node.js application. The pipeline uses template expressions to conditionally run certain jobs based on the branch name. You notice that the condition 'eq(variables['Build.SourceBranch'], 'refs/heads/main')' is not evaluating as expected. What is the most likely cause?

Accepted Answer

The variable 'Build.SourceBranch' is not available in the condition context.. The condition 'eq(variables['Build.SourceBranch'], 'refs/heads/main')' is used in a template expression, which is evaluated at compile time. However, 'Build.SourceBranch' is a runtime variable that is not available during compile time, causing the condition to fail. Template expressions can only reference parameters or variables defined within the template itself, not runtime pipeline variables. To conditionally run jobs based on the branch, use a runtime condition (e.g., in the 'condition' property of a job or stage) instead of a template expression.

Answer

The variable 'Build.SourceBranch' is misspelled; it should be 'Build.SourceBranchName'.

Answer

The condition syntax is correct but the branch name should not include 'refs/heads/'.

Answer

The condition should be in a template expression instead of a runtime condition.

Question 4

Your team uses Azure Repos with a Git branching strategy. You need to ensure that all changes to the release branch are reviewed by at least two approvers and that builds succeed before merging. Which TWO branch policy settings should you enable?

Accepted Answer

Build validation. Build validation (A) ensures that a pull request cannot be merged unless the source branch compiles successfully and passes all configured automated tests, which directly enforces the requirement that builds succeed before merging. Minimum number of reviewers (C) set to 2 enforces the policy that at least two distinct approvers must approve the pull request before it can be completed. Together, these two settings satisfy both conditions: successful builds and two-reviewer approval.

Answer

Work item linking

Answer

Require a clean fast-forward merge

Answer

Require a merge commit

Question 5

You need to trigger a pipeline whenever changes are pushed to the 'main' branch of a GitHub repository. Which trigger should you configure in the YAML pipeline?

Accepted Answer

trigger:
  branches:
    include:
    - main. The `trigger` keyword at the root of a YAML pipeline defines the CI trigger that automatically starts a pipeline run when changes are pushed to the specified branch. By including `main` under `branches.include`, the pipeline will trigger on any push to the `main` branch of the GitHub repository, which is the standard way to set up a CI trigger for a single branch.

Answer

pr:
  branches:
    include:
    - main

Answer

resources:
  repositories:
  - repository: self
    trigger:
      branches:
        include:
        - main

Answer

schedules:
- cron: "0 0 * * *"
  branches:
    include:
    - main

Question 6

Your release pipeline uses deployment groups to deploy to on-premises servers. You want to ensure that only one deployment runs at a time on each server. Which option should you configure?

Accepted Answer

Set the deployment queue to 'Deploy one at a time' with 'Exclusive lock'.. Setting the deployment queue to 'Deploy one at a time' with 'Exclusive lock' ensures that only one deployment runs at a time on each server in the deployment group. This lock prevents concurrent deployments to the same target, which is essential for on-premises servers that cannot handle parallel updates without conflicts.

Answer

Configure a pre-deployment condition that checks the current deployment status.

Answer

Add a manual approval step before each deployment.

Answer

Set the deployment queue to 'Deploy all in parallel' with 'Number of parallel deployments' set to 1.

Question 7

Which TWO branch policies can be configured in Azure Repos to enforce code quality?

Accepted Answer

Status check. Status check (A) is correct because Azure Repos allows you to require that a status check passes before a pull request can be completed. This enforces code quality by integrating with external or built-in services (e.g., Azure Pipelines, SonarQube) that run automated tests, linting, or security scans. Build validation (C) is correct because it triggers a build pipeline automatically when a pull request is created, ensuring the code compiles and passes defined quality gates before merging.

Answer

Comment requirements

Answer

Work item linking

Answer

Merge strategy

Question 8

Your organization uses Azure DevOps and Microsoft Entra ID. The compliance team needs to ensure that access to Azure DevOps projects is governed by conditional access policies. Which Azure DevOps integration should you use?

Accepted Answer

Link the Azure DevOps organization to the Microsoft Entra ID tenant and configure conditional access policies in Microsoft Entra ID.. To govern access to Azure DevOps projects with conditional access policies, you must link the Azure DevOps organization to the Microsoft Entra ID tenant. This integration makes Azure DevOps a registered application within the tenant, allowing conditional access policies (e.g., MFA, device compliance, location-based access) to be evaluated during authentication. Only then can the compliance team enforce organization-wide access rules via Microsoft Entra ID.

Answer

Configure service hooks to enforce conditional access.

Answer

Assign managed identities to users for conditional access.

Answer

Use OAuth tokens to authenticate users.

Question 9

Your organization needs to enforce that every commit to the main branch in Azure Repos is associated with a work item from Azure Boards. What should you configure?

Accepted Answer

Configure a pull request policy that requires a linked work item, and enforce that all merges to main are via pull request.. In Azure Repos, the 'Require a linked work item' branch policy applies only to pull requests, not to direct pushes. To enforce that every commit to main is associated with a work item, you must require that all changes come through pull requests (via a branch policy requiring PRs) and then enable the 'Require a linked work item' policy on pull requests. This ensures that every commit merged into main via a PR has a linked work item. Option A is incorrect because the 'Require a linked work item' branch policy does not apply to direct pushes; it only applies to pull request completions.

Answer

Add a branch policy on main that requires a linked work item for all pushes.

Answer

Create a pre-receive hook in the repository to reject commits without a work item.

Answer

Enable the 'Gated check-in' option in the branch policy for main.

Question 10

Your team uses Azure Pipelines for CI/CD. A release pipeline fails intermittently during deployment to an Azure App Service slot. The error message indicates 'Failed to fetch access token for Azure Resource Manager service endpoint.' The service principal used has been granted Contributor role on the resource group. The issue resolves after re-creating the service connection in Azure DevOps. What is the most likely cause?

Accepted Answer

The service principal client secret has expired.. Service principal credentials (client secret) can expire, causing intermittent token fetch failures. Re-creating the service connection generates a new secret, temporarily resolving the issue until it expires again. Option B is wrong because the service connection is bound to the service principal, not the user who created it; removing the user does not affect the existing connection. Option C is wrong because network restrictions would cause consistent failure, not intermittent. Option D is wrong because the service principal already has the Contributor role on the resource group.

Answer

The user who created the service connection has been removed from Azure DevOps.

Answer

The Azure DevOps organization is behind a firewall that blocks outbound requests to Azure Resource Manager.

Answer

The service principal lacks the required role on the target resource group.

Question 11

Which TWO are valid types of triggers for a YAML pipeline in Azure Pipelines? (Choose two.)

Accepted Answer

Push trigger. A is correct because a push trigger in a YAML pipeline automatically starts a pipeline run when a push is made to a specified branch or tag. B is correct because scheduled triggers are also valid in YAML pipelines, allowing you to run a pipeline on a schedule defined using cron syntax. D (PR trigger) is also a valid YAML trigger, but the question asks for exactly two valid types; the intended correct pair is push and scheduled triggers. Options C and E are not standard YAML trigger types in Azure Pipelines; release triggers are used in classic releases, and pipeline triggers are for triggering a pipeline from another pipeline, which is not a direct trigger type defined in the YAML file.

Answer

Release trigger

Answer

PR trigger

Answer

Pipeline trigger

Question 12

Which THREE components are required to implement a self-hosted agent pool in Azure Pipelines?

Accepted Answer

The Azure Pipelines agent software installed on the machine.. The Azure Pipelines agent software is the core component that executes pipeline jobs on the self-hosted machine. Without installing the agent software (via the agent configuration script), the machine cannot register with Azure Pipelines or run any tasks, making it a mandatory requirement for a self-hosted agent pool.

Answer

An Azure Resource Manager service connection.

Answer

A YAML pipeline definition.

Question 13

Your team uses GitHub Actions for CI/CD and needs to ensure that secrets such as Azure service principal credentials are not exposed in logs. What is the best practice to prevent secret exposure?

Accepted Answer

Store secrets as GitHub Actions secrets and reference them in workflows. GitHub Actions secrets are encrypted environment variables that are automatically masked in workflow logs when referenced. By storing Azure service principal credentials as GitHub Actions secrets and using the `${{ secrets.SECRET_NAME }}` syntax in workflows, the actual secret values are never written to logs, preventing exposure. This is the recommended approach for handling sensitive data in GitHub Actions CI/CD pipelines.

Answer

Store secrets in the workflow YAML file

Answer

Use environment protection rules to mask secrets

Answer

Encrypt workflow logs after the run completes

Question 14

You applied the above branch policy to a GitHub repository. A developer tries to push a commit to the main branch that is signed with an S/MIME signature. What will happen?

Accepted Answer

The commit is rejected because S/MIME is not in the allowed signature types.. The branch policy in question is configured to allow only GPG or SSH signatures. S/MIME is not listed as an allowed signature type, so the commit is rejected. GitHub's branch protection rules enforce signature requirements based on the allowed signature types specified in the policy.

Answer

The commit is accepted because S/MIME is implicitly allowed.

Answer

The commit is accepted because it is signed.

Answer

The commit is rejected because the policy is in 'block' mode, which blocks all pushes.

Question 15

Your team uses GitHub Actions for CI/CD. You need to ensure that only specific branches can trigger the deployment workflow to production. Which workflow trigger should you configure?

Accepted Answer

on: push: branches: [main]. The `on: push: branches: [main]` trigger ensures that the deployment workflow runs only when a push event occurs on the `main` branch. This directly enforces the requirement that only specific branches (here, `main`) can trigger production deployments, preventing accidental or unauthorized deployments from other branches.

Answer

on: pull_request: branches: [main]

Answer

on: workflow_dispatch: inputs: branch: description: 'Select branch'

Answer

on: schedule: cron: '0 0 * * *'