SC-100 Design security solutions for infrastructure Practice Question
Which TWO of the following are valid methods to secure Azure Kubernetes Service (AKS) workloads?
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Integrate Microsoft Entra ID for cluster authentication
Option A is correct because integrating Microsoft Entra ID (Azure AD) with AKS enables cluster authentication and authorization via Azure RBAC, allowing you to control who can access the Kubernetes API server and manage workloads using identity-based controls rather than static credentials. Option E is correct because Azure Policy for AKS uses the Gatekeeper admission controller (Open Policy Agent) to enforce policies on pods and cluster resources at admission time, preventing non-compliant workloads from being deployed and thus hardening the workload configuration. Option B is not the intended answer because Network Security Groups apply at the subnet/NIC level for network traffic filtering, not specifically for securing AKS workloads at the pod or admission level, and pod-level security typically uses Kubernetes Network Policies. Option C is not correct in this context because Azure Firewall provides network perimeter protection and egress filtering but does not directly secure AKS workloads themselves. Option D is not correct because Azure Front Door is a global HTTP/HTTPS load balancer and WAF for web applications, not a mechanism for securing AKS workloads internally.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Integrate Microsoft Entra ID for cluster authentication
Why this is correct
Integrating Microsoft Entra ID for AKS cluster authentication authenticates Kubernetes identities against Microsoft Entra ID, enabling identity-based access control. It supports assigning Kubernetes RBAC roles to Microsoft Entra ID users, groups, or service principals, and allows conditional access policies to protect the cluster API server. This provides a control-plane security mechanism that centrally manages access and audits via Microsoft Entra ID sign-in logs, rather than relying on local Kubernetes accounts.
- ✗
Apply Network Security Groups to pod subnets
Why it's wrong here
Network Security Groups (NSGs) in AKS are associated with the subnet hosting the AKS nodes, not with individual pods or pod subnets. While NSGs filter layer-3/4 traffic between subnets and the internet, they cannot inspect Kubernetes-native constructs like pod labels, namespaces, or service endpoints. Pod-level traffic should be controlled with Kubernetes Network Policies, which enforce micro-segmentation at the IP/port level and are independent of Azure networking, making the NSG approach ineffective for workload security.
- ✗
Deploy Azure Firewall in front of the AKS cluster
Why it's wrong here
Deploying Azure Firewall in front of an AKS cluster provides perimeter-level filtering of north-south traffic, such as blocking suspicious outbound connections or segmenting VNets. However, Azure Firewall is a network-layer appliance that cannot see into pod-level traffic, understand Kubernetes services, or enforce security context constraints like read-only root filesystem or disallowed capabilities. Workload security in the cluster demands admission controllers, container runtime protection, and policy-based controls, not merely network egress filtering.
- ✗
Use Azure Front Door to protect API endpoints
Why it's wrong here
Azure Front Door is a global, layer-7 HTTP(S) load balancer and CDN that routes traffic to backend origins, offering TLS termination, URL-based routing, and a web application firewall (WAF). While it can provide some edge protection against web attacks, it does not secure the workloads inside the AKS cluster—it cannot enforce Kubernetes RBAC, pod security standards, or runtime integrity. Thus, it addresses availability and edge DDoS, not workload-level security, making it unsuitable for protecting API endpoints in a container-native security context.
- ✓
Use Azure Policy with Azure Policy for AKS (Gatekeeper)
Why this is correct
Azure Policy with the Azure Policy for AKS (Gatekeeper) integration enforces security and compliance policies on Kubernetes resources at the time of admission. Using the Gatekeeper v3 admission controller based on Open Policy Agent (OPA), it can block deployments that violate policies such as 'privileged containers must be disallowed' or 'all namespaces must have resource limits'. This provides a central governance mechanism that ensures clusters consistently meet organizational security requirements without requiring custom admission webhooks.
Visual reference
Quick reference
Access Control Model Comparison
| Model | Acronym | Who Controls Access? | Best For |
|---|---|---|---|
| Discretionary Access Control | DAC | Resource owner | Small teams, file shares |
| Mandatory Access Control | MAC | System / security labels | Classified govt / military |
| Role-Based Access Control | RBAC | Administrator (via roles) | Enterprise environments |
| Attribute-Based Access Control | ABAC | Policy engine (user + resource attributes) | Fine-grained, dynamic policies |
| Rule-Based Access Control | RuBAC | System rules / ACLs | Firewall rules, network ACLs |
Go deeper
Related to this question
About these practice questions
Courseiva writes every SC-100 question from scratch — 605 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SC-100 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SC-100 exam.