AZ-400 Practice Test 44 — 15 Questions

Question 1

Your team is adopting Azure Pipelines for a new project. You need to ensure that only authorized users can approve releases to production. Which two methods can you use to implement approval checks?

Accepted Answer

Configure pre-deployment approvals on the Production environment.. Pre-deployment approvals on the Production environment (Option A) allow you to require one or more users or groups to approve a release before it is deployed to that environment. Similarly, setting the 'Required approvers' field on the environment (Option C) specifies the users or groups that must approve the deployment, which is another native Azure Pipelines approval mechanism. Both enforce authorization at the environment level, ensuring only designated approvers can promote a release to production.

Answer

Use Deployment Gates with a manual approval gate.

Answer

Add a Manual Intervention task in the release pipeline.

Answer

Add an Approval Check to the agent pool.

Question 2

You are designing an instrumentation strategy for a microservices application deployed to Azure Kubernetes Service (AKS) using Azure Pipelines. The application emits custom metrics using OpenTelemetry. You need to ensure that all pipeline-related events (build, release, and test results) are correlated with application telemetry to enable end-to-end traceability. What should you do?

Accepted Answer

Set a unique Correlation ID in the pipeline variables and pass it to the application's OpenTelemetry instrumentation as a span attribute.. To correlate pipeline events with application telemetry, you must propagate a shared identifier from the pipeline into the application's telemetry. Setting a unique Correlation ID in pipeline variables and passing it as an OpenTelemetry span attribute (D) lets Application Insights and pipeline logs join on that ID, enabling true end-to-end traceability.

Answer

Configure Application Insights to ingest pipeline telemetry via a custom exporter.

Answer

Store pipeline logs in an Azure Log Analytics workspace and query them together with application metrics.

Answer

Use Azure Pipelines' Checks feature to enforce deployment gates based on application metrics.

Question 3

Your team uses GitHub Actions for CI/CD. You need to collect and analyze build and deployment logs centrally to identify recurring failures. Which service should you use to ingest and query these logs?

Accepted Answer

Azure Log Analytics. Azure Log Analytics is the service designed to ingest, store, and query large volumes of log data using Kusto Query Language (KQL), making it ideal for centralizing GitHub Actions build and deployment logs and identifying recurring failures. You can create a Log Analytics workspace, send logs via the Logs Ingestion API or diagnostic settings, and run KQL queries to spot patterns. This directly satisfies the requirement to collect and analyze logs centrally.

Answer

Azure Monitor Alerts

Answer

GitHub Insights

Answer

Application Insights

Question 4

Which TWO actions should you take to ensure that Azure Pipelines artifacts are scanned for vulnerabilities before production deployment? (Choose two.)

Accepted Answer

Run dependency scanning on the artifact manifest. Option A is correct because running dependency scanning on the artifact manifest inspects the exact third-party packages and versions recorded in the artifact (e.g., via tools like Trivy, Grype, or OWASP Dependency-Check against SBOM/manifest files), catching known CVEs in the components that will actually ship to production. Option C is correct because Microsoft Defender for Cloud (specifically Defender for DevOps/Defender for Containers) integrates with Azure Pipelines to scan artifacts such as container images and IaC during the build/release flow and surface vulnerability findings before deployment. Option B is not correct because code signing provides integrity and authenticity assurance, not vulnerability detection. Option D is not correct because scanning IaC templates finds misconfigurations in infrastructure definitions, not vulnerabilities in the deployed artifact itself. Option E is not correct because static code analysis examines source code for coding flaws, not the built artifact that is promoted to production.

Answer

Sign the artifacts with a code signing certificate

Answer

Scan the infrastructure as code templates

Answer

Run static code analysis on the source code

Question 5

You are designing a release pipeline that must deploy to Azure App Service across multiple regions. Which two practices should you implement to minimize downtime during deployments? (Choose 2)

Accepted Answer

