Courseiva

Microsoft Azure DevOps Engineer Expert AZ-400 (AZ-400) — Questions 301–375

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

Take a mock examExam hub
Page 4

Page 5 of 13

Page 6
301
Multi-Selecteasy

Which TWO of the following are true about multi-stage pipelines in Azure Pipelines?

Select 2 answers
A.Stages can run in parallel if dependencies allow.
B.Each stage can contain only one job.
C.Each stage must run on the same agent.
D.Stages cannot have conditions.
E.They are defined in a single YAML file.
AnswersA, E

Using dependsOn with none.

Why this answer

Multi-stage pipelines are defined in YAML and can include multiple sequential or parallel stages. Option A is correct because YAML is the primary definition. Option C is correct because stages can be parallelized using dependsOn.

Option B is incorrect because stages can run across multiple agents. Option D is incorrect because stages are not limited to one job. Option E is incorrect because stages can have conditions.

Full explanation →
302
MCQmedium

You receive a GitHub Dependabot alert as shown. The repository 'my-app' is internal. What is the best immediate action to mitigate the risk?

A.Dismiss the alert as it is a false positive
B.Create a private fork of the repository
C.Enable secret scanning on the repository
D.Update the lodash dependency to the latest patched version
AnswerD

This directly fixes the vulnerability.

Why this answer

Option A is correct because updating the dependency to a patched version is the best mitigation. Option B is wrong because dismissing the alert ignores the risk. Option C is wrong because creating a private fork does not fix the vulnerability.

Option D is wrong because enabling secret scanning does not address dependency vulnerabilities.

Full explanation →
303
Multi-Selecteasy

Which TWO Azure DevOps features can be used to implement change management processes?

Select 2 answers
A.Test plans.
B.Release approval gates.
C.Audit logging.
D.Project wiki.
E.Code search.
AnswersB, C

Approvals are a change management control.

Why this answer

Release approval gates (Option B) in Azure Pipelines allow you to enforce manual or automated checks before a release proceeds to a stage, implementing change management by requiring sign-offs or validation against external systems. Audit logging (Option C) captures a chronological record of changes to Azure DevOps resources, providing an immutable trail for compliance and change review processes.

Exam trap

The trap here is that candidates confuse features for documentation or testing (Test plans, Wiki) with those that enforce process controls, overlooking that change management requires approval workflows and audit trails, not just recording or searching content.

Full explanation →
304
MCQmedium

A team uses Azure Monitor to collect metrics from their Azure Kubernetes Service (AKS) cluster. They notice that container logs are missing from Log Analytics. The cluster was created with the default settings and no custom configuration was applied. What is the most likely reason for the missing logs?

A.The diagnostic setting for the AKS cluster is not configured to send logs to Log Analytics.
B.The Log Analytics workspace is in a different region than the AKS cluster.
C.The Data Collection Rule does not include the ContainerLogs table.
D.The Azure Monitor agent version on the nodes is outdated.
AnswerC

A DCR must specify which tables to collect; by default, container logs are not collected.

Why this answer

By default, an AKS cluster created with default settings does not have container logs (stdout/stderr) collected by Azure Monitor. Container logs require a Data Collection Rule (DCR) that includes the 'ContainerLogs' table. Without this DCR, the Azure Monitor agent will not collect container logs, even though other metrics may be sent to Log Analytics.

Exam trap

The trap here is that candidates often confuse diagnostic settings (which control platform logs) with Data Collection Rules (which control container logs), leading them to incorrectly select Option A.

How to eliminate wrong answers

Option A is wrong because the diagnostic setting for an AKS cluster controls platform logs (e.g., kube-apiserver logs), not container stdout/stderr logs; container logs are collected via the Azure Monitor agent and DCR, not via diagnostic settings. Option B is wrong because Log Analytics workspaces can receive data from resources in any region; region mismatch does not cause missing container logs. Option D is wrong because the Azure Monitor agent version does not affect the collection of container logs; the agent will collect logs as long as the DCR includes the ContainerLogs table, regardless of version.

Full explanation →
305
Multi-Selecthard

Which THREE are valid strategies for managing configuration in a multi-environment CI/CD pipeline?

Select 3 answers
A.Store configuration in environment-specific YAML variable files.
B.Embed configuration values directly into the container image.
C.Hardcode configuration in pipeline scripts for each environment.
D.Use Azure Key Vault references in variable groups.
E.Use variable groups linked to Azure DevOps library.
AnswersA, D, E

You can use variable templates per environment.

Why this answer

Using variable groups, Key Vault references, and environment-specific YAML variable files are all valid. Storing config in the container image is not recommended because it couples the image to an environment. Hardcoding in scripts is bad practice.

Full explanation →
306
MCQmedium

You are designing a compliance strategy for Azure DevOps pipelines that deploy to production. The company policy requires that all production deployments must be reviewed by a security lead. Additionally, the deployment must use a specific release pipeline that has been pre-approved. How should you implement this?

A.Create a branch policy that requires the security lead to approve the pull request before merging.
B.Define a 'production' environment in Azure DevOps and configure an approval check that requires the security lead. Have the pipeline deploy to that environment.
C.Use a Classic release pipeline with a pre-deployment approval gate for the production stage.
D.Store the approved pipeline definition in a variable group and reference it in all pipelines.
AnswerB

Environment approvals provide the required manual review gate.

Why this answer

Option B is correct because Azure DevOps environments allow you to define approval checks that must be satisfied before a deployment proceeds. By creating a 'production' environment and adding a pre-deployment approval check requiring the security lead, you enforce the mandatory review. The pipeline then deploys to that environment, ensuring only the pre-approved release pipeline is used.

Exam trap

The trap here is that candidates often confuse branch policies (which control code changes) with deployment approvals (which control release execution), leading them to choose Option A instead of the environment-based approval check in Option B.

How to eliminate wrong answers

Option A is wrong because a branch policy requiring pull request approval only controls code merging, not the actual deployment to production; it does not enforce a pre-approved release pipeline or a security lead review at deployment time. Option C is wrong because Classic release pipelines are legacy and do not integrate with modern YAML-based environments and their approval checks; the question implies a modern pipeline approach, and Classic pipelines lack the same granular environment-based approval controls. Option D is wrong because storing the pipeline definition in a variable group does not enforce any approval or review process; it merely centralizes configuration and does not prevent unauthorized deployments.

Full explanation →
307
MCQeasy

Your team uses Azure Pipelines to build a .NET Core application. You notice that the build takes too long because it restores NuGet packages every time. What is the best way to improve build performance?

A.Configure the build to use a self-hosted agent with previously restored packages
B.Use a private agent with a faster network connection
C.Use a Microsoft-hosted agent with a larger SKU
D.Enable the 'Cache' task to cache the NuGet packages folder
AnswerD

Caching packages avoids downloading them each time, significantly speeding up builds.

Why this answer

Option B is correct because caching package restore speeds up builds. Option A is wrong because piped builds are not a concept. Option C is wrong because a hosted agent does not cache by default.

Option D is wrong because a self-hosted agent does not automatically cache.

Full explanation →
308
MCQeasy

Your team uses Microsoft Defender for Cloud to monitor Azure resources. You need to ensure that all Azure DevOps pipelines are scanned for security misconfigurations before deployment. Which integration should you enable?

A.Connect Azure DevOps to Microsoft Sentinel.
B.Enable the 'Defender for DevOps' integration in Microsoft Defender for Cloud.
C.Deploy Microsoft Intune policies to Azure DevOps agents.
D.Configure Microsoft Purview to scan Azure DevOps repositories.
AnswerB

This integration scans pipelines for misconfigurations.

Why this answer

Option A is correct because Microsoft Defender for Cloud can integrate with Azure DevOps to scan infrastructure as code templates. Option B is incorrect because Microsoft Sentinel is a SIEM, not a scanner. Option C is incorrect because Microsoft Purview is for data governance.

Option D is incorrect because Microsoft Intune manages devices.

Full explanation →
309
MCQhard

Refer to the exhibit. You have an availability set with two VMs. One VM shows a degraded availability state. What is the most likely impact on application availability?

A.The application will be fully resilient to both planned and unplanned maintenance events.
B.The application will be vulnerable to unplanned hardware failures that affect the degraded VM's host.
C.The application will experience downtime during planned maintenance events.
D.The application will continue to run without any impact because the other VM is healthy.
AnswerB

Correct. The degraded VM is not on fault-tolerant infrastructure, meaning if its host fails, the VM will go down, potentially causing application downtime if the other VM cannot handle the load.

Why this answer

The availability set provides fault tolerance by distributing VMs across fault domains. A degraded state indicates one VM is on a host with potential issues, making it susceptible to unplanned hardware failures. The other VM remains healthy, but the application may not be fully resilient.

Full explanation →
310
MCQeasy

Your Azure Pipelines build takes 45 minutes. You want to reduce build time by caching dependencies. Which task should you add to the pipeline?

A.PublishBuildArtifacts@1
B.CopyFiles@2
C.DownloadBuildArtifacts@0
D.Cache@2
AnswerD

The Cache task is designed for caching dependencies.

Why this answer

The Cache task allows you to cache folders (like npm packages or NuGet packages) to speed up subsequent runs.

Full explanation →
311
Multi-Selectmedium

Which TWO of the following are valid strategies to reduce build times in Azure Pipelines? (Select TWO.)

Select 2 answers
A.Increase the number of retained artifacts.
B.Use a self-hosted agent pool.
C.Use parallel jobs to run tasks concurrently.
D.Use pipeline caching for dependencies.
E.Disable test execution.
AnswersC, D

Parallel execution reduces overall build time.

Why this answer

Options A and C are correct. Pipeline caching (A) avoids re-downloading dependencies; parallel jobs (C) splits work across multiple agents. Option B is wrong because self-hosted agents may not reduce time if not properly sized.

Option D is wrong because increasing artifact retention doesn't affect build time. Option E is wrong because disabling tests may compromise quality.

Full explanation →
312
MCQmedium

