Microsoft Microsoft Certifications AZ-400 Questions & Answers

• Question 541:

  Which branching strategy should you recommend for the investment planning applications suite?

  A. release isolation

  B. main only

  C. development isolation

  D. feature isolation

  Correct Answer: C

  Scenario: A branching strategy that supports developing new functionality in isolation must be used.

  

  Feature isolation is a special derivation of the development isolation, allowing you to branch one or more feature branches from main, as shown, or from your dev branches.

  When you need to work on a particular feature, it might be a good idea to create a feature branch.

  References: https://docs.microsoft.com/en-us/azure/devops/repos/tfvc/branching-strategies-with-tfvc?view=azure-devops

• Question 542:

  DRAG DROP

  You are implementing a new project in Azure DevOps.

  You need to assess the performance of the project. The solution must identify the following metrics:

  1.

  How long it takes to complete a work item

  2.

  The percentage of defects found in production

  Which DevOps KPI should you review for each metric? To answer, drag the appropriate KPIs to the correct metrics. Each KPI may be used once, more than once, or not at all. You may need to drag the split bar between panes or scroll to

  view content.

  NOTE: Each correct selection is worth one point.

  Select and Place:

  

  Correct Answer:

  

  Box 1: Cycle time

  How long it takes to complete a work item

  Cycle time measures the time it takes for your team to complete work items once they begin actively working on them.

  Lead time measures the total time elapsed from the creation of work items to their completion.

  

  Box 2: Defect Escape Rate The percentage of defects found in production

  Defect Escape Rate: Each software deployment includes the risk of sparking new defects. These issues can be discovered with user acceptance testing but sometimes these errors are found by the end-user. Since errors are the natural part of the development process, the development team should plan to deal with these issues before the development process. Defect escape rate comes into play to deal with such scenarios. It monitors the reality by accepting that issues will arise and they should be discovered as early as possible. The defect escape rate checks how often defects are discovered in the preproduction phase versus during the production phase. This metric alone provides essential insights into the quality of software releases.

• Question 543:

  DRAG DROP

  You are using Agile process methodologies and Azure Boards in Azure DevOps.

  You import the work items shown in the following table.

  

  You need to categorize the items.

  Which state should you assign to each item? To answer, drag the appropriate states to the correct items. Each state may be used once, more than once, or not at all. You may need to drag the split bar between panes or scroll to view content.

  NOTE: Each correct selection is worth one point.

  Select and Place:

  

  Correct Answer:

  

  Box 1: In Progress

  Category states

  Category states determine how Agile planning tools and select dashboard widgets treat each workflow state. The state categories used by the backlogs, boards and widgets are Proposed, In Progress, Resolved, and Complete.

  In Progress: Assigned to states that represent active work. Work items assigned to states mapped to this category appear in the backlog (unless you choose to hide them) and make up the middle columns on Kanban boards.

  Box 2: Proposed

  Proposed: Assigned to states associated with newly added work items so that they appear on the backlog. The first column on the Kanban boards and Taskboards map to a Proposed state category.

  Box 3: Completed

  Completed: Assigned to states that represent work that has finished. Work items whose state is in this category don't appear on the backlog and do appear in the last column of the Kanban board. You can't modify states in this category nor

  can you add states to this category.

  Reference:

  https://learn.microsoft.com/en-us/azure/devops/boards/work-items/workflow-and-state-categories

• Question 544:

  DRAG DROP

  You have a GitHub repository.

  You need to configure Dependabot dependency scanning. The solution must meet the following requirements:

  1.

  Automatically open a pull request to resolve an alert.

  2.

  Automatically open a pull request when a dependency is updated.

  What should you enable for each requirement? To answer, drag the appropriate features to the correct requirements. Each feature may be used once, more than once, or not at all. You may need to drag the split bar between panes or scroll

  to view content.

  NOTE: Each correct selection is worth one point.

  Select and Place:

  

  Correct Answer:

  

  Box 1: A dependency graph

  Automatically open a pull request to resolve an alert.

  GitHub generates Dependabot alerts when we detect that the default branch of your codebase is using dependencies with known security risks. For repositories where Dependabot security updates are enabled, when GitHub detects a

  vulnerable dependency in the default branch, Dependabot creates a pull request to fix it.

  GitHub starts generating the dependency graph immediately and generates alerts for any insecure dependencies as soon as they are identified. The graph is usually populated within minutes but this may take longer for repositories with many

  dependencies.

  Box 2: Security updates

  Automatically open a pull request when a dependency is updated.

  Dependabot security updates make it easier for you to fix vulnerable dependencies in your repository. If you enable this feature, when a Dependabot alert is raised for a vulnerable dependency in the dependency graph of your repository,

  Dependabot automatically tries to fix it.

  About updates for vulnerable dependencies in your repository

  GitHub generates Dependabot alerts when we detect that the default branch of your codebase is using dependencies with known security risks. For repositories where Dependabot security updates are enabled, when GitHub detects a

  vulnerable dependency in the default branch, Dependabot creates a pull request to fix it. The pull request will upgrade the dependency to the minimum possible secure version needed to avoid the vulnerability.

  Reference:

  https://docs.github.com/en/code-security/dependabot/dependabot-security-updates/about-dependabot-security-updates

  https://docs.github.com/en/code-security/dependabot/dependabot-alerts/viewing-and-updating-dependabot-alerts

