CH20-02: Identity, Governance, and Security Services
Goal
Identity, governance, and security services define the control plane around every Azure architecture. They answer who the caller is, what the caller can do, which resource states are allowed, how secrets are protected, and how risk becomes visible.
The durable idea is:
Identity, governance, and security services define the control plane around every Azure architecture.
The Short Version
Do not compress security into one service name. Start with the control question:
| Control Question | Common Azure Direction |
|---|---|
| Who is the caller? | Microsoft Entra ID. |
| What can this principal do at this scope? | Azure RBAC. |
| What resource states are allowed or audited? | Azure Policy. |
| Where do platform ownership and billing boundaries sit? | Management groups and subscriptions. |
| How are secrets, keys, and certificates protected? | Azure Key Vault. |
| How does a workload authenticate without stored credentials? | Managed identities. |
| How is cloud security posture assessed? | Microsoft Defender for Cloud. |
| How are security events investigated and correlated? | Microsoft Sentinel. |
Service Reference
| Service | Purpose | Use When | Avoid When | Common Prompt |
|---|---|---|---|---|
| Microsoft Entra ID | Identity provider for users, groups, applications, and service principals. | You need authentication, tenant identity, application registration, enterprise identity integration, or conditional access. | You are trying to grant Azure resource permissions by itself; use RBAC for authorization at Azure scopes. | Who is the caller? |
| Azure RBAC | Authorization system for Azure management-plane actions at scopes such as management group, subscription, resource group, and resource. | You need to grant least-privilege access to Azure resources. | You need to require or deny resource configuration; use Azure Policy. | What can this principal do here? |
| Azure Policy | Governance guardrails for allowed, denied, audited, or remediated resource configurations. | You need compliance controls, required tags, allowed locations, SKU rules, or configuration enforcement. | You are trying to authenticate users or assign operational permissions. | What resource states are allowed? |
| Management groups | Governance grouping above subscriptions. | You need policy and access organization across multiple subscriptions. | You only need to organize resources inside one workload. | Where should shared rules apply? |
| Subscriptions | Azure billing, quota, deployment, and management boundary. | You need to separate environments, ownership, billing, risk, or platform boundaries. | You are only grouping related resources inside an existing subscription; use resource groups. | What boundary owns this workload? |
| Azure Key Vault | Protects secrets, keys, and certificates. | Workloads need controlled access to secrets, certificates, encryption keys, or signing material. | You expect it to remove the need for identity, network, rotation, or access design. | How does the workload access secrets safely? |
| Managed identities | Azure-managed identity for workloads hosted on Azure. | A workload needs to authenticate to Azure services without storing credentials. | The workload is not running in an environment that supports managed identities, or user-level authorization is still required and not enforced. | Can this workload avoid stored credentials? |
| Microsoft Defender for Cloud | Security posture management and workload protection guidance. | You need visibility into misconfiguration, recommendations, regulatory posture, and threat protection options. | You treat recommendations as a substitute for secure architecture. | What risks are visible? |
| Microsoft Sentinel | Cloud-native SIEM and security orchestration platform. | You need to collect, correlate, investigate, and respond to security signals across environments. | You only need basic resource health metrics or application logs. | How will security events be detected and investigated? |
Commonly Confused Services
| Comparison | Short Answer |
|---|---|
| Microsoft Entra ID vs Azure RBAC | Entra ID proves identity; RBAC grants Azure permissions at scope. |
| Azure RBAC vs Azure Policy | RBAC controls who can perform actions; Policy controls which resource configurations are allowed, audited, or remediated. |
| Key Vault vs managed identity | Key Vault stores and protects secrets or keys; managed identity lets the workload authenticate without storing credentials. They often work together. |
| Defender for Cloud vs Sentinel | Defender for Cloud helps assess and protect cloud posture; Sentinel helps collect, correlate, investigate, and respond to security events. |
Architecture Patterns
These services often appear in patterns such as:
Landing zone governance with management groups, subscriptions, Azure Policy, Azure RBAC, and tags.
Secretless service-to-service access with managed identities and Key Vault.
Least-privilege operations with scoped RBAC assignments.
Compliance evidence with Azure Policy and Defender for Cloud recommendations.
Security operations with Defender for Cloud signals flowing into Sentinel investigations.
Cloud Comparison
AWS and GCP have similar responsibility families, but Azure places them differently. Microsoft Entra ID is the tenant identity foundation. Subscriptions are important billing, quota, and management boundaries. Resource groups are explicit workload organization boundaries inside subscriptions. Azure RBAC and Azure Policy work together, but they answer different questions.
Use comparisons only to orient yourself. The stronger Azure design answer names the scope: tenant, management group, subscription, resource group, or resource.
Common Mistakes
Confusing authentication with authorization.
Using RBAC when policy guardrails are needed, or policy when access control is needed.
Storing secrets in application settings, code, images, or pipelines without a rotation plan.
Treating security monitoring as a replacement for secure design.
Assigning broad permissions at subscription scope when a narrower resource group or resource scope would fit.
Using managed identity for service access but forgetting user-level authorization inside the application.
If Someone Asks You
Which Azure services should I remember for identity, governance, and security?
A good answer is:
Remember the control questions. Microsoft Entra ID handles identity, Azure RBAC handles Azure authorization at scope, Azure Policy handles resource guardrails, management groups and subscriptions organize governance boundaries, Key Vault protects secrets and keys, managed identities reduce stored credentials, Defender for Cloud makes posture and risk visible, and Sentinel supports security detection and response.
What You Should Remember
Identity proves who, RBAC decides allowed actions, Policy enforces resource rules, and security services make risk visible.
Questions to Check Understanding
How are Microsoft Entra ID and Azure RBAC different?
How is Azure Policy different from Azure RBAC?
Why do managed identities and Key Vault often appear together?