Courseiva

Microsoft Azure DevOps Engineer Expert AZ-400 (AZ-400) — Questions 826–900

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

Take a mock examExam hub
Page 11

Page 12 of 13

Page 13
826
MCQeasy

Your team wants to implement a policy that requires all pull requests to have at least one approval from a member of the 'Senior Developers' group before merging. Which mechanism should you use?

A.Add a CODEOWNERS file that designates 'Senior Developers' as owners of all files.
B.Create a branch policy on the target branch that requires a minimum number of reviewers from the 'Senior Developers' group.
C.Configure the pull request dashboard to display required reviewers.
D.Set up a build validation policy that runs a script to check approvals.
AnswerB

Branch policies enforce review requirements.

Why this answer

Azure Repos branch policies allow you to enforce required reviewers on pull requests. By creating a branch policy on the target branch that requires a minimum number of reviewers from the 'Senior Developers' group, you ensure that no pull request can be completed without at least one approval from that group. This directly meets the requirement without relying on file-level ownership or external scripts.

Exam trap

The trap here is that candidates confuse CODEOWNERS (which only requests reviews) with a branch policy that enforces required approvals, leading them to choose option A even though it does not block merging without the required approval.

How to eliminate wrong answers

Option A is wrong because a CODEOWNERS file designates owners for specific files and automatically requests their review, but it does not enforce a minimum number of approvals from a group before merging; it only notifies them. Option C is wrong because configuring the pull request dashboard to display required reviewers is a UI customization that does not enforce any policy or block merging. Option D is wrong because a build validation policy runs a script to validate code quality or compliance, but it cannot enforce a specific number of human approvals from a group; it is meant for automated checks, not reviewer requirements.

Full explanation →
827
MCQhard

Your team uses Azure Repos and wants to enforce that all commits to the release branch must be signed using GPG. Which branch policy should you enable?

A.Limit merge types
B.Check for linked work items
C.Require a minimum number of reviewers
D.Require signed commits
AnswerD

This policy enforces GPG or S/MIME signing.

Why this answer

Option D is correct because Azure Repos branch policies include a 'Require signed commits' setting that enforces GPG signature verification on all commits pushed to the branch. When enabled, any commit without a valid GPG signature is rejected, ensuring the integrity and authenticity of the commit author.

Exam trap

The trap here is that candidates may confuse 'Require signed commits' with other authentication or authorization policies, such as requiring reviewers or limiting merge types, because all are listed under branch policy settings but serve entirely different security purposes.

How to eliminate wrong answers

Option A is wrong because 'Limit merge types' controls the merge strategies (e.g., squash, rebase, or no-fast-forward) allowed on the branch, not commit signing. Option B is wrong because 'Check for linked work items' enforces that pull requests reference Azure Boards work items, which is unrelated to cryptographic commit signing. Option C is wrong because 'Require a minimum number of reviewers' mandates a certain count of reviewers approve a pull request before merging, but does not enforce that individual commits are signed with GPG.

Full explanation →
828
MCQhard

You are designing a branching strategy for a microservices application with independent deployment cadences. The team wants to support continuous deployment to production from the main branch while allowing feature work to be isolated and tested. Which branching strategy best meets these requirements?

A.One branch per environment (dev, test, prod)
B.GitHub Flow with feature branches merging to main
C.Trunk-based development with short-lived feature branches
D.Git Flow with develop, release, and hotfix branches
AnswerC

Supports CI/CD and isolation.

Why this answer

Trunk-based development with short-lived feature branches (C) is correct because it enables continuous deployment from the main branch while isolating feature work in branches that are merged back to main within hours or a day. This approach minimizes merge conflicts and supports independent deployment cadences for microservices, as each service can be deployed from main independently without waiting for release branches.

Exam trap

The trap here is that candidates confuse GitHub Flow with trunk-based development, but GitHub Flow lacks the strict short-lived branch discipline and feature toggle support required for true continuous deployment from main in a microservices context.

How to eliminate wrong answers

Option A is wrong because one branch per environment (dev, test, prod) creates long-lived branches that diverge over time, leading to merge hell and preventing continuous deployment from a single source of truth. Option B is wrong because GitHub Flow with feature branches merging to main does not inherently support independent deployment cadences for microservices; it assumes a single deployment pipeline and can cause blocking if multiple features are merged before validation. Option D is wrong because Git Flow with develop, release, and hotfix branches introduces long-lived branches and release cycles that conflict with continuous deployment to production from main, as releases are staged through develop and release branches rather than directly from main.

Full explanation →
829
MCQmedium

Your organization uses GitHub Actions for CI/CD. You have a workflow that deploys to Azure App Service. The deployment uses a publish profile secret stored as a GitHub secret. You want to improve security by using OpenID Connect (OIDC) to authenticate to Azure without storing secrets. What should you do?

A.Remove the secret and use Azure AD Managed Identity directly from the GitHub runner.
B.Configure the GitHub workflow to use the 'azure/login' action with OIDC, and set up a federated identity credential in Microsoft Entra ID for the GitHub environment.
C.Replace the publish profile secret with an Azure service principal secret stored as a GitHub secret.
D.Use the 'Azure App Service Deploy' task with the 'Publish Profile' parameter set to an empty string.
AnswerB

OIDC eliminates the need for long-lived secrets.

Why this answer

Option B is correct: Configuring OIDC with Azure AD (now Microsoft Entra ID) app registration and federated credentials allows token-based authentication without secrets. Option A is incorrect because GitHub secrets are still secrets. Option C is incorrect because Azure AD is not required to be replaced; OIDC works with it.

Option D is incorrect because the Azure/login action supports OIDC.

Full explanation →
830
Multi-Selectmedium

Which TWO conditions must be met to use the 'Approvals and gates' feature in a release pipeline? (Choose two.)

Select 2 answers
A.A manual intervention task must be added.
B.A post-deployment approval must be configured.
C.A pre-deployment approval must be configured.
D.A variable group must be linked to the pipeline.
E.The pipeline must use a service connection.
AnswersB, C

Post-deployment approvals are also a type of approval.

Why this answer

Options A and C are correct. Approvals and gates require a pre-deployment approval and a post-deployment approval. Option B is incorrect because gates can be used without manual approval.

Option D is incorrect because variable groups are not required. Option E is incorrect because service connections are not specifically required for approvals.

Full explanation →
831
MCQhard

You are the lead DevOps engineer for a large e-commerce company. The company has a multi-region Azure Kubernetes Service (AKS) cluster deployment for its microservices. The current CI/CD pipeline uses Azure DevOps to build Docker images and deploy to AKS via Helm charts. Recently, the team noticed that after a deployment to the West Europe region, the application experienced a 5-minute downtime due to a configuration error where the new pods couldn't connect to the database because the connection string was pointing to a staging database instead of production. The issue was detected manually after a customer reported the outage. The team wants to implement a mechanism to automatically detect such misconfigurations before they affect production traffic. They also want to ensure that if a deployment fails health checks, the previous version is automatically rolled back. The pipeline currently runs all stages in sequence: build, deploy to West Europe, then deploy to East US. The team has a small budget for additional resources. Which approach should the team implement?

A.Implement a canary deployment strategy with automated health checks and automatic rollback on failure.
B.Use a blue-green deployment strategy with deployment slots in AKS.
C.Add a manual approval gate before the deployment to East US, requiring a tester to verify the deployment in West Europe.
D.Deploy to a separate test environment first, run integration tests, then deploy to production.
AnswerA

Canary releases with health checks and rollback catch misconfigurations early and minimize impact.

Why this answer

Option A is correct because a canary deployment strategy with automated health checks and automatic rollback directly addresses the need to detect misconfigurations before they affect all production traffic. By routing a small percentage of traffic to the new pods and monitoring health probes (e.g., liveness and readiness probes in Kubernetes), the pipeline can automatically roll back if the canary fails, preventing the 5-minute downtime scenario. This approach is cost-effective as it leverages existing AKS features without requiring additional infrastructure.

Exam trap

The trap here is that candidates may confuse blue-green or test environment strategies with automated detection and rollback, but these options lack the real-time health monitoring and automatic traffic shifting that canary deployments provide for catching configuration errors in production.

How to eliminate wrong answers

Option B is wrong because blue-green deployment with deployment slots in AKS does not inherently provide automated health checks or rollback on failure; it requires manual traffic switching and does not automatically detect configuration errors like a wrong database connection string. Option C is wrong because adding a manual approval gate before deploying to East US still relies on human verification, which is slow and error-prone, and does not automatically detect misconfigurations or trigger rollback. Option D is wrong because deploying to a separate test environment first and running integration tests does not guarantee that the exact production configuration (e.g., database connection strings) is validated; it also adds cost and complexity without addressing the need for automatic rollback in production.

Full explanation →
832
MCQeasy

Your organization uses Microsoft Entra ID (formerly Azure AD) for identity management. You need to ensure that only authorized users can access the Azure DevOps organization. What is the most secure way to manage access?

A.Require all users to use multi-factor authentication (MFA) and enable Conditional Access policies.
B.Disable external user access and only allow internal users.
C.Use IP address restrictions to limit access to the corporate network.
D.Add users to the Azure DevOps organization and assign them to the 'Basic' access level.
AnswerA

Conditional Access policies provide secure, conditional access.

Why this answer

Option D is correct because Conditional Access policies provide granular access control based on conditions like location, device compliance, and risk. Option A is incorrect because it does not enforce additional security. Option B is incorrect because manual review is not scalable.

Option C is incorrect because disabling external users is not the most secure; it still allows all internal users.

Full explanation →
833
MCQeasy

Your organization uses Azure DevOps and Microsoft Entra ID. The compliance team needs to ensure that access to Azure DevOps projects is governed by conditional access policies. Which Azure DevOps integration should you use?

A.Link the Azure DevOps organization to the Microsoft Entra ID tenant and configure conditional access policies in Microsoft Entra ID.
B.Configure service hooks to enforce conditional access.
C.Assign managed identities to users for conditional access.
D.Use OAuth tokens to authenticate users.
AnswerA

