AZ-400 Practice Exam 58 — 20 Questions

Question 1

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.. Option A is correct because, 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 does not include the 'resetOnPush' property (or its equivalent in the REST API), which is required to invalidate existing approvals. Without that setting, approvals remain valid even after new commits are pushed.

Answer

The policy blocks the push until re-reviewed.

Answer

The pull request is automatically rejected.

Answer

All existing approvals are reset.

Question 2

You are designing a release pipeline for a microservices application deployed to Azure Kubernetes Service (AKS). You need to implement a strategy that allows rolling back to the previous version quickly if a deployment fails. The pipeline should also support canary deployments. Which tool or feature should you use?

Accepted Answer

Helm package manager with Helm deploy task.. Helm is the correct choice because it provides native support for rollbacks via `helm rollback`, which can revert a release to a previous revision quickly. Additionally, Helm supports canary deployments through its upgrade strategy (e.g., `--set canary.enabled=true`) and integration with tools like Flagger or Argo Rollouts, enabling fine-grained traffic shifting. The Helm deploy task in Azure Pipelines wraps these capabilities, making it the most suitable tool for both rollback and canary requirements.

Answer

Terraform with Kubernetes provider.

Answer

Azure Pipelines Kubernetes manifest task with kubectl apply.

Answer

Kubectl task with rolling update strategy.

Question 3

Your team uses GitHub for source control and Azure Pipelines for CI/CD. You need to trigger a pipeline automatically when a pull request is created against the main branch. Which trigger type should you configure in the YAML pipeline?

Accepted Answer

pr:. Option A is correct because the `pr:` trigger in Azure Pipelines YAML is specifically designed to automatically start a pipeline when a pull request is created or updated against a specified branch. By default, `pr:` triggers are enabled for the `main` branch, so configuring `pr: main` ensures the pipeline runs on PR creation without needing a separate branch policy.

Answer

trigger:

Answer

schedules:

Answer

resources:

Question 4

You have a build pipeline that produces several artifacts. You need to publish these artifacts to Azure Artifacts feed, but only if the build succeeds. Which task should you add to the pipeline?

Accepted Answer

Add a 'Publish Build Artifacts' task and then a 'Universal Publish' task.. The 'Publish Build Artifacts' task makes the build outputs available as pipeline artifacts, and the 'Universal Publish' task is the correct way to publish those artifacts to an Azure Artifacts feed (which supports Universal Packages). This combination ensures artifacts are only published after the build succeeds because both tasks run in the pipeline's job sequence, and by default, subsequent tasks execute only if the previous task succeeded.

Answer

Add an 'npm publish' task to publish packages.

Answer

Add a 'Copy Files' task to copy artifacts to the feed location.

Answer

Add a 'NuGet push' task to push packages to the feed.

Question 5

Your Azure DevOps pipeline uses a YAML template to avoid duplication. The template defines common build steps. You need to override one of the steps in a specific pipeline without modifying the template. Which approach should you use?

Accepted Answer

Use template parameters with a 'steps' object that can be injected, and use the 'replace' keyword in the pipeline to override the step.. Option D is correct because Azure DevOps YAML templates support parameterized steps objects, allowing a pipeline to inject a custom set of steps that replace the default ones defined in the template. The `replace` keyword is used within the template to designate a default steps object that can be overridden by the calling pipeline, enabling step-level customization without modifying the template file.

Answer

Use the 'overrides' keyword in the pipeline YAML to specify which steps to replace.

Answer

Create a copy of the template and modify the step directly.

Answer

Use a conditional 'if' statement in the template to skip steps based on a parameter.

Question 6

Which THREE components are required to set up a self-hosted agent pool in Azure Pipelines?

Accepted Answer

The agent software installed on the target machine. Option A is correct because the self-hosted agent requires the Azure Pipelines agent software to be installed on the target machine. This software, which includes the agent listener and worker processes, is what registers the machine with the agent pool and executes pipeline jobs. Without the agent software, the machine cannot communicate with Azure Pipelines or run any tasks.

Answer

