AZ-400 Practice Test 24 — 15 Questions

Question 1

Your Azure DevOps organization contains multiple teams. You need to ensure that code reviews require approval from a member of the security team before merging to the main branch. What is the best way to implement this?

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

Accepted Answer

Configure branch policies in Azure Repos. Configuring branch policies in Azure Repos (option D) is the correct approach because branch policies allow you to require specific reviewers—such as members of the security team—for pull requests targeting the main branch. This ensures that every merge to main must be approved by the security team. Option A is incorrect: Azure Pipelines is designed for continuous integration and delivery (CI/CD), not for enforcing code review requirements. Option B is incorrect: Microsoft Defender for Cloud focuses on cloud security posture management and threat protection, not on code review policies. Option C is incorrect: Microsoft Sentinel is a security information and event management (SIEM) tool for security analytics and threat intelligence, not for managing branch-level review policies.

Answer

Add a validation step in Azure Pipelines

Answer

Enable Microsoft Defender for Cloud

Answer

Deploy Microsoft Sentinel

Question 2

Drag and drop the steps to set up a continuous integration pipeline in Azure Pipelines into the correct order.

Accepted Answer

Create the pipeline, then select the source repository, then configure triggers, then add tasks, then validate the pipeline.. The correct order for setting up a continuous integration pipeline in Azure Pipelines is: first create the pipeline, then select the source repository (e.g., Azure Repos or GitHub), then configure triggers (e.g., on commit or PR), then add tasks (build, test, etc.), and finally validate the pipeline by running it. This sequence is reflected in option A. Starting with source selection or adding tasks before creation is incorrect.

Answer

Create the pipeline, then configure triggers, then select the source repository, then add tasks, then validate the pipeline.

Answer

Create the pipeline, then add tasks, then select the source repository, then configure triggers, then validate the pipeline.

Answer

Select the source repository, then create the pipeline, then configure triggers, then add tasks, then validate the pipeline.

Question 3

Your team uses GitHub Actions to build and deploy a static website to Azure Storage. The workflow uses the 'azure/storage-blob-upload' action to deploy to a storage account static website. Recently, deployments started failing with 'Error: Failed to get credentials'. The workflow uses OpenID Connect (OIDC) for authentication. What is the most likely cause?

Accepted Answer

The service principal used for OIDC does not have the 'Storage Blob Data Contributor' role on the storage account.. The 'azure/storage-blob-upload' action requires the service principal used for OIDC authentication to have the 'Storage Blob Data Contributor' role on the storage account to upload static website content. Without this role, the action fails to obtain credentials for blob write operations, resulting in the 'Failed to get credentials' error.

Answer

The storage account firewall is blocking the GitHub Actions IP range.

Answer

The OIDC configuration in GitHub is missing the 'client secret' field.

Answer

The 'azure/storage-blob-upload' action does not support static websites.

Question 4

You are reviewing a branch protection rule JSON for a GitHub repository. Developers complain that they cannot merge pull requests. What is the most likely cause?

Accepted Answer

The signed commit requirement is enforced but developers are not signing commits.. When a branch protection rule requires signed commits, any pull request containing unsigned commits will be blocked from merging. GitHub verifies commit signatures using GPG or S/MIME, and if developers are not signing their commits, the merge will fail regardless of other settings.

Answer

The required approving review count is set to 1.

Answer

Rebase merging is disabled.

Answer

Squash merge is the only allowed method.

Question 5

You are designing a multi-stage YAML pipeline for a .NET Core application. The pipeline must build, test, and deploy to a staging environment. You want to ensure that the deployment stage only runs if the build and test stages succeed, and that the staging deployment uses the exact same bits that were built. Which strategy should you use?

Accepted Answer

Create separate stages for build, test, and deploy. Use the 'dependsOn' keyword and publish artifact in build stage, download in deploy stage.. Using separate stages with 'dependsOn' ensures the deployment stage only runs after successful build and test stages. Publishing the build artifact in the build stage and downloading it in the deploy stage guarantees that the exact same compiled bits are used for deployment, maintaining consistency across environments.

Answer

Set up a release pipeline that uses the same build artifact and requires manual approval.

Answer

Use a build trigger on the staging branch to deploy after each commit, ignoring test results.

Answer

Define the pipeline with a single stage and use a condition to skip test on failure.

Question 6

