How should I use these Configure processes and communications practice questions?

Read each scenario carefully and choose your answer before revealing the explanation. Then check why your choice was right or wrong. Repeat until the reasoning feels automatic.

AZ-400 · topic practice

Configure processes and communications practice questions

Q: Can I practise just Configure processes and communications questions in a focused session?

Yes — use the session launcher on this page to start a 10-, 20-, 30- or 50-question session drawn entirely from the Configure processes and communications domain.

Practise Microsoft Azure DevOps Engineer Expert AZ-400 Configure processes and communications practice questions — original exam-style scenarios with answer choices, explanations, and analysis of common mistakes.

Courseiva uses original exam-style practice questions designed for learning and revision. The goal is to understand the concepts, recognise exam patterns, and improve through explanations — not memorise copied exam dumps.

Reviewed byJohnson Ajibi· MSc IT Security

20 questionsDomain: Configure processes and communications

Practice 10 questions Browse domain →

What the exam tests

What to know about Configure processes and communications

Configure processes and communications questions test whether you can apply the concept in context, not just recognise a definition.

How the topic appears in realistic exam-style scenarios.

Which detail in the question changes the correct answer.

How to eliminate plausible but wrong options.

How to connect the question back to the wider exam objective.

Watch out for

Common Configure processes and communications exam traps

▸Answering from memory before reading the full scenario.
▸Missing a constraint such as cost, availability, security, scope or command context.
▸Choosing a broad answer when the question asks for the most specific fix.
▸Ignoring why the wrong options are tempting.

Practice set

Configure processes and communications questions

20 questions · select your answer, then reveal the explanation

Question 1easymultiple choice

Read the full Configure processes and communications explanation →

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?

Trap 1: Modify the work item type definition to add a custom field for code…

Adding a field does not enforce the transition condition.

Trap 2: Use a tag to mark work items as code-reviewed before moving to…

Tags are not enforceable rules.

Trap 3: Configure branch policies in Azure Repos to require pull request…

Branch policies apply to code, not work item states.

Study all Configure processes and communications common traps →

A
Add a work item rule in the process template to require a code review for the 'Done' transition.
Work item rules enforce conditions on state transitions.
B
Modify the work item type definition to add a custom field for code review status.
Why wrong: Adding a field does not enforce the transition condition.
C
Use a tag to mark work items as code-reviewed before moving to 'Done'.
Why wrong: Tags are not enforceable rules.
D
Configure branch policies in Azure Repos to require pull request approvals.
Why wrong: Branch policies apply to code, not work item states.

Full breakdown with real-world context →

Question 2mediummultiple choice

Read the full Configure processes and communications explanation →

During a sprint review, stakeholders complain that they don't receive notifications about completed work items. The team uses Azure Boards with a custom notification subscription. What is the most likely cause?

Trap 1: Email notifications are disabled at the organization level.

If disabled, no one would receive notifications.

Trap 2: The subscription is set to deliver only to the team members.

Team members get notifications, so the subscription works.

Trap 3: The subscription was automatically disabled after the first…

Subscriptions remain active until manually disabled.

Study all Configure processes and communications common traps →

A
Email notifications are disabled at the organization level.
Why wrong: If disabled, no one would receive notifications.
B
The subscription is set to deliver only to the team members.
Why wrong: Team members get notifications, so the subscription works.
C
The subscription's 'Deliver to' filter excludes stakeholders.
The filter must include stakeholders for them to receive notifications.
D
The subscription was automatically disabled after the first notification.
Why wrong: Subscriptions remain active until manually disabled.

Full breakdown with real-world context →

Question 3hardmultiple choice

Read the full NAT/PAT explanation →

A multinational company uses Azure DevOps with a single project. The project has multiple teams in different time zones. They want to customize the process to reflect different working days for each team. What is the recommended approach?

Trap 1: Create a custom process for each time zone and assign teams…

A project uses one process; processes cannot be assigned per team.

Trap 2: Use the same process but create separate areas for each team, then…

Working days are configured per team, not per area path.

Trap 3: Use the same process and configure capacity planning for each team…

Capacity planning affects individual work, not team-level working days.

Study all Configure processes and communications common traps →

A
Create a custom process for each time zone and assign teams accordingly.
Why wrong: A project uses one process; processes cannot be assigned per team.
B
Use the same process but create separate areas for each team, then configure working days per area path.
Why wrong: Working days are configured per team, not per area path.
C
Use the same process and configure working days in the team settings for each team.
Team settings allow per-team working days.
D
Use the same process and configure capacity planning for each team to account for time off.
Why wrong: Capacity planning affects individual work, not team-level working days.

