Knowledge + Practice

Microsoft Azure DevOps Engineer Expert AZ-400 (AZ-400) — Questions 676–750

913 questions total · 13pages · All types, answers revealed

Take a mock exam Exam hub

Page 10 of 13

676

Multi-Selectmedium

A company is adopting Azure DevOps and needs to ensure that all pipelines comply with regulatory standards. The security team wants to enforce that every build includes a security scan and that deployment to production requires approval from a compliance officer. Which TWO actions should the DevOps engineer take?

Select 2 answers

A.Configure branch policies to require a security scan on pull requests.

B.Create a required template that includes the security scan task and mandate its use via a pipeline resource.

C.Add a variable group to store security scan results and reference it in the pipeline.

D.Configure a required reviewer approval on the production stage of the release pipeline.

E.Use a pipeline decorator to automatically run a security scan on every build.

AnswersB, D

Required templates enforce consistent steps.

Why this answer

Option B is correct because creating a required template that includes the security scan task and mandating its use via a pipeline resource ensures that every pipeline inherits the security scan step, enforcing compliance at the pipeline definition level. Option D is correct because configuring a required reviewer approval on the production stage of the release pipeline enforces that a compliance officer must explicitly approve the deployment, meeting the regulatory requirement for production deployments.

Exam trap

The trap here is that candidates often confuse branch policies (Option A) with build-level enforcement, not realizing that branch policies only apply to pull request validation, not to all builds triggered by other events like CI or scheduled triggers.

Full explanation →

677

MCQmedium

Your team uses Azure DevOps and wants to automate the creation of work items when a build pipeline fails. The work item should be assigned to the last person who committed a change in the failed build. Which approach should you use?

A.Create a release pipeline that triggers on build failure and creates a work item.

B.Add the 'Create work item on failure' task to the build pipeline.

C.Configure a Service Hook to create a work item on build failure.

D.Use a PowerShell script in the pipeline to call Azure DevOps REST API.

AnswerB

This built-in task creates a bug assigned to the responsible committer.

Why this answer

Option B is correct because the 'Create work item on failure' task in a build pipeline automatically creates a bug and assigns it to the person who triggered the build or the last committer. Option A (Service Hook) would require custom logic. Option C (YAML task with REST API) is more complex and not built-in.

Option D (Release pipeline) is for deployments, not builds.

Full explanation →

678

MCQmedium

Your team uses GitHub Actions for CI/CD. Security policies require that secrets must be automatically rotated every 90 days. Which Azure DevOps feature should you integrate to enforce this requirement?

A.Microsoft Purview Compliance Manager

B.GitHub Actions secrets with scheduled workflows

C.Azure Key Vault with rotation policy

D.Azure Managed Identities

AnswerC

Azure Key Vault supports secret rotation policies that can be configured to rotate secrets automatically.

Why this answer

Option C is correct because Azure Key Vault supports automatic secret rotation policies. Option A is wrong because Microsoft Purview is for data governance, not secret rotation. Option B is wrong because Managed Identities are for authentication, not rotation.

Option D is wrong because GitHub Actions secrets do not support automatic rotation natively.

Full explanation →

679

MCQeasy

Your team uses Azure Pipelines to deploy to multiple environments. The compliance team requires that all deployments to the production environment are approved by a security officer. Which feature should you use?

A.Configure approvals and checks on the production environment in Azure Pipelines.

B.Create a branch policy that requires approval for pull requests.

C.Use a service connection with a managed identity that requires approval.

D.Store the production credentials in a variable group with approval required.

AnswerA

Approvals and checks allow you to require manual sign-off before deployment to an environment.

Why this answer

Approvals and checks in Azure Pipelines allow you to require manual approval before deployment to a specific environment. Branch policies are for GitHub/Azure Repos branches. Service connections are for authentication.

Variable groups store variables, not approvals.

Full explanation →

680

Multi-Selectmedium

Which TWO conditions should you configure in a release pipeline to ensure that a deployment to production only happens when both the staging deployment succeeded and a manual approval is granted? (Choose two.)

Select 2 answers

A.Add a post-deployment approval on the staging stage.

B.Add a pre-deployment approval on the production stage.

C.Set the trigger to 'After release' and filter by artifact.

D.Set the deployment queue setting to 'After previous deployment' for the production stage.

E.Add a gate that checks if the staging deployment succeeded.

AnswersB, D

Requires manual approval before deploying to production.

Why this answer

You need to set the deployment queue setting to 'After previous deployment' to enforce order (C) and add a pre-deployment approval (E). Option A is wrong because a post-deployment approval on staging would approve after staging, not before production. Option B is wrong because a trigger on artifact source is not needed.

Option D is wrong because gates evaluate conditions but don't enforce order or approvals.

Full explanation →

681

MCQmedium

Your team uses Git for source control. A developer accidentally committed a large binary file (500 MB) to the main branch. The push succeeded but other team members are now complaining about slow fetch times. What is the most efficient way to remove the file from the repository history?

A.Use 'git filter-repo' to remove the file from history

B.Add the file to .gitignore and push again

C.Use 'git revert' to undo the commit

D.Use BFG Repo-Cleaner

AnswerA

git filter-repo is the recommended tool for history rewriting.

Why this answer

Option A is correct because 'git filter-repo' is the recommended modern tool for permanently removing large files from Git history. It rewrites the repository's commit graph, eliminating the file from all commits, which reduces repository size and resolves slow fetch times for team members. Unlike BFG Repo-Cleaner, 'git filter-repo' is actively maintained and integrates natively with Git, making it the most efficient and reliable choice for this task.

Exam trap

The trap here is that candidates often confuse 'git revert' (which only adds a new commit to undo changes) with history-rewriting tools like 'git filter-repo' or BFG, not realizing that only history rewriting permanently removes a file from all commits and reduces repository size.

How to eliminate wrong answers

Option B is wrong because adding the file to .gitignore only prevents future tracking of the file; it does not remove the file from existing commits, so the large binary file remains in the repository history and continues to bloat fetch times. Option C is wrong because 'git revert' creates a new commit that undoes the changes of the original commit, but the large binary file remains in the commit history, so the repository size is not reduced and slow fetch times persist. Option D is wrong because BFG Repo-Cleaner is a valid tool for removing large files from history, but it is less efficient than 'git filter-repo' for this specific scenario; BFG is a Java-based tool that requires additional setup and is not as tightly integrated with Git's internals, making 'git filter-repo' the preferred choice in modern Git workflows.

Full explanation →

682

MCQhard

You are a DevOps engineer for a large e-commerce company. The company uses Azure DevOps for CI/CD and Application Insights for monitoring. The application is a .NET Core 6 microservice running on Azure Kubernetes Service (AKS) with a Redis cache and Azure SQL Database. Recently, the operations team noticed that the application's response time has degraded significantly during peak traffic hours. Application Insights shows an increase in server-side dependency call duration to Redis and SQL, but no increase in exceptions. The team suspects a connection pooling issue. You have been asked to diagnose and fix the problem. Which approach should you take first?

A.Increase the number of AKS nodes to handle peak traffic and reduce resource contention.

B.Review the application code to ensure that Redis and SQL connections are properly opened and closed using 'using' statements.

C.Run a load test against the application to reproduce the issue and monitor system counters.

D.Use Application Insights 'Dependency' performance blade to analyze call duration percentiles and identify whether the bottleneck is in Redis or SQL. Then adjust connection pool sizes accordingly.

AnswerD

This allows data-driven diagnosis of which dependency is causing the delay.

Why this answer

Option D is correct because the first step in diagnosing a connection pooling issue is to analyze the dependency performance data in Application Insights. The 'Dependency' blade provides detailed percentiles (e.g., P50, P95, P99) for Redis and SQL call durations, allowing you to pinpoint which dependency is the bottleneck. Once identified, you can adjust the connection pool size (e.g., Max Pool Size in SQL connection string or Redis multiplexer settings) to match the peak concurrency demands without overwhelming the database or cache.

Exam trap

The trap here is that candidates assume the issue is a code bug (Option B) or infrastructure scaling (Option A), but the question explicitly states no exceptions and a connection pooling suspicion, so the correct first diagnostic step is to analyze existing telemetry to confirm the bottleneck before making changes.

How to eliminate wrong answers

Option A is wrong because increasing AKS nodes addresses compute resource contention, not connection pooling issues; the problem is at the dependency layer (Redis/SQL), not node CPU/memory. Option B is wrong because while proper disposal of connections is important, the team already suspects a connection pooling issue (not leaked connections), and the code likely already uses 'using' statements in .NET Core 6; the fix is to tune pool sizes, not to fix leaks. Option C is wrong because running a load test to reproduce the issue is a valid step, but it should come after analyzing existing telemetry; Application Insights already has the data needed to identify the bottleneck, making a load test premature and potentially disruptive.

Full explanation →

683

MCQhard

Refer to the exhibit. You are creating an ARM template to deploy an App Service and its Application Insights configuration. The template fails to deploy with error: 'The resource 'Microsoft.Insights/components/...' is not defined in the template.' What is the most likely cause?

A.The reference function cannot be used in a properties object.

B.The reference function syntax is incorrect.

C.The Application Insights component is not defined as a resource in the template.

D.The apiVersion for the config resource is outdated.

AnswerC

Correct: reference() can only refer to resources deployed in the same template or existing resources if using 'full' reference.

Why this answer

Option A is correct because the reference function cannot reference a resource that is not defined in the template unless it exists already. Option B is wrong because the expression syntax is correct for ARM. Option C is wrong because apiVersion is valid.

