Microsoft Azure DevOps Engineer Expert AZ-400 AZ-400 Questions 451–525 | Page 7/11

451

MCQmedium

Your team uses a multi-stage YAML pipeline to build and deploy a .NET Core application. The build stage runs successfully, but the deployment to a Linux web app fails with an error indicating that the Kudu service cannot start because the startup command is missing. What is the most likely cause?

A.The pipeline is missing the 'AzureWebApp@1' task with a 'StartupCommand' parameter.

B.The service connection lacks permission to access the web app.

C.The web app is configured with a Windows runtime stack.

D.The build output does not include the web.config file.

AnswerA

On Linux-based Azure App Service, the runtime is containerized and requires an explicit entry point to start the application. The AzureWebApp@1 task (or AzureWebAppContainer@1 when deploying a container) exposes a StartupCommand parameter that injects this command (for example, `pm2 start /home/site/wwwroot/server.js`) into the App Service configuration. Without that parameter, the platform falls back to a default command that may not exist, producing the exact error about a missing startup command. The fix is to add the task with the appropriate StartupCommand, or to configure the startup command in the app's Application settings.

Why this answer

The Kudu service on Linux web apps requires a startup command to launch the .NET Core application. The 'AzureWebApp@1' task's 'StartupCommand' parameter specifies this command (e.g., 'dotnet myapp.dll'). Without it, Kudu cannot start the process, causing the deployment failure.

Exam trap

The trap here is that candidates might think the issue is a missing web.config file (common for Windows deployments) or a permission problem, but on Linux, the startup command is the critical missing piece, not a configuration file.

How to eliminate wrong answers

Option B is wrong because a permission issue would typically cause an authorization error (e.g., 403) during deployment, not a Kudu startup failure. Option C is wrong because the error explicitly occurs on a Linux web app; a Windows runtime stack would not cause a missing startup command error on Linux. Option D is wrong because .NET Core applications on Linux do not require a web.config file; they rely on a startup command or a process file (e.g., 'server.js' for Node.js) to start.

Full explanation →

452

MCQeasy

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

A.Pipeline decorators.

B.Environment checks.

C.Pre-deployment conditions with approval gates.

D.Post-deployment gates.

AnswerC

Pre-deployment conditions with approval gates define a manual approval step that must be completed by authorized reviewers before the deployment job is allowed to start, making it the correct way to include a manual validation step before deployment.

Why this answer

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

Exam trap

The trap here is confusing environment checks (which may include both automated and manual checks) with the specific pre-deployment approval gate feature. Environment checks can include an 'Approvals' check, but the question asks for the feature that explicitly models the pre-deployment approval workflow, which is 'Pre-deployment conditions with approval gates'.

How to eliminate wrong answers

Option A is wrong because pipeline decorators are used to automatically inject additional steps (e.g., security scans) into every pipeline run, not to pause for manual validation. Option B is wrong because environment checks are automated evaluations (e.g., resource availability, compliance) that run before deployment, but they do not provide a manual approval mechanism. Option D is wrong because post-deployment gates run after the deployment to production has already occurred, so they cannot serve as a manual validation step before deployment.

Full explanation →

453

Multi-Selectmedium

Your team uses GitHub Advanced Security to identify vulnerabilities in code. Which TWO actions can you take to ensure that critical security alerts are addressed before code is merged?

Select 2 answers

A.Enable secret scanning push protection.

B.Create a repository rule that allows bypassing pull request requirements.

C.Configure branch protection rules to require status checks from code scanning.

D.Enable Dependabot auto-merge for pull requests.

E.Use pull request annotations to display code scanning alerts.

AnswersC, E

Configuring branch protection rules to require code scanning status checks creates a hard merge gate: if CodeQL or other scanning tools detect critical vulnerabilities, the status check fails and the pull request is blocked. This enforces alert resolution before code can enter the protected branch, making it the correct answer.

Why this answer

Branch protection rules can require passing status checks from code scanning and secret scanning. Pull request annotations show alerts directly in the PR. Dependabot auto-merge and repository rules for bypassing are not relevant for blocking merges based on security alerts.

Full explanation →

454

Multi-Selecthard

You are building a comprehensive instrumentation strategy for a large-scale Azure DevOps environment. You need to ensure that all pipeline events (build, release, test) are automatically tracked and correlated with application performance data. Which THREE components should you include?

Select 3 answers

A.A shared Correlation ID that flows from pipeline to application.

B.Azure Monitor Workbooks to visualize pipeline data.

C.Custom pipeline tasks that send telemetry to Application Insights.

D.Azure Boards to track pipeline run metadata.

E.OpenTelemetry SDK in the application to emit trace context.

AnswersA, C, E

A shared Correlation ID that flows from pipeline to application is correct because it enables end-to-end traceability, linking build/release pipeline events to application telemetry. This ID is propagated via environment variables or HTTP headers, allowing every log, metric, and trace to be correlated across the CI/CD boundary, which is essential for diagnosing failures that span pipeline and runtime.

Why this answer

Options A, C, and E are correct. A shared Correlation ID (A) flows from pipeline to application, enabling end-to-end trace correlation. Custom pipeline tasks (C) send telemetry (e.g., build/release events) to Application Insights.

The OpenTelemetry SDK (E) emits trace context from the application, which can include the correlation ID. Option B is wrong because Azure Monitor Workbooks are visualization tools, not data collection components. Option D is wrong because Azure Boards is for work item tracking, not pipeline event capture.

Full explanation →

455

MCQhard

Your organization uses a monorepo in Azure Repos containing multiple microservices. You need to design a build pipeline that only builds and tests the services that have changed in a given commit, to optimize build times. The pipeline must trigger on any push to any branch, but only the affected services should be built. You also need to ensure that dependent services are rebuilt if their dependencies change. The services are located in subdirectories: /services/serviceA, /services/serviceB, etc. Each service has a Dockerfile and a unit test project. You plan to use a script to determine which services changed. Which approach should you use to implement this pipeline?

A.Use a script step to determine which services changed, then output variables to dynamically create a job matrix or use the 'each' keyword to iterate over changed services.

B.Create a multi-stage pipeline where each stage represents a service, and use a 'dependsOn' condition to run stages only if the corresponding service changed.

C.Create a single job that runs all unit tests for all services on every commit. Use caching to speed up the build.

D.Create a job for each service that runs in parallel on every commit. Use conditions to skip jobs if the service has not changed, but the conditions would need to check every service, which is complex.

AnswerA

A script step can run `git diff` against the previous commit or merge target to identify which services changed, then set output variables such as `ChangedServices=true,false`. The pipeline can later use these variables with YAML's `matrix` strategy or the `each` directive in template expressions to dynamically generate one job per changed service, ensuring only affected services are built and tested while keeping the pipeline fully data-driven and scalable.

Why this answer

Use a script to determine which services changed, then output variables to dynamically create a job matrix. This satisfies the requirement to only build affected services and handle dependency rebuilding if the script includes dependency detection. Option B is wrong because it requires a stage for every service upfront and is less dynamic.

Option C is wrong because it does not optimize build times. Option D is wrong because it creates all jobs and uses complex conditions to skip unchanged services.

Full explanation →

456

MCQmedium

Your organization needs to enforce that every commit to the main branch in Azure Repos is associated with a work item from Azure Boards. What should you configure?

A.Add a branch policy on main that requires a linked work item for all pushes.

B.Create a pre-receive hook in the repository to reject commits without a work item.

C.Enable the 'Gated check-in' option in the branch policy for main.

D.Configure a pull request policy that requires a linked work item, and enforce that all merges to main are via pull request.

AnswerD

Correct because by requiring all merges to main to be done via pull requests and enabling the 'Require a linked work item' policy on those pull requests, every commit to main will be associated with a work item.

Why this answer

In Azure Repos, the 'Require a linked work item' branch policy applies only to pull requests, not to direct pushes. To enforce that every commit to main is associated with a work item, you must require that all changes come through pull requests (via a branch policy requiring PRs) and then enable the 'Require a linked work item' policy on pull requests. This ensures that every commit merged into main via a PR has a linked work item.

Option A is incorrect because the 'Require a linked work item' branch policy does not apply to direct pushes; it only applies to pull request completions.

Exam trap

The trap is that candidates assume the 'Require a linked work item' branch policy applies to all pushes, but in Azure Repos it only applies to pull request completions. To enforce linked work items on every commit, you must first require pull requests for all changes to main.

How to eliminate wrong answers

Option B is wrong because Azure Repos does not support pre-receive hooks; that feature is specific to GitHub or on-premises Git servers. Option C is wrong because 'Gated check-in' (also known as 'Build validation') is a branch policy that triggers a build before accepting a push, but it does not enforce work item association. Option D is wrong because while a pull request policy requiring a linked work item can enforce work item association for PR merges, it does not cover direct pushes to main; to enforce the requirement for all commits, you must also restrict direct pushes by requiring pull requests, which is not stated in the option.

Full explanation →

457

MCQhard

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

A.The artifact name 'drop' contains invalid characters.

B.The artifact is too large to publish.

C.Two jobs are publishing artifacts with the same name.

D.The pipeline does not have permission to publish artifacts.

AnswerC

When two or more jobs in the same pipeline publish artifacts with an identical artifact name, the Azure DevOps PublishPipelineArtifact task fails because artifact names must be unique within the entire pipeline run. The second job's attempt to publish 'drop' conflicts with the first job's already published artifact, causing the build to fail.

Why this answer

Artifact names must be unique within a build. Both jobs publish with the same name 'drop', causing a conflict.

Full explanation →

458

MCQeasy

You need to create a build pipeline that runs on a Microsoft-hosted agent. You want to use the latest Ubuntu image. Which YAML snippet should you use?

A.pool: vmImage: 'ubuntu-latest'

B.pool: name: 'ubuntu-latest'

C.agent: vmImage: 'ubuntu-latest'

D.resources: vmImage: 'ubuntu-latest'

AnswerA

In Azure Pipelines YAML, the `pool` keyword defines the execution agent, and for Microsoft-hosted agents you must specify the VM image using the `vmImage` property. `'ubuntu-latest'` is a valid alias that resolves to the current stable Ubuntu LTS image, so this is the correct syntax.

Why this answer

In Azure Pipelines YAML, the `pool` keyword is used to specify the agent pool, and `vmImage` is a sub-property that defines the virtual machine image for Microsoft-hosted agents. Setting `vmImage: 'ubuntu-latest'` within the `pool` section selects the latest Ubuntu LTS image provided by Microsoft, ensuring the build runs on a current, maintained environment.

Exam trap

The trap here is that candidates confuse the `pool.name` property (used for self-hosted agents) with `pool.vmImage` (used for Microsoft-hosted agents), leading them to select option B, or they mistakenly use `agent` or `resources` as top-level keys for specifying the VM image.

Why the other options are wrong

The 'name' property is for agent pools, not VM images.

'agent' is not a valid top-level key; use 'pool'.

Resources are for external resources, not agent specification.

Full explanation →

459

Multi-Selectmedium

Which TWO are valid ways to pass build artifacts from one stage to another in a multi-stage YAML pipeline in Azure Pipelines?

Select 2 answers

A.Use the Pipeline Artifact task to publish artifacts, which are automatically available to subsequent stages without download.

B.Use the Publish Pipeline Artifact task in the first stage and Download Pipeline Artifact task in the second stage.

C.Use the Publish Build Artifacts task and then the Download Build Artifacts task.

D.Use the Copy Files task to copy artifacts to a shared network drive.

E.Define variables in the first stage and reference them in the second stage.

AnswersB, D

Correct. The Publish Pipeline Artifact task in the first stage publishes artifacts, and the Download Pipeline Artifact task in the second stage retrieves them. This is the standard and recommended method.

Why this answer

The Publish Pipeline Artifact task in the first stage makes the artifact available to the pipeline, and the Download Pipeline Artifact task in the second stage explicitly retrieves it. This is the standard, supported method for passing artifacts between stages in a multi-stage YAML pipeline. Option D is also correct because the Copy Files task can copy artifacts to a shared network drive accessible by subsequent stages, which is a valid alternative method.

Options A and C are incorrect: A is wrong because published pipeline artifacts are not automatically available without a download task; C is wrong because the Publish/Download Build Artifacts tasks are legacy and not the recommended way for multi-stage YAML pipelines, and they do not work seamlessly across stages without additional configuration.

Exam trap

The trap here is that candidates often confuse the legacy Build Artifacts tasks (Publish/Download Build Artifacts) with the modern Pipeline Artifact tasks, or assume that variables can pass complex build outputs between stages, when in fact only artifacts provide a reliable, cross-stage file transfer mechanism.

Full explanation →

460

MCQmedium

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

A.Add 'condition: succeeded()' to the Deploy stage.

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

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

D.Add 'dependsOn: Build' to the Deploy stage.

AnswerA

The 'succeeded()' function is a predefined pipeline expression that evaluates to true only if all prior stages and jobs in the pipeline have completed successfully, so adding 'condition: succeeded()' to the Deploy stage ensures it runs only after the Build stage succeeds, which is exactly the desired behavior.

Why this answer

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

Exam trap

The trap here is that candidates often think `dependsOn` alone enforces success, but it only sets the dependency order; without an explicit `condition: succeeded()`, a custom condition that always evaluates to true will still trigger the stage regardless of the dependency's status.

How to eliminate wrong answers

