AZ-400 Practice Exam 54 — 20 Questions

Question 1

Which TWO actions should you take to ensure that only approved pipelines can deploy to production in Azure DevOps? (Choose two.)

Accepted Answer

Configure a pipeline approval gate on the production environment.. Configuring a pipeline approval gate on the production environment ensures that every deployment to production requires explicit approval from designated reviewers, preventing unauthorized or unapproved pipelines from deploying. Option C is correct because setting branch policies to require a pull request before merging to the main branch enforces code review and validation, ensuring that only approved changes reach the main branch, which is typically the source for production deployments.

Answer

Disable parallel jobs for the project.

Answer

Limit the number of pipelines that can deploy from the main branch.

Answer

Use a single agent pool for all pipelines.

Question 2

You are configuring a branch policy for the main branch using the Azure DevOps REST API. The JSON above is the policy configuration. A developer pushes a new commit to an existing pull request. What happens to the existing approvals?

Accepted Answer

The existing approvals remain valid.. By default, Azure DevOps branch policies do not automatically reset approvals when a new commit is pushed to a pull request. The policy configuration shown includes the 'resetOnPush' property set to false (or it is not enabled), which means existing approvals remain valid even after new commits are pushed. Only if 'resetOnPush' is explicitly set to true would approvals be invalidated.

Answer

The policy blocks the push until re-reviewed.

Answer

The pull request is automatically rejected.

Answer

All existing approvals are reset.

Question 3

Refer to the exhibit. You have this YAML pipeline in an Azure Repos repository. What is the expected behavior when a pull request is created from a feature branch to the main branch?

Accepted Answer

The pipeline does not run automatically on the PR; it must be triggered manually or via branch policy.. The YAML pipeline shown does not include a `pr` trigger, and the `trigger` block only applies to CI (continuous integration) builds on branch pushes, not pull requests. Without a `pr` trigger, Azure Pipelines does not automatically run on pull request creation; it must be triggered manually or via a branch policy configured in the repository settings.

Answer

The pipeline runs twice: once on PR creation and once on merge.

Answer

The pipeline runs automatically on the PR to main, triggered by the pr trigger.

Answer

The pipeline runs when the PR is merged to main, triggered by the trigger block.

Question 4

Which TWO features of Azure Pipelines help you manage build artifacts across stages? (Choose two.)

Accepted Answer

Download Pipeline Artifact task. The Publish Pipeline Artifact task (option E) makes files available to subsequent stages by uploading them to Azure Pipelines, while the Download Pipeline Artifact task (option D) retrieves those artifacts in later stages. Together, they form the primary mechanism for passing build outputs across stages in a pipeline.

Answer

Pipeline variables

Answer

Release gates

Answer

Build tags

Question 5

Your organization uses GitHub Actions and needs to enforce that only approved actions from the GitHub Marketplace can be used in workflows. Developers have been using custom actions from third-party repositories. What is the most effective way to control which actions are allowed?

Accepted Answer

Use the 'Allow actions created by GitHub and verified partners' policy and add specific actions to the allow list.. The 'Allow actions created by GitHub and verified partners' policy, combined with an explicit allow list, provides granular control over which actions can run in workflows. This approach blocks unverified third-party actions by default while permitting specific approved actions from the Marketplace, directly addressing the need to enforce only approved actions without unnecessarily restricting all third-party actions.

Answer

Create a manual approval process for each new action.

Answer

Set the organization to disallow all third-party actions.

Answer

Configure the organization to allow only actions created by GitHub.

Question 6

Your company uses Microsoft Purview to manage data governance. You need to classify a new dataset containing personally identifiable information (PII) and apply a data loss prevention (DLP) policy. What should you do first?

Accepted Answer

Register and scan the data source in Microsoft Purview. To classify a new dataset containing PII and apply a DLP policy, the first step is to register and scan the data source in Microsoft Purview. Scanning automatically discovers and classifies sensitive data using built-in classifiers. Only after classification can you create sensitivity labels (option A) or define a DLP policy (option C). Adding to an Azure service tag (option B) is unrelated to data classification. Therefore, option D is the correct first step.

Answer

Create a sensitivity label in Microsoft Purview

Answer

Add the data source to an Azure service tag

Answer

Define a DLP policy in Microsoft Purview

Question 7

A company is adopting Azure DevOps and needs to ensure that all pipelines comply with regulatory standards. The security team wants to enforce that every build includes a security scan and that deployment to production requires approval from a compliance officer. Which TWO actions should the DevOps engineer take?

Accepted Answer

