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 Kubernetes Service (AKS)

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 Kubernetes Service (AKS) provides a managed Kubernetes platform for running containerized applications in Azure. Because AKS hosts potentially sensitive workloads and provides access to Azure resources, securing an AKS environment requires controls at several layers:

• Cluster and API server access
• Identity and authorization
• Pod and container security
• Network segmentation
• Secrets and credential protection
• Container image security
• Policy and compliance enforcement
• Threat detection and runtime protection
• Cluster and node security

For the SC-500 exam, it is important to understand which security control addresses which threat and how the controls work together.

1. Understanding the AKS Security Model

AKS security should be viewed as a layered defense model.

No individual control provides complete protection. A secure AKS implementation combines multiple layers.

Microsoft’s current AKS security guidance specifically emphasizes authentication and authorization, Azure Policy, Defender for Containers, secure pod traffic, protection of sensitive credentials, and keeping Kubernetes and node operating systems updated.

2. Secure Access to the AKS API Server

The Kubernetes API server is the primary management interface for an AKS cluster.

An attacker who obtains unauthorized access to the API server may be able to:

• Deploy malicious workloads
• Modify existing workloads
• Access cluster resources
• Retrieve sensitive configuration
• Change Kubernetes objects
• Potentially move laterally through workloads

Therefore, protecting API-server access is one of the most important AKS security tasks.

Microsoft Entra ID Authentication

Microsoft recommends integrating AKS with Microsoft Entra ID for authentication.

Instead of maintaining independent local identities for Kubernetes users, Microsoft Entra ID becomes the centralized identity provider.

This provides benefits such as:

• Centralized identity management
• Group-based access
• Multifactor authentication
• Conditional Access
• Privileged Identity Management
• Centralized identity lifecycle management

Microsoft Entra ID handles authentication — determining who the user is.

Kubernetes RBAC or Azure RBAC can then handle authorization — determining what that authenticated identity is allowed to do.

Exam distinction

Authentication = Who are you?
Authorization = What are you allowed to do?

This distinction is frequently important in security scenarios.

3. Kubernetes RBAC and Azure RBAC

AKS supports both Kubernetes RBAC and Azure RBAC-based authorization models.

Kubernetes RBAC

Kubernetes RBAC controls permissions to Kubernetes resources.

For example, a user might be allowed to:

• View pods
• Create deployments
• Modify services

but not:

• Create cluster-wide roles
• Modify namespaces
• Access sensitive resources

Kubernetes RBAC uses objects such as:

• Roles
• ClusterRoles
• RoleBindings
• ClusterRoleBindings

Azure RBAC

Azure RBAC controls access to Azure resources through Azure Resource Manager.

For example, Azure RBAC can determine whether an administrator can:

• Manage an AKS cluster
• Modify Azure networking
• Access Azure Key Vault
• Modify Azure Storage

AKS also supports Azure RBAC for Kubernetes authorization, allowing Azure identities and Azure RBAC concepts to participate in authorization decisions for Kubernetes resources.

Least privilege

The objective is to give administrators, developers, applications, and services only the permissions they require.

Avoid giving users or applications cluster-admin privileges unless there is a compelling operational requirement.

4. Protecting the AKS API Server

There are two important approaches to restricting access to the AKS API server.

Private AKS Cluster

A private AKS cluster uses a private endpoint for API-server communication.

This can prevent the Kubernetes API server from being directly accessible over the public internet.

A private cluster is particularly useful when:

• Cluster administration must remain on private networks.
• The organization has strict network segmentation requirements.
• The cluster handles sensitive workloads.
• Administrative traffic must remain within controlled network boundaries.

Microsoft’s current guidance recommends private AKS clusters when stronger segmentation of API-server traffic is required.

Authorized IP Ranges

A public AKS API server can instead be restricted using authorized IP ranges.

This approach allows access only from specified public IP addresses.

For example:

Allowed:
Corporate office public IP
CI/CD build-agent IP
Security administration network
Blocked:
All other internet addresses

Important distinction

5. Secure Pod-to-Pod Communication with Network Policies

By default, pods can communicate with one another unless restrictions are implemented.

This can create excessive lateral-movement opportunities.

For example:

Frontend Pod
     |
     v
API Pod
     |
     v
Database Pod

The desired security architecture might allow:

Frontend ---> API
API -------> Database

but prevent:

Frontend ---> Database
Database ---> Frontend
Unrelated Pod ---> Database

Kubernetes Network Policies

AKS supports Kubernetes network policies that can control traffic between pods.

Policies can use criteria such as:

