Chapter 4

Identity, Security, and Governance

Microsoft Azure Fundamentals (AZ-900) Study GuideBased on the Microsoft AZ-900 exam objectives

Picture a midsize company on a Monday morning. An engineer opens her laptop at home, connects to the VPN, and opens the company's file server. She types her password. She opens a second app — a cloud dashboard — and types a different password. She opens a third app and is told her password expired two weeks ago, so she calls the help desk. Meanwhile, a contractor who left three months ago still has an active account, and nobody noticed. Somewhere, a spreadsheet with all the server passwords sits on a shared drive called "final_passwords_USE_THIS_ONE.xlsx."

This is how identity used to be managed, and in many companies, this is how it is still managed. It is a disaster waiting for a headline. The AZ-900 exam devotes a significant chunk of its governance domain to one core insight: in the cloud, identity is the perimeter. There is no office network to hide behind anymore. Every login is a security decision. This chapter explains how Azure answers that reality — through Microsoft Entra ID, access control, policy enforcement, and the security services that watch over it all.

The Identity Perimeter

For decades, corporate security worked like a castle. You had walls (firewalls), a moat (network segmentation), and guards at the gate (VPNs and badge readers). Once you were inside the walls, you were trusted. This was called the perimeter-based security model, and it worked reasonably well when everyone worked in the office and every server lived in the company data center.

The cloud broke the castle. Your users log in from home, from coffee shops, from phones on hotel Wi-Fi. Your servers live in data centers you will never visit. There is no wall anymore — there are only doors, and each door is a login. That is why the industry says identity is the new perimeter. Instead of asking "is this person inside our network?" we now ask "is this the right person, on a trusted device, doing something they are allowed to do, at a reasonable time?"

This shift explains why Microsoft built its entire security story around identity — and why this chapter carries real exam weight.

Microsoft Entra ID: The Identity Authority

Microsoft Entra ID — formerly called Azure Active Directory — is Microsoft's cloud-based identity and access management service. It is the system that decides who you are (authentication) and what you are allowed to do (authorization) across Azure, Microsoft 365, and thousands of third-party applications. If Azure is a city, Entra ID is the government office that issues the ID cards, and almost every door in the city checks those cards.

A word about the name change, because it confuses exam candidates: Microsoft renamed Azure Active Directory to Microsoft Entra ID in 2023. The product is the same. The exam may use the new name, the old name, or both. If you see "Azure AD," treat it as Entra ID. The Entra family also includes related products (Entra Private Access, Entra Internet Access, Entra Verified ID), but for AZ-900, when you see "Entra," think: identity.

Authentication vs. Authorization: The Two Questions

Every access decision involves two separate questions, and the exam will test that you can tell them apart:

1. Authentication — "Who are you?" This is the login. You present credentials (a password, a fingerprint, a phone approval), and the system verifies you are who you claim to be.
2. Authorization — "What are you allowed to do?" Once your identity is established, the system checks your permissions. You may be authenticated as a legitimate employee but still not authorized to delete the production database.

A useful analogy: authentication is showing your ID at the door of a nightclub. Authorization is the wristband that determines whether you can enter the VIP section. Getting past the door does not get you into VIP.

Single Sign-On (SSO): One Key for Every Door

Remember the engineer at the start of this chapter juggling three passwords? Single sign-on (SSO) is the cure. With SSO, you authenticate once — one login, one identity check — and that single authentication grants you access to many applications without re-entering credentials.

SSO matters for two reasons, and both are exam-relevant:

• Security: Fewer passwords means fewer passwords to steal, phish, or reuse. Users stop writing passwords on sticky notes when they only have one.
• Productivity: Nobody wastes time on password resets for twelve different apps. IT stops drowning in "I forgot my password" tickets.

Entra ID provides SSO across Azure resources, Microsoft 365 apps, and thousands of integrated SaaS applications (Salesforce, ServiceNow, Dropbox, and more). The user signs in once, and Entra ID vouches for them to every connected app.

MFA and Conditional Access: Proving It Is Really You

A password alone is a thin lock. Passwords get phished, guessed, leaked in breaches, and reused across sites. Multifactor authentication (MFA) fixes this by requiring two or more independent forms of proof before granting access. The factors fall into three classic categories:

1. Something you know — a password or PIN.
2. Something you have — your phone, a hardware security key, an authenticator app code.
3. Something you are — a fingerprint, a face scan.

The point is independence: a thief who steals your password still does not have your phone. Microsoft's own data has long shown that MFA blocks the overwhelming majority of account-compromise attacks — the exact percentage has shifted over the years, but the exam expects you to know that MFA is the single most effective step an organization can take against identity attacks.

MFA in Entra ID can be enforced through Conditional Access, which is one of the most exam-tested concepts in this chapter. Conditional Access is not just "turn on MFA for everyone." It is a policy engine that evaluates the context of every sign-in and decides what to require. The logic works as an if-then statement:

• If a user signs in from an unusual location or an unrecognized device, then require MFA.
• If a sign-in shows signs of compromise (impossible travel, leaked credentials), then block access entirely.
• If a user is on a company-managed device on the office network, then allow access without extra friction.

The signals Conditional Access can evaluate include user identity, device health and compliance, location, the application being accessed, and real-time risk detection. The actions it can take include granting access, requiring MFA, requiring a compliant device, or blocking access outright.

One nuance worth knowing: Conditional Access is a premium feature. It requires Microsoft Entra ID P1 or P2 licensing (or equivalent bundled licenses). The free tier of Entra ID includes basic MFA, but policy-driven Conditional Access needs the paid plans. The exam occasionally probes this with "which license is required" questions — Conditional Access means P1/P2.

RBAC: Who Gets to Do What

Authentication proves who you are. Authorization decides what you can do. In Azure, the system that answers "what can this identity do to this resource?" is role-based access control (RBAC) — the fine-grained access management system built into Azure Resource Manager.

RBAC works through three ingredients:

1. Security principal — who or what gets access. This can be a user, a group, a service principal (an identity for an application), or a managed identity (an automatically managed identity for an Azure resource).
2. Role definition — what they can do. A role is a bundle of permissions: read, write, delete, and so on. Azure ships with built-in roles like Owner (full control, including managing access), Contributor (full control except managing access), and Reader (view everything, change nothing).
3. Scope — where the access applies. Roles can be assigned at the management group, subscription, resource group, or individual resource level. Assignments flow downward: a role assigned at the subscription level applies to every resource group and resource inside it.

The classic exam formulation: RBAC = security principal + role definition + scope. If you can recite those three components and explain each, you have the conceptual core.

Least Privilege: The Golden Rule

The guiding principle of RBAC is least privilege: every identity should have the minimum permissions needed to do its job, and nothing more. A developer who only needs to deploy code to one app service should not be a Contributor on the entire subscription. A support technician who needs to read logs should be a Reader, not an Owner.

Why does this matter? Because breaches are inevitable, and least privilege contains the blast radius. If an attacker's stolen credentials only grant read access to one resource group, the damage stops there. If those credentials are subscription-wide Owner, the attacker owns everything. Least privilege is not paranoia — it is damage control designed in advance.

A related best practice: assign roles to groups, not individuals. When someone joins the network team, you add them to the network-team group, and the group's role assignments apply automatically. When they leave, you remove them from the group once. Managing permissions person-by-person across hundreds of resources is how access sprawl happens — and how ex-employees keep access they should have lost.

RBAC vs. Other Access Controls

Candidates sometimes confuse RBAC with other access concepts. Two distinctions worth locking in:

• RBAC controls the management plane — who can manage Azure resources (create VMs, change configurations, delete resource groups). It does not control access to the data inside resources. Whether someone can read the files in a storage account is governed by data-plane controls (like storage access keys or data-level roles), not by Contributor/Reader.
• RBAC is about Azure resources specifically. Access to Microsoft 365 apps is governed by Entra ID roles and app permissions — a related but separate system.

Resource Locks: The Safety Catch

Even with perfect RBAC, accidents happen. An administrator with legitimate Contributor access might accidentally delete the production database while cleaning up old resources. This is not hypothetical — it is one of the most common causes of cloud outages. Resource locks are Azure's answer: a safety catch that prevents accidental deletion or modification, regardless of the user's permissions.

There are two lock types:

• CanNotDelete — authorized users can read and modify the resource, but cannot delete it. This is the most common lock: it stops the catastrophic accident (deletion) while allowing normal work (configuration changes).
• ReadOnly — authorized users can read the resource but cannot modify or delete it. This is stricter and is used for resources whose configuration must never drift, like a compliance-mandated network setup.

Key facts the exam expects you to know:

• Locks can be applied at the subscription, resource group, or resource scope, and they inherit downward like RBAC assignments.
• Locks override RBAC permissions. Even a subscription Owner cannot delete a resource protected by a CanNotDelete lock. The lock must be removed first.
• The most restrictive lock wins. If a resource group has a ReadOnly lock, everything inside it is read-only, even if an individual resource has no lock.

Resource Tags: Labeling Everything

Azure lets you attach tags — name-value pairs like Environment: Production, Department: Finance, or CostCenter: 42 — to resources and resource groups. Tags are metadata, and their power is organizational, not technical:

• Cost management: Filter your Azure bill by tag to see exactly what the Finance department's resources cost versus Engineering's.
• Operations: Find every resource in the "Production" environment at a glance.
• Automation and policy: Azure Policy can require tags (more on that below), so untagged resources get flagged or blocked.

Tags inherit nothing automatically — a tag on a resource group does not flow to the resources inside it (though policies can enforce consistent tagging). Each resource carries its own tags.

Azure Policy: Enforcing the Rules

RBAC says who can do things. Azure Policy says what is allowed to exist. It is a governance engine that enforces organizational rules across your Azure environment — automatically, continuously, and at scale.

Policy works through policy definitions (the rules, such as "virtual machines must use managed disks" or "resources must have a CostCenter tag") and policy assignments (where the rule applies — a management group, subscription, or resource group). When a policy is assigned, Azure evaluates both existing resources and new ones. Non-compliant resources are flagged on a compliance dashboard, and policies can be configured to deny non-compliant deployments outright or simply audit them for review.

The distinction between the two enforcement effects is exam-critical:

• Deny — blocks the non-compliant action. Try to deploy a VM in the wrong region, and the deployment fails with a policy error.
• Audit — allows the action but records the violation. Useful when you want visibility before you start blocking people's work.

Common real-world policies: restrict which VM SKUs can be deployed (to control cost), require specific tags on all resources, restrict deployments to approved regions (for data residency), and require encryption on storage accounts.

Policy also supports initiatives — bundles of related policy definitions grouped together, such as a complete "NIST compliance" or "PCI DSS" initiative. Instead of assigning forty individual policies, you assign one initiative.

Management Groups: Governance at Scale

As organizations grow, they end up with many subscriptions — one per department, per project, per environment. Managing governance subscription-by-subscription becomes chaos. Management groups solve this by creating a hierarchy above subscriptions: you organize subscriptions into management groups, and then apply RBAC assignments and Azure Policy at the management group level. Everything below inherits the governance automatically.

The hierarchy, from top to bottom:

Management groups → Subscriptions → Resource groups → Resources

A policy assigned at the management group level applies to every subscription, resource group, and resource beneath it. New subscriptions placed under that management group are governed from day one — no one has to remember to configure them.

Microsoft Defender for Cloud: The Security Watchtower

With identity, access, and governance in place, the next question is: who is watching for attacks? Microsoft Defender for Cloud is Azure's cloud-native security posture management and threat protection service. It does two big jobs:

1. Security posture management (CSPM): It continuously assesses your Azure resources against security best practices and gives you a Secure Score — a single number representing how hardened your environment is. It then recommends specific remediations: "enable MFA for these accounts," "encrypt these storage accounts," "restrict network access on these VMs." Fix the issues, and your score rises.
2. Threat protection (CWDPP): Defender plans (such as Defender for Servers, Defender for Storage, Defender for SQL) provide active threat detection — alerting on suspicious activity like brute-force login attempts, unusual data exfiltration, or malware-like behavior on VMs.

Think of it this way: Defender for Cloud is both the building inspector (finding weaknesses before attackers do) and the alarm system (detecting break-ins in progress).

Microsoft Sentinel: The SIEM and SOAR

Microsoft Sentinel is Microsoft's cloud-native SIEM (Security Information and Event Management) and SOAR (Security Orchestration, Automation, and Response) solution. In plain terms: it collects security data from everywhere — Azure, Microsoft 365, on-premises servers, even non-Microsoft clouds — and uses AI to find attacks hiding in the noise.

