Design and implement source control

A development team uses a forking workflow in Azure Repos. They want to ensure that only specific users can create forks of the main repository. How can they achieve this?

A team uses Git for source control. They want to automatically squash all commits in a feature branch into a single commit when merging to the main branch. Which merge type should they use?

A company has a policy that all code changes must be reviewed by at least two people. However, for urgent bug fixes, they want to allow a single reviewer. How should they configure the branch policy?

A developer accidentally committed a sensitive password to a Git repository. The commit has already been pushed to the remote. What is the first step to remediate the situation?

A team is migrating from TFVC to Git. They have a large codebase with many branches. What is the recommended approach to preserve the history during migration?

Which TWO branch policies can be configured in Azure Repos to enforce code quality?

Which THREE are benefits of using a monorepo vs multiple repositories?

Which THREE are valid Git merge strategies available in Azure Repos pull requests?

You are a DevOps engineer at a company that develops a cloud-based SaaS application. The application consists of multiple microservices, each stored in its own Git repository within a single Azure DevOps project. The team has grown rapidly, and developers frequently need to make changes that span multiple services. They often complain about the overhead of managing multiple pull requests and coordinating merges across repositories. To improve efficiency, the team lead suggests consolidating all microservices into a single monorepo. However, the lead architect is concerned about the impact on build times, as the CI pipeline currently builds each service independently. You are tasked with designing a source control strategy that reduces cross-repository coordination overhead while maintaining fast, independent builds. You propose using a monorepo with a structure that allows selective building. Which approach should you recommend?

You are a DevOps consultant for a financial services company that is migrating from TFVC to Git. The existing TFVC repository has several branches: main, dev, feature branches, and release branches. The history is linear with no branching. The company requires that all future Git commits follow a strict naming convention: 'type(scope): description' (e.g., 'feat(api): add new endpoint'). They also want to prevent direct commits to the main branch; all changes must go through pull requests with at least one reviewer. Additionally, they want to ensure that each commit message is validated before it is merged. The team is small (5 developers) and they want a simple setup without complex tooling. Which approach should you recommend?

A development team uses Git for source control. They want to ensure that all code changes are reviewed before merging into the main branch. Which branch policy should they configure in Azure Repos?

A team is migrating from TFVC to Git in Azure Repos. They have a large repository with a history of 10,000+ commits. They want to preserve the full history while minimizing migration time. Which approach should they recommend?

An organization uses Azure Repos with multiple Git repositories. They want to enforce that all commits to the main branch are signed using GPG keys. Which combination of actions is required to enforce commit signing?

A team uses a monorepo in Azure Repos. They want to implement a build validation policy that only triggers builds for code changes in specific folders to reduce build times. Which approach should they use?

Which TWO actions should you take to ensure that your Git repository in Azure Repos remains performant as it grows?

A development team uses Git for source control. They want to enforce a branching strategy where all feature work is done in short-lived branches that are merged to main via pull requests. The team also requires that every commit on main builds successfully. Which TWO practices should the team implement?

Your team manages a large monorepo in Azure Repos containing multiple projects. Developers frequently complain that cloning the entire repository takes too long and that they only need a subset of the code. The team uses Git LFS for large binary files. The repository currently has 50,000 commits and is 5 GB in size. You want to improve clone performance without sacrificing the ability to contribute to any part of the repo. What should you do?

A development team is using Git for source control. They have a main branch that should always be deployable. Developers work on feature branches and create pull requests to merge into main. Recently, a feature branch with incomplete work was accidentally merged into main, causing build failures. What is the best Git branch strategy to prevent this in the future while maintaining fast feedback?

Drag and drop the steps to set up a continuous integration pipeline in Azure Pipelines into the correct order.

Drag and drop the steps to troubleshoot a failed Azure DevOps release pipeline into the correct order.

Match each Git branching strategy to its description.

Match each Azure Artifacts feed type to its description.

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?

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

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

Refer to the exhibit. A developer pushes a new commit to an existing pull request targeting the main branch. What is the effect on the pull request?

Refer to the exhibit. A developer is on the 'feature/login' branch and wants to integrate the latest changes from 'feature/user-profile' without creating a merge commit. Which Git command should the developer use?

Refer to the exhibit. A pipeline in repository 'MyProject/AppRepo' is configured to trigger when changes are pushed to 'SharedRepo'. A developer pushes a commit to the 'release/v1' branch of 'SharedRepo'. What will happen?

You are an Azure DevOps engineer at a software company that uses a single Azure Repos Git repository for a product with two independent release trains: a web front end and a backend API. You need to enforce that pull requests targeting the release branch for each train require approval from a different set of reviewers, and you must be able to report on policy compliance separately for each train. What should you configure?

A development team uses Azure Repos Git. They need to ensure that every commit pushed to the main branch includes a valid work item link, but they do not want to block developers from pushing to feature branches. What should they configure?

A team is using Azure Repos Git and wants to integrate their repository with Azure Boards so that they can create branches directly from work items and track commits and pull requests against those work items. What should they do?