AZ-400 Practice Test 23 — 15 Questions

Question 1

Drag and drop the steps to configure Azure DevOps artifact feeds for NuGet packages into the correct order.

Accepted Answer

Step 1: Create a new feed, Step 2: Configure upstream sources, Step 3: Set feed permissions, Step 4: Publish NuGet packages, Step 5: Consume packages from feed. Feed setup starts with creation, upstream sources, permissions, publishing, and consumption.

Answer

Step 1: Create a new feed, Step 2: Set feed permissions, Step 3: Configure upstream sources, Step 4: Publish NuGet packages, Step 5: Consume packages from feed

Answer

Step 1: Create a new feed, Step 2: Publish NuGet packages, Step 3: Configure upstream sources, Step 4: Set feed permissions, Step 5: Consume packages from feed

Answer

Step 1: Create a new feed, Step 2: Configure upstream sources, Step 3: Publish NuGet packages, Step 4: Set feed permissions, Step 5: Consume packages from feed

Question 2

Your team uses GitHub Actions to build a Python application. The workflow includes a step to run unit tests with pytest. The tests pass locally but fail in CI with 'ModuleNotFoundError: No module named 'myapp''. The repository structure has the application code in a subdirectory 'src/'. What is the most likely fix?

Accepted Answer

Set the environment variable PYTHONPATH to 'src/' before running tests.. The Python interpreter cannot find the 'myapp' module when tests run in CI, even though the code is present in the 'src/' subdirectory. Setting PYTHONPATH to 'src/' tells Python to include that directory in the module search path, allowing 'import myapp' to resolve correctly without moving or copying files. This is the most direct fix for a missing module path issue in a CI environment where the working directory is not automatically set to the source folder.

Answer

Set the working directory of the test step to 'src/'.

Answer

Add a step to install dependencies with 'pip install -r requirements.txt'.

Answer

Add a step to run 'pip install -e .' from the repository root.

Question 3

Which TWO tools can be used to manage feature flags in Azure DevOps pipelines?

Accepted Answer

LaunchDarkly.. LaunchDarkly is a third-party feature management platform that integrates with Azure DevOps pipelines to control feature flag rollouts, targeting, and experimentation. It allows teams to toggle features on/off without redeploying code, making it a valid tool for managing feature flags in pipeline-driven deployments.

Answer

Azure Policy.

Answer

Azure Monitor.

Answer

Azure Key Vault.

Question 4

Which TWO practices should you adopt to improve the security of your Azure DevOps pipeline? (Choose two.)

Accepted Answer

Grant the least privilege to service connections. Granting the least privilege to service connections (Option A) is a core security principle that limits the permissions of automated processes to only what is strictly necessary, reducing the blast radius of a compromised connection. Using Azure Key Vault to store secrets and fetch them at runtime (Option B) ensures that sensitive values like API keys and passwords are never exposed in pipeline definitions or logs, and are securely retrieved via managed identities or service principals at execution time.

Answer

Use the default hosted agent for all builds

Answer

Store secrets as plain text in pipeline variables

Answer

Allow contributors to bypass the required reviewer policy

Question 5

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

Accepted Answer

Enable the 'Automatically delete source branches' policy in the branch policy.. 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.

Answer

Use a post-merge script in the pipeline.

Answer

Train developers to delete branches manually.

Answer

Configure branch retention policies in Azure Repos.

Question 6

You need to ensure that only authorized users can access the Azure DevOps organization. Which identity provider should you configure for single sign-on (SSO)?

Accepted Answer

Microsoft Entra ID. Microsoft Entra ID (formerly Azure AD) is the required identity provider for configuring single sign-on (SSO) for Azure DevOps organizations. Azure DevOps relies on Entra ID to authenticate users and enforce conditional access policies, ensuring only authorized identities from your tenant can sign in. This integration also supports SAML-based SSO and OAuth 2.0 flows, making it the native and only supported IdP for Azure DevOps SSO.

Answer

Google Workspace

Answer

Microsoft account (MSA)

Answer

GitHub ID

Question 7

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?

Accepted Answer

Set minimum number of reviewers to 2, but allow policy override for urgent fixes. 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.

Answer

Set minimum number of reviewers to 1 and require a separate approval from a manager

Answer

Set minimum number of reviewers to 2 and allow resetting code review votes on new pushes

Answer

Configure a build validation policy that checks number of approvals

Question 8

A company uses Azure DevOps to manage code. They want to enforce that all changes to the main branch must go through a pull request with at least two reviewers. What should they configure?

Accepted Answer

