Courseiva

Microsoft Azure DevOps Engineer Expert AZ-400 (AZ-400) — Questions 751–823

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

Take a mock examExam hub
Page 10

Page 11 of 11

751
MCQmedium

Your organization uses GitHub Actions for CI/CD. You have a workflow that deploys to Azure App Service. The deployment uses a publish profile secret stored as a GitHub secret. You want to improve security by using OpenID Connect (OIDC) to authenticate to Azure without storing secrets. What should you do?

A.Remove the secret and use Azure AD Managed Identity directly from the GitHub runner.
B.Configure the GitHub workflow to use the 'azure/login' action with OIDC, and set up a federated identity credential in Microsoft Entra ID for the GitHub environment.
C.Replace the publish profile secret with an Azure service principal secret stored as a GitHub secret.
D.Use the 'Azure App Service Deploy' task with the 'Publish Profile' parameter set to an empty string.
AnswerB

The 'azure/login' action with OIDC exchanges GitHub's OIDC token for an Azure AD access token by using a federated identity credential configured in Microsoft Entra ID for the GitHub environment. You create the credential with the correct subject identifier (e.g., repo:owner/repo:environment:prod) so that GitHub's token is trusted, and the action automatically retrieves the token without requiring a client secret. This eliminates long-lived secrets, enables automatic token rotation, and is the recommended secure pattern for GitHub Actions to Azure deployments.

Why this answer

Configuring OIDC with Microsoft Entra ID (formerly Azure AD) using a federated identity credential for the GitHub environment allows token-based authentication without storing secrets. Option A is incorrect because Azure Managed Identity cannot be used directly from a GitHub runner; Managed Identity is designed for Azure-hosted resources, not external runners. Option C is incorrect because replacing the publish profile secret with a service principal secret still requires storing a secret, which does not improve security compared to OIDC.

Option D is incorrect because setting the 'Publish Profile' parameter to an empty string does not enable OIDC authentication; the deployment would fail due to missing credentials.

Full explanation →
752
MCQhard

You are the lead DevOps engineer for a large e-commerce company. The company has a multi-region Azure Kubernetes Service (AKS) cluster deployment for its microservices. The current CI/CD pipeline uses Azure DevOps to build Docker images and deploy to AKS via Helm charts. Recently, the team noticed that after a deployment to the West Europe region, the application experienced a 5-minute downtime due to a configuration error where the new pods couldn't connect to the database because the connection string was pointing to a staging database instead of production. The issue was detected manually after a customer reported the outage. The team wants to implement a mechanism to automatically detect such misconfigurations before they affect production traffic. They also want to ensure that if a deployment fails health checks, the previous version is automatically rolled back. The pipeline currently runs all stages in sequence: build, deploy to West Europe, then deploy to East US. The team has a small budget for additional resources. Which approach should the team implement?

A.Implement a canary deployment strategy with automated health checks and automatic rollback on failure.
B.Use a blue-green deployment strategy with deployment slots in AKS.
C.Add a manual approval gate before the deployment to East US, requiring a tester to verify the deployment in West Europe.
D.Deploy to a separate test environment first, run integration tests, then deploy to production.
AnswerA

A canary deployment with automated health checks and automatic rollback is the correct choice because it incrementally routes a small percentage of production traffic to the new release, say 5%, then gradually increases it only if health checks pass. Automated checks monitor key signal like HTTP 5xx error rate, request latency, and custom application health endpoints, and if a threshold is breached, the release pipeline automatically reverts the routing to the previous stable version. This catches misconfigurations and regressions early with a minimal blast radius, preventing full-scale downtime. Unlike blue-green or a staged test deploy, it validates against real production load and configuration while keeping the majority of users on the safe version.

Why this answer

A canary deployment strategy with automated health checks and automatic rollback directly addresses the need to detect misconfigurations before they affect all production traffic. By routing a small percentage of traffic to the new pods and monitoring health probes (e.g., liveness and readiness probes in Kubernetes), the pipeline can automatically roll back if the canary fails, preventing the 5-minute downtime scenario. This approach is cost-effective as it leverages existing AKS features without requiring additional infrastructure.

Exam trap

The trap here is that candidates may confuse blue-green or test environment strategies with automated detection and rollback, but these options lack the real-time health monitoring and automatic traffic shifting that canary deployments provide for catching configuration errors in production.

How to eliminate wrong answers

Option B is wrong because blue-green deployment with deployment slots in AKS does not inherently provide automated health checks or rollback on failure; it requires manual traffic switching and does not automatically detect configuration errors like a wrong database connection string. Option C is wrong because adding a manual approval gate before deploying to East US still relies on human verification, which is slow and error-prone, and does not automatically detect misconfigurations or trigger rollback. Option D is wrong because deploying to a separate test environment first and running integration tests does not guarantee that the exact production configuration (e.g., database connection strings) is validated; it also adds cost and complexity without addressing the need for automatic rollback in production.

Full explanation →
753
MCQeasy

Your organization uses Microsoft Entra ID (formerly Azure AD) for identity management. You need to ensure that only authorized users can access the Azure DevOps organization. What is the most secure way to manage access?

A.Require all users to use multi-factor authentication (MFA) and enable Conditional Access policies.
B.Disable external user access and only allow internal users.
C.Use IP address restrictions to limit access to the corporate network.
D.Add users to the Azure DevOps organization and assign them to the 'Basic' access level.
AnswerA

Requiring multi-factor authentication (MFA) ensures users prove their identity via a second factor, and Conditional Access policies enforce context-aware conditions such as device compliance, sign-in risk, and location for Azure DevOps resources. This combined approach mitigates credential theft and provides adaptive, secure access controls directly integrated with Microsoft Entra ID.

Why this answer

Requiring multi-factor authentication (MFA) and enabling Conditional Access policies provides the most secure access control. MFA adds an extra layer of security beyond passwords, and Conditional Access allows granular policy enforcement based on user, device, location, and risk, ensuring only authorized users under secure conditions can access Azure DevOps. Option B is less secure as it does not enforce additional authentication.

Option C only restricts access by network location but does not prevent unauthorized access if an attacker is on the corporate network. Option D only grants basic access without security controls.

Full explanation →
754
MCQeasy

Your organization uses Azure DevOps and Microsoft Entra ID. The compliance team needs to ensure that access to Azure DevOps projects is governed by conditional access policies. Which Azure DevOps integration should you use?

A.Link the Azure DevOps organization to the Microsoft Entra ID tenant and configure conditional access policies in Microsoft Entra ID.
B.Configure service hooks to enforce conditional access.
C.Assign managed identities to users for conditional access.
D.Use OAuth tokens to authenticate users.
AnswerA

Linking the Azure DevOps organization to your Microsoft Entra ID tenant is the prerequisite that makes conditional access policies effective for Azure DevOps sign-ins. Once linked, Azure DevOps delegates authentication and authorization to Microsoft Entra ID, so conditional access policies you configure in Microsoft Entra ID — such as MFA, device compliance, or location-based restrictions — are evaluated during the interactive sign-in and token issuance flow. This applies organization-wide and covers all users who authenticate through the linked tenant, enforcing policy before users can access Azure DevOps resources.

Why this answer

To govern access to Azure DevOps projects with conditional access policies, you must link the Azure DevOps organization to the Microsoft Entra ID tenant. This integration makes Azure DevOps a registered application within the tenant, allowing conditional access policies (e.g., MFA, device compliance, location-based access) to be evaluated during authentication. Only then can the compliance team enforce organization-wide access rules via Microsoft Entra ID.

Exam trap

The trap here is that candidates confuse service hooks or OAuth tokens with identity governance features, not realizing that conditional access requires the resource to be a first-party or registered application in Microsoft Entra ID, not just any authentication method.

How to eliminate wrong answers

Option B is wrong because service hooks are used for integrating external services (e.g., Slack, Jenkins) via event-driven notifications, not for enforcing authentication or conditional access policies. Option C is wrong because managed identities are designed for Azure resources (e.g., VMs, Functions) to authenticate to Azure services without storing credentials, not for user-level conditional access enforcement. Option D is wrong because OAuth tokens are an authentication mechanism for granting delegated access to APIs; they do not by themselves enforce conditional access policies, which require the resource (Azure DevOps) to be integrated with Microsoft Entra ID as a relying party.

Full explanation →
755
MCQmedium

You have a build pipeline that produces several artifacts. You need to publish these artifacts to Azure Artifacts feed, but only if the build succeeds. Which task should you add to the pipeline?

A.Add a 'Publish Build Artifacts' task and then a 'Universal Publish' task.
B.Add an 'npm publish' task to publish packages.
C.Add a 'Copy Files' task to copy artifacts to the feed location.
D.Add a 'NuGet push' task to push packages to the feed.
AnswerA

Correct: Publish build artifacts first, then publish to Azure Artifacts feed.

Why this answer

The 'Publish Build Artifacts' task makes the build outputs available as pipeline artifacts, and the 'Universal Publish' task is the correct way to publish those artifacts to an Azure Artifacts feed (which supports Universal Packages). This combination ensures artifacts are only published after the build succeeds because both tasks run in the pipeline's job sequence, and by default, subsequent tasks execute only if the previous task succeeded.

Exam trap

The trap here is that candidates often assume any package-specific task (npm, NuGet) can publish to Azure Artifacts, but the question asks for publishing 'several artifacts' (not just one package type), so the Universal Publish task is the only correct choice for a generic, multi-artifact scenario.

How to eliminate wrong answers

Option B is wrong because 'npm publish' is specific to npm packages and cannot publish arbitrary build artifacts to an Azure Artifacts feed. Option C is wrong because 'Copy Files' only copies files to a local or network path, not to an Azure Artifacts feed; it does not perform any publish operation. Option D is wrong because 'NuGet push' is limited to NuGet packages and cannot handle other artifact types like Universal Packages or Maven artifacts.

Full explanation →
756
MCQmedium

Your organization uses GitHub for source control and Azure Pipelines for CI/CD. You need to implement a pipeline that automatically builds and tests a Python application on every pull request to the main branch, but only if the pull request is from a fork. The pipeline must also publish test results as a build artifact. What should you do?

A.Use GitHub Actions to build and test the application on PRs, and then trigger Azure Pipelines for deployment.
B.Use a scheduled trigger to run the pipeline every hour and check for new PRs from forks.
C.Set up a pipeline completion trigger on the main branch that runs the pipeline after every merge.
D.Configure a branch protection rule on main that requires status checks from Azure Pipelines. Set the pipeline trigger to 'Pull request validation' and include a condition to run only if the pull request is from a fork.
AnswerD

This correctly uses Azure Pipelines as the PR validation engine: setting the pipeline trigger to 'Pull request validation' makes Azure Pipelines run on each PR, and the condition limits it to fork PRs. The branch protection rule on main then requires the Azure Pipelines status check to pass before the PR can be merged, enforcing validation as a merge gate.

Why this answer

It configures a branch protection rule on the main branch that requires status checks from Azure Pipelines. By setting the pipeline trigger to 'Pull request validation' and including a condition to run only if the pull request is from a fork, the pipeline automatically builds and tests the Python application on every pull request from a fork to main. The pipeline can also publish test results as a build artifact.

Option A is incorrect because GitHub Actions is not Azure Pipelines; the requirement specifies using Azure Pipelines for CI/CD. Option B is incorrect because a scheduled trigger polling for PRs is inefficient and not the proper way to handle PR events. Option C is incorrect because a pipeline completion trigger runs after a merge, not on pull requests.

Full explanation →
757
Multi-Selecthard

Which THREE are benefits of using a monorepo vs multiple repositories?

Select 3 answers
A.Easier code sharing and refactoring across projects
B.Reduced risk of configuration drift
C.Simplified dependency management across projects
D.Faster clone times due to smaller repository size
E.Atomic commits that span multiple components
AnswersA, C, E

Because all code resides in a single repository, projects can directly import shared libraries without separately publishing and versioning them. This enables large-scale refactoring, such as changing an API signature, to be done in one atomic change that immediately affects all consuming projects, greatly simplifying coordination.

Why this answer

A monorepo enables easier code sharing and refactoring across projects by allowing all code to reside in a single repository. This eliminates the need for cross-repository package publishing or versioning, as shared libraries can be directly referenced and refactored atomically across all dependent projects within the same commit.

Exam trap

The trap here is that candidates often confuse 'reduced configuration drift' (Option B) with the benefits of centralized configuration management, but in a monorepo, configuration drift can still occur if teams modify shared files inconsistently, and the exam expects you to recognize that this is not an inherent benefit.

Full explanation →
758
MCQeasy

You need to ensure that only signed-in users can view Azure DevOps project wikis. Which setting should you configure?

A.Configure wiki permissions to deny anonymous users
B.Set project visibility to 'Private'
C.Set repository visibility to 'Private'
D.Use Microsoft Entra ID Application Proxy
AnswerB

Setting the project visibility to 'Private' in Azure DevOps is the definitive project-level setting that requires all users to authenticate before viewing any project data, including wikis, repos, boards, and pipelines. This ensures that anonymous users are completely barred from accessing Azure DevOps content, as private projects only allow authenticated members or explicitly added external users.

Why this answer

Setting the project visibility to 'Private' ensures that only authenticated users who are members of the Azure DevOps organization can access the project and its wikis. Anonymous or unauthenticated users are blocked entirely at the project level, which directly satisfies the requirement to restrict wiki viewing to signed-in users only.

Exam trap

The trap here is that candidates often confuse repository-level visibility with project-level visibility, assuming that setting a repo to private will also secure the wiki, when in fact the wiki is a project-level artifact and its access is governed by the project's visibility setting.

How to eliminate wrong answers

Option A is wrong because Azure DevOps wikis do not have a separate 'deny anonymous users' permission; anonymous access is controlled at the project visibility level, not through granular wiki permissions. Option C is wrong because repository visibility settings control access to the underlying Git repository, not the wiki itself; project wikis are provisioned as a separate service and are governed by project-level visibility. Option D is wrong because Microsoft Entra ID Application Proxy is used for publishing on-premises web applications externally, not for controlling access to Azure DevOps wikis.

Full explanation →
759
MCQeasy

Your team uses Azure Pipelines to build a Node.js application. The build pipeline runs linting, unit tests, and creates a production build. You want to ensure that the pipeline fails if the test coverage drops below 80%. You need to implement this check. What should you do?