Linking the Azure DevOps organization to the Microsoft Entra ID tenant allows conditional access policies to be applied to all users.

Why this answer

Azure DevOps supports Microsoft Entra ID conditional access policies, which apply to all users accessing Azure DevOps through the organization's tenant. Service hooks and OAuth tokens are for automation, not access control. Managed identities are for Azure resources, not user access.

Full explanation →
834
MCQhard

A financial services company uses Azure DevOps to manage CI/CD pipelines for a critical application. The security team requires that all production deployments be approved by two different managers, and that the build artifacts are immutable and signed. Currently, the pipeline uses a manual approval gate with one approver and stores artifacts in Azure Artifacts. What should the DevOps engineer implement to meet the security requirements?

A.Store artifacts in Azure Key Vault and use access policies to control deployment.
B.Use branch policies to require two reviewers on pull requests.
C.Configure a second manual approval gate and enable immutable feed in Azure Artifacts.
D.Add a pipeline decorator that injects a validation step for code signing.
AnswerC

This enforces two approvals and ensures artifacts cannot be overwritten.

Why this answer

Option C is correct because it directly addresses both security requirements: adding a second manual approval gate ensures two different managers must approve production deployments, and enabling the immutable feed in Azure Artifacts prevents any artifact from being overwritten or deleted, guaranteeing immutability. Code signing is not explicitly required by the question, but the immutable feed ensures artifact integrity, and the two-approver gate satisfies the dual-manager approval mandate.

Exam trap

The trap here is that candidates may confuse branch policies (which control code review) with deployment approval gates (which control release to production), or think that storing artifacts in Key Vault or adding a code-signing decorator alone satisfies the dual-approval and immutability requirements.

How to eliminate wrong answers

Option A is wrong because Azure Key Vault is designed for managing secrets and keys, not for storing build artifacts; it does not provide immutable artifact storage or deployment approval gates. Option B is wrong because branch policies requiring two reviewers on pull requests control code changes in the repository, not production deployment approvals; they do not enforce approval gates on the pipeline release process. Option D is wrong because a pipeline decorator injects a validation step for code signing, which addresses artifact signing but does not add a second manual approval gate or enforce immutable artifact storage.

Full explanation →
835
MCQmedium

You have a build pipeline that produces several artifacts. You need to publish these artifacts to Azure Artifacts feed, but only if the build succeeds. Which task should you add to the pipeline?

A.Add a 'Publish Build Artifacts' task and then a 'Universal Publish' task.
B.Add an 'npm publish' task to publish packages.
C.Add a 'Copy Files' task to copy artifacts to the feed location.
D.Add a 'NuGet push' task to push packages to the feed.
AnswerA

Correct: Publish build artifacts first, then publish to Azure Artifacts feed.

Why this answer

The 'Publish Build Artifacts' task makes the build outputs available as pipeline artifacts, and the 'Universal Publish' task is the correct way to publish those artifacts to an Azure Artifacts feed (which supports Universal Packages). This combination ensures artifacts are only published after the build succeeds because both tasks run in the pipeline's job sequence, and by default, subsequent tasks execute only if the previous task succeeded.

Exam trap

The trap here is that candidates often assume any package-specific task (npm, NuGet) can publish to Azure Artifacts, but the question asks for publishing 'several artifacts' (not just one package type), so the Universal Publish task is the only correct choice for a generic, multi-artifact scenario.

How to eliminate wrong answers

Option B is wrong because 'npm publish' is specific to npm packages and cannot publish arbitrary build artifacts to an Azure Artifacts feed. Option C is wrong because 'Copy Files' only copies files to a local or network path, not to an Azure Artifacts feed; it does not perform any publish operation. Option D is wrong because 'NuGet push' is limited to NuGet packages and cannot handle other artifact types like Universal Packages or Maven artifacts.

Full explanation →
836
MCQmedium

Your organization uses GitHub for source control and Azure Pipelines for CI/CD. You need to implement a pipeline that automatically builds and tests a Python application on every pull request to the main branch, but only if the pull request is from a fork. The pipeline must also publish test results as a build artifact. What should you do?

A.Use GitHub Actions to build and test the application on PRs, and then trigger Azure Pipelines for deployment.
B.Use a scheduled trigger to run the pipeline every hour and check for new PRs from forks.
C.Set up a pipeline completion trigger on the main branch that runs the pipeline after every merge.
D.Configure a branch protection rule on main that requires status checks from Azure Pipelines. Set the pipeline trigger to 'Pull request validation' and include a condition to run only if the pull request is from a fork.
AnswerD

Branch protection enforces status check, and trigger condition filters fork PRs.

Why this answer

Option A is correct because GitHub branch protection can require status checks from Azure Pipelines, and the pipeline can be triggered on pull request events. Option B is incorrect because pipeline completion trigger is not for PR from forks. Option C is incorrect because manual trigger doesn't automate.

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

Full explanation →
837
MCQhard

Your team uses GitHub Enterprise to manage source code. You need to implement a security and compliance plan that ensures all commits are signed using GPG keys and that secrets are scanned before code is merged. Which GitHub features should you combine?

A.Enable secret scanning alerts and require signed commits via branch protection rules.
B.Enable Dependabot alerts and require pull request reviews before merging.
C.Configure branch protection rules to require code owners review and enable automatic security fixes.
D.Enable push protection for secret scanning and configure branch protection rules with 'Require signed commits' and 'Vigilant mode'.
AnswerD

Push protection blocks secrets at push time. Vigilant mode marks unsigned commits as unverified and branch protection can block unverified commits.

Why this answer

Push protection in secret scanning prevents secrets from being pushed. Commit signature verification with Vigilant mode blocks unsigned commits. Branch protection rules enforce both.

Secret scanning alerts only notify after a push. Dependabot and code owners address dependency and review requirements, not signing or secret prevention.

Full explanation →
838
Multi-Selecthard

Which THREE are benefits of using a monorepo vs multiple repositories?

Select 3 answers
A.Easier code sharing and refactoring across projects
B.Reduced risk of configuration drift
C.Simplified dependency management across projects
D.Faster clone times due to smaller repository size
E.Atomic commits that span multiple components
AnswersA, C, E

Shared code is in the same repo, simplifying updates.

Why this answer

Option A is correct because a monorepo enables easier code sharing and refactoring across projects by allowing all code to reside in a single repository. This eliminates the need for cross-repository package publishing or versioning, as shared libraries can be directly referenced and refactored atomically across all dependent projects within the same commit.

Exam trap

The trap here is that candidates often confuse 'reduced configuration drift' (Option B) with the benefits of centralized configuration management, but in a monorepo, configuration drift can still occur if teams modify shared files inconsistently, and the exam expects you to recognize that this is not an inherent benefit.

Full explanation →
839
MCQeasy

You need to ensure that only signed-in users can view Azure DevOps project wikis. Which setting should you configure?

A.Configure wiki permissions to deny anonymous users
B.Set project visibility to 'Private'
C.Set repository visibility to 'Private'
D.Use Microsoft Entra ID Application Proxy
AnswerB

Private projects require authentication to view.

Why this answer

Option A is correct because project visibility controls who can view the project. Option B is wrong because repository security is for code, not wikis. Option C is wrong because Microsoft Entra ID Application Proxy is for on-prem apps.

Option D is wrong because wiki permissions are per-wiki, not a global setting.

Full explanation →
840
MCQeasy

Your team uses Azure Pipelines to build a Node.js application. The build pipeline runs linting, unit tests, and creates a production build. You want to ensure that the pipeline fails if the test coverage drops below 80%. You need to implement this check. What should you do?

A.Configure a pipeline variable 'CoverageThreshold' and use it in a gate.
B.Set a branch policy that requires code coverage to be at least 80%.
C.Use the 'Visual Studio Test' task with code coverage enabled and set the 'Minimum coverage' option.
D.Add a 'Publish Test Results' task with code coverage enabled, then use a 'Script' task that reads the coverage report and fails if below 80%.
AnswerD

This allows custom logic to enforce the coverage threshold.

Why this answer

Option A is correct: The 'Publish Test Results' task can publish coverage results, and you can use a 'Check for coverage' task or script to fail the pipeline. Option B is incorrect because the task itself does not enforce a minimum coverage. Option C is incorrect because pipeline variables cannot enforce coverage thresholds.

Option D is incorrect because code coverage is not a branch policy.

Full explanation →
841
Multi-Selectmedium

Which THREE of the following are true about GitHub Actions self-hosted runners?

Select 3 answers
A.They can have custom software installed.
B.They are automatically scaled by GitHub.
C.They are free and do not incur any costs.
D.They can run on Windows, Linux, or macOS.
E.They can access on-premises resources.
AnswersA, D, E

Self-hosted runners allow custom software.

Why this answer

Option A is correct because GitHub Actions self-hosted runners are machines you manage, allowing you to install any custom software, libraries, or tools required by your workflows. Unlike GitHub-hosted runners, which have a fixed set of pre-installed software, self-hosted runners give you full administrative control over the environment, enabling you to meet specific build or test dependencies.

Exam trap

The trap here is that candidates often assume self-hosted runners are entirely free and automatically managed by GitHub, overlooking the operational overhead and infrastructure costs, while also forgetting that GitHub does not handle scaling for self-hosted runners.

Full explanation →
842
Multi-Selecthard

Which THREE are valid deployment strategies supported by Azure Pipelines and GitHub Actions? (Choose three.)

Select 3 answers
A.Blue-green
B.Canary
C.Rolling
D.Immutable
E.Recreate
AnswersA, B, C

Blue-green is supported in both platforms.

Why this answer

Options A, C, and D are correct. Canary, blue-green, and rolling are all supported deployment strategies. Option B is wrong because 'immutable' is not a built-in strategy in Azure Pipelines or GitHub Actions; it is a concept in some platforms but not as a predefined strategy.

Option E is wrong because 'recreate' is not a standard strategy name; the standard is 'recreate' but it is not in the list; however, 'recreate' is actually a valid strategy in some contexts, but the question asks for supported strategies. In Azure Pipelines and GitHub Actions, canary, blue-green, and rolling are explicitly supported. Recreate is also supported, but since we need exactly three, and the options include immutable which is not, we choose A, C, D.

