AZ-400 Practice Test 46 — 15 Questions

Question 1

Your organization uses GitHub for source control. You need to enforce that all pull requests require at least one approval and that branches must be up to date with the base branch before merging. Which branch protection rule settings should you enable?

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

Accepted Answer

Require a pull request before merging and require branches to be up to date. GitHub branch protection rules allow you to enforce both that pull requests require at least one approval and that branches are up to date with the base branch before merging. The 'Require a pull request before merging' setting ensures that changes cannot be pushed directly to the protected branch and must go through a PR with required approvals. The 'Require branches to be up to date' setting (under 'Require status checks to pass before merging') ensures that the branch is tested against the latest base branch code, preventing stale merges.

Answer

Require branches to be up to date only

Answer

Require a pull request before merging only

Answer

Require status checks to pass before merging only

Question 2

You are designing a process for incident management. When a critical bug is reported, you need to automatically create a work item in Azure Boards and notify the on-call engineer via Microsoft Teams. Which Azure DevOps feature should you use?

Accepted Answer

Set up a service hook that sends a message to Teams when a bug is created.. Service hooks are used to notify external systems (like Microsoft Teams) when an event occurs in Azure DevOps, such as a work item being created. They do not create the work item itself; they react to its creation. To automatically create the work item when a critical bug is reported, you would use a separate mechanism such as the Azure Boards REST API or an external integration. Among the provided options, B is the correct feature for the Teams notification, but the explanation should clarify that the automated creation is handled outside the service hook.

Answer

Create a release pipeline that triggers on work item creation.

Answer

Configure a work item notification in Azure DevOps to email the on-call engineer.

Answer

Use a work item template to pre-populate the bug form.

Question 3

Your team uses Azure Pipelines to build a .NET application. You notice that the build takes 15 minutes because of dependency restoration. You want to cache the NuGet packages to speed up subsequent builds. Which task should you add to your pipeline?

Accepted Answer

Cache task with a key based on the package lock file. The Cache task (D) is the correct choice because it allows you to cache the NuGet packages folder (typically `~/.nuget/packages`) based on a key derived from the package lock file (e.g., `packages.lock.json`). This ensures that when the lock file hasn't changed, the cached packages are restored from the pipeline cache instead of being downloaded from the NuGet feed, significantly reducing build time. The key is computed from the lock file's content hash, so any change in dependencies automatically invalidates the cache.

Answer

DownloadBuildArtifacts task

Answer

NuGet restore task with the 'noCache' option set to false

Answer

DotNetCoreCLI task with the 'restore' command

Question 4

Your team uses GitHub Discussions for Q&A. You notice that many questions go unanswered. Which two actions can improve response rates? (Choose two.)

Accepted Answer

Create a template for new discussions to guide users.. Option C is correct because creating a discussion template guides users to provide complete, structured information (such as version, environment, and steps to reproduce), which makes questions easier to understand and answer, thereby improving response rates. Option D is correct because assigning a team of maintainers to monitor unanswered discussions ensures there is clear ownership and accountability for responding, directly reducing the number of questions that go unanswered. Option A is not appropriate because limiting discussions to a single category reduces organization and makes it harder for the right experts to find relevant questions. Option B is not appropriate because auto-closing unanswered discussions after 7 days would suppress legitimate questions rather than encourage answers. Option E is not appropriate because converting unanswered discussions to issues does not by itself increase response rates and may simply move the problem elsewhere.

Answer

Limit the number of discussion categories to one.

Answer

Automatically close discussions that are unanswered for 7 days.

Answer

Convert unanswered discussions to issues.

Question 5

Which THREE are required components to implement a secure CI/CD pipeline using Azure Pipelines and GitHub?

Accepted Answer

