Courseiva

Microsoft Azure DevOps Engineer Expert AZ-400 (AZ-400) — Questions 376450

823 questions total · 11pages · All types, answers revealed

Page 5

Page 6 of 11

Page 7
376
MCQmedium

Your team uses GitHub Issues for work tracking. You want to automate the creation of a new issue when a build pipeline fails in Azure Pipelines. Which action should you implement in the YAML pipeline?

A.Add a GitHub Action that triggers on pipeline completion.
B.Use a PowerShell task to call the GitHub Issues API.
C.Configure a Service Hook in Azure DevOps to GitHub Issues.
D.Add a task to create a work item in Azure Boards.
AnswerB

The GitHub API allows creating issues from any HTTP client.

Why this answer

Azure Pipelines does not natively support creating GitHub Issues directly from a YAML pipeline. Instead, you must use a PowerShell task (or a script task) to call the GitHub Issues API (POST /repos/{owner}/{repo}/issues) with an authentication token to create the issue when the build fails. This approach gives you full control over the issue content and is the standard way to integrate with GitHub Issues from Azure Pipelines.

Exam trap

The trap here is that candidates confuse Service Hooks (external configuration) with pipeline tasks, thinking a Service Hook can be defined inside a YAML pipeline, when in fact Service Hooks are configured outside the pipeline in Azure DevOps project settings and cannot be triggered conditionally based on pipeline failure within the YAML definition.

How to eliminate wrong answers

Option A is wrong because a GitHub Action triggers on GitHub events (e.g., push, pull request), not on Azure Pipelines completion; Azure Pipelines and GitHub Actions are separate platforms, and a GitHub Action cannot directly respond to an Azure Pipelines build failure. Option C is wrong because Service Hooks in Azure DevOps can send notifications to GitHub (e.g., create an issue) but they are configured in the Azure DevOps project settings, not in the YAML pipeline; the question asks for an action implemented in the YAML pipeline, so a Service Hook is an external configuration, not a pipeline task. Option D is wrong because adding a task to create a work item in Azure Boards would create an Azure Boards work item, not a GitHub Issue; the question specifically requires creating a GitHub Issue, not an Azure Boards item.

377
Multi-Selecteasy

Your team follows trunk-based development. The main branch should always be deployable. Which two practices must you implement? (Choose two.)

Select 2 answers
A.Require manual approval for every pull request.
B.Use feature flags to manage incomplete work.
C.Keep branches short-lived (less than a day).
D.Create release branches for each deployment.
E.Use long-lived feature branches for each feature.
AnswersB, C

Feature flags (also called toggles) let teams merge incomplete or experimental code into main behind a runtime switch, decoupling deployment from feature release and enabling continuous integration. This keeps main always in a releasable state while incomplete work remains safely hidden from users until the flag is turned on.

Why this answer

In trunk-based development, the main branch must always be deployable. Feature flags (B) allow incomplete or work-in-progress code to be merged into the main branch without affecting production behavior, because the new functionality is toggled off until ready. Keeping branches short-lived (C) (typically less than a day) minimizes merge conflicts and ensures that changes are integrated quickly, reducing the risk of long-lived divergence that could break the main branch.

Exam trap

The trap here is that candidates often confuse trunk-based development with GitFlow or other branching strategies, leading them to select release branches (D) or long-lived feature branches (E) as valid practices, when in fact trunk-based development explicitly avoids these in favor of short-lived branches and feature flags.

378
Multi-Selecteasy

You are designing a process to manage work item tracking in Azure Boards. Your team uses a custom process based on the Agile template. You need to ensure that when a bug is resolved, the associated user story is automatically moved to the 'Done' state. Which TWO approaches can you use to achieve this?

Select 2 answers
A.Set up an 'Automate' level rule on the user story to move to 'Done' when all child bugs are resolved.
B.Modify the 'View' rule on the user story to automatically transition when child bugs are resolved.
C.Configure a rule on the work item type to automatically transition the user story when a linked bug is resolved.
D.Create a Power Automate flow triggered when a bug state changes to 'Resolved', then update the parent user story.
E.Use service hooks to call a custom webhook that updates the user story.
AnswersA, C

Automate levels in Azure DevOps Services (inherited processes) allow automatic state transitions based on child work item status.

Why this answer

Azure Boards supports 'Automate' level rules on work item types that can automatically transition a parent user story to 'Done' when all its child bugs are resolved. This rule is configured directly in the process settings under the user story work item type, leveraging the parent-child link hierarchy to enforce the state change.

Exam trap

The trap here is that candidates may confuse 'Automate' rules (which handle automatic state transitions based on linked work items) with 'View' rules (which only affect field visibility) or overcomplicate the solution by choosing external automation like Power Automate or service hooks when native process rules suffice.

379
Multi-Selectmedium

Which TWO conditions must be met to use multi-stage YAML pipelines with approvals?

Select 2 answers
A.The pipeline must be triggered by a pull request.
B.An environment must be created and approval checks configured on it.
C.The pipeline must have at least one stage defined in a separate release pipeline.
D.The deployment job must reference a specific environment.
E.The pipeline must be created using the classic release editor.
AnswersB, D

Approvals are set on environments.

Why this answer

Multi-stage YAML pipelines in Azure DevOps require that an environment be created and approval checks configured on it to enable manual approvals. Additionally, the deployment job within the pipeline must reference a specific environment, as the approval check is associated with that environment resource. Without these two conditions, the pipeline cannot enforce approval gates before deployment.

Exam trap

The trap here is that candidates often think approvals are configured directly on the pipeline or stage in YAML, but they must be set on the environment resource and the deployment job must explicitly reference that environment.

380
Multi-Selecthard

A team uses Azure Boards to manage work items. They want to automatically update the state of a work item when a related pull request is merged in Azure Repos. Which TWO actions should they configure to enable this integration?

Select 2 answers
A.Set up a webhook in Azure Repos to call Azure Logic Apps on pull request merge.
B.Add a branch policy that requires a linked work item for pull requests.
C.In the pull request description, use the #mention syntax to reference the work item.
D.Configure a Service Hooks subscription in Azure DevOps to send pull request merge events to Azure Boards.
E.Create an Azure Function that listens for pull request merge events and updates work items via the REST API.
AnswersB, C

This ensures every PR has a work item, and on merge, the work item state can be updated.

Why this answer

A branch policy that requires linked work items for pull requests ensures that every PR is associated with a work item. When the PR is merged, Azure Repos automatically updates the state of the linked work item (e.g., from 'Active' to 'Resolved') based on the default or configured transition rules. This integration is built into Azure DevOps without requiring external services.

Exam trap

The trap here is that candidates often confuse external automation (webhooks, Azure Functions, Logic Apps) with the native, built-in integration that Azure DevOps provides, leading them to select custom solutions instead of the simple branch policy configuration.

381
MCQeasy

A developer wants to automatically trigger a GitHub Actions workflow when a pull request is opened that targets the 'release' branch. Which trigger should they use?

A.pull_request_target: branches: [release]
B.push: branches: [release]
C.workflow_dispatch:
D.pull_request: branches: [release]
AnswerD

The pull_request trigger with branches: [release] is the standard and correct event for running a workflow whenever a pull request is opened, updated, or reopened against the release branch; it automatically validates the PR's merged result and meets the requirement precisely.

Why this answer

The `pull_request` trigger fires when a pull request is opened, and the `branches: [release]` filter restricts it to PRs targeting the `release` branch. `pull_request_target` also fires on PR open events but runs in the base repository context and is intended for workflows requiring secrets or write access, not as the general PR-open trigger. `push` only fires on pushes to branches, not on PR opens. Therefore, D is correct.

Exam trap

The trap is confusing `pull_request` with `push` or `pull_request_target`. `push` only fires when code is pushed, not when a PR is opened. `pull_request_target` does fire on PR activity, but it is designed for fork-safe workflows requiring secrets/write permissions; using it without that context is unnecessary and potentially unsafe. The question asks for a trigger when a PR is opened targeting a branch, so `pull_request` is the appropriate choice.

How to eliminate wrong answers

Option A is wrong because `pull_request_target` runs in the context of the base repository (not the merge commit) and is designed for secure workflows when PRs come from forks; it is not the standard trigger for a simple PR open event. Option B is wrong because `push` triggers on commits pushed to a branch, not when a pull request is opened. Option C is wrong because `workflow_dispatch` requires manual triggering via the GitHub UI or API and does not respond to pull request events.

382
MCQeasy

Your team is migrating from on-premises TFS to Azure DevOps Services. You need to ensure that all existing work item history and attachments are preserved. Which migration approach should you use?

A.Export to Excel and import using Azure DevOps Office Integration
B.Manually recreate work items in Azure DevOps
C.Use the Azure DevOps Migration Tools (open source)
D.Use the Azure DevOps REST API to migrate work items
AnswerC

The Azure DevOps Migration Tools are open-source utilities built specifically for TFS-to-Azure DevOps migrations, using the Client Object Model to incrementally copy work items while preserving full revision history, attachments, links, and custom field/process template mappings. They support repeated, configurable v2 migrations with migration state tracking, making them the only listed option that can meet historical fidelity and traceability requirements.

Why this answer

The Azure DevOps Migration Tools (an open-source project) are specifically designed to migrate work items, including history, attachments, and links, from on-premises TFS to Azure DevOps Services. These tools handle the complex data transformations required to preserve the full fidelity of work item data, which is not possible with simpler export/import methods.

Exam trap

The trap here is that candidates may assume the REST API is sufficient for full migration, but it lacks built-in support for preserving history and attachments, requiring custom development that is more error-prone than using the purpose-built open-source tools.

How to eliminate wrong answers

Option A is wrong because Excel export/import via Office Integration does not preserve work item history, attachments, or links; it only transfers flat field data and is intended for bulk editing, not migration. Option B is wrong because manually recreating work items is error-prone, time-consuming, and cannot replicate the original history, timestamps, or attachments, leading to data loss and audit gaps. Option D is wrong because while the Azure DevOps REST API can create work items, it does not natively support migrating history or attachments in a single operation; you would need to write custom scripts to handle each element, which is far more complex and less reliable than using the dedicated migration tools.

383
Multi-Selectmedium

Which TWO actions should be taken to secure secrets in Azure Pipelines? (Choose two.)

Select 2 answers
A.Use secret variables with the 'secret' input type to mask them in logs.
B.Use a variable group without Key Vault integration for easier management.
C.Store secrets directly in the YAML pipeline file.
D.Store secrets in a variable group linked to Azure Key Vault.
E.Disable CI triggers to reduce exposure.
AnswersA, D

In Azure Pipelines, defining variables with the `secret` input type (e.g., via the pipeline UI or YAML `${{ variables.secret }}`) ensures they are encrypted at rest and automatically masked in all pipeline logs, preventing accidental exposure. This is a fundamental practice for handling sensitive data in CI/CD, as it protects against log leakage while still allowing tasks to reference the variable securely.

Why this answer

Azure Pipelines allows you to mark variables as secret by using the 'secret' input type in the pipeline settings UI or by setting `secret: true` in YAML. This ensures the variable's value is masked with asterisks in all logs and output, preventing accidental exposure during build or release execution. Additionally, storing secrets in a variable group linked to Azure Key Vault provides a secure, centralized way to manage secrets, with access control, versioning, and auditability, making it a best practice for protecting sensitive data.

Exam trap

The trap here is that candidates may think disabling CI triggers (Option E) reduces secret exposure, but it only affects build automation, not the security of the secrets themselves, which is a common misconception about pipeline security controls.

384
MCQhard

Refer to the exhibit. You have a YAML pipeline with the variables shown. What will be the value of $(Build.BuildNumber) on the first run?

A.1.0.0.0
B.20250101.1
C.1.0.0
D.1.0.1
AnswerB

20250101.1 is correct because Azure Pipelines automatically sets Build.BuildNumber to $(Date:yyyyMMdd).$(Rev:r) when no custom format is specified. On January 1, 2025, the first build of the day gets the revision 1, producing 20250101.1, and each subsequent build increments the revision.

Why this answer

The pipeline does not define a custom build number format, so Azure DevOps defaults to the date-based format 'yyyyMMdd.revision'. On the first run of the day, the revision starts at 1, resulting in a Build.BuildNumber like '20250101.1'. The counter expression (not shown in the exhibit) is a separate variable and does not affect Build.BuildNumber.

Therefore, the correct answer is B.

385
MCQhard

Your team uses GitHub Issues for tracking bugs and features. They want to automatically assign issues to the person who created the pull request that closes the issue. Which GitHub Actions workflow trigger and action should you use?

A.Use the 'pull_request' event and the 'actions/assign' action to assign the issue.
B.Use the 'issues' event with 'closed' type and an action that assigns the issue to the PR author.
C.Use the 'push' event and call the GitHub API to assign the issue.
D.Use the 'schedule' event to periodically check for closed issues and assign them.
AnswerB