• Namespace
• Pod labels
• Ports
• Traffic direction

Microsoft describes network policies as a cloud-native way to control pod traffic, while NSGs are more appropriate for controlling traffic at the Azure/node network layer.

Example

Suppose an organization has:

namespace: frontend
namespace: backend
namespace: database

A network policy can permit:

frontend → backend
backend → database

while denying:

frontend → database

This implements micro-segmentation within the Kubernetes environment.

6. Network Security Groups vs. Network Policies

This distinction is important for the exam.

A network policy is not a replacement for an NSG.

Instead, they operate at different layers.

7. Secure Pod and Container Execution

A compromised container can become a significant security problem if it has excessive privileges.

A fundamental principle is:

Run containers with the minimum privileges they require.

Avoid unnecessarily running containers as root.

Security Context

Kubernetes security contexts can restrict how containers and pods operate.

Examples include:

• Running as a specific user
• Controlling group ownership
• Restricting privilege escalation
• Controlling Linux capabilities
• Applying filesystem restrictions

Microsoft recommends using pod security contexts and minimizing privileges.

Example concept

Instead of:

Container
   |
   └── root privileges
          |
          └── Full access to privileged operations

prefer:

Container
   |
   └── Non-root identity
          |
          └── Only required permissions

This reduces the potential impact of a container compromise.

8. Pod Security Standards

Kubernetes provides Pod Security Standards (PSS) to define security expectations for workloads.

The standards provide different levels of restriction.

The important security concept is that organizations can prevent workloads from violating defined security requirements.

For example, an organization might require workloads to:

• Avoid privileged containers
• Avoid running as root
• Restrict privilege escalation
• Use appropriate security contexts

Current AKS security guidance also incorporates Pod Security Standards and deployment safeguards into the security baseline for AKS Automatic, while AKS Standard provides greater flexibility and generally requires more explicit configuration.

9. Protecting Secrets and Credentials

Never place sensitive credentials directly into:

• Application source code
• Container images
• Configuration files committed to source control
• Plain-text deployment manifests

Examples of sensitive information include:

• Database passwords
• API keys
• Connection strings
• Certificates
• Access tokens

Instead, Azure Key Vault can be used as a centralized secret store.

10. Microsoft Entra Workload ID

Microsoft Entra Workload ID allows an application running in an AKS pod to authenticate to Azure resources without embedding long-lived credentials in the application.

For example:

AKS Pod
   |
   | Federated identity
   v
Microsoft Entra ID
   |
   v
Azure Key Vault

The workload can then access Azure resources according to the permissions granted to its identity.

Microsoft Entra Workload ID uses Kubernetes service-account tokens and OpenID Connect (OIDC) federation to establish trust with Microsoft Entra ID.

Why is this better?

Without workload identity:

Application
   |
   └── Stored secret
          |
          └── Risk of exposure

With workload identity:

Application
   |
   └── Federated identity
          |
          v
     Microsoft Entra ID
          |
          v
     Azure resource

This reduces the need to distribute and rotate long-lived credentials.

11. Azure Key Vault and the Secrets Store CSI Driver

AKS can integrate with Azure Key Vault using the Secrets Store CSI Driver and its Azure Key Vault provider.

This allows a pod to retrieve secrets, keys, or certificates from Key Vault.

The general architecture is:

                Azure Key Vault
                      |
                      |
             Secrets Store CSI
                      |
                      v
                  AKS Pod
                      |
                      v
                Application

This keeps sensitive values out of container images and application source code.

Microsoft’s current AKS guidance recommends using Key Vault with the Secrets Store CSI Driver, including Microsoft Entra Workload ID where appropriate.

12. Container Image Security

Container security begins before a container is deployed.

A vulnerable image can introduce vulnerabilities into every pod that uses it.

Organizations should therefore:

1. Use trusted container registries.
2. Scan images for vulnerabilities.
3. Keep base images updated.
4. Remove unnecessary packages.
5. Rebuild images when critical vulnerabilities are discovered.
6. Avoid embedding secrets in images.
7. Control which images can be deployed.

For Azure workloads, Azure Container Registry (ACR) can be integrated into the AKS security architecture.

Microsoft recommends using Microsoft Entra-based authentication for AKS-to-ACR access rather than relying unnecessarily on stored imagePullSecrets.

13. Microsoft Defender for Containers

Microsoft Defender for Containers provides security capabilities for containerized environments, including AKS.

It can provide:

• Container image vulnerability assessment
• Security posture recommendations
• Runtime threat detection
• Security alerts
• Kubernetes configuration insights
• Monitoring of workloads and cluster activity

