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 Instances and Azure Container Apps

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 provides several ways to run containerized workloads. Two important services are:

• Azure Container Instances (ACI) — a serverless container service designed for running containers or container groups without managing virtual machines or a Kubernetes cluster.
• Azure Container Apps (ACA) — a managed application platform designed for containerized applications, microservices, APIs, background jobs, and event-driven workloads.

From a security perspective, both services support important controls around identity, authentication, secrets, networking, container images, and workload isolation. However, the implementation details differ.

Azure Container Instances (ACI) and Azure Container Apps (ACA) provide different levels of abstraction and therefore expose different security controls. The key for the SC-500 exam is understanding which security mechanism belongs to which service and how to combine identity, secrets, networking, image security, and workload isolation.

For the SC-500 exam, you should be able to determine:

1. How to authenticate containers to Azure resources.
2. How to avoid embedding credentials in container images.
3. How to secure container image retrieval.
4. How to restrict network exposure.
5. How to secure inbound application traffic.
6. How to protect secrets.
7. How to use Microsoft Entra ID and managed identities.
8. How Azure Container Apps environments provide security boundaries.
9. When to use private networking.
10. How security controls differ between ACI and Azure Container Apps.

1. Azure Container Instances vs. Azure Container Apps

Although both services run containers, they address different workload requirements.

ACI is often appropriate when you simply need to run a container without managing an orchestration platform. Azure Container Apps provides more application-level security and networking capabilities for long-running applications and microservices.

2. Secure Azure Container Instances

2.1 Use managed identities instead of embedded credentials

One of the most important security practices for ACI is to avoid placing Azure credentials inside:

• Container images
• Source code
• Configuration files
• Dockerfiles
• Plain-text environment variables

ACI supports managed identities, allowing a container group to authenticate to Azure resources that support Microsoft Entra authentication without embedding credentials in the container.

For example, an ACI workload might need to access:

• Azure Key Vault
• Azure Storage
• Azure Container Registry
• Other Azure services supporting Microsoft Entra authentication

The basic pattern is:

ACI container → Managed identity → Microsoft Entra ID → Azure resource

The Azure resource is then protected through Azure RBAC or the applicable authorization mechanism.

Why this matters

Suppose a developer puts an Azure service principal password into a Docker image:

Docker image
   |
   +-- application
   +-- connection string
   +-- client secret

Anyone who gains access to the image may potentially obtain the credential.

A managed identity removes the need to distribute that credential with the container.

3. Use managed identity for ACR image pulls

ACI can use a managed identity to authenticate to Azure Container Registry (ACR) when pulling private container images.

This is particularly valuable when the ACR itself is protected using a private endpoint.

The architecture can look like:

                 Azure VNet
                     |
       +-------------+-------------+
       |                           |
       |                        Private
       |                       Endpoint
       |                           |
   ACI Container  ------------>  ACR
       |
       |
 Managed Identity
       |
 Microsoft Entra ID

ACI can therefore retrieve a private image without storing an ACR username and password in the container configuration. Microsoft specifically documents managed-identity-based ACR authentication for ACI, including scenarios where ACR access is restricted through a private endpoint.

Exam point

If the question asks:

“How should an ACI container securely authenticate to a private Azure Container Registry?”

A strong answer is:

Use a managed identity and grant that identity the required ACR permissions.

Do not choose an embedded registry password when a managed identity is available.

4. Secure ACI environment variables

ACI supports environment variables for passing configuration information to containers.

However, there is an important distinction between ordinary environment variables and secure environment variables.

A regular environment variable can expose its value through container configuration.

A secure environment variable uses the secureValue property. Its value isn’t exposed through the container’s properties, although the running application can access it from inside the container.

For example:

environmentVariables:
  - name: APP_MODE
    value: "production"
  - name: DATABASE_PASSWORD
    secureValue: "secret-value"

The second value is protected from being displayed through the container properties.

Important security consideration

Secure environment variables are better than placing secrets directly into an image, but for production architectures, centralized secret management such as Azure Key Vault is generally preferable when practical.

5. ACI secret volumes

ACI also supports secret volumes.

