Secure storage, databases, and networking

Two ideas run through everything here. Close the public path — private endpoints, disabled public network access, firewalls that default to deny. And stop using shared secrets — Microsoft Entra authorisation instead of account keys, managed identities instead of connection strings, user delegation SAS instead of account SAS. When two answers both technically work, the one that does one of those two things is the keyed one.

2.1 Securing storage accounts

Encryption, which is mostly already done for you

• Storage Service Encryption is always on, 256-bit AES, and cannot be disabled.
• Customer-managed keys (CMK) in Key Vault or Managed HSM replace the Microsoft-managed key for blobs and files. They require the vault to have soft delete and purge protection enabled, and the storage account to have an identity with key permissions.
• Infrastructure encryption adds a second, independent 256-bit AES layer beneath the first — "double encryption". It can only be chosen when the account is created, never afterwards.
• Encryption scopes apply a different key to an individual container or blob within the same account.

Authorising access — the part that is actually tested

# A user delegation SAS: signed with Microsoft Entra credentials, not the
# account key, so it can be revoked without rotating anything.
az storage blob generate-sas \
  --account-name contosodata \
  --container-name reports --name q3.pdf \
  --permissions r \
  --expiry 2026-09-20T18:00Z \
  --auth-mode login --as-user \
  --https-only --full-uri

# Turn shared key authorisation off entirely so account keys — and every
# service and account SAS derived from them — stop working.
az storage account update \
  --name contosodata --resource-group rg-data \
  --allow-shared-key-access false

Network controls

Data protection and immutability

• Soft delete for blobs, containers and file shares — a recovery window before data is really gone.
• Versioning and point-in-time restore for block blobs.
• Immutability policies (WORM) — time-based retention holds data for a fixed period; a legal hold holds it indefinitely until the tag is cleared. Set at container scope or version scope. A time-based policy can be locked, after which retention can only be extended, never shortened.

Microsoft Defender for Storage

Enable it agentlessly at the subscription level (all current and future accounts, with exclusions) or per storage account. No diagnostic logs need to be turned on.

2.2 Securing databases

Authentication

• Set a Microsoft Entra admin on the logical server, then create contained database users mapped to Entra principals — including managed identities.
• Turn on Microsoft Entra-only authentication to disable SQL authentication entirely. This is the keyed answer to "prevent the use of SQL logins, including the server admin account".
• Applications should connect with a managed identity, never a connection string containing a password.

Network

Protecting the data itself

Auditing

• Configure at server level (applies to every database, current and future — the usual answer) or at database level. Enabling both produces duplicate logs.
• Three destinations: Log Analytics workspace (the one that feeds Microsoft Sentinel), Event Hubs, and a storage account.
• Microsoft support operations auditing separately records what Microsoft support engineers do in your database during a support request.
• For SQL Managed Instance, auditing can also be configured with T-SQL server audit specifications.

Microsoft Defender for Databases

An umbrella plan covering four database families, each enabled separately:

• Azure SQL Database servers
• SQL servers on machines — SQL Server on Azure VMs and on Arc-enabled servers
• Open-source relational databases — Azure Database for MySQL, PostgreSQL and MariaDB
• Azure Cosmos DB

It brings two things: Advanced Threat Protection alerts (SQL injection, brute-force attempts, access from an unusual location or principal, suspicious data exfiltration) and, for SQL, vulnerability assessment. The express vulnerability assessment configuration needs no storage account and is the modern default; the classic configuration writes scan results to a storage account you provide.

2.3 Network security groups and application security groups

An NSG is a stateful five-tuple filter — source, source port, destination, destination port, protocol — with a priority from 100 to 4096, evaluated lowest number first. The first match wins and evaluation stops. NSGs associate to subnets and to network interfaces.

Default rules, which cannot be deleted

Service tags (Internet, AzureCloud, Storage, Sql, AzureActiveDirectory, VirtualNetwork, AzureLoadBalancer) stand in for address ranges Microsoft keeps updated, and many accept a regional suffix such as Storage.WestEurope. Application security groups (ASGs) let a rule say "from asg-web to asg-db on 1433" instead of listing IP addresses — the NICs carry the membership, so rules survive scaling. Both NICs in a rule must be in the same virtual network.

