AZ-400 Practice Test 1 — 10 Questions

Question 1

A team uses Git-LFS to store large binary files. They observe that cloning the repository takes a long time because Git-LFS files are downloaded. How can they improve clone performance?

Accepted Answer

Use the --filter=blob:none option when cloning. The `--filter=blob:none` option performs a partial clone, which omits all blob objects (including Git-LFS pointer files and other large blobs) from the initial download. This significantly reduces clone time by only fetching commit and tree metadata, and then lazily downloading blobs on demand when they are actually accessed. For Git-LFS specifically, this avoids downloading the large binary files stored in LFS until they are needed, improving clone performance.

Answer

Use a shallow clone with depth 1

Answer

Use sparse checkout to limit files in working directory

Answer

Configure git lfs prune to run automatically

Question 2

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?

Accepted Answer

PR trigger. 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.

Answer

Scheduled trigger

Answer

CI trigger

Answer

Manual trigger

Question 3

Your release pipeline deploys to multiple environments (dev, test, prod). You need to ensure that only authorized users can approve production deployments. Which TWO actions should you take?

Accepted Answer

Add a 'Approval' check on the production environment.. The correct actions to ensure only authorized users can approve production deployments are to add an 'Approval' check on the production environment (option D) and to add a pre-deployment approval to the production stage (option E). Both methods require explicit user approval before deployment proceeds. Option A is incorrect because a manual intervention task pauses the pipeline for interactive validation but does not enforce user authorization checks; it is typically used for prompts, not approval gates. Option B is incorrect because environment permissions control who can create releases or manage environments, not who can approve deployments to production—they manage access at a higher level. Option C is incorrect because deployment gates are automated health checks (e.g., monitoring metrics) that can block deployment based on conditions, but they do not handle user approval; approval is a separate check type.

Answer

Use a manual intervention task in the pipeline.

Answer

Set environment permissions to allow only specific users to create releases.

Answer

Configure deployment gates to check for user approval.

Question 4

Your company uses Azure Repos with a Git branching strategy that includes a main branch, a develop branch, and feature branches. You need to enforce that only designated release managers can merge changes from develop into main, while developers can create feature branches off develop and merge pull requests into develop. What is the best way to implement this?

Accepted Answer

Configure branch policies on main to require a minimum number of reviewers from the release manager group, and set the 'Allow users to create pull requests' permission to only include release managers.. By configuring branch policies on the main branch to require a minimum number of reviewers from the release manager group, you ensure that any changes to main are reviewed by designated release managers. Additionally, setting the 'Allow users to create pull requests' permission to only include release managers controls who can initiate pull requests into main. Option B is incorrect because branch protection rules are a GitHub feature, not available in Azure Repos. Option C is incorrect because setting the main branch to read-only would prevent all pushes, including those from release managers, unless they are granted write permissions; however, this approach does not enforce pull request reviews and is less granular. Option D is incorrect because requiring a successful build does not restrict who can merge; it only ensures code quality.

Answer

Use GitHub branch protection rules to require pull request reviews from release managers on main.

Answer

Set the main branch to read-only for all users except release managers using the 'Security' tab in repository settings.

Answer

Require a successful build for all branches and set the build pipeline to only run for release manager commits.

Question 5

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?

Accepted Answer

.github/workflows/ci.yml. GitHub Actions workflows are defined in YAML files stored in the .github/workflows directory. Option A is wrong because a Jenkinsfile is used with Jenkins, not GitHub Actions. Option C is wrong because a Dockerfile is used to build Docker images, not to define CI workflows. Option D is wrong because azure-pipelines.yml is for Azure Pipelines, not GitHub Actions.

Answer

Jenkinsfile

Answer

Dockerfile

Answer

azure-pipelines.yml

Question 6

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?

Accepted Answer

Add a pre-deployment approval gate on the Prod environment.. Pre-deployment approval gates on the Prod environment block the release until manual approval is granted, and a stage condition ensures it runs only after successful Test deployment. Option A is wrong because manual intervention tasks are not designed for approvals and do not integrate with pipeline stages as seamlessly. Option B is wrong because conditions can't enforce manual approval; they only evaluate at runtime. Option C is wrong because scheduling doesn't provide manual approval; triggers can be manual but not combined with stage success conditions effectively.

Answer

Add a manual intervention task before the Prod deployment in the pipeline.

Answer

Use a condition on the Prod stage to require success from Test and manual intervention variable.

Answer

Schedule the Prod deployment to run after Test, and require manual trigger.

Question 7

Your organization uses Microsoft Defender XDR to secure Azure DevOps pipelines. You need to ensure that any build pipeline triggered by a pull request automatically runs a security scan and fails if critical vulnerabilities are found. What should you configure?

Accepted Answer

Branch protection rule with required status check. Branch protection rules in Azure Repos or GitHub can require a status check from a build pipeline. By configuring a required status check that runs a security scan, the pull request cannot be merged if the scan fails. Option A (Code scanning alerts in GitHub) is for identifying vulnerabilities in code, not blocking merges based on pipeline results. Option B (Azure Policy for Pipelines) enforces governance on Azure resources, not pipeline security scans. Option D (Pipeline security gate) is not a feature in Azure DevOps.

Answer

Code scanning alerts in GitHub

Answer

Azure Policy for Pipelines

Answer

Pipeline security gate

Question 8

Which THREE measures should you implement to protect secrets (e.g., API keys, passwords) used in Azure Pipelines?

Accepted Answer

Mark variables as 'Secret' in pipeline YAML or UI definitions. To protect secrets like API keys and passwords in Azure Pipelines, you should implement three key measures. First, mark variables as 'Secret' in pipeline YAML or UI definitions (Option B). This prevents the secret from being displayed in logs or output. Second, use service connections with managed identity instead of personal access tokens (Option D). Managed identities eliminate the need to store credentials and reduce secret exposure. Third, store secrets in Azure Key Vault and reference them via a Key Vault task (Option E). This centralizes secret management and allows fine-grained access control. Option A is incorrect because storing secrets as plain text in a Git repo, even with restricted access, is insecure—secrets should never be committed to source control. Option C is incorrect because environment variables are not encrypted by default and can be exposed in logs or to other pipeline tasks, making them unsafe for secret passing.

Answer

Store secrets as plain text in a secure Git repo with restricted access

Answer

Use environment variables in the pipeline to pass secrets at runtime

Question 9

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?

Accepted Answer

Use a single build pipeline and promote the same build artifact through each environment.. 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.

Answer

Use a multi-stage YAML pipeline with a separate artifact for each stage.

Answer

Create a separate build pipeline for each environment to ensure environment-specific configurations.

Answer

Use a single build pipeline but trigger a new build for each environment.

Question 10

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

Accepted Answer

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

Answer

GitHub Importer

Answer

Azure DevOps Migration Tools

Answer

git-svn