Option D is wrong because the reference function can be used in outputs if the resource is defined.

Full explanation →

684

MCQhard

A development team is using Git for source control. They have a main branch that should always be deployable. Developers work on feature branches and create pull requests to merge into main. Recently, a feature branch with incomplete work was accidentally merged into main, causing build failures. What is the best Git branch strategy to prevent this in the future while maintaining fast feedback?

A.Require at least one code reviewer approval for all pull requests into main.

B.Configure branch protection on main to require status checks (CI build and tests) to pass before merging.

C.Adopt a GitFlow-like branching model with a separate release branch for stable code.

D.Disable direct pushes to main and enforce all merges through pull requests.

E.Require a linear history on main by enabling 'Rebase and merge' for all pull requests.

AnswerB

This ensures that only branches with passing builds and tests can be merged into main.

Why this answer

Option B is correct because configuring branch protection on main to require status checks (CI build and tests) to pass before merging directly prevents incomplete or broken code from being merged. This enforces that every pull request must pass automated validation, ensuring main remains deployable while still allowing fast feedback through the CI pipeline.

Exam trap

The trap here is that candidates often confuse process controls (like requiring pull requests or code reviews) with automated quality gates (like status checks), mistakenly believing that human review alone is sufficient to catch all integration issues.

How to eliminate wrong answers

Option A is wrong because requiring code reviewer approval alone does not prevent incomplete or broken code from being merged; reviewers may miss issues or approve without running builds. Option C is wrong because adopting GitFlow with a separate release branch adds complexity and delays feedback, contradicting the need for fast feedback and not directly preventing accidental merges of incomplete work. Option D is wrong because disabling direct pushes and enforcing merges through pull requests is a prerequisite but does not enforce that the code is complete or passes validation; it only controls the merge mechanism.

Option E is wrong because requiring a linear history via 'Rebase and merge' only affects commit history structure, not the quality or completeness of the code being merged.

Full explanation →

685

MCQmedium

Refer to the exhibit. You run the Kusto query in Azure Monitor to analyze pipeline performance. The query returns no results even though you know some pipelines have average durations over 10 minutes. What is the most likely reason?

A.The column name 'RunStartTime' is incorrect; the actual column may be 'StartTime'.

B.The 'avg' function ignores values over 600, so no rows are returned.

C.The 'ago(7d)' function is not supported in Azure Monitor.

D.The 'RunDurationSeconds' column stores durations as strings, so the average cannot be calculated.

AnswerA

If the column name is wrong, the query returns no results.

Why this answer

Option B is correct because the query filters by 'RunStartTime' but the column is likely named differently (e.g., 'StartTime'). The KQL query uses an incorrect column name. Option A is wrong because the 'ago' function works correctly.

Option C is wrong because the query would return results even if durations are stored as integers. Option D is wrong because averaging does not filter out results over 600.

Full explanation →

686

Multi-Selectmedium

Which TWO actions should you take to implement a secure build pipeline that uses Azure Key Vault to store secrets? (Choose two.)

Select 2 answers

A.Store the Key Vault name and secret names in a secure file in the repository.

B.Define secrets as pipeline variables and mark them as secret.

C.Grant the Azure DevOps service principal 'Get' and 'List' permissions on the Key Vault.

D.Use the 'Azure CLI' task to run 'az keyvault secret show' for each secret.

E.Use the 'Azure Key Vault' task to download secrets as pipeline variables.

AnswersC, E

Necessary for the pipeline to access secrets.

Why this answer

To securely use secrets from Azure Key Vault, you should grant the build service principal access to the vault (A) and use the 'Azure Key Vault' task to download secrets as variables (D). Option B is wrong because checking in secrets to the repository defeats the purpose of Key Vault. Option C is wrong because secrets should be stored in Key Vault, not as pipeline variables.

Option E is wrong because the Key Vault task can directly retrieve secrets without using the Azure CLI.

Full explanation →

687

MCQmedium

Refer to the exhibit. You have this Azure Pipeline YAML. When you run the pipeline, it fails because the resource group name is not correctly resolved. What is the likely cause?

A.The script type 'pscore' is not supported on Ubuntu.

B.The variable 'resourceGroupName' uses $(environment) which cannot reference a parameter.

C.Parameters cannot be used in YAML pipelines; they must be defined in a template.

D.The 'trigger: none' prevents the pipeline from running.

AnswerB

Parameters are accessed via ${{ parameters.environment }} in variables.

Why this answer

Option A is correct. In Azure Pipelines, variables defined in YAML using 'variables' can reference parameters using ${{ parameters.environment }} but not $(environment). The macro syntax $(variable) is for runtime variables, but 'environment' is a parameter.

So $(environment) is not resolved. Option B is incorrect because parameters can be used in templates. Option C is not the issue.

Option D is incorrect because the script type is valid.

Full explanation →

688

MCQhard

You manage a release pipeline that deploys to multiple environments. The pipeline uses variables that differ per environment. You want to avoid duplicating variable definitions. Which strategy should you use?

A.Use variable groups linked to environments

B.Use the 'variables' section in the pipeline YAML with conditions

C.Define variables in each stage of the YAML pipeline

D.Store all variables in Azure Key Vault and reference them in the pipeline

AnswerA

Variable groups can be scoped to environments.

Why this answer

Variable groups allow sharing common variables across pipelines and overriding per environment. Option A is wrong because stage-level variables duplicate per stage. Option B is wrong because Azure Key Vault stores secrets, not all variables.

Option D is wrong because the variables section in YAML is still duplicated.

Full explanation →

689

MCQeasy

You need to run a set of tasks only when the build pipeline runs for the main branch. Which condition should you add to the job or step?

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

B.condition: eq(variables['Build.SourceBranch'], 'main')

C.condition: and(succeeded(), eq(variables['System.PullRequest.TargetBranch'], 'main'))

D.condition: ne(variables['Build.Reason'], 'PullRequest')

AnswerA

Why this answer

Option A is correct because the `Build.SourceBranch` variable in Azure Pipelines contains the full Git ref (e.g., `refs/heads/main`). Using `eq(variables['Build.SourceBranch'], 'refs/heads/main')` ensures the condition evaluates to true only when the pipeline runs on the main branch. This is the standard way to filter by branch in YAML pipeline conditions.

Exam trap

The trap here is that candidates often assume `Build.SourceBranch` contains only the short branch name (like `main`) rather than the full Git ref path (`refs/heads/main`), leading them to choose Option B.

Why the other options are wrong

B

Missing 'refs/heads/' prefix, so it won't match.

C

This checks PR target branch, not the source branch.

D

This excludes PRs but does not limit to main branch.

Full explanation →

690

MCQhard

Your YAML pipeline uses the 'AzureResourceManagerTemplateDeployment' task to deploy ARM templates. You need to handle incremental deployments and ensure that the task fails if any resource already exists and cannot be updated. Which deployment mode should you specify?

A.Incremental

B.Complete

C.Validate

D.CreateOrUpdate

AnswerA

Why this answer

The 'Incremental' deployment mode in the AzureResourceManagerTemplateDeployment task handles only changes specified in the template, leaving existing resources unchanged. If a resource already exists and cannot be updated (e.g., due to a property conflict or immutable resource), the deployment fails, meeting the requirement to fail on such conflicts. This mode is the standard for additive, non-destructive ARM template deployments.

Exam trap

The trap here is that candidates confuse 'Incremental' with 'Complete' mode, mistakenly thinking 'Complete' is safer for incremental updates, when in fact 'Complete' can delete resources not in the template, leading to data loss.

Why the other options are wrong

B

Complete mode deletes resources not in the template; it does not fail on existing resources that cannot be updated.

C

Validate mode only validates the template without actually deploying resources.

D

There is no deployment mode named 'CreateOrUpdate'; it is a behavior of Incremental mode.

Full explanation →

691

MCQeasy

Your development team uses GitHub Actions for CI/CD. You need to ensure that secrets stored in GitHub repository secrets are not exposed in build logs. What is the best practice?

A.Use a custom action to manually mask secrets in the logs.

B.Define secrets as environment variables directly in the workflow YAML.

C.Store secrets in GitHub repository secrets and reference them in workflows using ${{ secrets.SECRET_NAME }}. GitHub automatically masks secrets in logs.

D.After the workflow runs, delete the logs from GitHub.

AnswerC

This is the recommended approach; GitHub automatically redacts secrets.

Why this answer

Option A is correct because GitHub automatically redacts secrets in logs. Option B is incorrect because masking is automatic, not manual. Option C is incorrect because secrets should be stored in repository secrets, not environment variables in YAML.

Option D is incorrect because adding a step to delete logs does not prevent exposure.

Full explanation →

692

Multi-Selectmedium

Your release pipeline deploys to multiple environments sequentially: Dev, QA, Staging, Production. You need to implement manual approval gates before Staging and Production deployments. Which TWO configurations should you use? (Choose two.)

Select 2 answers

A.Add a post-deployment approval gate to the Dev and QA stages.

B.Use the 'Approvals and gates' settings in the release pipeline stage.

C.Configure branch policy on the release branch to require approvals.

D.Add a 'Manual Validation' task in the YAML pipeline.

E.Add a pre-deployment approval gate to the Staging and Production stages.

AnswersB, E

Correct: Approval gates are configured per stage in release pipeline settings.

Why this answer

Option A is correct because pre-deployment approvals can be set on each stage. Option D is correct because approval gates are configured in the release pipeline editor. Option B is wrong because post-deployment approvals are after deployment.