Full breakdown with real-world context →

Question 4mediummultiple choice

Read the full Configure processes and communications explanation →

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?

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

This option changes merge strategy, not branch deletion.

Trap 2: Configure branch retention policy in the pipeline to delete…

Retention policies delete old runs, not branches.

Trap 3: Create a work item to remind developers to delete branches after…

This is not automated enforcement.

Study all Configure processes and communications common traps →

A
Enable 'Automatically delete source branch' in the branch policy.
This deletes the source branch after the PR is completed.
B
Enable 'Create a merge commit' option in the branch policy.
Why wrong: This option changes merge strategy, not branch deletion.
C
Configure branch retention policy in the pipeline to delete branches after build.
Why wrong: Retention policies delete old runs, not branches.
D
Create a work item to remind developers to delete branches after merge.
Why wrong: This is not automated enforcement.

Full breakdown with real-world context →

Question 5hardmultiple choice

Read the full Configure processes and communications explanation →

An organization uses Azure DevOps and wants to implement a change management process where all changes to the main branch require approval from a change advisory board (CAB). The CAB members are not part of the development team. How should they configure this?

Trap 1: Set branch permissions to restrict push to main and only allow CAB…

Permissions alone don't enforce a required number of approvals.

Trap 2: Use a service hook to notify CAB when a PR is created, and rely on…

Service hooks don't enforce approvals.

Trap 3: Add the CAB as members of the development team and require team…

Adding CAB to team may not be appropriate; also team review includes developers.

Study all Configure processes and communications common traps →

A
Set branch permissions to restrict push to main and only allow CAB to approve via manual process.
Why wrong: Permissions alone don't enforce a required number of approvals.
B
Create a new branch policy on main that requires a minimum number of reviewers from a separate CAB group.
Branch policies can require specific reviewers or groups.
C
Use a service hook to notify CAB when a PR is created, and rely on manual approval.
Why wrong: Service hooks don't enforce approvals.
D
Add the CAB as members of the development team and require team review.
Why wrong: Adding CAB to team may not be appropriate; also team review includes developers.

Full breakdown with real-world context →

Question 6easymulti select

Read the full Configure processes and communications explanation →

Which TWO actions help improve communication and collaboration in a distributed Azure DevOps team?

Trap 1: Use multiple chat channels for each topic to organize discussions.

Too many channels can hinder communication.

Trap 2: Use long email threads for decision-making to ensure full…

Email threads are inefficient for collaboration.

Trap 3: Avoid using pull request comments to reduce noise.

PR comments are essential for code review collaboration.

Study all Configure processes and communications common traps →

A
Maintain a shared wiki with project documentation and decisions.
Centralized documentation aids transparency.
B
Use multiple chat channels for each topic to organize discussions.
Why wrong: Too many channels can hinder communication.
C
Use long email threads for decision-making to ensure full documentation.
Why wrong: Email threads are inefficient for collaboration.
D
Schedule daily stand-up meetings at a time that works for all time zones.
Daily sync helps alignment.
E
Avoid using pull request comments to reduce noise.
Why wrong: PR comments are essential for code review collaboration.

Full breakdown with real-world context →

Question 7mediummulti select

Read the full Configure processes and communications explanation →

Which THREE steps are essential when customizing an Azure DevOps process?

Trap 1: Use Hosted XML process model to customize.

Hosted XML is deprecated; use Inheritance.

Trap 2: Directly modify the 'Agile' system process.

System processes cannot be modified directly.

Study all Configure processes and communications common traps →

A
Use Hosted XML process model to customize.
Why wrong: Hosted XML is deprecated; use Inheritance.
B
Add custom fields to work item types.
Custom fields allow tracking additional data.
C
Directly modify the 'Agile' system process.
Why wrong: System processes cannot be modified directly.
D
Create an inherited process from an existing system process.
Customization requires an inherited process.
E
Add custom work item types to the process.
Custom work item types can be added.

Full breakdown with real-world context →

Question 8hardmultiple choice

Read the full Configure processes and communications explanation →

