Courseiva

Microsoft Azure DevOps Engineer Expert AZ-400 (AZ-400) — Questions 1–75

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

Take a mock examExam hub

Page 1 of 11

Page 2
1
MCQeasy

Your team uses GitHub for source control. You need to ensure that sensitive data, such as connection strings, is never committed to the repository. Which tool should you use?

A.GitHub Actions
B.Dependabot
C.Git Large File Storage (LFS)
D.GitHub secret scanning
AnswerD

GitHub secret scanning is the correct feature because it automatically scans repositories for known patterns of secrets, including connection strings, API keys, and authentication tokens. It alerts on detected secrets and can partner with secret providers to help prevent exposure, directly addressing the need to ensure secrets are not left in source control.

Why this answer

GitHub secret scanning automatically detects sensitive data like connection strings, API keys, and tokens as they are pushed to a repository, preventing them from being committed. It scans for known patterns and can block the push or alert the repository administrator, making it the correct tool for this requirement.

Exam trap

The trap here is that candidates often confuse secret scanning with Dependabot (which handles dependency vulnerabilities, not secrets) or assume GitHub Actions can be scripted to scan for secrets, but secret scanning is a dedicated, built-in feature that operates at the push level without requiring workflow configuration.

How to eliminate wrong answers

Option A is wrong because GitHub Actions is a CI/CD automation platform for building, testing, and deploying code, not a tool for scanning or blocking sensitive data in commits. Option B is wrong because Dependabot is used for automated dependency updates and security vulnerability alerts, not for detecting secrets or connection strings in source code. Option C is wrong because Git LFS is designed to handle large binary files by replacing them with text pointers, not for scanning or preventing sensitive data from being committed.

Full explanation →
2
MCQeasy

A development team uses Git for source control. They want to ensure that all code changes are reviewed before merging into the main branch. Which branch policy should they configure in Azure Repos?

A.Configure a branch policy that requires a minimum number of reviewers and resolves all comments.
B.Configure a branch policy that requires commit messages to follow a specific pattern.
C.Configure a branch policy that requires a successful build.
D.Configure a branch policy that requires linked work items.
AnswerA

This branch policy enforces mandatory peer review by requiring at least a specified number of reviewers to approve the pull request, and also requires that all comment threads be resolved before merging. This ensures that code is reviewed by multiple team members before integration, directly serving the goal of ensuring peer review.

Why this answer

Azure Repos branch policies allow you to enforce that pull requests require a minimum number of reviewers and that all comments are resolved before merging. This directly ensures that all code changes are reviewed and any feedback is addressed, meeting the team's requirement for mandatory code review before merging into the main branch.

Exam trap

The trap here is that candidates may confuse 'code review' with other quality gates like build validation or work item linking, but the question explicitly asks for a policy that ensures all changes are reviewed before merging, which is directly addressed only by reviewer and comment resolution policies.

How to eliminate wrong answers

Option B is wrong because requiring commit messages to follow a specific pattern enforces formatting conventions, not code review. Option C is wrong because requiring a successful build ensures code quality and integration, but does not mandate human review of the changes. Option D is wrong because requiring linked work items enforces traceability to tasks or user stories, not a code review process.

Full explanation →
3
MCQhard

Your organization uses GitHub Actions for CI/CD. You need to ensure that secrets stored in GitHub are not exposed in logs. A developer reports that a secret value appeared in the workflow run log. What is the most likely reason?

A.The workflow was triggered via repository_dispatch.
B.The secret was printed using a script that bypassed automatic masking.
C.The secret name was used in the log output.
D.The workflow used 'debug' log level.
AnswerB

Correct: When a script or action writes a secret value to stdout in a format that GitHub's log redaction does not recognize—for example, by printing it in base64, with escaped characters, or through an intermediate environment variable that is not pre-registered as a secret—the automatic masking may fail and expose the value. GitHub masks secrets that appear verbatim in the log, but only if the exact string is seen; any transformation bypasses that protection.

Why this answer

GitHub Actions automatically masks secrets in log output, but this masking can be bypassed if the secret is printed via a script that outputs it directly (e.g., using `echo` with a variable that contains the secret value, or printing it in a manipulated form). The most likely reason the secret appeared is that the developer used a script that directly printed the secret value, bypassing the automatic masking. Option A is incorrect because the trigger type (repository_dispatch) does not affect logging.

Option C is incorrect because secret names are not masked; only their values are masked. Option D is incorrect because the 'debug' log level does not disable masking; masking applies to all log levels.

Full explanation →
4
MCQeasy

Your organization is adopting GitHub Copilot and wants to ensure that no proprietary code is used to train models. Which setting should you configure in the GitHub organization?

A.Enable secret scanning.
B.Enable Dependabot alerts.
C.Disable GitHub Copilot for the organization.
D.Opt out of allowing GitHub to use code snippets for product improvement.
AnswerD

Opting out of allowing GitHub to use code snippets for product improvement is the exact setting that prevents Copilot from using your code as training data. This is the correct action when you want to retain Copilot's functionality while ensuring your proprietary code is not used to improve the model.

Why this answer

GitHub provides an organization-level setting to opt out of allowing GitHub to use code snippets for product improvement, which prevents Copilot from training on that code. Option A is incorrect because secret scanning is unrelated to model training. Option B is incorrect because Dependabot alerts focus on dependency vulnerabilities, not data usage.

Option C is incorrect because disabling Copilot prevents its use but does not address the underlying data usage for training; the organization may still want to use Copilot while preventing training on proprietary code.

Full explanation →
5
MCQeasy

You are using Azure Pipelines to deploy a function app. You need to automatically roll back the deployment if the post-deployment smoke tests fail. What should you do?

A.Add a stage that runs only when the previous stage fails, executing a rollback script.
B.Configure the pipeline to retry the deployment on failure.
C.Use a pre-deployment approval gate to validate the build before deployment.
D.Set up a manual validation gate that requires operations to initiate a rollback.
AnswerA

In Azure Pipelines, you can define a conditional stage using the `condition: failed()` expression on the deployment stage. This stage runs only when the preceding stage fails, allowing you to execute a rollback script that reverts the function app to its previous healthy version. This approach automates the rollback process, ensuring immediate recovery without manual intervention.

Why this answer

Azure Pipelines supports conditional stage execution using expressions like `eq(variables['Build.Reason'], 'IndividualCI')` or `failed()`. By adding a stage that runs only when the previous deployment stage fails (e.g., `condition: failed()`), you can execute a rollback script that reverts the function app to its previous stable version. This ensures automatic rollback upon smoke test failure without manual intervention.

Exam trap

The trap here is that candidates confuse automatic rollback with retry logic or manual gates, failing to recognize that Azure Pipelines' conditional stage execution (`failed()`) is the native mechanism to trigger a rollback stage automatically when smoke tests fail.

How to eliminate wrong answers

Option B is wrong because retrying the deployment on failure does not roll back; it simply re-attempts the same failing deployment, which will likely fail again if the underlying issue persists. Option C is wrong because a pre-deployment approval gate validates the build before deployment, not after; it cannot detect or respond to post-deployment smoke test failures. Option D is wrong because a manual validation gate requires human approval to proceed, but it does not automatically trigger a rollback; it pauses the pipeline and relies on an operator to manually initiate rollback, which contradicts the requirement for automatic rollback.

Full explanation →
6
MCQhard

You are analyzing Azure DevOps audit logs with the KQL query above. Your security team wants to ensure that only approved service connections are used. After running the query, you find multiple service connections created by a user who is not on the approved list. What should you do next?

A.Immediately delete all service connections created by that user.
B.Disable the user's account in Microsoft Entra ID.
C.Review each unapproved service connection's permissions and usage.
D.Modify the query to also include the user's email address.
AnswerC

Reviewing each unapproved service connection's permissions and usage is the correct response because it enables you to determine whether the connection is malicious, misconfigured, or a legitimate access grant that requires tracking. By examining scopes, used-by pipelines, and activity logs, you can assess risk and decide which connections to revoke, modify, or leave in place with proper oversight.

Why this answer

The immediate priority is to assess the risk of each unapproved service connection before taking action. Service connections in Azure DevOps can have varying permissions and may be used by pipelines, so blindly deleting them could break critical deployments. The correct next step is to review each connection's permissions (e.g., who can use it, which service principals are linked) and its usage history (e.g., which pipelines reference it) to determine whether it is malicious or simply an oversight.

Exam trap

The trap here is that candidates often jump to a punitive action (deleting connections or disabling accounts) instead of following a structured incident response process that first investigates and validates the risk before taking corrective measures.

How to eliminate wrong answers

Option A is wrong because immediately deleting all service connections created by that user could disrupt running pipelines and deployments, and it bypasses the necessary investigation to confirm whether any of those connections are legitimate or approved for specific use cases. Option B is wrong because disabling the user's account in Microsoft Entra ID is a drastic measure that may be premature; the user might have created connections with proper authorization for a different project, and disabling the account could block other legitimate work without addressing the specific service connections. Option D is wrong because modifying the query to include the user's email address does not resolve the security concern; it only provides more information for analysis, but the question asks what to do next after finding unapproved connections, not how to improve the query.

Full explanation →
7
MCQmedium

Refer to the exhibit. A developer pushes a new commit to an existing pull request targeting the main branch. What is the effect on the pull request?

A.The pull request is automatically merged.
B.The existing approvals remain valid, and no re-review is needed.
C.All existing approvals are revoked, and the pull request must be re-approved.
D.The new commit is rejected because it was pushed without a code review.
AnswerC

With the reset-approvals policy enabled, all previously granted approvals are revoked as soon as a new commit is pushed to the source branch, requiring reviewers to re-approve the latest changes before the pull request can be merged.

Why this answer

The policy 'Reset code reviewer votes when new changes are pushed' is set to true. Therefore, when a new commit is pushed, all previous reviewer votes are reset. The required number of reviewers is 2, but minimum is 1, so at least one reviewer must approve again.

Full explanation →
8
Multi-Selecthard

You are designing a build pipeline for a .NET Core application. You need to ensure that the pipeline restores NuGet packages from both an Azure Artifacts feed and the public NuGet gallery. The pipeline must fail if a package is not found in either source. Which two actions must you take? (Select two.)

Select 1 answer
A.Create a NuGet.config file that includes both feeds as package sources and reference it in the restore task.
B.Set the 'NoWarn' property to NU1603 to ignore warnings about missing packages.
C.Use the 'dotnet restore' task with the '--no-cache' flag.
D.Set the 'CheckConsistency' flag to true in the restore task.
E.Configure the Azure Artifacts feed to use the public NuGet gallery as an upstream source.
AnswersA

Correct. A NuGet.config file explicitly defines the package sources, and referencing it in the restore task ensures the pipeline searches both feeds and fails if a package is not found in either.

Why this answer

Creating a NuGet.config file that includes both the Azure Artifacts feed and the public NuGet gallery as package sources, and referencing it in the restore task, ensures the pipeline consults both sources. Option D is incorrect because the 'CheckConsistency' flag is not related to failing on missing packages; the restore task already fails by default if a package cannot be resolved from any configured source. Options B, C, and E do not fulfill the requirement to fail on missing packages from both sources.

Exam trap

The trap here is that candidates often confuse upstream sources (which provide automatic fallback) with explicit source configuration and error handling, leading them to select Option E instead of understanding that upstream sources prevent failures rather than enforce them.

Why the other options are wrong

B

This would suppress warnings, not cause failure on missing packages.

C

This bypasses cache but does not enforce failure on missing packages.

E

This is a feed configuration, not a pipeline setting, and does not cause failure if a package is missing.

Full explanation →
9
MCQhard

Your team uses GitHub Actions to build and deploy a Node.js application to Azure Functions. You need to implement a CI/CD pipeline that automatically deploys to a staging environment on every push to the main branch, and then promotes to production after a manual approval via GitHub Environments. The pipeline must also run unit tests and linting. You want to use the official Azure actions. What should you do?

A.Create two separate workflows: one for CI (build, test, deploy staging) and one for CD (deploy production) that triggers manually.
B.Use a single workflow with a step that deploys to staging and then to production, using a condition to require manual approval via GitHub Issues.
C.Create a single GitHub Actions workflow with multiple jobs. Use a job for build and test, then a job for deploy to staging, and a job for deploy to production with an environment that requires approval.
D.Use Azure Pipelines with a multi-stage YAML pipeline that includes a stage for staging and a stage for production with pre-deployment approvals.
AnswerC

The correct approach defines one workflow with three jobs: build/test, deploy to staging, and deploy to production; the production job references an environment configured with required reviewers, which automatically pauses the job until approval is granted. This gives a native audit trail and allows environment-specific secrets to be used safely.

Why this answer

Correct answer is C. A single GitHub Actions workflow can have multiple jobs: build and test, deploy to staging, and deploy to production. The production deployment job should use a GitHub Environment configured with required reviewers, enabling manual approval.

Option A is incorrect because two separate workflows make it harder to share build artifacts and do not inherently use environment-based approvals for staging vs production. Option B is incorrect because GitHub Issues are not used for manual approvals; approvals are configured via GitHub Environments. Option D is incorrect because it uses Azure Pipelines, not GitHub Actions, which violates the requirement to use official Azure actions in GitHub Actions.

Full explanation →
10
Multi-Selecthard

Your build pipeline uses a YAML template that references variables from a variable group. The variable group is linked to a library. You need to ensure that sensitive variables are not exposed in logs. Which THREE actions should you take?

Select 3 answers
A.Set the variable group to 'Allow access to all pipelines'.
B.Store the secrets in Azure Key Vault and reference them in the variable group.
C.Use 'Write-Host' to output the variable values for debugging.
D.Mark the variables as 'secret' in the variable group.
E.Configure permissions on the library to restrict which pipelines can use the variable group.
AnswersB, D, E

Storing secrets in Azure Key Vault and referencing them via a variable group is the recommended secure approach, as Azure DevOps retrieves these values at runtime and automatically masks them in logs. It enables centralized secret rotation, access policies, and auditing without storing sensitive data in the pipeline definition itself.

Why this answer

To keep sensitive variables out of pipeline logs, you should store secrets in Azure Key Vault and reference them in a variable group (B), mark variables as secret in the variable group (D), and configure permissions on the library to restrict which pipelines can use the variable group (E). Key Vault integration and secret marking ensure that values are masked automatically, while restricting access limits the risk of unauthorized pipelines that could expose secrets.

Exam trap

Candidates may incorrectly think that allowing access to all pipelines is harmless or that explicitly writing secret values to logs with Write-Host is safe. In reality, both actions can expose sensitive data. Restricting library permissions is a key security measure to prevent unauthorized pipeline access.

Full explanation →
11
MCQmedium