Use Azure App Service deployment slots and perform a swap. Azure App Service deployment slots allow you to deploy a new version of your application to a staging slot, perform validation, and then swap it into production with zero downtime. The swap operation warms up the target slot and smoothly transitions traffic, ensuring no requests are dropped during the update. Additionally, implementing a rolling deployment strategy across regions reduces the blast radius and allows you to gradually shift traffic, further minimizing downtime during multi-region updates.

Answer

Stop the web app before deploying, then start it after

Answer

Deploy to all regions simultaneously

Answer

Use a single deployment slot for all regions

Question 6

Refer to the exhibit. You have a YAML pipeline that references a repository resource with a tag. When will this pipeline trigger?

Accepted Answer

When changes are pushed to the main branch of the current repository.. By default, a YAML pipeline triggers on changes to the main branch of the repository where the pipeline definition resides, even when a repository resource with a tag is referenced. The tag in the repository resource only controls which version of the resource is used at runtime, not the trigger behavior. Without an explicit trigger section, the pipeline uses the default CI trigger on the main branch of the self-repo.

Answer

When a new tag v1.0 is pushed to the referenced repository.

Answer

When changes are pushed to any branch of the referenced repository.

Answer

The pipeline will never trigger because no trigger is defined.

Question 7

Refer to the exhibit. A build pipeline fails at the 'Publish Artifact' step. The pipeline has two jobs: 'Build' and 'Test'. Both jobs have a 'PublishBuildArtifacts' task with artifact name 'drop'. What is the most likely cause?

Accepted Answer

Two jobs are publishing artifacts with the same name.. In Azure Pipelines, artifact names must be unique within a pipeline run. When two jobs (Build and Test) each run a PublishBuildArtifacts task with the same artifact name 'drop', the second publish conflicts with the first, causing the 'Publish Artifact' step to fail. The fix is to use distinct artifact names per job or use a single job to publish.

Answer

The artifact name 'drop' contains invalid characters.

Answer

The artifact is too large to publish.

Answer

The pipeline does not have permission to publish artifacts.

Question 8

Your team uses Azure DevOps and wants to enforce that all work items must be linked to a pull request before merging. Additionally, the pull request must be approved by at least two reviewers. Which two branch policies should you enable?

Accepted Answer

Require a minimum number of reviewers. Option B (Require a minimum number of reviewers) is correct because this branch policy lets you set the required reviewer count, so configuring it to two enforces that a pull request must be approved by at least two reviewers before it can complete. Option C (Check for linked work items) is correct because this policy blocks pull request completion unless at least one work item is linked, directly enforcing that all work items be associated with a pull request before merging. Option A (Automatically update work items) only changes the state of linked work items after a merge and does not require any link to exist, so it does not enforce the linking requirement. Option D (Build validation) triggers a build pipeline to validate the merge but has nothing to do with reviewer counts or work item links. Option E (Comment resolution) only requires that active pull request comments be resolved and does not enforce reviewer approvals or work item linkage.

Answer

Automatically update work items

Answer

Build validation

Answer

Comment resolution

Question 9

You are designing a release pipeline for a microservices application deployed to Azure Kubernetes Service (AKS). Each microservice has its own build pipeline that produces a container image. You need a single release pipeline that can deploy multiple microservices in a coordinated manner, but you want to avoid rebuilding the deployment pipeline for each microservice. The deployment should use Helm charts. What should you do?

Accepted Answer

Create a single release pipeline that consumes multiple build artifacts (one per microservice) and uses a Helm chart per microservice, deploying them in stages.. A single release pipeline can consume multiple build artifacts (one per microservice) and deploy each with its own Helm chart, using stages to coordinate the rollout. This avoids rebuilding the pipeline for each microservice while still allowing coordinated deployment. Azure Pipelines supports multiple artifact sources in a single release definition, and Helm tasks can be parameterized per stage.

Answer

Create a separate release pipeline for each microservice and trigger them in sequence using pipeline completion triggers.

Answer

Create a single build pipeline that produces all container images, then a release pipeline that deploys the single artifact.

