Technical Lab: Create and manage an Azure Container Registry
Questionsβ
Question 1 β Multiple Choiceβ
You need to ensure that only services running in a specific virtual network can pull images from an Azure Container Registry. Which configuration meets this requirement?
A) Enable Public network access for "Selected networks" and associate the desired subnet via Service Endpoint
B) Configure a Private Endpoint and disable public access, keeping the default registry DNS
C) Set the SKU to Premium and enable the "Allow trusted Microsoft services" option
D) Create a firewall rule with the subnet IP range in the registry Networking panel
Question 2 β Technical Scenarioβ
A CI/CD pipeline successfully executes the following command:
az acr build --registry myregistry --image app:v1 .
Subsequently, the team tries to execute:
docker pull myregistry.azurecr.io/app:v1
The command fails with an authentication error, even with Docker installed and the user having access to the Azure subscription. What is the most likely cause?
A) The az acr build command stores the image in temporary cache and it wasn't promoted to the repository
B) The registry's Basic SKU doesn't support external pull via Docker CLI
C) Local Docker isn't authenticated to the registry; it's necessary to run az acr login before the pull
D) The user needs the AcrPush role explicitly assigned to perform pulls
Question 3 β True or Falseβ
Geographic replication of an Azure Container Registry, available in the Premium SKU, automatically ensures that all replicated regions receive new images without any additional webhook or pipeline configuration.
Question 4 β Technical Scenarioβ
A team configures the following in the registry:
{
"quarantinePolicy": { "status": "enabled" },
"retentionPolicy": { "days": 7, "status": "enabled" },
"trustPolicy": { "type": "Notary", "status": "enabled" }
}
After pushing a new image, it doesn't appear available for pull immediately. What explains this behavior?
A) The retention policy retains recent images for 7 days before releasing them
B) The quarantine policy places newly pushed images in quarantine until a security check releases them
C) The trust policy requires the image to be digitally signed before any pull is allowed
D) The registry requires a manual approval webhook linked to Microsoft Defender for Containers
Question 5 β Multiple Choiceβ
When comparing Azure Container Registry SKUs, which statement correctly describes a functional difference between Basic and Premium?
A) Only the Premium SKU allows the use of az acr build for server-side builds
B) Only the Premium SKU supports geographic replication and Private Endpoint access
C) The Basic SKU doesn't offer Microsoft Entra ID integration for authentication
D) The Standard and Premium SKUs have identical storage and throughput limits
Answer Key and Explanationsβ
Answer Key β Question 1β
Answer: A
Restricting access to a specific virtual network is done via Service Endpoint with the "Selected networks" option in the registry's Networking panel. This configuration allows only traffic originating from the associated subnet to reach the registry, without exposing it publicly.
Alternative B is plausible but incomplete as a sole answer: a Private Endpoint isolates access via private IP, but the default DNS (*.azurecr.io) would continue resolving to the public address, breaking connectivity. Proper private DNS configuration would be necessary.
Alternative C (trusted Microsoft services) allows first-party Azure services like Azure Pipelines, not arbitrary virtual networks. Alternative D, firewall rule by IP, works for known public IPs, not for VNet subnets natively and manageably.
Answer Key β Question 2β
Answer: C
The az acr build command uses a managed identity from Azure CLI to send the build context and store the image, but this doesn't authenticate the local Docker daemon. For the Docker CLI to interact with the registry, it's necessary to execute az acr login --name myregistry, which obtains a temporary token and configures Docker locally.
Alternative A is a common misconception: az acr build indeed stores the image in the registry repository, not in temporary cache. Alternative B is false; all SKUs support external pull. Alternative D confuses roles: AcrPull is the role needed for pull, and AcrPush is for push. The error here, however, is authentication, not authorization.
Answer Key β Question 3β
Answer: True
Geographic replication of the Premium SKU is automatically managed by Azure. When enabling replication to an additional region, the registry begins synchronizing images to that region without the operator needing to configure pipelines, copy webhooks, or additional tasks. Azure ensures eventual consistency of images across all replicas.
The key point is that webhooks can be optionally configured per region for event notifications, but they're not necessary for replication to occur. Confusing notification webhooks with replication mechanism is a frequent conceptual error in this topic.
Answer Key β Question 4β
Answer: B
The quarantine policy, when enabled, automatically places every newly pushed image in quarantine state. The image only becomes available for pull after being explicitly released, typically by a vulnerability scanning tool integrated into the flow, such as Microsoft Defender for Containers or a third-party solution via API.
Alternative A represents a misconception about the retention policy: it defines how many days untagged images are kept before being deleted, not a grace period before availability. Alternative C is partially true regarding content signing, but the trust policy blocks pulls of unsigned images, it doesn't prevent immediate visibility of pushed images. Alternative D doesn't exist as a native registry mechanism.
Answer Key β Question 5β
Answer: B
The Premium SKU is the only one that offers support for geographic replication (geo-replication) and integration with Private Endpoint for private network access. These are exclusive capabilities of this tier and are frequently required in enterprise scenarios.
Alternative A is false: az acr build is available in all SKUs, as it's a server task execution functionality, independent of the tier. Alternative C is false: all SKUs integrate with Microsoft Entra ID for authentication. Alternative D is incorrect: Standard and Premium differ in included storage limits, throughput, and features like replication, with Premium being substantially superior.