Courseiva

Microsoft Azure DevOps Engineer Expert AZ-400 (AZ-400) — Questions 601–675

696 questions total · 10pages · All types, answers revealed

Take a mock examExam hub
Page 8

Page 9 of 10

Page 10
601
MCQmedium

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

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

The PublishCodeCoverageResults@1 task is the dedicated Azure DevOps task for publishing code coverage data generated by test runs to the pipeline UI and build summary. It accepts coverage files in formats like Cobertura or JaCoCo, making it the correct choice for publishing .NET Core coverage reports.

Why this answer

The 'PublishCodeCoverageResults@1' task is the correct choice because it is specifically designed to publish code coverage results (e.g., Cobertura or JaCoCo XML reports) to Azure DevOps, making them visible in the build summary and pipeline artifacts. This task consumes the coverage data file generated by a previous test run (e.g., via 'DotNetCoreCLI@2' with '--collect "Code Coverage"') and uploads it to the Azure DevOps service for reporting.

Exam trap

The trap here is that candidates confuse the task that runs tests with coverage collection (e.g., VSTest@2 or DotNetCoreCLI@2) for the task that publishes the coverage results, forgetting that publishing is a separate, explicit step required to surface the data in Azure DevOps.

How to eliminate wrong answers

Option B is wrong because 'PublishTestResults@2' publishes test pass/fail results (e.g., TRX, JUnit XML) to the Tests tab, not code coverage data. Option C is wrong because 'DotNetCoreCLI@2' with the 'test' command runs tests and can collect coverage data (e.g., via Coverlet), but it does not publish the coverage results to Azure DevOps; a separate publish task is required. Option D is wrong because 'VSTest@2' with 'codeCoverageEnabled' runs tests with coverage instrumentation (using the Visual Studio coverage engine), but it does not publish the results; the coverage data must still be published using a dedicated task like 'PublishCodeCoverageResults@1'.

Full explanation →
602
MCQhard

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

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

If the Windows service or daemon account that runs the runner no longer has write permissions on the workspace, _work, or the NuGet cache directory, the restore step fails with an access denied (UnauthorizedAccessException) error. This exactly matches the symptom, as permission changes on the runner service account directly affect local file access.

Why this answer

The 'Access to the path is denied' error during NuGet restore on a self-hosted runner typically indicates a file system permission issue. Since the runner has been working for months, the most likely cause is that the service account under which the runner runs no longer has write access to the working directory or the NuGet cache folder, often due to a group policy change, account modification, or folder permission drift.

Exam trap

The trap here is that candidates confuse authentication failures (token expiry) with local file system permission errors, assuming any 'access denied' relates to GitHub connectivity rather than the runner's service account permissions on the on-premises machine.

How to eliminate wrong answers

Option A is wrong because an expired runner authentication token would cause authentication failures when connecting to GitHub, not file access errors during NuGet restore. Option C is wrong because deleting the NuGet cache directory would cause cache misses and re-downloads, not 'Access to the path is denied' errors; the runner would still have permission to create a new cache folder. Option D is wrong because newer runner versions maintain full backward compatibility with NuGet restore; the runner does not 'support' or 'not support' NuGet restore as a feature.

Full explanation →
603
MCQeasy

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

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

The file .github/workflows/ci.yml is the standard and expected location for a GitHub Actions workflow. Any YAML file in the .github/workflows directory defines an automated workflow that GitHub Actions will parse and run based on configured event triggers, such as push or pull_request, making it the correct choice for setting up CI with GitHub.

Why this answer

GitHub Actions workflows are defined in YAML files stored in the .github/workflows directory at the root of the repository. The file can have any name but must have a .yml or .yaml extension, and ci.yml is a common convention. This file contains the workflow definition, including triggers (on), jobs, and steps.

GitHub automatically detects and runs workflows from this directory.

Exam trap

AZ-400 often tests the specific file location and format required for GitHub Actions workflows, and candidates may confuse it with other CI/CD tools like Jenkins or Azure Pipelines.

How to eliminate wrong answers

Option A is wrong because a Jenkinsfile is used by Jenkins, not GitHub Actions, to define pipeline stages in Groovy DSL. Option C is wrong because a Dockerfile is used to build container images, not to define CI workflows. Option D is wrong because azure-pipelines.yml is used by Azure Pipelines, not GitHub Actions, to define build and release pipelines.

Full explanation →
604
MCQeasy

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

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

Azure Monitor alerts can be configured from Application Insights metrics or logs, and by setting an action group that invokes a webhook, you can call the Azure Boards REST API to automatically create a work item. This closes the loop by transforming telemetry-driven alerts into actionable backlog items without manual intervention.

Why this answer

Azure Monitor alerts based on Application Insights data can trigger a webhook that calls the Azure Boards REST API to automatically create a work item. This integrates monitoring data with the pipeline to establish a continuous feedback loop. Option A is incorrect because Power BI visualization and email alerts do not automate work item creation.

Option C is incorrect because release pipeline logs are not for collecting user analytics; Application Insights is needed. Option D is incorrect because manually reviewing dashboards is not automated.

Full explanation →
605
MCQhard

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

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

Creating a branch protection rule for the main branch with required status checks is the correct solution because it prevents merging until the specified GitHub Actions workflow checks succeed. This enforces CI/CD validation as a hard gate for all pull requests targeting main, ensuring only verified changes are merged.

Why this answer

Branch protection rules in GitHub allow you to enforce required status checks on pull requests before merging. By configuring a branch protection rule for the main branch, you can specify that certain GitHub Actions workflow runs must pass (e.g., CI checks) before a pull request can be merged. This directly enforces the policy that all workflows must pass required status checks.

Exam trap

The trap here is confusing branch protection rules (which enforce merge requirements) with environment protection rules (which control deployment approvals) or CODEOWNERS (which mandate file-level reviews), leading candidates to pick options that address review or permissions rather than status checks.

How to eliminate wrong answers

Option A is wrong because environment protection rules control deployments to specific environments (e.g., production), not pull request merge requirements on a branch. Option B is wrong because setting 'contents: write' permission in a workflow grants write access to repository contents, which is unrelated to enforcing status checks on pull requests. Option C is wrong because a CODEOWNERS file defines who must review changes to specific files, but it does not enforce that workflows must pass before merging; it only requires approval from designated teams or individuals.

Full explanation →
606
MCQhard

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

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

This option is incorrect because although dismiss_stale_reviews is false, the branch policy also sets require_last_push_approval to true. In Azure DevOps, require_last_push_approval forces all previous approvals to be invalidated whenever a new push occurs, regardless of whether stale review dismissals are enabled. Thus, the current commits have no valid approval, and the PR cannot be merged.

Why this answer

In Azure Repos, the 'Block on last push' policy (require_last_push_approval) only revokes an approval from the user who made the most recent push, preventing them from approving their own changes. It does not invalidate approvals from other reviewers. The setting that resets all approvals when new commits are pushed is 'Reset code reviewer votes when there are new changes' (dismiss_stale_reviews).

Since dismiss_stale_reviews is false in the given configuration, the two existing approvals remain valid when the developer pushes a third commit.

Exam trap

Do not confuse 'require_last_push_approval' with 'dismiss_stale_reviews'. The former only affects the last pusher's approval, while the latter resets all approvals on any new push.

How to eliminate wrong answers

Option A is wrong because `dismiss_stale_reviews` is not present in the JSON; instead, `require_last_push_approval` is set to true, which overrides any default behavior and forces dismissal of approvals on new pushes. Option B is wrong because the `allowed_merge_types` list includes squash, but automatic merging is not triggered by a push; the PR still requires valid approvals and policy compliance. Option D is wrong because the merge type (squash) is explicitly allowed in the configuration, so the PR is not blocked on that basis.

Full explanation →
607
MCQmedium

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

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

Branch protection rules in GitHub allow requiring status checks to pass before a pull request can be merged. When you require status checks, the pipeline's validation becomes a mandatory gate: any PR that doesn't have a successful status check from the configured pipeline is blocked from merging, directly enforcing the quality gate at the repository level. This is the only option that enforces the requirement at the merge point.

Why this answer

GitHub branch protection rules allow you to require status checks to pass before merging a pull request. By configuring a rule that requires the Azure Pipelines build and test status check to succeed, you enforce that all pull requests are validated before they can be merged into the protected branch.

Exam trap

The trap here is confusing pipeline triggers (which only initiate runs) with merge gating (which enforces that those runs must succeed before merging), leading candidates to select option B instead of A.

How to eliminate wrong answers

Option B is wrong because setting the pipeline trigger to run on pull request only ensures the pipeline runs when a PR is created, but does not enforce that the pipeline must succeed before the PR can be merged. Option C is wrong because pipeline permissions requiring approval control who can run or modify the pipeline, not whether a PR can be merged based on test results. Option D is wrong because a pre-deployment check on an environment gates deployment to that environment, not the merging of a pull request in GitHub.

Full explanation →
608
Matchingmedium

Match each Azure DevOps security concept to its purpose.

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