A.Configure a pipeline variable 'CoverageThreshold' and use it in a gate.
B.Set a branch policy that requires code coverage to be at least 80%.
C.Use the 'Visual Studio Test' task with code coverage enabled and set the 'Minimum coverage' option.
D.Add a 'Publish Test Results' task with code coverage enabled, then use a 'Script' task that reads the coverage report and fails if below 80%.
AnswerD

This is the correct pattern: the Publish Test Results task accepts coverage output (e.g., Cobertura XML from Istanbul/nyc) and publishes it to the pipeline, and then a subsequent Script task (PowerShell, Bash, etc.) parses the generated report—such as reading the 'coverage-summary.json' or the Cobertura XML—and explicitly fails the build if the line coverage is below 80%. This gives you arbitrary custom logic to enforce the threshold exactly as required.

Why this answer

The 'Publish Test Results' task can publish code coverage reports, and a subsequent script task can parse the report (e.g., using a tool like c8 or nyc) and exit with a non-zero code if coverage is below 80%, causing the pipeline to fail. Option A is incorrect because a pipeline variable alone cannot enforce coverage thresholds; you need a task that checks the coverage. Option B is incorrect because branch policies can enforce code review requirements but not specific code coverage percentages from build results.

Option C is incorrect because the 'Visual Studio Test' task is designed for .NET applications, not Node.js; it does not work with Node.js coverage reports.

Full explanation →
760
Multi-Selectmedium

Which THREE of the following are true about GitHub Actions self-hosted runners?

Select 3 answers
A.They can have custom software installed.
B.They are automatically scaled by GitHub.
C.They are free and do not incur any costs.
D.They can run on Windows, Linux, or macOS.
E.They can access on-premises resources.
AnswersA, D, E

Self-hosted runners are machines you control, so you can pre-install any custom software, tools, or libraries required by your workflows, unlike GitHub-hosted runners which have a fixed set of pre-installed software.

Why this answer

GitHub Actions self-hosted runners are machines you manage, allowing you to install any custom software, libraries, or tools required by your workflows. Unlike GitHub-hosted runners, which have a fixed set of pre-installed software, self-hosted runners give you full administrative control over the environment, enabling you to meet specific build or test dependencies.

Exam trap

The trap here is that candidates often assume self-hosted runners are entirely free and automatically managed by GitHub, overlooking the operational overhead and infrastructure costs, while also forgetting that GitHub does not handle scaling for self-hosted runners.

Full explanation →
761
MCQeasy

Your team uses Azure Repos and wants to trigger a pipeline automatically when a pull request is created targeting the main branch. The pipeline should run validations and report the status to the PR. Which trigger type should you configure?

A.Path filter
B.Scheduled trigger
C.PR trigger
D.CI trigger
AnswerC

PR triggers automatically start a pipeline when a pull request is created, updated, or reopened against a target branch, evaluating the merged result of the source and target branches. In Azure Pipelines, a PR trigger is the correct event type to validate changes before merging, and it can be configured specifically for individual or multiple branches, unlike CI triggers which only fire on direct pushes.

Why this answer

A PR trigger is the correct choice because it specifically initiates a pipeline when a pull request is created or updated against a target branch (main). This allows the pipeline to run validations (e.g., builds, tests, linting) and report the status back to the PR via the Azure Repos status API, enabling branch protection policies to block merging if checks fail.

Exam trap

The trap here is that candidates often confuse CI triggers (which run on branch pushes) with PR triggers (which run on pull request events), especially when they see 'trigger on main branch' and incorrectly assume a CI trigger will handle PR validation.

How to eliminate wrong answers

Option A is wrong because a path filter is not a trigger type; it is a configuration option used within CI or PR triggers to limit execution based on file changes in specific paths. Option B is wrong because a scheduled trigger runs pipelines at predefined times (e.g., nightly builds) and does not respond to pull request events. Option D is wrong because a CI trigger runs when code is pushed to a branch (e.g., main), not when a PR is created; it does not automatically report status to a PR and is intended for continuous integration on commits.

Full explanation →
762
MCQhard

A company uses Microsoft Entra ID for identity. They want to enforce that all code changes in Azure Repos require a linked work item and a successful policy evaluation. Which branch policy should they configure?

A.Set the merge strategy to squash merge.
B.Enable 'Automatically include reviewers'.
C.Require work item linking in the branch policy.
D.Enforce a minimum number of comments.
AnswerC

Requiring work item linking in the branch policy is correct because it enforces that every pull request must have at least one linked work item before it can be completed. This creates an auditable trace from code changes back to the original requirement or task in Azure Boards.

Why this answer

Requiring work item linking in the branch policy ensures that every pull request (PR) in Azure Repos must be associated with a work item (e.g., user story, bug) before it can be completed. Combined with a successful policy evaluation (e.g., build validation, required reviewers), this enforces traceability and compliance for all code changes.

Exam trap

The trap here is that candidates may confuse branch policy settings that add metadata (like auto-include reviewers or comment counts) with policies that enforce mandatory linking or validation, leading them to select options that only facilitate review but do not enforce the required traceability.

How to eliminate wrong answers

Option A is wrong because setting the merge strategy to squash merge controls how commits are combined into the target branch (e.g., squashing all commits into one), but it does not enforce any requirement for linked work items or policy evaluation. Option B is wrong because enabling 'Automatically include reviewers' adds specific reviewers to a PR based on file paths or other criteria, but it does not enforce work item linking or policy evaluation. Option D is wrong because enforcing a minimum number of comments only requires a certain number of comments on a PR before it can be completed, which does not ensure work item linking or policy evaluation.

Full explanation →
763
MCQeasy

You are configuring a build pipeline for a JavaScript application. You want to run linting, unit tests, and build steps only when changes are pushed to the 'develop' branch. Which trigger should you configure?

A.Enable pull request trigger.
B.Enable scheduled trigger.
C.Enable continuous integration (CI) trigger without branch filters.
D.Enable CI trigger with a branch filter for 'develop'.
AnswerD

Enabling CI with a branch filter for 'develop' ensures the pipeline is triggered automatically on every push to the develop branch, while ignoring pushes to other branches. This provides immediate build validation for changes integrated into the mainline, aligning exactly with the requirement of building on direct pushes to develop.

Why this answer

Enabling a CI trigger with a branch filter for 'develop' ensures that the pipeline automatically runs linting, unit tests, and build steps only when changes are pushed to the 'develop' branch. This matches the requirement precisely, as CI triggers respond to push events, and the branch filter restricts execution to the specified branch.

Exam trap

The trap here is that candidates often confuse CI triggers with pull request triggers, mistakenly thinking a CI trigger without branch filters is sufficient, but the branch filter is essential to restrict execution to a specific branch.

How to eliminate wrong answers

Option A is wrong because pull request triggers run when a PR is created or updated, not when changes are pushed directly to a branch; this would not satisfy the requirement to run on pushes to 'develop'. Option B is wrong because scheduled triggers run at specified times regardless of code changes, which does not align with the requirement to trigger only on pushes. Option C is wrong because enabling a CI trigger without branch filters would cause the pipeline to run on pushes to any branch, including feature branches, not just 'develop'.

Full explanation →
764
MCQhard

Your organization uses Microsoft Entra ID for identity and Azure DevOps for source control. You need to enforce that all code changes to the main branch require a pull request with at least two approvals and no failing checks. What should you configure?

A.Configure a Conditional Access policy in Microsoft Entra ID
B.Add an environment protection rule in Azure Pipelines
C.Set up a branch policy on the main branch in Azure Repos
D.Use a service hook to notify reviewers when a push occurs
AnswerC

Branch policies in Azure Repos provide a server-enforced compliance gate on pull requests targeting the main branch. You can configure a policy to require a minimum number of reviewers, enforce build validation by running a pipeline, and mandate linked work items. These policies block direct pushes to the main branch and prevent pull request completion until every defined criterion is satisfied, making them an authoritative mechanism for code review and build quality gates.

Why this answer

Azure Repos branch policies allow you to enforce required pull requests, minimum number of reviewers (e.g., two approvals), and status checks (e.g., no failing checks) on the main branch. This ensures that all code changes to the protected branch comply with the defined quality and security gates before merging.

Exam trap

The trap here is that candidates confuse environment protection rules (used for deployment approvals in release pipelines) with branch policies (used for source code merge requirements in Azure Repos), leading them to select Option B instead of C.

How to eliminate wrong answers

Option A is wrong because Conditional Access policies in Microsoft Entra ID control authentication and access to applications (e.g., requiring MFA or device compliance), not code review or merge requirements within Azure Repos. Option B is wrong because environment protection rules in Azure Pipelines govern deployment approvals and checks for release pipelines (e.g., manual approval before deploying to production), not source control branch policies for pull requests. Option D is wrong because service hooks are used to trigger external events (e.g., sending notifications to Slack or triggering a webhook) when a push occurs, but they do not enforce approval or check requirements on pull requests.

Full explanation →
765
MCQeasy

Your team is migrating from TFVC to Git in Azure Repos. You need to preserve the full history of the TFVC repository, including all branches and changesets. The TFVC repository is large (over 10 GB). Which tool should you use to perform the migration?

A.Manually recreate the commits in a new Git repository.
B.Use git-tfs to clone the TFVC repository and then push to Azure Repos.
C.Use git-svn to convert TFVC to Git.
D.Use the Azure DevOps Migration Tools to export TFVC to Git.
AnswerB

git-tfs is a specialized bridge that clones a TFVC repository into a local Git repository while preserving the full history of changesets, branches, and merges. It is designed for large TFVC repos, and after cloning, you can push the Git repository to Azure Repos, making it the correct migration path.

Why this answer

B is correct because git-tfs is specifically designed to bridge TFVC and Git, allowing you to clone a TFVC repository (including all branches, changesets, and history) into a local Git repository, which can then be pushed to Azure Repos. It handles large repositories (over 10 GB) by performing an incremental clone, preserving the full history without manual recreation.

Exam trap

The trap here is that candidates confuse git-tfs with git-svn, assuming any 'git-*' tool works for any version control system, but git-svn only works with Subversion, not TFVC.

How to eliminate wrong answers

Option A is wrong because manually recreating commits in a new Git repository would lose the full history, branches, and changesets, which contradicts the requirement to preserve them. Option C is wrong because git-svn is designed for Subversion (SVN) repositories, not TFVC; it cannot interpret TFVC's changeset structure or branching model. Option D is wrong because the Azure DevOps Migration Tools are primarily for migrating work items, test plans, and other Azure DevOps artifacts between organizations, not for converting TFVC repositories to Git with full history.

Full explanation →
766
MCQhard

Your organization uses Azure DevOps with classic pipelines. Security audit requires that all pipeline variables containing secrets (e.g., API keys) are stored in Azure Key Vault and referenced dynamically. Currently, secrets are stored as plain text in the pipeline UI. You need to migrate to Key Vault with minimal downtime and ensure that secret values are never exposed in logs. What should you do?

A.Store secrets in a secure file in Azure DevOps.
B.Create a variable group linked to Key Vault, mark variables as 'secret', and reference them in pipelines. Update pipeline steps to use the variable group.
C.Use the 'Azure Key Vault' task to download secrets as pipeline variables.
D.Add each secret as a pipeline variable with the 'secret' type.
AnswerB

Create a variable group linked to an Azure Key Vault and select the secrets to expose. The linked variable group automatically loads those secrets as pipeline variables, and each one is implicitly treated as secret, so Azure DevOps masks its value in every log. Update your pipeline steps to reference $(secret-name) instead of hardcoding values; this also lets you rotate secrets in Key Vault without redeploying pipelines and gives you centralized access control and auditing through the vault.

Why this answer

The correct approach is to create a variable group linked to Azure Key Vault in the Library, mark the variables as 'secret', and reference that variable group in the pipeline. This ensures secrets are stored in Key Vault (not in Azure DevOps) and masked in logs. Option A (secure file) still stores secrets in Azure DevOps and may not prevent log exposure.

Option C (Azure Key Vault task) downloads secrets as pipeline variables, which could expose them if not properly masked. Option D (secret pipeline variables) stores secrets in Azure DevOps, not Key Vault, and while masked, they remain in the pipeline definition.

Full explanation →
767
Multi-Selecthard

Which THREE factors should you consider when designing a release pipeline for a critical production application? (Choose three.)

Select 3 answers
A.Use of service principal with least privilege
B.Rollback strategy
C.Single environment deployment
D.Deployment health monitoring
E.Approval gates before production deployment
AnswersB, D, E

A rollback strategy is essential because even with thorough testing in lower environments, production failures can still occur; a well-defined process to revert to the last known good artifact, whether through redeployment or automated restore, minimizes mean time to recovery (MTTR) and reduces customer impact.

Why this answer

A release pipeline for a critical production application must include a rollback strategy (e.g., deployment slots or redeploying a previous artifact) to recover quickly from failed releases, deployment health monitoring (e.g., Application Insights, Azure Monitor) to detect issues early and trigger rollbacks or alerts, and approval gates before production deployment to ensure manual or automated checks are passed. These three factors together minimize downtime and ensure controlled, safe releases.

Exam trap

The trap here is that candidates confuse security best practices (like service principal least privilege) with release pipeline design factors, or they mistakenly think a single environment is acceptable for critical apps, ignoring the necessity of staging and rollback capabilities.

Full explanation →
768
MCQmedium

Your team uses Azure Pipelines to deploy a Docker container to Azure Kubernetes Service (AKS). The pipeline builds a Docker image, pushes it to Azure Container Registry (ACR), and then runs a deployment to AKS. You want to ensure that the deployment uses the exact image that was built in the same pipeline run. Which approach should you use?

A.Use two separate pipelines: one for build/push, one for deploy, and share the image tag via a variable group.
B.Use a single task for build and push, and rely on ACR's internal pull-through cache.
C.Generate a unique tag (e.g., Build.BuildId) and pass it to both the Docker build and Kubernetes manifest via variable substitution.
D.Tag the image as 'latest' and reference it in the Kubernetes manifest.
AnswerC

Using Build.BuildId (or another unique identifier) as the image tag makes each build's image reference immutable and traceable, and when you inject that same tag into the Kubernetes manifest during variable substitution, the deployment is guaranteed to pull the exact artifact produced by the current pipeline run. This eliminates tag-mutation races and provides clear auditability.

Why this answer