• Question 545:

  DRAG DROP

  You have a large repository named Repo1 that contains a directory named directory1.

  You plan to modify files in directory1.

  You need to create a clone of Repo1. The solution must minimize the amount of transferred data.

  How should you complete the script? To answer, drag the appropriate values to the correct targets. Each value may be used once, more than once, or not at all. You may need to drag the split bar between panes or scroll to view content.

  NOTE: Each correct selection is worth one point.

  Select and Place:

  

  Correct Answer:

  

  Box 1: git clone

  Clone a Git repository using git clone

  To clone a git repository, use the “git clone” command with the URL of your Git repository.

  $ git clone

  For example, let's say that you want to clone a public repository from Github, you are going to execute the following command

  $ git clone https://github.com/username/project.git

  Cloning into 'project'...

  remote: Enumerating objects: 813, done.

  remote: Total 813 (delta 0), reused 0 (delta 0), pack-reused 813

  Receiving objects: 100% (813/813), 3.66 MiB | 5.52 MiB/s, done.

  Resolving deltas: 100% (391/391), done.

  As you can see, by default, Git is going to clone your Git repository into a folder named by the name of project.

  Box 2: git sparse-checkout

  Using sparse-checkout with an existing repository

  To restrict your working directory to a set of directories, run the following commands:

  git sparse-checkout init --cone

  git sparse-checkout set ...

  If you get stuck, run git sparse-checkout disable to return to a full working directory.

  The init subcommand sets the necessary Git config options and fills the sparse-checkout file with patterns that mean “only match files in the root directory”.

  The set subcommand modifies the sparse-checkout file with patterns to match the files in the given directories. Further, any files that are immediately in a directory that's a parent to a specified directory are also included.

  Reference:

  https://devconnected.com/how-to-clone-a-git-repository/

  https://github.blog/2020-01-17-bring-your-monorepo-down-to-size-with-sparse-checkout/

• Question 546:

  DRAG DROP

  You have a project in Azure DevOps named Project1 that contains two Azure DevOps pipelines named Pipeline1 and Pipeline2.

  You need to ensure that Pipeline1 can deploy code successfully to an Azure web app named webapp1. The solution must ensure that Pipeline2 does not have permission to webapp1.

  Which three actions should you perform in sequence? To answer, move the appropriate actions from the list of actions to the answer area and arrange them in the correct order.

  Select and Place:

  

  Correct Answer:

  

  Step 1: Create a service principal in Microsoft Azure Active Directory (Azure ad), part of Microsoft Entra

  We need it in step 3.

  Step 2: In Project1, create a service connection¨

  You can create a connection from Azure Pipelines to external and remote services for executing tasks in a job. Once you establish a connection, you can view, edit, and add security to the service connection

  Step 3: In Project, configure permissions.

  To authorize a service connection for a specific pipeline, open the pipeline by selecting Edit and queue a build manually. You see a resource authorization error and an "Authorize resources" action on the error. Choose this action to explicitly

  add the pipeline as an authorized user of the service connection.

  Azure Resource Manager service connection

  Use the following parameters to define and secure a connection to a Microsoft Azure subscription using Service Principal Authentication (SPA) or an Azure managed Service Identity. The dialog offers two main modes:

  * Automated subscription detection. In this mode, Azure Pipelines queries Azure for all of the subscriptions and instances to which you have access. They use the credentials you're currently signed in with in Azure Pipelines (including

  Microsoft accounts and School or Work accounts).

  If you don't see the subscription you want to use, sign out of Azure Pipelines and sign in again using the appropriate account credentials.

  *-> Manual subscription pipeline. In this mode, you must specify the service principal you want to use to connect to Azure. The service principal specifies the resources and the access levels that are available over the connection.

  Use this approach when you need to connect to an Azure account using different credentials from the credentials you're currently signed in with in Azure Pipelines. It's useful way to maximize security and limit access. Service principals are

  valid for two years.

  Reference: https://docs.microsoft.com/en-us/azure/devops/pipelines/library/connect-to-azure https://docs.microsoft.com/en-us/azure/devops/pipelines/library/service-endpoints