For AKS, Defender for Containers integrates with Azure services and can collect runtime security signals from AKS environments.

Think of Defender for Containers as covering multiple stages

Build
  |
  v
Container Image
  |
  | Vulnerability assessment
  v
Deployment
  |
  | Configuration/posture checks
  v
Running Workload
  |
  | Runtime monitoring/threat detection
  v
Security Alert

This is different from Azure Policy.

Defender for Containers vs. Azure Policy

A useful exam rule is:

Defender for Containers detects and protects; Azure Policy governs and enforces.

14. Azure Policy for AKS

Azure Policy can extend governance into Kubernetes.

The Azure Policy add-on for AKS uses policy enforcement mechanisms to apply governance to Kubernetes resources such as:

• Pods
• Containers
• Namespaces

Azure Policy can centrally define and report compliance for Kubernetes clusters.

The Azure Policy implementation extends Gatekeeper/OPA capabilities to provide centralized policy management.

Example

An organization might establish a policy:

Containers must not run with privileged mode enabled.

A deployment violating the policy can be identified or, depending on the policy and enforcement configuration, prevented.

This is particularly valuable in large organizations where manually reviewing every Kubernetes manifest is impractical.

15. Policy as a Security Guardrail

Consider a development team that deploys this workload:

Deployment
   |
   +-- Container A
   |      └── Privileged = true
   |
   +-- Container B
          └── Runs as root

Instead of relying solely on developers to detect these risks, Azure Policy can establish organizational guardrails.

Conceptually:

Developer
    |
    v
Kubernetes Deployment
    |
    v
Policy Evaluation
    |
    +---- Compliant ------> Deploy
    |
    +---- Noncompliant ---> Audit / Deny

This is an example of preventive governance.

16. AKS Automatic vs. AKS Standard

Current AKS documentation distinguishes between AKS Automatic and AKS Standard.

AKS Automatic provides a more opinionated security baseline, while AKS Standard provides greater configuration flexibility.

AKS Automatic includes several security controls preconfigured, including:

• Azure RBAC for Kubernetes authorization
• API server virtual network integration
• Workload identity and OIDC issuer
• Deployment safeguards
• Baseline Pod Security Standards in enforce mode
• Image cleaner
• Security restrictions around managed system node pools

AKS Standard supports these capabilities but generally gives the customer greater responsibility for configuring and operating them.

Exam takeaway

Do not assume that every AKS security feature is automatically configured identically in every AKS deployment.

Always consider:

Which AKS mode is being used, and which controls have actually been enabled?

17. Restricting Access to the Instance Metadata Service

A compromised pod may attempt to access Azure instance metadata endpoints to obtain information or credentials.

AKS security guidance recommends using network policies to restrict pod access to the instance metadata endpoint where appropriate.

This is another example of defense in depth.

Even if an attacker compromises a container, network controls can limit what the compromised workload can reach.

18. Keeping AKS and Nodes Updated

Security controls are not effective if the underlying Kubernetes environment contains known vulnerabilities.

Organizations should:

• Keep AKS on supported Kubernetes versions.
• Upgrade node images.
• Apply security patches.
• Remove obsolete node images.
• Monitor Kubernetes version support.
• Test upgrades before production rollout.

Microsoft specifically identifies maintaining current Kubernetes and node OS security updates as an important AKS security practice.

A security strategy therefore includes both:

Configuration Security
+
Patch Security
+
Runtime Security

19. A Layered AKS Security Architecture

A secure AKS environment can be visualized as follows:

                       Internet
                           |
                           v
                    WAF / Firewall
                           |
                           v
                    AKS Ingress
                           |
              +------------+------------+
              |                         |
              v                         v
        Frontend Pods              API Pods
              |                         |
              +-----------+-------------+
                          |
                   Network Policy
                          |
                          v
                     Data Pods
                          |
                          v
                    Azure Services
                          |
                    Key Vault / SQL /
                    Storage / APIs


        ┌──────────────────────────────────────┐
        │          Security Controls           │
        │                                      │
        │ Microsoft Entra ID / RBAC            │
        │ Microsoft Entra Workload ID          │
        │ Azure Policy                         │
        │ Defender for Containers              │
        │ Key Vault                            │
        │ Network Policies                     │
        │ Pod Security Standards               │
        │ Private API Server / IP restrictions │
        │ Kubernetes/node updates              │
        └──────────────────────────────────────┘

The important concept is that these controls complement one another.

20. Common AKS Security Design Scenarios

Scenario 1: Protect the API server from the public internet