An Azure service connection to authenticate to Azure resources.. Option A is correct because an Azure service connection (a service principal or workload identity federation stored in Azure DevOps) is the mechanism Azure Pipelines uses to authenticate to Azure subscriptions and deploy resources securely without embedding credentials in code. Option C is correct because a YAML pipeline definition with stages and jobs is the declarative pipeline artifact that Azure Pipelines executes to build, test, and deploy code in a repeatable, version-controlled manner. Option E is correct because branch protection rules requiring status checks to pass prevent unreviewed or failing code from being merged, enforcing quality and security gates in the GitHub workflow. Option B is not required because a container registry is only needed when the pipeline builds and stores Docker images, which is not a universal requirement for a secure CI/CD pipeline. Option D is not required and is in fact insecure, since storing a GitHub personal access token as a plain text variable exposes the secret; tokens should be kept in Azure Key Vault or a secret variable group instead.

Answer

A container registry to store Docker images.

Answer

A GitHub personal access token stored as a plain text variable.

Question 6

Which TWO actions should you take to implement a gated deployment strategy in Azure Pipelines?

Accepted Answer

Use deployment gates to evaluate metrics like error rate before allowing the next stage.. Option A is correct because deployment gates in Azure Pipelines are precisely the mechanism that queries external sources—such as Azure Monitor alerts, REST APIs, or work items—to evaluate metrics like error rate and automatically decide whether the stage may proceed, which is the core of a gated deployment. Option E is correct because manual approval checks (approvals and checks configured on an environment or service connection) pause the pipeline before production deployment so a human can verify readiness, which is a standard gating control in a gated release strategy. Option B is not correct because a dashboard is a monitoring and visualization tool; it reports health but does not itself gate or block a pipeline stage. Option C is not correct because a multi-stage YAML pipeline is just the structural definition of stages and does not by itself implement gating logic. Option D is not correct because a rollback strategy is a recovery measure after a failed deployment, not a gate that controls whether deployment proceeds.

Answer

Configure a dashboard to monitor application health.

Answer

Use a multi-stage YAML pipeline.

Answer

Configure a rollback strategy if deployment fails.

Question 7

Which THREE measures should you implement to protect secrets used in GitHub Actions workflows? (Choose three.)

Accepted Answer

Enable secret scanning to detect secrets in code pushes.. Option B is correct because enabling secret scanning (including push protection) lets GitHub detect and block credentials committed to the repository, catching accidental leaks before they are exploited. Option D is correct because configuring OpenID Connect (OIDC) with a federated identity credential allows GitHub Actions to authenticate to Azure via short-lived tokens, eliminating the need to store long-lived cloud credentials as secrets. Option E is correct because storing values as GitHub repository secrets or organization secrets keeps them encrypted at rest, masks them in logs, and injects them only at runtime rather than exposing them in workflow files. Option A is wrong because hardcoding secrets in workflow YAML exposes them in plaintext to anyone with repository read access and in logs. Option C is wrong because reusing one secret across all environments removes isolation, so a compromise in a low-trust environment grants access to production.

Answer

Use hardcoded secrets in workflow files for simplicity.

Answer

Use the same secret across all environments to reduce management overhead.

Question 8

Your team uses Azure DevOps and needs to ensure that secrets are not exposed in pipeline logs. Which THREE practices should you implement?

Accepted Answer

Use logging commands to mask secrets in scripts. Option A is correct because Azure Pipelines supports the logging command `##vso[task.setsecret]value` (and the older `##vso[task.setvariable variable=name;issecret=true]`) to explicitly register a value with the agent so it is masked as `***` anywhere it appears in pipeline logs. Option C is correct because marking a variable as 'secret' in pipeline variables (via the UI lock icon or `issecret=true` in YAML) causes Azure DevOps to encrypt the value at rest and automatically mask it in logs. Option E is correct because Azure Key Vault stores secrets outside the pipeline definition and, when linked via a variable group or the `AzureKeyVault@2` task, the retrieved values are automatically treated as secrets and masked in logs, while also enforcing access control and rotation. Option B is not a real Azure DevOps feature — pipeline logs are not configured via a 'log encryption' toggle; masking is achieved through secret variables and logging commands. Option D is incorrect because storing secrets in plain YAML variable files commits them to the repository in cleartext, which is exactly the exposure the team must avoid.

Answer

Enable pipeline log encryption

Answer

Store secrets in YAML variable files

Question 9