Using a unique tag like Build.BuildId ensures that the exact image built in the pipeline is referenced in the Kubernetes manifest. This prevents deployment from accidentally using a stale or overwritten image, as the tag is unique per run and passed consistently via variable substitution from the Docker build to the deployment YAML.

Exam trap

The trap here is that candidates often choose the 'latest' tag (Option D) because it seems simpler, but they overlook that 'latest' is mutable and can cause deployment of a different image than the one built in the same pipeline run.

How to eliminate wrong answers

Option A is wrong because using two separate pipelines with a variable group introduces a race condition and does not guarantee that the deploy pipeline uses the exact image from the same build run; the variable group could be overwritten by another run. Option B is wrong because relying on ACR's internal pull-through cache does not enforce image identity; it only caches layers and does not tie the deployment to the specific build output. Option D is wrong because tagging the image as 'latest' is mutable and can be overwritten by subsequent builds, leading to deployment of a different image than the one built in the same pipeline run.

Full explanation →
769
MCQeasy

You are setting up a release pipeline for a web application. The pipeline must deploy to three environments: Dev, Test, and Prod. The deployment to Prod must be triggered only after a successful deployment to Test and after a manual approval. How should you configure the pipeline?

A.Add a manual intervention task before the Prod deployment in the pipeline.
B.Use a condition on the Prod stage to require success from Test and manual intervention variable.
C.Schedule the Prod deployment to run after Test, and require manual trigger.
D.Add a pre-deployment approval gate on the Prod environment.
AnswerD

A pre-deployment approval gate is configured directly on the Prod environment in Azure Pipelines, and it forces the pipeline to pause before the deployment job to that environment begins. Designated approvers must explicitly approve the release, which provides a formal, auditable sign-off that blocks the Prod stage from starting until the required approval is granted.

Why this answer

Pre-deployment approval gates on the Prod environment block the release until manual approval is granted, and a stage condition ensures it runs only after successful Test deployment. Option A is wrong because manual intervention tasks are not designed for approvals and do not integrate with pipeline stages as seamlessly. Option B is wrong because conditions can't enforce manual approval; they only evaluate at runtime.

Option C is wrong because scheduling doesn't provide manual approval; triggers can be manual but not combined with stage success conditions effectively.

Exam trap

Candidates often confuse manual intervention tasks with approval gates. Pre-deployment approvals are the proper Azure DevOps feature for manual sign-off on a stage.

Full explanation →
770
MCQhard

Your organization is migrating from Azure Repos to GitHub. You have 200 repositories with complex branching strategies and build policies. You need to preserve the commit history and branch policies. What is the best migration approach?

A.Manually recreate each repository in GitHub and copy the code from Azure Repos
B.Use a third-party tool to perform a mirror clone and then push to GitHub
C.Use the GitHub Importer tool with a custom mapping script to migrate repositories and policies
D.Use git push --force to push all branches to GitHub and recreate policies manually
AnswerD

Using `git push --force` migrates all commit history, and then recreating policies manually or via API ensures both history and policies are preserved.

Why this answer

The GitHub Importer tool does not preserve branch policies; it only migrates repository history and code. To keep commit history and then recreate branch policies, the best approach is to use `git push --force` to push all branches from Azure Repos to GitHub, then recreate branch policies manually or via the GitHub API. This ensures complete history is preserved while policies are re-established separately.

Exam trap

Candidates often assume the GitHub Importer tool can also migrate branch policies, but it only migrates repository code and history. Platform-specific policies like branch protection must be recreated manually or via API.

How to eliminate wrong answers

Option A is wrong because manually recreating repositories and copying code loses commit history and branch policies, which is inefficient and error-prone for 200 repositories. Option B is wrong because a third-party mirror clone only copies the repository data (commits, branches) but does not migrate branch policies or build policies, which are critical for compliance and CI/CD. Option D is wrong because git push --force pushes all branches but does not preserve branch policies, and recreating them manually for 200 repositories is impractical and risks misconfiguration.

Full explanation →
771
MCQhard

Your organization uses Microsoft Entra ID and Azure DevOps. You need to ensure that only users from specific Entra ID groups can create new Azure DevOps organizations. What should you configure?

A.Assign the Global Administrator role to the security group
B.Assign the Azure DevOps Administrator role to the security group
C.Configure Conditional Access policies to block non-group members
D.Use Azure DevOps security policies to restrict organization creation
AnswerB

The Azure DevOps Administrator role in Microsoft Entra ID is specifically designed to grant permissions to manage Azure DevOps organizations, including creation. Assigning this role to a security group enables group-based assignment, ensuring that members have the precise privileges needed without overreaching, following the least-privilege model.

Why this answer

The Azure DevOps Administrator role in Microsoft Entra ID is specifically designed to manage Azure DevOps service-level settings, including the ability to restrict who can create new Azure DevOps organizations. By assigning this role to a security group, only members of that group can create new organizations, which directly meets the requirement.

Exam trap

The trap here is that candidates often confuse Conditional Access policies (which control sign-in and access) with administrative roles (which control resource creation permissions), leading them to select option C instead of the correct role-based option B.

How to eliminate wrong answers

Option A is wrong because the Global Administrator role grants broad administrative access across all Entra ID services, which is excessive and not scoped to Azure DevOps organization creation. Option C is wrong because Conditional Access policies control authentication and access to applications, not the ability to create new Azure DevOps organizations; they cannot restrict organization creation at the Entra ID level. Option D is wrong because Azure DevOps security policies are scoped within an existing organization and cannot control the creation of new organizations at the tenant level.

Full explanation →
772
MCQhard

Your Azure DevOps pipeline deploys to multiple environments (Dev, Test, Prod) using YAML multi-stage pipelines. The Prod deployment requires manual approval. However, the approval gate shows 'Pending' even after an authorized user approves. What is the most likely cause?

A.The pipeline run was triggered by a PR merge, and the approval needs to be re-applied after the build completes.
B.The build pipeline includes a step that modifies the approval settings.
C.The approval gate is configured to require approval on the latest commit, but a newer commit was pushed after the approval.
D.The approver is not a member of the security group defined in the approval settings.
AnswerC

Correct: Environment approval gates are configured to evaluate the latest commit of the pipeline run; if a newer commit is pushed after the approval was granted, the gate detects the changed commit and requires re-approval before the deployment proceeds.

Why this answer

In Azure DevOps, approvals are associated with a specific pipeline run and its commit. When a new commit is pushed after an approval, it triggers a new pipeline run. The new run has its own approval requirement, so it remains 'Pending' until approved.

The previous approval does not carry over to the new run.

Exam trap

The trap is that candidates assume an approval applies to the stage or environment indefinitely, rather than to a specific pipeline run/commit. A new commit generates a new run with a new pending approval.

How to eliminate wrong answers

Option A is wrong because PR merges trigger the pipeline, but the approval gate is evaluated after the build completes; re-applying approval is not required unless a new commit is pushed. Option B is wrong because build pipeline steps cannot modify approval settings; approval settings are defined at the environment or stage level in YAML, not altered by pipeline tasks. Option D is wrong because if the approver were not a member of the security group, the approval would fail or be rejected, not remain in 'Pending' state.

Full explanation →
773
MCQhard

You are designing a release pipeline for a critical application that requires zero-downtime deployments. The application runs on Azure Kubernetes Service (AKS) with multiple replicas. You are using Azure Pipelines with a canary deployment strategy. What is the best approach to gradually shift traffic to the new version while monitoring for errors?

A.Use a service mesh like Istio to route a percentage of traffic to the new version.
B.Use Azure Application Gateway as an ingress controller with weighted backend pools.
C.Use the AKS rolling update strategy with max surge.
D.Deploy to a staging environment, then swap VIPs with production.
AnswerA

Istio enables precise traffic routing for canary deployments.

Why this answer

Using a service mesh like Istio allows granular traffic splitting between versions, enabling gradual canary deployments with real-time monitoring. Option B is incorrect: Azure Application Gateway can route traffic to backends, but it works at the ingress level and cannot easily shift traffic at the pod level without additional configuration; it's less flexible than a service mesh for canary. Option C is incorrect: AKS rolling update gradually replaces pods but does not split traffic between old and new; all traffic goes to the new version once a pod is updated, making it unsuitable for gradual traffic shift.

Option D is incorrect: VIP swap is a blue-green deployment, which switches all traffic at once, not gradually.

Full explanation →
774
Multi-Selecteasy

Which TWO features of GitHub Actions can be used to enforce code quality standards before merging?

Select 2 answers
A.Environments
B.Secrets
C.Branch protection rules with required status checks
D.Status checks
E.Repository variables
AnswersC, D

Branch protection rules with required status checks enforce quality by preventing a pull request from being merged until all specified status checks pass. This directly enforces that CI/CD workflows, including code quality jobs, succeed before changes are accepted into a protected branch.

Why this answer

Branch protection rules with required status checks (C) enforce that pull requests must pass specific GitHub Actions workflows (e.g., linting, testing, security scans) before merging. Status checks (D) are the actual workflow runs that report pass/fail to the pull request; when required, they block merging until all checks succeed. Together, they ensure code quality gates are met automatically.

Exam trap

The trap here is that candidates confuse 'Environments' (deployment gates) with 'branch protection rules' (merge gates), or assume 'Secrets' or 'Variables' can enforce quality, when they are purely for storing configuration data.

Full explanation →
775
Multi-Selecteasy

Your team is adopting GitHub Copilot for code generation. The compliance team requires that all code generated by AI is reviewed and that proprietary code is not used as training data. Which TWO settings should you configure in your GitHub organization?

Select 2 answers
A.Configure a branch protection rule that requires all code to be reviewed before merging.
B.Disable Copilot for all repositories in the organization.
C.Disable the 'Allow GitHub to use my data for training' option in the organization's Copilot settings.
D.Enable 'Suggestions matching public code' to block suggestions that match public code.
E.Enable 'Allow GitHub to use my code snippets for product improvements' to improve Copilot.
AnswersA, C

Configuring a branch protection rule that requires at least one approved pull request review on protected branches (e.g., main) enforces a mandatory human review checkpoint before any Copilot-generated code can be merged. This ensures AI-suggested changes are inspected for correctness, security, and compliance, meeting the core safety requirement while still allowing Copilot usage.

Why this answer

Branch protection rules enforce mandatory pull request reviews before merging, which satisfies the compliance requirement that all AI-generated code must be reviewed by a human before entering the main branch. Additionally, disabling the 'Allow GitHub to use my data for training' option in the organization's Copilot settings prevents proprietary code from being used as training data, directly addressing the compliance requirement that proprietary code not be used for training. Together, these two settings allow the team to use GitHub Copilot safely while meeting compliance.

Exam trap

The trap here is that candidates might confuse the 'Suggestions matching public code' setting (which blocks suggestions that match public code to avoid license violations) with the data privacy setting that controls training data usage, or think that disabling Copilot entirely is the only way to meet compliance, when in fact the two correct settings allow safe usage without violating policies.

Full explanation →
776
MCQeasy

Your Azure DevOps repository contains a large binary file that is slowing down clone operations. Which Git feature should you use to reduce the clone time?

A.Shallow clone
B.Git LFS (Large File Storage)
C.Depth parameter in clone command
D.Sparse checkout
AnswerB

Git LFS replaces large binary files with text pointers in the Git repository, storing the actual file content in a separate remote LFS store. On clone/checkout, pointers are swapped for the real files, which keeps the Git database small and prevents repository bloat.

Why this answer

Git LFS (Large File Storage) is the correct solution because it replaces large binary files in the repository with lightweight text pointers, storing the actual binary content in external remote storage. This prevents the large file from being downloaded during every clone, significantly reducing clone time and repository size on disk.

Exam trap

The trap here is that candidates confuse shallow clones or sparse checkouts as solutions for large files, when in fact those features address history depth or working tree scope, not the fundamental problem of large binary objects being stored and transferred in the repository.

How to eliminate wrong answers

Option A is wrong because a shallow clone (using --depth 1) limits the commit history but still downloads the current version of all files, including the large binary, so it does not address the root cause of the large file slowing clones. Option C is wrong because the depth parameter is simply the mechanism to perform a shallow clone; it has the same limitation as option A and does not exclude the large binary from being downloaded. Option D is wrong because sparse checkout limits which directories or files are populated in the working tree, but the entire repository object data (including the large binary) is still downloaded during clone; it only affects checkout, not the transfer size.

Full explanation →
777
MCQeasy

Your team uses GitFlow and wants to enforce that all feature branches are deleted after merging to develop. Which automation should you implement?

A.Enable the 'Automatically delete source branches' policy in the branch policy.
B.Use a post-merge script in the pipeline.
C.Train developers to delete branches manually.
D.Configure branch retention policies in Azure Repos.
AnswerA

Enabling 'Automatically delete source branches' in the branch policy for the target branch (e.g., main or develop) ensures that whenever a pull request is merged, the source feature branch is deleted automatically. This is a native Azure Repos policy that enforces cleanup without relying on developer action or custom scripts, making it the correct way to enforce branch cleanup in GitFlow.

Why this answer

The 'Automatically delete source branches' policy in Azure Repos branch policies automatically removes a feature branch once its pull request is completed into the target branch (e.g., develop). This directly enforces the GitFlow requirement without manual intervention or pipeline scripting, as it is a native repository-level setting.

Exam trap

The trap here is that candidates may confuse branch retention policies (which are time-based cleanup rules) with the immediate deletion policy on PR completion, or assume a pipeline script is necessary when a built-in repository policy already exists.

How to eliminate wrong answers

Option B is wrong because a post-merge script in the pipeline can delete branches, but it requires custom code, runs only on pipeline execution, and may fail if the pipeline is skipped or the merge happens outside a build (e.g., via the web UI). Option C is wrong because training developers to delete branches manually relies on human compliance, which is unreliable and not an automated enforcement mechanism. Option D is wrong because branch retention policies in Azure Repos control how long branches are kept before automatic cleanup (e.g., after a set number of days), not immediate deletion upon merge to develop.

Full explanation →
778
MCQmedium

A company has a policy that all code changes must be reviewed by at least two people. However, for urgent bug fixes, they want to allow a single reviewer. How should they configure the branch policy?

A.Set minimum number of reviewers to 1 and require a separate approval from a manager
B.Set minimum number of reviewers to 2 and allow resetting code review votes on new pushes
C.Configure a build validation policy that checks number of approvals
D.Set minimum number of reviewers to 2, but allow policy override for urgent fixes
AnswerD

