Courseiva

Microsoft Azure DevOps Engineer Expert AZ-400 (AZ-400) — Questions 226–300

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

Take a mock examExam hub
Page 3

Page 4 of 13

Page 5
226
MCQmedium

Your organization uses Microsoft Purview to manage sensitive data in Azure DevOps repositories. The compliance team needs to automatically classify and label source code that contains personally identifiable information (PII). Which solution should you use?

A.Use Azure Policy to enforce PII labeling on repositories.
B.Use Microsoft Purview Information Protection to automatically scan and label repositories.
C.Use Microsoft Sentinel to detect PII in repositories.
D.Use Microsoft Defender for Cloud to scan for PII.
AnswerB

Purview Information Protection can automatically classify and label sensitive data in source code.

Why this answer

Microsoft Purview Information Protection can automatically classify and label sensitive data, including source code. Microsoft Sentinel is for security information and event management, not classification. Microsoft Defender for Cloud is for cloud security posture management.

Azure Policy enforces rules on Azure resources, not on source code content.

Full explanation →
227
MCQmedium

Your team uses GitHub Flow. A developer pushes a feature branch to origin and creates a pull request to main. After review and approval, the pull request is merged. Which branch should the developer delete after the merge to maintain a clean repository?

A.Delete the feature branch
B.Keep both branches indefinitely
C.Delete the main branch
D.Delete the remote main branch and recreate it
AnswerA

Feature branches are temporary and should be deleted after merge.

Why this answer

In GitHub Flow, feature branches are temporary and should be deleted after their pull request is merged into main. Deleting the feature branch keeps the repository clean by removing stale branches that are no longer needed, reducing clutter and preventing confusion. This practice aligns with the principle of short-lived branches in trunk-based development workflows.

Exam trap

The trap here is that candidates may think keeping feature branches is harmless or that deleting main is acceptable for cleanup, but GitHub Flow explicitly requires deleting feature branches after merge to maintain a clean, linear history and avoid repository clutter.

How to eliminate wrong answers

Option B is wrong because keeping both branches indefinitely violates the GitHub Flow convention of deleting feature branches after merge, leading to repository bloat and potential confusion about active work. Option C is wrong because deleting the main branch would break the repository's default branch and disrupt all future development, as main is the stable integration branch. Option D is wrong because deleting and recreating the remote main branch is unnecessary and destructive; it would require force-pushing and could cause loss of commit history or break CI/CD pipelines that depend on the existing branch.

Full explanation →
228
MCQeasy

Your organization uses GitHub Actions and needs to enforce that all workflows pass required checks before a pull request can be merged. Which GitHub feature should you configure?

A.Workflow triggers
B.Branch protection rules with required status checks
C.Required reviewers
D.Environment protection rules
AnswerB

Branch protection rules can require specific status checks to pass before merging.

Why this answer

Option C is correct because branch protection rules allow you to require status checks to pass before merging. Option A is wrong because workflow triggers define when workflows run, not merge requirements. Option B is wrong because required reviewers are for manual approval, not automated checks.

Option D is wrong because environment protection rules are for deployments, not pull request merges.

Full explanation →
229
MCQeasy

You are designing the communication strategy for a large team using Azure DevOps. The team uses a Kanban board and wants to automatically notify stakeholders when work items are moved to 'Done'. Which Azure DevOps feature should you use?

A.Use the built-in email subscription for work item changes.
B.Set up a pipeline notification for the work item.
C.Configure team alerts in the project settings.
D.Create a service hook subscription to send events to a webhook.
AnswerD

Service hooks can send notifications to external systems like Slack or email gateways.

Why this answer

Option D is correct because service hook subscriptions in Azure DevOps allow you to send real-time notifications to external systems (like webhooks) when specific events occur, such as a work item moving to 'Done'. This is the appropriate feature for automatically notifying stakeholders outside of Azure DevOps, as it integrates with custom endpoints or third-party services.

Exam trap

The trap here is that candidates often confuse built-in email notifications (Option A or C) with service hooks, not realizing that the requirement to 'automatically notify stakeholders' implies an external integration (webhook) rather than just internal email alerts.

How to eliminate wrong answers

Option A is wrong because built-in email subscriptions for work item changes are designed to notify individual users or groups within Azure DevOps via email, not to automatically notify external stakeholders through a webhook or other integration. Option B is wrong because pipeline notifications are triggered by pipeline events (e.g., build or release completion), not by work item state changes on a Kanban board. Option C is wrong because team alerts in project settings are for sending email notifications to team members about specific events (like work item updates), but they do not support sending events to external webhooks or custom endpoints.

Full explanation →
230
Multi-Selectmedium

Which TWO features in Azure Pipelines allow you to enforce separation of duties between development and operations teams? (Choose two.)

Select 2 answers
A.Pipeline decorators
B.Approvals and checks on environments
C.Service connections with different scopes
D.Environment security roles
E.Branch policies on the main branch
AnswersB, D

Approvals require designated reviewers to approve deployments.

Why this answer

Approvals and checks enforce separation by requiring ops approval before deployment. Environment security ensures only specific users can deploy to production. Option C is wrong because branch policies are for source control, not deployment.

Option D is wrong because service connections are for authentication, not separation of duties. Option E is wrong because pipeline decorators inject steps but do not enforce separation.

Full explanation →
231
MCQmedium

Your project uses a monorepo in Azure Repos. You want to enforce that changes to a specific folder (/src/security) require approval from the security team. What is the best approach?

A.Add a required reviewer policy for all pull requests.
B.Configure a branch policy with a path filter and require approval from the security team group.
C.Move the security folder to a separate repository with its own policies.
D.Set folder-level permissions to restrict who can modify the folder.
AnswerB

This ensures only changes to that path get additional review.

Why this answer

Option B is correct because Azure Repos branch policies allow you to define path filters that scope policy enforcement to specific folders. By adding a required reviewer policy with a path filter for `/src/security` and assigning the security team group, only pull requests modifying files under that folder will require their approval, leaving other changes unaffected.

Exam trap

The trap here is that candidates often confuse folder-level permissions (which control direct access) with branch policy path filters (which enforce workflow approvals), leading them to select Option D instead of the correct branch policy configuration.

How to eliminate wrong answers

Option A is wrong because a required reviewer policy without a path filter applies to all pull requests across the entire repository, forcing security team approval for every change, which is overly broad and not scoped to the specific folder. Option C is wrong because moving the folder to a separate repository introduces unnecessary complexity, breaks monorepo consistency, and does not leverage Azure Repos' built-in branch policy path filters for granular control. Option D is wrong because folder-level permissions in Azure Repos control direct push access but do not enforce pull request review workflows; a user with write permissions could still bypass approval by pushing directly to the branch if branch policies are not configured.

Full explanation →
232
Multi-Selectmedium

You are designing a release pipeline for a microservices application. Which two strategies can you use to manage configuration across different environments? (Choose two.)

Select 2 answers
A.Use variable groups linked to Azure Key Vault.
B.Use environment-specific variable groups.
C.Use XML transformation tasks for web.config.
D.Use multi-stage YAML pipelines with stage-level variables.
AnswersA, B

Why this answer

Option A is correct because variable groups linked to Azure Key Vault allow you to securely store and manage secrets (like connection strings and API keys) centrally, and reference them across multiple pipelines and environments without hardcoding sensitive values. This approach integrates with Azure Key Vault's access policies and automatic secret rotation, ensuring configuration consistency and security across environments.

Exam trap

The trap here is that candidates often confuse pipeline definition techniques (like multi-stage YAML with stage-level variables) with configuration management strategies, or incorrectly assume XML transformations are applicable to modern microservices deployments that use JSON, YAML, or environment variables instead of web.config files.

Why the other options are wrong

C

XML transformation is for config files, not a variable management strategy.

D

This is a valid approach but the question asks for 'strategies' and the two most common are variable groups and Key Vault.

Full explanation →
233
MCQeasy

Your team uses Azure Pipelines to build and deploy a web app. You want to send a notification to a Microsoft Teams channel when a build fails. What should you configure?

A.Add a task in the pipeline to send an email on failure.
B.Create a service hook to trigger an Azure Logic App that sends a Teams message.
C.Add a dashboard widget that shows build status.
D.Use the built-in Azure Pipelines Teams integration to send a notification on build failure.
AnswerD

This is the native way to notify Teams.

Why this answer

Option D is correct because Azure Pipelines has a built-in integration with Microsoft Teams that allows you to subscribe to notifications for pipeline events, such as build failures, directly from the Azure DevOps interface. This integration uses a service hook to send adaptive cards to a Teams channel without requiring custom logic or additional tasks.

Exam trap

The trap here is that candidates may overengineer the solution by choosing a custom Logic App or third-party task, overlooking the fact that Azure Pipelines has a first-class, built-in integration with Microsoft Teams that requires no additional code or services.

How to eliminate wrong answers

Option A is wrong because Azure Pipelines does not have a native 'send email on failure' task; email notifications are configured via subscription settings, not as a pipeline task. Option B is wrong because while a service hook can trigger an Azure Logic App to send a Teams message, this is an overly complex solution when the built-in Teams integration provides the same functionality with less overhead. Option C is wrong because a dashboard widget only displays build status visually within Azure DevOps and does not send proactive notifications to Microsoft Teams.

Full explanation →
234
MCQmedium

Your team uses Azure Repos and has a repository with a large number of binary files (e.g., images, compiled libraries) that bloat the repository size. You want to reduce clone times and storage usage while still maintaining version history for those files. Which approach should you recommend?

A.Split the repository into two: one for code and one for binaries.
B.Use git annex to manage large files with a separate store.
C.Use git submodules to reference the large files from another repository.
D.Use Git Large File Storage (LFS) to track large files with pointers.
AnswerD

Git LFS is supported and reduces clone size.

Why this answer

Git LFS (Large File Storage) replaces large binary files in the repository with text pointers, while storing the actual file content in a separate remote store. This keeps the repository lightweight for cloning and fetching, but still preserves the full version history of the binary files because each pointer references a specific version in the LFS store. It integrates natively with Azure Repos and requires minimal workflow changes.

Exam trap

The trap here is that candidates often confuse git submodules or repo splitting as valid solutions for large files, but they fail to realize that those approaches do not actually reduce clone times or storage usage for the binary files themselves—they only reorganize the problem.

How to eliminate wrong answers

