AZ-400 Practice Test 40 — 15 Questions

Question 1

Your organization uses Azure Repos and has multiple Git repositories that share common code. You want to enable code reuse across these repositories without duplicating code. Which strategy should you use?

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

Accepted Answer

Reference the shared repository as a Git submodule. Git submodules allow you to include a specific commit of a shared repository as a subdirectory within multiple parent repositories, enabling code reuse without duplication. When the shared code is updated, you can pull the latest commit into each parent repository, maintaining a clear link between the parent and the shared codebase. This is the native Git mechanism for referencing external repositories while preserving version control history.

Answer

Use Git subtrees to merge the shared code into each repository

Answer

Publish the shared code as a NuGet package

Answer

Add the shared repository as an upstream source in Azure Artifacts

Question 2

Your team is implementing a security and compliance plan for Azure DevOps. Which TWO actions should you take to meet regulatory requirements for audit logging and access control?

Accepted Answer

Enable Azure DevOps audit log to track changes to security policies and user permissions.. Enabling the Azure DevOps audit log (option B) is essential for regulatory compliance because it records changes to security policies, user permissions, and other critical events, providing an immutable trail for forensic analysis and reporting. This directly meets audit logging requirements by capturing who did what and when, which is necessary for standards like SOC 2, ISO 27001, or GDPR.

Answer

Enable anonymous access to project boards for external stakeholders.

Answer

Grant all users Project Collection Administrator role to simplify access management.

Answer

Disable auditing for the project to reduce log volume.

Question 3

You need to enforce that every commit in your repository is associated with a work item in Azure Boards. Which mechanism should you use?

Accepted Answer

Configure a branch policy to require linked work items. Azure Repos branch policies include a setting to 'Require linked work items', which enforces that every pull request (and by extension, every commit merged through that PR) is associated with a work item in Azure Boards. This policy is enforced server-side at merge time, ensuring no commit can be merged without a linked work item, regardless of how the commit message is formatted.

Answer

Use commit messages with work item IDs

Answer

Deploy a custom Git hook on the server

Answer

Use the 'Require status checks' policy

Question 4

You have a YAML pipeline that builds a .NET application. You need to ensure that the pipeline uses the .NET SDK version 6.0.x. Which task should you add to the pipeline?

Accepted Answer

UseDotNet@2. The UseDotNet@2 task is the correct choice because it explicitly installs a specific .NET SDK version (6.0.x) on the build agent, ensuring the pipeline uses the required SDK for building the .NET application. This task downloads and caches the SDK, making it available for subsequent tasks like DotNetCoreCLI@2.

Answer

NuGetToolInstaller@1

Answer

DotNetCoreCLI@2

Answer

PowerShell@2

Question 5

Your team uses Azure Boards with a Kanban board. You want to limit the number of work items in the 'In Progress' column to prevent bottlenecks. What should you configure?

Accepted Answer

Column limits on the Kanban board. Column limits on the Kanban board directly enforce work-in-progress (WIP) constraints by capping the number of work items allowed in a specific column, such as 'In Progress'. This prevents bottlenecks by signaling the team to complete existing work before pulling new items, aligning with Lean and Kanban principles. Azure Boards supports this configuration through the board settings, where you can set a maximum limit per column.

Answer

Branch policies

Answer

Backlog level settings

Answer

Work item rules

Question 6

Your company uses Microsoft Sentinel for security monitoring. Azure DevOps pipelines deploy resources to production. You need to create an automated response that triggers when Sentinel detects a high-severity alert related to unauthorized pipeline changes. The response should temporarily disable the service connection used by the pipeline and notify the security team. What should you do?

Accepted Answer

Create a Sentinel playbook using Azure Logic Apps that calls the Azure DevOps REST API to update the service connection status.. A Sentinel playbook built with Azure Logic Apps can be triggered by a Sentinel alert and execute custom actions, such as calling the Azure DevOps REST API to disable a service connection and sending notifications. This provides the automated response required. The playbook integrates with Sentinel's automation rules to run when the high-severity alert fires.

Answer

Configure a Sentinel analytics rule with the alert and use automated response to send an email.

Answer

Set up an Azure DevOps service hook that triggers on pipeline events.

Answer

Use Azure Policy to deny changes to service connections.

Question 7

Which TWO actions should you take to ensure that only approved pipelines can deploy to production in Azure DevOps? (Choose two.)

Accepted Answer

Configure a pipeline approval gate on the production environment.. Configuring a pipeline approval gate on the production environment ensures that every deployment to production requires explicit approval from designated reviewers, preventing unauthorized or unapproved pipelines from deploying. Option C is correct because setting branch policies to require a pull request before merging to the main branch enforces code review and validation, ensuring that only approved changes reach the main branch, which is typically the source for production deployments.

Answer

Disable parallel jobs for the project.

Answer

Limit the number of pipelines that can deploy from the main branch.

Answer

Use a single agent pool for all pipelines.

Question 8

You are deploying a Java application to Azure App Service using Azure Pipelines. You want to automatically capture JVM metrics (heap usage, garbage collection) and correlate them with deployment events. What should you do?

Accepted Answer

Enable Application Insights Java agent in the App Service.. To automatically capture JVM metrics (heap usage, garbage collection) and correlate them with deployment events, you should enable the Application Insights Java agent in the App Service. The Java agent auto-instruments the JVM, collecting detailed metrics and telemetry without code changes. Application Insights integrates with Azure Pipelines, allowing deployment annotations to be correlated with telemetry.

Answer