This allows the two-reviewer policy to be applied normally, while still permitting urgent fixes to be merged without two approvals; the override requires a justification and is logged for audit, balancing policy enforcement with operational flexibility.

Why this answer

Azure Repos branch policies allow you to set a minimum number of reviewers (e.g., 2) and then enable the 'Allow policy override' setting for urgent fixes. This lets authorized users bypass the two-reviewer requirement for critical bug fixes while maintaining the default policy for normal changes.

Exam trap

The trap here is that candidates often confuse 'policy override' with 'bypassing all policies' or think a build validation can count approvals, when in fact Azure Repos requires explicit permission-based override settings for urgent scenarios.

How to eliminate wrong answers

Option A is wrong because setting the minimum number of reviewers to 1 does not enforce the two-reviewer policy, and requiring a separate manager approval does not address the urgent fix scenario—it adds an extra approval step instead of allowing a single reviewer. Option B is wrong because setting minimum reviewers to 2 and allowing resetting votes on new pushes does not provide a mechanism to bypass the two-reviewer requirement for urgent fixes; it only resets approvals when new commits are pushed. Option C is wrong because a build validation policy checks build success, not the number of approvals; it cannot enforce or override reviewer count requirements.

Full explanation →
779
MCQmedium

Your build pipeline uses a self-hosted agent. The agent is running low on disk space. You need to clean up the agent's working directory after each build. Which option should you configure in the pipeline?

A.Set the 'Clean' option to 'Sources' in the pipeline settings.
B.Add a 'Delete Files' task at the end of the pipeline to delete the sources directory.
C.Add a 'Cleanup' task from the marketplace to clean the agent.
D.Use the 'clean' parameter in the checkout step of the YAML pipeline.
AnswerD

Correct: 'clean: true' cleans the working directory before checkout.

Why this answer

The `clean` parameter in the YAML checkout step is the native, built-in way to instruct the agent to delete the sources directory before or after the build. Setting `clean: true` or `clean: all` ensures the working directory is purged, directly addressing the low disk space issue without requiring additional tasks or marketplace extensions.

Exam trap

The trap here is that candidates often confuse the classic pipeline 'Clean' setting (which is a pre-build option) with the YAML `clean` parameter (which can be configured to run after the build), leading them to incorrectly select Option A.

How to eliminate wrong answers

Option A is wrong because the 'Clean' option set to 'Sources' in the classic pipeline settings only cleans the sources directory before the build starts, not after each build, and it does not apply to YAML pipelines. Option B is wrong because adding a 'Delete Files' task at the end of the pipeline is an extra, non-native step that can fail if the agent lacks permissions or if the sources directory is locked, and it is not the standard or recommended approach for cleaning the working directory. Option C is wrong because a 'Cleanup' task from the marketplace is unnecessary overhead; the built-in `clean` parameter in the checkout step provides the same functionality without relying on external extensions.

Full explanation →
780
MCQhard

Your release pipeline uses Azure Kubernetes Service (AKS) and Helm charts. You need to roll back to a previous release quickly if the new release fails health checks. What is the BEST approach?

A.Manually redeploy the previous Helm chart version.
B.Use a canary deployment strategy.
C.Use Helm rollback command.
D.Use a Kubernetes Deployment rollout undo.
AnswerC

The Helm rollback command is the correct approach because Helm maintains an ordered release history for each release name, with every deployment sequence stored as an immutable revision that includes the rendered manifests, values, and metadata. Executing `helm rollback <RELEASE> <REVISION>` instructs Helm to perform an in-place upgrade using the exact templates and values from that prior revision, thereby reinstating the known-good configuration atomically and quickly. This operation is fully tracked by Helm, incrementing to a new revision, so the release state and history remain internally consistent for subsequent upgrades or further rollbacks. Unlike manual redeployments or kubectl-level actions, Helm rollback does not require reconstructing old charts or reconciling drift—it simply reapplies the previously successful applied state.

Why this answer

Helm provides a built-in `helm rollback <release> <revision>` command that reverts a release to a previous revision in a single, atomic operation. This is the fastest and most reliable method for rolling back a failed Helm-based deployment on AKS, as it directly restores the exact Kubernetes manifests and configuration from the specified revision without manual intervention.

Exam trap

The trap here is that candidates confuse Kubernetes-native rollback (`kubectl rollout undo`) with Helm's release-level rollback, forgetting that Helm manages releases as a unit and that using `kubectl` directly breaks Helm's revision history and can leave the release in a broken state.

How to eliminate wrong answers

Option A is wrong because manually redeploying the previous Helm chart version is error-prone, slow, and requires the operator to locate and re-run the exact previous chart and values, which defeats the purpose of a quick rollback. Option B is wrong because a canary deployment strategy is a progressive delivery technique used to test a new release with a subset of traffic before full rollout, not a rollback mechanism; it does not revert a failed release but rather mitigates risk during rollout. Option D is wrong because `kubectl rollout undo` works on a Kubernetes Deployment object directly, but when using Helm, the Deployment is managed as part of a Helm release; using `kubectl rollout undo` bypasses Helm's release tracking, leading to state inconsistency between the Helm release history and the actual cluster state.

Full explanation →
781
MCQhard

Your Azure DevOps pipeline uses a self-hosted agent pool. You notice that builds are queuing for a long time. What is the most effective way to reduce queue times without incurring additional costs?

A.Allocate more parallel jobs to the agent pool.
B.Reduce the number of steps in the pipeline.
C.Increase the agent specification (e.g., from DS2 to DS4).
D.Switch to Microsoft-hosted agents to get more parallelism.
AnswerA

Allocating more parallel jobs to the self-hosted agent pool increases the maximum number of pipeline runs that can execute concurrently on that pool. Each parallel job consumes one agent slot; with additional parallel job capacity, more builds or releases can run at the same time, directly addressing a bottleneck caused by concurrency limits.

Why this answer

Allocating more parallel jobs to the self-hosted agent pool allows multiple pipelines or jobs to run concurrently, directly reducing queue times. This is achieved by adjusting the parallelism setting in the agent pool's properties, which does not incur additional costs as you are already paying for the self-hosted infrastructure.

Exam trap

The trap here is that candidates often confuse improving individual job performance (faster agents or fewer steps) with increasing parallelism. If the pool has idle agents but the parallelism limit is set too low, increasing the limit is a free way to reduce queue times. However, if the pool is actually saturated (all agents busy), increasing the parallelism setting alone will not help; you would need to add agents or optimize the pipeline.

How to eliminate wrong answers

Option B is wrong because reducing the number of steps in the pipeline may slightly decrease the duration of each build, but it does not address the root cause of queuing—insufficient concurrent execution capacity. Option C is wrong because increasing the agent specification (e.g., from DS2 to DS4) improves the speed of individual job execution but does not increase the number of jobs that can run simultaneously, so queue times remain unchanged. Option D is wrong because switching to Microsoft-hosted agents typically incurs additional costs for parallel jobs beyond the free tier, and the question explicitly requires no additional costs.

Full explanation →
782
MCQeasy

Your development team uses GitHub for source control. You want to automatically run a set of tests every time a pull request is opened against the main branch. What should you configure?

A.Create a GitHub Actions workflow triggered by pull_request events to main
B.Use the GitHub API to trigger tests when a PR is opened
C.Set up a webhook to trigger an external CI system
D.Configure a branch protection rule to require status checks
AnswerA

A GitHub Actions workflow with a `pull_request` trigger to `main` is the native, built-in CI/CD solution: it automatically runs any defined test jobs on every PR, and its resulting status checks integrate directly with GitHub’s branch protection and PR UI. This is the correct approach because no external service or custom listener is needed.

Why this answer

GitHub Actions natively supports the `pull_request` event trigger, which can be configured to run workflows automatically when a pull request is opened against a specific branch (e.g., `main`). This allows you to define a YAML-based workflow in the `.github/workflows` directory that executes tests on every PR event, providing immediate feedback to developers without requiring external services or manual API calls.

Exam trap

The trap here is that candidates often confuse branch protection rules (which enforce status checks) with the actual mechanism that triggers the tests, leading them to select Option D, but protection rules only block merges without initiating any automated testing.

How to eliminate wrong answers

Option B is wrong because using the GitHub API to trigger tests when a PR is opened would require custom polling or event handling logic, which is inefficient and not a built-in automation mechanism; GitHub Actions already provides a declarative event-driven trigger. Option C is wrong because setting up a webhook to trigger an external CI system is an alternative approach, but the question asks what you should configure, and GitHub Actions is the native, recommended solution for GitHub-hosted repositories, making this option less direct and more complex. Option D is wrong because configuring a branch protection rule to require status checks only enforces that checks must pass before merging, but it does not automatically trigger the tests; it is a policy enforcement mechanism, not a trigger mechanism.

Full explanation →
783
MCQhard

Your release pipeline deploys to multiple environments (Dev, QA, Prod) using approvals. You need to ensure that the deployment to Prod only proceeds if the deployment to QA succeeded and an approval is granted. Which combination of triggers and pre-deployment conditions should you configure?

A.Set the trigger on Prod to 'Automatic' and add a post-deployment approval on QA.
B.Set the trigger on Prod to 'After release' and add a pre-deployment approval on Prod.
C.Set the trigger on Prod to 'Manual only' and add a pre-deployment approval on Prod.
D.Set the trigger on Prod to 'After stage' and select QA as the stage, and add a pre-deployment approval on Prod.
AnswerD

Setting the Prod trigger to 'After stage' and selecting QA creates a dependency where the Prod deployment is queued only after the QA stage completes successfully, so a QA failure will prevent Prod from starting. Adding a pre-deployment approval on Prod then provides the required human authorization before the actual deployment, ensuring both QA success and an explicit approval gate.

Why this answer

It configures the Prod stage trigger to 'After stage' with QA selected as the preceding stage, ensuring that the release to Prod only starts after QA completes successfully. Adding a pre-deployment approval on Prod then enforces that a manual approval is granted before the deployment actually begins. This combination satisfies both conditions: dependency on QA success and required approval.

Exam trap