The 'issues' event with type 'closed' is the appropriate trigger because GitHub Actions fires it synchronously when an issue is closed, providing the issue payload directly. A workflow can then invoke the GitHub API (or a purpose-built action) to inspect the issue timeline, locate the 'cross-referenced' event pointing to the pull request that closed it, and fetch that PR's author for assignment. This reacts in real time without polling and does not require external state tracking.

Why this answer

The 'issues' event with 'closed' type triggers a workflow when an issue is closed, and the 'actions/github-script' action can be used to assign the issue to the pull request author by querying the pull request that closed the issue. Option A is incorrect because the 'pull_request' event does not directly close issues; closing an issue is done via a commit or pull request merge. Option C is incorrect because the 'push' event is not related to issue closure.

Option D is incorrect because the 'schedule' event is time-based and does not respond to issue closures.

386
MCQhard

Refer to the exhibit. A build pipeline uses this trigger configuration. A developer pushes a commit to the 'main' branch that modifies files in '/src/app/' and '/src/tests/'. How many builds will be triggered?

A.1 build, because batchChanges is true.
B.0 builds, because the excluded path takes precedence.
C.3 builds, because maxConcurrentBuildsPerBranch is 1 but batchChanges overrides.
D.2 builds, one for each modified folder.
AnswerA

With batchChanges set to true, all commits and file changes from a single push are coalesced into one build invocation; you don't get a separate build per modified file or folder. Because at least one changed path matches an include pattern, the pipeline queues exactly one batched build for that change set.

Why this answer

The trigger configuration has `batchChanges` set to `true`. When `batchChanges` is enabled, Azure Pipelines groups all commits that arrive while a build is in progress into a single build, rather than triggering a separate build for each commit. In this scenario, the developer pushes a single commit that modifies files in both `/src/app/` and `/src/tests/`.

Since `batchChanges` is true, only one build is triggered for that commit, regardless of the number of modified folders.

Exam trap

The trap here is that candidates often confuse `batchChanges` with `maxConcurrentBuildsPerBranch`, thinking that batching affects concurrency limits, or mistakenly believe that modifying multiple folders in a single commit triggers multiple builds.

How to eliminate wrong answers

Option B is wrong because the excluded path (`/src/tests/`) does not take precedence over the included paths; the trigger includes `/src/app/**` and `/src/tests/**`, so the commit modifies files in both included paths, and the exclusion is not configured. Option C is wrong because `maxConcurrentBuildsPerBranch` controls how many builds can run concurrently for the same branch, not the number of builds triggered; `batchChanges` does not override it but works alongside it to batch commits. Option D is wrong because the number of builds is not determined by the number of modified folders; with `batchChanges` set to true, a single commit that modifies multiple folders still triggers only one build.

387
MCQmedium

You have a pipeline that uses Azure Repos Git. You need to enforce that all commits to the main branch are associated with a work item. Which branch policy should you enable?

A.Require linked work items
B.Limit merge types
C.Require a minimum number of reviewers
D.Check for comment resolution
AnswerA

This branch policy enforces that every pull request must have at least one linked work item before it can be completed. By blocking completion without a work item link, it provides full traceability from code changes back to the original requirement or task, which is critical for audit and compliance.

Why this answer

Require linked work items. This branch policy enforces that pull requests or commits to the main branch have at least one associated work item, ensuring traceability. Option B, Limit merge types, restricts which merge strategies can be used (e.g., squash, rebase), but does not enforce work item linking.

Option C, Require a minimum number of reviewers, ensures code review but not work item association. Option D, Check for comment resolution, requires that all comments on pull requests are resolved before merging, which is unrelated to work items.

388
MCQhard

Refer to the exhibit. You deploy this ARM template using Azure Pipelines. The deployment succeeds, but the storage account is created with a name that is not what you expected. What is the most likely reason?

A.The uniqueString function returns a hash based on the resource group ID, resulting in a non-meaningful name.
B.The storage account name parameter is of type 'string' but the default value is an object.
C.The location parameter uses resourceGroup().location which is not a valid function.
D.The apiVersion '2022-09-01' is too new and causes a naming conflict.
AnswerA

The uniqueString function in ARM templates computes a deterministic hash from the supplied inputs, such as the resource group ID, which makes the resulting name technically unique but not human-readable or descriptive. For storage accounts, which require globally unique names, this often leads to seemingly random strings that fail to convey the resource's purpose unless combined with a meaningful prefix.

Why this answer

The uniqueString(resourceGroup().id) function generates a deterministic hash based on the resource group ID, resulting in a storage account name that is a hash rather than a human-readable name. Option B is incorrect because the parameter type 'string' can accept a default value that is a string, even if it looks like an object. Option C is incorrect because resourceGroup().location is a valid function that returns the location of the resource group.

Option D is incorrect because the apiVersion '2022-09-01' is valid and does not cause naming conflicts; naming conflicts arise from the hash function, not the API version.

389
MCQhard

Your Azure Pipelines build is failing with the error: '##[error]No agent found in pool 'Default' that satisfies the specified demands: Agent.Version -gtVersion 2.200.0'. The pool 'Default' contains agents of various versions. What is the most likely cause?

A.The pipeline YAML has a syntax error in the 'demands' section.
B.The pipeline is configured to run on an agentless job.
C.The 'demands' keyword is not supported in Azure Pipelines.
D.The 'Default' agent pool has no agents with version greater than 2.200.0.
AnswerD

The pipeline includes a demand such as 'Agent.Version -gtVersion 2.200.0', but every agent in the Default pool runs an agent version less than or equal to 2.200.0. As a result, no agent satisfies the demand, causing the build to fail with an error that no matching agent could be found.

Why this answer

The error message explicitly states that no agent in the 'Default' pool satisfies the demand 'Agent.Version -gtVersion 2.200.0'. Since the pool contains agents of various versions, the most likely cause is that none of those agents have a version greater than 2.200.0. This demand is set in the pipeline YAML or classic editor to ensure the agent meets a minimum version requirement.

Exam trap

The trap here is that candidates may assume the error is due to a syntax or configuration issue, when in fact it is a straightforward version mismatch — the pool simply lacks agents meeting the version demand.

How to eliminate wrong answers

Option A is wrong because a syntax error in the 'demands' section would produce a YAML parsing error, not a specific 'No agent found' message with the exact demand string. Option B is wrong because an agentless job does not use an agent pool at all, so it would not trigger an agent demand error. Option C is wrong because the 'demands' keyword is fully supported in Azure Pipelines to specify required agent capabilities or versions.

390
MCQhard

Your company has multiple teams working on a monorepo in Azure Repos. You need to enforce that changes to the /src/api folder require approval from the API team, while changes to /src/web require approval from the Web team. Which branch policy feature should you use?

A.Require a minimum number of reviewers
B.Automatically include code reviewers
C.Path filters in branch policy
D.Use separate repositories for each team
AnswerC

Path filters allow scoping policy to specific file paths.

Why this answer

Path filters in branch policy allow you to define conditions that trigger specific policy requirements based on the files changed in a pull request. By configuring a path filter for /src/api, you can require approval from the API team only when files in that folder are modified, and a separate path filter for /src/web can require approval from the Web team. This ensures that each team's approval is enforced only for their respective code areas within the monorepo.

Exam trap

The trap here is that candidates often confuse 'automatically include code reviewers' (which just adds reviewers to all PRs) with the ability to conditionally enforce approval based on file paths, leading them to choose option B instead of the correct path filter feature.

How to eliminate wrong answers

Option A is wrong because 'Require a minimum number of reviewers' enforces a blanket number of approvals for all pull requests, without any ability to differentiate based on which files are changed. Option B is wrong because 'Automatically include code reviewers' adds specific reviewers to all pull requests but does not conditionally enforce their approval based on file paths. Option D is wrong because using separate repositories for each team would break the monorepo structure, which is explicitly stated as a requirement, and would introduce additional overhead for cross-team dependencies and integration.

391
MCQhard

Your team is adopting a shift-left security approach in Azure Pipelines. They want to automatically detect secrets, such as API keys or connection strings, in source code before code is committed. Which Azure DevOps feature should be configured to scan pull requests for secrets and block the PR if any are found?

A.Azure Policy for Repos
B.Credential Scanner task in pipeline
C.Dependency Scanning
D.Secret Scanning
AnswerD

Secret Scanning is a GitHub Advanced Security feature, not a built-in Azure DevOps feature; the correct equivalent in Azure DevOps is the Credential Scanner task.

Why this answer

Azure DevOps Secret Scanning is the built-in feature that automatically detects secrets in Azure Repos and can block pull requests when secrets are found. While a Credential Scanner task can also be added to a pipeline, Secret Scanning is the native feature designed for this purpose and is the correct answer. Options A and C are unrelated, and B is a pipeline task, not the primary Azure DevOps feature.

392
Multi-Selectmedium

Which TWO approaches can you use to enforce consistent commit message conventions across your GitHub repositories?

Select 2 answers
A.Add a .gitattributes file
B.Use a GitHub Action to validate commit messages on push
C.Set the default branch to main
D.Create a repository rule that requires commit message patterns
E.Set up an issue template
AnswersB, D

A custom action can check commit messages and reject non-conforming pushes.

Why this answer

GitHub Actions can be configured with a workflow that triggers on `push` events to validate commit messages against a regex pattern, rejecting non-conforming commits. Option D is correct because repository rulesets (or branch protection rules) allow you to define required commit message patterns that must match before a push is accepted, enforced server-side. Both approaches enforce conventions consistently across all contributors.

Exam trap

The trap here is that candidates often confuse `.gitattributes` or branch naming with commit message enforcement, failing to recognize that only server-side rules or CI/CD actions can validate commit message content.

393
Multi-Selecthard

Which TWO actions are required to securely use Azure Key Vault secrets in an Azure Pipelines build? (Choose 2)

Select 2 answers
A.Set the 'secrets' output variable to 'true' in the pipeline.
B.Use the 'Azure Key Vault' task to download secrets as pipeline variables.
C.Use the 'Environment Variables' section in the pipeline to map secrets.
D.Reference the secret identifier directly in the pipeline YAML.
E.Grant the Azure DevOps service principal 'Get' and 'List' permissions on the Key Vault.
AnswersB, E

The Azure Key Vault task authenticates to the Key Vault using the Azure DevOps service principal, retrieves the specified secrets, and injects them as pipeline variables, automatically marking them as secret and masked in logs. This is the recommended, supported method for consuming Key Vault secrets in a pipeline.

Why this answer

The Azure Key Vault task in Azure Pipelines is the recommended way to securely download secrets from a Key Vault and expose them as pipeline variables. This task automatically handles authentication and ensures that secret values are masked in logs, preventing accidental exposure. It eliminates the need to manually manage secret retrieval and mapping in YAML.

For the task to succeed, the Azure DevOps service principal (from the Azure Resource Manager service connection) must have 'Get' and 'List' permissions on the Key Vault. Without these permissions, the task cannot retrieve the secrets. Therefore, both using the Azure Key Vault task and granting the appropriate permissions are required actions.

Exam trap

The trap here is that candidates often think they can directly reference the secret identifier in YAML (Option D) or use environment variables (Option C) to securely retrieve secrets, but these approaches bypass the secure authentication and masking provided by the dedicated Azure Key Vault task.

394
MCQmedium

Your team uses Azure DevOps to manage a monolithic .NET Framework application that is deployed to on-premises Windows servers. You plan to modernize the application by containerizing it and moving it to Azure Kubernetes Service (AKS). The existing build pipeline uses the .NET Framework build task and MSBuild. The release pipeline uses WinRM-based deployment to copy files to on-premises servers. You need to design a new CI/CD pipeline that builds a Docker image, pushes it to Azure Container Registry (ACR), and deploys it to AKS. Your solution should minimize changes to the existing codebase and leverage Azure Pipelines. What should you do?

A.Keep the existing build pipeline as is, and add a script to build the Docker image in the release pipeline before deploying.
B.Modify the existing build pipeline by adding a 'Docker' task to build and push the image, and modify the release pipeline to use a 'Kubernetes' task for deployment.
C.Create a new build pipeline from scratch using the 'Docker' template and a new release pipeline with the 'Deploy to Kubernetes' template.
D.Use self-hosted agents to build the Docker image and deploy to AKS.
AnswerB

This is the correct approach because it extends the existing CI/CD flow with minimal disruption: add a Docker task to the build pipeline to compile, build, and push the container image to a registry, then replace the release pipeline's deployment step with a Kubernetes task that applies manifests to AKS. This keeps the build artifact (the image) produced during CI and consumes it in CD, which is the recommended practice.

Why this answer

Adding a Docker task to build and push the image to ACR, and a Kubernetes task to deploy to AKS, minimally changes the existing pipelines. Option A is incorrect because building the Docker image via a script in the release pipeline is less integrated and does not leverage the build pipeline's Docker capabilities. Option C is incorrect because creating new pipelines from scratch is unnecessary and introduces more changes.

Option D is incorrect because self-hosted agents are not required to build and push to ACR or deploy to AKS.

395
MCQeasy

You are designing a build pipeline for a Java application that uses Maven. You want to publish the compiled JAR file as a build artifact. Which task should you use?

