AZ-400 Practice Test 1 — 30 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

Question 11

You are designing a source control strategy for a team that uses GitHub Copilot. The team wants to ensure that code suggestions do not include sensitive data. Which approach should you recommend?

Accepted Answer

Configure content exclusions in GitHub Copilot settings to block sensitive data patterns. GitHub Copilot's content exclusions allow you to define patterns (e.g., regex for API keys, tokens, or PII) that Copilot will block from being used as context for code suggestions. This directly prevents sensitive data from appearing in suggestions without disabling the tool entirely. It is the most targeted and least disruptive approach to meet the team's goal.

Answer

Use pre-commit hooks to scan for secrets

Answer

Disable GitHub Copilot for the organization

Answer

Enable secret scanning for the repository

Question 12

Your Azure Pipelines build takes 45 minutes. You want to reduce build time by caching dependencies. Which task should you add to the pipeline?

Accepted Answer

Cache@2. Cache@2 is the correct task because it allows you to cache dependencies (e.g., npm packages, Maven artifacts) between pipeline runs, significantly reducing build time by avoiding re-downloading unchanged dependencies. This task stores and restores a cache keyed by a hash of the dependency files, enabling incremental builds.

Answer

PublishBuildArtifacts@1

Answer

CopyFiles@2

Answer

DownloadBuildArtifacts@0

Question 13

A team uses Azure Boards to manage work items. They want to automatically update the state of a work item when a related pull request is merged in Azure Repos. Which TWO actions should they configure to enable this integration?

Accepted Answer

Add a branch policy that requires a linked work item for pull requests.. A branch policy that requires linked work items for pull requests ensures that every PR is associated with a work item. When the PR is merged, Azure Repos automatically updates the state of the linked work item (e.g., from 'Active' to 'Resolved') based on the default or configured transition rules. This integration is built into Azure DevOps without requiring external services.

Answer

Set up a webhook in Azure Repos to call Azure Logic Apps on pull request merge.

Answer

Configure a Service Hooks subscription in Azure DevOps to send pull request merge events to Azure Boards.

Answer

Create an Azure Function that listens for pull request merge events and updates work items via the REST API.

Question 14

Refer to the exhibit. You have configured a Conditional Access policy in Microsoft Entra ID to require MFA for Azure DevOps. However, users report that they can still access Azure DevOps without MFA when using a PAT for authentication. What is the most likely reason?

Accepted Answer

PATs are not subject to Conditional Access policies because they use legacy authentication.. B is correct because Personal Access Tokens (PATs) in Azure DevOps are considered legacy authentication tokens. Conditional Access policies in Microsoft Entra ID do not evaluate requests made using legacy authentication protocols, including PATs, OAuth device code flow, or IMAP/POP. Therefore, even if a Conditional Access policy requires MFA for Azure DevOps, users authenticating with a PAT bypass the policy entirely.

Answer

The policy should include 'Require device to be marked as compliant'.

Answer

The policy should be scoped to 'All cloud apps' instead of just Azure DevOps.

Answer

The Conditional Access policy is not enabled.

Question 15

You need to enforce that all builds in Azure Pipelines use a specific version of the .NET SDK. What is the best approach?

Accepted Answer

Add a UseDotNet task to the pipeline that specifies the required SDK version.. The UseDotNet task in Azure Pipelines can be configured to download and install a specific version of the .NET SDK, ensuring that all builds use exactly that version, regardless of what is pre-installed on the agent. Option B is incorrect because setting a pipeline variable DotNetVersion and using it in the DotNetCoreCLI task does not enforce the SDK version; the DotNetCoreCLI task uses the SDK already available on the agent, unless explicitly redirected, and the variable alone does not install or enforce a specific SDK. Option C is incorrect because installing the SDK manually via a script is not a reliable or repeatable approach; it depends on the agent's state and does not automatically enforce the version across different agents or pipeline runs. Option D is incorrect because including a global.json file in the repository does not guarantee that the required SDK version is installed on the agent; the build agent may not respect global.json if the specified SDK is not present, and there is no enforcement mechanism without additional steps.

Answer

Set a pipeline variable DotNetVersion and use it in the DotNetCoreCLI task.

Answer

Install the SDK manually on the build agent using a script.

Answer

Include a global.json file in the repository and rely on the build agent to respect it.

Question 16

