AZ-400 Question 85
Select 3Your team stores its application code in an Azure DevOps Git repository and wants to create tags for each release to organize and reference specific versions. You also want to enable automated build pipelines to retrieve specific tagged releases. Which three actions should you take to properly configure and manage tags in this scenario?
- A
Use annotated tags that include metadata and descriptions for each release commit
- B
Rely exclusively on lightweight tags without additional metadata
- C
Adopt a clear, consistent naming convention, such as 'v1.0', 'v1.1', and so on
- D
Push your tags to the remote repository to share them with the team
- E
Configure each tag as a protected branch within the repository settings
Show answer and explanation
Correct answers: A, C, D
Explanation
Tags in Azure DevOps Git (or any Git-based system) are important for marking and referencing significant points in the repository's history, such as production releases. Following best practices�using annotated tags, employing a clear naming convention, and pushing tags to the remote�ensures that developers and automated build pipelines can reliably locate specific versions. For more information, see Microsoft's documentation on Git tagging: https://docs.microsoft.com/azure/devops/repos/git/git-tags.
- A. Correct.
Option 1 is correct. Annotated tags contain metadata like the tagger name, date, and an optional message. This helps maintain an organized reference to the specific commit and its context, making release management more transparent.
- B. Incorrect.
Option 2 is incorrect. While lightweight tags are quick to create and might be useful for minor references, they lack the descriptive metadata that Annotated tags provide. Depending on your use case, relying solely on lightweight tags can make release tracking less informative.
- C. Correct.
Option 3 is correct. A consistent naming convention (e.g., 'v1.0', 'v1.1') helps quickly identify the tag related to a given release and makes it easy for both developers and automated tools to find the correct version.
- D. Correct.
Option 4 is correct. Pushing your tags to the remote repository is essential so other team members and build pipelines have access to them. If tags are kept only locally, other collaborators or pipelines will not see them.
- E. Incorrect.
Option 5 is incorrect. Tags are not branches; therefore, configuring them as protected branches is not applicable. Protected branch rules are meant to prevent direct commits and enforce policies on long-lived branches, not on tags.