AZ-400 Practice Questions 1 — 50 Questions

Question 1

Which THREE factors should you consider when designing a release pipeline for a critical production application? (Choose three.)

Accepted Answer

Rollback strategy. A release pipeline for a critical production application must include a rollback strategy (e.g., deployment slots or redeploying a previous artifact) to recover quickly from failed releases, deployment health monitoring (e.g., Application Insights, Azure Monitor) to detect issues early and trigger rollbacks or alerts, and approval gates before production deployment to ensure manual or automated checks are passed. These three factors together minimize downtime and ensure controlled, safe releases.

Answer

Use of service principal with least privilege

Answer

Single environment deployment

Question 2

Drag and drop the steps to implement a branch policy in Azure Repos for pull requests into the correct order.

Accepted Answer

Step 1: Access the repository settings. Step 2: Select the branch for which to configure the policy. Step 3: Add policy requirements (e.g., minimum reviewers, linked work items). Step 4: Save the policy.. Branch policies are set by accessing repo settings, selecting branch, adding requirements, and saving.

Answer

Step 1: Select the branch. Step 2: Add policy requirements. Step 3: Access the repository settings. Step 4: Save the policy.

Answer

Step 1: Access the repository settings. Step 2: Add policy requirements. Step 3: Select the branch. Step 4: Save the policy.

Answer

Step 1: Access the repository settings. Step 2: Select the branch. Step 3: Save the policy. Step 4: Add policy requirements.

Question 3

Your team uses Azure Pipelines to build and test code. You want to automatically trigger a pipeline when a pull request is created targeting the main branch. Which trigger should you configure?

Accepted Answer

PR trigger. A PR trigger is the correct choice because Azure Pipelines supports a 'pr' trigger that automatically starts a pipeline when a pull request is created targeting a specified branch (e.g., main). This is distinct from a CI trigger, which runs on commits to a branch, and is essential for validating changes before merging.

Answer

Scheduled trigger

Answer

CI trigger

Answer

Manual trigger

Question 4

You are designing a release pipeline that must deploy to multiple environments in sequence: Dev, Test, and Prod. Each environment requires manual approval before deployment. You want to minimize the number of approvals while ensuring that Prod is never deployed without approval. What should you do?

Accepted Answer

Add a pre-deployment approval only to the Prod environment.. Configuring a pre-deployment approval only on the Prod environment ensures that Prod deployments are gated by manual approval, while Dev and Test deploy automatically. This reduces the total number of approvals to one per release, meeting the requirement to minimize approvals and protect Prod. It is the most efficient approach for sequential environments.

Answer

Use a single approval for all environments by adding an approval to the pipeline.

Answer

Add a post-deployment approval to the Test environment.

Answer

Add a pre-deployment approval to each environment.

Question 5

Your Azure Pipelines build takes 45 minutes. You want to reduce build time by caching dependencies. Which task should you add to the pipeline?

Accepted Answer

Cache@2. Cache@2 is the correct task because it allows you to cache dependencies (e.g., npm packages, Maven artifacts) between pipeline runs, significantly reducing build time by avoiding re-downloading unchanged dependencies. This task stores and restores a cache keyed by a hash of the dependency files, enabling incremental builds.

Answer

PublishBuildArtifacts@1

Answer

CopyFiles@2

Answer

DownloadBuildArtifacts@0

Question 6

You are setting up a GitHub Actions workflow to deploy an Azure Resource Manager (ARM) template. The workflow must run whenever a pull request is opened against the main branch. Which trigger should you use?

Accepted Answer

pull_request: branches: [main] types: [opened]. The `pull_request` trigger with `branches: [main]` and `types: [opened]` ensures the workflow runs only when a pull request targeting the `main` branch is newly opened. This is the correct trigger for the stated requirement. Note that `pull_request` events from forks run with limited permissions and do not have access to repository secrets by default, which is a safety measure. If secrets are required for deployment, additional configuration such as using `pull_request_target` (with caution) or environment-scoped secrets would be necessary, but the trigger itself remains `pull_request`.

Answer

pull_request_target: branches: [main]

Answer

workflow_dispatch

Answer

push: branches: [main]

Question 7

Your team uses GitHub Actions for CI/CD. You want to reuse a workflow across multiple repositories without duplicating code. Which approach should you use?

