AZ-400 Practice Test 27 — 15 Questions

Question 1

Your team uses GitHub Actions for CI/CD. You want to automatically deploy to Azure App Service whenever a pull request is merged to the main branch. Which event trigger should you use in the GitHub Actions workflow?

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

Accepted Answer

push: branches: [main]. In GitHub Actions, merging a pull request into `main` results in a `push` event to `main`. The `push` trigger with `branches: [main]` therefore correctly fires whenever a PR is merged. `pull_request: types: [closed]` fires on any PR closure, whether merged or not, so it would deploy even when a PR is closed without merging. To use `pull_request` for merges, you would need an additional `if: github.event.pull_request.merged == true` check, but the question asks for the event trigger alone.

Answer

pull_request: branches: [main]

Answer

pull_request: types: [closed] branches: [main]

Answer

release: types: [published]

Question 2

Your team is migrating from on-premises TFS to Azure DevOps Services. You need to ensure that all existing work item history and attachments are preserved. Which migration approach should you use?

Accepted Answer

Use the Azure DevOps Migration Tools (open source). The Azure DevOps Migration Tools (an open-source project) are specifically designed to migrate work items, including history, attachments, and links, from on-premises TFS to Azure DevOps Services. These tools handle the complex data transformations required to preserve the full fidelity of work item data, which is not possible with simpler export/import methods.

Answer

Export to Excel and import using Azure DevOps Office Integration

Answer

Manually recreate work items in Azure DevOps

Answer

Use the Azure DevOps REST API to migrate work items

Question 3

Your team uses Azure Boards and wants to automate work item state transitions when code is merged. What should you use?

Accepted Answer

GitHub + Azure Boards integration with automatic work item linking. GitHub + Azure Boards integration, when configured with automatic work item linking, automatically transitions work items (e.g., from 'Active' to 'Resolved') when a pull request is merged. This is achieved through the integration's ability to detect commit messages or PR descriptions containing 'AB#{ID}' or 'Fixes AB#{ID}' patterns, which trigger state changes defined in the Azure Boards project configuration.

Answer

Azure Pipelines with 'Update work item' task

Answer

Branch policy in Azure Repos

Answer

Power Automate with Azure DevOps connector

Question 4

Refer to the exhibit. An engineer tries to add a custom script extension to a VMSS but gets a ResourceNotFound error. What is the most likely cause?

Accepted Answer

The VMSS does not exist in the specified resource group.

Answer

The script URL is inaccessible due to network restrictions.

Answer

The CustomScript extension is not supported on this VMSS SKU.

Answer

The VMSS is in a different region than the resource group.

Question 5

You are a DevOps engineer at a company that develops a cloud-based SaaS application. The application consists of multiple microservices, each stored in its own Git repository within a single Azure DevOps project. The team has grown rapidly, and developers frequently need to make changes that span multiple services. They often complain about the overhead of managing multiple pull requests and coordinating merges across repositories. To improve efficiency, the team lead suggests consolidating all microservices into a single monorepo. However, the lead architect is concerned about the impact on build times, as the CI pipeline currently builds each service independently. You are tasked with designing a source control strategy that reduces cross-repository coordination overhead while maintaining fast, independent builds. You propose using a monorepo with a structure that allows selective building. Which approach should you recommend?

Accepted Answer

Create a single monorepo with a build pipeline that uses path filters to trigger builds only for changed services. Using a single monorepo with path filters in the build pipeline allows you to trigger builds only for the microservices that have changed, reducing cross-repository coordination overhead while maintaining fast, independent builds. Path filters in Azure Pipelines (e.g., `paths` in YAML) enable selective triggering based on file paths, so unchanged services are not rebuilt, preserving CI efficiency.

Answer

Keep separate repositories but create a meta-repo that references them as submodules

Answer

Keep separate repositories but use Git submodules to share code

Answer

Create a single monorepo with all services and a single build pipeline that builds everything

Question 6