You have an Azure Pipelines YAML file with the following trigger configuration: ```yaml trigger: branches: include: - main paths: include: - /src/* ``` The team reports that the pipeline does not trigger when changes are pushed to the main branch that modify files outside the /src folder. What is the most likely reason?

A.The path filter restricts the trigger to only changes in /src/.
B.The trigger syntax is incorrect; 'branch' should be 'branches'.
C.The script step is missing a display name.
D.The pool vmImage is not specified correctly.
AnswerA

The path filter in the trigger uses the 'paths' keyword with an 'include' clause, which restricts the pipeline to run only when changes are made to files under the /src/ directory. Any commits affecting other paths, such as the root or documentation, will not trigger the pipeline, making this statement correct.

Why this answer

The most likely reason is that a path filter is configured in the trigger, restricting the pipeline to only trigger on changes under /src/. The other options are incorrect because they either refer to minor syntax issues or irrelevant details.

Exam trap

The trap is that candidates may overlook the path filter's restrictive behavior and instead focus on minor syntax details like 'branch' vs 'branches', missing that the core issue is the include pattern limiting triggers to only the /src folder. Without seeing the exhibit, it's essential to recognize that path filters are the most likely cause.

How to eliminate wrong answers

Option B is wrong because 'branch' is actually a valid property in the trigger block (though 'branches' is also accepted as an alias), and the syntax shown is correct for specifying branch filters; the issue is not with the branch property but with the path filter. Option C is wrong because a missing display name on a script step does not affect pipeline triggering; it only affects the UI label in pipeline runs. Option D is wrong because the pool vmImage specification (e.g., 'ubuntu-latest') is syntactically correct and does not impact trigger behavior; it only defines the build agent environment.

Full explanation →
12
MCQmedium

Refer to the exhibit. You monitor an Azure App Service web app. At 10:30 AM, you observe a spike in HTTP 5xx errors and response time. Based on the metrics, what is the most likely cause?

A.The web app reached its scaling limit and could not handle the increased load.
B.A deployment of new code at 10:30 AM introduced a bug.
C.A DDoS attack started at 10:30 AM.
D.A database outage caused the errors and slow responses.
AnswerA

The correct explanation is that the App Service plan reached its maximum configured instance count, causing a capacity bottleneck. As request volume steadily increased throughout the morning, CPU/RAM utilization and the request queue grew until hitting the scaling ceiling at 10:30 AM. At that point, the service could not spawn additional instances, and Azure began responding with HTTP 500/503 errors and severe latency, which matches the sharp degradation in the exhibit.

Why this answer

The request count increased gradually from 1200 to 2500 before the errors started at 10:30 AM. The sharp rise in errors and response time coinciding with peak load indicates the app reached its capacity limit (e.g., instance count or plan limits).

Full explanation →
13
MCQmedium

You are designing a build pipeline for a Python application that uses Anaconda environments. The pipeline must create a Conda environment, install dependencies, and run tests. The pipeline should also cache the Conda environment to speed up subsequent builds. Which configuration should you use?

A.Use the 'UsePythonVersion' task with a version spec, and add a script to create the Conda environment.
B.Use a Docker container with Anaconda pre-installed and run the pipeline inside the container.
C.Use the 'CondaEnvironment' task to create the environment, and use the 'Cache' task to cache the Conda packages folder.
D.Use a script to run 'conda create' and 'conda install', and manually cache the environment by specifying a path.
AnswerC

The 'CondaEnvironment' task is specifically designed to create a Conda environment from a YAML file or package specification, ensuring the environment is set up correctly and integrated with the pipeline. Pairing it with the 'Cache' task to cache the Conda packages folder (typically 'pkgs') reduces re-download overhead and speeds up subsequent runs.

Why this answer

The 'CondaEnvironment' task is purpose-built for creating and updating Conda environments from an environment.yml file, and combining it with the 'Cache' task to cache the Conda packages folder (typically `$(Pipeline.Workspace)/conda_pkgs`) significantly reduces build time by avoiding re-downloading packages on subsequent runs. This approach aligns with Azure DevOps best practices for dependency caching and Conda environment management.

Exam trap

The trap here is that candidates often assume manual scripting (Option D) is more flexible or that Docker (Option B) is always the best isolation strategy, but they overlook the purpose-built 'CondaEnvironment' task and its seamless integration with the 'Cache' task for efficient, maintainable pipelines.

How to eliminate wrong answers

Option A is wrong because the 'UsePythonVersion' task is designed for standard Python installations (e.g., from the Microsoft-hosted agent's Python versions), not for managing Conda environments; it cannot create or activate Conda environments, and it lacks caching capabilities. Option B is wrong because using a Docker container with Anaconda pre-installed adds unnecessary complexity and overhead (e.g., image build/pull time, volume mounts) and does not natively integrate with Azure DevOps caching tasks for Conda packages; it also bypasses the simplicity of the built-in CondaEnvironment task. Option D is wrong because manually scripting 'conda create' and 'conda install' is error-prone (e.g., missing environment activation, inconsistent environment names) and manually caching by specifying a path requires extra boilerplate code to handle cache keys and restore logic, whereas the CondaEnvironment task and Cache task provide a standardized, tested solution.

Full explanation →
14
MCQhard

Your organization requires that all code changes must be built and tested before merging to the main branch. You plan to use branch policies in Azure Repos. Which policy enforcement will ensure that a pull request cannot be completed unless the build succeeds?

A.Require a linked work item in the pull request.
B.Require a minimum number of reviewers.
C.Add a build validation policy that triggers a build on each PR update.
D.Reset code reviewer votes when new changes are pushed.
AnswerC

Adding a build validation policy queues a build on every pull request update and blocks completion unless the build succeeds. This directly enforces that all code changes are built successfully before merging, preventing broken code from entering the target branch.

Why this answer

Azure Repos branch policies include a 'Build validation' policy that triggers a specified build pipeline on each pull request (PR) update. The policy enforces that the PR cannot be completed unless the build succeeds, directly meeting the requirement that all code changes must be built and tested before merging to the main branch.

Exam trap

The trap here is that candidates may confuse a 'build validation' policy with other branch policies like 'Require a linked work item' or 'Minimum number of reviewers', thinking any policy that adds a check will enforce build success, but only build validation directly triggers and gates on a build pipeline result.

How to eliminate wrong answers

Option A is wrong because requiring a linked work item ensures traceability but does not enforce any build or test execution. Option B is wrong because requiring a minimum number of reviewers enforces peer review but does not trigger or validate a build. Option D is wrong because resetting code reviewer votes when new changes are pushed ensures re-review but does not enforce build success before merge.

Full explanation →
15
Multi-Selectmedium

Which TWO actions should you take to ensure that your Azure DevOps pipeline securely manages secrets?

Select 2 answers
A.Use Azure Key Vault variable groups
B.Enable 'Allow scripts to access the system token' and print secrets in logs for debugging
C.Store secrets directly in the YAML pipeline file
D.Use secret variables set in the pipeline UI or variable groups
E.Store secrets as plain text in the repository
AnswersA, D

Azure Key Vault variable groups securely store secrets in Azure Key Vault and link them to pipelines via variable group metadata, enabling pipelines to fetch secrets at runtime without writing them into YAML or repository files; access is governed by Azure RBAC and Key Vault access policies.

Why this answer

Azure Key Vault variable groups securely store and manage secrets outside the pipeline definition, with access control and auditing. Option D is correct because secret variables set in the pipeline UI or variable groups are masked in logs and not exposed in the YAML file. Option B is incorrect: enabling script access to the system token and printing secrets in logs is a security risk.

Option C is incorrect: storing secrets directly in the YAML pipeline file exposes them in the repository. Option E is incorrect: storing secrets as plain text in the repository is insecure.

Full explanation →
16
MCQmedium

Your company uses GitHub Enterprise for source control and GitHub Actions for CI/CD. The development team is distributed across three time zones. You are designing a process to improve communication and collaboration for code reviews. The team currently uses email notifications for pull request reviews, which often get missed. You want to implement a more efficient system that integrates with Microsoft Teams and provides real-time updates. Additionally, you need to ensure that critical pull requests (e.g., those affecting production) are escalated if not reviewed within 4 hours. You also want to automatically assign reviewers based on the files changed. Which combination of actions should you take?

A.Use a GitHub App (e.g., Pull Request Assigner) to automatically assign reviewers based on file patterns. Create a GitHub Action that sends a message to Microsoft Teams via webhook when a pull request is opened. Set up a second GitHub Action that runs every hour and checks pull request age, sending an escalation to Teams if older than 4 hours.
B.Use GitHub's built-in code owners feature to automatically request reviews based on file patterns. Create a GitHub Action that posts a notification to Microsoft Teams via webhook when a pull request is opened. For escalation, create a scheduled workflow (e.g., using cron) that runs every 30 minutes to identify pull requests older than 4 hours and sends an alert to Teams.
C.Configure GitHub branch protection rules to require pull request reviews. Create a Microsoft Teams webhook connector and add it to the repository to post notifications. Instruct team leads to manually tag reviewers based on file changes.
D.Use a third-party service like PullRequest.com to manage code reviews. Configure GitHub Actions to send notifications to Teams. For escalation, use a GitHub Action that triggers on pull request review request and uses conditional logic to escalate after 4 hours.
AnswerB

This is the correct approach because CODEOWNERS natively assigns reviewers automatically based on file patterns (e.g., requiring the frontend team for .tsx changes), which is reliable and free. A GitHub Action triggered on pull_request opened sends an immediate webhook notification to Microsoft Teams, giving the team instant visibility. For escalation, a scheduled workflow using cron (e.g., every 30 minutes) queries open pull requests and alerts Teams for any PR older than 4 hours, providing timely detection without constant polling or wasted CI minutes. This combination leverages built-in GitHub features, avoids external services, and ensures stale reviews are automatically escalated.

Why this answer

It uses GitHub's built-in code owners feature for automatic reviewer assignment based on file patterns, which is native and requires no third-party app. It then uses a GitHub Action with a webhook to post real-time notifications to Microsoft Teams when a pull request is opened. For escalation, a scheduled workflow (cron) running every 30 minutes checks pull request age and sends an alert to Teams if older than 4 hours, meeting the real-time and escalation requirements without manual intervention.

Exam trap

The trap here is that candidates may choose Option A because it seems comprehensive, but they overlook that GitHub's built-in code owners feature is the recommended and simpler approach for automatic reviewer assignment, and that a scheduled workflow (cron) is necessary for time-based escalation rather than relying on event-driven triggers.

How to eliminate wrong answers

Option A is wrong because it relies on a third-party GitHub App (Pull Request Assigner) instead of GitHub's native code owners feature, which is simpler and more maintainable; also, checking pull request age every hour may miss the 4-hour escalation window if the check runs at the wrong interval. Option C is wrong because it requires manual tagging of reviewers based on file changes, which is inefficient and error-prone for a distributed team; it also lacks automated escalation for critical pull requests. Option D is wrong because it uses a third-party service (PullRequest.com) for code reviews, which adds unnecessary complexity and cost; the escalation approach using a GitHub Action triggered on review request with conditional logic is not reliable for time-based escalation because it only fires on events, not on a schedule, and cannot detect pull requests that have not been reviewed after 4 hours.

Full explanation →
17
Multi-Selecteasy

Your organization uses GitHub and wants to automatically assign pull request reviewers based on the files changed. Which three steps should you take?

Select 3 answers
A.Configure 'Code owner review requirement' in branch protection.
B.Create a CODEOWNERS file in the repository defining teams for file patterns.
C.Enable 'Require pull request reviews before merging' branch protection rule.
D.Enable 'Protected branches' for the main branch.
E.Configure team synchronization for the organization.
AnswersA, B, C

Enabling 'Code owner review requirement' under branch protection mandates that any pull request modifying files with designated code owners must receive an approving review from at least one of those owners before merging. This setting enforces the approval from the exact responsible party, making it the correct automatic review-assignment mechanism.

Why this answer

Configuring 'Code owner review requirement' in branch protection enforces that pull requests affecting files with defined code owners must be approved by those owners before merging. This ensures that changes to specific file patterns automatically require review from the designated teams or individuals, aligning with the goal of automatic assignment based on files changed.

Exam trap

The trap here is that candidates may confuse 'Require pull request reviews before merging' (which only requires any reviewer approval) with 'Code owner review requirement' (which specifically requires approval from the code owner defined in CODEOWNERS), leading them to think option C alone is sufficient without the CODEOWNERS file and the code owner enforcement.

Full explanation →
18
MCQhard

Your organization uses Azure Pipelines to build a large monolithic application. The build takes over 60 minutes. Management wants to reduce the build time to under 30 minutes. The application has multiple independent modules that could be built in parallel. What is the most effective strategy to reduce build time?

A.Reduce the number of unit tests run during the build.
B.Upgrade the build agent to a larger VM size with more CPU and memory.
C.Move the build to a self-hosted agent in the same network as the source code repository.
D.Refactor the build pipeline to use multiple parallel jobs, each building a separate module.
AnswerD

A monorepo with independent modules can be split into multiple parallel jobs, each building a separate module on its own agent; this leverages true concurrency to reduce overall wall-clock time, provided you correctly manage inter-module dependencies and publish artifacts for downstream consumption.

Why this answer

The build time is dominated by sequential compilation of independent modules. By refactoring the pipeline to use multiple parallel jobs, each building a separate module, Azure Pipelines can leverage its built-in parallelism to reduce wall-clock time significantly. This directly addresses the root cause—lack of concurrency—without sacrificing code quality or infrastructure cost.

Exam trap

The trap here is that candidates often choose 'upgrade the build agent' (Option B) because they assume more CPU/RAM will linearly speed up compilation, but for a build with many independent modules, the real bottleneck is sequential execution; adding parallelism yields the greatest reduction. Hardware upgrades may help somewhat but do not remove the sequential dependency.

How to eliminate wrong answers

Option A is wrong because reducing unit tests may compromise code quality and does not address the core issue of sequential module compilation; tests typically run after compilation and are not the primary bottleneck in a 60-minute build. Option B is wrong because upgrading to a larger VM size provides only linear CPU/memory improvements, which cannot reduce build time by half if the build is I/O-bound or constrained by sequential dependencies; parallel execution is far more effective. Option C is wrong because moving to a self-hosted agent in the same network as the source repository reduces network latency but does not change the sequential build process; the bottleneck is compilation time, not network transfer.

Full explanation →
19
Multi-Selecteasy

Which TWO tasks can be used to run unit tests in an Azure Pipeline?

Select 2 answers
A.DotNetCoreCLI@2
B.VSTest@2
C.NuGetCommand@2
D.PublishBuildArtifacts@1
E.CopyFiles@2
AnswersA, B

DotNetCoreCLI@2 runs the `dotnet test` command, which discovers and executes unit tests in .NET Core and .NET 5+ projects using the dotnet test runner, supporting VSTest and xUnit/NUnit/MSTest adapters via the `command: test` and `arguments` inputs.

Why this answer

The DotNetCoreCLI@2 task can run unit tests for .NET Core and .NET 5+ projects by invoking the 'dotnet test' command, which discovers and executes tests in the specified project files. The VSTest@2 task runs unit tests using the Visual Studio Test Runner, supporting a wide range of test frameworks (MSTest, xUnit, NUnit) and can run tests from assemblies or test containers. Both tasks are designed specifically for executing unit tests within an Azure Pipeline, making them the correct choices.

Exam trap

The trap here is that candidates may confuse tasks that are part of the build process (like NuGetCommand or CopyFiles) with tasks that actually execute tests, or assume that any task with 'Test' in its name (like VSTest) is the only correct option, overlooking DotNetCoreCLI@2 which also runs tests via 'dotnet test'.

Full explanation →
20
MCQhard

Your company uses GitHub Actions to build and deploy a Python application. The workflow includes a job that runs on a self-hosted runner. You need to ensure that sensitive environment variables are not exposed in the workflow logs. What is the best approach?

A.Use a custom action to read secrets from a file.
B.Use GitHub environment secrets and mark the secret as sensitive to ensure it is masked in logs.
C.Store secrets in GitHub repository secrets and reference them in the workflow.
D.Define the variables directly in the workflow YAML.
AnswerC

Secrets are automatically masked, but this is the standard approach, not necessarily the 'best' for additional security.

Why this answer

GitHub repository secrets and environment secrets are both automatically masked in workflow logs when referenced via ${{ secrets.NAME }}. The best practice is to store sensitive variables in GitHub secrets and reference them in the workflow, rather than defining them directly in YAML or reading from a file. Option C correctly describes this approach.

Exam trap

A common mistake is thinking you need to manually mark secrets as 'sensitive' or that repository secrets are not masked. In fact, all GitHub secrets are masked automatically.

How to eliminate wrong answers

Option A is wrong because reading secrets from a file bypasses GitHub's built-in secret masking and logging controls, potentially exposing the secret if the file content is printed or logged. Option C is wrong because while GitHub repository secrets are masked when referenced directly in workflows, the option does not specify marking them as sensitive or using environment-level scoping, which is the best practice for controlling access and ensuring masking. Option D is wrong because defining variables directly in the workflow YAML exposes them in plaintext in the repository and logs, completely defeating security requirements.

Full explanation →
21
MCQhard

Your organization uses Azure DevOps with multiple teams. You are tasked with creating a security and compliance plan. The environment includes: Azure Repos for source control, Azure Pipelines for CI/CD, and Azure Artifacts for package management. Requirements: 1) All code changes to the main branch must be reviewed by at least one member of the security team. 2) Deployment to production requires approval from a manager. 3) Secrets must be stored securely and rotated every 90 days. 4) Pipeline logs must be retained for 1 year for audit purposes. You have configured branch policies requiring a minimum number of reviewers and mandatory security team review. For production deployments, you have added a manual approval gate. Secrets are stored in Azure Key Vault with automatic rotation. However, the audit team reports that pipeline logs are only retained for 30 days. You need to extend log retention to 1 year. What should you do?

