AZ-400 Practice Test 19 — 15 Questions

Question 1

Your release pipeline deploys to multiple Azure regions. You need to ensure that if a deployment to one region fails, the pipeline continues deploying to other regions. Which deployment strategy should you use?

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

Accepted Answer

Rolling deployment. Rolling deployment updates instances gradually across regions. If a deployment to one region fails, the pipeline can continue deploying to other regions because each region is updated independently. Option A (immutable deployment) replaces all instances at once, so a failure would halt the entire deployment. Option C (blue-green) switches all traffic to a new environment; if that environment fails, the whole deployment fails. Option D (canary) routes a small percentage of traffic to a new version and rolls back if issues occur, but it does not ensure continued deployment to other regions upon failure.

Answer

Immutable deployment

Answer

Blue-green deployment

Answer

Canary deployment

Question 2

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 Azure Container Registry name specified in the pipeline is incorrect or does not exist in the subscription. Option A is correct because the most likely cause is a misspelled or wrong registry name. Option B is incorrect because the build ID variable is unrelated to finding a registry resource. Option C is incorrect because permission issues typically result in authorization errors, not 'not found'. Option D is incorrect because Azure CLI availability does not affect resource lookup, and the error is about resource existence, not CLI installation.

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 3

You have a multi-stage YAML pipeline with stages: Build, Test, and Deploy. The Deploy stage requires approval from a specific user group. You want to ensure that the approval request is sent only after the Test stage completes successfully. Which configuration should you use?

Accepted Answer

Define an environment with required approvers and reference it in the Deploy stage.. Azure Pipelines environments allow you to define required approvers (user groups) that must approve a deployment before it proceeds. By referencing the environment in the Deploy stage, the approval request is automatically triggered only after the preceding Test stage completes successfully, since stages execute sequentially by default.

Answer

Add a manual validation task in the Deploy stage.

Answer

Use the 'condition' keyword: condition: eq(variables['Build.SourceBranch'], 'refs/heads/main')

Answer

Configure branch policies on the main branch.

Question 4

You are configuring a YAML build pipeline for a .NET Core application. Which task should you use to restore NuGet packages?

Accepted Answer

DotNetCoreCLI task with 'restore' command. The DotNetCoreCLI task with the 'restore' command is the recommended approach for restoring NuGet packages in a YAML build pipeline for a .NET Core application. It directly invokes 'dotnet restore', which is the native .NET CLI command that handles package restoration efficiently and integrates seamlessly with the .NET SDK, ensuring compatibility with project files and dependency resolution.

Answer

NuGetCommand task

Answer

PowerShell task with dotnet restore

Answer

NuGetAuthenticate task

Question 5

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.. GitHub Actions path filters (on: pull_request paths:) allow you to trigger workflows only when changes occur in specific directories. This ensures that only the microservices affected by a pull request are built and tested, reducing build times and resource usage. Option A is incorrect because building all services on every push is wasteful. Option B is incorrect because manual triggering via webhook comments defeats automation and is not scalable. Option C is incorrect because a matrix strategy, while useful for parallel builds, still triggers on every pull request and would build all services, not just the changed ones.

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 6

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.. For a phased rollout to multiple Azure App Service regions, you should create an environment per region and use a multi-stage YAML pipeline that contains deployment jobs (or stages) targeting those environments. Manual approval gates can be configured on each environment, enabling controlled progression from West US to East US to North Europe without duplicating tasks. This approach directly uses App Service slots and environments. Deployment group jobs (Option D) are intended for targeting on-premises or VM-based agents, not App Service instances, and do not support slots. Options B and C are incorrect because they duplicate tasks or deploy in parallel rather than in the required phased sequence.

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.

Question 7

You have a release pipeline that deploys to multiple stages. You want to ensure that a manual approval is required before deploying to the production stage. Which approach should you use?

Accepted Answer

Add a pre-deployment approval on the production stage.. Pre-deployment approvals in Azure Pipelines allow you to require manual sign-off before a release proceeds to a specific stage. By adding a pre-deployment approval on the production stage, the pipeline will pause and wait for designated approvers to approve the deployment, ensuring that no code reaches production without explicit authorization.

Answer

Add a post-deployment approval on the staging stage.

Answer

Configure a deployment gate with a manual intervention task.

Answer

Use a pipeline decorator to inject approval step.

Question 8

Your team uses Azure Pipelines to build a Node.js application. The build pipeline runs linting, unit tests, and creates a production build. You want to ensure that the pipeline fails if the test coverage drops below 80%. You need to implement this check. What should you do?

Accepted Answer