Full explanation →
843
MCQmedium

Your pipeline runs on a Microsoft-hosted agent. You need to securely reference an Azure Key Vault secret in a pipeline variable without exposing the value in logs. Which variable group type should you use and how should you reference the secret?

A.Create a variable group linked to Key Vault, then reference as $(KeyVaultName.SecretName)
B.Use the 'Azure Key Vault' task to download secrets and assign to variables
C.Store the secret as a plain text variable and mark it as 'secret'
D.Reference the secret directly as $(SecretName) from a library variable group
AnswerA

Why this answer

Option A is correct because linking a variable group to Azure Key Vault allows you to securely reference secrets as pipeline variables without exposing their values in logs. The $(KeyVaultName.SecretName) syntax retrieves the secret value at runtime from Key Vault, and the value is automatically masked in any output.

Exam trap

The trap here is that candidates often confuse the 'Azure Key Vault' task with a variable group linked to Key Vault, not realizing that the task requires explicit variable mapping and can still leak secrets if not handled carefully, whereas the linked variable group provides automatic masking and on-demand retrieval.

Why the other options are wrong

B

This is an alternative but not the simplest; variable groups are preferred.

C

This would expose the secret in the pipeline definition and version control.

D

Variable groups from library can store secrets, but they are not automatically linked to Key Vault.

Full explanation →
844
MCQeasy

Your team uses Azure Repos and wants to trigger a pipeline automatically when a pull request is created targeting the main branch. The pipeline should run validations and report the status to the PR. Which trigger type should you configure?

A.Path filter
B.Scheduled trigger
C.PR trigger
D.CI trigger
AnswerC

PR triggers run on pull request events.

Why this answer

Option A is correct because PR triggers are specifically designed to run pipelines on pull request creation and report status back. Option B is wrong because CI triggers run on pushes to branches. Option C is wrong because scheduled triggers run on a schedule.

Option D is wrong because path filters restrict which files trigger, not the event type.

Full explanation →
845
MCQhard

A company uses Microsoft Entra ID for identity. They want to enforce that all code changes in Azure Repos require a linked work item and a successful policy evaluation. Which branch policy should they configure?

A.Set the merge strategy to squash merge.
B.Enable 'Automatically include reviewers'.
C.Require work item linking in the branch policy.
D.Enforce a minimum number of comments.
AnswerC

This policy mandates a work item for each pull request.

Why this answer

Option C is correct because requiring work item linking in the branch policy ensures that every pull request (PR) in Azure Repos must be associated with a work item (e.g., user story, bug) before it can be completed. Combined with a successful policy evaluation (e.g., build validation, required reviewers), this enforces traceability and compliance for all code changes.

Exam trap

The trap here is that candidates may confuse branch policy settings that add metadata (like auto-include reviewers or comment counts) with policies that enforce mandatory linking or validation, leading them to select options that only facilitate review but do not enforce the required traceability.

How to eliminate wrong answers

Option A is wrong because setting the merge strategy to squash merge controls how commits are combined into the target branch (e.g., squashing all commits into one), but it does not enforce any requirement for linked work items or policy evaluation. Option B is wrong because enabling 'Automatically include reviewers' adds specific reviewers to a PR based on file paths or other criteria, but it does not enforce work item linking or policy evaluation. Option D is wrong because enforcing a minimum number of comments only requires a certain number of comments on a PR before it can be completed, which does not ensure work item linking or policy evaluation.

Full explanation →
846
MCQeasy

You are configuring a build pipeline for a JavaScript application. You want to run linting, unit tests, and build steps only when changes are pushed to the 'develop' branch. Which trigger should you configure?

A.Enable pull request trigger.
B.Enable scheduled trigger.
C.Enable continuous integration (CI) trigger without branch filters.
D.Enable CI trigger with a branch filter for 'develop'.
AnswerD

Limits pipeline execution to the 'develop' branch.

Why this answer

Option B is correct because CI triggers can be filtered by branch. Option A is wrong because it runs on all branches. Option C is wrong because PR triggers are for pull requests.

Option D is wrong because scheduled triggers run on a schedule, not on push.

Full explanation →
847
MCQhard

Your organization uses Microsoft Entra ID for identity and Azure DevOps for source control. You need to enforce that all code changes to the main branch require a pull request with at least two approvals and no failing checks. What should you configure?

A.Configure a Conditional Access policy in Microsoft Entra ID
B.Add an environment protection rule in Azure Pipelines
C.Set up a branch policy on the main branch in Azure Repos
D.Use a service hook to notify reviewers when a push occurs
AnswerC

Branch policies in Azure Repos can require a minimum number of reviewers and enforce build validation.

Why this answer

Option B is correct because Azure DevOps branch policies can require a minimum number of reviewers and check for build validation. Option A is wrong because Entra ID Conditional Access policies manage sign-in, not code reviews. Option C is wrong because environment protection rules in GitHub are for deployments, not pull requests.

Option D is wrong because service hooks are for integration, not policy enforcement.

Full explanation →
848
MCQeasy

Your team is migrating from TFVC to Git in Azure Repos. You need to preserve the full history of the TFVC repository, including all branches and changesets. The TFVC repository is large (over 10 GB). Which tool should you use to perform the migration?

A.Manually recreate the commits in a new Git repository.
B.Use git-tfs to clone the TFVC repository and then push to Azure Repos.
C.Use git-svn to convert TFVC to Git.
D.Use the Azure DevOps Migration Tools to export TFVC to Git.
AnswerB

git-tfs preserves history and handles large repos.

Why this answer

B is correct because git-tfs is specifically designed to bridge TFVC and Git, allowing you to clone a TFVC repository (including all branches, changesets, and history) into a local Git repository, which can then be pushed to Azure Repos. It handles large repositories (over 10 GB) by performing an incremental clone, preserving the full history without manual recreation.

Exam trap

The trap here is that candidates confuse git-tfs with git-svn, assuming any 'git-*' tool works for any version control system, but git-svn only works with Subversion, not TFVC.

How to eliminate wrong answers

Option A is wrong because manually recreating commits in a new Git repository would lose the full history, branches, and changesets, which contradicts the requirement to preserve them. Option C is wrong because git-svn is designed for Subversion (SVN) repositories, not TFVC; it cannot interpret TFVC's changeset structure or branching model. Option D is wrong because the Azure DevOps Migration Tools are primarily for migrating work items, test plans, and other Azure DevOps artifacts between organizations, not for converting TFVC repositories to Git with full history.

Full explanation →
849
MCQhard

Your organization uses Azure DevOps with classic pipelines. Security audit requires that all pipeline variables containing secrets (e.g., API keys) are stored in Azure Key Vault and referenced dynamically. Currently, secrets are stored as plain text in the pipeline UI. You need to migrate to Key Vault with minimal downtime and ensure that secret values are never exposed in logs. What should you do?

A.Store secrets in a secure file in Azure DevOps.
B.Create a variable group linked to Key Vault, mark variables as 'secret', and reference them in pipelines. Update pipeline steps to use the variable group.
C.Use the 'Azure Key Vault' task to download secrets as pipeline variables.
D.Add each secret as a pipeline variable with the 'secret' type.
AnswerB

Key Vault integration masks secrets and keeps them out of logs.

Why this answer

Option A is correct because linking Key Vault via library variable groups keeps secrets out of logs when 'Keep secret' is enabled. The 'secret' variable type in pipelines masks values. Option B is wrong because secret variables are still stored in Azure DevOps, not Key Vault.

Option C is wrong because it doesn't address log exposure. Option D is wrong because it doesn't prevent exposure in logs.

Full explanation →
850
Multi-Selecthard

Which THREE factors should you consider when designing a release pipeline for a critical production application? (Choose three.)

Select 3 answers
A.Use of service principal with least privilege
B.Rollback strategy
C.Single environment deployment
D.Deployment health monitoring
E.Approval gates before production deployment
AnswersB, D, E

Allows reverting to a known good state.

Why this answer

Options A, B, and D are correct. A: Approval gates ensure controlled deployments. B: Rollback strategy is essential for failures.

D: Monitoring deployment health is crucial. Option C is wrong because least privilege is a security principle, not specific to release pipeline design. Option E is wrong because single environment is not a factor; you typically have multiple environments.

Full explanation →
851
Multi-Selectmedium

You are designing a release pipeline that uses Azure App Service deployment slots. The pipeline must perform a swap after deployment to the staging slot. Which three tasks or actions should you include in the pipeline? (Select all that apply.)

Select 3 answers
A.Azure App Service deploy: Deploy to staging slot
B.Azure App Service manage: Swap slots
C.Azure App Service manage: Start staging slot
D.Azure App Service manage: Delete staging slot
E.Azure CLI: Run az webapp deployment slot swap
AnswersA, B, C

Why this answer

Option A is correct because the Azure App Service deploy task with the 'Deploy to staging slot' action is the standard method to deploy an application to a staging slot before a swap. This ensures the new release is validated in an isolated environment without affecting the production slot.

Exam trap

The trap here is that candidates may confuse the Azure CLI command (Option E) as a valid pipeline task, but Azure DevOps provides dedicated tasks (Azure App Service manage) that are simpler and more reliable for slot operations within a release pipeline.

Why the other options are wrong

D

Deleting the staging slot is not part of the swap process.

E

While this works, it's not a built-in task; the question expects Azure App Service tasks.

Full explanation →
852
MCQmedium

Your team is implementing a CI/CD pipeline for a .NET application. The build pipeline should only run when changes are pushed to the main branch, but a recent push to a feature branch triggered the pipeline. What is the most likely cause?

A.The trigger includes 'main' and also has no branch filters, so all branches trigger builds.
B.The pull request trigger is enabled for the feature branch.
C.Path filters are configured to include all paths.
D.The CI trigger is disabled in the pipeline YAML.
AnswerA

Without branch filters, the CI trigger applies to all branches.

Why this answer

Option C is correct because the trigger should be set to include 'main' branch only. Option A is wrong because disabling CI trigger would stop all automatic builds. Option B is wrong because path filters affect file paths, not branches.