A.Export pipeline logs to Azure Blob Storage and set a lifecycle policy to retain for 365 days.
B.Configure diagnostic settings in Azure Monitor to stream pipeline logs to a Log Analytics workspace.
C.In Azure DevOps project settings, navigate to Pipelines > Retention and releases, and set the retention policy to 365 days.
D.Enable Azure DevOps audit logs and export them to a Log Analytics workspace with a 365-day retention.
AnswerC

To retain pipeline logs for 365 days, use the project-level retention policy under Project Settings > Pipelines > Retention and releases, setting the maximum retention for pipeline runs and logs to the desired number of days.

Why this answer

In Azure DevOps, pipeline retention policies for runs are configured at the project level under Project Settings > Pipelines > Retention and releases. Setting the retention to 365 days will keep pipeline run records and logs for one year. Option A is incorrect because exporting pipeline logs to Azure Blob Storage is not a built-in feature; pipeline logs are retained according to DevOps retention policies.

Option B is incorrect because diagnostic settings in Azure Monitor stream Azure resource logs, not Azure DevOps pipeline logs. Option D is incorrect because audit logs capture events like changes to policies, not pipeline execution logs, and they have separate retention settings.

Full explanation →
22
Multi-Selectmedium

Your company uses Azure Key Vault to store secrets. Which TWO actions should you take to ensure secure access? (Select TWO.)

Select 2 answers
A.Restrict access using Key Vault access policies
B.Use managed identities to authenticate applications
C.Enable HTTP access for performance
D.Disable audit logging to reduce exposure
E.Enable soft-delete to recover deleted secrets
AnswersA, B

Restrict access using Key Vault access policies: Access policies are evaluated for each principal, allowing fine-grained permissions such as get, list, and set on secrets, certs, and keys. By assigning only the minimum required permissions to each user, group, or service principal, you implement least privilege and directly reduce the attack surface for unauthorized secret access.

Why this answer

Restricting access using Key Vault access policies (Option A) is correct because Azure Key Vault uses a granular permission model where you assign specific permissions (e.g., GET, LIST, SET) to individual security principals (users, groups, or service principals) at the vault level. This ensures that only authorized identities can read or manage secrets, keys, and certificates, following the principle of least privilege. Using managed identities (Option B) is correct because they provide an automatically managed identity in Azure AD for applications to authenticate to Key Vault without storing credentials in code or configuration, eliminating the risk of secret leakage.

Exam trap

The trap here is that candidates often confuse data protection features (like soft-delete) with access control mechanisms, or mistakenly think enabling HTTP improves performance without realizing Key Vault enforces HTTPS exclusively, leading them to select options that address recovery or monitoring rather than secure authentication and authorization.

Full explanation →
23
MCQeasy

Your team uses GitHub for source control and Azure Pipelines for CI/CD. You need to ensure that only pull requests from specific branches trigger a build pipeline. Which trigger configuration should you use?

A.pr: paths: include: - main - develop
B.pr: branches: only: - main
C.trigger: branches: include: - main - develop
D.pr: branches: include: - main - develop
AnswerD

This is the correct YAML syntax for filtering PR triggers by target branch. The `pr` keyword enables PR validation, and `branches: include` specifies that only PRs targeting `main` or `develop` should be built, ensuring the pipeline runs only for those branches.

Why this answer

The `pr` trigger in Azure Pipelines controls which pull requests trigger a pipeline. By using `branches` with `include`, you specify that only PRs targeting the `main` and `develop` branches should trigger the build. This directly meets the requirement to restrict PR triggers to specific branches.

Exam trap

The trap here is confusing `pr` triggers (for pull requests) with `trigger` triggers (for CI builds on commits), leading candidates to select option C which targets commits instead of PRs.

How to eliminate wrong answers

Option A is wrong because `paths` filters changes by file paths, not branches; it would still trigger on PRs to any branch if the specified paths are modified. Option B is wrong because `only` is not a valid keyword under `pr.branches`; the correct syntax uses `include` and `exclude`. Option C is wrong because `trigger` controls CI triggers for commits, not pull request triggers; it would run builds on direct pushes to `main` and `develop`, not on PRs.

Full explanation →
24
MCQeasy

You need to enforce that all builds in Azure Pipelines use a specific version of the .NET SDK. What is the best approach?

A.Add a UseDotNet task to the pipeline that specifies the required SDK version.
B.Set a pipeline variable DotNetVersion and use it in the DotNetCoreCLI task.
C.Install the SDK manually on the build agent using a script.
D.Include a global.json file in the repository and rely on the build agent to respect it.
AnswerA

Correct: The UseDotNet task can download and install a specified .NET SDK version, enforcing it for the build.

Why this answer

The UseDotNet task in Azure Pipelines can be configured to download and install a specific version of the .NET SDK, ensuring that all builds use exactly that version, regardless of what is pre-installed on the agent. Option B is incorrect because setting a pipeline variable DotNetVersion and using it in the DotNetCoreCLI task does not enforce the SDK version; the DotNetCoreCLI task uses the SDK already available on the agent, unless explicitly redirected, and the variable alone does not install or enforce a specific SDK. Option C is incorrect because installing the SDK manually via a script is not a reliable or repeatable approach; it depends on the agent's state and does not automatically enforce the version across different agents or pipeline runs.

Option D is incorrect because including a global.json file in the repository does not guarantee that the required SDK version is installed on the agent; the build agent may not respect global.json if the specified SDK is not present, and there is no enforcement mechanism without additional steps.

Full explanation →
25
MCQhard

Your team uses Azure Pipelines with a YAML-based build pipeline. The pipeline builds a .NET application and runs unit tests. Recently, the unit tests are failing intermittently due to flaky tests. You need to ensure that the pipeline fails only if the same test fails in two consecutive runs. Which feature should you configure?

A.Implement a GitHub Actions workflow with 're-run' trigger.
B.Use the 'Re-run failed stages' option in the pipeline run.
C.Enable 'Automatically rerun failed jobs' in the pipeline settings.
D.Configure the 'retry failed tests' setting in the pipeline's test tab.
AnswerD

The 'retry failed tests' setting in the pipeline's Test tab is the correct way to handle flaky tests: it automatically re-executes only the failed test cases (not entire jobs or stages) a configurable number of times during the same run. If a retried test passes, it is reported as 'Passed on retry' in the Test tab, giving you visibility into which tests are flaky while keeping the overall run green.

Why this answer

The correct feature is the 'Retry failed tests' setting in the pipeline's test tab. This allows you to configure the number of times a failed test is automatically retried. If the test passes on retry, the pipeline is marked as succeeded with warnings, effectively requiring two consecutive failures for the pipeline to fail.

Option A is incorrect because GitHub Actions workflows are not relevant to Azure Pipelines. Option B is for rerunning failed stages, not individual tests. Option C reruns failed jobs, not tests.

Full explanation →
26
MCQhard

You are designing a build pipeline that must be triggered only when changes are made to specific folders in the repository. The pipeline should ignore documentation changes. Which trigger configuration should you use?

A.Configure a scheduled trigger to run the pipeline daily.
B.Configure a branch trigger with an include filter for the main branch.
C.Configure a path trigger with include paths for source code and exclude paths for docs.
D.Configure a tag trigger with a pattern that matches release tags.
AnswerC

A path trigger uses include/exclude patterns on file paths to decide whether a push starts the pipeline. By including paths to source code folders and excluding paths to docs, the pipeline runs only when actual code changes, precisely matching the trigger requirement while ignoring doc-only commits.

Why this answer

Azure Pipelines path triggers allow you to specify include and exclude filters on file paths. By including only source code folders and excluding the docs folder, the pipeline will only run when relevant code changes are made, ignoring documentation updates.

Exam trap

The trap here is that candidates often confuse branch triggers with path triggers, thinking that filtering by branch alone can ignore documentation changes, but branch filters only control which branches trigger the pipeline, not which files within those branches.

How to eliminate wrong answers

Option A is wrong because a scheduled trigger runs the pipeline at specified times regardless of any changes, so it would not respond to specific folder changes. Option B is wrong because a branch trigger with an include filter for the main branch only restricts which branch triggers the pipeline, not which paths within that branch; it would still trigger on any change to the main branch, including documentation. Option D is wrong because a tag trigger is designed to run the pipeline when a Git tag matching a pattern is pushed, not for monitoring changes to specific folders.

Full explanation →
27
MCQeasy

Your team uses GitHub and wants to automatically detect and block secrets pushed to repositories. Which GitHub feature should you enable?

A.Dependabot alerts
B.Code scanning
C.Push protection
D.Secret scanning
AnswerC

Push protection is not an independent feature; it is a layer built into secret scanning that blocks git pushes when a known secret is detected. It relies entirely on secret scanning's detection engine, so it cannot be the feature that automatically detects secrets by itself.

Why this answer

Push protection is the GitHub feature that automatically detects known types of secrets in pushed content and blocks the push, preventing exposure. Secret scanning, on the other hand, scans for secrets and alerts after they exist in the repository but does not block the push unless push protection is enabled. Since the requirement is to 'automatically detect and block secrets pushed', the feature to enable is Push protection.

Exam trap

A common mistake is selecting 'Secret scanning' because it is a broader feature, but the question specifically requires blocking. Push protection is the sub-feature that actually blocks the push, while secret scanning provides the underlying detection mechanism. You can enable push protection as part of secret scanning, but the blocking action is performed by push protection.

How to eliminate wrong answers

Option A is wrong because Dependabot alerts are focused on vulnerable dependencies and outdated package versions, not on detecting secrets in code. Option B is wrong because Code scanning uses CodeQL to find code quality and security vulnerabilities (e.g., SQL injection, XSS), but it does not scan for hardcoded secrets or block pushes. Option C is wrong because Push protection is a sub-feature of Secret scanning that blocks pushes containing secrets, not a standalone feature; the question asks which feature to enable, and the parent feature is Secret scanning.

Full explanation →
28
Multi-Selecteasy

Which TWO Git commands are commonly used to incorporate changes from a remote repository into your local branch while keeping history linear?

Select 2 answers
A.git pull --rebase
B.git fetch
C.git merge
D.git cherry-pick
E.git rebase
AnswersA, E

Fetches and rebases local commits on top of remote branch.

Why this answer

`git pull --rebase` (A) is correct because it fetches changes from the remote and then replays your local commits on top of the fetched commits, resulting in a linear history without merge commits. `git rebase` (E) is correct because it directly rewrites commit history by moving or combining a sequence of commits onto a new base, which can be used to incorporate remote changes linearly when combined with `git fetch`.

Exam trap

The trap here is that candidates often confuse `git fetch` (which only downloads data) with `git pull` (which integrates), or they assume `git merge` always creates a merge commit and forget that fast-forward merges can keep history linear, but the question explicitly asks for commands that keep history linear, and `git merge` does not guarantee that.

Full explanation →
29
MCQmedium

A company uses Azure Pipelines to deploy a web app to Azure App Service. They want to ensure that the deployment is first validated in a staging slot before swapping to production. What should they configure?

A.Create two separate pipelines for staging and production
B.Use Azure Traffic Manager to route traffic
C.Use deployment slots in the App Service and configure auto-swap
D.Use an App Service plan with multiple instances
AnswerC

Deployment slots are separate, warm environments in the same App Service plan that allow you to deploy and validate a build without affecting the production slot. Configuring auto-swap promotes the verified staging slot to production instantly with zero downtime, making it the recommended pattern for Azure Pipelines deployments to App Service.

Why this answer

Azure App Service deployment slots allow you to deploy a web app to a staging slot, validate it, and then swap it to production with zero downtime. Auto-swap automates this process by swapping the staging slot into production after a successful deployment, ensuring validation occurs before the production slot receives the new code.

Exam trap