Add a 'Publish Test Results' task with code coverage enabled, then use a 'Script' task that reads the coverage report and fails if below 80%.. The 'Publish Test Results' task can publish code coverage reports, and a subsequent script task can parse the report (e.g., using a tool like c8 or nyc) and exit with a non-zero code if coverage is below 80%, causing the pipeline to fail. Option A is incorrect because a pipeline variable alone cannot enforce coverage thresholds; you need a task that checks the coverage. Option B is incorrect because branch policies can enforce code review requirements but not specific code coverage percentages from build results. Option C is incorrect because the 'Visual Studio Test' task is designed for .NET applications, not Node.js; it does not work with Node.js coverage reports.

Answer

Configure a pipeline variable 'CoverageThreshold' and use it in a gate.

Answer

Set a branch policy that requires code coverage to be at least 80%.

Answer

Use the 'Visual Studio Test' task with code coverage enabled and set the 'Minimum coverage' option.

Question 9

Which TWO actions should you take to ensure that your Azure DevOps pipeline securely manages secrets?

Accepted Answer

Use Azure Key Vault variable groups. Azure Key Vault variable groups securely store and manage secrets outside the pipeline definition, with access control and auditing. Option D is correct because secret variables set in the pipeline UI or variable groups are masked in logs and not exposed in the YAML file. Option B is incorrect: enabling script access to the system token and printing secrets in logs is a security risk. Option C is incorrect: storing secrets directly in the YAML pipeline file exposes them in the repository. Option E is incorrect: storing secrets as plain text in the repository is insecure.

Answer

Enable 'Allow scripts to access the system token' and print secrets in logs for debugging

Answer

Store secrets directly in the YAML pipeline file

Answer

Store secrets as plain text in the repository

Question 10

Which THREE practices are recommended for effective source control in a GitHub monorepo? (Choose three.)

Accepted Answer

Use branch protection rules to enforce CI checks. Branch protection rules (B) enforce required status checks like CI builds and tests before merging, maintaining stability in a monorepo with many contributors. Code owners (D) automatically request reviewers from the responsible teams for changes in their respective paths, ensuring proper review and accountability. Path filters (E) trigger only the CI workflows relevant to the changed code, avoiding unnecessary builds and reducing feedback loops. Storing large binaries in the repo (A) is poor practice, and a single build definition for all projects (C) is inefficient because it forces full builds on every change.

Answer

Store large binary files directly in the repository

Answer

Use a single build definition for all projects

Question 11

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.. Marking the alert as a false positive in the GitHub UI closes the alert and helps train the detection algorithm for future scans. Option A is incorrect because disabling secret scanning entirely would stop detection for all secrets, which is not appropriate for a single false positive. Option B is incorrect because deleting the PAT might be necessary if it were real, but since it's a false positive, it is unnecessary and could break functionality. Option D is incorrect because ignoring the alert leaves it open and does not resolve the false positive.

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 12

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.. Branch protection rules in GitHub can require status checks to pass before merging. You set up a rule that requires the CI workflow to succeed.

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 13

Your organization requires that all code changes be signed using a valid code signing certificate before they can be merged. Which feature in GitHub should you enable to enforce this?

Accepted Answer

Commit signature verification.. Commit signature verification in GitHub enforces that commits are signed with a verified GPG or S/MIME key, which meets the requirement of signing code changes. Option A is wrong because Dependabot handles dependency updates, not signature enforcement. Option C is wrong because code scanning analyzes code for vulnerabilities, not for commit signatures. Option D is wrong because secret scanning detects secrets in repositories, not signature enforcement.

Answer

Dependabot.

Answer

Code scanning.

Answer

Secret scanning.

Question 14

You run the above Azure CLI command to deploy a Bicep template. The deployment fails with 'The resource 'Microsoft.Storage/storageAccounts/mystgaccount' already exists'. What is the most likely cause?

Accepted Answer

The storage account 'mystgaccount' already exists in the resource group.. The error message 'The resource 'Microsoft.Storage/storageAccounts/mystgaccount' already exists' indicates that the storage account 'mystgaccount' already exists in the target resource group, which prevents the deployment from creating it again. This directly supports option A as the correct answer. Option B is incorrect because 'az deployment group validate' only validates the template and does not perform a deployment; the error occurs during the actual deployment, not validation. Option C is incorrect because Bicep defaults to incremental mode, not complete mode, and even if complete mode were used, the error would be about a resource existing in the template but not in the resource group, which is not the case here. Option D is incorrect because if the resource group did not exist, the error would be something like 'ResourceGroupNotFound', not an already-exists error.

Answer

The command should use 'az deployment group validate' instead.

Answer

The Bicep file uses 'complete' mode.

Answer

The resource group 'MyRG' does not exist.

Question 15

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. It uses path filters in the pipeline trigger to only run when files in the changed projects are modified, and a custom script detects dependencies between projects to also build any dependent projects. This minimizes build time while ensuring all affected projects are built. Option A builds all projects on every commit, which is inefficient. Option C only builds changed projects but ignores dependency chains, potentially breaking the build. Option D requires manual triggers, which is not automated and defeats the purpose of CI/CD.

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