Concepts
Matches

Personal access token for API authentication

Securely stores credentials for external services

Shared variables with optional secret protection

Centralized secure files and variable groups

Why these pairings

Azure AD manages user identities; PATs authenticate scripts; Service Principals authenticate automated services; Security Groups manage user permissions. Common confusions include mixing the roles of Azure AD and Service Principals, or PATs with Security Groups.

Full explanation →
609
Multi-Selecthard

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

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

Configuring deployment approvals and checks on the production stage is correct because it enforces manual authorization and integrates with Azure Policy or other gates, ensuring that only authorized personnel can approve and promote builds to production, reducing risk of unauthorized deployments.

Why this answer

Deployment approvals and checks in Azure Pipelines require manual sign-off or automated policy validation before a release proceeds to production, preventing unauthorized or unverified changes. Option D is correct because using a service connection with a managed identity eliminates the need to store static credentials, reducing the risk of credential exposure and unauthorized access to Azure resources during deployment.

Exam trap

The trap here is that candidates often confuse secret management (Option A) with access control, or think that PR triggers (Option C) or self-hosted agents (Option E) directly prevent unauthorized production access, when in fact they address different security concerns (secret protection, code validation, and agent isolation) rather than deployment authorization.

Full explanation →
610
MCQeasy

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

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

Azure Log Analytics is the log ingestion, storage, and query service within Azure Monitor; it can collect GitHub Actions workflow run logs via diagnostic settings or integrations, enabling you to centralize CI/CD logs and analyze them with KQL queries.

Why this answer

Azure Log Analytics is the service designed to ingest, store, and query large volumes of log data using Kusto Query Language (KQL), making it ideal for centralizing GitHub Actions build and deployment logs and identifying recurring failures. You can create a Log Analytics workspace, send logs via the Logs Ingestion API or diagnostic settings, and run KQL queries to spot patterns. This directly satisfies the requirement to collect and analyze logs centrally.

Exam trap

The trap is picking Application Insights because it sounds like the 'monitoring' answer — but AZ-400 tests the distinction between APM telemetry (Application Insights) and centralized log ingestion/query (Log Analytics).

How to eliminate wrong answers

Option A is wrong because Azure Monitor Alerts evaluates conditions and triggers notifications — it is a response mechanism, not a log ingestion and query platform. Option C is wrong because GitHub Insights provides repository and contributor analytics (e.g., commit activity, PR metrics), not centralized log ingestion or KQL querying of build/deployment logs. Option D is wrong because Application Insights is an APM tool for instrumenting application telemetry (requests, dependencies, exceptions), not for ingesting CI/CD pipeline logs from GitHub Actions.

Full explanation →
611
MCQeasy

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

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

Branch control for environments is the correct answer because Azure Pipelines environment checks allow you to restrict which branches or branch types can deploy to that environment. This is done by configuring an approval or branch control check that references an allowed branch list or a required template, thereby enforcing that only authorized branches trigger releases.

Why this answer

Branch control for environments in Azure Pipelines allows you to restrict which branches can trigger deployments to specific environments, such as production. By configuring branch filters on an environment, you ensure that only approved branches (e.g., main or release branches) can initiate a production deployment, providing a security and governance boundary.

Exam trap

The trap here is that candidates often confuse deployment gates (approval checks) with branch-level access control, but gates evaluate conditions during deployment, not which branches are allowed to trigger the deployment in the first place.

How to eliminate wrong answers

Option A is wrong because YAML template expressions are used for parameterization and conditional logic within pipeline definitions, not for restricting which branches can trigger deployments to environments. Option C is wrong because deployment gates are approval checks (e.g., monitoring, manual intervention) that evaluate conditions before or during a deployment, but they do not control which branches can initiate the deployment. Option D is wrong because pipeline decorators inject additional steps or tasks into every pipeline run at the organization or project level, but they cannot enforce branch-based restrictions on environment deployments.

Full explanation →
612
MCQeasy

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

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

A build validation branch policy on main requires a pull request trigger build to complete successfully before merging; if the build fails or has not yet finished, the merge is blocked by server-side enforcement, providing a true quality gate.

Why this answer

Azure Repos branch policies on main can require a build validation that runs on pull requests and blocks completion until the build succeeds. This enforces that every PR is built and tested before merge, which is exactly the requirement. Manual runs, non-blocking pipelines, and post-merge CI triggers do not prevent merging of failing code.

Exam trap

The trap is choosing a CI trigger on main (which runs post-merge) instead of a PR build validation policy (which gates the merge) — the exam tests whether you know the difference between post-merge CI and pre-merge gating.

How to eliminate wrong answers

Option A is wrong because manual pipeline runs rely on human discipline and do not enforce or block merges. Option B is wrong because a non-blocking pre-merge pipeline provides feedback but does not prevent merging failing code. Option D is wrong because a CI trigger on main runs after commits are already merged, so it cannot prevent bad code from reaching main.

Full explanation →
613
MCQhard

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

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

Azure autoscale requires the rule to reference the correct resource-specific metric namespace (e.g., Microsoft.Compute/virtualMachineScaleSets for VMSS) and metric name such as 'Percentage CPU' with an aggregation of Average over the evaluated time window; specifying a low-level counter like 'CpuTime' or the wrong namespace prevents the metric signal from being recognized, so the scale-out condition never evaluates to true and no scale operation occurs.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
614
Multi-Selectmedium

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

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

Scoping variable group access to only the specific pipelines that require those secrets reduces the attack surface and enforces least privilege. Azure DevOps pipeline permissions on variable groups ensure unauthorized pipelines cannot consume or expose the linked secrets.

Why this answer

Limiting variable group permissions to specific pipelines ensures that only authorized pipelines can access sensitive secrets, reducing the risk of unauthorized exposure. Option D is correct because Azure Key Vault provides a centralized, auditable, and encrypted store for secrets, and mapping them as secret variables in Azure Pipelines prevents the secret values from being exposed in logs or output.

Exam trap

The trap here is that candidates may think overriding secrets at queue time (Option C) is a valid security feature, but it actually undermines security by allowing users to bypass the approved secret store and inject arbitrary values.

Full explanation →
615
MCQmedium

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

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

A custom capability demand restricts pipeline job placement to self-hosted agents that carry that capability, so only approved, patched agents in the specified pool run the pipeline. This satisfies the requirement to enforce use of approved agents with current security patches.

Why this answer

By adding a demand for a custom capability (e.g., 'SecurityPatchLevel = latest') on the pipeline, only agents that possess that capability can run the pipeline. This allows you to enforce that only approved, patched agents are used. Option C is incorrect because 'setting an agent pool to use a specific agent queue with an isolation scope' is not a recognized Azure Pipelines feature; agent pools use demands, not isolation scopes, to filter agents.

Options A and B are also incorrect because configuring pool permissions or creating a deployment pool does not enforce that only agents with specific patches are used; they only control access or assignment but not the selection logic based on capabilities.

Exam trap

The trap is that candidates may think that using a dedicated agent queue or deployment pool will automatically limit which agents can run the pipeline. However, without a custom capability demand, any agent in the pool could be matched to the job. The correct approach is to define a custom capability for 'SecurityPatchLevel' or similar and add a demand to the pipeline.

How to eliminate wrong answers

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

Full explanation →
616
Multi-Selectmedium

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

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

Defining variables in the pipeline UI and marking them secret encrypts the value at rest in Azure DevOps and masks it in logs, satisfying the requirement to keep credentials out of plain-text YAML. Secret variables are not automatically exposed to scripts, so tasks must map them explicitly via environment variables.

Why this answer

Option A is correct because defining variables in the pipeline UI (Library variable groups or pipeline variables) and marking them as secret encrypts them at rest and masks their values in logs, which is the built-in Azure Pipelines mechanism for handling sensitive values. Option C is correct because Azure Key Vault is the recommended centralized secret store, and Azure Pipelines can link a Key Vault as a variable group so secrets are fetched at runtime and never persisted in the pipeline definition. Option B is not recommended because plain environment variables on the build agent are not encrypted or masked and can leak into logs or be read by other processes.

Option D is wrong because there is no 'secret' keyword for variables in YAML; secrets must come from the UI, variable groups, or Key Vault. Option E is wrong because storing secrets as plain text in YAML exposes them in source control and build logs.

Exam trap

The trap here is that candidates often confuse the ability to define variables in YAML with the ability to define secret variables in YAML, not realizing that Azure Pipelines explicitly prohibits storing secret values in YAML files to prevent repository exposure.

Full explanation →
617
MCQhard

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

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

Trunk-based development (TBD) with short-lived feature branches merged multiple times per day minimizes merge conflicts because branches diverge for hours, not weeks; feature flags decouple deployment from release, letting incomplete work ship safely behind toggles, and hotfix branches cut from main can be merged and deployed immediately, keeping main always in a releasable state and enabling continuous integration and continuous delivery.

Why this answer