You are the Azure DevOps administrator for a large enterprise with multiple projects using the Scrum process. The organization has recently adopted a new compliance policy requiring that all work items of type 'Epic' must be approved by a compliance officer before they can be moved to the 'Committed' state. The compliance officers are external to the development teams and should not have direct access to modify work items. You need to implement this requirement with minimal administrative overhead. The current process has the following states for Epics: New, Proposed, Committed, In Progress, Done. The desired flow is: from 'Proposed' to 'Committed', a compliance officer must approve the transition. Compliance officers are part of a security group named 'Compliance Officers'. They should be able to approve the transition without having to edit the work item directly. What should you do?

Trap 1: Use a service hook to send an email to the compliance officers when…

Service hooks do not enforce the condition.

Trap 2: Modify the Epic work item type to add a field 'Compliance Approval'…

Reviewers are not enforced for state transitions.

Trap 3: Configure a branch policy on the main branch that requires approval…

Branch policies apply to code, not work items.

Study all Configure processes and communications common traps →

A
In the process template for Epic, add a work item rule on the transition from 'Proposed' to 'Committed' that requires approval from a member of the 'Compliance Officers' group.
Work item rules can require approval from a group.
B
Use a service hook to send an email to the compliance officers when an Epic is moved to 'Proposed', and rely on them to manually approve the transition.
Why wrong: Service hooks do not enforce the condition.
C
Modify the Epic work item type to add a field 'Compliance Approval' and set the compliance officer as a required reviewer in the field settings.
Why wrong: Reviewers are not enforced for state transitions.
D
Configure a branch policy on the main branch that requires approval from the 'Compliance Officers' group for pull requests.
Why wrong: Branch policies apply to code, not work items.

Full breakdown with real-world context →

Question 9mediummultiple choice

Read the full Configure processes and communications explanation →

A company recently migrated its CI/CD pipelines from Jenkins to Azure Pipelines. The development team is experiencing frequent build failures due to conflicting changes when multiple developers push code simultaneously. The team wants to maintain a linear history and avoid merge commits. Which strategy should you recommend?

Trap 1: Switch to Git with a central repository and require merge commits.

This generates merge commits and does not prevent conflicts.

Trap 2: Enforce a rebase strategy for all pull requests in the branch…

Rebase does not prevent concurrent pushes; conflicts must still be resolved.

Trap 3: Configure Azure Repos to use squash merge when completing pull…

Squash merge still allows concurrent pushes and conflicts.

Study all Configure processes and communications common traps →

A
Switch to Git with a central repository and require merge commits.
Why wrong: This generates merge commits and does not prevent conflicts.
B
Enforce a rebase strategy for all pull requests in the branch policy.
Why wrong: Rebase does not prevent concurrent pushes; conflicts must still be resolved.
C
Use Team Foundation Version Control (TFVC) with exclusive checkout enabled.
TFVC with exclusive checkout locks files, preventing concurrent edits and ensuring linear history.
D
Configure Azure Repos to use squash merge when completing pull requests.
Why wrong: Squash merge still allows concurrent pushes and conflicts.

Full breakdown with real-world context →

Question 10easymultiple choice

Read the full Configure processes and communications explanation →

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?

Trap 1: Use the built-in email subscription for work item changes.

Email subscriptions only send to users with access to the project.

Trap 2: Set up a pipeline notification for the work item.

Pipeline notifications are for CI/CD events.

Trap 3: Configure team alerts in the project settings.

Team alerts are for team members within Azure DevOps.

Study all Configure processes and communications common traps →

A
Use the built-in email subscription for work item changes.
Why wrong: Email subscriptions only send to users with access to the project.
B
Set up a pipeline notification for the work item.
Why wrong: Pipeline notifications are for CI/CD events.
C
Configure team alerts in the project settings.
Why wrong: Team alerts are for team members within Azure DevOps.
D
Create a service hook subscription to send events to a webhook.
Service hooks can send notifications to external systems like Slack or email gateways.

Full breakdown with real-world context →

Question 11hardmulti select

Read the full Configure processes and communications explanation →

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?

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

This does not prevent Bug-to-Epic links; it only requires a link.

Trap 2: Use a work item rule to set the parent type to Feature when a Bug…

This does not block linking to Epics; it only sets a default.

Trap 3: Add a rule to the Bug work item type that prohibits linking to…

Rules cannot restrict link types; they can only set or clear fields.

Study all Configure processes and communications common traps →