The trap here is that candidates often confuse deployment slots with separate pipelines or scaling, not realizing that slots provide a built-in, zero-downtime validation mechanism within the same App Service.

How to eliminate wrong answers

Option A is wrong because creating two separate pipelines for staging and production introduces manual overhead and potential configuration drift, whereas deployment slots within a single pipeline enable seamless validation and swap. Option B is wrong because Azure Traffic Manager is a DNS-based traffic load balancer for routing traffic across regions, not for validating deployments within a single App Service; it does not provide slot swapping or pre-production validation. Option D is wrong because scaling an App Service plan with multiple instances improves availability and performance but does not provide a staging environment for validating deployments before they reach production.

Full explanation →
30
MCQhard

You have a YAML pipeline that deploys to multiple environments. The pipeline uses environment approvals. You need to ensure that the pipeline waits for manual approval before deploying to the production environment. The production environment is named 'Production'. Which configuration should you add to the deployment job?

A.Add 'environment: Production' to the deployment job and configure approvals on the environment in the Azure DevOps portal
B.Add 'approvals: Production' to the deployment job
C.Add 'checks: Production' to the deployment job
D.Add 'dependsOn: ProductionApproval' and use a separate stage for approval
AnswerA

In Azure DevOps, attaching a deployment job to an environment named 'Production' and configuring approvals on that environment in the portal is the correct, native mechanism. The environment acts as a gate that pauses the pipeline before deployment, waiting for the designated approvers to approve or reject the release, with full audit trail and notifications.

Why this answer

Environment approvals in Azure DevOps are configured on the environment resource itself, not in the pipeline YAML. By adding 'environment: Production' to the deployment job, the pipeline references the environment, and the manual approval gate is enforced by the approvals configured on that environment in the Azure DevOps portal. This ensures the pipeline waits for approval before proceeding to the production deployment job.

Exam trap

The trap here is that candidates often assume approvals can be defined directly in the YAML pipeline (like a task or a key), but Azure DevOps requires approvals to be configured on the environment resource in the portal, not in the pipeline code.

Why the other options are wrong

B

'approvals' is not a valid keyword in YAML pipeline syntax.

C

'checks' is not a valid keyword; checks are configured on environments.

D

While you can create a separate stage for approval, it's not the standard way; environment approvals are built-in.

Full explanation →
31
MCQhard

You have the YAML pipeline shown in the exhibit. What will be the output of the script in the Deploy stage?

A.The Deploy stage will be skipped
B.Deploying to prod
C.Deploying to dev
D.The script will fail because variable is not defined
AnswerB

The Deploy stage defines the variable 'environment' with the value 'prod' in its stage-level variables block. This stage-scoped variable overrides any same-named variable from the pipeline or global scope, so when the script executes 'echo Deploying to $(environment)', it outputs 'Deploying to prod'.

Why this answer

The YAML pipeline defines a variable `environment` at the stage level with the value `prod`. The script in the Deploy stage references `$(environment)`, which resolves to `prod`, so the output is `Deploying to prod`. Stage-level variables override any pipeline-level or default variables for that stage.

Exam trap

The trap here is that candidates may assume the variable `environment` is undefined or defaults to `dev` from a pipeline-level variable, but they overlook that the stage-level definition explicitly sets it to `prod`, which overrides any broader scope.

How to eliminate wrong answers

Option A is wrong because the Deploy stage is not skipped; it runs normally with the stage-level variable `environment` set to `prod`. Option C is wrong because the variable `environment` is explicitly set to `prod` in the stage, not `dev`; if no stage-level variable were defined, it might default to `dev` from a pipeline-level variable, but here the stage-level value takes precedence. Option D is wrong because the variable `environment` is defined at the stage level, so it is available to the script; the script will not fail due to an undefined variable.

Full explanation →
32
MCQmedium

Refer to the exhibit. Your organization has configured an Azure DevOps pipeline security setting that enforces a required template for all pipelines deploying to production and staging. The required template 'security-validation.yml' runs a series of security scans and compliance checks. A developer creates a new pipeline that deploys to a test environment, but the pipeline does not reference the required template. What will happen?

A.The pipeline will run normally because the required template enforcement only applies to production and staging environments.
B.The pipeline will run but the security scans will be automatically injected.
C.The pipeline will fail because it does not reference the required template.
D.The pipeline will prompt the developer to add the required template before running.
AnswerC

Incorrect. The pipeline will not fail because the required template enforcement is restricted to production and staging environment scopes only. Since this pipeline targets a test environment, it is outside the enforcement scope, so omitting the required template does not trigger a policy failure and the pipeline executes normally.

Why this answer

The Azure DevOps 'Required template' security setting is configured at the project or organization level and applies to all YAML pipelines, regardless of the deployment target environment. There is no native option to enforce it only for specific environments like production or staging. Therefore, a new pipeline deploying to test without referencing the required template would also fail.

Exam trap

The trap incorrectly claims that required template enforcement can be scoped to environments. In reality, the enforcement is global; once enabled, all pipelines must include the template.

How to eliminate wrong answers

Option B is wrong because Azure DevOps does not automatically inject security scans into pipelines that do not reference the required template; the enforcement is based on environment targeting, not automatic injection. Option C is wrong because the pipeline will not fail—the required template policy only blocks pipelines that deploy to production or staging without the template, not those targeting test environments. Option D is wrong because Azure DevOps does not prompt developers to add the required template; it either enforces the requirement at queue time (failing the run) or allows the run, depending on the environment scope.

Full explanation →
33
MCQhard

You are implementing a multi-stage YAML pipeline in Azure Pipelines for a microservices application. You need to ensure that the 'deploy' stage only runs if the 'build' stage succeeds and that the 'test' stage runs in parallel with 'build' for different services. How should you structure the pipeline?

A.Define stages 'build', 'test', 'deploy' with 'dependsOn: []' on 'test' and 'dependsOn: build' on 'deploy'
B.Define stages 'build', 'test', 'deploy' with 'dependsOn: build' on 'test' and 'dependsOn: test' on 'deploy' but use 'condition: always()' on test
C.Define stages 'build', 'test', 'deploy' with 'dependsOn: build' on 'test' and 'dependsOn: test' on 'deploy'
D.Define stages 'build', 'test', 'deploy' with no dependsOn; by default they run sequentially
AnswerA

test runs in parallel with build because it has no dependencies; deploy runs after build.

Why this answer

Setting `dependsOn: []` on the 'test' stage removes any implicit dependency, allowing it to run in parallel with the 'build' stage (since stages without explicit dependencies default to running sequentially after the previous stage). The 'deploy' stage with `dependsOn: build` ensures it only runs after the 'build' stage succeeds, as Azure Pipelines stages by default only run if all dependencies succeed. This structure meets the requirement: 'test' runs in parallel with 'build' for different services, and 'deploy' depends on 'build' success.

Exam trap

The trap here is that candidates assume stages always run sequentially by default and overlook the `dependsOn: []` syntax to break the implicit dependency chain, leading them to choose options that enforce sequential execution or incorrect conditions.

How to eliminate wrong answers

Option B is wrong because `condition: always()` on the 'test' stage would cause it to run even if the 'build' stage fails, which violates the requirement that 'deploy' only runs if 'build' succeeds (though 'test' could still run, the condition is unnecessary and could lead to unwanted behavior). Option C is wrong because it makes 'test' depend on 'build' (sequential, not parallel) and 'deploy' depend on 'test', forcing a linear order that does not allow 'test' to run in parallel with 'build'. Option D is wrong because by default stages run sequentially in the order they are defined, so 'build' would run first, then 'test', then 'deploy', which does not achieve parallel execution of 'test' with 'build'.

Full explanation →
34
MCQmedium

Your organization uses Azure DevOps to manage CI/CD pipelines. The security team requires that all pipeline runs use a specific service connection that references a managed identity in Microsoft Entra ID. However, some developers have been using personal access tokens (PATs) in their pipelines, bypassing the managed identity. What should you implement to enforce the use of the managed identity service connection?

A.Configure a branch policy on the main branch to require a specific service connection.
B.Use a pipeline decorator to validate the service connection and fail the pipeline if an unauthorized connection is used.
C.Restrict the use of PATs by setting an agent pool-level permission.
D.Store the service connection ID in a variable group and reference it in each pipeline.
AnswerB

Pipeline decorators are injected into every job at execution time, allowing you to add a validation step that inspects the service connection ID used by tasks such as AzureCLI or AzurePowerShell. Because the decorator runs as part of the job definition, you can compare the connection against an approved list and call an error to fail the pipeline before deployment proceeds. This control is centralized at the organization level and cannot be bypassed by a repository without modifying the decorator itself, making it the only enforceable option.

Why this answer

Pipeline decorators allow you to inject custom validation steps into every pipeline run at the organization or project level. By using a decorator that checks the service connection ID used in each job and fails the run if it does not match the approved managed identity connection, you can enforce compliance without relying on developer cooperation or manual policy configuration.

Exam trap

The trap here is that candidates confuse branch policies (which control code changes) with runtime enforcement mechanisms, overlooking that only pipeline decorators can inject mandatory validation into every pipeline execution.

How to eliminate wrong answers

Option A is wrong because branch policies apply to pull request validation and merge gates, not to the service connection used during pipeline execution; they cannot enforce which connection is used at runtime. Option C is wrong because agent pool-level permissions control who can use or manage the pool, not which authentication method (PAT vs. managed identity) is used in pipeline tasks. Option D is wrong because storing the service connection ID in a variable group does not enforce its use; developers can still reference a different connection directly in their YAML or override the variable.

Full explanation →
35
MCQeasy

You need to trigger a pipeline whenever changes are pushed to the 'main' branch of a GitHub repository. Which trigger should you configure in the YAML pipeline?

A.trigger: branches: include: - main
B.pr: branches: include: - main
C.resources: repositories: - repository: self trigger: branches: include: - main
D.schedules: - cron: "0 0 * * *" branches: include: - main
AnswerA

This is the standard YAML syntax in Azure Pipelines to trigger a pipeline on a push to the main branch in GitHub. It uses the `trigger` keyword with branch filters under `branches.include`, causing the pipeline to run automatically when commits are pushed to that branch.

Why this answer

The `trigger` keyword at the root of a YAML pipeline defines the CI trigger that automatically starts a pipeline run when changes are pushed to the specified branch. By including `main` under `branches.include`, the pipeline will trigger on any push to the `main` branch of the GitHub repository, which is the standard way to set up a CI trigger for a single branch.

Exam trap

The trap here is that candidates often confuse the `trigger` (CI push trigger) with the `pr` (pull request trigger), or incorrectly assume that a resource-level trigger is required for the self repository, when the root-level `trigger` is the correct and simplest configuration for push-based CI on the same repository.

Why the other options are wrong

B

This triggers on pull request creation, not on push.

C

This is for triggering from another repository, not the self repo.

D

This is a scheduled trigger, not on push.

Full explanation →
36
Multi-Selecthard

Which THREE steps should you take to implement a blue-green deployment strategy for an Azure App Service using Azure Pipelines? (Choose three.)

Select 3 answers
A.Create a deployment slot named 'staging' for the App Service.
B.Enable 'Auto swap' on the staging slot.
C.Deploy the new version to the staging slot.
D.Delete the production slot after swapping.
E.Route 100% of traffic to the staging slot.
AnswersA, B, C

Create a deployment slot named 'staging' for the App Service: This creates a separate live app slot that acts as the 'green' environment, allowing you to deploy and validate a new build without affecting the 'blue' production slot. The staging slot gets its own hostname and app settings, and you can later swap it with the production slot to promote the new version.

Why this answer

In a blue-green deployment for Azure App Service using Azure Pipelines, the three key steps are: create a staging deployment slot (A), enable 'Auto swap' on the staging slot (B), and deploy the new version to the staging slot (C). Auto-swap ensures that after the new version is deployed and validated, the staging slot automatically swaps with the production slot, enabling zero-downtime updates. Option D (deleting the production slot after swapping) is incorrect because the production slot continues to hold the previous version for potential rollback.

Option E (routing 100% of traffic to the staging slot) is incorrect because traffic routing is handled by the swap operation, not by manually directing traffic.

Full explanation →
37
MCQmedium

Your team uses GitHub Actions to build and deploy a Node.js application to Azure App Service. The deployment succeeds, but the app crashes after startup with an error indicating a missing module. The build artifact includes the node_modules folder. What is the most likely cause?

A.The .gitignore file excludes node_modules from the artifact.
B.The Node.js version on the runner differs from the App Service runtime, causing native module incompatibility.
C.The workflow YAML has an indentation error that causes the deploy step to fail silently.
D.The build step does not run npm ci, so the package-lock.json is ignored.
AnswerB

The runner and Azure App Service runtime must use the same Node.js major version (or at least a compatible ABI) for native modules such as bcrypt or sharp. If the workflow builds with a different Node.js version than the App Service runtime, those native addons are compiled against incompatible V8/N-API binaries and fail to load at startup, producing a 'module not found' or similar crash.

Why this answer

The most likely cause is that the Node.js version on the GitHub Actions runner differs from the version on Azure App Service, leading to native module incompatibility. Native modules (e.g., those using node-gyp) are compiled against the specific Node.js ABI (Application Binary Interface) of the build environment. If the runtime version differs, the compiled .node binaries will fail to load, resulting in a 'missing module' error even though the node_modules folder is present in the artifact.

Exam trap

The trap here is that candidates assume a missing module error always means the file wasn't included in the artifact, but in this scenario the node_modules folder is present, so the real issue is ABI incompatibility between the build and runtime Node.js versions.

How to eliminate wrong answers

Option A is wrong because the .gitignore file does not affect the build artifact; GitHub Actions artifacts are created from the workspace after the build step, and the workflow explicitly includes node_modules in the artifact. Option C is wrong because an indentation error in the YAML would cause the workflow to fail at parse time, not silently skip the deploy step; the deployment succeeded, so the YAML is valid. Option D is wrong because npm ci is used for deterministic installs based on package-lock.json, but the error is about a missing module at runtime, not about the install process; the artifact includes node_modules, so npm ci was likely run or the modules were otherwise included.

Full explanation →
38
MCQhard

Your organization uses Azure Pipelines to manage infrastructure as code with Terraform. The pipeline runs terraform plan and apply. You need to ensure that the state file is stored securely and can be locked to prevent concurrent modifications. What should you configure?

A.Store the state file in a Git repository with LFS.
B.Use the Terraform Cloud backend with remote operations.
C.Store the state file in Azure Pipelines secure files.
D.Use an Azure Storage account as the backend with a container for the state file.
AnswerB, D

Terraform Cloud does provide state locking and remote operations, but it is a third-party SaaS that requires managing an external subscription and credentials outside Azure; for an Azure-centric pipeline, an Azure Storage-backed backend is the native, integrated choice.

Why this answer

