Microsoft Azure DevOps Engineer Expert AZ-400 AZ-400 Questions 376–450 | Page 6/13

376

Multi-Selecteasy

Which THREE are common Git branching strategies used by development teams? (Select THREE.)

Select 3 answers

A.GitFlow

B.Trunk-based development

C.Feature branching

D.Monorepo

E.Centralized version control

AnswersA, B, C

GitFlow uses develop and feature branches.

Why this answer

GitFlow, Trunk-based development, and Feature branching are common strategies. Centralized version control is not a Git branching strategy. Monorepo is a repository structure, not a branching strategy.

Full explanation →

377

MCQhard

Your team is migrating from TFVC to Git in Azure Repos. Developers frequently work on the same files simultaneously. Which Git workflow should you recommend to minimize merge conflicts?

A.GitFlow

B.Forking workflow

C.Feature branch workflow

D.Centralized workflow

AnswerC

Short-lived feature branches merged frequently reduce conflicts.

Why this answer

The feature branch workflow is ideal for minimizing merge conflicts when developers work on the same files simultaneously because each developer creates a short-lived branch off the main branch for their specific feature or fix, commits frequently, and merges back via pull requests. This isolates changes until they are ready, reducing the surface area for conflicts compared to long-lived branches. Git's merge or rebase strategies within this workflow allow for incremental conflict resolution, which is more manageable than resolving large conflicts from divergent histories.

Exam trap

The trap here is that candidates often confuse GitFlow's structured branching model with being conflict-minimizing, when in fact its long-lived branches increase conflict risk, while the simpler feature branch workflow with frequent integration is more effective for simultaneous edits.

How to eliminate wrong answers

Option A is wrong because GitFlow introduces long-lived branches (develop, release, hotfix) that can diverge significantly, increasing the likelihood of merge conflicts when multiple developers work on the same files simultaneously. Option B is wrong because the forking workflow is designed for open-source contributions where contributors don't have direct repository access; it adds overhead of managing forks and cross-repo synchronization, which doesn't inherently minimize merge conflicts for a team with direct access. Option D is wrong because the centralized workflow mimics TFVC by having all developers commit directly to a single branch (e.g., main), which maximizes the chance of merge conflicts when multiple people edit the same files concurrently, as there is no isolation of changes.

Full explanation →

378

MCQhard

Refer to the exhibit. You are reviewing an Azure DevOps YAML pipeline. The pipeline is configured with a webhook trigger from GitHub for pull request opened events. However, the pipeline does not trigger when a PR is opened. What is the most likely cause?

A.The webhook subscription is not configured in GitHub.

B.The webhook name does not match the service connection.

C.The pipeline lacks an agent pool specification.

D.The webhook filter is incorrect; 'opened' should be 'created'.

AnswerA

The YAML defines the webhook, but GitHub needs to be configured to send events to Azure DevOps.

Why this answer

Option B is correct because the 'trigger' is set to 'none', which disables all triggers except the webhook? Actually, 'trigger: none' disables the CI trigger but does not affect resource triggers like webhooks? Wait, in Azure DevOps YAML, 'trigger: none' disables the CI trigger, but resource triggers (like webhooks) still work. However, the pipeline might not be set to use the correct webhook? Actually, the most likely cause is that the webhook is not properly configured in GitHub to send events to Azure DevOps. Option A (Incorrect filter) is possible but the filter looks correct.

Option C (Missing agent pool) would cause a runtime error. Option D (Webhook name mismatch) would cause connection issue but the exhibit shows 'GitHubPR' as name.

Full explanation →

379

MCQmedium

Your team uses GitHub. You need to automatically remove a user's access to all repositories when they leave the company. What is the most efficient approach?

A.Assign the user to a 'Leaver' team and remove all repository permissions

B.Manually remove the user from each repository

C.Configure SAML single sign-on (SSO) with Microsoft Entra ID

D.Enable SCIM provisioning from Microsoft Entra ID to GitHub

AnswerD

SCIM automatically provisions and deprovisions users based on Microsoft Entra ID group membership.

Why this answer

Option D is correct because linking GitHub to Microsoft Entra ID via SCIM automates deprovisioning. Option A is wrong because manual removal is not efficient. Option B is wrong because SAML SSO provides authentication but not automatic deprovisioning.

Option C is wrong because GitHub organization roles are not automatically updated.

Full explanation →

380

MCQhard

A company uses Azure Pipelines to build a .NET Core application. The build takes 45 minutes due to dependency restoration. They want to reduce build time. What is the most effective strategy?

A.Cache the NuGet packages and enable caching in the pipeline

B.Use parallel jobs in the pipeline

C.Use a self-hosted agent with more CPU

D.Enable incremental builds

AnswerA

Caching packages reduces the need to download them every build, significantly reducing build time.

Why this answer

Caching NuGet packages in Azure Pipelines is the most effective strategy because dependency restoration is the primary bottleneck, often downloading hundreds of packages from nuget.org. By caching the ~/.nuget/packages folder, subsequent builds skip the network download entirely, reducing the 45-minute build time to minutes. This directly addresses the root cause—repetitive package restoration—without requiring additional infrastructure or parallelism.

Exam trap

The trap here is that candidates confuse 'parallel jobs' or 'faster agents' with solving a network-bound dependency restoration problem, when caching is the only strategy that eliminates the repeated download of unchanged packages.

How to eliminate wrong answers

Option B is wrong because parallel jobs distribute work across multiple agents but do not eliminate the redundant dependency restoration step; each parallel job would still spend 45 minutes restoring packages independently. Option C is wrong because a self-hosted agent with more CPU does not address the network-bound dependency restoration; the bottleneck is I/O and network latency, not CPU. Option D is wrong because incremental builds only skip recompiling unchanged code, but dependency restoration is a separate step that runs before compilation; incremental builds do not cache NuGet packages.

Full explanation →

381

MCQhard

You are reviewing a branch protection rule JSON for a GitHub repository. Developers complain that they cannot merge pull requests. What is the most likely cause?

A.The signed commit requirement is enforced but developers are not signing commits.