A team uses Terraform to manage Azure infrastructure. They want to store the Terraform state file securely and enable collaboration. What is the recommended approach?

Accepted Answer

Store the state file in an Azure Storage account with state locking enabled. Storing the Terraform state file in an Azure Storage account with state locking enabled is the recommended approach because it provides a centralized, durable backend that supports native state locking via Azure Blob Storage leases. This prevents concurrent modifications and state corruption, enabling safe collaboration among team members. Azure Storage also offers encryption at rest and access control via RBAC, aligning with security best practices for infrastructure-as-code.

Answer

Store the state file in a local folder and commit to Git

Answer

Store the state file in Terraform Cloud

Answer

Store the state file in a Git repository with manual locking

Question 17

Your organization uses Azure DevOps for a multi-tier web application. The application consists of a React frontend, a Node.js API, and a SQL database. The security team has mandated the following: (1) All code changes must be scanned for secrets before merging to the main branch. (2) Infrastructure-as-code templates (ARM) must be validated for security compliance before deployment. (3) Production deployments must use a service connection with a managed identity that has only the required permissions. You have set up a CI/CD pipeline with two stages: Build and Release. The Build stage runs on pull requests and the Release stage deploys to a production environment. Recently, a developer accidentally committed a secret (API key) to a configuration file. The secret was not caught by the pipeline, and the code was merged to main. You need to prevent this in the future. What should you do?

Accepted Answer

Add a 'Credential Scanner' task to the Build pipeline and configure it to fail the build if any secrets are found. Also, move all secrets to Azure Key Vault and reference them via variable groups.. It directly addresses the root cause: secrets were not being scanned before merge. The Credential Scanner task (part of Microsoft Security Code Analysis) scans for hardcoded secrets and can fail the build, preventing the merge. Moving secrets to Azure Key Vault and referencing them via variable groups (linked to the vault) ensures secrets are never stored in the repository, eliminating the risk of accidental commits.

Answer

Configure a branch policy to require at least two reviewers on pull requests to the main branch.

Answer

Implement a manual approval gate on the Release stage to review each deployment for secrets.

Answer

Use a pipeline decorator to inject a validation step that runs Azure Policy on the code repository.

Question 18

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

Accepted Answer

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

Answer

Use CODEOWNERS to assign different reviewers for frontend and backend, and rely on manual pipeline triggers.

Answer

Create branch policies that require specific builds based on the branch name.

Answer

Use a single pipeline that runs all tests on every change.

Question 19

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?

Accepted Answer

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.. Configuring OIDC with Microsoft Entra ID (formerly Azure AD) using a federated identity credential for the GitHub environment allows token-based authentication without storing secrets. Option A is incorrect because Azure Managed Identity cannot be used directly from a GitHub runner; Managed Identity is designed for Azure-hosted resources, not external runners. Option C is incorrect because replacing the publish profile secret with a service principal secret still requires storing a secret, which does not improve security compared to OIDC. Option D is incorrect because setting the 'Publish Profile' parameter to an empty string does not enable OIDC authentication; the deployment would fail due to missing credentials.

Answer

Remove the secret and use Azure AD Managed Identity directly from the GitHub runner.

Answer

Replace the publish profile secret with an Azure service principal secret stored as a GitHub secret.

Answer

Use the 'Azure App Service Deploy' task with the 'Publish Profile' parameter set to an empty string.

Question 20

Your team uses GitHub Actions for CI/CD. You need to ensure that secrets stored in GitHub repository secrets are not exposed in build logs. Which security practice should you implement?

Accepted Answer

Use GitHub Actions secrets and ensure they are marked as masked. GitHub Actions automatically masks secret values in build logs when referenced via the secrets context, such as ${{ secrets.SECRET_NAME }}. Option B is wrong because storing secrets in a repository YAML file exposes them to anyone with repo access. Option C is wrong not because environment variables are unsecurely logged, but because it is not the recommended practice; secrets should be referenced directly through the secrets context to avoid risk of unintended exposure (e.g., if the value is modified or used outside GitHub's masking). Option D, while a valid security practice, does not directly address preventing log exposure unless the fetched secrets are also masked.

Answer

Store secrets in a YAML file within the repository

Answer

Pass secrets as environment variables in the workflow

Answer

Use a third-party secret management service and fetch secrets at runtime