Option B is wrong because `variables['Build.Succeeded']` is not a predefined variable in Azure Pipelines; the correct variable is `Agent.JobStatus` or you must use the `succeeded()` function. Option C is wrong because it combines an invalid variable reference with `succeeded()`, which is redundant and still relies on a non-existent variable. Option D is wrong because adding `dependsOn: Build` only establishes the dependency order but does not enforce a success condition; without an explicit condition, the Deploy stage will still run even if the Build stage fails, as the default condition is `succeeded()` only when `dependsOn` is used without a custom condition—but here the question states a condition that always evaluates to true overrides that default, so `dependsOn` alone is insufficient.

Full explanation →

461

MCQhard

You are deploying an ARM template using the parameters file shown. The deployment fails with an error that the referenced secret cannot be found. What is the most likely cause?

A.The secret name in the parameters file does not match the actual secret name in Key Vault.

B.The Key Vault does not have an access policy granting the deployment user 'Get' secret permission.

C.The resource group 'rg-kv' does not exist.

D.The Key Vault is in a different region than the deployment.

AnswerA

An ARM template dynamic Key Vault reference resolves the secret by name exactly as specified in the parameters file. If the name contains a typo or does not match the secret's actual name in Key Vault (including case sensitivity for secret names), Azure returns a 'Secret not found' error, even if the Key Vault and access policies are correctly configured.

Why this answer

The error 'referenced secret cannot be found' directly indicates that the secret name specified in the parameters file does not match the actual secret name stored in Azure Key Vault. ARM template deployment uses the `reference()` function to retrieve the secret value at deployment time, and if the secret name is misspelled or incorrect, the deployment fails with this specific error.

Exam trap

The trap here is that candidates often confuse the 'secret not found' error with permission issues (Option B), but the error message specifically indicates the secret name mismatch, not an access policy problem.

How to eliminate wrong answers

Option B is wrong because an incorrect access policy would produce a different error, such as 'Access denied' or 'Forbidden', not 'secret cannot be found'. Option C is wrong because if the resource group 'rg-kv' did not exist, the deployment would fail with a resource group not found error, not a secret not found error. Option D is wrong because Key Vault region does not affect secret retrieval; ARM templates can reference Key Vaults in any region as long as the deployment user has appropriate permissions.

Full explanation →

462

Multi-Selecthard

Which THREE are valid approaches to securely store secrets used in Azure Pipelines? (Choose three.)

Select 3 answers

A.Inline secret variables defined in the YAML file

B.Secret variables defined in the pipeline UI

C.Azure Key Vault task to fetch secrets at runtime

D.Variable groups linked to Azure Key Vault

E.Environment variables set on the build agent

AnswersB, C, D

Secret variables defined in the pipeline UI are stored encrypted in Azure DevOps and automatically masked in all logs, ensuring they are never exposed during the build or release execution. They can be scoped to the pipeline run and are the recommended way to handle non-Key Vault secrets.

Why this answer

Secret variables defined in the pipeline UI (B) are encrypted at rest and masked in logs, preventing exposure in source control. The Azure Key Vault task (C) retrieves secrets from Azure Key Vault at runtime, avoiding storage in Azure DevOps. Variable groups linked to Azure Key Vault (D) allow you to reference Key Vault secrets directly as pipeline variables, keeping them out of YAML and providing centralized access control.

All three approaches ensure secrets are not stored in plaintext in repositories or pipeline definitions.

Exam trap

The trap here is that candidates may think inline YAML secrets (Option A) are secure because they are marked as 'secret' in the YAML, but they are still stored in plaintext in the repository, which is a common security misconception.

Full explanation →

463

Matchingmedium

Match each Azure DevOps service to its primary function.

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

Concepts

Matches

Agile planning and work tracking

Source control with Git or TFVC

CI/CD build and release automation

Manual and exploratory testing

Package management and sharing

Why these pairings

The correct matches are: Azure Boards for agile planning, Azure Repos for version control, Azure Pipelines for CI/CD, and Azure Artifacts for package management. Common confusions include swapping Boards with Repos or Pipelines.

Full explanation →

464

MCQhard

A development team uses a forking workflow in Azure Repos. They want to ensure that only specific users can create forks of the main repository. How can they achieve this?

A.Use branch security to restrict who can create forks

B.Set branch policies on the main branch to prevent forks

C.Configure the repository to disable forks globally

D.Remove the 'Create Fork' permission from all users except the required group

AnswerD

The 'Create Fork' permission is a repository-level security permission in Azure Repos, stored separately from branch permissions. To allow only a specific group to create forks, you remove the 'Create Fork' permission from all other users and groups (for example, Contributors and Readers) in the repository's Security page, then explicitly set it to 'Allow' for the required group. This is the only per-repository mechanism that enforces the requirement precisely, since it leaves fork creation available to the approved group while denying everyone else.

Why this answer

In Azure Repos, the ability to create forks is controlled by the 'Create Fork' permission, which is a repository-level permission, not a branch-level setting. By default, all contributors have this permission. To restrict fork creation to only specific users, navigate to the repository settings, go to Security (or Permissions), remove the 'Create Fork' permission from all users and groups, then explicitly grant it only to the desired group or individuals.

Therefore, the correct answer is D: remove the 'Create Fork' permission from all users except the required group.

Exam trap

The trap is that candidates often confuse repository-level permissions with branch-level settings. They may think 'branch security' controls fork creation because both involve permissions, but fork creation is managed at the repository level, not the branch level.

How to eliminate wrong answers

Option A is correct because it directly addresses the permission control needed. Option B is wrong because branch policies on the main branch (e.g., requiring pull request reviews) do not control who can create forks; they only enforce rules on commits and merges to that branch. Option C is wrong because Azure Repos does not have a global 'disable forks' setting; fork creation is controlled per-repository via permissions.

Option D is wrong because 'Create Fork' is not a permission that can be removed from users; it is a permission that must be explicitly denied or granted, and the correct approach is to remove the permission from all users and grant it only to the required group.

Full explanation →

465

Multi-Selecthard

Which THREE conditions must be met for you to use the 'Approvals' feature in Azure Pipelines to control deployments to a production environment? (Choose three.)

Select 3 answers

A.The approver must be an individual user, not a group.

B.The approval must be configured in the release pipeline's pre-deployment conditions.

C.The approver must have the 'Approve pipeline permissions' permission for the environment.

D.The pipeline must be a Release Pipeline or a YAML pipeline that uses the 'environment' resource.

E.You must create an environment in Azure Pipelines and add an approval check to it.

AnswersC, D, E

To successfully approve a deployment to an environment, the designated approver must have the 'Approve pipeline permissions' permission on that environment. This permission is managed through the environment's security settings and is separate from permissions like 'View' or 'Manage'. Without this permission, even if a user is listed as an approver, they will not be able to approve the deployment.

Why this answer

The 'Approvals' feature in Azure Pipelines requires an environment to be defined in the pipeline. You must add an approval check to that environment, which can be done in either a classic release pipeline or a YAML pipeline that references the environment as a resource. Additionally, the approver(s) - whether individual users or groups - must have the 'Approve pipeline permissions' permission on that environment.

Without an environment resource, the approval check cannot be configured; without the permission, approval requests cannot be validated.

Exam trap

The trap here is that candidates often assume approvals must be configured in the release pipeline's pre-deployment conditions only, but Azure Pipelines also supports approvals in post-deployment conditions and as environment-level checks in YAML pipelines, making option B a common distractor.

Full explanation →

466

MCQeasy

Your team uses Azure Pipelines for CI/CD. The pipeline builds a Docker image and pushes it to Azure Container Registry (ACR). You need to ensure that only the main branch triggers a build of the Docker image. What should you configure in the pipeline YAML?

A.Set 'pr: branches: include: - main'

B.Add a condition: 'eq(variables['Build.SourceBranch'], 'refs/heads/main')' to the job.

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

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

AnswerD

Setting `trigger: branches: include: - main` defines the CI trigger to fire only on commits pushed to the `main` branch. This ensures that pushes to feature or other branches do not create pipeline runs, while any commit to `main` correctly starts a new CI build, satisfying the requirement to restrict builds to the main branch.

Why this answer

Setting `trigger: branches: include: - main` in the pipeline YAML configures a CI trigger that only starts a new pipeline run when changes are pushed to the `main` branch. This ensures that the Docker image build and push to ACR occurs exclusively for the main branch, meeting the requirement.

Exam trap

The trap here is that candidates often confuse CI triggers (`trigger`) with PR triggers (`pr`) or try to use job-level conditions to filter branches, not realizing that conditions only skip job execution but still trigger the pipeline, wasting resources and potentially causing unintended side effects like failed runs or unnecessary ACR pushes.

How to eliminate wrong answers

Option A is wrong because `pr: branches: include: - main` configures a pull request (PR) trigger, not a CI build trigger; it would cause the pipeline to run when a PR targets main, not when code is pushed directly to main. Option B is wrong because adding a condition like `eq(variables['Build.SourceBranch'], 'refs/heads/main')` to a job would still allow the pipeline to be triggered by any branch, but the job would be skipped for non-main branches; this does not prevent the pipeline from being triggered at all, which is inefficient and does not meet the requirement to 'only trigger a build' on main. Option C is wrong because `trigger: branches: include: - *` uses a wildcard that includes all branches, which would trigger the pipeline on every push to any branch, not just main.

Full explanation →

467

MCQmedium

You are configuring a multi-stage YAML pipeline that builds a .NET Core application and deploys it to Azure Kubernetes Service (AKS). The build stage produces a container image that is pushed to Azure Container Registry (ACR). The deploy stage needs to use the image from ACR. How should you pass the image tag from the build stage to the deploy stage?

A.Write the image tag to a file and publish it as a build artifact, then read it in the deploy stage.

B.Define a pipeline variable at the top level and set it in the build stage.

C.Use the 'stageDependencies' syntax to retrieve the output variable of a job in the build stage.

D.Use the 'Azure CLI' task in the deploy stage to query the ACR for the latest image tag.

AnswerC

Output variables are the intended mechanism for sharing a value between stages: a job in the build stage sets the variable with `task.setvariable` and `isoutput=true`, making it available in the job's output context. A subsequent stage's job can then retrieve that exact value at runtime using the syntax `$[stageDependencies.buildStage.buildJob.outputs['imageTag']]` in a variable definition, condition, or argument. This guarantees the consuming stage receives the precise tag produced by the build, independent of ordering or naming conventions, and avoids the overhead of publishing artifacts for a single string value.

Why this answer

Azure DevOps supports cross-stage output variables, allowing a job in the build stage to set a variable (e.g., imageTag) that can be consumed in the deploy stage using the stageDependencies syntax. This avoids the overhead of artifacts or external queries and ensures the exact tag produced during the build is used in deployment.

Exam trap

The trap here is that candidates often assume artifacts are the only way to pass data between stages, overlooking the built-in cross-stage variable feature that is more efficient and purpose-built for this scenario.

How to eliminate wrong answers

Option A is wrong because writing the image tag to a file and publishing it as a build artifact introduces unnecessary complexity and latency; artifacts are designed for binary files, not simple variable passing, and require extra steps to download and parse. Option B is wrong because pipeline variables defined at the top level are static and cannot be dynamically set by a stage; they are evaluated at pipeline start, not updated during execution. Option D is wrong because querying ACR for the latest image tag is unreliable—there may be multiple tags, race conditions, or no guarantee that the tag corresponds to the specific build just completed, leading to deployment of the wrong image.

Full explanation →

468

MCQhard

Your organization uses GitHub Actions with self-hosted runners on Azure virtual machines. You notice that some workflows are taking longer than expected because runners are busy. You need to improve the performance without adding more permanent runners. Which solution should you implement?

A.Migrate all workflows to GitHub-hosted runners.

B.Reduce the number of concurrent jobs in each workflow.

C.Implement auto-scaling for self-hosted runners using a scale set or Kubernetes-based runner controller.

D.Increase the size of the existing self-hosted runner VMs to handle more jobs.

AnswerC

Implementing auto-scaling for self-hosted runners using a scale set or Kubernetes-based Actions Runner Controller dynamically matches runner count to job demand, provisioning new runners during peak times and scaling to zero when idle, which optimizes both latency and cost.

Why this answer

Auto-scaling self-hosted runners using a scale set or a Kubernetes-based runner controller (e.g., actions-runner-controller) dynamically provisions and deprovisions runner instances based on workflow demand. This eliminates idle runner waste while ensuring sufficient capacity during peak loads, directly addressing the bottleneck without adding permanent infrastructure.

Exam trap

The trap here is that candidates often confuse vertical scaling (increasing VM size) with horizontal scaling (adding more runner instances), mistakenly believing a larger VM can process multiple jobs concurrently when in fact each self-hosted runner handles only one job at a time.

How to eliminate wrong answers

Option A is wrong because migrating to GitHub-hosted runners may increase costs and does not leverage existing self-hosted infrastructure; it also does not solve the core issue of scaling capacity dynamically. Option B is wrong because reducing concurrent jobs limits parallelism and throughput, which would worsen performance rather than improve it. Option D is wrong because increasing VM size (vertical scaling) does not increase the number of concurrent jobs a runner can handle; a single runner processes one job at a time regardless of its size.

Full explanation →

469

Multi-Selecthard

Your team uses Azure Boards and has several work item types (Epic, Feature, User Story, Bug, Issue). They want to enforce a rule that bugs can only be linked to Features, not directly to Epics. Which TWO actions should you perform?

Select 2 answers

A.Customize the Epic work item type to remove the 'Child' link to Bug.

B.Configure the Epic work item type to require a link to a Bug.

C.Use a work item rule to set the parent type to Feature when a Bug is created.

D.Add a rule to the Bug work item type that prohibits linking to Epics.

E.Customize the Bug work item type to remove the 'Parent' link to Epic.

AnswersA, E

This prevents users from linking an Epic to a Bug as a child.

Why this answer