Option C is wrong because branch policies are for PRs, not releases. Option E is wrong because YAML pipelines use 'approvals' keyword, not a separate task.

Full explanation →

693

Multi-Selecteasy

Which TWO actions help improve communication and collaboration in a distributed Azure DevOps team?

Select 2 answers

A.Maintain a shared wiki with project documentation and decisions.

B.Use multiple chat channels for each topic to organize discussions.

C.Use long email threads for decision-making to ensure full documentation.

D.Schedule daily stand-up meetings at a time that works for all time zones.

E.Avoid using pull request comments to reduce noise.

AnswersA, D

Centralized documentation aids transparency.

Why this answer

A shared wiki (e.g., Azure DevOps Wiki) provides a single source of truth for project documentation, decisions, and onboarding materials. It is version-controlled, searchable, and accessible asynchronously, which is critical for distributed teams to stay aligned without relying on real-time communication.

Exam trap

The trap here is that candidates may think multiple chat channels improve organization, but Azure DevOps emphasizes asynchronous, traceable communication via work items, pull requests, and wikis rather than real-time chat fragmentation.

Full explanation →

694

MCQeasy

Your Azure DevOps pipeline uses a YAML template to avoid duplication. The template defines common build steps. You need to override one of the steps in a specific pipeline without modifying the template. Which approach should you use?

A.Use the 'overrides' keyword in the pipeline YAML to specify which steps to replace.

B.Create a copy of the template and modify the step directly.

C.Use a conditional 'if' statement in the template to skip steps based on a parameter.

D.Use template parameters with a 'steps' object that can be injected, and use the 'replace' keyword in the pipeline to override the step.

AnswerD

Template parameters allow injecting custom steps, and 'replace' can override specific steps.

Why this answer

Option D is correct because Azure DevOps YAML templates support parameterized steps objects, allowing a pipeline to inject a custom set of steps that replace the default ones defined in the template. The `replace` keyword is used within the template to designate a default steps object that can be overridden by the calling pipeline, enabling step-level customization without modifying the template file.

Exam trap

The trap here is that candidates may confuse the fictional `overrides` keyword (Option A) with a real feature, or incorrectly assume that conditional logic in the template (Option C) is the only way to control step execution, when in fact Azure DevOps provides a dedicated parameter injection pattern for step replacement.

How to eliminate wrong answers

Option A is wrong because Azure DevOps YAML does not support an `overrides` keyword; this is a fictional construct. Option B is wrong because creating a copy of the template defeats the purpose of reuse and introduces maintenance overhead, which is not the intended solution for overriding steps without modifying the template. Option C is wrong because using a conditional `if` statement in the template requires modifying the template itself, which violates the requirement to avoid modifying the template.

Full explanation →

695

Matchingmedium

Match each Azure Test Plans concept to its definition.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Container for test suites and configurations

Group of test cases

Individual test with steps and expected results

Execution of a set of test cases

Why these pairings

Basic test artifacts in Azure Test Plans.

Full explanation →

696

MCQhard

Refer to the exhibit. You have a YAML pipeline definition that builds a .NET application. You notice that the revision number is always 0. What is the most likely cause?

A.The 'DotNetCoreCLI@2' task does not support the counter expression.

B.The counter expression uses a variable that is not defined as a counter, causing it to reset.

C.The counter expression resets every time the pipeline runs because of the 'minorVersion' variable.

D.The counter expression is evaluated after the build steps, so it always returns 0.

AnswerB

The seed should be a static value or a counter itself; using a non-counter variable as seed resets the counter each run.

Why this answer

Option A is correct because the counter expression uses 'minorVersion' as the seed, which is a string variable '0', not a numeric counter. The counter function expects a numeric seed to increment; using a variable that is not a counter expression itself causes the counter to reset each time. Option B is wrong because the counter is not resetting per run; it stays at 0.

Option C is wrong because the counter is evaluated at pipeline start, not per step. Option D is wrong because the counter is not related to the build task.

Full explanation →

697

MCQhard

Your organization uses GitHub Actions for CI/CD. You need to ensure that secrets stored in GitHub are not exposed in build logs. A developer accidentally printed a secret to the console in a workflow step. What built-in feature of GitHub Actions automatically prevents this?

A.Audit log monitoring

B.Secret scanning alerts

C.Required reviewers on workflows

D.Automatic log redaction

AnswerD

GitHub automatically redacts secrets from workflow run logs.

Why this answer

GitHub Actions automatically redacts secrets from logs when they are printed or used in commands. This is a built-in security feature.

Full explanation →

698

MCQmedium

Your team uses Azure Pipelines for CI/CD. You need to enforce that all builds produce a signed artifact. Which approach should you use?

A.Add a YAML template that includes the signing task and require all pipelines to extend it.

B.Set a branch policy requiring a signed build status.

C.Configure a manual approval gate on the build pipeline.

D.Use a Pipeline decorator to inject the signing task into every build pipeline.

AnswerD

Pipeline decorators inject tasks at runtime, ensuring every pipeline runs the signing step.

Why this answer

Option D is correct because Pipeline decorators allow injecting a task (like signing) into every pipeline without modifying each pipeline definition. Option A is wrong because requiring a manual approval gate does not enforce signing. Option B is wrong because branch policies control PR merges, not build steps.

Option C is wrong because YAML templates require explicit inclusion in each pipeline.

Full explanation →

699

MCQeasy

Your team uses GitHub Flow and wants to ensure that every pull request is reviewed by at least one team member. Which branch protection rule should you enable?

A.Require a pull request before merging and set required number of reviewers to 1

B.Require signed commits

C.Require status checks to pass before merging

D.Require conversation resolution before merging

AnswerA

This enforces review before merge.

Why this answer

Option A is correct because GitHub Flow relies on pull requests for collaboration, and the 'Require a pull request before merging' rule with a required number of reviewers set to 1 enforces that every PR must be reviewed by at least one team member before it can be merged. This directly satisfies the requirement of ensuring code review for all changes.

Exam trap

The trap here is that candidates may confuse 'requiring status checks' (automated validation) with 'requiring pull request reviews' (human validation), leading them to select option C instead of A.

How to eliminate wrong answers

Option B is wrong because requiring signed commits ensures commit authenticity and integrity via GPG or S/MIME signatures, but it does not enforce any review process. Option C is wrong because requiring status checks to pass before merging ensures that CI/CD checks (e.g., tests, builds) succeed, but it does not mandate human review. Option D is wrong because requiring conversation resolution before merging ensures that all comments on a PR are marked as resolved, but it does not guarantee that a specific number of reviewers have approved the changes.

Full explanation →

700

MCQeasy

You are designing a build pipeline for a Node.js application. The team wants to ensure that the pipeline runs unit tests and publishes test results to Azure DevOps. Which task should you add to the pipeline?

A.Publish Test Results task

B.Copy Files task

C.npm test

D.Publish Build Artifacts task

AnswerA

Publishes test results to Azure DevOps from various formats.

Why this answer

The 'Publish Test Results' task is specifically designed to publish test results in formats like JUnit, NUnit, etc., to Azure DevOps. Option A is wrong because 'npm test' only runs tests but doesn't publish results. Option B is wrong because 'Copy Files' only copies files.

Option D is wrong because 'Publish Build Artifacts' publishes build outputs, not test results.

Full explanation →

701

MCQeasy

Refer to the exhibit. The pipeline will trigger when changes are pushed to which branches?

A.All branches

B.The main branch and any branch starting with 'release/'

C.Only the main branch

D.Only branches starting with 'release/'

AnswerB

