Skip to content

AZ-400 · Domain 1: Design and implement processes and communications · 13% of the exam

Task 1.3: Configure collaboration and communication

Wikis with Markdown and Mermaid diagrams, release notes and API documentation, documentation generated from Git history, webhooks, and integrations between Azure Boards, GitHub, Azure DevOps and Microsoft Teams.

Study it

  • Wikis, Markdown and Mermaid, release notes, API documentation and docs from Git history

    Lesson coming

  • Webhooks and integrations with GitHub and Microsoft Teams

    Lesson coming

Sample questions

Try each one before opening the answer. Every option is explained, with the Microsoft documentation page that proves it.

Question 1 · choose 1

A wiki page in Azure DevOps contains a process diagram written in a ::: mermaid block that starts with "flowchart LR". It renders on the team's other Markdown viewer but shows an error in the wiki. The diagram must stay as text in the page. What should you change?

  1. AExport the diagram as a PNG and embed the image instead
  2. BWrap the diagram in an HTML div tag so the wiki passes it through
  3. CReplace flowchart LR with graph LR in the same ::: mermaid block
  4. DAdd [[_TOC_]] above the diagram so the wiki renders it
Show the answer and why
  • AExport the diagram as a PNG and embed the image instead

    Incorrect

    The diagram must stay as text that can be edited in the page.

  • BWrap the diagram in an HTML div tag so the wiki passes it through

    Incorrect

    Most HTML tags aren't supported in wiki Mermaid diagrams.

  • CReplace flowchart LR with graph LR in the same ::: mermaid block

    Correct

    The wiki's Mermaid support doesn't include flowchart syntax; the graph element draws the same diagram.

  • DAdd [[_TOC_]] above the diagram so the wiki renders it

    Incorrect

    That tag builds a table of contents from headings; it doesn't affect diagrams.

The Azure DevOps wiki supports Mermaid diagrams in a ::: mermaid container or a mermaid code block, with limited syntax: most HTML tags, Font Awesome, the flowchart keyword (use graph instead) and long arrows aren't supported.

Question 2 · choose 1

An internal change-tracking service has an HTTPS endpoint. It must receive a JSON message whenever a work item is updated in one Azure DevOps project, with basic authentication. Nobody wants to run a polling job. What should you configure?

  1. AA scheduled pipeline that queries updated work items every five minutes and calls the service with them
  2. BA Web Hooks service hook subscription on the work item updated event, pointing at the endpoint
  3. CA team notification subscription that emails the service's mailbox
  4. DAn Azure Monitor action group that calls the endpoint
Show the answer and why
  • AA scheduled pipeline that queries updated work items every five minutes and calls the service with them

    Incorrect

    That's the polling job the team wants to avoid.

  • BA Web Hooks service hook subscription on the work item updated event, pointing at the endpoint

    Correct

    A webhook subscription sends a JSON representation of the event to the endpoint, and basic authentication requires HTTPS.

  • CA team notification subscription that emails the service's mailbox

    Incorrect

    Email isn't a JSON POST to the service's endpoint.

  • DAn Azure Monitor action group that calls the endpoint

    Incorrect

    It isn't triggered by Azure DevOps work item events.

Service hooks run tasks on other services when events happen in a project. A Web Hooks subscription sends a JSON representation of the chosen event, such as a work item update, to any public HTTPS endpoint, and the payload's level of detail is configurable.

Question 3 · choose 1

In an Azure DevOps wiki page, how do you link to work item 512?

  1. AType @512
  2. BType #512
  3. CType AB#512
  4. DType [[512]]
Show the answer and why
  • AType @512

    Incorrect

    @ mentions users and groups.

  • BType #512

    Correct

    A hash mark followed by an ID links the work item.

  • CType AB#512

    Incorrect

    AB# is the syntax for GitHub text linking to Azure Boards.

  • DType [[512]]

    Incorrect

    That isn't the work item link syntax.

In Azure DevOps Markdown, type # followed by a work item ID to link the work item, and use @ mentions for users and groups.

Question 4 · choose 1

A Project Collection Administrator in Azure DevOps tries to connect five GitHub repositories to Azure Boards, but only two appear in the list. What is the most likely reason?

  1. ABoards connections allow two repositories at most
  2. BThe other three are private repositories in the organization
  3. CShe isn't an administrator of the other three repositories
  4. DThe project uses the Scrum process
Show the answer and why
  • ABoards connections allow two repositories at most

    Incorrect

    A connection can include up to 2,000 repositories.

  • BThe other three are private repositories in the organization

    Incorrect

    Private repositories can be connected.

  • CShe isn't an administrator of the other three repositories

    Correct

    You must be an administrator or owner of the GitHub repositories you connect.

  • DThe project uses the Scrum process

    Incorrect

    The process doesn't affect GitHub connections.

To connect Azure Boards to GitHub, you need to be an administrator or owner of the repositories; the dialog preselects the repositories where you're an administrator. A connection supports up to 2,000 repositories.

Question 5 · choose 1

Every new pull request in an Azure Repos repository should start with the same description checklist. How should the team set this up?

  1. AAdd a wiki page with the checklist
  2. BAdd a pull_request_template.md file to the default branch
  3. CAdd a branch policy that requires every comment to be resolved first
  4. DPut the checklist in the README
Show the answer and why
  • AAdd a wiki page with the checklist

    Incorrect

    A wiki page isn't inserted into pull requests.

  • BAdd a pull_request_template.md file to the default branch

    Correct

    A default pull request template is applied to the description of every new pull request.

  • CAdd a branch policy that requires every comment to be resolved first

    Incorrect

    Policies don't fill in descriptions.

  • DPut the checklist in the README

    Incorrect

    A README isn't applied to pull requests.

A default pull request template, a file named pull_request_template.md in the default branch, is applied automatically to new pull requests unless a branch-specific template overrides it.

Question 6 · choose 1

New contributors to a repository don't know how to build it or where to start. Where should the team put that guidance so it's shown with the code?

  1. AIn the pipeline's YAML comments
  2. BIn a work item assigned to every newcomer during their first sprint
  3. CIn a README file written in Markdown in the repository
  4. DIn the repository's Git tags
Show the answer and why
  • AIn the pipeline's YAML comments

    Incorrect

    YAML comments aren't where people look first.

  • BIn a work item assigned to every newcomer during their first sprint

    Incorrect

    Work items track work, not lasting guidance.

  • CIn a README file written in Markdown in the repository

    Correct

    READMEs orient contributors and are shown with the repository's files.

  • DIn the repository's Git tags

    Incorrect

    Tags mark commits.

You can define README files for each repository or project, written in Markdown, to orient contributors to the code and how to work with it.

Practise domain 1 →Practise all domains →