AZ-400 Practice Test 21 — 15 Questions

Question 1

Your team follows trunk-based development. The main branch should always be deployable. Which two practices must you implement? (Choose two.)

Accepted Answer

Use feature flags to manage incomplete work.. In trunk-based development, the main branch must always be deployable. Feature flags (B) allow incomplete or work-in-progress code to be merged into the main branch without affecting production behavior, because the new functionality is toggled off until ready. Keeping branches short-lived (C) (typically less than a day) minimizes merge conflicts and ensures that changes are integrated quickly, reducing the risk of long-lived divergence that could break the main branch.

Answer

Require manual approval for every pull request.

Answer

Create release branches for each deployment.

Answer

Use long-lived feature branches for each feature.

Question 2

You are implementing a build pipeline for a .NET application that uses GitHub Advanced Security (GHAS) for code scanning. The pipeline must run CodeQL analysis on every pull request to the main branch. You have added the CodeQL task to the pipeline. However, the analysis results are not appearing in the 'Security' tab of the repository on GitHub. What is the most likely cause?

Accepted Answer

The pipeline is missing the 'Publish Security Analysis Logs' step to upload SARIF results to GitHub.. CodeQL analysis results are uploaded to GitHub as SARIF files. Without the 'Publish Security Analysis Logs' step (or the equivalent 'upload-sarif' action), the SARIF file generated by CodeQL is not sent to GitHub, so the findings never appear in the Security tab. The pipeline must explicitly include this step to complete the integration with GitHub Advanced Security.

Answer

The GitHub repository is private, so security alerts are disabled.

Answer

The .NET project is not supported by CodeQL.

Answer

CodeQL analysis is not supported on pull request triggers.

Question 3

You are designing a build pipeline for a Java application that uses Maven. You want to publish the compiled JAR file as a build artifact. Which task should you use?

Accepted Answer

PublishBuildArtifacts@1. The Publish Build Artifacts task publishes files as pipeline artifacts. Option B (Maven@3) is wrong because it builds the project but does not publish artifacts. Option C (ArchiveFiles@2) is wrong because it creates a zip but does not publish. Option D (CopyFiles@2) is wrong because it only copies files within the agent.

Answer

Maven@3

Answer

ArchiveFiles@2

Answer

CopyFiles@2

Question 4

You need to integrate Azure Pipelines with GitHub to trigger a build when a release is published in GitHub. Which trigger type should you use in the pipeline?

Accepted Answer

resources:
  repositories:
    - repository: self
      type: github
      trigger:
        release: true. Azure Pipelines supports a GitHub release trigger through the `resources` definition, where you specify a `trigger` with `release: true` under the repository configuration. This tells the pipeline to automatically start a build whenever a new release is published in the linked GitHub repository, which directly matches the requirement.

Answer

pr:

Answer

trigger:

Answer

schedules:

Question 5

Your development team uses GitHub Enterprise and wants to automatically synchronize code from a public GitHub repository to their private repository every morning. What feature should they use?

Accepted Answer

A scheduled GitHub Actions workflow that fetches from the public repo and pushes to the private repo.. B is correct because a scheduled GitHub Actions workflow can periodically fetch changes from the public repository (using `git fetch` or `git pull`) and push them to the private repository. This approach avoids the need for external triggers and works even when the public repo does not send webhooks to your private environment. The schedule is defined using cron syntax in the workflow YAML, ensuring automatic daily synchronization.

Answer

Webhooks from the public repository to trigger a sync pipeline.

Answer

Git submodules to link the public repository as a subdirectory.

Answer

GitHub repository mirroring to automatically mirror the public repo.

Question 6

You are configuring a release pipeline that deploys to multiple environments. You want to automate the deployment to the staging environment only if the build succeeds, and then require manual approval before deploying to production. Which strategy should you use?

Accepted Answer

Define an environment with approvals required for the production stage.. Azure Pipelines allows you to define environments with explicit approval checks. By adding a manual approval gate on the production environment stage, the pipeline will automatically deploy to staging after a successful build, but pause before production until an authorized user approves the release. This directly meets the requirement for automated staging deployment and manual production approval.

Answer

Use deployment gates in the production stage to check for manual intervention.

Answer

Use a classic release pipeline with pre-deployment approvals.

Answer

Configure a branch policy on the main branch to require approval for pull requests.

Question 7

Which TWO features of GitHub Actions can be used to enforce code quality standards before merging?

Accepted Answer

Branch protection rules with required status checks. 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.

Answer

Environments

Answer

Secrets

Answer

