Courseiva

Microsoft Azure DevOps Engineer Expert AZ-400 (AZ-400) — Questions 151–225

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

Take a mock examExam hub
Page 2

Page 3 of 11

Page 4
151
MCQeasy

You are designing a build pipeline for a Python application that uses multiple third-party packages from the public PyPI repository. Your organization has security policies that require all build dependencies to be scanned for known vulnerabilities before being used. The build pipeline runs on Microsoft-hosted agents. You need to integrate vulnerability scanning into the build pipeline with minimal overhead and without storing credentials in the pipeline. What should you do?

A.Configure a service connection to a private vulnerability database and use a script to scan.
B.Write a custom script that uses pip audit to scan the requirements.txt file.
C.Use a pre-build validation step in the pipeline to manually review dependencies.
D.Add a dependency scanning task from the Azure DevOps marketplace to the build pipeline.
AnswerD

Adding a dependency scanning task from the Azure DevOps marketplace is the correct approach because it integrates directly into the pipeline, supports credential-free scanning for public packages, and automatically fails the build on detected vulnerabilities. It leverages Azure DevOps' built-in reporting, governance, and extension ecosystem, providing comprehensive coverage of both direct and transitive dependencies without custom code.

Why this answer

The correct approach is to add a dependency scanning task from the Azure DevOps marketplace to the build pipeline. These tasks, such as WhiteSource Bolt or Snyk, integrate seamlessly with Azure Pipelines, automatically scan dependencies from PyPI for known vulnerabilities, and require no credential storage in the pipeline. Option A is incorrect because connecting to a private vulnerability database adds unnecessary complexity and overhead.

Option B is incorrect because using a custom script with pip audit would require maintaining the script and potentially storing credentials for external services. Option C is incorrect because manual review is not automated and defeats the purpose of a CI/CD pipeline.

Full explanation →
152
MCQhard

You are designing a release pipeline for a critical business application that must adhere to strict compliance requirements. The pipeline must deploy to multiple environments (dev, test, staging, prod) with manual approvals required for staging and prod. Additionally, the pipeline must automatically run integration tests after deployment to dev and test, and only proceed to the next environment if tests pass. You need to implement this using Azure Pipelines YAML. What should you do?

A.Use a single multi-stage YAML pipeline with a stage per environment. Add approvals on staging and prod stages. Ensure stages run sequentially by default.
B.Create separate YAML pipelines for each environment and use pipeline completion triggers to chain them together.
C.Use a classic release pipeline with environments and pre-deployment approvals on staging and prod. Add a post-deployment task to run integration tests in dev and test environments.
D.Use a single multi-stage YAML pipeline with a stage per environment. Add a job after deployment to dev that runs integration tests, and use a condition on the next stage to run only if tests passed. Add approvals on staging and prod stages.
AnswerD

Stages with conditions and approvals fulfill all requirements.

Why this answer

It uses a single multi-stage YAML pipeline with a stage per environment, adds a job after deployment to dev that runs integration tests, uses a condition on the next stage to run only if tests passed, and adds approvals on staging and prod stages. This satisfies all requirements: sequential deployment, conditional test execution, and manual approvals. Option A is incorrect because it lacks the conditional test execution; after deployment to dev, the pipeline would proceed to test regardless of test results.

Option B is incorrect because separate pipelines with completion triggers cannot enforce the required conditions (run tests and only proceed if passed) and cannot easily add approvals per environment. Option C is incorrect because it describes a classic release pipeline, which does not support YAML-based definitions and cannot easily integrate conditional test execution with stage dependencies.

Full explanation →
153
Multi-Selecthard

Which THREE practices are recommended for managing secrets in a Git repository? (Select THREE.)

Select 3 answers
A.Use tools like GitLeaks to scan for accidentally committed secrets
B.Store secrets in a separate encrypted file committed to the repository
C.Use GitHub Secrets or Azure Pipelines secret variables
D.Use Azure Key Vault to store and retrieve secrets at build/release time
E.Commit a .env file with default values to the repository
AnswersA, C, D

GitLeaks and similar secret-scanning tools inspect repository history, staging areas, and CI/CD diffs for high-entropy strings and known provider patterns (e.g., AWS Access Key IDs, GitHub tokens). They are typically run as a pre-commit hook or a separate pipeline stage, so leaks are caught early before they propagate to forks or downstream branches. This is a detection control, not a prevention control; it complements secure storage options by providing visibility and enforcing policy on legacy codebases.

Why this answer

The recommended practices for managing secrets in a Git repository include using tools like GitLeaks to scan for accidentally committed secrets (Option A), using GitHub Secrets or Azure Pipelines secret variables (Option C), and using Azure Key Vault to store and retrieve secrets at build/release time (Option D). These approaches help avoid storing secrets directly in the repository. Option B is incorrect because storing secrets in an encrypted file committed to the repository still exposes them to anyone who can access the repo and the decryption key.

Option E is incorrect because committing a .env file with default values risks including sensitive data and is not a secure practice.

Full explanation →
154
Multi-Selecteasy

Your team uses Git for source control. You want to maintain a clean commit history on the main branch by avoiding merge commits. Which TWO merge strategies in a pull request achieve this?

Select 2 answers
A.Rebase merge
B.Merge commit
C.Squash merge
D.Three-way merge
E.Fast-forward merge
AnswersA, C

Rebase merge is the correct choice when you want linear history: it takes each commit from the source branch and applies it onto the latest target branch tip, creating a straight-line history with no merge commit while preserving individual commits.

Why this answer

A rebase merge (option A) rewrites the commit history of the feature branch onto the tip of the target branch, creating a linear sequence of commits without any merge commits. This maintains a clean, linear history on the main branch. A squash merge (option C) combines all commits from the feature branch into a single new commit on the target branch, also avoiding merge commits and keeping the history clean.

Exam trap

The trap here is that candidates often confuse 'fast-forward merge' with a clean history strategy, but fast-forward merges only avoid merge commits when the branches haven't diverged; they do not rewrite or consolidate commits, so they fail to maintain a clean history in the general case.

Full explanation →
155
MCQhard

An Azure Policy is defined as shown in the exhibit. You attempt to create a storage account with HTTPS traffic only set to false. What will happen?

A.The policy will only apply if the storage account is in a specific resource group
B.The storage account will be created but HTTPS will be enforced
C.The storage account will be created and an audit event will be logged
D.The creation will be denied with an error message
AnswerD

The policy effect is 'deny', which causes Azure Resource Manager to evaluate the request and, if the storage account does not have supportsHttpsTrafficOnly set to true, reject the creation with a policy violation error message. The resource is never created as a result.

Why this answer

The Azure Policy in the exhibit uses a 'Deny' effect for the condition that storage accounts must have HTTPS traffic enabled. When you attempt to create a storage account with 'HTTPS traffic only' set to false, the policy evaluation detects a non-compliant resource and denies the creation request, returning an error message. This is because the 'Deny' effect blocks the resource deployment entirely, preventing the non-compliant configuration from being provisioned.

Exam trap

The trap here is that candidates often confuse the 'Deny' effect with 'Audit' or 'Modify', mistakenly thinking the policy will either log the violation or auto-correct the setting, rather than understanding that 'Deny' blocks the operation entirely.

How to eliminate wrong answers

Option A is wrong because the policy definition does not include a scope restriction to a specific resource group; Azure Policies apply at the assigned scope (e.g., subscription or management group) unless a parameter or condition explicitly filters by resource group. Option B is wrong because the 'Deny' effect prevents the storage account from being created at all; it does not allow creation and then enforce HTTPS after the fact—enforcement would require a 'Modify' or 'DeployIfNotExists' effect. Option C is wrong because the 'Deny' effect blocks creation and logs a denial event, but it does not allow creation with an audit event; an 'Audit' effect would log the non-compliance without blocking.

Full explanation →
156
Multi-Selecthard

Your organization uses GitHub Actions for CI/CD. You need to enforce branch protection rules and ensure that all pull requests to the main branch require a successful status check from a specific workflow. Which TWO actions should you take? (Choose two.)

Select 2 answers
A.Configure a GitHub environment with required reviewers.
B.Add a workflow to the repository that runs tests and reports a conclusion status.
C.Use a repository ruleset to require status checks.
D.Set up branch policies in Azure Repos for the main branch.
E.In the repository settings, enable 'Require status checks to pass before merging' under branch protection rules.
AnswersB, E

Adding a workflow that runs tests and reports a conclusion status is the essential first step because it creates a check run (status check) whose conclusion can later be required. Without such a workflow, there is no status check for branch protection rules to enforce, so this is the correct way to enable test validation before merging.

Why this answer

A workflow that runs tests and reports a conclusion status provides the status check that branch protection rules can require. Option E is correct because enabling 'Require status checks to pass before merging' under branch protection rules in the repository settings enforces that the specific workflow's status check must succeed before a pull request can be merged into the main branch.

Exam trap

The trap here is confusing GitHub's branch protection rules with repository rulesets or Azure Repos policies, leading candidates to select options that are either for a different platform or for a different enforcement mechanism.

Full explanation →
157
MCQeasy

You need to ensure that only specific branches can trigger a release to production in Azure Pipelines. What should you configure?

A.Add an approval gate that requires a manager to approve the release.
B.Add a deployment gate that checks the source branch.
C.Add a branch filter to the release pipeline's artifact trigger.
D.Add a branch filter to the build pipeline trigger.
AnswerC

In Azure Pipelines, a release pipeline's artifact trigger can be configured with a branch filter to specify which branches of the source repository are allowed to initiate a release. When you add a branch filter under the artifact trigger of the release pipeline, only builds from those branches (or builds that match the filter) will cause a release to be created, directly meeting the requirement to restrict which branches can trigger a release.

Why this answer