By customizing the Epic work item type to remove the 'Child' link type to Bug, you prevent any Bug from being linked as a child of an Epic. This enforces the rule that Bugs can only be linked to Features. Option E is correct because by customizing the Bug work item type to remove the 'Parent' link type to Epic, you prevent a Bug from having an Epic as its parent, which directly enforces the desired linking restriction.

Exam trap

The trap here is that candidates often assume work item rules can enforce link restrictions, but Azure Boards rules only control field values and state transitions, not link types, so the correct approach is to customize the work item type definitions to remove the unwanted link relationships.

Full explanation →

470

MCQeasy

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

A.Increase the 'timeoutInMinutes' property in the pipeline YAML for the job.

B.Split the pipeline into multiple stages to reduce job duration.

C.Enable parallel jobs to run the pipeline faster.

D.Use a self-hosted agent with more CPU cores.

AnswerA

Increasing the timeoutInMinutes property in the pipeline YAML for the job extends the maximum allowed duration for the job, preventing Azure DevOps from cancelling it when it exceeds the default 60-minute limit. This directly addresses the intermittent timeout error by giving the job more time to complete. Note: for Microsoft-hosted agents, the max is 360 minutes, while self-hosted agents can use 0 for no limit.

Why this answer

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

Exam trap

The trap here is that candidates may confuse job timeout with pipeline performance, incorrectly assuming that optimizing speed (parallelism or faster agents) resolves a timeout error, when the actual fix is to adjust the timeout limit.

How to eliminate wrong answers

Option B is wrong because splitting the pipeline into multiple stages does not reduce the execution time of a single job; it only organizes the workflow, and each stage still runs within its own job timeout. Option C is wrong because enabling parallel jobs runs multiple jobs concurrently but does not affect the timeout of an individual job that exceeds 60 minutes. Option D is wrong because using a self-hosted agent with more CPU cores may improve performance but does not change the maximum execution time limit; the job would still fail if it runs longer than the default or configured timeout.

Full explanation →

471

MCQhard

Refer to the exhibit. A developer is working on the feature/login branch and wants to ensure that the latest changes from main are incorporated before creating a pull request. Which command should the developer run next?

A.git rebase --abort

B.git merge main

C.git push origin feature/login

D.git pull --rebase origin main

AnswerD

This fetches the latest main and rebases the feature branch onto it, incorporating the latest changes and keeping history linear.

Why this answer

The exhibit shows that the feature/login branch has a merge commit from main (3a1b2c3) which means main was already merged into feature/login. However, the local branch is ahead of origin by 1 commit (the merge commit). The developer wants to incorporate the latest changes from main.

Since main has advanced (d4e5f6a is the latest on origin/main), the developer should pull the latest main and rebase or merge again. The best practice is to rebase onto the latest main to maintain a linear history. Therefore, the developer should run 'git pull --rebase origin main' to fetch and rebase.

Full explanation →

472

Multi-Selectmedium

Which TWO are valid strategies for reducing build times in Azure Pipelines? (Choose two.)

Select 2 answers

A.Reduce the number of parallel jobs and increase the number of steps in a single job.

B.Remove unit tests from the build pipeline and run them only in the release pipeline.

C.Implement caching for package dependencies (e.g., npm, NuGet, Maven) to avoid restoring on every build.

D.Configure incremental builds by enabling 'Build in parallel' and using 'msbuild' or 'dotnet' build with appropriate flags to skip unchanged projects.

E.Increase the number of agents in the pool and run all jobs on the same agent.

AnswersC, D

Caching package dependencies avoids redundant network downloads of unchanged packages across pipeline runs, which is often the biggest time sink in a cold build. Use Azure Pipelines' Cache task or built-in caching (keyed on lockfiles) so restores are near-instant when dependencies haven't changed.

Why this answer