The includes specify main and release/*, which matches branches like release/v1.

Why this answer

Option C is correct because the trigger includes 'main' and 'release/*' branches, so any branch matching 'main' or starting with 'release/' will trigger the pipeline. Option A is wrong because it only includes main, not release/*. Option B is wrong because it includes all branches.

Option D is wrong because it only includes release/* branches.

Full explanation →

702

MCQhard

Refer to the exhibit. A developer queues a build manually but notices the build status remains 'notStarted' for an extended period. The pipeline has no demands and priority is normal. Which is the most likely cause?

A.The variable 'BuildConfiguration' is misspelled.

B.The branch 'main' does not exist.

C.All agents in the pool are currently busy.

D.The pipeline definition ID is incorrect.

AnswerC

With no demands, the build can run on any agent. If all agents are occupied, the build will wait.

Why this answer

The build is queued but not starting. Since priority is normal and there are no demands, the most likely cause is that all available build agents are busy or the agent pool has no agents.

Full explanation →

703

MCQmedium

Your team is designing a build pipeline for a Java application that uses Maven. The pipeline must run unit tests and integration tests separately, and fail the build if integration tests fail. However, integration tests require a running database container. Which approach should you use to ensure the database is available for the integration tests?

A.Use a Docker Compose task in the pipeline to start the database container before running integration tests.

B.Configure the pipeline to use a self-hosted agent that has the database already installed and running.

C.Install the database as a service in the pipeline using the Service Fabric task.

D.Use a PowerShell script in the pipeline to install and start the database on the build agent.

AnswerA

Docker Compose provides a declarative way to run dependent services as containers.

Why this answer

Option B is correct because Docker Compose allows you to define and run multi-container Docker applications, making it easy to spin up a database container for integration tests. Option A is incorrect because it requires manual steps and is not automated. Option C is incorrect because a self-hosted agent with preinstalled database reduces flexibility.

Option D is incorrect because it's not a feature of Azure DevOps.

Full explanation →

704

MCQmedium

Your organization uses GitHub for source control and Azure Pipelines for CI/CD. You need to implement a policy that requires all pull requests to pass a status check before merging. The status check should be provided by a pipeline that runs when a pull request is created. Which type of trigger should you configure in the pipeline YAML?

A.Push trigger

B.Manual trigger

C.PR trigger

D.Scheduled trigger

AnswerC

PR trigger runs when a pull request is opened or updated.

Why this answer

Option B is correct because 'pr' trigger is specifically for pull request validation in GitHub. Option A is wrong because 'push' trigger runs on commits. Option C is wrong because 'schedules' trigger runs on a timer.

Option D is wrong because 'manual' is not a trigger type.

Full explanation →

705

Multi-Selecteasy

Which TWO are best practices when configuring alerts in Azure Monitor for a production application?

Select 2 answers

A.Use metric alerts only for simple threshold-based conditions.

B.Use dynamic thresholds for metrics with seasonal patterns.

C.Create separate alert rules for each condition to avoid complexity.

D.Configure action groups to send notifications and run automated actions.

E.Ensure each alert rule uses a unique action group to isolate notifications.

AnswersB, D

Dynamic thresholds automatically adjust baselines.

Why this answer

Option B is correct because dynamic thresholds in Azure Monitor use machine learning to automatically detect and adjust alert thresholds based on historical patterns, making them ideal for metrics with seasonal or cyclical behavior (e.g., CPU usage that spikes during business hours). This reduces alert noise and manual tuning effort compared to static thresholds.

Exam trap

The trap here is that candidates often assume metric alerts are only for simple thresholds (Option A) and overlook that dynamic thresholds are purpose-built for seasonal patterns, while also mistakenly thinking unique action groups per rule (Option E) improve isolation rather than creating unnecessary complexity.

Full explanation →

706

MCQhard

You have a multi-stage YAML pipeline in Azure DevOps that deploys to multiple environments. The pipeline uses a deployment job with environment approvals. You need to ensure that the deployment to the production environment is only triggered after a manual approval is granted. However, you also want the deployment to automatically roll back if the post-deployment health check fails. Which configuration should you implement?

A.Use a release pipeline with a pre-deployment approval and a post-deployment automatic rollback trigger.

B.Configure pre-deployment approvals on the production environment and use a post-deployment gate that fails the deployment.

C.Configure pre-deployment approvals and add a manual intervention task to roll back if health check fails.

D.Enable 'Auto-revert' on the production environment and set post-deployment conditions.

AnswerD

Auto-revert automatically rolls back on post-deployment failure.

Why this answer

In Azure Pipelines, environment approvals provide manual gate before deployment. The 'post-deployment auto-revert' feature can be enabled on the environment to automatically revert to the previous successful deployment if the post-deployment conditions (like health checks) fail. Option D is correct.

Option A is incorrect because the approval is pre-deployment, not post-deployment. Option B is incorrect because approvers cannot trigger rollback automatically. Option C is incorrect because 'Automatically revert' is the feature name.

Full explanation →

707

MCQmedium

Your team uses GitHub for source control and wants to enforce that all pull requests into the main branch require at least two reviewers and must pass a status check from a CI pipeline. Which branch protection rule configurations should you apply?

A.Require a minimum of 2 reviewers, require status checks to pass before merging

B.Require signed commits and status checks

C.Require status checks to pass, but do not require reviewers

D.Require a minimum of 2 reviewers, but do not require status checks

AnswerA

Correctly includes both requirements.

Why this answer

Option A is correct because GitHub branch protection rules allow you to require a minimum number of reviewers before merging and to require status checks to pass. By setting 'Require a minimum number of reviewers' to 2 and enabling 'Require status checks to pass before merging', you enforce that every pull request into the main branch must be approved by at least two reviewers and must pass the CI pipeline status check, meeting the stated requirements.

Exam trap

The trap here is that candidates may think requiring signed commits or only status checks is sufficient, but the question explicitly demands both two reviewers and a CI status check, which only option A satisfies.

How to eliminate wrong answers

Option B is wrong because requiring signed commits ensures commit authenticity but does not enforce the required two reviewers or the CI status check. Option C is wrong because it omits the requirement for at least two reviewers, which is explicitly needed. Option D is wrong because it omits the requirement for status checks to pass, leaving the CI pipeline result unenforced.

Full explanation →

708

MCQmedium

Your release pipeline deploys to multiple environments sequentially. The deployment to production fails intermittently due to a database schema migration issue. You need to implement a strategy that automatically rolls back the deployment if the migration fails. What should you do?

A.Enable 'Auto-rollback' in the release pipeline settings.

B.Use a multi-stage YAML pipeline with manual intervention.

C.Configure pre-deployment approval gates.

D.Add a post-deployment script that runs a rollback script on failure.

AnswerD

A rollback script can be triggered on failure to revert changes.

Why this answer

Approval gates only pause deployment; they don't roll back. Pre-deployment conditions can check conditions but not automatically roll back. Rollback scripts in the pipeline can reverse changes if a failure is detected.

Using multiple stages doesn't automatically roll back; it just defines stages.

Full explanation →

709

Multi-Selectmedium

You manage a release pipeline for a Java application that is deployed to Azure App Service. The pipeline currently uses manual approval gates. You need to implement automated quality gates to reduce manual intervention. Which THREE conditions can you use in the 'Post-deployment approvals' settings of a release pipeline? (Choose three.)

Select 3 answers

A.Azure Policy

B.Manual approval

C.Invoke Azure Functions

D.REST API

E.Query Azure Monitor alerts

AnswersC, D, E

Runs custom function code to evaluate conditions.

Why this answer

Option A is correct: 'Query Azure Monitor alerts' can be used as an automated gate to check for active alerts. Option B is correct: 'Invoke Azure Functions' can run custom logic to evaluate quality. Option C is correct: 'REST API' can call external services to check conditions.

Option D is incorrect because 'Manual approval' is not automated. Option E is incorrect because 'Azure Policy' is not a gate type in release pipelines, though it can be used via other integrations.

Full explanation →

710

Multi-Selectmedium

Which THREE measures should be implemented to protect secrets in Azure Pipelines? (Choose three.)

Select 3 answers

A.Restrict which pipelines can access the variable group

B.Log secret values to pipeline console for debugging

C.Use variable groups with locked variables

D.Link Azure Key Vault as a variable group

E.Store secrets in code as environment variables

AnswersA, C, D

Scoping access reduces exposure.

Why this answer

Options A, B, and D are correct. Option A: Using variable groups with locked variables prevents modification. Option B: Linking Azure Key Vault centrally manages secrets.

Option D: Limiting scope of secret-using pipelines reduces exposure. Option C is wrong because logging secrets to console exposes them. Option E is wrong because storing secrets in code defeats the purpose.

Full explanation →

711

MCQeasy

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?

A.Add a required reviewer policy for the branch.

B.Enable 'Automatically approve' for security group.

C.Code ownership policy with automatic reviewer assignment.

D.Branch policy with minimum number of reviewers.

AnswerC

Code ownership can auto-assign based on file patterns.

Why this answer

Option B is correct because code ownership policies allow automatic reviewer assignment based on file paths. Option A is wrong because branch policies are separate. Option C is wrong because auto-approve bypasses review.

Option D is wrong because required reviewers are for all PRs, not per folder.

Full explanation →

712

MCQhard

You are a DevOps engineer for a large enterprise that uses GitHub Enterprise Cloud. The development team follows a GitFlow branching strategy with develop, feature, release, and main branches. The release branch is created from develop when a release is ready. After testing, the release branch is merged into main and then tagged. However, the team frequently forgets to merge release branches back into develop, causing hotfixes applied to main to not be in develop. You need to implement an automated process to ensure that after a release branch is merged into main, the changes are also merged back into develop. The solution must not require manual intervention and must handle merge conflicts gracefully by opening a pull request for conflict resolution. Which approach should you use?

A.Configure a branch protection rule on main that requires a pull request to merge into develop.

B.Create a GitHub Actions workflow that triggers on push to main, attempts to merge main into develop, and if conflicts occur, opens a pull request for manual resolution.

C.Create a scheduled workflow that runs daily and merges main into develop if there are no conflicts.

D.Set up a webhook in GitHub that calls an Azure Function to merge main into develop.

AnswerB

This automates the merge and handles conflicts with a PR.

Why this answer

Option B is correct because it uses a GitHub Actions workflow triggered on pushes to main to automatically merge main into develop. If conflicts arise, the workflow opens a pull request for manual resolution, ensuring no changes are lost and the process remains automated without manual intervention.

Exam trap

The trap here is that candidates may choose a scheduled workflow (Option C) thinking it is sufficient, but it fails to handle merges that occur between scheduled runs and does not gracefully manage merge conflicts by opening a pull request.

How to eliminate wrong answers

Option A is wrong because a branch protection rule on main requiring a pull request to merge into develop does not automate the merge process; it only enforces a policy, leaving the team to remember to perform the merge. Option C is wrong because a scheduled daily workflow may miss merges that occur between runs, and it does not handle conflicts gracefully by opening a pull request—it only merges if there are no conflicts, which could silently skip merges. Option D is wrong because setting up a webhook to call an Azure Function introduces unnecessary complexity and external dependencies, and it does not natively handle merge conflicts by opening a pull request within GitHub.

Full explanation →

713

MCQhard

An organization uses an on-premises Jenkins server to build Docker images and push them to Azure Container Registry (ACR). The security team requires that all images be scanned for vulnerabilities before deployment. The DevOps team needs to automate this scanning after each push. What is the most efficient way to meet this requirement?

A.Use Azure Policy to enforce vulnerability scanning.

B.Configure a Jenkins job to scan images before pushing to ACR.

C.Configure a webhook in ACR to notify Jenkins to scan the image.

D.Create an ACR task that runs a vulnerability scanner triggered by image push events.

AnswerD

ACR tasks can be triggered by push events and run custom steps like scanning.

Why this answer

Option D is correct because ACR Tasks natively support automated vulnerability scanning via integration with Azure Security Center or third-party scanners like Trivy. By creating an ACR task that triggers on image push events, the organization can scan images immediately after they are pushed without additional infrastructure or manual intervention. This approach is event-driven, serverless, and aligns with the requirement to automate scanning after each push.

Exam trap

The trap here is that candidates may confuse Azure Policy with an action that performs scanning, or assume ACR webhooks can directly trigger Jenkins jobs for scanning, when in fact ACR Tasks provide a simpler, event-driven, and fully managed solution for post-push scanning.

How to eliminate wrong answers

Option A is wrong because Azure Policy can enforce compliance rules (e.g., requiring scanning) but does not perform the actual vulnerability scanning; it only audits or denies resources that don't meet policy definitions, not trigger scans. Option B is wrong because scanning images before pushing to ACR would require the Jenkins job to pull the image back or scan locally, which adds latency and complexity, and does not leverage the push event as required. Option C is wrong because ACR does not support webhooks that notify Jenkins of push events for vulnerability scanning; ACR webhooks can trigger actions like sending notifications or invoking HTTP endpoints, but they are not designed to initiate scanning workflows directly, and this approach would require custom Jenkins plugin configuration and polling, making it less efficient than a native ACR task.

Full explanation →

714

Multi-Selectmedium

Which TWO practices should you adopt to improve the security of your Azure DevOps pipeline? (Choose two.)

Select 2 answers

A.Grant the least privilege to service connections

B.Use Azure Key Vault to store secrets and fetch them at runtime

C.Use the default hosted agent for all builds

D.Store secrets as plain text in pipeline variables

E.Allow contributors to bypass the required reviewer policy

AnswersA, B

Least privilege minimizes potential damage.

Why this answer

Options B and D are correct. B reduces the attack surface by limiting permissions. D ensures secrets are not stored in code.

A is wrong because using the default agent may expose the pipeline to untrusted code. C is wrong because it bypasses security reviews.

Full explanation →

715

Multi-Selecthard

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

Select 3 answers

A.Use hardcoded secrets in workflow files for simplicity.

B.Enable secret scanning to detect secrets in code pushes.

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

D.Use OpenID Connect (OIDC) to authenticate to Azure without storing credentials.

E.Store secrets as GitHub repository secrets or organization secrets.

AnswersB, D, E

Secret scanning alerts on exposed secrets.

Why this answer

Options A, C, and D are correct: Using GitHub Secrets to store secrets, using OpenID Connect to authenticate to cloud providers without storing credentials, and enabling secret scanning to detect accidentally committed secrets. Option B is incorrect because hardcoding secrets is insecure. Option E is incorrect because using the same secret across environments reduces security.

Full explanation →

716

MCQeasy

You have an Azure DevOps Pipeline that builds a Node.js application. The pipeline uses template expressions to conditionally run certain jobs based on the branch name. You notice that the condition 'eq(variables['Build.SourceBranch'], 'refs/heads/main')' is not evaluating as expected. What is the most likely cause?

A.The variable 'Build.SourceBranch' is misspelled; it should be 'Build.SourceBranchName'.

B.The condition syntax is correct but the branch name should not include 'refs/heads/'.

C.The variable 'Build.SourceBranch' is not available in the condition context.

D.The condition should be in a template expression instead of a runtime condition.

AnswerA

'Build.SourceBranchName' returns the branch name without 'refs/heads/'.

Why this answer

In Azure DevOps YAML pipelines, variables are evaluated at runtime. The correct way to reference the source branch variable is 'variables['Build.SourceBranch']' or '$(Build.SourceBranch)'. Option C is correct because the condition syntax 'eq(variables['Build.SourceBranch'], 'refs/heads/main')' is valid and should work; the issue is likely that the variable name is misspelled or the branch name is incorrect.

However, the most common mistake is using 'SourceBranchName' instead of 'SourceBranch'. Option A is incorrect because template expressions are evaluated at compile time, but conditions are runtime. Option B is correct: using 'SourceBranchName' would give only the branch name without 'refs/heads/'.

Option D is irrelevant.

Full explanation →

717

MCQmedium

You maintain a classic release pipeline that deploys to multiple environments. You need to ensure that a deployment to the Production environment only proceeds after a manual approval from a specific group of users. Which feature should you configure?

A.Post-deployment approvals on the Production environment

B.Deployment queue settings on the Production environment

C.Deployment gates on the Production environment

D.Pre-deployment approvals on the Production environment

AnswerD

Correct: Pre-deployment approvals pause before deploying to that environment.

Why this answer

Option A is correct because pre-deployment approvals can be set on the Production environment. Option B is wrong because post-deployment approvals occur after deployment. Option C is wrong because gates are automated checks, not manual approvals.

Option D is wrong because deployment queue settings control parallelism, not approvals.

Full explanation →

718

MCQmedium

Your build pipeline uses a YAML template to define steps. You want to pass a parameter to the template to conditionally run a task. What syntax should you use in the template?

A.parameters:

B.arguments:

C.inputs:

D.variables:

AnswerA

Template parameters are defined under 'parameters'.

Why this answer

Option C is correct because 'parameters' is the correct YAML key to define template parameters. Option A is wrong because 'inputs' is for task inputs. Option B is wrong because 'variables' are for pipeline variables.

Option D is wrong because 'arguments' is not a valid key.

Full explanation →

719

MCQmedium

Refer to the exhibit. You are reviewing the branch policy configuration for the main branch in Azure DevOps. The policy requires a successful status check for 'continuous-integration/azure-devops' but not for 'security-scanner'. The minimum approver count is 0 and direct push is disallowed. What is the effect of this policy?

A.Developers can push directly to main without a pull request.

B.Pull requests require at least two reviewers.

C.Both status checks are required to pass.

D.Pull requests must pass the 'continuous-integration/azure-devops' check, but no reviewer approval is needed.

AnswerD

Minimum approver count is 0, so no approval required; only the required status check must pass.

Why this answer

The policy requires a successful status check for 'continuous-integration/azure-devops' but not for 'security-scanner'. With a minimum approver count of 0 and direct push disallowed, pull requests must pass the required CI check, but no reviewer approval is needed. This means the PR can be completed automatically once the CI check passes, without any human reviewer.

Exam trap

The trap here is that candidates assume 'minimum approver count = 0' means direct push is allowed, or that all listed status checks are required, when in fact only explicitly selected checks are mandatory.

How to eliminate wrong answers

Option A is wrong because direct push is disallowed, so developers cannot push directly to main without a pull request. Option B is wrong because the minimum approver count is 0, meaning no reviewer approval is required, not at least two. Option C is wrong because the policy explicitly requires only 'continuous-integration/azure-devops' to pass; 'security-scanner' is not required.

Full explanation →

720

MCQhard

Your company has a large monorepo with multiple microservices. You have a single YAML-based Azure Pipeline that builds the entire solution on every commit to the main branch. The pipeline takes over an hour to complete, causing long feedback loops. Developers often submit changes to only one service, but the whole pipeline runs. You need to reduce build time while maintaining quality. You are considering splitting the pipeline into multiple pipelines, each for a service, and using path triggers. However, some services have dependencies on shared libraries that are updated infrequently. You also need to ensure that integration tests that span multiple services still run when necessary. What should you do?

A.Create separate pipelines for each service with path triggers, and create an additional comprehensive pipeline that triggers only when shared libraries change.

B.Keep the single pipeline but add caching for dependencies.

C.Use a single pipeline but add conditional stages to skip unchanged services.

D.Create separate pipelines for each service with path triggers, and disable the comprehensive pipeline.

AnswerA

This optimizes build time while preserving integration testing.

Why this answer

Option A is correct because it uses path triggers to run only the pipeline for the changed service, drastically reducing build time. The additional comprehensive pipeline, triggered only when shared libraries change, ensures that integration tests spanning multiple services still run when dependencies are updated, maintaining quality.

Exam trap

The trap here is that candidates may think caching (Option B) or conditional stages (Option C) are sufficient, but they fail to address the need for integration tests across services when shared libraries change, which requires a separate comprehensive pipeline with path triggers.

How to eliminate wrong answers

Option B is wrong because caching dependencies reduces build time for repeated steps but does not address the core issue of running the entire pipeline for every commit, including unchanged services. Option C is wrong because conditional stages to skip unchanged services still require evaluating the entire pipeline, and Azure Pipelines does not natively support skipping stages based on changed paths without complex scripting; it also does not solve the integration test problem for shared library changes. Option D is wrong because disabling the comprehensive pipeline means integration tests that span multiple services will not run when shared libraries change, breaking the requirement to maintain quality.

Full explanation →

721

MCQmedium

Your team uses Azure Pipelines to deploy a Node.js application. Recently, deployments have been failing intermittently due to a missing npm package. The pipeline runs successfully on the local agent but fails on the hosted agent. Which instrumentation strategy should you implement to identify the root cause?

A.Replace the hosted agent with a self-hosted agent.

B.Configure Application Insights for the Node.js app to monitor runtime errors.

C.Enable verbose logging for the npm install task and compare the output between pipeline runs.

D.Add a pipeline cache task for npm packages to ensure consistent restore.

AnswerC

Verbose logging shows detailed dependency resolution steps.

Why this answer

Option A is correct because enabling verbose logging and comparing the npm install output between agents can reveal differences in package resolution. Option B is wrong because pipeline caching would mask the issue. Option C is wrong because telemetry from the application does not capture build-time dependency issues.

Option D is wrong because self-hosted agents would not match the hosted environment.

Full explanation →

722

MCQhard

You are designing a Git branching strategy for a large enterprise with multiple Azure DevOps projects. The strategy must support hotfixes for production releases, feature development in isolated branches, and release branches for stabilization. The team uses CI/CD pipelines that trigger on branch creation. You need to minimize merge conflicts and ensure that hotfix changes are propagated to all active branches. Which branching model should you recommend and how should you configure branch policies?

A.Use GitHub Flow with feature branches merging directly to main. Use a release branch for stabilization. Use pull requests for all merges.

B.Use trunk-based development with short-lived feature branches. Use feature toggles for incomplete work. No separate hotfix branch.

C.Use a forking workflow where each developer forks the repository and submits pull requests. Use branch policies on the upstream main branch.

D.Use GitFlow with main, develop, and hotfix branches. Configure branch policies on main and develop to enforce pull requests with required reviewers. Use a pipeline to automatically merge hotfix branches into both main and develop.

AnswerD

GitFlow supports hotfix propagation; policies enforce quality.

Why this answer

Option A is correct because GitFlow with branch policies on main and develop that enforce hotfix merges via pull request ensures propagation. Option B (GitHub Flow) does not have dedicated hotfix branches and release branches. Option C (Trunk-Based) lacks hotfix isolation.

Option D (Forking) is for external contributions, not enterprise internal.

Full explanation →

723

MCQmedium

Your Azure DevOps project uses Git for source control. You want to enforce that all code changes are reviewed before merging into the main branch. Which branch policy should you enable?

A.Allow only comment resolution.

B.Require a successful build before merging.

C.Limit merge types to squash merge.

D.Require a minimum number of reviewers.

AnswerD

This policy enforces code review before merge.

Why this answer

Option A is correct because a branch policy requiring pull request reviews enforces code review before merge. Option B is wrong because build validation is separate. Option C is wrong because it restricts direct pushes but doesn't enforce review.

Option D is wrong because commenting doesn't enforce review.

Full explanation →

724

MCQeasy

You ran the above Azure CLI command to check the deployment source of an Azure Web App. The web app is not deploying automatically when commits are pushed to the main branch. Based on the output, what is the most likely cause?

A.Deployment rollback is disabled, preventing automatic deployments.

B.The continuous deployment sync is not enabled; you need to enable it or configure a pipeline.

C.The branch is set to 'main' but commits are pushed to 'master'.

D.The repo URL uses GitHub but Azure Web Apps only supports Azure Repos.

AnswerB

The output shows the source but not that CD is active; likely sync is off.

Why this answer

Option D is correct because the output does not show a CI/CD trigger; it only shows the source. The web app may have disconnected sync. Option A is wrong because branch is main.

Option B is wrong because deployment rollback is disabled, which is fine. Option C is wrong because GitHub is supported.

Full explanation →

725

MCQmedium

Refer to the exhibit. A release is created with the above command. The Dev environment starts deploying, but the Prod environment does not. Which is the most likely reason?

A.The Prod environment requires manual approval before deployment.

B.The release definition ID 5 is incorrect.

C.The Prod environment has a pre-deployment condition that waits for the Dev environment to succeed.

D.The build artifact with ID 123 is not accessible.

AnswerC

By default, release environments can be set to deploy only after previous environments succeed, which would cause Prod to wait for Dev.

Why this answer

The release is created successfully with two environments: Dev and Prod. Dev is in progress, but Prod is not started. This suggests that the release pipeline is configured with a trigger condition that delays or gates the Prod deployment until after Dev completes successfully.

Also, note that 'preDeployApprovals' are empty, so approvals are not the issue.

Full explanation →

726

MCQeasy

A team wants to automatically destroy a temporary test environment after a pull request is merged or closed. What Azure DevOps feature should they use?

A.Environment with post-deployment approvals

B.Branch policy with required reviewers

C.Pipeline trigger on branch deletion

D.Service hook to Azure Functions

AnswerA

Post-deployment approvals can trigger a cleanup job when the environment is no longer needed.

Why this answer

Option A is correct because Azure DevOps Environments support post-deployment approvals and can be configured with a deployment job that automatically triggers resource cleanup when a pull request is merged or closed. By defining a 'destroy' job in the YAML pipeline that runs only on the 'post-deployment' trigger of an environment, the team can tear down the temporary test environment without manual intervention.

Exam trap

The trap here is that candidates often confuse pipeline triggers on branch deletion (Option C) with environment lifecycle events, not realizing that branch deletion triggers do not inherently respond to pull request merge/close events and lack the built-in environment management capabilities of deployment jobs with post-deployment gates.

How to eliminate wrong answers

Option B is wrong because branch policies with required reviewers control code review and merge gates, not the lifecycle of deployed environments. Option C is wrong because pipeline triggers on branch deletion fire when a branch is removed from the repository, but they do not inherently know about pull request merge or close events, and they cannot automatically destroy a test environment without additional custom logic. Option D is wrong because service hooks to Azure Functions can be used to trigger external processes on pull request events, but they are not a built-in Azure DevOps feature for environment lifecycle management; they require custom code and do not integrate directly with Azure Pipelines environment cleanup.

Full explanation →

727

MCQmedium

Your team uses Azure Boards to manage work items. You need to ensure that when a work item is moved to 'Closed', all linked pull requests in Azure Repos are automatically completed. What should you configure?

A.Service hook to a custom Azure Function

B.Work item 'Pull Request' tab

C.Work item rule (state transition rule)

D.Branch policy on the target branch

AnswerC

Azure Boards supports rules that automatically complete linked PRs when a work item is closed.

Why this answer

Option D is correct because Azure Boards can be configured with a rule that automates PR completion when a work item state changes. Option A is wrong because branch policies do not react to work item changes. Option B is wrong because service hooks can trigger webhooks but not directly complete PRs; a custom function would be needed.

Option C is wrong because the 'Pull Request' tab is informational.

Full explanation →

728

Multi-Selecteasy

Your organization uses GitHub Actions for CI/CD. You need to ensure that workflows are only triggered when changes are pushed to the main branch or when a pull request is opened against main. Which two trigger types should you specify in the workflow?

Select 2 answers

A.pull_request: branches: [ main ]

B.push: branches: [ main ]

C.release

D.workflow_dispatch

E.schedule

AnswersA, B

Correct: Triggers on PR targeting main.

Why this answer

Options A and C are correct. Option A triggers on push to main. Option C triggers on pull request events targeting main.

Option B is wrong because workflow_dispatch is manual. Option D is wrong because schedule is time-based. Option E is wrong because release triggers on GitHub releases.

Full explanation →

729

MCQeasy

Your team is using GitHub Actions to deploy a containerized application to Azure Kubernetes Service (AKS). You need to securely authenticate the workflow to AKS without storing credentials in the repository. What should you use?

A.Use OpenID Connect (OIDC) with a federated identity credential.

B.Use the GITHUB_TOKEN to authenticate to Azure.

C.Use an SSH deploy key to authenticate to AKS.

D.Store an Azure service principal password as a GitHub secret.

AnswerA

OIDC allows passwordless authentication from GitHub Actions to Azure.

Why this answer

OpenID Connect allows workflows to authenticate to Azure without secrets by exchanging tokens. Option A is wrong because PATs are stored as secrets. Option C is wrong because SSH keys are for code access.

Option D is wrong because GitHub tokens are for GitHub API, not Azure.

Full explanation →

730

Multi-Selecthard

Which THREE are benefits of using a monorepo with Azure Repos and CI/CD pipelines?

Select 3 answers

A.Granular repository-level permissions

B.Faster build times due to smaller codebase

C.Easier code sharing across projects

D.Simplified dependency management

E.Atomic cross-component commits

AnswersC, D, E

Shared libraries are in the same repo.

Why this answer

Option C is correct because a monorepo enables easier code sharing across projects by allowing multiple teams to reference the same source files, libraries, and modules without needing separate package feeds or cross-repo synchronization. In Azure Repos, this means you can use common build artifacts and shared code directly within the same repository, reducing duplication and simplifying collaboration.

Exam trap

The trap here is that candidates confuse the benefits of a monorepo with those of a multi-repo setup, assuming that a monorepo inherently improves build times or permissions granularity, when in reality it often worsens both without specific pipeline optimizations like sparse checkout or path-based triggers.

Full explanation →

731

MCQmedium

You are configuring a YAML pipeline that deploys to multiple environments. The pipeline should automatically trigger when changes are pushed to the main branch, but only if the build artifact changes. Which trigger configuration should you use?

A.trigger: branches: include: - main

B.trigger: paths: include: - src/*

C.pr: branches: include: - main

D.resources: containers: - container: myContainer

AnswerB

Why this answer

Option B is correct because the `trigger: paths: include: - src/*` configuration specifies that the pipeline should only trigger when changes are pushed to the `main` branch AND those changes affect files under the `src/` directory. This ensures that the pipeline runs only when the build artifact (source code) changes, not for other changes like documentation or configuration files. The `paths` filter works in conjunction with the branch filter to provide fine-grained control over pipeline triggers.

Exam trap

The trap here is that candidates often confuse the `trigger` and `pr` keywords, or assume that a branch trigger alone is sufficient, forgetting that path filtering is required to restrict triggers to specific file changes.

Why the other options are wrong

A

This triggers on any change to main, regardless of artifact changes.

C

This triggers on pull request to main, not on pushes.

D

This defines a container resource, not a trigger.

Full explanation →

732

MCQeasy

You are configuring a release pipeline to deploy to Azure App Service. You want to use the 'Deploy Azure App Service' task. Which authentication method should you use to securely connect Azure DevOps to the Azure subscription?

A.Azure CLI authentication with a user account.

B.Azure Resource Manager service connection using a service principal.

C.Use a SAS token for the App Service.

D.Managed Identity assigned to the Azure DevOps agent.

AnswerB

Service principal provides secure, automated authentication.

Why this answer

Option B is correct because the Azure Resource Manager service connection with Service Principal authentication is the recommended and secure method. Option A is wrong because Azure CLI does not provide persistent service connection. Option C is wrong because Managed Identity is not directly used by Azure DevOps.

Option D is wrong because SAS tokens are for storage, not App Service.

Full explanation →

733

MCQmedium

Your organization uses Azure Pipelines and wants to enforce that all builds must pass a security scan before being deployed to production. The security scan is performed by a third-party tool that is not available as a built-in task. You have installed the tool on a self-hosted agent. What is the best way to integrate the security scan into the pipeline?

A.Add the tool as a capability of the agent pool and use the 'Install Tool' task.

B.Add the 'Run Security Scan' task from the Azure DevOps marketplace.

C.Create a custom service hook to trigger the scan externally and wait for results.

D.Use a command-line task (e.g., Bash, PowerShell) to execute the security scan tool.

AnswerD

You can run any command-line tool installed on the agent via a script task.

Why this answer

Option C is correct because you can use a command-line script task (e.g., bash, PowerShell) to run the security scan tool installed on the agent. Option A is wrong because there is no generic 'Run Security Scan' task. Option B is wrong because the third-party tool may not have an API.

Option D is wrong because you would need to execute it, not just install it.

Full explanation →

734

MCQhard

You are setting up a GitHub Actions workflow to deploy a containerized application to Azure Kubernetes Service (AKS). You need to securely authenticate to the AKS cluster using a service principal. What is the recommended way to store and use the service principal credentials?

A.Use managed identity for GitHub Actions and assign it to the AKS cluster

B.Store the service principal credentials in a Kubernetes secret in the AKS cluster

C.Store the service principal credentials as GitHub Actions secrets and reference them in the 'azure/login' action

D.Store the service principal credentials as environment variables in the workflow file

AnswerC

Secrets are encrypted and can be used securely with the 'azure/login' action.

Why this answer

Option B is correct because GitHub Actions secrets are encrypted and the 'azure/login' action can use them. Option A is wrong because environment variables are exposed in logs. Option C is wrong because the Kubernetes secret is for cluster secrets, not workflow secrets.

Option D is wrong because the service principal is not stored in AKS.

Full explanation →

735

MCQhard

Your team uses trunk-based development with short-lived feature branches. You notice that code reviews often delay merging because reviewers are not available. What is the best way to reduce review latency while maintaining quality?

A.Enable auto-merge for pull requests that have passed all checks.

B.Require only one reviewer instead of two.

C.Create a separate review team that only handles pull requests.

D.Encourage pair programming or mob programming to review code in real-time.

AnswerD

Real-time review eliminates async delays.

Why this answer

Option B is correct because pair programming or mob programming can reduce the need for asynchronous reviews as code is reviewed in real-time. Option A is incorrect because reducing reviewer count may lower quality. Option C is incorrect because automatic merging bypasses review.

Option D is incorrect because a separate review team introduces bottlenecks.

Full explanation →

736

MCQhard

You are deploying a multi-container application to Azure Kubernetes Service (AKS) using Azure Pipelines. You need to ensure that the deployment rollback automatically if the health checks fail. Which strategy should you implement?

A.Configure a rolling update with readiness and liveness probes

B.Use a blue-green deployment strategy

C.Use Helm charts with pre-upgrade hooks

D.Implement a canary deployment with manual verification

AnswerA

Kubernetes automatically rolls back if probes fail.

Why this answer

Option B is correct because Kubernetes deployment strategy with health probes enables automatic rollback. Option A is wrong because blue-green does not automatically rollback. Option C is wrong because canary does not automatically rollback.

Option D is wrong because Helm alone does not provide health check-based rollback.

Full explanation →

737

Multi-Selecthard

Which THREE features are available in GitHub Actions for managing secrets across environments?

Select 3 answers

A.Encrypted variables in workflows

B.Organization-level secrets

C.Secret scanning alerts

D.Environment-specific secrets

E.Repository-level secrets

AnswersB, D, E

Organization secrets are available to all repositories in the organization.

Why this answer

Options B, C, and D are correct. Environments in GitHub Actions allow secret scoping, organization secrets are available across repos, and repository secrets are scoped to a single repo. Option A is secret scanning, which is a security feature but not for managing secrets across environments.

Option E is about encrypted variables, which is redundant with secrets.

Full explanation →

738

MCQeasy

You need to configure a build pipeline that triggers only when changes are pushed to the 'release/*' branch. Which trigger configuration should you use?

A.Set 'trigger: none' in YAML

B.Set 'trigger: branches: include: - release/*'

C.Set 'trigger: branches: include: - main'

D.Set 'trigger: tags: include: - v*'

AnswerB

This triggers on any branch matching release/*.

Why this answer

Option C is correct because specifying a branch filter with wildcard triggers on release branches. Option A is wrong because it triggers on all branches. Option B is wrong because it disables CI.

Option D is wrong because it triggers on tags only.

Full explanation →

739

MCQmedium

The exhibit shows a deployment job in an Azure Pipelines YAML file. The deployment fails with the error 'No package found with pattern: $(Pipeline.Workspace)/drop/*.zip'. What is the most likely cause?

A.The artifact is not downloaded to the expected path; the artifact name must be included in the path.

B.The wildcard pattern '*.zip' is not supported.

C.The Azure service connection has expired.

D.The pipeline is using a Microsoft-hosted agent that does not support the download task.

AnswerA

The downloaded artifact is placed under '$(Pipeline.Workspace)/<artifact name>/'. If the artifact is named 'drop', the correct path is '$(Pipeline.Workspace)/drop'.

Why this answer

Option C is correct because the 'download: current' step downloads the artifact from the current pipeline run, but the artifact path usually includes the artifact name as a subfolder. The correct path would be '$(Pipeline.Workspace)/drop' or '$(Pipeline.Workspace)/drop/**/*.zip'. Option A is wrong because the service connection is unrelated to the artifact.