Requirement: Administrative access to the API server must remain on private networks.

Best choice: Use a private AKS cluster.

Scenario 2: Public API server but only corporate IPs should connect

Requirement: The organization must retain a public endpoint but restrict its sources.

Best choice: Configure authorized IP ranges.

Scenario 3: Developers should authenticate using corporate identities

Requirement: Avoid separate Kubernetes user accounts.

Best choice: Integrate AKS with Microsoft Entra ID.

Scenario 4: Frontend pods should not communicate directly with database pods

Requirement: Implement pod-level network segmentation.

Best choice: Use Kubernetes network policies.

Scenario 5: An application needs Key Vault access

Requirement: Avoid storing a client secret inside the container.

Best choice: Use Microsoft Entra Workload ID and grant the workload the required Key Vault permissions.

Scenario 6: Retrieve secrets without embedding them in the container image

Requirement: Applications need database credentials stored centrally.

Best choice: Use Azure Key Vault with the Secrets Store CSI Driver, with an appropriate workload identity/authentication mechanism.

Scenario 7: Prevent developers from deploying privileged containers

Requirement: Establish an organization-wide Kubernetes security guardrail.

Best choice: Use Azure Policy for Kubernetes with an appropriate policy definition.

Scenario 8: Detect a vulnerable container image and suspicious runtime behavior

Requirement: Security operations needs visibility into vulnerabilities and runtime threats.

Best choice: Use Microsoft Defender for Containers.

21. AKS Security Control Decision Matrix

22. Key Exam Concepts to Remember

For SC-500, remember these relationships:

Microsoft Entra ID

Authenticates users and identities.

Kubernetes RBAC

Controls permissions within Kubernetes.

Azure RBAC

Controls Azure resource access and can participate in AKS authorization.

Private AKS cluster

Keeps API-server connectivity private.

Authorized IP ranges

Restrict which public IP addresses can reach the API server.

Network policies

Control pod-to-pod network communication.

Pod security

Limits what containers and pods can do.

Microsoft Entra Workload ID

Allows workloads to authenticate to Azure resources without embedding long-lived credentials.

Azure Key Vault

Provides centralized protection and management of secrets, keys, and certificates.

Secrets Store CSI Driver

Allows Kubernetes workloads to retrieve secrets from external secret stores such as Key Vault.

Azure Policy

Provides centralized governance and policy enforcement for Kubernetes resources.

Defender for Containers

Provides container security posture, vulnerability assessment, runtime protection, and threat detection capabilities.

23. Best Practices Checklist

A strong AKS security implementation should consider:

• Use Microsoft Entra ID for cluster authentication.
• Apply least privilege through RBAC.
• Avoid unnecessary cluster-admin permissions.
• Consider a private AKS cluster for sensitive environments.
• Use authorized IP ranges when a public API endpoint is required.
• Implement network policies to restrict pod-to-pod traffic.
• Avoid running containers as root where possible.
• Minimize Linux capabilities and privilege escalation.
• Use Pod Security Standards and appropriate security contexts.
• Use Microsoft Entra Workload ID for workload-to-Azure authentication.
• Store secrets in Azure Key Vault rather than source code or images.
• Use the Secrets Store CSI Driver where appropriate.
• Scan container images for vulnerabilities.
• Use trusted container registries and keep images current.
• Enable Azure Policy for centralized governance.
• Use Defender for Containers for security posture and runtime protection.
• Keep Kubernetes and node images supported and patched.
• Monitor security alerts and compliance continuously.
• Treat AKS security as a layered defense rather than a single feature.

Practice Exam Questions

Question 1

An organization deploys an AKS cluster containing sensitive financial workloads. Security policy requires that communication with the Kubernetes API server remain on private networks and not traverse a public API endpoint.

Which solution should you implement?

A. Configure Kubernetes network policies
B. Configure an AKS private cluster
C. Configure authorized IP ranges
D. Configure Azure Policy

Answer: B

Explanation: A private AKS cluster provides private connectivity to the Kubernetes API server. Network policies control pod traffic, while authorized IP ranges restrict sources to a public API endpoint. Azure Policy provides governance rather than making the API server private.

Question 2

A company wants developers to authenticate to AKS by using their existing corporate identities. The security team also wants to take advantage of Microsoft Entra security capabilities such as multifactor authentication and Conditional Access.

Which solution should be implemented?

A. Microsoft Entra ID integration
B. Kubernetes service accounts only
C. Azure Firewall
D. Network Security Groups

Answer: A