Create a required template that includes the security scan task and mandate its use via a pipeline resource.. Creating a required template with the security scan task and mandating its use via a pipeline resource ensures every pipeline inherits the security scan. Option D is correct because configuring a required reviewer approval on the production stage enforces compliance officer approval. Options A, C, and E are incorrect: Branch policies (A) only apply to pull requests, not all builds; storing results (C) does not enforce the scan; and while a pipeline decorator (E) can run a scan on every build, it does not enforce the required approval for production deployment.

Answer

Configure branch policies to require a security scan on pull requests.

Answer

Add a variable group to store security scan results and reference it in the pipeline.

Answer

Use a pipeline decorator to automatically run a security scan on every build.

Question 8

You need to configure a release pipeline that deploys to Azure App Service. The deployment should use the 'slot swap' strategy to minimize downtime. Which deployment slot should you initially deploy to?

Accepted Answer

Staging slot. The slot swap strategy in Azure App Service deploys to a non-production slot (typically 'staging') first, allowing validation before swapping with the production slot. This eliminates downtime by warming up the staging slot and then routing traffic to it via a zero-downtime swap operation. Deploying directly to production would cause downtime or require manual traffic management.

Answer

Production slot

Answer

Warmup slot

Answer

All slots simultaneously

Question 9

You need to run a set of tasks only when the build pipeline runs for the main branch. Which condition should you add to the job or step?

Accepted Answer

condition: eq(variables['Build.SourceBranch'], 'refs/heads/main'). The `Build.SourceBranch` variable in Azure Pipelines contains the full Git ref (e.g., `refs/heads/main`). Using `eq(variables['Build.SourceBranch'], 'refs/heads/main')` ensures the condition evaluates to true only when the pipeline runs on the main branch. This is the standard way to filter by branch in YAML pipeline conditions.

Answer

condition: eq(variables['Build.SourceBranch'], 'main')

Answer

condition: and(succeeded(), eq(variables['System.PullRequest.TargetBranch'], 'main'))

Answer

condition: ne(variables['Build.Reason'], 'PullRequest')

Question 10

Your organization uses GitHub for source control and Azure Pipelines for CI/CD. You need to implement a policy that requires all pull requests to be built and pass tests before merging. What should you do?

Accepted Answer

Add a branch protection rule in the GitHub repository requiring status checks.. GitHub branch protection rules allow you to require status checks to pass before merging a pull request. By configuring a rule that requires the Azure Pipelines build and test status check to succeed, you enforce that all pull requests are validated before they can be merged into the protected branch.

Answer

Set the pipeline trigger to run on pull request.

Answer

Configure pipeline permissions to require approval.

Answer

Add a pre-deployment check on the environment.

Question 11

Your team uses GitHub for source control. You need to ensure that sensitive data, such as connection strings, is never committed to the repository. Which tool should you use?

Accepted Answer

GitHub secret scanning. GitHub secret scanning automatically detects sensitive data like connection strings, API keys, and tokens as they are pushed to a repository, preventing them from being committed. It scans for known patterns and can block the push or alert the repository administrator, making it the correct tool for this requirement.

Answer

GitHub Actions

Answer

Dependabot

Answer

Git Large File Storage (LFS)

Question 12

Which TWO actions help improve communication and collaboration in a distributed Azure DevOps team?

Accepted Answer

Maintain a shared wiki with project documentation and decisions.. A shared wiki (e.g., Azure DevOps Wiki) provides a single source of truth for project documentation and decisions, accessible asynchronously—critical for distributed teams. Additionally, scheduling daily stand-up meetings at a time that works for all time zones ensures regular synchronous alignment and promotes collaboration. Multiple chat channels can fragment discussions, long email threads are hard to follow, and avoiding PR comments removes a key asynchronous review/discussion mechanism.

Answer

Use multiple chat channels for each topic to organize discussions.

Answer

Use long email threads for decision-making to ensure full documentation.

Answer

Avoid using pull request comments to reduce noise.

Question 13

Your organization is adopting Microsoft Entra ID for identity management. You need to configure Azure DevOps to trust tokens issued by Entra ID for service connections. Which authentication method should you use?

Accepted Answer

Managed identity. Managed identity (Option B) is correct because it allows Azure DevOps to authenticate to Microsoft Entra ID without storing any credentials, using an identity automatically managed by Azure. This is the recommended approach for service connections when the Azure DevOps agent runs on an Azure resource (e.g., a VM or App Service) that supports managed identities, as it eliminates the need for secret rotation and reduces security risk.

Answer

Service principal with client secret

Answer

OAuth 2.0 authorization code grant

Answer

Personal access token (PAT)

Question 14

You have a multi-stage YAML pipeline that builds and deploys a containerized application to Azure Kubernetes Service (AKS). The build stage runs successfully, but the deploy stage fails with an error: 'Error: failed to get credentials: context deadline exceeded'. You verify that the AKS cluster is running and that the service connection is valid. What is the most likely cause?