A secret volume allows secrets to be mounted as files inside the container.

For example:

/mnt/secrets/
    database-password
    api-key

Secret volumes are currently supported for Linux containers.

This can be useful when an application expects credentials or configuration to be provided as files rather than environment variables.

Exam distinction

Remember:

• Secure environment variables → sensitive values exposed to the application as environment variables.
• Secret volumes → sensitive values mounted as files.
• Managed identity → eliminates the need for stored Azure credentials when the target service supports Microsoft Entra authentication.
• Azure Key Vault → centralized service for protecting secrets, keys, and certificates.

6. Protect container images

Container security begins before the container is deployed.

A compromised or vulnerable image can introduce risk even if the container’s networking and identity controls are configured correctly.

Microsoft recommends using a private registry, scanning container images for vulnerabilities, and protecting credentials used to access containers and registries.

A common architecture is:

Developer / CI/CD
       |
       v
Azure Container Registry
       |
       | vulnerability scanning
       | access controls
       |
       v
ACI / Azure Container Apps

Security controls should include:

• Private container registries
• Microsoft Entra authentication
• Managed identities
• Least-privilege registry permissions
• Image vulnerability scanning
• Secure CI/CD pipelines
• Regular image updates
• Avoidance of embedded credentials

Important distinction

Image vulnerability scanning and image signing solve different problems.

A signed image can still contain a vulnerability.

7. Network security for Azure Container Instances

ACI can be integrated with an Azure virtual network.

This allows containers to participate in private network architectures rather than exposing every workload directly to the public internet.

A common security architecture is:

                Azure VNet
                    |
       +------------+-------------+
       |                          |
   ACI subnet                Private services
       |                          |
       +-------- Private ----------+
                connectivity

Network design should follow least privilege:

• Use private networking where appropriate.
• Avoid unnecessary public exposure.
• Restrict access to required destinations.
• Use appropriate NSG and routing controls where supported by the architecture.
• Protect backend services with private endpoints when appropriate.

For sensitive workloads, the objective should be to minimize the number of public endpoints.

8. Confidential containers in ACI

For workloads requiring particularly strong protection of data while it is being processed, Azure Container Instances supports confidential container deployments.

Confidential containers use a trusted execution environment (TEE) to provide hardware-based confidentiality and integrity protections.

This is particularly relevant when an organization has requirements involving:

• Highly sensitive data
• Data-in-use protection
• Strong workload isolation
• Regulatory requirements
• Protection from certain infrastructure-level threats

Exam concept

Confidential containers address a different security problem than encryption at rest.

Think of the three states of data:

9. Secure Azure Container Apps

Azure Container Apps provides additional application-level security capabilities beyond the basic container execution model.

A Container Apps environment acts as a security boundary around container apps and jobs. The environment has a virtual network, either one created and managed by Azure or one supplied by the customer.

This makes the environment an important architectural security boundary.

A typical architecture is:

                 Container Apps Environment
                 ---------------------------
                 |                         |
             Frontend                   Backend
           Container App              Container App
                 |                         |
                 +-------- Internal -------+
                          traffic

A useful security design is to place related applications in the same environment while separating workloads that require stronger isolation.

For example:

• Production environment
• Development environment
• Test environment

Separating environments can reduce the possibility of accidental cross-environment access and configuration drift.

10. Managed identities in Azure Container Apps

Azure Container Apps supports both:

• System-assigned managed identities
• User-assigned managed identities

A system-assigned identity is associated with the lifecycle of the container app.

A user-assigned identity is an independent Azure resource and can be assigned to multiple resources.

System-assigned identity

A good choice when:

One application needs its own identity and the identity should have the same lifecycle as the application.

User-assigned identity

A good choice when:

An identity needs to exist independently of a particular application or potentially be reused.

11. Managed identities for Azure Container Registry

Container Apps can use managed identity to pull images from a private Azure Container Registry.

This eliminates the need to put registry credentials into application configuration.

A particularly strong design is to use a dedicated identity for container registry access, separate from the identity used by the application itself when appropriate.

This supports better separation of duties and least privilege.

