View Full Microsoft AZ-400 Exam Dumps and Practice Test Dumps

 

Q201. Which Azure DevOps feature can require comments on a pull request to be resolved before the pull request is completed?

1) Branch policy
2) Artifact feed
3) Pipeline cache
4) Agent pool

Correct Answer: 1)

Explanation:

Branch policies provide controls that help maintain code quality and enforce organizational requirements before changes are merged into protected branches. One available policy can require pull-request comments to be resolved before completion. This ensures that important review feedback is addressed rather than being ignored when the pull request is merged. Artifact feeds manage packages, pipeline caching improves build performance, and agent pools provide execution resources. By configuring appropriate branch policies, teams can establish consistent review practices and reduce the chance that unresolved issues or reviewer concerns are carried into the main development branch.

Q202. A company wants to require that pull requests include links to relevant Azure Boards work items. Which branch policy should be considered?

1) Build retention policy
2) Linked work items policy
3) Artifact retention policy
4) Agent demand policy

Correct Answer: 2)

Explanation:

A linked work items branch policy helps organizations maintain traceability between code changes and planned work. When enabled, the policy can require pull requests to be associated with relevant work items before they can be completed. This allows teams to understand why a change was made and connect development activity with requirements, bugs, or other tracked work. Build retention controls how long build outputs are stored, artifact retention manages published artifacts, and agent demands determine which agents can run specific jobs. Therefore, linked work items are the appropriate policy for improving development traceability.

Q203. Which pull-request feature allows a team to automatically complete a pull request once all required policies and approvals have been satisfied?

1) Auto-complete
2) Pipeline caching
3) Release gate
4) Artifact promotion

Correct Answer: 1)

Explanation:

Pull-request auto-complete allows Azure Repos to complete a pull request automatically after all required conditions are satisfied. These conditions can include required reviewers, successful builds, branch policies, and other configured requirements. This can reduce manual effort and help developers merge approved changes promptly. Pipeline caching improves dependency retrieval and build performance, release gates control deployment progression, and artifact promotion moves tested outputs between environments. Auto-complete is therefore the appropriate feature when the team wants an approved pull request to be completed automatically after its required validation checks succeed.

Q204. A development team wants to ensure that only changes that successfully pass an automated build can be merged into the main branch. Which configuration should be used?

1) Variable group
2) Build validation branch policy
3) Service connection
4) Artifact feed

Correct Answer: 2)

Explanation:

A build validation branch policy can require a pull request to pass a specified build before it can be completed. This provides an automated quality control mechanism for protected branches and helps prevent code that fails compilation, automated tests, or other validation steps from being merged. Variable groups store shared configuration values, service connections provide authenticated access to external resources, and artifact feeds manage packages. Build validation is therefore the appropriate choice when successful automated builds must be a prerequisite for merging changes into an important branch.

Q205. Which Git strategy allows developers to incorporate selected commits from one branch into another without merging the entire branch?

1) Git reset
2) Git stash
3) Git cherry-pick
4) Git clone

Correct Answer: 3)

Explanation:

Git cherry-pick allows a developer to apply a specific commit from one branch to another branch without merging all changes from the source branch. This can be useful when a particular bug fix or security correction needs to be applied to a maintenance branch while unrelated development remains separate. Git reset changes branch history or the current state, Git stash temporarily stores uncommitted changes, and Git clone creates a local copy of a repository. Cherry-pick should be used carefully because applying individual commits across branches can create conflicts or duplicate changes if the histories later converge.

Q206. A team wants to keep a production branch protected from direct pushes while allowing approved pull requests. Which Git governance practice is most appropriate?

1) Branch protection policies
2) Local Git stash
3) Pipeline artifacts
4) Package caching

Correct Answer: 1)

Explanation:

Branch protection policies help prevent unauthorized or uncontrolled changes to important branches such as production or main. Teams can configure requirements such as pull requests, minimum reviewers, successful builds, linked work items, comment resolution, and other checks. These controls encourage changes to pass through a consistent review and validation process before they reach protected branches. Git stash is intended for temporarily storing local changes, pipeline artifacts are build outputs, and package caching improves dependency retrieval. Therefore, branch protection policies are the most suitable approach for preventing direct pushes to critical branches.

Q207. A pipeline must deploy the exact same tested package to development, staging, and production. Which strategy best supports this requirement?

1) Rebuild the package separately for each environment
2) Build once and promote the same artifact
3) Modify the package manually before production
4) Build directly on the production server

Correct Answer: 2)

Explanation:

The build-once-and-promote strategy creates an artifact one time and then uses that exact artifact across multiple environments. This improves consistency because the package tested in development or staging is the same package deployed to production. Rebuilding for every environment can introduce differences because dependencies, build tools, or source changes may vary between executions. Manual modifications also reduce traceability and reproducibility. Using a single tested artifact supports stronger release confidence and makes it easier to determine exactly what version was validated and ultimately deployed to production.

Q208. Which Azure Pipelines capability can prevent a deployment stage from running unless a specific condition is satisfied?

1) Pipeline condition
2) Git tag
3) Azure Boards query
4) Package feed

Correct Answer: 1)

Explanation:

Pipeline conditions allow Azure Pipelines to determine whether a job, stage, or step should execute based on specified criteria. Conditions can use information such as the result of previous stages, branch names, variables, or other runtime values. This is useful when organizations need production deployments to occur only after successful validation or when different branches require different deployment behavior. Git tags identify versions, Azure Boards queries retrieve work items, and package feeds store packages. Pipeline conditions therefore provide the appropriate mechanism for controlling execution based on defined requirements.

Q209. Which deployment approach gradually introduces a new application version to a subset of users before expanding the release to everyone?

1) Big-bang deployment
2) Canary deployment
3) Full rebuild
4) Manual deployment

Correct Answer: 2)

Explanation:

A canary deployment releases a new application version to a limited percentage or subset of users before making it broadly available. Teams can monitor application behavior, error rates, performance, and user feedback during the initial rollout. If problems occur, the deployment can be paused or rolled back before affecting the entire user population. This reduces the risk associated with large releases. A big-bang deployment exposes all users at once, while manual deployment describes how deployment is performed rather than providing a controlled rollout strategy. Canary deployment is therefore appropriate for gradual risk-managed releases.

Q210. A team wants to enable or disable a new application feature without redeploying the application. Which technique should be used?

1) Feature flags
2) Git clone
3) Build artifacts
4) Branch deletion

Correct Answer: 1)

Explanation:

Feature flags allow application teams to control the availability of functionality through configuration rather than requiring a new deployment. A feature can be enabled for selected users, environments, or groups and then expanded gradually after the team confirms that it behaves correctly. Feature flags can also provide a quick way to disable problematic functionality without reverting the entire application release. Git clone copies repositories, build artifacts contain compiled outputs, and branch deletion removes a branch. Feature flags are therefore a useful DevOps practice for reducing deployment risk and supporting controlled feature releases.

Q211. Which Azure service is designed to host and manage packages used by Azure DevOps development workflows?

1) Azure Monitor
2) Azure Artifacts
3) Azure Boards
4) Azure Test Plans

Correct Answer: 2)

Explanation:

Azure Artifacts provides package management capabilities for development teams. It can host and manage package types used by applications and pipelines, allowing teams to publish, consume, and control versions of dependencies and internal packages. This supports consistent dependency management across development and CI/CD workflows. Azure Monitor focuses on observability and monitoring, Azure Boards manages work items, and Azure Test Plans supports test management. Azure Artifacts is therefore the appropriate service when a team needs a centralized package feed for dependencies or internally developed packages.

Q212. A team wants a pipeline to retrieve packages from an internal feed while also obtaining approved dependencies from public package sources. Which Azure Artifacts capability can help?

1) Upstream sources
2) Deployment slots
3) Branch policies
4) Agent demands

Correct Answer: 1)

Explanation:

Azure Artifacts upstream sources allow an organization to consume packages from configured external sources through an Azure Artifacts feed. This can simplify dependency management and provide greater control over which packages are consumed by development teams. Instead of allowing every build to contact public package repositories independently, organizations can configure approved upstream sources and use the internal feed as a controlled package access point. Deployment slots manage application versions, branch policies govern source changes, and agent demands control agent selection. Upstream sources are therefore useful for centralized and controlled dependency consumption.

Q213. What is a major advantage of pinning dependency versions in a CI/CD pipeline?

1) It makes dependencies change automatically
2) It improves build reproducibility
3) It removes the need for testing
4) It disables package management

Correct Answer: 2)

Explanation:

Pinning dependency versions means explicitly specifying which versions of libraries or packages a build should use. This improves reproducibility because future pipeline executions are less likely to unexpectedly retrieve newer versions that could introduce breaking changes or behavioral differences. Teams can then update dependencies intentionally, test the changes, and review them through normal development processes. Pinning does not remove the need for testing or package management. Instead, it provides greater control over the dependency environment and makes it easier to investigate differences between builds and deployments.

Q214. Which practice helps identify security vulnerabilities in third-party libraries before they reach production?

1) Dependency scanning
2) Git tagging
3) Work item assignment
4) Pipeline naming

Correct Answer: 1)

Explanation:

Dependency scanning analyzes third-party libraries and packages for known security vulnerabilities or other risks. Integrating this capability into CI/CD allows teams to identify vulnerable dependencies earlier in the software delivery lifecycle. Depending on the configured tool and policies, a pipeline can report vulnerabilities or prevent an artifact from progressing when defined security thresholds are exceeded. Git tagging provides version identification, work item assignment supports planning, and pipeline naming provides organizational structure. Dependency scanning is therefore an important DevSecOps practice for identifying risks in external packages before deployment.

Q215. Which security testing technique analyzes application source code for potential vulnerabilities without executing the application?

1) Load testing
2) Dynamic application testing
3) Static application security testing
4) Availability testing

Correct Answer: 3)

Explanation:

Static Application Security Testing, or SAST, examines source code or compiled code to identify potential security weaknesses without requiring the application to execute normally. It can detect issues such as insecure coding patterns, injection risks, or other vulnerabilities depending on the analysis tool. Dynamic testing instead evaluates an application while it is running. Load testing measures behavior under increased traffic, while availability testing checks whether services remain reachable. SAST is therefore especially useful as an early security control because it can identify potential vulnerabilities during the development and CI stages.

Q216. A pipeline needs to prevent a release from continuing when required security or quality criteria are not satisfied. Which concept is most appropriate?

1) Quality gate
2) Git clone
3) Repository archive
4) Package download

Correct Answer: 1)

Explanation:

A quality gate defines conditions that must be satisfied before software can proceed to a later stage of the delivery process. Quality gates can incorporate measures such as test results, code coverage, security findings, vulnerability thresholds, or other quality criteria. If the required conditions are not met, the pipeline can stop or prevent promotion to a protected environment. This supports automated quality control and helps prevent low-quality or insecure releases from progressing. Git clone, repository archives, and package downloads do not provide this type of release-governance mechanism.

Q217. Which metric measures the average time required to restore a service after a production failure?

1) Deployment frequency
2) Lead time for changes
3) Mean time to restore
4) Code coverage

Correct Answer: 3)

Explanation:

Mean Time to Restore, often abbreviated MTTR, measures the average amount of time required to restore a service after an incident or failure. It is an important DevOps and reliability metric because it indicates how effectively a team can detect, diagnose, and recover from operational problems. Deployment frequency measures how often deployments occur, while lead time for changes measures the time required to move changes from development toward deployment. Code coverage measures how much code is exercised by automated tests. MTTR therefore focuses specifically on recovery performance following service disruptions.

Q218. Which DORA-style metric measures how frequently an organization successfully deploys changes to production?

1) Deployment frequency
2) Mean time to restore
3) Change failure rate
4) Defect density

Correct Answer: 1)

Explanation:

Deployment frequency measures how often an organization successfully delivers changes to a production environment. It is one of the commonly used DevOps delivery performance indicators and can help teams understand their ability to release software regularly. A high deployment frequency does not automatically mean that delivery is effective, so organizations should consider it alongside other measures such as lead time, change failure rate, and recovery time. Mean time to restore focuses on recovery, while change failure rate measures deployments that cause problems requiring remediation. Deployment frequency specifically measures release cadence.

Q219. A team wants to identify where work is waiting too long between development, testing, approval, and deployment. Which practice can help visualize these process bottlenecks?

1) Value stream mapping
2) Git reset
3) Container tagging
4) Package publishing

Correct Answer: 1)

Explanation:

Value stream mapping helps teams visualize the flow of work from an initial request through development, testing, deployment, and delivery. By mapping the process, teams can identify waiting periods, handoffs, bottlenecks, rework, and other sources of delay. This supports continuous improvement by showing where time is being spent and where automation or process changes could provide greater efficiency. Git reset manages repository history, container tagging identifies image versions, and package publishing distributes software packages. Value stream mapping is therefore appropriate when an organization wants to understand and improve its overall software delivery flow.

Q220. A team repeatedly experiences deployment failures caused by changes that were not tested in a production-like environment. Which practice can reduce this risk?

1) Skip staging environments
2) Use a staging environment with automated validation
3) Disable automated testing
4) Deploy directly from developer workstations

Correct Answer: 2)

Explanation:

A staging environment provides a controlled environment where application changes can be validated before production deployment. When staging closely resembles production and includes automated functional, integration, security, or performance checks, teams can identify deployment problems earlier. This reduces the likelihood that configuration differences or untested behavior will reach production. Skipping staging or disabling testing increases release risk, while deploying directly from developer workstations reduces consistency and traceability. Therefore, a production-like staging environment combined with automated validation is an effective practice for improving release confidence and reducing deployment failures.