AZ-400 Timed Practice Test 2 — 10 Questions

Question 1

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?

10 minute time limit — choose an answer to begin.

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 2

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 3

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 4

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 5

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 6

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 7

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 8

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 9

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 10

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.