A
Customize the Epic work item type to remove the 'Child' link to Bug.
This prevents users from linking an Epic to a Bug as a child.
B
Configure the Epic work item type to require a link to a Bug.
Why wrong: This does not prevent Bug-to-Epic links; it only requires a link.
C
Use a work item rule to set the parent type to Feature when a Bug is created.
Why wrong: This does not block linking to Epics; it only sets a default.
D
Add a rule to the Bug work item type that prohibits linking to Epics.
Why wrong: Rules cannot restrict link types; they can only set or clear fields.
E
Customize the Bug work item type to remove the 'Parent' link to Epic.
This prevents users from linking a Bug to an Epic as a parent.

Full breakdown with real-world context →

Question 12hardmultiple choice

Read the full Configure processes and communications explanation →

You are the DevOps lead for a financial services company. The company uses Azure DevOps Services with a single project containing multiple teams. The compliance team requires that all production deployments be approved by a change advisory board (CAB) member. Additionally, any deployment that changes a configuration value stored in Azure App Configuration must be audited. You have set up a release pipeline with a manual approval gate and a pre-deployment condition that runs a PowerShell script to validate configuration changes. However, the compliance team reports that some deployments bypassed the approval gate. Upon investigation, you find that developers with 'Edit release pipeline' permissions can modify the pipeline and remove the approval gate. You need to ensure that the approval gate cannot be bypassed by developers. You also need to ensure that any change to a configuration key is logged to Azure Monitor. What should you do?

Trap 1: Create a new service connection with limited permissions and…

Service connections do not enforce approval gates.

Trap 2: Configure environment-level approvals in the release pipeline and…

Environment approvals can be removed if the pipeline is editable.

Trap 3: Implement a branch policy on the release pipeline's YAML file in…

Branch policies apply to code, not release pipeline definitions. Webhooks are not the best for logging.

Study all Configure processes and communications common traps →

A
Create a new service connection with limited permissions and require that all pipeline runs use it. Use an Azure Policy to audit configuration changes.
Why wrong: Service connections do not enforce approval gates.
B
Configure environment-level approvals in the release pipeline and use Azure Policy to enforce that all deployments go through the environment. Use diagnostic settings on App Configuration to stream logs to Azure Monitor.
Why wrong: Environment approvals can be removed if the pipeline is editable.
C
Implement a branch policy on the release pipeline's YAML file in the repository to require approval for changes. Use a webhook to send configuration change events to Azure Monitor.
Why wrong: Branch policies apply to code, not release pipeline definitions. Webhooks are not the best for logging.
D
Create a protected variable group that stores the approval gate configuration and set the pipeline to use it. Restrict edit permissions on the release pipeline to a security group that does not include developers. For configuration changes, use an Azure Resource Manager template with a deployment script that sends logs to Azure Monitor.
Protected variable groups and restricted permissions prevent bypassing approvals; ARM template with script logs changes.

Full breakdown with real-world context →

Question 13mediummultiple choice

Read the full Configure processes and communications explanation →

A development team is transitioning from a centralized version control system to Git in Azure Repos. The team lead wants to ensure that the branch structure supports both feature development and hotfix releases, with the ability to stabilize a release candidate before final deployment. Which branch strategy should the team implement?

Trap 1: Use trunk-based development with short-lived feature branches that…

Trunk-based does not have release branches for stabilization.

Trap 2: Use a forking workflow where each developer forks the repository…

Forking workflow is for external contributions, not internal release management.

Trap 3: Use GitHub Flow with feature branches and pull requests directly to…

GitHub Flow lacks release branches for stabilization.

Study all Configure processes and communications common traps →

A
Use trunk-based development with short-lived feature branches that merge directly to main.
Why wrong: Trunk-based does not have release branches for stabilization.
B
Use a forking workflow where each developer forks the repository and creates pull requests.
Why wrong: Forking workflow is for external contributions, not internal release management.
C
Use Git Flow with feature, develop, release, and main branches.
Git Flow provides release branches for stabilization before merging to main.
D
Use GitHub Flow with feature branches and pull requests directly to main.
Why wrong: GitHub Flow lacks release branches for stabilization.

Full breakdown with real-world context →

Question 14hardmulti select

Read the full Configure processes and communications explanation →

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?

Trap 1: Set up a webhook in Azure Repos to call Azure Logic Apps on pull…

Webhooks require custom logic, not a built-in integration.

Trap 2: Configure a Service Hooks subscription in Azure DevOps to send pull…

Service Hooks send events to external systems, not directly update work items.

Trap 3: Create an Azure Function that listens for pull request merge events…

