M02 · Azure Supporting Technologies

Course: Microsoft Defender — Security Operations Fundamentals Module duration: 3.5 hours (including lab) Format: Instructor-led, hands-on

Currency note (as of June 2026): Azure portal labels, blade names, and navigation paths change frequently. This handout describes goals and structure rather than exact click-paths where the portal is volatile. Verify current paths against Microsoft Learn before relying on a specific UI step.

Learning objectives

By the end of this module you will be able to:

  1. Describe Azure’s organizational hierarchy: tenant, management group, subscription, resource group.
  2. Identify and explain key resources used by security services: Log Analytics workspace, Key Vault, Storage Account, and Virtual Machine.
  3. Explain what Azure Policy does and how it enforces governance at scale.
  4. Navigate the Azure portal to locate and review these resources.

1. Why a SOC analyst needs Azure fundamentals

Microsoft’s security tooling does not float in space — it runs on Azure and reads from Azure resources. Defender for Cloud assesses Azure subscriptions; Microsoft Sentinel stores its data in a Log Analytics workspace; Defender for Endpoint onboards virtual machines; secrets used by automation live in Key Vault; logs land in Storage Accounts. If you do not understand where these resources sit and how they relate, incident investigation and tool configuration become guesswork. This module gives you the structural literacy the rest of the course assumes.

2. The Azure organizational hierarchy

Azure organizes everything in a strict containment hierarchy. Each level is a scope — a boundary at which you can apply access control (role-based access control, RBAC) and governance (Azure Policy). Settings applied at a higher scope inherit downward.

flowchart TD A["Microsoft Entra ID tenant<br/>(identity boundary)"] --> B["Root management group"] B --> C["Management group(s)<br/>(group subscriptions for governance)"] C --> D["Subscription<br/>(billing + access boundary)"] D --> E["Resource group<br/>(lifecycle container)"] E --> F["Resource<br/>(VM, Key Vault, workspace, ...)"]

Diagram alt text: A top-down hierarchy of five nested levels. At the top is the Microsoft Entra ID tenant, the identity boundary. Below it is the root management group, then one or more management groups that group subscriptions for governance, then a subscription that acts as a billing and access boundary, then a resource group that is a lifecycle container, and finally individual resources such as a virtual machine, Key Vault, or workspace at the bottom.

  • Tenant (Microsoft Entra ID tenant) — the identity boundary. A tenant is a dedicated instance of Microsoft Entra ID (formerly Azure Active Directory) holding your organization’s users, groups, and app registrations. Every Azure subscription trusts exactly one Entra tenant to authenticate its users. Identity is the front door to everything else.
  • Management group — a container to organize multiple subscriptions and apply policy and access at scale. All management groups roll up to a single root management group. Useful when an organization has many subscriptions that should share governance.
  • Subscription — a billing and access-management boundary. Resources are billed to a subscription, and it is a common scope for assigning who can do what. Defender for Cloud plans are often enabled per subscription.
  • Resource group — a lifecycle container for resources that share a purpose and are managed and deleted together (e.g., everything for one application). A resource lives in exactly one resource group.
  • Resource — an individual manageable item: a VM, a Log Analytics workspace, a Key Vault, etc.

Why this matters for security: RBAC and Azure Policy are applied at a scope and inherit downward. Assigning a reader role or a policy at the management-group level reaches every subscription beneath it. Knowing the hierarchy tells you where a permission or control actually takes effect.

Entra ID’s relationship to subscriptions

A single Entra tenant can be trusted by many subscriptions; a subscription trusts one tenant. This separation matters: moving a subscription between tenants changes who can sign in, and identity risk (covered conceptually here, in depth elsewhere) is managed at the tenant level while resource access is granted at subscription/resource-group/resource scopes.

3. Key resources used by security services

3.1 Log Analytics workspace — the data backbone

A Log Analytics workspace is the storage and query environment for log and telemetry data in Azure Monitor. It is the single most important resource for SOC work because:

  • Microsoft Sentinel is built on top of a Log Analytics workspace — Sentinel’s incidents and analytics query data stored there.
  • Defender for Cloud, Azure resources, and agents can send their logs into a workspace.
  • You query it with KQL (Kusto Query Language) — the same language used in Defender Advanced Hunting, which you will use throughout the course.

Data is organized into tables (e.g., Heartbeat, SecurityEvent, SigninLogs). Each workspace has a retention setting (how long data is kept) and a pricing/commitment tier that affects ingestion cost. A minimal example query:

// Count heartbeat signals per computer in the last hour
Heartbeat
| where TimeGenerated > ago(1h)
| summarize Beats = count() by Computer
| order by Beats desc

Expected output: one row per reporting computer with a Beats count, sorted highest first. If a machine you expect is missing, it may not be sending data — a common first check during onboarding.

3.2 Key Vault — secrets, keys, and certificates

Azure Key Vault safeguards three object types:

  • Secrets — arbitrary sensitive strings (connection strings, passwords, API tokens).
  • Keys — cryptographic keys for encryption/signing (can be backed by hardware security modules).
  • Certificates — TLS/SSL certificates with lifecycle management.

Access-control model: Key Vault supports two models — Azure RBAC (recommended; permissions via Azure roles) and the older vault access policy model. As of June 2026, Microsoft recommends the Azure RBAC model for new vaults. For a SOC, Key Vault is doubly relevant: it stores the secrets your automation uses (e.g., a playbook’s API credential), and anomalous access to it is itself a signal — Defender for Key Vault (Module 8) alerts on unusual access patterns.

3.3 Storage Account — where logs and data land

An Azure Storage Account provides several data services:

  • Blob — unstructured object storage (files, logs, backups, malware samples in a lab).
  • Queue — message queuing for decoupled processing.
  • Table — NoSQL key-value store.
  • File — managed SMB file shares.