Option A is wrong because splitting the repository does not reduce the total storage or clone time for the binary files—they still exist in a separate repo and must be cloned separately, and maintaining version history across two repos adds complexity. Option B is wrong because git annex is not a native Azure Repos feature; it requires a separate external store and manual configuration, and it does not integrate seamlessly with Azure DevOps pipelines or pull requests. Option C is wrong because git submodules only link to a specific commit in another repository; they do not reduce clone times for the large files (the submodule must still be cloned in full) and they complicate version management by requiring explicit submodule updates.

Full explanation →
235
MCQhard

You are a DevOps engineer for a company developing a mobile application. The source code is stored in Azure Repos (Git). The team uses trunk-based development with short-lived feature branches. Recently, developers have reported that their feature branch builds are taking over 30 minutes, whereas the main branch builds complete in under 10 minutes. The pipeline is defined in a YAML file and includes steps to restore NuGet packages, compile, run unit tests, and perform code analysis. The pipeline also publishes build artifacts. The main branch has a branch policy that requires a successful build before merging. The feature branches do not have branch policies. All builds run on Microsoft-hosted agents. Upon investigation, you notice that the feature branch builds are restoring all NuGet packages from scratch each time, while main branch builds use cached packages. Additionally, the code analysis tool is scanning the entire codebase, not just the changed files. You need to reduce the feature branch build time to under 15 minutes without compromising code quality. Which course of action should you take?

A.Configure a self-hosted agent with pre-installed dependencies and a larger disk for faster I/O.
B.Enable pipeline caching for NuGet packages and configure the code analysis step to scan only changed files using path filters.
C.Remove the code analysis step from feature branch builds and only run it on main branch builds.
D.Increase the agent VM size to a more powerful SKU for feature branch builds.
AnswerB

Caching reduces restore time, and scanning only changed files reduces analysis time.

Why this answer

Option B is correct because it directly addresses the two root causes of the slow feature branch builds: uncached NuGet package restores and full-codebase code analysis. Enabling pipeline caching (using the Cache@2 task) stores the NuGet packages folder (typically ~/.nuget/packages) and restores it on subsequent runs, eliminating redundant downloads. Configuring the code analysis step with path filters (e.g., using the 'changedFiles' condition or a custom script) ensures only modified files are scanned, drastically reducing analysis time without sacrificing quality.

Exam trap

The trap here is that candidates often assume hardware upgrades (larger agents or self-hosted machines) are the solution, when the real issue is inefficient pipeline logic—specifically, missing caching and incremental scanning—which are software-level optimizations that directly target the root causes.

How to eliminate wrong answers

Option A is wrong because switching to a self-hosted agent with pre-installed dependencies and a larger disk does not address the core issues of uncached package restores or full-codebase scanning; it only improves I/O speed, which is not the bottleneck here. Option C is wrong because removing code analysis entirely from feature branch builds compromises code quality by allowing potential issues to go undetected until the main branch merge, violating the requirement to not compromise code quality. Option D is wrong because increasing the agent VM size (e.g., to a more powerful SKU) only speeds up execution but does not solve the fundamental problem of redundant package downloads and unnecessary full scans; it would still leave builds over 15 minutes and waste resources.

Full explanation →
236
Multi-Selecthard

Which THREE are benefits of using 'Environment' resources in YAML pipelines compared to classic release pipelines? (Choose three.)

Select 3 answers
A.Environments provide a dashboard showing the deployment history and resource health.
B.Environments can only be used in classic release pipelines.
C.Environments support checks like approval gates and manual intervention.
D.Environments allow you to define pre-deployment and post-deployment gates using the classic release pipeline interface.
E.Environments can represent Kubernetes namespaces and track deployed versions.
AnswersA, C, E

Environments offer visibility into deployment status.

Why this answer

Options A, C, and D are correct. Option A: YAML pipelines with environments support Kubernetes resources for tracking deployments to AKS. Option C: Environments provide a centralized view of deployments and live resource health.

Option D: Environments support checks such as approvals, gates, and manual intervention. Option B is wrong because YAML pipelines do not support pre-deployment gates directly; they use checks. Option E is wrong because environments are available in both YAML and classic pipelines.

Full explanation →
237
MCQmedium

Your CI pipeline includes a step that runs unit tests. You want to fail the pipeline if code coverage drops below 80%, but continue if tests pass with lower coverage. How should you configure the test step?

A.Configure a quality gate in the release pipeline to check coverage.
B.Add a script task that reads the coverage report and prints a warning.
C.Use the 'PublishCodeCoverageResults' task with a 'codeCoverageThreshold' setting.
D.Use the VSTest task with the 'codeCoverageEnabled' option set to true.
AnswerC

This task can fail the pipeline if coverage is below threshold.

Why this answer

Option B is correct because the PublishCodeCoverageResults task can set a coverage threshold and fail the pipeline if not met. Option A is wrong because the test runner does not enforce thresholds. Option C is wrong because the build summary doesn't fail the pipeline.

Option D is wrong because quality gates apply to release, not CI.

Full explanation →
238
MCQhard

Your release pipeline deploys to Azure App Service using a deployment slot strategy. After a successful deployment to the staging slot, you run smoke tests, then swap slots. Recently, a swap failed because the staging slot had an incorrect application setting. What is the BEST way to prevent this issue?

A.Use a manual approval gate before swap.
B.Configure the App Service deployment center.
C.Add a task to verify settings before swap.
D.Mark the application setting as a deployment slot setting.
AnswerD

Slot settings remain with the slot, preventing misconfiguration after swap.

Why this answer

Option C is correct because slot-specific settings should be marked as 'deployment slot settings' so they persist across swaps. Option A is wrong because verifying before swap is reactive, not preventive. Option B is wrong because manual validation is error-prone.

Option D is wrong because deployment center doesn't control slot settings.

Full explanation →
239
MCQmedium

Your organization uses GitHub Copilot for pull request summaries. However, the summaries sometimes miss security-related changes. What should you recommend?

A.Configure Copilot to ignore non-security files.
B.Provide custom instructions to Copilot to emphasize security analysis.
C.Disable Copilot and rely on manual review.
D.Switch to a different AI model specialized in security.
AnswerB

Custom instructions refine Copilot behavior.

Why this answer

Option B is correct because GitHub Copilot's pull request summaries can be customized using custom instructions to prioritize security analysis. By providing specific directives in the repository's `.github/copilot-instructions.md` file or through the Copilot settings, you can instruct the AI to explicitly highlight security-related changes, such as those involving authentication, encryption, or input validation. This ensures the generated summaries are more aligned with your organization's security review requirements without disabling the tool.

Exam trap

The trap here is that candidates may assume AI tools are inflexible and require replacement or disabling when they encounter limitations, rather than recognizing that GitHub Copilot supports custom instructions to refine its behavior for specific domains like security analysis.

How to eliminate wrong answers

Option A is wrong because configuring Copilot to ignore non-security files would prevent it from analyzing all files, potentially missing security issues in files that are not exclusively security-related (e.g., a configuration file that contains a security vulnerability). Option C is wrong because disabling Copilot entirely is an overreaction and discards its productivity benefits; the goal is to improve its output, not eliminate it. Option D is wrong because switching to a different AI model specialized in security is unnecessary and disruptive; GitHub Copilot already supports customization through instructions, and a specialized model would require separate integration and may not work seamlessly with pull request summaries.

Full explanation →
240
MCQeasy

You have a GitHub repository with a GitHub Actions workflow that builds a .NET application. The workflow should only run when changes are pushed to the main branch, but it currently runs on every push to any branch. How should you fix the workflow trigger?

A.Add 'on: push: branch: [main]' to the workflow.
B.Add 'on: push: paths: [main]' to the workflow.
C.Add 'on: pull_request: branches: [main]' to the workflow.
D.Add 'on: push: branches: [main]' to the workflow.
AnswerD

This restricts the trigger to pushes on main.

Why this answer

Option D is correct because the GitHub Actions workflow syntax to restrict a push trigger to a specific branch uses `on: push: branches: [main]`. This ensures the workflow only executes when commits are pushed to the main branch, not on pushes to any other branch.

Exam trap

The trap here is that candidates often confuse the singular `branch` with the plural `branches` or mix up `paths` with `branches`, leading them to select options that either use invalid syntax or apply the wrong filter entirely.

How to eliminate wrong answers

Option A is wrong because `branch` is not a valid key under `push`; the correct key is `branches` (plural). Option B is wrong because `paths` filters by file paths changed in the push, not by branch name, so it would not restrict the trigger to the main branch. Option C is wrong because it defines a `pull_request` trigger, not a `push` trigger, so the workflow would run on pull request events instead of push events.

Full explanation →
241
MCQhard

Refer to the exhibit. You deploy this ARM template to create a Log Analytics workspace and a saved search. After deployment, you notice that the saved search returns no results even though there are failed pipeline runs. What is the most likely reason?

A.The savedSearch API version is not supported.
B.The Log Analytics workspace API version is incorrect.
C.The custom table 'AzureDevOpsPipelineEvents_CL' does not exist in the workspace.
D.The category 'Azure Pipelines' is misspelled.
AnswerC

Custom tables must be created or data ingested first.

Why this answer

Option C is correct because the query uses a custom log table 'AzureDevOpsPipelineEvents_CL' which requires a custom table or data connector to be created first. Option A is wrong because the apiVersion is valid for workspace. Option B is wrong because the API version for savedSearches is valid.

Option D is wrong because the category is just a label.

Full explanation →
242
MCQeasy

Your team uses Azure Pipelines to deploy to multiple environments. You need to ensure that deployment to the production environment requires approval from the security team. What should you configure?

A.Add a branch policy to the production branch
B.Add an environment approval check for the production environment
C.Use a condition in the YAML pipeline to check a variable
D.Configure a service connection with restricted permissions
AnswerB

Environment approvals require designated users to approve the deployment.

Why this answer

Option D is correct because Azure Pipelines environment approvals allow you to require manual approval before deployment. Option A is wrong because branch policies apply to code changes, not deployments. Option B is wrong because YAML conditions are for runtime decisions, not manual approval.

Option C is wrong because service connections manage credentials, not approvals.

Full explanation →
243
Drag & Dropmedium

Drag and drop the steps to implement a branch policy in Azure Repos for pull requests into the correct order.

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

Steps
Order

Why this order

Branch policies are set by accessing repo settings, selecting branch, adding requirements, and saving.

Full explanation →
244
MCQeasy

Your team uses GitHub for source control and Azure Pipelines for CI/CD. You need to trigger a pipeline automatically when a pull request is created against the main branch. Which trigger type should you configure in the YAML pipeline?