Explanation: Microsoft Entra ID provides centralized authentication for AKS users and integrates with Microsoft identity security capabilities. Kubernetes service accounts serve different workload-oriented purposes, while Azure Firewall and NSGs are network controls.

Question 3

An AKS cluster contains frontend, API, and database pods. The security team requires that frontend pods communicate with API pods, API pods communicate with database pods, but frontend pods must not communicate directly with database pods.

Which control should you use?

A. Azure RBAC
B. Azure Key Vault
C. Kubernetes network policies
D. Microsoft Entra Workload ID

Answer: C

Explanation: Kubernetes network policies control traffic between pods based on characteristics such as namespaces, labels, ports, and traffic direction. This makes them appropriate for implementing pod-level network segmentation.

Question 4

An application running in an AKS pod needs to access Azure Key Vault. The security team does not want developers to store a client secret or other long-lived credential in the container.

Which solution provides the most appropriate identity mechanism?

A. Store the secret in the Docker image
B. Store the credential in a Kubernetes ConfigMap
C. Use a Kubernetes NetworkPolicy
D. Use Microsoft Entra Workload ID

Answer: D

Explanation: Microsoft Entra Workload ID enables an AKS workload to federate its Kubernetes identity with Microsoft Entra ID and obtain access to Azure resources without embedding long-lived application credentials.

Question 5

A security administrator wants to prevent developers from deploying privileged containers into production AKS clusters. The administrator wants the requirement centrally governed across multiple clusters.

Which solution is most appropriate?

A. Azure Policy for Kubernetes
B. Azure Key Vault
C. Azure Firewall
D. Microsoft Entra Workload ID

Answer: A

Explanation: Azure Policy for Kubernetes provides centralized governance and enforcement for Kubernetes resources such as pods, containers, and namespaces. It can be used to establish organizational security guardrails.

Question 6

A security operations team wants to identify vulnerabilities in container images and detect suspicious activity occurring in running AKS workloads.

Which Microsoft security service is designed for this purpose?

A. Azure Policy
B. Microsoft Defender for Containers
C. Azure Resource Manager
D. Azure Private Link

Answer: B

Explanation: Microsoft Defender for Containers provides capabilities including container image vulnerability assessment, security posture insights, runtime security signals, and threat detection for supported AKS environments.

Question 7

An organization has an AKS cluster with a public API server. The organization does not want to migrate to a private cluster, but it needs to ensure that only the organization’s approved public IP addresses can access the API server.

Which control should be configured?

A. Kubernetes RBAC
B. Azure Key Vault
C. Authorized IP ranges
D. Pod Security Standards

Answer: C

Explanation: Authorized IP ranges restrict access to a public AKS API server to specified source IP addresses. Kubernetes RBAC controls what authenticated identities can do after access is established; it does not restrict the network source.

Question 8

A security engineer wants to prevent an application in one AKS namespace from communicating with workloads in another namespace unless explicitly permitted.

Which security control should the engineer prioritize?

A. Azure RBAC
B. Azure Policy
C. Microsoft Entra ID
D. Kubernetes network policy

Answer: D

Explanation: Kubernetes network policies can restrict pod traffic using namespaces, labels, ports, and other selectors. They are designed specifically for controlling pod-to-pod network communication.

Question 9

An application stores a database password inside its container image. The security team wants to remove the credential from the image and retrieve it securely at runtime from Azure Key Vault.

Which combination is most appropriate?

A. Azure Key Vault and the Secrets Store CSI Driver
B. Azure Firewall and NSGs
C. Azure Policy and Azure RBAC only
D. Private AKS cluster and authorized IP ranges

Answer: A

Explanation: Azure Key Vault provides centralized secret storage, while the Secrets Store CSI Driver with its Azure Key Vault provider allows AKS workloads to retrieve secret contents from Key Vault. Microsoft Entra Workload ID can also be used to provide the workload’s identity to Key Vault.

Question 10

A company wants to implement defense in depth for an AKS environment. The security architecture must restrict pod communication, prevent excessively privileged workloads, detect container vulnerabilities, and provide runtime threat detection.

Which combination provides the best overall solution?

A. Azure RBAC, Azure Storage, and Azure DNS
B. Network policies, pod security controls, Azure Policy, and Defender for Containers
C. Azure Firewall alone
D. Microsoft Entra ID alone

Answer: B

Explanation: No single AKS security feature provides all of these capabilities. Network policies provide pod-level segmentation, pod security controls reduce workload privileges, Azure Policy provides centralized governance/enforcement, and Defender for Containers provides vulnerability and runtime security capabilities. Together they provide layered defense in depth.

Go to the SC-500 Exam Prep Hub main page