Microsoft Azure DevOps Engineer Expert AZ-400 (AZ-400) — Questions 751825

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

Page 10

Page 11 of 13

Page 12
751
Multi-Selecteasy

You are designing a plan to protect Azure DevOps pipelines from supply chain attacks. Which TWO measures should you implement?

Select 2 answers
A.Require approval for pipeline runs that use external resources
B.Use Dependabot to automatically update vulnerable dependencies
C.Implement code coverage thresholds in pull requests
D.Enable secret scanning for all repositories
E.Use release gates to validate deployment health
AnswersA, B

Approval prevents unauthorized use of external resources.

Why this answer

Options A and C are correct. Option A ensures dependencies are secure. Option C prevents unauthorized access to pipeline resources.

Option B is wrong because it does not address supply chain. Option D is wrong because it is about deployment. Option E is wrong because it is about testing.

752
MCQmedium

Your team uses Azure Pipelines to deploy to production. You need to ensure that deployment only proceeds if a security scan passes and a manual approval is obtained. What is the best approach?

A.Add pipeline variables
B.Set up service connections
C.Configure branch policies
D.Use release gates in release pipelines
AnswerD

Release gates can run automated checks and require manual approvals.

Why this answer

Option B is correct because release gates can run automated checks (security scan) and manual approvals. Option A is wrong because branch policies are for code review. Option C is wrong because service connections handle authentication, not approvals.

Option D is wrong because pipeline variables store values, not enforce gates.

753
MCQhard

You are designing a release pipeline for a critical production application. The pipeline must ensure that changes are deployed to a staging environment first, and if integration tests pass, they are automatically deployed to production. However, if the tests fail, the deployment to production must be blocked. What is the best approach?

A.Create a single stage in the pipeline with conditional tasks to deploy to staging and then to production based on test results.
B.Create a multi-stage YAML pipeline with a gate on the production stage that evaluates test results from the staging stage.
C.Create two separate pipelines: one for staging and one for production. Use a pipeline trigger to run the production pipeline after staging completes.
D.Use a classic release pipeline with pre-deployment approvals on the production stage.
AnswerB

Gates allow automated evaluation of conditions like test pass rate before promoting to the next stage.

Why this answer

A multi-stage YAML pipeline with a gate on the production stage that evaluates test results is the best approach because it allows for automated promotion with conditional logic. Option A is wrong because a single stage with conditional tasks doesn't separate environments properly. Option B is wrong because separate pipelines are harder to manage and coordinate.

Option D is wrong because manual approval defeats the requirement for automatic deployment.

754
MCQeasy

The exhibit shows a draft Azure Monitor alert rule for Key Vault secret expiry. However, the query fails to return results for secrets that have already expired. What is the most likely reason?

A.The query does not include secrets that have no expiry date set.
B.The condition `DaysToExpiry > 0` excludes secrets that have already expired.
C.The query only checks secrets that are enabled.
D.The `limit 10` clause restricts to only 10 secrets, which may miss expired ones.
AnswerB

Expired secrets have negative DaysToExpiry, so they are filtered out.

Why this answer

Option B is correct because the query filters on `DaysToExpiry > 0`, which only returns secrets with a positive number of days remaining until expiry. Once a secret has expired, its `DaysToExpiry` becomes zero or negative, so it is excluded from the results. This is a logical filter error: the condition should be `DaysToExpiry <= 0` or remove the filter entirely to include expired secrets.

Exam trap

The trap here is that candidates focus on the syntax or limits of the query (like `limit 10`) rather than recognizing that the logical filter `DaysToExpiry > 0` inherently excludes the very data the alert is supposed to detect—expired secrets.

How to eliminate wrong answers

Option A is wrong because the query does not filter on whether a secret has an expiry date set; the issue is specifically about expired secrets, not those without an expiry date. Option C is wrong because the query does not include any condition that checks the enabled status of secrets; the problem is purely with the `DaysToExpiry` filter. Option D is wrong because the `limit 10` clause only affects the number of results returned, not the logical inclusion of expired secrets; even if more secrets were returned, expired ones would still be excluded by the `DaysToExpiry > 0` condition.

755
MCQeasy

You are configuring a continuous integration trigger in Azure Pipelines for a repository in Azure Repos. You want to trigger a build for all branches except the 'release' branch. How should you configure the trigger?

A.Set trigger: branches: include: - main
B.Set trigger: branches: include: - '*' exclude: - '*'
C.Set trigger: branches: include: - '*' exclude: - release
D.Set trigger: branches: exclude: - release
AnswerC

This includes all branches except release.

Why this answer

Option C is correct because using 'include' for all branches and 'exclude' for the release branch achieves the desired behavior. Option A is incorrect because it only includes main. Option B is incorrect because it excludes all branches.

Option D is incorrect because the syntax is invalid.

756
MCQhard

You are a DevOps engineer for a large e-commerce company. The development team uses GitHub for source control and GitHub Actions for CI/CD. The application is a microservices architecture with 15 services, each in its own repository. You need to implement a continuous delivery pipeline that builds and deploys each service to a Kubernetes cluster in Azure (AKS). The pipeline must meet the following requirements: - Each service must have its own pipeline that triggers on pushes to the main branch. - Deployment to AKS must use Helm charts. - The pipeline must automatically increment the Helm chart version and update the deployment manifest in the repository. - Security scanning must be performed on container images before deployment. - The pipeline must support manual approval for production deployment. - All secrets (e.g., AKS credentials, registry credentials) must be stored securely and not exposed in logs. You need to design the workflow. What is the best course of action?

A.Use Azure Pipelines instead of GitHub Actions because it has better integration with AKS. Store secrets in Azure Key Vault and use variable groups.
B.Create a reusable workflow with OIDC authentication to Azure. Use Helm to deploy, increment chart version, and commit back. Use GitHub environments for approval gates. Integrate container scanning with Docker Scout or Trivy.
C.Create a workflow per service with direct deployment. Use kubectl commands to deploy. Store all secrets in a single GitHub secret. Skip security scanning to save time.
D.Create a single reusable workflow that each service calls. Use Azure CLI to deploy Helm charts. Store AKS credentials as GitHub secrets. Use a manual approval step via environment protection rules.
AnswerB

This meets all requirements: OIDC for secure auth, Helm for deployment, version bump, approval, and scanning.

Why this answer

Using GitHub Actions with OIDC to authenticate to Azure avoids storing long-lived secrets. Helm chart version bumping can be done with a script. The workflow uses environments for approval gates.

Container scanning using tools like Trivy can be added as a step.

757
MCQhard

You are a security engineer for a large financial institution. The organization uses Azure DevOps with multiple projects, each containing hundreds of pipelines. The security team recently discovered that several pipeline variables marked as 'Secret' were inadvertently printed to logs due to a custom script task that echoed the variable. Consequently, the compliance officer requires that all secrets used in pipelines must be centrally managed in Azure Key Vault, and any pipeline that references a variable not from Key Vault must be blocked from running. Additionally, the solution must minimize administrative overhead and provide real-time enforcement across all projects in the organization. You have the following options: Option A: Create an Azure Policy definition that audits pipelines for the use of non-Key Vault variables and attach it to the management group containing the Azure DevOps resources. Option B: Develop a custom pipeline task that checks at runtime whether all secret variables originate from Key Vault, and add it to every pipeline YAML file manually. Option C: Configure a pipeline decorator in the organization settings that injects a task at the beginning of every pipeline to validate that all secret variables are linked to Key Vault, and fail the pipeline if any are not. Option D: Use Azure DevOps Audit Logs to periodically review pipeline runs and manually identify pipelines that use non-Key Vault secrets. Which option meets the requirements most effectively?

A.Develop a custom pipeline task that checks at runtime whether all secret variables originate from Key Vault
B.Create an Azure Policy definition that audits pipelines for the use of non-Key Vault variables
C.Use Azure DevOps Audit Logs to periodically review pipeline runs
D.Configure a pipeline decorator in the organization settings that injects a task at the beginning of every pipeline to validate that all secret variables are linked to Key Vault
AnswerD

Pipeline decorators automatically apply to all pipelines and can enforce compliance in real time.

Why this answer

Option C (Configure a pipeline decorator) is correct because it provides real-time enforcement at the organization level with minimal overhead. Option A is wrong because Azure Policy does not apply to Azure DevOps pipeline configurations. Option B is wrong because manual addition to each pipeline is high overhead and error-prone.

Option D is wrong because it is reactive and does not block non-compliant runs.

758
MCQhard

Refer to the exhibit. You have a YAML pipeline with the above steps. The pipeline publishes a web app and deploys to Azure App Service. The deployment fails with error: 'Could not find the package in the specified path.' What is the most likely cause?

A.The package path is wrong; the zip file is in $(Build.ArtifactStagingDirectory).
B.The AzureWebApp task input 'appType' is incorrect.
C.The dotnet publish command did not generate a zip file.
D.The service connection 'MyServiceConnection' is not authorized.
AnswerA

Correct: DotNetCoreCLI publish outputs to $(Build.ArtifactStagingDirectory) by default.

Why this answer

Option C is correct because the publish step outputs the zip file to $(Build.ArtifactStagingDirectory), not $(System.DefaultWorkingDirectory). Option A is wrong because the AzureWebApp task is correct. Option B is wrong because the service connection would cause a different error.

Option D is wrong because the dotnet publish command produces a zip file when zipAfterPublish is true.

759
MCQmedium

Refer to the exhibit. You executed the Azure CLI command to list variable groups. A security audit requires that all variable groups containing secrets are configured to be authorized for all pipelines. Which statement is true based on the output?

A.The variable group 'ProdVars' contains a secret variable, but the output does not indicate whether it is authorized for all pipelines
B.The variable group 'ProdVars' is not authorized for all pipelines because no such property exists
C.The variable group 'ProdVars' has exposed the secret value in the output
D.The variable group 'ProdVars' is authorized for all pipelines because it has secret variables
AnswerA

