AZ-400 Practice Test 13 — 15 Questions

Question 1

You have a GitHub repository with a GitHub Actions workflow that builds a .NET application. The workflow should only run when changes are pushed to the main branch, but it currently runs on every push to any branch. How should you fix the workflow trigger?

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

Accepted Answer

Add 'on: push: branches: [main]' to the workflow.. The GitHub Actions workflow syntax to restrict a push trigger to a specific branch uses `on: push: branches: [main]`. This ensures the workflow only executes when commits are pushed to the main branch, not on pushes to any other branch.

Answer

Add 'on: push: branch: [main]' to the workflow.

Answer

Add 'on: push: paths: [main]' to the workflow.

Answer

Add 'on: pull_request: branches: [main]' to the workflow.

Question 2

A company uses Microsoft Entra ID for identity. They want to enforce that all code changes in Azure Repos require a linked work item and a successful policy evaluation. Which branch policy should they configure?

Accepted Answer

Require work item linking in the branch policy.. Requiring work item linking in the branch policy ensures that every pull request (PR) in Azure Repos must be associated with a work item (e.g., user story, bug) before it can be completed. Combined with a successful policy evaluation (e.g., build validation, required reviewers), this enforces traceability and compliance for all code changes.

Answer

Set the merge strategy to squash merge.

Answer

Enable 'Automatically include reviewers'.

Answer

Enforce a minimum number of comments.

Question 3

Your release pipeline deploys to Azure App Service using a deployment slot. You need to ensure that after swapping slots, the staging slot retains the previous production configuration for rollback. Which deployment strategy should you use?

Accepted Answer

Swap with preview. Swap with preview (multi-phase swap) is the correct strategy because it uses Azure App Service deployment slots to validate the staged version before completing the swap. When the swap is completed, the staging slot receives the previous production code and configuration, preserving a rollback state. If a problem occurs, you can swap back to the staging slot. Note that a standard slot swap also preserves the previous production state in staging, but swap with preview adds the benefit of preview validation before finalizing the swap, which aligns with the requirement of maintaining rollback capability.

Answer

Rolling deployment

Answer

Blue-green deployment

Answer

Canary deployment

Question 4

You have the YAML pipeline shown in the exhibit. What will be the output of the script in the Deploy stage?

Accepted Answer

Deploying to prod. The YAML pipeline defines a variable `environment` at the stage level with the value `prod`. The script in the Deploy stage references `$(environment)`, which resolves to `prod`, so the output is `Deploying to prod`. Stage-level variables override any pipeline-level or default variables for that stage.

Answer

The Deploy stage will be skipped

Answer

Deploying to dev

Answer

The script will fail because variable is not defined

Question 5

Your team uses feature flags to manage feature releases. You need to ensure that a feature flag is automatically turned off for all users except the development team after a production incident. What is the best approach?

Accepted Answer

Use a feature management system like Azure App Configuration with a targeting filter to enable only for the dev team.. Azure App Configuration's feature management system provides a built-in targeting filter that allows you to dynamically enable a feature flag for specific users or groups (e.g., the development team) while disabling it for all others. This approach supports real-time, no-deployment changes, which is essential for quickly responding to a production incident without modifying code or redeploying.

Answer

Create a separate branch with the feature disabled and deploy it.

Answer

Set an environment variable in the production environment to disable the feature.

Answer

Manually toggle the feature flag off in the app configuration.

Question 6

Refer to the exhibit. You have an Azure Pipelines YAML file for a .NET Core application. The pipeline is triggered on changes to the main branch, but only for files under src/. After a push to main that modifies a file in src/, the pipeline does not start. What is the most likely reason?

Accepted Answer

The path filter 'src/*' does not match files in subdirectories of src/.. The path filter `src/*` uses a single asterisk, which only matches files directly within the `src/` directory, not files in subdirectories (e.g., `src/app/main.cs`). Azure Pipelines path filters require a double asterisk `src/**` to recursively match all files under `src/`. Since the modified file is in a subdirectory, the trigger condition is not met, and the pipeline does not start.

Answer

The branch filter is missing the 'refs/heads/' prefix.

Answer

The trigger configuration has a syntax error: 'include' should be 'includes'.

Answer

The variable 'buildConfiguration' is not defined at the top level.

Question 7

You run the Azure CLI command shown in the exhibit. What is the output?

Accepted Answer

A table showing VM names and resource groups for VMs in eastus. The Azure CLI command `az vm list --query "[?location=='eastus'].{Name:name, ResourceGroup:resourceGroup}" --output table` filters virtual machines to only those in the 'eastus' location, then projects the 'name' and 'resourceGroup' properties into a table. The `--query` parameter uses JMESPath syntax, which is correct here, and the `--output table` formats the result as a table. Therefore, the output is a table showing VM names and resource groups for VMs in eastus.

Answer

An error because the query syntax is incorrect

Answer

A list of all VMs in the subscription

Answer

A list of all VMs in the westus location

Question 8

You are designing a pipeline to build a .NET Core application. The build must run unit tests and publish code coverage results. Which task should you use to publish the code coverage results to Azure DevOps?

Accepted Answer

Use the 'PublishCodeCoverageResults@1' task.. The 'PublishCodeCoverageResults@1' task is the correct choice because it is specifically designed to publish code coverage results (e.g., Cobertura or JaCoCo XML reports) to Azure DevOps, making them visible in the build summary and pipeline artifacts. This task consumes the coverage data file generated by a previous test run (e.g., via 'DotNetCoreCLI@2' with '--collect "Code Coverage"') and uploads it to the Azure DevOps service for reporting.