This is a custom solution, not a built-in configuration.

Study all Configure processes and communications common traps →

A
Set up a webhook in Azure Repos to call Azure Logic Apps on pull request merge.
Why wrong: Webhooks require custom logic, not a built-in integration.
B
Add a branch policy that requires a linked work item for pull requests.
This ensures every PR has a work item, and on merge, the work item state can be updated.
C
In the pull request description, use the #mention syntax to reference the work item.
This links the PR to the work item, enabling automatic updates on merge.
D
Configure a Service Hooks subscription in Azure DevOps to send pull request merge events to Azure Boards.
Why wrong: Service Hooks send events to external systems, not directly update work items.
E
Create an Azure Function that listens for pull request merge events and updates work items via the REST API.
Why wrong: This is a custom solution, not a built-in configuration.

Full breakdown with real-world context →

Question 15easymultiple choice

Read the full Configure processes and communications explanation →

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?

Exhibit

Refer to the exhibit.

```json
{
  "resources": {
    "repositories": {
      "self": {
        "ref": "refs/heads/feature/*"
      }
    }
  },
  "trigger": {
    "batch": true,
    "branches": {
      "include": ["main", "release/*"]
    }
  },
  "pr": {
    "branches": {
      "include": ["main"]
    }
  }
}
```

Trap 1: A CI trigger will start because the branch name starts with…

The trigger does not include 'feature/*' branches.

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

PR triggers only run when a PR is created, not on push.

Trap 3: A CI trigger will start for all branches because batch is set to…

Batch does not affect branch inclusion; it only batches multiple commits.

Study all Configure processes and communications common traps →

A
A CI trigger will start because the branch name starts with 'feature/'.
Why wrong: The trigger does not include 'feature/*' branches.
B
No trigger will start.
The push to feature/new-feature does not match any branch in the trigger include list, and the PR trigger only applies to PRs.
C
A PR trigger will start because the branch name contains 'feature'.
Why wrong: PR triggers only run when a PR is created, not on push.
D
A CI trigger will start for all branches because batch is set to true.
Why wrong: Batch does not affect branch inclusion; it only batches multiple commits.

Full breakdown with real-world context →

Question 16easymultiple choice

Read the full Configure processes and communications explanation →

Your team uses Azure Boards to track work items. They want to automatically update the state of a work item when a pull request is merged in Azure Repos. What should you configure?

Trap 1: Configure a work item template.

Work item templates define default values for new work items, not state transitions on merge.

Trap 2: Create a service hook subscription.

Service hooks send notifications but do not update work items automatically.

Trap 3: Set pipeline variables in the YAML file.

Pipeline variables are for build/release processes, not work item state changes.

Study all Configure processes and communications common traps →

A
Configure a work item template.
Why wrong: Work item templates define default values for new work items, not state transitions on merge.
B
Define a branch policy to link work items and set automatic state transition.
Branch policies can require linked work items and automatically transition their state when a pull request is merged.
C
Create a service hook subscription.
Why wrong: Service hooks send notifications but do not update work items automatically.
D
Set pipeline variables in the YAML file.
Why wrong: Pipeline variables are for build/release processes, not work item state changes.

Full breakdown with real-world context →

Question 17mediummultiple choice

Read the full Configure processes and communications explanation →

A development team wants to ensure that all code changes are reviewed by at least two senior developers before merging into the main branch. They use Azure Repos. What should they configure?

Trap 1: Enable the build validation policy on the branch.

Build validation ensures code compiles but does not enforce reviewer count.

Trap 2: Set up a release pipeline with gated deployments.

Release pipelines control deployments, not code review requirements.

Trap 3: Add a status check policy using Azure Functions.

Status checks can enforce external conditions but not specifically reviewer count.

Study all Configure processes and communications common traps →

A
Enable the build validation policy on the branch.
Why wrong: Build validation ensures code compiles but does not enforce reviewer count.
B
Set up a release pipeline with gated deployments.
Why wrong: Release pipelines control deployments, not code review requirements.
C
Configure a branch policy requiring a minimum number of reviewers.
Branch policies can enforce a minimum number of reviewers for pull requests.
D
Add a status check policy using Azure Functions.
Why wrong: Status checks can enforce external conditions but not specifically reviewer count.

Full breakdown with real-world context →

Question 18hardmultiple choice

Read the full Configure processes and communications explanation →

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?

Trap 1: Configure a branch policy requiring CAB member approval on pull…