• Question 547:

  DRAG DROP

  You create a Git repository named Repo1 in Azure Repos.

  You need to configure Repo1 to meet the following requirements:

  1.

  Work items must be linked to a pull request.

  2.

  Pull requests must have a minimum of two reviewers.

  3.

  Pull requests must complete a code review by using a third-party tool.

  The solution must minimize administrative effort.

  Which type of policy should you use for each requirement? To answer, drag the appropriate policy types to the correct requirements. Each type policy may be used once, more than once, or not at all. You may need to drag the split bar

  between panes or scroll to view content.

  NOTE: Each correct selection is worth one point.

  Select and Place:

  

  Correct Answer:

  

  Box 1: Check-in

  Work items must be linked to a pull request.

  In the Add Check-in Policy dialog box, select the policy types you want, and then select OK.

  You can select from the following policies:

  *-> Work Items requires that one or more work items be associated with every check-in.

  Builds requires that the last build was successful before any new changes can be checked in.

  Changeset Comments Policy requires users to provide check-in comments.

  Code Analysis requires that code analysis be run before code can be checked in.

  Custom Path Policy scopes the other policies to specific folders or file types.

  Forbidden Patterns Policy prevents check-ins that have files with forbidden filename patterns.

  Work Item Query Policy specifies a work item query whose results are the only legal work items to associate with a check-in.

  Box 2: Status

  Pull requests must complete a code review by using a third-party tool.

  A status policy requires that an external service posts a status to the pull request. In this case, the external service could be SonarCloud. SonarCloud can analyze the code and check whether it meets the defined quality standards (Quality

  Gates). If it does, SonarCloud can then post a Passed status to the pull request. The status policy will then check this status before allowing the pull request to be merged.

  Box 3 Branch

  Pull requests must have a minimum of two reviewers.

  Require a minimum number of reviewers

  Code reviews are important for software development projects. To ensure that teams review and approve PRs, you can require approval from a minimum number of reviewers. The basic policy requires that a specified number of reviewers

  approve the code, with no rejections.

  To set the policy, under Branch Policies, set Require a minimum number of reviewers to On. Enter the required number of reviewers, and select any of the following options:

  Reference:

  https://learn.microsoft.com/bs-latn-ba/azure/devops/repos/tfvc/add-check-policies

  https://learn.microsoft.com/en-us/azure/devops/repos/git/branch-policies

  https://azuredevopslabs.com/labs/vstsextend/sonarcloud/

• Question 548:

  DRAG DROP

  You have an Azure Repos repository that contains large PSD files.

  You need to configure Git LFS to manage all the files.

  How should you complete the script? To answer, drag the appropriate values to the correct targets. Each value may be used once, more than once, or not at all. You may need to drag the split bar between panes or scroll to view content.

  NOTE: Each correct selection is worth one point.

  Select and Place:

  

  Correct Answer:

  

  Box 1: git lfs track "*.psd"

  Git Large File Storage (LFS)

  For example, if you want to upload a very large file and check it into your Git repository:

  git clone [email protected]:group/my-sample-project.git

  cd my-sample-project

  git lfs install # initialize the Git LFS project

  git lfs track "*.iso" # select the file extensions that you want to

  Note: Make sure that .gitattributes is tracked by Git. Otherwise Git LFS doesn't work properly for people cloning the project:

  git add .gitattributes

  git commit -am "Added .gitattributes to capture LFS tracking"

  Box 2: git lfs migrate import --include="psd" --everything

  git-lfs-migrate(1)

  NAME

  git-lfs-migrate - Migrate history to or from Git LFS

  SYNOPSIS

  git lfs migrate [options] [--] [branch … ]

  DESCRIPTION

  Convert files in a Git repository to or from Git LFS pointers, or summarize Git file sizes by file type. The import mode converts Git files (i.e., blobs) to Git LFS, while the export mode does the reverse, and the info mode provides an

  informational summary which may be useful in deciding which files to import or export.

  you can run git lfs migrate import to convert some file types to LFS:

  $ git lfs migrate import --include="*.mp3,*.psd"

  migrate: Fetching remote refs: ..., done

  migrate: Sorting commits: ..., done

  migrate: Rewriting commits: 100% (1/1), done

  main d2b959babd099fe70da1c1512e2475e8a24de163 -> 136e706bf1ae79643915c134e17a6c933fd53c61

  migrate: Updating refs: ..., done

  If after conversion you find that some files in your working directory have been replaced with Git LFS pointers, this is normal, and the working copies of these files can be repopulated with their full expected contents by using git lfs checkout.

  Box 3: git push

  While the --everything option means all commits reachable from any ref will be considered for migration, after migration only local refs will be updated even when --everything is specified. This ensures remote refs stay synchronized with their

  remote. In other words, refs/heads/foo will be updated with the --everything option, but refs/remotes/origin/foo will not, so it stays in sync with the remote until git push origin foo is performed. After checking that the results of a migration with -everything are satisfactory, it may be convenient to push all local branches to your remotes by using the --all option to git push.

  Reference:

  https://docs.gitlab.com/ee/topics/git/lfs/

  https://github.com/git-lfs/git-lfs/blob/main/docs/man/git-lfs-migrate.adoc