The output shows variable definitions but not authorization settings.

Why this answer

Option B (The variable group 'ProdVars' contains a secret variable, but the output does not indicate whether it is authorized for all pipelines) is correct. The JSON output does not include an 'authorize' property; you need to check the group's settings separately. Option A is wrong because the ApiKey value is null (masked).

Option C is wrong because you cannot tell from this output if it's authorized. Option D is wrong because the secret is shown as null, not exposed.

760
MCQmedium

During a sprint review, stakeholders complain that they don't receive notifications about completed work items. The team uses Azure Boards with a custom notification subscription. What is the most likely cause?

A.Email notifications are disabled at the organization level.
B.The subscription is set to deliver only to the team members.
C.The subscription's 'Deliver to' filter excludes stakeholders.
D.The subscription was automatically disabled after the first notification.
AnswerC

The filter must include stakeholders for them to receive notifications.

Why this answer

The most likely cause is that the custom notification subscription's 'Deliver to' filter is configured to exclude stakeholders. In Azure Boards, notification subscriptions can have filters that restrict delivery to specific groups or roles, and if stakeholders are not included in the filter, they will not receive notifications even if the subscription is active. This directly addresses the complaint that stakeholders are not getting notified about completed work items.

Exam trap

The trap here is that candidates might assume the issue is a global email disable or an automatic subscription expiry, rather than understanding that Azure Boards notification subscriptions rely on explicit filter configurations that can exclude specific roles like stakeholders.

How to eliminate wrong answers

Option A is wrong because if email notifications were disabled at the organization level, no one would receive any notifications, not just stakeholders, and the team would likely be aware of a global setting change. Option B is wrong because the subscription being set to deliver only to team members would explain why stakeholders don't receive notifications, but the question specifies a custom subscription with a 'Deliver to' filter, and the correct filter-based exclusion is more precise; however, the 'Deliver to' filter is the mechanism that controls who receives the notification, and excluding stakeholders is the direct cause. Option D is wrong because Azure Boards notification subscriptions are not automatically disabled after the first notification; they remain active until manually disabled or deleted, and there is no built-in behavior that disables subscriptions after a single delivery.

761
MCQhard

Refer to the exhibit. A build pipeline produces the above logs. Which change would resolve the build failure?

A.Change the build configuration from Release to Debug.
B.Add a definition for 'MyMethod' in the 'MyClass' class.
C.Remove the '--no-build' flag from the test step.
D.Add the '--no-restore' flag to the build step.
AnswerB

The error indicates that 'MyMethod' is missing from 'MyClass'. Adding the method definition resolves the compilation error.

Why this answer

The build fails with a CSC error CS0117 indicating that 'MyClass' does not contain a definition for 'MyMethod'. This is a compilation error. The 'dotnet test' step runs with '--no-build' which skips building and relies on the build output, but the build step fails, so the test step produces no results.

The fix is to correct the code in the source file to include the definition for 'MyMethod'.

762
MCQeasy

Your company is migrating to Microsoft Entra ID and needs to manage secrets used in Azure Pipelines. Which service should you use to securely store and rotate secrets?

A.Azure Key Vault
B.GitHub Secrets
C.Azure App Configuration
D.Microsoft Purview
AnswerA

Azure Key Vault securely stores secrets and integrates with Azure Pipelines.

Why this answer

Option B is correct because Azure Key Vault is the native secret management service in Azure, integrated with Azure Pipelines via library variable groups. Option A is wrong because GitHub Secrets is for GitHub Actions, not Azure Pipelines. Option C is wrong because Azure App Configuration is for feature flags and configuration.

Option D is wrong because Microsoft Purview is for data governance.

763
MCQhard

Your organization uses GitHub Actions and has a repository containing sensitive infrastructure code. You need to ensure that only approved actions are used in workflows. Which two settings should you configure? (Select two.)

A.Allow actions created by GitHub.
B.Disable actions for the repository.
C.Allow actions from only specific approved repositories.
D.Use environment protection rules.
E.Store actions in encrypted secrets.
AnswerA, C

This restricts actions to those created by GitHub (verified creators).

Why this answer

Options A and D are correct because GitHub allows you to restrict actions to those from verified creators and to allow only actions in approved repositories. Option B is wrong because disabling actions would block all workflows. Option C is wrong because secrets do not restrict actions.

Option E is wrong because environment protection rules do not restrict actions.

764
MCQmedium

Refer to the exhibit. You have a YAML pipeline that references a repository resource with a tag. When will this pipeline trigger?

A.When a new tag v1.0 is pushed to the referenced repository.
B.When changes are pushed to any branch of the referenced repository.
C.When changes are pushed to the main branch of the current repository.
D.The pipeline will never trigger because no trigger is defined.
AnswerC

The trigger defines main branch pushes.

Why this answer

The pipeline has a CI trigger on the main branch of the current repository. The repository resource specifies a tag, which is used for checkout in the pipeline, but the trigger is based on the source trigger (main branch). Option A is correct because the trigger is on main.

Option B is wrong because tags are not triggers. Option C is wrong because the trigger is not for the repository resource. Option D is wrong because there is a trigger defined.

765
MCQeasy

Your Azure DevOps pipeline uses a YAML template that defines variables. You want to override a variable value when running the pipeline manually. What is the best approach?

A.Create a variable group and link it to the pipeline.
B.Edit the template YAML file to hardcode the desired value.
C.Use the 'Variables' tab in the pipeline run UI to set a new value for the variable.
D.Define a parameter in the template and pass the value via the 'Override' parameter in the pipeline.
AnswerC

Queue-time variables override template variables.

Why this answer

Option A is correct because Azure DevOps allows you to set pipeline variables at queue time, which override template variables. Option B is incorrect because it would require modifying the template. Option C is incorrect because variable groups are for shared variables, not for overriding.

Option D is incorrect because the 'Override' parameter is not a YAML template parameter.

766
MCQeasy

Your organization uses Azure Pipelines for CI/CD. The current pipeline for a .NET Core application builds and runs unit tests, then deploys to a staging environment. The team wants to add a step to run integration tests against the staging environment after deployment, and only if integration tests pass, promote the build to production. The integration tests require a database connection string that is stored as a secret in Azure Key Vault. The pipeline uses a service principal with permissions to read secrets from the Key Vault. You need to modify the pipeline to meet these requirements while ensuring security best practices. Which action should you take?

A.Set the connection string as a secret variable in the pipeline UI and reference it in the integration test step.
B.Add an Azure Key Vault task before the integration test step to retrieve the secret and map it to a variable.
C.Add a variable group linked to the Key Vault and reference the secret variable directly in the integration test step.
D.Use a PowerShell script to read the secret from Key Vault using the service principal.
AnswerB

This is the recommended approach: use the Azure Key Vault task to fetch secrets securely and make them available as pipeline variables.

Why this answer

Option B is correct because the Azure Key Vault task securely retrieves the secret at pipeline runtime and maps it to a pipeline variable without exposing the secret in logs or YAML. This approach follows security best practices by avoiding hard-coded secrets and leveraging the existing service principal permissions. The integration test step can then reference the variable, ensuring the connection string is available only during execution.

Exam trap

The trap here is that candidates often confuse variable groups linked to Key Vault (which load secrets at queue time) with the Azure Key Vault task (which loads secrets at runtime), leading them to choose Option C despite the runtime retrieval requirement for integration tests that depend on the latest secret value.

How to eliminate wrong answers

Option A is wrong because setting the connection string as a secret variable in the pipeline UI still requires manual management and does not leverage Azure Key Vault, increasing the risk of secret exposure and violating the principle of centralized secret storage. Option C is wrong because a variable group linked to Key Vault retrieves secrets at queue time, not at runtime, which means the secret value is static for the entire pipeline run and cannot be updated dynamically if the Key Vault secret changes mid-run; also, variable groups do not support per-step scoping as securely as the Key Vault task. Option D is wrong because using a PowerShell script to read the secret from Key Vault introduces unnecessary complexity and potential security gaps (e.g., script errors might leak secrets in logs), whereas the dedicated Azure Key Vault task provides built-in logging suppression and seamless variable mapping.

767
MCQmedium

Your organization uses GitHub Enterprise and wants to prevent secrets (e.g., API keys) from being pushed to any repository. Which GitHub feature should you enable?

A.Repository rulesets
B.GitHub Advanced Security secret scanning
C.Push protection for secret scanning
D.Branch protection rules requiring signed commits
AnswerC

Push protection prevents commits with secrets from being pushed.

Why this answer

Push protection for secret scanning (Option C) is the correct answer because it actively blocks pushes that contain known secrets (e.g., API keys, tokens) at the client side, preventing them from ever reaching the remote repository. This is a dedicated feature of GitHub Advanced Security that integrates with pre-receive hooks to scan commits in real time, rejecting the push if a secret pattern is detected. It is specifically designed to prevent secrets from being pushed, unlike passive scanning which only alerts after the fact.

Exam trap

The trap here is that candidates confuse 'secret scanning' (passive detection) with 'push protection' (active prevention), assuming that enabling GitHub Advanced Security secret scanning alone will block pushes, when in fact push protection is a separate toggle that must be explicitly enabled.

How to eliminate wrong answers

Option A is wrong because repository rulesets are used to enforce branch policies (e.g., required status checks, merge restrictions) but do not scan or block secrets in commits. Option B is wrong because GitHub Advanced Security secret scanning alone only detects secrets after they have been pushed (via alerts or pull request comments) and does not prevent the push from succeeding. Option D is wrong because branch protection rules requiring signed commits enforce commit integrity via GPG or S/MIME signatures but have no mechanism to inspect commit content for secrets.

768
Multi-Selecthard