Trunk-based development with short-lived feature branches (less than a day) and frequent merges to main directly addresses the root causes of merge conflicts and long integration periods by minimizing divergence. Feature flags decouple deployment from release, allowing incomplete features to be merged safely. Hotfixes from main and quick merges back align with CI/CD principles, enabling fast feedback and high-quality releases.

Exam trap

AZ-400 often tests the misconception that GitFlow is suitable for CI/CD; candidates may choose stricter GitFlow (Option D) or release branches (Option C) because they seem to add control, but they actually hinder continuous integration and fast feedback.

How to eliminate wrong answers

Option B is wrong because committing directly to main without pull requests or code reviews bypasses quality gates and increases risk, even if commits are small and pass CI; it also lacks a structured way to handle incomplete features. Option C is wrong because merging feature branches into release branches and then to main creates long-lived release branches, reintroducing integration delays and merge conflicts, and it doesn't support fast feedback for features. Option D is wrong because GitFlow inherently promotes long-lived branches (develop, release, hotfix), which cause merge conflicts and slow integration; stricter policies and more frequent merges do not eliminate the fundamental branching overhead.

Full explanation →
618
MCQhard

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

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

The 'azure/k8s-deploy' action only applies Kubernetes manifests, treating them as static YAML; it does not create or inject imagePullSecrets into the cluster. When pulling images from a private registry like ACR, Kubernetes requires a docker-registry secret (type kubernetes.io/dockerconfigjson) containing credentials, and your deployment spec must explicitly reference that secret under `imagePullSecrets`. Because the action simply runs `kubectl apply`, it cannot authenticate the kubelet on the cluster's behalf, so you must add a prior step to create the secret (e.g., using `kubectl create secret docker-registry`) and ensure it is referenced in the deployment manifest.

Why this answer

The 'azure/k8s-deploy@v1' action deploys to Kubernetes but does not automatically create imagePullSecrets for private container registries. Even if the registry credentials are stored as secrets in GitHub, they are not automatically applied to the cluster. You must explicitly create a Kubernetes secret of type docker-registry and add an imagePullSecrets entry to the deployment manifest.

Option A is wrong because using 'latest' tag is not a best practice and does not address authentication. Option B is wrong because the image name is likely correct; the issue is pulling due to lack of credentials. Option C is wrong because the action does support private registries when credentials are properly configured.

Full explanation →
619
MCQeasy

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

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

Commit signature verification requires each commit to be cryptographically signed with a verified key (e.g., GPG, SSH, or S/MIME) and the signature to be verified by the repository host. Enabling this in Azure Repos or GitHub protects the integrity and authenticity of every change, directly ensuring that all code changes are signed.

Why this answer

GitHub's commit signature verification uses GPG, SSH, or S/MIME keys to cryptographically sign commits and tags, and branch protection/rulesets can require signed commits before merging. This enforces that all code changes carry a verified signature tied to a trusted identity.

Exam trap

AZ-400 often tests the confusion between commit signature verification (authorship integrity) and code scanning/secret scanning (vulnerability and credential detection) — only signature verification enforces signed commits.

How to eliminate wrong answers

Option A is wrong because Dependabot automates dependency updates and has nothing to do with commit signing or merge enforcement. Option C is wrong because code scanning (CodeQL) analyzes code for vulnerabilities and does not verify commit signatures. Option D is wrong because secret scanning detects leaked credentials and does not enforce commit signing.

Full explanation →
620
MCQhard

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

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

Marking the alert as false positive in the GitHub UI correctly dismisses the alert for that specific detected secret and provides feedback that helps reduce future false positives. This is the intended workflow when you determine the secret is not a real credential, such as a test value or sample string.

Why this answer

GitHub Advanced Security secret scanning alerts can be dismissed as 'false positive' directly in the GitHub UI (Security tab → Secret scanning → alert → Dismiss → False positive). This preserves the audit trail and prevents the alert from recurring as an open finding while documenting the reason.

Exam trap

AZ-400 often tests the overreaction of disabling scanning or revoking credentials when the correct action is to triage and dismiss the alert as a false positive in the UI.

How to eliminate wrong answers

Option A is wrong because disabling secret scanning for the entire repository removes protection for all secrets and is a disproportionate response to a single false positive. Option B is wrong because deleting and revoking the PAT assumes the alert is a real secret — the developer already determined it is a false positive, so revocation is unnecessary and disruptive. Option D is wrong because leaving the alert open clutters the security dashboard and does not communicate the triage decision, undermining the security workflow.

Full explanation →
621
MCQmedium

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

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

This is correct because the Cache task supports a key derived from the hash of packages.lock.json, which uniquely identifies the exact set of dependencies. When the key matches a previously saved cache, the packages folder is restored immediately, and after the build it is saved again, significantly improving restore time.

Why this answer

The Cache task in Azure Pipelines allows you to cache NuGet packages by specifying a key derived from the hash of `packages.lock.json`. This ensures that the cache is invalidated only when the lock file changes, which accurately reflects changes in package dependencies. The cached `~/.nuget/packages` folder is then restored on subsequent runs, significantly reducing restore time.

Exam trap

The trap here is that candidates confuse the NuGet restore task's built-in caching (which is not a parameter) with the separate Cache task, or they mistakenly believe that copying or publishing artifacts achieves caching for subsequent builds.

How to eliminate wrong answers

Option A is wrong because the CopyFiles task merely copies files to a staging directory; it does not implement caching logic or persist packages across pipeline runs. Option B is wrong because the NuGet restore task does not have a 'cacheRestore' option; caching is handled by a separate Cache task, not by a parameter on the restore task. Option D is wrong because the PublishBuildArtifacts task uploads artifacts to Azure Pipelines or a file share, but it does not cache packages for reuse in future builds; it is intended for sharing build outputs, not for dependency caching.

Full explanation →
622
MCQmedium

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

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

Individual build pipelines per service enable each team to build, version, and test independently, while a dedicated release pipeline that deploys all services to an integration environment validates cross-service contracts and interactions in a realistic environment, combining independence with necessary integration assurance.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
623
MCQmedium

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

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

A build completion trigger in a release pipeline is the correct choice because it automatically starts a release as soon as a specified build pipeline finishes successfully. This is the standard mechanism to deploy the artifacts produced by a CI build, enabling a fully automated build-and-release workflow.

Why this answer

A build completion trigger in the release pipeline allows you to automatically create a release whenever a specific build pipeline succeeds on the main branch. This trigger monitors the build pipeline for successful completions and initiates the release process, which directly matches the requirement of creating a release after every successful build on main.

Exam trap

The trap here is that candidates often confuse CI triggers (which apply to build pipelines) with release triggers, leading them to incorrectly select option B, not realizing that release pipelines use build completion triggers instead of CI triggers.

How to eliminate wrong answers

Option A is wrong because a pull request trigger in the build pipeline is used to automatically run a build when a PR is created or updated, not to create a release after a build succeeds. Option B is wrong because continuous integration (CI) triggers in release pipelines are not a valid concept; CI triggers exist in build pipelines to trigger builds on code changes, not to trigger releases. Option D is wrong because a scheduled trigger in the release pipeline runs releases on a fixed time schedule, not in response to a successful build on the main branch.

Full explanation →
624
Multi-Selecthard

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

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

Adding a step to run Trivy scans the container image for known vulnerabilities in OS packages and application dependencies. Trivy integrates into GitHub Actions via aquasecurity/trivy-action, can fail the build based on severity thresholds, and generates a SARIF report for GitHub code scanning, making it the correct step for a security scanning requirement.

Why this answer

Option B is correct because the requirement explicitly states the images must be scanned for vulnerabilities, and adding a step that runs a scanning tool such as Trivy (e.g., aquasecurity/trivy-action) performs that vulnerability scan against the built image. Option C is correct because the requirement also states the images must be signed, and cosign (sigstore/cosign) is the standard tool for signing container images, producing a signature that can be verified against the image digest. Option E is correct because a multi-container application must actually be built and pushed to a registry before it can be scanned or signed, and docker/build-push-action is the canonical GitHub Actions step that builds and pushes the images.

Option A is not required because authenticating to Docker Hub is only necessary if pushing to Docker Hub specifically; the scenario does not mandate that registry, and authentication could be handled differently or target another registry. Option D is not required for the stated goals because checking out the code is a general prerequisite for many workflows but is not one of the three actions specifically needed to scan and sign the produced images.

Exam trap

The trap is including generic workflow steps (checkout, login) that are helpful but not the specific actions that perform scanning and signing — the exam wants the three steps that directly satisfy the stated security requirement.

Full explanation →
625
MCQmedium

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

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

This is the correct configuration because it disables CI triggers entirely (trigger: none) and defines a PR trigger that runs only for pull requests targeting the main branch and only when changes occur under the src/ path. This filters out irrelevant PRs, ensuring the pipeline runs precisely when code in src/ is modified, saving resources and providing focused validation.

Why this answer

It sets `trigger: none` to disable CI triggers on commits, and uses a PR trigger with `branches: include: - main` and `paths: include: - src/*` to ensure the pipeline only runs automatically when a pull request targets the main branch and the changes include modifications to the 'src/' directory. This configuration meets the requirement of conditional PR-triggered builds based on file paths.

