Courseiva

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

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

Take a mock examExam hub

Page 1 of 13

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

Secret scanning detects secrets like connection strings in code.

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 enforces peer review before merge.

Why this answer

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

Manual echo or printing of secret values can bypass masking if not handled correctly.

Why this answer

Option D is correct because GitHub Actions automatically masks secrets in logs, but if a secret is explicitly printed or used in a way that bypasses masking (e.g., using echo with variable substitution), it may appear. Option A is wrong because the log level does not affect masking. Option B is wrong because secret names are not masked, only values.

Option C is wrong because the trigger does not affect logging.

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

This prevents Copilot from using your code for training.

Why this answer

Option B is correct because GitHub Copilot allows you to opt out of code snippet sharing for training. Option A is wrong because Copilot is not a feature that can be disabled for specific repositories only. Option C is wrong because Dependabot does not affect Copilot training.

Option D is wrong because secret scanning is unrelated.

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

A conditional stage on failure can automate rollback.

Why this answer

Option D is correct because a conditional stage that runs on failure can execute a rollback deployment. Option A is wrong because retrying the same deployment does not roll back. Option B is wrong because manual intervention is not automatic.

Option C is wrong because approval gates prevent deployment but do not roll back after failure.

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

This helps assess risk and determine if any are malicious.

Why this answer

Option A is correct because the first step is to review the service connections and their permissions to understand the impact. Option B is wrong because deleting all connections created by that user could break running pipelines. Option C is wrong because disabling the user might be premature without investigation.

Option D is wrong because the query already shows the creator.

Full explanation →
7
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 2 answers
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, D

Why this answer

Option A is correct because a NuGet.config file explicitly defines the package sources (both the Azure Artifacts feed and the public NuGet gallery) that the restore task will query. By referencing this file in the restore task, the pipeline ensures it searches both sources. Option D is correct because setting the 'CheckConsistency' flag to true in the restore task enforces that the restore operation fails if any package cannot be resolved from the configured sources, meeting the requirement to fail on missing packages.

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 →
8
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

Environments support required reviewers for manual approval.

Why this answer

Option C is correct because it uses a single workflow with jobs for build, test, and deploy, and uses environments for staging and production with required reviewers. Option A is incorrect because GitHub Actions does not use multi-stage YAML. Option B is incorrect because separate workflows cannot share artifacts easily.

Option D is incorrect because Azure Pipelines is not GitHub Actions.

Full explanation →
9
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

Key Vault provides secure secret storage and retrieval.

Why this answer

Option A is correct because marking variables as 'secret' masks them in logs. Option C is correct because limiting access to the variable group reduces exposure. Option E is correct because using Azure Key Vault provides secure storage.

Option B is wrong because logs can still show secret variable names. Option D is wrong because logging commands can still output secrets if not handled.

Full explanation →
10
MCQmedium

Refer to the exhibit. This YAML pipeline snippet is configured in an Azure Pipelines YAML file. 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 include filter limits triggers to those paths.

Why this answer