A.pr:
B.trigger:
C.schedules:
D.resources:
AnswerA

Correct: pr trigger fires on pull requests.

Why this answer

Option A is correct because the `pr:` trigger in Azure Pipelines YAML is specifically designed to automatically start a pipeline when a pull request is created or updated against a specified branch. By default, `pr:` triggers are enabled for the `main` branch, so configuring `pr: main` ensures the pipeline runs on PR creation without needing a separate branch policy.

Exam trap

The trap here is that candidates often confuse `trigger:` (CI on push) with `pr:` (PR validation), especially since both can be used for the same branch, but they serve different events and have distinct YAML syntax.

How to eliminate wrong answers

Option B is wrong because `trigger:` is used for continuous integration (CI) triggers on branch pushes, not for pull request events; it would start the pipeline when code is pushed to `main`, not when a PR is created. Option C is wrong because `schedules:` defines cron-based scheduled triggers for nightly or periodic builds, which are unrelated to PR events. Option D is wrong because `resources:` is used to define external dependencies like other pipelines, repositories, or containers, not to trigger a pipeline on PR creation.

Full explanation →
245
MCQeasy

Your pipeline uses a multi-stage YAML file. You want to conditionally run a stage only if the build originates from the 'main' branch. Which syntax should you use?

A.condition: variables['Build.SourceBranch'] == 'main'
B.condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))
C.condition: eq(variables['Build.SourceBranch'], 'refs/heads/main')
D.condition: eq(variables['Build.SourceBranch'], 'main')
AnswerC

Correct: Build.SourceBranch includes full ref path.

Why this answer

Option C is correct because the `condition` directive in a YAML pipeline stage evaluates expressions using Azure Pipelines syntax. The `eq()` function compares two values, and `Build.SourceBranch` for the 'main' branch returns `refs/heads/main`, not just `main`. This exact match ensures the stage runs only when the build originates from the 'main' branch.

Exam trap

The trap here is that candidates often forget that `Build.SourceBranch` includes the full ref path (`refs/heads/main`) and incorrectly use just the branch name (`main`), or they misuse the `==` operator instead of the `eq()` function required by Azure Pipelines expression syntax.

How to eliminate wrong answers

Option A is wrong because it uses a simple equality operator (`==`) which is not valid in Azure Pipelines YAML expressions; the correct syntax requires the `eq()` function. Option B is wrong because it adds `and(succeeded(), ...)` which is unnecessary for a stage-level condition (stages do not have a preceding task to succeed or fail) and introduces an extra check that could cause the stage to be skipped incorrectly. Option D is wrong because it compares `Build.SourceBranch` to `'main'` instead of the full ref `'refs/heads/main'`, which will never match and thus the stage will never run.

Full explanation →
246
MCQhard

Your Azure DevOps pipeline uses a YAML template that includes a step to push a Docker image to Azure Container Registry. The pipeline fails with 'unauthorized: authentication required'. The service connection uses a workload identity federation. What is the most likely cause?

A.The Docker image tag contains invalid characters
B.The Azure Container Registry name is incorrect
C.The service principal used by the workload identity does not have the 'acrPush' role
D.The service connection secret has expired
AnswerC

The federated credential must be assigned the AcrPush role on the registry.

Why this answer

The error 'unauthorized: authentication required' indicates that the Docker client could not authenticate with Azure Container Registry. With workload identity federation, the service principal used by the federated credential must have the 'acrPush' role assigned on the ACR scope to push images. Without this role assignment, the authentication token lacks the necessary permissions, even if the identity itself is valid.

Exam trap

The trap here is that candidates confuse authentication (identity validation) with authorization (permission to act), assuming any valid identity can push to ACR, but ACR requires explicit role assignment even for federated identities.

How to eliminate wrong answers

Option A is wrong because invalid characters in the Docker image tag cause a different error (e.g., 'invalid reference format') and do not trigger authentication failures. Option B is wrong because an incorrect ACR name would result in a 'name unknown' or 'repository not found' error, not an authentication error. Option D is wrong because workload identity federation does not use a client secret; it relies on a federated credential token exchange, so secret expiry is irrelevant.

Full explanation →
247
MCQhard

A team uses Git-LFS to store large binary files. They observe that cloning the repository takes a long time because Git-LFS files are downloaded. How can they improve clone performance?

A.Use a shallow clone with depth 1
B.Use the --filter=blob:none option when cloning
C.Use sparse checkout to limit files in working directory
D.Configure git lfs prune to run automatically
AnswerB

This partial clone defers downloading LFS blobs until they are accessed.

Why this answer

Option B is correct because the `--filter=blob:none` option performs a partial clone, which omits all blob objects (including Git-LFS pointer files and other large blobs) from the initial download. This significantly reduces clone time by only fetching commit and tree metadata, and then lazily downloading blobs on demand when they are actually accessed. For Git-LFS specifically, this avoids downloading the large binary files stored in LFS until they are needed, improving clone performance.

Exam trap

The trap here is that candidates confuse shallow clones (which limit history) or sparse checkouts (which limit working tree files) with partial clones (which limit object downloads), not realizing that Git-LFS files are downloaded during checkout regardless of history depth or sparse patterns unless blob filtering is used.

How to eliminate wrong answers

Option A is wrong because a shallow clone with depth 1 reduces the commit history but does not prevent Git-LFS files from being downloaded; Git-LFS still downloads all LFS objects during checkout. Option C is wrong because sparse checkout limits the working directory to a subset of files but does not affect the download of Git-LFS objects; all LFS files in the checked-out commit are still fetched. Option D is wrong because `git lfs prune` removes local copies of LFS files that are no longer referenced, but it runs after cloning and does not improve initial clone performance.

Full explanation →
248
MCQhard

You are a DevOps engineer at a large enterprise that develops a cloud-native application using microservices architecture. The application consists of 15 microservices, each stored in a separate GitHub repository. Your team uses GitHub Actions for CI/CD and Azure Kubernetes Service (AKS) for production. The current deployment process is manual and error-prone. You need to design an automated CI/CD pipeline that supports the following requirements: 1. Each microservice must have its own build and test pipeline triggered on pull requests and merges to the main branch. 2. Upon merging to main, a container image must be built, tagged with the Git commit SHA, and pushed to Azure Container Registry (ACR). 3. A separate release pipeline must deploy the updated images to AKS using a GitOps approach with Flux v2. 4. The release pipeline must support rolling back to a previous version quickly if a deployment fails. 5. The entire solution must be defined as code to ensure reproducibility. Which approach should you recommend?

A.Create a single monorepo with all microservices. Use GitHub Actions with a multi-branch pipeline that builds only changed services. Deploy to AKS using kubectl commands in the pipeline. For rollback, redeploy the previous image tag.
B.Use Azure Pipelines with a single build pipeline that triggers on any change in any repo using webhooks. Use Azure DevOps Release Pipelines to deploy to AKS using Helm. Store Helm charts in Azure Container Registry. For rollback, use Helm rollback command.
C.Use GitHub Actions for CI and deploy directly to AKS using kubectl in the same workflow. Store Kubernetes manifests in each microservice repo. Use Argo CD to monitor the repos and sync.
D.Use GitHub Actions in each microservice repo for CI to build and push images to ACR. Use a separate GitOps repository that contains Kubernetes manifests. Configure Flux v2 in AKS to sync from the GitOps repo. When a new image is pushed to ACR, update the manifest in the GitOps repo via a GitHub Action, triggering Flux to deploy. For rollback, revert the commit in the GitOps repo.
AnswerD

Correct: This satisfies all requirements with GitHub Actions for CI, Flux for GitOps, and rollback via Git revert.

Why this answer

Option A is correct because it uses GitHub Actions for CI per microservice, pushes to ACR, and uses Flux v2 for GitOps-based deployment with rollback by reverting Git. Option B is wrong because Azure Pipelines is not preferred if the team already uses GitHub Actions and GitOps. Option C is wrong because multi-branch pipelines in a single repo would mix concerns and violate requirement 1 (separate repos).

Option D is wrong because Argo CD is not a native GitHub or Azure solution and introduces complexity.

Full explanation →
249
MCQhard

You are designing a release pipeline for a mission-critical application that must achieve zero-downtime deployments to Azure App Service (Web App for Containers). The application uses Azure SQL Database with schema migrations. The current deployment slot strategy uses staging and production slots. You need to ensure that during a swap, the staging slot is warmed up and the database schema is rolled back if the swap fails. Which combination of deployment slots and pre/post-swap actions should you implement?

A.Use three slots: production, staging, and a new slot for the new version. Apply schema changes in the new slot, then swap new to staging, warm up staging, then swap staging to production. On failure, swap staging back to production.
B.Use two slots (staging and production) with auto-swap enabled. The auto-swap handles warm-up automatically. If the swap fails, Azure automatically rolls back.
C.Use three slots: production, staging, and a new slot for the new version. Apply schema changes in the new slot, then swap new slot to staging, then staging to production. On failure, swap staging back to production.
D.Use two slots (staging and production). Apply schema changes in staging before swap. If swap fails, manually redeploy the old version to production.
AnswerA

This allows you to test schema changes in the new slot, warm up in staging, and swap staging to production. If the final swap fails, you swap staging back to production, which still has the old code and old schema.

Why this answer

Option C is correct because adding a third slot (e.g., 'test') allows you to apply schema changes in a non-production slot, swap test to staging to warm, then swap staging to production. If the final swap fails, you can swap back because the production slot still has the old code and old schema. Option A is wrong because swapping staging to production applies schema changes to production before the swap is complete, risking data loss on failure.

Option B is wrong because swapping staging for a new slot without schema changes doesn't address database rollback. Option D is wrong because swapping staging to production uses automatic swap with no rollback handling.

Full explanation →
250
MCQmedium

A team is implementing a release pipeline for a Node.js application. They want to run integration tests against a temporary environment that is destroyed after the tests complete. Which strategy should they use?

A.Use a separate release pipeline that deploys to a production environment for testing.
B.Use a single release pipeline that deploys to a staging slot and runs tests on the slot.
C.Run integration tests in the build pipeline using a mock environment.
D.Use a release pipeline that deploys to a new Azure App Service instance, runs tests, and then removes the instance.
AnswerD

Ephemeral environments are ideal for temporary testing.

Why this answer