Exam trap

The trap here is that candidates often confuse CI triggers (`trigger`) with PR triggers (`pr`) and forget that path filtering must be explicitly specified under the PR trigger to restrict which file changes initiate the pipeline.

How to eliminate wrong answers

Option A is wrong because it sets a CI trigger on main (trigger: - main) and disables PR triggers (pr: none), so the pipeline would run on every commit to main, not only on pull requests. Option C is wrong because it sets `trigger: none` and `pr: - main` without a `paths` filter, so the pipeline would run on any pull request to main, regardless of whether changes are in 'src/'. Option D is wrong because it sets both CI and PR triggers on main without a `paths` filter, causing the pipeline to run on every commit to main and on every pull request to main, not only when 'src/' changes.

Full explanation →
626
MCQeasy

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

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

Squash commit is correct because it merges the feature branch by combining all of its changes into a single new commit on the target branch. This collapses the entire commit history of the feature into one commit, exactly matching the requirement to combine all changes into a single commit.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →
627
MCQhard

Refer to the exhibit. A developer runs the pipeline on a branch called 'feature/abc'. What will happen?

A.The pipeline will fail with a syntax error.
B.Only the Build stage will execute.
C.Both stages will execute.
D.The Deploy stage will run but skip the steps.
AnswerB

Only the Build stage will execute because the Build stage has no condition (or an unconditional condition), so it runs on every branch. The Deploy stage has a condition that restricts it to the main branch (e.g., eq(variables['Build.SourceBranch'], 'refs/heads/main')), which evaluates to false on the o50p branch, causing the entire Deploy stage to be skipped.

Why this answer

The 'Deploy' stage has a condition that checks if the source branch is 'refs/heads/main'. Since the branch is 'feature/abc', the condition evaluates to false, so the Deploy stage will be skipped. The Build stage runs regardless.

Full explanation →
628
MCQmedium

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

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

The deployment job fails because it references an environment named 'Production' that does not yet exist in the Azure DevOps project. You must create the environment in Project Settings > Pipelines > Environments before running the pipeline; this provides the required resource for deployment job execution and enables tracking, approvals, and security on that environment.

Why this answer

The error indicates that the Azure DevOps pipeline references an environment named 'Production' that does not exist in the project. Environments must be explicitly created in Azure DevOps project settings before they can be used in deployment jobs. Option D resolves this by creating the required environment, allowing the deployment job to target it correctly.

Exam trap

The trap here is that candidates may think a script step can dynamically create the environment before the deployment job runs, but Azure DevOps validates environment references at pipeline compile time, not runtime, so the environment must already exist.

How to eliminate wrong answers

Option A is wrong because removing the 'environment' property would eliminate the deployment target, which is likely required for approvals, checks, and traceability; the pipeline would then fail to deploy to the intended stage. Option B is wrong because changing the deployment strategy from 'runOnce' to 'rolling' does not address the missing environment; it only alters how resources are updated during deployment, not the existence of the environment itself. Option C is wrong because environments cannot be created dynamically via a script step in a pipeline; they must be pre-created in Azure DevOps project settings or via the REST API, and a script step cannot create an environment that the deployment job references at parse time.

Full explanation →
629
MCQmedium

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

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

The File Transform task is the correct choice because it directly performs token replacement in configuration files like appsettings.json, using variable values from pipeline variable groups. It supports both standard and secret variables, so connection strings and API keys can be injected at release time without exposing them in the repository.

Why this answer

The File Transform task in Azure Pipelines can perform token replacement in configuration files like appsettings.json using variables defined in pipeline variable groups. This allows environment-specific settings to be injected during deployment without hardcoding secrets in source control. Variable groups can be linked to Azure Key Vault for secure secret management.

Exam trap

AZ-400 often tests the confusion between build-time and release-time configuration, and candidates may choose options that involve code changes or are specific to older technologies like Web.config.

How to eliminate wrong answers

Option B is wrong because separate build configurations and Web.config transforms are specific to ASP.NET and not applicable to appsettings.json in .NET Core. Option C is wrong because the Azure App Service Deploy task with Web Deploy parameterization is for web.config, not appsettings.json. Option D is wrong because setting environment variables in App Service and reading them in code is a valid approach but does not automatically replace settings in appsettings.json during deployment; it requires code changes to read environment variables.

Full explanation →
630
MCQmedium

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

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

Path filters in Azure Pipelines follow minimatch semantics, where a single asterisk (*) matches characters within a path segment but not directory separators. Consequently, 'src/*' only matches files directly inside 'src' and does not match files in subdirectories like 'src/WebApplication/Program.cs', so the trigger will not fire for changes in subdirectories.

Why this answer

The path filter `src/*` uses a single asterisk, which only matches files directly within the `src/` directory, not files in subdirectories (e.g., `src/app/main.cs`). Azure Pipelines path filters require a double asterisk `src/**` to recursively match all files under `src/`. Since the modified file is in a subdirectory, the trigger condition is not met, and the pipeline does not start.

Exam trap

The trap here is that candidates confuse the single asterisk `*` with the recursive double asterisk `**`, assuming `src/*` matches all files under `src/` including subdirectories, which is incorrect in Azure Pipelines path filters.

How to eliminate wrong answers

Option A is wrong because branch filters in Azure Pipelines YAML triggers do not require the 'refs/heads/' prefix; the branch name alone (e.g., 'main') is sufficient. Option B is wrong because the correct keyword is 'include' (not 'includes'), and 'include' is valid syntax for path filters in YAML triggers. Option C is wrong because the variable 'buildConfiguration' is defined later in the YAML (under variables) and does not need to be at the top level; its absence does not prevent the trigger from firing.

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

A branch policy on the target branch that requires a minimum number of reviewers from the Senior Developers group enforces that at least that many senior devs must approve before the PR can be completed, and you can also set it to block merge until their approvals are obtained.

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

Requiring signed commits is the policy that enforces each commit to be cryptographically signed with GPG or S/MIME, thereby verifying the identity of the committer and ensuring the commit content has not been tampered with. This directly fulfills the goal of enforcing that all commits are signed.

Why this answer

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

Trunk-based development with short-lived feature branches (typically less than a day) ensures that all developers integrate into main frequently, which minimizes merge conflicts, enables continuous integration, and supports rapid, automated deployment of microservices while still isolating work in progress via feature branches that are merged and deleted quickly.

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

The 'azure/login' action with OIDC exchanges GitHub's OIDC token for an Azure AD access token by using a federated identity credential configured in Microsoft Entra ID for the GitHub environment. You create the credential with the correct subject identifier (e.g., repo:owner/repo:environment:prod) so that GitHub's token is trusted, and the action automatically retrieves the token without requiring a client secret. This eliminates long-lived secrets, enables automatic token rotation, and is the recommended secure pattern for GitHub Actions to Azure deployments.

Why this answer

Using the 'azure/login' action with OIDC and configuring a federated identity credential in Microsoft Entra ID allows GitHub Actions to authenticate to Azure without storing any secrets. The federated credential establishes a trust relationship between GitHub's OIDC provider and an Azure AD app registration, so the workflow can obtain a short-lived token. This eliminates the need for a publish profile secret, improving security by removing long-lived credentials.

Exam trap

AZ-400 often tests the misconception that managed identities can be used directly from GitHub runners, but they are only available to Azure resources. The correct approach is to use OIDC with federated credentials.

How to eliminate wrong answers

Option A is wrong because Azure AD Managed Identity is not directly available to GitHub-hosted runners; it requires an Azure-hosted compute resource. Option C is wrong because storing a service principal secret as a GitHub secret still involves a long-lived credential, which OIDC aims to eliminate. Option D is wrong because setting the Publish Profile parameter to an empty string would break the deployment, not enable OIDC authentication.

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

A canary deployment with automated health checks and automatic rollback is the correct choice because it incrementally routes a small percentage of production traffic to the new release, say 5%, then gradually increases it only if health checks pass. Automated checks monitor key signal like HTTP 5xx error rate, request latency, and custom application health endpoints, and if a threshold is breached, the release pipeline automatically reverts the routing to the previous stable version. This catches misconfigurations and regressions early with a minimal blast radius, preventing full-scale downtime. Unlike blue-green or a staged test deploy, it validates against real production load and configuration while keeping the majority of users on the safe version.

Why this answer

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

Requiring multi-factor authentication (MFA) ensures users prove their identity via a second factor, and Conditional Access policies enforce context-aware conditions such as device compliance, sign-in risk, and location for Azure DevOps resources. This combined approach mitigates credential theft and provides adaptive, secure access controls directly integrated with Microsoft Entra ID.

Why this answer

Requiring MFA and enabling Conditional Access policies is the most secure way to manage access because it enforces strong authentication and context-aware access controls. Conditional Access can evaluate user, device, location, and risk to grant or block access, and MFA adds a critical layer beyond passwords. This combination aligns with Microsoft's Zero Trust model and is recommended for Azure DevOps access.

