AZ-400 Practice Test 43 — 15 Questions

Question 1

You are a DevOps engineer for a large enterprise that uses GitHub Enterprise Cloud. The development team follows a GitFlow branching strategy with develop, feature, release, and main branches. The release branch is created from develop when a release is ready. After testing, the release branch is merged into main and then tagged. However, the team frequently forgets to merge release branches back into develop, causing hotfixes applied to main to not be in develop. You need to implement an automated process to ensure that after a release branch is merged into main, the changes are also merged back into develop. The solution must not require manual intervention and must handle merge conflicts gracefully by opening a pull request for conflict resolution. Which approach should you use?

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

Accepted Answer

Create a GitHub Actions workflow that triggers on push to main, attempts to merge main into develop, and if conflicts occur, opens a pull request for manual resolution.. It uses a GitHub Actions workflow triggered on pushes to main to automatically merge main into develop. If conflicts arise, the workflow opens a pull request for manual resolution, ensuring no changes are lost and the process remains automated without manual intervention.

Answer

Configure a branch protection rule on main that requires a pull request to merge into develop.

Answer

Create a scheduled workflow that runs daily and merges main into develop if there are no conflicts.

Answer

Set up a webhook in GitHub that calls an Azure Function to merge main into develop.

Question 2

You have deployed an Azure Resource Manager (ARM) template for a scheduled query rule as shown. The rule is enabled and targets an Application Insights resource. However, no alerts are firing despite HTTP 500 errors occurring. What is the most likely cause?

Accepted Answer

The threshold of 100 is too high; the rule should use a percentage-based condition on error rate.. The threshold of 100 is an absolute count, not a percentage. HTTP 500 errors may occur sporadically, but unless they reach 100 within the evaluation window, the alert will not fire. For error-rate monitoring, a percentage-based condition (e.g., >5% of total requests) is more appropriate to detect anomalies even with lower traffic volumes.

Answer

The severity is set to 2, which suppresses the alert.

Answer

The metric name 'requests/count' is misspelled; it should be 'requests/count' (correct).

Answer

The dimension filter for 'request/resultCode' includes '500' but should also include '5xx' wildcard.

Question 3

Your team uses GitHub and wants to automatically label pull requests based on the content of the changes (e.g., 'frontend' for changes in /frontend folder, 'backend' for /backend). Which approach should you use?

Accepted Answer

Create a GitHub Actions workflow that runs on pull_request events and uses an action like 'actions/labeler' to add labels based on path patterns.. GitHub Actions provides a native, event-driven way to automate labeling based on pull request changes. The 'actions/labeler' action specifically inspects file paths in the diff and applies labels defined in a configuration file, making it the simplest and most maintainable solution for path-based labeling.

Answer

Use branch protection rules to require specific labels based on branch name patterns.

Answer

Set up a webhook that triggers an Azure Function to parse the pull request diff and add labels.

Answer

Use a CODEOWNERS file to assign labels based on file paths.

Question 4

Your team deploys a web application to Azure App Service using Azure Pipelines. The application requires a configuration file that contains connection strings and app settings. You need to ensure that the configuration is environment-specific and that sensitive values are not exposed in the pipeline logs. The configuration file is stored in a Git repository with different branches for each environment. You also need to support local development with the same configuration approach. Which strategy should you use?

Accepted Answer

Store environment-specific settings in Azure App Service configuration, and use variable groups in Azure Pipelines for secrets. Use token replacement in the config file during deployment.. The correct strategy is to store environment-specific settings in Azure App Service configuration (which can be set per slot/environment) and use Azure Pipelines variable groups for secrets, ensuring they are not exposed in logs. Token replacement in the config file during deployment allows the same config file to be used across environments while injecting environment-specific values. This supports local development because developers can use local settings or user secrets without committing sensitive data.

Answer

Store all settings, including secrets, in the config file in each branch. Use a script to replace tokens.

Answer

Use Azure App Service slots with sticky settings and store all settings in a single config file committed to the repository.

Answer

Use the same config file for all environments and override settings using pipeline variables based on branch name.

Question 5

Which THREE are benefits of using a monorepo with Azure Repos and CI/CD pipelines?

Accepted Answer