Option D is correct because it provisions a dedicated, isolated Azure App Service instance for integration testing, runs the tests against the real environment, and then destroys the instance to avoid ongoing costs. This aligns with the ephemeral environment pattern, ensuring tests validate actual deployment behavior without contaminating shared resources.

Exam trap

The trap here is that candidates often confuse staging slots with ephemeral environments, but staging slots are persistent and not automatically destroyed after testing, whereas a new App Service instance can be fully removed to ensure cost and isolation compliance.

How to eliminate wrong answers

Option A is wrong because deploying to a production environment for testing risks corrupting live data and causing downtime, violating the principle of environment isolation. Option B is wrong because a staging slot is a permanent, shared resource that may not be destroyed after tests, and running tests on the slot does not guarantee a clean, disposable environment. Option C is wrong because running integration tests in the build pipeline with a mock environment bypasses real infrastructure validation, missing critical issues like deployment configuration, network dependencies, and service bindings.

Full explanation →
251
MCQeasy

Your company is migrating from on-premises Jenkins to Azure Pipelines. You have a Jenkins pipeline that builds a C++ application using MSBuild. The build environment requires specific Visual Studio components and SDKs. You need to set up a build agent in Azure Pipelines that matches the Jenkins environment. You want to minimize administrative overhead and ensure the agent is always up to date with the latest patches. What should you do?

A.Use a self-hosted agent on an Azure VM with a custom image that includes Visual Studio and SDKs.
B.Deploy a container-based agent using a Docker image that includes Visual Studio.
C.Use a Microsoft-hosted agent with the 'windows-2022' image that includes Visual Studio Build Tools.
D.Provision a self-hosted agent on an Azure VM and install required components manually.
AnswerC

Pre-configured and automatically updated.

Why this answer

Option C is correct because Microsoft-hosted agents come with Visual Studio pre-installed and are automatically maintained. Option A is incorrect because custom images require maintenance. Option B is incorrect because Azure VM agents require manual updates.

Option D is incorrect because container agents need custom image management.

Full explanation →
252
Multi-Selectmedium

Your organization uses Azure Pipelines with multiple release stages. You need to instrument the pipeline to capture the duration of each stage and the number of failed tasks. Which TWO approaches should you use?

Select 2 answers
A.Configure pipeline notifications for failed tasks.
B.Implement a 'runOnce' deployment strategy to ensure sequential stages.
C.Enable the 'Summary' tab in the pipeline run to view stage durations.
D.Use the Azure DevOps REST API to retrieve pipeline run statistics after each run.
E.Add a script task at the end of each stage to log stage duration and task results to a custom log file.
AnswersD, E

REST API provides detailed run data.

Why this answer

Options A and D are correct. Option A: REST API can query pipeline run details including stage durations and failures. Option D: Custom logging in tasks writes to the console, which is captured in pipeline logs.

Option B is wrong because it only gives a summary, not per-stage. Option C is wrong because it's a deployment pattern, not instrumentation. Option E is wrong because it's about notifications, not data collection.

Full explanation →
253
Multi-Selectmedium

Which THREE are valid deployment patterns for Kubernetes? (Choose three.)

Select 3 answers
A.Canary deployment
B.Rolling update
C.A/B testing deployment
D.Helm deployment
E.Blue-green deployment
AnswersA, B, E

Gradually routing traffic to a new version.

Why this answer

A canary deployment is a valid Kubernetes deployment pattern where a small subset of users (the 'canary') receives the new version of an application before a full rollout. This allows monitoring for issues with minimal impact, and Kubernetes supports this via techniques like multiple Deployments with shared labels and service mesh traffic splitting (e.g., Istio). It is a core strategy for progressive delivery in Kubernetes.

Exam trap

The trap here is that candidates confuse deployment patterns (like canary, rolling, blue-green) with deployment tools (like Helm) or traffic management techniques (like A/B testing), leading them to select options that are not actual Kubernetes rollout strategies.

Full explanation →
254
MCQmedium

Your team uses Azure Repos and needs to prevent secrets from being committed to the repository. Which built-in feature should you enable?

A.Enable GitHub secret scanning
B.Enable Azure Policy to scan repositories
C.Configure a pre-commit hook with a secret scanning tool
D.Enable push protection in Azure Repos
AnswerD

Blocks commits with secrets.

Why this answer

Push protection in Azure Repos is a built-in feature that scans commits for high-confidence secrets (e.g., Azure service connection strings, SSH keys, and other credential patterns) and blocks the push if a secret is detected. This prevents secrets from ever reaching the remote repository, enforcing security at the server side without requiring client-side configuration.

Exam trap

The trap here is that candidates confuse client-side pre-commit hooks (Option C) with a built-in server-side solution, overlooking that hooks can be bypassed and are not enforced, while push protection in Azure Repos is a native, unbypassable guard.

How to eliminate wrong answers

Option A is wrong because GitHub secret scanning is a feature of GitHub, not Azure Repos, and the question specifies the team uses Azure Repos. Option B is wrong because Azure Policy is used for governance and compliance of Azure resources (e.g., VM SKUs, resource locations), not for scanning repository contents for secrets. Option C is wrong because configuring a pre-commit hook is a client-side solution that can be bypassed by developers (e.g., by using --no-verify) and requires manual setup per machine, whereas Azure Repos push protection is a server-side, enforced feature.

Full explanation →
255
Multi-Selecthard

Which THREE are required to set up a self-hosted agent for Azure Pipelines?

Select 3 answers
A.A virtual machine running in Azure.
B.Network connectivity to Azure DevOps services.
C.A Personal Access Token (PAT) to authenticate the agent.
D.An agent pool configured in Azure DevOps and the agent configured to use that pool.
E.Docker installed on the agent machine.
AnswersB, C, D

Agent needs to communicate with Azure DevOps.

Why this answer

Correct answers: A, C, D. A: agent must be registered with a PAT. C: agent machine needs network access to Azure DevOps.

D: agent must be configured with the account. B is wrong because you don't need a VM in Azure; self-hosted can be on-premises. E is wrong because Docker is optional.

Full explanation →
256
MCQmedium

Your organization uses GitHub Actions for CI/CD. You have a workflow that builds and deploys a containerized application to Azure Kubernetes Service (AKS). The workflow uses the 'azure/aks-set-context' action to connect to the AKS cluster. Recently, the workflow started failing with authentication errors. The service principal used has Contributor role on the AKS cluster. What is the most likely cause?

A.The service principal must have 'Owner' role on the resource group containing the AKS cluster.
B.The service principal lacks the 'Azure Kubernetes Service Cluster Admin Role' on the AKS cluster.
C.The workflow uses an incorrect Kubernetes version.
D.The AKS cluster has RBAC disabled, causing authentication failures.
AnswerB

This role is required to fetch admin credentials.

Why this answer

The 'azure/aks-set-context' action requires the 'Azure Kubernetes Service Cluster User Role' or 'Azure Kubernetes Service Cluster Admin Role' to get cluster credentials. Contributor role does not grant permission to retrieve admin credentials. Option A is correct because the service principal needs the 'Azure Kubernetes Service Cluster Admin Role'.

Option B is incorrect as the action does not require cluster creation. Option C is incorrect because the issue is not about RBAC within the cluster. Option D is irrelevant.

Full explanation →
257
Multi-Selectmedium

Which TWO actions should you take to implement a CI/CD pipeline for a microservices application using Azure Pipelines? (Choose two.)

Select 2 answers
A.Use a classic release pipeline instead of YAML for the deployment stages.
B.Publish build artifacts and use them in the release stages.
C.Store deployment credentials directly in the YAML file.
D.Use a multi-stage YAML pipeline that includes build, test, and deploy stages.
E.Create a separate pipeline for each microservice.
AnswersB, D

Artifacts ensure the same build is deployed across stages.

Why this answer

Options B and D are correct. B: Using a multi-stage YAML pipeline allows you to define build, test, and deploy stages in a single file. D: Publishing build artifacts and using them in release stages ensures consistency between build and deploy.

Option A is wrong because using separate pipelines for each microservice would increase complexity; you can use a single pipeline with matrix strategies. Option C is wrong because you should not store credentials in YAML; use variable groups or Azure Key Vault. Option E is wrong because Azure Pipelines supports YAML for both CI and CD.

Full explanation →
258
Multi-Selecthard

You are designing a security compliance plan for a GitHub Enterprise environment. Which THREE practices should you implement? (Select THREE.)

Select 3 answers
A.Disable two-factor authentication for automation accounts
B.Allow repository admins to bypass branch protection rules
C.Configure branch protection rules to require pull request reviews
D.Enable Dependabot alerts for dependency vulnerability monitoring
E.Enable secret scanning to detect accidental credential commits
AnswersC, D, E

Branch protection rules enforce code quality and review processes.

Why this answer

Options A, B, and D are correct. A: Dependabot alerts help manage vulnerabilities in dependencies. B: Secret scanning detects exposed secrets.

D: Branch protection rules enforce code review and status checks. Option C is wrong because disabling 2FA is insecure. Option E is wrong because allowing admins to bypass policies undermines compliance.

Full explanation →
259
MCQmedium

Your team uses Git with Azure Repos. You notice that the commit history on the main branch contains many merge commits and commit messages like 'fix merge conflict'. You want a linear history for better traceability. What should you change?

A.Configure the repository to use rebase when pulling
B.Set the branch policy to require a clean fast-forward merge
C.Use rebase merge when completing pull requests
D.Use squash merge when completing pull requests
AnswerD

Squash merge condenses all commits into one, allowing a clean commit message and linear history.

Why this answer

Option D is correct because squash merge collapses all feature branch commits into a single commit on the main branch, eliminating merge commits and preserving a linear history. This directly addresses the problem of cluttered commit messages like 'fix merge conflict' by discarding intermediate commits and their messages. Squash merge is configured in the Azure Repos branch policy for pull request completion.

Exam trap

The trap here is that candidates confuse 'rebase merge' (which preserves individual commits) with 'squash merge' (which collapses them), or mistakenly think that requiring fast-forward merges alone eliminates merge commits, when in fact it only prevents non-linear merges but still allows merge commits from out-of-date branches.

How to eliminate wrong answers

Option A is wrong because configuring 'rebase when pulling' affects local developer workflows (git pull --rebase) but does not enforce a linear history on the remote main branch; merge commits can still be introduced via pull requests. Option B is wrong because requiring a clean fast-forward merge only prevents non-fast-forward merges but still allows merge commits if the feature branch is not up to date; it does not eliminate merge commits or clean up commit messages. Option C is wrong because rebase merge replays each individual commit from the feature branch onto main, preserving all intermediate commits and their messages, including 'fix merge conflict' commits, thus failing to achieve a clean linear history.