Which THREE are benefits of using 'Environment' resources in YAML pipelines compared to classic release pipelines? (Choose three.)

Accepted Answer

Environments provide a dashboard showing the deployment history and resource health.. Option A is correct because Azure DevOps Environments provide a dedicated dashboard that surfaces deployment history and the health/status of the associated resources (VMs, Kubernetes, etc.), giving visibility that classic release pipelines lack in a unified view. Option C is correct because Environments support configurable checks such as approvals, business hours, and manual intervention, which gate pipeline stages before deployment proceeds. Option E is correct because an Environment can be backed by a Kubernetes resource, where the target can be a namespace, and the environment tracks the deployed versions/artifacts to that namespace. Option B is incorrect because Environments are designed for YAML pipelines, not classic release pipelines. Option D is incorrect because pre-deployment and post-deployment gates are a classic release pipeline feature, not a benefit of Environments in YAML pipelines.

Answer

Environments can only be used in classic release pipelines.

Answer

Environments allow you to define pre-deployment and post-deployment gates using the classic release pipeline interface.

Question 10

Your team uses GitFlow with Azure Repos. You need to ensure that every commit to the 'main' branch is built and deployed to production automatically. Which trigger should you configure in your YAML pipeline?

Accepted Answer

trigger:
  branches:
    include:
    - main. To automatically build and deploy on every commit to the 'main' branch, you need a CI trigger that includes the 'main' branch. The YAML snippet 'trigger: branches: include: - main' does exactly that. It tells Azure Pipelines to trigger a run whenever a commit is pushed to 'main'. Other options either disable triggers, schedule runs, or trigger on pull requests, none of which meet the requirement of automatic build on commit.

Answer

Trigger: none

Answer

schedules:
- cron: "0 0 * * *"
  branches:
    include:
    - main

Answer

pr:
  branches:
    include:
    - main

Question 11

A development team is implementing a distributed tracing solution for a microservices application deployed on Azure. They want to correlate requests across services using OpenTelemetry and send data to Azure Monitor. The application currently generates traces, but the traces are incomplete, showing only individual service spans without end-to-end correlation. The team has already instrumented each service with the OpenTelemetry SDK. What should the team do to ensure proper end-to-end trace correlation?

Accepted Answer

Implement context propagation by passing trace headers between services.. Distributed tracing requires propagating trace context (trace ID, span ID) across service boundaries via HTTP headers (e.g., W3C Trace-Context). Without context propagation, each service creates its own trace, resulting in disconnected spans. The OpenTelemetry SDK automatically handles propagation when configured, but the team must ensure that outgoing requests include the trace headers and incoming requests extract them.

Answer

Enable the Application Insights auto-instrumentation agent on the application host.

Answer

Configure the OpenTelemetry SDK to use the Azure Monitor exporter instead of the default exporter.

Answer

Set the same service name for all services in the OpenTelemetry configuration.

Question 12

Which TWO triggers can start a release in Azure Pipelines?

Accepted Answer

Schedule. Option B (Schedule) is correct because Azure Pipelines release pipelines support scheduled triggers, configured via the pipeline's Triggers tab or YAML scheduled triggers, which start a release at defined times (e.g., cron-based schedules). Option C (Build completion) is correct because a release can be triggered when a specified build (artifact source) completes successfully, using the build completion trigger that monitors a chosen build pipeline. Option A (Continuous integration) is not a release trigger in this context; CI triggers start builds, not releases (the release equivalent is the continuous deployment trigger on an artifact). Option D (Work item state change) is not a supported release trigger in Azure Pipelines. Option E (Pull request) is a build/CI trigger (PR triggers on branches), not a release trigger.

Answer

Continuous integration

Answer

Work item state change

Answer

Pull request

Question 13

Which THREE are valid security best practices for Azure Pipelines? (Choose three.)

Accepted Answer