flowchart TB
  P["An inbound packet heads for a VM in a virtual network"] --> SA{"Does a Virtual Network Manager<br/>security admin rule match?"}
  SA -->|"Deny"| D1["Dropped — NSG rules<br/>are never evaluated"]
  SA -->|"Always allow"| A1["Delivered straight to the VM —<br/>NSG rules are never evaluated"]
  SA -->|"Allow, or<br/>nothing matches"| SN{"NSG rules — subnet first,<br/>then network interface<br/>lowest priority number first,<br/>and both must allow"}
  SN -->|"Either NSG denies, or neither allows it"| D2["Dropped"]
  SN -->|"Both allow"| OK["Delivered to the virtual machine"]

2.4 Azure Virtual Network Manager

AVNM is the central-governance layer above NSGs. You scope a network manager to a management group or subscription, group virtual networks into network groups (static membership, or dynamic membership driven by an Azure Policy condition on tags or names), then deploy configurations to regions.

Security admin rules, in detail

• Applied at the virtual network level; NSGs apply at subnet and NIC level.
• Priority 1 to 4096, lowest first, and always evaluated before NSGs.
• Three actions: Allow (hand on to the NSGs), Always allow (deliver, skip the NSGs) and Deny (drop, skip the NSGs).
• Only one security admin configuration can be deployed per region per network manager — use multiple rule collections inside it rather than multiple configurations.
• They use an eventual consistency model, so newly created resources pick them up after a short delay.
• Several subnets are exempt: Application Gateway, Azure Bastion, Azure Firewall, Route Server, VPN Gateway, Virtual WAN and ExpressRoute gateway subnets. They also do not apply to private endpoints in managed virtual networks.

2.5 Azure Firewall

flowchart TB
  T["Traffic reaches Azure Firewall"] --> TI{"Threat intelligence mode"}
  TI -->|"Alert and deny, and the address or domain<br/>is on a Microsoft threat feed"| DROP["Dropped before any rule is read"]
  TI -->|"Off, Alert only, or no match"| DNAT["1 · DNAT rules — translate inbound connections"]
  DNAT --> NET["2 · Network rules — layer 3 and 4, any protocol"]
  NET --> APP["3 · Application rules — FQDN, URL and web categories"]
  APP --> PREM["Premium only — IDPS and TLS inspection applied to the permitted flow"]

Two more behaviours worth knowing: DNS proxy makes the firewall the DNS server for the virtual network, which is what lets FQDN-based network rules resolve consistently; and forced tunnelling sends the firewall's own outbound traffic to an on-premises next hop, which requires a dedicated AzureFirewallManagementSubnet.

2.6 Virtual WAN and VPN

A Virtual WAN hub becomes a secured virtual hub the moment you deploy Azure Firewall or a supported partner NVA into it. Routing intent then declares, in one place, that internet traffic and/or private traffic must be inspected by that security appliance — replacing the fleet of user-defined routes you would otherwise maintain per spoke.

2.7 Microsoft Entra Private Access

Part of Global Secure Access, Microsoft's Security Service Edge. Private Access replaces the traditional VPN with per-application access: nothing is published to the internet, the user's client tunnels only the traffic that matches a profile, and Conditional Access is applied per application rather than once at the tunnel.

Administering it needs the Global Secure Access Administrator role, plus Application Administrator to manage connector groups and enterprise applications.

2.8 Private endpoints, Private Link service and service endpoints

flowchart TB
  Q["You need a PaaS resource reached privately"] --> A{"Does it need a private IP inside your own address space?"}
  A -->|"Yes — on-premises, peered and cross-region<br/>networks must reach it too"| PE["Private endpoint — a network interface with a private IP in your subnet"]
  A -->|"No — you only need to stop everyone<br/>except a named subnet reaching it"| SE["Service endpoint — the subnet's identity is presented to the service,<br/>which keeps its public IP and firewall"]
  PE --> DNS["Add a private DNS zone, or clients still resolve and use the public address"]
  DNS --> OFF["Set public network access to Disabled, or the public path stays open beside it"]
  SE --> POL["Service endpoint policies can narrow the subnet to specific storage accounts"]

Azure Private Link service is the other side of the same coin: it is what you create to publish your own service — behind a Standard internal load balancer — so that consumers in other virtual networks and other tenants can reach it through their own private endpoints, with no peering and no overlapping-address problems. Approval of each connection is explicit, automatic or rejected, per your configuration.

2.9 Diagnosing it with Network Watcher

Skill 2 checklist

Next: Skill 3, which covers servers, containers, the application platform — and the AI workloads that make this exam what it is.