The SIEM side aggregates logs and alerts into a single pane of glass, correlating events across sources to detect multi-stage attacks that no single tool would catch. The SOAR side automates responses through playbooks: when Sentinel detects a compromised account, a playbook can automatically disable the account, revoke its sessions, and open a ticket — in seconds, without waiting for a human analyst.

For AZ-900, the conceptual understanding is enough: Sentinel = collect security data from many sources + AI-powered threat detection + automated response.

Azure Key Vault: The Safe for Secrets

Every application has secrets: database passwords, API keys, certificates, encryption keys. Hard-coding them into application code or config files is how breaches happen — one leaked repository and every secret is public. Azure Key Vault is the managed service for storing and controlling access to these secrets.

Key Vault handles three kinds of items:

• Secrets — passwords, API keys, connection strings. Applications fetch them at runtime instead of storing them locally.
• Keys — encryption keys used to protect data.
• Certificates — TLS/SSL certificates for securing communications.

Access to the vault itself is controlled through Entra ID authentication and RBAC or vault access policies, so only authorized identities and applications can retrieve secrets. Applications using managed identities can authenticate to Key Vault without storing any credentials at all — the identity is managed by Azure, eliminating the "where do I store the password to get the passwords" problem.

Zero Trust and Defense in Depth: The Security Philosophy

Two models tie this entire chapter together, and the exam expects you to describe both.

Zero Trust is the security philosophy that assumes breach. Its three guiding principles:

1. Verify explicitly — authenticate and authorize every access request using all available signals (identity, device, location, risk). Never trust based on network location alone.
2. Use least privilege — grant only the minimum access needed, for the minimum time needed (just-in-time access).
3. Assume breach — design as if attackers are already inside: segment access, encrypt everything, monitor continuously, and minimize blast radius.

Zero Trust is the philosophical opposite of the old castle model. The castle said "trust everyone inside the walls." Zero Trust says "trust no one by default; verify everything."

Defense in depth is the layered implementation strategy: protect at every layer so that if one layer fails, others still stand. The layers, from outermost to innermost:

1. Physical security — Microsoft's data center protections (relevant for AZ-900's shared responsibility model).
2. Identity and access — Entra ID, MFA, Conditional Access, RBAC.
3. Perimeter — DDoS protection, firewalls (still useful, just not sufficient alone).
4. Network — network security groups, segmentation.
5. Compute — endpoint protection, patching.
6. Application — secure code, input validation.
7. Data — encryption at rest and in transit, classification.

Putting It All Together

Walk through a realistic scenario and watch every concept in this chapter work together:

A new finance analyst joins the company. IT adds her to the Finance-Analysts group in Microsoft Entra ID. That group has an RBAC role assignment — Reader — scoped to the finance resource group, following least privilege. When she signs in from home, Conditional Access evaluates the context and requires MFA on her phone. She can view reports but cannot modify or delete anything. The finance resource group has a CanNotDelete lock, so even an administrator cannot accidentally wipe it. Azure Policy ensures every resource in the subscription carries a Department: Finance tag and denies VM deployments outside approved regions; the policy was assigned at the management group level, so it covers all finance subscriptions. Database passwords live in Azure Key Vault, never in code. Defender for Cloud monitors the environment's Secure Score, and Microsoft Sentinel watches for attack patterns across all data sources, ready to trigger an automated playbook. Every layer assumes the others might fail — defense in depth — and no access is granted without verification — Zero Trust.

That is identity, security, and governance in Azure: not a single product, but a system of interlocking controls. The exam will test each piece individually, but understanding how they fit together is what turns memorized definitions into real comprehension — and real comprehension is what passes exams.

---

End-of-Chapter Test

1. A company wants employees to sign in once and access Azure, Microsoft 365, and Salesforce without re-entering credentials. Which Microsoft Entra ID feature provides this?

A. Conditional Access B. Single sign-on (SSO) C. Multifactor authentication (MFA) D. Privileged Identity Management

2. A user successfully logs in to the Azure portal but receives an "access denied" error when trying to view a virtual machine's settings. Is this an authentication or authorization issue?