Branch policies apply to code changes, not deployment approvals.

Trap 2: Add a manual intervention task in the YAML pipeline.

Manual intervention tasks are less integrated and may not provide proper audit trails.

Trap 3: Set up a service hook to send an email to the CAB and wait for a…

Service hooks can notify but do not enforce approval within the pipeline.

Study all Configure processes and communications common traps →

A
Configure a branch policy requiring CAB member approval on pull requests.
Why wrong: Branch policies apply to code changes, not deployment approvals.
B
Add a manual intervention task in the YAML pipeline.
Why wrong: Manual intervention tasks are less integrated and may not provide proper audit trails.
C
Set up a service hook to send an email to the CAB and wait for a reply.
Why wrong: Service hooks can notify but do not enforce approval within the pipeline.
D
Create a release pipeline with a pre-deployment approval gate for the production stage.
Pre-deployment approvals allow designated approvers to approve before deployment, with full audit trail.

Full breakdown with real-world context →

Question 19mediumdrag order

Review the full routing breakdown →

Drag and drop the steps to configure a static route on a Cisco IOS router into the correct order.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

5Step 5

Question 20mediumdrag order

Read the full Configure processes and communications explanation →

Drag and drop the steps to set up a self-hosted Azure DevOps agent on a Windows VM into the correct order.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

5Step 5

Continue with 20-question session →

Free account

Track your progress over time

Create a free account to save your results and see which topics improve across sessions.

Focused Configure processes and communications sessions

Start a Configure processes and communications only practice session

Every question in these sessions is drawn from the Configure processes and communications domain — nothing else.

10 questions 20 questions 30 questions 50 questions

Browse all Configure processes and communications questions →Mixed AZ-400 session

Frequently asked questions

What does the AZ-400 exam test about Configure processes and communications?: Configure processes and communications questions test whether you can apply the concept in context, not just recognise a definition.
How should I use these practice questions?: Select your answer before revealing the explanation. Then read why each option is right or wrong — this active recall approach builds retention far faster than re-reading notes.
Can I practise just Configure processes and communications questions in a focused session?: Yes — the session launcher on this page draws every question from the Configure processes and communications domain. Use a 10-question session first to gauge your baseline, then move to 20 or 30 once the weak spots are clear.
Where can I practise other AZ-400 topics?: Use the topic links above to move to related areas, or go back to the AZ-400 question bank to see all topics.
Are these real exam questions or dumps?: These are original practice questions written to test the same concepts the AZ-400 exam covers. They are not copied from any real exam or dump site.

Configure processes and communications only

10 questions 20 questions 30 questions 50 questions

Mixed AZ-400 session

Track your progress

A free account saves results across sessions and highlights which topics need work.

Study resources

All AZ-400 questions Configure processes and communications domain overview AZ-400 exam guide

Exam traps to avoid

▸Answering from memory before reading the full scenario.
▸Missing a constraint such as cost, availability, security, scope or command context.
▸Choosing a broad answer when the question asks for the most specific fix.
▸Ignoring why the wrong options are tempting.

Configure processes and communications practice questions

What to know about Configure processes and communications

Common Configure processes and communications exam traps

Configure processes and communications questions

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?

During a sprint review, stakeholders complain that they don't receive notifications about completed work items. The team uses Azure Boards with a custom notification subscription. What is the most likely cause?

A multinational company uses Azure DevOps with a single project. The project has multiple teams in different time zones. They want to customize the process to reflect different working days for each team. What is the recommended approach?

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?

An organization uses Azure DevOps and wants to implement a change management process where all changes to the main branch require approval from a change advisory board (CAB). The CAB members are not part of the development team. How should they configure this?

Which TWO actions help improve communication and collaboration in a distributed Azure DevOps team?

Which THREE steps are essential when customizing an Azure DevOps process?

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?

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?

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?

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?

Exhibit

Your team uses Azure Boards to track work items. They want to automatically update the state of a work item when a pull request is merged in Azure Repos. What should you configure?

A development team wants to ensure that all code changes are reviewed by at least two senior developers before merging into the main branch. They use Azure Repos. What should they configure?

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?

Drag and drop the steps to configure a static route on a Cisco IOS router into the correct order.

Drag and drop the steps to set up a self-hosted Azure DevOps agent on a Windows VM into the correct order.

Track your progress over time

Start a Configure processes and communications only practice session

Related AZ-400 topic practice pages