Your company is migrating from on-premises TFS to Azure DevOps Services in the cloud. The security policy mandates that all access to Azure DevOps must go through a conditional access policy that requires multi-factor authentication (MFA) for users outside the corporate network. Additionally, the policy requires that service accounts (used for automated deployments) must use device-based authentication and cannot be interactive. You are configuring Microsoft Entra ID (formerly Azure AD) conditional access. The Azure DevOps organization is connected to the corporate Entra ID tenant. You have the following options: Option A: Create a conditional access policy that applies to all users and service principals, requiring MFA for all cloud apps, and exclude the Azure DevOps app from the policy. Option B: Create a conditional access policy that targets the Azure DevOps app, grant access requiring MFA for all users, and create a separate policy for service accounts that requires device compliance. Option C: Create a conditional access policy that applies to the Azure DevOps app, requiring MFA for all users, and exclude service accounts by user group. Then create a separate policy for service accounts that requires a compliant device. Option D: Use Azure DevOps IP address restrictions to block external traffic and rely on VPN for external users. Which option best meets the requirements?

A.Create a conditional access policy that applies to all users and service principals, requiring MFA for all cloud apps, and exclude the Azure DevOps app
B.Create a conditional access policy that targets the Azure DevOps app, grant access requiring MFA for all users, and create a separate policy for service accounts that requires device compliance
C.Use Azure DevOps IP address restrictions to block external traffic and rely on VPN for external users
D.Create a conditional access policy that applies to the Azure DevOps app, requiring MFA for all users, and exclude service accounts by user group. Then create a separate policy for service accounts that requires a compliant device
AnswerD

This correctly enforces MFA for users and device compliance for service accounts.

Why this answer

Option C is correct. It correctly applies MFA to all users except service accounts, and uses device compliance for service accounts. Option A excludes the Azure DevOps app, which would not enforce MFA.

Option B applies MFA to service accounts as well, which is not allowed for automated accounts. Option D does not provide MFA and is less secure.

Full explanation →
313
MCQhard

Your company develops a microservices-based application deployed on Azure Kubernetes Service (AKS). The CI/CD pipeline uses Azure Pipelines. The development team has recently adopted a trunk-based development strategy where all feature work is done on short-lived branches that merge to main at least daily. The release pipeline must automatically deploy to a development environment on each commit to main, and to a staging environment after a manual approval. The staging environment is used for integration tests and must remain stable. You need to design the release pipeline strategy to support this workflow. What should you do?

A.Create a single release pipeline with one stage that deploys to both dev and staging simultaneously, and add a manual intervention task before staging deployment.
B.Create a single release pipeline with two stages: 'Dev' triggered automatically on successful build, and 'Staging' with a pre-deployment approval gate.
C.Create two separate release pipelines: one for dev with continuous deployment trigger, and one for staging with a manual trigger.
D.Create a single release pipeline with two stages: 'Dev' triggered automatically, and 'Staging' with a post-deployment approval gate and disable continuous deployment trigger.
AnswerB

This provides automatic deployment to dev and controlled deployment to staging with approval.

Why this answer

Option A is correct: A single release pipeline with multiple stages (dev and staging) and an approval gate on staging meets the requirements. Option B is incorrect because separate pipelines would cause duplication and maintenance overhead. Option C is incorrect because multiple environments in a single stage would not allow different triggers.

Option D is incorrect because disabling CD for staging would require manual promotion, which is not desired.

Full explanation →
314
MCQmedium

Your build pipeline uses a self-hosted agent in your on-premises network. The agent pool is configured to use the 'latest' agent version. Recently, a new version of the Azure Pipelines agent was released, and your builds started failing because the new agent requires .NET 6.0, which is not installed on the agent machine. What is the best way to prevent this issue in the future?

A.Configure the agent pool to use a specific agent version (e.g., '2.210.0') and test new versions in a separate pool before updating.
B.Switch to using Microsoft-hosted agents instead of self-hosted.
C.Disable automatic agent updates on the self-hosted agents.
D.Install .NET 6.0 on the agent machine to meet the new requirement.
AnswerA

Pinning the version allows controlled upgrades and testing.

Why this answer

Option C is correct because pinning the agent to a specific major version allows you to control updates and test compatibility before upgrading. Option A is wrong because disabling updates is not recommended and may cause security issues. Option B is wrong because installing .NET 6.0 is a reactive fix, not a preventive measure.

Option D is wrong because using Microsoft-hosted agents avoids the issue but is not always feasible for on-premises needs.

Full explanation →
315
MCQhard

Your organization uses GitHub and wants to enforce that all commits to the main branch are signed with a GPG key that is verified against the user's GitHub account. Additionally, you want to block unsigned commits even if the committer is a repository admin. Which configuration should you use?

A.Add a pre-receive hook that rejects unsigned commits.
B.Enable 'Require signed commits' and set 'Include administrators' to false.
C.Enable 'Require signed commits' and set 'Include administrators' to true.
D.Enable 'Require signed commits' and configure web commit signing.
AnswerC

This enforces signed commits for all users, including admins.

Why this answer

Option C is correct because enabling 'Require signed commits' in a GitHub branch protection rule, combined with setting 'Include administrators' to true, enforces that every commit pushed to the protected branch must be signed with a GPG key verified against the user's GitHub account, and this restriction applies even to repository administrators. This configuration blocks unsigned commits entirely, meeting the requirement to enforce signing for all users including admins.

Exam trap

The trap here is that candidates often confuse 'Include administrators' with a separate setting or assume that admins are always exempt, leading them to choose Option B, but the question explicitly requires blocking unsigned commits for all users including admins, so 'Include administrators' must be set to true.

How to eliminate wrong answers

Option A is wrong because pre-receive hooks are only available in GitHub Enterprise Server (self-hosted) and are not supported in GitHub.com (SaaS), so this option is not applicable for a standard GitHub organization. Option B is wrong because setting 'Include administrators' to false would exempt repository administrators from the signing requirement, allowing them to push unsigned commits, which violates the requirement to block unsigned commits even for admins. Option D is wrong because 'web commit signing' is a feature for automatically signing commits made via the GitHub web interface, but it does not enforce signing for commits pushed via Git CLI or other tools, and it does not block unsigned commits from being pushed.

Full explanation →
316
MCQeasy

Your team uses Git and wants to ensure that all commits follow a consistent message format. Which approach should you use?

A.Add a step in Azure Pipelines to validate commit messages
B.Use a client-side Git hook (commit-msg) to validate the message
C.Create a GitHub Actions workflow that checks commit messages on push
D.Configure a branch policy in Azure Repos to enforce commit message format
AnswerB

Client-side hooks enforce locally before commit.

Why this answer

A client-side Git hook, specifically the commit-msg hook, runs locally on the developer's machine before the commit is finalized, allowing immediate validation of the commit message format. This ensures that every commit adheres to the team's convention at the point of creation, without relying on server-side enforcement or pipeline execution.

Exam trap

The trap here is that candidates often assume server-side enforcement (branch policies or pipeline validation) is the only way to enforce commit message standards, overlooking the fact that client-side hooks provide immediate, local validation before the commit is ever recorded.

How to eliminate wrong answers

Option A is wrong because adding a step in Azure Pipelines validates commit messages only after the code is pushed to the remote repository, which is too late to prevent non-compliant commits from being created locally and pushed. Option C is wrong because a GitHub Actions workflow that checks commit messages on push also runs after the push event, meaning non-compliant commits can still be pushed before the workflow detects the issue. Option D is wrong because branch policies in Azure Repos can enforce certain conditions (e.g., required reviewers, build validation) but do not natively support validating commit message format; they cannot inspect or reject commits based on message content.

Full explanation →
317
MCQhard

Refer to the exhibit. You have configured a Conditional Access policy in Microsoft Entra ID to require MFA for Azure DevOps. However, users report that they can still access Azure DevOps without MFA when using a PAT for authentication. What is the most likely reason?

A.The policy should include 'Require device to be marked as compliant'.
B.PATs are not subject to Conditional Access policies because they use legacy authentication.
C.The policy should be scoped to 'All cloud apps' instead of just Azure DevOps.
D.The Conditional Access policy is not enabled.
AnswerB

PATs are considered legacy authentication and do not satisfy the MFA requirement; they are not evaluated by Conditional Access.

Why this answer

Conditional Access policies do not apply to legacy authentication protocols or tokens like PATs. PATs are considered non-interactive and bypass device-based policies. The policy is correctly configured for interactive sessions, but PATs are not subject to the same conditions.

Enabling additional client app conditions or using a trusted location would not help. Blocking legacy authentication is a separate policy.

Full explanation →
318
MCQmedium

Your team uses Azure Pipelines to deploy a web app. They want to automatically roll back the deployment if the post-deployment smoke tests fail. What is the recommended approach?

A.Define an approval gate that requires manual sign-off after deployment.
B.Use a deployment gate with a monitoring tool that automatically initiates a rollback if health check fails.
C.Set up a manual intervention step in the pipeline to decide rollback.
D.Configure a release variable that toggles between deployment slots.
AnswerB

Gates can evaluate health and trigger rollback.

Why this answer

Option B is correct because Azure Pipelines supports deployment gates that can integrate with monitoring tools (e.g., Azure Monitor, Application Insights) to evaluate health metrics after deployment. If the gate detects a failure (e.g., a smoke test health check fails), it can automatically trigger a rollback to the previous stable version, ensuring zero manual intervention and faster recovery.

Exam trap

The trap here is that candidates often confuse manual approval gates or manual intervention steps with automated rollback, failing to recognize that only a deployment gate with a monitoring tool can provide the continuous health evaluation and automatic rollback required for a fully automated recovery process.

How to eliminate wrong answers

Option A is wrong because an approval gate with manual sign-off does not automate rollback; it only pauses the pipeline for human approval, which defeats the goal of automatic rollback on smoke test failure. Option C is wrong because a manual intervention step requires a human to decide and execute the rollback, which is not automated and introduces delay and potential error. Option D is wrong because a release variable that toggles between deployment slots only switches traffic between slots but does not automatically trigger a rollback based on smoke test results; it requires manual or separate logic to detect failure and toggle the variable.