Both Azure Storage backend (D) and Terraform Cloud backend (B) satisfy the requirement of secure state storage and locking. Azure Storage uses blob leases; Terraform Cloud uses its own locking mechanism. The original explanation only justifies D but does not explain why B is incorrect, and it cannot be considered incorrect as written.

Exam trap

The trap here is that candidates may confuse secure file storage (Option C) with state file storage, not realizing that state files require dynamic locking and frequent updates, which secure files do not support.

How to eliminate wrong answers

Option A is wrong because storing the state file in a Git repository with LFS does not provide native locking mechanisms and can lead to merge conflicts or corruption when multiple pipelines attempt to update the state simultaneously. Option B is wrong because Terraform Cloud with remote operations is a paid service and introduces an external dependency, whereas the requirement specifies using Azure Pipelines and Azure-native services. Option C is wrong because Azure Pipelines secure files are designed for storing secrets or configuration files, not for dynamic state files that require read/write locking and frequent updates during pipeline execution.

Full explanation →
39
MCQmedium

Your team uses GitHub Actions for CI/CD. You need to ensure that secrets stored in GitHub repository secrets are not exposed in build logs. Which security practice should you implement?

A.Use GitHub Actions secrets and ensure they are marked as masked
B.Store secrets in a YAML file within the repository
C.Pass secrets as environment variables in the workflow
D.Use a third-party secret management service and fetch secrets at runtime
AnswerA

Use GitHub Actions secrets and ensure they are marked as masked. This is correct because secrets are automatically masked in logs when referenced via ${{ secrets.NAME }}.

Why this answer