Your organization is adopting Azure DevOps to manage a new project for a client. The client requires that all work items be linked to Git commits and pull requests. Additionally, they want a dashboard that shows the team's velocity and work item trends. You are responsible for setting up the project and configuring the necessary integrations. The team uses a Scrum process with Sprints. You have already created the project and imported the work items. What should you do next to meet the client's requirements?

Accepted Answer

Configure branch policies on the main branch to require linking work items. Set up the repository to automatically link commits to work items. Then create an Analytics view in Azure Boards to track velocity and work item trends.. Configuring branch policies on the main branch to require linking work items ensures that all pull requests are linked to work items, and enabling automatic linking of commits to work items covers commits. Creating an Analytics view in Azure Boards provides the necessary velocity and work item trend dashboards. Option A is incorrect because Azure Functions are unnecessary—Azure DevOps provides built-in linking and Analytics. Option C is incorrect because manual linking is inefficient and error-prone, and Power BI is not required. Option D is incorrect because it does not enforce linking on commits/PRs and does not address the dashboard requirement.

Answer

Create a custom tool using Azure Functions to parse commit messages and link work items. Use the built-in Charts feature in Azure Boards to create velocity charts.

Answer

Instruct developers to manually add work item IDs in commit messages and pull request descriptions. Create a custom dashboard using Power BI connected to Azure Boards.

Answer

Enable the setting 'Automatically link work items' in the repository settings. Configure a service hook to post commit details to a Teams channel for visibility.

Question 7

Refer to the exhibit. You receive a secret scanning alert for an Azure DevOps PAT in a GitHub repository. The push_protection_bypass is false. What does this mean and what action should you take?

Accepted Answer

The secret was blocked from being pushed; you should revoke the PAT and investigate the incident.. When `push_protection_bypass` is `false`, it means the secret was blocked from being pushed by GitHub's push protection feature. The alert indicates the secret was detected and prevented from entering the repository, so the correct action is to revoke the compromised PAT and investigate the incident to prevent future occurrences. Option D correctly identifies that the secret was blocked and prescribes the appropriate remediation steps.

Answer

The secret was pushed but push protection was bypassed; you need to revoke the PAT and use git filter-branch to remove it from history.

Answer

The secret was pushed successfully; you need to rotate the PAT and audit the commit history.

Answer

The secret was pushed and push protection was not bypassed; you need to open a support ticket with GitHub to remove the secret.

Question 8

Which THREE factors should you consider when designing a strategy for managing secrets in Azure Pipelines? (Choose three.)

Accepted Answer

Use Azure Key Vault to store secrets.. Azure Key Vault is the recommended service for securely storing and managing secrets, keys, and certificates. By integrating Key Vault with Azure Pipelines, you can avoid exposing sensitive information in YAML files or pipeline logs. This approach ensures secrets are never hardcoded and are dynamically retrieved at runtime.

Answer

Hardcode secrets in the pipeline YAML for simplicity.

Answer

Store secrets as plain text variables in YAML pipelines.

Question 9

Your organization uses Microsoft Entra ID for identity and Azure DevOps for source control. You need to enforce that all code changes to the main branch require a pull request with at least two approvals and no failing checks. What should you configure?

Accepted Answer

Set up a branch policy on the main branch in Azure Repos. Azure Repos branch policies allow you to enforce required pull requests, minimum number of reviewers (e.g., two approvals), and status checks (e.g., no failing checks) on the main branch. This ensures that all code changes to the protected branch comply with the defined quality and security gates before merging.

Answer

Configure a Conditional Access policy in Microsoft Entra ID

Answer

Add an environment protection rule in Azure Pipelines

Answer

Use a service hook to notify reviewers when a push occurs

Question 10

You are configuring a build pipeline for a JavaScript application. You want to run linting, unit tests, and build steps only when changes are pushed to the 'develop' branch. Which trigger should you configure?

Accepted Answer

Enable CI trigger with a branch filter for 'develop'.. Enabling a CI trigger with a branch filter for 'develop' ensures that the pipeline automatically runs linting, unit tests, and build steps only when changes are pushed to the 'develop' branch. This matches the requirement precisely, as CI triggers respond to push events, and the branch filter restricts execution to the specified branch.

Answer

Enable pull request trigger.

Answer

Enable scheduled trigger.

Answer

Enable continuous integration (CI) trigger without branch filters.