Option D is wrong because PR triggers are separate.

Full explanation →
853
MCQmedium

Your team uses Azure Pipelines to deploy a Docker container to Azure Kubernetes Service (AKS). The pipeline builds a Docker image, pushes it to Azure Container Registry (ACR), and then runs a deployment to AKS. You want to ensure that the deployment uses the exact image that was built in the same pipeline run. Which approach should you use?

A.Use two separate pipelines: one for build/push, one for deploy, and share the image tag via a variable group.
B.Use a single task for build and push, and rely on ACR's internal pull-through cache.
C.Generate a unique tag (e.g., Build.BuildId) and pass it to both the Docker build and Kubernetes manifest via variable substitution.
D.Tag the image as 'latest' and reference it in the Kubernetes manifest.
AnswerC

Unique tag ensures exact image is used.

Why this answer

Option C is correct because using a manifest file with build-specific variables ensures the correct image tag is used. Option A is wrong because 'latest' tag can be overwritten. Option B is wrong because the ACR task can be reused.

Option D is wrong because separate pipelines may have different image builds.

Full explanation →
854
MCQeasy

You are setting up a release pipeline for a web application. The pipeline must deploy to three environments: Dev, Test, and Prod. The deployment to Prod must be triggered only after a successful deployment to Test and after a manual approval. How should you configure the pipeline?

A.Add a manual intervention task before the Prod deployment in the pipeline.
B.Use a condition on the Prod stage to require success from Test and manual intervention variable.
C.Schedule the Prod deployment to run after Test, and require manual trigger.
D.Add a pre-deployment approval gate on the Prod environment.
AnswerD

Pre-deployment approval requires manual approval before Prod.

Why this answer

Option A is correct because pre-deployment approvals on the Prod stage ensure manual approval before deployment. Option B is wrong because a separate manual task would not block the pipeline. Option C is wrong because conditions alone don't enforce manual approval.

Option D is wrong because schedule ignores approval.

Full explanation →
855
MCQhard

Your organization is migrating from Azure Repos to GitHub. You have 200 repositories with complex branching strategies and build policies. You need to preserve the commit history and branch policies. What is the best migration approach?

A.Manually recreate each repository in GitHub and copy the code from Azure Repos
B.Use a third-party tool to perform a mirror clone and then push to GitHub
C.Use the GitHub Importer tool with a custom mapping script to migrate repositories and policies
D.Use git push --force to push all branches to GitHub and recreate policies manually
AnswerC

GitHub Importer preserves history and can map branch policies.

Why this answer

The GitHub Importer tool, combined with a custom mapping script, is the correct approach because it can migrate repositories along with their commit history and branch policies from Azure Repos to GitHub. This tool handles the complex branching strategies and build policies by allowing you to define mappings for users, branches, and policies, ensuring a seamless transition without manual recreation or data loss.

Exam trap

The trap here is that candidates often assume a simple git push --force (Option D) is sufficient for migration, overlooking that branch policies are not stored in the Git repository itself but in the platform's metadata, requiring a tool like GitHub Importer to transfer them.

How to eliminate wrong answers

Option A is wrong because manually recreating repositories and copying code loses commit history and branch policies, which is inefficient and error-prone for 200 repositories. Option B is wrong because a third-party mirror clone only copies the repository data (commits, branches) but does not migrate branch policies or build policies, which are critical for compliance and CI/CD. Option D is wrong because git push --force pushes all branches but does not preserve branch policies, and recreating them manually for 200 repositories is impractical and risks misconfiguration.

Full explanation →
856
MCQhard

Your organization uses Microsoft Entra ID and Azure DevOps. You need to ensure that only users from specific Entra ID groups can create new Azure DevOps organizations. What should you configure?

A.Assign the Global Administrator role to the security group
B.Assign the Azure DevOps Administrator role to the security group
C.Configure Conditional Access policies to block non-group members
D.Use Azure DevOps security policies to restrict organization creation
AnswerB

This role controls who can create and manage Azure DevOps organizations.

Why this answer

Option B is correct because the Azure DevOps Administrator role in Entra ID can restrict who can create new organizations. Option A is wrong because the Global Administrator role is too broad. Option C is wrong because Azure DevOps does not have a 'Create organizations' permission.

Option D is wrong because Conditional Access policies control access to resources, not creation of organizations.

Full explanation →
857
MCQhard

Your Azure DevOps pipeline deploys to multiple environments (Dev, Test, Prod) using YAML multi-stage pipelines. The Prod deployment requires manual approval. However, the approval gate shows 'Pending' even after an authorized user approves. What is the most likely cause?

A.The pipeline run was triggered by a PR merge, and the approval needs to be re-applied after the build completes.
B.The build pipeline includes a step that modifies the approval settings.
C.The approval gate is configured to require approval on the latest commit, but a newer commit was pushed after the approval.
D.The approver is not a member of the security group defined in the approval settings.
AnswerC

Azure Pipelines requires re-approval if the commit changes.

Why this answer

Option D is correct because branch policy requires the approval to be on the specific commit that triggered the release. Option A is wrong because re-running does not change the commit. Option B is wrong because the policy is not about the build but the commit.

Option C is wrong because the user is authorized.

Full explanation →
858
Multi-Selecteasy

Your organization uses Microsoft Defender for Cloud and Azure DevOps. Security teams need to automatically detect and block secrets (e.g., passwords, keys) pushed to Azure Repos. Which TWO actions should you take?

Select 2 answers
A.Enable push protection for secrets in Microsoft Defender for Cloud.
B.Set branch policies to require a pull request for all changes.
C.Store all secrets in Azure Key Vault and reference them in pipelines.
D.Enable secret scanning in GitHub Advanced Security for Azure Repos.
E.Configure Microsoft Purview Information Protection to scan repositories.
AnswersA, D

Push protection blocks secrets during push.

Why this answer

Option A (Enable push protection for secrets via Microsoft Defender for Cloud) provides real-time blocking. Option D (Configure repository-level secret scanning in GitHub Advanced Security for Azure Repos) is the feature that actually scans and blocks secrets. Option B is wrong because Microsoft Purview focuses on data classification, not real-time secret scanning.

Option C is wrong because branch policies control PRs, not pushes. Option E is wrong because key vault secrets are for storage, not scanning.

Full explanation →
859
MCQhard

You are designing a release pipeline for a critical application that requires zero-downtime deployments. The application runs on Azure Kubernetes Service (AKS) with multiple replicas. You are using Azure Pipelines with a canary deployment strategy. What is the best approach to gradually shift traffic to the new version while monitoring for errors?

A.Use a service mesh like Istio to route a percentage of traffic to the new version.
B.Use Azure Application Gateway as an ingress controller with weighted backend pools.
C.Use the AKS rolling update strategy with max surge.
D.Deploy to a staging environment, then swap VIPs with production.
AnswerA

Istio enables precise traffic routing for canary deployments.

Why this answer

Option B is correct because AKS native features for canary deployments using Istio or similar service mesh provide fine-grained traffic shifting. Option A is incorrect because blue-green with full swap does not allow gradual traffic shift. Option C is incorrect because rolling update in AKS is not canary; it replaces pods gradually but does not split traffic.

Option D is incorrect because using Application Gateway does not provide gradual traffic shift at the pod level.

Full explanation →
860
Multi-Selecteasy

Which TWO features of GitHub Actions can be used to enforce code quality standards before merging?

Select 2 answers
A.Environments
B.Secrets
C.Branch protection rules with required status checks
D.Status checks
E.Repository variables
AnswersC, D

This enforces that quality checks must pass.

Why this answer

Branch protection rules with required status checks (C) enforce that pull requests must pass specific GitHub Actions workflows (e.g., linting, testing, security scans) before merging. Status checks (D) are the actual workflow runs that report pass/fail to the pull request; when required, they block merging until all checks succeed. Together, they ensure code quality gates are met automatically.

Exam trap

The trap here is that candidates confuse 'Environments' (deployment gates) with 'branch protection rules' (merge gates), or assume 'Secrets' or 'Variables' can enforce quality, when they are purely for storing configuration data.

Full explanation →
861
MCQhard

Your organization uses Azure DevOps to manage a large-scale microservices application deployed to Azure Kubernetes Service (AKS). The application consists of 20 microservices, each with its own code repository and CI/CD pipeline. Recently, the team has been experiencing frequent build failures due to dependency conflicts between microservices when multiple pipelines run simultaneously and try to use the same build agent. The team is using Microsoft-hosted agents with a single agent pool. The builds take an average of 30 minutes each, and there are often 10+ builds queued at the same time. The team wants to reduce build failures and improve build throughput without significant increase in cost. What should they do?

A.Reduce the number of agents to 5 to avoid conflicts
B.Move all microservices into a single repository and use a single pipeline
C.Provision self-hosted agents on Azure VMs with dedicated agent pools for each microservice
D.Increase the number of parallel jobs in the agent pool to 20
AnswerC

Self-hosted agents can be isolated per microservice, avoiding dependency conflicts, and can be sized appropriately.

Why this answer

Option C is correct because provisioning self-hosted agents on Azure VMs with dedicated agent pools for each microservice eliminates dependency conflicts by isolating build environments. This approach also improves throughput by allowing parallel builds without contention, and using Azure VMs (e.g., spot instances or reserved instances) can be cost-effective compared to scaling Microsoft-hosted parallel jobs, which incur per-minute charges.

Exam trap

The trap here is that candidates often assume increasing parallel jobs (Option D) is the cheapest and simplest fix, but they overlook the per-minute billing for Microsoft-hosted agents and the fact that dependency conflicts persist because agents are not isolated.

How to eliminate wrong answers

Option A is wrong because reducing the number of agents to 5 would worsen queue times and increase build failures due to even higher contention, directly contradicting the goal of improving throughput. Option B is wrong because moving all microservices into a single repository and using a single pipeline would create a monolithic build process, increasing build times, reducing parallelism, and violating microservices best practices for independent deployment and scaling. Option D is wrong because increasing parallel jobs in the agent pool to 20 with Microsoft-hosted agents would significantly increase costs (each parallel job incurs additional charges) and does not address the root cause of dependency conflicts, as agents still share the same environment and can interfere with each other.