Full explanation →
319
MCQhard

Your Azure DevOps release pipeline deploys to Azure Kubernetes Service (AKS). You need to ensure that the deployment is rolled back automatically if the health checks fail within 5 minutes after deployment. The AKS cluster uses a canary deployment strategy. What should you use?

A.Use an Azure CLI task to run 'kubectl rollout undo' in a post-deployment script.
B.Use a Helm upgrade task with --wait and --timeout flags.
C.Use the Kubernetes manifest task with 'canary' deployment strategy and configure 'stabilityCheck' and 'rollback' settings.
D.Use the Kubectl task with a 'rollback' subcommand condition.
AnswerC

The Kubernetes manifest task supports canary deployments with automatic rollback on stability failure.

Why this answer

Option B is correct because the Kubernetes manifest task can be configured with a canary strategy and automatic rollback based on deployment stability checks. Option A is wrong because the Helm task does not natively support canary rollback. Option C is wrong because the Azure CLI task would require custom scripting.

Option D is wrong because the Kubectl task does not have built-in canary rollback.

Full explanation →
320
MCQeasy

Your team uses GitHub repositories and wants to ensure that all code changes are signed by a verified contributor before merging. Which branch protection rule should you enable?

A.Require signed commits
B.Require pull request reviews before merging
C.Require linear history
D.Restrict who can push to matching branches
AnswerA

This ensures commits are signed with a verified key.

Why this answer

Option B is correct because requiring signed commits ensures that only commits signed by a verified GPG or S/MIME key are accepted. Option A is wrong because it only requires pull request reviews, not commit signing. Option C is wrong because it restricts who can push, not signing.

Option D is wrong because it enforces linear history, not signing.

Full explanation →
321
MCQeasy

You need to create a pipeline that triggers only when changes are made to files in the 'src/api' folder. Which trigger configuration should you use?

A.trigger: branches: include: - 'main'
B.trigger: paths: exclude: - 'src/api/*'
C.trigger: tags: include: - 'v*'
D.trigger: paths: include: - 'src/api/*'
AnswerD

Include filter triggers on changes to that path.

Why this answer

Option A is correct because the 'paths' filter with 'include' triggers only for changes in that path. Option B is wrong because 'exclude' would ignore that path. Option C is wrong because 'tags' filter by tag.

Option D is wrong because 'branches' filter by branch.

Full explanation →
322
MCQeasy

You are designing a release pipeline for a .NET application. The pipeline must deploy to multiple environments (Dev, Test, Prod) with manual approval at each stage. Which release trigger should you configure for the production stage?

A.Pull request trigger from the main branch.
B.Continuous deployment trigger after a successful build.
C.Manual trigger with pre-deployment approvals.
D.Scheduled trigger set to run nightly.
AnswerC

Manual trigger requires user initiation, and approvals can be added for control.

Why this answer

Option B is correct because a manual trigger with approval ensures that deployment to production only happens after explicit approval. Option A is wrong because continuous deployment trigger would skip approvals. Option C is wrong because scheduled trigger is not appropriate for manual approval.

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

Full explanation →
323
MCQmedium

Your organization uses Azure DevOps for a multi-tier web application. The application consists of a React frontend, a Node.js API, and a SQL database. The security team has mandated the following: (1) All code changes must be scanned for secrets before merging to the main branch. (2) Infrastructure-as-code templates (ARM) must be validated for security compliance before deployment. (3) Production deployments must use a service connection with a managed identity that has only the required permissions. You have set up a CI/CD pipeline with two stages: Build and Release. The Build stage runs on pull requests and the Release stage deploys to a production environment. Recently, a developer accidentally committed a secret (API key) to a configuration file. The secret was not caught by the pipeline, and the code was merged to main. You need to prevent this in the future. What should you do?

A.Configure a branch policy to require at least two reviewers on pull requests to the main branch.
B.Implement a manual approval gate on the Release stage to review each deployment for secrets.
C.Use a pipeline decorator to inject a validation step that runs Azure Policy on the code repository.
D.Add a 'Credential Scanner' task to the Build pipeline and configure it to fail the build if any secrets are found. Also, move all secrets to Azure Key Vault and reference them via variable groups.
AnswerD

Automated secret scanning prevents secrets from being merged, and Key Vault centralizes secret management.

Why this answer

Option D is correct because it directly addresses the root cause: secrets were not being scanned before merge. The Credential Scanner task (part of Microsoft Security Code Analysis) scans for hardcoded secrets and can fail the build, preventing the merge. Moving secrets to Azure Key Vault and referencing them via variable groups (linked to the vault) ensures secrets are never stored in the repository, eliminating the risk of accidental commits.

Exam trap

The trap here is that candidates may confuse Azure Policy (which governs Azure resource compliance) with code scanning tools, or mistakenly think that manual reviews or approval gates are sufficient to catch secrets before merge, when automated scanning is required by the mandate.

How to eliminate wrong answers

Option A is wrong because requiring two reviewers does not prevent a secret from being committed; reviewers may not catch a secret in a configuration file. Option B is wrong because a manual approval gate on the Release stage only catches secrets after they have already been merged to main, which violates the mandate to scan before merging. Option C is wrong because Azure Policy is used for governance of Azure resources (e.g., ARM template compliance), not for scanning code repositories for secrets; a pipeline decorator cannot run Azure Policy on a Git repository.

Full explanation →
324
MCQhard

Your company uses GitHub and wants to implement a compliance framework that requires signed commits for all repositories. Developers use various IDEs and Git clients. What is the best way to enforce signed commits across the organization?

A.Set the repository to 'Require pull request reviews before merging' and rely on reviewers to check commit signatures.
B.Ask developers to configure GPG keys and sign commits manually.
C.Enable 'Require signed commits' in the branch protection rules for the default branch.
D.Use a GitHub Action that fails if commits are unsigned.
AnswerC

This enforces signed commits on the branch.

Why this answer

Option C is correct because GitHub allows repository administrators to enable 'Require signed commits' in branch protection rules. Option A is incorrect because it is not enforceable; commits can be unsigned. Option B is incorrect because it only encourages, not enforces.

Option D is incorrect because it does not enforce signing.

Full explanation →
325
MCQmedium

Your Azure Pipelines build fails intermittently due to transient network errors when downloading NuGet packages. You want to implement retry logic. What is the best approach?

A.Add a PowerShell task that wraps the NuGet restore in a retry loop
B.Increase the number of parallel jobs to average out failures
C.Use a deployment group to deploy the build to a staging environment
D.Configure a build retention policy to automatically retry failed builds
AnswerA

An inline script with retry logic can handle transient errors.

Why this answer

Option C is correct because a retry task with an inline script can handle transient errors. Option A is wrong because a build retention policy does not affect retries. Option B is wrong because parallel jobs do not retry.

Option D is wrong because a deployment group is for deployments, not builds.

Full explanation →
326
MCQeasy

Your team uses GitHub and wants to automatically detect exposed credentials in code. Which GitHub feature should you enable?

A.Code scanning.
B.Dependabot.
C.Secret scanning.
D.GitHub Actions.
AnswerC

Secret scanning detects secrets like API keys and tokens.

Why this answer

Option A is correct because secret scanning detects credentials and other secrets in repositories. Option B is wrong because Dependabot handles dependency vulnerabilities. Option C is wrong because code scanning finds code quality issues.

Option D is wrong because GitHub Actions is for CI/CD, not scanning for secrets.

Full explanation →
327
MCQhard

You are troubleshooting an intermittent performance issue in a web application. Application Insights shows a high number of failed dependency calls to Azure SQL Database. The errors are SqlException with error code -2 (timeout). What is the most likely cause and recommended fix?

A.The application is exhausting the connection pool; increase Max Pool Size in the connection string.
B.The SQL Server firewall is blocking the application IP; add a firewall rule.
C.The database is experiencing deadlocks; enable read committed snapshot isolation.
D.The database DTU limit is being exceeded; scale up the service tier.
AnswerA

Timeouts often indicate pool exhaustion.

Why this answer

A is correct because SqlException with error code -2 indicates a connection timeout, which in a high-traffic scenario is most commonly caused by the application exhausting the connection pool. When all connections in the pool are in use and the wait time for a free connection exceeds the Connect Timeout (default 15 seconds), new requests fail with this error. Increasing Max Pool Size in the connection string (e.g., Max Pool Size=200) allows more concurrent connections, reducing contention.

Exam trap

The trap here is that candidates confuse a connection timeout (error -2) with a query timeout or resource throttling, leading them to choose DTU scaling or deadlock solutions instead of recognizing the connection pool exhaustion pattern.

How to eliminate wrong answers

Option B is wrong because a firewall block would produce a different error (e.g., SqlException with error 53 or 18456, not -2) and would affect all requests consistently, not intermittently. Option C is wrong because deadlocks generate error code 1205, not -2, and are resolved by retry logic or snapshot isolation, not by adjusting pool size. Option D is wrong because exceeding DTU limits causes throttling with error codes like 10928 or 40501, not a timeout error -2, and scaling up would not fix connection pool exhaustion.

Full explanation →
328
MCQmedium

Your team is using GitHub Flow for a web application. Developers create feature branches from main, make changes, and open pull requests. Recently, several pull requests were merged without required reviews because the branch protection rules were not enforced on the main branch. What should you do to ensure all pull requests to main require at least one reviewer?

A.Enable the 'Require a pull request before merging' rule in branch protection for main, and set 'Required approvals' to 1.
B.Configure the repository to automatically delete head branches after pull requests are merged.
C.Enable the 'Require branches to be up to date' rule in branch protection for main.
D.Add a CODEOWNERS file and configure it so that every file has at least one owner.
AnswerA

This enforces that pull requests require at least one approval before merging.

Why this answer

Option B is correct because branch protection rules in GitHub can enforce required pull request reviews before merging. Option A is incorrect because deleting the branch after merge does not enforce reviews. Option C is incorrect because require branches to be up to date is not the same as requiring reviews.