Exam trap

The trap is thinking that network-level restrictions (IP restrictions) or simple MFA alone are sufficient, but the most secure approach combines MFA with Conditional Access for adaptive, context-aware security.

How to eliminate wrong answers

Option B is wrong because disabling external user access does not secure internal accounts and may not be feasible for collaboration. Option C is wrong because IP restrictions alone can be bypassed and do not protect against compromised credentials. Option D is wrong because assigning Basic access level does not enforce authentication strength or conditional policies; it only controls feature access.

Full explanation →
637
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 your Microsoft Entra ID tenant is the prerequisite that makes conditional access policies effective for Azure DevOps sign-ins. Once linked, Azure DevOps delegates authentication and authorization to Microsoft Entra ID, so conditional access policies you configure in Microsoft Entra ID — such as MFA, device compliance, or location-based restrictions — are evaluated during the interactive sign-in and token issuance flow. This applies organization-wide and covers all users who authenticate through the linked tenant, enforcing policy before users can access Azure DevOps resources.

Why this answer

To govern access to Azure DevOps projects with conditional access policies, you must link the Azure DevOps organization to the Microsoft Entra ID tenant. This integration makes Azure DevOps a registered application within the tenant, allowing conditional access policies (e.g., MFA, device compliance, location-based access) to be evaluated during authentication. Only then can the compliance team enforce organization-wide access rules via Microsoft Entra ID.

Exam trap

The trap here is that candidates confuse service hooks or OAuth tokens with identity governance features, not realizing that conditional access requires the resource to be a first-party or registered application in Microsoft Entra ID, not just any authentication method.

How to eliminate wrong answers

Option B is wrong because service hooks are used for integrating external services (e.g., Slack, Jenkins) via event-driven notifications, not for enforcing authentication or conditional access policies. Option C is wrong because managed identities are designed for Azure resources (e.g., VMs, Functions) to authenticate to Azure services without storing credentials, not for user-level conditional access enforcement. Option D is wrong because OAuth tokens are an authentication mechanism for granting delegated access to APIs; they do not by themselves enforce conditional access policies, which require the resource (Azure DevOps) to be integrated with Microsoft Entra ID as a relying party.

Full explanation →
638
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 →
639
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

Because all code resides in a single repository, projects can directly import shared libraries without separately publishing and versioning them. This enables large-scale refactoring, such as changing an API signature, to be done in one atomic change that immediately affects all consuming projects, greatly simplifying coordination.

Why this answer

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 →
640
MCQmedium

Your team uses an Azure Pipelines YAML build pipeline to compile a .NET solution. The pipeline is defined in a repository named 'ContosoApp'. You need to ensure that the build runs only when changes are pushed to the 'main' branch, and that it does not run for any other branch. Which trigger configuration should you use?

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

This configuration uses the trigger block with branches.include set to main, which is the correct YAML syntax to limit CI triggers to the main branch. It ensures the pipeline runs only when changes are pushed to main, satisfying the requirement. Other branches are excluded by default because only main is included.

Why this answer

The trigger block with branches.include is the standard way to specify which branches trigger a YAML pipeline. Including only main ensures the pipeline runs exclusively for pushes to main, meeting the requirement. The other options either exclude main, configure PR triggers, or misuse path filters.

Exam trap

The trap here is confusing branch filters with path filters, or mixing up CI triggers with PR triggers, leading to incorrect YAML syntax.

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

Setting the project visibility to 'Private' in Azure DevOps is the definitive project-level setting that requires all users to authenticate before viewing any project data, including wikis, repos, boards, and pipelines. This ensures that anonymous users are completely barred from accessing Azure DevOps content, as private projects only allow authenticated members or explicitly added external users.

Why this answer

Setting the project visibility to 'Private' ensures that only authenticated users who are members of the Azure DevOps organization can access the project and its wikis. Anonymous or unauthenticated users are blocked entirely at the project level, which directly satisfies the requirement to restrict wiki viewing to signed-in users only.

Exam trap

The trap here is that candidates often confuse repository-level visibility with project-level visibility, assuming that setting a repo to private will also secure the wiki, when in fact the wiki is a project-level artifact and its access is governed by the project's visibility setting.

How to eliminate wrong answers

Option A is wrong because Azure DevOps wikis do not have a separate 'deny anonymous users' permission; anonymous access is controlled at the project visibility level, not through granular wiki permissions. Option C is wrong because repository visibility settings control access to the underlying Git repository, not the wiki itself; project wikis are provisioned as a separate service and are governed by project-level visibility. Option D is wrong because Microsoft Entra ID Application Proxy is used for publishing on-premises web applications externally, not for controlling access to Azure DevOps wikis.

Full explanation →
642
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 let you preinstall bespoke toolchains, SDKs and agents directly on the runner machine, so jobs needing software absent from GitHub-hosted images execute without per-run setup steps. This satisfies the custom-software constraint, unlike GitHub-hosted runners whose images are fixed and cannot be modified.

Why this answer

Option A is correct because self-hosted runners are machines you provision and manage yourself, so you can preinstall any custom software, tools, or dependencies your workflows require rather than being limited to the GitHub-hosted runner image. Option D is correct because the self-hosted runner application supports Windows, Linux, and macOS operating systems, letting you register runners on any of these platforms. Option E is correct because self-hosted runners can be deployed inside your own network (for example on-premises or in a private VPC), giving workflows direct access to internal resources such as databases, file shares, and internal APIs that GitHub-hosted runners cannot reach.

Option B is not correct because GitHub does not autoscale self-hosted runners; scaling must be implemented by you, for example with the Actions Runner Controller or autoscaling groups. Option C is not correct because while GitHub does not charge for self-hosted runner usage, you still pay for the underlying compute, storage, and network infrastructure you provide.

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 →
643
MCQhard

You are an Azure DevOps engineer at a software company that uses a single Azure Repos Git repository for a product with two independent release trains: a web front end and a backend API. You need to enforce that pull requests targeting the release branch for each train require approval from a different set of reviewers, and you must be able to report on policy compliance separately for each train. What should you configure?