Security relevance: storage accounts are a common destination for exported logs and a frequent SIEM ingestion source; they are also a high-value target (data exfiltration) and are protected by Defender for Storage (Module 8), which adds malware scanning and anomaly detection on blobs. Misconfigured public blob access is a classic finding in posture assessments.

3.4 Virtual Machine — the endpoint you onboard

An Azure Virtual Machine (VM) is an on-demand compute instance. Components a SOC analyst should recognize:

  • OS disk — the managed disk holding the operating system (and optional data disks).
  • NIC (network interface card) — connects the VM to a virtual network.
  • NSG (network security group) — a set of allow/deny rules controlling inbound/outbound traffic to a NIC or subnet; a primary network control and a frequent posture finding when overly permissive.

VMs are the onboarding target for Defender for Endpoint and are protected by Defender for Servers (Module 8). Understanding the OS disk / NIC / NSG trio helps you reason about both how a VM is attacked over the network and how telemetry leaves it.

flowchart LR subgraph RG["Resource group"] VM["Virtual Machine"] --- DISK["OS disk"] VM --- NIC["NIC"] NIC --- NSG["NSG (allow/deny rules)"] NIC --- VNET["Virtual network / subnet"] end

Diagram alt text: Inside a resource group box, a Virtual Machine connects to three things: an OS disk, and a NIC. The NIC in turn connects to an NSG that holds allow/deny rules and to a virtual network subnet, showing how a VM attaches to storage and to the network through its interface.

4. Azure Policy — governance at scale

Azure Policy evaluates your resources against rules you assign and reports — or enforces — compliance. Where RBAC controls who can act, Azure Policy controls what the resulting configuration is allowed to be.

  • Definitions — the rule itself (e.g., “storage accounts must not allow public blob access”). There are many built-in definitions; you can also author custom ones.
  • Assignment & scope — you assign a definition (or an initiative, a grouped set of definitions) at a scope (management group, subscription, or resource group). It applies there and inherits downward.
  • Effects — what happens on evaluation: Audit (report non-compliance), Deny (block non-compliant creation), DeployIfNotExists (auto-remediate by deploying a needed resource), and others.
  • Compliance view — a dashboard showing the percentage of in-scope resources that satisfy each policy, so you can track drift over time.

Security tie-in: Defender for Cloud’s recommendations and regulatory-compliance dashboard (Module 8) are powered in part by Azure Policy initiatives. Understanding policy here makes that module’s Secure Score and compliance content click into place.

5. Navigating the Azure portal (orientation)

As of June 2026 — verify live, paths change. The Azure portal (https://portal.azure.com) lets you:

  • Browse the hierarchy via Management groups, Subscriptions, and Resource groups blades.
  • Open any resource to see its Overview, Activity log (who did what), Access control (IAM) (RBAC assignments), and Tags.
  • Find resources fast with the global search bar and All resources view.
  • Review governance under Azure Policy (assignments and compliance) and Microsoft Defender for Cloud (security posture).

In the lab you will open a Log Analytics workspace and run a KQL query, review a Key Vault’s access configuration, and examine an assigned Azure Policy and its compliance state.

6. Module summary

  • Azure nests resources as tenant → management group → subscription → resource group → resource; each level is a scope where access (RBAC) and governance (Policy) apply and inherit downward.
  • The Entra ID tenant is the identity boundary; subscriptions trust one tenant.
  • Security tooling depends on four resources: Log Analytics workspace (data backbone, queried with KQL, foundation of Sentinel), Key Vault (secrets/keys/certificates), Storage Account (log landing zone and exfiltration target), and Virtual Machine (Defender onboarding target; know OS disk / NIC / NSG).
  • Azure Policy audits or enforces configuration compliance at scale and underpins Defender for Cloud recommendations.

Glossary (first-use acronyms in this module)

  • Entra ID — Microsoft Entra ID, the cloud identity service (formerly Azure Active Directory).
  • KQL — Kusto Query Language, used to query Log Analytics and Defender hunting tables.
  • NIC — Network Interface Card (a VM’s network attachment).
  • NSG — Network Security Group (allow/deny network rules).
  • RBAC — Role-Based Access Control (who can perform which actions at a scope).
  • SIEM — Security Information and Event Management.
  • SMB — Server Message Block (file-sharing protocol; Azure Files uses it).
  • VM — Virtual Machine.

Sources

Citations recorded per CLAUDE.md. All pages are living documents; “as of June 2026” stamps indicate currency. Verify before reuse.

  1. Microsoft Learn — “Azure management groups, subscriptions, and resource hierarchy.” https://learn.microsoft.com/azure/governance/management-groups/overview
  2. Microsoft Learn — “Log Analytics workspace overview” / Azure Monitor Logs. https://learn.microsoft.com/azure/azure-monitor/logs/log-analytics-workspace-overview
  3. Microsoft Learn — “About Azure Key Vault.” https://learn.microsoft.com/azure/key-vault/general/overview
  4. Microsoft Learn — “Azure Storage account overview.” https://learn.microsoft.com/azure/storage/common/storage-account-overview
  5. Microsoft Learn — “Virtual machines in Azure” and “Network security groups.” https://learn.microsoft.com/azure/virtual-machines/overview · https://learn.microsoft.com/azure/virtual-network/network-security-groups-overview
  6. Microsoft Learn — “What is Azure Policy?” https://learn.microsoft.com/azure/governance/policy/overview
  7. Microsoft Learn — “Kusto Query Language (KQL) overview.” https://learn.microsoft.com/azure/data-explorer/kusto/query/

M02 of 10 · Microsoft Defender — Security Operations Fundamentals · maps to curriculum.md → M02 learning objectives 1–4. Student handout — distribute freely to learners. No answer keys contained.