Option B is wrong because the wildcard is valid. Option D is wrong because the agent type does not affect artifact download behavior.

Full explanation →

740

MCQhard

You need to implement a strategy to manage secrets for your multi-stage YAML pipeline. The pipeline runs on Microsoft-hosted agents. Which approach should you use to securely pass secrets to pipeline tasks?

A.Define the secrets as environment variables in the pipeline YAML directly.

B.Use the Azure Key Vault task to download secrets and then pass them as parameters.

C.Use pipeline variables with 'secret: true' and reference them as $(variableName).

D.Store secrets in a file in the repository and read it during the build.

AnswerC

Secret variables are encrypted and masked in logs.

Why this answer

Option D is correct because using variables with 'secret: true' in the YAML pipeline and referencing them as $(variableName) is the recommended way. Option A is wrong because environment variables are not secure in YAML. Option B is wrong because hardcoding is insecure.

Option C is wrong because Azure Key Vault task should be used to fetch secrets into variables.

Full explanation →

741

Multi-Selecthard

Which TWO of the following are valid ways to trigger a pipeline in Azure DevOps when a pull request is created?

Select 2 answers

A.Pull request trigger in YAML pipeline

B.Scheduled trigger

C.Continuous integration trigger

D.Branch policy with build validation

E.Pipeline completion trigger