Option D is incorrect because code owners are optional, not mandatory.

Full explanation →
329
Multi-Selecteasy

Which TWO triggers can be used to start a pipeline automatically in Azure Pipelines? (Choose two.)

Select 2 answers
A.Pipeline completion trigger
B.Continuous integration (CI) trigger on a branch push
C.Manual trigger via the DevOps portal
D.Schedule trigger
E.Pull request (PR) trigger
AnswersB, E

A push to a branch matching the trigger starts the pipeline.

Why this answer

CI triggers (push to branch) and PR triggers are standard automatic triggers. Option C is wrong because schedule triggers are automatic but not triggered by events. Option D is wrong because pipeline completion trigger is another pipeline, not a direct trigger.

Option E is wrong because manual triggers require human action.

Full explanation →
330
MCQhard

A financial services company uses Azure DevOps and requires that all secrets (e.g., API keys, connection strings) be stored in Azure Key Vault. They have a pipeline that runs automated tests and deploys to staging. The pipeline uses a variable group linked to Key Vault to retrieve secrets. Recently, the pipeline failed with the error: 'Secret 'DbPassword' not found in Key Vault 'kv-prod'. Ensure the secret exists and the service principal has List permission.' The secret exists in the vault. What is the most likely cause?

A.The variable group is linked to the wrong Key Vault instance.
B.The variable name in the variable group does not exactly match the secret name in Key Vault (case-sensitive).
C.The service principal does not have Get permission on the secret.
D.The Key Vault is in a different Azure region than the Azure DevOps organization.
AnswerB

Azure DevOps maps variable names to secret names, and the match is case-sensitive.

Why this answer

Option B is correct because variable groups linked to Azure Key Vault in Azure DevOps require an exact case-sensitive match between the variable name in the variable group and the secret name in Key Vault. Even though the secret 'DbPassword' exists in the vault, if the variable group defines the variable as 'dbpassword' or 'DBPassword', the lookup will fail with the 'not found' error. The error message explicitly states the secret was not found, which is the typical symptom of a case mismatch, not a permissions or connectivity issue.

Exam trap

The trap here is that candidates assume the error 'secret not found' always means the secret is missing or permissions are wrong, but Azure DevOps specifically tests the case-sensitive mapping between variable group variable names and Key Vault secret names, which is a subtle but critical detail.

How to eliminate wrong answers

Option A is wrong because the error message specifically names Key Vault 'kv-prod', indicating the pipeline is targeting that vault; if the variable group were linked to a different vault, the error would reference that other vault's name. Option C is wrong because the error message mentions 'List permission', not 'Get permission'; the service principal must have both Get and List permissions on secrets, but the error explicitly says 'List permission' is required, and the secret exists, so the issue is not a missing Get permission. Option D is wrong because Azure Key Vault and Azure DevOps can operate across different Azure regions without any impact on secret retrieval; region mismatch does not cause 'secret not found' errors.

Full explanation →
331
Matchingmedium

Match each Azure Pipeline concept to its definition.

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

Concepts
Matches

Compute resource to run jobs

Logical boundary for pipeline phases

Sequence of steps on a single agent

Atomic build or deployment action

Why these pairings

Core pipeline components in Azure Pipelines.

Full explanation →
332
MCQhard

Your organization uses GitHub and wants to implement a monorepo strategy for multiple related projects. Which approach best optimizes CI/CD pipeline performance by only building projects that have changed?

A.Use a single workflow that builds all projects on every push
B.Use submodules to separate projects
C.Use workflow templates and composite actions
D.Use path filters in GitHub Actions workflows
AnswerD

Triggers only for changed paths.

Why this answer

Option D is correct because GitHub Actions path filters (using `on.push.paths` or `on.pull_request.paths`) allow you to trigger workflows only when changes are made to specific directories or files. In a monorepo, this ensures that CI/CD pipelines run exclusively for the projects that have been modified, avoiding unnecessary builds and significantly improving performance.

Exam trap

The trap here is that candidates confuse workflow reuse mechanisms (templates, composite actions) with conditional execution, or assume submodules are the standard monorepo approach, when in fact path filters are the native and efficient way to achieve selective builds in GitHub Actions.

How to eliminate wrong answers

Option A is wrong because a single workflow that builds all projects on every push ignores the monorepo optimization goal—it would rebuild unchanged projects, wasting compute time and slowing feedback loops. Option B is wrong because submodules are designed for managing external dependencies or separate repositories, not for optimizing CI/CD within a monorepo; they add complexity and do not inherently provide path-based build skipping. Option C is wrong because workflow templates and composite actions are reuse and abstraction mechanisms, not a solution for conditional execution based on changed paths; they help reduce duplication but do not control which projects are built.

Full explanation →
333
MCQeasy

You are creating a release pipeline that uses Azure Pipelines to deploy to multiple virtual machines. You need to ensure that the deployment runs on each machine in parallel. Which deployment strategy should you use?

A.Blue-green deployment
B.Canary deployment
C.Rolling deployment
D.Run once deployment with parallel execution
AnswerD

Run once with parallel runs the job on all targets simultaneously.

Why this answer

Option D is correct because the 'runOnce' strategy with 'parallel' deployment option runs the job on multiple targets simultaneously. Option A is wrong because rolling strategy updates a subset at a time. Option B is wrong because canary is a phased rollout.

Option C is wrong because blue-green swaps between environments.

Full explanation →
334
MCQmedium

Your team uses feature flags to manage feature releases. You need to ensure that a feature flag is automatically turned off for all users except the development team after a production incident. What is the best approach?

A.Create a separate branch with the feature disabled and deploy it.
B.Use a feature management system like Azure App Configuration with a targeting filter to enable only for the dev team.
C.Set an environment variable in the production environment to disable the feature.
D.Manually toggle the feature flag off in the app configuration.
AnswerB

This allows dynamic control without redeployment.

Why this answer

Option B is correct because Azure App Configuration's feature management system provides a built-in targeting filter that allows you to dynamically enable a feature flag for specific users or groups (e.g., the development team) while disabling it for all others. This approach supports real-time, no-deployment changes, which is essential for quickly responding to a production incident without modifying code or redeploying.

Exam trap

The trap here is that candidates may choose manual toggling (Option D) because it seems simplest, but they overlook the requirement to keep the feature enabled for the development team, which requires a targeting filter rather than a global off switch.

How to eliminate wrong answers

Option A is wrong because creating a separate branch and redeploying introduces unnecessary delay and risk, and it contradicts the purpose of feature flags, which are designed to toggle features without code changes or deployments. Option C is wrong because environment variables require a restart or redeployment to take effect, and they lack the granular user/group targeting needed to enable the feature only for the development team. Option D is wrong because manually toggling the flag off in the app configuration would disable it for all users, including the development team, which does not meet the requirement of keeping it enabled for the dev team.

Full explanation →
335
Multi-Selectmedium

Which TWO are valid strategies for managing secrets in a GitHub Actions workflow?

Select 2 answers
A.Use OpenID Connect to authenticate to Azure without storing any credentials.
B.Hardcode the secret in the YAML file.
C.Set the secret as an environment variable in the runner's shell profile.
D.Base64-encode the secret and include it directly in the workflow file.
E.Store the secret as an encrypted GitHub secret and reference it using ${{ secrets.SECRET_NAME }}.
AnswersA, E

OIDC eliminates the need for stored secrets for Azure authentication.

Why this answer

GitHub secrets and OIDC are both secure methods. Option B is wrong because base64 is not encryption. Option C is wrong because hardcoding is insecure.

Option D is wrong because environment variables are visible.

Full explanation →
336
MCQmedium

Your team uses Azure Repos for source control. You need to enforce that all builds must pass unit tests before code can be merged into the main branch. Which branch policy should you configure?

A.Add a build validation policy that triggers the CI pipeline and requires it to succeed.
B.Require a linked work item.
C.Require a minimum number of reviewers.
D.Require comment resolution.
AnswerA

Build validation enforces that the pipeline runs and succeeds before merging.

Why this answer

Option B is correct because a branch policy with a build validation requires a specific build pipeline to succeed before merging. Option A is incorrect because it only requires a review, not a build. Option C is incorrect because commenting is not required.

Option D is incorrect because commit message requirements do not enforce builds.

Full explanation →
337
MCQmedium

You run the PowerShell command shown in the exhibit. The virtual network already exists. What is the outcome?

A.The virtual network's tags are updated to the specified tags.
B.The virtual network is deleted and recreated.
C.An error occurs because the virtual network already exists.
D.A new virtual network with a different name is created.
AnswerA

-Force allows updating tags.

Why this answer

The `New-AzVirtualNetwork` cmdlet with the `-Force` parameter will update an existing virtual network if it already exists, rather than failing or recreating it. The `-Tag` parameter specifies the tags to apply, so the existing virtual network's tags are updated to the specified values. This behavior is consistent with Azure PowerShell's idempotent design for resource management.

Exam trap

The trap here is that candidates assume `New-Az*` cmdlets always create new resources and will error if the resource exists, but the `-Force` parameter changes this behavior to an update operation.

How to eliminate wrong answers

Option B is wrong because `New-AzVirtualNetwork -Force` does not delete and recreate the virtual network; it updates the existing resource in place. Option C is wrong because the `-Force` parameter suppresses the 'resource already exists' error, allowing the command to proceed with an update. Option D is wrong because the command uses the same name (from the `-Name` parameter) and does not create a new virtual network with a different name.

Full explanation →
338
MCQmedium

You are designing a release pipeline for a microservices application where each service is built as a Docker container and deployed to Azure Kubernetes Service (AKS). You want to ensure that each service is deployed independently to the same cluster. The services have dependencies on each other. Which deployment strategy should you use?

A.Canary deployment with traffic splitting via Istio.
B.Immutable infrastructure with new cluster per deployment.
C.Rolling update using Kubernetes Deployment strategies.
D.Blue-green deployment to AKS using Kubernetes namespaces for isolation.
AnswerD