Caching package dependencies (e.g., npm, NuGet, Maven) avoids restoring them on every build, reducing download time. Incremental builds (e.g., using 'dotnet build --no-restore' with appropriate flags or MSBuild's incremental building) skip projects that haven't changed, reducing compilation time. Option A is incorrect because reducing parallel jobs and adding steps increases build time.

Option B is incorrect because removing unit tests compromises quality and is not a valid strategy. Option E is incorrect because increasing agents without parallelizing jobs or running all jobs on the same agent does not reduce build time.

Full explanation →

473

Multi-Selectmedium

Your team uses Azure DevOps with a Git repository. You want to enforce that all pull requests to main must have at least one reviewer from the 'security' group. Which two configurations are required? (Choose two.)

Select 2 answers

A.Configure automatic reviewers for the security group.

B.Add the security group as a required reviewer for the main branch policy.

C.Create a repository policy for the main branch.

D.Set the minimum number of reviewers to 1 in the branch policy.

E.Configure a branch protection rule in GitHub.

AnswersB, D

Adding the security group as a required reviewer in the Azure DevOps branch policy for main is the correct approach. This policy blocks pull request completion until a member of that group approves, making the security review a hard condition. The policy can also specify 'Required' reviewers, which prevents the PR from being completed without the mandated approval. This is the standard, declarative way to enforce that a specific team always signs off on merges to the main branch.

Why this answer

You can add the security group as a required reviewer in the branch policy. Option D is correct because setting the minimum number of reviewers to 1 ensures at least one reviewer is required. Option A is incorrect because automatic reviewers are not the same as required reviewers; they only suggest reviewers but do not enforce mandatory review.

Option C is incorrect because a repository policy applies to all branches, not just main, and does not enforce required reviewers for pull requests; a branch policy is needed. Option E is incorrect because a branch protection rule is a GitHub feature, not available in Azure Repos.

Full explanation →

474

MCQmedium

Your team uses GitHub and wants to automatically link pull requests to work items in Azure Boards. What should you configure?

A.Add a repository secret with Azure Boards connection string

B.Install the Azure Boards app for GitHub and configure the integration

C.Configure branch protection rules to require a linked work item

D.Create a GitHub Actions workflow that posts comments to Azure Boards

AnswerB

This integration provides automatic linking.

Why this answer

The Azure Boards app for GitHub is the official integration that synchronizes work items with GitHub commits, branches, and pull requests. Once installed and configured, it automatically links pull requests to Azure Boards work items based on mention patterns (e.g., 'AB#123') in the PR description or commit messages, enabling traceability without custom scripting.

Exam trap

The trap here is that candidates confuse 'requiring a linked work item' (a branch protection rule) with 'automatically linking work items' (the integration), leading them to pick Option C, which enforces a precondition rather than establishing the actual linking mechanism.

How to eliminate wrong answers

Option A is wrong because repository secrets are used for storing sensitive tokens or credentials (e.g., for GitHub Actions), not for establishing a cross-service integration like Azure Boards; there is no 'Azure Boards connection string' concept. Option C is wrong because branch protection rules can require a linked work item for PRs, but they do not automatically link PRs to work items—they only enforce that a link already exists, which requires the integration from Option B to be in place first. Option D is wrong because while a GitHub Actions workflow could theoretically post comments to Azure Boards, this is a brittle, custom workaround that duplicates the purpose-built Azure Boards app, which handles bidirectional linking, status updates, and automation natively.

Full explanation →

475

MCQeasy

Your DevOps team is using Microsoft Defender for Cloud to monitor Azure resources. Which of the following is a security recommendation that Defender for Cloud might provide?

A.Allow all inbound traffic on port 22 for SSH

B.Enable Transparent Data Encryption (TDE) on SQL databases

C.Disable auditing on storage accounts to reduce overhead

D.Configure web apps to use HTTP instead of HTTPS

AnswerB

Enabling Transparent Data Encryption (TDE) encrypts SQL database data files, transaction logs, and backups at rest, protecting against data exfiltration if storage is compromised. This is a recommended security control in Defender for Cloud and helps meet compliance requirements for encryption at rest.

Why this answer

Microsoft Defender for Cloud provides security recommendations based on best practices and compliance frameworks. Enabling Transparent Data Encryption (TDE) on SQL databases is a standard security recommendation because it encrypts data at rest, protecting against unauthorized access to the physical database files. This aligns with the 'Develop a security and compliance plan' domain, as TDE helps meet regulatory requirements like GDPR or HIPAA.

Exam trap

The trap here is that candidates may confuse security recommendations with operational shortcuts, such as disabling auditing or using HTTP, thinking they reduce overhead, when in fact Defender for Cloud always promotes security hardening and compliance.

How to eliminate wrong answers

Option A is wrong because allowing all inbound traffic on port 22 (SSH) is a security risk, not a recommendation; Defender for Cloud would recommend restricting SSH access to specific IP ranges or using just-in-time (JIT) VM access. Option C is wrong because disabling auditing on storage accounts reduces visibility for security monitoring and compliance, whereas Defender for Cloud recommends enabling auditing to track access and changes. Option D is wrong because configuring web apps to use HTTP instead of HTTPS exposes data in transit to interception and man-in-the-middle attacks; Defender for Cloud recommends enforcing HTTPS to ensure encrypted communication.

Full explanation →

476

Drag & Dropmedium

Drag and drop the steps to set up a continuous integration pipeline in Azure Pipelines into the correct order.

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

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

The correct order for setting up a continuous integration pipeline in Azure Pipelines is: first create the pipeline, then select the source repository (e.g., Azure Repos or GitHub), then configure triggers (e.g., on commit or PR), then add tasks (build, test, etc.), and finally validate the pipeline by running it. This sequence is reflected in option A. Starting with source selection or adding tasks before creation is incorrect.

Full explanation →

477

Multi-Selecteasy

Which TWO practices help you manage build artifacts efficiently in Azure Pipelines?

Select 2 answers

A.Set retention policies to automatically delete old artifacts

B.Copy artifacts to each agent's local storage

C.Download all artifacts manually after each build

D.Publish build artifacts using the Publish Build Artifacts task

E.Store artifacts as large single files to reduce number of files

AnswersA, D

Setting retention policies automatically prunes outdated build artifacts, preventing storage bloat and reducing costs without manual intervention. You can define branch-specific or pipeline-specific retention rules, and the system cleans up old runs and their associated artifacts while preserving recent or stable builds. This ensures storage remains manageable and aligns with governance and compliance requirements.

Why this answer

Setting retention policies (A) helps automate cleanup of old artifacts, reducing storage waste. Using the Publish Build Artifacts task (D) is the standard way to store artifacts from builds efficiently. Option B (copying to each agent) is wasteful because it duplicates artifacts unnecessarily.

Option C (manual download) is inefficient because it requires human intervention and does not scale. Option E (large single files) makes downloads and incremental updates difficult.

Full explanation →

478

MCQmedium

Your team uses a monorepo in Azure Repos with multiple microservices. Developers frequently report merge conflicts due to long-lived feature branches. Which branching strategy minimizes merge conflicts while supporting continuous integration?

A.Use release branches for all development work and merge to main only at release time

B.Use GitFlow with separate develop and main branches, and long-lived feature branches

C.Use a forking workflow where each developer works in a personal fork and submits pull requests

D.Use trunk-based development with short-lived feature branches and frequent merges to main

AnswerD

Trunk-based development minimizes conflicts by integrating small changes often.

Why this answer

Trunk-based development with short-lived feature branches (typically lasting less than a day) minimizes merge conflicts by ensuring that changes are integrated into the main branch frequently, often multiple times per day. This approach reduces the divergence between branches, making conflicts less likely and easier to resolve. It also supports continuous integration by triggering automated builds and tests on every merge to main, aligning with the team's need for rapid feedback and reduced integration overhead.

Exam trap

The trap here is that candidates often associate GitFlow (Option B) with structured branching and mistakenly believe it reduces conflicts, but in reality, its long-lived feature branches increase conflict frequency and hinder continuous integration, making trunk-based development (Option D) the correct choice for minimizing conflicts and supporting CI.

How to eliminate wrong answers

Option A is wrong because using release branches for all development work and merging only at release time creates long-lived branches that accumulate significant divergence, leading to frequent and complex merge conflicts, and it violates CI principles by delaying integration. Option B is wrong because GitFlow with separate develop and main branches and long-lived feature branches encourages prolonged branch lifetimes, increasing the risk of merge conflicts and making continuous integration difficult due to infrequent merges to the main integration branch. Option C is wrong because a forking workflow, while useful for open-source projects with external contributors, introduces additional overhead in synchronizing forks and does not inherently reduce merge conflicts; it can actually increase them if forks diverge significantly before submitting pull requests.

Full explanation →

479

MCQmedium

Your team uses GitHub Issues to track work. You want to enforce that all new issues include a specific set of labels based on the issue type (bug, feature, task). What is the most efficient way to achieve this?

A.Configure branch protection rules to require label assignments.

B.Use a CODEOWNERS file to auto-assign labels.

C.Create YAML-based issue forms in the .github/ISSUE_TEMPLATE folder.

D.Set up a repository ruleset to restrict label modifications.

AnswerC

YAML-based issue forms in the `.github/ISSUE_TEMPLATE` folder allow you to define structured issue templates with fields and a `labels:` key that automatically applies specified labels when the form is submitted, enforcing consistent label assignment at issue creation.

Why this answer

GitHub issue forms, defined as YAML files in the .github/ISSUE_TEMPLATE folder, allow you to create structured templates that can enforce required fields, including mandatory label assignments. When a user submits an issue via a form, the labels specified in the template are automatically applied, ensuring consistency without manual intervention or additional automation.

Exam trap

The trap here is that candidates confuse branch protection rules or repository rulesets (which manage code changes) with issue management features, or mistakenly think CODEOWNERS can assign labels instead of reviewers.

How to eliminate wrong answers

Option A is wrong because branch protection rules apply to pull requests and branches, not to issue creation; they cannot enforce label assignments on new issues. Option B is wrong because CODEOWNERS is designed to automatically request reviews from specific teams or individuals based on file paths in a repository, not to assign labels to issues. Option D is wrong because repository rulesets control permissions and restrictions on branches and tags, not on issue metadata like labels; they cannot enforce label assignments on new issues.

Full explanation →

480

MCQmedium

Your build pipeline runs on a self-hosted agent pool. You need to ensure that only authorized pipelines can use these agents. Which security measure should you implement?

A.Set permissions on the agent pool

B.Use agent tokens

C.Use variable groups

D.Configure agent queues

AnswerA

Set permissions on the agent pool to control which pipelines can queue jobs on that pool. In Azure Pipelines, agent pool security roles (Reader, User, Administrator) govern authorization at the pool level, so you can restrict a pipeline or project from using specific self-hosted agents by modifying these permissions.

Why this answer

Agent pool permissions allow restricting which pipelines can use the agents, ensuring only authorized pipelines can access the self-hosted agents. Option B (agent tokens) is for registering agents, not for authorizing pipelines. Option C (variable groups) is for storing variables and secrets, not for agent access control.

Option D (agent queues) is a legacy concept that does not provide granular pipeline-level permissions.

Full explanation →

481

MCQhard

Your organization uses GitHub and wants to implement a policy that requires all pull requests to be approved by at least two members of the 'security-team' team before merging. The 'security-team' team is a child team of 'engineering'. Which branch protection rule setting should you use?

A.Enable 'Dismiss stale pull request approvals when new commits are pushed'.

B.Use the 'Require pull request reviews before merging' rule and set 'Required reviewers' to the security team.

C.Require a minimum number of reviewers and set it to 2.

D.Require code owner review and add the security team as code owners.

AnswerB

This enforces approval from two members of the specified team.

Why this answer

'Require pull request reviews before merging' with 'Required reviewers' set to the security team. This configuration enables branch protection to enforce reviews from that specific team. To require approval from at least two members, you must also set the 'Required number of reviewers' to 2 within the same branch protection rule.

Option A is unrelated to reviewer requirements. Option C only sets a minimum number of reviewers without specifying which team, so it could allow any approver. Option D requires a CODEOWNERS file and only applies to file patterns owned by the team, not all pull requests.

Therefore, B is the foundational setting needed to achieve the policy.

Full explanation →

482

MCQhard

Refer to the exhibit. An Azure CLI command outputs the configuration of an Azure Web App. Your pipeline deploys to this Web App using the 'AzureWebApp@1' task. The deployment fails with an error indicating that the runtime stack is not supported. What is the most likely cause?

A.The Web App is not a Linux app.

B.The ASPNETCORE_ENVIRONMENT setting is incorrect.

C.The runtime stack (DOTNETCORE|6.0) is not compatible with the deployed application.

D.The resource group name is incorrect.

AnswerC

If the application targets a different runtime version, the deployment fails.

Why this answer

The error 'runtime stack is not supported' indicates that the Azure Web App's configured runtime stack (DOTNETCORE|6.0) does not match the application being deployed. The AzureWebApp@1 task uses the Web App's stack setting to determine how to deploy and run the code; if the deployed app requires a different runtime (e.g., .NET 8.0 or a non-.NET framework), the deployment fails. Option C correctly identifies this mismatch as the root cause.

Exam trap

The trap here is that candidates often confuse runtime stack errors with environment variable misconfigurations (like ASPNETCORE_ENVIRONMENT) or OS-level issues, but the error message directly points to a mismatch between the Web App's configured stack and the deployed application's framework.

How to eliminate wrong answers

Option A is wrong because the runtime stack error is unrelated to whether the Web App is Linux or Windows; both platforms support runtime stack configurations, and the error specifically points to an unsupported stack, not the OS type. Option B is wrong because the ASPNETCORE_ENVIRONMENT setting controls the environment name (e.g., Development, Production) and does not affect runtime stack compatibility; it is an application-level configuration, not a deployment-level one. Option D is wrong because an incorrect resource group name would cause a different error (e.g., 'Resource group not found') during the task's initial resource lookup, not a runtime stack error during deployment.

Full explanation →

483

Multi-Selectmedium

Which TWO are true about Azure Pipelines YAML templates? (Choose two.)

Select 2 answers

A.Templates must be stored in the same repository as the main pipeline.

B.Template expressions are evaluated at compile time.

C.Templates require parameters to be defined.

D.Templates can be nested by including other templates.

E.Templates can only define a single job.

AnswersB, D

Expressions like '${{ variables.var }}' are expanded when the pipeline is compiled, before any runtime execution. This enables conditional inclusion of stages, jobs, or steps based on parameters or compile-time variables, but they cannot reference runtime values like agent-specific variables.

Why this answer

Template expressions in Azure Pipelines YAML are evaluated at compile time, before the pipeline runs. This allows the template to inject variables, conditions, and other logic into the pipeline definition statically, ensuring that the final pipeline structure is fully resolved before execution begins.

Exam trap

The trap here is that candidates often confuse compile-time evaluation with runtime evaluation, leading them to think template expressions can use runtime variables, or they mistakenly believe templates must be in the same repo or require parameters, when in fact templates are flexible and optional in their structure.

Full explanation →

484

MCQhard

Your company uses Azure Repos with a Git branching strategy that includes a main branch, a develop branch, and feature branches. You need to enforce that only designated release managers can merge changes from develop into main, while developers can create feature branches off develop and merge pull requests into develop. What is the best way to implement this?

A.Configure branch policies on main to require a minimum number of reviewers from the release manager group, and set the 'Allow users to create pull requests' permission to only include release managers.

B.Use GitHub branch protection rules to require pull request reviews from release managers on main.

C.Set the main branch to read-only for all users except release managers using the 'Security' tab in repository settings.

D.Require a successful build for all branches and set the build pipeline to only run for release manager commits.

AnswerA

This allows only release managers to create pull requests into main, enforcing the desired control.

Why this answer

By configuring branch policies on the main branch to require a minimum number of reviewers from the release manager group, you ensure that any changes to main are reviewed by designated release managers. Additionally, setting the 'Allow users to create pull requests' permission to only include release managers controls who can initiate pull requests into main. Option B is incorrect because branch protection rules are a GitHub feature, not available in Azure Repos.

Option C is incorrect because setting the main branch to read-only would prevent all pushes, including those from release managers, unless they are granted write permissions; however, this approach does not enforce pull request reviews and is less granular. Option D is incorrect because requiring a successful build does not restrict who can merge; it only ensures code quality.

Full explanation →

485

MCQmedium

You need to implement a build retention policy that automatically deletes old builds after 30 days, but keeps the latest 5 builds regardless of age. Which configuration should you use?

A.Set 'Number of days to keep runs' to 30 and 'Number of runs to keep' to 5

B.Set 'Maximum retention policy' to 30 days and 'Number of builds to retain' to 5

C.Set 'Days to keep builds' to 30 and 'Minimum number of builds to keep' to 5

D.Set 'Number of days to keep artifacts' to 30 and 'Number of artifacts to keep' to 5

AnswerC

Deletes builds older than 30 days but keeps at least 5.

Why this answer

In Azure Pipelines, the 'Days to keep builds' and 'Minimum number of builds to keep' settings work together to enforce a retention policy that deletes builds older than 30 days while ensuring that at least the latest 5 builds are retained, even if they exceed the age limit. This configuration directly matches the requirement to delete old builds after 30 days but keep the latest 5 builds regardless of age.

Exam trap

The trap here is that candidates confuse the 'Minimum number of builds to keep' with a maximum limit, or they misremember the exact field names (e.g., 'Number of runs to keep' or 'Number of builds to retain'), leading them to select options that do not exist in the Azure DevOps UI.

How to eliminate wrong answers

Option A is wrong because 'Number of days to keep runs' and 'Number of runs to keep' are not valid retention policy fields in Azure Pipelines; the correct fields are 'Days to keep builds' and 'Minimum number of builds to keep'. Option B is wrong because 'Maximum retention policy' and 'Number of builds to retain' are not standard terms in Azure DevOps; the retention policy uses 'Days to keep builds' and 'Minimum number of builds to keep' to define the retention behavior. Option D is wrong because 'Number of days to keep artifacts' and 'Number of artifacts to keep' apply only to artifact retention, not to build pipeline runs, and do not control the deletion of old builds themselves.

Full explanation →

486

MCQeasy

Your organization is adopting DevSecOps and wants to integrate security scanning into the CI/CD pipeline. Which tool should you use to scan container images for vulnerabilities?

A.Azure Monitor

B.GitHub Copilot

C.Microsoft Defender for Cloud

D.Azure Logic Apps

AnswerC

Microsoft Defender for Cloud, specifically through Microsoft Defender for Containers, includes vulnerability scanning for container images in Azure Container Registry (ACR) and other registries. It uses Microsoft Defender Vulnerability Management to detect OS and language-level CVEs and can be integrated into a CI/CD pipeline as a quality gate, blocking vulnerable images from being promoted to production.

Why this answer

Microsoft Defender for Cloud (Option C) is the correct tool for scanning container images for vulnerabilities in a CI/CD pipeline, as it integrates with Azure Container Registry to perform vulnerability assessments. Option A (Azure Monitor) is incorrect because it is a monitoring and observability service, not a security scanner. Option B (GitHub Copilot) is incorrect as it is an AI code completion tool.

Option D (Azure Logic Apps) is incorrect because it is a workflow automation service, not a security scanning tool.

Full explanation →

487

Multi-Selectmedium

Which THREE of the following are prerequisites for implementing a CI/CD pipeline for a .NET Core application?

Select 3 answers

A.Build agent (Microsoft-hosted or self-hosted)

B.Source control repository (e.g., Git)

C.Unit test framework

D.Docker container registry

E.Target deployment environment (e.g., App Service)

AnswersA, B, E

A build agent, whether Microsoft-hosted or self-hosted, provides the compute environment where pipeline tasks such as restore, build, test, and publish execute. Without an available and properly configured agent, the pipeline has no infrastructure to run on, making it an absolute prerequisite for any implementation.

Why this answer

A build agent is required to execute the pipeline tasks, such as compiling code, running tests, and packaging artifacts. Microsoft-hosted agents provide a pre-configured environment with common tools, while self-hosted agents allow custom configurations and access to on-premises resources. Without a build agent, the CI/CD pipeline cannot perform any automated build or deployment steps.

Exam trap

The trap here is that candidates often mistake optional pipeline components (like unit tests or container registries) as prerequisites, when in fact only the core infrastructure (agent, source control, and target environment) is mandatory for a basic CI/CD pipeline.

Full explanation →

488

Multi-Selecthard

You are designing a release pipeline for a .NET Core application that must comply with regulatory requirements. The pipeline must sign the assembly with a code-signing certificate stored in Azure Key Vault. Which THREE actions should you perform?

Select 3 answers

A.Add a step to download the certificate from Key Vault using the AzureKeyVault task.

B.Use a script task to invoke the signing tool (e.g., signtool.exe) after the build.

C.Grant the Azure Pipelines service principal access to the Key Vault.

D.Store the certificate in a secure file in the build artifact.

E.Package the application before signing to avoid signature corruption.

AnswersA, B, C

The task retrieves the certificate securely.

Why this answer

The AzureKeyVault task can download the certificate from Azure Key Vault. Option B is correct because after downloading the certificate, a script task like signtool.exe must be used to sign the assembly. Option C is correct because the Azure Pipelines service principal must be granted access to the Key Vault to retrieve the certificate.

Option D is incorrect because the certificate should not be stored in a secure file in the build artifact; it should remain in Key Vault for security. Option E is incorrect because signing should occur before packaging; packaging after signing is typical to avoid corruption.

Full explanation →

489

MCQmedium

Your team uses Azure DevOps for CI/CD. You want to ensure that only code from the main branch is deployed to production. The release pipeline has a pre-deployment condition that requires approval. However, you notice that a release created from a feature branch was approved and deployed. What is the most likely cause?

A.The deployment queue settings were set to 'Deploy all in parallel'.

B.The pre-deployment condition did not include a branch filter on the artifact.

C.The artifact was published from a build pipeline that allowed any branch.

D.The pre-deployment condition was set to 'After release' instead of 'Before deployment'.

AnswerB

Branch filters must be configured on the artifact trigger or pre-deployment condition to restrict branches.

Why this answer

The pre-deployment condition in Azure DevOps release pipelines can include a branch filter on the artifact to restrict which branches trigger a release. If this filter is not configured, any release—regardless of the source branch—can proceed through the approval gate. Since the feature branch release was approved and deployed, the most likely cause is that the pre-deployment condition lacked a branch filter to enforce that only artifacts from the main branch are eligible.

Exam trap

The trap here is that candidates often assume that requiring approval alone is sufficient to control which branches are deployed, but Azure DevOps separates branch filtering from the approval gate, so without an explicit artifact branch filter, any branch can be approved and deployed.

How to eliminate wrong answers

Option A is wrong because 'Deploy all in parallel' controls how multiple pending releases are deployed simultaneously, not which branches are allowed to trigger a release. Option C is wrong because the artifact source branch is determined by the build pipeline's trigger or manual run, but the release pipeline's pre-deployment condition is where branch filtering should be enforced; allowing any branch in the build pipeline does not bypass the release gate if the filter is set. Option D is wrong because 'After release' vs 'Before deployment' refers to the timing of the approval gate relative to the deployment stage, not to branch filtering; setting it to 'After release' would still not prevent a feature branch release from being approved.

Full explanation →

490

MCQmedium

A developer pushes a commit to a branch named 'releases/v1.0'. What will happen?

A.The pipeline runs but fails because the branch name contains a dot.

B.The pipeline runs only if a pull request is created.

C.The pipeline runs automatically on the push.

D.The pipeline does not run because the branch is not main.

AnswerC

This outcome is expected because the repository's Azure Pipelines YAML defines a continuous integration (CI) trigger with a branch include filter such as `releases/*`. Since `releases/v1.0` matches that pattern, the push event automatically queues a new pipeline run, even without a pull request. The filter comparison uses glob-style matching on the full branch ref, and Azure Pipelines evaluates it at the time the push is received, making the run immediate and unattended.

Why this answer

Azure Pipelines, by default, triggers a pipeline run automatically on any push to any branch unless a trigger filter is explicitly configured. The branch name 'releases/v1.0' is valid and does not contain any characters that would prevent a trigger; dots are allowed in branch names. The pipeline will execute the steps defined in the YAML file for that branch.

Exam trap

The trap here is that candidates may assume branch names with dots are invalid or that pipelines only run on the main branch, but Azure Pipelines treats all branches equally by default and dots are perfectly valid in Git branch names.

How to eliminate wrong answers

Option A is wrong because Azure Pipelines does not restrict branch names containing dots; dots are valid characters in Git branch names and do not cause pipeline failures. Option B is wrong because a push to a branch triggers the pipeline automatically by default, regardless of whether a pull request is created; pull request triggers are a separate configuration. Option D is wrong because Azure Pipelines does not require the branch to be 'main' to run; pipelines can be configured to trigger on any branch, and by default they trigger on all branches.

Full explanation →

491

MCQeasy

You are designing a build pipeline for a Python application that uses multiple external packages from PyPI. You want to ensure that builds are reproducible and not affected by package updates. Which strategy should you use?

A.Use a Pipfile and Pipfile.lock without version pinning.

B.Use a dependency update tool like Dependabot weekly.

C.Pin exact versions in requirements.txt.

D.Use 'pip install <package>' without version specifiers.

AnswerC

Pinning exact versions in requirements.txt using `==` (e.g., `package==1.2.3`) forces pip to install the same version every time, regardless of when or where the install runs. This makes the build deterministic, ensuring that all environments—development, CI, and production—use the exact same library versions, which is the core requirement for reproducible builds.

Why this answer

Pinning exact versions in requirements.txt ensures that the same package versions are installed every time, making builds reproducible. Option A is wrong because while Pipfile.lock contains exact resolved versions, the Pipfile itself typically uses version ranges; if the lock file is regenerated (e.g., via 'pipenv lock'), it may resolve to different package versions, breaking reproducibility. Option B is wrong: Dependabot is a tool for automated dependency updates, which introduces version changes and thus breaks reproducibility.

Option D is wrong because 'pip install <package>' without version specifiers fetches the latest version, causing non-deterministic builds.

Exam trap

A common trap is assuming that using a Pipfile.lock guarantees reproducibility. While Pipfile.lock does contain exact resolved versions, the Pipfile itself may specify version ranges, and if the lock file is regenerated (e.g., via 'pipenv lock'), it could resolve to different versions if the range allows updates. For true reproducibility, pinning exact versions in requirements.txt is more robust.

Full explanation →

492

MCQmedium

Your organization uses GitHub Actions. You need to create a reusable workflow that builds and tests a Node.js application. Which approach should you use to define the workflow?

A.Define a standard workflow in .github/workflows/build.yml

B.Use a composite action to encapsulate the build steps

C.Create a custom action and reference it in multiple workflows

D.Define a reusable workflow with 'on: workflow_call'

AnswerD

Defining a reusable workflow with on: workflow_call is correct because it makes the workflow callable from other workflows using the uses: syntax (e.g., uses: ./.github/workflows/build.yml), allowing you to create a standard build pipeline that can be referenced by many workflows without duplicating job definitions.

Why this answer

Reusable workflows are defined in a separate file with workflow_call trigger. Option A is wrong because it defines a workflow that cannot be reused. Option B is wrong because actions are different from workflows.

Option C is wrong because composite actions are for multiple steps, not entire workflows.

Full explanation →

493

MCQhard

You are reviewing a Data Collection Rule (DCR) for an Azure virtual machine. The DCR is assigned to the VM, and the Azure Monitor Agent is installed. After one hour, no performance data appears in the Log Analytics workspace. What is the most likely cause?

A.The workspace resource ID is incorrectly formatted.

B.The data flow streams property does not include 'Microsoft-Perf'.

C.The counter specifier uses the wrong format for Windows performance counters.

D.The sampling frequency of 60 seconds is too low and data is being throttled.

AnswerB

The data flow streams property does not include 'Microsoft-Perf'. For Windows performance counters to be collected in an Azure Monitor DCR, the 'dataFlows' section must map the 'Microsoft-Perf' stream to the destination workspace; without this stream explicitly listed, the DCR lacks the required linkage for performance data ingestion, and no counter data will flow.

Why this answer

The most likely cause is that the data flow streams property in the DCR does not include 'Microsoft-Perf'. The Azure Monitor Agent uses DCRs to define which data to collect and where to send it. Without the 'Microsoft-Perf' stream specified in the dataFlows section, performance counters are not collected, even if the counter specifiers are correctly defined.

The workspace resource ID and counter format may be correct, but the missing stream prevents any performance data from being ingested.

Exam trap

The trap here is that candidates focus on the counter specifier format or sampling frequency, overlooking the critical data flow stream property which is the actual pipeline that enables data ingestion.

How to eliminate wrong answers

Option A is wrong because an incorrectly formatted workspace resource ID would typically cause a configuration error or a failure to connect, not a silent absence of data after one hour; the agent would log an error. Option B is wrong because it is actually the correct answer, not a wrong option. Option C is wrong because the counter specifier format (e.g., '\Processor(_Total)\% Processor Time' for Windows) is validated at DCR creation time, and an incorrect format would result in a schema validation error, not a one-hour delay with no data.

Option D is wrong because a sampling frequency of 60 seconds is standard and not too low; Azure Monitor does not throttle data based on sampling frequency, and throttling would affect all data types, not just performance counters.

Full explanation →

494

MCQmedium

Refer to the exhibit. You have this YAML pipeline in an Azure Repos repository. What is the expected behavior when a pull request is created from a feature branch to the main branch?

A.The pipeline runs twice: once on PR creation and once on merge.

B.The pipeline runs automatically on the PR to main, triggered by the pr trigger.

C.The pipeline runs when the PR is merged to main, triggered by the trigger block.

D.The pipeline does not run automatically on the PR; it must be triggered manually or via branch policy.

AnswerD

No automatic trigger for PRs to main; the pr trigger is only for develop.

Why this answer

The YAML pipeline shown does not include a `pr` trigger, and the `trigger` block only applies to CI (continuous integration) builds on branch pushes, not pull requests. Without a `pr` trigger, Azure Pipelines does not automatically run on pull request creation; it must be triggered manually or via a branch policy configured in the repository settings.

Exam trap

The trap here is that candidates often assume the `trigger` block also applies to pull requests, but in Azure Pipelines, `trigger` and `pr` are separate, and omitting `pr` means no automatic PR build occurs.

How to eliminate wrong answers

Option A is wrong because the pipeline does not have a `pr` trigger, so it will not run on PR creation, and the `trigger` block only triggers on merges to main, not on PR creation. Option B is wrong because the `pr` trigger is not defined in the YAML; without it, Azure Pipelines does not automatically run on PRs to main. Option C is wrong because while the `trigger` block would cause the pipeline to run on a merge to main, the question asks about behavior when a PR is created, not when it is merged.

Full explanation →

495

MCQmedium

Your organization uses Microsoft Purview Data Loss Prevention (DLP) to protect sensitive data in Azure DevOps repositories. The compliance team has identified that source code containing credit card numbers (PCI data) was accidentally committed to a public repository. You need to implement a solution that meets the following requirements: (1) Automatically scan all new commits in Azure Repos for sensitive data types like credit card numbers. (2) If sensitive data is detected, automatically block the push and notify the security team. (3) The solution must be integrated with Microsoft Purview and Azure DevOps. Option A: Enable Microsoft Purview Data Loss Prevention for Azure DevOps, which automatically scans and blocks pushes containing sensitive data. Option B: Configure a branch policy in Azure Repos that runs a custom Azure Function via a service hook when a push occurs, and the function uses Purview APIs to scan the commit. Option C: Use GitHub Advanced Security secret scanning for Azure Repos, and configure a webhook to notify the security team. Option D: Install a third-party extension from Azure DevOps Marketplace that provides content scanning and configure it to block pushes. Which option is the most appropriate and efficient?

A.Enable Microsoft Purview Data Loss Prevention for Azure DevOps, which automatically scans and blocks pushes containing sensitive data

B.Configure a branch policy in Azure Repos that runs a custom Azure Function via a service hook when a push occurs, and the function uses Purview APIs to scan the commit

C.Use GitHub Advanced Security secret scanning for Azure Repos, and configure a webhook to notify the security team

D.Install a third-party extension from Azure DevOps Marketplace that provides content scanning and configure it to block pushes

AnswerA

This is the native Microsoft solution that meets all requirements.

Why this answer

Microsoft Purview DLP for Azure DevOps (currently in preview) provides native integration to automatically scan commits for sensitive data types like credit card numbers and block the push if detected, meeting all requirements natively without custom development. Option B describes a custom Azure Function approach which is more complex and not native, and may not integrate as seamlessly with Purview. Option C uses GitHub Advanced Security, which is not available for Azure Repos (it's for GitHub repositories).

Option D relies on a third-party extension, which may not have native Purview integration and could be less reliable. Therefore, Option A is the most appropriate and efficient solution.

Full explanation →

496

MCQhard

Your team uses Azure Boards with a custom process. You need to ensure that when a bug is closed, it automatically triggers a new release pipeline. Which approach should you use?

A.Configure a CI trigger in the release pipeline.

B.Add a release gate that checks for closed bugs.

C.Create an Azure Function that polls work items.

D.Set up a Service Hook from Azure Boards to Azure Pipelines.

AnswerD

Service Hooks in Azure Boards can subscribe to work item state change events and directly trigger an Azure Pipelines release, providing the native, event-driven integration needed to initiate a release when a bug is closed or another work item field is updated.

Why this answer

Service Hooks in Azure DevOps allow you to integrate Azure Boards with Azure Pipelines by subscribing to events like 'work item updated' or 'work item state changed'. When a bug is closed (state changed to 'Closed'), a Service Hook can automatically trigger a release pipeline, enabling event-driven automation without polling or custom code. This is the correct approach because it directly connects the work item state change to pipeline execution.

Exam trap

The trap here is that candidates often confuse CI triggers (which respond to code changes) with event-driven triggers from work items, or mistakenly think release gates can initiate pipelines rather than just gate ongoing releases.

How to eliminate wrong answers

Option A is wrong because a CI trigger in a release pipeline is designed to fire on code changes (e.g., a commit or pull request merge), not on work item state changes in Azure Boards. Option B is wrong because release gates are conditions evaluated during a release (e.g., checking for approvals or quality metrics), not triggers that initiate a new release; they cannot start a pipeline based on a work item being closed. Option C is wrong because creating an Azure Function to poll work items introduces unnecessary complexity, latency, and overhead compared to the native event-driven Service Hook mechanism, which is simpler and more reliable.

Full explanation →

497

MCQhard

Your company uses Microsoft Defender for Cloud to monitor Azure DevOps environments. You receive an alert that a service principal has excessive permissions. What is the first step you should take to investigate and remediate?

A.Reduce the service principal's permissions to the minimum required.

B.Review the Microsoft Entra ID audit logs for the service principal.

C.Immediately delete the service principal.

D.Reset the service principal's credentials.

AnswerB

Reviewing the Microsoft Entra ID audit logs is the correct first step because these logs provide a detailed trail of the service principal's sign-ins, granted permissions, and activities, allowing you to determine whether the alert indicates a real threat or normal operation before taking any corrective action.

Why this answer

Reviewing the Microsoft Entra ID audit logs is the correct first step because it allows you to investigate the service principal's activity, such as which resources it accessed, when, and from where, before taking any remediation action. This forensic analysis is essential to understand the scope of the excessive permissions and to ensure that reducing permissions or other actions do not inadvertently disrupt legitimate operations. Without this step, you risk breaking functionality or missing evidence of misuse.

Exam trap

The trap here is that candidates often jump to immediate remediation (reducing permissions or deleting the principal) without first performing a forensic investigation, failing to recognize that the first step in incident response is always to gather evidence via audit logs to understand the scope and impact.

How to eliminate wrong answers

Option A is wrong because reducing permissions immediately without first investigating the audit logs could disrupt legitimate automated processes or deployments that depend on those permissions, and it skips the necessary forensic step to understand the context of the alert. Option C is wrong because immediately deleting the service principal is a drastic action that could cause widespread service outages, as the service principal may be essential for CI/CD pipelines or other automated tasks, and it destroys the ability to audit past activities. Option D is wrong because resetting the service principal's credentials (e.g., client secret or certificate) addresses credential compromise but does not remediate the root cause of excessive permissions, and it should be done only after investigation to avoid breaking active sessions without understanding the impact.

Full explanation →

498

MCQhard

You are designing a centralized logging strategy for multiple microservices hosted in Azure Kubernetes Service (AKS). Each microservice writes logs in JSON format to stdout/stderr. The operations team needs to query logs across all services and correlate them with application performance metrics. Which solution provides the best integration?

A.Configure AKS to send logs to Azure Blob Storage and use Azure Storage Analytics for querying.

B.Enable Container Insights in Azure Monitor to collect stdout/stderr logs and metrics into a Log Analytics workspace.

C.Stream logs to Azure Event Hubs and then to Azure Data Explorer for analysis.

D.Deploy the Application Insights agent as a DaemonSet in AKS and send logs directly to Application Insights.

AnswerB

Container Insights is the native Azure Monitor solution for AKS: it deploys a Log Analytics agent as a DaemonSet to collect stdout/stderr logs, performance metrics, and container inventory into a Log Analytics workspace. This enables rich Kusto Query Language (KQL) queries, alerting, and correlation with other Azure Monitor data, making it the correct centralized logging approach for AKS workloads.

Why this answer

Container Insights in Azure Monitor is the best solution because it natively collects stdout/stderr logs from AKS containers and correlates them with performance metrics (CPU, memory, disk, network) in a single Log Analytics workspace. This enables the operations team to query logs across all microservices using KQL and join them with metrics for end-to-end troubleshooting, without additional infrastructure or data movement.

Exam trap

The trap here is that candidates often confuse Application Insights (designed for application-level telemetry) with Container Insights (designed for container-level logs and metrics), leading them to choose Option D, which lacks the native AKS metric correlation and Log Analytics workspace integration required for centralized querying.

How to eliminate wrong answers

Option A is wrong because Azure Blob Storage is a cold storage tier with no native query capability for JSON logs; Storage Analytics provides only storage metrics, not log search or correlation with application performance metrics. Option C is wrong because streaming logs to Event Hubs and then to Azure Data Explorer adds unnecessary complexity and latency; while ADX is a powerful analytics engine, it is not the integrated, out-of-the-box solution for AKS log and metric correlation that Container Insights provides. Option D is wrong because the Application Insights agent as a DaemonSet sends logs directly to Application Insights, which is designed for application-level telemetry (traces, exceptions, requests) rather than container stdout/stderr logs and AKS node/container metrics; it lacks the native integration with AKS cluster-level metrics and Log Analytics workspace that Container Insights offers.

Full explanation →

499

MCQmedium

Refer to the exhibit. An Azure DevOps pipeline has the YAML configuration shown. A developer creates a pull request from a feature branch to the develop branch. What will happen?

A.The pipeline runs only if the PR is merged

B.The pipeline runs as a CI build on the feature branch

C.The pipeline runs as a PR validation build

D.The pipeline does not run automatically

AnswerD

The CI trigger only includes `develop` and `main`, while the PR trigger only includes `main`; the exhibited feature-branch push/PR matches neither branch filter. Consequently, the pipeline has no automatic trigger event and will not run on its own.

Why this answer

The YAML configuration does not include a `trigger` or `pr` trigger, so by default the pipeline only runs on pushes to branches that have a pipeline configured, not on pull requests. Since the developer creates a PR from a feature branch to develop, and no trigger is defined for the feature branch or PR validation, the pipeline does not run automatically.

Exam trap

The trap here is that candidates assume a pull request automatically triggers a pipeline, but Azure DevOps requires an explicit `pr` trigger for PR validation builds, and without it, no automatic execution occurs.

How to eliminate wrong answers

Option A is wrong because the pipeline does not run on merge unless a trigger is defined for the target branch (develop) or the PR is configured to trigger on completion; without a trigger, no automatic run occurs. Option B is wrong because a CI build on the feature branch would require a `trigger` (e.g., `trigger: branches: include: ['feature/*']`) which is absent in the YAML. Option C is wrong because a PR validation build requires a `pr` trigger (e.g., `pr: branches: include: ['develop']`) which is not present in the configuration.

Full explanation →

500

MCQeasy

Your team uses Azure Pipelines and wants to ensure that builds cannot access the internet to prevent data exfiltration. What should you do?

A.Create a private agent pool with no internet access

B.Use Microsoft-hosted agents with network isolation

C.Set the pipeline variable 'DisableInternetAccess' to true

D.Use self-hosted agents on an isolated network

AnswerA, B, D

This is similar to option A.

Why this answer

Microsoft-hosted agents with network isolation (B) is a valid Azure feature. However, using a private agent pool with no internet access (A) or self-hosted agents on an isolated network (D) are also valid methods to prevent internet access for builds. The question should be revised to specify a constraint that excludes these options, or the correct options should include A and D.

Exam trap

The provided trap note falsely claims that a private agent pool cannot address network access. In reality, private agent pools can be placed in isolated networks. The true trap is that multiple answer choices are correct.

How to eliminate wrong answers

Option A is wrong because a private agent pool simply refers to agents you manage; it does not inherently restrict internet access unless you configure the underlying network to block it. Option C is wrong because there is no built-in pipeline variable named 'DisableInternetAccess' in Azure Pipelines; this is a fictional setting. Option D is wrong because while self-hosted agents on an isolated network can block internet access, the question asks for a solution using Azure Pipelines, and Microsoft-hosted agents with network isolation provide a managed, scalable approach without requiring you to maintain your own infrastructure.

Full explanation →

501

MCQmedium

Your team deploys a web application to Azure App Service using Azure Pipelines. The application requires a configuration file that contains connection strings and app settings. You need to ensure that the configuration is environment-specific and that sensitive values are not exposed in the pipeline logs. The configuration file is stored in a Git repository with different branches for each environment. You also need to support local development with the same configuration approach. Which strategy should you use?

A.Store all settings, including secrets, in the config file in each branch. Use a script to replace tokens.

B.Use Azure App Service slots with sticky settings and store all settings in a single config file committed to the repository.

C.Store environment-specific settings in Azure App Service configuration, and use variable groups in Azure Pipelines for secrets. Use token replacement in the config file during deployment.

D.Use the same config file for all environments and override settings using pipeline variables based on branch name.

AnswerC

App Service configuration handles non-secrets, variable groups for secrets, and token replacement for environment values.

Why this answer

The recommended approach is to store environment-specific settings (non-secret) in Azure App Service configuration settings, and store secrets in Azure Pipelines variable groups. During deployment, use token replacement in the config file to replace placeholders with actual values. This ensures secrets are not exposed in logs or stored in the repository, and supports local development by using config transforms.

Option A exposes secrets by storing them in the repository. Option B uses a single config file and sticky settings, which does not address environment-specific configurations and can be insecure. Option D relies on branch-based pipeline variables, which may not support local development and can lead to secrets exposure in logs if not properly handled.

Full explanation →

502

MCQeasy

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

A.Require pull request reviews before merging.

B.Require status checks to pass before merging.

C.Require linear history.

D.Require signed commits.

AnswerD

Requiring signed commits is a branch protection rule that rejects any commit not cryptographically signed with a verified GPG or S/MIME key, authenticating the committer and ensuring content integrity. This directly enforces that every commit must be signed, exactly as the requirement demands.

Why this answer

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

Exam trap

The trap here is that candidates confuse 'Require signed commits' with 'Require status checks to pass before merging', mistakenly thinking a CI status check can enforce signing, but GitHub's built-in rule is the only way to natively reject unsigned commits at the server level.

How to eliminate wrong answers

Option A is wrong because requiring pull request reviews before merging enforces code review, not commit signing. Option B is wrong because requiring status checks to pass before merging enforces CI/CD pipeline checks (e.g., tests, builds), not cryptographic signing of commits. Option C is wrong because requiring linear history enforces a linear commit graph (no merge commits), but does not require commits to be signed with a GPG key.

Full explanation →

503

MCQhard

You are implementing a release pipeline for a containerized application using Azure Kubernetes Service (AKS). The pipeline should use canary deployments to gradually shift traffic from the stable version to the new version. Which strategy should you use to manage the traffic shift?

A.Blue-green deployment strategy

B.Rolling update strategy

C.A/B testing with feature flags

D.Canary deployment using a service mesh (e.g., Istio)

AnswerD

Canary deployment using a service mesh (e.g., Istio) is correct because Istio's traffic management rules (VirtualService and DestinationRule) allow precise percentage-based traffic splitting between the stable and canary versions of a containerized workload. This enables gradual exposure, real-time metrics collection, and automated or manual rollback, making it the ideal strategy for safely validating a new release in production.

Why this answer

A service mesh like Istio provides fine-grained traffic management capabilities (e.g., using VirtualService and DestinationRule resources) that allow you to route a specific percentage of traffic to the new canary version while the rest goes to the stable version. This enables gradual traffic shifting without modifying application code, and supports advanced routing rules based on headers or weights, which is essential for canary deployments in AKS.

Exam trap

The trap here is that candidates confuse canary deployments with blue-green or rolling updates, not realizing that only a service mesh (or similar traffic-splitting mechanism) provides the precise, percentage-based traffic shifting required for a true canary release in Kubernetes.

How to eliminate wrong answers

Option A is wrong because blue-green deployment switches all traffic at once between two environments (blue and green), not gradually shifting traffic as required by canary deployments. Option B is wrong because a rolling update replaces pods incrementally but does not allow fine-grained traffic splitting between versions; it updates all pods to the new version over time without a controlled canary phase. Option C is wrong because A/B testing with feature flags controls feature exposure at the application level (e.g., via code toggles), not at the network/traffic level, and does not inherently manage traffic shifting between container versions in a Kubernetes cluster.

Full explanation →

504

Drag & Dropmedium

Drag and drop the steps to implement infrastructure as code with Azure Resource Manager (ARM) templates into the correct order.

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

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

The correct order for implementing infrastructure as code with ARM templates is: first define the ARM template, then parameterize it to make it reusable, then store it in version control (e.g., Git) to track changes, then validate the deployment using the what-if operation to preview changes, and finally deploy the template to Azure.

Full explanation →

505

MCQeasy

A DevOps engineer needs to ensure that only approved Azure Resource Manager (ARM) templates are used for deployments. They want to enforce this at the subscription level. Which Azure service should they use?

A.Azure Role-Based Access Control (RBAC)

B.Azure Policy

C.Azure Blueprints

D.Azure Management Groups

AnswerB

Azure Policy can evaluate ARM template properties during deployment and deny or audit resources that do not comply with defined rules, such as allowed template versions or specific resource types. This enables enforcing approved templates across the enterprise by blocking non-compliant deployment attempts.

Why this answer

Azure Policy is the correct service because it allows you to create, assign, and manage policies that enforce specific rules on your Azure resources. You can define a custom policy to audit or deny resources that do not contain metadata indicating they were deployed from an approved ARM template. Azure Policy evaluates all resource creation and update requests against these rules, blocking or auditing non-compliant deployments at the subscription level.

RBAC only controls who can deploy, not what is deployed; Azure Blueprints packages templates but does not enforce their exclusive use.

Exam trap

The trap here is that candidates often confuse Azure Policy with Azure RBAC, thinking that role-based access can restrict template content, when in fact RBAC only controls who can deploy, not what they deploy.

How to eliminate wrong answers

Option A is wrong because Azure RBAC controls who can perform actions (authentication and authorization) on resources, not what specific ARM templates are allowed; it cannot inspect the content or source of a template. Option C is wrong because Azure Blueprints is used to orchestrate the deployment of a repeatable set of Azure resources (including policies, RBAC, and resource groups) but does not itself enforce which ARM templates are used; it relies on Azure Policy for enforcement. Option D is wrong because Azure Management Groups provide a hierarchical structure for managing access, policies, and compliance across multiple subscriptions, but they do not directly enforce ARM template restrictions; they are a container for applying policies, not the enforcement mechanism itself.

Full explanation →

506

MCQhard

Your team uses GitHub Actions for CI/CD. You need to enforce that all workflows use approved actions from a private marketplace. Which GitHub feature should you configure?

A.Use environment secrets to store allowed action names.

B.Require self-hosted runners.

C.Set the Actions permissions to 'Allow only specified actions'.

D.Configure OpenID Connect (OIDC) for Actions.

AnswerC

Setting Actions permissions to 'Allow only specified actions' creates an explicit allowlist at the repository or organization level, so only actions (and optional version constraints) that you add are permitted. Any action not on that list is blocked from running, which is exactly the enforcement mechanism needed for this policy.

Why this answer

The 'Allow only specified actions' setting in GitHub Actions permissions allows you to restrict workflow execution to a curated list of actions from a private marketplace or specific verified publishers. This enforces governance by preventing the use of unapproved actions, which is critical for compliance and security in enterprise CI/CD pipelines.

Exam trap

The trap here is that candidates often confuse runner-level controls (self-hosted runners) with action-level governance, mistakenly thinking that restricting where code runs also restricts what actions can be used.

How to eliminate wrong answers

Option A is wrong because environment secrets are used to store sensitive values like API tokens, not to enforce action allowlists; they cannot control which actions are permitted at the repository or organization level. Option B is wrong because self-hosted runners control where workflows execute, not which actions they can use; they do not provide a mechanism to restrict action selection. Option D is wrong because OpenID Connect (OIDC) is used for short-lived authentication tokens between GitHub Actions and cloud providers, not for managing action permissions or marketplace access.

Full explanation →

507

MCQhard

You have the YAML pipeline snippet shown in the exhibit. The first run produces version 1.0.0. What will be the version produced on the third run?

A.1.0.1

B.1.0.3

C.1.0.2

D.1.0.0

AnswerC

The counter expression returns 0 on the first run, 1 on the second, and 2 on the third for a given key. With the prefix '1.0', the third run correctly produces 1.0.2, matching the exhibit.

Why this answer

The YAML pipeline uses a counter expression `$[counter(format('{0}.{1}', variables['major'], variables['minor']), 0)]` for the patch version. The counter starts at 0 for the first run, producing version 1.0.0. Each subsequent run increments the counter by 1, so the second run produces 1.0.1, and the third run produces 1.0.2.

Therefore, option C is correct.

Exam trap

The trap here is that candidates may mistakenly think the counter starts at 1 or that the version increments by more than 1 per run, leading them to choose 1.0.1 or 1.0.3 instead of understanding the exact sequential increment from the seed value.

How to eliminate wrong answers

Option A is wrong because 1.0.1 would be the version produced on the second run, not the third. Option B is wrong because 1.0.3 would be the version produced on the fourth run, as the counter increments by 1 each run. Option D is wrong because 1.0.0 is the version produced on the first run, and the counter does not reset to 0 on subsequent runs.

Full explanation →

508

MCQhard

Refer to the exhibit. The workflow runs successfully but the deployment fails because the Azure CLI is not authenticated. What should you add to the workflow to authenticate?

A.Add the 'azure/login' action with Azure credentials

B.Add the 'actions/setup-node' action

C.Add the 'azure/webapps-deploy' action

D.Add the 'actions/github-script' action to use the GitHub token

AnswerA

Adding the 'azure/login' action with Azure credentials is correct because it authenticates the Azure CLI with a service principal, establishing an Azure session (via the `AZURE_CREDENTIALS` secret containing client ID, client secret, tenant ID, and subscription ID) that subsequent steps can use to run `az` commands. Without this authentication step, any Azure CLI command in the workflow fails with an authentication error, even if the workflow itself runs successfully.

Why this answer

The Azure CLI in the workflow requires authentication to interact with Azure resources. Adding the 'azure/login' action with valid Azure credentials (e.g., service principal secrets or OpenID Connect) establishes the necessary authentication context before any Azure CLI commands are executed, resolving the 'not authenticated' error.

Exam trap

The trap here is that candidates may assume any Azure action (like 'azure/webapps-deploy') implicitly handles authentication, but in reality, authentication must be explicitly performed before any Azure CLI or SDK calls.

How to eliminate wrong answers

Option B is wrong because 'actions/setup-node' sets up a Node.js environment and has no role in Azure authentication. Option C is wrong because 'azure/webapps-deploy' deploys to Azure Web Apps but does not authenticate the Azure CLI; it relies on prior authentication from 'azure/login'. Option D is wrong because 'actions/github-script' runs scripts using the GitHub token, which is not valid for authenticating to Azure resources.

Full explanation →

509

MCQhard

Your release pipeline uses a 'Run Azure CLI' task to execute a script. The script authenticates using a service principal. However, the deployment fails with 'insufficient privileges to complete the operation'. What is the most likely cause?

A.The Azure CLI task is not logged in.

B.The service principal secret has expired.

C.The service principal lacks the necessary RBAC role on the target resource.

D.The service principal does not have a secret.

AnswerC

The service principal is authenticated but does not have the required Azure RBAC role (e.g., Contributor, Reader, or a custom role) on the target resource or resource group. Azure CLI commands that attempt to perform an action without the necessary role assignment will return an authorization error, so assigning the appropriate RBAC role resolves the issue.

Why this answer

The error 'insufficient privileges to complete the operation' indicates that the service principal successfully authenticated but lacks the required Azure RBAC role on the target resource. Even with a valid secret and a logged-in Azure CLI session, the service principal must have an assigned role (e.g., Contributor, Owner, or a custom role) that grants the specific permissions needed for the deployment operation.

Exam trap

The trap here is that candidates confuse authentication failures (invalid credentials, expired secrets) with authorization failures (insufficient RBAC permissions), leading them to incorrectly select options related to credential issues when the error message explicitly states 'insufficient privileges'.

How to eliminate wrong answers

Option A is wrong because the 'Run Azure CLI' task automatically handles authentication via the service principal connection; if the task were not logged in, the error would be an authentication failure (e.g., 'login failed' or 'unable to acquire token'), not an authorization error. Option B is wrong because an expired secret would cause an authentication failure (e.g., 'invalid client secret' or 'AADSTS7000222'), not an 'insufficient privileges' error which occurs after successful token acquisition. Option D is wrong because if the service principal had no secret, the Azure CLI task would fail to authenticate entirely, producing a credential-related error rather than an RBAC authorization error.

Full explanation →

510

MCQeasy

You are designing a release pipeline in Azure Pipelines that deploys a web app to multiple environments (dev, test, prod). You want to ensure that the same build artifact is deployed to each environment without rebuilding. Which trigger type should you use?

A.Pull request trigger

B.Continuous deployment trigger on the release pipeline

C.Schedule trigger

D.Build completion trigger

AnswerB

A continuous deployment trigger on the release pipeline is the artifact trigger that watches a connected build artifact for a successful build. When a new version of that artifact is produced, the trigger automatically creates a release and promotes that exact artifact through every stage, so all environments test and receive the same immutable build. This precisely matches the requirement to use the same artifact without rebuilding or recompiling.

Why this answer

A continuous deployment trigger on the release pipeline automatically starts a new release deployment whenever a new build artifact is available, ensuring the same build artifact is deployed to each environment without rebuilding. This is the correct choice because the requirement is to deploy the same artifact across multiple environments, and the continuous deployment trigger is designed to initiate a release pipeline after a build completes, preserving the artifact for downstream stages.

Exam trap

The trap here is that candidates often confuse build completion triggers (which chain builds) with continuous deployment triggers (which chain builds to releases), leading them to select build completion trigger thinking it will automatically deploy to environments, but it only triggers another build pipeline, not a release.

How to eliminate wrong answers

Option A is wrong because a pull request trigger is used to validate code changes in a build pipeline, not to deploy existing artifacts to multiple environments; it triggers a build on PR creation, not a release deployment. Option C is wrong because a schedule trigger runs the release pipeline at specified times, which does not guarantee that the same build artifact is used across environments and may deploy outdated or different artifacts if builds occur between scheduled runs. Option D is wrong because a build completion trigger is used to chain build pipelines, not release pipelines; it triggers another build pipeline when a build completes, not a release deployment.

Full explanation →

511

MCQhard

Your company uses Azure DevOps for CI/CD. You have a YAML build pipeline that builds a .NET Core application and publishes artifacts. The build runs on a Microsoft-hosted agent. Recently, the build started failing with the error 'The process cannot access the file because it is being used by another process.' This occurs intermittently during the 'dotnet build' step. The pipeline uses multiple jobs that run in parallel. You suspect that one job is interfering with another because they share the same workspace on the agent. You need to ensure that each job runs in its own isolated workspace. What should you do?

A.Add a 'demands' section to the job to ensure each job runs on a different agent.

B.Set 'workspace: clean' in the pipeline root.

C.Use a 'multi-job' configuration with a matrix to run each job in separate folders.

D.Set 'clean: all' on the checkout step in each job.

AnswerD

Setting `clean: all` on the checkout step in each job is the correct fix because it deletes the entire workspace, including all files from previous jobs, before the repository is checked out. This guarantees a fresh, isolated environment for every job, preventing stale artifacts from affecting the build.

Why this answer

Setting 'clean: all' on the checkout step ensures that the workspace is cleaned before each job runs, preventing file conflicts caused by shared workspace on the agent. Option A is wrong because 'demands' are for selecting agents with specific capabilities, not for workspace isolation. Option B is wrong because 'workspace: clean' is not a valid setting at the pipeline root; workspace cleaning is configured per checkout step.

Option C is wrong because a multi-job configuration with a matrix is used for parallelizing builds across different configurations, not for isolating workspaces.

Full explanation →

512

MCQeasy

Your team uses GitHub Copilot for code suggestions. To comply with your organization's data protection policies, you need to ensure that code snippets and prompts sent to Copilot are not stored or used by Microsoft for service improvement. What should you configure?

A.Set a compliance grade in Microsoft Defender for Cloud

B.Enable the 'Data Exclusion' setting in Copilot's enterprise settings

C.Apply a Microsoft Purview Data Loss Prevention policy

D.Configure Azure OpenAI Service content filtering

AnswerB

Enabling the 'Data Exclusion' setting in Copilot's enterprise settings is the correct action because it instructs GitHub not to store or use your code snippets for service improvement purposes, aligning with your requirement to ensure code is not retained or used for model training. This setting is specifically designed to prevent Microsoft from retaining or using your code data beyond what is necessary to provide the Copilot service.

Why this answer

GitHub Copilot's enterprise settings include a 'Data Exclusion' feature that, when enabled, prevents Microsoft from storing or using your code snippets and prompts for service improvement. This directly addresses the data protection policy requirement by ensuring that your organization's code is not retained or analyzed by Microsoft beyond the immediate suggestion generation.

Exam trap

The trap here is that candidates may confuse data protection controls for Copilot with broader Microsoft security tools like Defender for Cloud or Purview DLP, which address different compliance aspects and do not directly control Copilot's data storage behavior.

How to eliminate wrong answers

Option A is wrong because Microsoft Defender for Cloud compliance grades assess the security posture of cloud resources, not the data handling policies of third-party tools like GitHub Copilot. Option C is wrong because Microsoft Purview Data Loss Prevention (DLP) policies are designed to prevent sensitive data from being shared or leaked across services like email or SharePoint, but they do not control how GitHub Copilot processes or stores code snippets. Option D is wrong because Azure OpenAI Service content filtering applies to content moderation in Azure OpenAI deployments, not to GitHub Copilot's data storage or usage policies.

Full explanation →

513

MCQhard

Refer to the exhibit. A developer queues a build with a variable 'BuildConfiguration' set to 'Release'. The pipeline definition has a default variable 'BuildConfiguration' set to 'Debug' and does not allow overrides at queue time. What will be the value of 'BuildConfiguration' during the build?

A.Debug

B.Release

C.null

D.The build fails with an error

AnswerA

Because the variable has a default value defined in the pipeline and overrides at queue time are not enabled, the build uses the configured default "Debug". The system substitutes this value before any tasks run, so the build executes as if Debug were explicitly set.

Why this answer

The pipeline definition does not allow overrides at queue time, so the variable value passed in the queue command is ignored; the default value 'Debug' is used.

Full explanation →

514

MCQhard

Refer to the exhibit. A team wants to release version 1.0 from the main branch. They notice that the tag v1.0 is already on the current main commit. However, they also see that the origin/feature/experiment branch has commits that are not merged into main. What is the most likely scenario?

A.The team should delete the experiment branch because it is not merged.

B.The tag v1.0 was applied to the wrong commit; it should be on the merge commit of the experiment branch.

C.The main branch is missing the experiment branch commits; a merge is required before release.

D.The experiment branch contains experimental work that was not intended for release; the tag v1.0 correctly marks the release on main.

AnswerD

The experiment branch was created for isolated, exploratory work and has intentionally never been merged into main, so none of its commits are part of the v1.0 release history. Tagging the main branch's commit correctly captures the exact state of the code that was built, tested, and validated for release. This is consistent with standard branching practices where release tags are applied to integration branches, not to feature or experiment branches.

Why this answer

The tag v1.0 is on the current main commit (9a8b7c6). The feature/experiment branch (1a2b3c4) is a child of the initial commit, but it is not merged into main. The main branch has commits that are ahead of the experiment branch.

The team wants to release v1.0 from main; the tag already exists. The presence of the experiment branch not merged suggests that it was not intended for this release. The most likely scenario is that the experiment branch was created from an older commit and is not ready for release, so it was not merged.

The release v1.0 is correctly tagged on main.

Full explanation →

515

MCQmedium

Your organization uses Azure DevOps and requires that all pipelines enforce branch policy for pull requests. A developer creates a pipeline that builds and tests code on push to any branch. The security team wants to ensure that no code can be deployed to production without passing through a pull request with required reviewers. Which action should you take to meet this requirement?

A.Disable CI triggers on the pipeline and require manual builds.

B.Modify the service connection to require admin approval.

C.Set the pipeline to require approval from the security team before running.

D.Configure branch policy on the main branch to require a pull request with a minimum number of reviewers.

AnswerD

Branch policies on the main branch are the correct Azure DevOps mechanism to enforce pull request requirements, including a minimum number of reviewers; once configured, any update to the main branch must go through a PR that meets the required reviewer count, preventing unreviewed changes from being merged.

Why this answer

Azure DevOps branch policies enforce that all changes to the main branch must go through a pull request with required reviewers. This ensures no code can be deployed to production without passing through the defined review process, meeting the security team's requirement.

Exam trap

The trap here is that candidates confuse pipeline-level approvals (like pre-deployment gates) with branch policies, which are the correct mechanism to enforce pull request workflows at the source control level.

How to eliminate wrong answers

Option A is wrong because disabling CI triggers and requiring manual builds does not enforce pull request review; it only prevents automatic builds on push, leaving the deployment path unsecured. Option B is wrong because modifying the service connection to require admin approval controls access to Azure resources but does not enforce a pull request workflow or code review before deployment. Option C is wrong because setting the pipeline to require approval from the security team before running adds a manual gate but does not prevent direct pushes to the main branch or enforce a pull request with reviewers.

Full explanation →

516

MCQmedium

You are reviewing an Azure Policy definition that denies pipeline creation if the pipeline template path is not '/pipeline-templates/my-template.yml'. What does this policy do?

A.Denies pipelines that use an outdated template version.

B.Allows only pipelines that use a specific YAML template.

C.Allows only pipelines in the pipeline-templates folder.

D.Denies any pipeline that does not use a specific YAML template.

AnswerD

This is correct because the policy definition uses a deny effect that triggers when the pipeline's YAML template path does not equal the specified value. As a result, any pipeline creation or update that references a different template or a non-matching path is blocked, effectively forcing all pipelines to use that exact YAML template.

Why this answer

This Azure Policy definition uses a 'deny' effect with a condition that checks whether the pipeline references a specific YAML template. If the pipeline does not reference that template, the policy denies the pipeline creation or update. Option D is correct because the policy explicitly denies any pipeline that does not use the specified YAML template, enforcing compliance by blocking non-compliant pipelines.

Exam trap

The trap here is that candidates often confuse 'deny' with 'audit' or 'allow' effects, or misinterpret the condition as restricting folder paths instead of template references, leading them to select options that describe permissive or location-based policies.

How to eliminate wrong answers

Option A is wrong because the policy does not check template version; it checks for the presence of a specific YAML template reference, not its version. Option B is wrong because the policy uses the 'deny' effect, not 'allow' or 'audit'; it blocks non-compliant pipelines rather than allowing only those that match. Option C is wrong because the policy does not restrict pipelines to a specific folder; it evaluates the YAML template reference in the pipeline definition, not the file path location.

Full explanation →

517

MCQeasy

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

A.Require branches to be up to date only

B.Require a pull request before merging only

C.Require status checks to pass before merging only

D.Require a pull request before merging and require branches to be up to date

AnswerD

Both settings enforce the required policies.

Why this answer

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

Exam trap

The trap here is that candidates often think 'Require status checks to pass before merging' alone covers both the approval and up-to-date requirements, but it does not enforce the pull request workflow or the branch freshness check unless those specific status checks are explicitly configured.

How to eliminate wrong answers

Option A is wrong because 'Require branches to be up to date only' does not enforce that pull requests require approval; it only ensures the branch is current, leaving the repository vulnerable to direct pushes without review. Option B is wrong because 'Require a pull request before merging only' does not enforce that the branch is up to date with the base branch, allowing merges from outdated branches that may break the build. Option C is wrong because 'Require status checks to pass before merging only' does not inherently require a pull request or an approval; it only mandates that defined status checks (e.g., CI tests) succeed, which can be bypassed by direct pushes if no PR requirement is set.

Full explanation →

518

MCQhard

Your organization uses Azure DevOps Server (on-premises) and plans to migrate to Azure DevOps Services. You have hundreds of classic build and release pipelines. You need to design a migration strategy that minimizes downtime and allows for a gradual transition. The team wants to use the new YAML-based pipelines after migration. What should you do?

A.Export the classic pipeline definitions as JSON, and manually recreate them as YAML pipelines in Azure DevOps Services.

B.Recreate all pipelines from scratch using YAML in the new organization.

C.Use the Azure DevOps Migration Tools to automatically convert classic pipelines to YAML.

D.Migrate all pipelines as-is (classic) and then plan a separate project to convert them to YAML.

AnswerA

This allows gradual migration while maintaining existing pipelines.

Why this answer

Exporting classic pipeline definitions as JSON and manually recreating them as YAML pipelines in Azure DevOps Services allows for a gradual migration, minimizing downtime. The team can convert pipelines incrementally, ensuring familiarity with YAML syntax and validating each pipeline before moving the next. Option B is wrong because recreating all pipelines from scratch is inefficient, error-prone, and does not leverage the existing pipeline logic.

Option C is wrong because the Azure DevOps Migration Tools are designed for data migration (work items, repos, etc.) and do not automatically convert classic pipelines to YAML. Option D is wrong because migrating pipelines as classic first and then planning a separate conversion project delays the adoption of YAML and introduces additional rework.

Full explanation →

519

Multi-Selectmedium

Which TWO features can you use to enforce quality gates before a production deployment in Azure Pipelines?

Select 2 answers

A.Scheduled triggers

B.Branch policies on repositories

C.Pipeline decorators

D.Approval checks on environments

E.Deployment gates evaluating health metrics

AnswersD, E

Approval checks on environments are a valid quality gate feature in Azure Pipelines. They require designated users or groups to explicitly approve a deployment before it is released to that environment, providing manual sign-off as a gate.

Why this answer

Approval checks on environments allow you to require manual sign-off before a release proceeds to a production stage. This enforces a quality gate by ensuring that a designated approver reviews and authorizes the deployment. Option E is correct because deployment gates evaluate health metrics (e.g., from Azure Monitor or Application Insights) automatically, blocking or allowing the deployment based on predefined conditions such as error rates or performance thresholds.

Exam trap

The trap here is that candidates confuse pre-deployment quality checks (like branch policies or scheduled triggers) with the specific deployment-time gates and approvals that Azure Pipelines provides for production environments.

Full explanation →

520

MCQmedium

You are implementing a secrets management strategy for a multi-cloud deployment. You need to securely store and rotate API keys for a third-party service. Which Azure service should you use?

A.Azure Key Vault

B.Microsoft Entra ID

C.Azure App Configuration

D.Azure Storage Blob

AnswerA

Azure Key Vault is a cloud service for securely storing and accessing secrets, keys, and certificates. It provides centralized secret management, fine-grained access policies, and built-in rotation capabilities, making it the appropriate choice for implementing a secrets management strategy.

Why this answer

Azure Key Vault is the correct service because it is designed specifically for securely storing and managing secrets, including API keys, with built-in support for automatic rotation via integration with Azure Event Grid and Azure Functions. It provides hardware security module (HSM)-backed encryption, access policies, and auditing, making it ideal for multi-cloud secrets management.

Exam trap

The trap here is that candidates often confuse Azure App Configuration's encrypted storage with Key Vault's secrets management, but App Configuration lacks automatic rotation and HSM-backed security, making it unsuitable for API keys.

How to eliminate wrong answers

Option B is wrong because Microsoft Entra ID (formerly Azure AD) is an identity and access management service for authentication and authorization, not a secrets store; it cannot natively store or rotate API keys. Option C is wrong because Azure App Configuration is optimized for managing application configuration settings and feature flags, not secrets; it lacks automatic rotation capabilities and HSM-backed encryption. Option D is wrong because Azure Storage Blob is an unstructured object storage service with no native secrets management features, rotation policies, or access control granularity required for API keys.

Full explanation →

521

MCQeasy

You are setting up a CI/CD pipeline for a microservices application deployed to Azure Kubernetes Service (AKS). Your team wants to automatically generate release notes from commit messages and work items. Which Azure DevOps feature should you use?

A.Copy Files task

B.Azure Repos Wiki

C.Azure Test Plans

D.Generate release notes task (from YAML pipeline)

AnswerD

The Generate release notes task in a YAML pipeline is purpose-built to automatically create a Markdown or HTML changelog from the build's associated commits, work items, and test results. It queries the build's metadata through Azure DevOps APIs and uses Handlebars or custom templates to render a formatted release-notes file, which can then be published as a pipeline artifact or copied to a target. This is the correct answer because it directly transforms source-control and work-item data into release documentation without manual authoring.

Why this answer

The Generate release notes task (from YAML pipeline) is the correct choice because it is specifically designed to automatically generate release notes from commit messages and work items in Azure Pipelines. This task parses the commit history and linked work items between two Git refs (e.g., tags or branches) and outputs a formatted markdown file, which can be published as an artifact or used in a release pipeline. It directly addresses the requirement to derive release notes from commits and work items without manual effort.

Exam trap

The trap here is that candidates may confuse the Generate release notes task with other documentation or file-copy tasks, but only this task is purpose-built to parse commit messages and work items into structured release notes within a YAML pipeline.

How to eliminate wrong answers

Option A is wrong because the Copy Files task is used to copy files from a source folder to a destination folder within the pipeline, not to generate release notes from commit messages or work items. Option B is wrong because Azure Repos Wiki is a documentation repository for project wikis, not a pipeline task that can automatically generate release notes from commits and work items. Option C is wrong because Azure Test Plans is a testing and quality management tool for manual and exploratory testing, not a feature for generating release notes from commit messages or work items.

Full explanation →

522

Multi-Selecteasy

Which THREE are true about using deployment groups in Azure Pipelines? (Choose 3)

Select 3 answers

A.Each machine in a deployment group must have the Azure Pipelines agent installed.

B.Deployment groups can only be used with Windows-based machines.

C.Deployment groups allow you to deploy an application to multiple machines in a rolling fashion.

D.Deployment groups can be used in classic release pipelines.

E.Deployment groups are tied to a specific environment.

AnswersA, C, D

The Azure Pipelines agent is required on every machine in a deployment group because it is the execution engine that receives and runs tasks from the pipeline. Without the agent, the deployment group cannot communicate with Azure Pipelines or execute any deployment steps on that target machine.

Why this answer

Each target machine in a deployment group requires the Azure Pipelines agent (either the Windows or Linux agent) to be installed and configured. The agent is responsible for executing the deployment tasks on that machine, and without it, the deployment group cannot communicate with or deploy to the machine.

Exam trap

The trap here is that candidates often confuse deployment groups with environments, assuming they are the same concept, but deployment groups are a legacy feature for multi-machine deployments while environments are a newer, more flexible abstraction that supports Kubernetes, virtual machines, and other resources.

Full explanation →

523

MCQmedium

Refer to the exhibit. An Azure DevOps administrator has configured the branch policy for the main branch as shown. A developer attempts to push a commit directly to the main branch. What will happen?

A.The push triggers the build validation pipeline

B.The push is allowed because allowForcePush is false

C.The push is rejected because branch policies require a pull request

D.The push is allowed because requireLinearHistory is false

AnswerC

Branch policies enforce pull request requirement.

Why this answer

The branch policy for the main branch requires that all changes be submitted via a pull request. When a developer attempts to push a commit directly to main, Azure Repos enforces this policy by rejecting the push. The push is blocked at the server level before any build validation or other checks occur.

Exam trap

The trap here is that candidates assume build validation or other policies are the primary gate, when in fact the 'Require a pull request before merging' setting is the first and most restrictive policy that blocks direct pushes regardless of other policy states.

How to eliminate wrong answers

Option A is wrong because the push is rejected before any build validation pipeline can be triggered; build validation only runs on pull request creation or updates, not on rejected direct pushes. Option B is wrong because allowForcePush being false only prevents force pushes, but the standard push is still blocked by the pull request requirement. Option D is wrong because requireLinearHistory being false does not affect the push rejection; linear history is a separate policy that controls merge commit types, not the ability to push directly.

Full explanation →

524

MCQmedium

A team is designing a release pipeline for a .NET Core web application. They want to deploy to Azure App Service using a blue-green deployment strategy to minimize downtime. Which Azure App Service feature should they use to implement this?

A.Use Azure Load Balancer in front of two separate App Services.

B.Use deployment slots with swap operation.

C.Configure auto-scaling rules.

D.Use Azure Traffic Manager to route traffic between slots.

AnswerB

Deployment slots with swap operation are the correct choice because they enable blue-green deployment: the new release is deployed to a staging slot, validated, and then swapped with the production slot, making the new version live with zero downtime. App Service automatically handles slot swap by warming up the target slot and preserving production settings, and the swap operation allows instant rollback if issues arise, which is ideal for a .NET Core web app release pipeline.

Why this answer

Deployment slots in Azure App Service support swap operations that enable blue-green deployment by swapping the production slot with a staging slot. This minimizes downtime because the swap is warm-up and validation is done in the staging slot before traffic is redirected, and the swap itself is instantaneous under the hood. No external load balancer or traffic manager is needed because the swap operation handles the routing internally.

Exam trap

The trap here is that candidates may confuse Azure Traffic Manager or Load Balancer as necessary for blue-green deployments, but Azure App Service's built-in deployment slots with swap operation are the correct and simplest implementation for this specific service.

How to eliminate wrong answers

Option A is wrong because using Azure Load Balancer in front of two separate App Services adds unnecessary complexity and cost; it does not leverage the built-in slot swap mechanism that Azure App Service provides for zero-downtime deployments. Option C is wrong because auto-scaling rules handle scaling out or in based on demand, not traffic routing or deployment strategies like blue-green. Option D is wrong because Azure Traffic Manager is a DNS-based traffic routing service that operates at the DNS level and cannot perform instant slot swaps; it would introduce DNS propagation delays and is not designed for the warm-up and validation workflow of blue-green deployments.

Full explanation →

525

MCQeasy

A company uses Azure DevOps and has a security policy that all pipeline runs must use a specific service connection scoped to a resource group. A developer reports that a pipeline fails with the error: 'The service connection does not have permission to access the resource.' What is the most likely cause?

A.The Azure subscription linked to the service connection is disabled.

B.The service connection name is misspelled in the pipeline YAML.

C.The variable group in the library does not include the service connection ID.

D.The service principal used by the service connection does not have the required role assignment on the resource group.

AnswerD

Missing role assignments cause access denied errors.

Why this answer

The error 'The service connection does not have permission to access the resource' indicates that the service principal associated with the service connection lacks the necessary Azure RBAC role assignment on the target resource group. In Azure DevOps, a service connection authenticates via a service principal, and that principal must have a role (e.g., Contributor) explicitly assigned at the resource group scope to perform actions like deploying resources. Without this role assignment, the pipeline fails with an access-denied error.

Exam trap

The trap here is that candidates often confuse service connection authentication (which always works if the connection is valid) with authorization (RBAC role assignments), leading them to pick options about disabled subscriptions or misspelled names instead of the missing role assignment.

How to eliminate wrong answers

Option A is wrong because a disabled Azure subscription would cause a different error (e.g., 'Subscription not found' or 'Authorization failed'), not a specific permission-denied message on a resource group. Option B is wrong because a misspelled service connection name in the YAML would result in a 'Service connection not found' error, not a permission error. Option C is wrong because variable groups in the library store variables, not service connection IDs; service connections are referenced by name in the pipeline, and the ID is not required for permission checks.

Full explanation →

Microsoft Azure DevOps Engineer Expert AZ-400 (AZ-400) — Questions 451–525