AZ-400 Practice Test 35 — 15 Questions

Question 1

You are a DevOps engineer at a company that develops a cloud-based SaaS application. The application consists of multiple microservices, each stored in its own Git repository within a single Azure DevOps project. The team has grown rapidly, and developers frequently need to make changes that span multiple services. They often complain about the overhead of managing multiple pull requests and coordinating merges across repositories. To improve efficiency, the team lead suggests consolidating all microservices into a single monorepo. However, the lead architect is concerned about the impact on build times, as the CI pipeline currently builds each service independently. You are tasked with designing a source control strategy that reduces cross-repository coordination overhead while maintaining fast, independent builds. You propose using a monorepo with a structure that allows selective building. Which approach should you recommend?

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

Accepted Answer

Create a single monorepo with a build pipeline that uses path filters to trigger builds only for changed services. Using a single monorepo with path filters in the build pipeline allows you to trigger builds only for the microservices that have changed, reducing cross-repository coordination overhead while maintaining fast, independent builds. Path filters in Azure Pipelines (e.g., `paths` in YAML) enable selective triggering based on file paths, so unchanged services are not rebuilt, preserving CI efficiency.

Answer

Keep separate repositories but create a meta-repo that references them as submodules

Answer

Keep separate repositories but use Git submodules to share code

Answer

Create a single monorepo with all services and a single build pipeline that builds everything

Question 2

Refer to the exhibit. The pipeline uses a variable group 'ReleaseVariables' that contains a variable named 'EnvironmentName' with value 'Staging'. What environment will the deployment target?

Accepted Answer

Production. The pipeline uses a variable group 'ReleaseVariables' with a variable 'EnvironmentName' set to 'Staging', but the deployment job's environment field is explicitly set to 'Production' (as shown in the exhibit). Variable groups are used for sharing values across pipelines, but they do not override the environment specified directly in the YAML job definition. Therefore, the deployment target is 'Production'.

Answer

Staging

Answer

VirtualMachine

Answer

DeployWeb

Question 3

Your team uses GitHub for source control and Azure Pipelines for CI/CD. You need to trigger a pipeline automatically when a pull request is created against the main branch. Which trigger type should you configure in the YAML pipeline?

Accepted Answer

pr:. The `pr:` trigger in Azure Pipelines YAML is specifically designed to automatically start a pipeline when a pull request is created or updated against a specified branch. By default, `pr:` triggers are enabled for all branches; however, to ensure the pipeline only runs for PRs targeting `main`, you configure `pr: main`. This triggers the pipeline on PR creation/update without needing a separate branch policy.

Answer

trigger:

Answer

schedules:

Answer

resources:

Question 4

Your build pipeline uses a YAML template that references variables from a variable group. The variable group is linked to a library. You need to ensure that sensitive variables are not exposed in logs. Which THREE actions should you take?

Accepted Answer

Store the secrets in Azure Key Vault and reference them in the variable group.. To keep sensitive variables out of pipeline logs, you should store secrets in Azure Key Vault and reference them in a variable group (B), mark variables as secret in the variable group (D), and configure permissions on the library to restrict which pipelines can use the variable group (E). Key Vault integration and secret marking ensure that values are masked automatically, while restricting access limits the risk of unauthorized pipelines that could expose secrets.

Answer

Set the variable group to 'Allow access to all pipelines'.

Answer

Use 'Write-Host' to output the variable values for debugging.

Question 5

Your organization uses Azure Pipelines with Microsoft-hosted agents. The pipeline runs a .NET Core application build. You notice that the build takes longer than expected. Which THREE actions can you take to improve build performance? (Choose three.)

Accepted Answer

Enable caching for NuGet packages.. Enabling NuGet package caching reduces build time by avoiding repeated downloads of packages. Using a self-hosted agent with pre-installed dependencies eliminates the need to install and download tools on each run, further reducing overhead. Additionally, structuring the pipeline as a multi-stage build and running tests in parallel across multiple agents can significantly shorten overall pipeline duration by executing independent test suites concurrently. Together, these optimizations improve build performance.