Blue-green allows independent deployment with traffic switching.

Why this answer

Blue-green deployment is ideal for microservices with dependencies because it allows you to deploy a new version of a service alongside the old version and then switch traffic after testing. Rolling updates can cause issues if dependencies are not compatible. Canary releases are gradual but more complex.

Option A is correct because blue-green provides isolation and easy rollback. Option B is not suitable for dependencies. Option C is more for testing.

Option D is simpler but riskier.

Full explanation →
339
MCQmedium

You have deployed an Azure Resource Manager (ARM) template for a scheduled query rule as shown. The rule is enabled and targets an Application Insights resource. However, no alerts are firing despite HTTP 500 errors occurring. What is the most likely cause?

A.The severity is set to 2, which suppresses the alert.
B.The threshold of 100 is too high; the rule should use a percentage-based condition on error rate.
C.The metric name 'requests/count' is misspelled; it should be 'requests/count' (correct).
D.The dimension filter for 'request/resultCode' includes '500' but should also include '5xx' wildcard.
AnswerB

The rule should be based on failed requests percentage, not absolute count.

Why this answer

Option B is correct because the threshold of 100 is an absolute count, not a percentage. HTTP 500 errors may occur sporadically, but unless they reach 100 within the evaluation window, the alert will not fire. For error-rate monitoring, a percentage-based condition (e.g., >5% of total requests) is more appropriate to detect anomalies even with lower traffic volumes.

Exam trap

The trap here is that candidates often assume an absolute count threshold is fine for error monitoring, but Azure's alerting logic requires careful consideration of traffic patterns—percentage-based conditions are essential for detecting error rate spikes in variable-load environments.

How to eliminate wrong answers

Option A is wrong because severity level 2 does not suppress alerts; severity levels (0-4) only affect the alert's classification in Azure Monitor, not its firing behavior. Option C is wrong because 'requests/count' is a valid metric name in Application Insights; there is no misspelling. Option D is wrong because the dimension filter for 'request/resultCode' with value '500' is correct; Azure Monitor does not support wildcards like '5xx' in dimension filters—you must specify exact values.

Full explanation →
340
MCQmedium

Your organization uses Azure Pipelines and requires that all builds be run on Microsoft-hosted agents to reduce maintenance overhead. However, you need to ensure that the build agent has a specific version of Node.js installed that is not available on the standard Microsoft-hosted agents. What should you do?

A.Use a container job that runs a custom Docker image with the required Node.js version.
B.Deploy a self-hosted agent with the required Node.js version.
C.Use a script task to install the specific Node.js version at the start of the pipeline.
D.Request Microsoft to add the Node.js version to their hosted agents.
AnswerC

You can install Node.js temporarily during the pipeline execution.

Why this answer

Option B is correct because you can use a script task to install Node.js using a version manager like nvm or download the required version. Option A is wrong because you cannot install software on a Microsoft-hosted agent permanently. Option C is wrong because self-hosted agents require maintenance.

Option D is wrong because container jobs are possible but require the agent to support containers, and you still need to customise the container image.

Full explanation →
341
MCQhard

The pipeline fails because the artifact is empty. What is the most likely cause?

A.The build output is not copied to the staging directory
B.The projects pattern '**/*.csproj' does not match any files
C.The task 'PublishBuildArtifacts@1' is misspelled
D.The artifact name 'drop' is invalid
AnswerA

The build task does not copy output to staging directory.

Why this answer

Option A is correct because the build output is not copied to the staging directory. Option B is wrong because the pattern is likely correct. Option C is wrong because the task name is correct.

Option D is wrong because the artifact name is valid.

Full explanation →
342
Multi-Selecteasy

Which TWO compliance frameworks are directly supported by Microsoft Purview Compliance Manager for Azure DevOps?

Select 2 answers
A.ISO 27001
B.HIPAA
C.PCI DSS
D.FedRAMP High
E.SOC 2
AnswersA, E

ISO 27001 is a standard template in Purview Compliance Manager.

Why this answer

Option A and Option D are correct. Option A (SOC 2) and Option D (ISO 27001) are included in Purview Compliance Manager templates. Option B (PCI DSS) is not directly mapped to Azure DevOps in Purview.

Option C (FedRAMP High) is for Azure infrastructure, not Azure DevOps specifically. Option E (HIPAA) is not directly mapped to Azure DevOps in Purview.

Full explanation →
343
MCQhard

You are designing a build pipeline that uses Microsoft-hosted agents. The pipeline must build a .NET Framework 4.8 application and run on a Windows agent. Due to compliance, the build must use a specific version of Visual Studio that is not pre-installed on the Microsoft-hosted agents. What should you do?

A.Use a self-hosted agent that has the required version of Visual Studio installed.
B.Build the application inside a Docker container that includes the required Visual Studio version.
C.Specify the 'vsVersion' parameter in the MSBuild task to target the required version.
D.Use the 'Visual Studio Test Platform Installer' task to install the required version at build time.
AnswerA

Self-hosted agents can be configured with specific software requirements.

Why this answer

The only way to ensure a specific version of Visual Studio is to use a self-hosted agent with that version installed. Microsoft-hosted agents have pre-installed software but you cannot customize them to add a specific version not available. Using a Docker container with the required version is a valid approach but requires a self-hosted agent to run the container.

Building with MSBuild alone might not work if the project depends on Visual Studio components.

Full explanation →
344
MCQmedium

You are a DevOps consultant for a financial services company that is migrating from TFVC to Git. The existing TFVC repository has several branches: main, dev, feature branches, and release branches. The history is linear with no branching. The company requires that all future Git commits follow a strict naming convention: 'type(scope): description' (e.g., 'feat(api): add new endpoint'). They also want to prevent direct commits to the main branch; all changes must go through pull requests with at least one reviewer. Additionally, they want to ensure that each commit message is validated before it is merged. The team is small (5 developers) and they want a simple setup without complex tooling. Which approach should you recommend?

A.Create a build pipeline that validates commit messages and fails the build if invalid
B.Use a server-side pre-receive hook in the Git repository
C.Install a client-side pre-commit hook on each developer's machine to validate messages
D.Configure branch policies on the main branch: require a minimum of one reviewer, and add a status check that runs a script to validate the commit message format
AnswerD

Server-side enforcement with minimal overhead.

Why this answer

Option D is correct because Azure Repos branch policies allow you to enforce pull request requirements (e.g., minimum number of reviewers) and require a status check that runs a custom script to validate commit message format. This ensures all commits merged into main comply with the naming convention and review policy without complex tooling, fitting the small team's need for a simple, server-side enforcement mechanism.

Exam trap

The trap here is that candidates often confuse client-side hooks (option C) with server-side enforcement, not realizing that client-side hooks are optional and easily bypassed, whereas Azure Repos branch policies (option D) provide mandatory, centralized enforcement without requiring custom server-side hook infrastructure.

How to eliminate wrong answers

Option A is wrong because a build pipeline that validates commit messages runs after the code is already merged (or during a PR build), but it does not prevent direct commits to main or enforce the review requirement; it only fails the build, not the merge. Option B is wrong because server-side pre-receive hooks are not natively supported in Azure Repos (they are available in on-premises Git servers like GitHub Enterprise or self-hosted GitLab); Azure Repos uses branch policies instead. Option C is wrong because client-side pre-commit hooks are not enforceable; developers can bypass them by using --no-verify or by not installing the hook, so they do not guarantee compliance across the team.

Full explanation →
345
MCQeasy

Your build pipeline uses a self-hosted agent that runs on a Windows machine. The pipeline fails with the error: 'The task 'DotNetCoreCLI' is not supported on this agent.' What is the most likely cause?

A.The agent's execution policy is restricted.
B.The agent does not have the required capabilities (e.g., .NET Core SDK installed).
C.The agent is not authorized to run the pipeline.
D.The agent cannot connect to the internet to download the task.
AnswerB

Correct: Self-hosted agents need capabilities matching task demands.

Why this answer

Option B is correct because the agent's capabilities do not include the required .NET Core SDK. Option A is wrong because the error specifically says the task is not supported, not that execution policy is an issue. Option C is wrong because the error doesn't mention network or credentials.

Option D is wrong because the error is about the task not being supported, not about agent pool access.

Full explanation →
346
MCQhard

A company uses Azure Pipelines with YAML-based pipelines stored in a Git repository. The pipeline triggers on every push to the main branch, but the team wants to reduce unnecessary builds when only documentation files are changed. What is the best way to achieve this?

A.Use path filters in the trigger section to exclude 'docs/*' and '*.md' files.
B.Configure branch policy to require a pull request for documentation changes.
C.Add a 'condition' to the pipeline that checks if changed files are documentation.
D.Disable CI trigger and rely on scheduled builds.
AnswerA

Path filters allow excluding specific paths from triggering.

Why this answer

Option D is correct because using path filters with exclude patterns on the main branch trigger prevents builds for specific file changes. Option A is wrong because branch policies do not filter file changes. Option B is wrong because skipping CI entirely is not desirable.

Option C is wrong because conditions evaluate after the pipeline starts, not before.

Full explanation →
347
MCQeasy

A company uses Azure DevOps to manage code. They want to enforce that all changes to the main branch must go through a pull request with at least two reviewers. What should they configure?

A.Branch policy on the main branch
B.Add a tag to the main branch
C.Repository permissions
D.Configure a service hook
AnswerA

Branch policies can require a minimum number of reviewers.

Why this answer

Branch policies in Azure DevOps allow you to enforce requirements on pull requests targeting a specific branch. By configuring a branch policy on the main branch, you can require a minimum number of reviewers (e.g., two) and mandate that all changes must go through a pull request. This ensures that no direct commits bypass the review process.

Exam trap

The trap here is that candidates may confuse repository permissions (which control access) with branch policies (which control workflow and quality gates), leading them to select Option C instead of the correct branch policy configuration.

How to eliminate wrong answers