B.The required approving review count is set to 1.

C.Rebase merging is disabled.

D.Squash merge is the only allowed method.

AnswerA

Unsigned commits will be rejected.

Why this answer

Option A is correct because when a branch protection rule requires signed commits, any pull request containing unsigned commits will be blocked from merging. GitHub verifies commit signatures using GPG or S/MIME, and if developers are not signing their commits, the merge will fail regardless of other settings.

Exam trap

The trap here is that candidates often confuse branch protection rules that block merging (like required signed commits or required status checks) with settings that merely affect merge options (like disabling rebase or restricting merge methods), leading them to incorrectly choose options that do not actually prevent merging.

How to eliminate wrong answers

Option B is wrong because a required approving review count of 1 is a common and valid setting that allows merging once at least one reviewer approves; it does not block merging by itself. Option C is wrong because disabling rebase merging only removes one merge method option but does not prevent merging via other allowed methods like merge commit or squash merge. Option D is wrong because restricting to squash merge only limits the merge strategy but still allows pull requests to be merged as long as other conditions (like reviews or status checks) are met.

Full explanation →

382

MCQeasy

You are implementing a CI pipeline for a Node.js application. The pipeline must run linting, unit tests, and build the application. Which YAML structure is most appropriate?

A.Define three separate stages: lint, test, build.

B.Define one job with parallel steps using 'parallel' keyword.

C.Define multiple jobs without dependencies.

D.Define one job with multiple steps: lint, test, build.

AnswerD

A single job with sequential steps is the simplest and fastest approach.

Why this answer

Option B is correct because jobs allow multiple steps to run sequentially on the same agent, which is efficient for linting, testing, and building. Option A uses stages but not necessary. Option C runs steps in parallel, which may cause conflicts.

Option D is not valid YAML for Azure Pipelines.

Full explanation →

383

MCQhard

Your Azure Pipeline builds a Docker image and pushes it to Azure Container Registry (ACR). You need to ensure that the image is scanned for vulnerabilities before being pushed. Which task should you add to the pipeline?

A.Azure CLI task to run 'az acr scan'

B.Docker task with the 'push' action

C.Container scanning task from Microsoft Defender for Cloud

D.PublishBuildArtifacts task

AnswerC

This task integrates vulnerability scanning for container images in ACR.

Why this answer

Option C is correct because the 'Container scanning' task (from Defender for Cloud) can scan images in ACR for vulnerabilities. Option A is wrong because the 'Docker' task only builds and pushes. Option B is wrong because 'Azure CLI' task can run commands but not built-in scanning.

Option D is wrong because 'PublishBuildArtifacts' publishes files, not scanning.

Full explanation →

384

MCQhard

Your organization uses GitHub for code and GitHub Actions for CI/CD. You want to enforce that all workflows include a 'codeql-analysis' job for security scanning. What is the best approach?

A.Create a workflow template and add it to the organization's workflow templates directory

B.Use branch protection rules to require a status check named 'codeql-analysis'

C.Create a custom GitHub Action that runs CodeQL and require it in all workflows

D.Use GitHub's required workflows feature to mandate specific workflows

AnswerD

Required workflows enforce that designated workflows are present in all repositories.

Why this answer

GitHub's required workflows feature allows organization owners to enforce that specific workflows (like a CodeQL analysis) run on all repositories in the organization, ensuring consistent security scanning without relying on templates or manual setup. This is the only approach that centrally mandates the workflow's presence and execution across all repositories, even if developers create new workflows or modify existing ones.

Exam trap

The trap here is that candidates often confuse 'workflow templates' (which are optional) with 'required workflows' (which are mandatory), or they mistakenly believe that branch protection rules can enforce the existence of a workflow job, when in fact they only enforce the outcome of a status check that may not even be configured.

How to eliminate wrong answers

Option A is wrong because workflow templates are optional starting points that developers can choose to use or ignore; they do not enforce that every repository includes the 'codeql-analysis' job. Option B is wrong because branch protection rules require a status check to pass on pull requests, but they do not ensure the workflow itself exists in the repository—developers could omit the CodeQL job entirely and the branch protection would have no effect. Option C is wrong because creating a custom GitHub Action does not enforce its inclusion in all workflows; developers would still need to manually add it to each workflow file, and there is no mechanism to require its use across the organization.

Full explanation →

385

MCQmedium

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

A.Trigger: none

B.trigger: branches: include: - main

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

D.pr: branches: include: - main

AnswerB

This triggers the pipeline on every commit to main.

Why this answer

Option B is correct because a branch-specific trigger on 'main' will automatically run the pipeline on each commit to that branch. Option A is wrong because a CI trigger on any branch would cause builds on feature branches as well. Option C is wrong because a scheduled trigger runs at specific times, not on commits.

Option D is wrong because PR triggers run on pull requests, not on commits to main.

Full explanation →

386

MCQhard

Your release pipeline deploys to Azure App Service using deployment slots. You need to ensure that traffic is gradually shifted to the new slot over 30 minutes, and if performance issues occur, it should automatically roll back. Which deployment strategy should you implement?

A.Use the 'Deploy to Azure App Service' task with the 'Deploy to Slot' option and configure auto-swap with monitoring.

B.Use two separate deployment slots (blue/green) and manually swap after validation.

C.Use a canary deployment with multiple slots and manual approval gate.

D.Use an A/B testing deployment by deploying to two different App Services and routing traffic via Traffic Manager.

AnswerA

Correct: Deployment slots support gradual traffic shift and auto-rollback via monitoring.

Why this answer

Option A is correct because the rolling deployment with traffic shifting and automatic rollback is best achieved using Azure App Service deployment slots with auto-swap and monitoring. Option B is wrong because blue-green with manual swap does not provide gradual traffic shift. Option C is wrong because canary with manual approval does not automate rollback.

Option D is wrong because A/B testing is not a native deployment strategy in Azure Pipelines.

Full explanation →

387

MCQeasy

You want to trigger a pipeline automatically when a new commit is pushed to the 'develop' branch of your repository. Which trigger configuration should you use in the YAML pipeline?

