AZ-400 Configure processes and communications — Timed 40 Questions

Question 1

A team uses Azure Repos with a Git branching strategy that includes feature branches. They want to ensure that all feature branches are deleted automatically after the pull request is completed. What should they do?

40 minute time limit — choose an answer to begin.

Accepted Answer

Enable 'Automatically delete source branch' in the branch policy.. Azure Repos branch policies include an 'Automatically delete source branch' checkbox. When enabled, the source branch (e.g., a feature branch) is automatically deleted once the pull request is completed (merged or abandoned). This enforces cleanup without manual intervention, directly meeting the requirement.

Answer

Enable 'Create a merge commit' option in the branch policy.

Answer

Configure branch retention policy in the pipeline to delete branches after build.

Answer

Create a work item to remind developers to delete branches after merge.

Question 2

You are designing the communication strategy for a large team using Azure DevOps. The team uses a Kanban board and wants to automatically notify stakeholders when work items are moved to 'Done'. Which Azure DevOps feature should you use?

Accepted Answer

Use the built-in email subscription for work item changes.. Both A and D can be used to notify stakeholders when work items move to Done. Built-in email subscriptions (A) send email notifications to the configured recipients, while service hooks (D) can send webhook events to external systems for further processing. Without a requirement for external integration, both are equally valid. To make D the only correct answer, the question must clarify that stakeholders are external or that a third-party integration is needed.

Answer

Set up a pipeline notification for the work item.

Answer

Configure team alerts in the project settings.

Question 3

Your team uses Azure Boards and has several work item types (Epic, Feature, User Story, Bug, Issue). They want to enforce a rule that bugs can only be linked to Features, not directly to Epics. Which TWO actions should you perform?

Accepted Answer

Customize the Epic work item type to remove the 'Child' link to Bug.. Option A is correct because in Azure Boards you enforce link restrictions by customizing the work item type's link controls on the process: removing the 'Child' link from the Epic work item type prevents Epics from having Bugs as direct children, which is exactly the restriction the team wants. Option E is correct because removing the 'Parent' link from the Bug work item type stops a Bug from being linked directly to an Epic as its parent, closing the relationship from the Bug side as well. Together, these two link-control customizations on the inherited process block the Epic-to-Bug direct relationship while still allowing Bugs to link to Features. Option B is wrong because requiring a link to a Bug on Epic does not prevent Bugs from linking to Epics and adds an unrelated constraint. Option C is wrong because Azure Boards work item rules cannot dynamically set a parent type to Feature when a Bug is created. Option D is wrong because Azure Boards does not provide a rule that prohibits linking a work item type to another type; link restrictions are enforced through work item type link controls, not rules.

Answer

Configure the Epic work item type to require a link to a Bug.

Answer

Use a work item rule to set the parent type to Feature when a Bug is created.

Answer

Add a rule to the Bug work item type that prohibits linking to Epics.

Question 4

A team uses Azure Boards to manage work items. They want to automatically update the state of a work item when a related pull request is merged in Azure Repos. Which TWO actions should they configure to enable this integration?

Accepted Answer

Add a branch policy that requires a linked work item for pull requests.. A branch policy that requires linked work items for pull requests ensures that every PR is associated with a work item. When the PR is merged, Azure Repos automatically updates the state of the linked work item (e.g., from 'Active' to 'Resolved') based on the default or configured transition rules. This integration is built into Azure DevOps without requiring external services.

Answer

Set up a webhook in Azure Repos to call Azure Logic Apps on pull request merge.

Answer

Configure a Service Hooks subscription in Azure DevOps to send pull request merge events to Azure Boards.

Answer

Create an Azure Function that listens for pull request merge events and updates work items via the REST API.

Question 5

Your team uses Azure DevOps and wants to implement a change management process where all production releases must be approved by a change advisory board (CAB) after the build is complete but before deployment. The approval must be recorded in the pipeline. What is the best approach?

Accepted Answer

Create a release pipeline with a pre-deployment approval gate for the production stage.. A release pipeline with a pre-deployment approval gate for the production stage enforces that a designated approver (or group, such as the CAB) must approve the release before deployment begins. The approval is recorded in the pipeline's audit trail, satisfying the requirement for documented change management. This approach aligns with Azure DevOps release management best practices for gating production deployments.

Answer

Configure a branch policy requiring CAB member approval on pull requests.

Answer

Add a manual intervention task in the YAML pipeline.

Answer

Set up a service hook to send an email to the CAB and wait for a reply.

Question 6

Your Azure DevOps environment uses Microsoft Entra ID for authentication. You need to ensure that users from a partner organization can access only a specific Azure Boards project without being added to your tenant as guests. What should you do?

Accepted Answer

Invite the partner users as Microsoft Entra B2B guests and assign them to the project.. Microsoft Entra B2B collaboration allows you to invite external users as guests, granting them access to specific resources like an Azure Boards project without creating full member accounts in your directory. While they are added to the tenant as guest accounts, they have restricted permissions and are not full members. This meets the requirement of restricting access to only that project when the intent is to avoid full membership.