Which THREE of the following are best practices for managing secrets in Azure Pipelines? (Select THREE.)

Select 3 answers
A.Hardcode secrets directly in the YAML file and use variable substitution at runtime.
B.Use Azure Key Vault to store secrets and link them to variable groups.
C.Enable 'Allow scripts to access the OAuth token' for all build pipelines.
D.Restrict access to variable groups by using pipeline permissions.
E.Map secret variables as environment variables with a mapping to prevent exposure in logs.
AnswersB, D, E

Key Vault provides secure storage and access control.

Why this answer

Options A, C, and E are correct. A: Using Azure Key Vault is a secure way to store secrets. C: Limiting variable group permissions ensures only authorized pipelines access secrets.

E: Using secret variables with $( ) in script tasks prevents exposure. B is incorrect because pipeline logs can inadvertently output secrets; it's better to avoid logging. D is incorrect because hardcoding secrets in YAML is a security risk.

769
MCQeasy

You have a YAML pipeline that builds a .NET application. You need to ensure that the pipeline uses the .NET SDK version 6.0.x. Which task should you add to the pipeline?

A.UseDotNet@2
B.NuGetToolInstaller@1
C.DotNetCoreCLI@2
D.PowerShell@2
AnswerA

Why this answer

The UseDotNet@2 task is the correct choice because it explicitly installs a specific .NET SDK version (6.0.x) on the build agent, ensuring the pipeline uses the required SDK for building the .NET application. This task downloads and caches the SDK, making it available for subsequent tasks like DotNetCoreCLI@2.

Exam trap

The trap here is that candidates often confuse DotNetCoreCLI@2 (which runs .NET commands) with UseDotNet@2 (which installs the SDK), assuming the build task itself can set the SDK version, but DotNetCoreCLI@2 only uses whatever SDK is already available.

Why the other options are wrong

B

This installs NuGet, not the .NET SDK.

C

This runs .NET commands but does not install a specific SDK version.

D

PowerShell can install SDK but it's not the built-in task for this purpose.

770
MCQmedium

Your organization uses Azure DevOps Server (on-premises) and is planning to migrate to Azure DevOps Services. You have hundreds of build and release pipelines. The migration must be done with minimal downtime and with validation that each pipeline works after migration. You have a test collection of 20 critical pipelines that must be validated first. What is the best approach?

A.Export all pipelines as JSON from the server and import them into Azure DevOps Services. Skip validation to save time.
B.Manually recreate the 20 critical pipelines in Azure DevOps Services and test them. Then recreate the rest manually.
C.Use the Azure DevOps Migration Tools to replicate the test pipelines to a new Azure DevOps Services organization. Validate, fix issues, then migrate the remaining pipelines in batches.
D.Perform an in-place upgrade of Azure DevOps Server to the latest version, then migrate to Azure DevOps Services using the Data Migration Tool.
AnswerC

This allows validation and incremental migration with minimal impact.

Why this answer

Using the Azure DevOps Migration Tools to perform a trial migration to a test organization allows you to validate and fix issues before migrating the full collection. Direct upgrade is not supported. Manual recreation is error-prone and not minimal downtime.

Skipping validation risks breaking pipelines.

771
MCQmedium

Refer to the exhibit. You have this Azure Pipelines YAML definition. The pipeline runs manually, but you want it to automatically trigger on every push to the main branch and also build pull requests targeting main. Which change should you make?

A.Remove the 'triggers' and 'pr' sections entirely.
B.Replace 'triggers: ["none"]' with 'triggers: ["main"]' and 'pr: ["none"]' with 'pr: ["main"]'.
C.Set 'triggers' to '["main"]' and 'pr' to '["none"]'.
D.Set 'triggers' to 'none' and 'pr' to 'none'.
AnswerB

This enables CI on push to main and PR triggers for PRs targeting main.

Why this answer

Option C is correct because removing the explicit 'triggers: none' and 'pr: none' enables the default triggers: CI on push to any branch and PR triggers on PRs to any branch. To limit to main branch, you need to specify triggers and pr properly. Option A is wrong because 'none' disables triggers.

Option B is wrong because setting both to 'none' disables triggers. Option D is wrong because setting triggers: none still disables CI, and pr: none disables PR triggers.

772
MCQhard

An organization uses Azure Repos with multiple Git repositories. They want to enforce that all commits to the main branch are signed using GPG keys. Which combination of actions is required to enforce commit signing?

A.Configure branch policy to require signed commits and have developers add their SSH public key to Azure Repos.
B.Configure repository settings to require a personal access token (PAT) for each commit.
C.Configure branch policy to require signed commits and have developers configure Git to sign commits with their GPG key.
D.Use Azure Key Vault to store signing keys and configure Azure Repos to automatically sign commits.
AnswerC

Branch policy enforces signing, and GPG key configuration enables signing locally.

Why this answer

Option C is correct because Azure Repos supports a branch policy that requires commits to be signed, and developers must configure Git to sign commits with their GPG key using `git config --global user.signingkey` and `git commit -S`. This ensures that only signed commits are accepted into the main branch, enforcing non-repudiation and integrity.

Exam trap

The trap here is confusing authentication methods (SSH keys, PATs) with commit signing (GPG keys), leading candidates to select options that address access control rather than cryptographic integrity.

How to eliminate wrong answers

Option A is wrong because SSH public keys are used for authentication, not for signing commits; commit signing requires GPG keys, not SSH keys. Option B is wrong because a personal access token (PAT) is used for authentication to Azure Repos, not for signing commits; it does not enforce cryptographic signing. Option D is wrong because Azure Key Vault can store keys but Azure Repos does not automatically sign commits; signing must be performed client-side by the developer using Git.

773
Matchingmedium

Match each YAML pipeline trigger to its behavior.

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

Concepts
Matches

Runs pipeline on code push

Runs pipeline on pull request creation

Runs pipeline at specified times

Runs pipeline after another pipeline completes

Why these pairings

Trigger types available in Azure Pipelines YAML.

774
MCQeasy

Your team uses Azure DevOps and wants to automatically scan pull requests for secrets before they are merged. Which Azure DevOps feature should you use?

A.Azure Policy.
B.Secret scanning in Azure DevOps.
C.GitHub Advanced Security.
D.Branch policy with a required reviewer.
AnswerB

Azure DevOps has built-in secret scanning for Azure Repos.

Why this answer

Option C is correct because Azure DevOps includes a built-in secret scanner that can be integrated into pipelines. Option A is wrong because GitHub Advanced Security is for GitHub, not Azure DevOps. Option B is wrong because branch policies do not include secret scanning.

Option D is wrong because Azure Policy does not scan pull request content.

775
MCQeasy

You are setting up a new GitHub repository for a project that requires strict access control. Only specific team members should be able to push to the main branch, but all team members should be able to create branches and open pull requests. What is the best way to achieve this?

A.Add all team members as administrators of the repository.
B.Remove write permissions for non-core team members and give them read-only access.
C.Use a branch protection rule to restrict pushes to the main branch to specific users or teams.
D.Set the repository to private and invite only core team members.
AnswerC

Allows branch creation but restricts pushes to main.

Why this answer

Branch protection rules in GitHub allow you to enforce restrictions on specific branches, such as requiring pull request reviews or restricting who can push directly. By configuring a rule for the main branch that limits push access to only designated users or teams, you ensure that all team members can create branches and open PRs, but only authorized members can merge into main. This directly meets the requirement without over-provisioning permissions or blocking collaboration.

Exam trap

The trap here is that candidates often confuse restricting push access with removing write permissions entirely, not realizing that branch protection rules allow granular control over specific branches while preserving write-level collaboration on other branches.

How to eliminate wrong answers

Option A is wrong because adding all team members as administrators grants them full control over the repository, including the ability to bypass any restrictions and push directly to main, which violates the strict access control requirement. Option B is wrong because removing write permissions for non-core members and giving them read-only access prevents them from creating branches or opening pull requests, which contradicts the requirement that all team members should be able to do so. Option D is wrong because setting the repository to private and inviting only core team members excludes non-core members entirely, preventing them from creating branches or opening pull requests, which is not the desired outcome.

776
MCQeasy

You run the above Azure CLI command to deploy a Bicep template. The deployment fails with 'The resource 'Microsoft.Storage/storageAccounts/mystgaccount' already exists'. What is the most likely cause?

A.The storage account 'mystgaccount' already exists in the resource group.
B.The command should use 'az deployment group validate' instead.
C.The Bicep file uses 'complete' mode.
D.The resource group 'MyRG' does not exist.
AnswerA

Azure deployment with 'create' mode fails if resource exists.

Why this answer

Option D is correct because the storage account already exists. Option A is wrong because the command uses 'create' which is correct. Option B is wrong because the error mentions 'already exists', not resource group.

Option C is wrong because 'create' mode fails if resource exists; 'incremental' would update.

777
MCQmedium

You are designing a release pipeline for a microservices application. Each service must be deployed independently with zero downtime. Which deployment strategy should you recommend?

A.Rolling update
B.Feature flags
C.Canary release
D.Blue-green deployment
AnswerD

Blue-green maintains two full environments for instant switch.

Why this answer

Blue-green deployment allows switching traffic to the new version while keeping the old version running, enabling instant rollback. Option A is wrong because rolling update replaces instances gradually. Option B is wrong because canary releases route a subset of users.

Option D is wrong because feature flags enable toggling features at runtime.

778
Drag & Dropmedium

Drag and drop the steps to troubleshoot a failed Azure DevOps release pipeline into the correct order.

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

Steps
Order

Why this order

Troubleshooting starts with logs, then task identification, variable check, debug run, and fix.

779
MCQeasy

You are configuring Application Insights for a .NET Core web application deployed to Azure App Service. The application must capture telemetry for all HTTP requests, exceptions, and dependency calls with minimal code changes. What should you do?