Easier code sharing across projects. Option C is correct because a monorepo places all projects in a single repository, so shared libraries, utilities, and interfaces can be referenced directly rather than published and consumed as versioned packages across multiple repos. Option D is correct because dependencies between components are resolved from one consistent source tree, avoiding version-skew and cross-repo package coordination that complicates dependency management. Option E is correct because a single commit can change multiple components together, so a cross-component change lands atomically and CI/CD can validate the whole change set in one pipeline run. Option A is not a benefit of a monorepo; granular repository-level permissions are actually harder because everything lives in one repo, and Azure Repos permissions are typically applied at repo, branch, or path level rather than per project. Option B is not a benefit either, since a monorepo is a larger codebase and builds are not inherently faster; faster builds usually require path filters, incremental builds, or pipeline caching rather than resulting from the monorepo itself.

Answer

Granular repository-level permissions

Answer

Faster build times due to smaller codebase

Question 6

You are designing a release pipeline for a microservices application deployed to Azure Kubernetes Service (AKS). You need to implement a strategy that minimizes downtime during updates by gradually shifting traffic to the new version while monitoring for errors. Which deployment strategy should you use?

Accepted Answer

Canary deployment. Canary deployment is the correct choice because it gradually shifts a small percentage of traffic to the new version while monitoring for errors, allowing you to detect issues early and roll back quickly without impacting all users. In AKS, this can be implemented using a service mesh like Istio or a progressive delivery tool like Flagger, which manages traffic splitting via VirtualService and DestinationRule configurations. This minimizes downtime by ensuring the majority of users remain on the stable version until the new version is verified.

Answer

Recreate deployment

Answer

Blue-green deployment

Answer

Rolling update

Question 7

A developer accidentally committed a sensitive password to a Git repository. The commit has already been pushed to the remote. What is the first step to remediate the situation?

Accepted Answer

Immediately notify the security team and rotate the password. Once a secret is pushed to a remote Git repository, it must be considered compromised because the commit may already be fetched by others, and old commits remain in reflogs and other clones. The first step is to immediately notify the security team and rotate/revoke the password to prevent unauthorized use. Only after the credential is invalidated should you attempt to remove it from Git history (e.g., by amending, rebasing, or using filter-repo) and force push, understanding that history rewriting may not fully eliminate all copies.

Answer

Delete the file from the repository and commit the deletion

Answer

Remove the password from the file, amend the commit, and force push

Answer

Revert the commit that introduced the password

Question 8

Which TWO of the following are valid ways to trigger a pipeline in Azure DevOps when a pull request is created?

Accepted Answer

Pull request trigger in YAML pipeline. Azure DevOps YAML pipelines support a `pr` trigger that automatically runs the pipeline when a pull request is created or updated. This trigger is defined directly in the YAML file and can be scoped to specific branches or paths, making it a native and flexible way to respond to PR events.

Answer

Scheduled trigger

Answer

Continuous integration trigger

Answer

Pipeline completion trigger

Question 9

Which TWO of the following are valid ways to trigger a release pipeline in Azure DevOps? (Select TWO.)

Accepted Answer

Continuous deployment trigger after a build completes.. Azure DevOps release pipelines can be triggered in multiple ways. A continuous deployment trigger (A) automatically creates a release whenever a build artifact is successfully produced. A scheduled release trigger (E) creates a release at a defined time (e.g., nightly). Manual release creation via the 'Create release' button (C) is a manual action, not an automated configured trigger. Pull request triggers (D) are valid only for build pipelines, not release pipelines. 'Source version trigger' (B) is not a standard release trigger type. Therefore, the two valid trigger types are A and E.

Answer

Source version trigger.

Answer

Manual trigger via the 'Create release' button.

Answer

Pull request trigger.

Question 10

Your organization uses Azure DevOps. You have a classic release pipeline that deploys to multiple stages: Dev, QA, and Prod. Each stage has a pre-deployment approval gate. Recently, the QA team complained that they are not receiving approval notifications. You have verified that the approval configuration is correct and the approvers are members of the 'QA Approvers' group. The release pipeline is set to send email notifications to the approvers. However, the QA approvers report they do not receive any emails when a release is pending their approval. What should you check first?

Accepted Answer

Verify that the organization-level notification settings allow email notifications for approvals.. In Azure DevOps, email notifications for approvals are governed by organization-level (and sometimes project-level) notification settings, not just the pipeline's own configuration. If the organization has disabled or restricted the 'Approval pending' notification, approvers will not receive emails even though the pipeline is configured to send them. Verifying organization notification settings is therefore the correct first check.