Answer

Add more build steps to the pipeline.

Answer

Increase the number of parallel jobs in the pipeline.

Question 6

Your Azure DevOps pipeline uses a self-hosted agent pool. You notice that builds are queuing for a long time. What is the most effective way to reduce queue times without incurring additional costs?

Accepted Answer

Allocate more parallel jobs to the agent pool.. Allocating more parallel jobs to the self-hosted agent pool allows multiple pipelines or jobs to run concurrently, directly reducing queue times. This is achieved by adjusting the parallelism setting in the agent pool's properties, which does not incur additional costs as you are already paying for the self-hosted infrastructure.

Answer

Reduce the number of steps in the pipeline.

Answer

Increase the agent specification (e.g., from DS2 to DS4).

Answer

Switch to Microsoft-hosted agents to get more parallelism.

Question 7

Your team wants to include a manual validation step before deploying to production. Which Azure Pipelines feature should they use?

Accepted Answer

Pre-deployment conditions with approval gates.. Pre-deployment conditions with approval gates allow you to require manual approval before a release is deployed to a specific stage, such as production. This is the correct feature because it explicitly pauses the pipeline before deployment and waits for designated approvers to validate the build, meeting the requirement for a manual validation step. Environment checks are a broader feature that can include both automated checks and manual approvals; however, the specific configuration for requiring manual approval in a release pipeline is pre-deployment conditions with approval gates.

Answer

Pipeline decorators.

Answer

Environment checks.

Answer

Post-deployment gates.

Question 8

Which THREE of the following are valid steps to implement a trunk-based development workflow in Azure Repos? (Select THREE.)

Accepted Answer

Run CI builds on the main branch.. Trunk-based development requires developers to integrate into the main branch frequently. In Azure Repos, you set a CI trigger on main so every commit is built and validated (A). Developers use short-lived feature branches that are merged into main within a day (D) to keep integration conflicts small. Feature flags and pair programming are supporting practices that allow work to be integrated even before a feature is complete, avoiding long-running branches (B). Merging to main only once per week (C) contradicts the continuous-integration principle, and creating a release branch for every production release (E) is characteristic of GitFlow/release-flow, not trunk-based development.

Answer

Merge to main only once per week.

Answer

Create release branches for each production release.

Question 9

You run the PowerShell command shown in the exhibit. The virtual network already exists. What is the outcome?

Accepted Answer

The virtual network's tags are updated to the specified tags.. The `New-AzResource` cmdlet can create a new resource or update an existing resource. If the virtual network already exists, the cmdlet updates it, including applying the specified tags. The `-Force` parameter suppresses confirmation prompts and does not determine create vs. update behavior.

Answer

The virtual network is deleted and recreated.

Answer

An error occurs because the virtual network already exists.

Answer

A new virtual network with a different name is created.

Question 10

Which TWO are valid strategies for managing secrets in Azure Pipelines?

Accepted Answer

Use a variable group linked to Azure Key Vault and mark variables as secret.. Linking a variable group to Azure Key Vault allows secrets to be securely referenced without exposing them in plaintext; when variables are marked as secret, Azure Pipelines masks their values in logs. Alternatively, the Azure Key Vault task can fetch secrets at runtime and map them to pipeline variables for use in tasks, which also keeps secrets out of YAML and logs. Both approaches are valid strategies for secret management.

Answer

Store secrets in plain text in a variable group.

Answer

Store secrets in a Git repository and read them during build.

Answer

Embed secrets directly in the pipeline YAML file.

Question 11

Your team uses GitHub Flow. A developer pushes a feature branch to origin and creates a pull request to main. After review and approval, the pull request is merged. Which branch should the developer delete after the merge to maintain a clean repository?

Accepted Answer

