Explanation

Box 1: A deployment group
When authoring an Azure Pipelines or TFS Release pipeline, you can specify the deployment targets for a job using a deployment group.
If the target machines are Azure VMs, you can quickly and easily prepare them by installing the Azure Pipelines Agent Azure VM extension on each of the VMs, or by using the Azure Resource Group Deployment task in your release pipeline to create a deployment group dynamically.
Box 2: A deployment group
References: https://docs.microsoft.com/en-us/azure/devops/pipelines/release/deployment-groups

Box 1; tag
Tagging. Like most VCSs, Git has the ability to tag specific points in a repository's history as being important.
Typically, people use this functionality to mark release points (v1.0, v2.0 and so on).
Box 2: -a
Creating an annotated tag in Git is simple. The easiest way is to specify -a when you run the tag command:
Example:
$ git tag -a v1.4 -m "my version 1.4"
Box 3: -m
Reference:
https://git-scm.com/book/en/v2/Git-Basics-Tagging

Explanation:
App1: Canary deployment
With canary deployment, you deploy a new application code in a small part of the production infrastructure. Once the application is signed off for release, only a few users are routed to it. This minimizes any impact.
With no errors reported, the new version can gradually roll out to the rest of the infrastructure.
App2: Rolling deployment:
In a rolling deployment, an application's new version gradually replaces the old one. The actual deployment happens over a period of time. During that time, new and old versions will coexist without affecting functionality or user experience. This process makes it easier to roll back any new component incompatible with the old components.
Incorrect Answers:
Blue/Green deployment
A blue/green deployment is a change management strategy for releasing software code. Blue/green deployments, which may also be referred to as A/B deployments require two identical hardware environments that are configured exactly the same way. While one environment is active and serving end users, the other environment remains idle.
Blue/green deployments are often used for consumer-facing applications and applications with critical uptime requirements. New code is released to the inactive environment, where it is thoroughly tested. Once the code has been vetted, the team makes the idle environment active, typically by adjusting a router configuration to redirect application program traffic. The process reverses when the next software iteration is ready for release.
References:
https://dev.to/mostlyjason/intro-to-deployment-strategies-blue-green-canary-and-more-3a3

Feeds have four levels of access: Owners, Contributors, Collaborators, and Readers. Owners can add any type of identity-individuals, teams, and groups-to any access level.

Reference:
https://docs.microsoft.com/en-us/azure/devops/artifacts/feeds/feed-permissions