A deployment group target

Answer

Azure VM extension for Azure Pipelines Agent

Question 7

You are designing a multi-stage YAML pipeline that builds a Docker image and deploys it to Azure Kubernetes Service (AKS). You want to reuse the Docker build steps across multiple stages. What is the best approach?

Accepted Answer

Create a YAML template and reference it from each stage.. Option C is correct because YAML templates in Azure Pipelines allow you to define reusable step, job, or stage definitions in a separate file and reference them using the `template` keyword. This approach promotes DRY (Don't Repeat Yourself) principles, simplifies maintenance, and ensures consistency when the same Docker build steps are needed across multiple stages in a multi-stage pipeline.

Answer

Use a stage template.

Answer

Define the steps as variables and reference them.

Answer

Create a separate job and call it from each stage.

Question 8

Your team uses Azure Pipelines to deploy a microservices application to Azure Kubernetes Service (AKS). You need to implement a strategy that minimizes downtime during updates. Which TWO options should you use?

Accepted Answer

Configure a rolling update strategy in the Kubernetes manifest.. Option C is correct because a rolling update strategy in Kubernetes gradually replaces old pods with new ones, ensuring that a minimum number of pods remain available throughout the update. This minimizes downtime by only terminating old pods after new ones are healthy, controlled by parameters like `maxSurge` and `maxUnavailable` in the Deployment manifest.

Answer

Set the deployment replica count to zero before updating.

Answer

Use a canary deployment with a service mesh.

Answer

Use a recreate deployment strategy.

Question 9

Refer to the exhibit. A developer pushes a commit to the main branch. Which stages will run?

Accepted Answer

Only the Build stage.. The exhibit shows a pipeline with a trigger condition set to 'main' for the Build stage only. The Test stage has no trigger condition defined, meaning it will only run if explicitly triggered by a preceding stage or a separate trigger. When a developer pushes a commit to the main branch, only the Build stage is triggered because it is the only stage with a branch filter matching 'main'. The Test stage does not have a trigger, so it will not run automatically.

Answer

Only the Test stage.

Answer

Neither stage.

Answer

Both Build and Test stages.

Question 10

Your release pipeline deploys a .NET Core web app to Azure App Service using a deployment slot for staging. The pipeline runs integration tests against the staging slot. After tests pass, you want to swap the staging slot with production. However, the swap fails sometimes because the staging slot has different configuration settings. What is the best practice to ensure swapping succeeds?

Accepted Answer

Use slot-specific configuration settings (deployment slot settings) for connection strings and app settings that differ between slots.. Option A is correct because Azure App Service allows you to mark specific configuration settings (like connection strings and app settings) as 'deployment slot settings.' When a setting is marked as slot-specific, it stays with the slot during a swap, preventing failures caused by mismatched configurations. This ensures that the staging slot retains its test-specific settings (e.g., a test database connection string) while the production slot keeps its own settings, making the swap predictable and reliable.

Answer

Manually update the production slot settings to match staging before each swap.

Answer

Perform a swap with preview and then complete the swap after verifying the staging slot.

Answer

Write a custom PowerShell script to copy configuration from staging to production before swapping.

Question 11

Your organization uses GitHub Actions for CI/CD. You need to ensure that secrets stored in GitHub Actions are not exposed in logs. A developer accidentally logs a secret using 'echo ${{ secrets.API_KEY }}' in a workflow step. What is the default behavior?

Accepted Answer

The secret value is masked with asterisks in the log output. Option D is correct because GitHub Actions automatically masks secrets in workflow logs. When a secret is used in a step (e.g., via `${{ secrets.API_KEY }}`), GitHub replaces any occurrence of the secret's value in the log output with `***`. This redaction happens at runtime, so even if a developer accidentally echoes the secret, the log will show asterisks instead of the actual value.

Answer

The secret value is replaced with an empty string in the log

Answer

The workflow run fails with an error about secret exposure

Answer

The secret is redacted before the step runs, and the step fails if it tries to use the secret

Question 12

Which TWO are valid strategies for managing secrets in Azure Pipelines?

Accepted Answer

Use a variable group linked to Azure Key Vault and mark variables as secret.. Option B is correct because linking a variable group to Azure Key Vault allows secrets to be securely referenced in pipelines without exposing them in plaintext. When variables are marked as secret, Azure Pipelines automatically masks their values in logs and output, ensuring sensitive data remains protected throughout the build and release process.

Answer

Store secrets in plain text in a variable group.

Answer

Store secrets in a Git repository and read them during build.

Answer

Embed secrets directly in the pipeline YAML file.

Question 13

Refer to the exhibit. A developer pushes a commit to a branch named 'feature/new-login'. Which of the following will occur?

Accepted Answer

The pipeline will not trigger because the branch is excluded.. The trigger includes main and release/* branches, and explicitly excludes feature/* branches. Since 'feature/new-login' matches the exclude pattern 'feature/*', the pipeline will not trigger. The pipeline will only trigger for branches that match include patterns and do not match exclude patterns. 'feature/new-login' is excluded, so no build will start.

Answer

The pipeline will trigger and run all steps because the branch name does not match any exclude pattern.

Answer

The pipeline will trigger only the restore and build steps, skipping tests.

Answer

The pipeline will trigger but fail with an error because the branch is not in the include list.

Question 14

Refer to the exhibit. A developer attempts to push a commit directly to the main branch of FabrikamWeb repository but receives a push rejection. What is the most likely reason?

Accepted Answer

The developer does not have permission to push to the main branch due to branch policies requiring pull requests.. The repository FabrikamWeb has a default branch 'develop', and the merge strategy policy may require that all changes be made via pull requests. Also, the absence of a policy on main branch suggests that main is protected by branch policies that are not listed because the query was for the develop branch. However, the question is about pushing to main. Given the exhibit shows policies for the repository, but not specifically for main branch, the most likely cause is that the branch policies are set on the default branch (develop) and maybe also on main, but the push rejection could be due to a branch policy requiring pull requests. However, the correct answer is that the main branch is protected by a branch policy that requires pull requests, which is a common setting.

Answer

The developer tried to push to the wrong remote URL.

Answer

The FabrikamWeb repository has a minimum number of reviewers policy set to 1, which blocks direct pushes.

Answer

The main branch does not exist in the FabrikamWeb repository.

Question 15

Refer to the exhibit. You run an ARM template deployment and get the error shown. What is the most likely cause?

Accepted Answer

The template references a resource that already exists and conflicts with the deployment.. The error details show a Conflict with message 'User 'adminuser' already exists in this resource group.' This indicates the template tries to create a resource that already exists, causing a conflict.

Answer

The deployment name already exists in the resource group.

Answer

The resource group location does not match the template location.

Answer

The template has a syntax error in the JSON.

Question 16

Refer to the exhibit. A developer is working on the feature/login branch and wants to ensure that the latest changes from main are incorporated before creating a pull request. Which command should the developer run next?

Accepted Answer

git pull --rebase origin main. The exhibit shows that the feature/login branch has a merge commit from main (3a1b2c3) which means main was already merged into feature/login. However, the local branch is ahead of origin by 1 commit (the merge commit). The developer wants to incorporate the latest changes from main. Since main has advanced (d4e5f6a is the latest on origin/main), the developer should pull the latest main and rebase or merge again. The best practice is to rebase onto the latest main to maintain a linear history. Therefore, the developer should run 'git pull --rebase origin main' to fetch and rebase.

Answer

git rebase --abort

Answer

git merge main

Answer

git push origin feature/login

Question 17

Refer to the exhibit. A team wants to release version 1.0 from the main branch. They notice that the tag v1.0 is already on the current main commit. However, they also see that the origin/feature/experiment branch has commits that are not merged into main. What is the most likely scenario?

Accepted Answer

The experiment branch contains experimental work that was not intended for release; the tag v1.0 correctly marks the release on main.. The tag v1.0 is on the current main commit (9a8b7c6). The feature/experiment branch (1a2b3c4) is a child of the initial commit, but it is not merged into main. The main branch has commits that are ahead of the experiment branch. The team wants to release v1.0 from main; the tag already exists. The presence of the experiment branch not merged suggests that it was not intended for this release. The most likely scenario is that the experiment branch was created from an older commit and is not ready for release, so it was not merged. The release v1.0 is correctly tagged on main.

Answer

The team should delete the experiment branch because it is not merged.

Answer

The tag v1.0 was applied to the wrong commit; it should be on the merge commit of the experiment branch.

Answer

The main branch is missing the experiment branch commits; a merge is required before release.

Question 18

Refer to the exhibit. After executing the delete command, what is the state of the repository?

Accepted Answer

The tag v1.0-rc is removed, and the repository now contains only one tag (v1.0) and three branches.. The command deleted the tag refs/tags/v1.0-rc. After deletion, the tag is no longer available. The other refs (branches and tags) remain unchanged. The repository now has only one tag: v1.0. The branches main, develop, and feature/new-feature still exist.

Answer

The tag v1.0-rc is removed, but the commit it pointed to is also deleted from the repository.

Answer

The tag v1.0-rc is removed, and the branch feature/new-feature is also deleted because it was the same object.

Answer

The command fails because the tag does not exist.

Question 19

You are a DevOps engineer for a large enterprise that uses GitHub Enterprise Cloud. The development team follows a GitFlow branching strategy with develop, feature, release, and main branches. The release branch is created from develop when a release is ready. After testing, the release branch is merged into main and then tagged. However, the team frequently forgets to merge release branches back into develop, causing hotfixes applied to main to not be in develop. You need to implement an automated process to ensure that after a release branch is merged into main, the changes are also merged back into develop. The solution must not require manual intervention and must handle merge conflicts gracefully by opening a pull request for conflict resolution. Which approach should you use?

Accepted Answer

Create a GitHub Actions workflow that triggers on push to main, attempts to merge main into develop, and if conflicts occur, opens a pull request for manual resolution.. Option B is correct because it uses a GitHub Actions workflow triggered on pushes to main to automatically merge main into develop. If conflicts arise, the workflow opens a pull request for manual resolution, ensuring no changes are lost and the process remains automated without manual intervention.

Answer

Configure a branch protection rule on main that requires a pull request to merge into develop.

Answer

Create a scheduled workflow that runs daily and merges main into develop if there are no conflicts.

Answer

Set up a webhook in GitHub that calls an Azure Function to merge main into develop.

Question 20

Your team manages a large-scale microservices application deployed on Azure Kubernetes Service (AKS). The code is hosted in Azure Repos, and you use Azure Pipelines for CI/CD. You have recently adopted GitHub Copilot for code suggestions. Your compliance team requires that all pipeline runs include a security scan using Microsoft Defender for Cloud. Additionally, all pull requests must have at least two reviewers from separate teams before merging. The current pipeline completes in 45 minutes, and you want to minimize overhead. You need to design a process that enforces these requirements without degrading developer productivity. Which approach should you recommend?

Accepted Answer

Integrate the security scan as a step early in the CI pipeline, and configure branch policies on the main branch to require two reviewers from different teams and a successful CI build including the scan. Document the process and use Copilot to generate commit messages that reference work items.. Option B is correct because it integrates the security scan early in the CI pipeline, ensuring it runs on every build without adding a separate pipeline overhead. Branch policies enforce both the required two reviewers from different teams and the successful CI build (including the scan) before merging, which minimizes additional pipeline complexity and maintains developer productivity.

Answer

Configure a branch policy on the main branch that requires a successful build and security scan before merging, and use a single pipeline that includes the scan.

Answer

Create a separate security scan pipeline triggered on pull request creation, and require its successful completion via branch policy. Then set up a separate PR policy requiring two reviewers.

Answer

Add a manual approval gate in the release pipeline that requires the security officer to approve after the scan completes.

AZ-400 Practice Exam 58 — 20 Questions

Exhibit

AZ-400 Practice Exam 58 — 20 Questions

Exhibit