Answer

Create a single multi-stage YAML pipeline that builds and deploys all microservices together.

Question 10

You need to automatically run a pipeline when a new tag is pushed to the repository. Which trigger configuration should you use?

Accepted Answer

Tags trigger. Tags trigger allows running pipelines when a tag is pushed or updated. Option B (Schedule trigger) is incorrect because it runs on a predefined schedule, not on tag events. Option C (PR trigger) is incorrect because it triggers on pull request actions, not on tags. Option D (CI trigger with branch filters) is incorrect because CI trigger monitors branches, not tags; even with branch filters it does not respond to tags.

Answer

Schedule trigger

Answer

PR trigger

Answer

CI trigger with branch filters

Question 11

Your team is using Azure Pipelines to deploy a web application to Azure App Service. The application uses a configuration file (appsettings.json) that contains environment-specific settings. You need to manage these settings across development, staging, and production environments without exposing secrets in the source code. The pipeline should automatically replace the settings during deployment. What should you configure?

Accepted Answer

Use the 'File Transform' task in the release pipeline to replace tokens in the configuration file with variables defined in pipeline variable groups.. The File Transform task in Azure Pipelines can perform token replacement in configuration files like appsettings.json using variables defined in pipeline variable groups. This allows environment-specific settings to be injected during deployment without hardcoding secrets in source control. Variable groups can be linked to Azure Key Vault for secure secret management.

Answer

Create separate build configurations for each environment and use the 'Transform Web.config' task.

Answer

Use the 'Azure App Service Deploy' task with the 'Use Web Deploy' option and configure parameterization.

Answer

Set environment variables in the Azure App Service and read them in the application code.

Question 12

Your company uses Azure DevOps and must comply with SOC 2. The auditor requires proof that all production deployments went through a change management process with approval. What should you implement?

Accepted Answer

Configure release approval gates in Azure Pipelines. Release approval gates in Azure Pipelines allow you to define approvers who must approve a deployment before it proceeds. This enforces a change management process with documented approval, providing an audit trail that satisfies SOC 2 requirements. Approval gates can be configured for specific environments or stages, ensuring that all production deployments are reviewed.

Answer

Use branch policies to require pull request approvals

Answer

Set pipeline retention policies to keep deployment records

Answer

Enable audit logging for all pipelines

Question 13

You have the above branch policy configuration for the main branch. A developer pushes a new commit to an existing pull request. What happens?

Accepted Answer

The existing approvals are reset, and a new build is automatically queued.. When a new commit is pushed to an existing pull request and the branch policy includes a build validation with 'Reset approvals on new changes' enabled, Azure DevOps resets all existing approvals and automatically queues a new build to validate the updated code. This ensures that approvals are only valid for the exact code revision that was reviewed. The behavior is standard for branch policies that require a build and have the reset option configured.

Answer

The existing approvals are reset, but no new build is queued.

Answer

The pull request is automatically completed.

Answer

The existing approvals remain valid, and the build is not requeued.

Question 14

Match each Azure Monitor feature to its use case.

Accepted Answer

Log Analytics: Collects and queries log data from Azure resources.. The correct matches are Log Analytics for log collection and querying, Application Insights for live web application monitoring, and Azure Monitor Metrics for numeric performance data. The distractors swap the definitions of Log Analytics and Application Insights.

Answer

Log Analytics: Monitors live web applications.

Answer

Application Insights: Collects and queries log data.

Question 15

Match each Azure Test Plans concept to its definition.

Accepted Answer

Test Plan: A container for test suites and test cases that specifies test settings and test configurations.. In Azure Test Plans, a Test Plan is a container for test suites and test cases with settings. A Test Suite groups test cases. A Test Case has steps and expected results. A Test Run is an execution of test cases. A Test Point is a test case with a specific configuration.

Answer

Test Suite: A set of steps and expected results to validate a feature.

Answer

Test Case: A collection of test cases grouped together for execution.