A.Enable the Application Insights site extension in the App Service 'Application Insights' blade.
B.Configure diagnostics logging in the App Service and stream logs to Application Insights.
C.Install the Microsoft.ApplicationInsights.AspNetCore NuGet package and add services.AddApplicationInsightsTelemetry() in Startup.cs.
D.Add the Application Insights JavaScript SDK to each page.
AnswerA

The site extension enables auto-instrumentation with no code changes.

Why this answer

Option A is correct because enabling the Application Insights site extension via the App Service 'Application Insights' blade automatically instruments the .NET Core application without requiring any code changes. This extension injects the necessary telemetry modules to capture HTTP requests, exceptions, and dependency calls at the runtime level, leveraging the Azure App Service integration for zero-code instrumentation.

Exam trap

The trap here is that candidates often assume the NuGet package (Option C) is always required for .NET Core instrumentation, overlooking the zero-code site extension option that meets the 'minimal code changes' requirement more directly.

How to eliminate wrong answers

Option B is wrong because configuring diagnostics logging and streaming logs to Application Insights captures only platform-level logs (e.g., IIS logs, failed request tracing) and does not automatically capture application-level telemetry like dependency calls or exceptions without additional custom code. Option C is wrong because while installing the NuGet package and adding services.AddApplicationInsightsTelemetry() is a valid code-based approach, the question explicitly requires 'minimal code changes,' making the site extension (zero-code) the better choice. Option D is wrong because the JavaScript SDK is for client-side browser telemetry (page views, client exceptions), not for server-side HTTP requests, exceptions, or dependency calls in a .NET Core web application.

780
MCQhard

You are designing a build pipeline that must run on Microsoft-hosted agents. The pipeline has a dependency on a native library that is not pre-installed. You want to minimize pipeline duration. Which approach should you use?

A.Use a container job with a custom Docker image that includes the library
B.Use a self-hosted agent with the library pre-installed
C.Add a script step to install the library using a package manager
D.Download the library from Azure Blob Storage in each build
AnswerB

Self-hosted agents skip installation.

Why this answer

Using a custom agent with the library pre-installed avoids repeated installation. Option A is wrong because inline scripts run each time. Option C is wrong because Docker requires pull and build each time.

Option D is wrong because downloading from storage is slow.

781
MCQhard

An organization uses Azure DevOps and wants to implement a change management process where all changes to the main branch require approval from a change advisory board (CAB). The CAB members are not part of the development team. How should they configure this?

A.Set branch permissions to restrict push to main and only allow CAB to approve via manual process.
B.Create a new branch policy on main that requires a minimum number of reviewers from a separate CAB group.
C.Use a service hook to notify CAB when a PR is created, and rely on manual approval.
D.Add the CAB as members of the development team and require team review.
AnswerB

Branch policies can require specific reviewers or groups.

Why this answer

Option B is correct because Azure DevOps branch policies allow you to enforce a minimum number of reviewers from a specific security group (e.g., a CAB group) on pull requests targeting the main branch. This ensures that every change to main requires explicit approval from CAB members, who are separate from the development team, without relying on manual processes or altering team membership.

Exam trap

The trap here is that candidates often confuse branch permissions (which control who can push) with branch policies (which control the review process), leading them to choose Option A instead of the correct policy-based solution.

How to eliminate wrong answers

Option A is wrong because restricting push permissions to main would block all direct pushes, but it does not enforce a review process; it would require a manual, non-auditable workflow outside Azure DevOps. Option C is wrong because a service hook only sends a notification when a PR is created; it does not enforce approval as a required gate, so changes could still be completed without CAB sign-off. Option D is wrong because adding CAB members to the development team would grant them unnecessary permissions and violate the requirement that CAB is separate from the development team; the team review policy would also apply to all team members, not specifically to CAB.

782
MCQeasy

You have a YAML pipeline that builds a Docker image and pushes it to Azure Container Registry (ACR). You need to dynamically set the image tag based on the build number. Which predefined variable should you use?

A.$(System.JobId)
B.$(System.TeamProject)
C.$(Build.BuildNumber)
D.$(Build.BuildId)
AnswerD

Build.BuildId is a unique numeric ID that can be used as a tag.

Why this answer

Option A is correct because Build.BuildId is a unique identifier for each build run. Option B is wrong because Build.BuildNumber is customizable and may not be numeric. Option C is wrong because System.TeamProject is the project name.

Option D is wrong because System.JobId is a job-level ID.

783
MCQeasy

A team uses a monorepo with multiple projects in one Git repository. They want to enforce that each commit message must reference a work item from Azure Boards. Which branch policy should they configure?

A.Automatically include work items in pull request descriptions
B.Require a work item linking policy in branch policies
C.Configure a minimum number of reviewers policy
D.Use a build validation policy to check commit messages
AnswerB

This policy enforces that every pull request has at least one linked work item.

Why this answer

The 'Require a work item linking policy' in Azure Repos branch policies enforces that every pull request must be associated with at least one Azure Boards work item before it can be completed. This policy directly meets the requirement to ensure each commit message references a work item, as the linking is validated at merge time.

Exam trap

The trap here is that candidates often confuse 'commit message validation' with 'pull request work item linking', assuming a build validation or custom script is needed, when Azure Repos provides a native branch policy specifically for enforcing work item association.

How to eliminate wrong answers

Option A is wrong because automatically including work items in pull request descriptions only adds work item links to the description text, but does not enforce that every commit message must reference a work item. Option C is wrong because a minimum number of reviewers policy controls who must approve the pull request, not the content of commit messages or work item references. Option D is wrong because a build validation policy runs a build pipeline to validate code quality or tests, but it cannot inspect or enforce commit message content for work item references without custom scripting, and it is not the native policy designed for this purpose.

784
MCQmedium

Your team uses Azure Pipelines for CI/CD. You need to enforce that all builds sign the assemblies with a code signing certificate stored in Azure Key Vault. What is the recommended approach?

A.Store the certificate as a secure file in the pipeline library and use the 'Download Secure File' task.
B.Embed the certificate in the repository and use a script to sign.
C.Use the 'Azure Key Vault' task to download secrets and then a 'PowerShell' task to sign.
D.Use the 'Azure CLI' task to retrieve the certificate and then sign.
AnswerC

The Key Vault task downloads secrets (including certificates) and makes them available as pipeline variables.

Why this answer

Use a 'Download secrets' task to retrieve the certificate from Key Vault and then use a script to sign the assemblies.

785
MCQmedium

You are designing a pipeline to build a .NET Core application. The build must run unit tests and publish code coverage results. Which task should you use to publish the code coverage results to Azure DevOps?

A.Use the 'PublishCodeCoverageResults@1' task.
B.Use the 'PublishTestResults@2' task.
C.Use the 'DotNetCoreCLI@2' task with the 'test' command.
D.Use the 'VSTest@2' task with the 'codeCoverageEnabled' option.
AnswerA

This task publishes code coverage reports.

Why this answer

Option D is correct because the 'PublishCodeCoverageResults@1' task publishes code coverage results to the pipeline. Option A is wrong because the 'DotNetCoreCLI@2' task can run tests but does not publish results. Option B is wrong because 'VSTest@2' is for Visual Studio tests.

Option C is wrong because 'PublishTestResults@2' publishes test results, not coverage.

786
MCQmedium

Your company uses Azure DevOps for CI/CD. You have a build pipeline that compiles a C++ application and runs unit tests. The pipeline uses a Microsoft-hosted agent. The build takes approximately 45 minutes to complete. You want to reduce the build time. You notice that the pipeline downloads dependencies from a NuGet feed every time. You have a private NuGet feed in Azure Artifacts. The pipeline restores packages using 'nuget restore'. You want to cache the NuGet packages on the agent to avoid downloading them on every build. What should you do?

A.Use a self-hosted agent with persistent storage.
B.Use a hosted Azure Artifacts feed with upstream sources.
C.Increase the agent's compute resources by selecting a higher SKU.
D.Add a CacheBeta task before the restore step to cache the packages folder.
AnswerD

Caching the packages folder avoids re-downloading on subsequent builds.

Why this answer

Option B is correct because the CacheBeta task allows caching folders between builds, reducing download time. Option A is wrong because self-hosted agents might not be available or cost-effective. Option C is wrong because upgrading to a higher SKU of Microsoft-hosted agents does not affect package caching.

Option D is wrong because a hosted NuGet feed does not inherently cache packages locally.

787
MCQhard

You are designing a source control strategy for a team that uses GitHub Copilot. The team wants to ensure that code suggestions do not include sensitive data. Which approach should you recommend?

A.Use pre-commit hooks to scan for secrets
B.Disable GitHub Copilot for the organization
C.Enable secret scanning for the repository
D.Configure content exclusions in GitHub Copilot settings to block sensitive data patterns
AnswerD

Prevents suggestions with secrets.

Why this answer

Option C is correct because GitHub Copilot policies can be configured to block suggestions containing secrets. Option A is wrong because it disables Copilot entirely. Option B is wrong because it only alerts, not blocks.

Option D is wrong because it is a post-commit measure.

788
MCQhard

Your organization uses GitHub Actions for CI/CD. You have a workflow that builds a .NET application and runs tests. The workflow uses a self-hosted runner on an on-premises Windows server. Recently, builds started failing with 'Access to the path is denied' errors when the runner tries to restore NuGet packages. The runner has been working for months. What is the most likely cause?

A.The runner's authentication token to GitHub has expired.
B.The runner service account's permissions have changed, and it no longer has write access to the working directory or cache.
C.The NuGet cache directory on the runner has been deleted.
D.The runner has been updated to a newer version that no longer supports NuGet restore.
AnswerB

Permission changes can cause access denied errors.

Why this answer

