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
    |
    v
Source Code
    |
    v
Container Build
    |
    v
Container Image
    |
    v
Azure Container Registry
    |
    v
AKS / 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
        v
Azure Container Registry
        |
        | Authorization
        v
AcrPull / 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:

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:

AcrPull is 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
      v
Microsoft Entra ID
      |
      | Authorized token
      v
Azure Container Registry
      |
      v
Container 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
      |
      v
Azure Container Registry
      |
      +---- Pull
      |
      v
Production 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
        |
        v
Azure Container Registry
        |
        v
Publicly 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
   |
   v
Private Endpoint
   |
   v
ACR

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
        v
Customer-managed key
        |
        v
Azure 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.

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:

1. Compromise a build system.
2. Modify an image.
3. Push the modified image.
4. 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
    |
    v
Azure Container Registry
    |
    v
Sign Image
    |
    v
Deploy
    |
    v
Verify 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
    |
    v
Signed Image
    |
    v
ACR
    |
    v
AKS Deployment
    |
    v
Signature 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
    |
    v
Source Repository
    |
    v
CI Pipeline
    |
    | Push permission
    v
ACR
    |
    | Pull permission
    v
CD / 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

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