AnswersA, D

YAML pipelines can define PR triggers using the 'pr:' keyword.

Why this answer

Option A is correct because Azure DevOps YAML pipelines support a `pr` trigger that automatically runs the pipeline when a pull request is created or updated. This trigger is defined directly in the YAML file and can be scoped to specific branches or paths, making it a native and flexible way to respond to PR events.

Exam trap

The trap here is that candidates often confuse the continuous integration trigger (which fires on push) with the pull request trigger, or they overlook that branch policy build validation is a separate but equally valid method to trigger a pipeline on PR creation.

Full explanation →

742

Multi-Selecthard

Which THREE factors should you consider when designing a strategy for managing secrets in Azure Pipelines? (Choose three.)

Select 3 answers

A.Hardcode secrets in the pipeline YAML for simplicity.

B.Store secrets as plain text variables in YAML pipelines.

C.Use Azure Key Vault to store secrets.

D.Use a library variable group linked to Azure Key Vault.

E.Reference secrets as secret variables in pipeline tasks.

AnswersC, D, E

Key Vault is the recommended service for storing secrets.

Why this answer

Options A, C, and E are correct. Secrets should be stored in Azure Key Vault, retrieved using library variable groups linked to Key Vault, and referenced as secret variables. Option B is incorrect because variables in YAML are visible in logs.