Option C is correct because the runner service runs under a specific account, and if that account's permissions changed (e.g., password reset, group membership changed), it may lose access to the NuGet cache directory. Option A is wrong because the runner doesn't need to authenticate to GitHub for NuGet restore. Option B is wrong because network issues would cause different errors.

Option D is wrong because the runner itself doesn't install NuGet packages; it uses dotnet restore.

789
MCQeasy

Your team uses GitHub for source control and wants to set up continuous integration using GitHub Actions. Which file should you create in the repository to define the workflow?

A.Jenkinsfile
B..github/workflows/ci.yml
C.Dockerfile
D.azure-pipelines.yml
AnswerB

Standard location for GitHub Actions workflows.

Why this answer

Option A is correct because GitHub Actions workflows are defined in YAML files under the .github/workflows directory. Option B is wrong because azure-pipelines.yml is for Azure Pipelines. Option C is wrong because the Dockerfile is for building Docker images.

Option D is wrong because Jenkinsfile is for Jenkins.

790
MCQeasy

Your organization uses Azure Pipelines and wants to implement a continuous feedback loop by collecting user analytics from the production environment and automatically creating work items in Azure Boards for critical issues. You need to design a solution that integrates monitoring data with the pipeline. What should you do?

A.Use Power BI to visualize Application Insights data and set up data-driven alerts that send emails to the team.
B.Set up Azure Monitor alerts based on Application Insights data, and configure the alerts to invoke a webhook that calls the Azure Boards REST API to create a work item.
C.Configure the release pipeline to output logs to Azure Monitor and use Log Analytics to create work items.
D.Use Azure Application Insights to collect user analytics, and manually review dashboards to create work items.
AnswerB

This automates the creation of work items from alerts.

Why this answer

Option C is correct: Azure Monitor alerts can trigger webhooks that call Azure DevOps REST API to create work items. Option A is incorrect because release logs are not for user analytics. Option B is incorrect because manual creation is not automated.

Option D is incorrect because Power BI is for reporting, not automated issue creation.

791
MCQhard

Your organization is adopting GitHub Actions for CI/CD. You need to enforce that all workflows must pass required status checks before merging pull requests to the main branch. The repository is in an organization. What should you configure?

A.Add an environment protection rule requiring approval from specific reviewers.
B.Set the workflow to have 'contents: write' permission.
C.Define a CODEOWNERS file that requires team review for main branch changes.
D.Create a branch protection rule for the main branch with required status checks.
AnswerD

Branch protection rules enforce required checks before merging.

Why this answer

Branch protection rules with required status checks enforce that workflows pass before merging. Option A is wrong because environment protection rules apply to deployments, not PR merges. Option B is wrong because workflow permissions control what workflows can do, not merge requirements.

Option D is wrong because CODEOWNERS defines reviewers, not checks.

792
MCQhard

Refer to the exhibit. The JSON above shows a branch policy configuration for the main branch in Azure Repos. A developer pushes a third commit to an existing pull request after two reviewers have already approved. What happens?

A.The existing approvals remain valid because dismiss_stale_reviews is false.
B.The pull request is automatically merged because allowed merge types include squash.
C.The approvals are dismissed because require_last_push_approval is true.
D.The pull request is blocked because the merge type is not allowed.
AnswerC

The new push invalidates previous approvals.

Why this answer

Option B is correct because require_last_push_approval is true, so after the new push, previous approvals are dismissed, requiring re-approval. Option A is wrong because require_last_push_approval overrides dismiss_stale_reviews. Option C is wrong because allowed merge types are squash and rebase, but that doesn't affect approval.

Option D is wrong because the pull request can still be updated.

793
MCQhard

Your organization uses Azure DevOps and Azure Key Vault to manage secrets. You have a pipeline that deploys a web app to Azure App Service. The pipeline uses a variable group linked to Key Vault to retrieve the database connection string. Recently, the build started failing with the error: 'Access to Key Vault is denied. Please ensure the service connection has Get and List permissions on secrets.' The service connection uses a service principal. You have verified that the service principal has the correct Key Vault access policy with Get and List permissions. What is the most likely cause of the failure?

A.The service connection is configured to use the wrong Azure subscription.
B.The secret name in the variable group does not match the secret name in Key Vault.
C.The service principal used by the service connection does not have Contributor role on the Key Vault.
D.The build service identity does not have Get and List permissions on the Key Vault secrets.
AnswerD

The build service identity (project collection or project level) must be granted access to Key Vault for variable group resolution.

Why this answer

The error message indicates that the identity attempting to access Key Vault lacks the required permissions. Even though the service principal has the correct access policy, the pipeline may be using a different identity—the build service identity—to authenticate with Key Vault. In Azure DevOps, when a variable group is linked to Key Vault, the pipeline's build service identity (not the service connection's service principal) must have Get and List permissions on the Key Vault secrets.

This is a common misconfiguration where the service principal is granted permissions but the build service identity is not.

Exam trap

The trap here is that candidates assume the service principal configured in the service connection is the identity used to access Key Vault, but in reality, Azure DevOps uses the build service identity for variable group secret retrieval, leading to a permissions mismatch.

How to eliminate wrong answers

Option A is wrong because the Azure subscription configured in the service connection determines the scope for resource management, but Key Vault access is governed by its own access policies, not subscription-level settings. Option B is wrong because a mismatch between secret names would cause a different error (e.g., 'Secret not found') rather than an access denied error. Option C is wrong because the Contributor role on Key Vault is an Azure RBAC role that grants management-plane permissions (e.g., creating/deleting vaults), not data-plane permissions (e.g., reading secrets); Key Vault access policies or Azure RBAC data-plane roles are required for secret access.

794
MCQmedium

Your organization uses GitHub for source control and Azure Pipelines for CI/CD. You need to implement a policy that requires all pull requests to be built and pass tests before merging. What should you do?

A.Add a branch protection rule in the GitHub repository requiring status checks.
B.Set the pipeline trigger to run on pull request.
C.Configure pipeline permissions to require approval.
D.Add a pre-deployment check on the environment.
AnswerA

Branch protection rules enforce that status checks (from pipelines) pass before merging.

Why this answer

Option B is correct because branch protection rules in GitHub can require status checks to pass. Option A is wrong because pipeline permissions don't enforce PR checks. Option C is wrong because trigger controls build triggers, not merge requirements.

Option D is wrong because environment checks are for deployments.

795
MCQmedium

You are designing a multi-stage YAML pipeline that deploys to multiple environments. You need to ensure that the pipeline can be triggered manually for a specific stage without running previous stages. Which feature should you use?

A.Use the 'Run pipeline' button with 'Stages to run' and set 'stagesToSkip' parameter
B.Use 'condition: always()' on the stage
C.Use 'dependsOn: []' to make the stage independent
D.Use 'trigger: none' at the stage level
AnswerA

When manually running a pipeline, you can specify which stages to skip using the 'stagesToSkip' parameter, allowing you to run only the desired stage.

Why this answer

Option C is correct because stage-level triggers are not supported in YAML pipelines; however, the 'stagesToSkip' parameter in the REST API when manually running a pipeline allows skipping previous stages. Option A is wrong because multi-stage YAML pipelines do not support stage-specific triggers. Option B is wrong because the 'dependsOn' condition runs all dependencies.

Option D is wrong because 'condition: always()' still runs all stages if triggered.

796
Matchingmedium

Match each Azure DevOps security concept to its purpose.

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

Concepts
Matches

Personal access token for API authentication

Securely stores credentials for external services

Shared variables with optional secret protection

Centralized secure files and variable groups

Why these pairings

Key security features in Azure DevOps.

797
Multi-Selecthard

Which TWO actions should you take to implement a secure CI/CD pipeline that uses Azure Pipelines and prevents unauthorized access to production? (Choose two.)

Select 2 answers
A.Store production secrets as pipeline variables marked as 'Secret'.
B.Configure deployment approvals and checks on the production stage.
C.Enable PR triggers for the production stage to validate changes.
D.Use a service connection with a managed identity for Azure resources.
E.Use self-hosted agents running on-premises for all pipelines.
AnswersB, D

Approvals ensure that only authorized personnel can approve deployments to production.

Why this answer

Options A and C are correct. Option A: Using a service connection with a managed identity reduces the need for secrets and provides secure, auditable access. Option C: Using approvals and checks ensures that only authorized users can approve deployments to production.

Option B is wrong because storing secrets in pipeline variables, even as secrets, is less secure than using Key Vault or managed identities. Option D is wrong because self-hosted agents can be secure but do not inherently prevent unauthorized access. Option E is wrong because enabling PR triggers for production deployments could allow unauthorized changes.

798
MCQhard

You see the above git log output. The team has a policy requiring linear history on the main branch. Which command should be used next time to integrate the feature branch?

A.git merge --squash feature/login
B.git cherry-pick f4e5d6c a7b8c9d
C.git merge --no-ff feature/login
D.git rebase main feature/login then git merge --ff-only
AnswerD

Rebase creates linear history; fast-forward merge preserves it.

Why this answer

Option D is correct because the team requires a linear history on the main branch. By first rebasing the feature branch onto main (`git rebase main feature/login`), you reapply the feature commits on top of the latest main commit, creating a clean, linear sequence. Then `git merge --ff-only` performs a fast-forward merge, which simply moves the main branch pointer forward without creating a merge commit, preserving the linear history policy.

Exam trap

The trap here is that candidates often confuse `--no-ff` (which preserves history but creates a merge commit) with the requirement for linear history, or they incorrectly think `git cherry-pick` is a valid way to integrate an entire feature branch.

How to eliminate wrong answers

Option A is wrong because `git merge --squash` collapses all feature commits into a single commit, which violates the requirement to integrate the feature branch while preserving its individual commits (the log shows multiple commits). Option B is wrong because `git cherry-pick f4e5d6c a7b8c9d` only applies two specific commits, not the entire feature branch, and it does not integrate the branch in a way that maintains a clean linear history. Option C is wrong because `git merge --no-ff` forces a merge commit even when a fast-forward is possible, which creates a non-linear history (a merge bubble) that violates the linear history policy.