A.PublishBuildArtifacts@1
B.Maven@3
C.ArchiveFiles@2
D.CopyFiles@2
AnswerA

PublishBuildArtifacts@1 uploads a specified directory or file to the Azure Pipelines artifact store, assigning it a name so it can be downloaded from the build summary or consumed by subsequent jobs, stages, and release pipelines. This task is the definitive way to make build outputs available as build artifacts.

Why this answer

The Publish Build Artifacts task publishes files as pipeline artifacts. Option B (Maven@3) is wrong because it builds the project but does not publish artifacts. Option C (ArchiveFiles@2) is wrong because it creates a zip but does not publish.

Option D (CopyFiles@2) is wrong because it only copies files within the agent.

396
MCQeasy

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

A.Pull request trigger
B.Continuous integration (CI) trigger
C.Scheduled trigger
D.Build completion trigger
AnswerD

A build completion trigger starts the release pipeline after a build completes, using the same artifact.

Why this answer

A build completion trigger ensures that the release pipeline is initiated only after a specific build pipeline completes, allowing the same build artifact to be deployed across multiple environments without rebuilding. This trigger is ideal for multi-environment release pipelines where consistency of the artifact is critical, as it decouples the build from the release and promotes the identical binary through dev, test, and prod.

Exam trap

The trap is that candidates may confuse the build pipeline's CI trigger (which does rebuild code on every commit) with a release pipeline's continuous deployment trigger (which does not rebuild; it deploys the artifact produced by the specified build). For ensuring the same artifact across multiple environments, the build completion trigger is the correct choice because it is directly tied to a specific build pipeline completion.

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 initiate a release pipeline that deploys the same artifact across environments. Option B is wrong because a continuous integration (CI) trigger automatically starts a build when code is committed, which would rebuild the artifact for each environment rather than reusing the same artifact. Option C is wrong because a scheduled trigger runs the release pipeline at predefined times, which does not guarantee that the same build artifact is used across environments and may deploy outdated or inconsistent artifacts.

397
MCQhard

Your organization uses GitHub Advanced Security. You need to ensure that secrets detected in pull requests automatically block the PR from merging. What should you configure?

A.Configure a custom secret scanning pattern and set the 'Block pull requests' property.
B.Configure a code scanning query to detect secrets.
C.Enable secret scanning and set the severity to critical.
D.Enable push protection for secret scanning.
AnswerA

The correct approach is to configure a custom secret scanning pattern with the 'Block pull requests' property enabled. When a pull request contains a secret matching the custom pattern, the PR check fails and the merge is blocked, directly satisfying the requirement to block PRs when secrets are detected.

Why this answer

GitHub Advanced Security allows you to create custom secret scanning patterns with a 'Block pull requests' property. When enabled, this property prevents a pull request from being merged if the custom pattern detects a secret in the PR's changes, directly meeting the requirement to automatically block merging on secret detection.

Exam trap

The trap here is confusing push protection (which blocks pushes) with the 'Block pull requests' property (which blocks PR merges), leading candidates to incorrectly select push protection as the solution for merge blocking.

How to eliminate wrong answers

Option B is wrong because code scanning queries detect code vulnerabilities and errors, not secrets; secret scanning is a separate GitHub Advanced Security feature that specifically identifies secrets like tokens and keys. Option C is wrong because enabling secret scanning with a severity setting only controls alert visibility or filtering, not merge blocking; there is no 'severity' property that blocks pull requests. Option D is wrong because push protection for secret scanning prevents secrets from being pushed to the repository in the first place, but it does not block a pull request from merging after the push has already occurred; the requirement is to block merging of PRs, not to block pushes.

398
MCQhard

Refer to the exhibit. A developer creates a pull request from a branch called 'feature/update'. The workflow runs on the pull_request event. What will the output of this workflow be?

A.The workflow will not run because the branch is not 'main'.
B.The workflow will run and output 'Running PR tests'.
C.The workflow will run but output nothing because the condition fails.
D.The workflow will fail due to a syntax error in the conditional expression.
AnswerB

The workflow is configured with the `pull_request` event, so it runs when a PR is opened or updated. The `if` condition `github.event_name == 'pull_request'` is true for this event, so the echo step executes and outputs 'Running PR tests'.

Why this answer

The workflow is triggered on the `pull_request` event, which fires for any pull request regardless of the source branch name. The condition `github.event_name == 'pull_request'` evaluates to `true` because the event is indeed a pull_request. Therefore, the `if` condition passes, and the step runs, outputting 'Running PR tests'.

Exam trap

The trap here is that candidates may assume a workflow only runs on the default branch or that branch names like 'feature/update' are excluded, but GitHub Actions `pull_request` events fire for any source branch unless explicitly filtered with `branches` or `paths`.

How to eliminate wrong answers

Option A is wrong because the workflow is configured to run on the `pull_request` event, not only on pushes to `main`; the branch name does not prevent the workflow from executing. Option C is wrong because the condition `github.event_name == 'pull_request'` is satisfied, so the step does execute and produces output. Option D is wrong because the conditional expression `github.event_name == 'pull_request'` is syntactically valid YAML and GitHub Actions expression syntax.

399
MCQeasy

A team uses Azure Boards and wants to ensure that work items moved to the 'Done' state require a completed code review. What should they configure?

A.Add a work item rule in the process template to require a code review for the 'Done' transition.
B.Modify the work item type definition to add a custom field for code review status.
C.Use a tag to mark work items as code-reviewed before moving to 'Done'.
D.Configure branch policies in Azure Repos to require pull request approvals.
AnswerA

A process template rule is the correct mechanism in Azure Boards because rules can enforce conditions on state transitions, such as requiring a custom 'Code Review' field to be completed before a work item is allowed to move to 'Done'.

Why this answer

Azure Boards allows you to define work item rules within the process template that enforce specific conditions on state transitions. By adding a rule to the 'Done' transition that requires a completed code review (e.g., via a custom field or check), you ensure work items cannot be moved to 'Done' without meeting that prerequisite. This is done through the inherited process customization in Azure DevOps, where you can add rules to the work item type's state transition.

Exam trap

The trap here is confusing Azure Repos branch policies (which enforce code review on pull requests) with Azure Boards work item rules (which enforce conditions on work item state transitions), leading candidates to select Option D instead of A.

How to eliminate wrong answers

Option B is wrong because simply adding a custom field for code review status does not enforce a requirement; it only stores data, and without a rule on the transition, the field can be left empty. Option C is wrong because tags are informal metadata and cannot enforce a mandatory check; they are not evaluated by work item state transitions. Option D is wrong because branch policies in Azure Repos control pull request approvals for code branches, not work item state transitions in Azure Boards; they operate at the repository level, not the work item tracking level.

400
MCQhard

You have a multi-stage YAML pipeline with stages: Build, Test, and Deploy. The Deploy stage requires approval from a specific user group. You want to ensure that the approval request is sent only after the Test stage completes successfully. Which configuration should you use?

A.Add a manual validation task in the Deploy stage.
B.Define an environment with required approvers and reference it in the Deploy stage.
C.Use the 'condition' keyword: condition: eq(variables['Build.SourceBranch'], 'refs/heads/main')
D.Configure branch policies on the main branch.
AnswerB

Defining an environment with required approvers and referencing that environment in the Deploy stage adds a pre-deployment approval gate that must be completed before the stage runs, giving you a first-class, audit-ready mechanism for human sign-off on production deployments.

Why this answer

Azure Pipelines environments allow you to define required approvers (user groups) that must approve a deployment before it proceeds. By referencing the environment in the Deploy stage, the approval request is automatically triggered only after the preceding Test stage completes successfully, since stages execute sequentially by default.

Exam trap

The trap here is that candidates confuse manual validation tasks (Option A) with environment-based approvals, not realizing that environment approvals are the native, recommended way to enforce stage-level approval gates in YAML pipelines.

Why the other options are wrong

A

Manual validation tasks require a custom script and do not integrate with Azure AD groups for approvals.

C

This condition controls stage execution based on branch, not approvals.

D

Branch policies are for pull requests, not pipeline stages.

401
MCQeasy

You are configuring a YAML build pipeline for a .NET Core application. Which task should you use to restore NuGet packages?

A.NuGetCommand task
B.DotNetCoreCLI task with 'restore' command
C.PowerShell task with dotnet restore
D.NuGetAuthenticate task
AnswerB

The DotNetCoreCLI task with the 'restore' command is the correct and officially recommended way to restore NuGet packages for .NET Core and .NET Standard projects. It invokes `dotnet restore`, automatically discovers project files, honors NuGet.config and authenticated feeds, and provides rich pipeline logging and error handling without requiring manual command invocation.

Why this answer

The DotNetCoreCLI task with the 'restore' command is the recommended approach for restoring NuGet packages in a YAML build pipeline for a .NET Core application. It directly invokes 'dotnet restore', which is the native .NET CLI command that handles package restoration efficiently and integrates seamlessly with the .NET SDK, ensuring compatibility with project files and dependency resolution.

Exam trap

The trap here is that candidates often choose the NuGetCommand task (A) because they associate 'NuGet' with package restoration, not realizing that .NET Core projects require the DotNetCoreCLI task for proper SDK integration and that the legacy task is deprecated for modern .NET workflows.

Why the other options are wrong

A

NuGetCommand is for classic NuGet scenarios; for .NET Core, DotNetCoreCLI is preferred.

C

While possible, using the dedicated DotNetCoreCLI task is the standard approach.

D

NuGetAuthenticate is for authentication, not restoring packages.

402
MCQeasy

Your team uses Azure Boards to track work items. They want to automatically update the state of a work item when a pull request is merged in Azure Repos. What should you configure?

A.Configure a work item template.
B.Define a branch policy to link work items and set automatic state transition.
C.Create a service hook subscription.
D.Set pipeline variables in the YAML file.
AnswerB

A branch policy in Azure Repos can require pull requests to be linked to work items and include an option to automatically transition the linked work item's state when the PR is merged. This is the built-in mechanism that updates Azure Boards work items without custom code, as the policy triggers the state change (e.g., from Active to Done) on successful completion of the merge. It directly satisfies the requirement, making it the correct choice.

Why this answer

Azure Repos branch policies allow you to require linked work items for pull requests and automatically transition the state of a linked work item (e.g., from 'Active' to 'Resolved') upon merge. This is configured in the branch policy settings under 'Automatically update work items' with a state transition rule, directly integrating Azure Boards with pull request completion.

Exam trap

The trap here is that candidates often confuse service hooks (which only send notifications) with the branch policy's built-in work item state transition feature, leading them to select option C instead of B.

How to eliminate wrong answers

Option A is wrong because work item templates only define default field values when creating a work item; they do not trigger automatic state changes on pull request merge. Option C is wrong because service hook subscriptions can send notifications (e.g., to Slack or Teams) when a pull request is merged, but they cannot directly update the state of a work item in Azure Boards. Option D is wrong because pipeline variables in YAML files control build/release pipeline behavior, not work item state transitions triggered by pull request merges.

403
Multi-Selecteasy

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

Select 2 answers
A.Disable the NuGet restore step in the pipeline.
B.Install the NuGet tool on the self-hosted agent machine.
C.Use a Microsoft-hosted agent instead.
D.Configure the self-hosted agent to access Azure Artifacts or an internal NuGet feed.
E.Use the NuGet Authenticate task to authenticate with Azure Artifacts.
AnswersB, D

The NuGet tool (NuGet.exe) or the dotnet CLI is the client executable that actually executes restore, pack, and push commands in classic build tasks like the NuGetCommand task. On a self-hosted agent, this tool is not guaranteed to be installed, so explicitly installing it ensures the agent can perform the required NuGet operations for the pipeline. For .NET Core projects, the dotnet CLI can handle restore via the SDK, but if the pipeline uses the legacy NuGet tasks, NuGet.exe must be present and accessible on the agent's PATH. Installing the NuGet tool directly addresses the missing executable that the build pipeline relies on to interact with package feeds.

Why this answer

To restore NuGet packages on a self-hosted agent without internet access, the NuGet tool must be installed on the agent machine (B) and the agent must be configured to access an internal NuGet feed, such as Azure Artifacts or a local feed (D). Disabling the NuGet restore step (A) would prevent packages from being downloaded. Using a Microsoft-hosted agent (C) would require internet access, which violates the private network constraint.

The NuGet Authenticate task (E) is not required because authentication can be handled through feed configuration or integrated authentication.

404
MCQmedium

Your organization uses GitHub Actions for CI/CD. You need to ensure that secrets used in workflows are not exposed in logs. What should you do?

A.Encrypt the secret with a password before using it.
B.Use the 'echo' command to output the secret and then delete the log.
C.Store the secret in GitHub Secrets and reference it as ${{ secrets.SECRET_NAME }}.
D.Disable logging on the self-hosted runner.
AnswerC

Storing the secret in GitHub Secrets and referencing it as ${{ secrets.SECRET_NAME }} is the correct approach because GitHub Actions automatically masks the secret's value in all logs, and the secret is only injected into the workflow at runtime without being visible in the workflow definition.