Accepted Answer

Create a reusable workflow in a central repository and reference it using 'uses: owner/repo/.github/workflows/workflow.yml@ref'.. GitHub Actions supports reusable workflows that allow you to define a workflow in a central repository and reference it from other repositories using the 'uses' syntax with the format 'owner/repo/.github/workflows/workflow.yml@ref'. This eliminates code duplication while maintaining a single source of truth for the workflow logic, and the referenced workflow can be triggered by events in the caller repository.

Answer

Store the workflow in a shared repository and use environment secrets to share credentials.

Answer

Create a composite action and reference it from each workflow.

Answer

Create a workflow template in the organization's .github repository.

Question 8

You are designing a release pipeline that deploys to multiple environments (dev, test, prod) with approval gates between each. You need to ensure that the same build artifact is deployed to all environments. Which strategy should you use?

Accepted Answer

Use a single build pipeline and promote the same build artifact through each environment.. Promoting the same build artifact through each environment ensures consistency and traceability. In Azure Pipelines, a single build produces one immutable artifact; deploying that same artifact across dev, test, and prod eliminates the risk of environment-specific build variations. Approval gates between stages control the promotion, while the artifact remains unchanged.

Answer

Use a multi-stage YAML pipeline with a separate artifact for each stage.

Answer

Create a separate build pipeline for each environment to ensure environment-specific configurations.

Answer

Use a single build pipeline but trigger a new build for each environment.

Question 9

Your organization uses Azure DevOps for a multi-tier web application. The application consists of a React frontend, a Node.js API, and a SQL database. The security team has mandated the following: (1) All code changes must be scanned for secrets before merging to the main branch. (2) Infrastructure-as-code templates (ARM) must be validated for security compliance before deployment. (3) Production deployments must use a service connection with a managed identity that has only the required permissions. You have set up a CI/CD pipeline with two stages: Build and Release. The Build stage runs on pull requests and the Release stage deploys to a production environment. Recently, a developer accidentally committed a secret (API key) to a configuration file. The secret was not caught by the pipeline, and the code was merged to main. You need to prevent this in the future. What should you do?

Accepted Answer

Add a 'Credential Scanner' task to the Build pipeline and configure it to fail the build if any secrets are found. Also, move all secrets to Azure Key Vault and reference them via variable groups.. It directly addresses the root cause: secrets were not being scanned before merge. The Credential Scanner task (part of Microsoft Security Code Analysis) scans for hardcoded secrets and can fail the build, preventing the merge. Moving secrets to Azure Key Vault and referencing them via variable groups (linked to the vault) ensures secrets are never stored in the repository, eliminating the risk of accidental commits.

Answer

Configure a branch policy to require at least two reviewers on pull requests to the main branch.

Answer

Implement a manual approval gate on the Release stage to review each deployment for secrets.

Answer

Use a pipeline decorator to inject a validation step that runs Azure Policy on the code repository.

Question 10

Refer to the exhibit. The JSON above shows a branch policy configuration for the main branch in Azure Repos. A developer pushes a third commit to an existing pull request after two reviewers have already approved. What happens?

Accepted Answer

The existing approvals remain valid because dismiss_stale_reviews is false.. In Azure Repos, the 'Block on last push' policy (require_last_push_approval) only revokes an approval from the user who made the most recent push, preventing them from approving their own changes. It does not invalidate approvals from other reviewers. The setting that resets all approvals when new commits are pushed is 'Reset code reviewer votes when there are new changes' (dismiss_stale_reviews). Since dismiss_stale_reviews is false in the given configuration, the two existing approvals remain valid when the developer pushes a third commit.

Answer

The pull request is automatically merged because allowed merge types include squash.

Answer

The approvals are dismissed because require_last_push_approval is true.

Answer

The pull request is blocked because the merge type is not allowed.

Question 11

Your release pipeline deploys to multiple environments (Dev, Test, Prod) using approval gates. Recently, the Prod deployment failed because a manual validation task timed out after 30 minutes. You need to ensure that if the manual validation is not approved within 15 minutes, the pipeline automatically rejects the deployment and sends a notification. What should you do?

Accepted Answer