Refer to the exhibit. The pipeline uses a variable group 'ReleaseVariables' that contains a variable named 'EnvironmentName' with value 'Staging'. What environment will the deployment target?

Accepted Answer

Production. The pipeline uses a variable group 'ReleaseVariables' with a variable 'EnvironmentName' set to 'Staging', but the deployment job's environment field is explicitly set to 'Production' (as shown in the exhibit). Variable groups are used for sharing values across pipelines, but they do not override the environment specified directly in the YAML job definition. Therefore, the deployment target is 'Production'.

Answer

Staging

Answer

VirtualMachine

Answer

DeployWeb

Question 7

Your build pipeline uses a YAML template that references variables from a variable group. The variable group is linked to a library. You need to ensure that sensitive variables are not exposed in logs. Which THREE actions should you take?

Accepted Answer

Store the secrets in Azure Key Vault and reference them in the variable group.. To keep sensitive variables out of pipeline logs, you should store secrets in Azure Key Vault and reference them in a variable group (B), mark variables as secret in the variable group (D), and configure permissions on the library to restrict which pipelines can use the variable group (E). Key Vault integration and secret marking ensure that values are masked automatically, while restricting access limits the risk of unauthorized pipelines that could expose secrets.

Answer

Set the variable group to 'Allow access to all pipelines'.

Answer

Use 'Write-Host' to output the variable values for debugging.

Question 8

Your Azure DevOps pipeline uses a self-hosted agent pool. You notice that builds are queuing for a long time. What is the most effective way to reduce queue times without incurring additional costs?

Accepted Answer

Allocate more parallel jobs to the agent pool.. Allocating more parallel jobs to the self-hosted agent pool allows multiple pipelines or jobs to run concurrently, directly reducing queue times. This is achieved by adjusting the parallelism setting in the agent pool's properties, which does not incur additional costs as you are already paying for the self-hosted infrastructure.

Answer

Reduce the number of steps in the pipeline.

Answer

Increase the agent specification (e.g., from DS2 to DS4).

Answer

Switch to Microsoft-hosted agents to get more parallelism.

Question 9

Which THREE of the following are valid steps to implement a trunk-based development workflow in Azure Repos? (Select THREE.)

Accepted Answer

Run CI builds on the main branch.. Trunk-based development requires developers to integrate into the main branch frequently. In Azure Repos, you set a CI trigger on main so every commit is built and validated (A). Developers use short-lived feature branches that are merged into main within a day (D) to keep integration conflicts small. Feature flags and pair programming are supporting practices that allow work to be integrated even before a feature is complete, avoiding long-running branches (B). Merging to main only once per week (C) contradicts the continuous-integration principle, and creating a release branch for every production release (E) is characteristic of GitFlow/release-flow, not trunk-based development.

Answer

Merge to main only once per week.

Answer

Create release branches for each production release.

Question 10

Your team uses GitHub Flow. A developer pushes a feature branch to origin and creates a pull request to main. After review and approval, the pull request is merged. Which branch should the developer delete after the merge to maintain a clean repository?

Accepted Answer

Delete the feature branch. In GitHub Flow, feature branches are temporary and should be deleted after their pull request is merged into main. Deleting the feature branch keeps the repository clean by removing stale branches that are no longer needed, reducing clutter and preventing confusion. This practice aligns with the principle of short-lived branches in trunk-based development workflows.

Answer

Keep both branches indefinitely

Answer

Delete the main branch

Answer

Delete the remote main branch and recreate it

Question 11

Your Azure DevOps pipeline uses a variable group to store secrets. The variable group is linked to a Key Vault. You need to use a secret variable in a pipeline task. How should you reference the secret in the YAML pipeline?

Accepted Answer

Reference the variable as $(VariableName) in the pipeline tasks.. When a variable group is linked to an Azure Key Vault, secret variables are automatically available in the pipeline. You can reference them directly using the standard $(VariableName) syntax in any pipeline task. No special task or script is required. Option A is incorrect because you do not need to restrict to script tasks or use 'env' mapping; the $(VariableName) works everywhere. Option B is incorrect because 'task.getVariable' is a scripting method used within tasks, not a YAML syntax. Option D is incorrect because the Azure Key Vault task is unnecessary; the variable group handles the retrieval automatically.