Use Azure Monitor diagnostic settings for the App Service.

Answer

Attach a profiler from Visual Studio to the App Service process.

Answer

Configure App Service diagnostic logs to capture stdout/stderr.

Question 9

Your build pipeline runs on a self-hosted agent pool. You need to ensure that only authorized pipelines can use these agents. Which security measure should you implement?

Accepted Answer

Set permissions on the agent pool. In Azure DevOps, agent pool security is controlled through the pool's permissions. By setting permissions on the agent pool, you can restrict which projects, pipelines, or users are allowed to use the agents, ensuring only authorized pipelines can run on them. This is the direct, built-in mechanism for securing a self-hosted agent pool.

Answer

Use agent tokens

Answer

Use variable groups

Answer

Configure agent queues

Question 10

Your pipeline has the following YAML trigger configuration:

trigger:
  paths:
    include:
    - src/app/**

A developer pushes changes to a file in 'src/app/config.json' on a branch named 'release/v1'. Which statement is true about the build trigger?

Accepted Answer

The build will be triggered.. The provided YAML trigger includes a path filter that matches 'src/app/**'. The push to 'src/app/config.json' matches that include pattern, so the build triggers. No branch filter is specified, so the trigger applies to all branches including 'release/v1'. Therefore, option B is correct.

Answer

The build will be triggered but only if no other builds are running.

Answer

The build will not be triggered because the path filter is too restrictive.

Answer

The build will not be triggered because the branch is not 'main'.

Question 11

Your organization uses GitHub for source control and Azure Pipelines for CI/CD. You have a monorepo with multiple projects. You need to design a pipeline that only builds and tests the projects that have changed in each commit. You want to minimize build time and avoid unnecessary runs. The pipeline should also handle dependencies between projects. Which approach should you use?

Accepted Answer

Configure path filters in the pipeline trigger, and use a custom script to detect dependencies and build only affected projects plus their dependents. To build only changed projects in a monorepo, you need to detect which files changed and then determine the affected projects and their dependents. Path filters in the pipeline trigger can limit the pipeline to run only when specific paths change, but they don't handle dependencies. A custom script can analyze the dependency graph and build only the affected projects plus their dependents, minimizing build time. This approach is flexible and can be implemented in Azure Pipelines using scripts or tools like Nx or Lerna.

Answer

Create a single pipeline that builds all projects on every commit

Answer

Use a single pipeline with a condition that checks which files changed and runs only the corresponding job

Answer

Create separate pipelines for each project and trigger them manually

Question 12

Your organization has multiple GitHub repositories that use shared workflows. You want to centrally manage these workflows and ensure they are always up to date. What is the recommended approach?

Accepted Answer

Create a central repository with reusable workflows and reference them using the 'uses' keyword in your workflows.. GitHub reusable workflows are the native mechanism for centralizing workflow logic across repositories. By storing workflows in a central repository and referencing them with the 'uses' keyword (e.g., 'uses: org/central-repo/.github/workflows/build.yml@main'), all consuming repositories automatically inherit updates when the central workflow changes. This eliminates duplication and ensures consistency without manual synchronization.

Answer

Use the GitHub API to push workflow files to each repository on a schedule.

Answer

Download the workflows from a central blob storage and include them as inline scripts.

Answer

Store the workflows in a separate repository and use Git submodules to include them.

Question 13

You are designing a build validation policy for a GitHub repository. You want to ensure that all pull requests pass a CI check before they can be merged. What should you configure?

Accepted Answer

Add a GitHub Actions workflow that runs on 'pull_request' and set it as a required status check in branch protection.. To require a CI check before merge, you add a GitHub Actions workflow triggered on 'pull_request' and then configure branch protection (or a repository ruleset) to mark that workflow's job as a required status check. This blocks merging until the check passes.

Answer

Enable Dependabot alerts on the repository.

Answer

Configure a repository rule to require a pull request before merging.

Answer

Create a webhook to trigger a build on Azure Pipelines.

Question 14

Your team uses GitHub Enterprise with GitHub Actions. Compliance requires that all contributors sign commits with a verified GPG key. You have enabled 'Require signed commits' on the repository. However, a developer reports that their commits are being rejected even though they have configured a GPG key. The error says 'Commit must have a valid signature.' The developer's GPG key is listed in their GitHub account settings. What is the most likely cause?

Accepted Answer

The developer's local Git email does not match the email associated with the GPG key in GitHub.. GitHub verifies a GPG signature by matching the signing key's associated email (and key ID) against the commit's author/committer email. If the developer's local Git user.email does not match the email registered with the GPG key in GitHub, GitHub marks the signature as unverified and the 'Require signed commits' rule rejects the push with 'Commit must have a valid signature.' The key being present in GitHub settings is not sufficient — the email binding must also match.

Answer

The developer's GPG key has expired.

Answer

The developer's GPG key is not uploaded to GitHub.

Answer

GitHub only supports S/MIME, not GPG.

Question 15

Your team uses GitHub Flow and wants to enforce that all pull requests require at least one approval before merging to the main branch. Which branch protection rule should you configure?

Accepted Answer

Require a pull request before merging with at least 1 approval. GitHub branch protection's 'Require a pull request before merging' setting, with 'Require approvals' set to at least 1, enforces that changes to main go through a PR with a reviewer sign-off. This directly matches the requirement for at least one approval before merge. Status checks, push restrictions, and linear history address different concerns and do not enforce human approval.

Answer

Require status checks to pass before merging

Answer

Restrict who can push to matching branches

Answer

Require linear history