Exam AZ-400 topic 12 question 2 discussion

Since a fork is a copy of a repository. Therefore no need to create a repository. - Create a fork - Add a build policy for the master branch - Add an application access policy https://docs.microsoft.com/en-us/azure/devops/repos/git/forks?view=azure-devops&tabs=visual-studio#whats-in-a-fork

The answer is correct. Firstly, let me try to exclude the options which are not related - Create a branch -> Not such requirement - Add a build policy for the master branch -> No mention about Master branch. Build policy can be set at any branch depends on the project. Lets exclude this option - Add an application access policy -> No clue what it does for Azure repo Since there is no Azure repo exist for Project 2, lets include it as a first step - Create a repository - Create a fork - Add a build policy for a fork

answer is correct, no repo exists so we need to create it first.

- Create a fork - Add a build policy for the master branch - Create a branch

Create a fork Add a build policy for master branch Create a branch

the given answer is correct. 1st. teams has no access to project2, so it has to be a fork. in order to do so, you need to create a repository. the last step will be a build policy on the fork which mostly like raise a PR to project 2 once everything goes well. so someone with permission of project 2 can do the merge. my 2 cents.

I have doubts, In Planned changes mention that Contoso plans to create projects in Azure DevOps, then Project2 hadn't been created then you didn't have a code repository yet. But the question ask about "implement the code flow strategy for Project2 in Azure DevOps", then if we focus on the code flow strategy for Project2, I assume that the Project2 exists and now you have to implement the code flow strategy. Starting from there. 1. Create a fork, for create an independent copy of the original repository. 2. Add an application access policy, Team2 needs the necessary permissions to access on the forked repository. 3. Add a build policy for the fork, the forked repo doesn't inherit permissions or policies then you have to define it to enforce the desired behavior. Create repo in this scenary wasn't necessary. Create a branch is not a requirement, the closest requirement would be "Enable Team2 to work independently on changes to a copy of Project2", we achieve that with the fork. Add a build policy for the master branch, could limit policy on a master branch and not the repo.

Same as Topic 9 Question 4. https://www.examtopics.com/discussions/microsoft/view/18333-exam-az-400-topic-9-question-4-discussion

1. Create a fork 2. Add a build policy for master branch 3. Create a branch https://learn.microsoft.com/en-us/azure/devops/repos/git/forks?view=azure-devops&tabs=visual-studio Git repo forks are useful when people want to make experimental, risky, or confidential changes to a codebase, but those changes need to be isolated from the codebase in the original repo. A new fork is basically a clone of the original repo pushed to a new remote repo. The fork is independent of the original repo, and is a complete copy unless you specify a single branch. As an independent copy, changes you make to your fork, such as adding commits or branches, aren't shared with the original repo. If you want to merge your codebase changes into the original repo, you must create a pull request (PR) to request review and approval of those changes. The forking process doesn't transfer any permissions, policies, or build pipelines from the original repo to your fork.

- create a fork - Add a build policy for the fork - Add an application access policy Rationale: "Ensure that any intermediary changes performed by Team2 on a copy of Project2" - fork repo to a new repo, so need to create a repo forking process doesn't transfer any permissions, policies, or build pipelines from the original repo to your fork - so you need to add a build policy for the fork "Enable Team2 to work independently on changes to a copy of Project2" - satisfied "Enable Team2 to submit pull requests for Project2." - satisfied "Team2 members will not have permissions to project2" - Add an application access policy

All in all, I think the solution would be - Create a repository - Add a build policy for the master - Create a fork - Add a build policy for the fork However, we need to drop one of those, not sure which. The workflow would be: 1) make changes to your fork 2) make PR to original repo 3) original repo policies take effect. Now: Existing environment does not have repos or build policies(?) which are typically in master branch “Working independently on changes to a copy of Project2” probably means forking. “Ensure that any intermediary changes performed by Team2 on a copy of Project2 will be subject to the same restrictions” would mean we also need to add the policies to the fork repository.

"- Enable Team2 to work independently on changes to a copy of Project2. - Ensure that any intermediary changes performed by Team2 on a copy of Project2 will be subject to the same restrictions as the ones defined in the build policy of Project2." https://docs.microsoft.com/en-us/azure/devops/repos/get-started/key-concepts-repos?view=azure-devops A fork is a complete copy of a repository, including all files, commits, and (optionally) branches Given answer is correct

The answer is correct. Here first you need a Repos. You don't have one yet. Second you have to create a Fork --> "Enable Team2 to work independently on changes to a copy of Project2" Third you need a build policy for the fork

in case of Implement a code flow strategy for Project2 that will: - Enable Team2 to submit pull requests for Project2. - Enable Team2 to work independently on changes to a copy of Project2. - Ensure that any intermediary changes performed by Team2 on a copy of Project2 will be subject to the same restrictions as the ones defined in the build policy of Project2. may be a fork and then policy and policy (to both branches?)

Got this January 2022.

the correct answer is - Create a repository - Create a fork - Add a build policy

- Create a repo - Create a fork - Add a build policy for the fork