For example:

                Azure Container Apps
                       |
            +----------+----------+
            |                     |
      Workload Identity       ACR Identity
            |                     |
            v                     v
      Key Vault / APIs          ACR

The application doesn’t need the same permissions required to pull images.

12. Protect secrets in Container Apps

Container Apps provides application-level secrets.

Secrets can be referenced by revisions and can also be referenced from Azure Key Vault.

For production workloads, a preferred pattern is:

Container App
      |
Managed Identity
      |
      v
 Azure Key Vault
      |
      v
   Secret

The managed identity is granted permission to retrieve the required secret.

For example, Microsoft documents using the Key Vault Secrets User role for a managed identity that needs to retrieve secrets from Key Vault.

Why Key Vault is preferable

Instead of:

Container App
   |
   +-- password
   +-- API key
   +-- connection string

use:

Container App
      |
Managed Identity
      |
      v
Key Vault
      |
      +-- password
      +-- API key
      +-- connection string

This provides centralized secret management and reduces the need to distribute credentials.

13. Understand Container Apps secret lifecycle

An important exam detail is that Container Apps secrets are application-scoped rather than revision-specific.

Multiple revisions can reference the same secret. Changing a secret doesn’t automatically create a new revision. Existing revisions may need to be restarted or a new revision deployed so that the updated value is loaded.

This distinction is important in questions involving secret rotation.

Example

Suppose Revision 1 and Revision 2 both use:

DATABASE_PASSWORD

The administrator changes the secret.

The change does not automatically mean that every running revision instantly reloads the new value.

The application must be restarted or a new revision deployed as appropriate.

14. Secure Container Apps ingress

Container Apps provides configurable ingress.

Ingress can be:

• External
• Internal

External ingress exposes the application through the environment’s inbound endpoint.

Internal ingress restricts application access to the appropriate internal environment/network boundary.

Security principle

Do not make every microservice publicly accessible.

For example:

Internet
   |
   v
Frontend API
   |
   | internal
   v
Order Service
   |
   | internal
   v
Database Service

Only the component that genuinely needs internet exposure should use external ingress.

15. Enforce HTTPS

Container Apps supports HTTP and HTTPS traffic through its ingress configuration.

The allowInsecure setting determines whether insecure HTTP connections are allowed. For secure applications, disable insecure connections so that traffic is protected using HTTPS.

The security principle is straightforward:

Do not permit unencrypted application traffic when the workload requires protected communications.

This is particularly important for:

• Authentication tokens
• Session information
• Personally identifiable information
• API requests
• Credentials
• Sensitive business data

16. Built-in authentication and authorization

Azure Container Apps includes built-in authentication and authorization capabilities, sometimes referred to as Easy Auth.

It can integrate with Microsoft Entra ID and other supported identity providers.

This is useful when an application needs to protect an externally accessible endpoint without requiring the application developers to implement the entire authentication mechanism themselves.

For example:

User
 |
 v
Container Apps ingress
 |
 v
Authentication layer
 |
 +---- unauthenticated --> sign-in
 |
 +---- authenticated ----> Application

The built-in authentication layer runs separately from the application code and can pass authenticated identity information to the application.

Exam distinction

Do not confuse:

Managed identity

with:

Container Apps built-in authentication

Managed identity is primarily about the application authenticating to other Azure resources.

Built-in authentication is primarily about users or clients authenticating to the Container App.

17. Client certificate authentication

For higher-assurance application scenarios, Container Apps supports client certificate authentication/mutual TLS scenarios.

With mTLS, both sides participate in certificate-based authentication:

Client certificate
       |
       v
Container App
       |
Server certificate
       |
       v
Authenticated TLS connection

This can provide stronger service-to-service or client-to-service authentication than relying solely on a shared secret.

18. Private endpoints for Container Apps

For environments requiring private access, Azure Container Apps supports private endpoints.

A private endpoint provides private connectivity to the Container Apps environment through an Azure virtual network.

When using a private endpoint, public network access can be disabled so that connectivity occurs through the controlled private network path.

Private endpoint architectures also require appropriate private DNS configuration.

A simplified architecture is:

Corporate network
       |
 VPN / ExpressRoute
       |
 Azure VNet
       |
 Private Endpoint
       |
 Container Apps Environment
       |
 Container App

This is preferable to exposing a sensitive application directly to the public internet.

19. Control outbound traffic

Security isn’t limited to inbound traffic.

A compromised container may attempt to communicate with malicious external infrastructure.

For Container Apps environments integrated with a customer-managed VNet, outbound traffic can be controlled using mechanisms such as:

• Azure Firewall
• User-defined routes
• Network security groups where applicable
• Private endpoints
• Destination allowlists

Microsoft recommends using Azure Firewall with UDRs when centralized outbound inspection and control are required.

The security objective is:

Allow workloads to communicate only with destinations they actually need.

20. Network security groups and Container Apps

When using a customer-managed virtual network, NSGs can provide additional traffic controls.

However, an important architectural distinction is that the automatically generated Microsoft-managed VNet for a Container Apps environment isn’t equivalent to a customer-managed VNet that you can freely modify.

For security-sensitive architectures requiring extensive network control, use an appropriate customer-managed networking design. Microsoft notes that a Microsoft-managed VNet can’t be manipulated in the same way as a customer-managed VNet, such as adding NSGs or forcing traffic through an egress firewall.

This is an excellent SC-500 scenario distinction.

21. Peer-to-peer encryption

Container Apps environments can support encryption for peer-to-peer application traffic.

When enabled, traffic between applications can use TLS encryption within the environment. Microsoft notes that enabling peer-to-peer encryption can have performance implications and that built-in peer-to-peer encryption provides authentication of applications but not application-level authorization between them.

Therefore:

Encryption does not automatically mean authorization.

An application may still need its own authorization controls to determine whether another application is permitted to perform a particular operation.

22. Protect container images in Container Apps

The same container supply-chain principles that apply to ACI apply to Container Apps.

Use:

• Private ACR
• Managed identities
• Least-privilege registry access
• Image vulnerability scanning
• Secure CI/CD
• Trusted image sources
• Image signing where appropriate
• Current base images
• Minimal container images

A container application should not automatically trust an image simply because it came from a registry.

The registry itself must also be protected.

23. Resource limits and denial-of-service considerations

Container Apps supports resource allocation and scaling controls.

Appropriate CPU, memory, replica, and scaling limits can reduce the impact of resource exhaustion and help prevent one workload from consuming disproportionate resources.

Microsoft’s current Container Apps security guidance specifically recommends appropriate scaling and resource limits and monitoring scaling events for unusual patterns.

For exam questions, remember:

Availability is part of security.

Security isn’t only about confidentiality and authentication.

24. ACI security architecture

A strong ACI architecture might look like this:

                 Azure Container Registry
                         |
                  Managed Identity
                         |
                         v
                  Private Endpoint
                         |
                    Azure VNet
                         |
                         v
                +----------------+
                | ACI Container  |
                |     Group      |
                +----------------+
                         |
                  Managed Identity
                         |
             +-----------+-----------+
             |                       |
             v                       v
         Key Vault                Storage

Security controls include:

• Private registry
• Managed identity
• Private networking
• Least-privilege RBAC
• Secure secrets
• Image scanning
• Optional confidential containers
• Appropriate monitoring

25. Container Apps security architecture

A stronger application-oriented architecture could look like:

                         Internet
                            |
                            v
                    External Ingress
                            |
                     Authentication
                            |
                            v
                    Frontend/API App
                            |
                       Internal
                        ingress
                            |
                            v
                     Backend App
                            |
                  Managed Identity
                            |
              +-------------+-------------+
              |                           |
              v                           v
          Key Vault                    Azure SQL

Security controls include:

• External/internal ingress
• Microsoft Entra authentication
• Managed identities
• Key Vault
• Private endpoints
• HTTPS
• Network segmentation
• Azure Firewall where appropriate
• Image security
• Resource/scaling controls
• Environment separation

26. ACI vs. Container Apps security decision matrix

27. Common SC-500 mistakes to avoid

Mistake 1: Putting credentials into a container image

Never place passwords, API keys, registry credentials, or Azure service principal secrets in a Dockerfile or container image.