A branch filter on the release pipeline's artifact trigger allows you to specify which branches of the source artifact (e.g., a build pipeline) should automatically trigger a release. By configuring this filter to only include branches like 'main' or 'release/*', you ensure that only builds from those specific branches can initiate a release to production, providing precise control over deployment triggers.

Exam trap

The trap here is confusing branch filters on build pipeline triggers (which control when code is built) with branch filters on release pipeline artifact triggers (which control when releases are created from those builds), leading candidates to incorrectly select Option D.

How to eliminate wrong answers

Option A is wrong because an approval gate requires a manager to approve the release after it is triggered, but it does not restrict which branches can trigger the release; any branch could still initiate the release, and the gate only adds a manual approval step. Option B is wrong because a deployment gate checks conditions (like source branch) at deployment time, but it does not prevent the release from being triggered; it only evaluates whether to proceed with the deployment after the release is already created. Option D is wrong because a branch filter on the build pipeline trigger controls which branches trigger a build, not which branches trigger a release; this would affect when code is compiled, not when a release is deployed to production.

Full explanation →
158
MCQmedium

Your team uses Azure DevOps and wants to enforce branch protection policies for all repositories in a GitHub Advanced Security-enabled organization. Which approach should you use to ensure that pull requests require a successful status check from a required workflow?

A.Use GitHub Actions secrets to store the required status check name.
B.Define a repository rule in GitHub that requires a successful status check from a required workflow.
C.Create a branch protection rule in each repository's settings.
D.Configure branch policies in Azure DevOps project settings.
AnswerB

Repository rules (the modern replacement for individual protected branch settings) let you centrally define branch protection policies for all repositories in an organization. By creating a rule that requires a successful status check named after a required workflow, you enforce that check across every matching branch and repository, making it the correct organization-wide solution for this requirement.

Why this answer

GitHub repository rules (also known as repository rulesets) allow organizations to centrally enforce policies like required status checks across multiple repositories. To require a successful status check from a specific workflow on all pull requests, create an organization-level repository ruleset that includes the 'Require status checks to pass' rule and specify the workflow's check name. This applies to all selected repositories without per-repository configuration.

GitHub Advanced Security is not required for this feature; it is a separate security add-on.

Exam trap

Candidates may confuse Azure DevOps branch policies (which apply to Azure Repos) with GitHub repository rules. Option D is incorrect because Azure DevOps branch policies do not apply to GitHub repositories, even if the organization uses Azure DevOps.

How to eliminate wrong answers

Option A is wrong because GitHub Actions secrets are used to store sensitive data like tokens or passwords, not to enforce branch protection policies or required status checks. Option C is wrong because creating a branch protection rule in each repository's settings would require manual configuration per repository, which is not scalable for enforcing policies across all repositories in an organization. Option D is wrong because Azure DevOps project settings manage policies for Azure Repos, not for GitHub repositories; the question specifies a GitHub Advanced Security-enabled organization, so Azure DevOps policies are irrelevant.

Full explanation →
159
MCQhard

Your team uses GitHub and wants to automatically label pull requests based on the content of the changes (e.g., 'frontend' for changes in /frontend folder, 'backend' for /backend). Which approach should you use?

A.Use branch protection rules to require specific labels based on branch name patterns.
B.Set up a webhook that triggers an Azure Function to parse the pull request diff and add labels.
C.Create a GitHub Actions workflow that runs on pull_request events and uses an action like 'actions/labeler' to add labels based on path patterns.
D.Use a CODEOWNERS file to assign labels based on file paths.
AnswerC

The actions/labeler GitHub Action runs on the pull_request event and uses a declarative configuration file (typically .github/labeler.yml) to map file path patterns to labels. When a PR modifies files matching a pattern, the action automatically adds the corresponding label, making this the purpose-built, native GitHub solution for path-based auto-labeling.

Why this answer

GitHub Actions provides a native, event-driven way to automate labeling based on pull request changes. The 'actions/labeler' action specifically inspects file paths in the diff and applies labels defined in a configuration file, making it the simplest and most maintainable solution for path-based labeling.

Exam trap

The trap here is confusing CODEOWNERS (which assigns reviewers) with label automation, leading candidates to pick option D despite it having no labeling functionality.

How to eliminate wrong answers

Option A is wrong because branch protection rules enforce policies on merging (e.g., required status checks, number of reviewers) but cannot automatically add labels based on branch name patterns. Option B is wrong because while a webhook plus Azure Function could technically work, it introduces unnecessary complexity and external dependencies when a built-in GitHub Actions workflow is available and simpler. Option D is wrong because CODEOWNERS files define who is responsible for code reviews based on file paths, not for automatically applying labels to pull requests.

Full explanation →
160
Multi-Selecthard

Which TWO actions should you take to ensure that Azure Pipelines artifacts are securely stored and access is audited?

Select 2 answers
A.Configure the storage account firewall to only allow access from Azure Pipelines IP ranges
B.Use Azure Policy to enforce that artifacts are only deployed to production storage accounts
C.Enable Azure Artifacts retention policies to automatically delete old artifact versions
D.Enable customer-managed keys (CMK) for artifact encryption
E.Configure audit logging for artifact downloads via Azure DevOps audit logs
AnswersC, E

Enabling Azure Artifacts retention policies automatically deletes old artifact versions, reducing the attack surface and limiting the window in which outdated or potentially vulnerable artifacts can be downloaded or exploited. This is a security best practice that ensures only recent, vetted versions remain available to the pipeline.

Why this answer

Azure Artifacts retention policies allow you to automatically delete older versions of packages, reducing the attack surface and ensuring that only current, approved artifacts are stored. This is a key security practice to prevent outdated or vulnerable artifacts from being accessed. Option E is correct because enabling audit logging for artifact downloads via Azure DevOps audit logs provides a detailed, immutable record of who accessed which artifact and when, which is essential for compliance and security investigations.

Exam trap

The trap here is that candidates often confuse Azure Policy with pipeline governance (e.g., deployment gates) or assume that network-level controls like storage firewalls are the primary security mechanism for Azure Artifacts, when in fact Azure Artifacts is a PaaS service within Azure DevOps that does not expose a direct storage account endpoint for artifact downloads.

Full explanation →
161
MCQmedium

Your team uses Azure Pipelines to deploy a web app to Azure App Service. You need to ensure that secrets (e.g., connection strings) are not exposed in the pipeline logs. What is the recommended approach?

A.Remove all logging from the pipeline.
B.Use secret pipeline variables and reference them in the pipeline.
C.Store secrets in Azure Key Vault and retrieve them in the pipeline, then log them for debugging.
D.Store secrets as environment variables in the pipeline.
AnswerB

Secret variables are masked in logs.

Why this answer

Azure Pipelines supports secret pipeline variables that are masked in logs, preventing exposure of sensitive data like connection strings. When you mark a variable as secret, its value is automatically hidden from pipeline output, and you can reference it securely using $(variableName) syntax. This is the recommended approach for handling secrets directly within the pipeline without additional service dependencies.

Exam trap

The trap here is that candidates may think storing secrets in Azure Key Vault automatically prevents log exposure, but the retrieval and subsequent logging of those values in the pipeline still leaks them unless they are explicitly marked as secret variables.

How to eliminate wrong answers

Option A is wrong because removing all logging eliminates valuable debugging and auditing information, which is not a practical or recommended security practice; Azure Pipelines provides selective masking instead. Option C is wrong because logging secrets for debugging directly contradicts the goal of preventing exposure; even if retrieved from Key Vault, logging them would still leak sensitive data. Option D is wrong because environment variables in the pipeline are not automatically masked; they can appear in logs if echoed or printed, unlike secret variables which are explicitly hidden.

Full explanation →
162
MCQeasy

Your team is using YAML pipelines in Azure DevOps and wants to ensure that a specific stage runs only for changes to the 'main' branch. Which condition should you add to the stage?

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

This condition uses eq() to perform an exact string comparison against the full source ref 'refs/heads/main'. In Azure Pipelines, Build.SourceBranch contains the full ref, so this matches only the actual main branch and excludes all others, including branches that merely contain 'main' as a substring. It is the precise, minimal condition that satisfies the requirement without adding extra behavior such as succeeded() checks.

Why this answer

The `eq(variables['Build.SourceBranch'], 'refs/heads/main')` condition evaluates to true only when the pipeline is triggered by a change to the 'main' branch. In YAML pipelines, conditions are evaluated as expressions, and this simple equality check ensures the stage runs exclusively for that branch. The other options either invert the logic, use a partial match that could include other branches, or unnecessarily combine conditions.

Exam trap

The trap here is that candidates often choose option B (`contains`) thinking it is a simpler way to match the branch, but they overlook that `contains` does a substring match and will incorrectly trigger on branches like 'maintenance' or 'main-feature', whereas the exact ref comparison in option D is the precise and safe approach.

How to eliminate wrong answers

Option A is wrong because `ne(variables['Build.SourceBranch'], 'refs/heads/main')` runs the stage when the source branch is NOT 'main', which is the opposite of the requirement. Option B is wrong because `contains(variables['Build.SourceBranch'], 'main')` would match any branch containing 'main' in its ref path (e.g., 'refs/heads/main-feature' or 'refs/heads/notmain'), not just the exact 'main' branch. Option C is wrong because while it correctly checks for 'main', it adds `and(succeeded(), ...)` which is redundant since stages default to running only if the previous stage succeeded; this extra condition does not break the logic but is unnecessary and not the simplest correct answer.

Full explanation →
163
Multi-Selectmedium

Your organization is implementing a security compliance plan for Azure DevOps. Which TWO actions help enforce the principle of least privilege?

Select 2 answers
A.Allow all team members to edit security permissions
B.Use Azure DevOps security groups to grant minimal permissions
C.Use built-in roles without customizing
D.Restrict who can create new agent pools to a small admin team
E.Grant Project Collection Administrators group to all developers
AnswersB, D

This follows least privilege by granting only necessary permissions.

Why this answer

Azure DevOps security groups allow administrators to assign specific permissions to groups rather than individuals, enabling granular control over who can perform actions like editing work items or managing pipelines. This directly supports the principle of least privilege by ensuring users have only the permissions necessary for their role. Option D is correct because restricting agent pool creation to a small admin team prevents unauthorized users from deploying agents that could execute arbitrary code or access sensitive resources, which is a common attack vector in CI/CD environments.

Exam trap

The trap here is that candidates often assume built-in roles are always the safest choice (Option C), but Azure DevOps built-in roles like 'Project Administrators' grant broad permissions that exceed least privilege, whereas custom security groups with minimal permissions are more secure.

Full explanation →
164
MCQeasy

Your build pipeline includes a task that runs unit tests. You want to ensure that if any test fails, the pipeline stops immediately and does not proceed to the next tasks. What should you configure in the pipeline?

A.Set the 'Continue on error' option to false for the test task.
B.Add a custom condition to the test task to only run if previous tasks succeeded.
C.Set the 'Always run' option for the test task.
D.Ensure the task control option 'Run this task' is set to 'Only when all previous tasks have succeeded'.
AnswerA

'Continue on error' true allows continuation; false stops the task but not necessarily the pipeline.

Why this answer

To stop the pipeline immediately when a test task fails, you must ensure that the task's 'Continue on error' option is false (unchecked). This is the task control option that determines whether a task failure is ignored. When 'Continue on error' is false, a failed task causes the pipeline to stop and subsequent tasks with the default run condition ('Only when all previous tasks have succeeded') will not run.

Setting 'Run this task' to 'Only when all previous tasks have succeeded' is the default and only controls whether the test task runs based on prior task results; it does not directly affect what happens after the test task fails. Therefore, option A is the correct configuration.

Exam trap

This question tests knowledge of task control options in Azure Pipelines. 'Continue on error' and 'Run this task' are separate settings. A common trap is confusing 'Run this task' (which controls when a task runs) with 'Continue on error' (which controls what happens after a task fails).

Full explanation →
165
MCQmedium

You are configuring a release pipeline that deploys to multiple environments. You want to automate the deployment to the staging environment only if the build succeeds, and then require manual approval before deploying to production. Which strategy should you use?

A.Define an environment with approvals required for the production stage.
B.Use deployment gates in the production stage to check for manual intervention.
C.Use a classic release pipeline with pre-deployment approvals.
D.Configure a branch policy on the main branch to require approval for pull requests.
AnswerA

Defining an environment and enabling the approval check on its production stage is the correct way to require a manual sign-off before deployment. This approval is configured on the environment itself and naturally integrates with multi-stage YAML pipelines, ensuring that only authorized users can deploy to production.

Why this answer

Azure Pipelines allows you to define environments with explicit approval checks. By adding a manual approval gate on the production environment stage, the pipeline will automatically deploy to staging after a successful build, but pause before production until an authorized user approves the release. This directly meets the requirement for automated staging deployment and manual production approval.

Exam trap

The trap here is that candidates often confuse deployment gates (which are automated checks) with manual approvals, leading them to incorrectly select Option B, even though gates cannot provide the required manual intervention step.

How to eliminate wrong answers

Option B is wrong because deployment gates are designed for automated health checks (e.g., monitoring metrics, incident status) and do not support manual intervention; they evaluate conditions automatically, not wait for human approval. Option C is wrong because classic release pipelines with pre-deployment approvals are a legacy approach that still works, but the question asks for a strategy in the context of modern YAML-based multi-stage pipelines, where environment approvals are the recommended method. Option D is wrong because branch policies on the main branch control pull request merges and code quality, not release deployment approvals; they are unrelated to the release pipeline's manual approval requirement.

Full explanation →
166
Multi-Selecthard

Which TWO actions should you take to ensure that Azure Pipelines artifacts are scanned for vulnerabilities before production deployment? (Choose two.)

Select 2 answers
A.Run dependency scanning on the artifact manifest
B.Sign the artifacts with a code signing certificate
C.Use Microsoft Defender for Cloud to scan the artifact during the pipeline
D.Scan the infrastructure as code templates
E.Run static code analysis on the source code
AnswersA, C

Dependency scanning on the artifact manifest examines the SBOM or dependency lock files (e.g., package-lock.json, packages.lock.json) to identify known Common Vulnerabilities and Exposures (CVEs) in third-party libraries. In Azure Pipelines, this is done with tools like Trivy or OWASP Dependency Check, ensuring that the exact dependency versions that ship in the artifact are assessed for vulnerabilities.

Why this answer

For ensuring Azure Pipelines artifacts are scanned for vulnerabilities before production deployment, the correct actions are A and C. Option A: Running dependency scanning on the artifact manifest (e.g., package.json, pom.xml) identifies known vulnerabilities in open-source dependencies. Option C: Using Microsoft Defender for Cloud to scan artifacts (such as container images) during the pipeline provides comprehensive vulnerability detection.

Option B is incorrect because signing artifacts with a code signing certificate ensures integrity and authenticity, not vulnerability scanning. Option D is incorrect because scanning Infrastructure as Code (IaC) templates addresses configuration security, not artifact vulnerabilities. Option E is incorrect because static code analysis examines source code for coding flaws, not dependencies or artifacts.

Full explanation →
167
MCQhard

Your release pipeline uses deployment groups to deploy to Windows servers. You need to securely pass credentials to a script that runs on target machines. What is the recommended approach?

A.Hardcode credentials in the script and encrypt the script file
B.Store credentials as pipeline variables and reference them
C.Use Azure Key Vault task to fetch secrets during deployment
D.Use environment variables on the target machines
AnswerC

The Azure Key Vault task securely retrieves secrets from Key Vault at deployment time and injects them as variables, ensuring that credentials are not stored in the pipeline or exposed in logs while centralizing access and enabling rotation.

Why this answer

The Azure Key Vault task securely retrieves secrets (e.g., passwords) from an Azure Key Vault during deployment, avoiding hardcoded or exposed credentials. This integrates with Azure Pipelines to pass secrets to scripts without storing them in the pipeline or on target machines, adhering to least-privilege and secure secret management practices.

Exam trap

The trap here is that candidates may choose Option B (pipeline variables) thinking they are secure because they can be marked as secret, but they lack the centralized management, rotation, and access control that Azure Key Vault provides, which is the recommended approach for production secrets.

How to eliminate wrong answers

Option A is wrong because hardcoding credentials in a script, even if encrypted, violates security best practices and is difficult to rotate or audit; encryption keys can be compromised. Option B is wrong because pipeline variables, even marked as secret, are stored in the pipeline definition and can be exposed in logs or export operations, and they do not provide centralized secret management. Option D is wrong because environment variables on target machines are static, not centrally managed, and can be read by any process or user on the machine, leading to credential leakage.

Full explanation →
168
MCQhard

Your Azure DevOps project uses a self-hosted agent pool. Users report that builds are randomly failing with a 'disk full' error. The agents have 50 GB of disk space. What is the most effective way to mitigate this issue?

A.Add more agents to the pool
B.Use the 'Clean all build directories' option in the agent configuration
C.Enable the 'Clean after build' option on the build pipeline
D.Set 'Maximum number of parallel jobs' to 1
AnswerC

Enabling 'Clean after build' on the build pipeline triggers an automated workspace purge, typically using commands like `git clean -fdx` or equivalent, immediately after each job finishes. This removes source files, compiled outputs, test binaries, and cached dependencies from the agent's working directory (e.g., `_work`) at the point when they are no longer needed, so disk space is reclaimed on a per-build basis. This directly prevents the steady accumulation of stale build artifacts that ultimately exhausts the agent's local storage.

Why this answer

Enabling 'Clean after build' ensures workspace cleanup after each run, reclaiming disk space to prevent failures. Option A is wrong because adding more agents doesn't free disk space on existing agents. Option B is wrong because 'Clean all build directories' cleans before builds, which may not prevent mid-build disk full errors and can disrupt parallel builds.

Option D is wrong because limiting parallel jobs doesn't free disk space; a single build can still consume all available disk space.

Full explanation →
169
MCQmedium

Your team uses GitHub and wants to automatically close stale branches that have not been updated in 90 days. Which GitHub feature should you configure?

A.Create a scheduled GitHub Actions workflow that deletes branches older than 90 days
B.Auto-merge feature
C.Stale bot (GitHub Actions)
D.GitHub Discussions
AnswerA

A scheduled GitHub Actions workflow using the `schedule` event (cron) can run `git branch -d` commands or call the GitHub API to list branches filtered by `committer.date` older than 90 days, then delete them, automating branch cleanup at the repository level.

Why this answer

A is correct because GitHub Actions can be scheduled using cron syntax to run a workflow that identifies branches with no commits in the last 90 days and deletes them via the GitHub API. This gives you full control over the deletion logic, logging, and notifications, unlike a simple bot. The workflow can use actions like `actions/github-script` to enumerate branches and filter by `committer.date`.

Exam trap

The trap here is that candidates confuse the Stale bot (which handles issues/PRs) with branch management, assuming it can also delete branches, but it has no branch deletion capability.

How to eliminate wrong answers

Option B is wrong because the auto-merge feature automatically merges a pull request when required checks pass, but it does not delete stale branches. Option C is wrong because the Stale bot (GitHub Actions) is designed to mark issues and pull requests as stale and close them, not to delete branches. Option D is wrong because GitHub Discussions is a forum for conversations and does not provide any branch management or deletion capabilities.

Full explanation →
170
MCQeasy

You are setting up a release pipeline that deploys to multiple environments (dev, test, prod) sequentially. Each environment requires approval before deployment. What is the best way to implement this in Azure Pipelines?

A.Define pipeline stages with environment resources and pre-deployment approvals.
B.Use environment resources with 'auto' trigger and no approvals.
C.Use classic release pipelines with approval gates per environment.
D.Use a custom PowerShell script to pause and prompt for approval.
AnswerA

Defining stages with environment resources and pre-deployment approvals is the correct approach because each environment maps to a resource in Azure DevOps, and pre-deployment approvals provide a built-in, auditable manual sign-off before the deployment proceeds, making it the native and recommended YAML pipeline pattern.

Why this answer

Azure Pipelines supports multi-stage YAML pipelines where each stage can reference an environment resource. Pre-deployment approvals are configured on the environment itself, ensuring that before a stage deploys to that environment, the specified approvers must grant approval. This provides a native, auditable, and integrated approval gate without custom scripting or legacy tooling.

Exam trap

The trap here is that candidates may think classic release pipelines are still the best practice, but Microsoft has not deprecated classic releases; they are legacy and Microsoft recommends YAML pipelines with environment resources for better traceability, consistency, and integration with modern DevOps practices.

How to eliminate wrong answers

Option B is wrong because using 'auto' trigger with no approvals would automatically deploy to each environment without any manual intervention, failing the requirement for approval before deployment. Option C is wrong because classic release pipelines are a legacy approach; while they do support approval gates, the modern and recommended approach for multi-environment sequential deployments is to use YAML pipelines with environment resources and pre-deployment approvals. Option D is wrong because using a custom PowerShell script to pause and prompt for approval is brittle, non-auditable, bypasses the built-in approval workflow, and does not integrate with Azure Pipelines' environment resource tracking or deployment history.

Full explanation →
171
MCQmedium

Your organization requires compliance with SOC 2 and needs to audit all changes to Azure Pipelines. What should you enable?

A.Azure Policy
B.Microsoft Purview
C.Azure Blueprints
D.Azure DevOps audit logs
AnswerD

Azure DevOps audit logs capture security-relevant events such as pipeline run changes, permission modifications, and user access updates, and they can be exported to Log Analytics or SIEM tools for SOC 2 compliance. They provide the immutable, timestamped record of who did what and when, directly meeting the audit requirement.

Why this answer

Azure DevOps audit logs capture all changes to pipelines and can be exported for compliance with SOC 2. Option A is incorrect because Azure Policy enforces governance rules on Azure resources, not pipeline changes. Option B is incorrect because Microsoft Purview is a data governance service, not for auditing DevOps changes.

Option C is incorrect because Azure Blueprints (now deprecated) were used to define repeatable Azure environments, not for audit logging.

Full explanation →
172
MCQhard

Your team uses GitHub Actions for CI/CD and must ensure that only approved contributors can merge code to the main branch. You need to enforce a policy where every pull request must be reviewed by at least two members of the security team. Which branch protection rule should you configure?

A.Require pull request reviews before merging
B.Require status checks to pass before merging
C.Dismiss stale pull request approvals
D.Require a minimum number of reviewers
AnswerD

This enforces at least two reviewers from the security team.

Why this answer

The 'Require a minimum number of reviewers' branch protection rule in GitHub directly enforces that a specified number of reviewers must approve a pull request before it can be merged. By setting this minimum to two and restricting review permissions to the security team, you ensure that only approved security team members can authorize merges to the main branch, meeting the policy requirement.

Exam trap

The trap here is that candidates often confuse 'Require pull request reviews before merging' (which only requires at least one review) with the specific 'Require a minimum number of reviewers' rule, failing to recognize that the question explicitly demands a minimum of two reviewers from a specific team.

How to eliminate wrong answers

Option A is wrong because 'Require pull request reviews before merging' only mandates that at least one review is submitted, but it does not enforce a specific number of reviewers or restrict who can approve. Option B is wrong because 'Require status checks to pass before merging' is used to enforce CI/CD pipeline checks (e.g., tests, builds) and does not control human review requirements. Option C is wrong because 'Dismiss stale pull request approvals' automatically invalidates approvals after new commits, but it does not set a minimum number of reviewers or enforce security team involvement.

Full explanation →
173
MCQmedium

Your team uses Microsoft-hosted agents for builds. Recently, builds are taking longer to start. What is the best way to reduce queue times?

A.Increase the number of parallel jobs in the organization.
B.Use more pipeline triggers.
C.Provision self-hosted agents.
D.Reduce the number of parallel jobs.
AnswerC

Self-hosted agents are owned and managed by your team, providing dedicated compute capacity that operates independently of Microsoft's hosted agent pool. By registering self-hosted agents in an agent pool that your pipelines target, you can scale out processing capacity and reduce or eliminate queue waiting times, especially for high-frequency builds.

Why this answer

Microsoft-hosted agents share a global pool with other Azure DevOps organizations, so queue times increase during peak usage. Provisioning self-hosted agents gives you dedicated compute resources that are always available, eliminating dependency on the shared pool and reducing queue wait times.

Exam trap

The trap here is that candidates confuse 'parallel jobs' (concurrency limit) with 'agent availability' (queue wait time), assuming that buying more parallelism will speed up agent assignment when it only affects how many builds can run at once.

How to eliminate wrong answers

Option A is wrong because increasing parallel jobs only allows more builds to run concurrently once they start, but does not reduce the time a build waits in the queue for an available agent. Option B is wrong because pipeline triggers control when a build is initiated, not how quickly an agent is assigned to run it; more triggers could actually increase queue congestion. Option D is wrong because reducing parallel jobs would decrease the number of builds that can run simultaneously, likely increasing queue times further.

Full explanation →
174
MCQmedium

Your organization uses GitHub Actions for CI/CD. You want to enforce that all workflows pass required checks before a pull request can be merged. The repository is in an organization that uses GitHub Enterprise Cloud. What should you configure?

A.Add a branch protection rule that requires status checks to pass.
B.Enable 'Require approval for all workflows' in the organization settings.
C.Set the workflow to be required in the 'Require status check' settings of each pull request.
D.Create a repository ruleset that requires linear history.
AnswerA

Branch protection rules can enforce that all required checks pass before merging.

Why this answer

Branch protection rules in GitHub Enterprise Cloud allow you to require status checks to pass before merging a pull request. By configuring a branch protection rule on the target branch (e.g., main) and selecting the specific GitHub Actions workflow status checks that must succeed, you enforce that all required CI/CD checks pass before a merge is allowed. This directly meets the requirement to enforce workflow checks on pull requests.

Exam trap

The trap here is confusing organization-level workflow approval settings (which control workflow execution) with branch-level status check requirements (which control merge permissions), leading candidates to select option B or C instead of the correct branch protection rule.

How to eliminate wrong answers

Option B is wrong because 'Require approval for all workflows' is a setting that controls whether external contributors' workflows require approval before running, not a mechanism to enforce status checks on pull requests. Option C is wrong because there is no 'Require status check' setting on individual pull requests; status checks are configured at the branch or repository level via branch protection rules or rulesets. Option D is wrong because requiring linear history enforces a linear commit history (e.g., via rebase or squash merges) but does not enforce that workflows pass checks before merging.

Full explanation →
175
Multi-Selecthard

Which THREE are valid security best practices for Azure Pipelines? (Choose three.)

Select 3 answers
A.Restrict agent pool permissions to only necessary users
B.Use Microsoft Entra ID to control access to pipelines
C.Store secrets as plain text in YAML files
D.Use variable groups with Azure Key Vault integration for secrets
E.Run build agents on domain controllers
AnswersA, B, D

Least privilege principle applies to agent pools.

Why this answer

Restricting agent pool permissions to only necessary users follows the principle of least privilege, reducing the attack surface by ensuring only authorized personnel can register, manage, or use build agents. This prevents unauthorized access that could lead to code injection or credential theft.

Exam trap

The trap here is that candidates may think storing secrets in YAML files is acceptable if the repository is private, but Azure Pipelines explicitly warns against this because secrets can be exposed in pipeline logs, build artifacts, or through source control history.

Full explanation →
176
MCQhard

Your Azure DevOps pipeline deploys a microservice to a Kubernetes cluster using Helm. The Helm chart requires a values file that contains environment-specific configurations. You want to store the values file securely and use it during deployment. What is the recommended approach?

A.Store the values in a variable group and map them to Helm values.
B.Store the values file in Azure Key Vault and use the HelmDeploy task's 'overrideValues' parameter to set values.
C.Store the values file as a secure file in Azure Pipelines library.
D.Store the values file in a separate Git repository and clone it during the pipeline.
AnswerC

Secure files in the Azure Pipelines Library are encrypted at rest and can be downloaded during a pipeline run using the DownloadSecureFile task, which yields a temporary file path. This makes it the correct choice for storing a sensitive Helm values file because the original file never resides in source control and is exposed only as an encrypted library artifact.

Why this answer

Azure Pipelines Library's Secure Files feature allows storing files like Helm values securely and referencing them in pipeline tasks (e.g., HelmDeploy with the 'filePath' parameter). Option A is incorrect because variable groups store key-value pairs, not entire files. Option B is incorrect because the HelmDeploy task's 'overrideValues' parameter expects individual key-value overrides, not a file; Azure Key Vault is for secrets, but using it for a whole values file is not straightforward.

Option D is incorrect because storing the values file in a separate Git repository still exposes it to source control, reducing security compared to Secure Files.

Full explanation →
177
MCQeasy

You have an Azure DevOps pipeline that deploys to multiple environments. You need to ensure that approvals are required before production deployment. Which pipeline configuration should you use?

A.Set the pipeline trigger to 'Manual' only
B.Add a 'Manual Intervention' task in the pipeline
C.Configure branch policies on the main branch
D.Define an environment with required approvers for the production stage
AnswerD

Defining an environment with required approvers is the correct approach because Azure Pipelines environments provide pre-deployment approval checks that pause the pipeline before the production stage runs. Each deployment to that environment must be explicitly approved by the listed users or groups, creating an auditable, enforceable gate before any production release proceeds.

Why this answer

Azure DevOps environments allow you to define required approvers for a specific stage (e.g., production). When a pipeline deploys to that environment, it pauses and waits for manual approval before proceeding, ensuring that production deployments are gated by authorized personnel.

Exam trap

The trap here is that candidates confuse branch policies (which control code merging) with deployment approvals (which control release execution), leading them to select option C instead of the environment-based approval mechanism.

How to eliminate wrong answers

Option A is wrong because setting the pipeline trigger to 'Manual' only prevents automatic pipeline runs but does not enforce approvals during the deployment process; approvals are a separate gate mechanism. Option B is wrong because the 'Manual Intervention' task is a legacy feature that pauses the pipeline for manual input, but it is not designed for multi-environment approval workflows and does not integrate with Azure DevOps environment-based approval gates. Option C is wrong because branch policies on the main branch control code quality and pull request merges, not deployment approvals; they do not gate the release pipeline after code is merged.

Full explanation →
178
MCQhard

Your company uses Azure DevOps and must comply with SOC 2. The auditor requires proof that all production deployments went through a change management process with approval. What should you implement?

A.Use branch policies to require pull request approvals
B.Set pipeline retention policies to keep deployment records
C.Enable audit logging for all pipelines
D.Configure release approval gates in Azure Pipelines
AnswerD

Release approval gates in Azure Pipelines require designated approvers to explicitly approve a release stage before it continues, directly enforcing a formal sign-off step for production deployments—this aligns with SOC 2's change-management and authorization requirements by making approval a mandatory precondition.

Why this answer

Release approval gates in Azure Pipelines enforce a formal approval process before deployment, providing the required change management and approval evidence for SOC 2 audits. Option A is incorrect because branch policies control code changes, not deployments. Option B is incorrect because pipeline retention policies only manage artifact storage, not approval process.

Option C is incorrect because audit logging records events but does not enforce an approval process.

Full explanation →
179
Multi-Selecteasy

Which TWO strategies can you use to manage secrets in Azure Pipelines securely?

Select 2 answers
A.Use a variable group linked to Azure Key Vault.
B.Store secrets directly in the YAML pipeline file.
C.Use the 'secret' variable type in the pipeline UI.
D.Use environment variables in the build agent.
E.Print the secret in a script to verify it is correct.
AnswersA, C

A variable group linked to Azure Key Vault enables pipelines to reference secrets stored in Key Vault without never copying them into the pipeline definition. Access is governed by Azure RBAC, and secret values are dynamically retrieved at run time, keeping them out of source control and logs.

Why this answer

Options A and C are correct. Variable groups can be linked to Azure Key Vault to fetch secrets, and you can mark variables as secret in the pipeline UI to prevent them from being displayed in logs. Option B is wrong because storing secrets in YAML files exposes them in source control.

Option D is wrong because using environment variables on the build agent is not inherently secure; they can be accessed by other processes and may be logged. Option E is wrong because printing secrets in scripts exposes them in the pipeline logs, which is a security risk.

Full explanation →
180
MCQeasy

Your organization uses Microsoft Entra ID. You want to ensure that only users from specific countries can access Azure DevOps. Which security feature should you configure?

A.Microsoft Entra ID Conditional Access policies
B.Azure Network Security Group (NSG) rules
C.Azure DevOps security groups with allowed IP ranges
D.Microsoft Intune compliance policies
AnswerA

Microsoft Entra ID Conditional Access policies evaluate signals like user location, device state, and risk at sign-in time, allowing you to enforce restrictions such as blocking access from untrusted IP ranges or requiring MFA when users connect from outside the corporate network.

Why this answer

Microsoft Entra ID Conditional Access policies allow you to enforce location-based access controls by specifying allowed countries or IP ranges. By configuring a Conditional Access policy that targets Azure DevOps (as a cloud app) and setting the condition to 'Locations' with 'Selected countries,' you can restrict sign-ins to only users from those countries. This is the correct approach because Azure DevOps relies on Entra ID for authentication, and Conditional Access is the native mechanism to control access based on geographic location.

Exam trap

The trap here is that candidates often confuse network-level controls (NSGs) or IP allowlisting in Azure DevOps with identity-based location policies, overlooking that Conditional Access is the correct mechanism for restricting access by country in a SaaS context like Azure DevOps.

How to eliminate wrong answers

Option B is wrong because Azure Network Security Group (NSG) rules operate at the network layer (L3/L4) to filter traffic to Azure resources like VMs or virtual networks, but they cannot restrict user authentication to Azure DevOps, which is a SaaS service accessed over the internet. Option C is wrong because Azure DevOps security groups do not support IP range restrictions; IP allowlisting is configured at the organization level via 'Organization settings > Policies > Security policies,' not through security groups, and it applies to all users, not per-group. Option D is wrong because Microsoft Intune compliance policies are designed to enforce device compliance (e.g., OS version, encryption) for managed devices, not to restrict access based on user location or country.

Full explanation →
181
MCQeasy

Your team uses Azure Test Plans. You need to ensure that testers can easily see which test cases are blocked by a known bug. What should you do?

A.Configure the test plan to show only failed tests.
B.Create a test suite for each bug.
C.Link test cases to the bug and create a query for linked items.
D.Copy the test case and mark it as blocked.
AnswerC

Linking provides traceability.

Why this answer

Azure Test Plans allows test cases to be linked directly to bugs via work item linking. By creating a query for linked items (e.g., a shared query that returns all test cases linked to a specific bug), testers can instantly see which test cases are blocked by that known bug. This provides a dynamic, filterable view without duplicating or reorganizing test artifacts.

Exam trap

The trap here is that candidates often confuse 'marking a test as blocked' (a manual status change) with the proper traceability approach of linking work items, leading them to choose Option D or B instead of leveraging Azure DevOps' built-in query and linking capabilities.

How to eliminate wrong answers

Option A is wrong because configuring the test plan to show only failed tests does not indicate which failures are caused by a known bug; it simply filters out passed tests, leaving all failures regardless of root cause. Option B is wrong because creating a test suite for each bug would require manual duplication and maintenance of test cases, leading to redundancy and confusion when bugs are fixed or closed. Option D is wrong because copying a test case and marking it as blocked creates an unnecessary duplicate that must be manually tracked and updated, breaking the traceability between the original test case and the bug.

Full explanation →
182
MCQeasy

You have a pipeline that builds a Docker image and pushes it to Azure Container Registry. You need to ensure that only the latest successful build image is tagged as 'latest'. Which tagging strategy should you use?

A.Use a conditional step that runs only when the build succeeds to tag the image as 'latest'
B.Use the build ID as the tag and manually update 'latest'
C.Use the Git commit hash as the tag and push 'latest' separately
D.Always tag the image as 'latest' regardless of build status
AnswerA

This approach guarantees that the 'latest' tag is only moved after a fully successful build, using a condition such as `condition: succeeded()` to run a docker tag/push step. It ensures the image referenced by 'latest' is always a known-good artifact, avoiding the risk of tagging broken builds.

Why this answer

It ensures the 'latest' tag is applied only after a successful build, preventing broken or incomplete images from being tagged as 'latest'. In Azure Pipelines, you can use a condition like `condition: succeeded()` on a script or Docker task that runs `docker tag` and `docker push` to update the 'latest' tag only when the preceding build steps succeed. This maintains a reliable 'latest' pointer to the most recent stable image.

Exam trap

The trap here is that candidates may assume any tagging strategy that includes 'latest' is sufficient, overlooking the critical requirement that the tag must only be applied to successful builds, which is enforced by a conditional step.

How to eliminate wrong answers

Option B is wrong because manually updating the 'latest' tag introduces human error and operational overhead, and it does not automate the process to ensure only successful builds are tagged. Option C is wrong because using the Git commit hash as the tag is a valid strategy for traceability, but pushing 'latest' separately without a conditional check on build success could result in tagging a failed build as 'latest'. Option D is wrong because always tagging the image as 'latest' regardless of build status would overwrite the 'latest' tag with a broken or incomplete image, breaking downstream consumers that rely on 'latest' being a stable reference.

Full explanation →
183
Multi-Selecthard

A company uses Azure Monitor and Application Insights to monitor a microservices application deployed on Azure Kubernetes Service (AKS). The development team wants to implement distributed tracing to correlate requests across services. They currently have Application Insights SDKs instrumented in each service. Which TWO configurations are required to enable end-to-end distributed tracing?

Select 2 answers
A.Enable the Live Metrics Stream feature in Application Insights.
B.Ensure all services use the same Application Insights instrumentation key or connection string.
C.Configure adaptive sampling in the Application Insights SDK.
D.Ensure the SDKs are configured to propagate correlation headers (e.g., W3C Trace-Context).
E.Enable Application Map in the Azure portal for each service.
AnswersB, D

For distributed tracing, all services must send telemetry to the same Application Insights resource by using the same instrumentation key or connection string. This ensures that the operation IDs and parent IDs emitted by each service are stored in one logical table, allowing the trace to be stitched together across service boundaries. Using different keys on different services scatters telemetry into separate resources, making it impossible to correlate a request end-to-end even if trace-context headers are present. This is a necessary prerequisite, though not sufficient on its own.

Why this answer

All services must share the same Application Insights instrumentation key or connection string to ensure that telemetry from different microservices is correlated into a single application map and trace. Without a common instrumentation key, the distributed trace data would be siloed across separate Application Insights resources, preventing end-to-end correlation.

Exam trap

The trap here is that candidates often confuse enabling Application Map (a visualization) with the actual configuration needed for correlation, or they think adaptive sampling is required for tracing, when in fact the key requirements are a shared instrumentation key and header propagation.

Full explanation →
184
Multi-Selectmedium

Which TWO actions should you take to protect sensitive information (e.g., API keys, passwords) in Azure Pipelines? (Choose two.)

Select 2 answers
A.Store secrets in environment variables on the agent machine.
B.Define secrets as pipeline secret variables and reference them as $(secretName).
C.Store secrets in a YAML file and include the file in the repository.
D.Use plain text variables in the pipeline and mask them using the 'Logging Command' feature.
E.Use Azure Key Vault to store secrets and reference them via variable groups linked to Key Vault.
AnswersB, E

Pipeline secret variables are encrypted at rest by Azure DevOps and are masked in pipeline logs when referenced as $(secretName). Only tasks that explicitly reference the variable receive its value, and it is never exposed in the pipeline definition or logs, making this a secure method.

Why this answer

Azure Pipelines allows you to define secret variables in the pipeline UI or YAML, which are encrypted at rest and never exposed in logs. Referencing them as $(secretName) ensures they are securely injected at runtime without being stored in plaintext. Option E is correct because Azure Key Vault provides a centralized, audited, and encrypted store for secrets, and variable groups linked to Key Vault allow pipelines to fetch secrets dynamically without embedding them in pipeline definitions.

Exam trap

The trap here is that candidates may think masking secrets in logs (Option D) is sufficient, but masking does not protect the secret from being stored in plaintext in the pipeline definition or from being exposed in other output channels.

Full explanation →
185
Multi-Selecteasy

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

Select 3 answers
A.Schedule trigger
B.Pull request (PR) trigger
C.Continuous integration (CI) trigger
D.'on: push' trigger in YAML
E.Commit trigger
AnswersA, B, C

Schedule triggers are a first-class trigger mechanism in Azure Pipelines, enabling automated runs based on a cron schedule.

Why this answer

In Azure Pipelines, scheduled triggers, pull request triggers, and continuous integration (CI) triggers are all valid ways to trigger a pipeline. 'on: push' is GitHub Actions syntax, not Azure Pipelines, and 'commit trigger' is not a formal trigger type in Azure Pipelines.

Exam trap

Do not confuse Azure Pipelines trigger syntax with other CI systems. Azure Pipelines supports CI triggers, PR triggers, and scheduled triggers as first-class trigger types.

Full explanation →
186
MCQhard

Your pipeline builds a .NET application and runs unit tests. You notice that the pipeline takes too long because it restores NuGet packages on every run. You want to cache the NuGet packages to speed up subsequent builds. Which task should you use?

A.NuGetCommand@2 with the restore command
B.CopyFiles@2
C.PowerShell@2 to manually download and cache
D.Cache@2 (CacheBeta)
AnswerD

The Cache@2 task (formerly CacheBeta) is Azure DevOps' built-in caching solution; it restores a folder from a cache key, and if there is a miss, it saves the folder after the job completes. For a .NET application, you can cache the ~/.nuget/packages directory (NuGet package cache) to speed up subsequent restores, so it is the correct answer.

Why this answer

The Cache@2 (CacheBeta) task is specifically designed to cache folders or files between pipeline runs, such as NuGet packages, to reduce restore time. By caching the NuGet packages folder (e.g., $(UserProfile)/.nuget/packages), subsequent builds can skip the full restore and reuse previously downloaded packages, significantly speeding up the pipeline.

Exam trap

The trap here is that candidates often choose NuGetCommand@2 (Option A) thinking it inherently caches packages, but it only restores from remote sources each time unless combined with a separate caching task.

How to eliminate wrong answers

Option A is wrong because NuGetCommand@2 with the restore command only restores packages from sources; it does not cache them across pipeline runs. Option B is wrong because CopyFiles@2 is used to copy files from source to destination, not to manage caching of NuGet packages. Option C is wrong because PowerShell@2 can manually download and cache packages, but it requires custom scripting and lacks the built-in cache key, restore keys, and automatic hit/miss handling that Cache@2 provides, making it error-prone and less efficient.

Full explanation →
187
MCQmedium

Your pipeline uses the DotNetCoreCLI task to build a .NET Core application. You need to ensure that the build produces a self-contained deployment (SCD) for a Linux target. Which argument should you pass to the 'arguments' input of the task?

A.--configuration Release
B.--runtime linux-x64
C.--output $(Build.ArtifactStagingDirectory)
D.--self-contained true
AnswerB

The --runtime flag, along with --self-contained true in the project file, produces a self-contained deployment for the specified runtime.

Why this answer

The --runtime argument specifies the target runtime (linux-x64) and produces a self-contained deployment. Option A is wrong because --configuration specifies the build configuration, not the runtime. Option C is wrong because --output specifies the output directory, not the runtime.

Option D is wrong because while --self-contained true is a valid argument, it does not specify the target runtime; to target Linux specifically, you must use --runtime linux-x64 (which implies self-contained) or combine --runtime with --self-contained true.

Full explanation →
188
MCQmedium

Your release pipeline deploys to multiple Azure regions. You need to ensure that if a deployment to one region fails, the pipeline continues deploying to other regions. Which deployment strategy should you use?

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

Rolling deployment replaces instances incrementally across regions, keeping the previous version running in unaffected instances; if a region's batch fails health checks, Azure DevOps can stop that batch while other regions continue receiving updates, thereby tolerating regional failures and meeting the requirement to keep deploying.

Why this answer

Rolling deployment updates instances gradually across regions. If a deployment to one region fails, the pipeline can continue deploying to other regions because each region is updated independently. Option A (immutable deployment) replaces all instances at once, so a failure would halt the entire deployment.

Option C (blue-green) switches all traffic to a new environment; if that environment fails, the whole deployment fails. Option D (canary) routes a small percentage of traffic to a new version and rolls back if issues occur, but it does not ensure continued deployment to other regions upon failure.

Full explanation →
189
MCQeasy

Your organization uses GitHub Actions for CI/CD. You need to ensure that secrets are securely passed to workflows without being exposed in logs. What should you use?

A.GitHub Secrets
B.Environment variables in the workflow YAML
C.Hardcode the secrets in the workflow file
D.Azure Key Vault with Azure DevOps encrypted variables
AnswerA

GitHub Secrets are repository-level encrypted values that are never stored in the workflow file; GitHub encrypts each secret with a public key using the libsodium sealed box algorithm before storing it and exposes it to workflow runs only as the secrets context. During a run, GitHub injects the secret into the runner environment and automatically redacts its value from logs, and secrets are not available to pull requests from forks unless explicitly configured. This provides a secure, native mechanism for storing sensitive data like API tokens with per-environment scoping and rotation through the GitHub UI or API.

Why this answer

GitHub Secrets (Option A) is the correct choice because GitHub Actions provides a built-in secrets management system that encrypts sensitive values at rest and masks them in all workflow logs. When you reference a secret using ${{ secrets.MY_SECRET }}, GitHub automatically redacts the value from any log output, ensuring it is never exposed during execution.

Exam trap

The trap here is that candidates confuse Azure DevOps encrypted variables with GitHub Secrets, assuming Azure Key Vault integration works identically in GitHub Actions, when in fact GitHub Actions requires a separate action or manual API calls to fetch secrets from Azure Key Vault.

How to eliminate wrong answers

Option B is wrong because environment variables defined directly in the workflow YAML file are stored in plain text and can be printed or leaked in logs, offering no security for sensitive data. Option C is wrong because hardcoding secrets in the workflow file commits them to the repository history, making them visible to anyone with repository access and violating security best practices. Option D is wrong because Azure Key Vault with Azure DevOps encrypted variables is a valid approach for Azure Pipelines, but the question specifically asks about GitHub Actions, where Azure Key Vault integration is not natively supported without additional custom steps or third-party actions.

Full explanation →
190
MCQmedium

Refer to the exhibit. A developer creates a pipeline with this YAML. When a commit is pushed to the 'main' branch of the repository 'MyProject/MyRepo', the pipeline does NOT trigger. Which is the most likely cause?

A.The 'checkout: internal' step should use a different syntax.
B.The 'ref' property should be set to a commit SHA, not a branch name.
C.The branch specification 'main' is case-sensitive and should be 'Main'.
D.The 'internal' repository trigger requires a pipeline trigger to be enabled in the UI.
AnswerD

For a repository resource trigger to fire, the pipeline's overall Continuous Integration trigger must be enabled in the Azure DevOps UI, not just the YAML trigger under 'resources'. When the CI trigger is turned off, Azure Pipelines ignores both the pipeline-section branch filters and the repository resource trigger configurations. Because the pipeline trigger may be disabled in the UI, this statement identifies the actual root cause and is therefore correct.

Why this answer

When using the 'internal' repository type in Azure Pipelines YAML, the pipeline must have a 'Pipeline trigger' explicitly enabled in the UI settings. The YAML 'trigger' branch specification alone is insufficient for 'internal' repositories; the UI trigger acts as a required gate. Without this UI setting, commits to 'main' will not initiate the pipeline.

Exam trap

The trap here is that candidates assume the YAML 'trigger' block alone is sufficient to enable CI for any repository type, but Azure Pipelines requires an additional UI-based trigger enablement for internal Azure Repos, which is a subtle but critical distinction.

How to eliminate wrong answers

Option A is wrong because 'checkout: internal' is a valid syntax for checking out an internal Azure Repos repository; there is no alternative syntax required. Option B is wrong because the 'ref' property in a trigger can be set to a branch name (e.g., 'refs/heads/main') and does not require a commit SHA. Option C is wrong because branch names in Azure Repos are case-insensitive by default; 'main' and 'Main' are treated as the same branch.

Full explanation →
191
MCQmedium

Your team uses Azure Pipelines to build a React application. The build process runs npm install, npm test, and npm run build. The build succeeds, but the application loads slowly in the browser due to large bundle sizes. What should you add to the pipeline to optimize the build?

A.Add a step to cache the node_modules folder.
B.Add a step to minify JavaScript using Terser.
C.Add a step to run Webpack bundle analyzer and implement code splitting.
D.Add a step to run additional unit tests to catch performance issues.
AnswerC

Running Webpack Bundle Analyzer generates a visual treemap of module and dependency sizes, which helps identify large libraries or accidental duplicates that inflate the bundle. Implementing code splitting via dynamic imports or SplitChunksPlugin then breaks the single bundle into smaller lazy-loaded chunks, directly reducing the initial bundle size and improving load performance.

Why this answer

The issue is large bundle sizes causing slow load times. Running Webpack bundle analyzer identifies which modules contribute most to the bundle, and implementing code splitting (e.g., dynamic imports or React.lazy) allows splitting the bundle into smaller chunks loaded on demand, reducing initial payload size.

Exam trap

The trap here is that candidates confuse build optimization (caching, minification) with bundle size optimization, overlooking that code splitting directly addresses the symptom of slow loading due to large bundles.

How to eliminate wrong answers

Option A is wrong because caching node_modules speeds up the npm install step but does not reduce bundle size or address slow loading in the browser. Option B is wrong because minifying JavaScript with Terser reduces file size only slightly (by removing whitespace and shortening variable names) and does not address the root cause of large bundle sizes from monolithic chunks. Option D is wrong because additional unit tests do not affect bundle size or runtime performance; they only verify code correctness.

Full explanation →
192
MCQmedium

You have a multi-stage YAML pipeline that deploys to Azure App Service. The deployment to the production stage should only proceed if a manual approval is granted. How should you configure this?

A.Use deployment gates with Azure Monitor metrics
B.Configure branch policies on the main branch
C.Add a pipeline decorator to require sign-off
D.Add an approval check on the production environment
AnswerD

Adding an approval check on the production environment in Azure Pipelines creates a manual gate that halts the deployment before it runs, requiring an authorized user to explicitly approve or reject the release. This is the proper native mechanism for enforcing human sign-off on a production deployment in a multi-stage YAML pipeline.

Why this answer

Azure Pipelines supports approval checks on environments, which allow you to require manual approval before a deployment proceeds to a specific stage. By adding an approval check on the production environment, the pipeline will pause at that stage until an authorized user grants approval, meeting the requirement for manual sign-off before production deployment.

Exam trap

The trap here is that candidates often confuse deployment gates (automated health checks) with manual approvals, or mistakenly think branch policies or pipeline decorators can enforce stage-level sign-off, when only environment-level approval checks provide the required manual approval workflow.

How to eliminate wrong answers

Option A is wrong because deployment gates with Azure Monitor metrics are used for automated health checks (e.g., monitoring error rates or latency) and do not provide manual approval functionality; they are designed for automatic validation, not human sign-off. Option B is wrong because branch policies on the main branch control code merging (e.g., requiring pull request reviews) but have no effect on pipeline deployment approvals after the code is merged; they do not gate deployment stages. Option C is wrong because a pipeline decorator is a mechanism to inject additional steps or tasks into every pipeline run (e.g., for compliance scanning) but cannot enforce manual approval; it is not a replacement for environment-level approval checks.

Full explanation →
193
MCQeasy

You need to automatically run a security scan on every pull request in GitHub. The scan should block the PR if critical vulnerabilities are found. Which GitHub feature should you use?

A.GitHub Code Scanning with a CodeQL workflow
B.Dependabot version updates
C.Secret scanning
D.Branch protection rules with required status checks
AnswerA

GitHub Code Scanning with a CodeQL workflow is the correct answer because CodeQL performs semantic analysis of your source code, identifying vulnerabilities such as SQL injection, cross-site scripting, and path traversal. When configured in a GitHub Actions workflow with an `on: pull_request` trigger, CodeQL runs on every pull request and surfaces results directly as a check run in the PR's checks interface. These check runs can then be required by branch protection rules, meaning a pull request is blocked from merging until CodeQL reports no security issues, providing a true automated code-security gate.

Why this answer

GitHub Code Scanning with a CodeQL workflow is the correct choice because it allows you to define a custom security analysis that runs on every pull request. By configuring the workflow to fail on critical-severity alerts, the pull request is automatically blocked, preventing vulnerable code from being merged. This integrates directly with GitHub's checks API to enforce the scan result as a required status check.

Exam trap

The trap here is that candidates often confuse Dependabot (which handles dependency updates) or branch protection rules (which enforce checks) with the actual scanning tool, forgetting that Code Scanning with CodeQL is the specific feature that performs the security analysis and can block PRs based on vulnerability severity.

How to eliminate wrong answers

Option B is wrong because Dependabot version updates only automate the creation of pull requests to update outdated dependencies; it does not perform security scanning or block PRs based on vulnerabilities. Option C is wrong because Secret scanning is a passive detection feature that alerts on exposed secrets (e.g., API keys) in repositories, but it does not run on every pull request or block PRs. Option D is wrong because branch protection rules with required status checks are a mechanism to enforce that certain checks pass, but they do not themselves perform any security scanning; they rely on an external check like CodeQL to provide the status.

Full explanation →
194
Multi-Selecteasy

Your team wants to implement automated testing in the build pipeline. You need to ensure that tests run and results are published. Which TWO tasks should you include?

Select 2 answers
A.Publish Build Artifacts task
B.Copy Files task
C.Visual Studio Test task
D.Publish Test Results task
E.Azure PowerShell task
AnswersC, D

The Visual Studio Test task is the correct choice because it uses vstest.console.exe to run unit tests from test assemblies (MSTest, xUnit, NUnit) and produces test result data (e.g., TRX). It is the built-in Azure Pipelines task that actually executes tests during the build.

Why this answer

The correct tasks are Visual Studio Test task (option C) which runs the tests, and Publish Test Results task (option D) which publishes the test results to Azure Pipelines. Option A (Publish Build Artifacts) publishes build outputs but not test results. Option B (Copy Files) copies files between locations and does not run tests.

Option E (Azure PowerShell) runs PowerShell scripts and is not for testing.

Full explanation →
195
Matchingmedium

Match each Azure Repos policy to its enforcement.

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

Concepts
Matches

Ensures at least N reviewers approve

Requires PR to be associated with a work item

Requires all comments to be resolved before merge

Requires a successful pipeline run before merge

Why these pairings

The correct matches are A, B, C, D. Policy A requires at least two reviewers. Policy B requires linked work items.

Policy C requires a successful build. Policy D limits merge types. Policies E and F are incorrect because they swap the descriptions: E describes merge types but is labeled as reviewer count, and F describes reviewer count but is labeled as work item linking.

Exam trap

Candidates often confuse the 'Require a minimum number of reviewers' policy with merge type restrictions, and 'Check for linked work items' with reviewer approval.

Full explanation →
196
Multi-Selecteasy

Which TWO triggers can be used to start a release pipeline in Azure DevOps?

Select 2 answers
A.Continuous integration trigger
B.Scheduled release trigger
C.Continuous deployment trigger
D.Pull request trigger
E.Branch policy trigger
AnswersB, C

Scheduled trigger starts a release at a specified time.

Why this answer

B is correct because a scheduled release trigger allows you to define a recurring time (e.g., daily at 2:00 AM) to automatically start a release pipeline, which is essential for scenarios like nightly builds or periodic deployments. C is correct because a continuous deployment trigger automatically starts a release pipeline whenever a new build artifact is available from a linked build pipeline, enabling immediate deployment after a successful build. Both triggers are native to Azure Pipelines and are configured directly on the release pipeline's 'Triggers' tab.

Exam trap

The trap here is that candidates confuse 'continuous integration trigger' (which starts a build) with 'continuous deployment trigger' (which starts a release), and also mistakenly think 'pull request trigger' or 'branch policy trigger' can initiate a release pipeline when they are actually build/repository-level triggers.

Full explanation →
197
MCQhard

A team uses Terraform to manage Azure infrastructure. They want to store the Terraform state file securely and enable collaboration. What is the recommended approach?

A.Store the state file in an Azure Storage account with state locking enabled
B.Store the state file in a local folder and commit to Git
C.Store the state file in Terraform Cloud
D.Store the state file in a Git repository with manual locking
AnswerA

Azure Storage provides remote state with leasing for locking, ensuring consistency.

Why this answer

Storing the Terraform state file in an Azure Storage account with state locking enabled is the recommended approach because it provides a centralized, durable backend that supports native state locking via Azure Blob Storage leases. This prevents concurrent modifications and state corruption, enabling safe collaboration among team members. Azure Storage also offers encryption at rest and access control via RBAC, aligning with security best practices for infrastructure-as-code.

Exam trap

The trap here is that candidates often assume Terraform Cloud is always the best remote backend, but the question specifies Azure infrastructure, and the recommended approach for Azure is the native Azure Storage backend due to its tight integration, lower latency, and no additional licensing cost.

How to eliminate wrong answers

Option B is wrong because storing the state file in a local folder and committing it to Git exposes sensitive data (e.g., plaintext secrets, resource IDs) in version control and lacks state locking, leading to corruption if multiple team members run Terraform simultaneously. Option C is wrong because while Terraform Cloud is a valid remote backend, the question specifically asks for the recommended approach for Azure infrastructure, and the Azure Storage backend is the native, cost-effective, and fully integrated solution within Azure; Terraform Cloud introduces an external dependency and additional cost. Option D is wrong because storing the state file in a Git repository with manual locking does not prevent concurrent writes—Git does not provide distributed locking, and manual coordination is error-prone and unscalable, risking state conflicts.

Full explanation →
198
MCQmedium

Your Azure DevOps pipeline uses the 'DotNetCoreCLI@2' task to run unit tests. Some tests are failing intermittently. You suspect test flakiness due to race conditions. What should you do to automatically retry failed tests without rewriting the tests?

A.Use the 'VSTest@2' task with 'retryFailedTests: true' option.
B.Create a custom script that runs each test individually and retries on failure.
C.Enable 'test retry' in the pipeline settings under 'General'.
D.Wrap the test task in a 'Retry' loop using a 'each' expression.
AnswerA

The VSTest@2 task supports automatic retry of failed tests.

Why this answer

The 'VSTest@2' task in Azure DevOps includes a built-in 'retryFailedTests' property that automatically re-runs failed tests a specified number of times. This directly addresses intermittent test flakiness caused by race conditions without requiring any code changes to the tests themselves. The 'DotNetCoreCLI@2' task does not support this retry mechanism, so switching to 'VSTest@2' is the appropriate solution.

Exam trap

The trap here is that candidates may assume the 'DotNetCoreCLI@2' task has a retry option or that a generic pipeline setting exists for test retries, when in fact only the 'VSTest@2' task provides this specific capability, and the other options are either non-existent or overly complex workarounds.

How to eliminate wrong answers

Option B is wrong because creating a custom script that runs each test individually and retries on failure is unnecessarily complex, time-consuming, and error-prone; it also bypasses the built-in retry functionality provided by Azure DevOps, which is simpler and more reliable. Option C is wrong because there is no 'test retry' setting under 'General' in pipeline settings; this option is a fabrication and does not exist in Azure DevOps. Option D is wrong because wrapping the test task in a 'Retry' loop using an 'each' expression is not a valid syntax or feature in Azure DevOps YAML pipelines; the 'each' keyword is used for iterating over parameters, not for retrying tasks, and this approach would not correctly retry only failed tests.

Full explanation →
199
MCQmedium

Your Azure DevOps pipeline uses a variable group to store secrets. The variable group is linked to a Key Vault. You need to use a secret variable in a pipeline task. How should you reference the secret in the YAML pipeline?

A.Reference the variable as $(VariableName) but only in a script task using 'env' mapping.
B.Use the 'task.getVariable' method in a PowerShell script.
C.Reference the variable as $(VariableName) in the pipeline tasks.
D.Use the Azure Key Vault task to retrieve the secret and then reference the output variable.
AnswerC

Once an Azure Key Vault variable group is linked, its secrets are automatically surfaced as pipeline variables, so you can reference them directly in any task using the macro syntax $(VariableName). This works because Azure Pipelines resolves the macro during runtime, injecting the secret's value into the task before it executes, without needing a separate Key Vault task or explicit service connection in each task.

Why this answer

When a variable group is linked to an Azure Key Vault, secret variables are automatically available in the pipeline. You can reference them directly using the standard $(VariableName) syntax in any pipeline task. No special task or script is required.

Option A is incorrect because you do not need to restrict to script tasks or use 'env' mapping; the $(VariableName) works everywhere. Option B is incorrect because 'task.getVariable' is a scripting method used within tasks, not a YAML syntax. Option D is incorrect because the Azure Key Vault task is unnecessary; the variable group handles the retrieval automatically.

Full explanation →
200
Multi-Selecthard

Your organization uses Azure Pipelines with Microsoft-hosted agents. The pipeline runs a .NET Core application build. You notice that the build takes longer than expected. Which THREE actions can you take to improve build performance? (Choose three.)

Select 3 answers
A.Add more build steps to the pipeline.
B.Enable caching for NuGet packages.
C.Increase the number of parallel jobs in the pipeline.
D.Use multi-stage build with parallel test execution.
E.Use a self-hosted agent with pre-installed dependencies.
AnswersB, D, E

Caching NuGet packages in Azure Pipelines stores restored packages in a local cache keyed by your package lock files, so subsequent builds restore them from the cache instead of downloading from nuget.org. This dramatically reduces restore time and network latency, directly shortening the overall build duration.

Why this answer

Enabling NuGet package caching reduces build time by avoiding repeated downloads of packages. Using a self-hosted agent with pre-installed dependencies eliminates the need to install and download tools on each run, further reducing overhead. Additionally, structuring the pipeline as a multi-stage build and running tests in parallel across multiple agents can significantly shorten overall pipeline duration by executing independent test suites concurrently.

Together, these optimizations improve build performance.

Exam trap

The trap here is that candidates often confuse increasing parallel jobs (which affects concurrency) with optimizing a single pipeline's execution time, leading them to incorrectly select option C.

Full explanation →
201
MCQmedium

Refer to the exhibit. A developer is on the 'feature/login' branch and wants to integrate the latest changes from 'feature/user-profile' without creating a merge commit. Which Git command should the developer use?

A.git rebase origin/feature/user-profile
B.git pull --rebase origin main
C.git merge origin/feature/user-profile
D.git cherry-pick 9f8e7d6..8a7b6c5
AnswerA

git rebase origin/feature/user-profile is correct because it replays the unique commits from the current feature/login branch on top of the latest commits from origin/feature/user-profile, creating a linear history without a merge commit while preserving the login-specific changes.

Why this answer

To integrate changes from another branch without a merge commit, rebase is appropriate. The developer can rebase feature/login onto feature/user-profile (or onto main after merging user-profile). However, the exhibit shows that feature/user-profile is already merged into main, so rebasing feature/login onto main is also valid.

The simplest is to rebase feature/login onto main, but that would include all changes. Alternatively, rebasing feature/login onto feature/user-profile directly would also work, but since user-profile is merged into main, rebasing onto main is common. The correct answer is rebase.

Full explanation →
202
MCQmedium

Refer to the exhibit. You have a branch policy JSON for Azure Repos. Which statement about this policy is correct?

A.The last person who pushed can approve the pull request.
B.At least two reviewers must approve the pull request.
C.Pull requests to main are automatically squash-merged.
D.Approvals are reset when the source branch is updated.
AnswerB

The branch policy sets requireApprovalCount to 2, meaning that two distinct reviewers (excluding those blocked by policy) must independently approve the PR before it can be completed. This is the correct interpretation of the policy.

Why this answer

The branch policy JSON specifies `minimumApproverCount: 2`, which enforces that at least two distinct reviewers must approve the pull request before it can be completed. This is a standard Azure Repos branch policy setting that controls the required number of approvals, not the identity of the approvers or the merge strategy.

Exam trap

The trap here is that candidates assume the last person who pushed can always approve, but Azure Repos defaults to blocking that unless explicitly overridden, and the policy JSON shown does not include the override setting.

How to eliminate wrong answers

Option A is wrong because Azure Repos branch policies do not automatically allow the last pusher to approve; unless explicitly allowed via the 'Allow approvers to approve their own changes' setting, the last person who pushed is typically blocked from approving. Option C is wrong because the JSON does not set a merge strategy; squash-merge is a separate policy option not shown here. Option D is wrong because the policy does not include `resetOnSourcePush: true`; without that setting, approvals are not automatically reset when the source branch is updated.

Full explanation →
203
Multi-Selecthard

You are designing a pipeline that must run tasks in a container. The container needs access to Azure resources using a managed identity. Which two configurations are required? (Choose two.)

Select 1 answer
A.Enable a system-assigned managed identity on the agent VM.
B.Use the 'docker login' command in the pipeline.
C.Add a service principal connection to the pipeline.
D.Set the 'identity' field in the container resource definition.
E.Use the Azure CLI task with '–identity' flag.
AnswersA

Enabling a system-assigned managed identity on the agent VM allows the container to use the IMDS endpoint to request tokens for Azure resources without storing credentials.

Why this answer

Enabling a system-assigned managed identity on the agent VM allows the container job to use the Azure Instance Metadata Service (IMDS) endpoint to obtain tokens for authenticating to Azure resources without storing credentials. Option D is incorrect because Azure Pipelines container job resource definitions do not have an 'identity' field; the identity is inherited from the agent VM.

Exam trap

The trap here is that candidates confuse pipeline-level authentication (service principal connections) with container-level identity assignment, or think that a Docker login or Azure CLI flag can substitute for the explicit identity configuration on the container resource.

Why the other options are wrong

B

docker login is for authentication to a container registry, not for Azure resources.

C

Service principal connection is for non-managed identity authentication; managed identity avoids storing credentials.

E

The Azure CLI task can use managed identity, but the configuration requires the identity to be assigned and the task to run inside the container.

Full explanation →
204
Multi-Selectmedium

You are designing a multi-stage YAML pipeline for an application that requires approval for production deployment. The pipeline must run automatically for non-production stages. Which TWO configurations should you use?

Select 2 answers
A.Set the pipeline trigger to include branches used for non-production stages.
B.Define a stage for production with an 'approvals' block.
C.Use a release pipeline instead of a YAML pipeline.
D.Set the pipeline to require manual approval for every stage.
E.Use a single-stage pipeline with conditional approval.
AnswersA, B

Setting the pipeline trigger to include branches used for non-production stages means CI will automatically run the pipeline for changes to develop/feature branches, allowing non-production stages (e.g., build, test, staging) to execute without manual intervention. This is correct in a multi-stage YAML design where automated progression is desired for non-production while production remains approval-gated.

Why this answer

Options A and B are correct. Option A: Setting the pipeline trigger to include branches used for non-production stages enables automatic CI triggers for those branches, so non-production stages run automatically. Option B: Adding an 'approvals' block to the production stage enforces manual approval before deployment to production.

Options C, D, and E are incorrect: C suggests using a release pipeline which is unnecessary; D would require manual approval for every stage, not just production; E describes a single-stage pipeline, which doesn't fit the multi-stage requirement.

Full explanation →
205
MCQmedium

Your release pipeline deploys a .NET Core web app to Azure App Service using a deployment slot for staging. The pipeline runs integration tests against the staging slot. After tests pass, you want to swap the staging slot with production. However, the swap fails sometimes because the staging slot has different configuration settings. What is the best practice to ensure swapping succeeds?

A.Use slot-specific configuration settings (deployment slot settings) for connection strings and app settings that differ between slots.
B.Manually update the production slot settings to match staging before each swap.
C.Perform a swap with preview and then complete the swap after verifying the staging slot.
D.Write a custom PowerShell script to copy configuration from staging to production before swapping.
AnswerA

In Azure App Service, deployment slot settings are marked as 'sticky' so they remain with the slot during swap, ensuring correct connection strings and app settings are applied regardless of swap. This prevents configuration mismatches and eliminates the need for manual updates or scripts. By defining slot-specific settings, production continues to use its intended values while staging uses its own, making swap safe.

Why this answer

Azure App Service allows you to mark specific configuration settings (like connection strings and app settings) as 'deployment slot settings.' When a setting is marked as slot-specific, it stays with the slot during a swap, preventing failures caused by mismatched configurations. This ensures that the staging slot retains its test-specific settings (e.g., a test database connection string) while the production slot keeps its own settings, making the swap predictable and reliable.

Exam trap

The trap here is that candidates often confuse 'swap with preview' (which is about validation and rollback) with the root cause of swap failures, not realizing that slot-sticky settings are the proper mechanism to prevent configuration conflicts during a swap.

How to eliminate wrong answers

Option B is wrong because manually updating production slot settings before each swap is error-prone, violates infrastructure-as-code principles, and introduces downtime or misconfiguration risks. Option C is wrong because swap with preview is a technique to validate the swap outcome, not a solution for configuration mismatches; it does not prevent swap failures caused by slot-specific settings. Option D is wrong because writing a custom PowerShell script to copy configuration is unnecessary complexity and defeats the purpose of Azure's built-in slot-sticky settings; it also risks overwriting production settings unintentionally.

Full explanation →
206
MCQeasy

You are responsible for a release pipeline that deploys a containerized application to Azure Kubernetes Service (AKS). The pipeline currently builds and pushes a Docker image to Azure Container Registry (ACR) and then updates the Kubernetes manifest. You need to implement a rollback strategy in case the deployment fails. The rollback should revert to the previous known good version of the application. Which approach should you use?

A.Keep the previous Docker image tag in ACR and update the manifest to point to it manually.
B.Rerun the previous successful pipeline run.
C.Use the Kubernetes task with the 'rollback' option, which runs 'kubectl rollout undo' on the deployment.
D.Use Helm to manage releases and rollback using 'helm rollback' command.
AnswerC

The Kubernetes task's 'rollback' option invokes 'kubectl rollout undo deployment/<name>', which instructs the Kubernetes Deployment controller to revert to the previously recorded ReplicaSet revision. This restores the exact previous pod template (image, env vars, labels, etc.) automatically and is the built-in, native rollback mechanism for Deployments.

Why this answer

'kubectl rollout undo' is a native Kubernetes feature that automatically reverts the deployment to the previous ReplicaSet, providing a simple and reliable rollback without manual intervention or additional tools. Option A is manual and not automated. Option B re-runs the entire pipeline, which may build a new image and not truly revert to the previous version.

Option D uses Helm, which adds complexity when native rollback is sufficient.

Full explanation →
207
MCQhard

Refer to the exhibit. A pipeline in repository 'MyProject/AppRepo' is configured to trigger when changes are pushed to 'SharedRepo'. A developer pushes a commit to the 'release/v1' branch of 'SharedRepo'. What will happen?

A.The pipeline will trigger only if the commit also includes changes to 'main'.
B.The pipeline will fail because the trigger configuration is invalid.
C.The pipeline will trigger because 'release/v1' matches the 'release/*' include pattern.
D.The pipeline will not trigger because 'release/v1' is not explicitly listed.
AnswerC

The 'release/*' include pattern is a wildcard that matches any branch name beginning with 'release/' and containing any characters after the slash. Because 'release/v1' starts with 'release/', it matches the pattern, satisfying the branch trigger and causing the pipeline to trigger on that branch.

Why this answer

The trigger includes branches matching 'main' and 'release/*'. 'release/v1' matches the wildcard 'release/*', so the pipeline in AppRepo will be triggered.

Full explanation →
208
MCQeasy

Your team uses Azure DevOps and wants to enforce that all changes to the main branch go through a pull request process with at least two approvals. They also want to prevent contributors from approving their own pull requests. Which branch policy settings should they use?

A.Enable 'Check for linked work items' and 'Require a minimum number of reviewers' set to 2, and enable 'Reset code reviewer votes when new changes are pushed'.
B.Add the 'main' branch to the 'Required reviewers' list and add all developers as required reviewers.
C.Enable 'Require a minimum number of reviewers' set to 2, and enable 'Build validation' with a required build.
D.Enable 'Require a minimum number of reviewers' set to 2, and enable 'Allow users to approve their own changes' unchecked (or set to false).
AnswerD

Setting the minimum reviewers to two forces at least two approvals, while unchecking 'Allow users to approve their own changes' prevents the author from counting as one of them, thereby enforcing authentic peer review from two distinct eligible reviewers.

Why this answer

It directly addresses both requirements: setting 'Require a minimum number of reviewers' to 2 enforces at least two approvals, and unchecking 'Allow users to approve their own changes' prevents contributors from approving their own pull requests. These are branch policy settings within Azure Repos that control the pull request workflow on the main branch.

Exam trap

The trap here is that candidates often confuse 'Require a minimum number of reviewers' with 'Required reviewers' (a static list) or think that build validation alone satisfies the approval requirement, missing the need to explicitly disable self-approval.

How to eliminate wrong answers

Option A is wrong because 'Check for linked work items' ensures traceability but does not enforce the number of approvals or prevent self-approval; 'Reset code reviewer votes when new changes are pushed' is unrelated to the approval count or self-approval restriction. Option B is wrong because adding the 'main' branch to 'Required reviewers' and listing all developers as required reviewers would force every developer to be a reviewer on every PR, which is impractical and does not enforce a minimum of two approvals or prevent self-approval. Option C is wrong because 'Build validation' ensures code quality via automated builds but does not control the number of human approvals or self-approval behavior.

Full explanation →
209
MCQmedium

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

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

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

Why this answer

Microsoft Purview Information Protection provides built-in data classification and labeling capabilities that can automatically scan Azure DevOps repositories for sensitive data such as PII. It uses sensitive information types and machine learning classifiers to detect patterns like social security numbers or credit card numbers, then applies the appropriate sensitivity label directly to the source code files. This meets the compliance team's requirement for automatic classification and labeling without custom development.

Exam trap

The trap here is that candidates often confuse Microsoft Purview Information Protection (which handles data classification and labeling) with Azure Policy (which handles resource governance) or Microsoft Defender for Cloud (which handles security posture), leading them to select a tool that cannot perform content-level scanning or labeling.

How to eliminate wrong answers

Option A is wrong because Azure Policy is used to enforce organizational standards and assess compliance at the resource level (e.g., requiring HTTPS on repos), but it cannot scan file contents or apply sensitivity labels to source code. Option C is wrong because Microsoft Sentinel is a SIEM/SOAR tool for security incident detection and response, not for scanning and labeling data within Azure DevOps repositories. Option D is wrong because Microsoft Defender for Cloud focuses on cloud security posture management and workload protection (e.g., vulnerability scanning, threat detection), not on classifying or labeling PII in source code.

Full explanation →
210
MCQmedium

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

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

Delete the feature branch. In GitHub Flow, feature branches are ephemeral and should be deleted after their pull request is merged, because the merge already integrates all commits into main; leaving the branch creates stale references and confusion for future work.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
211
MCQeasy

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

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

Branch protection rules with required status checks enforce that a pull request cannot be merged until the specified GitHub Actions checks (reported as commit statuses, e.g., from a job's `check_run` or `status` context) succeed. The protected branch's `required_status_checks` context verifies the list of checks, and the merge is rejected if any required check is failing, pending, or absent — this is the correct GitHub-native mechanism for CI gating.

Why this answer

Branch protection rules with required status checks enforce that all configured GitHub Actions workflows must pass before a pull request can be merged. This ensures that any workflow defined in the repository (e.g., CI, linting, security scans) produces a successful check run, and the merge is blocked if any required check fails or is pending.

Exam trap

The trap here is confusing workflow triggers (which control when automation runs) with branch protection rules (which enforce that automation results are satisfied before merging).

How to eliminate wrong answers

Option A is wrong because workflow triggers (e.g., push, pull_request) define when a workflow runs, not whether its results block a merge. Option C is wrong because required reviewers enforce manual approval from specific people, not automated workflow checks. Option D is wrong because environment protection rules control deployments to specific environments (e.g., production) and do not gate pull request merges based on workflow status.

Full explanation →
212
Multi-Selectmedium

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

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

Approvals and checks on environments are pre-deployment gates that require designated reviewers or automated checks to approve before a release proceeds; this ensures separation of duties by allowing one group to create a release and a different group to approve it, and checks can enforce policies like branch protection.

Why this answer

Approvals and checks on environments (B) enforce separation of duties by requiring designated approvers (e.g., operations team members) to approve a deployment before it proceeds, ensuring that development cannot directly push to production. Environment security roles (D) allow you to define who can create, view, or manage environments, restricting developers from modifying production environments without operations oversight.

Exam trap

The trap here is that candidates confuse branch policies (which govern code merging) with deployment approvals (which govern release to environments), leading them to select branch policies instead of environment security roles or approvals.

Full explanation →
213
MCQmedium

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

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

This ensures only changes to that path get additional review.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
214
Multi-Selectmedium

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

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

Linking variable groups to Azure Key Vault is the recommended way to manage secrets and non-sensitive configuration centrally; it stores values securely in Key Vault, supports access control, auditing, and automatic rotation, and references them in pipelines without exposing secrets in source control.

Why this answer

Options A and B are correct because variable groups provide a centralized and secure way to manage configuration across multiple environments and pipelines. Option A uses Azure Key Vault for secrets, integrating with access policies and rotation, while option B stores non-sensitive environment-specific settings. Option C is incorrect because XML transformation targets web.config files, which are legacy .NET artifacts and not typical for modern microservices that use JSON, YAML, or environment variables.

Option D is incorrect because stage-level variables are scoped to a single pipeline definition and do not offer a reusable, centralized configuration mechanism across different environments or pipelines; variable groups are designed for that purpose.

Exam trap

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

Why the other options are wrong

C

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

D

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

Full explanation →
215
MCQeasy

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

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

The built-in Azure Pipelines Teams integration lets you subscribe to build pipeline events, such as a failed build, and delivers an adaptive card notification directly to a configured Teams channel. This native subscription uses Azure DevOps service hooks to Teams internally, requiring no custom code, Logic Apps, or extra configuration, and is the canonical solution for notifying Teams of build failures.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
216
MCQmedium

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

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

Git LFS is supported and reduces clone size.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
217
MCQhard

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

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

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
218
MCQmedium

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

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

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

Why this answer

The 'PublishCodeCoverageResults' task with a 'codeCoverageThreshold' setting is correct because it allows you to define a minimum coverage percentage (e.g., 80%) and fail the pipeline if that threshold is not met, while still allowing the pipeline to continue if tests pass but coverage is lower. This task evaluates the coverage report after tests run and enforces the threshold as a build failure condition, not a test failure.

Exam trap

The trap here is that candidates confuse enabling code coverage collection (VSTest with 'codeCoverageEnabled') with enforcing a coverage threshold, which requires a separate task like 'PublishCodeCoverageResults' that explicitly evaluates and fails the build.

How to eliminate wrong answers

Option A is wrong because a quality gate in the release pipeline checks coverage after deployment, not during the CI build, and cannot fail the CI pipeline at the test step. Option B is wrong because a script task that reads the coverage report and prints a warning does not enforce a failure condition; it only outputs a message, so the pipeline would continue regardless of coverage. Option D is wrong because the VSTest task with 'codeCoverageEnabled' set to true only enables coverage collection during test execution, but does not provide a threshold setting to fail the pipeline based on coverage percentage.

Full explanation →
219
MCQhard

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

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

Marking the application setting as a deployment slot setting makes it 'sticky' to the slot, meaning it will not be swapped with the app code between staging and production. This ensures the staging slot retains its own configured value and the production slot's value remains unchanged, thereby preventing the misconfiguration from being promoted during a swap.

Why this answer

Marking the application setting as a deployment slot setting ensures that the setting stays with the slot and is not swapped between staging and production. This prevents the staging slot from having an incorrect value that could cause a swap failure, as the setting is pinned to the slot and not part of the swap payload.

Exam trap

The trap here is that candidates often choose a manual or scripted verification step (like Option C) because they think it adds safety, but the native slot setting feature is the simplest, most reliable, and built-in way to prevent swap failures caused by slot-specific misconfigurations.

How to eliminate wrong answers

Option A is wrong because a manual approval gate only pauses the pipeline for human review; it does not automatically validate or correct application settings before the swap, so the same misconfiguration could still cause a failure. Option B is wrong because the App Service deployment center is a high-level configuration interface for continuous deployment, not a mechanism to validate or pin slot-specific settings before a swap. Option C is wrong because adding a task to verify settings before swap is a reactive workaround that requires custom scripting and maintenance, whereas marking the setting as a slot setting is a native, declarative, and reliable solution that prevents the issue at the configuration level.

Full explanation →
220
MCQmedium

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

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

Custom instructions refine Copilot behavior.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
221
MCQeasy

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

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

This correctly configures the 'push' trigger with the 'branches' filter set to 'main', using the proper plural key. As a result, the workflow will execute only when commits are pushed directly to the 'main' branch, ignoring pushes to other branches.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
222
MCQhard

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

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

The ARM template deployment fails because the saved search references the custom log table 'AzureDevOpsPipelineEvents_CL', but that table does not exist in the workspace. Custom tables with the _CL suffix must be created beforehand (or data must be ingested to auto-create them); ARM templates do not implicitly create custom tables just because a saved search queries them.

Why this answer

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

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

Full explanation →
223
MCQeasy

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

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

An environment approval check adds a required manual approval step before any jobs targeting that environment are executed. The pipeline pauses, and only after an authorized user or group explicitly approves the deployment does it proceed to the production stage, directly fulfilling the need for human sign-off on production deployments.

Why this answer

Environment approval checks in Azure Pipelines allow you to require manual approval before a deployment proceeds to a specific environment, such as production. By adding an approval check to the production environment, you ensure that the security team must explicitly approve the deployment, meeting the requirement without modifying the pipeline code or branch policies.

Exam trap

The trap here is confusing branch policies (which govern code changes) with environment approval checks (which govern deployment gates), leading candidates to incorrectly select a branch policy for deployment control.

How to eliminate wrong answers

Option A is wrong because a branch policy controls code changes to a branch (e.g., requiring pull request reviews) but does not gate deployments to an environment; it operates at the source code level, not the deployment stage. Option C is wrong because a YAML condition checking a variable can skip or run stages based on runtime values, but it cannot enforce a manual approval process; it is purely automated and lacks human intervention. Option D is wrong because a service connection with restricted permissions controls which identities can deploy to a resource, but it does not provide a manual approval gate; it is a security boundary for authentication, not a workflow approval step.

Full explanation →
224
Drag & Dropmedium

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

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

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

Why this order

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

Full explanation →
225
MCQeasy

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

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

The `pr:` keyword in an Azure Pipelines YAML file defines the branch filters that trigger a pipeline on pull requests (PRs) targeting those branches. This is the correct mechanism for PR validation, as it specifically listens to PR creation and updates, unlike other trigger types.

Why this answer

The `pr:` trigger in Azure Pipelines YAML is specifically designed to automatically start a pipeline when a pull request is created or updated against a specified branch. By default, `pr:` triggers are enabled for all branches; however, to ensure the pipeline only runs for PRs targeting `main`, you configure `pr: main`. This triggers the pipeline on PR creation/update without needing a separate branch policy.

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
Page 2

Page 3 of 11

Page 4

All pages

1234567891011

Practice AZ-400 by domain

Target a specific domain to shore up weak areas.

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