Full explanation →
260
MCQeasy

Your team uses GitHub Actions to build a Docker image and push it to Azure Container Registry (ACR). The workflow fails with the error 'unauthorized: authentication required'. The workflow uses the 'azure/docker-login@v1' action. What is the most likely cause?

A.The 'azure/docker-login@v1' action does not support ACR.
B.The Dockerfile is not in the repository root.
C.The service principal used for authentication lacks the AcrPush role on the ACR.
D.The workflow uses the registry admin credentials, which are disabled.
AnswerC

AcrPush role is required to push images.

Why this answer

Option B is correct because the Docker login action requires a service principal with AcrPush role. Option A is wrong because the action supports ACR. Option C is wrong because the action does not need admin credentials by default.

Option D is wrong because the action can handle private registries.

Full explanation →
261
Multi-Selectmedium

Your organization uses Azure DevOps and Azure Policy to enforce compliance. You need to ensure that all Azure resources deployed by Azure DevOps pipelines have specific tags (e.g., CostCenter and Environment) applied. Which TWO approaches can achieve this? (Choose TWO.)

Select 2 answers
A.Configure the service connection to only allow deployments with tags.
B.Create an Azure Policy with the 'audit' effect to report non-compliant resources.
C.Create an Azure Policy with the 'deny' effect that requires the tags to be present at resource creation.
D.Add a pipeline task after resource creation that applies the required tags using Azure CLI or PowerShell.
E.Configure a branch policy on the main branch to require tag verification in pull requests.
AnswersC, D

Deny policy blocks deployment of non-compliant resources.

Why this answer

Option C is correct because an Azure Policy with the 'deny' effect prevents the creation of any resource that does not include the required tags (e.g., CostCenter and Environment). This enforces compliance at the moment of deployment, blocking non-compliant resources from being provisioned by Azure DevOps pipelines. Option D is correct because adding a pipeline task (using Azure CLI or PowerShell) after resource creation programmatically applies the required tags, ensuring resources are tagged even if the initial deployment omitted them.

Exam trap

The trap here is that candidates often confuse Azure Policy effects (audit vs. deny) and overlook that a post-deployment task can also enforce tagging, leading them to select only the deny policy or incorrectly choose audit as a compliance enforcement mechanism.

Full explanation →
262
MCQmedium

A company recently migrated its CI/CD pipelines from Jenkins to Azure Pipelines. The development team is experiencing frequent build failures due to conflicting changes when multiple developers push code simultaneously. The team wants to maintain a linear history and avoid merge commits. Which strategy should you recommend?

A.Switch to Git with a central repository and require merge commits.
B.Enforce a rebase strategy for all pull requests in the branch policy.
C.Use Team Foundation Version Control (TFVC) with exclusive checkout enabled.
D.Configure Azure Repos to use squash merge when completing pull requests.
AnswerC

TFVC with exclusive checkout locks files, preventing concurrent edits and ensuring linear history.

Why this answer

Option C is correct because Team Foundation Version Control (TFVC) with exclusive checkout enforces a lock on a file when a developer checks it out, preventing simultaneous edits. This eliminates conflicting changes that cause build failures when multiple developers push code concurrently, and since TFVC does not use merge commits, it maintains a linear history. The scenario explicitly requires avoiding merge commits and resolving conflicts from simultaneous pushes, which TFVC’s exclusive checkout directly addresses.

Exam trap

The trap here is that candidates often assume Git-based strategies (like rebase or squash merge) can prevent simultaneous push conflicts, but they only manage how history looks after a merge, not the underlying conflict that occurs when two developers push changes to the same file at the same time.

How to eliminate wrong answers

Option A is wrong because switching to Git with a central repository and requiring merge commits would introduce merge commits, violating the requirement to maintain a linear history and avoid merge commits. Option B is wrong because enforcing a rebase strategy for pull requests in Git still allows conflicting changes when multiple developers push simultaneously; rebase rewrites commit history but does not prevent conflicts at the push stage, and it can lead to non-linear history if not handled carefully. Option D is wrong because configuring Azure Repos to use squash merge when completing pull requests collapses all commits into one, but it still requires a pull request and merge operation, which can introduce merge commits if conflicts arise, and it does not prevent simultaneous push conflicts; squash merge is about commit history compression, not conflict prevention.

Full explanation →
263
MCQhard

Your organization uses Azure DevOps and wants to enforce that all pipelines use a specific set of approved tasks. How can you achieve this?

A.Use the task restrictions feature in Azure DevOps to block unapproved tasks
B.Assign permissions to the task group to limit who can add tasks
C.Create a YAML template with the approved tasks and require all pipelines to use it
D.Configure a service hook to notify when an unapproved task is used
AnswerA

Task restrictions can block or warn on unapproved tasks at the organization level.

Why this answer

Option B is correct because Azure DevOps allows you to mark tasks as deprecated or use built-in task restrictions. Option A is wrong because YAML templates do not enforce task usage. Option C is wrong because permissions control access, not task selection.

Option D is wrong because notifications do not enforce rules.

Full explanation →
264
MCQmedium

You are designing a security compliance plan for Azure Pipelines. The plan must ensure that no pipeline can use variables containing secrets unless those variables are stored in Azure Key Vault and referenced via a variable group linked to Key Vault. What is the best way to enforce this across all pipelines in an Azure DevOps organization?

A.Create a YAML template that mandates the use of Key Vault references.
B.Implement an Azure Policy that audits variable groups and requires Key Vault integration.
C.Require manual approval for all pipeline runs that use variables.
D.Use branch policies to prevent merging code that contains secrets.
AnswerB

Azure Policy can enforce compliance across all Azure DevOps resources.

Why this answer

Option D is correct because using Azure Policy to audit and enforce Key Vault usage in variable groups ensures compliance across the organization. Option A is wrong because manual reviews are not scalable. Option B is wrong because YAML templates can be bypassed.

Option C is wrong because branch policies do not control variable usage.

Full explanation →
265
MCQmedium

Your build pipeline uses the 'NuGetCommand@2' task to restore NuGet packages. You want to use packages from an Azure Artifacts feed that requires authentication. How should you configure the pipeline to authenticate with the feed?

A.Store the Personal Access Token (PAT) in a variable and use it in the NuGet config.
B.Create an Azure Artifacts service connection and select it in the NuGet task.
C.Add a 'NuGetAuthenticate@1' task before the NuGet restore task.
D.Install the NuGet credential provider on the agent manually.
AnswerC

This task authenticates with Azure Artifacts.

Why this answer

Option B is correct because the NuGetAuthenticate task handles authentication to Azure Artifacts feeds. Option A is wrong because service connection is not directly used by NuGet tasks. Option C is wrong because PAT is less secure and not recommended.

Option D is wrong because the NuGet task has built-in support via NuGetAuthenticate.

Full explanation →
266
MCQmedium

The pipeline fails with the error 'The resource with name 'myregistry' could not be found'. What is the most likely cause?

A.The Azure Container Registry name is incorrect
B.The build ID variable is not defined
C.The service connection does not have permission to access the registry
D.The Azure CLI is not installed on the agent
AnswerA

The error states the resource could not be found.

Why this answer

Option B is correct because the registry name might be incorrect or not exist. Option A is wrong because the CLI is available. Option C is wrong because authentication is not the issue if the error says not found.

Option D is wrong because build ID is a variable that resolves.

Full explanation →
267
MCQmedium

Refer to the exhibit. You are migrating repository policies from Azure Repos to GitHub. The JSON shows a branch protection rule you plan to apply to the main branch. A developer pushes a hotfix directly to main without a pull request. What happens?

A.The push is blocked because required status checks are not met.
B.The push is blocked because enforceAdmins is true.
C.The push succeeds because no push restriction is defined.
D.The push is rejected because lockBranch is false.
AnswerC

No push restriction is set.

Why this answer

Option A is correct because the rule does not specify a restriction on direct pushes (no push restrictions). Option B is wrong because required status checks apply to pull requests, not direct pushes. Option C is wrong because lockBranch is false, so pushes are allowed.

Option D is wrong because enforceAdmins applies to admin overrides, not direct pushes.

Full explanation →
268
MCQmedium

Your release pipeline deploys to Azure App Service using a deployment slot. You need to ensure that after swapping slots, the staging slot retains the previous production configuration for rollback. Which deployment strategy should you use?

A.Rolling deployment
B.Blue-green deployment
C.Swap with preview
D.Canary deployment
AnswerC

Allows validation and retains previous config in staging.

Why this answer

Option D is correct because swap with preview allows you to validate before completing the swap, and the staging slot keeps the old production configuration. Option A is wrong because rolling update doesn't use slots. Option B is wrong because blue-green typically uses separate environments, not slots.

Option C is wrong because canary deploys traffic gradually, not slot swap.

Full explanation →
269
Multi-Selectmedium

Which THREE practices are recommended for effective source control in a GitHub monorepo? (Choose three.)

Select 3 answers
A.Store large binary files directly in the repository
B.Use branch protection rules to enforce CI checks
C.Use a single build definition for all projects
D.Use code owners to automatically request reviewers
E.Use path filters to trigger only relevant CI workflows
AnswersB, D, E

Maintains quality.

Why this answer

Options A, B, and E are correct. Option C is wrong because it reduces performance. Option D is wrong because it is not specific to monorepos.

Full explanation →
270
MCQmedium

You are designing a release pipeline for a Node.js application that deploys to Azure App Service. The pipeline must run integration tests against the deployed application. You want to use deployment slots to minimize downtime. What is the recommended approach?

A.Deploy to a staging slot, run tests against the staging slot, then swap to production.
B.Deploy to the production slot directly and run tests after deployment.
C.Deploy to a staging slot, swap, then run tests.
D.Deploy to a staging slot, run tests, then delete the staging slot.
AnswerA

This validates the app before swapping, ensuring zero downtime.

Why this answer

Option C is correct because deploying to a staging slot, running tests, then swapping ensures zero downtime. Option A is incorrect because deploying to production directly causes downtime. Option B is incorrect because running tests before swap does not validate the deployed app.

Option D is incorrect because deploying to staging then deleting the slot loses the deployed app.

Full explanation →
271
MCQmedium

You have a multi-stage pipeline that deploys to multiple regions. You want to ensure that if the deployment to one region fails, the pipeline does not proceed to the next region. What is the best way to implement this?