In the Manual Validation task, set 'Timeout' to 15 and 'On timeout' to 'Reject'.. The Manual Validation task has a 'Timeout' setting and an 'On timeout' option. Setting Timeout to 15 minutes and On timeout to 'Reject' will automatically reject the deployment if not approved within 15 minutes. Additionally, you can configure a notification using an Azure DevOps subscription or service hook for the rejection event. Option A is incorrect because the stage timeout does not specifically handle manual validation rejection. Option C is incorrect because, although pre-deployment approvals do have a timeout that can reject on timeout, they apply to the approval gate before the stage, not to a manual validation task within the stage. Option D is incorrect because adding a PowerShell task is unnecessary and less reliable than the built-in timeout behavior.

Answer

Set the 'Timeout in minutes' for the entire stage to 15.

Answer

Configure a pre-deployment approval with a timeout of 15 minutes.

Answer

Add a PowerShell task after the manual validation that checks the status and cancels the pipeline if not approved.

Question 12

Your organization uses GitHub Actions for CI/CD. You need to ensure that deployment to production only occurs after a successful deployment to a staging environment and requires approval from a senior developer. The deployment workflow is defined in a single YAML file. What is the most efficient way to achieve this?

Accepted Answer

Use two environments (staging and production) with required reviewers on the production environment, and use conditional steps to deploy to staging first.. GitHub Actions supports deployment environments with required reviewers. By defining separate 'staging' and 'production' environments, you can use a conditional step to deploy to staging first, and then require manual approval from a senior developer before the production deployment proceeds. This approach is built into GitHub Actions and does not require external webhooks or manual workflow triggers, making it the most efficient and secure method.

Answer

Add a step that pauses the pipeline until a manual approval is received via a custom webhook.

Answer

Use a workflow_dispatch trigger and require the senior developer to manually run the production deployment.

Answer

Use a build matrix to run staging and production deployments in parallel.

Question 13

Your team is designing a build pipeline for a Java application that uses Maven. The pipeline must run unit tests and integration tests separately, and fail the build if integration tests fail. However, integration tests require a running database container. Which approach should you use to ensure the database is available for the integration tests?

Accepted Answer

Use a Docker Compose task in the pipeline to start the database container before running integration tests.. Docker Compose allows you to define and start a database container as a dependency before running integration tests in a build pipeline. By using a Docker Compose task, you can ensure the database container is running in a clean, isolated environment, and the pipeline can fail the build if the integration tests fail. This approach is ideal for CI/CD pipelines where ephemeral, disposable infrastructure is needed for testing.

Answer

Configure the pipeline to use a self-hosted agent that has the database already installed and running.

Answer

Install the database as a service in the pipeline using the Service Fabric task.

Answer

Use a PowerShell script in the pipeline to install and start the database on the build agent.

Question 14

Your team is migrating from TFVC to Git in Azure Repos. Developers frequently work on the same files simultaneously. Which Git workflow should you recommend to minimize merge conflicts?

Accepted Answer

Feature branch workflow. The feature branch workflow is ideal for minimizing merge conflicts when developers work on the same files simultaneously because each developer creates a short-lived branch off the main branch for their specific feature or fix, commits frequently, and merges back via pull requests. This isolates changes until they are ready, reducing the surface area for conflicts compared to long-lived branches. Git's merge or rebase strategies within this workflow allow for incremental conflict resolution, which is more manageable than resolving large conflicts from divergent histories.

Answer

GitFlow

Answer

Forking workflow

Answer

Centralized workflow

Question 15

You are designing a release pipeline that deploys a web app to Azure App Service. You need to ensure that configuration secrets (e.g., database connection strings) are not stored in the pipeline YAML file. Which approach should you use?

Accepted Answer

Use an Azure Key Vault variable group linked to the pipeline.. Azure Key Vault variable groups allow you to securely reference secrets stored in Azure Key Vault from within a pipeline without exposing them in the YAML file. The pipeline retrieves the secrets at runtime via a linked service connection, ensuring they never appear in source control or pipeline logs.

Answer

Define the secrets as agent-scoped variables in the release pipeline.

Answer

Hardcode the secrets in the App Service configuration and reference them in the pipeline.

Answer

Store the secrets as pipeline variables and mark them as 'Secret'.