Restrict agent pool permissions to only necessary users. Option A is correct because restricting agent pool permissions to only necessary users enforces least privilege, preventing unauthorized users from creating or modifying agents that could execute malicious pipeline jobs. Option B is correct because Microsoft Entra ID (formerly Azure AD) provides centralized identity and access control for Azure DevOps, enabling conditional access, MFA, and role-based assignments to secure pipeline access. Option D is correct because variable groups integrated with Azure Key Vault keep secrets out of YAML and pipeline definitions, retrieving them securely at runtime with proper access policies. Option C is not a best practice because storing secrets as plain text in YAML files exposes them to anyone with repository read access and to logs or history. Option E is not a best practice because running build agents on domain controllers violates the principle of least privilege and exposes critical identity infrastructure to pipeline workloads.

Answer

Store secrets as plain text in YAML files

Answer

Run build agents on domain controllers

Question 14

You are designing a build pipeline for a .NET Core application. The pipeline must run on a self-hosted agent in a private network without internet access. Which TWO actions are required to ensure the build can download NuGet packages?

Accepted Answer

Install the NuGet tool on the self-hosted agent machine.. Option B is correct because a self-hosted agent in an isolated network must have the NuGet client tooling installed locally, since the pipeline's NuGet restore tasks (e.g., NuGetCommand@2 or DotNetCoreCLI restore) rely on a NuGet executable or the .NET SDK's built-in restore capability being present on the agent machine to resolve and download packages. Option D is correct because with no internet access, the agent cannot reach nuget.org, so the pipeline must point NuGet at a reachable package source such as Azure Artifacts or an internal NuGet feed configured via NuGet.config or a service connection, allowing packages to be downloaded from inside the private network. Option A is wrong because disabling NuGet restore would prevent package download entirely, defeating the build's dependency resolution. Option C is wrong because switching to a Microsoft-hosted agent contradicts the requirement to run on a self-hosted agent in a private network and would not have access to internal feeds. Option E is wrong because NuGet Authenticate only supplies credentials for Azure Artifacts; authentication alone does not provide network reachability or a configured internal feed, so it is not sufficient (and not required) to enable package download in an offline network.

Answer

Disable the NuGet restore step in the pipeline.

Answer

Use a Microsoft-hosted agent instead.

Answer

Use the NuGet Authenticate task to authenticate with Azure Artifacts.

Question 15

You are a DevOps engineer for a large e-commerce company. The development team uses GitHub for source control and GitHub Actions for CI/CD. The application is a microservices architecture with 15 services, each in its own repository. You need to implement a continuous delivery pipeline that builds and deploys each service to a Kubernetes cluster in Azure (AKS). The pipeline must meet the following requirements: 
- Each service must have its own pipeline that triggers on pushes to the main branch.
- Deployment to AKS must use Helm charts.
- The pipeline must automatically increment the Helm chart version and update the deployment manifest in the repository.
- Security scanning must be performed on container images before deployment.
- The pipeline must support manual approval for production deployment.
- All secrets (e.g., AKS credentials, registry credentials) must be stored securely and not exposed in logs.
You need to design the workflow. What is the best course of action?

Accepted Answer

Create a reusable workflow with OIDC authentication to Azure. Use Helm to deploy, increment chart version, and commit back. Use GitHub environments for approval gates. Integrate container scanning with Docker Scout or Trivy.. Option B satisfies every stated requirement using native GitHub Actions capabilities: reusable workflows provide DRY pipeline logic across the 15 service repos, OIDC federation eliminates long-lived AKS/registry credentials by exchanging short-lived tokens with Microsoft Entra ID, GitHub Environments supply the manual approval gate for production, and Trivy/Docker Scout integrate cleanly as a scanning step before Helm deployment. Helm handles chart versioning, and committing the bumped chart back to the repo closes the GitOps loop.

Answer

Use Azure Pipelines instead of GitHub Actions because it has better integration with AKS. Store secrets in Azure Key Vault and use variable groups.

Answer

Create a workflow per service with direct deployment. Use kubectl commands to deploy. Store all secrets in a single GitHub secret. Skip security scanning to save time.

Answer

Create a single reusable workflow that each service calls. Use Azure CLI to deploy Helm charts. Store AKS credentials as GitHub secrets. Use a manual approval step via environment protection rules.