Use managed identities or a secure secret-management solution.

Mistake 2: Assuming a private registry makes an application secure

A private registry controls access to the image repository.

It does not automatically:

• Authenticate users to the application
• Secure application traffic
• Protect secrets
• Prevent vulnerabilities in the image

Security must be layered.

Mistake 3: Confusing managed identity with user authentication

Managed identity:

Container → Azure resource

Built-in authentication:

User/client → Container App

This distinction is frequently tested in scenario questions.

Mistake 4: Making every Container App externally accessible

Microservices that don’t require internet access should generally use internal communication rather than external ingress.

Mistake 5: Assuming encryption provides authorization

TLS protects communications.

It does not determine whether a caller is authorized to perform an operation.

Authentication and authorization are separate controls.

Mistake 6: Assuming image scanning means an image is trusted

Scanning identifies known vulnerabilities.

It does not prove that an image came from an authorized publisher.

Image signing addresses authenticity and integrity.

Mistake 7: Forgetting outbound traffic

A secure workload must consider both:

• Inbound traffic
• Outbound traffic

Azure Firewall and controlled routing can help enforce outbound policies in appropriate Container Apps network architectures.

28. Key SC-500 takeaways

For this topic, remember these core relationships:

Azure Container Instances

Managed identity
→ Authenticate to Azure resources without embedded credentials.

Managed identity + ACR
→ Secure private image pulls.

Secure environment variables / secret volumes
→ Protect sensitive runtime values.

VNet integration
→ Provide private networking options.

Confidential containers
→ Protect sensitive workloads using hardware-backed trusted execution environments.

Azure Container Apps

Environment
→ Security boundary for container apps and jobs.

Managed identity
→ Credential-free access to Azure resources.

Key Vault
→ Centralized secret management.

Internal ingress
→ Keep backend applications from unnecessary internet exposure.

External ingress
→ Expose applications that genuinely require external access.

Built-in authentication
→ Protect externally accessible applications with identity providers such as Microsoft Entra ID.

Private endpoint
→ Provide private connectivity to the Container Apps environment.

Azure Firewall + UDR
→ Control and inspect outbound traffic when the network architecture supports it.

HTTPS
→ Protect application traffic in transit.

Resource/scaling limits
→ Help protect availability and reduce resource-exhaustion risk.

Practice Exam Questions

Question 1

A company runs an Azure Container Instance that needs to pull a private image from Azure Container Registry. The security team doesn’t want registry usernames or passwords stored in the deployment configuration.

What should you implement?

A. A registry administrator username embedded in the container image

B. An anonymous ACR pull configuration

C. A managed identity assigned to the ACI container group with the required ACR permissions

D. A public container registry

Answer: C

Explanation: ACI supports managed identities for authenticating to ACR. The identity can be granted the required permissions, eliminating the need to store registry credentials in the container configuration. This is especially useful when the registry is private.

Question 2

An organization runs a backend API in Azure Container Apps. The API should be accessible only by other applications within the Container Apps environment and must not be directly accessible from the public internet.

Which configuration should you use?

A. External ingress with unrestricted access

B. Internal ingress

C. External ingress with HTTP only

D. Disable the Container Apps environment’s virtual network

Answer: B

Explanation: Internal ingress is designed for applications that should be reachable internally rather than exposed through public ingress. Container Apps supports both external and internal ingress configurations.

Question 3

A Container App needs to retrieve a database password stored in Azure Key Vault. The organization doesn’t want the password embedded in the application image or deployment scripts.

What is the most appropriate approach?

A. Store the password in a Dockerfile

B. Store the password in a regular environment variable

C. Assign a managed identity to the Container App and use it to retrieve the Key Vault secret

D. Make the Key Vault publicly accessible

Answer: C

Explanation: Container Apps supports managed identities and Key Vault secret references. The managed identity can be granted the required Key Vault permissions, allowing the application to retrieve secrets without embedding credentials.

Question 4

A security architect wants to protect a highly sensitive ACI workload from certain infrastructure-level threats and wants hardware-backed protection for data while it is being processed.

Which capability should the architect evaluate?