A.schedules: - cron: "0 0 * * *" branches: include: - develop

B.pr: branches: include: - develop

C.resources: repositories: - repository: self trigger: branches: include: - develop

D.trigger: branches: include: - develop

AnswerD

This triggers on pushes to develop.

Why this answer

Option A is correct because 'trigger: develop' triggers on pushes to the 'develop' branch. Option B is wrong because 'pr: develop' triggers on pull requests. Option C is wrong because 'schedules' is for cron triggers.

Option D is wrong because 'resources' is for pipeline resources.

Full explanation →

388

MCQhard

Your organization has a multi-stage YAML pipeline that builds and deploys a containerized application to Azure Kubernetes Service (AKS). The pipeline uses environment approvals for the production stage. You need to ensure that the container image deployed to production is the same as the one that passed all previous stages. Which strategy should you implement?

A.Publish the container image as a pipeline artifact and reference it from each stage.

B.Use the same image tag in all stages, updating the tag as needed.

C.Enable immutable tags on the container registry to prevent overwrites.

D.Rebuild the container image in each stage to ensure freshness.

AnswerA

Pipeline artifacts are immutable and ensure the same image is used across stages.

Why this answer

Option C is correct because using a pipeline artifact (like the pipeline artifact published during the build stage) ensures the exact same image is used in all stages, preventing rebuilds and ensuring consistency. Option A is wrong because rebuilding in each stage can introduce variations. Option B is wrong because tags can be overwritten.

Option D is wrong because container registries do not enforce immutability by default.

Full explanation →

389

MCQhard

Refer to the exhibit. You queue a build in Azure Pipelines. The build status remains 'notStarted' for an extended period. What is the most likely reason?

A.The build priority is set to normal, causing delay.

B.The build is waiting for an available agent that meets the demands.

C.The build definition has a syntax error in the YAML file.

D.The build definition is not authorized to use the Azure Pipelines pool.

AnswerB

Correct. The demands require a Linux agent with Agent.Version > 2.170.1. If no hosted agent matches, the build waits indefinitely.

Why this answer

The build demands specify 'Agent.OS -equals Linux' and 'Agent.Version -gtVersion 2.170.1'. If no agent in the Azure Pipelines pool satisfies these demands, the build will remain queued until an appropriate agent becomes available.

Full explanation →

390

Multi-Selecthard

Which THREE practices are recommended when implementing a Git branching strategy for a team using Azure Repos?

Select 3 answers

A.Delete branches after they are merged.

B.Allow force pushes to shared branches to clean up history.

C.Use short-lived feature branches that are merged within a day.

D.Keep feature branches alive for the entire sprint.

E.Require build validation on pull requests to the main branch.

AnswersA, C, E

Keeps repository clean and avoids confusion.

Why this answer

Options A, B, and D are correct. A: Short-lived branches reduce merge conflicts. B: Build validation in branch policies ensures quality.

D: Deleting branches after merge keeps repository clean. C is wrong because long-lived feature branches increase complexity. E is wrong because force pushing can rewrite history and disrupt collaboration.

Full explanation →

391

MCQmedium

Your organization uses GitHub Copilot for pull request summaries. However, some developers report that the summaries are inaccurate. What should you do to improve the quality of Copilot-generated pull request summaries?

A.Encourage developers to write more detailed commit messages.

B.Ask developers to write clear, structured PR titles and descriptions.

C.Disable Copilot for pull requests and use manual summaries.

D.Provide a link to a documentation wiki in the PR description.

AnswerB

Better input leads to better Copilot output.

Why this answer

Option B is correct because GitHub Copilot for pull request summaries relies on the PR title and description as primary input to generate accurate summaries. Clear, structured titles and descriptions provide better context for the AI model, reducing ambiguity and improving summary quality. Detailed commit messages (Option A) are not directly used by Copilot for PR summaries, as it focuses on the PR-level metadata.

Exam trap

The trap here is that candidates may overestimate the role of commit messages (Option A) in Copilot's PR summary generation, when in fact the model primarily uses the PR title and description, not the commit history, to produce the summary.

How to eliminate wrong answers

Option A is wrong because commit messages are not the primary input for Copilot's PR summary generation; the model uses the PR title and description, not individual commit messages, to synthesize a summary. Option C is wrong because disabling Copilot is a reactive measure that avoids the problem rather than addressing the root cause of inaccurate summaries, and manual summaries are less efficient. Option D is wrong because providing a documentation wiki link in the PR description does not directly improve the quality of Copilot-generated summaries; the model does not parse external links for content, and the summary is based on the text within the PR title and description itself.

Full explanation →

392

Multi-Selectmedium

Which THREE of the following are valid deployment strategies that can be implemented using Azure DevOps release pipelines? (Select THREE.)

Select 3 answers

A.Red-black deployment.

B.Rolling deployment.

C.Blue-green deployment.

D.Canary deployment.

E.Linear deployment.

AnswersB, C, D

Rolling deployment replaces instances incrementally.

Why this answer

Options A, B, and E are correct. A: Rolling deployment updates instances gradually. B: Blue-green deployment uses two environments for switching traffic.

E: Canary deployment releases to a subset before full rollout. C is incorrect because 'red-black' is not a standard term. D is incorrect because 'linear deployment' is not a recognized strategy.

Full explanation →

393

MCQeasy

Your release pipeline includes a 'Deploy to App Service' task for a Linux web app. The deployment fails with 'Error: Failed to deploy web package to App Service'. What should you check first?

A.Verify that the deployment slot is correctly configured.

B.Check the Kudu console for errors.

C.Ensure the web.config file is present.

D.Review the App Service diagnostic logs.

AnswerD

Diagnostic logs contain detailed deployment errors.

Why this answer

Option B is correct because App Service logs provide detailed error messages. Option A is wrong because Kudu is for Windows apps, not Linux. Option C is wrong because deployment slots are optional.

Option D is wrong because the web.config is for IIS, not Linux.

Full explanation →

394

MCQeasy

You need to run unit tests in your build pipeline and publish the test results to Azure Pipelines. Which task should you use?

A.DotNetCoreCLI task with test command