A. Authentication — the user's credentials were rejected B. Authorization — the user's identity was verified but they lack permission C. Authentication — the login session expired D. Neither — this indicates a network connectivity problem

3. An organization wants to require MFA only when users sign in from outside the corporate office network. Which Entra ID feature should they configure?

A. Identity Protection with user risk policies only B. Conditional Access policies C. Access reviews D. Single sign-on

4. A developer needs to deploy and manage virtual machines in a single resource group called "Dev-RG" but should have no access to other resource groups in the subscription. What is the best approach following least privilege?

A. Assign the Contributor role at the subscription scope B. Assign the Owner role at the resource group scope C. Assign the Contributor role at the "Dev-RG" resource group scope D. Assign the Reader role at the subscription scope

5. An administrator with the Owner role on a subscription attempts to delete a resource group but the deletion fails. The administrator confirms they have full permissions. What is the most likely cause?

A. The administrator's account is locked B. A CanNotDelete resource lock is applied to the resource group C. Azure Policy is auditing the resource group D. The resource group contains a ReadOnly tag

6. A company wants to prevent any user from deploying virtual machines in the East US region, regardless of their RBAC permissions. Which solution should they use, and with what effect?

A. RBAC — assign the Reader role for East US B. Azure Policy with a Deny effect C. A ReadOnly resource lock on the subscription D. Conditional Access with a block policy

7. An enterprise has 40 Azure subscriptions across multiple departments and needs to apply consistent policies and RBAC assignments across all of them from a single point. What should they use?

A. Resource groups B. Management groups C. Resource tags D. Azure Blueprints

8. Which Azure service provides a Secure Score that measures how well your cloud resources follow security best practices, along with threat protection for workloads?

A. Microsoft Sentinel B. Microsoft Defender for Cloud C. Azure Key Vault D. Microsoft Entra ID

9. A security team wants to collect logs from Azure, Microsoft 365, and on-premises firewalls into one system, detect multi-stage attacks with AI, and automatically disable compromised accounts using playbooks. Which service meets all these requirements?

A. Microsoft Defender for Cloud B. Azure Monitor C. Microsoft Sentinel D. Azure Policy

10. An application needs to retrieve a database connection string at runtime without storing it in source code or configuration files. Where should the connection string be stored?

A. In an Azure Policy definition B. In a resource tag on the application C. In Azure Key Vault as a secret D. In a Conditional Access policy

---

Answer Key

1. B — Single sign-on lets users authenticate once and access multiple applications without re-entering credentials. Conditional Access controls conditions of access; MFA adds verification factors; neither provides the one-login-many-apps experience.

2. B — The login succeeded, so authentication (who you are) worked. The denial is about permissions (what you can do), which is authorization.

3. B — Conditional Access evaluates sign-in context (such as location/network) and applies requirements like MFA only when conditions match. This is its defining scenario.

4. C — Least privilege means granting the minimum needed: Contributor (can manage VMs) scoped to only the "Dev-RG" resource group. Subscription scope (A, D) is too broad; Owner (B) includes access management the developer doesn't need.

5. B — Resource locks override RBAC permissions, including Owner. A CanNotDelete lock blocks deletion while still allowing modification. Auditing (C) only records; tags (D) don't block deletion.

6. B — Azure Policy with a Deny effect blocks non-compliant deployments regardless of the user's RBAC role. RBAC (A) controls who can manage resources, not which configurations are allowed. Locks (C) prevent deletion/modification of existing resources, not new deployments.

7. B — Management groups sit above subscriptions and let you apply RBAC and Policy once across many subscriptions. Resource groups (A) are below subscriptions; tags (C) are for organization/billing; Blueprints (D) is a deprecated packaging feature.

8. B — Microsoft Defender for Cloud provides the Secure Score (posture assessment) plus threat protection plans. Sentinel (A) is the SIEM/SOAR for detection and response across sources.

9. C — Microsoft Sentinel is the SIEM (collect and correlate security data with AI) and SOAR (automated response via playbooks) solution. Defender for Cloud (A) focuses on Azure resource posture and protection, not cross-source investigation and playbooks.

10. C — Azure Key Vault is the central secure store for secrets (connection strings, API keys), keys, and certificates. Applications retrieve secrets at runtime instead of embedding them in code.