Repository variables

Question 8

Your team uses GitHub Actions to build a Docker image and push it to Azure Container Registry (ACR). The workflow fails with the error 'unauthorized: authentication required'. The workflow uses the 'azure/docker-login@v1' action. What is the most likely cause?

Accepted Answer

The service principal used for authentication lacks the AcrPush role on the ACR.. The 'azure/docker-login@v1' action authenticates Docker with Azure Container Registry using a service principal. If the service principal lacks the AcrPush role, Docker login succeeds but the subsequent push fails with 'unauthorized: authentication required' because the identity does not have permission to push images. The error occurs at push time, not login time, which is a key diagnostic clue.

Answer

The 'azure/docker-login@v1' action does not support ACR.

Answer

The Dockerfile is not in the repository root.

Answer

The workflow uses the registry admin credentials, which are disabled.

Question 9

Your company uses GitHub Advanced Security. You need to ensure that all code in the main branch is free of high-severity secrets before deployment. What is the most efficient way to enforce this?

Accepted Answer

Enable secret scanning push protection. Secret scanning push protection (option B) is the most efficient way to enforce that no high-severity secrets reach the main branch because it blocks the push at the Git level before the commit is accepted. This prevents secrets from ever entering the repository, eliminating the need for post-hoc detection or manual review. Other options either rely on reactive detection or do not address secrets in code.

Answer

Require manual review of all pull requests for secrets

Answer

Configure Dependabot to flag secrets in dependencies

Answer

Enable code scanning alerts for secrets

Question 10

Your company uses GitHub Enterprise and wants to implement a secret scanning policy to detect and block secrets (e.g., API keys) in code pushes. The policy must allow exceptions for test repositories that use fake secrets. What is the recommended approach?

Accepted Answer

Configure secret scanning with custom patterns and use the 'secret_scanning_push_protection' setting with an allow-list for test repositories.. GitHub Enterprise's secret scanning push protection can be configured with custom patterns and an allow-list (via the `secret_scanning_push_protection` setting in the repository's security settings or through the API). This allows you to block pushes containing secrets across all repositories while explicitly exempting test repositories that use fake secrets, meeting the requirement for exceptions without manual intervention.

Answer

Use a pre-commit hook to detect secrets and allow developers to bypass it.

Answer

Implement a GitHub Actions workflow that scans for secrets and fails the push.

Answer

Enable secret scanning for all repositories, then manually disable it for test repositories.

Question 11

Your release pipeline uses deployment groups to deploy to Windows servers. You need to securely pass credentials to a script that runs on target machines. What is the recommended approach?

Accepted Answer

Use Azure Key Vault task to fetch secrets during deployment. The Azure Key Vault task securely retrieves secrets (e.g., passwords) from an Azure Key Vault during deployment, avoiding hardcoded or exposed credentials. This integrates with Azure Pipelines to pass secrets to scripts without storing them in the pipeline or on target machines, adhering to least-privilege and secure secret management practices.

Answer

Hardcode credentials in the script and encrypt the script file

Answer

Store credentials as pipeline variables and reference them

Answer

Use environment variables on the target machines

Question 12

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?

Accepted Answer

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

Answer

Use Power BI to visualize Application Insights data and set up data-driven alerts that send emails to the team.

Answer

Configure the release pipeline to output logs to Azure Monitor and use Log Analytics to create work items.

Answer

Use Azure Application Insights to collect user analytics, and manually review dashboards to create work items.

Question 13

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?

Accepted Answer

Git LFS (Large File Storage). 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.

Answer

Shallow clone

Answer

Depth parameter in clone command

Answer

Sparse checkout

Question 14

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

Accepted Answer

Only the Build stage will execute.. 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.

Answer

The pipeline will fail with a syntax error.

Answer

Both stages will execute.

Answer

The Deploy stage will run but skip the steps.

Question 15

Which TWO tasks can be used to run unit tests in an Azure Pipeline?

Accepted Answer

DotNetCoreCLI@2. The DotNetCoreCLI@2 task can run unit tests for .NET Core and .NET 5+ projects by invoking the 'dotnet test' command, which discovers and executes tests in the specified project files. The VSTest@2 task runs unit tests using the Visual Studio Test Runner, supporting a wide range of test frameworks (MSTest, xUnit, NUnit) and can run tests from assemblies or test containers. Both tasks are designed specifically for executing unit tests within an Azure Pipeline, making them the correct choices.

Answer

NuGetCommand@2

Answer

PublishBuildArtifacts@1

Answer

CopyFiles@2