The trap here is that candidates often confuse 'After release' (which triggers based on release creation, not stage completion) with 'After stage' (which triggers based on a specific preceding stage's outcome), leading them to pick Option B or A without recognizing the need for explicit stage dependency.

How to eliminate wrong answers

Option A is wrong because setting the trigger on Prod to 'Automatic' would cause Prod to deploy immediately after the release is created, without waiting for QA to succeed, and a post-deployment approval on QA does not gate the Prod deployment. Option B is wrong because 'After release' trigger starts Prod after the release is created, not after QA completes, so it ignores the QA stage outcome. Option C is wrong because 'Manual only' trigger requires a manual start but does not enforce that QA must succeed first; the pre-deployment approval only adds an approval gate without the stage dependency.

Full explanation →
784
MCQeasy

You are configuring a release pipeline in Azure DevOps to deploy to multiple environments (dev, test, prod). You need to ensure that the production deployment requires manual approval from the release manager. What should you configure?

A.Set pre-deployment approvals on the production stage.
B.Add a manual intervention task before the production deployment.
C.Set post-deployment approvals on the test stage.
D.Use a condition on the production stage to check a variable.
AnswerA

Pre-deployment approvals on the production stage create a formal gate before the stage begins, requiring designated approvers to explicitly authorize the release. This is the correct mechanism because it applies to the entire stage, ensuring no production deployment occurs without human sign-off.

Why this answer

Pre-deployment approvals on the production stage enforce manual sign-off before any deployment to that environment begins. This ensures the release manager must explicitly approve the deployment, meeting the requirement for manual approval on production. Azure DevOps stages support pre-deployment and post-deployment approval gates, with pre-deployment being the correct choice for controlling when a stage starts.

Exam trap

The trap here is confusing a manual intervention task (which pauses within a stage) with a pre-deployment approval (which gates the start of a stage), leading candidates to incorrectly select the task-based option instead of the stage-level approval.

How to eliminate wrong answers

Option B is wrong because a manual intervention task is a step within a stage that pauses execution, but it does not prevent the stage from starting; the release would already have been deployed to the stage before the task runs, which does not satisfy the requirement to gate the production deployment itself. Option C is wrong because post-deployment approvals on the test stage control what happens after test completes, not before production starts; they cannot block the production deployment from beginning. Option D is wrong because a condition on the production stage to check a variable can control stage execution based on a variable value, but it cannot enforce manual human approval; it is an automated check, not a manual approval gate.

Full explanation →
785
MCQeasy

You are setting up a GitHub Actions workflow to deploy an Azure Resource Manager (ARM) template. The workflow must run whenever a pull request is opened against the main branch. Which trigger should you use?

A.pull_request: branches: [main] types: [opened]
B.pull_request_target: branches: [main]
C.workflow_dispatch
D.push: branches: [main]
AnswerA

This trigger fires automatically when a pull request targeting the main branch is opened, using the code from the pull request's merge commit rather than the base branch. It is the correct choice for deploying the ARM template proposed in the PR, because it runs as a pre-merge validation and uses the PR's changes.

Why this answer

The `pull_request` trigger with `branches: [main]` and `types: [opened]` ensures the workflow runs only when a pull request targeting the `main` branch is newly opened. This is the correct trigger for the stated requirement. Note that `pull_request` events from forks run with limited permissions and do not have access to repository secrets by default, which is a safety measure.

If secrets are required for deployment, additional configuration such as using `pull_request_target` (with caution) or environment-scoped secrets would be necessary, but the trigger itself remains `pull_request`.

Exam trap

Candidates often confuse `pull_request_target` with `pull_request`. `pull_request_target` runs in the context of the base repository and has access to secrets, but it should be used with extreme caution because it can be exploited via malicious PRs. `pull_request` is the standard, safer trigger for PR events and does not expose secrets to untrusted forks; however, it also does not allow access to secrets for fork PRs without additional mechanisms.

How to eliminate wrong answers

Option B is wrong because `pull_request_target` runs in the context of the base branch (main) with full write permissions and secret access, which is intended for safe handling of PRs from forks but is not the standard trigger for deploying ARM templates on PR open; it also lacks the `types: [opened]` filter, so it would run on all PR events (synchronize, reopened, etc.). Option C is wrong because `workflow_dispatch` requires manual triggering via the GitHub UI or API, not automatic execution when a PR is opened. Option D is wrong because `push: branches: [main]` triggers on direct commits or merges to main, not on pull request creation, so it would deploy after a merge rather than when the PR is opened.

Full explanation →
786
MCQeasy

Your organization wants to enforce that all commits to the main branch are signed using GPG or S/MIME. Which GitHub feature should you enable?

A.Use the GitHub API to check commit signatures after push.
B.Configure a branch protection rule that requires signed commits.
C.Enable the 'Include administrators' setting in branch protection.
D.Require SSH key authentication for all users.
AnswerB

Branch protection rules are evaluated during the push, and requiring signed commits causes GitHub to reject any push containing commits without a valid verified signature, thereby enforcing the policy before the commit is accepted. This is a preventive control at the repository level.

Why this answer

GitHub branch protection rules include a 'Require signed commits' setting that enforces all commits pushed to the protected branch must be signed with a verified GPG or S/MIME key. This ensures commit integrity and non-repudiation directly at the repository level, without requiring external scripts or API calls.

Exam trap

The trap here is that candidates confuse authentication (SSH keys) with commit signing (GPG/S/MIME), or assume that post-push API checks are equivalent to pre-merge enforcement.

How to eliminate wrong answers

Option A is wrong because using the GitHub API to check commit signatures after push is a reactive, custom workaround that does not prevent unsigned commits from being merged; it only audits them after the fact. Option C is wrong because the 'Include administrators' setting merely extends existing branch protection rules to admin users, but does not itself enforce signed commits. Option D is wrong because SSH key authentication only verifies the transport layer identity of the user, not the commit signature; commits can still be pushed without any signing.

Full explanation →
787
MCQhard

Refer to the exhibit. You receive a secret scanning alert for an Azure DevOps PAT in a GitHub repository. The push_protection_bypass is false. What does this mean and what action should you take?

A.The secret was pushed but push protection was bypassed; you need to revoke the PAT and use git filter-branch to remove it from history.
B.The secret was pushed successfully; you need to rotate the PAT and audit the commit history.
C.The secret was pushed and push protection was not bypassed; you need to open a support ticket with GitHub to remove the secret.
D.The secret was blocked from being pushed; you should revoke the PAT and investigate the incident.
AnswerD

The GitHub Secret Scanning push protection alert (with push_protection_bypass: false) confirms the push was rejected before any commit landed in the repository, so the PAT never exists in the commit history. Nevertheless, the PAT was transmitted to GitHub in the blocked push payload and should be treated as exposed, so revoking it is the immediate security action. Investigating the alert helps determine who attempted the push, which repo/branch was targeted, and whether the PAT was compromised elsewhere.

Why this answer

When `push_protection_bypass` is `false`, it means the secret was blocked from being pushed by GitHub's push protection feature. The alert indicates the secret was detected and prevented from entering the repository, so the correct action is to revoke the compromised PAT and investigate the incident to prevent future occurrences. Option D correctly identifies that the secret was blocked and prescribes the appropriate remediation steps.

Exam trap

The trap here is confusing `push_protection_bypass` with the secret being pushed successfully; candidates often assume `false` means the secret was allowed through, but it actually means the push was blocked.

How to eliminate wrong answers

Option A is wrong because `push_protection_bypass` is `false`, meaning push protection was NOT bypassed; the secret was blocked, not pushed. Option B is wrong because the secret was not pushed successfully; it was blocked, so rotating the PAT and auditing commit history is unnecessary and misinterprets the alert. Option C is wrong because while the secret was not bypassed, opening a support ticket with GitHub is not the correct action; the PAT should be revoked and the incident investigated, not escalated to support.

Full explanation →
788
MCQeasy

Your team uses Azure Pipelines to build and test code. You want to automatically trigger a pipeline when a pull request is created targeting the main branch. Which trigger should you configure?

A.PR trigger
B.Scheduled trigger
C.CI trigger
D.Manual trigger
AnswerA

PR trigger is the correct answer because Azure Pipelines automatically runs a pipeline when a pull request is created or updated in a branch, allowing validation of proposed changes before merge. It is ideal for verifying code in a feature branch that is the source of a pull request, ensuring the target branch remains stable.

Why this answer

A PR trigger is the correct choice because Azure Pipelines supports a 'pr' trigger that automatically starts a pipeline when a pull request is created targeting a specified branch (e.g., main). This is distinct from a CI trigger, which runs on commits to a branch, and is essential for validating changes before merging.

Exam trap

The trap here is that candidates often confuse CI triggers with PR triggers, assuming a CI trigger on the target branch will run for PRs, but CI triggers only fire on direct pushes, not on PR creation events.

How to eliminate wrong answers

Option B is wrong because a scheduled trigger runs pipelines on a time-based schedule (e.g., nightly), not in response to pull request creation. Option C is wrong because a CI trigger runs when code is pushed to a branch, not when a pull request is created; it does not differentiate between direct commits and PRs. Option D is wrong because a manual trigger requires a user to explicitly start the pipeline via the Azure DevOps UI or API, providing no automation for PR events.

Full explanation →
789
MCQeasy

A developer reports that their Azure DevOps pipeline is failing with 'Access denied' when trying to push to a protected branch. The branch policy requires a successful build and approval from the 'Code Owners' group. The developer is a member of 'Contributors' but not 'Code Owners'. What is the most likely cause?

A.The branch name contains invalid characters.
B.The pipeline's service principal lacks 'Create Branch' permission.
C.The developer lacks 'Contribute' permissions at the project level.
D.The developer is not in the 'Code Owners' group allowed to bypass the policy.
AnswerD

Azure DevOps branch policies provide a checkbox called 'Allow bypassing of branch policy' that can be granted to specific security groups, commonly a 'Code Owners' group. If the developer is not a member of that allowed group, the Git server rejects their push with an error like 'Denied by branch policy'. Because the push never reaches the remote, the CI pipeline never triggers, so the developer sees a failed build—rather than a missing 'Contribute' right or a pipeline service principal issue.

Why this answer

The branch policy requires membership in the 'Code Owners' group to push directly to the branch. The developer is not a member, so they get 'Access denied'. Option A (invalid characters) would cause a different error.

Option B (pipeline service principal lacking permission) is unrelated to the developer's push. Option C (lacking 'Contribute' permissions at project level) is less specific and would result in a different error; the error here is specifically due to branch policy enforcement.

Full explanation →
790
Multi-Selectmedium

Which THREE steps are essential when customizing an Azure DevOps process?

Select 3 answers
A.Use Hosted XML process model to customize.
B.Add custom fields to work item types.
C.Directly modify the 'Agile' system process.
D.Create an inherited process from an existing system process.
E.Add custom work item types to the process.
AnswersB, D, E

Adding custom fields to work item types is essential because it enables teams to capture, query, and report on project-specific data that is not covered by the default system fields, supporting more tailored workflow and metrics.

Why this answer

Customizing work item types by adding custom fields is a fundamental step in tailoring Azure DevOps processes to capture project-specific data. This is done through the inherited process model, which allows you to extend system processes without modifying the base definitions, ensuring upgrades and maintenance remain supported.

Exam trap

The trap here is that candidates often confuse the deprecated Hosted XML model with the current Inheritance model, or mistakenly think they can edit system processes directly, leading them to select options A or C instead of recognizing that only inherited processes support customization.

Full explanation →
791
MCQeasy

Your team needs to automatically run a pipeline whenever a pull request is created in GitHub. Which trigger should you configure in Azure Pipelines?

A.Pipeline completion trigger
B.Scheduled trigger
C.Pull request trigger
D.Continuous integration trigger
AnswerC

A pull request trigger automatically runs a pipeline whenever a pull request is created, updated, or reopened against the target branch, enabling validation of the proposed changes before merge. This directly matches the requirement to run a pipeline whenever a PR is created, making it the correct choice.

Why this answer

Azure Pipelines provides a dedicated pull request trigger that automatically starts a pipeline when a pull request is created or updated in GitHub. This trigger validates proposed changes before merging, ensuring code quality and preventing broken builds from entering the main branch.

Exam trap

The trap here is that candidates often confuse the continuous integration trigger (which runs on branch pushes) with the pull request trigger, failing to recognize that CI triggers do not activate on pull request creation events unless the PR branch is also pushed to, which is not the same as the PR event itself.

How to eliminate wrong answers

Option A is wrong because a pipeline completion trigger starts a pipeline when another pipeline finishes, not in response to a GitHub pull request event. Option B is wrong because a scheduled trigger runs pipelines at specified times (e.g., nightly builds) and cannot react to real-time pull request creation. Option D is wrong because a continuous integration trigger runs on pushes to branches (e.g., main or feature branches), not specifically on pull request creation; it would run on every commit push, not just when a PR is opened.

Full explanation →
792
Multi-Selecteasy

Which TWO are valid reasons to use a monorepo?

Select 2 answers
A.Smaller clone size compared to multiple repositories.
B.Simplifies code sharing and reuse across multiple projects.
C.Allows independent CI/CD pipelines for each project.
D.Improves security by isolating each project.
E.Simplifies dependency management and versioning.
AnswersB, E

Because all code lives in a single repository, projects can share internal libraries and components directly without needing to publish and consume separate packages from an external registry. This enables immediate reuse and atomic, cross-project changes in the same commit, which simplifies refactoring and speeds up development.

Why this answer

A monorepo centralizes all code in a single repository, making it straightforward to share common libraries, utilities, and components across multiple projects without needing separate package feeds or submodule references. Option E is correct because with all projects in one repo, dependency versions are unified and managed in a single set of manifest files (e.g., package.json, requirements.txt), eliminating cross-repo version drift and simplifying coordinated updates.

Exam trap

The trap here is that candidates confuse the theoretical benefits of isolation (C and D) with the practical reality of monorepos, which trade isolation for simplified sharing and unified versioning, while clone size (A) is actually larger, not smaller.

Full explanation →
793
MCQmedium

You are designing a release pipeline that deploys to multiple environments (dev, test, prod) with approval gates between each. You need to ensure that the same build artifact is deployed to all environments. Which strategy should you use?

A.Use a multi-stage YAML pipeline with a separate artifact for each stage.
B.Create a separate build pipeline for each environment to ensure environment-specific configurations.
C.Use a single build pipeline but trigger a new build for each environment.
D.Use a single build pipeline and promote the same build artifact through each environment.
AnswerD

Promoting the same artifact ensures consistency across environments.

Why this answer

Promoting the same build artifact through each environment ensures consistency and traceability. In Azure Pipelines, a single build produces one immutable artifact; deploying that same artifact across dev, test, and prod eliminates the risk of environment-specific build variations. Approval gates between stages control the promotion, while the artifact remains unchanged.

Exam trap

The trap here is that candidates confuse environment-specific configuration (which is handled by variable groups or pipeline variables) with the need for separate build artifacts, leading them to incorrectly select options that create multiple builds instead of promoting a single artifact.

How to eliminate wrong answers

Option A is wrong because using a separate artifact for each stage breaks the principle of deploying the same build across environments, introducing potential inconsistencies and making it impossible to guarantee that the exact same bits reach production. Option B is wrong because creating a separate build pipeline for each environment defeats the purpose of a unified release pipeline; it forces rebuilding for each environment, which can introduce different compilation results or dependency versions. Option C is wrong because triggering a new build for each environment means each environment receives a different artifact, violating the requirement to deploy the same build artifact to all environments.

Full explanation →
794
MCQmedium

Your team uses Azure Boards and wants to automate work item state transitions when code is merged. What should you use?

A.Azure Pipelines with 'Update work item' task
B.Branch policy in Azure Repos
C.GitHub + Azure Boards integration with automatic work item linking
D.Power Automate with Azure DevOps connector
AnswerC

The GitHub + Azure Boards integration automatically links GitHub commits and pull requests to Azure Boards work items when the commit or PR title includes the work item ID (e.g., 'AB#123'). When configured, it can also transition the linked work item to a 'Done' or 'Closed' state upon the merge of the PR, providing the desired automation directly from the merge event without additional pipeline tasks or services.

Why this answer

GitHub + Azure Boards integration, when configured with automatic work item linking, automatically transitions work items (e.g., from 'Active' to 'Resolved') when a pull request is merged. This is achieved through the integration's ability to detect commit messages or PR descriptions containing 'AB#{ID}' or 'Fixes AB#{ID}' patterns, which trigger state changes defined in the Azure Boards project configuration.

Exam trap

The trap here is that candidates often confuse the 'Update work item' task in Azure Pipelines (Option A) as a direct merge-triggered automation, but it requires a pipeline run, whereas the GitHub integration provides a simpler, event-driven solution without additional pipeline overhead.

How to eliminate wrong answers

Option A is wrong because the 'Update work item' task in Azure Pipelines runs during a build or release pipeline, not directly when code is merged; it requires a pipeline trigger on merge, which adds unnecessary complexity and delay. Option B is wrong because branch policies in Azure Repos enforce code review and build validation, but they do not have built-in functionality to update work item states; they only require a linked work item, not state transitions. Option D is wrong because Power Automate with Azure DevOps connector can automate work item updates, but it is an external orchestration tool that requires custom flow design and polling or triggers, not a native, seamless integration like GitHub + Azure Boards.

Full explanation →
795
MCQmedium

Your team uses GitHub Actions for CI/CD. You want to reuse a workflow across multiple repositories without duplicating code. Which approach should you use?

A.Store the workflow in a shared repository and use environment secrets to share credentials.
B.Create a reusable workflow in a central repository and reference it using 'uses: owner/repo/.github/workflows/workflow.yml@ref'.
C.Create a composite action and reference it from each workflow.
D.Create a workflow template in the organization's .github repository.
AnswerB

A reusable workflow is a YAML file in another repository that declares `on: workflow_call`, and it is referenced from a calling workflow using `uses: owner/repo/.github/workflows/workflow.yml@ref` where `ref` can be a branch, tag, or SHA. This allows centralized management of CI/CD logic, versioned reuse, and parameterized inputs/secrets across multiple repositories within your organization.

Why this answer

GitHub Actions supports reusable workflows that allow you to define a workflow in a central repository and reference it from other repositories using the 'uses' syntax with the format 'owner/repo/.github/workflows/workflow.yml@ref'. This eliminates code duplication while maintaining a single source of truth for the workflow logic, and the referenced workflow can be triggered by events in the caller repository.

Exam trap

The trap here is that candidates often confuse reusable workflows with composite actions or workflow templates. Reusable workflows allow you to reference a complete workflow (jobs/steps) from a central repository, but they do not define their own triggers; they are invoked via `workflow_call` from a caller workflow.

How to eliminate wrong answers

Option A is wrong because storing a workflow in a shared repository does not enable reuse without duplication; environment secrets only handle credential sharing, not workflow logic reuse, and you would still need to copy the workflow file into each repository. Option C is wrong because a composite action is designed to encapsulate a series of steps (a reusable action), not an entire workflow with triggers, jobs, and steps; it cannot define workflow-level events like 'on: push' or 'on: pull_request'. Option D is wrong because a workflow template in the organization's .github repository provides a starting point for new workflows but does not allow referencing an existing workflow from another repository; each repository must still maintain its own copy of the workflow file.

Full explanation →
796
Multi-Selecteasy

Which TWO of the following are benefits of using deployment slots in Azure App Service? (Select TWO.)

Select 2 answers
A.Automatic rollback on failure.
B.Independent scaling of each slot.
C.Zero-downtime deployments.
D.Validate changes in a staging environment before production.
E.Geographic redundancy.
AnswersC, D

By deploying to a staging slot and then performing a swap, you can instantly redirect production traffic to the new version with no downtime, as the swap operation is atomic and warm-up can be handled before the slot receives production traffic.

Why this answer

Deployment slots enable zero-downtime deployments (C) by allowing you to swap a staging slot with the production slot. The swap operation warms up the target slot's application before routing traffic, ensuring no requests are dropped. This is a core feature of Azure App Service for safe, continuous delivery.

Exam trap

The trap here is that candidates confuse the ability to swap slots with automatic rollback (A) or assume slots provide independent scaling (B), when in fact slots share the same plan and rollback requires manual intervention.

Full explanation →
797
Multi-Selecthard

Which TWO actions should a DevOps engineer take to ensure that Azure DevOps pipelines comply with the principle of least privilege for service connections?

Select 2 answers
A.Create a service principal with permissions scoped to the minimum required Azure resources.
B.Use the Project Collection Build Service account for all pipeline runs.
C.Use Workload identity federation to avoid managing secrets.
D.Configure the service connection to be available only to specific pipelines.
E.Use the same service connection for both build and release pipelines.
AnswersA, D

Creating a service principal with permissions scoped to the minimum required Azure resources enforces least privilege by granting the pipeline identity only the specific RBAC roles needed on targeted resource groups or services, preventing over-permissioning and reducing the attack surface if credentials are compromised.

Why this answer

Creating a service principal with permissions scoped to the minimum required Azure resources directly implements the principle of least privilege. By assigning only the necessary roles (e.g., Contributor on a specific resource group) to the service principal used in the service connection, you ensure that the pipeline can only perform actions on those resources, reducing the attack surface. This aligns with Azure RBAC best practices for securing automated deployments.

Exam trap

The trap here is that candidates often confuse 'Workload identity federation' (which improves secret management) with 'least privilege' (which is about permission scoping), leading them to select option C instead of recognizing that federation does not automatically restrict permissions.

Full explanation →
798
MCQmedium

Your team is migrating from TFVC to Git in Azure Repos. They want to preserve the history of all branches. Which migration tool should you use?

A.GitHub Importer
B.Azure DevOps Migration Tools
C.git-tfs tool
D.git-svn
AnswerC

Preserves history and branches.

Why this answer

The git-tfs tool is specifically designed to migrate TFVC repositories to Git while preserving full branch history, including changesets, branch relationships, and merge history. It bridges the gap between TFVC and Git by converting TFVC changesets into Git commits and mapping TFVC branches to Git branches, making it the correct choice for this migration scenario.

Exam trap

The trap here is that candidates often confuse git-tfs with git-svn, assuming both are interchangeable for any centralized-to-distributed migration, but git-tfs is TFVC-specific while git-svn is for Subversion, and Azure DevOps Migration Tools are for organizational data migration, not source control conversion.

How to eliminate wrong answers

Option A is wrong because GitHub Importer is used to import repositories from other Git hosts (like SVN, Mercurial, or another Git server) into GitHub, not from TFVC to Azure Repos. Option B is wrong because Azure DevOps Migration Tools are designed for migrating work items, test plans, and other Azure DevOps artifacts between organizations, not for converting TFVC source control history to Git. Option D is wrong because git-svn is a tool for bidirectional operation between Git and Subversion (SVN), not for TFVC migration.

Full explanation →
799
MCQmedium

Your team uses GitHub with a monorepo containing frontend and backend code. You need to implement a strategy where changes to the frontend folder trigger a frontend CI pipeline, changes to the backend folder trigger a backend CI pipeline, and changes to both trigger both. You also want to ensure that pull requests include changes only to one area to reduce complexity. What should you do?

A.Use CODEOWNERS to assign different reviewers for frontend and backend, and rely on manual pipeline triggers.
B.Configure separate CI pipelines with path filters so that each pipeline triggers only on changes to its respective folder.
C.Create branch policies that require specific builds based on the branch name.
D.Use a single pipeline that runs all tests on every change.
AnswerB

Path filters allow conditional triggering.

Why this answer

GitHub Actions and Azure Pipelines support path filters (e.g., `paths` in YAML triggers) that allow you to define separate CI pipelines for frontend and backend folders. When a pull request includes changes to both folders, both pipelines automatically trigger, satisfying the requirement. This approach ensures that each pipeline runs only when its relevant code changes, reducing unnecessary builds and complexity.

Exam trap

The trap here is that candidates may think branch policies or CODEOWNERS can control pipeline triggers, but only path filters in the pipeline YAML definition can conditionally start a pipeline based on which files changed.

How to eliminate wrong answers

Option A is wrong because CODEOWNERS only assigns reviewers based on file paths, not pipeline triggers, and relying on manual pipeline triggers defeats the purpose of CI automation. Option C is wrong because branch policies that require specific builds based on branch name cannot differentiate between frontend and backend changes within the same branch; they apply to all changes on that branch. Option D is wrong because a single pipeline that runs all tests on every change would not differentiate between frontend and backend changes, violating the requirement to trigger separate pipelines based on the changed folder.

Full explanation →
800
MCQhard

Your company uses Azure DevOps and has a large monorepo with multiple teams. Developers report that Git operations are slow due to the repository size. Which approach should you recommend to improve performance while maintaining a single repository?

A.Use Git LFS to store all files
B.Split the monorepo into multiple smaller repositories
C.Add a .gitattributes file with filter directives
D.Enable sparse checkout and shallow fetch
AnswerD

Sparse checkout restricts the working tree to only the directories or files you actually need, reducing checkout time and disk usage. Shallow fetch with a depth limit downloads only the most recent commits, drastically reducing the number of objects transferred; combined, these are the standard Git techniques to speed up work with a large monorepo.

Why this answer

Sparse checkout and shallow fetch are designed to improve Git performance in large monorepos by limiting the working tree to specific directories (sparse checkout) and reducing the history depth (shallow fetch). This keeps the repository intact as a single unit while significantly reducing the amount of data transferred and stored locally, directly addressing the slow Git operations without breaking the monorepo structure.

Exam trap

The trap here is that candidates often confuse performance improvements with repository restructuring, assuming that splitting the repo (Option B) is the only way to speed up Git, when Azure DevOps supports native Git features like sparse checkout and shallow fetch that preserve the monorepo architecture.

How to eliminate wrong answers

Option A is wrong because Git LFS is intended for large binary files, not for improving general Git performance on a large monorepo; storing all files in LFS would introduce overhead and break normal Git workflows. Option B is wrong because splitting the monorepo into multiple smaller repositories violates the requirement to maintain a single repository. Option C is wrong because .gitattributes with filter directives is used for custom smudge/clean filters (e.g., for Git LFS or keyword expansion), not for reducing the size or history of the repository to speed up operations.

Full explanation →
801
MCQhard

Your team uses a Git flow branching strategy with develop and release branches. You want to enforce that only release branches can be merged into main, and all merges into main require a successful deployment to a production-like environment. How should you implement this in Azure Pipelines?

A.Branch policy with required reviewers for main
B.Required status check for 'Check for linked work items'
C.YAML pipeline with environment approvals and branch filters on trigger
D.Build validation policy on main
AnswerC

Environment approvals enforce manual sign-off, and branch filters ensure only release branches trigger deployment.

Why this answer

A YAML pipeline with environment approvals can require manual approval for deployment to a production-like environment, ensuring only successful deployments from a production-like environment allow merges. Branch filters on triggers can restrict pipeline execution to only release branches, preventing other branches from triggering the pipeline that leads to main. Option A is wrong because branch policies with required reviewers only enforce PR review requirements, not deployment or branch source restrictions.

Option B is wrong because the 'Check for linked work items' status check ensures work items are linked but does not enforce branch restrictions or deployment validation. Option D is wrong because build validation runs on PR creation but does not enforce environment approvals or restrict the source branch to release branches only.

Full explanation →
802
MCQmedium

Refer to the exhibit. You are reviewing an ARM template used in an Azure Pipeline deployment. Which security concern should you address?

A.The VM size is too small for production
B.The apiVersion is outdated
C.The admin password is hardcoded in the template
D.The location parameter has a default value
AnswerC

Hardcoding the admin password as a plaintext string in the ARM template or its default parameters exposes the secret to anyone with read access to the source repository or deployment history. The template should accept the password via a secureString parameter and reference an Azure Key Vault secret, or use a managed identity and guest configuration to set credentials without embedding them.

Why this answer

The admin password is hardcoded in plain text in the ARM template, which is a significant security vulnerability. Passwords should be stored securely using Azure Key Vault or referenced as secure parameters. Option A is incorrect because VM size is not a security concern.

Option B is incorrect because the apiVersion is valid. Option D is incorrect because a default value for location is acceptable.

Full explanation →
803
Multi-Selecthard

You are creating a YAML pipeline that builds a .NET Core application. The pipeline must use a multi-stage build with separate stages for 'Build', 'Test', and 'Deploy'. The 'Deploy' stage should only run if both 'Build' and 'Test' succeed. Which two conditions can you use to achieve this? (Select all that apply.)

Select 2 answers
A.In the Deploy stage, set 'dependsOn: [Build, Test]'
B.In the Deploy stage, set 'condition: and(succeeded('Build'), succeeded('Test'))'
C.In the Deploy stage, set 'condition: succeeded()' and 'dependsOn: [Build, Test]'
D.In the Deploy stage, set 'dependsOn: [Build, Test]' and 'condition: stageDependencies.Build.result == 'Succeeded''
AnswersA, C

Setting 'dependsOn: [Build, Test]' is correct because the default stage condition is 'succeeded()', which evaluates to true only if all explicitly listed dependency stages (Build and Test) complete successfully. This ensures Deploy runs only after both stages succeed without requiring an explicit condition.

Why this answer

Setting 'dependsOn: [Build, Test]' in the Deploy stage ensures that the Deploy stage only starts after both the Build and Test stages have completed. By default, a stage runs only if all its dependencies succeed, so this alone meets the requirement without needing an explicit condition. This is the standard way to enforce sequential execution in multi-stage YAML pipelines.

Exam trap

The trap here is that candidates often confuse the 'succeeded()' function with the ability to check individual stage results, leading them to incorrectly select Option B, or they misremember the exact syntax for accessing stage dependencies in Option D.

Why the other options are wrong

B

This syntax is for job conditions; stage conditions do not accept string arguments for succeeded().

D

'stageDependencies' is not a valid expression; you would use 'dependencies.Build.result'.

Full explanation →
804
MCQmedium

Refer to the exhibit. You have this GitHub Actions workflow YAML. The workflow does not trigger when you push to the main branch. What is the most likely issue?

A.The branch name should be in a list under 'branches' inside 'push'.
B.The 'vmImage' should be 'windows-latest' for scripts.
C.The correct keyword is 'on', not 'triggers'.
D.The 'triggers' keyword is misspelled; it should be 'trigger'.
AnswerC

GitHub Actions uses the top-level `on` key to define the events that trigger a workflow, such as `push` or `pull_request`. The exhibit incorrectly uses `triggers`, which is not a recognized key in GitHub Actions syntax, causing the workflow to be invalid or never run.

Why this answer

GitHub Actions workflows use the `on` keyword to define triggers, not `triggers`. The YAML snippet incorrectly uses `triggers`, which is not a valid key in GitHub Actions syntax; the workflow engine ignores it, so no push event on `main` will start the workflow. This is a common syntax error where the candidate confuses Azure Pipelines (which uses `trigger`) with GitHub Actions (which uses `on`).

Exam trap

The trap here is that candidates familiar with Azure Pipelines might choose option D, thinking `triggers` is a misspelling of `trigger`, but GitHub Actions requires `on`, not `trigger`.

How to eliminate wrong answers

Option A is wrong because GitHub Actions allows a single string or a list under `branches`; a single string like `main` is valid, so the issue is not the format. Option B is wrong because `vmImage: 'ubuntu-latest'` is perfectly valid for running scripts; there is no requirement to use `windows-latest` for scripts. Option D is wrong because the keyword is not `trigger`; GitHub Actions uses `on`, not `trigger` or `triggers`, so the misspelling is irrelevant.

Full explanation →
805
MCQhard

Your release pipeline deploys to multiple environments (Dev, Test, Prod) using approval gates. Recently, the Prod deployment failed because a manual validation task timed out after 30 minutes. You need to ensure that if the manual validation is not approved within 15 minutes, the pipeline automatically rejects the deployment and sends a notification. What should you do?

A.Set the 'Timeout in minutes' for the entire stage to 15.
B.In the Manual Validation task, set 'Timeout' to 15 and 'On timeout' to 'Reject'.
C.Configure a pre-deployment approval with a timeout of 15 minutes.
D.Add a PowerShell task after the manual validation that checks the status and cancels the pipeline if not approved.
AnswerB

The Manual Validation task has a 'Timeout' property and an 'On timeout' action. By setting the timeout to 15 and 'On timeout' to 'Reject', if a user does not respond within 15 minutes, the task automatically rejects the deployment, which immediately stops the pipeline and marks the deployment as rejected. This is the only option that directly enforces the desired rejection on a per-validation basis.

Why this answer

The Manual Validation task has a 'Timeout' setting and an 'On timeout' option. Setting Timeout to 15 minutes and On timeout to 'Reject' will automatically reject the deployment if not approved within 15 minutes. Additionally, you can configure a notification using an Azure DevOps subscription or service hook for the rejection event.

Option A is incorrect because the stage timeout does not specifically handle manual validation rejection. Option C is incorrect because, although pre-deployment approvals do have a timeout that can reject on timeout, they apply to the approval gate before the stage, not to a manual validation task within the stage. Option D is incorrect because adding a PowerShell task is unnecessary and less reliable than the built-in timeout behavior.

Full explanation →
806
MCQeasy

Your team uses GitHub Flow for feature development. A developer commits directly to the main branch without creating a pull request. Which practice should you enforce to ensure code quality and prevent direct commits?

A.Require a manual sign-off from a team lead after each commit.
B.Configure branch protection rules on the main branch to require pull request reviews before merging.
C.Set up a .gitignore file to prevent certain file types from being committed.
D.Add a CODEOWNERS file that automatically assigns reviewers to any changes.
AnswerB

Configuring branch protection rules on the main branch to require pull request reviews before merging is correct because GitHub branch policies natively block direct pushes and enforce PR-based collaboration. By requiring at least one approved review, you integrate quality checks into the merge workflow, ensuring feature changes go through review before reaching the main branch—a core mechanism in GitHub Flow.

Why this answer

Branch protection rules prevent direct commits to the main branch and require pull requests with reviews. Option A is incorrect because manual sign-off is not enforceable. Option C is incorrect because a .gitignore file does not block commits or enforce branch policies.

Option D is incorrect because a CODEOWNERS file alone does not block direct commits.

Full explanation →
807
MCQmedium

You are implementing a release pipeline that deploys a web app to Azure App Service. The deployment must be approved by a manager before proceeding to the production slot. However, the manager is on leave and the deployment is critical. What should you do to ensure the deployment can proceed without delaying the release?

A.Skip the approval for this deployment by overriding the settings.
B.Add an additional approver in the pre-deployment approval settings.
C.Configure the approval to time out after 24 hours and automatically approve.
D.Remove the approval requirement from the pipeline.
AnswerB

Adding an additional approver in the pre-deployment approval settings ensures that if the primary approver is unavailable, a designated backup can review and approve the release, allowing the deployment to proceed without delay. This maintains the required human gate and auditability, unlike skipping or auto-approving, making it the correct approach to handle approver unavailability.

Why this answer

Adding an additional approver in the pre-deployment approval settings allows another authorized user (e.g., a backup manager or team lead) to approve the deployment while the primary manager is unavailable. This maintains the required governance and security controls without blocking the critical release. Azure Pipelines supports multiple approvers, and any one of them can approve to proceed.

Exam trap

The trap here is that candidates may think skipping or removing the approval is acceptable for a critical release, but Azure DevOps enforces governance; the correct approach is to add an additional approver to maintain control while enabling progress.

How to eliminate wrong answers

Option A is wrong because skipping the approval by overriding settings bypasses the required governance and security controls, which violates compliance policies and could lead to unauthorized deployments. Option C is wrong because configuring the approval to time out after 24 hours and automatically approve would cause an unacceptable delay for a critical release and still does not guarantee timely approval. Option D is wrong because removing the approval requirement from the pipeline permanently eliminates the approval gate for all future deployments, which is an overreaction and weakens the release governance.

Full explanation →
808
MCQhard

You are designing a release pipeline for a multi-tenant SaaS application that is deployed to Azure App Service. Each tenant has its own App Service instance. The pipeline must deploy a new version of the application to a staging slot for each tenant, run smoke tests, and then swap the staging slot to production. You need to ensure that if the smoke tests fail for any tenant, the swap is not performed for that tenant, while other tenants continue. Which release pipeline configuration should you use?

A.Create a release with multiple jobs (one per tenant) in the same stage, each deploying to a tenant's staging slot, running tests, and conditionally swapping. Set the 'Run this job' condition to 'Only when all previous jobs have succeeded' or use custom conditions to skip swap on failure.
B.Create a single stage with a 'foreach' loop over tenants, and if smoke tests fail, skip the swap using a condition.
C.Create a single job with parallel tasks for each tenant, and configure failure conditions to skip the swap.
D.Create a single stage with multiple deployment tasks, one per tenant, and use a 'continue on error' option on each task.
AnswerA

Multiple jobs can run in parallel, and each job can independently handle success/failure for its tenant.

Why this answer

It uses separate jobs per tenant within a single stage, each with its own deployment, smoke test, and conditional swap. By setting the 'Run this job' condition to 'Only when all previous jobs have succeeded' or a custom condition, you ensure that a failed smoke test for one tenant blocks only that tenant's swap, while other tenants' jobs proceed independently. This design aligns with Azure Pipelines' job-level isolation, where each job runs on its own agent and can have independent success/failure conditions.

Exam trap

The trap here is that candidates often confuse job-level parallelism with task-level parallelism, assuming that parallel tasks within a single job can achieve the same isolation, but in Azure Pipelines, tasks within a job share the same agent and failure context, so a single failure can halt all tenant deployments.

How to eliminate wrong answers

Option B is wrong because a 'foreach' loop over tenants within a single job would execute sequentially and a failure in one iteration would stop the entire loop, preventing other tenants from being processed. Option C is wrong because parallel tasks within a single job share the same agent and failure conditions; if one task fails, the entire job fails by default, blocking all tenants. Option D is wrong because 'continue on error' on each task allows the pipeline to continue after a failure, but it does not prevent the swap for the failed tenant; the swap task would still execute unless explicitly conditioned, and the pipeline would not isolate failures per tenant.

Full explanation →
809
Multi-Selecthard

Which THREE of the following are valid steps to implement a trunk-based development workflow in Azure Repos? (Select THREE.)

Select 3 answers
A.Run CI builds on the main branch.
B.Use feature flags and pair programming.
C.Merge to main only once per week.
D.Use short-lived feature branches that are merged within a day.
E.Create release branches for each production release.
AnswersA, B, D

Running CI builds on the main branch is a core trunk-based development practice: every commit to main must compile and pass automated tests, ensuring the integration point is always stable and deployable, which allows teams to merge frequently without accumulating integration debt.

Why this answer

Trunk-based development requires developers to integrate into the main branch frequently. In Azure Repos, you set a CI trigger on main so every commit is built and validated (A). Developers use short-lived feature branches that are merged into main within a day (D) to keep integration conflicts small.

Feature flags and pair programming are supporting practices that allow work to be integrated even before a feature is complete, avoiding long-running branches (B). Merging to main only once per week (C) contradicts the continuous-integration principle, and creating a release branch for every production release (E) is characteristic of GitFlow/release-flow, not trunk-based development.

Exam trap

The trap here is that candidates confuse trunk-based development with GitFlow or release-based branching strategies, leading them to select options like creating release branches or infrequent merges, which are antithetical to the trunk-based workflow's emphasis on continuous integration and minimal branching.

Full explanation →
810
MCQmedium

Refer to the exhibit. A developer pushes a commit to a branch named 'feature/new-login'. Which of the following will occur?

A.The pipeline will trigger and run all steps because the branch name does not match any exclude pattern.
B.The pipeline will not trigger because the branch is excluded.
C.The pipeline will trigger only the restore and build steps, skipping tests.
D.The pipeline will trigger but fail with an error because the branch is not in the include list.
AnswerB

The branch in question, e.g., 'feature/ex6lsa', falls under the exclude pattern 'feature/*', which indicates that any branch beginning with 'feature/' is excluded from triggering the pipeline. Therefore, pushing a commit to this branch will not start the pipeline, and no steps (restore, build, test) will execute. This is the expected behavior according to the branch filter configuration.

Why this answer

The trigger includes main and release/* branches, and explicitly excludes feature/* branches. Since 'feature/new-login' matches the exclude pattern 'feature/*', the pipeline will not trigger. The pipeline will only trigger for branches that match include patterns and do not match exclude patterns. 'feature/new-login' is excluded, so no build will start.

Full explanation →
811
MCQmedium

Refer to the exhibit. You are deploying this Bicep file using Azure Pipelines. The 'environment' parameter should be set to 'dev', 'qa', or 'prod' based on the release stage. How should you pass the parameter value?

A.Define the parameter in the 'parameters:' section of the YAML pipeline.
B.Set a pipeline variable named 'environment' and reference it in the AzureResourceManagerTemplateDeployment task's overrideParameters.
C.Use a task to replace the string '${environment}' in the Bicep file before deployment.
D.Modify the Bicep file to include a default value for environment.
AnswerB

The overrideParameters field in the AzureResourceManagerTemplateDeployment task accepts key-value pairs that override Bicep/ARM template parameters at deployment time. By setting a pipeline variable and referencing it like -environment $(environment), you dynamically supply the environment-specific value per stage, leveraging Azure DevOps native variable scoping.

Why this answer

The AzureResourceManagerTemplateDeployment task's `overrideParameters` property allows you to dynamically pass parameter values at deployment time. By setting a pipeline variable named `environment` (which can be scoped per stage) and referencing it as `$(environment)` in `overrideParameters`, you can inject the correct value ('dev', 'qa', or 'prod') based on the release stage without modifying the Bicep file or its defaults.

Exam trap

The trap here is that candidates confuse YAML pipeline parameters (defined with `parameters:`) with Bicep file parameters, or assume that modifying the Bicep file's default value is a valid dynamic override, when in fact `overrideParameters` is the intended mechanism for stage-specific value injection.

How to eliminate wrong answers

Option A is wrong because the `parameters:` section in a YAML pipeline defines pipeline-level parameters (e.g., for manual triggers or template inputs), not runtime overrides for a Bicep file's parameters; it cannot pass values directly to the ARM deployment task's `overrideParameters`. Option C is wrong because string replacement in the Bicep file before deployment is an unnecessary and fragile workaround; Bicep files are compiled to ARM templates, and the proper way to supply parameter values is via the deployment task's `overrideParameters` or parameter file. Option D is wrong because adding a default value to the Bicep file would fix the parameter to a single value (e.g., 'dev') and prevent dynamic assignment per stage, which defeats the purpose of stage-specific overrides.

Full explanation →
812
MCQhard

Your Azure DevOps pipeline deploys to multiple environments. You want to require manual approval before production deployment, but only if the deployment originated from a branch other than 'main'. How can you implement this?

A.Set a pre-deployment approval on the production environment
B.Configure a deployment group with approval gates
C.Use a branch policy that requires approval for non-main branches
D.Add a manual validation task with a condition: ne(variables['Build.SourceBranch'], 'refs/heads/main')
AnswerD

Add a manual validation task with a condition: This is the correct method. However, the condition in the option uses `eq` instead of `ne`, which would trigger approval for main branches. When corrected to `ne(variables['Build.SourceBranch'], 'refs/heads/main')`, it pauses the pipeline for approval only when the source branch is not main, fulfilling the requirement.

Why this answer

To require manual approval only for non-main branches, add a manual validation task to the production deployment job with a condition checking that the source branch is not main: `ne(variables['Build.SourceBranch'], 'refs/heads/main')`. This pauses the pipeline and waits for approval. Pre-deployment approvals (A) cannot be conditional on branch, and deployment groups (B) are not for manual approval.

Branch policies (C) do not apply to pipeline stages.

Exam trap

The trap is to use the condition `eq` instead of `ne`, which would require approval on main branches instead of non-main branches. Pre-deployment approvals (option A) are unconditional and cannot be scoped to branch conditions.

How to eliminate wrong answers

Option A is wrong because a pre-deployment approval on the production environment applies to ALL deployments to that environment, regardless of the source branch, and cannot be conditionally applied based on branch. Option B is wrong because deployment group approval gates are used for controlling deployments to physical or virtual machines in a deployment group, not for conditional branch-based approvals in multi-environment pipelines. Option C is wrong because branch policies apply to pull requests and code changes in the repository, not to pipeline deployment approvals; they cannot gate a release pipeline's deployment step.

Full explanation →
813
MCQeasy

You need to ensure that only approved users can deploy to production from Azure Pipelines. What should you implement?

A.Pipeline approval gates
B.Microsoft Entra ID Conditional Access policies
C.Environment checks with required approvers
D.Branch protection rules in GitHub
AnswerC

In Azure Pipelines, an environment acts as a container for deployment targets and supports checks that control entry before a job executes. Adding an Approvals check to the Production environment lets you designate specific users or groups as required approvers; when a pipeline tries to deploy to that environment, the run pauses until one of those approvers explicitly approves or rejects the deployment. This is the native, supported mechanism that ensures only approved users can authorize releases to production, and it can be combined with other checks like branch control or time windows.

Why this answer

Azure Pipelines environment checks with required approvers allow you to enforce that only specific users or groups can approve deployments to a production environment. This is a native Azure DevOps feature that integrates with pipeline stages to gate deployments based on manual approval, ensuring that unauthorized users cannot trigger or approve production releases.

Exam trap

The trap here is that candidates often confuse pipeline approval gates (which are checks like monitoring or security scans) with environment-level required approvers (which are manual approval steps), leading them to select option A instead of C.

How to eliminate wrong answers

Option A is wrong because pipeline approval gates are a broader concept that can include manual approval checks, but they are not specifically designed to restrict which users can deploy to production; they are more about adding checks before a stage runs. Option B is wrong because Microsoft Entra ID Conditional Access policies control access to Azure resources and applications based on conditions like location or device compliance, but they do not directly integrate with Azure Pipelines to restrict who can approve or execute a deployment. Option D is wrong because branch protection rules in GitHub protect branches from direct pushes or merges without review, but they do not control who can deploy from Azure Pipelines to a production environment; they are a source control mechanism, not a deployment approval mechanism.

Full explanation →
814
Multi-Selectmedium

Which TWO are benefits of using deployment groups in Azure Pipelines compared to using individual virtual machines?

Select 2 answers
A.Built-in secrets management for connection strings.
B.Reduced cost because VMs are shut down when not in use.
C.Automatic scaling of virtual machines based on load.
D.Simplified targeting of multiple machines with a single pipeline run.
E.Rolling deployment support with health checks.
AnswersD, E

Deployment groups group machines together for parallel deployment.

Why this answer

Deployment groups in Azure Pipelines allow you to target multiple machines with a single pipeline run by logically grouping them, enabling parallel or rolling deployments across all machines in the group. This simplifies management compared to configuring each individual VM separately in the pipeline, as you can define the group once and reuse it across releases.

Exam trap

The trap here is confusing deployment groups with Azure VM scale sets, leading candidates to incorrectly associate automatic scaling or cost-saving shutdown features with deployment groups, when those are separate Azure services.

Full explanation →
815
MCQhard

You are a DevOps engineer for a financial services company with strict regulatory compliance requirements (e.g., PCI-DSS, SOX). The company uses Azure DevOps for CI/CD and manages multiple projects. Each project has its own set of service connections, variable groups, and agent pools. The security team recently audited the environment and found that several service connections have been granted Contributor rights at the subscription level, and some variable groups are accessible by all pipelines across all projects. Additionally, audit logs show that a former employee's service principal still has active service connections in two projects. You need to implement a security and compliance plan to address these issues. Which approach should you take?

A.Conduct a manual audit of all service connections and variable groups every quarter, and revoke any permissions that are not needed. Disable service connections associated with the former employee.
B.Immediately delete all service connections associated with the former employee and recreate them using service principals with the least privilege. Then, update all pipelines to use the new connections.
C.Restrict all service connections to use resource-group level scoped permissions instead of subscription-level. For variable groups, set them to be accessible only to specific pipelines.
D.Implement Azure Policy to enforce that service connections cannot have subscription-level Contributor role; instead, require specific resource group roles. Use Azure AD access reviews to automatically remove stale service principals. Use pipeline decorators to enforce branch policy and approval checks on variable groups that contain secrets.
AnswerD

This answer combines three complementary Azure native controls that together provide preventive, detective, and corrective governance. Azure Policy continuously audits and denies role assignments that grant subscription-level Contributor to service connections, enforcing least privilege automatically across all resources. Azure AD access reviews periodically evaluate service principal usage and automatically remove or disable stale principals, eliminating orphaned credentials like the former employee's. Pipeline decorators inject pre-execution steps into every pipeline run, enforcing branch policies and mandatory approval checks whenever a variable group containing secrets is referenced, even if the pipeline YAML does not explicitly include those checks.

Why this answer

It provides a comprehensive, automated, and scalable approach to enforcing least privilege and compliance. Azure Policy can audit and enforce that service connections are scoped to resource groups rather than subscriptions, preventing over-permissioned Contributor access. Azure AD access reviews automate the detection and removal of stale service principals, addressing the former employee issue without manual effort.

Pipeline decorators enforce mandatory approval checks and branch policies on variable groups containing secrets, ensuring that sensitive variables are not accessible to all pipelines across projects.

Exam trap

The trap here is that candidates often choose a manual or reactive approach (like Option A or B) because they focus on the immediate fix for the former employee, overlooking the need for automated, continuous enforcement that Azure Policy, access reviews, and pipeline decorators provide for long-term compliance.

How to eliminate wrong answers

Option A is wrong because a manual quarterly audit is reactive, error-prone, and does not scale across multiple projects; it fails to meet the strict regulatory compliance requirements that demand continuous enforcement. Option B is wrong because immediately deleting all service connections associated with the former employee could break running pipelines and does not address the root cause of over-permissioned service connections or variable group accessibility; it also lacks automation for ongoing compliance. Option C is wrong because restricting service connections to resource-group level scopes is a partial fix that does not enforce the change across existing connections, and setting variable groups to be accessible only to specific pipelines is a manual configuration that does not prevent future misconfigurations or provide audit trails.

Full explanation →
816
MCQeasy

You need to automatically create a work item in Azure Boards when a GitHub issue is opened. What is the most efficient way to achieve this?

A.Install the GitHub + Azure Boards integration
B.Create a GitHub Action that calls Azure DevOps REST API
C.Use Azure Pipelines with a GitHub trigger
D.Configure a webhook in GitHub to Azure DevOps
AnswerA

The GitHub + Azure Boards integration is a native, two-way sync that automatically creates and links Azure Boards work items from GitHub commits, branches, and pull requests, and can be configured to create work items from GitHub issues. This is the official, supported method that requires no custom code and provides rich traceability between GitHub and Azure Boards.

Why this answer

The official GitHub + Azure Boards integration provides automatic two-way syncing between GitHub issues and Azure Boards work items. This requires minimal configuration and no custom code. Option B requires writing a GitHub Action and calling the Azure DevOps REST API, which is more complex.

Option C involves using Azure Pipelines, which is not designed for this purpose. Option D involves manually configuring a webhook, which is less streamlined than the integration.

Full explanation →
817
Multi-Selecthard

Which THREE components are required to set up a self-hosted agent pool in Azure Pipelines?

Select 3 answers
A.The agent software installed on the target machine
B.A deployment group target
C.The agent pool name and URL of the Azure DevOps organization
D.Azure VM extension for Azure Pipelines Agent
E.A personal access token (PAT) for authentication
AnswersA, C, E

The agent software is essential for the self-hosted agent.

Why this answer

The self-hosted agent requires the Azure Pipelines agent software to be installed on the target machine. This software, which includes the agent listener and worker processes, is what registers the machine with the agent pool and executes pipeline jobs. Without the agent software, the machine cannot communicate with Azure Pipelines or run any tasks.

Exam trap

The trap here is that candidates often confuse the Azure VM extension (a convenience tool) with a mandatory requirement, or they mistakenly think a deployment group target is needed for agent pools, when in fact deployment groups are for targeting specific machines in a release context, not for agent registration.

Full explanation →
818
MCQmedium

You are using Microsoft Defender for Cloud to secure Azure Pipelines. You need to receive alerts when a pipeline run uses a service principal with excessive permissions. Which feature should you enable?

A.Enable Azure DevOps audit logs and review them manually.
B.Create an Azure Policy to deny over-privileged service principals.
C.Enable Microsoft Defender for Cloud's identity and access monitoring.
D.Configure Microsoft Entra ID Conditional Access policies.
AnswerC

Enabling Microsoft Defender for Cloud's identity and access monitoring activates continuous analysis of Azure AD identities and service principals, including their sign-in patterns, permissions, and usage anomalies. This feature leverages Microsoft Defender for Identity sensors to detect risky behaviors such as suspicious service principal credential usage and over-permissioned resource access, and it emits real-time security alerts. That gives the team the required detection and response capability for identity-based threats in Azure Pipelines.

Why this answer

Microsoft Defender for Cloud's identity and access monitoring continuously assesses the permissions of service principals used in Azure Pipelines and generates alerts when it detects over-privileged or anomalous usage. This feature is specifically designed to identify excessive permissions in real-time, enabling proactive security responses without manual log review or policy enforcement.

Exam trap

The trap here is that candidates often confuse Azure Policy (which enforces resource compliance) with identity monitoring (which detects permission misuse), leading them to select Option B instead of the correct identity-focused alerting feature.

How to eliminate wrong answers

Option A is wrong because manually reviewing Azure DevOps audit logs is reactive and does not provide automated, real-time alerts for over-privileged service principals; it requires constant human oversight. Option B is wrong because Azure Policy can enforce compliance on Azure resources but cannot directly deny or monitor pipeline runs that use over-privileged service principals; it operates at the resource management layer, not the pipeline execution layer. Option D is wrong because Microsoft Entra ID Conditional Access policies control authentication and access to applications based on conditions like location or device state, but they do not evaluate the permissions of service principals within Azure Pipelines or generate alerts for excessive privileges.

Full explanation →
819
MCQeasy

Your team uses GitHub Actions for CI/CD. You need to ensure that secrets are not exposed in build logs. What should you use?

A.Hardcoded values in the workflow YAML
B.Environment variables in the workflow
C.GitHub Secrets
D.Artifact storage
AnswerC

GitHub Secrets are the correct way to store sensitive data because they are encrypted at rest and only decrypted for the specific actions or workflows that reference them. Secrets are automatically masked in logs, preventing accidental exposure, and they support environment-based scoping for granular access control. This ensures credentials and API tokens remain protected throughout the CI/CD pipeline.

Why this answer

GitHub Secrets (Option C) is the correct choice because GitHub Actions provides a built-in encrypted secrets store that automatically masks secret values in build logs. When you reference a secret using `${{ secrets.MY_SECRET }}`, GitHub ensures the value is never printed or exposed in workflow output, unlike plaintext or environment variables that can be inadvertently logged.

Exam trap

The trap here is that candidates often confuse environment variables (which can be set in the workflow YAML) with GitHub Secrets, not realizing that environment variables are not automatically masked and can leak in logs, whereas GitHub Secrets are specifically designed for secure injection and automatic log redaction.

How to eliminate wrong answers

Option A is wrong because hardcoded values in the workflow YAML are stored as plaintext in the repository, visible to anyone with read access and exposed in logs if the workflow prints them. Option B is wrong because environment variables defined in the workflow YAML (e.g., `env: MY_VAR: value`) are not automatically masked; if a step echoes the variable or an error message includes it, the value appears in plaintext in the logs. Option D is wrong because artifact storage is used to persist build outputs (e.g., compiled binaries, test results) between jobs, not to securely store or inject secrets at runtime.

Full explanation →
820
MCQmedium

A company uses Azure DevOps for CI/CD. They have a multi-stage YAML pipeline that builds a Java application, runs unit tests, and deploys to a test environment. The test environment uses an Azure SQL Database. The pipeline currently runs successfully but the team notices that the test database schema is not always up-to-date. They want to apply database migrations automatically as part of the pipeline. Which tool or task should they integrate?

A.Use the Azure SQL Database deployment task to run a SQL script manually.
B.Use Azure SQL Database backup and restore to update the schema.
C.Add a PowerShell task that runs SQLCMD.
D.Integrate Flyway or similar database migration tool in the pipeline.
AnswerD

Integrating Flyway or a similar database migration tool gives the pipeline a versioned, repeatable way to manage schema changes. Flyway tracks applied migrations in a metadata table, applies scripts in order, and supports incremental upgrades and rollback, ensuring the database schema is synchronized with application code automatically as part of CI/CD.

Why this answer

Flyway is a dedicated database migration tool that integrates seamlessly with Azure DevOps pipelines, allowing you to version-control and apply schema changes automatically. Unlike ad-hoc scripts, Flyway tracks which migrations have been applied, ensuring the test database schema is always up-to-date without manual intervention.

Exam trap

The trap here is that candidates may think any SQL execution task (like SQLCMD or the Azure SQL task) is sufficient for schema updates, overlooking the critical need for version control, state tracking, and repeatability that dedicated migration tools provide.

How to eliminate wrong answers

Option A is wrong because the Azure SQL Database deployment task is designed for deploying a DACPAC or running a single SQL script, but it does not provide versioning or incremental migration tracking, so it cannot reliably keep the schema up-to-date across multiple changes. Option B is wrong because backup and restore is a data recovery operation, not a schema migration strategy; it would overwrite the entire database rather than applying incremental schema changes. Option C is wrong because a PowerShell task running SQLCMD can execute arbitrary SQL scripts, but it lacks migration state management, rollback capabilities, and version control, making it error-prone and non-repeatable for continuous schema updates.

Full explanation →
821
Multi-Selectmedium

Your release pipeline deploys a web app to Azure App Service. You need to implement safe deployment practices that minimize downtime and enable quick rollback. Which THREE strategies should you recommend?

Select 3 answers
A.Deploy to a staging slot first, validate, then swap.
B.Use rolling deployment with manual step to approve each instance.
C.Deploy directly to the production slot.
D.Configure monitoring and alerts to trigger automatic rollback if error rate increases.
E.Use deployment slots with swap and auto-swap.
AnswersA, D, E

Staging slot allows testing before production.

Why this answer

Deploying to a staging slot first allows you to validate the application in a production-like environment without affecting live traffic. Once validated, swapping the staging and production slots ensures zero-downtime deployment by instantly routing all traffic to the validated version. This is a core safe deployment practice for Azure App Service.

Exam trap

The trap here is that candidates often confuse 'rolling deployment' (which is a valid strategy for virtual machine scale sets) with Azure App Service's slot-based swap, and they may incorrectly think manual approval per instance is a safe practice when it actually breaks automation and consistency.

Full explanation →
822
MCQmedium

Your company uses Microsoft Teams for collaboration. You want to send notifications to a Teams channel whenever a build pipeline in Azure Pipelines fails. Which approach should you use?

A.Configure an email subscription in Azure DevOps to send alerts to the Teams channel email address.
B.Set up a webhook in Azure DevOps to post to the Teams channel's incoming webhook URL.
C.Install the Azure Pipelines app for Microsoft Teams and subscribe the channel to pipeline notifications.
D.Use the 'Post to a Microsoft Teams channel' task in the pipeline.
AnswerC

The Azure Pipelines app for Microsoft Teams is the official integration that lets you subscribe a channel to pipeline events, such as completed builds and releases, failed jobs, and pending approvals. It uses the Teams bot framework to deliver structured, interactive cards and does not require custom code, webhook secrets, or manual service hook construction, making it the recommended and simplest setup.

Why this answer

The Azure Pipelines app for Microsoft Teams provides built-in integration to subscribe to pipeline events and send notifications to channels. Option A is incorrect because email subscriptions are separate. Option B is incorrect because webhooks require custom configuration.

Option D is incorrect because the Teams connector is deprecated in favor of the app.

Full explanation →
823
MCQmedium

Refer to the exhibit. A build pipeline fails with this error. What is the most likely cause?

A.The build agent does not have the 'ASP.NET and web development' workload installed.
B.The build agent is out of disk space.
C.The pipeline is using the wrong version of MSBuild.
D.The solution file is corrupted.
AnswerA

The error indicates that the imported Microsoft.WebApplication.targets file cannot be found, which is installed with the 'ASP.NET and web development' workload in Visual Studio Build Tools. Without that workload, Web Application projects fail during MSBuild evaluation regardless of agent disk space or MSBuild version.

Why this answer

The error indicates that the MSBuild targets file for Web Applications is missing. This typically occurs when the build agent does not have the required Visual Studio workload installed, specifically the Web development build tools.

Full explanation →
Page 10

Page 11 of 11

All pages

1234567891011

Practice AZ-400 by domain

Target a specific domain to shore up weak areas.

Configure processes and communicationsDesign and implement source controlDevelop a security and compliance planImplement an instrumentation strategyDesign and implement build and release pipelinesDesign and implement a source control strategy
See all domains with question counts →