Answer

Reference the variable as $(VariableName) but only in a script task using 'env' mapping.

Answer

Use the 'task.getVariable' method in a PowerShell script.

Answer

Use the Azure Key Vault task to retrieve the secret and then reference the output variable.

Question 12

Your team uses GitHub Issues for tracking bugs and features. They want to automatically assign issues to the person who created the pull request that closes the issue. Which GitHub Actions workflow trigger and action should you use?

Accepted Answer

Use the 'issues' event with 'closed' type and an action that assigns the issue to the PR author.. The 'issues' event with 'closed' type triggers a workflow when an issue is closed, and the 'actions/github-script' action can be used to assign the issue to the pull request author by querying the pull request that closed the issue. Option A is incorrect because the 'pull_request' event does not directly close issues; closing an issue is done via a commit or pull request merge. Option C is incorrect because the 'push' event is not related to issue closure. Option D is incorrect because the 'schedule' event is time-based and does not respond to issue closures.

Answer

Use the 'pull_request' event and the 'actions/assign' action to assign the issue.

Answer

Use the 'push' event and call the GitHub API to assign the issue.

Answer

Use the 'schedule' event to periodically check for closed issues and assign them.

Question 13

A team uses Azure Boards and wants to ensure that work items moved to the 'Done' state require a completed code review. What should they configure?

Accepted Answer

Add a work item rule in the process template to require a code review for the 'Done' transition.. Azure Boards allows you to define work item rules within the process template that enforce specific conditions on state transitions. By adding a rule to the 'Done' transition that requires a completed code review (e.g., via a custom field or check), you ensure work items cannot be moved to 'Done' without meeting that prerequisite. This is done through the inherited process customization in Azure DevOps, where you can add rules to the work item type's state transition.

Answer

Modify the work item type definition to add a custom field for code review status.

Answer

Use a tag to mark work items as code-reviewed before moving to 'Done'.

Answer

Configure branch policies in Azure Repos to require pull request approvals.

Question 14

A developer pushes a commit to a branch named 'releases/v1.0'. What will happen?

Accepted Answer

The pipeline runs automatically on the push.. Azure Pipelines, by default, triggers a pipeline run automatically on any push to any branch unless a trigger filter is explicitly configured. The branch name 'releases/v1.0' is valid and does not contain any characters that would prevent a trigger; dots are allowed in branch names. The pipeline will execute the steps defined in the YAML file for that branch.

Answer

The pipeline runs but fails because the branch name contains a dot.

Answer

The pipeline runs only if a pull request is created.

Answer

The pipeline does not run because the branch is not main.

Question 15

Your organization uses Azure DevOps and has a project with multiple teams. The 'AlphaTeam' wants a branch policy on their feature branch 'feature/alpha' that requires a successful build from the CI pipeline and approval from at least one member of 'AlphaTeam'. However, the 'BetaTeam' should be able to push directly to 'feature/alpha' without a pull request. You need to configure the branch policy accordingly. What should you do?

Accepted Answer

Configure the branch policy on 'feature/alpha' to require build and approval from AlphaTeam, and set 'Allow direct pushes' to 'Selected users' and add BetaTeam.. Azure DevOps branch policies allow you to configure 'Allow direct pushes' to specific users or groups while still enforcing PR requirements for others. By setting the policy on 'feature/alpha' to require a successful build and approval from at least one AlphaTeam member, and then selecting 'Selected users' for direct pushes with BetaTeam added, BetaTeam can push directly without a PR, while AlphaTeam must follow the PR policy.

Answer

Create a new repository for AlphaTeam and apply the policy there.

Answer

Set a branch policy at the repository level that applies to all branches, then grant BetaTeam bypass permission.

Answer

Configure the branch policy on 'feature/alpha' to require build and approval, and set 'Allow direct pushes' to 'Everyone'.