GitHub Actions automatically masks secret values in build logs when referenced via the secrets context, such as ${{ secrets.SECRET_NAME }}. Option B is wrong because storing secrets in a repository YAML file exposes them to anyone with repo access. Option C is wrong not because environment variables are unsecurely logged, but because it is not the recommended practice; secrets should be referenced directly through the secrets context to avoid risk of unintended exposure (e.g., if the value is modified or used outside GitHub's masking).

Option D, while a valid security practice, does not directly address preventing log exposure unless the fetched secrets are also masked.

Exam trap

The trap is that even when using GitHub Actions secrets, if you output them to logs using echo or similar commands without proper masking, they can still be exposed. However, if you use the built-in secret syntax (${{ secrets.NAME }}), GitHub automatically masks them.

Full explanation →
40
MCQmedium

Your Azure DevOps project contains a Git repository with multiple branches. You need to ensure that code reviews are mandatory for all pull requests targeting the 'release' branch. Additionally, the build pipeline must pass before merging. How should you configure branch policies?

A.Enable 'Build validation' only.
B.Enable 'Require a minimum number of reviewers' only.
C.Enable 'Require a minimum number of reviewers' and 'Build validation'.
D.Enable 'Require a minimum number of reviewers' and 'Comment resolution'.
AnswerC

Combining 'Require a minimum number of reviewers' and 'Build validation' enforces both peer review and a successful build pipeline. This ensures that changes are approved by the required reviewers and meet the build quality gate before merging, delivering comprehensive branch protection.

Why this answer

The requirement specifies two distinct conditions: mandatory code reviews (enforced by 'Require a minimum number of reviewers') and a passing build pipeline before merge (enforced by 'Build validation'). In Azure Repos, branch policies allow you to combine multiple checks; enabling only one of these would leave the other requirement unmet. Therefore, both policies must be enabled to satisfy the full criteria.

Exam trap

The trap here is that candidates often assume 'Comment resolution' implies code review completion, but it only requires that all discussion comments are resolved, not that a specific number of reviewers have approved the changes.

How to eliminate wrong answers

Option A is wrong because enabling only 'Build validation' ensures the pipeline passes but does not enforce mandatory code reviews, leaving the review requirement unmet. Option B is wrong because enabling only 'Require a minimum number of reviewers' enforces code reviews but does not require the build pipeline to pass before merging, violating the build condition. Option D is wrong because 'Comment resolution' ensures all comments are resolved before merging, but it does not enforce a minimum number of reviewers or build validation, so it fails both stated requirements.

Full explanation →
41
Drag & Dropmedium

Drag and drop the steps to configure Azure Monitor alerts for application performance into the correct order.

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

Steps
Order
1Step 1
2Step 2
3Step 3
4Step 4

Why this order

Alert setup begins with enabling monitoring, creating rule, setting condition, action groups, and testing.

Full explanation →
42
Multi-Selectmedium

A company deploys a web application to Azure App Service. They want to monitor application performance and detect anomalies using Application Insights. Which two components should be configured?

Select 2 answers
A.Deploy the Azure Monitor agent on the App Service instance
B.Configure sampling to reduce data volume
C.Create a Log Analytics workspace and configure data collection rules
D.Enable application-side SDK for telemetry
E.Enable diagnostics settings to stream logs to Event Hubs
AnswersB, D

Configuring sampling in Application Insights filters telemetry while preserving a representative subset of the data. This reduces ingestion and storage costs while still retaining enough data to detect performance anomalies, making it an effective and necessary optimization for high-volume applications.

Why this answer

Sampling in Application Insights reduces the volume of telemetry data while preserving statistically correct analysis, which is essential for managing cost and performance in high-traffic applications. Option D is correct because the application-side SDK (e.g., Application Insights SDK for .NET, Java, or Node.js) is required to instrument the code and collect detailed telemetry such as requests, dependencies, and exceptions for performance monitoring and anomaly detection.

Exam trap

The trap here is that candidates often confuse the Azure Monitor agent (for VMs) with the App Service diagnostics settings or Log Analytics workspaces, thinking they are required for Application Insights instrumentation, when in fact the SDK and sampling are the two core components for application performance monitoring and anomaly detection.

Full explanation →
43
Multi-Selecthard

Which THREE of the following are valid considerations when designing a release pipeline to deploy to multiple environments (dev, test, prod) using Azure Pipelines YAML?

Select 3 answers
A.Use variable groups scoped to environments to override variables per stage.
B.Use environment-level approvals to gate production deployments.
C.Use stage-level approvals to gate each stage.
D.Use conditions on stages to filter based on branch.
E.Use YAML templates to define each environment's deployment steps.
AnswersA, B, D

In Azure Pipelines, variable groups can be linked to an environment, allowing environment-specific variable values to be automatically injected into deployment jobs that target that environment. This enables per-stage overrides without duplicating pipeline code, because each stage can reference a different environment and thus consume its linked variable group, making it a valid and recommended practice.

Why this answer

Variable groups can be reused across pipelines and stages. In a multi-stage YAML pipeline, you can use different variable groups for each environment by referencing them in the `variables` section of each stage (e.g., a variable group for dev, test, and prod). This allows you to override values such as connection strings per environment without duplicating pipeline code.

For production deployments, you should configure approvals and checks on the Azure Pipelines environment resource (e.g., 'prod') to require manual sign-off before the deployment job runs. Stage-level approvals do not exist in Azure Pipelines; approvals are always attached to an environment or a service connection. For branch-based filtering, you can use stage `condition` expressions, such as `and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))`, to control which stages run based on the source branch.

To reduce duplication, use YAML templates with parameters to define a single deployment template that is reused across environments rather than creating separate templates per environment.

Exam trap

The trap here is that candidates often confuse stage-level approvals (which do not exist) with environment-level approvals, and they mistakenly think YAML templates should be used to define separate deployment steps per environment instead of parameterizing a single template.

Full explanation →
44
Multi-Selecthard

Which THREE practices improve the efficiency of code review processes in GitHub?

Select 3 answers
A.Allow direct pushes to main for urgent fixes.
B.Enable required status checks to pass before merging.
C.Use pull request templates with checklists.
D.Require at least 5 reviewers for every PR.
E.Keep pull requests small and focused.
AnswersB, C, E

Automated checks reduce manual review burden.

Why this answer

Enabling required status checks ensures that automated tests, builds, or other validation steps must pass before a pull request can be merged. This enforces quality gates directly in the branch protection rules, preventing broken code from being merged and reducing manual review overhead.

Exam trap

The trap here is that candidates may confuse 'efficiency' with 'speed' and choose Option A (direct pushes) to bypass review, but the question asks for practices that improve efficiency of the review process itself, not shortcuts that undermine it.

Full explanation →
45
Multi-Selecthard

Which TWO approaches can you use to enforce consistent commit message formatting across your organization? (Choose two.)

Select 2 answers
A.Use a pre-receive hook in GitHub to validate commit messages
B.Use a GitHub workflow that checks PR titles
C.Configure a branch policy in Azure Repos to require commit message validation
D.Provide a commit message template to developers
E.Use Git hooks only on client side
AnswersA, C

A pre-receive hook in GitHub executes on the server for every push and can reject commits with invalid message formats before they are accepted, providing a hard enforcement point that developers cannot bypass locally. This centralizes policy and guarantees consistent commit message history across all contributions.

Why this answer

GitHub's pre-receive hooks are server-side scripts that execute on the repository before accepting a push, allowing you to enforce commit message format validation across all contributors. Similarly, Azure Repos branch policies can include a commit message pattern check, which validates commit messages against a regex and rejects pushes with non-conforming messages. Both approaches enforce the standard on the server side, regardless of local client configurations.

Exam trap

The trap here is that candidates often confuse client-side Git hooks (which are optional and local) with server-side hooks (which enforce policy remotely), or they mistakenly believe that PR title checks or templates provide the same level of enforcement as server-side validation.

Full explanation →
46
Multi-Selecteasy

Which TWO metrics should you monitor to evaluate the reliability of a web application according to the DORA metrics?

Select 2 answers
A.Lead Time for Changes
B.Change Failure Rate
C.Mean Time to Restore (MTTR)
D.CPU Usage
E.Deployment Frequency
AnswersB, C

Change Failure Rate is the percentage of deployments that cause a failure in production, such as a service impairment or rollback. It is a core DORA reliability metric because it directly quantifies how often changes disrupt service, making it essential for evaluating system stability.

Why this answer

The DORA metrics define four key measures for software delivery performance: Deployment Frequency, Lead Time for Changes, Mean Time to Restore (MTTR), and Change Failure Rate. For evaluating the reliability of a web application, the two most directly relevant metrics are Change Failure Rate (B), which measures the percentage of deployments causing a failure in production, and Mean Time to Restore (MTTR) (C), which measures the time it takes to recover from a failure. These two metrics directly quantify stability and resilience, whereas Deployment Frequency and Lead Time for Changes focus on throughput and speed.

Exam trap

The trap here is that candidates often confuse throughput metrics (Deployment Frequency, Lead Time for Changes) with reliability metrics, but DORA specifically separates them into 'throughput' and 'stability' categories, and the question explicitly asks for reliability.

Full explanation →
47
MCQhard

You configured a multi-stage YAML pipeline with a deployment job that uses a deployment strategy like 'runOnce' or 'rolling'. You need to ensure that the deployment target is marked as 'succeeded' only after the deployment job completes successfully, and that any previous deployment to the same environment is preserved for rollback. Which setting must you configure?

A.Set the environment's 'retain' property to 1 or more
B.Set the deployment job's 'continueOnError' to true
C.Use the 'deployment' job with 'strategy: rolling'
D.Set the 'deploymentStrategy' to 'blueGreen'
AnswerA

Setting the environment's 'retain' property to 1 or more instructs Azure Pipelines to keep the specified number of previous deployments for that environment. This retained deployment history enables rollback to a prior version, as the pipeline can redeploy the previous artifact without needing to recreate it.

Why this answer

Setting the environment's 'retain' property to 1 or more ensures that the previous deployment (e.g., the last successful run) is preserved as a 'retained' revision in the environment. This allows you to redeploy that specific revision for rollback purposes. The deployment job marks the environment target as 'succeeded' only after the job completes successfully, and retaining previous revisions prevents them from being automatically cleaned up.

Exam trap

The trap here is that candidates often confuse deployment strategies (rolling, blue-green) with revision retention, assuming that a strategy like 'rolling' or 'blueGreen' inherently preserves previous deployments for rollback, when in fact retention is a separate environment-level setting.

Why the other options are wrong

B

This would continue on failure, not preserve previous deployments.

C

This defines the update strategy but does not control retention of history.

D

Blue-green is a deployment strategy, but retention is still controlled by environment settings.

Full explanation →
48
MCQeasy

Your organization uses Microsoft Purview to classify and protect sensitive data. You need to ensure that source code in Azure DevOps repositories containing credit card numbers is detected and flagged. What should you configure?

A.Create a Data Loss Prevention (DLP) policy in Microsoft 365.
B.Set up Microsoft Sentinel to monitor Azure DevOps logs.
C.Configure a Microsoft Purview Data Classification scan for Azure DevOps repositories.
D.Enable Microsoft Defender for Cloud to scan repositories.
AnswerC

Microsoft Purview provides data governance and classification capabilities, and its data map can register and scan Azure DevOps repositories to automatically classify sensitive data such as credentials, connection strings, and personal information. This directly aligns with the requirement to classify and protect sensitive information in your organization's code repositories.

Why this answer

Microsoft Purview Data Classification scans can be configured to scan Azure DevOps repositories for sensitive data types, such as credit card numbers, using built-in or custom sensitive information types. This allows the organization to detect and flag source code containing credit card numbers directly within the repository, aligning with the requirement to classify and protect sensitive data under a compliance plan.

Exam trap

The trap here is that candidates often confuse Microsoft Purview Data Classification (which can scan Azure DevOps repositories) with Microsoft 365 DLP policies (which are limited to Microsoft 365 workloads), leading them to select Option A incorrectly.

How to eliminate wrong answers

Option A is wrong because Data Loss Prevention (DLP) policies in Microsoft 365 are designed to protect data in Microsoft 365 services (e.g., Exchange, SharePoint, OneDrive) and do not natively scan Azure DevOps repositories for sensitive data. Option B is wrong because Microsoft Sentinel is a Security Information and Event Management (SIEM) tool that monitors security logs and alerts, not a data classification service for scanning source code content in repositories. Option D is wrong because Microsoft Defender for Cloud focuses on cloud security posture management and workload protection, not on scanning source code for sensitive data classification like credit card numbers.

Full explanation →
49
MCQmedium

You applied the above branch policy to a GitHub repository. A developer tries to push a commit to the main branch that is signed with an S/MIME signature. What will happen?

A.The commit is rejected because S/MIME is not in the allowed signature types.
B.The commit is accepted because S/MIME is implicitly allowed.
C.The commit is accepted because it is signed.
D.The commit is rejected because the policy is in 'block' mode, which blocks all pushes.
AnswerA

Only GPG and SSH are allowed.

Why this answer

The branch policy in question is configured to allow only GPG or SSH signatures. S/MIME is not listed as an allowed signature type, so the commit is rejected. GitHub's branch protection rules enforce signature requirements based on the allowed signature types specified in the policy.

Exam trap

The trap here is that candidates may assume any signed commit is accepted, overlooking that GitHub's branch policy explicitly restricts which signature types are allowed, and S/MIME is not among them.

How to eliminate wrong answers

Option B is wrong because S/MIME is not implicitly allowed; only explicitly configured signature types (GPG or SSH) are permitted. Option C is wrong because the commit being signed does not guarantee acceptance; the signature type must match the allowed types in the policy. Option D is wrong because the 'block' mode does not block all pushes; it only blocks pushes that violate the specific policy rules, such as using an unapproved signature type.

Full explanation →
50
MCQmedium

A company deploys a .NET Core web application to Azure App Service. The application uses Application Insights for monitoring. The operations team reports that dependency tracking is missing for calls to a third-party REST API made using HttpClient. The application is instrumented with the Application Insights SDK. Which action should be taken to enable dependency tracking for HttpClient calls?

A.Ensure the SDK is configured using services.AddApplicationInsightsTelemetry(); in the Startup.cs file.
B.Install the Application Insights Agent on the App Service instance.
C.Add a reference to Microsoft.ApplicationInsights.DependencyCollector and call DependencyTrackingModule.Initialize().
D.Use the Application Insights Status Monitor to enable dependency tracking.
AnswerA

In ASP.NET Core, calling services.AddApplicationInsightsTelemetry() in the Startup.ConfigureServices method registers all Application Insights services with the built-in dependency injection container. This extension automatically initializes the DependencyTrackingModule, enabling outbound dependency calls (such as HttpClient) to be tracked without writing any additional initialization code, and it reads the instrumentation key or connection string from app settings.

Why this answer

`services.AddApplicationInsightsTelemetry()` in `Startup.cs` automatically registers the `DependencyTrackingModule` for .NET Core applications. This module collects dependency telemetry for `HttpClient` calls made via `IHttpClientFactory` or typed `HttpClient` instances, provided the SDK is properly configured. Since the application already uses the Application Insights SDK, this single line enables automatic dependency tracking without additional packages or agents.

Exam trap

The trap here is that candidates confuse the .NET Core SDK approach with legacy .NET Framework tools like Status Monitor or manual `DependencyTrackingModule.Initialize()`, assuming dependency tracking requires extra packages or agent installation, when in fact `AddApplicationInsightsTelemetry()` handles it automatically for .NET Core.

How to eliminate wrong answers

Option B is wrong because the Application Insights Agent (formerly Status Monitor v2) is designed for .NET Framework applications hosted on IIS or Azure VMs, not for .NET Core on App Service; .NET Core apps require SDK-based instrumentation. Option C is wrong because `DependencyTrackingModule.Initialize()` is a legacy approach for .NET Framework apps; in .NET Core, the module is automatically initialized by the SDK when `AddApplicationInsightsTelemetry()` is called, and adding a manual reference is unnecessary and may cause duplicate initialization. Option D is wrong because Status Monitor is a .NET Framework tool that cannot instrument .NET Core applications; Azure App Service for .NET Core relies on the SDK or the App Service 'Application Insights' blade settings, not Status Monitor.

Full explanation →
51
MCQmedium

A development team wants to ensure that all code changes are reviewed by at least two senior developers before merging into the main branch. They use Azure Repos. What should they configure?

A.Enable the build validation policy on the branch.
B.Set up a release pipeline with gated deployments.
C.Configure a branch policy requiring a minimum number of reviewers.
D.Add a status check policy using Azure Functions.
AnswerC

Branch policies in Azure Repos can enforce a minimum number of reviewers on pull requests, blocking completion until the required number of approved reviews is met; this directly ensures that every code change receives the mandated human review before merging.

Why this answer

Azure Repos branch policies allow you to enforce a minimum number of reviewers on pull requests. By setting the 'Minimum number of reviewers' policy to 2, the team ensures that at least two senior developers must approve any code change before it can be merged into the main branch. This directly meets the requirement without involving build validation, release pipelines, or external function calls.

Exam trap

The trap here is that candidates often confuse build validation policies (which ensure code compiles) with reviewer policies (which ensure human oversight), leading them to select option A instead of C.

How to eliminate wrong answers

Option A is wrong because enabling the build validation policy ensures that a build succeeds before merging, but it does not enforce any requirement for human code reviews or a minimum number of reviewers. Option B is wrong because a release pipeline with gated deployments controls when artifacts are deployed to environments, not when code is merged into a branch; it does not enforce pre-merge review requirements. Option D is wrong because a status check policy using Azure Functions can call external services to report a status, but it does not natively enforce a minimum number of reviewers; it would require custom logic and does not replace the built-in reviewer policy.

Full explanation →
52
MCQmedium

Your team uses GitHub Actions to build a Python application. The workflow includes a step to run unit tests with pytest. The tests pass locally but fail in CI with 'ModuleNotFoundError: No module named 'myapp''. The repository structure has the application code in a subdirectory 'src/'. What is the most likely fix?

A.Set the working directory of the test step to 'src/'.
B.Add a step to install dependencies with 'pip install -r requirements.txt'.
C.Set the environment variable PYTHONPATH to 'src/' before running tests.
D.Add a step to run 'pip install -e .' from the repository root.
AnswerC

Setting PYTHONPATH to 'src/' before running tests adds the 'src' directory to Python's module search path, allowing the test runner to import the local package modules directly. This is a standard and effective fix for a src-layout project where the package has not been installed, directly resolving the ModuleNotFoundError.

Why this answer

The Python interpreter cannot find the 'myapp' module when tests run in CI, even though the code is present in the 'src/' subdirectory. Setting PYTHONPATH to 'src/' tells Python to include that directory in the module search path, allowing 'import myapp' to resolve correctly without moving or copying files. This is the most direct fix for a missing module path issue in a CI environment where the working directory is not automatically set to the source folder.

Exam trap

The trap here is that candidates often confuse changing the working directory (Option A) with modifying the module search path, not realizing that Python's import resolution depends on sys.path, not the current working directory.

How to eliminate wrong answers

Option A is wrong because setting the working directory to 'src/' would only change where the test step runs, but it does not add 'src/' to Python's module search path; the tests would still fail if they import 'myapp' from a parent directory. Option B is wrong because installing dependencies with 'pip install -r requirements.txt' addresses missing third-party packages, not the inability to find the local 'myapp' module. Option D is wrong because 'pip install -e .' installs the package in editable mode from the repository root, but if the setup.py or pyproject.toml is not configured to include the 'src/' layout, it may not make 'myapp' importable; even if it did, it is an over-engineered solution compared to simply setting PYTHONPATH.

Full explanation →
53
MCQhard

You have the above branch policy configuration for the main branch. A developer pushes a new commit to an existing pull request. What happens?

A.The existing approvals are reset, but no new build is queued.
B.The pull request is automatically completed.
C.The existing approvals are reset, and a new build is automatically queued.
D.The existing approvals remain valid, and the build is not requeued.
AnswerC

This is correct because the branch policy has two relevant settings: 'Reset approvals on new push' is enabled, so existing approvals are invalidated when new commits are pushed, and the build validation policy has 'Queue new build on source update only' set to true, so a new build is automatically queued. Both actions occur as a direct result of the new push to the PR source branch.

Why this answer

The branch policy has 'Reset code review votes when new changes are pushed' enabled (resetOnSourcePush: true) and 'Build validation' with 'Automatically queue a new build when new changes are pushed' enabled (queueOnSourceUpdateOnly: true). When a new commit is pushed to an existing pull request, the existing approvals are reset, and a new build is automatically queued. Therefore, option C is correct.

Full explanation →
54
MCQmedium

Your team uses Azure Pipelines to build a .NET application. Recently, builds have been failing intermittently with NuGet restore errors. The pipeline uses a hosted agent. You need to ensure consistent package restoration. What should you do?

A.Use a self-hosted agent with persistent NuGet package caches.
B.Clear the NuGet cache in the pipeline using 'dotnet nuget locals all --clear' before restore.
C.Enable multi-stage Docker builds for the application.
D.Configure the pipeline to use the Dapr sidecar for package management.
AnswerA

Using a self-hosted agent with persistent NuGet package caches keeps the global-packages folder and HTTP cache across pipeline runs, so restore operations reuse already-downloaded packages instead of hitting external feeds every time. This reduces dependency on feed availability and network reliability, making builds faster and less prone to transient outages.

Why this answer

Using a self-hosted agent with persistent NuGet package caches ensures that packages are not re-downloaded on each build, avoiding intermittent network failures. Option B would clear the cache and force re-download, worsening the issue. Option C is for Docker builds, not NuGet.

Option D is unrelated to package restoration.

Full explanation →
55
MCQhard

You have a YAML pipeline that uses a multi-stage build. You want to cache the restored NuGet packages across builds to improve performance. Which caching strategy should you use?

A.Use the Cache@2 task with key: 'nuget | "$(Agent.OS)" | packages.lock.json', path: '$(System.DefaultWorkingDirectory)/packages'
B.Use the NuGetCommand@2 task with the -Cache argument.
C.Set the NUGET_PACKAGES environment variable to a custom path and rely on pipeline caching plugin.
D.Use the DotNetCoreCLI@2 task with the --no-restore flag and manually copy packages.
AnswerA

The Cache@2 task is the correct built-in mechanism for caching NuGet packages in Azure Pipelines. The composite key, combining 'nuget', the agent OS, and packages.lock.json, invalidates the cache only when the OS or the lock file changes, ensuring restore artifacts are reused across runs. The path points to the packages folder (typically the global packages folder) so subsequent restore operations can use the cached packages without hitting the network.

Why this answer

The Cache@2 task is the recommended way to cache NuGet packages in Azure Pipelines. By using a cache key that includes the agent OS and the packages.lock.json file, the cache is invalidated only when the lock file changes, ensuring restored packages are reused across builds. The path points to the NuGet global packages folder, which is typically $(System.DefaultWorkingDirectory)/packages when NUGET_PACKAGES is set.

Exam trap

The trap here is that candidates may confuse the Cache@2 task's explicit key-path pairing with other NuGet-specific arguments or environment variables, assuming a simpler flag exists, when in fact Azure DevOps requires the Cache@2 task for reliable cross-build caching.

Why the other options are wrong

B

NuGetCommand does not have a -Cache argument for cross-build caching.

C

The environment variable is useful but caching must be explicitly configured.

D

--no-restore skips restore, not caching.

Full explanation →
56
MCQhard

You are reviewing an Azure Policy assignment in a DevOps environment. The exhibit shows the policy assignment JSON. The policy set includes the built-in policy 'Allowed Locations' with effect Deny. During a pipeline deployment, a resource creation fails with a policy violation error. The resource being deployed is a storage account in the 'centralus' region. What is the most likely reason for the failure?

A.The policy assignment is misconfigured because it does not specify a policy set definition.
B.The resource being deployed is in a region that is not allowed by the policy assignment parameters.
C.The resource group is located in a region that overrides the policy assignment.
D.The policy set definition does not include the 'Allowed Locations' policy.
AnswerB

The allowedLocations parameter in the policy assignment restricts permissible deployment regions to eastus and westus only. Since the resource being deployed is in centralus, which is not included in those parameters, the 'Allowed Locations' policy denies the deployment as non-compliant.

Why this answer

The policy assignment includes the built-in 'Allowed Locations' policy with the Deny effect. The resource being deployed (a storage account) is in the 'centralus' region, but the policy assignment parameters likely specify a list of allowed regions that does not include 'centralus'. Since the Deny effect prevents any non-compliant resource creation, the deployment fails with a policy violation error.

This is the most direct and common cause of such failures in Azure Policy.

Exam trap

The trap here is that candidates may assume the resource group's location influences policy evaluation, but Azure Policy evaluates each resource's location independently, and the resource group's location is irrelevant unless explicitly referenced in the policy rule.

How to eliminate wrong answers

Option A is wrong because the exhibit shows the policy assignment JSON includes a 'policySetDefinitionId' field, so the assignment is correctly linked to a policy set definition. Option C is wrong because the resource group's location does not override a policy assignment; Azure Policy evaluates resources individually based on the policy rules, not the resource group's location. Option D is wrong because the policy set definition explicitly includes the 'Allowed Locations' policy, as shown in the exhibit's 'policyDefinitions' array.

Full explanation →
57
MCQeasy

Your organization uses Azure DevOps and has a project with multiple teams. The 'AlphaTeam' wants a branch policy on their feature branch 'feature/alpha' that requires a successful build from the CI pipeline and approval from at least one member of 'AlphaTeam'. However, the 'BetaTeam' should be able to push directly to 'feature/alpha' without a pull request. You need to configure the branch policy accordingly. What should you do?

A.Create a new repository for AlphaTeam and apply the policy there.
B.Set a branch policy at the repository level that applies to all branches, then grant BetaTeam bypass permission.
C.Configure the branch policy on 'feature/alpha' to require build and approval, and set 'Allow direct pushes' to 'Everyone'.
D.Configure the branch policy on 'feature/alpha' to require build and approval from AlphaTeam, and set 'Allow direct pushes' to 'Selected users' and add BetaTeam.
AnswerD

Configuring the 'feature/alpha' branch policy to require build and approval from AlphaTeam while setting 'Allow direct pushes' to 'Selected users' and adding BetaTeam grants BetaTeam a scoped bypass only for direct pushes to that specific branch. AlphaTeam and other non-selected users still must submit a pull request and satisfy the build and approval requirements. This balances the need for BetaTeam to push directly with the need to keep the feature branch protected, and it does not affect any other branches.

Why this answer

Azure DevOps branch policies allow you to configure 'Allow direct pushes' to specific users or groups while still enforcing PR requirements for others. By setting the policy on 'feature/alpha' to require a successful build and approval from at least one AlphaTeam member, and then selecting 'Selected users' for direct pushes with BetaTeam added, BetaTeam can push directly without a PR, while AlphaTeam must follow the PR policy.

Exam trap

The trap here is that candidates often confuse 'Allow direct pushes' with a global bypass permission, not realizing it can be scoped to specific users while still enforcing policies for others.

How to eliminate wrong answers

Option A is wrong because creating a separate repository is unnecessary and does not solve the requirement for a single repository with differentiated access; it would also break the existing project structure. Option B is wrong because setting a branch policy at the repository level applies to all branches, which would force PRs on BetaTeam's branches as well, and granting bypass permission would remove all policy enforcement, including the build requirement. Option C is wrong because setting 'Allow direct pushes' to 'Everyone' would allow anyone, including AlphaTeam, to bypass the PR requirement, which contradicts the need for AlphaTeam to use pull requests.

Full explanation →
58
MCQmedium

You have a multi-stage YAML pipeline that deploys to a Linux-based Azure App Service. The pipeline uses a 'Deploy to Azure App Service' task. You need to ensure that the deployment uses the Kudu REST API with ZIP deployment. Which value should you set for the 'packageForLinux' task input?

A.Set 'enableCustomDeployment' to true
B.Set 'packageForLinux' to true
C.Set 'useWebDeploy' to false
D.Set 'enableKuduDeploy' to true
AnswerB

Why this answer

The 'packageForLinux' input must be set to 'true' to force the 'Deploy to Azure App Service' task to use the Kudu REST API with ZIP deployment when targeting a Linux-based Azure App Service. This is required because Linux App Services do not support WebDeploy (MSDeploy) and rely on the Kudu endpoint for ZIP-based deployments.

Exam trap

The trap here is that candidates confuse the 'packageForLinux' input with a generic 'enableKudu' switch, not realizing that Kudu is the underlying mechanism for ZIP deployment on Linux and that this specific input is required to activate it.

Why the other options are wrong

A

This enables custom deployment scripts, not specifically ZIP deployment via Kudu for Linux.

C

This disables Web Deploy, but does not enable ZIP deployment for Linux.

D

There is no such input 'enableKuduDeploy' in the Azure Web App task.

Full explanation →
59
MCQhard

You are the Azure DevOps administrator for a large enterprise with multiple projects using the Scrum process. The organization has recently adopted a new compliance policy requiring that all work items of type 'Epic' must be approved by a compliance officer before they can be moved to the 'Committed' state. The compliance officers are external to the development teams and should not have direct access to modify work items. You need to implement this requirement with minimal administrative overhead. The current process has the following states for Epics: New, Proposed, Committed, In Progress, Done. The desired flow is: from 'Proposed' to 'Committed', a compliance officer must approve the transition. Compliance officers are part of a security group named 'Compliance Officers'. They should be able to approve the transition without having to edit the work item directly. What should you do?

A.In the process template for Epic, add a work item rule on the transition from 'Proposed' to 'Committed' that requires approval from a member of the 'Compliance Officers' group.
B.Use a service hook to send an email to the compliance officers when an Epic is moved to 'Proposed', and rely on them to manually approve the transition.
C.Modify the Epic work item type to add a field 'Compliance Approval' and set the compliance officer as a required reviewer in the field settings.
D.Configure a branch policy on the main branch that requires approval from the 'Compliance Officers' group for pull requests.
AnswerA

This is the correct solution because Azure DevOps process template rules for work item types can enforce approvals on specific state transitions. Adding a rule to the Epic workflow that requires approval from the 'Compliance Officers' group when moving from 'Proposed' to 'Committed' ensures the transition cannot be completed without that group's authorization, directly enforcing the compliance gate at the work item level.

Why this answer

Azure DevOps process templates allow you to add work item rules on state transitions. By adding a rule on the 'Proposed' to 'Committed' transition for the Epic work item type that requires approval from a member of the 'Compliance Officers' group, you enforce the compliance policy without granting those officers direct edit permissions. This leverages built-in approval gates within the work item tracking system, minimizing administrative overhead.

Exam trap

The trap here is that candidates may confuse work item rules with branch policies or service hooks, mistakenly thinking that notification-based or code-review mechanisms can enforce work item state transitions.

How to eliminate wrong answers

Option B is wrong because a service hook only sends a notification; it does not enforce an approval gate or prevent the transition from occurring without approval, so the compliance policy would not be technically enforced. Option C is wrong because adding a custom field and setting a required reviewer does not create an approval workflow on the state transition; it merely adds a field that can be filled without blocking the transition, and compliance officers would still need direct edit access to modify the field. Option D is wrong because branch policies apply to pull requests on code repositories, not to work item state transitions, and are unrelated to the Scrum process or Epic work items.

Full explanation →
60
MCQhard

Your organization uses GitHub Enterprise and wants to enforce that all repositories have a specific issue template. What is the most scalable way to achieve this?

A.Create a global issue template in the organization settings.
B.Use a script to periodically check and add templates.
C.Create a repository template and require all new repos to use it.
D.Configure a CODEOWNERS file in each repository.
AnswerA

Global templates apply to all repositories.

Why this answer

GitHub Enterprise allows organization owners to create a global issue template by placing a `.github/ISSUE_TEMPLATE/` directory in the `.github` repository. This template is automatically applied to all repositories within the organization, ensuring consistency without manual intervention per repo. This is the most scalable approach as it centralizes enforcement at the organization level.

Exam trap

The trap here is that candidates often confuse repository templates (which only affect new repos) with organization-level templates (which apply globally), leading them to choose option C as a scalable solution.

How to eliminate wrong answers

Option B is wrong because using a script to periodically check and add templates is reactive, not proactive; it introduces latency, potential race conditions, and administrative overhead, and does not enforce the template at creation time. Option C is wrong because a repository template only applies to new repositories created from that template; existing repositories and those created without the template would not have the issue template, so it is not a scalable enforcement mechanism. Option D is wrong because a CODEOWNERS file is used to define individuals or teams responsible for code reviews, not to enforce issue templates; it has no mechanism to require or apply issue templates.

Full explanation →
61
MCQmedium

Your team uses GitHub for source control and GitHub Actions for CI/CD. Security policy requires that all code changes must be signed by a verified contributor using a GPG key. You need to enforce this requirement at the organization level. However, some developers use SSH keys for authentication, and you want to allow them to continue. What should you do?

A.In GitHub organization settings, enable 'Require signed commits' and 'Require SSH keys for authentication'.
B.Enforce S/MIME signing via Microsoft Entra ID Conditional Access.
C.Add a branch protection rule for the default branch requiring signed commits.
D.Configure a GitHub Action that rejects unsigned commits in CI.
AnswerC

A branch protection rule on the default branch can require signed commits, enforcing that all commits pushed to that branch must be signed with a verified GPG key. This is a common and effective way to enforce the policy.

Why this answer

Adding a branch protection rule for the default branch that requires signed commits enforces that all commits to that branch must be signed with a verified GPG key. While this does not apply to the entire organization, it is the standard method to enforce signing on the most critical branch. Option A is incorrect because GitHub does not have an organization setting to 'Require SSH keys for authentication'; the setting mentioned is not valid.

Option B is incorrect because S/MIME signing via Microsoft Entra ID is not a native GitHub enforcement for commits. Option D is incorrect because a GitHub Action would only reject unsigned commits after they are pushed, not prevent them from being pushed.

Exam trap

The trap is that option A sounds plausible because it mentions both signed commits and SSH keys, but GitHub does not have a setting to 'require' SSH keys. The actual enforcement for signed commits is through the organization's 'Require signed commits' setting, which does not involve SSH key requirements.

Full explanation →
62
MCQeasy

You are designing a release pipeline for a mission-critical application. The pipeline must deploy to multiple environments (dev, test, prod) in sequence, with manual approval required before production deployment. Which Azure Pipelines feature should you use?

A.Pre-deployment approvals
B.Variable groups
C.Pipeline triggers
D.Deployment gates
AnswerA

Pre-deployment approvals define mandatory manual sign-off by designated approvers before a release is deployed to a stage. They act as a compliance checkpoint in the release pipeline and are distinct from automated gates, ensuring human oversight for mission-critical environments.

Why this answer

Pre-deployment approvals are the correct feature because they allow you to require manual sign-off before a release proceeds to a specific stage. In this scenario, you need a manual approval gate before production deployment, which is exactly what pre-deployment approvals enforce—the release pauses at the production stage until an authorized user approves it.

Exam trap

The trap here is that candidates often confuse pre-deployment approvals with deployment gates, thinking both are manual checks, but deployment gates are automated and based on external signals, not human approval.

How to eliminate wrong answers

Option B is wrong because variable groups store configuration values (like connection strings or secrets) and do not provide any approval or gating mechanism for deployment stages. Option C is wrong because pipeline triggers control when a pipeline starts (e.g., on code commit or schedule), not manual approval gates within a release. Option D is wrong because deployment gates are automated health checks (e.g., monitoring metrics or incident status) that evaluate conditions continuously, not manual approval steps requiring human intervention.

Full explanation →
63
MCQhard

Your team uses a monorepo in Azure Repos with multiple projects. You want to trigger a pipeline only when changes are made to a specific subfolder. Which configuration should you use?

A.Use a branch filter in the CI trigger.
B.Add a 'paths' filter to the CI trigger.
C.Configure the checkout step to only include the subfolder.
D.Use a 'file_match' condition on the job.
AnswerB

Paths filter triggers the pipeline only when files in the specified path change.

Why this answer

Azure Pipelines CI triggers support a 'paths' filter that allows you to specify include or exclude patterns for file changes. When a monorepo contains multiple projects in separate subfolders, adding a 'paths' filter to the CI trigger ensures the pipeline only runs when changes are detected within that specific subfolder, avoiding unnecessary builds for unrelated projects.

Exam trap

The trap here is that candidates confuse the checkout step's sparse checkout or path filtering with trigger-level path filtering, mistakenly believing that limiting what is downloaded also prevents the pipeline from being triggered by changes outside that path.

How to eliminate wrong answers

Option A is wrong because a branch filter in the CI trigger controls which branches trigger the pipeline, not which file paths within the repository; it cannot restrict triggers to a specific subfolder. Option C is wrong because configuring the checkout step to only include the subfolder limits what files are downloaded to the agent, but it does not prevent the pipeline from being triggered by changes outside that subfolder; the trigger still fires on any change in the repo. Option D is wrong because Azure Pipelines does not support a 'file_match' condition on a job; path-based triggering is configured at the pipeline trigger level, not as a job condition.

Full explanation →
64
MCQeasy

Your build pipeline uses a hosted agent. You notice that every build starts with a clean workspace, increasing build time. You want to improve performance by caching the Node.js 'node_modules' folder. Which task should you add to the pipeline?

A.Publish Build Artifacts task
B.Copy Files task
C.Download Build Artifacts task
D.Cache task
AnswerD

The Cache task is designed exactly for this: it captures a specified folder after a run and restores it on subsequent runs using a defined key (typically a hash of package manifests) and cache hit variables. When the key matches, it avoids expensive re-downloads or recompilation, making it the correct way to persist dependency caches on hosted agents. Its whole purpose is cross-run reuse, unlike tasks that publish, copy, or download artifacts.

Why this answer

The Cache task (option D) is correct because it allows you to cache the 'node_modules' folder between pipeline runs on hosted agents, avoiding the need to reinstall dependencies from scratch each time. By specifying a cache key (e.g., based on package-lock.json) and the path to cache, subsequent builds can restore the folder from cache, significantly reducing build time.

Exam trap

The trap here is that candidates confuse the Cache task with artifact tasks (Publish/Download Build Artifacts), assuming artifacts can be used for caching, but artifacts are designed for immutable output storage and lack the key-based restoration and automatic eviction that the Cache task provides for performance optimization.

How to eliminate wrong answers

Option A is wrong because the Publish Build Artifacts task is used to store build outputs (e.g., compiled binaries) for later use or release, not for caching intermediate folders like node_modules across builds. Option B is wrong because the Copy Files task simply copies files from source to destination within the workspace, but does not persist them across pipeline runs or provide caching functionality. Option C is wrong because the Download Build Artifacts task retrieves previously published artifacts, but artifacts are immutable and not designed for the incremental, key-based caching of node_modules that the Cache task provides.

Full explanation →
65
MCQhard

Refer to the exhibit. You are deploying this ARM template using Azure Pipelines. The pipeline passes the parameter 'environmentName' with value 'prod'. What will be the name of the virtual network?

A.vnet-default
B.vnet-prod
C.vnet-prod-vnet
D.vnet-dev
AnswerB

The ARM template variable expression uses string concatenation to join the prefix 'vnet-' with the value of the environment parameter. Because the parameter is set to (or defaults to) 'prod', the variable correctly resolves to 'vnet-prod', which is the intended name for the virtual network.

Why this answer

The ARM template uses the `concat` function to combine the string 'vnet-' with the value of the `environmentName` parameter. Since the pipeline passes 'prod' for `environmentName`, the resulting virtual network name is 'vnet-prod'. This is a standard pattern for parameterizing resource names in Azure Resource Manager templates.

Exam trap

The trap here is that candidates may assume the parameter's default value ('dev') is used instead of recognizing that the pipeline explicitly overrides it with 'prod', leading them to incorrectly select 'vnet-dev'.

How to eliminate wrong answers

Option A is wrong because 'vnet-default' would only be the result if the `environmentName` parameter had a default value of 'default' and no override was provided, but the pipeline explicitly passes 'prod'. Option C is wrong because 'vnet-prod-vnet' would require an additional concatenation or a different expression, such as `concat('vnet-', parameters('environmentName'), '-vnet')`, which is not present in the template. Option D is wrong because 'vnet-dev' would only be produced if the parameter value were 'dev', but the pipeline passes 'prod'.

Full explanation →
66
MCQmedium

A team uses Azure Pipelines to build a .NET application. The build takes 30 minutes, and developers complain that the pipeline runs slowly. The pipeline uses the 'windows-latest' agent and installs the .NET SDK in each run. Which action would MOST reduce the build time?

A.Enable pipeline caching for the .NET SDK.
B.Deploy a self-hosted agent in Azure.
C.Increase the number of parallel jobs.
D.Change the agent pool to 'ubuntu-latest'.
AnswerA

Enabling pipeline caching for the .NET SDK stores the downloaded SDK and NuGet packages in a shared cache, so subsequent pipeline runs can reuse them instead of re-downloading and re-extracting the SDK from the network. This directly reduces the repetitive setup time that dominates the pipeline's build time, especially when the project specifies a pinned SDK version.

Why this answer

Enabling pipeline caching for the .NET SDK allows the SDK to be restored from a cache instead of being downloaded and installed on every run. This eliminates the recurring overhead of SDK installation, which is a significant portion of the 30-minute build time, directly addressing the slow pipeline complaint.

Exam trap

The trap here is that candidates often confuse reducing build time with scaling resources (parallel jobs or self-hosted agents) instead of recognizing that eliminating redundant work (SDK installation) via caching directly shortens the pipeline duration.

How to eliminate wrong answers

Option B is wrong because deploying a self-hosted agent does not reduce the time spent installing the .NET SDK; it only removes agent provisioning delays, and the SDK must still be installed each run unless caching is also used. Option C is wrong because increasing parallel jobs speeds up concurrent builds but does not reduce the duration of a single build pipeline. Option D is wrong because changing to 'ubuntu-latest' would require a different .NET SDK installation and may introduce compatibility issues, but the SDK still needs to be installed each run without caching, so build time would not be significantly reduced.

Full explanation →
67
Multi-Selectmedium

Which TWO conditions must be met for a self-hosted agent to be used in an Azure Pipelines agent pool? (Choose two.)

Select 2 answers
A.The agent must be in the Default pool.
B.The agent must have network access to Azure Pipelines.
C.The agent must run on Windows Server.
D.The agent must be installed on a virtual machine.
E.The agent must be registered with the agent pool.
AnswersB, E

A self-hosted agent must have outbound network connectivity to the Azure Pipelines service over HTTPS. This connection is required to poll for queued jobs, download task definitions and source code, and report execution status back to the service; without it the agent cannot participate in pipelines.

Why this answer

A self-hosted agent must have outbound network connectivity to Azure Pipelines (specifically to the Azure DevOps service endpoints) in order to receive job assignments, download tasks, and report status. Without this network access, the agent cannot communicate with the orchestration layer and will remain offline. This is a fundamental requirement for any agent, whether hosted or self-hosted.

Exam trap

The trap here is that candidates often assume self-hosted agents must be in the Default pool or run on a specific OS, but Azure Pipelines allows any pool and any supported OS (Windows, Linux, macOS) as long as the agent is registered and has network access.

Full explanation →
68
MCQhard

Your organization uses GitHub Actions for CI/CD. You need to implement a deployment strategy where a new version of the application is gradually shifted from the stable environment to a canary environment, and if health checks pass, the traffic is fully shifted to the canary. Which GitHub Actions deployment strategy should you use?

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

Canary deployment is correct because it gradually shifts traffic to the new version, starting with a small percentage, and promotes it only if health checks and key metrics pass. If the health checks fail partway through, the rollout can be halted or rolled back, and only the small canary slice of users has been exposed to the problematic version. This satisfies the requirement for a gradual, safer release with a limited blast radius and controlled promotion.

Why this answer

A canary deployment gradually shifts traffic from the stable environment to a new canary environment, using health checks to validate the new version before fully routing all traffic to it. This matches the requirement of a gradual shift with health-check gating. GitHub Actions supports this via deployment strategies like `canary` in environments or custom workflows with traffic-splitting tools.

Exam trap

The trap here is that candidates confuse canary deployment with blue-green deployment, assuming both involve a full cutover, but canary specifically requires gradual traffic shifting with health-check validation before full promotion.

How to eliminate wrong answers

Option A is wrong because a recreate deployment tears down the existing environment and deploys the new version all at once, with no gradual traffic shift or canary phase. Option C is wrong because a blue-green deployment swaps all traffic from the stable (blue) environment to the new (green) environment in one cutover, not gradually shifting traffic to a canary. Option D is wrong because a rolling deployment updates instances incrementally but does not typically use a separate canary environment with health-check gating before full traffic shift.

Full explanation →
69
MCQmedium

A team is migrating from TFVC to Git in Azure Repos. They have a large repository with a history of 10,000+ commits. They want to preserve the full history while minimizing migration time. Which approach should they recommend?

A.Use git-tfs to clone the TFVC repository with full history, then push to Azure Repos.
B.Check out the latest version from TFVC, initialize a new Git repo, and push.
C.Use the Azure Repos import repository feature to import from TFVC.
D.Clone the TFVC repository using Git and push to Azure Repos.
AnswerA

git-tfs is a tool that bridges TFVC and Git, allowing you to clone a TFVC repository including all changesets, branches, and history, converting them into Git commits. After cloning, you push the local Git repository to Azure Repos as a new Git repository, preserving the full migration history. This is the recommended approach when you need to retain historical context.

Why this answer

Git-tfs is a specialized bridge tool that can clone a TFVC repository with full history into a local Git repository, preserving all commits, branches, and metadata. This approach minimizes migration time by performing the conversion locally without network overhead, after which the Git repo can be pushed to Azure Repos. Other methods either lose history or are not supported for TFVC-to-Git migration.

Exam trap

The trap here is that candidates may assume Azure Repos has a built-in TFVC import feature (Option C) or that Git can natively clone TFVC (Option D), when in fact only git-tfs or similar third-party tools can perform a full-history migration from TFVC to Git.

How to eliminate wrong answers

Option B is wrong because checking out only the latest version from TFVC and initializing a new Git repo discards all historical commits, which violates the requirement to preserve full history. Option C is wrong because the Azure Repos import repository feature only supports importing from external Git repositories (e.g., GitHub, Bitbucket), not from TFVC. Option D is wrong because Git cannot directly clone a TFVC repository; TFVC uses a different version control protocol and data model, so a standard Git clone operation will fail.

Full explanation →
70
MCQmedium

You have a multi-stage YAML pipeline that builds and deploys a Java application. The pipeline runs on a Microsoft-hosted agent. The build stage fails intermittently with 'OutOfMemoryError: Java heap space'. What should you do to resolve this issue?

A.Set the environment variable 'MAVEN_OPTS' to '-Xmx2048m'.
B.Use a self-hosted agent with more memory.
C.Set the environment variable 'GRADLE_OPTS' to '-Xmx2048m'.
D.Use the 'Maven@3' task with the 'jdkVersion' option set to 'jdk11'.
AnswerA

Setting MAVEN_OPTS to -Xmx2048m explicitly sets the maximum JVM heap size for the Maven process, ensuring the build has 2GB of heap available and directly addressing the OutOfMemoryError during compilation or tests. This is the standard environment variable for passing JVM arguments to Maven, and -Xmx is the primary switch to increase heap space.

Why this answer

The 'OutOfMemoryError: Java heap space' in a Maven build indicates that the JVM running Maven needs more heap memory. Setting the environment variable 'MAVEN_OPTS' to '-Xmx2048m' increases the maximum heap size for the Maven JVM process to 2048 MB, which resolves the memory issue. This is the standard and correct approach for Maven-based builds.

Exam trap

The trap here is that candidates may confuse 'MAVEN_OPTS' with 'GRADLE_OPTS' or think that increasing agent memory (Option B) will automatically increase JVM heap, but the JVM heap is independent of physical memory and must be explicitly configured.

How to eliminate wrong answers

Option B is wrong because using a self-hosted agent with more memory does not directly address the JVM heap limit; the error is caused by insufficient heap allocated to the Maven process, not the agent's physical memory. Option C is wrong because 'GRADLE_OPTS' is used for Gradle builds, not Maven; setting it would have no effect on a Maven pipeline. Option D is wrong because changing the JDK version with the 'jdkVersion' option does not affect JVM heap settings; it only selects the Java Development Kit version for compilation.

Full explanation →
71
MCQmedium

You are implementing a release pipeline for a web application deployed to multiple Azure App Service instances across different regions (West US, East US, and North Europe). The deployment must follow a phased rollout: first West US, then East US, then North Europe, with a manual approval gate between each region. Each region should have its own slot for staging and production. You need to design the pipeline to minimize duplication of stages and tasks. What should you do?

A.Use a multi-stage YAML pipeline with environment per region and a manual approval on each environment.
B.Create three separate stages (one per region) and duplicate the deployment tasks in each.
C.Use a single stage with parallel deployment to all regions and add manual approvals before each region's deployment.
D.Use a single stage with a deployment group job that targets agents tagged with region names, and use deployment group tags to control phased rollout.
AnswerA

While this approach provides a manual approval gate per region via separate environments, it still requires the pipeline author to define and manage duplicate environment objects and job logic for each region, significantly increasing YAML complexity and maintenance burden compared to a single reusable job that targets tagged deployment group agents.

Why this answer

For a phased rollout to multiple Azure App Service regions, you should create an environment per region and use a multi-stage YAML pipeline that contains deployment jobs (or stages) targeting those environments. Manual approval gates can be configured on each environment, enabling controlled progression from West US to East US to North Europe without duplicating tasks. This approach directly uses App Service slots and environments.

Deployment group jobs (Option D) are intended for targeting on-premises or VM-based agents, not App Service instances, and do not support slots. Options B and C are incorrect because they duplicate tasks or deploy in parallel rather than in the required phased sequence.

Exam trap

The trap is assuming deployment groups are the universal solution for multi-target deployment. For Azure App Service, deployment groups are not appropriate; you must use environments and deployment jobs targeting App Service resources.

Full explanation →
72
MCQhard

Your team uses Azure DevOps to deploy a Node.js web app to Azure App Service on Linux. The build pipeline runs `npm install` and `npm run build`, then publishes the `dist` folder. The release pipeline uses the 'Azure App Service deploy' task. Recently, deployments fail intermittently with 'ERR_MODULE_NOT_FOUND' for a custom module. The module is listed in `package.json` and is present in the `node_modules` folder on the build agent. What is the most likely cause?

A.The 'Azure App Service deploy' task modifies package.json during deployment.
B.The 'Azure App Service deploy' task runs npm install on the target, but it fails due to network restrictions.
C.The build artifact does not include node_modules; the app requires them at runtime.
D.The deployment slot's Kudu service fails to sync the dist folder.
AnswerC

The build artifact contains only the dist folder because the pipeline's publish step excluded node_modules, yet the Node.js app needs those dependencies at runtime to load modules. Without node_modules in the artifact, the deployed app cannot find required packages and fails to start, regardless of how the App Service deploy task behaves.

Why this answer

The most likely cause is that the build artifact does not include the `node_modules` folder. The build pipeline runs `npm install` and `npm run build`, which installs dependencies on the build agent, but only the `dist` folder is published as the artifact. At deployment time, the Azure App Service on Linux expects the `node_modules` folder to be present in the deployed artifact because it does not automatically run `npm install` for Node.js apps on Linux (unlike Windows-based App Services).

Without `node_modules`, the app cannot resolve custom modules at runtime, leading to the `ERR_MODULE_NOT_FOUND` error.

Exam trap

The trap here is that candidates often assume the Azure App Service deploy task automatically runs `npm install` on the target (like it does on Windows), but on Linux, the default behavior is to deploy the artifact as-is without dependency restoration unless explicitly configured.

How to eliminate wrong answers

Option A is wrong because the 'Azure App Service deploy' task does not modify `package.json` during deployment; it simply transfers the artifact to the target App Service. Option B is wrong because the 'Azure App Service deploy' task does not run `npm install` on the target for Linux App Service; it relies on the artifact containing all necessary dependencies. Option D is wrong because the Kudu service (which is a Windows-based deployment engine) is not used for Azure App Service on Linux; Linux App Service uses Oryx or direct artifact deployment, and the error is not related to sync failures of the `dist` folder.

Full explanation →
73
MCQeasy

You need to integrate security scanning into your build pipeline to detect vulnerable open-source dependencies. Which Azure DevOps extension should you use?

A.WhiteSource Bolt
B.Azure Policy
C.GitHub Advanced Security
D.SonarQube
AnswerA

WhiteSource Bolt is a build-task extension in Azure DevOps that scans open-source components from package managers like npm, NuGet, and Maven against the Whitesource vulnerability database, failing the pipeline on known CVEs and generating an inline report. It fits the requirement directly because it performs security scanning during the build, whereas other options either do not target open-source dependencies or are not integrated into Azure Pipelines.

Why this answer

WhiteSource Bolt is a free Azure DevOps extension that integrates directly into build pipelines to automatically scan open-source dependencies for known vulnerabilities. It identifies vulnerable components, provides remediation guidance, and enforces security policies without requiring additional configuration or external tools, making it the correct choice for this scenario.

Exam trap

The trap here is that candidates may confuse Azure Policy (a governance tool) or SonarQube (a code quality tool) with a dedicated dependency vulnerability scanner, overlooking that WhiteSource Bolt is purpose-built for open-source security scanning in Azure Pipelines.

How to eliminate wrong answers

Option B is wrong because Azure Policy is a governance tool for enforcing compliance rules on Azure resources (e.g., tagging, location restrictions), not a dependency scanner for open-source libraries in a build pipeline. Option C is wrong because GitHub Advanced Security is a suite of security features for GitHub repositories (including code scanning and secret scanning), but it is not an Azure DevOps extension and does not integrate directly into Azure Pipelines for dependency scanning. Option D is wrong because SonarQube is a code quality and static analysis tool that focuses on code smells, bugs, and technical debt, not specifically on detecting vulnerable open-source dependencies; it requires additional plugins or configurations to perform dependency scanning.

Full explanation →
74
MCQhard

Your organization uses GitHub Enterprise and wants to enforce that all repositories have a consistent CODEOWNERS file. Which approach should you use to centrally manage this?

A.Use repository rulesets to require that the CODEOWNERS file exists and has a specified pattern
B.Create a CODEOWNERS file at the organization level
C.Use a script to push CODEOWNERS to each repo manually
D.Create a GitHub Actions workflow that runs on push to check CODEOWNERS
AnswerB

CODEOWNERS is repository-specific; GitHub does not support an organization-level CODEOWNERS file that applies across repositories. Placing it at the organization level would have no effect on individual repository's code review ownership, so each repo must still contain its own file.

Why this answer

In GitHub Enterprise, you can create a special repository named `.github` at the organization level. A CODEOWNERS file stored in that repository is applied as a default to all repositories in the organization, providing centralized management. Repository rulesets cannot require that a file exists; they enforce branch/tag rules such as required reviews and status checks, but not file existence.

Exam trap

The trap is that candidates assume organization-level CODEOWNERS does not exist, or believe rulesets can enforce file existence. In reality, a .github repository with a CODEOWNERS file serves as the organization-wide default, while rulesets are not designed for this.

How to eliminate wrong answers

Option B is wrong because GitHub does not support a single organization-level CODEOWNERS file; CODEOWNERS must be defined per repository within a .github/ or root directory. Option C is wrong because manually pushing CODEOWNERS to each repo via a script is error-prone, lacks centralized enforcement, and does not prevent future non-compliance. Option D is wrong because a GitHub Actions workflow that runs on push to check CODEOWNERS only detects violations after the fact, rather than preventing non-compliant pushes or enforcing the file's existence proactively.

Full explanation →
75
Multi-Selectmedium

Which TWO actions should you take to ensure that your Git repository in Azure Repos remains performant as it grows?

Select 2 answers
A.Use shallow clones in CI/CD pipelines.
B.Store large binary files directly in the repository.
C.Use Git LFS for large binary files.
D.Keep all branches indefinitely to preserve history.
E.Encourage developers to commit all changes in a single commit per day.
AnswersA, C

Use `git clone --depth 1` or shallow fetch in CI/CD pipelines to retrieve only the most recent commit(s), drastically reducing clone time and disk usage since full history is rarely needed for build and test operations.

Why this answer

Shallow clones fetch only the most recent commit history rather than the entire repository history, which significantly reduces the amount of data transferred and stored during CI/CD pipeline runs. This keeps pipeline execution fast and avoids performance degradation as the repository grows. Azure Repos and Azure Pipelines support shallow clone options via the `--depth` parameter in Git commands or through pipeline YAML settings.

Exam trap

The trap here is that candidates may think storing binaries directly in the repo is acceptable for performance, or that reducing commit frequency improves performance, when in fact these actions degrade performance or violate source control best practices.

Full explanation →

Page 1 of 11

Page 2

All pages

1234567891011

Practice AZ-400 by domain

Target a specific domain to shore up weak areas.

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