Full explanation →
862
Multi-Selecteasy

Your team is adopting GitHub Copilot for code generation. The compliance team requires that all code generated by AI is reviewed and that proprietary code is not used as training data. Which TWO settings should you configure in your GitHub organization?

Select 2 answers
A.Configure a branch protection rule that requires all code to be reviewed before merging.
B.Disable Copilot for all repositories in the organization.
C.Disable the 'Allow GitHub to use my data for training' option in the organization's Copilot settings.
D.Enable 'Suggestions matching public code' to block suggestions that match public code.
E.Enable 'Allow GitHub to use my code snippets for product improvements' to improve Copilot.
AnswersA, C

Branch protection ensures that AI-generated code is reviewed by a human before merging.

Why this answer

GitHub Copilot for Business allows admins to disable training on user code and enforce policies. Disallowing public code suggestions from being used as training data protects proprietary code. Requiring Copilot to only suggest from approved libraries is not a feature.

Disabling Copilot entirely is not the goal. Enabling suggestions matching public code is the opposite of what is needed.

Full explanation →
863
MCQeasy

Your Azure DevOps repository contains a large binary file that is slowing down clone operations. Which Git feature should you use to reduce the clone time?

A.Shallow clone
B.Git LFS (Large File Storage)
C.Depth parameter in clone command
D.Sparse checkout
AnswerB

Replaces large files with pointers.

Why this answer

Git LFS (Large File Storage) is the correct solution because it replaces large binary files in the repository with lightweight text pointers, storing the actual binary content in external remote storage. This prevents the large file from being downloaded during every clone, significantly reducing clone time and repository size on disk.

Exam trap

The trap here is that candidates confuse shallow clones or sparse checkouts as solutions for large files, when in fact those features address history depth or working tree scope, not the fundamental problem of large binary objects being stored and transferred in the repository.

How to eliminate wrong answers

Option A is wrong because a shallow clone (using --depth 1) limits the commit history but still downloads the current version of all files, including the large binary, so it does not address the root cause of the large file slowing clones. Option C is wrong because the depth parameter is simply the mechanism to perform a shallow clone; it has the same limitation as option A and does not exclude the large binary from being downloaded. Option D is wrong because sparse checkout limits which directories or files are populated in the working tree, but the entire repository object data (including the large binary) is still downloaded during clone; it only affects checkout, not the transfer size.

Full explanation →
864
MCQeasy

Your team uses GitFlow and wants to enforce that all feature branches are deleted after merging to develop. Which automation should you implement?

A.Enable the 'Automatically delete source branches' policy in the branch policy.
B.Use a post-merge script in the pipeline.
C.Train developers to delete branches manually.
D.Configure branch retention policies in Azure Repos.
AnswerA

This setting deletes the branch after PR merge.

Why this answer

Option A is correct because branch policies can auto-delete after merge. Option B is wrong because cleanup scripts are manual. Option C is wrong because retention policies are for pipelines, not branches.

Option D is wrong because manual deletion is not automated.

Full explanation →
865
MCQmedium

A company has a policy that all code changes must be reviewed by at least two people. However, for urgent bug fixes, they want to allow a single reviewer. How should they configure the branch policy?

A.Set minimum number of reviewers to 1 and require a separate approval from a manager
B.Set minimum number of reviewers to 2 and allow resetting code review votes on new pushes
C.Configure a build validation policy that checks number of approvals
D.Set minimum number of reviewers to 2, but allow policy override for urgent fixes
AnswerD

Policy override can be used with a justification to bypass the two-reviewer requirement.

Why this answer

Option D is correct because Azure Repos branch policies allow you to set a minimum number of reviewers (e.g., 2) and then enable the 'Allow policy override' setting for urgent fixes. This lets authorized users bypass the two-reviewer requirement for critical bug fixes while maintaining the default policy for normal changes.

Exam trap

The trap here is that candidates often confuse 'policy override' with 'bypassing all policies' or think a build validation can count approvals, when in fact Azure Repos requires explicit permission-based override settings for urgent scenarios.

How to eliminate wrong answers

Option A is wrong because setting the minimum number of reviewers to 1 does not enforce the two-reviewer policy, and requiring a separate manager approval does not address the urgent fix scenario—it adds an extra approval step instead of allowing a single reviewer. Option B is wrong because setting minimum reviewers to 2 and allowing resetting votes on new pushes does not provide a mechanism to bypass the two-reviewer requirement for urgent fixes; it only resets approvals when new commits are pushed. Option C is wrong because a build validation policy checks build success, not the number of approvals; it cannot enforce or override reviewer count requirements.

Full explanation →
866
MCQmedium

Your build pipeline uses a self-hosted agent. The agent is running low on disk space. You need to clean up the agent's working directory after each build. Which option should you configure in the pipeline?

A.Set the 'Clean' option to 'Sources' in the pipeline settings.
B.Add a 'Delete Files' task at the end of the pipeline to delete the sources directory.
C.Add a 'Cleanup' task from the marketplace to clean the agent.
D.Use the 'clean' parameter in the checkout step of the YAML pipeline.
AnswerD

Correct: 'clean: true' cleans the working directory before checkout.

Why this answer

Option C is correct because setting 'clean: true' in the checkout step ensures the working directory is cleaned before each build. Option A is wrong because the 'workspace' cleanup option in agent configuration is not a pipeline setting. Option B is wrong because 'Delete Files' task is manual and not automatic.

Option D is wrong because 'Cleanup' task is not a built-in task.

Full explanation →
867
MCQhard

Your release pipeline uses Azure Kubernetes Service (AKS) and Helm charts. You need to roll back to a previous release quickly if the new release fails health checks. What is the BEST approach?

A.Manually redeploy the previous Helm chart version.
B.Use a canary deployment strategy.
C.Use Helm rollback command.
D.Use a Kubernetes Deployment rollout undo.
AnswerC

Helm natively supports rolling back to a previous release.

Why this answer

Option C is correct because Helm provides built-in rollback functionality. Option A is wrong because manual redeployment is slow. Option B is wrong because it requires additional tooling and scripting.

Option D is wrong because it is not native to Helm and requires custom logic.

Full explanation →
868
MCQhard

Your Azure DevOps pipeline uses a self-hosted agent pool. You notice that builds are queuing for a long time. What is the most effective way to reduce queue times without incurring additional costs?

A.Allocate more parallel jobs to the agent pool.
B.Reduce the number of steps in the pipeline.
C.Increase the agent specification (e.g., from DS2 to DS4).
D.Switch to Microsoft-hosted agents to get more parallelism.
AnswerA

Parallel jobs allow concurrent builds.

Why this answer

Option C is correct because parallel jobs allow multiple builds to run concurrently, reducing queue time. Option A is wrong because changing the agent specification does not increase concurrency. Option B is wrong because Microsoft-hosted agents incur additional cost.

Option D is wrong because reducing pipeline steps may not be feasible and doesn't address concurrency.

Full explanation →
869
MCQeasy

Your development team uses GitHub for source control. You want to automatically run a set of tests every time a pull request is opened against the main branch. What should you configure?

A.Create a GitHub Actions workflow triggered by pull_request events to main
B.Use the GitHub API to trigger tests when a PR is opened
C.Set up a webhook to trigger an external CI system
D.Configure a branch protection rule to require status checks
AnswerA

GitHub Actions can run tests automatically on pull requests.

Why this answer

Option A is correct because GitHub Actions natively supports the `pull_request` event trigger, which can be configured to run workflows automatically when a pull request is opened against a specific branch (e.g., `main`). This allows you to define a YAML-based workflow in the `.github/workflows` directory that executes tests on every PR event, providing immediate feedback to developers without requiring external services or manual API calls.

Exam trap

The trap here is that candidates often confuse branch protection rules (which enforce status checks) with the actual mechanism that triggers the tests, leading them to select Option D, but protection rules only block merges without initiating any automated testing.

How to eliminate wrong answers

Option B is wrong because using the GitHub API to trigger tests when a PR is opened would require custom polling or event handling logic, which is inefficient and not a built-in automation mechanism; GitHub Actions already provides a declarative event-driven trigger. Option C is wrong because setting up a webhook to trigger an external CI system is an alternative approach, but the question asks what you should configure, and GitHub Actions is the native, recommended solution for GitHub-hosted repositories, making this option less direct and more complex. Option D is wrong because configuring a branch protection rule to require status checks only enforces that checks must pass before merging, but it does not automatically trigger the tests; it is a policy enforcement mechanism, not a trigger mechanism.

Full explanation →
870
MCQhard

Your release pipeline deploys to multiple environments (Dev, QA, Prod) using approvals. You need to ensure that the deployment to Prod only proceeds if the deployment to QA succeeded and an approval is granted. Which combination of triggers and pre-deployment conditions should you configure?

A.Set the trigger on Prod to 'Automatic' and add a post-deployment approval on QA.
B.Set the trigger on Prod to 'After release' and add a pre-deployment approval on Prod.
C.Set the trigger on Prod to 'Manual only' and add a pre-deployment approval on Prod.
D.Set the trigger on Prod to 'After stage' and select QA as the stage, and add a pre-deployment approval on Prod.
AnswerD

This ensures QA succeeded before Prod deployment, and approval is needed.

Why this answer

Option C is correct because setting the trigger to 'After stage' on the QA stage and adding a pre-deployment approval on Prod ensures both conditions. Option A is wrong because automatic trigger does not enforce QA success. Option B is wrong because 'After release' ignores QA.

Option D is wrong because manual only trigger ignores QA.

Full explanation →
871
MCQeasy

You are configuring a release pipeline in Azure DevOps to deploy to multiple environments (dev, test, prod). You need to ensure that the production deployment requires manual approval from the release manager. What should you configure?

A.Set pre-deployment approvals on the production stage.
B.Add a manual intervention task before the production deployment.
C.Set post-deployment approvals on the test stage.
D.Use a condition on the production stage to check a variable.
AnswerA

Pre-deployment approvals require approval before the stage runs.

Why this answer