799
MCQeasy

Your development team uses GitHub Enterprise with GitHub Actions for CI/CD. The security team wants to ensure that all secrets used in workflows are stored in GitHub Secrets and that they are not accessible to forked repositories. Currently, some workflows reference secrets directly in YAML files. You need to implement a solution that meets the following requirements: (1) Secrets must be stored in GitHub Secrets, not in YAML files. (2) Workflows triggered from forked repositories must not have access to organization secrets. (3) Auditors must be able to see which workflows access which secrets. Option A: Move all secrets to GitHub Secrets, configure the repository to require approval for all external contributions, and enable audit logging for secret usage. Option B: Move all secrets to GitHub Secrets, and in the repository settings, disable 'Allow GitHub Actions to create and approve pull requests' and enable 'Fork pull request workflows from outside collaborators' to require approval. Option C: Move all secrets to GitHub Secrets, and in the organization settings, enable 'Private repository fork policy' to only allow forks from within the organization, and use environment secrets with required reviewers. Option D: Move all secrets to GitHub Secrets, and for each workflow that uses secrets, add a condition to check if the event is from a fork, and if so, skip the step. Which option best satisfies all requirements?

A.Move all secrets to GitHub Secrets, and for each workflow that uses secrets, add a condition to check if the event is from a fork, and if so, skip the step
B.Move all secrets to GitHub Secrets, configure the repository to require approval for all external contributions, and enable audit logging for secret usage
C.Move all secrets to GitHub Secrets, and in the repository settings, disable 'Allow GitHub Actions to create and approve pull requests' and enable 'Fork pull request workflows from outside collaborators' to require approval
D.Move all secrets to GitHub Secrets, and in the organization settings, enable 'Private repository fork policy' to only allow forks from within the organization, and use environment secrets with required reviewers
AnswerB

This meets all requirements: secrets in GitHub Secrets, fork access controlled via approval, and audit logging available.

Why this answer

Option A is correct. By moving secrets to GitHub Secrets, they are not in YAML. Requiring approval for external contributions ensures forked repos do not get access to secrets (since secrets are not passed to workflows triggered by pull requests from forks unless explicitly approved).

Audit logging tracks secret usage. Option B does not address fork access to secrets. Option C restricts forks but does not prevent secret exposure if a fork is made.

Option D is a workaround but not a policy-level solution.

800
Multi-Selecteasy

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

Select 2 answers
A.Continuous integration (CI) trigger
B.Webhook trigger
C.Pull request trigger
D.Manual trigger
E.Scheduled trigger
AnswersA, C

Triggers on code commits.

Why this answer

Options A and C are correct. A: Continuous integration (CI) trigger runs on code push. C: Pull request trigger runs on PR creation.

