This post is a part of the "SC-500: Implementing End-to-End Security Controls for Cloud and AI Workloads" Exam Prep Hub.
This topic falls under these sections:
Secure compute (20–25%)
--> Implement security for application platform services
--> Implement and configure security controls for Azure Container Registry
Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 4 practice tests with 30 questions each available from the hub's main page below the exam topics section.
Introduction
Azure Container Registry (ACR) is a managed private registry service for storing and managing container images and other OCI artifacts. Because container images are ultimately executed as workloads, protecting the registry is an important part of securing the container supply chain.
For the SC-500 exam, the key security areas to understand include:
- Authentication and authorization
- Azure RBAC and repository-level access
- Managed identities
- Network security
- Private endpoints
- Disabling unnecessary public access
- Container image vulnerability assessment
- Image signing and verification
- Administrative account security
- Azure Policy
- Secure integration with AKS and other Azure services
ACR supports Docker images and other OCI-compatible content, and provides Azure-based identity and RBAC capabilities for controlling access.
1. Why Azure Container Registry Security Matters
A container registry is a critical component of the software supply chain.
Consider the following process:
Developer | vSource Code | vContainer Build | vContainer Image | vAzure Container Registry | vAKS / Container Apps / Other Runtime
If an attacker compromises the registry, they may be able to:
- Push malicious images.
- Replace legitimate images.
- Delete images.
- Access proprietary application code contained in images.
- Introduce vulnerable dependencies.
- Distribute compromised images to production workloads.
Therefore, ACR security needs to protect both:
Who can access the registry
and
What content is allowed to move through the registry and into production.
2. ACR Authentication vs. Authorization
One of the most important concepts for the exam is the difference between authentication and authorization.
Authentication
Authentication answers:
Who are you?
ACR can authenticate users and applications through mechanisms including Microsoft Entra identities, service principals, managed identities, and other supported authentication methods.
Authorization
Authorization answers:
What are you allowed to do?
Azure RBAC determines what an authenticated identity can do with the registry and its contents.
For example:
Microsoft Entra identity | | Authentication vAzure Container Registry | | Authorization vAcrPull / AcrPush /Repository Reader / Writer
This distinction is fundamental to understanding ACR security.
3. Use Microsoft Entra ID and Azure RBAC
For most enterprise scenarios, use Microsoft Entra-based authentication and Azure RBAC rather than sharing registry administrator credentials.
ACR provides built-in roles designed for common registry operations.
Important roles include:
| Role | Purpose |
|---|---|
| AcrPull | Pull artifacts from a registry |
| AcrPush | Push and pull artifacts |
| AcrDelete | Delete repositories, tags, or manifests |
| AcrQuarantineReader | Read/pull quarantined artifacts |
| AcrQuarantineWriter | Manage quarantined artifacts |
The important security principle is least privilege.
For example:
Production application | +---- AcrPull | +---- Cannot push | +---- Cannot delete
A deployment identity that only needs to retrieve images should not receive AcrPush merely because that role is convenient.
Microsoft’s current role documentation confirms that AcrPull provides pull access while AcrPush provides both push and pull access.
4. Repository-Level Access with Azure ABAC
A particularly important current ACR capability is Azure attribute-based access control (ABAC) for repository permissions.
Traditional registry-wide permissions can be too broad.
For example:
Developer A | +---- AcrPull | +---- frontend +---- backend +---- database +---- internal-tools
Perhaps the developer should only be able to pull from:
frontend
ABAC can provide more granular repository-level authorization.
With an ABAC-enabled registry, roles such as:
- Container Registry Repository Reader
- Container Registry Repository Writer
- Container Registry Repository Contributor
can be scoped using conditions to specific repositories or repository prefixes.
For example:
Developer A | +---- Repository Reader | +---- frontend/*
This follows the principle of least privilege much more closely than granting registry-wide access.
Current ACR documentation states that ABAC repository permissions can use conditions to scope permissions to individual repositories or repository prefixes.
Important exam consideration
When a registry uses RBAC + ABAC Repository Permissions, legacy roles such as AcrPull, AcrPush, and AcrDelete are not honored for repository data access in the same way. The corresponding ABAC-enabled repository roles should be used.
Therefore, do not automatically assume:
AcrPullis always the correct role for every ACR configuration.
First determine whether the registry uses traditional RBAC or RBAC + ABAC repository permissions.
5. Managed Identities
Applications and Azure services often need to pull images from ACR.
A common security mistake is to store a username and password or long-lived credential in application configuration.
A better approach is to use a managed identity where the consuming Azure service supports it.
Conceptually:
Azure Service | | Managed Identity vMicrosoft Entra ID | | Authorized token vAzure Container Registry | vContainer Image
The identity can be assigned the minimum required ACR permissions.
For example, if a service only needs to pull images:
Managed Identity | +---- AcrPull
The identity does not need AcrPush.
Microsoft documents managed identity authentication for ACR specifically as a way to access private registries without placing credentials in application code.
6. Separate Push and Pull Permissions
A secure CI/CD architecture should separate responsibilities.
For example:
Build Pipeline | +---- Push | vAzure Container Registry | +---- Pull | vProduction Environment
The build pipeline might require push permissions, while the production workload only requires pull permissions.
Giving the production workload push permissions unnecessarily increases the potential impact of a compromised workload.
Microsoft’s ACR best-practice guidance recommends assigning different identities appropriate permissions for different operations, such as push permissions for build pipelines and pull permissions for deployment identities.
7. Disable the ACR Administrator Account When It Isn’t Required
ACR provides an administrator account for scenarios where it is needed, but it should not normally be the preferred enterprise authentication mechanism.
The administrator account represents a powerful shared credential and does not provide the same identity-level governance as Microsoft Entra-based access.
For enterprise environments, consider disabling the administrator account and using Microsoft Entra identities and RBAC instead.
Azure provides built-in policy definitions that can audit or modify registries to disable the local administrator account.
Security principle
Prefer:
Individual/service identity +Azure RBAC +Least privilege
over:
Shared administrator credential
8. Anonymous Pull Access
ACR normally requires authentication to pull content.
ACR also supports anonymous pull access, which makes registry content available to unauthenticated clients.
This can be appropriate when intentionally distributing public container images.
However, it is generally inappropriate for private enterprise images.
If anonymous pull is enabled:
Unauthenticated client | vAzure Container Registry | vPublicly pullable images
This can expose proprietary images or data.
Microsoft notes that anonymous pull applies to all repositories in the registry, making this setting particularly important to evaluate carefully.
Exam rule
If the requirement is:
“Only authenticated identities should be able to pull images.”
Disable anonymous pull.
9. Network Security for Azure Container Registry
Identity security alone is not enough.
An organization can also restrict where network connections to ACR can originate.
Potential controls include:
- Public network access restrictions
- IP-based network rules
- Virtual network integration/network rules where supported
- Azure Private Link
- Private endpoints
The security objective is to reduce unnecessary exposure.
10. Private Endpoints and Azure Private Link
For highly sensitive registries, organizations can use an ACR private endpoint.
Conceptually:
Azure VNet
|
+--------+--------+
| |
AKS Cluster Build System
| |
+--------+--------+
|
Private Endpoint
|
v
Azure Container Registry
The registry can then be accessed using a private IP through the Azure virtual network.
This is particularly useful when:
- Production workloads use private networking.
- Public network access should be eliminated.
- Registry access must remain inside controlled networks.
- Data leakage risks need to be reduced.
Current Azure Policy definitions include controls for configuring ACR private endpoints and disabling public network access.
11. Public Network Access
An organization may choose to disable public network access to ACR.
This creates a stronger network boundary:
Internet | X | X---- Public ACR access disabled |Private Azure Network | vPrivate Endpoint | vACR
This does not replace authentication and authorization.
Instead:
Network controls determine where the registry can be reached; identity controls determine who can use it.
Defense in depth uses both.
12. Trusted Azure Services
Network restrictions can sometimes interfere with Azure services that need to access a registry.
ACR supports a mechanism that allows selected trusted Azure services to access network-restricted registries in supported scenarios.
This is important when a registry has:
- Private endpoints
- IP restrictions
- Other network restrictions
and a Microsoft service needs access to registry content.
For example, Microsoft Defender for Cloud may need to pull images to perform vulnerability assessment.
Microsoft documents a trusted-services mechanism for supported network-restricted ACR scenarios.
Exam consideration
If you restrict ACR networking and a Microsoft service can no longer perform an expected operation, determine whether that service requires a trusted-service exception or another supported connectivity configuration.
13. Encrypting ACR Data at Rest
ACR data is encrypted at rest by default using service-managed encryption.
For scenarios requiring greater control over encryption keys, supported ACR configurations can use customer-managed keys (CMKs).
Conceptually:
Azure Container Registry | | Encryption at rest vCustomer-managed key | vAzure Key Vault
Customer-managed keys can be useful for organizations with:
- Regulatory requirements
- Key-management requirements
- Internal encryption policies
- Requirements for customer control over the encryption key lifecycle
Azure Policy includes built-in controls that can audit or deny registries that do not use customer-managed keys where required.
14. Container Image Vulnerability Assessment
A container image can contain vulnerabilities even when the application itself was developed securely.
For example:
Application | +-- Vulnerable operating-system package | +-- Vulnerable library | +-- Outdated framework | +-- Known CVE
Microsoft Defender for Cloud can scan ACR images for known vulnerabilities.
When vulnerabilities are found, Defender for Cloud can provide recommendations for remediation.
After an image is replaced with a remediated version, Defender can rescan the image.
15. Vulnerability Scanning vs. Image Signing
These concepts are easy to confuse.
Vulnerability scanning asks:
Does this image contain known security vulnerabilities?
Image signing asks:
Can I verify that this image came from a trusted publisher and has not been altered?
These address different risks.
| Security question | Control |
|---|---|
| Does the image contain known CVEs? | Vulnerability assessment |
| Who published the image? | Image signing |
| Has the signed artifact been modified? | Signature verification |
| Should this image be allowed into production? | Policy/admission controls |
A mature container security architecture can use both.
16. Image Signing and Supply Chain Security
Container images are part of the software supply chain.
An attacker could attempt to:
- Compromise a build system.
- Modify an image.
- Push the modified image.
- Deploy the malicious image into production.
Image signing helps establish:
- Authenticity — the artifact came from a trusted publisher.
- Integrity — the artifact has not been altered since signing.
Current Azure guidance uses Notation, based on the Notary Project, for signing and verifying OCI artifacts. A signature can be verified before an artifact is consumed or deployed.
17. Notation and Artifact Signing
A current approach is:
Build Image | vAzure Container Registry | vSign Image | vDeploy | vVerify Signature | +---- Valid -----> Allow | +---- Invalid ---> Block
Azure Artifact Signing can be used with Notation to sign container images.
Azure Key Vault can also participate in certificate-based signing scenarios.
Microsoft’s current guidance identifies Artifact Signing as an alternative to using Azure Key Vault for the signing service, with Artifact Signing providing managed certificate lifecycle capabilities.
18. Verifying Images Before AKS Deployment
Image signing becomes particularly powerful when combined with AKS policy enforcement.
A security architecture can require:
Only container images with valid signatures from trusted publishers may run.
Conceptually:
Developer | vSigned Image | vACR | vAKS Deployment | vSignature Verification | +---- Trusted -----> Run | +---- Untrusted ---> Reject
Microsoft’s current ACR signing guidance describes using Notation, Ratify, and Azure Policy to verify image signatures for AKS deployments.
19. Azure Policy for ACR
Azure Policy can be used to establish organizational security requirements for container registries.
Examples of policy requirements include:
- Disable anonymous authentication.
- Disable the ACR administrator account.
- Disable public network access.
- Require private endpoints.
- Require customer-managed keys.
- Require vulnerability remediation.
- Disable repository-scoped access tokens where organizational policy requires it.
- Disable certain authentication mechanisms.
Current built-in ACR policy definitions include controls for these areas.
This allows organizations to move from:
Security recommendation
to:
Governance rule
and, where appropriate:
Preventive enforcement
20. ACR Security and AKS
ACR and AKS are commonly used together.
A secure architecture might look like this:
Developer
|
v
Build Pipeline
|
Push Image
|
v
+----------------------+
| Azure Container |
| Registry |
| |
| RBAC / ABAC |
| Private Endpoint |
| Vulnerability Scan |
| Image Signing |
+----------+-----------+
|
| Pull
v
+-------------+
| AKS |
| |
| Azure Policy|
| Ratify |
+-------------+
|
v
Running Pods
Each component addresses a different security concern.
21. ACR Security for CI/CD Pipelines
CI/CD pipelines require special attention because they frequently have elevated registry permissions.
A common secure design is:
Developer | vSource Repository | vCI Pipeline | | Push permission vACR | | Pull permission vCD / AKS
The CI identity might have:
Push + Pull
while the production workload has:
Pull only
This prevents a compromised production workload from automatically obtaining the ability to modify images.
22. Avoid Secrets in Container Images
Never embed registry credentials inside a container image.
For example, avoid:
Dockerfile | +-- USERNAME=... +-- PASSWORD=...
Why?
Because anyone who can obtain the image may potentially extract those values.
Instead, use:
- Microsoft Entra authentication
- Managed identities
- Workload identities
- Key Vault
- Secure CI/CD authentication mechanisms
The principle is:
Credentials should be external to the image whenever possible.
23. ACR Security Control Decision Matrix
| Requirement | Recommended control |
|---|---|
| Authenticate developers | Microsoft Entra ID |
| Pull-only access | AcrPull |
| Push and pull access | AcrPush |
| Repository-specific access | ABAC repository permissions |
| Azure workload access | Managed identity |
| Prevent unauthenticated pulls | Disable anonymous pull |
| Remove shared admin credentials | Disable ACR admin account |
| Restrict network access | Network rules/private networking |
| Eliminate public exposure | Private endpoint + disable public access |
| Protect data at rest with customer-controlled keys | Customer-managed key |
| Detect known CVEs | Defender vulnerability assessment |
| Establish artifact authenticity | Image signing |
| Verify signed images | Notation / verification tooling |
| Enforce signed-image deployment | Azure Policy + signature verification |
| Enforce registry security configuration | Azure Policy |
24. Common Exam Scenarios
Scenario 1: AKS only needs to pull images
An AKS workload needs to pull images from ACR but must not be able to push images.
Best choice: Assign the identity the minimum pull permission, such as AcrPull in an RBAC-only registry, or the appropriate ABAC-enabled repository reader role in an ABAC-enabled registry.
Scenario 2: Build pipeline needs to publish images
A CI/CD pipeline builds images and pushes them to ACR.
Best choice: Give the pipeline identity appropriate push permissions.
Do not give production workloads the same permissions simply because they use the same registry.
Scenario 3: Only one repository should be accessible
A developer should access only:
frontend/*
but not:
backend/*database/*
Best choice: Use ACR’s ABAC repository permissions to scope access to the appropriate repository or repository prefix.
Scenario 4: No public registry access
A company requires the production registry to be accessible only from its Azure virtual network.
Best choice: Use a private endpoint/Private Link and disable public network access as appropriate.
Scenario 5: Detect vulnerable images
Security operations wants to identify known CVEs in images stored in ACR.
Best choice: Use Microsoft Defender for Cloud’s container image vulnerability assessment capabilities.
Scenario 6: Ensure images haven’t been tampered with
The organization wants to verify that production images came from approved publishers and were not altered.
Best choice: Implement container image signing and signature verification.
Scenario 7: Prevent anonymous access
The registry contains proprietary application images.
Best choice: Disable anonymous pull access.
25. Common Mistakes to Avoid
Mistake 1: Giving every developer AcrPush
If a developer only needs to pull images, AcrPush is excessive.
Use least privilege.
Mistake 2: Using the administrator account everywhere
The ACR admin account should not become the default enterprise authentication mechanism.
Mistake 3: Assuming network security replaces identity security
A private endpoint does not eliminate the need for authentication and authorization.
Mistake 4: Confusing vulnerability scanning with signing
A vulnerability scan does not prove that an image came from a trusted publisher.
Likewise, a valid signature does not mean an image contains no vulnerabilities.
Mistake 5: Granting registry-wide access when repository-level access is sufficient
Use repository-level ABAC permissions where the scenario requires granular access.
Mistake 6: Forgetting production pull-only requirements
Production workloads normally should not need permission to modify the images they consume.
26. Key SC-500 Takeaways
For the exam, remember these relationships:
Microsoft Entra ID
→ Provides identity-based authentication.
Azure RBAC
→ Determines what an identity can do.
AcrPull
→ Pull artifacts from an RBAC-only registry.
AcrPush
→ Push and pull artifacts in an RBAC-only registry.
ABAC repository permissions
→ Provide more granular repository-specific authorization.
Managed identity
→ Allows supported Azure resources to access ACR without storing credentials.
Private endpoint
→ Provides private connectivity to ACR.
Disable public network access
→ Prevents access through the public network where supported/configured.
Disable anonymous pull
→ Requires authentication for image pulls.
Defender for Cloud
→ Provides container image vulnerability assessment and security recommendations.
Image signing
→ Establishes artifact authenticity and integrity.
Notation
→ Provides current tooling for signing and verifying OCI artifacts.
Azure Policy
→ Provides centralized governance and enforcement of ACR security requirements.
Practice Exam Questions
Question 1
A company has an Azure Container Registry that stores proprietary production images. The security team requires that unauthenticated users must not be able to pull any image from the registry.
Which configuration should you implement?
A. Disable anonymous pull access
B. Enable the ACR administrator account
C. Assign AcrPush to all users
D. Enable public network access
Answer: A
Explanation: Anonymous pull allows unauthenticated clients to pull registry content. Disabling anonymous pull ensures that clients must authenticate before pulling images. RBAC should then determine what authenticated identities are authorized to access.
Question 2
A production application needs to retrieve container images from ACR. The application does not need to push, delete, or modify images. The organization wants to avoid storing registry credentials in application configuration.
Which approach provides the best solution?
A. Use a managed identity with pull-only permissions
B. Store the ACR administrator password in the application settings
C. Give the application AcrPush
D. Enable anonymous pull
Answer: A
Explanation: A managed identity allows a supported Azure resource to authenticate to ACR without embedding credentials in application code. The identity should receive only the permissions required to pull images.
Question 3
A company uses an ACR registry with Azure RBAC + ABAC Repository Permissions. A developer should be able to pull images only from the frontend repository and must not access backend.
Which approach should be used?
A. Assign Owner at the subscription level
B. Assign AcrPush at the registry level
C. Assign an ABAC-enabled repository reader role with a condition restricting access to frontend
D. Enable anonymous pull and rely on repository naming conventions
Answer: C
Explanation: ABAC repository permissions allow an ACR role assignment to be constrained to specific repositories or repository prefixes. This provides much more precise least-privilege access than registry-wide permissions.
Question 4
A security team wants to prevent the production ACR from being reachable through the public internet. AKS and build systems that require access to the registry operate within an Azure virtual network.
Which solution should the team consider?
A. Enable anonymous pull
B. Assign AcrPush to the AKS cluster
C. Enable the ACR administrator account
D. Configure an ACR private endpoint and restrict or disable public network access
Answer: D
Explanation: An ACR private endpoint provides private connectivity through Azure Private Link. Combining private connectivity with appropriate public network restrictions can prevent unintended public exposure.
Question 5
A security operations team wants to identify known CVEs in container images stored in ACR and receive recommendations for remediation.
Which service should they use?
A. Microsoft Defender for Cloud
B. Azure DNS
C. Azure Private Link
D. Microsoft Entra ID
Answer: A
Explanation: Microsoft Defender for Cloud can perform container image vulnerability assessment for supported ACR scenarios and provide recommendations when vulnerabilities are identified.
Question 6
A development organization wants to ensure that only images produced by an approved build organization can be deployed into production. It also wants to detect whether an image has been altered after it was signed.
Which security capability directly addresses these requirements?
A. Azure RBAC
B. Container image signing and signature verification
C. Anonymous pull access
D. Network Security Groups
Answer: B
Explanation: Image signing establishes artifact authenticity and integrity. Signature verification can confirm that an image was signed by a trusted publisher and has not been altered since signing.
Question 7
A CI/CD service builds container images and publishes them to ACR. A production AKS workload only needs to retrieve those images.
Which permission model follows the principle of least privilege?
A. Give both identities AcrPush
B. Give both identities Owner
C. Give the CI/CD identity push permissions and the production workload pull-only permissions
D. Give the production workload the ACR administrator account
Answer: C
Explanation: The build pipeline needs to publish images, while the production workload only needs to consume them. Separating push and pull permissions reduces the potential impact of a compromised production workload.
Question 8
An organization wants Azure Policy to identify ACR instances that do not have their local administrator account disabled.
What is the primary purpose of this policy?
A. Detect container image vulnerabilities
B. Enforce or audit registry security configuration
C. Sign container images
D. Encrypt container images during execution
Answer: B
Explanation: Azure Policy provides centralized governance and can audit or modify supported ACR configurations. Disabling the local administrator account is a registry configuration requirement, not a vulnerability-scanning or image-signing function.
Question 9
A company has disabled public access to an ACR through network restrictions. Microsoft Defender for Cloud is expected to scan images in the registry, but the scans are failing because the service cannot access the registry.
What should the security engineer investigate first?
A. Whether supported trusted-service access/network configuration is enabled for the restricted registry
B. Whether anonymous pull is enabled
C. Whether every developer has AcrPush
D. Whether the registry administrator account is enabled
Answer: A
Explanation: Defender for Cloud needs to access images to perform vulnerability scanning. When ACR is protected by network restrictions, the organization should verify the supported trusted-service/network configuration that allows the Microsoft service to access the registry.
Question 10
An organization wants to establish a complete security process for production container images. The requirements are:
- Detect known vulnerabilities.
- Verify image authenticity.
- Prevent unauthorized images from being deployed.
- Limit who can modify images.
Which combination provides the strongest solution?
A. Anonymous pull, public network access, and AcrPush
B. Vulnerability assessment, image signing/verification, Azure Policy enforcement, and least-privilege RBAC/ABAC
C. ACR administrator account and public IP restrictions only
D. Azure DNS and Network Security Groups only
Answer: B
Explanation: These controls address different stages of the container supply chain. Vulnerability assessment identifies known security weaknesses, signing and verification establish authenticity and integrity, Azure Policy can enforce organizational deployment/governance requirements, and RBAC/ABAC limits who can modify or access registry content. Together they provide defense in depth.
Final Word
This topic is especially important for SC-500 because it ties identity, least privilege, network security, vulnerability management, governance, and software supply-chain security together. The biggest distinctions to remember are AcrPull vs. AcrPush, RBAC vs. ABAC repository permissions, private endpoint vs. identity controls, vulnerability scanning vs. image signing, and Azure Policy vs. Defender for Cloud.
Go to the SC-500 Exam Prep Hub main page