Pre-deployment approvals on the production stage gate the deployment until the specified approvers grant approval.

Full explanation →
872
MCQeasy

You are setting up a GitHub Actions workflow to deploy an Azure Resource Manager (ARM) template. The workflow must run whenever a pull request is opened against the main branch. Which trigger should you use?

A.pull_request: branches: [main] types: [opened]
B.pull_request_target: branches: [main]
C.workflow_dispatch
D.push: branches: [main]
AnswerA

This triggers when a PR is opened against main.

Why this answer

Option D is correct because pull_request trigger with types: [opened] runs the workflow when a PR is opened. Option A is incorrect because push trigger runs on commits, not PRs. Option B is incorrect because pull_request_target runs in the context of the base branch and is used for PRs from forks.

Option C is incorrect because workflow_dispatch requires manual trigger.

Full explanation →
873
MCQeasy

Your organization wants to enforce that all commits to the main branch are signed using GPG or S/MIME. Which GitHub feature should you enable?

A.Use the GitHub API to check commit signatures after push.
B.Configure a branch protection rule that requires signed commits.
C.Enable the 'Include administrators' setting in branch protection.
D.Require SSH key authentication for all users.
AnswerB

This rule rejects unsigned commits.

Why this answer

Option B is correct because GitHub branch protection rules include a 'Require signed commits' setting that enforces all commits pushed to the protected branch must be signed with a verified GPG or S/MIME key. This ensures commit integrity and non-repudiation directly at the repository level, without requiring external scripts or API calls.

Exam trap

The trap here is that candidates confuse authentication (SSH keys) with commit signing (GPG/S/MIME), or assume that post-push API checks are equivalent to pre-merge enforcement.

How to eliminate wrong answers

Option A is wrong because using the GitHub API to check commit signatures after push is a reactive, custom workaround that does not prevent unsigned commits from being merged; it only audits them after the fact. Option C is wrong because the 'Include administrators' setting merely extends existing branch protection rules to admin users, but does not itself enforce signed commits. Option D is wrong because SSH key authentication only verifies the transport layer identity of the user, not the commit signature; commits can still be pushed without any signing.

Full explanation →
874
MCQhard

Refer to the exhibit. You receive a secret scanning alert for an Azure DevOps PAT in a GitHub repository. The push_protection_bypass is false. What does this mean and what action should you take?

A.The secret was pushed but push protection was bypassed; you need to revoke the PAT and use git filter-branch to remove it from history.
B.The secret was pushed successfully; you need to rotate the PAT and audit the commit history.
C.The secret was pushed and push protection was not bypassed; you need to open a support ticket with GitHub to remove the secret.
D.The secret was blocked from being pushed; you should revoke the PAT and investigate the incident.
AnswerD

Push protection blocked the push, so the secret never entered the repository. Revoke the PAT and investigate.

Why this answer

Push protection blocked the push, so the secret was not committed to the repository. You should revoke the PAT and investigate how it was used. The secret is not in the commit history because it was blocked.

Since it was not committed, you don't need to use git filter-branch or GitHub support to remove it.

Full explanation →
875
MCQeasy

Your team uses Azure Pipelines to build and test code. You want to automatically trigger a pipeline when a pull request is created targeting the main branch. Which trigger should you configure?

A.PR trigger
B.Scheduled trigger
C.CI trigger
D.Manual trigger
AnswerA

PR trigger runs when a pull request is created or updated.

Why this answer

A PR trigger is the correct choice because Azure Pipelines supports a 'pr' trigger that automatically starts a pipeline when a pull request is created targeting a specified branch (e.g., main). This is distinct from a CI trigger, which runs on commits to a branch, and is essential for validating changes before merging.

Exam trap

The trap here is that candidates often confuse CI triggers with PR triggers, assuming a CI trigger on the target branch will run for PRs, but CI triggers only fire on direct pushes, not on PR creation events.

How to eliminate wrong answers

Option B is wrong because a scheduled trigger runs pipelines on a time-based schedule (e.g., nightly), not in response to pull request creation. Option C is wrong because a CI trigger runs when code is pushed to a branch, not when a pull request is created; it does not differentiate between direct commits and PRs. Option D is wrong because a manual trigger requires a user to explicitly start the pipeline via the Azure DevOps UI or API, providing no automation for PR events.

Full explanation →
876
MCQeasy

A developer reports that their Azure DevOps pipeline is failing with 'Access denied' when trying to push to a protected branch. The branch policy requires a successful build and approval from the 'Code Owners' group. The developer is a member of 'Contributors' but not 'Code Owners'. What is the most likely cause?

A.The branch name contains invalid characters.
B.The pipeline's service principal lacks 'Create Branch' permission.
C.The developer lacks 'Contribute' permissions at the project level.
D.The developer is not in the 'Code Owners' group allowed to bypass the policy.
AnswerD

Branch policy restricts pushes to specific groups.

Why this answer

Option D is correct because the branch policy enforces that only members of the 'Code Owners' group can push directly to the branch; the developer lacks that membership. Option A (Insufficient permissions at project level) is less specific. Option B (Pipeline service principal missing) is unrelated.

Option C (Incorrect branch name) would give a different error.

Full explanation →
877
Multi-Selectmedium

Which THREE steps are essential when customizing an Azure DevOps process?

Select 3 answers
A.Use Hosted XML process model to customize.
B.Add custom fields to work item types.
C.Directly modify the 'Agile' system process.
D.Create an inherited process from an existing system process.
E.Add custom work item types to the process.
AnswersB, D, E

Custom fields allow tracking additional data.

Why this answer

Option B is correct because customizing work item types by adding custom fields is a fundamental step in tailoring Azure DevOps processes to capture project-specific data. This is done through the inherited process model, which allows you to extend system processes without modifying the base definitions, ensuring upgrades and maintenance remain supported.

Exam trap

The trap here is that candidates often confuse the deprecated Hosted XML model with the current Inheritance model, or mistakenly think they can edit system processes directly, leading them to select options A or C instead of recognizing that only inherited processes support customization.

Full explanation →
878
MCQeasy

Your team needs to automatically run a pipeline whenever a pull request is created in GitHub. Which trigger should you configure in Azure Pipelines?

A.Pipeline completion trigger
B.Scheduled trigger
C.Pull request trigger
D.Continuous integration trigger
AnswerC

PR trigger runs on pull request creation.

Why this answer

PR trigger automatically runs pipeline on pull request creation. Option A is wrong because continuous integration trigger runs on branch pushes. Option C is wrong because scheduled trigger runs at specific times.

Option D is wrong because pipeline completion trigger runs after another pipeline finishes.

Full explanation →
879
Multi-Selecteasy

Which TWO are valid reasons to use a monorepo?

Select 2 answers
A.Smaller clone size compared to multiple repositories.
B.Simplifies code sharing and reuse across multiple projects.
C.Allows independent CI/CD pipelines for each project.
D.Improves security by isolating each project.
E.Simplifies dependency management and versioning.
AnswersB, E

All code resides in one repository, making sharing easy.

Why this answer

Option B is correct because a monorepo centralizes all code in a single repository, making it straightforward to share common libraries, utilities, and components across multiple projects without needing separate package feeds or submodule references. Option E is correct because with all projects in one repo, dependency versions are unified and managed in a single set of manifest files (e.g., package.json, requirements.txt), eliminating cross-repo version drift and simplifying coordinated updates.

Exam trap

The trap here is that candidates confuse the theoretical benefits of isolation (C and D) with the practical reality of monorepos, which trade isolation for simplified sharing and unified versioning, while clone size (A) is actually larger, not smaller.

Full explanation →
880
MCQmedium

You are designing a release pipeline that deploys to multiple environments (dev, test, prod) with approval gates between each. You need to ensure that the same build artifact is deployed to all environments. Which strategy should you use?

A.Use a multi-stage YAML pipeline with a separate artifact for each stage.
B.Create a separate build pipeline for each environment to ensure environment-specific configurations.
C.Use a single build pipeline but trigger a new build for each environment.
D.Use a single build pipeline and promote the same build artifact through each environment.
AnswerD

Promoting the same artifact ensures consistency across environments.

Why this answer

Option C is correct because releasing the same artifact version across stages ensures consistency; promoting the build from dev to test to prod without rebuilding. Option A is wrong because rebuilding for each environment may produce different artifacts. Option B is wrong because separate pipelines for each environment do not guarantee the same artifact.

Option D is wrong because the release pipeline should use a single artifact source.

Full explanation →
881
MCQmedium

Your team uses Azure Boards and wants to automate work item state transitions when code is merged. What should you use?

A.Azure Pipelines with 'Update work item' task
B.Branch policy in Azure Repos
C.GitHub + Azure Boards integration with automatic work item linking
D.Power Automate with Azure DevOps connector
AnswerC

This integration automatically links and can transition work items on merge.

Why this answer

Option C is correct because GitHub + Azure Boards integration, when configured with automatic work item linking, automatically transitions work items (e.g., from 'Active' to 'Resolved') when a pull request is merged. This is achieved through the integration's ability to detect commit messages or PR descriptions containing 'AB#{ID}' or 'Fixes #{ID}' patterns, which trigger state changes defined in the Azure Boards project configuration.

Exam trap

The trap here is that candidates often confuse the 'Update work item' task in Azure Pipelines (Option A) as a direct merge-triggered automation, but it requires a pipeline run, whereas the GitHub integration provides a simpler, event-driven solution without additional pipeline overhead.

How to eliminate wrong answers

Option A is wrong because the 'Update work item' task in Azure Pipelines runs during a build or release pipeline, not directly when code is merged; it requires a pipeline trigger on merge, which adds unnecessary complexity and delay. Option B is wrong because branch policies in Azure Repos enforce code review and build validation, but they do not have built-in functionality to update work item states; they only require a linked work item, not state transitions. Option D is wrong because Power Automate with Azure DevOps connector can automate work item updates, but it is an external orchestration tool that requires custom flow design and polling or triggers, not a native, seamless integration like GitHub + Azure Boards.

Full explanation →
882
MCQmedium

Your team uses GitHub Actions for CI/CD. You want to reuse a workflow across multiple repositories without duplicating code. Which approach should you use?