Answer

Use the 'PublishTestResults@2' task.

Answer

Use the 'DotNetCoreCLI@2' task with the 'test' command.

Answer

Use the 'VSTest@2' task with the 'codeCoverageEnabled' option.

Question 9

Your team needs to automatically run a pipeline whenever a pull request is created in GitHub. Which trigger should you configure in Azure Pipelines?

Accepted Answer

Pull request trigger. Azure Pipelines provides a dedicated pull request trigger that automatically starts a pipeline when a pull request is created or updated in GitHub. This trigger validates proposed changes before merging, ensuring code quality and preventing broken builds from entering the main branch.

Answer

Pipeline completion trigger

Answer

Scheduled trigger

Answer

Continuous integration trigger

Question 10

Your team uses a multi-stage YAML pipeline. The 'Build' stage compiles the code and runs unit tests. The 'Deploy' stage deploys to a staging environment. You notice that if the 'Build' stage fails, the 'Deploy' stage still starts because it depends on a condition that always evaluates to true. How should you modify the pipeline to prevent the 'Deploy' stage from running if the 'Build' stage fails?

Accepted Answer

Add 'condition: succeeded()' to the Deploy stage.. The `succeeded()` function in Azure Pipelines evaluates whether all previous stages (or jobs, depending on context) have completed successfully. By adding `condition: succeeded()` to the Deploy stage, the stage will only run if the Build stage (its implicit or explicit dependency) succeeded. This directly prevents the Deploy stage from starting when the Build stage fails.

Answer

Add 'condition: eq(variables['Build.Succeeded'], 'true')' to the Deploy stage.

Answer

Add 'condition: and(succeeded(), eq(variables['Build.Succeeded'], 'true'))' to the Deploy stage.

Answer

Add 'dependsOn: Build' to the Deploy stage.

Question 11

You are designing a multi-stage YAML pipeline in Azure DevOps that builds, tests, and deploys a .NET Core application. The pipeline must use a self-hosted agent pool for compliance. You need to minimize agent idle time while ensuring that the agent is always available for builds. What should you do?

Accepted Answer

Deploy a scale set agent pool with autoscaling enabled. A scale set agent pool with autoscaling enabled dynamically provisions and deprovisions Azure virtual machines based on the pipeline's demand, minimizing idle time while ensuring agents are available when builds are triggered. This approach aligns with the requirement for a self-hosted agent pool for compliance and optimizes cost by scaling down when no jobs are pending.

Answer

Provision a virtual machine scale set with a fixed number of agents

Answer

Install multiple agents on a single VM to maximize utilization

Answer

Use a single persistent agent and queue builds when idle

Question 12

Your team uses GitHub and wants to enforce that all commits to the main branch are signed with a GPG key. Which branch protection rule should you configure?

Accepted Answer

Require signed commits.. The 'Require signed commits' branch protection rule enforces that every commit pushed to the protected branch must be signed with a GPG key. This ensures cryptographic verification of the commit author's identity, directly addressing the requirement to enforce signed commits on the main branch.

Answer

Require pull request reviews before merging.

Answer

Require status checks to pass before merging.

Answer

Require linear history.

Question 13

Your build pipeline fails intermittently with the error: 'The job running on agent 'Azure Pipelines' exceeded the maximum execution time of 60 minutes.' How can you resolve this issue?

Accepted Answer

Increase the 'timeoutInMinutes' property in the pipeline YAML for the job.. The error indicates the job exceeded the default 60-minute timeout for Azure Pipelines hosted agents. Increasing the 'timeoutInMinutes' property in the pipeline YAML for the job explicitly extends the maximum execution time, directly resolving the timeout issue. This property can be set at the job level to allow longer-running tasks without changing the pipeline structure.

Answer

Split the pipeline into multiple stages to reduce job duration.

Answer

Enable parallel jobs to run the pipeline faster.

Answer

Use a self-hosted agent with more CPU cores.

Question 14

Your team uses GitHub Actions for CI/CD. You need to ensure that secrets are not exposed in build logs. What should you use?

Accepted Answer

GitHub Secrets. GitHub Secrets (Option C) is the correct choice because GitHub Actions provides a built-in encrypted secrets store that automatically masks secret values in build logs. When you reference a secret using `${{ secrets.MY_SECRET }}`, GitHub ensures the value is never printed or exposed in workflow output, unlike plaintext or environment variables that can be inadvertently logged.

Answer

Hardcoded values in the workflow YAML

Answer

Environment variables in the workflow

Answer

Artifact storage

Question 15

Your team wants to automatically assign a code reviewer from a specific security group when a pull request modifies files in a 'security' folder. Which Azure DevOps feature should you use?

Accepted Answer

Add a required reviewer policy for the branch.. Azure DevOps branch policies include a 'Required reviewers' policy that can be configured with a path filter. By specifying the path 'security' and adding the security group as required reviewers, the system will automatically add those reviewers to any pull request that modifies files in that folder. This is the built-in feature designed for this scenario. A CODEOWNERS file can also suggest reviewers based on file paths, but it is not a branch policy and does not enforce that the review must occur.

Answer

Enable 'Automatically approve' for security group.

Answer

Code ownership policy with automatic reviewer assignment.

Answer

Branch policy with minimum number of reviewers.