The trigger includes a path filter that only includes /src/*. This means the pipeline will only trigger if changes are in /src. Option C is correct.

Option A is incorrect because the trigger is valid. Option B is incorrect because vmImage is not the issue. Option D is incorrect because script is valid.

Full explanation →
11
Multi-Selectmedium

Your team is migrating from TFVC to Git in Azure Repos. Which TWO actions should you take to ensure a smooth migration?

Select 2 answers
A.Use the Azure DevOps Migration Tool to directly map TFVC permissions to Git repository permissions.
B.Use the git-tfs tool to clone the TFVC repository with full history into a local Git repository.
C.Create a single Git repository with multiple branches that mirror the TFVC branch structure.
D.Train the development team on Git branching strategies and commands before the migration.
E.Enable Git LFS in the new repository to handle large binary files from TFVC.
AnswersB, D

git-tfs preserves history during migration.

Why this answer

Option B is correct because the git-tfs tool is specifically designed to bridge TFVC and Git, allowing you to clone a TFVC repository with full changeset history into a local Git repository. This preserves the commit history, which is critical for audit trails and code review continuity during the migration.

Exam trap

The trap here is that candidates often confuse the Azure DevOps Migration Tool's capabilities, assuming it can directly convert TFVC permissions to Git permissions, when in reality Git permissions are managed differently and require manual reconfiguration of branch policies and security groups.

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

Correct. The requests increased steadily, and at 10:30 AM, the app started returning errors and slowing down, indicating it hit a capacity bottleneck.

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 creates the environment; caching speeds up subsequent runs.

Why this answer

Option B is correct because the 'UsePythonVersion' task can set up Python, but not Conda environments. The 'CondaEnvironment' task manages Conda environments and can be combined with caching. Option A is wrong because 'UsePythonVersion' doesn't handle Conda.

Option C is wrong because script alone doesn't leverage built-in caching. Option D is wrong because Docker is unnecessary overhead.

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

Build validation ensures the build must succeed.

Why this answer

Option C is correct because 'Build validation' enforces that a build must succeed before the PR is completed. Option A is wrong because 'Require a minimum number of reviewers' does not enforce build success. Option B is wrong because 'Comment resolution' is about comments.

Option D is wrong because 'Check for linked work items' is about work items.

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

Secrets are stored in Key Vault and referenced securely in pipelines.

Why this answer

Option A is correct because variable groups linked to Azure Key Vault allow secure storage. Option C is correct because secret variables should be set in the pipeline UI or variable groups, not YAML. Option B is wrong because checking secrets into the repository is insecure.

Option D is wrong because logging secrets is a security risk. Option E is wrong because storing secrets in the YAML file exposes them in the repository.

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

Code owners provides automatic assignment. The scheduled workflow provides timely escalation without excessive overhead.

Why this answer

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

Requires approval from a code owner.

Why this answer

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

Parallel jobs leverage multiple agents to build modules concurrently, reducing overall time.

Why this answer

Option C is correct because parallel jobs and multi-agent builds can significantly reduce build time by running independent modules concurrently. Option A is incorrect because larger VMs may have limited impact. Option B is incorrect because reducing code coverage is counterproductive.

Option D is incorrect because using a self-hosted agent does not inherently reduce build time.

Full explanation →
19
MCQhard

You are designing a source control strategy for a global team of 200 developers working on a single large .NET solution. The solution takes 45 minutes to build. You need to reduce build times and enable independent versioning of components. What should you do?

A.Migrate from Git to Team Foundation Version Control (TFVC) for better performance
B.Stay in a monorepo and use one pipeline with path filters to build only changed components
C.Split the solution into multiple repositories, each with its own CI/CD pipeline
D.Keep the monorepo and disable continuous integration builds to reduce load
AnswerC

Multiple repositories with independent builds reduce build times and enable independent versioning.

Why this answer

Splitting the solution into multiple repositories (a multi-repo strategy) allows independent teams to version and build their components separately, reducing the monolithic 45-minute build to smaller, parallel CI/CD pipelines. This approach also enables independent versioning of components, which is impossible in a monorepo without complex tooling. Each repository can have its own pipeline that triggers only on changes to that component, drastically cutting build times.

Exam trap

The trap here is that candidates often think path filters in a monorepo (Option B) reduce build time, but they only control pipeline triggers—the actual build still compiles the entire solution, so the 45-minute build remains unchanged.

How to eliminate wrong answers

Option A is wrong because migrating from Git to TFVC would not reduce build times or enable independent versioning; TFVC is a centralized version control system that still requires building the entire solution and lacks Git's branching/merging efficiency for parallel work. Option B is wrong because staying in a monorepo with path filters still requires the entire solution to be built in a single pipeline, and the 45-minute build time is not reduced—path filters only skip pipeline triggers but do not change the fact that the build itself must process the whole solution. Option D is wrong because disabling continuous integration builds would eliminate automated builds entirely, which defeats the purpose of reducing build times and enabling independent versioning; it would only hide the problem, not solve it.

Full explanation →
20
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

Can run 'dotnet test' to execute tests.

Why this answer

The VSTest task runs Visual Studio tests, and the DotNetCoreCLI task with 'test' command runs .NET tests. The NuGet task restores packages, not tests. The CopyFiles task copies files.

The PublishBuildArtifacts task publishes artifacts.

Full explanation →
21
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.
AnswerB

Environment secrets provide scoped access and are automatically masked.

Why this answer

Option D is correct because marking a secret as sensitive or using environment secrets with masking ensures they are redacted. Option A is incorrect because environment variables are not automatically masked. Option B is incorrect because storing in repository secrets and referencing them is good, but they are still masked in logs automatically; however, the question asks for best approach to ensure no exposure, and using environment secrets provides additional scoping.

Option D is the most comprehensive.

Full explanation →
22
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

This directly controls pipeline log retention.

Why this answer

Option B is correct because Azure DevOps pipeline log retention is configured in the project settings under 'Pipelines' > 'Retention and releases'. Option A is wrong because Azure Monitor is for Azure resources, not DevOps logs. Option C is wrong because Azure Storage does not directly store pipeline logs.

Option D is wrong because audit logs are separate from pipeline logs.

Full explanation →
23
MCQmedium

You are reviewing a compliance policy for Azure Pipelines. What does this policy enforce?

A.Enforces MFA for all pipeline runs that use the 'MySecrets' variable group
B.Requires multi-factor authentication to approve use of secret variables in the 'MySecrets' variable group
C.Requires MFA to edit variables in the 'MySecrets' variable group
D.Blocks all access to the 'MySecrets' variable group unless MFA is used
AnswerB

The policy enforces MFA approval for the variable group.

Why this answer

Option A is correct because the policy requires MFA approval when accessing the variable group 'MySecrets'. Option B is wrong because the policy is scoped to the variable group, not all pipeline runs. Option C is wrong because it requires approval, not just MFA authentication.

Option D is wrong because it refers to a specific variable group.

Full explanation →
24
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

Access policies provide fine-grained control over who can access secrets.

Why this answer

Options B and C are correct. B: Using managed identities avoids storing credentials. C: Access policies control who can access the vault.

Option A is wrong because disabling logging reduces security monitoring. Option D is wrong because HTTP is insecure. Option E is wrong because enabling soft-delete is a recovery feature, not an access control.

Full explanation →
25
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

Correct syntax to filter PR triggers by branch.

Why this answer

In Azure Pipelines, you can specify branch filters for PR triggers using 'pr:' with 'branches:' and 'include:' to list the branches. Option A is correct. Option B is wrong because 'trigger:' is for CI triggers, not PR triggers.

Option C is wrong because the syntax is incorrect. Option D is wrong because 'paths:' filters changes to specific files, not branches.

Full explanation →
26
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

This task explicitly sets the SDK version.

Why this answer

Option A is correct because the UseDotNet task allows specifying a precise SDK version. Option B is wrong because global.json is not enforced by default. Option C is wrong because the pipeline doesn't auto-update global.json.

Option D is wrong because the task exists.

Full explanation →
27
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

This is the Test Retry feature for flaky tests.

Why this answer

The Test Retry feature in Azure Pipelines automatically retries a failed test a specified number of times. If the test passes on retry, the pipeline is marked as succeeded with warnings. Option A is correct because it allows retrying flaky tests.

Option B is a preview feature for rerunning failed stages, not tests. Option C is for rerunning failed jobs, not individual tests. Option D is a GitHub feature, not Azure Pipelines.

Full explanation →
28
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

Path triggers filter by file paths, allowing include/exclude rules.

Why this answer

Path filters in triggers allow specifying include and exclude patterns. Option A is wrong because branch filters are for branches, not folders. Option B is wrong because tags are for releases.

Option D is wrong because schedules are time-based.

Full explanation →
29
MCQmedium

Your team uses GitHub and wants to implement a policy that requires all pull requests to have a successful status check from a GitHub Actions workflow that runs unit tests. Additionally, the policy should require that the PR author is not allowed to merge their own PR. The repository is for a critical application and the main branch is protected. You need to configure the branch protection rules. Which combination of settings should you use?

A.Enable 'Require pull request reviews before merging' with 2 approvals, and enable 'Allow force pushes'.
B.Enable 'Require pull request reviews before merging' with 1 approval from a specific team, and disable 'Require status checks'.
C.Enable 'Require code owner review' and 'Require status checks to pass before merging'.
D.Enable 'Require pull request reviews before merging' with 1 approval, and enable 'Require status checks to pass before merging' with the unit test check required.
AnswerD

This ensures at least one approval from someone else (author cannot self-approve) and status checks pass.

Why this answer

Option D is correct because it combines two essential protections: requiring at least one approval prevents the PR author from merging their own PR (since the author cannot self-approve), and requiring the unit test status check to pass ensures that only code with successful automated tests can be merged into the protected main branch. This directly satisfies both policy requirements.

Exam trap

The trap here is that candidates may think 'Require code owner review' alone prevents self-merge, but it does not—a code owner can approve their own PR unless additional settings are applied, and it does not enforce a separate approval from another contributor.

How to eliminate wrong answers

Option A is wrong because enabling 'Allow force pushes' on a protected branch would allow bypassing the review and status check requirements, undermining the policy. Option B is wrong because disabling 'Require status checks' would allow merging without the unit test workflow passing, violating the requirement for a successful status check. Option C is wrong because 'Require code owner review' only mandates review from code owners, not a general approval, and does not prevent the PR author from merging their own PR (the author could be a code owner).

Full explanation →
30
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
AnswerD

Secret scanning detects secrets in repositories.

Why this answer

Option B is correct because secret scanning detects and alerts on secrets in repositories. Option A is wrong because Dependabot handles dependency vulnerabilities. Option C is wrong because code scanning finds code vulnerabilities.

Option D is wrong because push protection is a separate setting that blocks pushes containing secrets, but the broader feature is secret scanning.

Full explanation →
31
MCQhard

You run the above KQL query in Log Analytics to troubleshoot a failing container in a Kubernetes deployment. The query returns no results even though you know there are errors. What is the most likely cause?

A.The 'project' clause filters out relevant rows.
B.Container logs are not being sent to the ContainerLog table.
C.The 'contains' operator is case-sensitive.
D.The KQL syntax is incorrect.
AnswerB

Logs may be in ContainerLogV2 or not collected.

Why this answer

Option D is correct because container logs may be sent to a different table (e.g., ContainerLogV2) or the log collection is not configured. Option A is wrong because the query is correct syntax. Option B is wrong because 'contains' is case-insensitive.

Option C is wrong because the query returns only three columns, not affecting results.

Full explanation →
32
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 →
33
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 with auto-swap allow validation in staging and then swap to production.

Why this answer

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

Why this answer

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

Variable 'environment' is set to 'prod' in Deploy stage.

Why this answer

Option B is correct because the Deploy stage overrides the variable 'environment' to 'prod' for that stage. Option A is wrong because the variable is overridden. Option C is wrong because the condition only checks if Build succeeded.

Option D is wrong because the script will run and echo the variable.

Full explanation →
36
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.
AnswerA

The enforcement scope is limited to production and staging, so test pipelines are not affected.

Why this answer

The required template enforcement is scoped to 'production' and 'staging' environments. Pipelines targeting other environments like 'test' are not required to use the template. The pipeline will run without the security template.

It will not be blocked or fail unless it explicitly targets production or staging.

Full explanation →
37
MCQhard

You have a multi-stage pipeline that builds a .NET application and deploys it to Azure App Service. The build stage produces a drop artifact that is used by the deployment stage. Recently, the deployment stage started failing intermittently with a '403 Forbidden' error when trying to download the artifact. The service connection used for deployment has 'Contributor' role at the resource group level. The artifact is stored in Azure Artifacts. What is the most likely cause of the failure?

A.The service connection does not have 'Website Contributor' role on the App Service.
B.The pipeline has 'Limit job authorization scope to current project' enabled, restricting access to the artifact.
C.The artifact is stored in a different Azure region than the App Service, causing a cross-region access error.
D.The service principal used by the service connection lacks 'Reader' permissions on the Azure Artifacts feed.
AnswerD

To download artifacts from Azure Artifacts, the identity needs at least Reader role on the feed.

Why this answer

Option B is correct because Azure Artifacts requires the 'Reader' role at the project level to read packages. The deployment stage uses a service principal that may not have the necessary permissions on the artifact feed. Option A is incorrect because the service connection is for Azure App Service, not for reading artifacts.

Option C is not relevant as the error is not about pipeline permissions. Option D is incorrect because the pipeline does not need to be in the same region.

Full explanation →
38
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

Option B is correct because stages run sequentially by default, and you can use dependsOn with 'none' for parallel stages. Option A is wrong because 'dependsOn: build' on test makes it sequential. Option C is wrong because stages cannot run in parallel if they depend on each other.

Option D is wrong because you cannot run stages in parallel without using dependsOn.

Full explanation →
39
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 run before every job and can enforce security rules, such as requiring a specific service connection.

Why this answer

Azure DevOps pipeline decorators can inject a task at the beginning of every pipeline to validate that only approved service connections are used, rejecting pipelines that use PATs or other unauthorized connections. Branch policies protect branches but don't control service connection usage. Agent pools and variable groups don't enforce service connection selection.

Full explanation →
40
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

Why this answer

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

Staging slot is the 'green' environment.

Why this answer

Blue-green deployment: deploy to a staging slot (A), swap slots after validation (B), and enable auto-swap for zero-downtime (E). Option C is wrong because deleting the production slot is not part of blue-green; you swap to make it active. Option D is wrong because you typically route a percentage of traffic to the staging slot for testing, not 100%.

Full explanation →
42
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

Native modules compiled for a different Node.js version can fail.

Why this answer

Option C is correct because GitHub Actions runners may include a different Node.js version than the target App Service, causing native module incompatibility. Option A is wrong because the node_modules folder is included. Option B is wrong because the YAML syntax is valid.

Option D is wrong because build optimization does not cause missing modules.

Full explanation →
43
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.
AnswerD

Azure Storage supports leasing for state locking.

Why this answer

Option A is correct because Azure Storage supports state locking with leases. Option B is wrong because Terraform Cloud is external. Option C is wrong because Azure DevOps does not offer state locking.

Option D is wrong because Git is not suitable for state files.

Full explanation →
44
MCQmedium

Your team uses Azure DevOps to build a .NET application. The build pipeline takes 45 minutes to complete. You want to reduce build times by caching dependencies. What should you configure in the pipeline?

A.Configure a Build Retention Policy to keep only the latest build.
B.Add a Cache task with a key based on the package-lock.json file hash.
C.Use Pipeline Artifacts to store dependencies between builds.
D.Enable Incremental builds in the pipeline settings.
AnswerB

The Cache task caches dependencies and restores them if the key matches, reducing build time.

Why this answer

Using the Cache task with a key based on the package-lock.json file restores cached dependencies when the file hasn't changed, reducing build time. Option A is wrong because Build Retention Policy controls artifact retention, not caching. Option B is wrong because Incremental builds are not natively supported in YAML pipelines.

Option D is wrong because Pipeline Artifacts are for sharing files between stages, not caching.

Full explanation →
45
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

Masked secrets are automatically hidden in logs.

Why this answer

Option B is correct because marking secrets as masked prevents them from appearing in logs. Option A is wrong because storing secrets in code is insecure. Option C is wrong because secrets in environment variables can still be logged if not masked.

Option D is wrong because it does not prevent exposure in logs.

Full explanation →
46
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

Enforces both code review and successful build.

Why this answer

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

Why this order

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

Full explanation →
48
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

Sampling preserves representative data and reduces cost while still enabling anomaly detection.

Why this answer

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

Variable groups can be linked to environments.

Why this answer

Approval gates are configured on environments, not stages. Stage filters with conditions can control deployment to specific branches. Variables can be overridden per stage using variable groups scoped to environments.

Option A is correct because approvals are set on environments. Option C is correct because stage filters can restrict branches. Option D is correct because variable groups can be scoped to environments.

Option B is incorrect because stages don't have approvals. Option E is incorrect because YAML templates are not required.

Full explanation →
50
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

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

Enforced on every push.

Why this answer

Option A is correct because 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. This ensures that every commit pushed to the remote repository meets your organization's formatting standards, 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 →
52
MCQeasy

You are designing a release pipeline that deploys a web app to Azure App Service. You need to ensure that configuration secrets (e.g., database connection strings) are not stored in the pipeline YAML file. Which approach should you use?

A.Define the secrets as agent-scoped variables in the release pipeline.
B.Hardcode the secrets in the App Service configuration and reference them in the pipeline.
C.Use an Azure Key Vault variable group linked to the pipeline.
D.Store the secrets as pipeline variables and mark them as 'Secret'.
AnswerC

Key Vault variable groups securely fetch secrets at runtime and are not stored in the pipeline.

Why this answer

Option B is correct because Azure Key Vault securely stores secrets and integrates with Azure Pipelines via variable groups linked to Key Vault. Option A is wrong because pipeline variables are stored in YAML or in the pipeline settings, not encrypted at rest in a secure vault. Option C is wrong because agent-scoped variables are not designed for secret management and are still visible in logs.

Option D is wrong because environment variables in the App Service configuration are not managed by the pipeline securely.

Full explanation →
53
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

Measures how often deployments cause failures.

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 →
54
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

Why this answer

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

Purview can scan repos for sensitive data.

Why this answer

Option C is correct because Microsoft Purview Data Classification can scan repositories for sensitive data using built-in or custom sensitive information types. Option A is incorrect because DLP policies are for endpoints, not repositories. Option B is incorrect because Microsoft Sentinel is a SIEM.

Option D is incorrect because Microsoft Defender for Cloud is for cloud security posture.

Full explanation →
56
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 →
57
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

This enables automatic dependency tracking for HttpClient.

Why this answer

Option A is correct because `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 →
58
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 can enforce a minimum number of reviewers for pull requests.

Why this answer

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

PYTHONPATH adds the directory to the module search path.

Why this answer

Option C is correct because the CI environment does not have the 'src' directory in the Python path. Setting PYTHONPATH ensures the module is found. Option A is wrong because the working directory changes the context but not the Python path.

Option B is wrong because installing the package in editable mode requires a setup.py. Option D is wrong because the dependencies are already installed.

Full explanation →
60
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

Both settings trigger on new push.

Why this answer

Option A is correct because 'resetOnSourcePush' is true, so the vote count resets, and 'queueOnSourceUpdateOnly' is true, so a new build is queued. Option B is wrong because the build is queued. Option C is wrong because the vote count resets.

Option D is wrong because the build is queued and votes reset.

Full explanation →
61
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

Persistent caches reduce reliance on external feeds and improve reliability.

Why this answer

Using a self-hosted agent with persistent package caches avoids re-downloading packages on each build, reducing network issues. Option A is wrong because clearing caches would worsen the problem. Option C is wrong because multi-stage builds are for Docker, not NuGet.

Option D is wrong because Dapr is unrelated.

Full explanation →
62
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

Why this answer

Option A is correct because 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 →
63
MCQmedium

Refer to the exhibit. This YAML pipeline snippet uses parameters to deploy to different environments. The team wants to run the pipeline for a specific environment by providing the parameter at queue time. However, the pipeline fails with 'Invalid stage name'. What is the most likely cause?

A.The parameter values must be defined in a separate file.
B.Stage names cannot contain template expressions; they must be static.
C.The 'AzureWebApp@1' task inputs are incorrectly formatted.
D.The 'stage' keyword should be 'stageName'.
AnswerB

Stage names must be compile-time constants.

Why this answer

Stage names cannot contain template expressions like '${{ parameters.environment }}' directly; they must be resolved to a static string. In YAML, stage names are used for dependencies and must be known at compile time. Using a parameter in the stage name is not allowed because the parameter value is not known when the YAML is parsed.

Option A is correct. Option B is incorrect because the task inputs are fine. Option C is incorrect.

Option D is incorrect.

Full explanation →
64
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 only includes eastus and westus, so centralus is denied.

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 →
65
Multi-Selectmedium

Your organization uses Azure Repos and wants to implement a Git branching strategy that supports continuous delivery with hotfix capabilities. Which THREE practices should be part of the strategy?

Select 3 answers
A.Feature branches have long lifetimes and are merged to main only after full feature completion.
B.Release branches are used to stabilize a release before merging to main.
C.Main branch is always in a deployable state.
D.Hotfixes are merged directly to develop and then cherry-picked to main.
E.Hotfix branches are created from main and merged back into main and develop.
AnswersB, C, E

Release branches allow final testing and bug fixes before production.

Why this answer

Option B is correct because release branches allow a team to stabilize a release candidate without disrupting ongoing development on the main branch. Once the release is fully tested and stable, it is merged into main, ensuring that main always contains production-ready code. This aligns with the continuous delivery principle of maintaining a deployable main branch.

Exam trap

The trap here is confusing the hotfix branching model with the incorrect practice of merging hotfixes directly to develop and cherry-picking to main, which violates the principle that main must always be in a deployable state and can lead to missing fixes in the development branch.

Full explanation →
66
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

This applies the policy only to the feature branch and allows BetaTeam to push directly.

Why this answer

Option D is correct because 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 →
67
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 →
68
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

Work item rules can require approval from a group.

Why this answer

Option A is correct because 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 →
69
Multi-Selecteasy

You are configuring a YAML pipeline in Azure Pipelines. The pipeline must trigger only when changes are pushed to the main branch. Which TWO settings should you configure?

Select 2 answers
A.Set the PR trigger to include main.
B.Set the pipeline to run on every push regardless of branch.
C.Use a schedule trigger with cron expression.
D.Set the trigger to include the main branch.
E.Set the trigger to none for other branches.
AnswersD, E

The trigger section specifies which branches trigger the pipeline.

Why this answer

Option A is correct because trigger defines branches to trigger on. Option D is correct because setting trigger to none disables CI triggers for other branches. Options B, C, and E are not required.

Full explanation →
70
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

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

Org-wide setting enforces signed commits; SSH keys are allowed.

Why this answer

Option B is correct because enabling 'Require signed commits' on the organization enforces GPG signing. Requiring SSH keys is separate. Option A is wrong because branch protection rules only apply per branch, not org-wide.

Option C is wrong because SSH keys are for authentication, not signing. Option D is wrong because it's not an organization-level enforcement.

Full explanation →
72
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 require manual sign-off before deploying to a stage.

Why this answer

Pre-deployment approvals allow manual approval before deployment to a stage. Option A is wrong because gates evaluate conditions automatically. Option B is wrong because pipeline triggers start runs automatically.

Option D is wrong because variable groups store variables, not approvals.

Full explanation →
73
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

Option A is correct because the 'paths' trigger filter allows specifying include/exclude patterns. Option B is wrong because branch filters limit which branches trigger, not paths. Option C is wrong because the checkout step is for fetching code, not triggering.

Option D is wrong because file matching is not a trigger property.

Full explanation →
74
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

Caches the specified folder for subsequent runs.

Why this answer

Option B is correct because the Cache task is designed to cache folders between runs. Option A is wrong because the Copy Files task does not cache. Option C is wrong because the Publish Build Artifacts task publishes artifacts but does not cache on the agent.

Option D is wrong because the Download Build Artifacts task downloads artifacts, not cache.

Full explanation →
75
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 variable concatenates 'vnet-' with the parameter value 'prod'.

Why this answer

The variables section concatenates 'vnet-' with the parameter value, so 'vnet-prod'. Option A is wrong because it uses the default. Option C is wrong because it ignores the concatenation.

Option D is wrong because it uses a static name.

Full explanation →

Page 1 of 13

Page 2

All pages

12345678910111213

Practice AZ-400 by domain

Target a specific domain to shore up weak areas.

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