B.Npm task

C.Publish Test Results task

D.Visual Studio Test task

AnswerC

Publishes test results in formats like TRX, JUnit.

Why this answer

Option B is correct because the 'Publish Test Results' task publishes test results to Azure Pipelines. Option A is wrong because 'Visual Studio Test' runs tests but does not publish to the pipeline. Option C is wrong because 'DotNetCoreCLI' can run tests but needs an additional task to publish results.

Option D is wrong because 'Npm' is for Node.js, not .NET tests.

Full explanation →

395

MCQmedium

You receive a webhook notification from Azure Pipelines with the above payload. The build for the 'feature/logging' branch failed. You want to automatically create a work item to track the fix. What should you configure in Azure DevOps?

A.Add a branch policy on 'feature/logging' to require a successful build before merging.

B.Enable the 'Create work item on failure' option in the pipeline settings.

C.Use a GitHub Actions workflow to create an issue on failure.

D.Create a service hook subscription to listen for build failures and call Azure Boards API.

AnswerB

Automatically creates a work item when a build fails.

Why this answer

Option B is correct because Azure Pipelines provides a built-in setting called 'Create work item on failure' that automatically generates a work item (e.g., a bug or task) in Azure Boards whenever a pipeline run fails. This directly meets the requirement to track the fix for the failed build on the 'feature/logging' branch without requiring external integrations or manual steps.

Exam trap

The trap here is that candidates may overcomplicate the solution by choosing a manual or external integration (like service hooks or GitHub Actions) when Azure Pipelines already provides a simple, built-in configuration option for automatic work item creation on failure.

How to eliminate wrong answers

Option A is wrong because adding a branch policy to require a successful build before merging is a preventative measure that blocks merging if the build fails, but it does not automatically create a work item to track the fix. Option C is wrong because the scenario uses Azure Pipelines, not GitHub Actions; while a GitHub Actions workflow could create an issue, it is not applicable to an Azure Pipelines webhook notification. Option D is wrong because creating a service hook subscription to listen for build failures and call the Azure Boards API is a valid but unnecessarily complex approach; the built-in 'Create work item on failure' option achieves the same result with less configuration and is the recommended method.

Full explanation →

396

MCQmedium

Your team uses GitHub Enterprise and GitHub Actions for CI/CD. You need to implement a security compliance plan. The organization has the following requirements: 1) All code pushed to the main branch must be scanned for secrets and vulnerabilities. 2) Developers must use signed commits. 3) Only approved GitHub Actions can be used. 4) Dependencies must be scanned for vulnerabilities. You have enabled secret scanning and code scanning (CodeQL) on all repositories. You have configured branch protection rules to require signed commits using GPG keys. To restrict actions, you have set an allowed list of actions in the organization settings. You have enabled Dependabot alerts. However, during an audit, a reviewer notes that secret scanning alerts are not being reviewed within 30 days. You need to ensure that secret scanning alerts are triaged within 30 days. What should you do?

A.Assign secret scanning alerts to the security team using the 'Assign to' feature in the alerts view.

B.Set up a webhook to send secret scanning alerts to a security team's email.

C.Disable secret scanning on repositories that do not contain secrets.

D.Configure secret scanning to automatically close alerts after 30 days.

AnswerA

Assignment ensures ownership and tracking of triage.

Why this answer

Option D is correct because GitHub secret scanning alerts can be assigned to specific teams for triage, ensuring accountability. Option A is wrong because auto-closing alerts may miss genuine secrets. Option B is wrong because disabling secret scanning is counterproductive.

Option C is wrong because webhooks are for notifications, not triage assurance.

Full explanation →

397

MCQhard

You are a DevOps engineer at a healthcare company that must comply with HIPAA. The company uses Azure DevOps with YAML pipelines to deploy a multi-tier application to Azure Kubernetes Service (AKS). The application stores sensitive patient data. The security team requires that all secrets (e.g., database passwords, API keys) must be stored in Azure Key Vault and never hardcoded in the pipeline. The pipeline currently uses a service principal (SP1) for AKS deployments. The pipeline has a variable group 'VG-Prod' linked to Key Vault 'KV-Prod' with secrets: 'DbPassword', 'ApiKey'. The pipeline runs successfully in non-production environments. However, when you run the pipeline for production, it fails at the stage that deploys to AKS with the error: 'Error: failed to get secret 'DbPassword' from Key Vault: Forbidden'. You have verified that the secret exists and the variable group is correctly linked. The service principal SP1 has the 'Get' and 'List' permissions on KV-Prod secrets. The AKS cluster is in a different subscription than the Key Vault. What is the most likely cause and how should you fix it?

A.The variable group VG-Prod is not properly linked to KV-Prod; re-link it.

B.The build service identity does not have 'Get' and 'List' permissions on KV-Prod; add the build service identity to the Key Vault access policy.

C.The secret 'DbPassword' does not exist in KV-Prod; create it.

D.The service principal SP1 does not have 'Get' and 'List' permissions on KV-Prod; add them.

AnswerB

The build service identity (e.g., 'Project Collection Build Service') needs access to Key Vault for variable group resolution.

Why this answer