Answer

Issue OAuth 2.0 tokens to the partner users.

Answer

Configure Microsoft Entra ID identity protection to allow the partner IP range.

Answer

Create service principals for the partner users.

Question 7

Your team uses Azure Repos and wants to enforce that every commit message includes a work item ID. Which policy should you configure?

Accepted Answer

Branch policy to require linked work items.. Azure Repos' 'Require linked work items' branch policy only requires a linked work item on the pull request, not a work item ID in each commit message. Branch policies do not inspect commit message text. A pre-push Git hook is client-side and can be bypassed, so it is not a reliable policy. Therefore, none of the listed options meets the stated requirement.

Answer

Repository settings to restrict file paths.

Answer

Branch policy to require a minimum comment length.

Answer

Pre-push Git hook.

Question 8

Refer to the exhibit. You are migrating repository policies from Azure Repos to GitHub. The JSON shows a branch protection rule you plan to apply to the main branch. A developer pushes a hotfix directly to main without a pull request. What happens?

Accepted Answer

The push succeeds because no push restriction is defined.. The branch protection rule shown does not include a push restriction (such as 'Restrict who can push to matching branches'), so a developer with write access can push directly to main. Required status checks and enforceAdmins only apply to merges/pushes that go through the protected path; without an explicit push restriction, the direct push succeeds.

Answer

The push is blocked because required status checks are not met.

Answer

The push is blocked because enforceAdmins is true.

Answer

The push is rejected because lockBranch is false.

Question 9

Your organization uses GitHub Enterprise and wants to enforce that all repositories have a specific issue template. What is the most scalable way to achieve this?

Accepted Answer

Create a global issue template in the organization settings.. GitHub Enterprise allows organization owners to create a global issue template by placing a `.github/ISSUE_TEMPLATE/` directory in the `.github` repository. This template is automatically applied to all repositories within the organization, ensuring consistency without manual intervention per repo. This is the most scalable approach as it centralizes enforcement at the organization level.

Answer

Use a script to periodically check and add templates.

Answer

Create a repository template and require all new repos to use it.

Answer

Configure a CODEOWNERS file in each repository.

Question 10

Your team uses GitHub Issues for work tracking. You want to automate the creation of a new issue when a build pipeline fails in Azure Pipelines. Which action should you implement in the YAML pipeline?

Accepted Answer

Use a PowerShell task to call the GitHub Issues API.. Azure Pipelines does not natively support creating GitHub Issues directly from a YAML pipeline. Instead, you must use a PowerShell task (or a script task) to call the GitHub Issues API (POST /repos/{owner}/{repo}/issues) with an authentication token to create the issue when the build fails. This approach gives you full control over the issue content and is the standard way to integrate with GitHub Issues from Azure Pipelines.

Answer

Add a GitHub Action that triggers on pipeline completion.

Answer

Configure a Service Hook in Azure DevOps to GitHub Issues.

Answer

Add a task to create a work item in Azure Boards.

Question 11

Your organization uses Microsoft Teams for communication. You want to send a notification to a Teams channel when a release pipeline fails. Which action should you configure?

Accepted Answer

Add the 'Microsoft Teams Notification' task to the pipeline.. The 'Microsoft Teams Notification' task is a built-in Azure DevOps pipeline task that directly sends customizable notifications to a specified Teams channel when a pipeline event (such as failure) occurs. It requires no external configuration or additional services, making it the simplest and most appropriate choice for sending failure notifications from a release pipeline to Teams.

Answer

Configure an email notification to the team.

Answer

Use Azure Monitor alerts to send to Teams.

Answer

Add a Service Hook endpoint for Teams.

Question 12

Your team wants to include a manual validation step before deploying to production. Which Azure Pipelines feature should they use?

Accepted Answer

Pre-deployment conditions with approval gates.. Pre-deployment conditions with approval gates allow you to require manual approval before a release is deployed to a specific stage, such as production. This is the correct feature because it explicitly pauses the pipeline before deployment and waits for designated approvers to validate the build, meeting the requirement for a manual validation step. Environment checks are a broader feature that can include both automated checks and manual approvals; however, the specific configuration for requiring manual approval in a release pipeline is pre-deployment conditions with approval gates.

Answer

Pipeline decorators.

Answer

Environment checks.

Answer

Post-deployment gates.

Question 13

Your organization is adopting Microsoft Entra ID for identity management. You need to configure Azure DevOps to trust tokens issued by Entra ID for service connections. Which authentication method should you use?

Accepted Answer

Managed identity. Managed identity (Option B) is correct because it allows Azure DevOps to authenticate to Microsoft Entra ID without storing any credentials, using an identity automatically managed by Azure. This is the recommended approach for service connections when the Azure DevOps agent runs on an Azure resource (e.g., a VM or App Service) that supports managed identities, as it eliminates the need for secret rotation and reduces security risk.

Answer

Service principal with client secret

Answer

OAuth 2.0 authorization code grant

Answer

Personal access token (PAT)

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