Delete the feature branch. In GitHub Flow, feature branches are temporary and should be deleted after their pull request is merged into main. Deleting the feature branch keeps the repository clean by removing stale branches that are no longer needed, reducing clutter and preventing confusion. This practice aligns with the principle of short-lived branches in trunk-based development workflows.

Answer

Keep both branches indefinitely

Answer

Delete the main branch

Answer

Delete the remote main branch and recreate it

Question 12

Your Azure DevOps pipeline uses a variable group to store secrets. The variable group is linked to a Key Vault. You need to use a secret variable in a pipeline task. How should you reference the secret in the YAML pipeline?

Accepted Answer

Reference the variable as $(VariableName) in the pipeline tasks.. When a variable group is linked to an Azure Key Vault, secret variables are automatically available in the pipeline. You can reference them directly using the standard $(VariableName) syntax in any pipeline task. No special task or script is required. Option A is incorrect because you do not need to restrict to script tasks or use 'env' mapping; the $(VariableName) works everywhere. Option B is incorrect because 'task.getVariable' is a scripting method used within tasks, not a YAML syntax. Option D is incorrect because the Azure Key Vault task is unnecessary; the variable group handles the retrieval automatically.

Answer

Reference the variable as $(VariableName) but only in a script task using 'env' mapping.

Answer

Use the 'task.getVariable' method in a PowerShell script.

Answer

Use the Azure Key Vault task to retrieve the secret and then reference the output variable.

Question 13

Which TWO approaches can you use to enforce consistent commit message formatting across your organization? (Choose two.)

Accepted Answer

Use a pre-receive hook in GitHub to validate commit messages. GitHub's pre-receive hooks are server-side scripts that execute on the repository before accepting a push, allowing you to enforce commit message format validation across all contributors. Similarly, Azure Repos branch policies can include a commit message pattern check, which validates commit messages against a regex and rejects pushes with non-conforming messages. Both approaches enforce the standard on the server side, regardless of local client configurations.

Answer

Use a GitHub workflow that checks PR titles

Answer

Provide a commit message template to developers

Answer

Use Git hooks only on client side

Question 14

Your company uses GitHub Actions for CI/CD. The development team wants to automatically create a new GitHub release with release notes whenever a pull request is merged to the main branch. The release notes should include a list of all merged pull requests since the last release. You need to implement this automation. What should you do?

Accepted Answer

Add a workflow triggered on push to main that uses the 'softprops/action-gh-release' action to create a release with auto-generated release notes.. The 'softprops/action-gh-release' action can create a release and, when configured with `generate_release_notes: true`, generates release notes from merged PRs. Option B is incorrect because requiring a release note file via branch protection does not create a GitHub release. Option C is incorrect because GitHub does not automatically create releases from tags; a release must be created explicitly. Option D is incorrect because `gh release create` alone does not automatically generate release notes from merged PRs; it requires a manually constructed changelog.

Answer

Configure a branch protection rule to require a release note file in each pull request.

Answer

Use a workflow that runs on pull request merge and creates a Git tag, then rely on GitHub to create a release from the tag.

Answer

Add a step to the existing CI workflow that runs 'gh release create' with a changelog.

Question 15

Your pipeline uses the DotNetCoreCLI task to build a .NET Core application. You need to ensure that the build produces a self-contained deployment (SCD) for a Linux target. Which argument should you pass to the 'arguments' input of the task?

Accepted Answer

--runtime linux-x64. The --runtime argument specifies the target runtime (linux-x64) and produces a self-contained deployment. Option A is wrong because --configuration specifies the build configuration, not the runtime. Option C is wrong because --output specifies the output directory, not the runtime. Option D is wrong because while --self-contained true is a valid argument, it does not specify the target runtime; to target Linux specifically, you must use --runtime linux-x64 (which implies self-contained) or combine --runtime with --self-contained true.

Answer

--configuration Release

Answer

--output $(Build.ArtifactStagingDirectory)

Answer

--self-contained true