Option D is incorrect because hardcoding secrets is insecure.

Full explanation →

743

MCQhard

The exhibit shows a parameters file for an ARM template deployment. During a release pipeline, the deployment fails with the error 'The provided value for the template parameter 'sku' is not valid'. The ARM template defines the 'sku' parameter as an allowed value set of ['F1', 'D1', 'B1', 'S1']. What could be the issue?

A.The parameter file contains an extra space or hidden character in the 'sku' value.

B.The parameter file is missing the '$schema' property.

C.The 'sku' parameter is defined in the 'variables' section instead of 'parameters'.

D.The ARM template expects a different API version for the resource.

AnswerA

Even though 'S1' appears correct, hidden characters can cause the value to not match the allowed values.

Why this answer

Option A is correct because the error indicates that the provided value 'S1' is not in the allowed values, but the exhibit shows 'S1', which should be valid. However, the error could occur if the parameter file has a typo or extra whitespace that makes it invalid. Option B is wrong because the parameter file is properly formatted.

Option C is wrong because the schema version is correct. Option D is wrong because the parameter file does not include 'sku' in the wrong section.

Full explanation →

744

MCQhard

Refer to the exhibit. You are reviewing the branch policies for the main branch in Azure Repos. The team reports that while the branch naming policy works, the approval policy does not block pull requests when only one person approves. What is the most likely cause?