A.Enable required reviewers on each release branch individually using the branch name, and assign the appropriate reviewer group to each policy.
B.Configure a single required reviewer policy on the main branch and rely on branch hierarchy inheritance to apply it to the release branches.
C.Create a path-based required reviewer policy on the folders that contain the web and API source code.
D.Create a branch policy on the release/* wildcard path with a required reviewer group that contains all reviewers for both trains.
AnswerA

Configuring a separate required-reviewer policy on each specific release branch lets you attach the correct reviewer group to the web train and a different group to the API train. Because each branch has its own policy object, Azure DevOps reports policy status and compliance independently for each branch, satisfying both the approval and reporting requirements without affecting unrelated branches.

Why this answer

Separate required-reviewer policies on each specific release branch allow different reviewer groups to be assigned to the web and API trains while keeping policy status and compliance reporting distinct per branch. Wildcard policies, path-based policies, and main-branch policies all fail to scope the approval requirement to each release train independently.

Exam trap

The trap here is assuming that a wildcard branch policy on release/* or a path-based policy can enforce different reviewer groups per branch, when only per-branch policies provide that separation.

Full explanation →
644
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 automatically start a pipeline when a pull request is created, updated, or reopened against a target branch, evaluating the merged result of the source and target branches. In Azure Pipelines, a PR trigger is the correct event type to validate changes before merging, and it can be configured specifically for individual or multiple branches, unlike CI triggers which only fire on direct pushes.

Why this answer

A PR trigger is the correct choice because it specifically initiates a pipeline when a pull request is created or updated against a target branch (main). This allows the pipeline to run validations (e.g., builds, tests, linting) and report the status back to the PR via the Azure Repos status API, enabling branch protection policies to block merging if checks fail.

Exam trap

The trap here is that candidates often confuse CI triggers (which run on branch pushes) with PR triggers (which run on pull request events), especially when they see 'trigger on main branch' and incorrectly assume a CI trigger will handle PR validation.

How to eliminate wrong answers

Option A is wrong because a path filter is not a trigger type; it is a configuration option used within CI or PR triggers to limit execution based on file changes in specific paths. Option B is wrong because a scheduled trigger runs pipelines at predefined times (e.g., nightly builds) and does not respond to pull request events. Option D is wrong because a CI trigger runs when code is pushed to a branch (e.g., main), not when a PR is created; it does not automatically report status to a PR and is intended for continuous integration on commits.

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

Requiring work item linking in the branch policy is correct because it enforces that every pull request must have at least one linked work item before it can be completed. This creates an auditable trace from code changes back to the original requirement or task in Azure Boards.

Why this answer

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

Enabling CI with a branch filter for 'develop' ensures the pipeline is triggered automatically on every push to the develop branch, while ignoring pushes to other branches. This provides immediate build validation for changes integrated into the mainline, aligning exactly with the requirement of building on direct pushes to develop.

Why this answer

Enabling a CI trigger with a branch filter for 'develop' ensures that the pipeline automatically runs linting, unit tests, and build steps only when changes are pushed to the 'develop' branch. This matches the requirement precisely, as CI triggers respond to push events, and the branch filter restricts execution to the specified branch.

Exam trap

The trap here is that candidates often confuse CI triggers with pull request triggers, mistakenly thinking a CI trigger without branch filters is sufficient, but the branch filter is essential to restrict execution to a specific branch.

How to eliminate wrong answers

Option A is wrong because pull request triggers run when a PR is created or updated, not when changes are pushed directly to a branch; this would not satisfy the requirement to run on pushes to 'develop'. Option B is wrong because scheduled triggers run at specified times regardless of code changes, which does not align with the requirement to trigger only on pushes. Option C is wrong because enabling a CI trigger without branch filters would cause the pipeline to run on pushes to any branch, including feature branches, not just 'develop'.

Full explanation →
647
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 provide a server-enforced compliance gate on pull requests targeting the main branch. You can configure a policy to require a minimum number of reviewers, enforce build validation by running a pipeline, and mandate linked work items. These policies block direct pushes to the main branch and prevent pull request completion until every defined criterion is satisfied, making them an authoritative mechanism for code review and build quality gates.

Why this answer

Azure Repos branch policies allow you to enforce required pull requests, minimum number of reviewers (e.g., two approvals), and status checks (e.g., no failing checks) on the main branch. This ensures that all code changes to the protected branch comply with the defined quality and security gates before merging.

Exam trap

The trap here is that candidates confuse environment protection rules (used for deployment approvals in release pipelines) with branch policies (used for source code merge requirements in Azure Repos), leading them to select Option B instead of C.

How to eliminate wrong answers

Option A is wrong because Conditional Access policies in Microsoft Entra ID control authentication and access to applications (e.g., requiring MFA or device compliance), not code review or merge requirements within Azure Repos. Option B is wrong because environment protection rules in Azure Pipelines govern deployment approvals and checks for release pipelines (e.g., manual approval before deploying to production), not source control branch policies for pull requests. Option D is wrong because service hooks are used to trigger external events (e.g., sending notifications to Slack or triggering a webhook) when a push occurs, but they do not enforce approval or check requirements on pull requests.

Full explanation →
648
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 is a specialized bridge that clones a TFVC repository into a local Git repository while preserving the full history of changesets, branches, and merges. It is designed for large TFVC repos, and after cloning, you can push the Git repository to Azure Repos, making it the correct migration path.

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

A rollback strategy is essential because even with thorough testing in lower environments, production failures can still occur; a well-defined process to revert to the last known good artifact, whether through redeployment or automated restore, minimizes mean time to recovery (MTTR) and reduces customer impact.

Why this answer

A release pipeline for a critical production application must include a rollback strategy (e.g., deployment slots or redeploying a previous artifact) to recover quickly from failed releases, deployment health monitoring (e.g., Application Insights, Azure Monitor) to detect issues early and trigger rollbacks or alerts, and approval gates before production deployment to ensure manual or automated checks are passed. These three factors together minimize downtime and ensure controlled, safe releases.

Exam trap

The trap here is that candidates confuse security best practices (like service principal least privilege) with release pipeline design factors, or they mistakenly think a single environment is acceptable for critical apps, ignoring the necessity of staging and rollback capabilities.

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

Using Build.BuildId (or another unique identifier) as the image tag makes each build's image reference immutable and traceable, and when you inject that same tag into the Kubernetes manifest during variable substitution, the deployment is guaranteed to pull the exact artifact produced by the current pipeline run. This eliminates tag-mutation races and provides clear auditability.

Why this answer

Using a unique tag like Build.BuildId ensures that the exact image built in the pipeline is referenced in the Kubernetes manifest. This prevents deployment from accidentally using a stale or overwritten image, as the tag is unique per run and passed consistently via variable substitution from the Docker build to the deployment YAML.

Exam trap

The trap here is that candidates often choose the 'latest' tag (Option D) because it seems simpler, but they overlook that 'latest' is mutable and can cause deployment of a different image than the one built in the same pipeline run.

How to eliminate wrong answers

Option A is wrong because using two separate pipelines with a variable group introduces a race condition and does not guarantee that the deploy pipeline uses the exact image from the same build run; the variable group could be overwritten by another run. Option B is wrong because relying on ACR's internal pull-through cache does not enforce image identity; it only caches layers and does not tie the deployment to the specific build output. Option D is wrong because tagging the image as 'latest' is mutable and can be overwritten by subsequent builds, leading to deployment of a different image than the one built in the same pipeline run.

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

A pre-deployment approval gate is configured directly on the Prod environment in Azure Pipelines, and it forces the pipeline to pause before the deployment job to that environment begins. Designated approvers must explicitly approve the release, which provides a formal, auditable sign-off that blocks the Prod stage from starting until the required approval is granted.

Why this answer

In Azure Pipelines, environment-level checks such as pre-deployment approvals are the correct mechanism to gate a stage on human authorization. Approvals configured on the Prod environment (or on a service connection) block the deployment until an approver signs off, and the stage's dependency on Test ensures it only runs after Test succeeds. This combines the two required conditions — Test success and manual approval — declaratively.

Exam trap

AZ-400 often tests the confusion between task-level manual intervention and environment-level approval gates, tempting candidates to pick a manual intervention task when the requirement is a governed, dependency-aware approval on the target environment.

How to eliminate wrong answers

Option A is wrong because a manual intervention task inside the pipeline pauses execution but does not by itself enforce that Test succeeded first, and it is a task-level rather than environment-level control, making it harder to govern across pipelines. Option B is wrong because conditions on a stage cannot natively prompt a human for approval; conditions evaluate expressions, not interactive sign-off, so a 'manual intervention variable' is not a real approval mechanism. Option C is wrong because scheduling the Prod deployment and requiring a manual trigger does not guarantee Test succeeded — a schedule is time-based, not dependency-based, and a manual trigger bypasses the Test-success requirement.

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

The Azure DevOps Administrator role in Microsoft Entra ID is specifically designed to grant permissions to manage Azure DevOps organizations, including creation. Assigning this role to a security group enables group-based assignment, ensuring that members have the precise privileges needed without overreaching, following the least-privilege model.

Why this answer

The Azure DevOps Administrator role in Microsoft Entra ID is specifically designed to manage Azure DevOps service-level settings, including the ability to restrict who can create new Azure DevOps organizations. By assigning this role to a security group, only members of that group can create new organizations, which directly meets the requirement.

Exam trap

The trap here is that candidates often confuse Conditional Access policies (which control sign-in and access) with administrative roles (which control resource creation permissions), leading them to select option C instead of the correct role-based option B.

How to eliminate wrong answers

Option A is wrong because the Global Administrator role grants broad administrative access across all Entra ID services, which is excessive and not scoped to Azure DevOps organization creation. Option C is wrong because Conditional Access policies control authentication and access to applications, not the ability to create new Azure DevOps organizations; they cannot restrict organization creation at the Entra ID level. Option D is wrong because Azure DevOps security policies are scoped within an existing organization and cannot control the creation of new organizations at the tenant level.

Full explanation →
653
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's traffic-splitting rules operate at the ingress and sidecar layer, letting you weight traffic by percentage independently of pod replica counts. That satisfies the gradual, monitored shift the canary strategy demands, since rollback is a routing change rather than a redeployment.

Why this answer

A service mesh like Istio provides fine-grained traffic splitting at the network layer, allowing a precise percentage of traffic (e.g., 5%, then 10%, then 50%) to be routed to the canary version while the rest goes to the stable version. Istio's telemetry (via Envoy sidecars) enables real-time error-rate and latency monitoring, so you can automatically or manually roll back if anomalies appear. This is the most controlled, observable approach for canary deployments on AKS.

Exam trap

AZ-400 often tests the distinction between canary and blue/green or rolling deployments, tricking candidates into selecting ingress-level or Kubernetes-native strategies that lack the granular traffic-percentage control and observability a service mesh provides.

How to eliminate wrong answers

Option B is wrong because Application Gateway weighted backend pools operate at the ingress level and lack the per-request telemetry and dynamic traffic-shifting granularity of a service mesh; they also cannot easily perform header-based or user-based routing for canary analysis. Option C is wrong because AKS rolling updates replace pods gradually but do not control the percentage of user traffic hitting the new version — all traffic goes to whatever pods are ready, which is not a true canary. Option D is wrong because staging-to-production VIP swaps are blue/green deployments, not canary; they shift 100% of traffic at once and do not support gradual percentage-based rollout.

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

Branch protection rules with required status checks enforce quality by preventing a pull request from being merged until all specified status checks pass. This directly enforces that CI/CD workflows, including code quality jobs, succeed before changes are accepted into a protected branch.

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

Git LFS replaces large binary files with text pointers in the Git repository, storing the actual file content in a separate remote LFS store. On clone/checkout, pointers are swapped for the real files, which keeps the Git database small and prevents repository bloat.

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

Enabling 'Automatically delete source branches' in the branch policy for the target branch (e.g., main or develop) ensures that whenever a pull request is merged, the source feature branch is deleted automatically. This is a native Azure Repos policy that enforces cleanup without relying on developer action or custom scripts, making it the correct way to enforce branch cleanup in GitFlow.

Why this answer

The 'Automatically delete source branches' policy in Azure Repos branch policies automatically removes a feature branch once its pull request is completed into the target branch (e.g., develop). This directly enforces the GitFlow requirement without manual intervention or pipeline scripting, as it is a native repository-level setting.

Exam trap

The trap here is that candidates may confuse branch retention policies (which are time-based cleanup rules) with the immediate deletion policy on PR completion, or assume a pipeline script is necessary when a built-in repository policy already exists.

How to eliminate wrong answers

Option B is wrong because a post-merge script in the pipeline can delete branches, but it requires custom code, runs only on pipeline execution, and may fail if the pipeline is skipped or the merge happens outside a build (e.g., via the web UI). Option C is wrong because training developers to delete branches manually relies on human compliance, which is unreliable and not an automated enforcement mechanism. Option D is wrong because branch retention policies in Azure Repos control how long branches are kept before automatic cleanup (e.g., after a set number of days), not immediate deletion upon merge to develop.

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

This allows the two-reviewer policy to be applied normally, while still permitting urgent fixes to be merged without two approvals; the override requires a justification and is logged for audit, balancing policy enforcement with operational flexibility.

Why this answer

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

The Helm rollback command is the correct approach because Helm maintains an ordered release history for each release name, with every deployment sequence stored as an immutable revision that includes the rendered manifests, values, and metadata. Executing `helm rollback <RELEASE> <REVISION>` instructs Helm to perform an in-place upgrade using the exact templates and values from that prior revision, thereby reinstating the known-good configuration atomically and quickly. This operation is fully tracked by Helm, incrementing to a new revision, so the release state and history remain internally consistent for subsequent upgrades or further rollbacks. Unlike manual redeployments or kubectl-level actions, Helm rollback does not require reconstructing old charts or reconciling drift—it simply reapplies the previously successful applied state.

Why this answer

Helm provides a built-in `helm rollback <release> <revision>` command that reverts a release to a previous revision in a single, atomic operation. This is the fastest and most reliable method for rolling back a failed Helm-based deployment on AKS, as it directly restores the exact Kubernetes manifests and configuration from the specified revision without manual intervention.

Exam trap

The trap here is that candidates confuse Kubernetes-native rollback (`kubectl rollout undo`) with Helm's release-level rollback, forgetting that Helm manages releases as a unit and that using `kubectl` directly breaks Helm's revision history and can leave the release in a broken state.

How to eliminate wrong answers

Option A is wrong because manually redeploying the previous Helm chart version is error-prone, slow, and requires the operator to locate and re-run the exact previous chart and values, which defeats the purpose of a quick rollback. Option B is wrong because a canary deployment strategy is a progressive delivery technique used to test a new release with a subset of traffic before full rollout, not a rollback mechanism; it does not revert a failed release but rather mitigates risk during rollout. Option D is wrong because `kubectl rollout undo` works on a Kubernetes Deployment object directly, but when using Helm, the Deployment is managed as part of a Helm release; using `kubectl rollout undo` bypasses Helm's release tracking, leading to state inconsistency between the Helm release history and the actual cluster state.

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

Allocating more parallel jobs to the self-hosted agent pool increases the maximum number of pipeline runs that can execute concurrently on that pool. Each parallel job consumes one agent slot; with additional parallel job capacity, more builds or releases can run at the same time, directly addressing a bottleneck caused by concurrency limits.

Why this answer

Allocating more parallel jobs to the self-hosted agent pool allows multiple pipelines or jobs to run concurrently, directly reducing queue times. This is achieved by adjusting the parallelism setting in the agent pool's properties, which does not incur additional costs as you are already paying for the self-hosted infrastructure.

Exam trap

The trap here is that candidates often confuse improving individual job performance (faster agents or fewer steps) with increasing parallelism. If the pool has idle agents but the parallelism limit is set too low, increasing the limit is a free way to reduce queue times. However, if the pool is actually saturated (all agents busy), increasing the parallelism setting alone will not help; you would need to add agents or optimize the pipeline.

How to eliminate wrong answers

Option B is wrong because reducing the number of steps in the pipeline may slightly decrease the duration of each build, but it does not address the root cause of queuing—insufficient concurrent execution capacity. Option C is wrong because increasing the agent specification (e.g., from DS2 to DS4) improves the speed of individual job execution but does not increase the number of jobs that can run simultaneously, so queue times remain unchanged. Option D is wrong because switching to Microsoft-hosted agents typically incurs additional costs for parallel jobs beyond the free tier, and the question explicitly requires no additional costs.

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

A GitHub Actions workflow with a `pull_request` trigger to `main` is the native, built-in CI/CD solution: it automatically runs any defined test jobs on every PR, and its resulting status checks integrate directly with GitHub’s branch protection and PR UI. This is the correct approach because no external service or custom listener is needed.

Why this answer

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

Setting the Prod trigger to 'After stage' and selecting QA creates a dependency where the Prod deployment is queued only after the QA stage completes successfully, so a QA failure will prevent Prod from starting. Adding a pre-deployment approval on Prod then provides the required human authorization before the actual deployment, ensuring both QA success and an explicit approval gate.

Why this answer

It configures the Prod stage trigger to 'After stage' with QA selected as the preceding stage, ensuring that the release to Prod only starts after QA completes successfully. Adding a pre-deployment approval on Prod then enforces that a manual approval is granted before the deployment actually begins. This combination satisfies both conditions: dependency on QA success and required approval.

Exam trap

The trap here is that candidates often confuse 'After release' (which triggers based on release creation, not stage completion) with 'After stage' (which triggers based on a specific preceding stage's outcome), leading them to pick Option B or A without recognizing the need for explicit stage dependency.

How to eliminate wrong answers

Option A is wrong because setting the trigger on Prod to 'Automatic' would cause Prod to deploy immediately after the release is created, without waiting for QA to succeed, and a post-deployment approval on QA does not gate the Prod deployment. Option B is wrong because 'After release' trigger starts Prod after the release is created, not after QA completes, so it ignores the QA stage outcome. Option C is wrong because 'Manual only' trigger requires a manual start but does not enforce that QA must succeed first; the pre-deployment approval only adds an approval gate without the stage dependency.

Full explanation →
662
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 on the production stage create a formal gate before the stage begins, requiring designated approvers to explicitly authorize the release. This is the correct mechanism because it applies to the entire stage, ensuring no production deployment occurs without human sign-off.

Why this answer

Pre-deployment approvals on the production stage enforce manual sign-off before any deployment to that environment begins. This ensures the release manager must explicitly approve the deployment, meeting the requirement for manual approval on production. Azure DevOps stages support pre-deployment and post-deployment approval gates, with pre-deployment being the correct choice for controlling when a stage starts.

Exam trap

The trap here is confusing a manual intervention task (which pauses within a stage) with a pre-deployment approval (which gates the start of a stage), leading candidates to incorrectly select the task-based option instead of the stage-level approval.

How to eliminate wrong answers

Option B is wrong because a manual intervention task is a step within a stage that pauses execution, but it does not prevent the stage from starting; the release would already have been deployed to the stage before the task runs, which does not satisfy the requirement to gate the production deployment itself. Option C is wrong because post-deployment approvals on the test stage control what happens after test completes, not before production starts; they cannot block the production deployment from beginning. Option D is wrong because a condition on the production stage to check a variable can control stage execution based on a variable value, but it cannot enforce manual human approval; it is an automated check, not a manual approval gate.

Full explanation →
663
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 trigger fires automatically when a pull request targeting the main branch is opened, using the code from the pull request's merge commit rather than the base branch. It is the correct choice for deploying the ARM template proposed in the PR, because it runs as a pre-merge validation and uses the PR's changes.

Why this answer

The `pull_request` trigger with `branches: [main]` and `types: [opened]` ensures the workflow runs only when a pull request targeting the `main` branch is newly opened. This is the correct trigger for the stated requirement. Note that `pull_request` events from forks run with limited permissions and do not have access to repository secrets by default, which is a safety measure.

If secrets are required for deployment, additional configuration such as using `pull_request_target` (with caution) or environment-scoped secrets would be necessary, but the trigger itself remains `pull_request`.

Exam trap

Candidates often confuse `pull_request_target` with `pull_request`. `pull_request_target` runs in the context of the base repository and has access to secrets, but it should be used with extreme caution because it can be exploited via malicious PRs. `pull_request` is the standard, safer trigger for PR events and does not expose secrets to untrusted forks; however, it also does not allow access to secrets for fork PRs without additional mechanisms.

How to eliminate wrong answers

Option B is wrong because `pull_request_target` runs in the context of the base branch (main) with full write permissions and secret access, which is intended for safe handling of PRs from forks but is not the standard trigger for deploying ARM templates on PR open; it also lacks the `types: [opened]` filter, so it would run on all PR events (synchronize, reopened, etc.). Option C is wrong because `workflow_dispatch` requires manual triggering via the GitHub UI or API, not automatic execution when a PR is opened. Option D is wrong because `push: branches: [main]` triggers on direct commits or merges to main, not on pull request creation, so it would deploy after a merge rather than when the PR is opened.

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

Branch protection rules are evaluated during the push, and requiring signed commits causes GitHub to reject any push containing commits without a valid verified signature, thereby enforcing the policy before the commit is accepted. This is a preventive control at the repository level.

Why this answer

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

The GitHub Secret Scanning push protection alert (with push_protection_bypass: false) confirms the push was rejected before any commit landed in the repository, so the PAT never exists in the commit history. Nevertheless, the PAT was transmitted to GitHub in the blocked push payload and should be treated as exposed, so revoking it is the immediate security action. Investigating the alert helps determine who attempted the push, which repo/branch was targeted, and whether the PAT was compromised elsewhere.

Why this answer

When `push_protection_bypass` is `false`, it means the secret was blocked from being pushed by GitHub's push protection feature. The alert indicates the secret was detected and prevented from entering the repository, so the correct action is to revoke the compromised PAT and investigate the incident to prevent future occurrences. Option D correctly identifies that the secret was blocked and prescribes the appropriate remediation steps.

Exam trap

The trap here is confusing `push_protection_bypass` with the secret being pushed successfully; candidates often assume `false` means the secret was allowed through, but it actually means the push was blocked.

How to eliminate wrong answers

Option A is wrong because `push_protection_bypass` is `false`, meaning push protection was NOT bypassed; the secret was blocked, not pushed. Option B is wrong because the secret was not pushed successfully; it was blocked, so rotating the PAT and auditing commit history is unnecessary and misinterprets the alert. Option C is wrong because while the secret was not bypassed, opening a support ticket with GitHub is not the correct action; the PAT should be revoked and the incident investigated, not escalated to support.

Full explanation →
666
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 is the correct answer because Azure Pipelines automatically runs a pipeline when a pull request is created or updated in a branch, allowing validation of proposed changes before merge. It is ideal for verifying code in a feature branch that is the source of a pull request, ensuring the target branch remains stable.

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

Azure DevOps branch policies provide a checkbox called 'Allow bypassing of branch policy' that can be granted to specific security groups, commonly a 'Code Owners' group. If the developer is not a member of that allowed group, the Git server rejects their push with an error like 'Denied by branch policy'. Because the push never reaches the remote, the CI pipeline never triggers, so the developer sees a failed build—rather than a missing 'Contribute' right or a pipeline service principal issue.

Why this answer

The branch policy requires membership in the 'Code Owners' group to push directly to the branch. The developer is not a member, so they get 'Access denied'. Option A (invalid characters) would cause a different error.

Option B (pipeline service principal lacking permission) is unrelated to the developer's push. Option C (lacking 'Contribute' permissions at project level) is less specific and would result in a different error; the error here is specifically due to branch policy enforcement.

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

Adding custom fields to work item types is essential because it enables teams to capture, query, and report on project-specific data that is not covered by the default system fields, supporting more tailored workflow and metrics.

Why this answer

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

A pull request trigger automatically runs a pipeline whenever a pull request is created, updated, or reopened against the target branch, enabling validation of the proposed changes before merge. This directly matches the requirement to run a pipeline whenever a PR is created, making it the correct choice.

Why this answer

Azure Pipelines provides a dedicated pull request trigger that automatically starts a pipeline when a pull request is created or updated in GitHub. This trigger validates proposed changes before merging, ensuring code quality and preventing broken builds from entering the main branch.

Exam trap

The trap here is that candidates often confuse the continuous integration trigger (which runs on branch pushes) with the pull request trigger, failing to recognize that CI triggers do not activate on pull request creation events unless the PR branch is also pushed to, which is not the same as the PR event itself.

How to eliminate wrong answers

Option A is wrong because a pipeline completion trigger starts a pipeline when another pipeline finishes, not in response to a GitHub pull request event. Option B is wrong because a scheduled trigger runs pipelines at specified times (e.g., nightly builds) and cannot react to real-time pull request creation. Option D is wrong because a continuous integration trigger runs on pushes to branches (e.g., main or feature branches), not specifically on pull request creation; it would run on every commit push, not just when a PR is opened.

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

Because all code lives in a single repository, projects can share internal libraries and components directly without needing to publish and consume separate packages from an external registry. This enables immediate reuse and atomic, cross-project changes in the same commit, which simplifies refactoring and speeds up development.

Why this answer

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 →
671
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 one immutable build artifact through dev, test and prod guarantees identical binaries reach every environment, satisfying the same-artifact constraint. Rebuilding per environment would introduce drift, so a single build feeding staged deployments with approval gates is correct.

Why this answer

Promoting the same build artifact through each environment ensures consistency and traceability. In Azure Pipelines, a single build produces one immutable artifact; deploying that same artifact across dev, test, and prod eliminates the risk of environment-specific build variations. Approval gates between stages control the promotion, while the artifact remains unchanged.

Exam trap

The trap here is that candidates confuse environment-specific configuration (which is handled by variable groups or pipeline variables) with the need for separate build artifacts, leading them to incorrectly select options that create multiple builds instead of promoting a single artifact.

How to eliminate wrong answers

Option A is wrong because using a separate artifact for each stage breaks the principle of deploying the same build across environments, introducing potential inconsistencies and making it impossible to guarantee that the exact same bits reach production. Option B is wrong because creating a separate build pipeline for each environment defeats the purpose of a unified release pipeline; it forces rebuilding for each environment, which can introduce different compilation results or dependency versions. Option C is wrong because triggering a new build for each environment means each environment receives a different artifact, violating the requirement to deploy the same build artifact to all environments.

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

The GitHub + Azure Boards integration automatically links GitHub commits and pull requests to Azure Boards work items when the commit or PR title includes the work item ID (e.g., 'AB#123'). When configured, it can also transition the linked work item to a 'Done' or 'Closed' state upon the merge of the PR, providing the desired automation directly from the merge event without additional pipeline tasks or services.

Why this answer

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 AB#{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 →
673
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

A reusable workflow is a YAML file in another repository that declares `on: workflow_call`, and it is referenced from a calling workflow using `uses: owner/repo/.github/workflows/workflow.yml@ref` where `ref` can be a branch, tag, or SHA. This allows centralized management of CI/CD logic, versioned reuse, and parameterized inputs/secrets across multiple repositories within your organization.

Why this answer

GitHub Actions supports reusable workflows that allow you to define a workflow in a central repository and reference it from other repositories using the 'uses' syntax with the format 'owner/repo/.github/workflows/workflow.yml@ref'. This eliminates code duplication while maintaining a single source of truth for the workflow logic, and the referenced workflow can be triggered by events in the caller repository.

Exam trap

The trap here is that candidates often confuse reusable workflows with composite actions or workflow templates. Reusable workflows allow you to reference a complete workflow (jobs/steps) from a central repository, but they do not define their own triggers; they are invoked via `workflow_call` from a caller workflow.

How to eliminate wrong answers

Option A is wrong because storing a workflow in a shared repository does not enable reuse without duplication; environment secrets only handle credential sharing, not workflow logic reuse, and you would still need to copy the workflow file into each repository. Option C is wrong because a composite action is designed to encapsulate a series of steps (a reusable action), not an entire workflow with triggers, jobs, and steps; it cannot define workflow-level events like 'on: push' or 'on: pull_request'. Option D is wrong because a workflow template in the organization's .github repository provides a starting point for new workflows but does not allow referencing an existing workflow from another repository; each repository must still maintain its own copy of the workflow file.

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

By deploying to a staging slot and then performing a swap, you can instantly redirect production traffic to the new version with no downtime, as the swap operation is atomic and warm-up can be handled before the slot receives production traffic.

Why this answer

Deployment slots enable zero-downtime deployments (C) by allowing you to swap a staging slot with the production slot. The swap operation warms up the target slot's application before routing traffic, ensuring no requests are dropped. This is a core feature of Azure App Service for safe, continuous delivery.

Exam trap

The trap here is that candidates confuse the ability to swap slots with automatic rollback (A) or assume slots provide independent scaling (B), when in fact slots share the same plan and rollback requires manual intervention.

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

Creating a service principal with permissions scoped to the minimum required Azure resources enforces least privilege by granting the pipeline identity only the specific RBAC roles needed on targeted resource groups or services, preventing over-permissioning and reducing the attack surface if credentials are compromised.

Why this answer

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

Page 9 of 10

Page 10

All pages

12345678910

Practice AZ-400 by domain

Target a specific domain to shore up weak areas.

Design and implement source controlConfigure processes and communicationsDevelop a security and compliance planImplement an instrumentation strategyDesign and implement build and release pipelinesDesign and implement a source control strategy
See all domains with question counts →