Option B is wrong because adding a tag to the main branch is a labeling mechanism for marking releases or milestones; it does not enforce any workflow or review requirements. Option C is wrong because repository permissions control who can read, write, or administer the repository, but they do not enforce pull request review requirements on specific branches. Option D is wrong because a service hook is used to integrate with external systems (e.g., sending notifications or triggering builds) and cannot enforce branch-level policies like requiring reviewers.

Full explanation →
348
MCQeasy

Your organization is adopting Azure DevOps to manage a new project for a client. The client requires that all work items be linked to Git commits and pull requests. Additionally, they want a dashboard that shows the team's velocity and work item trends. You are responsible for setting up the project and configuring the necessary integrations. The team uses a Scrum process with Sprints. You have already created the project and imported the work items. What should you do next to meet the client's requirements?

A.Create a custom tool using Azure Functions to parse commit messages and link work items. Use the built-in Charts feature in Azure Boards to create velocity charts.
B.Configure branch policies on the main branch to require linking work items. Set up the repository to automatically link commits to work items. Then create an Analytics view in Azure Boards to track velocity and work item trends.
C.Instruct developers to manually add work item IDs in commit messages and pull request descriptions. Create a custom dashboard using Power BI connected to Azure Boards.
D.Enable the setting 'Automatically link work items' in the repository settings. Configure a service hook to post commit details to a Teams channel for visibility.
AnswerB

Branch policies enforce linking, and Analytics views provide the required dashboard data.

Why this answer

Option A is correct because it ensures all commits and PRs are linked to work items via policies, and the Analytics view provides velocity and trend data. Option B disables linking, contrary to the requirement. Option C only links PRs, not commits.

Option D uses manual linking which is error-prone and inefficient.

Full explanation →
349
MCQmedium

You have a YAML pipeline that builds a Java project using Maven. The pipeline uses a private artifact feed in Azure Artifacts. You need to authenticate to the feed from the pipeline. Which authentication method should you use?

A.Use the 'PipAuthenticate' task with a pip.conf file.
B.Use the 'npmAuthenticate' task with a .npmrc file.
C.Use the 'MavenAuthenticate' task with a settings.xml file.
D.Use the 'NuGetAuthenticate' task with a nuget.config file.
AnswerC

This task authenticates Maven builds to Azure Artifacts.

Why this answer

Azure Pipelines can use the project-level 'Azure Artifacts' service connection to authenticate to feeds. Option B is correct because it uses the pipeline identity. Option A is for npm.

Option C is for Python. Option D is for NuGet.

Full explanation →
350
MCQhard

Your company, Contoso Ltd., is a financial services firm that must comply with PCI DSS. You manage a Azure DevOps organization with over 200 projects. Each project uses a service principal to deploy to Azure using service connections stored in library variable groups. Recently, an auditor flagged that a developer used a service principal with Contributor rights on a production subscription to accidentally delete a storage account. The developer had been granted access to the variable group containing that service principal's credentials. You are tasked with implementing a security and compliance plan to prevent this from recurring. The solution must minimize administrative overhead and follow the principle of least privilege. Current environment: All service principals are created in Azure AD and assigned to variable groups. Developers are granted 'User' access level in Azure DevOps and are members of various teams. You have the ability to create Azure AD groups and custom roles. Which course of action should you take?

A.Remove all variable groups and require developers to use their own Azure AD accounts for deployments, granting them Contributor rights only on non-production environments.
B.Require all pipeline runs that use production service connections to be approved by a security team via Azure Pipelines approval gates.
C.Implement Azure DevOps pipeline decorators to inject a security task that checks the service connection's role before each deployment, and fail the pipeline if the role is Contributor or higher.
D.Create custom Azure RBAC roles with minimal required permissions for each service principal, restrict service connections to specific pipelines using Azure DevOps security settings (e.g., 'Use' permission), and assign developers only the 'Use' permission to the service connections they need, not the variable groups containing credentials.
AnswerD

This follows least privilege and limits access to only necessary pipelines.

Why this answer

Option D is correct because it enforces the principle of least privilege by creating custom Azure RBAC roles with minimal permissions, restricting service connections to specific pipelines via Azure DevOps security settings (e.g., 'Use' permission), and assigning developers only the 'Use' permission to the service connections rather than the variable groups containing credentials. This prevents developers from directly accessing or modifying the service principal credentials, eliminating the risk of accidental or malicious use of high-privilege roles like Contributor.

Exam trap

The trap here is that candidates often confuse approval gates (Option B) as a sufficient security control, but they fail to address the root cause—excessive permissions on the service principal itself—and overlook the need to restrict access to the service connection credentials at the Azure DevOps permission level.

How to eliminate wrong answers

Option A is wrong because removing variable groups and granting developers Contributor rights on non-production environments still violates least privilege—developers should not have Contributor rights on any environment if they only need to deploy, and using their own Azure AD accounts for deployments introduces security risks like credential exposure and lack of audit separation. Option B is wrong because requiring approval gates for all pipeline runs using production service connections adds administrative overhead and does not prevent a developer from accidentally using a Contributor role in a pipeline that has been approved; it only adds a manual check, not a technical control. Option C is wrong because pipeline decorators that check the service connection's role before each deployment can be bypassed if the developer modifies the pipeline YAML or if the decorator is not applied to all pipelines; also, failing the pipeline after the role check does not prevent the service principal from having excessive permissions in the first place.

Full explanation →
351
MCQmedium

You are reviewing a pipeline YAML file. The variable 'prod-db-password' is stored in a variable group linked to Azure Key Vault. However, the pipeline fails with an error that the secret cannot be accessed. What is the most likely cause?

A.The YAML syntax for referencing the variable is incorrect.
B.The pipeline's authorized service principal lacks 'Get' permission on the Key Vault.
C.The variable group 'prod-variables' does not exist.
D.The secret name in Key Vault does not match 'prod-db-password'.
AnswerB

Without proper access, the pipeline cannot retrieve the secret.

Why this answer

Option C is correct because the pipeline's service principal needs permission to access the Key Vault secrets. Option A is wrong because the variable group is already linked. Option B is wrong because the syntax is correct.

Option D is wrong because the secret name in Key Vault might differ, but the error indicates access issue.

Full explanation →
352
Multi-Selecteasy

Which TWO are valid types of triggers for a YAML pipeline in Azure Pipelines? (Choose two.)

Select 2 answers
A.Push trigger
B.Scheduled trigger
C.Release trigger
D.PR trigger
E.Pipeline trigger
AnswersA, D

Push trigger runs on commits.

Why this answer

Options A and B are correct. CI triggers (push) and PR triggers are valid YAML triggers. Option C is incorrect because scheduled triggers are defined outside YAML.

Option D is incorrect because release triggers are for release pipelines, not YAML. Option E is incorrect because pipeline triggers are for triggering other pipelines, not directly in YAML.

Full explanation →
353
MCQeasy

Your organization is adopting a trunk-based development strategy with short-lived feature branches. Which branch policy should you enforce to ensure that code is integrated frequently and conflicts are minimized?

A.Allow direct pushes to main branch for senior developers
B.Require a minimum number of reviewers and enforce a squash merge strategy
C.Create release branches for each production deployment
D.Require all merges to be fast-forward only
AnswerB

Squash merges keep history linear and reviews ensure quality.

Why this answer

In a trunk-based development strategy with short-lived feature branches, the goal is to integrate code frequently and minimize merge conflicts. Requiring a minimum number of reviewers ensures code quality and team awareness, while enforcing a squash merge strategy collapses all feature branch commits into a single commit on the main branch, keeping the history linear and clean. This approach reduces the risk of complex merge conflicts and supports continuous integration by encouraging small, frequent merges.

Exam trap

The trap here is that candidates often confuse trunk-based development with GitFlow and choose option C (release branches), or they mistakenly think fast-forward-only merges (option D) are required for trunk-based strategies, when in fact squash merges are the recommended approach to maintain a clean, linear history.

How to eliminate wrong answers

Option A is wrong because allowing direct pushes to the main branch bypasses pull request reviews and branch policies, which undermines the trunk-based strategy's need for controlled, frequent integration and can lead to untested code and conflicts. Option C is wrong because creating release branches for each production deployment is a practice for GitFlow or release-based strategies, not trunk-based development, which focuses on keeping the main branch always deployable and avoids long-lived branches. Option D is wrong because requiring all merges to be fast-forward only would prevent merge commits entirely, making it impossible to enforce squash merges or maintain a clear history of feature integration; fast-forward merges are typically used with rebase strategies, not trunk-based development with short-lived branches.

Full explanation →
354
MCQeasy

Your team is adopting GitHub Discussions for community Q&A. You want to ensure that only maintainers can create new discussion categories, but any authenticated user can create discussion posts within existing categories. How should you configure this?

A.Only maintainers can create categories; any authenticated user can create posts.
B.Enable discussions at the organization level and set permissions.
C.Configure branch protection to enforce maintainer-only posting.
D.Use a GitHub Action to approve discussion posts.
AnswerA

This is the default GitHub behavior.

Why this answer

Option A is correct because GitHub Discussions natively allows repository administrators to control category creation permissions independently from post creation permissions. By default, only users with 'triage' or higher access can create categories, while any authenticated user (including those without write access) can create posts within existing categories. This satisfies the requirement without additional configuration.

Exam trap

The trap here is that candidates may confuse branch protection rules (which apply to code) with discussion permissions, or assume that organization-level settings override repository-level category controls, when in fact category creation is a repository-level permission tied to the 'triage' role.

How to eliminate wrong answers

Option B is wrong because enabling discussions at the organization level does not provide granular control over who can create categories versus posts; it only enables the feature across repositories, and category permissions are managed per repository, not organization-wide. Option C is wrong because branch protection rules apply only to branches (e.g., enforcing pull request reviews or status checks), not to GitHub Discussions, which is a separate feature unrelated to code branches. Option D is wrong because GitHub Actions can automate workflows but cannot modify the built-in permission model for discussion categories; there is no action that can override the native role-based access controls for category creation.

Full explanation →
355
Multi-Selectmedium

Which TWO tools can be used to manage feature flags in Azure DevOps pipelines?