Why this answer

GitHub Secrets are encrypted environment variables that are automatically masked in workflow logs. When you reference a secret using the `${{ secrets.SECRET_NAME }}` syntax, GitHub Actions ensures the value is never printed in plain text, even if the workflow attempts to echo it. This is the built-in, secure method for handling sensitive data in CI/CD pipelines.

Exam trap

The trap here is that candidates may think disabling logging or manually encrypting secrets is sufficient, but GitHub Actions already provides automatic log masking via GitHub Secrets, making those workarounds unnecessary and insecure.

How to eliminate wrong answers

Option A is wrong because encrypting a secret with a password before using it does not prevent the encrypted value or the password from being exposed in logs; the encryption key would also need to be stored securely, and the decrypted value could still leak. Option B is wrong because using the 'echo' command to output a secret and then deleting the log is unreliable — the secret is already written to the log before deletion, and log retention policies or caching may preserve it. Option D is wrong because disabling logging on a self-hosted runner does not prevent secrets from being exposed in other log outputs (e.g., runner diagnostics, system logs) and violates the principle of least privilege; GitHub Secrets masking works regardless of runner type.

405
MCQmedium

Your team is adopting Infrastructure as Code (IaC) using Bicep. You need to validate the Bicep file syntax and run pre-deployment checks as part of the build pipeline. Which task should you use?

A.Azure Resource Group Deployment task
B.Terraform task
C.PowerShell task with Invoke-RestMethod
D.Azure CLI task with 'az bicep build'
AnswerD

The Azure CLI task with 'az bicep build' is the correct choice because this command compiles a Bicep file into an ARM template and reports any syntax errors during the build process. It serves as the official, built-in mechanism for validating Bicep syntax in a pipeline.

Why this answer

The `az bicep build` command compiles a Bicep file into an ARM template and performs syntax validation, making it the correct choice for validating Bicep syntax and running pre-deployment checks in a build pipeline. This task ensures that the Bicep code is syntactically correct before any deployment attempt, aligning with Infrastructure as Code (IaC) best practices.

Exam trap

The trap here is that candidates often confuse build-time syntax validation with deployment-time validation, leading them to choose the Azure Resource Group Deployment task (Option A) because it can deploy Bicep files, but it does not perform isolated syntax checks in the build phase.

How to eliminate wrong answers

Option A is wrong because the Azure Resource Group Deployment task is used to deploy ARM templates (or Bicep files via compilation) to a resource group, not to validate syntax or run pre-deployment checks independently; it executes deployment logic, not build-time validation. Option B is wrong because the Terraform task is designed for Terraform configurations, not Bicep files, and would require converting Bicep to Terraform or using a separate tool, which is unnecessary and incorrect for this scenario. Option C is wrong because a PowerShell task with Invoke-RestMethod would require manually calling the Azure REST API or a custom validation endpoint, which is overly complex and not the standard or efficient method for Bicep syntax validation; it lacks built-in Bicep support.

406
MCQhard

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

A.Implement context propagation by passing trace headers between services.
B.Enable the Application Insights auto-instrumentation agent on the application host.
C.Configure the OpenTelemetry SDK to use the Azure Monitor exporter instead of the default exporter.
D.Set the same service name for all services in the OpenTelemetry configuration.
AnswerA

Context propagation is required to correlate spans across services.

Why this answer

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

Exam trap

The trap here is that candidates often confuse telemetry export (sending data to a backend) with context propagation (passing trace IDs between services), assuming that using the correct exporter or agent automatically correlates spans.

How to eliminate wrong answers

Option B is wrong because the Application Insights auto-instrumentation agent (e.g., for .NET or Java) is a separate solution that does not use OpenTelemetry; it would replace the existing instrumentation rather than fix the missing context propagation. Option C is wrong because changing the exporter (e.g., to Azure Monitor exporter) only affects where telemetry is sent, not how trace context is propagated between services; the correlation issue is in the propagation layer, not the export layer. Option D is wrong because setting the same service name for all services would incorrectly merge telemetry into a single service identity, breaking the ability to distinguish service boundaries and still not propagating trace context.

407
MCQhard

Your team uses GitHub Actions and needs to enforce that all workflows must use approved actions from a curated list. What is the best way to implement this?

A.Configure branch protection rules
B.Set up an allowed list of actions in organization settings
C.Enable Dependabot alerts
D.Use OpenID Connect (OIDC)
AnswerB

In GitHub organization settings, under Actions > General, you can choose 'Allow only selected actions' and specify an allowlist of actions and reusable workflows. This restricts all workflows in the organization to only use approved actions, directly enforcing the required policy.

Why this answer

GitHub Organizations allow administrators to define an 'allowed list' of actions under Settings > Actions > Policies, restricting workflow execution to only approved actions from the curated list. This directly enforces the requirement that all workflows use only approved actions, preventing the use of unverified or malicious third-party actions.

Exam trap

The trap here is confusing branch protection rules (which control code changes) with action governance policies (which control which actions can run), leading candidates to incorrectly select branch protection as the enforcement mechanism.

How to eliminate wrong answers

Option A is wrong because branch protection rules control who can push to branches and require pull request reviews, but they do not restrict which actions can be used in workflows. Option C is wrong because Dependabot alerts notify about vulnerable dependencies in your repository, but they do not enforce a curated list of approved actions. Option D is wrong because OpenID Connect (OIDC) is used for federated authentication to access cloud resources without storing secrets, not for restricting which actions can be executed in workflows.

408
Drag & Dropmedium

Drag and drop the steps to configure a service hook for build completion notifications to Microsoft Teams 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

To configure a service hook for build completion notifications to Microsoft Teams, you must first access the Service Hooks page in Project Settings. Then, you create a new subscription and select the Build completed event and Microsoft Teams as the service. Finally, you provide the webhook URL and test the subscription to ensure it works.

409
MCQeasy

Your development team uses GitHub Enterprise and wants to automatically synchronize code from a public GitHub repository to their private repository every morning. What feature should they use?

A.Webhooks from the public repository to trigger a sync pipeline.
B.A scheduled GitHub Actions workflow that fetches from the public repo and pushes to the private repo.
C.Git submodules to link the public repository as a subdirectory.
D.GitHub repository mirroring to automatically mirror the public repo.
AnswerB

A scheduled GitHub Actions workflow uses the `on: schedule` event with cron syntax to run at specified intervals. The workflow can fetch the latest commits from the public repository and then push them to the private repository, providing a fully automated and time-controlled sync mechanism.

Why this answer

B is correct because a scheduled GitHub Actions workflow can periodically fetch changes from the public repository (using `git fetch` or `git pull`) and push them to the private repository. This approach avoids the need for external triggers and works even when the public repo does not send webhooks to your private environment. The schedule is defined using cron syntax in the workflow YAML, ensuring automatic daily synchronization.

Exam trap

The trap here is that candidates often assume webhooks (Option A) are the only way to trigger automation, forgetting that webhooks require external network access and cannot be sent from a public repo to a private GitHub Enterprise instance without a proxy or custom relay.

How to eliminate wrong answers

Option A is wrong because webhooks from a public repository cannot be configured to target a private GitHub Enterprise instance—webhooks require a publicly accessible endpoint, and the private repo's Actions runner would not receive the event directly. Option C is wrong because git submodules only link a specific commit from the public repo as a subdirectory; they do not automatically synchronize changes on a schedule and require manual updates. Option D is wrong because GitHub repository mirroring is a one-time or manual setup that mirrors an entire repository, but it does not support scheduled synchronization and is typically used for migrating repos, not for ongoing daily syncs from a public source.

410
MCQhard

Your organization uses GitHub Flow for source control with a monorepo containing multiple microservices. Each microservice has its own build and test workflow. You need to design a CI/CD strategy that builds and tests only the services affected by a pull request to reduce build times and resource usage. You also need to ensure that all pull requests to the main branch pass required checks before merging. What should you implement?

A.Use a single workflow that builds and tests all microservices on every push to any branch.
B.Set up a webhook that triggers builds manually per service based on pull request comments.
C.Create a single workflow that uses a matrix strategy to build and test each microservice, and run it on every pull request.
D.Use separate workflows for each microservice with path filters (on: pull_request paths:) so that only workflows with changed files are triggered.
AnswerD

Creating separate workflow files per microservice and using `on: pull_request: paths:` means each workflow activates only when a push or PR changes files under its configured path. This scopes builds and tests to the specific services affected by a change, reducing CI runtime and cost while still producing required status checks for the PR.

Why this answer

GitHub Actions path filters (on: pull_request paths:) allow you to trigger workflows only when changes occur in specific directories. This ensures that only the microservices affected by a pull request are built and tested, reducing build times and resource usage. Option A is incorrect because building all services on every push is wasteful.

Option B is incorrect because manual triggering via webhook comments defeats automation and is not scalable. Option C is incorrect because a matrix strategy, while useful for parallel builds, still triggers on every pull request and would build all services, not just the changed ones.

411
Multi-Selecteasy

Your team uses Azure Pipelines and needs to comply with SOC 2 requirements. Which TWO features should you use to meet audit log requirements? (Select TWO.)

Select 2 answers
A.Configure network security groups to block public access
B.Automate secret rotation for service connections
C.Enable Azure DevOps audit logging
D.Create service principals for pipeline authentication
E.Stream audit logs to Azure Monitor Log Analytics
AnswersC, E

Enabling Azure DevOps audit logging records user and service principal actions across the organization, such as pipeline creation, permission changes, and policy edits, into the Audit log, which is the foundational mechanism for meeting SOC compliance evidence requirements.

Why this answer

Azure DevOps audit logging (Option C) captures a detailed, immutable record of events such as pipeline runs, permission changes, and access attempts, which is essential for SOC 2 audit log requirements. Streaming these logs to Azure Monitor Log Analytics (Option E) enables long-term retention, advanced querying, and alerting, satisfying the need for secure log storage and monitoring.

Exam trap

The trap here is that candidates confuse security controls (like network security groups or secret rotation) with audit logging features, mistakenly thinking any security measure fulfills audit log requirements, when only dedicated logging and log export features satisfy SOC 2 audit trail mandates.

412
MCQmedium

You are designing a build pipeline that uses a combination of tasks. The pipeline must compile code, run unit tests, and then publish code coverage results. The tasks are: Visual Studio Build, Visual Studio Test, and Publish Code Coverage Results. Which task should be performed first?

A.Visual Studio Build
B.Visual Studio Test
C.Publish Code Coverage Results
AnswerA

The Visual Studio Build task invokes MSBuild to compile the solution and must be the first pipeline action because it produces the binary artifacts (e.g., test assemblies, application DLLs, and PDBs) that every downstream task consumes. Both the VSTest task and the Publish Code Coverage Results task depend on this compiled output—VSTest cannot discover or execute tests without assemblies to load, and coverage data is only generated when those tests run. Additionally, MSBuild can perform tasks like restoring NuGet packages and copying build outputs, ensuring that the workspace is in a consistent state before testing begins. Therefore, placing it anywhere other than first would create an immediate hard failure with 'file not found' or 'no test source files' errors.

Why this answer

The correct order of tasks is: first Visual Studio Build to compile code, then Visual Studio Test to run unit tests, and finally Publish Code Coverage Results. Since the question asks for the first task in the sequence, the correct answer is Visual Studio Build (Option A).

Exam trap

Some candidates may place 'Publish Code Coverage Results' before 'Visual Studio Test', but coverage results are generated during tests, so they must come after.

413
MCQhard

Your company is migrating from TFVC to Git in Azure Repos. The repository contains a large number of binary files (e.g., .dll, .exe) that are frequently updated. You need to minimize repository size and clone time. What should you include in your migration plan?

A.Perform a shallow clone of the last commit only.
B.Use Git LFS to track binary files.
C.Use sparse checkout to exclude binary files from the working tree.
D.Use TFVC to Git converter with default settings.
AnswerB

Git LFS stores binary files in a separate remote store and replaces them in Git with small text pointers, so cloning fetches only the pointers and downloads actual binaries on demand (via `git lfs fetch` or by checking out the working tree). This keeps the .git directory and clone time small, and Azure Repos fully supports Git LFS for repos, making it the correct solution for large binary files.

Why this answer

Git LFS (Large File Storage) replaces large binary files in the repository with lightweight text pointers, storing the actual binary content in external storage. This prevents the repository from bloating with frequently updated binaries, reducing clone time and repository size since only the pointers are cloned.

Exam trap

The trap here is that candidates often confuse sparse checkout (which only affects the working tree) with a solution for repository size, or assume a shallow clone is sufficient without realizing it does not prevent binary bloat from accumulating in the repository history.

How to eliminate wrong answers

Option A is wrong because a shallow clone of the last commit only reduces clone time initially but does not address the underlying issue of binary files bloating the repository; future fetches and pushes will still transfer the full binary history. Option C is wrong because sparse checkout only controls which files appear in the working tree, but the binary files remain in the repository history and are still cloned, so it does not reduce repository size or clone time. Option D is wrong because using a TFVC-to-Git converter with default settings will convert all history including binary files as-is, leading to a large Git repository without any optimization for binary files.