Question 16

Your organization uses GitHub Actions for CI/CD. You want to enforce that all workflows pass required checks before a pull request can be merged. The repository is in an organization that uses GitHub Enterprise Cloud. What should you configure?

Accepted Answer

Add a branch protection rule that requires status checks to pass.. Branch protection rules in GitHub Enterprise Cloud allow you to require status checks to pass before merging a pull request. By configuring a branch protection rule on the target branch (e.g., main) and selecting the specific GitHub Actions workflow status checks that must succeed, you enforce that all required CI/CD checks pass before a merge is allowed. This directly meets the requirement to enforce workflow checks on pull requests.

Answer

Enable 'Require approval for all workflows' in the organization settings.

Answer

Set the workflow to be required in the 'Require status check' settings of each pull request.

Answer

Create a repository ruleset that requires linear history.

Question 17

Your build pipeline uses the 'NuGetCommand@2' task to restore NuGet packages. You want to use packages from an Azure Artifacts feed that requires authentication. How should you configure the pipeline to authenticate with the feed?

Accepted Answer

Add a 'NuGetAuthenticate@1' task before the NuGet restore task.. The 'NuGetAuthenticate@1' task is the correct way to authenticate with Azure Artifacts feeds in a pipeline because it automatically handles credential acquisition using the built-in Azure Artifacts credential provider. It works without needing to store or manage Personal Access Tokens (PATs) manually, and it integrates seamlessly with the pipeline's identity (e.g., the project collection build service). This task must be placed before the 'NuGetCommand@2' restore task to ensure the credentials are available for package restoration.

Answer

Store the Personal Access Token (PAT) in a variable and use it in the NuGet config.

Answer

Create an Azure Artifacts service connection and select it in the NuGet task.

Answer

Install the NuGet credential provider on the agent manually.

Question 18

Which TWO are benefits of using deployment groups in Azure Pipelines compared to using individual virtual machines?

Accepted Answer

Simplified targeting of multiple machines with a single pipeline run.. Option D is correct because deployment groups let a single pipeline job target a logical set of machines (defined by tags), so one pipeline run can deploy to many VMs without enumerating each machine individually. Option E is correct because deployment groups natively support rolling deployments, where the agent on each target machine runs the deployment steps and the pipeline can perform health checks and stop the rollout if a machine fails. Option A is not a deployment group feature; secrets such as connection strings are handled by Azure Key Vault, variable groups, or secret variables, not by deployment groups themselves. Option B is incorrect because deployment groups do not shut down VMs to save cost; they only orchestrate deployment to registered machines. Option C is incorrect because automatic VM scaling is provided by VM scale sets or autoscale settings, not by deployment groups.

Answer

Built-in secrets management for connection strings.

Answer

Reduced cost because VMs are shut down when not in use.

Answer

Automatic scaling of virtual machines based on load.

Question 19

Which THREE components are required to set up a self-hosted agent pool in Azure Pipelines?

Accepted Answer

The agent software installed on the target machine. To set up a self-hosted agent pool in Azure Pipelines, you must install the agent software on the target machine (option A), which provides the listener that polls Azure DevOps for jobs and runs them locally. You also need to configure the agent with the agent pool name and the URL of the Azure DevOps organization (option C), since the agent registers itself into a specific pool under a specific organization endpoint. Authentication requires a personal access token (option E) with the appropriate scope (typically Agent Pools read/manage), which the agent uses during configuration to register with the service. Option B is incorrect because deployment groups are a separate feature for classic release pipelines targeting machines, not the mechanism for creating an agent pool. Option D is incorrect because the Azure VM extension for Azure Pipelines Agent is an optional convenience for provisioning agents on Azure VMs, not a required component of a self-hosted agent pool.

Answer

A deployment group target

Answer

Azure VM extension for Azure Pipelines Agent

Question 20

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?

Accepted Answer

No trigger will start.. The YAML trigger configuration (shown) explicitly lists the branches that trigger CI. Since feature/new-feature is not included in the branch filter, a push to that branch does not start a CI run. PR triggers are separate and require an actual PR to be created, not a push.

Answer

A CI trigger will start because the branch name starts with 'feature/'.

Answer

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

Answer

A CI trigger will start for all branches because batch is set to true.