You execute the above Azure CLI command. A pipeline YAML references the variable group 'Config' and uses the variable 'env'. However, the pipeline fails because the variable 'env' is not found. What is the most likely reason?

Accepted Answer

The variable group 'Config' is not linked to the pipeline.. In Azure Pipelines, variable names are case-insensitive. A casing mismatch between the variable group and the YAML reference would not cause the variable to be 'not found'. The most likely reason is that the variable group 'Config' is not linked or the pipeline is not authorized to use it, so its variables (including 'env') are not available in the pipeline.

Answer

The variable 'env' is a secret variable and cannot be used in YAML.

Answer

The variable name is case-sensitive; the YAML uses 'Env' instead of 'env'.

Answer

The variable group is scoped to a specific branch, and the pipeline is running on a different branch.

Question 16

Your team uses Azure Boards to track work items. They want to automatically update the 'Remaining Work' field on a task when a developer completes a pull request linked to that task. Which Azure DevOps feature should you configure?

Accepted Answer

Configure a branch policy to automatically update work items on PR completion.. Azure DevOps branch policies include a setting to automatically update work items linked to a pull request upon completion. Specifically, under branch policy settings, you can enable 'Automatically update work items' which, when a PR is completed, sets the 'Remaining Work' field to zero (or another configured value) for linked tasks. This directly meets the requirement without custom scripting or external services.

Answer

Define a pipeline variable to update the field during build.

Answer

Use a service hook to trigger an Azure Function that updates the work item.

Answer

Create a work item template that sets remaining work.

Question 17

Which TWO Azure DevOps features can be used to automate the process of updating work items when a build or release completes?

Accepted Answer

Pipeline task 'Update work item' from the Azure DevOps extension.. Option A is correct because the 'Update work item' pipeline task, provided by the Azure DevOps extension, can be added directly into a build or release pipeline and configured to modify work item fields (such as State, Integrated in Build, or custom fields) automatically when the pipeline runs to completion. Option B is correct because service hooks in Azure DevOps can subscribe to build/release completion events and invoke an Azure Function, which can then call the Work Item Tracking REST API to update the relevant work items programmatically. Option C is incorrect because release gates are pre/post-deployment conditions that evaluate health signals (like REST API, Azure Monitor, or work item queries) to allow or block a deployment, not actions that update work items. Option D is incorrect because work item query charts are read-only visualizations of query results and cannot trigger or perform updates. Option E is incorrect because branch policies with required reviewers enforce pull request approval requirements and do not update work items when a build or release completes.

Answer

Release gates with work item update actions.

Answer

Work item query charts.

Answer

Branch policy with required reviewers.

Question 18

Your team uses a monorepo in Azure Repos. You want to enforce that every PR to the main branch includes a work item link and a specific label. Which branch policy should you configure?

Accepted Answer

Build validation. Azure Repos branch policy 'Build validation' lets you require a custom build pipeline to succeed before a pull request can complete. This pipeline can run a script that uses the Azure DevOps REST API to verify the PR has a linked work item and a specific label, and fail the build if those conditions are not met. 'Check for linked work items' only enforces work item links but not labels. 'Comment requirements' is unrelated. 'Required status check' is not a native Azure Repos policy; 'Status check' policies are for requiring external statuses and do not directly invoke a build pipeline.

Answer

Comment requirements

Answer

Check for linked work items

Answer

Required status check (using a custom build pipeline)

Question 19

Your team uses a Git flow branching strategy with develop and release branches. You want to enforce that only release branches can be merged into main, and all merges into main require a successful deployment to a production-like environment. How should you implement this in Azure Pipelines?

Accepted Answer

YAML pipeline with environment approvals and branch filters on trigger. To enforce that only release branches can merge into main and that merges require a successful deployment to a production-like environment, you need a YAML pipeline that uses an environment with approval/check gates and a branch filter on the trigger. The environment's checks (approvals, business hours, etc.) run before deployment, and the branch filter ensures the pipeline only triggers for release branches. This combination enforces both the branch restriction and the deployment gate.

Answer

Branch policy with required reviewers for main

Answer

Required status check for 'Check for linked work items'

Answer

Build validation policy on main

Question 20

Which TWO approaches can you use to enforce consistent commit message conventions across your GitHub repositories?

Accepted Answer

Use a GitHub Action to validate commit messages on push. Option B is correct because a GitHub Action can run on the push event and execute a script or marketplace action that parses each commit message against a regex or Conventional Commits specification, failing the workflow when a message does not match and thereby enforcing the convention. Option D is correct because GitHub repository rulesets (repository rules) support a required commit message pattern using a regular expression, which blocks pushes containing non-conforming commit messages before they land on the protected branch. Option A is not correct because .gitattributes controls attributes such as line-ending normalization, diff drivers, and merge strategies, not commit message content. Option C is not correct because renaming or setting the default branch to main only affects branch naming and has no effect on commit message validation. Option E is not correct because an issue template standardizes the structure of new issues, not the format of commit messages.

Answer

Add a .gitattributes file

Answer

Set the default branch to main

Answer

Set up an issue template