A.The policy is disabled in the settings

B.The policy is not applied to the main branch

C.The main branch has a separate branch policy override that allows one approval

D.The 'creatorVoteCounts' setting is false, so the creator's approval is not counted

AnswerC

Branch policies can be overridden at the branch level, which could allow fewer approvals.

Why this answer

Option C (The policy is applied to all branches, but the main branch has a separate override) is correct. The exhibit shows policies defined at the project level, but branch policies for the main branch might have been explicitly set to override the project-level policy. Option A is wrong because the policy is enabled.

Option B is wrong because the policy is set to require minimum 2 approvals, so it should block. Option D is wrong because creator vote counts being false means the creator's vote is not counted, which doesn't affect the approval count.

Full explanation →

745

MCQeasy

A company uses Azure DevOps and needs to ensure that all pipelines use approved YAML templates from a central repository. The security team wants to prevent developers from referencing unapproved templates. What is the best way to enforce this?

A.Create a branch policy on the repository that requires all pull requests to be approved by security team members.

B.Configure a variable group with the approved template repository and require it in all pipelines.

C.Use a pipeline decorator to check the template origin and fail the pipeline if unapproved.

D.Set the 'Required template' repository setting in the Azure DevOps project to the approved central repository.

AnswerD

This built-in setting enforces that all YAML templates must come from the specified repository.

Why this answer

Option D is correct because the 'Required template' repository setting in Azure DevOps enforces that all pipelines must use a YAML template from a specified central repository. If a pipeline references a template from any other location, the pipeline will fail at runtime, providing a hard enforcement mechanism that cannot be bypassed by developers. This directly addresses the security team's requirement to prevent unapproved template references.

Exam trap

The trap here is that candidates often confuse pipeline decorators (which are custom and optional) with native enforcement settings, or they assume branch policies can control template references, when in fact only the 'Required template' setting provides a hard, built-in block at the pipeline level.

How to eliminate wrong answers

Option A is wrong because a branch policy requiring pull request approval by security team members only controls changes to the repository's code, not the templates referenced in pipelines; developers could still merge code that references unapproved templates in other repositories. Option B is wrong because a variable group can store the approved repository URL, but it does not enforce that pipelines actually use it; developers can still hardcode or override the template source in their YAML files. Option C is wrong because pipeline decorators are injected at runtime and can check template origins, but they are not a native enforcement mechanism; they require custom scripting and maintenance, and can be bypassed if the decorator is not applied to all pipelines or if the pipeline agent has sufficient permissions.

Full explanation →

746

Drag & Dropmedium

Drag and drop the steps to perform a blue-green deployment in Azure using App Service slots into the correct order.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

Why this order

Blue-green deployment involves creating a slot, deploying to it, validating, swapping, and monitoring.

Full explanation →

747

MCQmedium

What is the most likely cause of this error?

A.The variable group is not linked to the Key Vault

B.The service connection does not have 'Get' permission on the Key Vault

C.The secret name in Key Vault does not match 'myKeyVaultSecret'

D.Pipeline variables cannot reference Key Vault secrets

AnswerC

The secret name must match exactly.

Why this answer

Option D is correct because the secret name in Key Vault must match exactly. Option A is wrong because the variable group is linked. Option B is wrong because missing permissions would give a different error.

Option C is wrong because variable groups are supported.

Full explanation →

748

MCQhard

You are the DevOps lead for a financial services company. The company uses Azure DevOps Services with a single project containing multiple teams. The compliance team requires that all production deployments be approved by a change advisory board (CAB) member. Additionally, any deployment that changes a configuration value stored in Azure App Configuration must be audited. You have set up a release pipeline with a manual approval gate and a pre-deployment condition that runs a PowerShell script to validate configuration changes. However, the compliance team reports that some deployments bypassed the approval gate. Upon investigation, you find that developers with 'Edit release pipeline' permissions can modify the pipeline and remove the approval gate. You need to ensure that the approval gate cannot be bypassed by developers. You also need to ensure that any change to a configuration key is logged to Azure Monitor. What should you do?

A.Create a new service connection with limited permissions and require that all pipeline runs use it. Use an Azure Policy to audit configuration changes.

B.Configure environment-level approvals in the release pipeline and use Azure Policy to enforce that all deployments go through the environment. Use diagnostic settings on App Configuration to stream logs to Azure Monitor.

C.Implement a branch policy on the release pipeline's YAML file in the repository to require approval for changes. Use a webhook to send configuration change events to Azure Monitor.

D.Create a protected variable group that stores the approval gate configuration and set the pipeline to use it. Restrict edit permissions on the release pipeline to a security group that does not include developers. For configuration changes, use an Azure Resource Manager template with a deployment script that sends logs to Azure Monitor.

AnswerD

Protected variable groups and restricted permissions prevent bypassing approvals; ARM template with script logs changes.

Why this answer

Option D is correct because it addresses both requirements: restricting pipeline edit permissions to a security group that excludes developers prevents them from removing the approval gate, and using an ARM template with a deployment script that sends logs to Azure Monitor ensures configuration changes are audited. Protected variable groups secure sensitive configuration, but the key is permission separation and audit logging via ARM deployment scripts.

Exam trap

The trap here is that candidates assume environment-level approvals or branch policies alone are sufficient, but they overlook that users with 'Edit release pipeline' permissions can bypass these controls by modifying the pipeline definition.

How to eliminate wrong answers

Option A is wrong because creating a new service connection with limited permissions does not prevent developers with 'Edit release pipeline' permissions from modifying the pipeline to bypass the approval gate; Azure Policy audits Azure resources but does not enforce pipeline-level approval gates. Option B is wrong because environment-level approvals in a release pipeline can still be bypassed if developers have 'Edit release pipeline' permissions to remove the environment or its approvals; Azure Policy does not enforce pipeline deployment flows. Option C is wrong because a branch policy on the YAML file only protects changes to the pipeline definition, not runtime bypass of the approval gate, and webhooks for configuration change events do not replace the need for audit logging to Azure Monitor via diagnostic settings or deployment scripts.

Full explanation →

749

MCQhard

Refer to the exhibit. Your team uses a classic build pipeline. You notice that test assemblies are not being found during the Test phase. Which change resolves the issue?

A.Change testSelector to 'testMethod'

B.Use fully qualified paths in testAssemblyVer2

C.Add buildConfiguration: 'Release' to the DotNetCoreCLI task

D.Set searchFolder to $(Build.BinariesDirectory)

AnswerD

Test DLLs are in the build output folder.

Why this answer

The VSTest task searches for test DLLs in the source folder, but the build output goes to a subfolder like $(Build.BinariesDirectory). Setting searchFolder to the correct output path allows discovery. Option B is wrong because using full paths is not necessary if searchFolder is correct.

Option C is wrong because buildConfiguration is already set correctly. Option D is wrong because the issue is not about failing tests but finding them.

Full explanation →

750

Multi-Selecteasy

Your team uses Azure DevOps and wants to automate the creation of a bug work item when a release pipeline fails. Which two actions should you take?

Select 2 answers

A.Set a scheduled trigger for the release pipeline.

B.Configure a Service Hook to create a work item when a release stage fails.

C.Add a build completion trigger to the release pipeline.

D.Add the 'Create work item on failure' task to the release pipeline.

E.Configure a pre-deployment approval.

AnswersB, D

Service Hooks can create work items on failure.

Why this answer

Option B is correct because Service Hooks in Azure DevOps allow you to integrate with external services and trigger actions, such as creating a work item in Azure Boards, when a release stage fails. Option D is correct because the 'Create work item on failure' task can be added directly to a release pipeline to automatically generate a bug work item upon failure, providing a built-in automation mechanism without external dependencies.

Exam trap

The trap here is that candidates may confuse triggers (scheduled or build completion) with event-driven actions, or assume that approvals can automate work item creation, when in fact only Service Hooks and the dedicated task directly create work items on failure.

Full explanation →

Page 10 of 13

All pages

1 2 3 4 5 6 7 8 9 10 11 12 13

Practice AZ-400 by domain

Target a specific domain to shore up weak areas.

Configure processes and communications Design and implement source control Design and implement build and release pipelines Develop a security and compliance plan Implement an instrumentation strategy Design and implement a DevOps infrastructure Design and implement a source control strategy

See all domains with question counts →