Answer

Ask the QA team to check their spam folder.

Answer

Add a 'Send email' task in the pipeline before the approval gate.

Answer

Check the 'Release Pipeline' logs for a warning about email delivery failure.

Question 11

The pipeline fails with the error 'The resource with name 'myregistry' could not be found'. What is the most likely cause?

Accepted Answer

The Azure Container Registry name is incorrect. The error 'The resource with name 'myregistry' could not be found' indicates that the pipeline is trying to reference an Azure Container Registry that does not exist or is misspelled. The most likely cause is that the registry name in the pipeline configuration is incorrect, such as a typo or wrong environment variable. This is a resource resolution error, not a permissions or tooling issue.

Answer

The build ID variable is not defined

Answer

The service connection does not have permission to access the registry

Answer

The Azure CLI is not installed on the agent

Question 12

Your organization uses GitHub Advanced Security. A developer reports that a secret scanning alert for an Azure DevOps Personal Access Token (PAT) is a false positive. What should you do to handle this?

Accepted Answer

Mark the alert as false positive in the GitHub UI.. GitHub Advanced Security secret scanning alerts can be dismissed as 'false positive' directly in the GitHub UI (Security tab → Secret scanning → alert → Dismiss → False positive). This preserves the audit trail and prevents the alert from recurring as an open finding while documenting the reason.

Answer

Disable secret scanning for the repository.

Answer

Delete the PAT from the repository and revoke it.

Answer

Ignore the alert and leave it open.

Question 13

Your organization uses GitHub Flow for source control with a monorepo containing multiple microservices. Each microservice has its own build and test workflow. You need to design a CI/CD strategy that builds and tests only the services affected by a pull request to reduce build times and resource usage. You also need to ensure that all pull requests to the main branch pass required checks before merging. What should you implement?

Accepted Answer

Use separate workflows for each microservice with path filters (on: pull_request paths:) so that only workflows with changed files are triggered.. Path filters on the `on: pull_request` trigger allow each microservice workflow to run only when files under its directory change, which is the standard GitHub Actions pattern for monorepo selective CI. This directly reduces build time and resource consumption while still satisfying required status checks configured on the main branch. Separate workflows also give per-service check granularity, so branch protection rules can require only the relevant checks.

Answer

Use a single workflow that builds and tests all microservices on every push to any branch.

Answer

Set up a webhook that triggers builds manually per service based on pull request comments.

Answer

Create a single workflow that uses a matrix strategy to build and test each microservice, and run it on every pull request.

Question 14

Your team uses GitHub Flow for feature development. A developer commits directly to the main branch without creating a pull request. Which practice should you enforce to ensure code quality and prevent direct commits?

Accepted Answer

Configure branch protection rules on the main branch to require pull request reviews before merging.. Branch protection rules on the main branch are the GitHub-native mechanism to require pull request reviews before any merge, which directly prevents direct commits. Enabling 'Require a pull request before merging' with a minimum number of approvals blocks the developer's direct push and forces the GitHub Flow review step.

Answer

Require a manual sign-off from a team lead after each commit.

Answer

Set up a .gitignore file to prevent certain file types from being committed.

Answer

Add a CODEOWNERS file that automatically assigns reviewers to any changes.

Question 15

You are implementing a release pipeline for a web application deployed to multiple Azure App Service instances across different regions (West US, East US, and North Europe). The deployment must follow a phased rollout: first West US, then East US, then North Europe, with a manual approval gate between each region. Each region should have its own slot for staging and production. You need to design the pipeline to minimize duplication of stages and tasks. What should you do?

Accepted Answer

Use a multi-stage YAML pipeline with environment per region and a manual approval on each environment.. A multi-stage YAML pipeline with one environment per region and a manual approval check on each environment provides the phased rollout with approval gates while keeping stage definitions DRY through templates or repeated environment references. Environments in Azure DevOps natively support approval checks, so no duplicated approval logic is needed. This satisfies the minimize-duplication requirement.

Answer

Create three separate stages (one per region) and duplicate the deployment tasks in each.

Answer

Use a single stage with parallel deployment to all regions and add manual approvals before each region's deployment.

Answer

Use a single stage with a deployment group job that targets agents tagged with region names, and use deployment group tags to control phased rollout.