• Question 549:

  DRAG DROP

  You have an Azure Repos repository named repo1.

  You delete a branch named features/feature11.

  You need to recover the deleted branch.

  Which three commands should you run in sequence? To answer, move the appropriate commands from the list of commands to the answer area and arrange them in the correct order.

  Select and Place:

  

  Correct Answer:

  

  Azure Repos repository recover deleted branch "git restore" "git log" CLI git log.

  Step 1: git branch features/feature11

  You can restore deleted branches.

  In your local repo (if hasn't used git fetch after the branches deleted), use git branch -r, it will list all the remote branches. Then you can compare with the branches listed in VSTS, the branches show in local repo but not show in VSTS are the

  deleted branches.

  Step 2: git log

  Undo committed local changes

  When you commit to your local repository (git commit), Git records your changes. Because you did not push to a remote repository yet, your changes are not public (or shared with other developers). At this point, you can undo your changes.

  Undo staged local changes without modifying history

  You can revert a commit while retaining the commit history.

  This example uses five commits A,B,C,D,E, which were committed in order: A-B-C-D-E. The commit you want to undo is B.

  1.

  Find the commit SHA of the commit you want to revert to. To look through a log of commits, type git log. (Step 2)

  2.

  Choose an option and undo your changes:

  Step 3: git checkout

  To undo changes on a single file or directory from commit B, but retain them in the staged state:

  git checkout (Step 3)

  Note: You can also restore the deleted branches in local repo (if hasn't executed git fetch after the branches deleted) by:

  git checkout

  git push -u origin branchname Incorrect:

  *

  git stash To save local changes so you can re-use them later: git stash

  *

  get restore < > Note:

• Question 550:

  DRAG DROP

  You have a GitHub repository named repo1.

  You migrate repo1 to an Azure Repos repository named repo2.

  After the migration, changes are made to repo1.

  You need to sync the changes to repo2.

  How should you complete the script? To answer, drag the appropriate values to the correct targets. Each value may be used once, more than once, or not at all. You may need to drag the split bar between panes or scroll to view content.

  NOTE: Each correct selection is worth one point.

  Select and Place:

  

  Correct Answer:

  

  Box 1: repo1 repo URL Manually import a repo using git CLI You can follow these steps to manually import a repo into an Azure DevOps Services repo by replacing TFS with Azure Repos in the following steps.

  1. Clone the source repo to a temporary folder on your computer using the bare option, as shown in the following command line example, and then navigate to the repo's folder. When cloning using the bare option, the folder name includes the .git suffix. In this example, https://github.com/contoso/old-contoso-repo.git is the source repo to be manually imported.

  git clone --bare https://github.com/contoso/old-contoso-repo.git cd old-contoso-repo.git

  Box 2: repo1

  2. Create a target repo using TFS 2017 RTM, and make a note of the clone URL. In this example, https://dev.azure.com/contoso-ltd/MyFirstProject/_git/new-contoso-repo is the URL for the new target repo.

  Run the following command to copy the source repo to the target repo.

  git push --mirror https://dev.azure.com/contoso-ltd/MyFirstProject/_git/new-contoso-repo

  Box 3: repo2 clone URL

  Reference:

  https://learn.microsoft.com/en-us/azure/devops/repos/git/import-git-repository