Question 11

Your team uses Azure Pipelines with a YAML-based build pipeline. The pipeline builds a .NET application and runs unit tests. Recently, the unit tests are failing intermittently due to flaky tests. You need to ensure that the pipeline fails only if the same test fails in two consecutive runs. Which feature should you configure?

Accepted Answer

Configure the 'retry failed tests' setting in the pipeline's test tab.. The correct feature is the 'Retry failed tests' setting in the pipeline's test tab. This allows you to configure the number of times a failed test is automatically retried. If the test passes on retry, the pipeline is marked as succeeded with warnings, effectively requiring two consecutive failures for the pipeline to fail. Option A is incorrect because GitHub Actions workflows are not relevant to Azure Pipelines. Option B is for rerunning failed stages, not individual tests. Option C reruns failed jobs, not tests.

Answer

Implement a GitHub Actions workflow with 're-run' trigger.

Answer

Use the 'Re-run failed stages' option in the pipeline run.

Answer

Enable 'Automatically rerun failed jobs' in the pipeline settings.

Question 12

Your pipeline uses a multi-stage YAML file. You want to conditionally run a stage only if the build originates from the 'main' branch. Which syntax should you use?

Accepted Answer

condition: eq(variables['Build.SourceBranch'], 'refs/heads/main'). The `condition` directive in a YAML pipeline stage evaluates expressions using Azure Pipelines syntax. The `eq()` function compares two values, and `Build.SourceBranch` for the 'main' branch returns `refs/heads/main`, not just `main`. This exact match ensures the stage runs only when the build originates from the 'main' branch.

Answer

condition: variables['Build.SourceBranch'] == 'main'

Answer

condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))

Answer

condition: eq(variables['Build.SourceBranch'], 'main')

Question 13

You are a DevOps consultant for a financial services company that is migrating from TFVC to Git. The existing TFVC repository has several branches: main, dev, feature branches, and release branches. The history is linear with no branching. The company requires that all future Git commits follow a strict naming convention: 'type(scope): description' (e.g., 'feat(api): add new endpoint'). They also want to prevent direct commits to the main branch; all changes must go through pull requests with at least one reviewer. Additionally, they want to ensure that each commit message is validated before it is merged. The team is small (5 developers) and they want a simple setup without complex tooling. Which approach should you recommend?

Accepted Answer

Configure branch policies on the main branch: require a minimum of one reviewer, and add a status check that runs a script to validate the commit message format. Azure Repos branch policies allow you to enforce pull request requirements (e.g., minimum number of reviewers) and require a status check that runs a custom script to validate commit message format. This ensures all commits merged into main comply with the naming convention and review policy without complex tooling, fitting the small team's need for a simple, server-side enforcement mechanism.

Answer

Create a build pipeline that validates commit messages and fails the build if invalid

Answer

Use a server-side pre-receive hook in the Git repository

Answer

Install a client-side pre-commit hook on each developer's machine to validate messages

Question 14

An organization uses Azure Repos with multiple Git repositories. They want to enforce that all commits to the main branch are signed using GPG keys. Which combination of actions is required to enforce commit signing?

Accepted Answer

Configure branch policy to require signed commits and have developers configure Git to sign commits with their GPG key.. Azure Repos supports a branch policy that requires commits to be signed, and developers must configure Git to sign commits with their GPG key using `git config --global user.signingkey` and `git commit -S`. This ensures that only signed commits are accepted into the main branch, enforcing non-repudiation and integrity.

Answer

Configure branch policy to require signed commits and have developers add their SSH public key to Azure Repos.

Answer

Configure repository settings to require a personal access token (PAT) for each commit.

Answer

Use Azure Key Vault to store signing keys and configure Azure Repos to automatically sign commits.

Question 15

You are designing a YAML pipeline that builds a .NET application and publishes it as a NuGet package to Azure Artifacts. Which three tasks should you include in the build stage?

Accepted Answer

DotNetCoreCLI@2 with command 'build'. The DotNetCoreCLI@2 task with the 'build' command compiles the .NET application source code into intermediate language (IL) assemblies. This is a mandatory step after restoring dependencies and before packing the project into a NuGet package. Without a successful build, the subsequent pack and push operations would fail.

Answer

NuGetCommand@2 with command 'install'

Answer

DotNetCoreCLI@2 with command 'push'