414
MCQeasy

Your team uses GitHub Enterprise with GitHub Actions. Compliance requires that all contributors sign commits with a verified GPG key. You have enabled 'Require signed commits' on the repository. However, a developer reports that their commits are being rejected even though they have configured a GPG key. The error says 'Commit must have a valid signature.' The developer's GPG key is listed in their GitHub account settings. What is the most likely cause?

A.The developer's GPG key has expired.
B.The developer's GPG key is not uploaded to GitHub.
C.The developer's local Git email does not match the email associated with the GPG key in GitHub.
D.GitHub only supports S/MIME, not GPG.
AnswerC

GitHub verifies a GPG signature by checking that the email associated with the public key matches the author and committer email addresses embedded in the Git commit. If the developer's local Git user.email differs from the email linked to the GPG key in GitHub, the signature is cryptographically valid but GitHub marks the commit as 'unverified' because the identity does not match.

Why this answer

The most likely cause is that the developer's local Git email does not match the email associated with their GPG key in GitHub. When GitHub checks a signed commit, it verifies that the committer email matches one of the emails in the GPG key's UID. If they differ, the signature is considered unverified, even if the key is uploaded.

Option A is incorrect because an expired key would produce a different error. Option B is incorrect because the developer already has the key uploaded. Option D is incorrect because GitHub supports GPG, not just S/MIME.

415
Multi-Selecteasy

Which TWO practices help improve the security of container images in a CI/CD pipeline? (Choose two.)

Select 2 answers
A.Run containers with root privileges to avoid permission issues.
B.Store container images in a public registry for easy access.
C.Sign container images to verify their integrity.
D.Use the 'latest' tag for base images to always get the newest patches.
E.Scan container images for vulnerabilities during the build.
AnswersC, E

Signing container images cryptographically verifies the publisher's identity and guarantees the image has not been tampered with, ensuring that only trusted images are deployed. This helps prevent supply-chain attacks.

Why this answer

Signing container images (Option C) ensures their integrity and authenticity by allowing the CI/CD pipeline to verify that the image has not been tampered with since it was signed, typically using tools like Docker Content Trust (DCT) or Notary. Scanning container images for vulnerabilities (Option E) during the build identifies known security issues in the image layers and dependencies, allowing teams to remediate before deployment. Both practices are essential for supply chain security.

The other options are incorrect: running as root increases risk, public registries expose images, and 'latest' tags cause unpredictable updates.

Exam trap

Candidates often confuse the 'latest' tag with a security best practice, but it undermines reproducibility and security by introducing uncontrolled updates. Also, some may think running with root privileges avoids permission issues, but it increases attack surface. Signing and scanning are the verifiable security controls.

416
MCQeasy

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

A.Add a workflow triggered on push to main that uses the 'softprops/action-gh-release' action to create a release with auto-generated release notes.
B.Configure a branch protection rule to require a release note file in each pull request.
C.Use a workflow that runs on pull request merge and creates a Git tag, then rely on GitHub to create a release from the tag.
D.Add a step to the existing CI workflow that runs 'gh release create' with a changelog.
AnswerA

