Memory hook: Scope, data, compute, route, recover.
Reviewed 10 October 2026. Read this once, then answer the last-pass checks without looking.
Must remember by domain
| Domain | Rapid revision |
|---|---|
| Identity | Entra roles administer the directory; Azure RBAC roles authorize resources. Effective access depends on principal/group, role and scope inheritance. Owner can assign access; Contributor generally cannot assign roles. Data-plane roles can still be required. Guests, licenses, group membership and SSPR eligibility are separate checks. |
| Governance | Management group → subscription → resource group → resource. Policy evaluates configuration; deny blocks eligible new/changed operations; audit reports; remediation for supported effects needs identity/permissions. Tags do not automatically inherit. CanNotDelete allows changes; ReadOnly blocks supported writes. Locks target management operations, not all data deletion. |
| Storage access | Network allowance plus data authorization are both required. Account/service/user-delegation SAS differ in scope and signing. Stored access policies apply to service SAS, not account or user-delegation SAS. Prefer short-lived minimum permissions; rotate keys safely. Azure Files needs share and filesystem permissions. |
| Storage data | LRS local; ZRS zones; GRS/GZRS asynchronous second region; RA variants expose secondary reads. Versioning preserves earlier content; soft delete preserves eligible deleted content; lifecycle manages age. Archive rehydration differs from online tiers. Object replication requires supported block-blob, versioning and change-feed configuration. |
| Compute | ARM/Bicep parameters, resource references/modules and dependencies define deployment; what-if is a preview. Availability sets separate fault/update domains; zones separate zonal failures; scale sets manage fleets. Guest shutdown can still bill compute; deallocation still leaves billable disks. Regional moves require supported relocation/redeployment. |
| Apps/containers | ACR stores images; ACI runs container groups; Container Apps adds revisions/scaling. App Service plan owns shared compute. Scale up changes size/tier; scale out changes count. Slots stage/swap eligible apps; sticky settings stay with a slot. VNet integration is outbound; private endpoint is private inbound. |
| Networking | Nonoverlapping CIDRs, subnet/NIC NSGs, effective routes and return path all matter. Peering is nontransitive. NSGs are stateful, lower-number priority first. Longest-prefix route wins; equal prefixes normally prefer UDR, then BGP, then system. Private endpoints need DNS; service endpoints retain the service public endpoint. |
| Monitor/recover | Activity Log records management changes; resource logs need collection; AMA/DCR handles supported guest telemetry. Alert rule detects; action group responds; processing rule modifies alert handling. Backup restores history; Site Recovery supports failover. RPO bounds data loss; RTO bounds time to usable service. |
Diagnostic sequence and traps
Network failure: client DNS → destination IP → effective route → both NSGs/firewall → listener/probe → application permission. Failed restore: recovery point → key access → target compatibility/capacity → network → application validation. A private endpoint does not automatically disable public access; a healthy VM is not proof of application readiness.
Last-pass self-check
1. Contributor cannot read blobs: contradiction?
No. Management permission and blob data permission are different planes.
2. Two peered spokes cannot communicate through a hub automatically: why?
Peering is nontransitive; configure an appropriate forwarding/transit architecture.
3. What reverses a database write after an App Service slot swap?
The swap does not; data changes need their own compatible rollback/recovery design.
4. Which protection recovers an overwritten blob?
A retained earlier version or suitable backup, not merely a current replica.
5. An alert exists but nobody is notified: inspect what?
Action group, processing/suppression rules and notification configuration.
Sources
- Official exam scope and version
- Azure documentation
- Storage SAS types and stored access policies
- Azure route selection and exceptions
- Virtual network address reservations
Every topic at a glance
Open any topic to revisit its essential facts, decisions and exam traps. Use the full topic for active recall and supporting references.
01 · Microsoft Entra ID and Azure RBAC
Memory hook: Entra identifies the principal; Azure RBAC authorises an action at a scope.
Must remember
- A Microsoft Entra tenant is an identity directory. An Azure subscription is a billing/resource-management boundary associated with a tenant. Management groups organise subscriptions; resource groups organise resources. Do not treat tenant and subscription as synonyms.
- Manage users, groups, properties, assigned licences and guest access deliberately. Security groups organise access; dynamic membership uses rules when licensing/features permit. B2B guests retain an external identity relationship. Self-service password reset needs appropriate eligibility, authentication methods and configuration.
- An Azure role assignment is principal + role definition + scope. Scope can be management group, subscription, resource group or resource, with inheritance. Inspect effective assignments rather than only the nearest resource. Entra directory roles and Azure resource roles are different permission systems.
- Owner can manage resources and access; Contributor manages resources but does not normally grant Azure roles; Reader reads management information. Data-plane roles, such as Storage Blob Data Reader, authorise data operations separately. Management-plane access is not always data access.
- System-assigned managed identity follows one resource's lifecycle; user-assigned identity is an independent reusable resource. Both avoid embedded secrets for supported authentication. Grant the identity's service principal only the required target roles.
- PIM supports time-bound/eligible privileged access; Conditional Access evaluates sign-in conditions and grant controls with appropriate licensing. MFA strengthens authentication; it does not create a missing resource role assignment. Keep a monitored emergency-access design.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| App needs storage access without stored credentials | Managed identity plus an appropriate data role. |
| User can manage a storage account but cannot read blobs | Check data-plane permissions. |
| Temporary privileged operations | Eligible/time-bound access using PIM where available. |
Traps
- Entra administrator is not automatically Owner of every Azure subscription.
- Contributor and Owner differ in access-management privileges.
- A role at a parent scope can remain effective after a narrower assignment is removed.
02 · Subscriptions, Policy and Cost Governance
Memory hook: RBAC decides who may act; Policy evaluates what configuration is acceptable.
Must remember
- A management-group hierarchy applies governance across subscriptions. Resources belong to resource groups and subscriptions, but not every resource type supports every move. Check dependencies, provider registration, quotas and move validation before changing scope.
- Azure Policy definitions evaluate resource properties; initiatives group policies; assignments apply them at scopes with exclusions/exemptions. Effects include audit, deny, modify and deployIfNotExists. Existing noncompliant resources may need a remediation task and suitable managed-identity permissions.
- A CanNotDelete lock blocks management-plane deletion; ReadOnly can block management operations that look like reads but use POST. Locks are inherited and are not a universal data-plane protection mechanism. A privileged user able to remove a lock can change its protection.
- Tags support ownership and cost allocation, but tags do not automatically inherit from resource group to resource. Policy can enforce or add supported tags. Keep a naming/tagging convention and handle untaggable/shared resources explicitly.
- Cost Management analyses spending; budgets notify configured thresholds; Advisor recommends improvements. A budget is not a universal immediate resource shutdown. Billing latency, reservations/savings commitments and shared costs affect interpretation.
- Resource groups are useful for lifecycle management, but deleting a group is a broad action. Review dependencies and locks first. Region affects resource availability, residency and price; the resource group's metadata location does not force every contained resource into that Region.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Prevent unsupported regions at deployment | Azure Policy deny at the appropriate scope. |
| Let a team manage resources but not grant roles | Contributor, constrained to the required scope. |
| Find an oversized idle workload | Usage evidence plus Advisor/Cost Management recommendations. |
Traps
- Audit reports a problem; it does not block it.
- A tag on a group is not automatic tag inheritance.
- A budget alert is not a guaranteed spending cap.
03 · Storage Access, Encryption and Redundancy
Memory hook: Network reachability, authorisation and encryption are separate storage controls.
Must remember
- Storage accounts expose supported services such as blobs, files, queues and tables. Choose the account kind/features, Region and redundancy before relying on a capability. Names and endpoints have service-specific scope rules.
- Prefer Entra/managed-identity authorisation where supported. Account keys are broad credentials; rotate them with a staged client update. A SAS delegates selected operations for a time window and resource scope. User-delegation SAS uses Entra-backed delegation for supported Blob access; service/account SAS have different signing and capabilities.
- A stored access policy can centrally control/revoke associated supported service SAS permissions; it does not apply to every SAS type. Time skew, expiry, signed permissions, protocol and network restrictions can explain an otherwise valid token's failure.
- SAS recall: service SAS is signed with an account key and can reference a stored access policy; account SAS is signed with an account key and can cover supported account/service operations; user-delegation SAS is signed with an Entra-backed delegation key for supported Blob access. Stored access policies do not apply to account SAS or user-delegation SAS. Choose scope and revocation requirements before choosing the token type.
- Storage firewalls restrict network access. A service endpoint uses supported service networking and VNet rules; a private endpoint gives a private IP path and requires correct private DNS. Neither substitutes for authorisation. Disable public access deliberately when the requirement demands it.
- LRS replicates within one location; ZRS spans zones in a Region; GRS/GZRS add asynchronous geographic replication; RA variants allow supported secondary reads. Geo-replication lag affects possible data loss. Redundancy is not backup against authorised deletion.
- Storage encryption protects at-rest data; customer-managed keys add key lifecycle and access responsibilities. Object replication between supported blob accounts has prerequisites and scope; it is not a universal synchronisation of every storage service.
- Use Storage Explorer for interactive data management and AzCopy for scripted transfer. Choose an authentication method and validate source/destination permissions; success transferring a subset does not prove the entire dataset reconciles.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Temporary restricted blob access | A suitably scoped SAS, preferably user delegation when it fits. |
| Private IP access from a VNet | Private endpoint plus DNS and data authorisation. |
| Regional AZ resilience without a second Region | ZRS where supported. |
Traps
- A private endpoint does not automatically disable the public endpoint.
- RA-GRS secondary data may lag.
- A management role can lack permission to read stored data.
04 · Blob Storage and Azure Files
Memory hook: Versions preserve earlier content; soft delete recovers deletion; lifecycle controls aging.
Must remember
- Blob containers hold objects; Azure Files exposes managed file shares over supported protocols. Blob access and a mounted file share are different application interfaces. Identity-based SMB access combines share-level permissions with file/directory permissions.
- Blob access tiers trade storage price against access/retrieval charges and availability behaviour. Hot, cool, cold and archive fit different access patterns; archive rehydration takes time and minimum-duration charges can apply. Check account/redundancy compatibility.
- Versioning retains previous eligible blob versions. Soft delete retains deleted eligible data for a configured period. Container soft delete, blob soft delete and file-share soft delete protect different objects. A snapshot is a point-in-time copy/reference with its own lifecycle.
- Lifecycle rules filter eligible blobs/versions and automate tiering/deletion. Consider current versions, previous versions and snapshots separately. Moving to a cheaper tier too early can create retrieval and early-deletion costs.
- Azure Files snapshots/backup support recovery according to configuration. Restore the correct file/share point and validate permissions and usability. A retained snapshot can continue consuming storage after active files are removed.
- Object replication has supported block-blob/versioning/change-feed requirements and destination behaviour. It does not duplicate every account setting or immediately provide a tested application disaster-recovery plan.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Recover yesterday's overwritten blob | A retained previous version or suitable backup. |
| Recover a recently deleted share | Configured share soft delete/backup, depending on the event. |
| Rarely used data must remain immediately readable | Choose an online tier rather than assuming archive fits. |
Traps
- Soft delete must have protected the resource before the event.
- Archive is not an instant-access tier.
- Deleting current content can leave charged historical versions.
05 · ARM Templates and Bicep
Memory hook: Declare the desired resources, inspect the proposed change and preserve clear ownership.
Must remember
- ARM templates are declarative JSON; Bicep offers a concise language that compiles to ARM deployments. Parameters supply inputs, variables simplify expressions, resources declare objects, modules group reusable declarations and outputs expose selected results.
- A resource reference can establish an implicit dependency; explicit dependsOn is for dependencies not already expressed. Deployment ordering does not prove application readiness. Existing-resource declarations reference objects without necessarily taking over their full lifecycle.
- Use parameter files and secure parameters for sensitive inputs, but remember that secrets can still leak through outputs, logs or resource properties. Prefer managed identities and Key Vault references where supported.
what-ifpreviews supported changes; template validation checks syntax/configuration within its scope. Neither proves a deployment will have quota, permissions or a functioning application. Check incremental versus deletion behaviour and use deployment stacks or supported lifecycle controls deliberately.- Exported templates are a starting point, not always a complete reusable description of every deployed feature. Bicep decompilation may need repair/refactoring. Review API versions, unique names, dependencies, region support and hard-coded IDs.
- Deploy at the scope the resource type supports: resource group, subscription, management group or tenant. The deployer needs the required resource/deployment permissions; a reusable module does not grant them. Inspect deployment operations for the first relevant failure before retrying.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Reusable network deployment across environments | Bicep module with validated parameters. |
| See what an update may change | ARM/Bicep what-if plus review. |
| Secret needed at runtime | Managed identity and a supported secret-reference pattern. |
Traps
- An exported template can omit unsupported state.
- A successful what-if is not a guarantee of apply success.
- A secret marked secure can still be leaked by unsafe output use.
06 · Virtual Machines, Disks and Scale Sets
Memory hook: Size for the bottleneck, place for failure and distinguish stopped from deallocated.
Must remember
- Choose VM family/size using CPU, memory, storage throughput, networking and compatibility. Availability differs by Region and quota. Resizing may require restart/deallocation or a compatible host allocation; check disk and NIC limits too.
- Managed disks have performance and redundancy options. OS disks, data disks and temporary disks have different purposes; temporary storage is not durable business data. Snapshots capture disk state, but application consistency may require additional coordination.
- Availability sets distribute supported VMs across fault/update domains; availability zones distribute across zonal failure domains. A VM Scale Set manages a group of instances with selected orchestration, upgrade and autoscale behaviour. Health probes and application readiness affect safe replacement.
- Stopped within the guest can leave compute allocated and billed; deallocated releases allocation, though retained disks, snapshots and other resources can still bill. Public/private address behaviour depends on address configuration and lifecycle.
- Encryption at host protects supported host-side storage paths; disk encryption and guest/application encryption solve related but distinct requirements. Use trusted boot/security features where the workload and VM generation support them.
- Moving a resource group/subscription is a management-scope operation; moving to another Region generally involves a supported relocation/redeployment process. Validate dependencies, identity/role assignments, network addresses, extensions and backup settings after any move.
- Use Bastion or appropriate controlled administration paths. VM extensions and cloud-init/custom-data mechanisms help configure guests, but failed bootstrap scripts need logs and exit-status investigation. Never assume the portal's running state means the app is ready.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Scale a replaceable VM fleet | VM Scale Sets with health-aware policy. |
| Survive a zone loss | Sufficient working capacity across zones and resilient state. |
| Stop paying for allocated compute during a pause | Deallocate, then account for retained resources. |
Traps
- Guest shutdown and deallocation differ.
- Temporary disk data must be reproducible.
- A Region move is not merely changing a resource-group label.
07 · App Service and Container Platforms
Memory hook: Separate image storage, execution, application configuration and the hosting plan.
Must remember
- ACR stores container images/artifacts. Authenticate pushes/pulls with appropriate identities and roles; prefer immutable image digests for a known release. Registry access does not grant the running application permission to its database.
- Container Instances runs container groups without managing a cluster. Container Apps provides managed application environments, revisions, ingress and event-driven scaling capabilities. AKS gives Kubernetes orchestration with greater platform control and responsibility; it is not the default answer for every container.
- Size container CPU/memory and configure health/startup behaviour. Container Apps scaling rules and minimum replicas affect availability, cold starts and cost. Separate revision traffic from image publishing; pushing an image alone is not necessarily deployment.
- An App Service plan determines shared compute capacity, Region and pricing tier; apps run within it. Scale up changes plan capability; scale out changes instance count. Apps sharing a plan can compete for its resources.
- Deployment slots support staged releases and swaps on eligible tiers. Mark environment-specific settings as slot settings where needed. Warm up and validate the target before swapping; external database changes require their own compatibility plan.
- Configure custom-domain ownership, DNS records and TLS bindings separately. VNet integration primarily handles supported outbound access; private endpoints support private inbound access. Access restrictions, DNS and the destination's permissions still matter.
- Backup support depends on plan/features and configuration; define a restore test. Managed identity and Key Vault references reduce stored credentials. Inspect app logs and dependency/network failures before simply increasing plan size.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Run a small container without managing nodes | Container Instances or Container Apps, according to application/scaling needs. |
| Test a web release before moving users | App Service deployment slot. |
| App needs private database access | Supported VNet integration plus routes, DNS and authorisation. |
Traps
- A registry is not a container runtime.
- VNet integration is not equivalent to private inbound access.
- A slot swap does not reverse database writes.
08 · Virtual Networks, Routes and Secure Access
Memory hook: Check the effective route and the effective rule in both directions.
Must remember
- VNets contain address spaces and subnets. Plan non-overlapping ranges and future growth; supported peering requires compatible addresses. Peering connects VNets but is not automatically transitive through a third VNet.
- Azure selects routes using prefix specificity and route-source precedence for equal prefixes; inspect effective routes when system, BGP and user-defined routes interact. A UDR can direct traffic to a virtual appliance, but the appliance must forward it and the return path must work.
- For ordinary equal-prefix comparisons, remember UDR → BGP → system; first compare the destination prefix length. A matching
/24normally beats a/16regardless of that general source order. Service-specific routes have exceptions: service-endpoint routes cannot simply be overridden by a UDR. Inspect the effective route rather than treating the mnemonic as universal. - Azure reserves the first four and last IPv4 addresses of each subnet. A
/27contains 32 addresses, leaving 27 usable; service-specific subnet sizing can require more than the generic minimum. Subnet capacity planning must include service reservations and scale-out needs. - NSGs are stateful network filtering with priority-ordered allow/deny rules. They can apply at subnet and NIC scopes; evaluate the effective combination. Application security groups group supported VM interfaces for rule targeting; they are not application-layer WAFs.
- Public IP addresses have SKU/allocation/zone properties. NAT Gateway supports explicit outbound SNAT for associated subnets; consider port use and destination patterns. Do not assume new workloads receive default outbound internet access.
- Bastion provides managed administration through supported private VM access without exposing a public management port on each VM. It still needs the required deployment/network configuration and authorised users.
- Service endpoints extend supported service access from a VNet using its public service endpoint and service-side rules. Private endpoints use a private IP for a specific resource/subresource; DNS must resolve appropriately. Endpoint creation and resource approval are separate checks.
- Diagnose with Network Watcher tools, Connection Monitor, effective security rules/routes, name resolution and application listener checks. Existing stateful flows may not behave like brand-new test connections after a rule change.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| One private PaaS resource endpoint | Private Link/private endpoint with private DNS. |
| Traffic must traverse a network appliance | UDR plus forwarding and a symmetric return path. |
| VM administration without a VM public IP | Bastion where appropriate. |
Traps
- Peering is not automatically transitive.
- A service endpoint does not put the service itself inside your subnet.
- An NSG allow does not create a route.
09 · DNS and Load Balancing
Memory hook: DNS answers names; Layer 4 forwards connections; Layer 7 routes application requests.
Must remember
- Azure DNS hosts authoritative public zones; domain registration is a separate function. Delegate with the correct name servers. Private DNS zones require links to the VNets that need resolution; autoregistration is a specific feature, not universal record creation.
- Azure DNS Private Resolver supports hybrid resolution through inbound/outbound endpoints and forwarding rulesets. Avoid loops and test from the real client network. DNS TTL and negative caching can make a corrected record appear stale.
- Azure Load Balancer operates at Layer 4 for supported TCP/UDP traffic, with public or internal frontends, backend pools, probes and rules. Probe success depends on the actual response and permitted probe path. An inbound NAT rule is not the same as balancing to a pool.
- Application Gateway provides regional HTTP/S routing and WAF integration. Front Door provides global HTTP/S application delivery and edge features. Traffic Manager uses DNS routing and is not a reverse proxy for every request.
- TLS can terminate at an application gateway/edge, with a separate encrypted connection to the origin where configured. Host headers, certificate names, SNI and backend settings must align. A valid frontend certificate does not prove origin TLS works.
- Troubleshoot the client DNS answer, frontend connectivity, rule, backend health and application listener in order. A health probe can be too shallow: test a path that reflects usable service without making every shared dependency trigger an unnecessary fleet-wide outage.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Regional path-based HTTP routing | Application Gateway. |
| Global HTTP application delivery | Front Door. |
| TCP/UDP load distribution | Azure Load Balancer. |
Traps
- Traffic Manager decisions can remain cached.
- A healthy probe is only as useful as its tested condition.
- Private-zone association is not inherited through every network connection.
10 · Azure Monitor, Logs and Alerts
Memory hook: Metrics quantify, logs explain, traces connect and alerts start a response.
Must remember
- Azure Monitor combines metrics and logs; Log Analytics workspaces hold queryable log data. Activity Log records management-plane events; resource/application logs require relevant collection configuration. Diagnostic settings route supported categories to selected destinations.
- Azure Monitor Agent uses data collection rules for supported guest telemetry. VM, Storage and Network Insights provide focused views; Application Insights adds application performance and tracing with suitable instrumentation. Guest memory/disk metrics are not automatically identical to platform metrics.
- KQL pipelines transform tables:
wherefilters,projectselects columns,summarizeaggregates,bin()groups time intervals, and joins combine data. Example:Heartbeat | summarize LastSeen=max(TimeGenerated) by Computerfinds each computer's latest recorded heartbeat; absence can mean collection failure, not only host failure. - Alert rules define signal, scope, evaluation and condition. Action groups define notifications/actions. Alert processing rules modify processing such as suppression under selected conditions; they do not change the source telemetry. Use dynamic thresholds where appropriate and test missing-data behaviour.
- Network Watcher and Connection Monitor help inspect path and connectivity. Logs, effective routes/rules and an application test answer different questions. Narrow time windows and correlation IDs reduce noise; retention and ingestion volume affect cost.
- Monitor the collection pipeline itself. Permissions, network access, workspace configuration and data collection rules can break visibility. Avoid logging secrets and unnecessary personal data, and define retention according to operational/evidence requirements.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Who changed an Azure resource? | Activity Log and relevant audit evidence. |
| Notify an operations group on a metric breach | Alert rule linked to an action group. |
| Investigate recurring connection failures | Connection Monitor plus route, rule and application evidence. |
Traps
- No logs can mean no collection.
- Action groups do not define the alert threshold.
- Average response time can conceal severe tail latency.
11 · Azure Backup and Site Recovery
Memory hook: Backup restores a point; replication supports failover; neither is proven until tested.
Must remember
- Recovery Services vaults and Backup vaults support different workload/protection scenarios. Select the vault type, Region, redundancy and policy supported by the resource. A vault existing does not mean a backup is configured or healthy.
- Backup policies control schedule/retention; backup instances/items and recovery points show actual protection. App-consistent recovery requires supported coordination. Soft delete and immutability settings can protect backups but also affect deletion and retention obligations.
- Restore to the intended location or an isolated validation environment as supported. Check encryption-key access, identity permissions, networking, data consistency and application startup. Monitor job failures, missing recovery points and restore results, not just policy assignments.
- Site Recovery replicates supported workloads for disaster recovery. Recovery plans coordinate sequencing and automation. A test failover validates a separate test environment; planned and unplanned failover have different source availability and data-loss implications.
- RPO measures tolerable lost data/time; RTO measures time to useful service. Replication lag, application dependencies, DNS, certificates, secrets and capacity all affect the measured result. Failback needs reverse protection/synchronisation and deliberate traffic control.
- Keep recovery responsibilities documented, practise drills and review costs for replicas, snapshots, storage and reserved recovery capacity. Replication can preserve infrastructure availability while still copying logical corruption.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Recover data before an accidental deletion | A suitable retained backup/recovery point. |
| Move a supported workload to a DR Region during outage | Site Recovery failover with a tested recovery plan. |
| Validate DR without disrupting production | Test failover in an isolated network. |
Traps
- Replication is not historical backup.
- A successful backup job does not measure restore time.
- A vault lock/immutability policy must match retention and deletion requirements.