A.Use pipeline decorators to inject error handling steps.
B.Add a manual approval between regions.
C.Configure each region deployment as a separate stage with no dependencies.
D.Define stage dependencies with 'dependsOn' and set 'condition' to 'succeeded()'.
AnswerD

Stage dependencies with conditions ensure that subsequent stages only run if previous stages succeeded.

Why this answer

Using a multi-stage YAML pipeline with stage dependencies ensures stages run sequentially and stop on failure. Option A is wrong because parallel stages continue independently. Option B is wrong because pipeline decorators inject steps but don't handle dependencies.

Option C is wrong because manual approvals don't automatically stop on failure.

Full explanation →
272
MCQmedium

You are reviewing the branch protection policy for the main branch in an Azure DevOps repository. Based on the exhibit, what happens when a stale review exists on a pull request after new changes are pushed?

A.Admins are exempt from the review requirement
B.The stale review is automatically dismissed, and the PR requires new approvals
C.The PR still requires only 2 approvals, but stale reviews are not dismissed
D.The PR can be merged even without the required reviews
AnswerB

dismissStaleReviews: true.

Why this answer

The branch protection policy for the main branch has 'Reset code reviewer votes when there are new changes' enabled. When a stale review exists after new changes are pushed, Azure DevOps automatically dismisses the previous approval(s) and requires new approvals to meet the minimum number of reviewers (2). This ensures that reviewers re-evaluate the latest code changes before the pull request can be merged.

Exam trap

The trap here is that candidates may confuse 'stale reviews are not dismissed' with the default behavior of Azure DevOps, but the exhibit explicitly shows the 'Reset code reviewer votes when there are new changes' checkbox is enabled, which forces dismissal.

How to eliminate wrong answers

Option A is wrong because the exhibit does not show any exemption for admins from the review requirement; the policy applies equally to all users unless explicitly configured otherwise. Option C is wrong because when 'Reset code reviewer votes when there are new changes' is enabled, stale reviews are dismissed, not retained. Option D is wrong because the policy still requires the minimum number of approvals (2) to be met; the PR cannot be merged without the required reviews.

Full explanation →
273
MCQhard

You are debugging a production issue using Application Insights Snapshot Debugger. The exhibit shows a snapshot from a NullReferenceException. The variable _dbContext is null. What is the most likely root cause?

A.The call to the database is not awaited, causing a race condition.
B.The Index page model is not registered in the dependency injection container.
C.The database connection string is invalid in appsettings.json.
D.The OnGet method is missing a null check for _dbContext before usage.
AnswerB

If the page model isn't registered, DI can't inject _dbContext.

Why this answer

The Snapshot Debugger shows _dbContext is null, which indicates the dependency was never injected. In ASP.NET Core, page models like IndexModel must be registered in the dependency injection (DI) container (e.g., via AddTransient<IndexModel> or AddScoped<IndexModel>) for DI to resolve and inject the DbContext. Without registration, the runtime creates the page model manually, leaving _dbContext uninitialized and causing a NullReferenceException when OnGet accesses it.

Exam trap

The trap here is that candidates often assume a NullReferenceException always means a missing null check (Option D), but the snapshot's context—showing a dependency that is null—points to a DI registration failure, not a defensive coding oversight.

How to eliminate wrong answers

Option A is wrong because an unawaited database call would cause a race condition or incomplete operation, but the snapshot clearly shows _dbContext is null, not that the call was started and not completed. Option C is wrong because an invalid connection string would cause a runtime exception when the DbContext attempts to open a connection, not a NullReferenceException from a null _dbContext variable. Option D is wrong because while adding a null check would prevent the crash, it does not address the root cause—the missing DI registration—and would only mask the underlying configuration error.

Full explanation →
274
MCQmedium

You have a release pipeline that deploys to multiple environments. You need to ensure that a manual approval is required before deploying to production. What should you configure?

A.Add a manual intervention task in the production stage
B.Set a post-deployment approval on the production stage
C.Set a pre-deployment approval on the production stage
D.Set a branch policy on the release branch
AnswerC

Why this answer

Pre-deployment approvals are configured on a stage in Azure Pipelines to require manual sign-off before any deployment to that stage begins. Since the question specifies that approval is needed before deploying to production, a pre-deployment approval on the production stage enforces that gate before the release pipeline executes any deployment tasks in that environment.

Exam trap

The trap here is confusing pre-deployment approvals with post-deployment approvals or manual intervention tasks, as candidates often think a manual task can substitute for a formal approval gate, but only pre-deployment approvals enforce the 'before deployment' requirement with proper workflow and audit trail.

Why the other options are wrong

A

Manual intervention task is for classic releases, but approvals are a better fit and work in YAML too.

B

Post-deployment approval occurs after deployment, not before.

D

Branch policies affect pull requests, not release pipelines.

Full explanation →
275
MCQhard

You are the DevOps lead for a large enterprise that uses GitHub for source control and Azure Pipelines for CI/CD. The organization has hundreds of repositories, each with its own pipeline. Recently, the security team mandated that all pipelines must use a centralized set of tasks for secret scanning and compliance checks before any deployment. You need to design a solution that enforces these mandatory tasks across all pipelines without modifying each pipeline individually. The solution should allow pipeline authors to add their own custom steps after the mandatory steps. The mandatory steps must be versioned and updated centrally. You also need to ensure that the mandatory steps are not bypassed by pipeline authors. What should you do?

A.Store the mandatory tasks as a YAML template in a central repository. In each pipeline, use the 'template' reference to include the mandatory steps. Use branch protection rules on the central repository to require approval for changes to the template.
B.Use a global list of tasks in the Azure DevOps organization settings that automatically get injected into every pipeline.
C.Create a single pipeline that runs across all repositories and include the mandatory tasks in that pipeline.
D.Create a custom Azure DevOps extension that adds the mandatory tasks to all pipelines using a pre-job hook.
AnswerA

This enforces the use of the template and allows versioning and central updates.

Why this answer

Option C is correct because using a template repository with required templates and branch protection rules enforces the use of the mandatory steps. Option A is wrong because extensions can be disabled. Option B is wrong because a single pipeline cannot serve all repositories.

Option D is wrong because the YAML template repository approach with enforcement through branch policies is the recommended way.

Full explanation →
276
MCQeasy

You want to trigger a pipeline automatically when a new tag is pushed to a GitHub repository. Which trigger should you configure in the pipeline YAML?

A.pr:
B.schedules:
C.trigger: tags:
D.resources: pipelines:
AnswerC

This is the correct syntax to trigger on tags.

Why this answer

The 'tags' trigger under 'trigger' enables pipelines to run when specific tags are pushed.

Full explanation →
277
MCQhard

You are designing a pipeline that deploys to an Azure Kubernetes Service (AKS) cluster. You need to securely pass the Kubernetes cluster credentials to the pipeline without hardcoding them. Which approach should you use?

A.Store credentials in a pipeline variable with 'secret' type.
B.Use a variable group linked to Azure Key Vault.
C.Hardcode the credentials in the pipeline YAML.
D.Use a secure file in the pipeline library.
AnswerB

Why this answer

Option B is correct because Azure Key Vault provides a secure, centralized store for secrets like Kubernetes cluster credentials, and linking a variable group to Key Vault allows the pipeline to dynamically retrieve those secrets at runtime without exposing them in the pipeline definition or logs. This approach follows the principle of least privilege and ensures credentials are never hardcoded or stored in plaintext within the pipeline.

Exam trap

The trap here is that candidates may think a pipeline secret variable is sufficient for security, but Azure DevOps specifically recommends using Key Vault for production-grade secret management to avoid storing secrets in the pipeline's internal database and to enable centralized lifecycle management.

Why the other options are wrong

A

While secure, it does not leverage Key Vault for secret management and rotation.

C

This is insecure and violates best practices.

D

Secure files are for files like certificates, not for credentials; but they can be used for kubeconfig, but variable group with Key Vault is more direct.

Full explanation →
278
MCQeasy

Your build pipeline uses a hosted agent. You need to securely pass a connection string to a deployment task. The connection string contains a password. What is the recommended approach to store and use this secret in Azure Pipelines?

A.Define the connection string as a plain variable in the YAML pipeline.
B.Hardcode the connection string in the deployment script and set the file as read-only.
C.Define the connection string as a secret variable in the pipeline's variable group or in the pipeline settings UI, and reference it as `$(connectionString)`.
D.Store the connection string in Azure Key Vault and use the 'Azure Key Vault' task to retrieve it at runtime.
AnswerC

Secret variables are encrypted and masked in logs.

Why this answer

Option B is correct because Azure Pipelines secret variables are encrypted and not exposed in logs. Option A is wrong because storing secrets in YAML variables directly exposes them. Option C is wrong because Azure Key Vault is more complex for simple secrets and requires additional permissions.

Option D is wrong because environment variables in the agent are visible to other processes.

Full explanation →
279
MCQhard

Your organization uses Azure DevOps and has a strict compliance requirement: all changes to the main branch must be reviewed by at least two members of the 'ComplianceTeam' group. Additionally, a static code analysis tool must run and its results must be published to the pull request. The ComplianceTeam is a custom group defined in Azure DevOps, not a Microsoft Entra ID group. The team wants to enforce this using branch policies. You need to configure the minimum number of reviewers and also ensure that the code analysis results are visible to reviewers. What should you do?

A.Add a branch policy 'Require a minimum number of reviewers' set to 2, and specify the ComplianceTeam as required reviewers. Additionally, add a build policy that runs the code analysis and publishes results as a build summary.
B.Add a branch policy 'Require code owner review' and define the ComplianceTeam as code owners in a CODEOWNERS file.
C.Add a branch policy 'Comment resolution' and configure the ComplianceTeam to resolve comments.
D.Add a branch policy 'Automatically included reviewers' and set the ComplianceTeam to be automatically added to all PRs.
AnswerA

This enforces two approvals from the specified team and makes analysis results available.

Why this answer

Option A is correct because the 'Require a minimum number of reviewers' branch policy enforces that at least two members from the ComplianceTeam must approve the pull request. Adding a build policy that runs static code analysis and publishes results as a build summary ensures the analysis output is visible directly in the PR, meeting the compliance requirement for both reviewer count and code analysis visibility.

Exam trap

The trap here is that candidates often confuse 'Automatically included reviewers' (which only adds reviewers but does not enforce approval) with 'Require a minimum number of reviewers' (which enforces the actual approval count), leading them to choose Option D instead of A.