Accepted Answer

The build agent's IP address is not allowed by the AKS cluster's network policies.. The error 'context deadline exceeded' when running `az aks get-credentials` indicates a network timeout, not an authentication or permission failure. Since the AKS cluster is running and the service connection is valid, the most likely cause is that the build agent's IP address is blocked by AKS network policies (e.g., authorized IP ranges or a firewall), preventing the agent from reaching the cluster's API server within the default timeout.

Answer

The Azure service connection has expired.

Answer

The service principal used by the pipeline does not have RBAC permissions on the cluster.

Answer

The container registry is not accessible from the build agent.

Question 15

Your team uses GitHub and wants to automatically link pull requests to work items in Azure Boards. What should you configure?

Accepted Answer

Install the Azure Boards app for GitHub and configure the integration. The Azure Boards app for GitHub is the official integration that synchronizes work items with GitHub commits, branches, and pull requests. Once installed and configured, it automatically links pull requests to Azure Boards work items based on mention patterns (e.g., 'AB#123') in the PR description or commit messages, enabling traceability without custom scripting.

Answer

Add a repository secret with Azure Boards connection string

Answer

Configure branch protection rules to require a linked work item

Answer

Create a GitHub Actions workflow that posts comments to Azure Boards

Question 16

Your team wants to implement a policy that requires all pull requests to have at least one approval from a member of the 'Senior Developers' group before merging. Which mechanism should you use?

Accepted Answer

Create a branch policy on the target branch that requires a minimum number of reviewers from the 'Senior Developers' group.. Azure Repos branch policies allow you to enforce required reviewers on pull requests. By creating a branch policy on the target branch that requires a minimum number of reviewers from the 'Senior Developers' group, you ensure that no pull request can be completed without at least one approval from that group. This directly meets the requirement without relying on file-level ownership or external scripts.

Answer

Add a CODEOWNERS file that designates 'Senior Developers' as owners of all files.

Answer

Configure the pull request dashboard to display required reviewers.

Answer

Set up a build validation policy that runs a script to check approvals.

Question 17

Refer to the exhibit. You have a YAML pipeline definition that builds a .NET application. You notice that the revision number is always 0. What is the most likely cause?

Accepted Answer

The counter expression uses a variable that is not defined as a counter, causing it to reset.. The counter expression in Azure DevOps YAML pipelines requires a named counter variable to persist its value across pipeline runs. If the variable used as the first parameter of the `counter` function (e.g., `minorVersion`) is not defined as a counter variable, the counter resets to the seed value (0) on each run. Option B correctly identifies that the variable is not defined as a counter, causing the revision number to always be 0.

Answer

The 'DotNetCoreCLI@2' task does not support the counter expression.

Answer

The counter expression resets every time the pipeline runs because of the 'minorVersion' variable.

Answer

The counter expression is evaluated after the build steps, so it always returns 0.

Question 18

Which THREE are common Git branching strategies used by development teams? (Select THREE.)

Accepted Answer

GitFlow. GitFlow is a common branching strategy that uses a main branch (master/main) alongside develop, feature, release, and hotfix branches. It provides a structured model for managing releases, hotfixes, and parallel development, making it suitable for projects with scheduled release cycles.

Answer

Monorepo

Answer

Centralized version control

Question 19

Your team uses Azure Pipelines for CI/CD. You want to enforce that every build produces a versioned artifact that includes the Git commit ID. Which predefined variable should you use to get the commit ID in a YAML pipeline?

Accepted Answer

Build.SourceVersion. The `Build.SourceVersion` predefined variable in Azure Pipelines resolves to the commit ID (full SHA) of the commit that triggered the pipeline. This makes it the correct choice for embedding the Git commit ID into a versioned artifact. Other variables like `Build.BuildId` or `Build.SourceBranch` do not provide the commit hash.

Answer

Build.Repository.Name

Answer

Build.BuildId

Answer

Build.SourceBranch

Question 20

You are setting up a build pipeline for a .NET Core application. The build should run on every pull request to the 'main' branch. Which trigger configuration should you use in the YAML pipeline?

Accepted Answer

pr: branches: include: - main. In Azure Pipelines YAML, the `pr` trigger is used to define pull request validation triggers, separate from the `trigger` keyword which controls CI triggers on branch pushes. By specifying `pr: branches: include: - main`, the pipeline will automatically run on every pull request targeting the `main` branch, which matches the requirement exactly.

Answer

trigger: pr: branches: include: - main

Answer

trigger: branches: include: - main

Answer

pr: autoCancel: false branches: include: - '*'