Select 2 answers
A.Azure Policy.
B.LaunchDarkly.
C.Azure App Configuration.
D.Azure Monitor.
E.Azure Key Vault.
AnswersB, C

LaunchDarkly is a popular third-party feature flag service.

Why this answer

Options A and D are correct. Azure App Configuration provides feature management. LaunchDarkly is a third-party tool that integrates.

Options B, C, and E are not feature flag management tools.

Full explanation →
356
MCQmedium

You are using GitHub Advanced Security. The security team wants to prevent developers from introducing code with high-severity vulnerabilities. What is the best way to enforce this?

A.Enable Dependabot and require pull request reviews for dependency updates
B.Enable code scanning and configure a quality gate to fail PRs with high-severity alerts
C.Enable push protection for all repositories
D.Enable secret scanning and block pushes with high-confidence secrets
AnswerB

This blocks PRs with high-severity code vulnerabilities.

Why this answer

Option A is correct because code scanning with a quality gate can block PRs with high-severity findings. Option B is wrong because secret scanning deals with secrets. Option C is wrong because Dependabot focuses on dependency vulnerabilities.

Option D is wrong because push protection is for secrets.

Full explanation →
357
MCQeasy

You see the above YAML pipeline trigger configuration in an Azure Pipeline. The repository uses Git Flow with branches: feature/new-feature, develop, release/v1.0, and main. A developer pushes a commit to the branch feature/new-feature. Which action will trigger the pipeline?

A.A CI trigger will start because the branch name starts with 'feature/'.
B.No trigger will start.
C.A PR trigger will start because the branch name contains 'feature'.
D.A CI trigger will start for all branches because batch is set to true.
AnswerB

The push to feature/new-feature does not match any branch in the trigger include list, and the PR trigger only applies to PRs.

Why this answer

The YAML pipeline trigger configuration shown (not provided in text but implied by the answer) does not include a CI trigger for branches matching 'feature/*'. Without an explicit trigger block or a wildcard pattern like 'feature/*', only the default branch (typically 'main') triggers a CI pipeline on push. Since the push is to 'feature/new-feature' and no PR trigger is configured, no pipeline run is initiated.

Exam trap

The trap here is that candidates assume any push to a branch with a name containing 'feature' will automatically trigger a CI or PR pipeline, but Azure Pipelines requires explicit trigger configuration for non-default branches.

How to eliminate wrong answers

Option A is wrong because a CI trigger only starts if the YAML pipeline explicitly includes a trigger section with 'feature/*' or the branch name matches a configured pattern; simply having a branch name starting with 'feature/' does not automatically trigger a pipeline. Option C is wrong because a PR trigger requires a configured 'pr' block in the YAML pipeline or a branch policy on the target branch; a push to a feature branch does not create a pull request, so no PR trigger fires. Option D is wrong because setting 'batch: true' only affects how multiple pending CI runs are batched when a trigger is already configured; it does not enable CI triggers for all branches.

Full explanation →
358
Multi-Selecthard

You are designing a YAML pipeline that builds a .NET application and publishes it as a NuGet package to Azure Artifacts. Which three tasks should you include in the build stage?

Select 3 answers
A.DotNetCoreCLI@2 with command 'build'
B.NuGetCommand@2 with command 'install'
C.DotNetCoreCLI@2 with command 'restore'
D.DotNetCoreCLI@2 with command 'push'
E.DotNetCoreCLI@2 with command 'pack'
AnswersA, C, E

Correct: Builds the project.

Why this answer

Options A, B, and E are correct. First restore dependencies, then build the project, then pack into a NuGet package. Option C is wrong because NuGet push is not needed in build stage if you push later.

Option D is wrong because NuGet install is for packages.config, not SDK-style projects.

Full explanation →
359
Multi-Selectmedium

Which THREE are valid ways to trigger a pipeline in Azure Pipelines using GitHub integration? (Choose three.)

Select 3 answers
A.GitHub App webhooks
B.Polling GitHub on a schedule
C.GitHub pull request events
D.GitHub branch push events
E.Azure Pipelines schedule trigger
AnswersA, C, D

GitHub App sends webhooks to Azure Pipelines.

Why this answer

GitHub branch push triggers, pull request triggers, and GitHub App webhooks are valid methods. Option B is wrong because Azure Pipelines does not support direct polling of GitHub. Option E is wrong because schedule triggers are not GitHub-specific.

Full explanation →
360
MCQhard

Refer to the exhibit. You apply this Azure Policy to a subscription. A developer attempts to deploy a VM with SKU Standard_D2s_v3. What is the result?

A.The deployment is denied only if the VM is in a specific resource group.
B.The deployment is denied because the SKU matches the pattern.
C.The deployment is allowed because the SKU matches the pattern.
D.The deployment is allowed and a non-compliance event is logged.
AnswerB

Correct. The condition matches VM type and SKU name starting with 'Standard_D', so the deny effect blocks the deployment.

Why this answer

The policy definition uses a deny effect when the VM type is Microsoft.Compute/virtualMachines and the SKU name starts with 'Standard_D'. Since Standard_D2s_v3 matches that pattern, the deployment is denied.

Full explanation →
361
Matchingmedium

Match each Azure Monitor feature to its use case.

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

Concepts
Matches

Application performance monitoring and diagnostics

Query and analyze log data from various sources

Visualize performance metrics from Azure resources

Proactive notifications based on conditions

Why these pairings

Core Azure Monitor components for observability.

Full explanation →
362
MCQmedium

You are designing a release pipeline for a containerized application deployed to Azure Kubernetes Service (AKS). You want to implement a strategy where the new version is deployed to a small subset of pods first, and if healthy, gradually rolled out to all pods. Which Kubernetes deployment strategy should you use?

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

Canary deploys to a small subset and gradually shifts traffic based on health.

Why this answer

Option B is correct because a canary deployment releases the new version to a subset of pods and gradually increases traffic. Option A is wrong because rolling update gradually replaces pods but doesn't use traffic splitting for validation. Option C is wrong because blue-green switches all traffic at once.

Option D is wrong because recreate deletes all old pods before creating new ones.

Full explanation →
363
Multi-Selecthard

Your organization is implementing a security compliance plan for Azure DevOps. Which TWO actions should you take to ensure that only authorized users can modify build pipelines?

Select 2 answers
A.Require all users to use Personal Access Tokens (PATs)
B.Configure branch policies to require reviews for changes to pipeline YAML files
C.Set pipeline permissions to restrict editing to specific security groups
D.Enable audit logging for all pipeline changes
E.Enable OpenID Connect (OIDC) for pipeline authentication
AnswersB, C

Branch policies require approvals for changes to pipeline definitions.

Why this answer

Options C and E are correct because pipeline permissions in Azure DevOps control who can edit pipelines, and branch policies protect the pipeline definition. Option A is wrong because PATs are for authentication, not authorization. Option B is wrong because OIDC is for authentication.

Option D is wrong because audit logs track changes but don't prevent unauthorized modifications.

Full explanation →
364
Multi-Selecteasy

Which TWO practices help improve the efficiency of code reviews? (Choose two.)

Select 2 answers
A.Keep pull requests small and focused on a single change.
B.Include multiple unrelated changes in a single pull request to reduce the number of PRs.
C.Assign as many reviewers as possible to ensure thoroughness.
D.Require that all team members review every pull request.
E.Use a code review checklist to ensure common issues are checked.
AnswersA, E

Small PRs are easier and faster to review.

Why this answer

Keeping pull requests small and focused on a single change (Option A) improves code review efficiency because it reduces cognitive load on reviewers, allowing them to understand and evaluate the change quickly without context-switching. Smaller PRs also enable faster feedback loops and easier rollback if issues are found, which aligns with DevOps principles of continuous integration and delivery.

Exam trap

The trap here is that candidates may think more reviewers or requiring all team members to review ensures quality, but in practice, it reduces efficiency and accountability, while small, focused PRs and checklists are proven to improve both speed and accuracy.

Full explanation →
365
MCQhard

Your team uses GitHub Actions for CI/CD. You need to ensure that secrets used in workflows are automatically rotated every 90 days. What is the best approach?

A.Use OpenID Connect (OIDC) to authenticate.
B.Use a script that calls the GitHub API to update the secret and run it in a scheduled workflow.
C.Manually update the secrets every 90 days.
D.Store secrets as environment secrets and configure expiration.
AnswerB

Automated rotation via API.

Why this answer

Option B is correct because it uses the GitHub API within a scheduled workflow to programmatically rotate secrets, ensuring automation without manual intervention. This approach directly addresses the requirement for automatic rotation every 90 days by generating new secret values and updating the repository or organization secrets via the API.

Exam trap

The trap here is that candidates may confuse OIDC with secret management, assuming it provides rotation capabilities, when in fact OIDC only handles authentication without any secret lifecycle management.

How to eliminate wrong answers

Option A is wrong because OpenID Connect (OIDC) is used for authentication between GitHub Actions and cloud providers, not for rotating secrets stored in GitHub; it does not provide a mechanism to update or rotate secrets. Option C is wrong because manually updating secrets every 90 days is error-prone, not automated, and violates the requirement for automatic rotation. Option D is wrong because GitHub does not support environment secrets with a configurable expiration date; secrets do not have a built-in expiration feature, and this option misrepresents the platform's capabilities.

Full explanation →
366
MCQhard

You have the YAML pipeline exhibit above. The pipeline fails with: 'The pipeline is not valid. Could not find the template file shared-templates/build-steps.yml.' What is the most likely cause?

A.The checkout step for 'shared-templates' must be before the template reference, which it is.
B.The template file is missing from the shared-templates repository.
C.The template path is incorrect because it should be relative to the repository root; the repository name is 'myorg/shared-templates', so the path should be 'build-steps.yml'.
D.The ref 'refs/heads/main' does not exist in the shared-templates repository.
AnswerC

The path 'shared-templates/build-steps.yml' suggests that the template is in a subfolder, but the repository root is already 'shared-templates'.

Why this answer