How to eliminate wrong answers

Option B is wrong because 'Require code owner review' only mandates that a code owner (defined in a CODEOWNERS file) must approve changes to specific files; it does not enforce a minimum number of reviewers or require two specific members from the ComplianceTeam. Option C is wrong because 'Comment resolution' only tracks whether comments on a PR are resolved, not reviewer count or code analysis visibility. Option D is wrong because 'Automatically included reviewers' merely adds the ComplianceTeam as optional reviewers to the PR but does not enforce that at least two of them must approve the changes.

Full explanation →
280
MCQeasy

Your pipeline uses a multi-stage YAML file. You want to conditionally run a stage only when the build is triggered from the 'main' branch. Which expression should you use in the 'condition' property of the stage?

A.startsWith(variables['Build.SourceBranch'], 'main')
B.eq(variables['Build.SourceBranchName'], 'refs/heads/main')
C.eq(variables['Build.SourceBranch'], 'refs/heads/main')
D.eq(variables['Build.SourceBranch'], 'main')
AnswerC

Correctly compares the full source branch ref.

Why this answer

Option C is correct because eq(variables['Build.SourceBranch'], 'refs/heads/main') compares the source branch to the main branch. Option A is wrong because 'main' is not a valid branch reference; Azure Pipelines uses 'refs/heads/main'. Option B is wrong because 'Build.SourceBranchName' returns 'main' but comparing to 'refs/heads/main' would fail.

Option D is wrong because 'startsWith' might match branches like 'maintenance'.

Full explanation →
281
MCQmedium

Your team uses Azure Pipelines to build a .NET Core application. The build runs successfully on Windows agents, but you need to also run the build on Linux agents to validate cross-platform compatibility. The pipeline currently has a single `windows-latest` agent pool. What is the most efficient way to run the build on both platforms without duplicating the entire pipeline?

A.Create two separate pipelines, one for each platform.
B.Use a multi-job pipeline with two jobs, each specifying a different pool.
C.Use a multi-stage pipeline with a stage for each platform.
D.Add a `strategy` with a `matrix` that specifies `vmImage: ['windows-latest', 'ubuntu-latest']` in the job.
AnswerD

A matrix strategy runs the same job on multiple agent pools in parallel, meeting the requirement efficiently.

Why this answer

Option B is correct because a strategy with a matrix allows running the same job on multiple agent pools in parallel. Option A is wrong because it duplicates the pipeline. Option C is wrong because it would create two separate jobs that are not easily managed.

Option D is wrong because multi-stage runs stages sequentially, not in parallel for this purpose.

Full explanation →
282
Multi-Selecthard

Which TWO actions should you take to implement Git-based source control for a large enterprise with multiple teams and a single repository (monorepo)? (Select TWO.)

Select 2 answers
A.Require all teams to work on a single branch
B.Use Git submodules to separate team code
C.Use forking workflow for each team
D.Configure path-based branch policies
E.Use sparse checkout to reduce clone time
AnswersD, E

Path-based policies enforce reviews per team area.

Why this answer

Using sparse checkout reduces clone size. Path-based branch policies enforce team-specific reviews. Forking is not typical for monorepos.

Submodules introduce complexity. Single branch for all teams causes conflicts.

Full explanation →
283
Multi-Selectmedium

You are implementing a release pipeline with multiple stages. You want to automatically trigger the next stage only if the previous stage succeeds and the build is from the 'main' branch. Which TWO conditions should you configure?

Select 2 answers
A.Add a condition that checks if the source branch is 'main'.
B.Set the trigger on the stage to 'After stage' and select the previous stage.
C.Add a condition: 'eq(variables['Build.SourceBranch'], 'main')' to the stage.
D.Add a condition: 'succeeded()' to the stage.
E.Add a condition: 'eq(variables['Build.SourceBranch'], 'main')' with correct syntax.
AnswersA, B

Required to restrict to main branch.

Why this answer

Options A and D are correct. Option A ensures the stage runs after the previous stage succeeds. Option D ensures the build is from main branch.

Option B is wrong because it does not check main branch. Option C is wrong because it does not check stage success. Option E is wrong because 'eq(variables['Build.SourceBranch'], 'refs/heads/main')' is the correct syntax, not 'main' without refs/heads.

Full explanation →
284
MCQhard

You are designing a release pipeline for a critical application that must minimize downtime during deployment. The application runs on Azure Kubernetes Service (AKS) and uses Azure SQL Database. Which deployment strategy should you recommend?

A.Rolling update with health probes.
B.Canary deployment with progressive exposure.
C.Blue-green deployment with traffic manager.
D.Recreate deployment by deleting the old version first.
AnswerC

Blue-green allows instant switchover and rollback, minimizing downtime.

Why this answer

Option B is correct because blue-green deployment allows you to deploy a new version (green) alongside the old (blue) and switch traffic after validation, minimizing downtime. Option A (rolling update) gradually replaces pods but can cause downtime if the new version is broken. Option C (canary) only routes a small percentage of traffic, which is good for testing but not for minimizing downtime for the entire app.

Option D (recreate) causes full downtime.

Full explanation →
285
Multi-Selecthard

Which THREE are required components to implement a secure CI/CD pipeline using Azure Pipelines and GitHub?

Select 3 answers
A.An Azure service connection to authenticate to Azure resources.
B.A container registry to store Docker images.
C.A YAML pipeline definition with stages and jobs.
D.A GitHub personal access token stored as a plain text variable.
E.Branch protection rules requiring status checks to pass.
AnswersA, C, E

Service connections securely store credentials for Azure.

Why this answer

A service connection is needed for authentication, a YAML pipeline defines the process, and branch protection enforces quality. Option B is optional, D is for container scanning, E is for Kubernetes.

Full explanation →
286
Drag & Dropmedium

Drag and drop the steps to configure Azure DevOps artifact feeds for NuGet packages into the correct order.

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

Steps
Order

Why this order

Feed setup starts with creation, upstream sources, permissions, publishing, and consumption.

Full explanation →
287
MCQmedium

Your team uses Azure Pipelines to deploy to Azure Kubernetes Service (AKS). The security team requires that all container images be scanned for vulnerabilities before deployment. You have configured a container registry with Microsoft Defender for Cloud integration. What should you add to your pipeline to ensure only compliant images are deployed?

A.Set up Azure Policy to deny deployments of images without scan results.
B.Add a task that runs a vulnerability scan on the image after deployment.
C.Configure the AKS cluster to scan images after pulling.
D.Use the 'Azure Container Registry' task with the 'Scan' option to check vulnerabilities and fail the pipeline if critical vulnerabilities exist.
AnswerD

This blocks non-compliant images before deployment.

Why this answer

Option B is correct because you can use the 'ACR Task' or a script to check scan results before deployment. Option A is incorrect because scanning is not done at build time by default. Option C is incorrect because scanning the running container is too late.

Option D is incorrect because security policies in Azure Policy can block non-compliant resources but are not pipeline-level.

Full explanation →
288
MCQmedium

Your team uses a monorepo in Azure Repos containing multiple projects. You want to set up CI/CD so that only the projects affected by a commit are built and deployed. Which approach should you use?

A.Use Git hooks to detect changes and run only the relevant build scripts locally.
B.Create separate Azure Pipelines for each project, each configured to trigger on changes to that project's folder.
C.Use a single YAML pipeline that includes all projects, and use the 'condition' keyword to skip steps based on changed files.
D.Use a single YAML pipeline with path-based triggers and path filters in the 'trigger' section for each project's folder.
AnswerD

Path filters ensure the pipeline only triggers when files in specific paths are changed.

Why this answer

Option D is correct because Azure Pipelines supports path-based triggers in the `trigger` section of a YAML pipeline, allowing you to specify include/exclude patterns for folders. When a commit changes files only under a specific project's folder, only that project's pipeline is triggered, ensuring efficient CI/CD by building and deploying only affected projects.

Exam trap

The trap here is that candidates often confuse path-based triggers (which control when a pipeline runs) with conditions (which control whether steps run after the pipeline has already started), leading them to choose option C incorrectly.

How to eliminate wrong answers

Option A is wrong because Git hooks are client-side scripts that run locally on a developer's machine, not in the CI/CD pipeline, and they cannot enforce centralized build triggers or deployment automation. Option B is wrong because creating separate pipelines for each project is a valid approach but is not the single YAML pipeline approach described in the question; the question asks for a single pipeline solution, and separate pipelines would require managing multiple pipeline definitions. Option C is wrong because the `condition` keyword in YAML pipelines evaluates at runtime based on variables or expressions, not directly on changed files; it cannot skip steps based on which files changed in a commit without additional logic like `git diff` commands, making it less efficient and more complex than path-based triggers.

Full explanation →
289
MCQmedium

You are designing a build validation policy for a GitHub repository. You want to ensure that all pull requests pass a CI check before they can be merged. What should you configure?

A.Enable Dependabot alerts on the repository.
B.Configure a repository rule to require a pull request before merging.
C.Add a GitHub Actions workflow that runs on 'pull_request' and set it as a required status check in branch protection.
D.Create a webhook to trigger a build on Azure Pipelines.
AnswerC

This ensures the CI check must pass.

Why this answer

Branch protection rules in GitHub can require status checks to pass before merging. You set up a rule that requires the CI workflow to succeed.

Full explanation →
290
MCQmedium

Your team uses Azure Boards to track work items. They want to automatically update the 'Remaining Work' field on a task when a developer completes a pull request linked to that task. Which Azure DevOps feature should you configure?

A.Define a pipeline variable to update the field during build.
B.Use a service hook to trigger an Azure Function that updates the work item.
C.Create a work item template that sets remaining work.
D.Configure a branch policy to automatically update work items on PR completion.
AnswerD

This is the correct feature to update work items when a PR is completed.

Why this answer

Option A is correct because branch policies with automation can update work items when PRs are completed. Option B is wrong because service hooks are for external integrations, not internal work item updates. Option C is wrong because work item templates only set initial values.

Option D is wrong because pipeline variables are for build/release, not work item updates.

Full explanation →
291
Multi-Selecthard

Which THREE components are required to implement a GitHub Actions self-hosted runner on a Windows virtual machine? (Choose three.)

Select 3 answers
A.GitHub Actions runner application installed on the VM
B.A personal access token (PAT) for registering the runner
C.Windows operating system installed on the VM
D.IIS (Internet Information Services) running on the VM
E.Docker Desktop installed on the VM
AnswersA, B, C