A. Azure Storage firewall

B. Azure Bastion

C. Azure Firewall

D. Confidential containers

Answer: D

Explanation: Confidential containers on ACI use a trusted execution environment to provide hardware-based confidentiality and integrity protections. This specifically addresses protection of sensitive workloads while they are running.

Question 5

An organization has several Container Apps. One application needs permission to read secrets from Azure Key Vault, but it should not have broad permissions to other Azure resources.

Which security principle should be applied?

A. Grant the managed identity only the minimum required Key Vault permissions

B. Assign Owner to the container application

C. Store the Key Vault password inside the container image

D. Enable anonymous access to Key Vault

Answer: A

Explanation: Least privilege requires granting only the permissions needed by the workload. Managed identities combined with narrowly scoped RBAC permissions provide a credential-free and least-privilege approach.

Question 6

A company exposes a Container App through external ingress. The security team requires users to authenticate using Microsoft Entra ID before they can access the application.

Which capability should you configure?

A. A system-assigned identity for the application’s outbound calls

B. Built-in Container Apps authentication and authorization

C. An ACR private endpoint

D. A secret volume

Answer: B

Explanation: Container Apps provides built-in authentication and authorization capabilities that can integrate with Microsoft Entra ID and other identity providers. Managed identity is instead primarily used by the application when authenticating to Azure resources.

Question 7

An organization needs to ensure that an HTTP application in Azure Container Apps does not accept unencrypted HTTP connections.

Which ingress setting should be configured?

A. Enable external ingress

B. Enable internal ingress

C. Set allowInsecure to false

D. Enable session affinity

Answer: C

Explanation: The allowInsecure ingress setting controls whether insecure HTTP connections are permitted. For a secure application, allowInsecure should remain disabled so that HTTPS is enforced.

Question 8

A company wants to prevent direct public access to a sensitive Azure Container Apps environment. The workload-profile environment should be reachable through an Azure virtual network using private connectivity.

Which capability is most appropriate?

A. Public external ingress

B. A private endpoint with public network access disabled

C. Anonymous authentication

D. A public IP address assigned to each container

Answer: B

Explanation: Container Apps supports private endpoints for workload-profile environments. Public network access can be disabled so that connectivity uses the private endpoint and controlled network path. Appropriate private DNS configuration is also required.

Question 9

A security team wants an application running in Azure Container Apps to authenticate to Azure Storage without storing a storage account key in the application.

Which solution provides the strongest fit?

A. Managed identity with appropriate Azure RBAC permissions

B. Store the storage account key in the container image

C. Enable anonymous access to the storage account

D. Store the storage key in a public environment variable

Answer: A

Explanation: Managed identity allows the application to authenticate to Azure resources without maintaining credentials in application code or configuration. Appropriate Azure RBAC permissions should then be assigned to the identity.

Question 10

A security engineer changes a secret used by several revisions of an Azure Container App. The engineer expects all running revisions to immediately begin using the new secret value.

What should the engineer understand?

A. Every secret change automatically creates a new revision

B. Secrets are permanently associated with the revision that originally created them

C. Secret changes automatically delete all older revisions

D. Secrets are application-scoped, and running revisions may need to be restarted or a new revision deployed to consume the updated value

Answer: D

Explanation: Container Apps secrets are scoped to the application rather than a specific revision. Changing a secret doesn’t automatically create a new revision. Existing running revisions may need to be restarted or a new revision deployed so the updated secret value is loaded.

Final Word

For SC-500, the most important mental model for this topic is:

Secure the image → secure the identity → secure the secrets → secure the network → secure the application endpoint → monitor the workload.

For ACI, concentrate on managed identities, secure image retrieval, secure environment variables and secret volumes, virtual-network integration, private ACR access, and confidential containers.

For Azure Container Apps, concentrate on environment security boundaries, managed identities, Key Vault integration, internal versus external ingress, built-in authentication, HTTPS, private endpoints, outbound traffic control, and application/network isolation.

The exam is likely to test these controls through scenario-based decisions, so focus less on memorizing isolated features and more on identifying which control solves which security problem.

Go to the SC-500 Exam Prep Hub main page