This is correct because the workflow, triggered on every push to main, uses the 'softprops/action-gh-release' action with 'generate_release_notes: true' (or the action's default behavior) to automatically create a GitHub Release. The action compares against the previous tag and auto-assembles release notes from merged pull requests, providing a fully automated, hands-off release process.

Why this answer

The 'softprops/action-gh-release' action can create a release and, when configured with `generate_release_notes: true`, generates release notes from merged PRs. Option B is incorrect because requiring a release note file via branch protection does not create a GitHub release. Option C is incorrect because GitHub does not automatically create releases from tags; a release must be created explicitly.

Option D is incorrect because `gh release create` alone does not automatically generate release notes from merged PRs; it requires a manually constructed changelog.

417
MCQmedium

Your team uses a monorepo in Azure Repos. Developers frequently commit directly to the main branch, causing build failures. You need to enforce a policy that requires all changes to go through pull requests with at least one reviewer. What should you configure?

A.Configure a repository policy to require a pull request for all branches.
B.Create a service hook to reject commits to main that are not from pull requests.
C.Configure a branch policy on the main branch to require a minimum number of reviewers.
D.Enable the 'Require a minimum number of reviewers' setting in the project settings.
AnswerC

This is correct because Azure Repos branch polices on the main branch can require that all changes come through a pull request and specify a minimum number of reviewer approvals. This enforcement happens before merge, blocking direct pushes and insufficiently reviewed PRs, thus protecting the main branch.

Why this answer

Azure Repos allows you to configure branch policies on specific branches (like main) to enforce that all changes must come through pull requests and require a minimum number of reviewers. This directly addresses the need to prevent direct commits to main and ensure code review before merging.

Exam trap

The trap here is that candidates often confuse project-level settings with branch-level policies, or mistakenly think service hooks can enforce commit restrictions, when in fact Azure Repos requires explicit branch policy configuration on the target branch to enforce pull request requirements and reviewer counts.

How to eliminate wrong answers

Option A is wrong because configuring a repository policy to require a pull request for all branches would apply the restriction to every branch, including feature branches, which is overly broad and not the specific requirement to protect only the main branch. Option B is wrong because service hooks are used to trigger external events (e.g., webhooks) based on repository actions, not to reject commits; they cannot enforce branch policies or block direct commits. Option D is wrong because the 'Require a minimum number of reviewers' setting is not available in project settings; it is a branch policy configuration that must be applied at the branch level within the repository settings.

418
MCQeasy

A team wants to enforce that all Azure resource groups in a subscription are tagged with 'CostCenter' and 'Environment'. They need a solution that automatically applies these tags to any new resource group and ensures compliance without manual intervention. What should they use?

A.Azure Policy
B.Azure RBAC
C.Azure Blueprints
D.Azure Resource Graph
AnswerA

Azure Policy is the correct service because it uses built-in effects such as 'deny' to block non-compliant resource group creation or 'append' to automatically add required tags, enforcing tagging rules in real time during deployment and continuously. It provides both proactive enforcement and ongoing compliance assessment across subscriptions.

Why this answer

Azure Policy is the correct choice because it allows you to define and enforce tagging rules at scale. By creating a policy that requires 'CostCenter' and 'Environment' tags on resource groups, and setting the policy effect to 'deny' or 'append' (to automatically add missing tags), any new resource group creation that violates the policy is blocked or automatically remediated, ensuring compliance without manual intervention.

Exam trap

The trap here is that candidates confuse Azure Blueprints (which can include policies) with Azure Policy itself, but Blueprints are for deploying entire environments, not for continuous, automatic enforcement on all new resource groups across a subscription.

How to eliminate wrong answers

Option B (Azure RBAC) is wrong because Role-Based Access Control manages permissions (who can do what) on Azure resources, not the enforcement of resource metadata like tags. Option C (Azure Blueprints) is wrong because while Blueprints can include policies and assign tags during deployment, they are designed for orchestrating repeatable environments (e.g., a full subscription setup) and do not automatically enforce tagging on all new resource groups outside the blueprint's scope. Option D (Azure Resource Graph) is wrong because it is a query service for exploring and auditing resources, not a mechanism to enforce or automatically apply tags.

419
MCQhard

During a release pipeline, you notice that the deployment to staging fails intermittently due to a timeout waiting for the health check endpoint to return 200. The health check typically passes within 30 seconds, but occasionally takes up to 2 minutes. You need to make the deployment more reliable without affecting the overall release time. What should you do?

A.Remove the health check from the pipeline and rely on monitoring.
B.Add a retry task that runs the health check again after a failure.
C.Increase the health check timeout in the pipeline task to 3 minutes.
D.Reduce the health check timeout to 10 seconds to fail fast and trigger a rollback.
AnswerC

Increasing the health check timeout to 3 minutes directly addresses the intermittent startup delay by allowing the deployment to wait longer for the application to become healthy, reducing false-negative failures. The current timeout is too tight for the observed warm-up behavior, so this change accommodates the normal variation without compromising the overall release gate, while still failing if the service genuinely cannot become ready within the allowed window.

Why this answer

Increasing the health check timeout to 3 minutes accommodates the occasional 2-minute delay without failing the deployment. Since the health check typically passes within 30 seconds but can take up to 2 minutes, a 3-minute timeout ensures the pipeline waits long enough for the endpoint to return HTTP 200, making the deployment more reliable without adding extra retry cycles or changing the overall release time.

Exam trap

The trap here is that candidates often choose retry logic (Option B) thinking it handles intermittent failures, but retries increase total release time, whereas simply increasing the timeout (Option C) waits once for the expected duration without extra cycles.

How to eliminate wrong answers

Option A is wrong because removing the health check eliminates validation that the application is running correctly after deployment, which can lead to undetected failures in staging. Option B is wrong because adding a retry task would increase the overall release time by re-running the health check after each failure, contradicting the requirement to not affect overall release time. Option D is wrong because reducing the timeout to 10 seconds would cause frequent false failures, triggering unnecessary rollbacks and making the deployment less reliable.

420
MCQhard

You are designing a release pipeline for a microservices application deployed to Azure Kubernetes Service (AKS). You need to implement a strategy that minimizes downtime during updates by gradually shifting traffic to the new version while monitoring for errors. Which deployment strategy should you use?

A.Recreate deployment
B.Blue-green deployment
C.Canary deployment
D.Rolling update
AnswerC

Correct: Canary releases a small subset of new version and gradually increases traffic with monitoring.

Why this answer

Canary deployment is the correct choice because it gradually shifts a small percentage of traffic to the new version while monitoring for errors, allowing you to detect issues early and roll back quickly without impacting all users. In AKS, this can be implemented using a service mesh like Istio or a progressive delivery tool like Flagger, which manages traffic splitting via VirtualService and DestinationRule configurations. This minimizes downtime by ensuring the majority of users remain on the stable version until the new version is verified.

Exam trap

The trap here is that candidates often confuse canary deployment with rolling update, but rolling update does not support traffic splitting or error-monitoring-based rollback—it simply replaces pods without the ability to route a controlled percentage of traffic to the new version for validation.

How to eliminate wrong answers

Option A is wrong because Recreate deployment terminates all existing pods before creating new ones, causing full downtime during the update, which contradicts the requirement to minimize downtime. Option B is wrong because Blue-green deployment switches traffic entirely from the old version to the new version in one step, which does not gradually shift traffic or allow incremental monitoring; it also requires double the infrastructure. Option D is wrong because Rolling update replaces pods incrementally but does not provide fine-grained traffic splitting or canary-style monitoring—it updates pods in place without the ability to route a specific percentage of traffic to the new version for error detection.

421
MCQeasy

A developer accidentally committed a sensitive password to a Git repository. The commit has already been pushed to the remote. What is the first step to remediate the situation?

A.Delete the file from the repository and commit the deletion
B.Remove the password from the file, amend the commit, and force push
C.Revert the commit that introduced the password
D.Immediately notify the security team and rotate the password
AnswerD

Rotating/revoking the password is a critical remediation step to prevent unauthorized use, but it does not remove the secret from source control. You must also purge the secret from Git history using tools like git filter-branch or git filter-repo, or by amending the commit as described, to fully eliminate the exposure.

Why this answer

Once a secret is pushed to a remote Git repository, it must be considered compromised because the commit may already be fetched by others, and old commits remain in reflogs and other clones. The first step is to immediately notify the security team and rotate/revoke the password to prevent unauthorized use. Only after the credential is invalidated should you attempt to remove it from Git history (e.g., by amending, rebasing, or using filter-repo) and force push, understanding that history rewriting may not fully eliminate all copies.

Exam trap

The trap is that candidates may focus on removing the secret from history rather than recognizing that the secret is already exposed. The correct first action is always to limit the damage by revoking or rotating the compromised credential.

How to eliminate wrong answers

Option A is wrong because deleting the file and committing the deletion leaves the password in the previous commit history, which is still accessible via `git log` and `git checkout`. Option C is wrong because reverting the commit creates a new commit that undoes the changes but does not remove the original commit from history; the password remains in the reverted commit. Option D is wrong because while notifying the security team and rotating the password is a critical follow-up step, it is not the first technical step to remediate the Git history; the immediate priority is to remove the password from the remote repository to prevent further exposure.

422
MCQeasy

Your Azure DevOps project has multiple teams. You need to ensure that each team's board only shows work items assigned to that team. What should you configure?

A.Create a shared query for each team and pin it to the dashboard.
B.Assign each team a unique iteration path.
C.Set permissions on area paths to restrict access.
D.Configure team settings to set default area paths for each team.
AnswerD

Configuring team settings to set default area paths for each team is the correct, supported way to scope a team's board to only its work items. Each Azure DevOps team has a set of selected area paths; the board automatically filters to items assigned to those paths, so teams see only their own backlog and board items.

Why this answer

Team settings allow you to configure default area paths for each team, which ensures that the team board only displays work items assigned to those area paths. This effectively scopes the board to the team's work. Option A is wrong because shared queries are custom views and do not affect the default board filtering; they are used for reporting or dashboards, not for team board visibility.

Option B is wrong because iteration paths control sprint scheduling and timeboxes, not the visibility of work items on the board; area paths are used for team assignment. Option C is wrong because permissions on area paths control access levels (who can view or edit), not which work items appear on a team board; area path permissions do not filter the board content by team.

423
Multi-Selecteasy

Which TWO Git operations are considered dangerous and should be used with caution because they rewrite history? (Select TWO.)

Select 2 answers
A.git fetch
B.git push --force
C.git merge
D.git rebase
E.git revert
AnswersB, D

git push --force is dangerous because it replaces the remote branch's ref, forcibly overwriting the remote history and potentially discarding commits that other team members have already based work on. This rewrites shared history and can permanently destroy others' changes; --force-with-lease provides a safer alternative by refusing to overwrite if the remote has moved.

Why this answer

`git push --force` overwrites the remote branch history with the local branch, discarding any commits on the remote that are not in the local history. This can cause other collaborators to lose work if they have based changes on the overwritten commits, making it a history-rewriting operation that must be used with caution.

Exam trap

The trap here is that candidates often confuse `git revert` with `git reset` or think `git merge` rewrites history, but the key distinction is that only operations that change existing commit SHAs (like rebase and force push) are considered history-rewriting and dangerous.

424
Multi-Selectmedium

Which TWO of the following are valid ways to trigger a release pipeline in Azure DevOps? (Select TWO.)

Select 2 answers
A.Continuous deployment trigger after a build completes.
B.Source version trigger.
C.Manual trigger via the 'Create release' button.
D.Pull request trigger.
E.Scheduled release trigger.
AnswersA, E

A continuous deployment trigger automatically creates a release as soon as an associated build artifact is produced by a successful build. This is a native, valid release pipeline trigger in Azure DevOps, enabling automated deployment pipelines.

Why this answer

Azure DevOps release pipelines can be triggered in multiple ways. A continuous deployment trigger (A) automatically creates a release whenever a build artifact is successfully produced. A scheduled release trigger (E) creates a release at a defined time (e.g., nightly).

Manual release creation via the 'Create release' button (C) is a manual action, not an automated configured trigger. Pull request triggers (D) are valid only for build pipelines, not release pipelines. 'Source version trigger' (B) is not a standard release trigger type. Therefore, the two valid trigger types are A and E.

Exam trap

The trap here is that candidates confuse manual release creation (an action) with a configured trigger (an automated event), and they may incorrectly assume that pull request triggers apply to release pipelines when they are only valid for build pipelines.

425
MCQmedium

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

A.Create a separate release pipeline for each microservice and trigger them in sequence using pipeline completion triggers.
B.Create a single build pipeline that produces all container images, then a release pipeline that deploys the single artifact.
C.Create a single release pipeline that consumes multiple build artifacts (one per microservice) and uses a Helm chart per microservice, deploying them in stages.
D.Create a single multi-stage YAML pipeline that builds and deploys all microservices together.
AnswerC

A single release pipeline consuming multiple build artifacts, one per microservice, preserves independent artifact versioning while centralizing deployment coordination in one auditable process. Using a Helm chart per microservice allows each service to be templated and configured independently, while shared release stages, approval gates, and rollback steps can orchestrate the full deployment consistently across environments.

Why this answer

A single release pipeline can consume multiple build artifacts (one per microservice) and use Helm charts to deploy each microservice in stages. This allows coordinated deployment without duplicating the pipeline logic. Option A is incorrect because creating separate release pipelines for each microservice and triggering them sequentially lacks a single orchestration point and can lead to coordination failures.

Option B is incorrect because creating a single build pipeline that produces all container images couples the builds and prevents independent microservice development. Option D is incorrect because a single multi-stage YAML pipeline that builds and deploys all microservices together also couples the build and deploy stages, and does not allow each microservice to have its own independent build pipeline.

426
Multi-Selecteasy

Your team uses Azure Boards with a custom process. Which two features allow you to customize the work item types? (Choose two.)

Select 2 answers
A.Create an inherited process from the default process.
B.Add custom work item types to an inherited process.
C.Configure rules to create new work item types.
D.Use team settings to define new work item types.
E.Modify the default process directly.
AnswersA, B

Azure Boards default processes (Agile, Scrum, CMMI, Basic) are read-only system processes. To customize, you must create an inherited process, which is a copy that allows adding custom fields, work item types, rules, and other process-level changes while retaining the original defaults.

Why this answer

In Azure Boards, customization of work item types is only possible through an inherited process. You must create an inherited process from a default process (e.g., Agile, Scrum, CMMI) to enable any modifications. This ensures the default process remains unaltered and supports upgrade compatibility.

Exam trap

The trap here is that candidates often confuse team settings (which manage visibility and defaults) with process-level customization, or mistakenly believe the default process can be directly edited, but Azure Boards enforces that only inherited processes are customizable.

427
MCQmedium

You have a YAML pipeline with multiple jobs that need to run in parallel. However, one job depends on artifacts produced by a previous job. How should you configure the dependency?

A.Set dependsOn on the dependent job and use PublishBuildArtifacts and DownloadBuildArtifacts tasks.
B.Use the 'dependsOn' keyword only, artifacts are automatically shared.
C.Set the 'condition' to 'eq(variables['Agent.JobStatus'], 'Succeeded')' on the dependent job.
D.Use the 'pool' keyword to ensure both jobs run on the same agent.
AnswerA

To share artifacts between jobs in Azure Pipelines, you need both an execution dependency and an explicit artifact transfer. The `dependsOn` keyword on the dependent job ensures it runs only after the dependency job completes, but files are not automatically shared; instead, you must use the `PublishBuildArtifacts` task in the source job to publish the files and the `DownloadBuildArtifacts` task in the dependent job to retrieve them.

Why this answer

In Azure DevOps YAML pipelines, job dependencies are explicitly declared using the `dependsOn` keyword, and artifacts must be published and downloaded using `PublishBuildArtifacts` and `DownloadBuildArtifacts` tasks (or the `publish` and `download` pipeline decorators). Without explicit artifact sharing, outputs from one job are not automatically available to another job, even if `dependsOn` is set.

Exam trap

The trap here is that candidates assume `dependsOn` alone handles artifact sharing, but Azure DevOps requires explicit publish/download tasks because jobs may run on different agents with no shared file system.

Why the other options are wrong

B

Artifacts must be explicitly published and downloaded.

C

Condition controls execution but does not handle artifact sharing.

D

Same agent is not guaranteed and doesn't handle dependencies.

428
Multi-Selectmedium

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

Select 2 answers
A.Configure pre-deployment approvals on the Production environment.
B.Use Deployment Gates with a manual approval gate.
C.Set the 'Required approvers' field on the environment to a specific user or group.
D.Add a Manual Intervention task in the release pipeline.
E.Add an Approval Check to the agent pool.
AnswersA, C

In Azure Pipelines, pre-deployment approvals on an environment require designated approvers to manually approve before any release deployment to that environment, providing a controlled go/no-go checkpoint. This is the standard mechanism for enforcing manual sign-off on production deployments, unlike automated gates.

Why this answer

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

Exam trap

The trap here is confusing 'Deployment Gates' (which are automated health evaluation checks) with 'Approval Checks' (which are manual sign-offs), leading candidates to incorrectly select Option B as a valid method for approval checks.

429
Multi-Selecthard

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

Select 2 answers
A.Use Azure App Service deployment slots and perform a swap
B.Stop the web app before deploying, then start it after
C.Implement a rolling deployment strategy across regions
D.Deploy to all regions simultaneously
E.Use a single deployment slot for all regions
AnswersA, C

Use Azure App Service deployment slots and perform a swap: This is correct because deployment slots are live environments with their own hostnames, allowing you to stage a new build, run smoke tests, and then swap it into production instantly. The swap ensures zero downtime because the roles are atomically exchanged and Azure warms up the target slot before completing the operation.

Why this answer

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

Exam trap

The trap here is that candidates often confuse 'minimizing downtime' with 'eliminating all risk' and may incorrectly choose to stop the app (Option B) or deploy simultaneously (Option D), not realizing that deployment slots and rolling updates are the standard Azure patterns for zero-downtime deployments.

Why the other options are wrong

B

Stopping the app causes downtime.

D

Simultaneous deployment can cause full outage if something goes wrong.

E

A single slot doesn't allow zero-downtime swap.

430
Multi-Selecthard

You have a YAML pipeline that builds a Docker image and pushes it to Azure Container Registry (ACR). You need to ensure the pipeline uses the latest version of Docker and that the build is cached for faster subsequent runs. Which two tasks should you include? (Choose two.)

Select 2 answers
A.DockerInstaller@0
B.Docker@2 with arguments: --cache-from
C.DockerCompose@0
D.HelmDeploy@0
AnswersA, B

Why this answer

(DockerInstaller@0) is correct because it ensures the pipeline uses the latest version of Docker by installing or upgrading the Docker engine on the build agent. Option B (Docker@2 with --cache-from) is correct because it enables layer caching by pulling the previously built image from ACR as a cache source, which speeds up subsequent builds by reusing unchanged layers.

Exam trap

The trap here is that candidates often confuse DockerCompose@0 (used for orchestrating multiple containers) with Docker@2 (used for building and pushing single images), or assume HelmDeploy@0 is relevant because it involves containers, but it is strictly for Kubernetes deployments.

Why the other options are wrong

C

Docker Compose is not needed for a single image build.

D

Helm is for package management, not Docker build.

431
MCQeasy

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

A.Tags trigger
B.Schedule trigger
C.PR trigger
D.CI trigger with branch filters
AnswerA

Tags trigger runs the pipeline when tags are pushed.

Why this answer

Tags trigger allows running pipelines when a tag is pushed or updated. Option B (Schedule trigger) is incorrect because it runs on a predefined schedule, not on tag events. Option C (PR trigger) is incorrect because it triggers on pull request actions, not on tags.

Option D (CI trigger with branch filters) is incorrect because CI trigger monitors branches, not tags; even with branch filters it does not respond to tags.

432
Multi-Selecthard

Which THREE steps should you take to implement a secure CI/CD pipeline that uses secrets from Azure Key Vault?

Select 3 answers
A.Use the Azure Key Vault task to download secrets as variables
B.Use secret variables in the pipeline that reference Key Vault secrets
C.Store secrets as plain text variables in the pipeline library
D.Hardcode secrets in the YAML file and use variables to mask them
E.Grant the build agent managed identity access to the Key Vault
AnswersA, B, E

The Azure Key Vault task authenticates to the vault and downloads the specified secrets as pipeline variables at runtime, ensuring that secret values are never stored in the pipeline definition or source control. This approach keeps secrets out of the YAML and only exposes them to tasks that need them, and the values are automatically masked if used in logs.

Why this answer

The Azure Key Vault task in Azure Pipelines can download secrets as pipeline variables at runtime, allowing the pipeline to securely reference them without exposing the secret values in logs or configuration. This task authenticates to Key Vault using a service connection or managed identity, ensuring secrets are never stored in the pipeline definition.

Exam trap

The trap here is that candidates often confuse 'masking' secrets in logs (Option D) with true secret isolation, mistakenly thinking that masking alone provides sufficient security, whereas Azure Key Vault integration ensures secrets are never stored in the pipeline definition or source control.

433
MCQeasy

You run the Azure CLI command shown in the exhibit. What is the output?

A.An error because the query syntax is incorrect
B.A table showing VM names and resource groups for VMs in eastus
C.A list of all VMs in the subscription
D.A list of all VMs in the westus location
AnswerB

This command retrieves the list of VMs in the subscription and then applies a JMESPath query that filters to only those VMs where the location property equals 'eastus', projecting the name and resourceGroup properties. With --output table, these are displayed as a table showing VM names and their resource groups, making this the correct outcome.

Why this answer

The Azure CLI command `az vm list --query "[?location=='eastus'].{Name:name, ResourceGroup:resourceGroup}" --output table` filters virtual machines to only those in the 'eastus' location, then projects the 'name' and 'resourceGroup' properties into a table. The `--query` parameter uses JMESPath syntax, which is correct here, and the `--output table` formats the result as a table. Therefore, the output is a table showing VM names and resource groups for VMs in eastus.

Exam trap

The trap here is that candidates might think the query syntax is invalid (Option A) due to unfamiliarity with JMESPath, or they might overlook the location filter and assume the command returns all VMs (Option C) or VMs in a different location (Option D).

How to eliminate wrong answers

Option A is wrong because the query syntax is valid JMESPath; the filter `[?location=='eastus']` and projection `{Name:name, ResourceGroup:resourceGroup}` are correctly formed, so no error occurs. Option C is wrong because the query explicitly filters by location 'eastus', so it does not list all VMs in the subscription. Option D is wrong because the filter specifies 'eastus', not 'westus'; the command will only return VMs in the eastus location.

434
MCQhard

You are the DevOps lead for a fintech company. The organization uses a multi-tenant Azure DevOps environment with hundreds of pipelines. The compliance team requires that every pipeline run must be auditable with the following attributes captured: who triggered the run, what code changes were included, which artifacts were produced, and whether any secrets (e.g., Azure Key Vault references) were accessed during the run. Additionally, all audit data must be retained for 7 years and be queryable within 5 minutes of a pipeline completion. Current state: pipelines use Azure Key Vault for secrets, and YAML pipelines are defined with variables referencing Key Vault. You need to design an instrumentation strategy to meet these requirements. What should you do?

A.Enable Azure DevOps Audit Streams to send audit events to a Log Analytics workspace. Configure a Log Analytics workspace with 7-year retention. Create a dashboard and alert rules for compliance.
B.Use Azure Event Grid to subscribe to pipeline run events and store them in Azure Cosmos DB with TTL for 7 years.
C.Add a step at the end of each pipeline to upload pipeline logs as pipeline artifacts with a retention policy of 7 years.
D.Instrument each pipeline with custom tasks that send telemetry to Application Insights. Set Application Insights to 7-year retention.
AnswerA

Azure DevOps Audit Streams is the native mechanism that pushes every audit event from the organization, including user/group changes, permissions, service connection modifications, and pipeline run events, to a Log Analytics workspace via a diagnostic setting. Configuring the workspace with interactive retention plus a seven-year archive provides durable, long-term compliance storage, and KQL queries can power dashboards and alert rules to detect anomalous behavior. This matches the compliance requirement because it captures who did what, when, and from where, with near real-time delivery.

Why this answer

Using Azure DevOps Audit Streams to send events to a Log Analytics workspace provides long-term retention and near real-time querying. Azure DevOps Audit logs capture all required attributes including pipeline runs, secret access, and user identity. Option B is incorrect because Azure Event Grid subscription to pipeline run events does not provide long-term retention and querying capabilities; it is event-driven delivery.

Option C is incorrect because adding a step to upload pipeline logs as artifacts does not capture the audit trail of who triggered the run or whether secrets were accessed. Option D is incorrect because instrumenting pipelines with custom tasks sending telemetry to Application Insights is for application telemetry, not pipeline audit, and does not capture all required attributes.

435
MCQeasy

Your team uses Git with a trunk-based development strategy. They want to ensure that all code changes are integrated into the main branch at least once a day, and that branch lifetimes are short. Which practice best supports this?

A.Developers use GitFlow with develop and feature branches, merging to develop daily and to main at release.
B.Developers commit directly to a release branch, and then the release branch is merged to main at the end of the sprint.
C.Developers work on long-lived feature branches and merge to main only after all features are complete.
D.Developers work on short-lived feature branches (less than a day) and merge to main via pull requests after successful CI.
AnswerD

Trunk-based development relies on short-lived feature branches that are typically less than a day old, with developers merging to main via pull requests only after successful continuous integration; this keeps main in a releasable state and enables rapid, small-batch integration.

Why this answer

Trunk-based development emphasizes short-lived feature branches (typically less than a day) that are merged into the main branch via pull requests after passing continuous integration (CI) checks. This ensures all code changes are integrated at least daily, keeping branch lifetimes short and reducing merge conflicts.

Exam trap

The trap here is that candidates may confuse GitFlow (option A) with trunk-based development, but GitFlow's long-lived develop and feature branches directly contradict the requirement for daily integration into main and short branch lifetimes.

How to eliminate wrong answers

Option A is wrong because GitFlow uses long-lived develop and feature branches, with merges to main only at release, which violates the trunk-based requirement of daily integration into main. Option B is wrong because committing directly to a release branch and merging only at sprint end creates long-lived branches and delays integration, contradicting the need for daily main branch updates. Option C is wrong because long-lived feature branches delay integration until all features are complete, which is the opposite of trunk-based development's short-lived branch and frequent merge strategy.

436
MCQhard

Your organization uses GitHub Actions for CI/CD. You need to ensure that secrets stored in GitHub Actions are not exposed in logs. A developer accidentally logs a secret using 'echo ${{ secrets.API_KEY }}' in a workflow step. What is the default behavior?

A.The secret value is replaced with an empty string in the log
B.The workflow run fails with an error about secret exposure
C.The secret is redacted before the step runs, and the step fails if it tries to use the secret
D.The secret value is masked with asterisks in the log output
AnswerD

When a configured secret appears in the workflow log, GitHub Actions automatically scans the output and replaces every occurrence of the secret's value with `***` to prevent exposure. This masking occurs at the log-upload stage, so even indirect leakage via environment variables or command outputs is redacted in the displayed logs.

Why this answer

GitHub Actions automatically masks secrets in workflow logs. When a secret is used in a step (e.g., via `${{ secrets.API_KEY }}`), GitHub replaces any occurrence of the secret's value in the log output with `***`. This redaction happens at runtime, so even if a developer accidentally echoes the secret, the log will show asterisks instead of the actual value.

Exam trap

The trap here is that candidates may confuse GitHub Actions' automatic log masking with a workflow failure or pre-execution redaction, but the key is that masking happens at runtime in the log output without stopping the workflow.

How to eliminate wrong answers

Option A is wrong because secrets are not replaced with an empty string; they are masked with asterisks (`***`) to preserve log readability while hiding the value. Option B is wrong because the workflow does not fail due to secret exposure; GitHub Actions does not automatically fail a run when a secret is logged—it only masks the output. Option C is wrong because the secret is not redacted before the step runs; it is available for use, and the step does not fail if it tries to use the secret—the masking occurs in the log output after execution.

437
MCQhard

Your team uses Azure Pipelines with Microsoft-hosted agents. You need to ensure that sensitive variables like API keys are securely passed to build tasks, but not exposed in logs. Which approach should you use?

A.Retrieve the API key from Azure Key Vault at runtime using the Azure Key Vault task, but do not mark the output as secret
B.Store the API key as a secret variable in the pipeline library or variable group
C.Define the API key in a variable template with 'isSecret: false'
D.Store the API key as a plain text variable in the pipeline and use it as an environment variable
AnswerB

Secret variables stored in the pipeline library or a variable group are encrypted at rest with Azure Key Vault-backed encryption and are masked in all pipeline logs and output. This is the recommended approach for handling sensitive values like API keys because it centralizes secure storage and prevents accidental leakage.

Why this answer

Secret variables in Azure Pipelines are encrypted at rest and masked in logs, ensuring sensitive values like API keys are never exposed. Storing the API key as a secret in a pipeline library or variable group allows it to be securely referenced by tasks without appearing in output or debug logs.

Exam trap

The trap here is that candidates may think retrieving secrets from Key Vault is always secure, but failing to mark the output as secret (Option A) or using non-secret variable templates (Option C) will expose the value in logs, which is a common oversight.

How to eliminate wrong answers

Option A is wrong because not marking the output as secret means the retrieved value will be visible in plain text in logs, defeating the purpose of using Key Vault. Option C is wrong because setting 'isSecret: false' explicitly marks the variable as non-secret, so it will be displayed in logs and is not encrypted. Option D is wrong because plain text variables are stored in clear text and are not masked in logs, making them vulnerable to exposure.

438
MCQhard

Refer to the exhibit. This is a deployment job definition in a multi-stage YAML pipeline. The deployment fails because the Kubernetes service connection 'aks-prod' cannot be found. What is the most likely cause?

A.The approval for production environment is blocking the deployment.
B.The agent pool does not have access to the AKS cluster.
C.The service connection 'aks-prod' does not exist in the Azure DevOps project.
D.The namespace 'prod' does not exist in the AKS cluster.
AnswerC

The YAML deployment job references `aks-prod` via the `azureSubscription` or `connectionRef` field, and Azure DevOps must resolve this to an existing service connection in the project before any Kubernetes interaction occurs. If no service connection named `aks-prod` exists, the pipeline fails with a 'not found' error during the configuration phase, confirming this as the root cause.

Why this answer

The error message explicitly states that the Kubernetes service connection 'aks-prod' cannot be found. In Azure DevOps, a service connection is a stored credential set that must exist in the project before it can be referenced in a YAML pipeline. If the connection name is misspelled, deleted, or never created, the pipeline will fail at the deployment job stage regardless of other configurations.

Exam trap

The trap here is that candidates may confuse a missing service connection with runtime issues like namespace existence or agent permissions, but the error message is explicit about the connection not being found in the Azure DevOps project, not about a failure to connect to the cluster.

How to eliminate wrong answers

Option A is wrong because approval gates block the pipeline run from proceeding to the deployment stage, but they do not produce a 'service connection not found' error; they produce a pending approval status. Option B is wrong because agent pool access to the AKS cluster is managed via the service connection's credentials (e.g., kubeconfig or service principal), not directly by the agent pool; the error is about the connection object itself, not runtime access. Option D is wrong because a missing namespace in AKS would cause a Kubernetes API error (e.g., 'namespace not found') during the deployment step, not a failure to locate the service connection definition in Azure DevOps.

439
Multi-Selectmedium

Which TWO benefits does using deployment groups provide in Azure Pipelines? (Choose two.)

Select 2 answers
A.You can deploy to a specific set of target servers (e.g., all web servers in a farm).
B.They enable rolling deployments with health validation.
C.You can assign multiple deployment groups to a single agent.
D.Each target server must have its own agent.
E.Deployment groups can only be used with classic release pipelines.
AnswersA, B

Deployment groups allow you to define a logical set of target machines that share the same deployment role, such as all web servers in a farm. This enables precise, scoped deployments to specific servers within an environment, rather than deploying to an entire pool arbitrarily.

Why this answer

Deployment groups in Azure Pipelines allow you to define a logical set of target machines (e.g., all web servers in a farm) and deploy to them collectively. This enables targeted, multi-machine deployments without needing to manage individual agents per environment. Option B is correct because deployment groups support rolling deployments with built-in health validation, where the pipeline can monitor application health after each batch of updates and automatically roll back on failure.

Exam trap

The trap here is that candidates often confuse deployment groups with environment-level approvals or think they are exclusive to classic pipelines, but deployment groups are a flexible agent-based targeting mechanism that works across both classic and YAML pipelines.

440
MCQeasy

Your organization uses Azure DevOps. You have a classic release pipeline that deploys to multiple stages: Dev, QA, and Prod. Each stage has a pre-deployment approval gate. Recently, the QA team complained that they are not receiving approval notifications. You have verified that the approval configuration is correct and the approvers are members of the 'QA Approvers' group. The release pipeline is set to send email notifications to the approvers. However, the QA approvers report they do not receive any emails when a release is pending their approval. What should you check first?

A.Ask the QA team to check their spam folder.
B.Verify that the organization-level notification settings allow email notifications for approvals.
C.Add a 'Send email' task in the pipeline before the approval gate.
D.Check the 'Release Pipeline' logs for a warning about email delivery failure.
AnswerB

Verify that the organization-level notification settings allow email notifications for approvals, specifically the 'Release approval pending' subscription. In Azure DevOps, this subscription is a default system subscription that may be disabled or scoped to specific roles, and if it is turned off, approvers will not receive any approval notification emails regardless of personal notification preferences.

Why this answer

The correct first step. Even if the pipeline's approval configuration is correct and the approvers are in the correct group, the organization-level notification settings in Azure DevOps can override individual pipeline settings. If email notifications for approvals are disabled at the organization level, no emails will be sent regardless of the pipeline configuration.

Therefore, checking the organization-level notification settings should be the first troubleshooting step. Option A is not the first step because while spam filters could cause missed emails, the issue is more likely a system-level configuration problem. Option C is incorrect because Azure DevOps automatically sends approval notifications; adding a manual 'Send email' task is unnecessary and not a standard fix.

Option D is incorrect because checking release pipeline logs might reveal delivery failures, but the most efficient first step is to verify the notification settings at the organization level.

441
Matchingmedium

Match each Azure DevOps extension type to its example.

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

Concepts
Matches

SonarQube analysis

Burnup chart

Slack integration on work item update

Terraform task for Azure Pipelines

Why these pairings

In this matching exercise, the correct pairs are: Build task → NuGet Tool Installer, Dashboard widget → Sprint Burndown, and Service hook → Notify Slack on build completion. The distractors incorrectly assign Sprint Burndown as a build task and NuGet Tool Installer as a dashboard widget, testing your ability to distinguish between extension types based on their purpose. Build tasks execute during pipeline runs, dashboard widgets display information on dashboards, and service hooks trigger external actions on events.

442
Multi-Selectmedium

Your team uses Azure Repos with a Git branching strategy. You need to ensure that all changes to the release branch are reviewed by at least two approvers and that builds succeed before merging. Which TWO branch policy settings should you enable?

Select 2 answers
A.Build validation
B.Work item linking
C.Minimum number of reviewers (set to 2)
D.Require a clean fast-forward merge
E.Require a merge commit
AnswersA, C

Ensures builds succeed before merging.

Why this answer

Build validation (A) ensures that a pull request cannot be merged unless the source branch compiles successfully and passes all configured automated tests, which directly enforces the requirement that builds succeed before merging. Minimum number of reviewers (C) set to 2 enforces the policy that at least two distinct approvers must approve the pull request before it can be completed. Together, these two settings satisfy both conditions: successful builds and two-reviewer approval.

Exam trap

The trap here is that candidates often confuse 'minimum number of reviewers' with 'required reviewers' or mistakenly think 'work item linking' or 'merge strategy' policies can enforce approval counts or build success, when in fact they address completely different concerns.

443
Multi-Selecteasy

Which THREE are valid Git merge strategies available in Azure Repos pull requests?

Select 3 answers
A.Semi-linear merge
B.Merge commit (no fast-forward)
C.Fast-forward only
D.Squash merge
E.Rebase only
AnswersA, B, D

Semi-linear merge first rebases the source branch onto the latest target branch and then creates a merge commit, combining the benefits of a clean linear history with an explicit merge point. This strategy is valid in Azure Repos and is also known as 'rebasing before merging'.

Why this answer

Among the given options, the valid merge strategies are: 'Merge commit (no fast-forward)' (Option B), 'Semi-linear merge' (Option A), and 'Squash merge' (Option D). 'Merge commit (no fast-forward)' preserves the full history of both branches. 'Semi-linear merge' rebases the source branch onto the target before creating a merge commit, ensuring linear history. 'Squash merge' combines all source branch commits into a single commit on the target. Note that Azure Repos also supports 'Rebase and fast-forward' as a valid merge strategy, but it is not among the options. Options C and E are not valid merge strategies in Azure Repos pull requests.

Exam trap

Candidates often mistakenly believe that only two merge strategies are available or confuse 'Squash merge' as a non-strategy, but it is a valid completion option in Azure Repos.

444
MCQmedium

Your organization is adopting GitHub Actions for CI/CD. You need to ensure that only approved actions from your enterprise can be used in workflows. What should you configure?

A.Use a third-party tool to scan workflows for disallowed actions after each commit.
B.Set the enterprise policy to 'Allow all actions' and rely on code review.
C.Configure repository permissions to restrict actions to only those created by your organization.
D.Set the enterprise policy to 'Allow only specific actions' and add approved actions.
AnswerD

Setting the enterprise policy to 'Allow only specific actions' and adding approved actions is the correct approach because it enforces centrally across every repository in the enterprise. This proactive policy ensures that only vetted, approved actions from the allowlist can be used, preventing disallowed actions from ever running in the CI/CD pipeline.

Why this answer

GitHub Enterprise allows administrators to restrict which actions can be used in workflows by setting the enterprise policy to 'Allow only specific actions' and then explicitly approving a curated list of actions. This ensures that only trusted, pre-approved actions (e.g., from verified publishers or your own organization) can be referenced, preventing the execution of unapproved or malicious actions. This policy is enforced at the enterprise level and applies to all repositories within the enterprise, providing centralized control over CI/CD supply chain security.

Exam trap

The trap here is that candidates often confuse repository-level permissions (which do not have a 'restrict by creator' option) with enterprise-level policies, leading them to select Option C, which sounds plausible but is not a valid configuration in GitHub.

How to eliminate wrong answers

Option A is wrong because using a third-party tool to scan workflows after each commit is reactive and does not prevent the execution of disallowed actions at runtime; it also adds unnecessary complexity and latency. Option B is wrong because setting the enterprise policy to 'Allow all actions' and relying solely on code review is insecure and does not enforce any technical restriction, leaving the environment vulnerable to unapproved or malicious actions being merged and executed. Option C is wrong because configuring repository permissions to restrict actions to only those created by your organization is not a valid GitHub setting; GitHub does not have a built-in repository-level permission that filters actions by creator, and this approach would not cover actions from other trusted publishers or verified creators.

445
MCQmedium

You are designing a multi-stage YAML pipeline for a .NET Core application. The pipeline must build, test, and deploy to a staging environment. You want to ensure that the deployment stage only runs if the build and test stages succeed, and that the staging deployment uses the exact same bits that were built. Which strategy should you use?

A.Set up a release pipeline that uses the same build artifact and requires manual approval.
B.Create separate stages for build, test, and deploy. Use the 'dependsOn' keyword and publish artifact in build stage, download in deploy stage.
C.Use a build trigger on the staging branch to deploy after each commit, ignoring test results.
D.Define the pipeline with a single stage and use a condition to skip test on failure.
AnswerB

Separating build, test, and deploy into distinct stages with dependsOn ensures strict sequential execution: build completes, tests pass, then deploy runs. Publishing the artifact in the build stage and downloading it in the deploy stage preserves the exact compiled output, making the pipeline reliable and providing automatic gatekeeping based on test success.

Why this answer

Using separate stages with 'dependsOn' ensures the deployment stage only runs after successful build and test stages. Publishing the build artifact in the build stage and downloading it in the deploy stage guarantees that the exact same compiled bits are used for deployment, maintaining consistency across environments.

Exam trap

The trap here is that candidates may confuse release pipelines with multi-stage YAML pipelines, thinking manual approval is required for deployment control, but the question specifically requires using the exact same bits and conditional stage execution, which is directly achieved with 'dependsOn' and artifact publishing/downloading.

How to eliminate wrong answers

Option A is wrong because it suggests using a release pipeline with manual approval, which does not inherently ensure that the deployment uses the exact same bits from the build; it could use a different artifact version if not properly configured, and manual approval is not required for the scenario. Option C is wrong because using a build trigger on the staging branch and ignoring test results violates the requirement that the deployment stage only runs if tests succeed; it would deploy regardless of test outcomes. Option D is wrong because defining a single stage with a condition to skip tests on failure does not enforce that the deployment uses the same bits from the build; it also does not provide the multi-stage separation needed for the build, test, and deploy phases.

446
MCQhard

You are implementing a build pipeline for a .NET application that uses GitHub Advanced Security (GHAS) for code scanning. The pipeline must run CodeQL analysis on every pull request to the main branch. You have added the CodeQL task to the pipeline. However, the analysis results are not appearing in the 'Security' tab of the repository on GitHub. What is the most likely cause?

A.The pipeline is missing the 'Publish Security Analysis Logs' step to upload SARIF results to GitHub.
B.The GitHub repository is private, so security alerts are disabled.
C.The .NET project is not supported by CodeQL.
D.CodeQL analysis is not supported on pull request triggers.
AnswerA

In Azure DevOps, CodeQL results are produced as SARIF files, but they do not automatically appear in the GitHub Security tab. You must explicitly include the 'Publish Security Analysis Logs' task (or equivalent) to upload those SARIF logs to GitHub, which is what enables the findings to be displayed in the security alerts. Without this step, the analysis may run but the results are never surfaced.

Why this answer

CodeQL analysis results are uploaded to GitHub as SARIF files. Without the 'Publish Security Analysis Logs' step (or the equivalent 'upload-sarif' action), the SARIF file generated by CodeQL is not sent to GitHub, so the findings never appear in the Security tab. The pipeline must explicitly include this step to complete the integration with GitHub Advanced Security.

Exam trap

The trap here is that candidates assume adding the CodeQL analysis task alone is sufficient, overlooking the mandatory SARIF upload step that bridges the analysis output to GitHub's security dashboard.

How to eliminate wrong answers

Option B is wrong because GitHub Advanced Security and security alerts are fully supported on private repositories; the repository's visibility does not block results from appearing. Option C is wrong because CodeQL supports .NET (including C#, VB.NET, and F#) via the standard CodeQL queries; .NET is a first-class supported language. Option D is wrong because CodeQL analysis is explicitly supported on pull request triggers; the issue is not the trigger but the missing upload step.

447
MCQmedium

Your team uses GitHub Actions for CI/CD and needs to ensure that secrets such as Azure service principal credentials are not exposed in logs. What is the best practice to prevent secret exposure?

A.Store secrets as GitHub Actions secrets and reference them in workflows
B.Store secrets in the workflow YAML file
C.Use environment protection rules to mask secrets
D.Encrypt workflow logs after the run completes
AnswerA

GitHub automatically redacts secrets in logs when referenced correctly.

Why this answer

GitHub Actions secrets are encrypted environment variables that are automatically masked in workflow logs when referenced. By storing Azure service principal credentials as GitHub Actions secrets and using the `${{ secrets.SECRET_NAME }}` syntax in workflows, the actual secret values are never written to logs, preventing exposure. This is the recommended approach for handling sensitive data in GitHub Actions CI/CD pipelines.

Exam trap

The trap here is that candidates may confuse environment protection rules (which control deployment gates and approvals) with the built-in secret masking feature of GitHub Actions secrets, leading them to incorrectly select option C.

How to eliminate wrong answers

Option B is wrong because storing secrets directly in the workflow YAML file exposes them in plaintext in the repository, making them visible to anyone with access to the repository and potentially leaking them in logs or pull request comments. Option C is wrong because environment protection rules control deployment approvals and branch restrictions, but they do not mask or redact secrets from logs; secret masking is a built-in feature of GitHub Actions secrets, not environment rules. Option D is wrong because encrypting workflow logs after the run completes does not prevent secrets from being displayed in plaintext during the run or in the unencrypted logs before encryption; the secret would still be exposed in the log output.

448
Multi-Selecteasy

Which TWO triggers can start a release in Azure Pipelines?

Select 2 answers
A.Continuous integration
B.Schedule
C.Build completion
D.Work item state change
E.Pull request
AnswersB, C

A schedule trigger starts a release at a specified time.

Why this answer

In Azure Pipelines, a release can be triggered by a schedule, which allows you to define a cron-based trigger to deploy at specific times (e.g., nightly builds). The 'Build completion' trigger starts a release when a specific build pipeline completes, enabling chained deployments. Both are native release triggers in classic release pipelines.

Exam trap

The trap here is that candidates confuse triggers that apply to build pipelines (CI, PR) with those that apply to release pipelines, leading them to select 'Continuous integration' or 'Pull request' as valid release triggers.

449
MCQeasy

Your team uses GitHub Actions for CI/CD. You need to ensure that only specific branches can trigger the deployment workflow to production. Which workflow trigger should you configure?

A.on: push: branches: [main]
B.on: pull_request: branches: [main]
C.on: workflow_dispatch: inputs: branch: description: 'Select branch'
D.on: schedule: cron: '0 0 * * *'
AnswerA

This trigger fires the workflow automatically on every push to the main branch. The branch filter ensures that only commits pushed to main start the CI pipeline, so builds and tests run on the intended integration branch while ignoring feature branches.

Why this answer

The `on: push: branches: [main]` trigger ensures that the deployment workflow runs only when a push event occurs on the `main` branch. This directly enforces the requirement that only specific branches (here, `main`) can trigger production deployments, preventing accidental or unauthorized deployments from other branches.

Exam trap

The trap here is that candidates often confuse `pull_request` triggers with `push` triggers, thinking a PR merge to `main` counts as a push, but `pull_request` triggers on PR lifecycle events (like `opened` or `synchronize`), not the merge commit itself, which would require a `push` trigger on `main`.

How to eliminate wrong answers

Option B is wrong because `on: pull_request: branches: [main]` triggers the workflow on pull request events (opened, synchronized, etc.) targeting `main`, not on direct pushes; this would run the workflow in the context of a PR, not a production deployment, and could lead to unintended executions during code review. Option C is wrong because `workflow_dispatch` allows manual triggering from the GitHub UI or API with a branch input, but it does not restrict execution to specific branches by default—any user with write access can select any branch, violating the requirement for branch-specific restriction. Option D is wrong because `on: schedule: cron: '0 0 * * *'` triggers the workflow on a time-based schedule (daily at midnight), which is unrelated to branch-based triggers and would not enforce branch restrictions at all.

450
MCQhard

You are configuring a branch policy for the main branch using the Azure DevOps REST API. The JSON above is the policy configuration. A developer pushes a new commit to an existing pull request. What happens to the existing approvals?

A.The existing approvals remain valid.
B.The policy blocks the push until re-reviewed.
C.The pull request is automatically rejected.
D.All existing approvals are reset.
AnswerA

Correct: resetOnPush: false means approvals are not reset.

Why this answer

By default, Azure DevOps branch policies do not automatically reset approvals when a new commit is pushed to a pull request. The policy configuration shown includes the 'resetOnPush' property set to false (or it is not enabled), which means existing approvals remain valid even after new commits are pushed. Only if 'resetOnPush' is explicitly set to true would approvals be invalidated.

Exam trap

The trap here is that candidates often assume any new commit to a pull request automatically resets approvals, but Azure DevOps requires explicit configuration (the 'resetOnPush' property) to enable that behavior.

How to eliminate wrong answers

Option B is wrong because the policy does not block the push; Azure DevOps allows pushes to pull requests by default, and only blocks them if a 'Require a minimum number of reviewers' policy with 'Reset on push' is enabled. Option C is wrong because the pull request is not automatically rejected; rejection only occurs if the policy explicitly requires re-approval after a push, which is not configured here. Option D is wrong because approvals are not reset unless the policy configuration includes the 'resetOnPush' property set to true; without it, existing approvals persist.

Page 5

Page 6 of 11

Page 7

All pages