The pipeline fails because the build service identity (the Azure DevOps agent's identity) lacks 'Get' and 'List' permissions on KV-Prod. Even though the variable group is linked to Key Vault, the pipeline's build service identity must be explicitly granted access to the Key Vault's access policy to retrieve secrets. The service principal SP1 is used for AKS deployments, not for Key Vault secret retrieval; the variable group resolution uses the build service identity, not SP1.

Exam trap

The trap here is that candidates often assume the service principal used for AKS deployments (SP1) is also used for Key Vault secret retrieval, but Azure DevOps uses the build service identity for variable group resolution, requiring separate permissions on the Key Vault.

How to eliminate wrong answers

Option A is wrong because the variable group is correctly linked (the pipeline runs in non-production, and the error is 'Forbidden', not 'not found' or 'misconfigured link'). Option C is wrong because the secret 'DbPassword' exists (verified in the scenario) and the error is an authorization failure, not a missing secret. Option D is wrong because SP1 is the service principal for AKS deployments, not for Key Vault access; the build service identity is the one that needs permissions on KV-Prod to resolve secrets in the variable group.

Full explanation →

398

MCQmedium

A team uses Azure Repos with a Git branching strategy that includes feature branches. They want to ensure that all feature branches are deleted automatically after the pull request is completed. What should they do?

A.Enable 'Automatically delete source branch' in the branch policy.

B.Enable 'Create a merge commit' option in the branch policy.

C.Configure branch retention policy in the pipeline to delete branches after build.

D.Create a work item to remind developers to delete branches after merge.

AnswerA

This deletes the source branch after the PR is completed.

Why this answer

Option A is correct because Azure Repos branch policies include an 'Automatically delete source branch' checkbox. When enabled, the source branch (e.g., a feature branch) is automatically deleted once the pull request is completed (merged or abandoned). This enforces cleanup without manual intervention, directly meeting the requirement.

Exam trap

The trap here is that candidates may confuse pipeline retention policies (which manage build artifacts) with Git branch management, or assume that a manual work item is sufficient for automation, when Azure Repos provides a direct built-in setting for automatic branch deletion.

How to eliminate wrong answers

Option B is wrong because 'Create a merge commit' is a merge type setting that controls how commits are integrated, not a branch deletion mechanism. Option C is wrong because branch retention policies in Azure Pipelines control how long pipeline runs and artifacts are kept, not the deletion of Git branches in Azure Repos. Option D is wrong because creating a work item is a manual process that relies on developer discipline, not an automated enforcement mechanism.

Full explanation →

399

MCQhard

You have a pipeline with the above YAML trigger configuration. A developer pushes changes to a file in 'src/app/config.json' on a branch named 'release/v1'. Which statement is true about the build trigger?

A.The build will be triggered but only if no other builds are running.

B.The build will be triggered.

C.The build will not be triggered because the path filter is too restrictive.

D.The build will not be triggered because the branch is not 'main'.

AnswerB

Both branch and path conditions are satisfied.

Why this answer

Option A is correct because the branch 'release/v1' matches the include pattern 'release/*' and the file path is under 'src/app/'. Option B is wrong because the branch is included. Option C is wrong because the path is included.

Option D is wrong because the trigger will execute.

Full explanation →

400

Multi-Selectmedium

A development team is configuring a YAML-based pipeline in Azure Pipelines. The pipeline must meet the following requirements: - Build only the main branch. - Run integration tests after a successful build. - Deploy to a staging environment only if tests pass. - Handle failures gracefully by sending a notification to the team. You need to define the pipeline structure. Which TWO configurations should you include?

Select 2 answers

A.Use a `deployment: Staging` job with `displayName: Deploy to staging`.

B.Define a stage for 'Deploy' with `dependsOn: Test` and `condition: succeeded('Test')`.

C.Set `trigger: main` at the pipeline root.

D.Add `condition: succeeded()` to the build job.

E.Define the trigger in the `resources` section using `pipelines`.

AnswersB, C

This ensures deployment only runs after the Test stage succeeds.

Why this answer

Option B is correct because it defines a 'Deploy' stage that depends on the 'Test' stage and uses `condition: succeeded('Test')` to ensure deployment only occurs after tests pass. This satisfies the requirement to deploy to staging only if tests succeed. Option C is correct because `trigger: main` at the pipeline root configures the pipeline to build only the main branch, meeting the first requirement.

Exam trap

The trap here is that candidates may confuse the `deployment` job keyword (which defines a deployment job but does not enforce stage dependencies) with the stage-level `dependsOn` and `condition` needed to gate deployment on test success, or they may mistakenly place the branch trigger in the `resources` section instead of the root `trigger`.

Full explanation →

401

MCQeasy

You need to integrate Azure Pipelines with GitHub to trigger a build when a release is published in GitHub. Which trigger type should you use in the pipeline?

A.pr:

B.trigger:

C.resources: repositories: - repository: self type: github trigger: release: true

D.schedules:

AnswerC

Correct: resources with release trigger.

Why this answer

Option C is correct because Azure Pipelines supports a GitHub release trigger through the `resources` definition, where you specify a `trigger` with `release: true` under the repository configuration. This tells the pipeline to automatically start a build whenever a new release is published in the linked GitHub repository, which directly matches the requirement.

Exam trap

The trap here is that candidates often confuse the `trigger:` keyword (which handles CI branch triggers) with the release trigger syntax, or mistakenly think a simple `trigger:` can be configured to listen for GitHub release events, when in fact it requires the nested `resources` structure with `release: true`.

How to eliminate wrong answers

Option A is wrong because `pr:` is used to trigger builds on pull request events, not on release publications. Option B is wrong because `trigger:` at the pipeline root configures CI triggers for branch pushes or path filters, not for GitHub release events. Option D is wrong because `schedules:` defines cron-based scheduled triggers, which are time-driven and unrelated to GitHub release events.

Full explanation →

402

MCQhard

Your organization uses GitHub Enterprise and requires that all commits to the main branch are signed with a GPG key verified by your organization. Developers are getting errors when pushing signed commits. What is the most likely cause?

A.The branch protection rule requires a linear history.

B.The developer's GPG key is not uploaded to their GitHub account or not verified.

C.The developer's email in the commit does not match any email on their GitHub account.

D.The developer's SSH key is not added to their GitHub account.

AnswerB

The key must be uploaded and verified for GitHub to recognize the signature.

Why this answer

Option B is correct because GitHub requires that the GPG key used to sign a commit be uploaded to the user's GitHub account and marked as verified. If the key is missing or unverified, GitHub cannot confirm the signature's authenticity, causing the push to be rejected when branch protection rules enforce signed commits.

Exam trap

The trap here is that candidates often confuse authentication (SSH keys) with signing (GPG keys) or assume email mismatch is the primary cause, when in fact the core issue is the absence or unverified status of the GPG key itself.

How to eliminate wrong answers

Option A is wrong because a linear history requirement (e.g., via squash merging or rebase-only) does not affect GPG signature verification; it controls commit topology, not signing. Option C is wrong because while the commit email must match a verified email on the GitHub account for the signature to be associated, the error described is specifically about GPG key verification, not email mismatch—GitHub will still accept the signed commit if the key is valid, but the commit may show as 'unverified' if the email doesn't match. Option D is wrong because SSH keys are used for authentication (proving identity to GitHub), not for signing commits; GPG keys are used for signing, and SSH keys have no role in commit signature verification.

Full explanation →

403

MCQhard

Your release pipeline deploys to Azure App Service using slots. You need to ensure that after swapping, the warmup request is sent to the production slot before traffic is fully routed. What should you configure?

A.Enable auto swap for the deployment slot and configure a custom warmup path.

B.Add a health check to the App Service.

C.Perform a manual swap and then send a warmup request via a script.

D.Configure slot-specific app settings to enable warmup.

AnswerA

Auto swap with warmup sends request to slot before swap.

Why this answer

Option B is correct because auto swap with custom warmup triggers a warmup request to the target slot before swap completes. Option A is wrong because manual swap does not have warmup. Option C is wrong because deployment slot settings are sticky and not swapped.

Option D is wrong because health check is different from warmup.

Full explanation →

404

Multi-Selectmedium

Your organization uses Azure Pipelines to deploy a web application to multiple Azure App Service instances across regions. You need to implement a deployment strategy that allows rolling back to the previous version quickly if issues are detected. Which TWO strategies should you recommend?

Select 2 answers

A.Use a rolling update with incremental deployment.

B.Implement a canary deployment with traffic splitting.

C.Store previous deployment artifacts in Azure Blob Storage.

D.Use blue-green deployment with a traffic manager endpoint.

E.Deploy to a staging slot and then swap with production.

AnswersD, E

Blue-green allows switching traffic back to the previous environment.

Why this answer

Option A and Option D are correct. Slot swap allows swapping back to the previous slot. Blue-green deployment with a traffic manager allows switching traffic.

Option B is wrong because redeployment takes time. Option C is wrong because canary is for gradual rollout, not instant rollback. Option E is wrong because it doesn't address rollback.

Full explanation →

405

Multi-Selecthard

A company is designing an Azure DevOps strategy for a microservices application. They need to ensure that each microservice can be built, tested, and deployed independently. They also want to reuse pipeline components across services. Which TWO practices should they implement?

Select 2 answers

A.Publish all microservice artifacts to the same Azure Artifacts feed.

B.Store all pipeline variables in a single variable group.

C.Create a single pipeline that handles all microservices.

D.Use pipeline templates to define common build and test steps.

E.Use multi-stage YAML pipelines with separate pipeline definitions per microservice.

AnswersD, E

Templates promote reuse and consistency.

Why this answer

Option D is correct because pipeline templates in Azure DevOps allow you to define reusable YAML snippets for common build and test steps, enabling consistency across microservices without duplicating code. Option E is correct because multi-stage YAML pipelines with separate definitions per microservice ensure each service can be built, tested, and deployed independently, aligning with microservices architecture principles.

Exam trap

The trap here is that candidates often confuse reusing pipeline components (templates) with centralizing everything (single pipeline or single variable group), missing that independent deployment requires separate pipeline definitions per microservice.

Full explanation →

406

MCQeasy

Refer to the exhibit. The pipeline uses a variable group 'ReleaseVariables' that contains a variable named 'EnvironmentName' with value 'Staging'. What environment will the deployment target?

A.Staging

B.VirtualMachine

C.Production

D.DeployWeb

AnswerC

The pipeline variable 'EnvironmentName' value 'Production' overrides the group.

Why this answer

Variable groups are evaluated first, but in YAML, variables defined later override the group if the same name is used. Here, EnvironmentName is defined in the variable group and then redefined with value 'Production' in the pipeline variables. The pipeline variable overrides the variable group.

So the environment name is 'Production'. Option B is correct.

Full explanation →

407

MCQhard

You are designing a multi-stage YAML pipeline in Azure DevOps that builds, tests, and deploys a .NET Core application. The pipeline must use a self-hosted agent pool for compliance. You need to minimize agent idle time while ensuring that the agent is always available for builds. What should you do?

A.Provision a virtual machine scale set with a fixed number of agents

B.Install multiple agents on a single VM to maximize utilization

C.Deploy a scale set agent pool with autoscaling enabled

D.Use a single persistent agent and queue builds when idle

AnswerC

Autoscaling adds or removes agents based on demand.

Why this answer

Option D is correct because scaling set with autoscaling adjusts capacity based on demand. Option A is wrong because scaling set without autoscaling does not minimize idle time. Option B is wrong because persistent agents are always running, causing idle time.

Option C is wrong because multiple agents still run idle if not scaled.

Full explanation →

408

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

Option B is correct because 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.

Full explanation →

409

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 allow merging incomplete features safely.

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.

Full explanation →

410

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

Option A is correct because 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.

Full explanation →

411

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

Correct answers: C and D. C: approvals are configured on environments. D: deployment jobs must reference environments.

A is wrong because YAML pipelines don't require classic release. B is wrong because approvals don't require a separate release pipeline.

Full explanation →

412

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

Option B is correct because 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.

Full explanation →

413

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

This triggers on PRs targeting the release branch.

Why this answer

Option D is correct because the `pull_request` trigger fires when a pull request is opened, and the `branches: [release]` filter restricts it to PRs targeting the `release` branch. This matches the developer's requirement exactly: automatically trigger a workflow when a PR is opened against `release`.

Exam trap

The trap here is confusing `pull_request` with `pull_request_target` or `push`, where candidates mistakenly think a push to the branch or a fork-safe trigger is needed, but the question explicitly asks for a trigger when a pull request is opened, not when code is pushed.

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.

Full explanation →

414

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

These tools are designed to preserve full history, attachments, and links.

Why this answer

Option C is correct because 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.

Full explanation →

415

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

Secret variables are masked in logs.

Why this answer

Option A is correct because Azure Pipelines allows you to mark variables as 'secret' by using the 'secret' input type in the pipeline settings UI or by setting `isSecret: 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.

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.

Full explanation →

416

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

Default Build.BuildNumber is date-based (yyyymmdd.r).

Why this answer

The counter expression starts at the seed value (0) and increments by 1 each run. On the first run, the counter returns 0, so revision is 0. Build.BuildNumber is not explicitly set, so it defaults to the date-based format (e.g., 20250101.1) unless redefined.

However, the counter is used as a variable, not assigned to Build.BuildNumber. So the script echoes the default Build.BuildNumber, not the counter. But the question asks for the value of $(Build.BuildNumber).

The default Build.BuildNumber is the date-time based number (like 20250101.1). Option D is correct.

Full explanation →

417

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 triggers when an issue is closed, and the action can fetch the closing PR author.

Why this answer

Option D is correct because the 'issues' event with 'closed' type can trigger a workflow that uses the 'actions-ecosystem/action-add-assignees' action to assign the issue to the PR author. Option A is incorrect because 'pull_request' events do not directly close issues. Option B is incorrect because 'push' events are not related to issue closure.

Option C is incorrect because 'schedule' events are time-based.

Full explanation →

418

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 true, all changes within the same commit are batched into one build. Since there is an included change, the build triggers once.

Why this answer

The trigger includes '/src/*' and excludes '/src/tests/*'. The commit modifies files in both included and excluded paths. Because batchChanges is true, only one build will be queued for the batch.

However, since the commit includes changes to an included path ('/src/app/'), the build will trigger. The excluded path does not prevent the build because there is at least one included change. Thus, only one build will be triggered.

Full explanation →

419

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 enforces work item association.

Why this answer

Option B is correct because 'Require linked work items' enforces that each commit or PR has a work item. Option A is wrong because it only requires comments. Option C is wrong because it only checks build status.

Option D is wrong because it limits who can push, not work item linking.

Full explanation →

420

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

uniqueString generates a deterministic hash, not a descriptive name.

Why this answer

Option C is correct. The 'uniqueString(resourceGroup().id)' function generates a hash based on the resource group ID, not the storage account name parameter. The default value is a hash, not a human-readable name.

Option A is incorrect because the parameter type is string. Option B is incorrect because the default value uses resourceGroup().id, not resourceGroup().location. Option D is not relevant.

Full explanation →

421

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 demand requires a newer agent version not present in the pool.

Why this answer

The demand specifies an agent version greater than 2.200.0, but pool agents are older. Option B is wrong because agentless jobs don't use agents. Option C is wrong because demands are not a syntax error.

Option D is wrong because demands are for selecting agents, not for the pipeline itself.

Full explanation →

422

Multi-Selecthard

Which THREE are best practices for managing secrets in GitHub Actions workflows?

Select 3 answers

A.Pass secrets as environment variables to actions.

B.Use environment secrets to restrict access to specific workflows.

C.Store the same secret in multiple repositories for consistency.

D.Enable secret scanning and push protection in the repository settings.

E.Store secrets as GitHub Actions secrets instead of hardcoding them in the workflow file.

AnswersB, D, E

Environment secrets allow granular control.

Why this answer

Option A is correct because secrets should be stored as Actions secrets, not in YAML. Option B is correct because access can be limited to specific workflows. Option C is correct because secrets should be masked in logs.

Option D is wrong because secrets should not be shared across repositories unless necessary. Option E is wrong because environment variables are visible in logs.

Full explanation →

423

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.

Full explanation →

424

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 (part of GitHub Advanced Security) detects secrets in PRs and can block them.

Why this answer

Option D (Secret Scanning) is correct because GitHub Advanced Security (GHAS) provides secret scanning that can be configured to run on pull requests and block PRs containing secrets. Option A (Azure Policy) is for Azure resource compliance, not code-level scanning. Option B (Credential Scanner) is a legacy tool that is not directly integrated into PR gates.

Option C (Dependency Scanning) identifies vulnerable dependencies, not secrets.

Full explanation →

425

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

Option B is correct because 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.

Full explanation →

426

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 task retrieves secrets and makes them available.

Why this answer

Options A and C are correct. A: The pipeline must have access to the Key Vault via a service connection with Get and List permissions. C: The pipeline can use the 'Azure Key Vault' task to download secrets as pipeline variables, or reference them via variable groups linked to Key Vault.

Option B is wrong because secrets are not passed as environment variables by default. Option D is wrong because secrets are not exposed in logs by default; masking is automatic. Option E is wrong because the secret identifier can be used directly.

Full explanation →

427

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 leverages existing pipelines and minimizes changes.

Why this answer

Option B is correct: Adding a Docker task to build and push, and a Kubernetes task to deploy, minimizes changes. Option A is incorrect because creating a new pipeline from scratch is unnecessary. Option C is incorrect because using a script to build Docker is less integrated.

Option D is incorrect because self-hosted agents are not required for ACR and AKS.

Full explanation →

428

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

This task publishes files as build artifacts.

Why this answer

Option A is correct because the Publish Build Artifacts task publishes files as pipeline artifacts. Option B is wrong because the Copy Files task only copies files within the agent. Option C is wrong because the Maven task builds the project but does not publish artifacts.

Option D is wrong because the Archive Files task creates a zip but does not publish.

Full explanation →

429

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

Option B is correct because a build completion trigger starts the release pipeline when a build artifact is available, ensuring the same artifact is used across environments. Option A is wrong because a CI trigger starts a new build, not a release. Option C is wrong because a scheduled trigger runs at specific times, not tied to a build.

Option D is wrong because a pull request trigger starts builds for PRs, not releases.

Full explanation →

430

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

This will fail the PR check when a secret is detected.

Why this answer

Option A is correct because 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.

Full explanation →

431

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 event name is 'pull_request', so the condition is true.

Why this answer

The condition checks if github.event_name equals 'pull_request', which is true, so it prints 'Running PR tests'. Option A is wrong because the main branch push would not trigger on PR. Option B is wrong because the event is indeed pull_request.

Option D is wrong because the condition is correct.

Full explanation →

432

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

Work item rules enforce conditions on state transitions.

Why this answer

Option A is correct because 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.

Full explanation →

433

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

Why this answer

Option B is correct because 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

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

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

Branch policies are for pull requests, not pipeline stages.

Full explanation →

434

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

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

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

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

NuGetAuthenticate is for authentication, not restoring packages.

Full explanation →

435

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

Branch policies can require linked work items and automatically transition their state when a pull request is merged.

Why this answer

Option B is correct because 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.

Full explanation →

436

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 agent needs NuGet.exe or dotnet CLI to restore packages.

Why this answer

Option A is correct because the self-hosted agent needs network access to the NuGet feed. Option D is correct because the NuGet tool must be installed on the agent. Options B, C, and E are not required.

Full explanation →

437

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

GitHub automatically masks secret values in logs.

Why this answer

Option B is correct because GitHub automatically masks secrets when used in workflows. Option A is wrong because logging to a file still exposes the secret in the log. Option C is wrong because runner logs are stored and could be accessed.

Option D is wrong because encryption does not prevent exposure if the secret is printed.

Full explanation →

438

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

'az bicep build' validates Bicep syntax.

Why this answer

AzureCLI task can run 'az bicep build' to validate syntax. Option A is wrong because ARM template deployment task deploys, not validates. Option B is wrong because PowerShell task would need manual parsing.

Option D is wrong because Bicep is not directly supported by Terraform tasks.

Full explanation →

439

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

Option A is correct because 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.

Full explanation →

440

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

This restricts workflows to only approved actions.

Why this answer

Option D is correct because GitHub's 'Actions allowed list' restricts workflows to approved actions only. Option A is wrong because branch protection rules apply to branches, not actions. Option B is wrong because OIDC is for authentication.

Option C is wrong because Dependabot is for dependency updates.

Full explanation →

441

Drag & Dropmedium

Drag and drop the steps to configure a static route on a Cisco IOS router into the correct order.

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

Steps

Order

Why this order

Static routes require global config mode and must specify the destination network, subnet mask, and next-hop address or exit interface.

Full explanation →

442

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

Scheduled workflows can run at a specified time using cron syntax.

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.

Full explanation →

443

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

Path filters ensure only affected services are built and tested.

Why this answer

Option C is correct: GitHub Actions path filters trigger workflows only when files in specific paths change. Option A is incorrect because building all services every time is wasteful. Option B is incorrect because a single workflow for all services would be monolithic and hard to maintain.

Option D is incorrect because manual triggering defeats automation.

Full explanation →

444

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

Audit logging provides a record of user and service actions.

Why this answer

Options A and B are correct. A: Azure DevOps audit logs track user actions. B: Azure Monitor logs can be used to store and analyze audit data.

Option C is wrong because secret rotation is not logging. Option D is wrong because network security groups are for network traffic, not audit logs. Option E is wrong because service principals are for authentication, not logging.

Full explanation →

445

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. Match each task with its appropriate placement in the pipeline order. The tasks are: 'Visual Studio Test', 'Publish Code Coverage Results', 'Visual Studio Build'. The correct order is: 1. Build, 2. Test, 3. Publish coverage.

A.Visual Studio Build

B.Visual Studio Test

C.Publish Code Coverage Results

Why this answer

The correct order is: first build the code using 'Visual Studio Build', then run tests using 'Visual Studio Test', and finally publish code coverage results using 'Publish Code Coverage Results'. This ensures that the code is compiled before testing, and coverage results are available after tests run.

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.

Full explanation →

446

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 replaces large files with pointers, keeping the repo lean.

Why this answer

Option B is correct because 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.

Full explanation →

447

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

Email mismatch causes unverified signature.

Why this answer

Option B is correct because GitHub requires the commit to be signed with the GPG key associated with the committer's email. If the email in the git config doesn't match the one in GitHub, the signature is considered unverified. Option A is wrong because SSH keys are not used for commit signing.

Option C is wrong because GitHub supports GPG signing. Option D is wrong because the key is already associated.

Full explanation →

448

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

Image signing ensures that the image has not been tampered with.

Why this answer

Options A and D are correct. Option A: Scanning images for vulnerabilities as part of the build process helps catch issues early. Option D: Using signed images ensures integrity and trust.

Option B is wrong because using the 'latest' tag can lead to unpredictable updates; pinning to specific versions is more secure. Option C is wrong because storing images in a public registry exposes them to potential attacks; private registries are more secure. Option E is wrong because running containers as root is a security risk.

Full explanation →

449

MCQeasy

Your team uses Azure Repos and wants to enforce that every commit message includes a work item ID. Which policy should you configure?

A.Repository settings to restrict file paths.

B.Branch policy to require a minimum comment length.

C.Branch policy to require linked work items.

D.Pre-push Git hook.

AnswerC

This policy ensures pull requests link to work items.

Why this answer

Option C is correct because Azure Repos branch policies include a 'Require linked work items' setting that enforces every commit in a pull request to be associated with a work item. This ensures commit messages reference a work item ID, as the policy blocks pull requests without linked work items, directly meeting the requirement.

Exam trap

The trap here is that candidates confuse client-side Git hooks (like pre-push) with server-side branch policies, assuming hooks can enforce requirements centrally, but hooks are optional and can be skipped by developers using --no-verify.

How to eliminate wrong answers

Option A is wrong because restricting file paths controls which files can be changed in a branch, not commit message content or work item linking. Option B is wrong because requiring a minimum comment length only enforces a character count in commit messages, not the presence of a work item ID. Option D is wrong because a pre-push Git hook is a client-side script that can be bypassed by developers and is not centrally enforced via Azure Repos policies.

Full explanation →

450

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 action can automatically generate release notes from merged pull requests.

Why this answer

Option A is correct: The 'softprops/action-gh-release' action creates releases and can generate release notes from merged PRs. Option B is incorrect because tagging manually is not automated. Option C is incorrect because releases are not created by default on tag push.

Option D is incorrect because the 'Create a release' step alone does not generate release notes from merged PRs.

Full explanation →

Microsoft Azure DevOps Engineer Expert AZ-400 (AZ-400) — Questions 376–450