Branch policy on the main branch. Branch policies in Azure DevOps allow you to enforce requirements on pull requests targeting a specific branch. By configuring a branch policy on the main branch, you can require a minimum number of reviewers (e.g., two) and mandate that all changes must go through a pull request. This ensures that no direct commits bypass the review process.

Answer

Add a tag to the main branch

Answer

Repository permissions

Answer

Configure a service hook

Question 9

You are designing a compliance strategy for Azure DevOps pipelines that deploy to production. The company policy requires that all production deployments must be reviewed by a security lead. Additionally, the deployment must use a specific release pipeline that has been pre-approved. How should you implement this?

Accepted Answer

Define a 'production' environment in Azure DevOps and configure an approval check that requires the security lead. Have the pipeline deploy to that environment.. Azure DevOps environments allow you to define approval checks that must be satisfied before a deployment proceeds. By creating a 'production' environment and adding a pre-deployment approval check requiring the security lead, you enforce the mandatory review. The pipeline then deploys to that environment, ensuring only the pre-approved release pipeline is used.

Answer

Create a branch policy that requires the security lead to approve the pull request before merging.

Answer

Use a Classic release pipeline with a pre-deployment approval gate for the production stage.

Answer

Store the approved pipeline definition in a variable group and reference it in all pipelines.

Question 10

Your team is using GitHub Flow for a web application. Developers create feature branches from main, make changes, and open pull requests. Recently, several pull requests were merged without required reviews because the branch protection rules were not enforced on the main branch. What should you do to ensure all pull requests to main require at least one reviewer?

Accepted Answer

Enable the 'Require a pull request before merging' rule in branch protection for main, and set 'Required approvals' to 1.. Branch protection rules in GitHub can enforce required pull request reviews before merging. By enabling 'Require a pull request before merging' and setting 'Required approvals' to 1, any pull request to main must have at least one reviewer approve before merging. Option B is incorrect because deleting head branches after merge does not enforce reviews. Option C is incorrect because requiring branches to be up to date is about ensuring the branch is current with the base branch, not about requiring reviews. Option D is incorrect because CODEOWNERS are optional and do not enforce mandatory reviews unless branch protection rules are set accordingly.

Answer

Configure the repository to automatically delete head branches after pull requests are merged.

Answer

Enable the 'Require branches to be up to date' rule in branch protection for main.

Answer

Add a CODEOWNERS file and configure it so that every file has at least one owner.

Question 11

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

Accepted Answer

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

Answer

In the Deploy stage, set 'condition: and(succeeded('Build'), succeeded('Test'))'

Answer

In the Deploy stage, set 'dependsOn: [Build, Test]' and 'condition: stageDependencies.Build.result == 'Succeeded''

Question 12

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?

Accepted Answer

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

Answer

The commit SHA tag is not valid; use 'latest' tag instead.

Answer

The image name is incorrect; verify the registry URL.

Answer

The 'azure/k8s-deploy' action does not support private registries; use a different action.

Question 13

Your team uses Microsoft-hosted agents for builds. Recently, builds are taking longer to start. What is the best way to reduce queue times?

Accepted Answer

Provision self-hosted agents.. Microsoft-hosted agents share a global pool with other Azure DevOps organizations, so queue times increase during peak usage. Provisioning self-hosted agents gives you dedicated compute resources that are always available, eliminating dependency on the shared pool and reducing queue wait times.

Answer

Increase the number of parallel jobs in the organization.

Answer

Use more pipeline triggers.

Answer

Reduce the number of parallel jobs.

Question 14

A team is migrating from TFVC to Git. They have a large codebase with many branches. What is the recommended approach to preserve the history during migration?

Accepted Answer

Use the git-tfs tool to clone the TFVC repository with changesets. Git-tfs is a specialized bridge tool that converts TFVC changesets into Git commits, preserving the full history, author information, and branch structure during migration. Unlike Git-TF, which is deprecated and lacks support for newer TFVC features, git-tfs handles complex scenarios like merges and shelvesets, making it the recommended approach for preserving history when moving from TFVC to Git.

Answer

Copy the latest version of the code to a new Git repository and start fresh

Answer

Use the Git-TF tool to clone the TFVC repository

Answer

Export TFVC as a Git bundle and import with --no-metadata

Question 15

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?

Accepted Answer

Set the trigger on Prod to 'After stage' and select QA as the stage, and add a pre-deployment approval on Prod.. 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.

Answer

Set the trigger on Prod to 'Automatic' and add a post-deployment approval on QA.

Answer

Set the trigger on Prod to 'After release' and add a pre-deployment approval on Prod.

Answer

Set the trigger on Prod to 'Manual only' and add a pre-deployment approval on Prod.