A.Store the workflow in a shared repository and use environment secrets to share credentials.
B.Create a reusable workflow in a central repository and reference it using 'uses: owner/repo/.github/workflows/workflow.yml@ref'.
C.Create a composite action and reference it from each workflow.
D.Create a workflow template in the organization's .github repository.
AnswerB

Reusable workflows allow calling another workflow from a different repository.

Why this answer

Option D is correct because GitHub Actions supports reusable workflows by using the 'uses' keyword with a path to a workflow file in another repository. Option A is wrong because composite actions are for grouping steps, not entire workflows. Option B is wrong because workflow templates are for creating new workflows from a template, not for reuse.

Option C is wrong because environment secrets are for storing secrets, not for reusing workflow logic.

Full explanation →
883
Multi-Selecteasy

Which TWO of the following are benefits of using deployment slots in Azure App Service? (Select TWO.)

Select 2 answers
A.Automatic rollback on failure.
B.Independent scaling of each slot.
C.Zero-downtime deployments.
D.Validate changes in a staging environment before production.
E.Geographic redundancy.
AnswersC, D

Swap slots to switch traffic instantly.

Why this answer

Options A and D are correct. Zero-downtime deployments (A) are achieved by swapping slots; staging validation (D) allows pre-production testing. Option B is wrong because slot swap is not automatic rollback but can be reversed.

Option C is wrong because slots share the same App Service plan, so scaling applies to all. Option E is wrong because slots are in the same region.

Full explanation →
884
Multi-Selecthard

Which TWO actions should a DevOps engineer take to ensure that Azure DevOps pipelines comply with the principle of least privilege for service connections?

Select 2 answers
A.Create a service principal with permissions scoped to the minimum required Azure resources.
B.Use the Project Collection Build Service account for all pipeline runs.
C.Use Workload identity federation to avoid managing secrets.
D.Configure the service connection to be available only to specific pipelines.
E.Use the same service connection for both build and release pipelines.
AnswersA, D

Scoped permissions enforce least privilege.

Why this answer

Option A is correct because creating a service principal with permissions scoped to the minimum required Azure resources directly implements the principle of least privilege. By assigning only the necessary roles (e.g., Contributor on a specific resource group) to the service principal used in the service connection, you ensure that the pipeline can only perform actions on those resources, reducing the attack surface. This aligns with Azure RBAC best practices for securing automated deployments.

Exam trap

The trap here is that candidates often confuse 'Workload identity federation' (which improves secret management) with 'least privilege' (which is about permission scoping), leading them to select option C instead of recognizing that federation does not automatically restrict permissions.

Full explanation →
885
MCQmedium

Your team is migrating from TFVC to Git in Azure Repos. They want to preserve the history of all branches. Which migration tool should you use?

A.GitHub Importer
B.Azure DevOps Migration Tools
C.git-tfs tool
D.git-svn
AnswerC

Preserves history and branches.

Why this answer

The git-tfs tool is specifically designed to migrate TFVC repositories to Git while preserving full branch history, including changesets, branch relationships, and merge history. It bridges the gap between TFVC and Git by converting TFVC changesets into Git commits and mapping TFVC branches to Git branches, making it the correct choice for this migration scenario.

Exam trap

The trap here is that candidates often confuse git-tfs with git-svn, assuming both are interchangeable for any centralized-to-distributed migration, but git-tfs is TFVC-specific while git-svn is for Subversion, and Azure DevOps Migration Tools are for organizational data migration, not source control conversion.

How to eliminate wrong answers

Option A is wrong because GitHub Importer is used to import repositories from other Git hosts (like SVN, Mercurial, or another Git server) into GitHub, not from TFVC to Azure Repos. Option B is wrong because Azure DevOps Migration Tools are designed for migrating work items, test plans, and other Azure DevOps artifacts between organizations, not for converting TFVC source control history to Git. Option D is wrong because git-svn is a tool for bidirectional operation between Git and Subversion (SVN), not for TFVC migration.

Full explanation →
886
MCQmedium

Your team uses GitHub with a monorepo containing frontend and backend code. You need to implement a strategy where changes to the frontend folder trigger a frontend CI pipeline, changes to the backend folder trigger a backend CI pipeline, and changes to both trigger both. You also want to ensure that pull requests include changes only to one area to reduce complexity. What should you do?

A.Use CODEOWNERS to assign different reviewers for frontend and backend, and rely on manual pipeline triggers.
B.Configure separate CI pipelines with path filters so that each pipeline triggers only on changes to its respective folder.
C.Create branch policies that require specific builds based on the branch name.
D.Use a single pipeline that runs all tests on every change.
AnswerB

Path filters allow conditional triggering.

Why this answer

Option B is correct because GitHub Actions and Azure Pipelines support path filters (e.g., `paths` in YAML triggers) that allow you to define separate CI pipelines for frontend and backend folders. When a pull request includes changes to both folders, both pipelines automatically trigger, satisfying the requirement. This approach ensures that each pipeline runs only when its relevant code changes, reducing unnecessary builds and complexity.

Exam trap

The trap here is that candidates may think branch policies or CODEOWNERS can control pipeline triggers, but only path filters in the pipeline YAML definition can conditionally start a pipeline based on which files changed.

How to eliminate wrong answers

Option A is wrong because CODEOWNERS only assigns reviewers based on file paths, not pipeline triggers, and relying on manual pipeline triggers defeats the purpose of CI automation. Option C is wrong because branch policies that require specific builds based on branch name cannot differentiate between frontend and backend changes within the same branch; they apply to all changes on that branch. Option D is wrong because a single pipeline that runs all tests on every change would not differentiate between frontend and backend changes, violating the requirement to trigger separate pipelines based on the changed folder.

Full explanation →
887
MCQhard

Your company uses Azure DevOps and has a large monorepo with multiple teams. Developers report that Git operations are slow due to the repository size. Which approach should you recommend to improve performance while maintaining a single repository?

A.Use Git LFS to store all files
B.Split the monorepo into multiple smaller repositories
C.Add a .gitattributes file with filter directives
D.Enable sparse checkout and shallow fetch
AnswerD

Sparse checkout limits checkout to needed files; shallow fetch limits history depth.

Why this answer

Sparse checkout and shallow fetch are designed to improve Git performance in large monorepos by limiting the working tree to specific directories (sparse checkout) and reducing the history depth (shallow fetch). This keeps the repository intact as a single unit while significantly reducing the amount of data transferred and stored locally, directly addressing the slow Git operations without breaking the monorepo structure.

Exam trap

The trap here is that candidates often confuse performance improvements with repository restructuring, assuming that splitting the repo (Option B) is the only way to speed up Git, when Azure DevOps supports native Git features like sparse checkout and shallow fetch that preserve the monorepo architecture.

How to eliminate wrong answers

Option A is wrong because Git LFS is intended for large binary files, not for improving general Git performance on a large monorepo; storing all files in LFS would introduce overhead and break normal Git workflows. Option B is wrong because splitting the monorepo into multiple smaller repositories violates the requirement to maintain a single repository. Option C is wrong because .gitattributes with filter directives is used for custom smudge/clean filters (e.g., for Git LFS or keyword expansion), not for reducing the size or history of the repository to speed up operations.

Full explanation →
888
MCQhard

Your team uses a Git flow branching strategy with develop and release branches. You want to enforce that only release branches can be merged into main, and all merges into main require a successful deployment to a production-like environment. How should you implement this in Azure Pipelines?

A.Branch policy with required reviewers for main
B.Required status check for 'Check for linked work items'
C.YAML pipeline with environment approvals and branch filters on trigger
D.Build validation policy on main
AnswerC

Environment approvals enforce manual sign-off, and branch filters ensure only release branches trigger deployment.

Why this answer

Option B is correct because environment approvals in YAML pipelines can require manual approval before deployment to production, and branch filters on triggers can restrict to release branches. Option A is wrong because branch policies are for source control, not pipeline deployment. Option C is wrong because build validation runs on PR creation, not on merge.

Option D is wrong because 'Check for linked work items' does not enforce branch restrictions.

Full explanation →
889
MCQmedium

Refer to the exhibit. You are reviewing an ARM template used in an Azure Pipeline deployment. Which security concern should you address?

A.The VM size is too small for production
B.The apiVersion is outdated
C.The admin password is hardcoded in the template
D.The location parameter has a default value
AnswerC

Hardcoded passwords are insecure; should use a secure parameter or Key Vault reference.

Why this answer

Option B is correct because the admin password is hardcoded in plain text, which is a security vulnerability. Option A is wrong because the param default is acceptable. Option C is wrong because API version is valid.

Option D is wrong because VM size is fine.

Full explanation →
890
Multi-Selecthard

You are creating a YAML pipeline that builds a .NET Core application. The pipeline must use a multi-stage build with separate stages for 'Build', 'Test', and 'Deploy'. The 'Deploy' stage should only run if both 'Build' and 'Test' succeed. Which two conditions can you use to achieve this? (Select all that apply.)

Select 2 answers
A.In the Deploy stage, set 'dependsOn: [Build, Test]'
B.In the Deploy stage, set 'condition: and(succeeded('Build'), succeeded('Test'))'
C.In the Deploy stage, set 'condition: succeeded()' and 'dependsOn: [Build, Test]'
D.In the Deploy stage, set 'dependsOn: [Build, Test]' and 'condition: stageDependencies.Build.result == 'Succeeded''
AnswersA, C

Why this answer

Option A is correct because setting 'dependsOn: [Build, Test]' in the Deploy stage ensures that the Deploy stage only starts after both the Build and Test stages have completed. By default, a stage runs only if all its dependencies succeed, so this alone meets the requirement without needing an explicit condition. This is the standard way to enforce sequential execution in multi-stage YAML pipelines.

Exam trap

The trap here is that candidates often confuse the 'succeeded()' function with the ability to check individual stage results, leading them to incorrectly select Option B, or they misremember the exact syntax for accessing stage dependencies in Option D.

Why the other options are wrong

B

This syntax is for job conditions; stage conditions do not accept string arguments for succeeded().

