SC-100 Design security solutions for infrastructure Practice Question
You are designing a secure infrastructure for an Azure Kubernetes Service (AKS) cluster that will host sensitive workloads. Which TWO configurations should you implement to secure the cluster?
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
✓
Enable Microsoft Entra ID integration for role-based access control (RBAC).
Option A is correct because enabling Microsoft Entra ID integration for RBAC ties Kubernetes authorization to Microsoft Entra ID identities and group memberships, so cluster access is centrally governed and auditable rather than relying on static client certificates or local accounts. Option D is correct because Microsoft Entra ID pod identity (now largely superseded by Azure Workload Identity) lets pods obtain Microsoft Entra ID tokens via managed identities, eliminating the need to store credentials or secrets in containers for accessing Azure resources like Key Vault. Option B is not a security control but an observability feature, so it does not itself secure the cluster. Option C is incorrect and even risky, since the HTTP application routing add-on exposes an ingress endpoint and is intended for dev/test, not hardened production workloads. Option E is a scaling feature that improves availability and cost, not a security configuration.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Enable Microsoft Entra ID integration for role-based access control (RBAC).
Why this is correct
Integrating Microsoft Entra ID with AKS for role-based access control (RBAC) provides a centrally managed, authenticated identity for every human user who accesses the cluster. These identities are then mapped to Kubernetes RBAC roles and cluster roles, enabling granular, least-privilege authorization. This control also supports conditional access policies, multi-factor authentication, and comprehensive audit logs for cluster access, making it the fundamental security control for controlling who can perform administrative actions.
- ✗
Enable Azure Monitor for containers.
Why it's wrong here
Azure Monitor for containers collects performance metrics, logs, and inventory from nodes, pods, and containers, providing observability into cluster health and application performance. While it can help detect security-relevant anomalies after the fact, it is a monitoring and diagnostics tool rather than a preventive or enforced security control. It does not authenticate users, authorize actions, isolate workloads, or manage secrets, so enabling it alone does not improve the cluster's overall security posture.
- ✗
Enable the HTTP application routing add-on.
Why it's wrong here
The HTTP application routing add-on automatically deploys an ingress controller and creates a public DNS zone to route HTTP/HTTPS traffic to services in the cluster. It is a developer convenience for quickly exposing applications during development, not a security feature. It does not provide authentication, TLS policy enforcement, or network-level protection; in fact, it can increase the attack surface by making services publicly reachable without attendant security controls such as Web Application Firewall or API gateway policies.
- ✓
Use Microsoft Entra ID pod identity to provide identities for pods.
Why this is correct
Microsoft Entra ID pod identity assigns an Microsoft Entra ID identity to individual pods, enabling them to authenticate to Azure resources (such as Key Vault, Storage, or SQL) without embedding credentials in code. This is a critical security control for workload identity and least privilege, ensuring that applications only have the access they need. However, it governs pod-to-Azure communication, not human-to-cluster access; for cluster access, you still need Microsoft Entra ID integration with RBAC to authenticate and authorize operators and administrators.
- ✗
Enable the cluster autoscaler.
Why it's wrong here
The cluster autoscaler automatically adjusts the number of agent nodes in the nodepool based on pending pods and resource utilization. It is a horizontal scaling mechanism that focuses on capacity and cost management, not on security. Enabling it does not affect authentication, authorization, network policies, or workload identity, and it cannot protect the cluster from unauthorized access or malicious traffic.
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.