The runner application executes jobs.

Why this answer

Options A, B, and D are correct. A is the runner agent. B is required for the runner to authenticate.

D is the operating system for hosting. C is wrong because GitHub Actions does not require a web server. E is wrong because Docker is optional.

Full explanation →
292
MCQmedium

You are designing a build pipeline for a Java application that uses Maven. The build must run unit tests and integration tests separately. You want to publish test results to Azure Pipelines. Which task configuration should you use?

A.Use two Gradle tasks, one for unit tests and one for integration tests.
B.Use a single Maven task with goals 'test verify', and configure the task to publish test results.
C.Use two Maven tasks with goals 'test' and 'verify', and configure the Publish Test Results task to publish results from both runs.
D.Use two Visual Studio Test tasks, one for unit tests and one for integration tests.
AnswerC

Correct: Maven can run tests and PublishTestResults can publish results.

Why this answer

Option C is correct because it uses two separate Maven tasks with the 'test' and 'verify' goals, which allows unit tests and integration tests to run independently. The Publish Test Results task is then configured to consume the test result files (typically JUnit XML reports) from both runs, enabling Azure Pipelines to display a unified test summary. This approach aligns with the requirement to run unit and integration tests separately while still publishing all results.

Exam trap

The trap here is that candidates assume a single Maven task with both goals can achieve separation, but Azure Pipelines executes all goals in one run, so the tests are not isolated; the correct approach requires two distinct tasks to enforce separate execution and independent result publishing.

How to eliminate wrong answers

Option A is wrong because Gradle tasks are not applicable; the question specifies a Java application that uses Maven, not Gradle. Option B is wrong because using a single Maven task with goals 'test verify' runs both phases sequentially in the same Maven invocation, which does not satisfy the requirement to run unit tests and integration tests separately. Option D is wrong because Visual Studio Test tasks are designed for .NET test frameworks (e.g., MSTest, xUnit) and cannot directly execute Maven-based Java tests.

Full explanation →
293
Multi-Selecthard

Which THREE components are required to set up a self-hosted agent in Azure Pipelines? (Choose three.)

Select 3 answers
A.An Azure Resource Manager service connection
B.A personal access token (PAT) with Agent Pools (read, manage) scope
C.A machine (virtual or physical) to run the agent software
D.The agent software downloaded from the Azure DevOps organization
E.An Azure Active Directory account for the agent
AnswersB, C, D

PAT is required for the agent to authenticate with Azure DevOps.

Why this answer

Options B, C, and D are correct. B: A personal access token (PAT) is needed for authentication. C: The agent must be installed on a machine (Windows, Linux, or macOS).

D: The agent must be configured with the Azure DevOps organization URL and PAT. Option A is wrong because you don't need a service connection; the agent authenticates via PAT. Option E is wrong because Azure Pipelines agents do not require Azure Active Directory; they use PAT or other authentication.

Full explanation →
294
MCQhard

Your Azure Pipelines release pipeline deploys to multiple stages. You need to implement a manual approval gate that requires two specific users to approve before deployment proceeds to production. The approval should expire after 8 hours. Which configuration should you use?

A.Pre-deployment conditions: Add approvers (user1, user2) with 'All' policy and set timeout to 480 minutes
B.Pre-deployment conditions: Add approvers (user1, user2) with 'Any one' policy
C.Pre-deployment conditions: Add approvers (user1, user2) with 'All' policy and set 'Allow deployment without approval' to true
D.Post-deployment conditions: Add approvers (team) with 'All' policy
AnswerA

Requires both users to approve with an 8-hour timeout.

Why this answer

Option C is correct because you can add multiple approvers (individuals) and set a timeout for approval. Option A is wrong because requiring 'Any one' allows a single approver. Option B is wrong because 'Team' approval requires the team's collective approval, not two specific individuals.

Option D is wrong because pre-deployment conditions don't support timeout on approvals.

Full explanation →
295
MCQhard

Refer to the exhibit. You run a KQL query in Microsoft Sentinel to audit Azure Container Registry login failures. The result shows 15 failed push attempts to the 'contoso/webapp' repository and 3 failed pull attempts to 'contoso/api'. What is the most likely security implication?

A.The audit logs are not enabled for the container registry.
B.The container registry is misconfigured and allowing anonymous pushes.
C.The 'contoso/api' repository has been successfully pulled by an unauthorized user.
D.An attacker is attempting to push malicious images to the 'contoso/webapp' repository.
AnswerD

Multiple failed push attempts are a sign of unauthorized access attempts.

Why this answer

Multiple failed push attempts could indicate an attacker trying to push malicious images. Failed pulls are less concerning. The query does not show successful pushes.

The failures are not necessarily due to misconfiguration; they are authentication failures. Audit logs are already enabled, and RBAC assignment is a mitigation, not the most likely implication.

Full explanation →
296
MCQhard

You run the Azure CLI command shown in the exhibit as part of a release pipeline to deploy a ZIP package to an Azure App Service. The deployment succeeds, but the app does not start. What is the most likely cause?

A.The app's startup command is not configured
B.The resource group name is incorrect
C.The runtime stack is not specified in the command
D.The deployment slot is not specified
AnswerA

ZIP deploy does not set startup command; needs manual config.

Why this answer

Option B is correct because the ZIP deploy does not set the start command; you need to configure the startup file or command separately. Option A is wrong because the resource group name is only used for identification. Option C is wrong because the command does not require a slot name.

Option D is wrong because the command works without specifying the runtime stack.

Full explanation →
297
Multi-Selecteasy

Which TWO of the following are benefits of using Infrastructure as Code (IaC) over manual infrastructure management?

Select 2 answers
A.Consistent environment provisioning
B.Reduced configuration drift
C.Removes the need for testing
D.Eliminates the need for documentation
E.Lower infrastructure costs
AnswersA, B

IaC ensures environments are created from the same definition.

Why this answer

Options B and C are correct. Option B is correct because IaC ensures consistent environments. Option C is correct because IaC reduces configuration drift.

Option A is wrong because IaC does not reduce cost. Option D is wrong because IaC requires training. Option E is wrong because IaC does not eliminate testing.

Full explanation →
298
Multi-Selecteasy

Which TWO tools can be used to enforce branch protection policies in GitHub repositories? (Choose two.)

Select 2 answers
A.Azure Pipelines branch policies
B.Microsoft Intune compliance policies
C.GitHub branch protection rules
D.Microsoft Purview data classification
E.GitHub Actions workflows
AnswersA, C

Azure Pipelines can enforce branch policies on GitHub repositories.

Why this answer

Options A and C are correct. Option A: GitHub branch protection rules are built-in. Option C: Azure Pipelines can enforce policies via branch policy checks.

Option B is wrong because GitHub Actions can run checks but not enforce policies. Option D is wrong because Microsoft Intune manages devices. Option E is wrong because Microsoft Purview is for data governance.

Full explanation →
299
MCQhard

A multinational company uses Azure DevOps with a single project. The project has multiple teams in different time zones. They want to customize the process to reflect different working days for each team. What is the recommended approach?

A.Create a custom process for each time zone and assign teams accordingly.
B.Use the same process but create separate areas for each team, then configure working days per area path.
C.Use the same process and configure working days in the team settings for each team.
D.Use the same process and configure capacity planning for each team to account for time off.
AnswerC

Team settings allow per-team working days.

Why this answer

Option C is correct because Azure DevOps allows each team to have its own working days configured in team settings, independent of the process template. This enables teams in different time zones to define their own non-working days without modifying the shared process, which would affect all teams using that process.

Exam trap

The trap here is that candidates confuse team-level settings (like working days) with process-level customizations, assuming that different working days require different process templates, when in fact Azure DevOps separates team configuration from process inheritance.

How to eliminate wrong answers

Option A is wrong because creating a custom process for each time zone is unnecessary and introduces administrative overhead; working days are a team-level setting, not a process-level setting. Option B is wrong because area paths are used for organizing work items by feature or component, not for configuring working days; working days are configured per team, not per area path. Option D is wrong because capacity planning accounts for individual time off and sprint capacity, not recurring weekly working days for the entire team.

Full explanation →
300
MCQmedium

Your company is a startup developing a mobile application with a small team of 5 developers. You use GitHub Free and want to implement a simple but effective branching strategy that supports continuous delivery. The team wants to release new features every week and be able to hotfix critical bugs quickly. They currently have a main branch and feature branches, but sometimes features are merged to main before they are fully tested, causing issues. You need to recommend a strategy that minimizes risk while keeping the process lightweight. The team does not want to use long-lived branches. What should you recommend?

A.Use a single main branch and create release branches for each weekly release; features are merged to release branches, then release branches are merged to main after testing.
B.Use GitHub Flow: developers create feature branches from main, open pull requests with required CI and at least one review, then merge to main. Hotfixes follow the same process.
C.Allow developers to commit directly to main but require all commits to pass CI and be reviewed by at least one other developer after the fact.
D.Adopt GitFlow with develop and release branches.
AnswerB

GitHub Flow is lightweight, supports CI, and allows quick hotfixes.

Why this answer

GitHub Flow is the simplest and most effective strategy for a small team using GitHub Free that wants continuous delivery without long-lived branches. By requiring feature branches, pull requests with CI checks, and at least one review before merging to main, it ensures that all code is tested and reviewed before integration, preventing untested features from breaking main. Hotfixes follow the same lightweight process, allowing quick, safe patches without additional branch overhead.

Exam trap

The trap here is that candidates often overcomplicate branching strategies for small teams, mistakenly choosing GitFlow (Option D) or release branches (Option A) when GitHub Flow's simplicity and built-in CI/review gates perfectly address the need for risk mitigation without long-lived branches.

How to eliminate wrong answers

Option A is wrong because creating release branches for each weekly release adds unnecessary complexity and long-lived branches, contradicting the team's desire to avoid them; merging features to release branches before testing still risks untested code reaching production. Option C is wrong because allowing direct commits to main with post-hoc review violates the principle of protecting main from broken code; CI and review must happen before merge to prevent issues, not after. Option D is wrong because GitFlow introduces develop and release branches that are long-lived and overly complex for a 5-person startup doing weekly releases, adding overhead that contradicts the lightweight requirement.

Full explanation →
Page 3

Page 4 of 13

Page 5

All pages

12345678910111213

Practice AZ-400 by domain

Target a specific domain to shore up weak areas.

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