D

'stageDependencies' is not a valid expression; you would use 'dependencies.Build.result'.

Full explanation →
891
MCQmedium

Refer to the exhibit. You have this GitHub Actions workflow YAML. The workflow does not trigger when you push to the main branch. What is the most likely issue?

A.The branch name should be in a list under 'branches' inside 'push'.
B.The 'vmImage' should be 'windows-latest' for scripts.
C.The correct keyword is 'on', not 'triggers'.
D.The 'triggers' keyword is misspelled; it should be 'trigger'.
AnswerC

GitHub Actions uses 'on' to define events.

Why this answer

Option B is correct. The 'triggers' keyword is incorrect. In GitHub Actions, the correct keyword is 'on'.

The workflow should use 'on: push: branches: [main]' instead of 'triggers'. Option A is incorrect because the push event is valid. Option C is not the issue.

Option D is not the cause.

Full explanation →
892
MCQhard

Your release pipeline deploys to multiple environments (Dev, Test, Prod) using approval gates. Recently, the Prod deployment failed because a manual validation task timed out after 30 minutes. You need to ensure that if the manual validation is not approved within 15 minutes, the pipeline automatically rejects the deployment and sends a notification. What should you do?

A.Set the 'Timeout in minutes' for the entire stage to 15.
B.In the Manual Validation task, set 'Timeout' to 15 and 'On timeout' to 'Reject'.
C.Configure a pre-deployment approval with a timeout of 15 minutes.
D.Add a PowerShell task after the manual validation that checks the status and cancels the pipeline if not approved.
AnswerB

This automatically rejects the deployment if the validation is not completed within 15 minutes.

Why this answer

Option D is correct because the Manual Validation task has a 'Timeout' setting; setting it to 15 minutes and configuring the 'On timeout' option to 'Reject' will automatically reject the deployment. Notifications can be set via subscription. Option A is wrong because pre-deployment approvals don't have a timeout that triggers rejection.

Option B is wrong because the pipeline-level timeout is not granular enough. Option C is wrong because the 'Cancel' action would cancel the entire pipeline, not just reject the validation.

Full explanation →
893
MCQeasy

Your team uses GitHub Flow for feature development. A developer commits directly to the main branch without creating a pull request. Which practice should you enforce to ensure code quality and prevent direct commits?

A.Require a manual sign-off from a team lead after each commit.
B.Configure branch protection rules on the main branch to require pull request reviews before merging.
C.Set up a .gitignore file to prevent certain file types from being committed.
D.Add a CODEOWNERS file that automatically assigns reviewers to any changes.
AnswerB

Branch protection rules enforce PRs and reviews.

Why this answer

Option B is correct because branch protection rules prevent direct commits to the main branch and require pull requests with reviews. Option A is incorrect because manual sign-off is not enforceable. Option C is incorrect because a CODEOWNERS file alone does not block commits.

Option D is incorrect because a .gitignore file does not enforce branch policies.

Full explanation →
894
MCQmedium

You are implementing a release pipeline that deploys a web app to Azure App Service. The deployment must be approved by a manager before proceeding to the production slot. However, the manager is on leave and the deployment is critical. What should you do to ensure the deployment can proceed without delaying the release?

A.Skip the approval for this deployment by overriding the settings.
B.Add an additional approver in the pre-deployment approval settings.
C.Configure the approval to time out after 24 hours and automatically approve.
D.Remove the approval requirement from the pipeline.
AnswerB

Adding another approver ensures the deployment can proceed if the primary is unavailable.

Why this answer

The best practice is to have a backup approver or a temporary override process, but since the question asks what you should do, setting up a timeout that auto-approves after a period is not secure. The correct approach is to add an additional approver (the manager's backup) in the approval settings. Skipping approval violates compliance.

Changing the pipeline permanently removes approval for future releases.

Full explanation →
895
MCQhard

You are designing a release pipeline for a multi-tenant SaaS application that is deployed to Azure App Service. Each tenant has its own App Service instance. The pipeline must deploy a new version of the application to a staging slot for each tenant, run smoke tests, and then swap the staging slot to production. You need to ensure that if the smoke tests fail for any tenant, the swap is not performed for that tenant, while other tenants continue. Which release pipeline configuration should you use?

A.Create a release with multiple jobs (one per tenant) in the same stage, each deploying to a tenant's staging slot, running tests, and conditionally swapping. Set the 'Run this job' condition to 'Only when all previous jobs have succeeded' or use custom conditions to skip swap on failure.
B.Create a single stage with a 'foreach' loop over tenants, and if smoke tests fail, skip the swap using a condition.
C.Create a single job with parallel tasks for each tenant, and configure failure conditions to skip the swap.
D.Create a single stage with multiple deployment tasks, one per tenant, and use a 'continue on error' option on each task.
AnswerA

Multiple jobs can run in parallel, and each job can independently handle success/failure for its tenant.

Why this answer

Option D is correct because using a multi-job release allows each tenant deployment to be independent, and you can configure pre-deployment conditions or failure conditions to skip the swap for that tenant if tests fail. Option A is wrong because stages are sequential and a failure in one tenant would block others. Option B is wrong because a single job with multiple tasks would still block all tenants if one fails.

Option C is wrong because a parallel execution in a single job is not possible; you need multiple jobs.

Full explanation →
896
Multi-Selecthard

Which THREE of the following are valid steps to implement a trunk-based development workflow in Azure Repos? (Select THREE.)

Select 3 answers
A.Run CI builds on the main branch.
B.Use feature flags and pair programming.
C.Merge to main only once per week.
D.Use short-lived feature branches that are merged within a day.
E.Create release branches for each production release.
AnswersA, B, D

CI ensures main is always stable.

Why this answer

Options A, C, and E are correct. Short-lived feature branches (A) are key; CI builds on main (C) ensure quality; pair programming (E) reduces need for long-lived branches. Option B is wrong because frequent merges are encouraged, not weekly.

Option D is wrong because release branches are not part of trunk-based development; everything is done on main.

Full explanation →
897
MCQhard

You execute the above Azure CLI command. A pipeline YAML references the variable group 'Config' and uses the variable 'env'. However, the pipeline fails because the variable 'env' is not found. What is the most likely reason?

A.The variable 'env' is a secret variable and cannot be used in YAML.
B.The variable group 'Config' is not linked to the pipeline.
C.The variable name is case-sensitive; the YAML uses 'Env' instead of 'env'.
D.The variable group is scoped to a specific branch, and the pipeline is running on a different branch.
AnswerC

Variable names are case-sensitive in Azure Pipelines.

Why this answer

Option C is correct because Azure DevOps variable names are case-sensitive. The pipeline YAML references the variable 'env', but if the variable group defines it as 'Env' (or any other casing), the pipeline will fail with a 'not found' error. This is a common pitfall when variable names are not matched exactly, including case, in YAML pipelines.

Exam trap

The trap here is that candidates assume variable names are case-insensitive (as in many programming languages or operating systems), but Azure DevOps treats them as case-sensitive, causing a mismatch error when the casing differs between the variable group and the YAML reference.

How to eliminate wrong answers

Option A is wrong because secret variables can be used in YAML pipelines; they are referenced with the same syntax as non-secret variables, though they cannot be displayed in logs. Option B is wrong because the question states the pipeline references the variable group 'Config', implying it is linked; if it were not linked, the pipeline would fail with a different error (e.g., 'variable group not found'). Option D is wrong because variable group scoping to a branch affects when the group is available, but the error message specifically says 'variable not found', not 'variable group not available'.

Full explanation →
898
MCQhard

You are auditing an Azure Pipeline YAML file. The security team requires that deployments to the 'Prod' environment only occur from the main branch. Does this pipeline meet that requirement?

A.Yes, because the Deploy stage always runs after Build
B.No, because the Build stage should also be conditioned
C.Yes, because the condition ensures deployment only from main
D.No, because the condition should be 'succeeded()' only
AnswerC

The condition 'eq(variables['Build.SourceBranch'], 'refs/heads/main')' enforces this.

Why this answer

Option B is correct because the condition checks that the source branch is main. Option A is wrong because it does meet the requirement. Option C is wrong because the condition is correct.

Option D is wrong because the condition is correct.

Full explanation →
899
MCQmedium

Refer to the exhibit. A developer pushes a commit to a branch named 'feature/new-login'. Which of the following will occur?

A.The pipeline will trigger and run all steps because the branch name does not match any exclude pattern.
B.The pipeline will not trigger because the branch is excluded.
C.The pipeline will trigger only the restore and build steps, skipping tests.
D.The pipeline will trigger but fail with an error because the branch is not in the include list.
AnswerB

The exclude pattern 'feature/*' prevents triggering on any branch starting with 'feature/'.

Why this answer

The trigger includes main and release/* branches, and explicitly excludes feature/* branches. Since 'feature/new-login' matches the exclude pattern 'feature/*', the pipeline will not trigger. The pipeline will only trigger for branches that match include patterns and do not match exclude patterns. 'feature/new-login' is excluded, so no build will start.

Full explanation →
900
MCQmedium

Refer to the exhibit. You are deploying this Bicep file using Azure Pipelines. The 'environment' parameter should be set to 'dev', 'qa', or 'prod' based on the release stage. How should you pass the parameter value?

A.Define the parameter in the 'parameters:' section of the YAML pipeline.
B.Set a pipeline variable named 'environment' and reference it in the AzureResourceManagerTemplateDeployment task's overrideParameters.
C.Use a task to replace the string '${environment}' in the Bicep file before deployment.
D.Modify the Bicep file to include a default value for environment.
AnswerB

Correct: Override parameters allows passing values to ARM/Bicep.

Why this answer

Option B is correct because you can set the 'environment' parameter as a pipeline variable and pass it to the Bicep deployment task. Option A is wrong because ARM template parameters are not set in the YAML file directly. Option C is wrong because the Bicep file does not have a default value.

Option D is wrong because you cannot modify the Bicep file dynamically.

Full explanation →
Page 11

Page 12 of 13

Page 13

All pages

12345678910111213

Practice AZ-400 by domain

Target a specific domain to shore up weak areas.

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