Option B is correct because the template path is relative to the repository root, but the repository name includes 'myorg/shared-templates', so the path should be 'build-steps.yml' if it is in the root. Option A is wrong because the template is referenced correctly. Option C is wrong because the ref is correct.

Option D is wrong because checkout order does not affect template resolution.

Full explanation →
367
MCQmedium

You have a release pipeline that deploys to multiple stages (Dev, QA, Prod). You want to automatically deploy to Dev and QA after a successful build, but require a manual approval for Prod. Which deployment strategy should you use?

A.Set pre-deployment approvals on the Dev and QA stages.
B.Set pre-deployment approvals on the Prod stage.
C.Use a post-deployment approval on the QA stage.
D.Disable the automatic trigger for all stages.
AnswerB

Why this answer

Pre-deployment approvals control whether a release can start deploying to a stage. By setting a pre-deployment approval on the Prod stage only, Dev and QA will deploy automatically (since they have no approval requirement), while Prod requires manual sign-off before deployment begins. This matches the requirement exactly.

Exam trap

The trap here is confusing pre-deployment approvals with post-deployment approvals, leading candidates to think a post-deployment approval on QA can gate Prod, when in fact only pre-deployment approvals on the target stage (Prod) can prevent its deployment from starting.

Why the other options are wrong

A

That would require approval for Dev and QA, not Prod.

C

Post-deployment approvals occur after deployment, not before.

D

That would stop all automatic deployments.

Full explanation →
368
Multi-Selectmedium

Your team is implementing a security and compliance plan for Azure DevOps. Which TWO actions should you take to meet regulatory requirements for audit logging and access control?

Select 2 answers
A.Enable anonymous access to project boards for external stakeholders.
B.Enable Azure DevOps audit log to track changes to security policies and user permissions.
C.Configure Azure AD Conditional Access policy to require multi-factor authentication for Azure DevOps.
D.Grant all users Project Collection Administrator role to simplify access management.
E.Disable auditing for the project to reduce log volume.
AnswersB, C

Audit logs are essential for compliance tracking.

Why this answer

Enabling the Azure DevOps audit log (option B) is essential for regulatory compliance because it records changes to security policies, user permissions, and other critical events, providing an immutable trail for forensic analysis and reporting. This directly meets audit logging requirements by capturing who did what and when, which is necessary for standards like SOC 2, ISO 27001, or GDPR.

Exam trap

Microsoft often tests the misconception that enabling anonymous access or simplifying permissions (like granting admin roles to all users) is acceptable for compliance, when in fact these actions directly violate audit logging and access control requirements.

Full explanation →
369
Multi-Selectmedium

Your team uses Azure DevOps and needs to ensure that secrets are not exposed in pipeline logs. Which THREE practices should you implement?

Select 3 answers
A.Use logging commands to mask secrets in scripts
B.Enable pipeline log encryption
C.Mark variables as 'secret' in pipeline variables
D.Store secrets in YAML variable files
E.Use Azure Key Vault to store secrets
AnswersA, C, E

Logging commands like '##vso[task.setvariable]' can mask output.

Why this answer

Options B, C, and D are correct because using variables with 'secret' type hides them in logs, Azure Key Vault securely stores secrets, and logging commands can mask secrets. Option A is wrong because storing secrets in YAML files is insecure. Option E is wrong because pipeline logs are not encrypted by default.

Full explanation →
370
MCQhard

You are designing a release strategy for a critical application that must maintain high availability. You decide to use Azure Traffic Manager to route traffic between deployments in two Azure regions. Your release pipeline deploys the application to the secondary region first, then switches Traffic Manager priority to route traffic to the secondary region while the primary region is updated. This strategy is known as:

A.Blue-green deployment
B.Canary deployment
C.Red/Black deployment
D.Rolling deployment across regions
AnswerD

Correct: This is a rolling deployment that updates regions sequentially with traffic rerouting.

Why this answer

Option B is correct because it describes deploying to a secondary region, switching traffic, then updating primary. Option A is wrong because blue-green deploys a full parallel environment. Option C is wrong because rolling updates update instances gradually.

Option D is wrong because canary releases a small subset.

Full explanation →
371
MCQmedium

A team uses a monorepo in Azure Repos. They want to implement a build validation policy that only triggers builds for code changes in specific folders to reduce build times. Which approach should they use?

A.Use a manual trigger and have developers specify which folder to build.
B.Create separate YAML pipelines for each folder and configure branch policies to require all pipelines.
C.Configure the build policy in Azure Repos with a path filter to limit which folders trigger the policy.
D.Configure path filters in the pipeline trigger to include only the changed folder.
AnswerD

Path filters restrict when the pipeline runs based on changed paths.

Why this answer

Option D is correct because Azure Pipelines supports path filters in the pipeline trigger configuration (using the `paths` keyword in YAML). This allows you to specify include and exclude patterns so that the pipeline only triggers when changes are made to specific folders within the monorepo. This directly reduces unnecessary builds and aligns with the requirement to limit builds to code changes in specific folders.

Exam trap

The trap here is that candidates confuse branch policy path filters (which do not exist in Azure Repos) with pipeline trigger path filters, leading them to incorrectly select Option C.

How to eliminate wrong answers

Option A is wrong because a manual trigger defeats the purpose of an automated build validation policy; it relies on developers remembering to trigger builds, which is error-prone and not scalable. Option B is wrong because requiring all separate pipelines via branch policies would cause every pipeline to run on any change, negating the goal of reducing build times and creating unnecessary overhead. Option C is wrong because Azure Repos branch policies do not support path filters for build validation; path filters are a feature of pipeline triggers, not branch policy configuration.

Full explanation →
372
Multi-Selecteasy

Which TWO practices should you follow to ensure compliance with regulatory requirements (e.g., PCI DSS) when using Azure DevOps? (Choose two.)

Select 2 answers
A.Manually track changes to pipelines in a spreadsheet.
B.Allow all users to create and modify pipelines without restrictions.
C.Enable Azure DevOps audit logging to track changes to pipelines and policies.
D.Disable audit logging to reduce storage costs.
E.Use branch policies to enforce code reviews and approvals for all changes.
AnswersC, E

Audit logs provide an immutable record of changes.

Why this answer

Options A and C are correct: Enabling audit logging tracks all changes, and using branch policies enforces code review. Option B is incorrect because allowing all users to create pipelines reduces control. Option D is incorrect because disabling auditing is contrary to compliance.

Option E is incorrect because manual logging is not reliable.

Full explanation →
373
Multi-Selectmedium

Your organization uses GitHub and wants to ensure that all commits to the main branch are associated with a GitHub issue. Which three settings should you configure?

Select 3 answers
A.Require conversation resolution before merging
B.Require status checks to pass before merging
C.Allow force pushes
D.Require pull request reviews before merging
E.Allow deletions
AnswersA, B, D

Ensures discussions are resolved, promoting issue linking.

Why this answer

Option A is correct because requiring conversation resolution before merging ensures that all comments on a pull request are resolved before the PR can be merged. This is a branch protection rule that enforces that discussions tied to the PR (which should reference a GitHub issue) are fully addressed, indirectly ensuring the commit is associated with an issue. Option B is correct because requiring status checks to pass before merging can include a check that verifies the commit message contains an issue reference or that a linked issue exists.

Option D is correct because requiring pull request reviews before merging forces all changes to go through a PR, which must be linked to a GitHub issue, ensuring traceability.

Exam trap

The trap here is that candidates may think 'Require status checks' is unrelated to issue association, but it can be configured with a custom status check that validates issue references, making it a valid and necessary setting alongside PR reviews and conversation resolution.

Full explanation →
374
MCQhard

Your Azure DevOps environment uses Microsoft Entra ID for authentication. You need to ensure that users from a partner organization can access only a specific Azure Boards project without being added to your tenant as guests. What should you do?

A.Issue OAuth 2.0 tokens to the partner users.
B.Invite the partner users as Microsoft Entra B2B guests and assign them to the project.
C.Configure Microsoft Entra ID identity protection to allow the partner IP range.
D.Create service principals for the partner users.
AnswerB

B2B collaboration allows external users with specific permissions.

Why this answer

Option B is correct because Microsoft Entra B2B collaboration allows you to invite external users as guests, granting them access to specific resources like an Azure Boards project without fully adding them to your tenant. This meets the requirement of restricting access to only that project while avoiding permanent guest accounts in your directory.

Exam trap

The trap here is that candidates may confuse OAuth 2.0 tokens or service principals with user access, not realizing that B2B guest invitations are the correct mechanism for granting external users limited access without full tenant membership.

How to eliminate wrong answers

Option A is wrong because OAuth 2.0 tokens are used for delegated authorization and authentication flows, not for granting direct access to Azure DevOps projects; they require the user to already be authenticated in the tenant. Option C is wrong because Microsoft Entra ID Identity Protection is a security tool for detecting risks like compromised identities, not for granting access based on IP ranges. Option D is wrong because service principals are non-human identities used for automated processes or applications, not for individual user access to Azure Boards.

Full explanation →
375
MCQhard

You have a multi-stage YAML pipeline that builds and deploys a containerized application to Azure Kubernetes Service (AKS). The build stage runs successfully, but the deploy stage fails with an error: 'Error: failed to get credentials: context deadline exceeded'. You verify that the AKS cluster is running and that the service connection is valid. What is the most likely cause?

A.The Azure service connection has expired.
B.The service principal used by the pipeline does not have RBAC permissions on the cluster.
C.The container registry is not accessible from the build agent.
D.The build agent's IP address is not allowed by the AKS cluster's network policies.
AnswerD

Network restrictions can cause timeouts when trying to connect to the API server.

Why this answer

Option A is correct because the Kubernetes API server may have a network restriction (e.g., firewall, NSG) blocking the build agent's IP address. Option B is wrong because RBAC issues would produce a permission denied error, not a timeout. Option C is wrong because the service connection is valid per the scenario.

Option D is wrong because the container registry credentials are used for pulling images, not for connecting to AKS.

Full explanation →
Page 4

Page 5 of 13

Page 6

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 →