Option B is wrong because a manual trigger requires user action. Option D is wrong because a scheduled trigger is time-based, but not automatic on code changes. Option E is wrong because a webhook trigger is also automatic but not a built-in trigger type in Azure Pipelines (it's a service hook).

801
MCQhard

You have a YAML pipeline that uses a self-hosted agent. The agent runs on a VM in Azure. The pipeline fails intermittently with the error: '##[error]The job running on agent MyAgent has been cancelled because the agent was idle for more than the maximum idle time.' You need to resolve this issue. What should you do?

A.Configure the agent's idle timeout setting to a higher value or disable it.
B.Add more agents to the agent pool.
C.Increase the job's timeout in minutes.
D.Reduce the number of parallel jobs to avoid overloading the agent.
AnswerA

The idle timeout cancels the job if the agent is idle too long; increasing it prevents premature cancellation.

Why this answer

Option B is correct because the agent is being reaped due to idle timeout. Disabling the idle timeout or increasing its value prevents the agent from being cancelled when the job takes time to start (e.g., waiting for dependencies). Option A is wrong because communication timeout is different from idle timeout.

Option C is wrong because increasing agent pool size does not prevent individual agent timeout. Option D is wrong because parallel jobs do not affect idle timeout.

802
MCQeasy

Your team uses GitHub Actions for CI/CD. You need to collect and analyze build and deployment logs centrally to identify recurring failures. Which service should you use to ingest and query these logs?

A.Azure Monitor Alerts
B.Azure Log Analytics
C.GitHub Insights
D.Application Insights
AnswerB

Can ingest and query CI/CD logs centrally.

Why this answer

Option A is correct because Azure Log Analytics can ingest logs from GitHub Actions via connectors or API. Option B is wrong because Application Insights is for application monitoring, not CI/CD logs. Option C is wrong because GitHub Insights is a reporting feature, not a log analytics platform.

Option D is wrong because Azure Monitor Alerts is for alerting, not storage/query.

803
MCQhard

Refer to the exhibit. A developer pushes a commit to the main branch. Which stages will run?

A.Only the Test stage.
B.Only the Build stage.
C.Neither stage.
D.Both Build and Test stages.
AnswerB

Correct: Build runs, Test is skipped due to condition.

Why this answer

The exhibit shows a pipeline with a trigger condition set to 'main' for the Build stage only. The Test stage has no trigger condition defined, meaning it will only run if explicitly triggered by a preceding stage or a separate trigger. When a developer pushes a commit to the main branch, only the Build stage is triggered because it is the only stage with a branch filter matching 'main'.

The Test stage does not have a trigger, so it will not run automatically.

Exam trap

The trap here is that candidates assume all stages in a pipeline run automatically when a commit is pushed, but Azure Pipelines allows stage-level triggers that can prevent stages from running unless their specific conditions are met.

How to eliminate wrong answers

Option A is wrong because the Test stage has no trigger condition defined, so it will not run when a commit is pushed to main; only the Build stage runs. Option C is wrong because the Build stage has a trigger condition set to 'main', so it will run when a commit is pushed to main. Option D is wrong because the Test stage does not have a trigger condition, so it will not run alongside the Build stage.

804
MCQeasy

Your team uses Azure Pipelines for CI/CD. You need to ensure that only approved branches can trigger production deployments. Which feature should you use?

A.YAML template expressions
B.Branch control for environments
C.Deployment gates
D.Pipeline decorators
AnswerB

Branch control restricts which branches can deploy to an environment.

Why this answer

Branch control policies in environments restrict which branches can deploy to each environment. Option A is wrong because pipeline decorators inject steps but don't restrict branches. Option B is wrong because deployment gates check health metrics.

Option D is wrong because YAML templates organize jobs, not branch permissions.

805
MCQeasy

Your organization uses Azure Repos for source control and Azure Pipelines for CI/CD. You need to implement a policy that ensures every commit to the main branch is built and passes all tests before it can be merged. The team uses feature branches for development. What is the most efficient way to enforce this?

A.Require developers to manually run the pipeline before merging.
B.Use a pre-merge validation pipeline that runs on pull requests but does not block merging.
C.Configure a branch policy on the main branch that requires a successful build from a pull request trigger.
D.Set up a CI trigger on the main branch to run the pipeline on every commit.
AnswerC

Branch policies enforce build success before merge.

Why this answer

Option A is correct because branch policies on the main branch can require a successful build before merging. Option B is incorrect because pipeline triggers don't enforce merge requirements. Option C is incorrect because manual builds don't enforce.

Option D is incorrect because it doesn't enforce before merge.

806
MCQmedium

Your organization uses Microsoft Teams for communication. You want to send a notification to a Teams channel when a release pipeline fails. Which action should you configure?

A.Configure an email notification to the team.
B.Add the 'Microsoft Teams Notification' task to the pipeline.
C.Use Azure Monitor alerts to send to Teams.
D.Add a Service Hook endpoint for Teams.
AnswerB

This task sends customizable messages to Teams.

Why this answer

The 'Microsoft Teams Notification' task is a built-in Azure DevOps pipeline task that directly sends customizable notifications to a specified Teams channel when a pipeline event (such as failure) occurs. It requires no external configuration or additional services, making it the simplest and most appropriate choice for sending failure notifications from a release pipeline to Teams.

Exam trap

The trap here is that candidates confuse the 'Microsoft Teams Notification' task (a pipeline task) with a Service Hook subscription (a project-level integration), leading them to choose Option D even though it is not an action configured within the pipeline itself.

How to eliminate wrong answers

Option A is wrong because email notifications target individual or group email addresses, not a Teams channel, and require SMTP configuration; they do not integrate with Teams' messaging infrastructure. Option C is wrong because Azure Monitor alerts are designed for monitoring Azure resources and services, not for reacting to Azure DevOps pipeline events; they would require additional logic and webhook configuration to forward to Teams. Option D is wrong because a Service Hook endpoint for Teams is used to subscribe to Azure DevOps events (like release completion) and send them to a Teams channel via a connector, but it is not a pipeline task; it is configured at the project or collection level, not within the pipeline itself, and requires manual setup of a Teams incoming webhook.

807
MCQhard

A company has a multi-region application deployed on Azure App Service (Windows) across three regions: West US, East US, and West Europe. The operations team uses Azure Monitor to collect application logs and metrics. Recently, they noticed that the application in West US is experiencing high CPU usage (sustained above 90%) during peak hours, while the other regions remain below 60%. The team has set up an autoscale rule on the App Service plan to scale out when CPU exceeds 80% for 10 minutes. However, autoscale is not triggering, and the application in West US is becoming slow. The team has verified that the autoscale rule is correctly configured, the instance count is below the maximum, and there are no scale-in rules interfering. The metric data appears in Azure Monitor. You suspect that the metric alert that triggers autoscale is not firing. What is the most likely cause?

A.The autoscale rule is using the wrong metric aggregation or namespace, such as 'CpuTime' instead of 'Percentage CPU'.
B.The autoscale rule was created less than 24 hours ago and needs a learning period.
C.The metric collection interval for CPU is set to 30 minutes, causing a delay in autoscale evaluation.
D.The autoscale rule is configured to use Log Analytics queries instead of platform metrics.
AnswerA

Autoscale requires the correct metric and aggregation to trigger.

Why this answer

Option A is correct because the autoscale rule must use the correct metric name and aggregation to evaluate scaling conditions. If the rule is configured with 'CpuTime' instead of 'Percentage CPU', it will not match the actual CPU utilization metric emitted by the Azure App Service plan. 'Percentage CPU' is the standard platform metric for CPU load, while 'CpuTime' measures total CPU time consumed, which does not trigger the same threshold logic. Since the team verified the rule is correctly configured but autoscale is not firing, the most likely cause is a mismatch in the metric name or namespace.

Exam trap

The trap here is that candidates may assume autoscale is failing due to a learning period or data delay, but the real issue is a subtle metric name mismatch that prevents the rule from evaluating the correct data stream.

How to eliminate wrong answers

Option B is wrong because autoscale rules do not require a 24-hour learning period; the 'learning period' applies to predictive autoscale or certain metric-based rules that need historical data, but standard threshold-based autoscale rules evaluate immediately after creation. Option C is wrong because the metric collection interval for CPU on Azure App Service is typically 1 minute, not 30 minutes; a 30-minute interval would be unusual and would cause significant delays, but the question states metric data appears in Azure Monitor, implying normal collection. Option D is wrong because autoscale rules can only use platform metrics or custom metrics from Azure Monitor, not Log Analytics queries directly; Log Analytics queries are used for alert rules, not autoscale conditions.

808
MCQmedium

Your organization must comply with SOC 2 requirements. You are using Azure DevOps and need to ensure that all pipeline runs are logged and that logs are retained for at least one year. Which configuration should you implement?

A.Increase the retention period of pipeline logs in the Azure DevOps UI.
B.Configure diagnostic settings for the Azure DevOps organization.
C.Disable the option to delete pipelines.
D.Enable audit streaming to a Log Analytics workspace and set retention to 365 days.
AnswerD

Audit streaming allows long-term retention and compliance.

Why this answer

Option D is correct because enabling Azure DevOps audit streaming to a Log Analytics workspace allows long-term retention and compliance. Option A is wrong because the default retention is shorter. Option B is wrong because disabling pipeline deletion does not affect log retention.

Option C is wrong because diagnostic settings in Azure are for Azure resources, not Azure DevOps pipelines.

809
Multi-Selectmedium

Which TWO actions can you take to improve the security of secrets in Azure Pipelines? (Choose two.)

Select 2 answers
A.Log secret values for debugging purposes
B.Limit variable group permissions to specific pipelines
C.Allow pipeline users to override secret values at queue time
D.Use Azure Key Vault to store secrets and map them as secret variables
E.Store secrets as plain text variables in the pipeline
AnswersB, D

Restricting access to variable groups ensures only authorized pipelines can use the secrets.

Why this answer

Options B and C are correct. Option B: Using Azure Key Vault to store secrets and mapping them as secret variables prevents exposure. Option C: Limiting variable group permissions ensures only authorized pipelines can access secrets.

Option A is wrong because storing secrets as plain text variables exposes them in logs. Option D is wrong because checking 'Allow at queue time' exposes secrets to users. Option E is wrong because logging secret values defeats the purpose.

810
MCQmedium

Your team uses Azure Pipelines for CI/CD. You need to enforce that all pipeline runs use approved agents from a specific agent pool with the latest security patches. The agents are self-hosted on Azure VMs. What should you implement?

A.Configure pipeline permissions for the agent pool
B.Create a deployment pool and assign the agents to it
C.Set the agent pool to use a specific agent queue with an isolation scope
D.Add a demand on the agent for a custom capability that only approved agents have
AnswerC

An agent pool with an isolation scope ensures only approved agents from that queue are used.

Why this answer

Option C is correct because setting the agent pool to use a specific agent queue with an isolation scope ensures that only approved, security-patched agents from that queue are used for pipeline runs. This configuration restricts the pool to a designated set of self-hosted agents, preventing unauthorized or unpatched agents from executing jobs.

Exam trap

The trap here is that candidates often confuse agent pool permissions (access control) with agent selection enforcement, or mistakenly think deployment pools (used for release targets) can restrict build agent usage, when the correct mechanism is isolating agents via a dedicated queue with scope restrictions.

How to eliminate wrong answers

Option A is wrong because configuring pipeline permissions for the agent pool controls who can use the pool, but does not enforce that only agents with the latest security patches are selected; it manages access, not agent eligibility. Option B is wrong because a deployment pool is designed for managing deployment targets (e.g., VMs for releases), not for controlling which build agents are used in pipeline runs; it does not enforce agent patching or approval. Option D is wrong because adding a demand for a custom capability only filters agents based on that capability label, but it does not inherently ensure the agent has the latest security patches unless the capability is manually and reliably updated, which is error-prone and not a built-in enforcement mechanism.

811
Multi-Selectmedium

Which TWO practices are recommended for managing secrets in Azure Pipelines?

Select 2 answers
A.Define secret variables in the pipeline UI and mark them as secret
B.Use environment variables in the build agent
C.Use Azure Key Vault to store secrets and map them as variables
D.Set secret variables in the YAML file with the 'secret' keyword
E.Store secrets as plain text in YAML variables
AnswersA, C

This keeps secrets out of the repository.

Why this answer

Options B and D are correct. Option B is correct because variables mapped from Azure Key Vault are secure and audited. Option D is correct because secret variables should be set in the pipeline UI, not YAML.

Option A is wrong because hardcoding secrets is insecure. Option C is wrong because secret variables are masked, not visible.

812
MCQhard

Your organization uses Azure DevOps for a large-scale e-commerce platform. The source code is stored in a single Azure Repos Git repository with over 100 contributors. The current branching strategy is a modified GitFlow with main, develop, release, and hotfix branches. However, the team is experiencing frequent merge conflicts and long integration periods. You have been asked to redesign the branching strategy to support continuous integration and deployment (CI/CD) while ensuring high-quality releases. The new strategy must reduce merge conflicts, enable fast feedback, and support hotfixes. The team uses feature flags to manage incomplete features. Which branching strategy should you recommend?

A.Implement trunk-based development: developers work on short-lived feature branches (less than a day) and merge to main multiple times a day. Use feature flags to control release of incomplete features. Hotfixes are created from main and merged back quickly.
B.Use a single main branch and allow developers to commit directly to main, but require all commits to be small and pass CI. Hotfixes are committed directly to main.
C.Use a single main branch and create release branches from main for each deployment. Feature branches are merged to release branches, and then release branches are merged to main after deployment.
D.Continue using GitFlow but enforce stricter branch policies and require more frequent merges.
AnswerA

Trunk-based development with feature flags minimizes merge conflicts and enables CI/CD.

Why this answer

Option B is correct because trunk-based development with short-lived feature branches and feature flags is designed to reduce merge conflicts and enable continuous integration. Option A is incorrect because GitFlow is the current problematic strategy. Option C is incorrect because release branches are not suitable for CI/CD with feature flags.

Option D is incorrect because long-lived feature branches are the opposite of what is needed.

813
MCQhard

Your team uses GitHub Actions to deploy a microservices application to a Kubernetes cluster. The workflow builds Docker images and pushes them to a container registry, then updates the Kubernetes deployment. The deployment often fails due to image pull errors, specifically 'ErrImagePull' and 'ImagePullBackOff'. You investigate and find that the image tag in the Kubernetes manifest is the commit SHA. The workflow uses the 'azure/k8s-deploy@v1' action. You suspect that the image is not being pulled because the registry credentials are not properly configured. You have stored the registry credentials as secrets. What is the most likely cause and solution?

A.The commit SHA tag is not valid; use 'latest' tag instead.
B.The image name is incorrect; verify the registry URL.
C.The 'azure/k8s-deploy' action does not support private registries; use a different action.
D.The action does not automatically create imagePullSecrets; you need to add a step to create the secret in the cluster and reference it in the deployment.
AnswerD

The action requires that the cluster already has the image pull secret or you must create it.

Why this answer

Option A is correct because the k8s-deploy action by default uses the kubeconfig file for cluster access but does not automatically set up image pull secrets for the registry. The credentials need to be explicitly configured as imagePullSecrets in the deployment manifest. Option B is wrong because the image tag is correct; the issue is authentication.

Option C is wrong because the image name is likely correct; the issue is pulling. Option D is wrong because the action is capable of deploying; the issue is configuration.

814
MCQeasy

Your organization requires that all code changes be signed using a valid code signing certificate before they can be merged. Which feature in GitHub should you enable to enforce this?

A.Dependabot.
B.Commit signature verification.
C.Code scanning.
D.Secret scanning.
AnswerB

This requires all commits to be signed with a verified key.

Why this answer

Option A is correct because commit signature verification in GitHub enforces that commits are signed with a verified GPG or S/MIME key. Option B is wrong because secret scanning detects secrets, not signature enforcement. Option C is wrong because Dependabot handles dependency updates.

Option D is wrong because code scanning analyzes code for vulnerabilities.

815
MCQmedium

Your organization uses GitHub Enterprise with a monorepo containing multiple microservices. Developers work on feature branches and create pull requests to merge into main. You need to implement a policy that ensures all pull requests have at least one review from a code owner, pass required status checks (CI build and unit tests), and are up-to-date with the latest main branch before merging. Additionally, you want to prevent direct pushes to main. Which combination of branch protection rules should you configure?

A.Require pull request reviews before merging, require status checks, and restrict who can push to matching branches.
B.Require pull request reviews before merging, require branches to be up-to-date, and restrict push access to admins only.
C.Require status checks, require branches to be up-to-date, and include administrators.
D.Require pull request reviews before merging, require status checks, require branches to be up-to-date, and restrict who can push to matching branches.
AnswerD

Includes all required protections.

Why this answer

Option D is correct because it includes all required elements: require pull request reviews before merging, require status checks, require branches to be up-to-date, and restrict direct pushes. Option A lacks the up-to-date requirement. Option B does not require pull requests.

Option C lacks status checks.

816
MCQhard

Your organization uses GitHub Advanced Security. A developer reports that a secret scanning alert for an Azure DevOps Personal Access Token (PAT) is a false positive. What should you do to handle this?

A.Disable secret scanning for the repository.
B.Delete the PAT from the repository and revoke it.
C.Mark the alert as false positive in the GitHub UI.
D.Ignore the alert and leave it open.
AnswerC

This hides the alert and improves detection accuracy.

Why this answer

Option B is correct because marking the alert as false positive in the GitHub UI hides it and helps train the detection. Option A is wrong because deleting the PAT doesn't address the alert. Option C is wrong because disabling secret scanning removes detection entirely.

Option D is wrong because ignoring the alert leaves it open.

817
MCQmedium

You have a YAML pipeline that builds a .NET application. You want to cache the NuGet packages to speed up subsequent builds. Which task should you use?

A.CopyFiles task to copy packages to a staging directory.
B.NuGet restore task with 'cacheRestore' option.
C.Cache task with a key based on the packages.lock.json hash.
D.PublishBuildArtifacts task to upload packages.
AnswerC

Cache task uses key to restore/save packages.

Why this answer

Option A is correct because Cache task restores/saves a cache keyed by hash. Option B is wrong because NuGet restore does not cache by itself. Option C is wrong because CopyFiles copies files, not caches.

Option D is wrong because PublishBuildArtifacts is for artifacts, not caching.

818
MCQmedium

A development team is designing a build pipeline for a microservices application. They want to ensure that each service is built and tested independently, but they also need to run integration tests that span multiple services. What is the recommended approach?

A.Use a single release pipeline that triggers manual deployment for each service.
B.Create a single build pipeline that builds all services together to ensure consistency.
C.Create individual build pipelines for each service, and a separate release pipeline that deploys all services to an integration environment for testing.
D.Build each service separately, but skip integration tests to avoid complexity.
AnswerC

This allows independent builds and integration tests.

Why this answer

Option C is correct because it aligns with microservices best practices: each service has its own build pipeline for independent compilation, unit testing, and artifact generation, while a separate release pipeline orchestrates deployment of all services to a shared integration environment for cross-service testing. This decouples build concerns from deployment concerns, enabling parallel development and faster feedback loops.

Exam trap

The trap here is that candidates confuse 'building independently' with 'testing independently' and assume integration tests must be run within the build pipeline, when in fact they should be run in a separate release pipeline after deployment to a shared environment.

How to eliminate wrong answers

Option A is wrong because using a single release pipeline with manual deployment for each service introduces human delay and inconsistency, and it does not address independent building or automated integration testing. Option B is wrong because a single build pipeline that builds all services together violates the microservices principle of independent deployability, creating tight coupling and longer build times. Option D is wrong because skipping integration tests entirely defeats the purpose of verifying inter-service communication and data consistency, which is critical in a microservices architecture.

819
MCQmedium

Your team uses Azure Pipelines and wants to automatically create a release every time a build succeeds on the main branch. Which trigger should you configure?

A.Pull request trigger in the build pipeline
B.Continuous integration (CI) trigger in the release pipeline
C.Build completion trigger in the release pipeline
D.Scheduled trigger in the release pipeline
AnswerC

This triggers a release when a specific build pipeline completes.

Why this answer

Option D is correct because the build completion trigger in a release pipeline automatically creates a release when a build completes. Option A is wrong for a release pipeline. Option B is wrong because CI triggers are for build pipelines.

Option C is wrong because scheduled triggers run at specific times, not on build completion.

820
Multi-Selecthard

Your team uses GitHub Actions to build a multi-container application. The build must produce container images that are scanned for vulnerabilities and signed. Which THREE actions are required in the workflow?

Select 3 answers
A.Use the docker/login-action to authenticate with Docker Hub.
B.Add a step to run a container scan tool like Trivy.
C.Add a step to sign the container image using cosign.
D.Use the actions/checkout action to checkout the code.
E.Use the docker/build-push-action to build and push images.
AnswersB, C, E

Trivy scans for vulnerabilities.

Why this answer

Option A is correct because Docker Build Push action creates images. Option C is correct because container scanning uses tools like Trivy or Grype. Option E is correct because signing requires a step to sign images.

Options B and D are not required for the given tasks.

821
MCQmedium

Your team uses a YAML-based build pipeline in Azure Pipelines. You need to ensure that the pipeline runs automatically when a pull request is created against the main branch, but only if the changes include modifications to the 'src/' directory. Which trigger configuration should you use?

A.trigger: - main; pr: none
B.trigger: none; pr: branches: include: - main paths: include: - src/*
C.trigger: none; pr: - main
D.pr: - main; trigger: - main
AnswerB

This limits PR triggers to changes in src/ on main branch.

Why this answer

Option B is correct because the 'pr' trigger with path filters ensures the pipeline runs on PRs only when changes match the specified paths. Option A is wrong because it triggers on all PRs without filtering. Option C is wrong because branch filters alone do not filter by path.

Option D is wrong because 'trigger' is for CI builds, not PR triggers.

822
MCQeasy

A team uses Git for source control. They want to automatically squash all commits in a feature branch into a single commit when merging to the main branch. Which merge type should they use?

A.Rebase and fast-forward
B.Squash commit
C.Merge commit (no fast-forward)
D.Semi-linear merge
AnswerB

Combines all changes into a single commit on target branch.

Why this answer

B is correct because the squash commit merge type collapses all commits in a feature branch into a single new commit on the target branch. This satisfies the requirement to automatically squash all commits when merging to main, as it creates a clean, linear history with one combined commit that contains all changes from the feature branch.

Exam trap

The trap here is that candidates often confuse 'squash commit' with 'rebase and fast-forward' because both can produce a linear history, but only squash commit collapses multiple commits into one.

How to eliminate wrong answers

Option A is wrong because rebase and fast-forward replays each individual commit from the feature branch onto the tip of main, preserving the full commit history rather than squashing them into one. Option C is wrong because merge commit (no fast-forward) creates a merge commit that preserves all individual commits from the feature branch, resulting in a non-linear history with multiple commits. Option D is wrong because semi-linear merge (also called rebase merge) first rebases the feature branch onto main and then creates a merge commit, but still retains all original commits from the feature branch instead of squashing them.

823
MCQmedium

The pipeline above fails with: 'The deployment job 'DeployToProd' references environment 'Production' which does not exist.' What should you do to resolve this error?

A.Remove the 'environment' property from the deployment job.
B.Change the deployment strategy from 'runOnce' to 'rolling'.
C.Add a script step before the deployment job to create the environment.
D.Create an environment named 'Production' in Azure DevOps project settings.
AnswerD

The environment must exist before referencing it.

Why this answer

Option D is correct because creating the 'Production' environment in Azure DevOps will resolve the reference. Option A is wrong because changing to runOnce doesn't fix missing environment. Option B is wrong because adding a new job doesn't help.

Option C is wrong because removing the environment reference removes the deployment strategy.

824
MCQmedium

Your team is using Azure Pipelines to deploy a web application to Azure App Service. The application uses a configuration file (appsettings.json) that contains environment-specific settings. You need to manage these settings across development, staging, and production environments without exposing secrets in the source code. The pipeline should automatically replace the settings during deployment. What should you configure?

A.Use the 'File Transform' task in the release pipeline to replace tokens in the configuration file with variables defined in pipeline variable groups.
B.Create separate build configurations for each environment and use the 'Transform Web.config' task.
C.Use the 'Azure App Service Deploy' task with the 'Use Web Deploy' option and configure parameterization.
D.Set environment variables in the Azure App Service and read them in the application code.
AnswerA

This task supports token replacement and can reference variables securely.

Why this answer

Option A is correct: Use the 'File Transform' task to substitute variables from pipeline variables or variable groups. Option B is incorrect because build configuration transforms are for .NET projects and require specific setup. Option C is incorrect because environment variables are not directly used for file transforms.

Option D is incorrect because Azure App Service application settings are for the runtime, not for transforming configuration files during deployment.

825
MCQmedium

Refer to the exhibit. You have an Azure Pipelines YAML file for a .NET Core application. The pipeline is triggered on changes to the main branch, but only for files under src/. After a push to main that modifies a file in src/, the pipeline does not start. What is the most likely reason?

A.The branch filter is missing the 'refs/heads/' prefix.
B.The trigger configuration has a syntax error: 'include' should be 'includes'.
C.The variable 'buildConfiguration' is not defined at the top level.
D.The path filter 'src/*' does not match files in subdirectories of src/.
AnswerD

Azure Pipelines path filters require '**' for recursive matching.

Why this answer

Option B is correct because the trigger has a path filter with include but no exclude, which is correct, but the indentation of 'paths' is wrong (it should be at the same level as 'branch')? Actually the exhibit shows correct indentation. Another common issue: The trigger definition is inside an array, but the YAML might be parsed incorrectly. Actually the root cause is that the pipeline is defined as a multi-stage YAML but the trigger is configured at the top level; however, the exhibit shows the trigger correctly.

The real issue: The trigger path filter 'include' pattern 'src/*' does not recursively match files in subdirectories. Azure Pipelines path filters require '**' for recursive matches. So the pipeline does not trigger because 'src/*' only matches files directly in src/, not in subfolders.

Option A is wrong because the syntax is valid. Option C is wrong because the branch is main. Option D is wrong because the build configuration variable does not affect triggers.

Page 10

Page 11 of 13

Page 12