Manage identity, access, and governance

A function app holds a managed identity, the vault firewall admits its subnet, and it still cannot read the connection string it needs, so an administrator grants it Key Vault Contributor and nothing changes. That role configures vaults through Azure Resource Manager, the control plane, and never reads what is inside one, the data plane, and that gap is the shape of nearly every mistake in this domain: reaching for a control that sits beside the problem but answers a different question. Three questions divide the whole domain. Microsoft Entra ID, Microsoft's cloud identity directory, decides who is calling and whether they got in as themselves. Azure Key Vault decides where a key, secret, or certificate lives and who may read it. Azure Policy, Azure RBAC (role-based access control), resource locks, and Microsoft Defender for Cloud, among other governance controls, decide what an authenticated principal may then build, change, or delete, and how that outcome is reported. One mechanism spans two of those questions, so read Azure RBAC by the plane a role acts on: a data-plane role on a vault answers who may read what is inside it, while a control-plane assignment answers what its holder may build or change. One more split runs inside that habit: some of these controls refuse a request and others only observe it, so Microsoft Defender for Key Vault alerts on suspicious access without blocking the call it alerted on, and a Defender for Cloud compliance percentage assesses a subscription rather than stopping a deployment. Name the question the requirement is really asking, and the control follows.

The through-line runs from the caller inward to the resource. One word to pin down before that walk: role names two separate systems here, Microsoft Entra directory roles over the directory itself and Azure RBAC roles over Azure resources, and an assignment in one grants nothing in the other. Secure access to resources by using Microsoft Entra ID covers who may sign in and as whom: Privileged Identity Management (PIM) for whether a role is standing or has to be activated, authentication methods and Conditional Access for what must be true at sign-in, app registrations, enterprise applications and consent for what an application may do with data, and managed identities for code that should carry no credential of its own; reach for it whenever the subject is a sign-in, an elevation, or an application's identity. Secure secrets and keys by using Azure Key Vault covers where keys, secrets, and certificates live and who may read them: the vault boundary with its soft-delete and purge protections, the separation between control-plane and data-plane authorization, the firewall and private endpoint decisions that narrow network reach, versioned rotation, and the detection layer of Defender for Key Vault plus Defender Cloud Security Posture Management (Defender CSPM) secrets scanning; reach for it whenever a credential or key is the subject. Implement governance to enforce security and regulatory compliance covers what an authenticated principal may then build, change, or delete, and how that result is measured: Azure Policy definitions, assignments and effects, Azure RBAC assignments and custom roles, resource locks and Azure Backup protections, Defender for Cloud standards and recommendations, and shipping all of it as infrastructure as code; reach for it whenever the subject is a resource's configuration, its deletion, or a compliance report rather than a person's sign-in.

Across all three pages the exam rewards the same instinct: prefer the option where nothing sensitive is held permanently by anyone. That favors a managed identity, or workload identity federation for code running outside Azure, over a client secret an application stores; an eligible PIM assignment that has to be activated over an active one that carries the role continuously; the Azure RBAC data-plane model on a vault over legacy access policies; and a tracked policy exemption that can carry an expiry date over an exclusion that removes a scope permanently and silently. The same instinct decides the remediation questions, because Azure RBAC is additive: an over-privileged principal is fixed by removing or re-scoping the broad assignment, never by layering a narrower role on top of it. Depart from the default only when the scenario states a constraint that forces the manual form, and be able to name that constraint.