The ACR admin account is disabled by default, has two independently regenerable passwords, and is not recommended for production or multi-user scenarios.
ACR admin account is disabled by default, provides full push/pull access, has two independently regenerable passwords, and is not recommended for production or multi-user scenarios.
ACR admin account password regeneration takes approximately 60 seconds to replicate.
Password regeneration for ACR admin accounts takes approximately 60 seconds to replicate.
All ACR image transfers use HTTPS with TLS encryption.
ACR API rate limits (throttling) apply independently per geo-replica, not globally across the registry.
ACR authentication options are Azure identity, Microsoft Entra service principal, or admin account; all image transfers use HTTPS with TLS.
The access token from az acr login is valid for 3 hours and must be renewed.
ACR authentication options are Azure identity, Microsoft Entra service principal, or admin account.
Best practice is to create an ACR registry in the same Azure region as deployment targets for network-close storage and reduced latency.
Content trust (image tag signing) in ACR is a Premium-only feature.
ACR registries should be placed in a dedicated resource group to avoid accidental deletion when cleaning up container host resources.
Disabling --region-endpoint-enabled on an ACR geo-replica excludes it from global routing but data still syncs and storage costs still accrue.
The DOCKER_COMMAND environment variable can be set to switch az acr login to alternative container tools like podman.
The DOCKER_COMMAND environment variable can be set to switch az acr login to use alternative container tools like podman.
When using az acr login --expose-token, the username for docker login is the all-zeros GUID 00000000-0000-0000-0000-000000000000.
ACR supports five authentication methods: individual Microsoft Entra identity, service principal, managed identity, admin user, and non-Microsoft Entra token-based permissions.
ACR API rate limits (read/write throttling) apply independently to each geo-replica.
During an ACR home region outage, push/pull still works via other geo-replicas, but registry property modifications are blocked until the home region recovers.
Zone redundancy is automatically enabled for ACR geo-replicas in regions that support it.
Storage usage in a geo-replicated ACR is reported for the home region only; multiply by replica count for total consumption.
ACR geo-replication uses an active-active model where all replicas are writable — push and pull work from any replica.
ACR geo-replication uses an active-active model where all replicas are writable — push and pull work from any replica, not just the home region.
ACR geo-replication uses eventual consistency — there is a replication lag window after push before content appears in all replicas.
ACR geo-replication has three operational constraints: disabled replicas still sync data and incur costs, home region outages block registry property changes despite continued push/pull, and global endpoint routes by network performance not geographic proximity.
ACR geo-replication requires the Premium SKU.
ACR geo-replication requires the Premium SKU.
ACR geo-replication requires the Premium SKU.
Storage usage in a geo-replicated ACR is reported for the home region only; multiply by replica count for total consumption.
The ACR global endpoint (myregistry.azurecr.io) routes to the geo-replica with the best network performance, not necessarily geographic proximity.
During an ACR home region outage, push/pull still works via other geo-replicas, but registry property modifications are blocked until the home region recovers.
ACR included storage: Basic 10 GiB, Standard 100 GiB, Premium 500 GiB; additional storage billed per-GiB.
Individual login tokens from az acr login are valid for 3 hours and must be renewed.
ACR max image layer size is 200 GiB and max manifest size is 4 MiB across all SKUs.
ACR maximum image layer size is 200 GiB across all SKUs.
ACR maximum storage limits: Basic/Standard max 40 TiB, Premium max 100 TiB.
ACR should be placed in the same Azure region as container hosts to minimize latency and avoid cross-region egress fees.
ACR non-Entra token limits: Basic 100, Standard 500, Premium 50,000.
Optimal container image layer count for ACR is 5–10 layers, balancing layer reuse/caching against pull overhead.
The optimal number of layers per container image is 5–10, balancing layer reuse/caching against pull overhead.
ACR gates all enterprise capabilities behind Premium SKU: geo-replication, private link (up to 200 endpoints), content trust, customer-managed keys, and 2.5x higher storage limits (100 TiB vs 40 TiB for Basic/Standard).
ACR Premium-exclusive features include: geo-replication, private link, content trust, customer-managed keys, connected registries, artifact streaming, retention policies, dedicated agent pools, IP access rules, export policies, and artifact transfer.
ACR Premium-exclusive features: geo-replication, private link (up to 200 endpoints), content trust, customer-managed keys, connected registries, artifact streaming, retention policies, dedicated agent pools, IP access rules, export policies, artifact transfer.
ACR Premium-exclusive features include geo-replication, content trust (image tag signing), private endpoints, customer-managed keys, connected registries, artifact streaming, retention policies, dedicated agent pools, IP access rules, export policies, and artifact transfer.
ACR Premium-only features include geo-replication, content trust (image tag signing), and private endpoints with private link.
Best practice: place ACR in a dedicated resource group to avoid accidental deletion when cleaning up container host resources.
ACR service principal passwords have a default expiry of 1 year.
ACR service principal passwords have a default expiry of 1 year.
ACR SKU changes can be done freely with no downtime, but downgrading from Premium requires removing Premium-only resources first (e.g., geo-replications, connected registries).
ACR supports Docker container images (Windows and Linux), Helm charts, and OCI-format images.
ACR supports Docker container images, OCI-format images, and Helm charts as stored artifacts.
ACR Tasks can build container images on demand or automatically via triggers including source code commits and base image updates.
Azure Container Registry offers three SKU tiers: Basic (dev/test), Standard (most production), and Premium (high-volume/enterprise).
ACR offers three SKU tiers: Basic (dev/test), Standard (production), Premium (high-volume/enterprise).
ACR returns HTTP 429 errors during high request volume; mitigate with retry logic, exponential backoff, and reducing concurrency.
ACR token-based repository permissions are not integrated with Microsoft Entra ID and do not support RBAC role assignments.
ACR token-based repository permissions are not integrated with Microsoft Entra ID and do not support RBAC role assignments.
Untagged (dangling/orphaned) container images in ACR can be managed via a retention policy for untagged manifests.
Untagged (dangling/orphaned) container images in ACR can be managed via a retention policy for untagged manifests.
ACR webhook limits: Basic 2, Standard 10, Premium 500.
The API Server Guard (aks-managed-apiserver-guard) is a FlowSchema and PriorityLevelConfiguration that throttles non-system client requests under high load while allowing system-critical calls (e.g., kubelet) to continue.
The aks-managed-apiserver-guard FlowSchema is a last-resort throttling mechanism that throttles non-system client requests to protect the API server under high load; system-critical calls like kubelet continue normally.
The AKS API server is public by default; access can be restricted via authorized IP ranges or by creating a private cluster.
The AKS API server guard (aks-managed-apiserver-guard) is a FlowSchema and PriorityLevelConfiguration that throttles non-system client requests under high load while allowing system-critical calls (e.g., kubelet) to continue.
The aks-managed-apiserver-guard FlowSchema is a last-resort throttling mechanism that throttles non-system client requests to protect the API server under high load; system-critical calls (e.g., kubelet) continue normally.
AKS supports AppArmor and seccomp profiles to restrict container actions following the principle of least privilege.
AKS supports AppArmor and seccomp profiles to restrict container actions following the least-privilege principle.
Azure Disk volumes in AKS are mounted as ReadWriteOnce (single node); Azure Files supports ReadWriteMany (multi-node)
Azure Disks CSI provides single-pod access; Azure Files CSI provides multiple concurrent pod access.
Azure Files CSI driver supports SMB 3.1.1 and NFS 4.1 protocols, enabling multi-node and multi-pod concurrent access.
AKS supports bring-your-own CNI for third-party networking plugins in addition to Azure-provided CNI options.
AKS is a CNCF-certified conformant Kubernetes distribution.
AKS is CNCF-certified, meaning it passes Kubernetes conformance testing.
AKS is CNCF-certified, meaning it passes official Kubernetes conformance testing.
AKS is compliant with SOC, ISO, PCI DSS, and HIPAA standards.
AKS supports confidential computing nodes that run containers in hardware-based trusted execution environments (TEE).
AKS Confidential Containers (preview) use Kata-based isolation with AMD SEV-SNP hardware memory encryption to prevent clear-text memory access.
containerd is the sole supported container runtime in AKS for Linux (Kubernetes 1.19+) and Windows (Kubernetes 1.23+).
The AKS control plane is provided at no cost; users only pay for worker nodes.
The AKS control plane (kube-apiserver, etcd, kube-scheduler, kube-controller-manager, cloud-controller-manager) is fully managed by Azure; users manage only worker nodes.
AKS control plane scaling is multi-dimensional — scaling one dimension (e.g., pod count) reduces capacity in others (e.g., pod churn rate).
AKS auto-scales control plane components based on total cluster cores and CPU/memory pressure; scaling one dimension (e.g., pod count) limits capacity in other dimensions (e.g., pod churn rate).
CSI drivers are default in AKS from Kubernetes 1.21; in-tree driver support removed from Kubernetes 1.26
Custom VNet NSG rules for AKS must allow TCP 443 and 4443 from cluster subnet to API server subnet, and TCP 9988 from Azure Load Balancer to API server subnet.
Custom VNet NSGs for AKS must allow TCP 443/4443 from cluster subnet to API server subnet, and TCP 9988 from Azure Load Balancer to API server subnet.
Custom VNet NSG rules for AKS must allow TCP 443 and 4443 from cluster subnet to API server subnet, and TCP 9988 from Azure Load Balancer to API server subnet.
AKS custom VNet deployments inherit the Standard Load Balancer's zero-trust default-deny posture, requiring explicit NSG allowlisting of control plane ports (TCP 443, 4443 from cluster subnet to API server, TCP 9988 from Azure LB) — making AKS custom networking a manual allowlisting exercise where missing a single rule silently breaks cluster communication.
AKS defaults to ephemeral OS disks when the VM SKU supports them
AKS clusters include four default namespaces: default, kube-node-lease, kube-public, and kube-system.
The default operating system for AKS nodes is Ubuntu Linux; Azure Linux and Windows Server 2022 are also available as options.
Default outbound internet access for AKS-managed VNet clusters retires March 31, 2026 (defaultOutboundAccess=false); BYO VNet clusters are unaffected.
AKS default storage class is managed-csi backed by Standard SSD LRS
AKS reconciles built-in default storage classes — manual changes to them are overwritten by the platform.
Applications should not be deployed to the kube-system namespace in AKS; it is reserved for critical system pods.
AKS auto-manages NIC-level NSGs; users must not modify them. Custom traffic rules should use subnet-level NSGs instead.
AKS clusters have unrestricted outbound internet access by default, but it can be restricted via outbound type configuration.
Ephemeral OS disk default sizing in AKS requires the VM SKU to have at least 128 GiB of temporary storage.
Secrets stored in etcd can be encrypted at rest using customer-managed keys via AKS KMS etcd encryption.
In the AKS flat network model, egress traffic is not SNAT'd — the pod IP is directly exposed to the destination, which is useful when external services need to identify pod IPs.
Flatcar Container Linux (preview) is a vendor-neutral, CNCF-based immutable container OS with SELinux, usable cross-cloud on AKS.
Flatcar Container Linux (preview) is a vendor-neutral, CNCF-based immutable OS using SELinux, cross-cloud compatible, with cryptographic integrity protection.
The Horizontal Pod Autoscaler requires Metrics Server to be deployed in the cluster (available since Kubernetes 1.8+).
Azure Linux OS Guard (preview) is an immutable, read-only OS that enforces FIPS + Trusted Launch and uses SELinux for mandatory access control.
AKS offers two container-optimized immutable OS options: Azure Linux OS Guard (preview, Microsoft-built, FIPS/Trusted Launch/SELinux enforced) and Flatcar Container Linux (preview, vendor-neutral, CNCF-based). Both are read-only at runtime with cryptographic integrity protection.
AKS offers an Istio-based service mesh add-on as a managed option.
kube-proxy runs on every AKS node to provide network features.
AKS node storage uses Azure Managed Disks with automatic encryption at rest.
AKS manages Helm releases prefixed with aks-managed and labels managed components with kubernetes.azure.com/managedby: aks.
AKS-managed Helm releases use the aks-managed prefix; increasing revision counts on these are expected and safe.
AKS managed OS disk defaults scale by vCPU count: 1-7→P10/128G, 8-15→P15/256G, 16-63→P20/512G, 64+→P30/1024G
AKS multi-AZ clusters default to ZRS storage from Kubernetes 1.29
Node Autoprovisioning (NAP) is a preview feature based on Karpenter that dynamically selects optimal VM SKU and quantity for pending pod requirements.
Kubernetes network policies control pod-to-pod traffic based on labels, namespace, or port; NSGs control node-level traffic.
Node authorization is enabled by default on AKS 1.24+, authorizing kubelet API requests to protect against East-West attacks.
AKS node pools are backed by Azure VM scale sets (VMSS), and during scale-down the VMSS API determines which nodes are removed.
AKS reserves CPU and memory on each node for system functions, so allocatable resources are less than total node resources.
AKS nodes have no public IP addresses by default and are deployed to private subnets.
AKS supports Notary V2 for attaching and verifying container image signatures in the registry as part of the secure supply chain.
AKS supports Notary V2 to attach signatures to container images for trusted deployment verification.
Azure auto-configures NSG rules when LoadBalancer Services are created in AKS; no manual NSG configuration needed for standard scenarios.
Ephemeral NVMe data disks in AKS provide high-performance temporary storage; data is lost on deallocation and they are managed via Azure Container Storage.
NVMe data disks in AKS are ephemeral (data lost on deallocation) and are managed via Azure Container Storage.
AKS OS disk size cannot be changed after cluster or node pool creation
Azure Linux OS Guard (preview) is a Microsoft-created immutable container OS that enforces FIPS + Trusted Launch and uses SELinux for mandatory access control.
AKS offers two network models: Overlay (pods get IPs from a private CIDR separate from VNet subnet) and Flat (pods get IPs from the same VNet subnet as nodes, no SNAT on egress).
Persistent volumes cannot be shared between Windows and Linux pods in AKS
Persistent Volume (PV) to Persistent Volume Claim (PVC) binding is a 1:1 mapping in Kubernetes.
Persistent Volume (PV) to Persistent Volume Claim (PVC) binding in Kubernetes is a 1:1 mapping — each PV binds to exactly one PVC.
AKS reconciles built-in default storage classes — manual changes to built-in classes are overwritten by the platform.
Azure secure supply chain uses Notary V2 to attach signatures to container images for trusted deployment verification.
Raw Kubernetes secret manifests store data in base64 encoding, which is not encryption — etcd-level encryption with customer-managed keys is needed for true encryption at rest.
Kubernetes Secret manifest files contain data in base64 format (encoding, not encryption) and should never be committed to source control.
Watches on Kubernetes secrets are disproportionately expensive for the AKS control plane compared to watches on other resource types.
Raw Kubernetes secret manifests contain data in base64 format, which is encoding, not encryption.
Raw Kubernetes secret manifests contain data in base64 encoding, which is not encryption — secrets require etcd encryption at rest with customer-managed keys for actual cryptographic protection.
AKS nodes have SSH enabled by default via internal IP only (no public IPs); disabling SSH entirely is available in preview.
SSH on AKS nodes is enabled by default but accessible only via internal IP (no public IPs); SSH can be disabled in preview.
AKS storage options: Azure Disks CSI (single pod), Azure Files CSI (multi-pod concurrent), Azure NetApp Files (high-throughput/low-latency), Azure Container Storage (fully managed block storage).
AKS supports container supply chain verification through image signing with Notary V2 and Trusted Launch for node integrity, providing verification at both the container image and infrastructure layers.
AKS supported node operating systems are Ubuntu (default Linux), Azure Linux, and Windows Server 2022.
AKS supports Ubuntu (default for Linux), Azure Linux, and Windows Server 2022 as node operating systems.
AKS distinguishes system node pools (hosting critical system pods like CoreDNS, konnectivity) from user node pools (hosting application workloads).
AKS supports three autoscaling mechanisms: cluster autoscaler (node-level), horizontal pod autoscaler (pod-level), and KEDA (event-driven).
AKS has three pricing tiers: Free, Standard, and Premium.
AKS Trusted Launch requires Azure Gen2 VMs and combines secure boot with vTPM to verify boot chain integrity.
AKS has two cluster modes: Automatic (fully managed, preconfigured) and Standard (more control over node pools, scaling, settings).
AKS automatically creates two resource groups: one user-specified and one auto-created containing all infrastructure resources (VMs, VMSS, storage).
Virtual nodes enable bursting from AKS to Azure Container Instances (ACI) for rapid serverless pod scaling.
Virtual nodes (ACI burst) deploy into a separate subnet within the same VNet as the AKS cluster; no application modifications are required.
As of May 2025, AKS dynamically selects the default VM SKU based on available capacity and quota if not specified by the user.
As of May 2025, AKS dynamically selects the default VM SKU based on available capacity and quota if no VM size is specified.
For VMSS-backed AKS clusters, the VMSS API determines which nodes are removed during scale-down operations.
Setting volumeBindingMode: WaitForFirstConsumer on an AKS StorageClass enables topology-aware provisioning, delaying volume binding until a pod is scheduled.
AKS supports Windows Server containers via multi-OS (Linux + Windows) node pools within a single cluster.
AKS supports Windows Server containers via mixed OS (Linux + Windows) node pools within a single cluster.
AKS supports Windows Server containers via multi-OS node pools within a single cluster.
Windows containers in AKS use drive letters for volume mount paths (e.g., mountPath: "d:") instead of Unix-style paths.
Application Gateway backend pool members in other VNets require VNet peering or VPN gateway for connectivity.
Application Gateway backend pool members are not tied to an availability set.
Application Gateway backend pool members are not tied to an availability set — they can be distributed freely.
Application Gateway backend pool members are not tied to availability sets and can span cross-cluster, cross-datacenter, or outside Azure (requires IP connectivity).
Application Gateway backend pool members in other VNets require VNet peering or VPN gateway for connectivity.
Application Gateway backend pool members in other VNets require VNet peering or VPN gateway for connectivity; on-premises backends need ExpressRoute or VPN tunnels.
Custom health probes are recommended for each Application Gateway backend pool to monitor health with configurable hostname, path, interval, failure threshold, and response body matching.
Application Gateway DNS name is stable for the gateway's lifetime — use a CNAME alias pointing to it.
Application Gateway end-to-end TLS encryption is controlled by the HTTP settings component (port and protocol configuration to backend).
Application Gateway HTTP/2 is disabled by default and works only between client and gateway (backend always HTTP/1.1)
Application Gateway is a Layer 7 load balancer; Azure Load Balancer is Layer 4
Application Gateway multi-site listeners support 100+ websites per gateway and wildcard hostnames (up to 5 hostnames per listener)
Each Application Gateway listener maps to one routing rule
Application Gateway supports only one public and one private frontend IP address per gateway instance.
Application Gateway path-based routing matches URL path only, not query parameters
Application Gateway supports Private Link for private connectivity to backends and private-only deployment to eliminate data exfiltration risk, enabling zero-trust architectures.
Application Gateway makes routing decisions based on HTTP attributes (URL path, host headers), not just IP/port
Application Gateway provides SSL/TLS termination, offloading encryption processing from backend servers.
Application Gateway (V2) supports autoscaling based on traffic demand and zone redundancy across availability zones.
Application Gateway supports autoscaling based on traffic demand and zone redundancy across availability zones for high availability.
A CNAME alias should be used for Application Gateway's DNS name because it does not change over the gateway's lifecycle.
Application Gateway V1 dynamic public IP only changes on gateway stop/start, not during failures or updates.
Application Gateway V1 dynamic public IP only changes on gateway stop/start, not during failures or updates.
Application Gateway V1 SKU blocks port 3389; V2 blocks ports 22 (Private Link) and 53.
Application Gateway V2 blocks ports 22 (Private Link) and 53; V1 blocks port 3389
Application Gateway V2 supports ports 1–64999 (ports 22 and 53 blocked); V1 supports ports 1–65502 (port 3389 blocked).
Application Gateway V2 supports static public IP; V1 supports only dynamic public IP (changes only on stop/start)
VMSS backends in Application Gateway show unhealthy until instances are upgraded after being added to the pool
Application Gateway WebSocket support is enabled by default and cannot be disabled
App Service supports up to 512 access restriction rules per app, evaluated in priority order.
Deployment artifacts in Azure App Service are placed at /home/site/wwwroot, a mounted storage location shared by all instances.
App Service Environment (ASE) is single-tenant, runs inside the customer's VNet, supports ILB for private IP addresses, forces TLS 1.2, and networking rules apply to all apps in the ASE subnet.
App Service Environment (ASE) is single-tenant, runs inside the customer's VNet, forces TLS 1.2, and networking rules apply to all apps in the ASE subnet.
App Service Environment (ASE) is single-tenant, runs inside the customer's VNet, supports private IP addresses via ILB, and forces TLS 1.2.
App Service billing: Free = no cost; Shared = per-app CPU quota; Dedicated tiers = per VM instance; IsolatedV2 = per worker.
Azure App Service billing: Free = no cost; Shared = per-app CPU quota; Dedicated (Basic–PremiumV4) = per VM instance; IsolatedV2 = per worker
Container images deployed to App Service should be tagged with git commit ID or timestamp — avoid using the default latest tag.
Azure App Service default minimum TLS version is 1.2; must be configured separately for both the web app and SCM site
Azure App Service default minimum TLS version is 1.2; must be configured separately for both the web app and SCM site.
App Service default minimum TLS version is 1.2; must be configured separately for both the web app and the SCM site.
App Service deployment artifacts are placed at /home/site/wwwroot, a mounted storage location shared by all instances.
App Service deployment artifacts are placed in /home/site/wwwroot, a mounted storage location shared by all instances.
App Service deployment slots count as active apps competing for resources in the plan.
Azure App Service deployment slots count as active apps competing for resources within the plan
Azure App Service deployment slots enable staging environments for zero-downtime deployments
App Service deployment slots are available at Standard tier and above; swap operations provide zero-downtime deployment and instant rollback.
App Service deployment slots require Standard tier or above.
Azure App Service provides free managed TLS certificates for custom domains
Azure App Service Free and Shared tiers cannot scale out and run on shared VMs with other customers
App Service Free and Shared tiers cannot scale out and run on shared VMs with other customers.
App Service Free and Shared tiers cannot scale out and run on shared VMs with other customers.
FTP and WebDeploy deployments do not go through Kudu in App Service.
Gateway-required VNet integration is the only option for cross-region connectivity without peering or classic VNet access, but is Windows-only and does not support ExpressRoute.
Gateway-required VNet integration is legacy, Windows plans only, does not work with ExpressRoute, but can connect cross-region without peering.
App Service Hybrid Connections are outbound only, require port 443, use Azure Relay, and do not require a VNet.
Hybrid Connections are outbound only, require port 443, use Azure Relay, and do not require a VNet; Hybrid Connection Manager requires Windows Server 2012+.
App Service Hybrid Connections are outbound only, use Azure Relay on port 443, and do not require a VNet.
App Service inbound features (access restrictions, private endpoints) and outbound features (VNet integration, Hybrid Connections) are distinct — inbound features cannot solve outbound problems and vice versa.
Azure App Service IsolatedV2 is the only tier providing both network and compute isolation, running on dedicated VNets via App Service Environment
For Java App Service deployments, use zipdeploy for JAR files and wardeploy for WAR/EAR files.
Azure App Service Key Vault references use syntax @Microsoft.KeyVault(SecretUri=https://<vault>.vault.azure.net/secrets/<secret>) in app settings
App Service integrates with Key Vault for a zero-secret-in-code configuration pipeline: Key Vault references inject secrets into app settings via @Microsoft.KeyVault(SecretUri=...) syntax, certificates stored as Key Vault certificate objects enable autorotation, and user-assigned managed identity provides credential-free vault authentication — eliminating secrets from both application code and deployment configuration.
Kudu runs as a separate process on Windows App Service and as a second container on Linux App Service.
Kudu runs as a separate process on Windows and as a second container on Linux.
App Service local cache is not recommended for content management sites (e.g., WordPress) and should always be combined with deployment slots to prevent downtime.
Azure App Service Managed Instance persistent changes must be scripted via install scripts; RDP changes are not persisted across restarts
Azure App Service Managed Instance (preview) supports Windows only — no Linux, containers, or ASE support; requires Pv4/Pmv4 SKUs
App Service Managed Instance (preview) supports Windows only — it does not support Linux, containers, or ASE.
App Service Managed Instance (preview) supports Windows only, does not support Linux/containers/ASE, and RDP changes are not persisted — persistent changes must be scripted via install scripts.
App Service supports a maximum of 512 access restriction rules per app, evaluated in priority order.
App Service supports mutual TLS (client certificate authentication) for B2B or internal app scenarios.
App Service inbound and outbound networking features are distinct — inbound features cannot solve outbound problems and vice versa.
New Azure App Service apps default to FTPS-only; basic auth should be disabled in favor of Entra ID OAuth 2.0.
New Azure App Service apps default to FTPS-only; basic auth should be disabled in favor of Entra ID OAuth 2.0
New App Service apps default to FTPS-only; basic auth should be disabled in favor of Entra ID OAuth 2.0 tokens.
App Service outbound IP addresses change when switching between VM families (e.g., Standard → PremiumV2 → PremiumV3 → PremiumV4).
All apps in an App Service plan share the same VM instances; scaling the plan scales all apps together.
All apps in an Azure App Service plan share the same VM instances; scaling the plan scales all apps together
App Service billing: Free = no cost; Shared = per-app CPU quota; Dedicated tiers = per VM instance; IsolatedV2 = per worker.
App Service P*mv3 tiers are memory-optimized for high-density hosting (more apps per VM).
Port 445 (SMB) is blocked by default in the App Service sandbox.
Port 445 (SMB) is blocked by default in the App Service sandbox.
The possibleOutboundAddresses app property lists all potential outbound IPs an app might use in a scale unit.
PremiumV4 SKU does not expose outbound IP addresses.
Azure App Service private endpoints are inbound only and prevent data exfiltration via Private Link.
Recommended max apps per App Service plan: B1/S1/P1v2 = 8, B3/S3/P3v2 = 32, P3v3/P3v4/I3v2 = 64.
If App Service CPU/memory exceeds 90%, scale up instance count temporarily before deploying.
Setting SCMDOBUILDDURINGDEPLOYMENT=false disables Kudu builds when using an external build service (applies to Node.js and .NET).
Setting SCMDOBUILDDURINGDEPLOYMENT=false disables Kudu builds when using an external build service (Node or .NET).
App Service stores secrets encrypted at rest and decrypts them only at process startup into memory; encryption keys are rotated regularly.
Azure App Service app settings are stored encrypted at rest and decrypted only at process startup into memory; encryption keys are rotated regularly
Deployment slots count as active apps and compete for resources within the App Service plan.
Deployment slots in Azure App Service require Standard tier or above.
SNI-based TLS connections on App Service are free; IP-based TLS connections are charged (one free IP-based binding with Standard+ tiers).
Azure App Service supports .NET, Java, Node.js, Python, and PHP runtimes on both Windows and Linux, plus custom container deployments
App Service swap operations warm up worker instances to match production scale before switching traffic, enabling zero-downtime deployment and instant rollback by swapping again.
App Service slot swap operations warm up worker instances to match production scale before switching traffic, providing zero-downtime deployment and instant rollback (swap again to roll back).
Azure App Service has three distinct auth layers: RBAC (management plane), Easy Auth (application plane), and Managed Identities (app-to-resource)
App Service has three distinct auth layers: RBAC (management plane), Easy Auth (application plane), and Managed Identities (app-to-resource).
App Service has three distinct authentication layers: RBAC (management plane), Easy Auth (application plane), and Managed Identities (app-to-resource).
App Service enforces a hard scaling boundary between shared and dedicated tiers: Free/Shared cannot scale out and run on shared multi-tenant VMs, while Dedicated tiers share VM instances across all co-located apps — meaning one app's scale affects all apps in the plan.
App Service VNet integration is outbound only and requires the VNet to be in the same region as the app.
App Service VNet integration is outbound only and requires the VNet to be in the same region as the app.
Azure enforces protection through two orthogonal planes that must be independently configured: the access plane (identity-rooted default-deny across network and governance layers) prevents unauthorized data access, while the data plane (dual-layer FIPS-tiered encryption at rest plus universal TLS 1.2 in transit) ensures data remains protected even if access controls are compromised — neither plane compensates for gaps in the other.
The Activity log captures subscription-level events (e.g., VM created, VM started) and is collected automatically in a separate store.
The Activity Log tracks subscription-level events (VM start/stop, resource creation) in a separate store; it can be routed to Log Analytics for deeper analysis.
Azure Advisor provides built-in reliability recommendations as part of the WAF Reliability pillar.
Availability Sets require 2 or more VMs to meet the 99.95% Azure SLA.
Availability Sets provide a 99.95% SLA and require 2 or more VMs for high availability.
Availability Zones protect against datacenter loss; Azure Site Recovery protects against regional outages.
Availability Zones SLA is 99.99% with 2+ VM instances across 2+ zones.
Availability Zones protect against datacenter-level failure; Azure Site Recovery protects against region-level outages.
Basic load balancer front-end IPs are not reachable across global VNet peering; Standard load balancers are required.
Blob storage reservations cover capacity only — not bandwidth or transaction costs.
Azure Blob Storage reservations cover storage capacity only — not bandwidth or transaction costs.
Azure Managed Disks support only LRS and ZRS redundancy — no GRS option exists — meaning disk data is not automatically replicated across Azure regions.
All Azure Cache for Redis SKUs are being retired; migration to Azure Managed Redis is recommended.
All Azure Cache for Redis SKUs have been announced for retirement; Microsoft recommends migrating to Azure Managed Redis.
Cloud-init is supported on most Azure Linux distros for automated VM provisioning.
Cloud-init is supported on most Azure Linux distributions for automated deployment and configuration on VMs and VMSS.
Cloud-init is supported on most Azure Linux distributions for automated VM provisioning.
Azure Compute Gallery (formerly Shared Image Gallery) is needed for custom images at the 1,000-VM VMSS scale limit.
Azure Compute Gallery (formerly Shared Image Gallery) enables custom images with the higher 1,000-VM scale set limit.
Azure container solutions include AKS (managed K8s), Azure Red Hat OpenShift (managed OpenShift), Azure Arc-enabled Kubernetes (unmanaged K8s for hybrid/multi-cloud), Azure Container Instances (serverless containers), and Azure Container Apps (serverless app model on K8s).
Azure Container Storage is a Kubernetes-native volume orchestration and management service that uses existing Azure Storage offerings as backing storage.
Cosmos DB reservations cover provisioned throughput only — not storage or networking costs.
Cosmos DB reservations cover provisioned throughput only — storage and networking are not included.
Azure cost optimization operates under a dual constraint: the progressive tier pattern forces selection of a price floor to unlock required capabilities (each PaaS tier gates features behind increasing cost), while reservations discount only the primary billable unit per service (compute, capacity, or throughput) — creating a cost model where tier downgrades sacrifice features and reservation purchases leave ancillary costs at pay-as-you-go rates.
Cross-VNet DNS resolution requires using FQDNs; hostname-only queries are insufficient for resolving names across peered or linked VNets.
Azure data protection operates at two independently enforced encryption layers: at-rest encryption is tiered across three FIPS compliance levels (Key Vault's software/HSM/Managed HSM hierarchy), while in-transit TLS 1.2 is universally enforced as a non-optional platform standard across SQL, Monitor, Redis, and Storage.
Azure data-plane access follows a security gradient from weakest to strongest: SAS tokens provide delegated access with varying revocability (account key SAS is least secure, user delegation SAS most secure), while the Entra identity-to-authorization chain provides full RBAC-governed access — and the gradient position is determined by how deeply a workload integrates with the identity chain, with SAS appropriate for cross-boundary sharing and Entra RBAC for intra-platform access.
Azure data plane access increasingly supports Entra ID-based authentication alongside traditional key/SAS-based access, with identity-based access providing stronger auditability and more granular RBAC controls.
Azure Databricks reservations cover DBU costs only — not compute, storage, or networking; Databricks is the only service where reservations are not applied hourly.
A single DCR can be associated with multiple VMs, and a single VM can be associated with multiple DCRs.
Azure enforces default-deny at orthogonal infrastructure layers: Standard Load Balancer blocks all inbound traffic until NSG rules explicitly allow it (network layer), while Storage firewall blocks all requests until trusted networks or IPs are excepted (data layer) — architects must explicitly allowlist at every traffic boundary, not just the network perimeter.
Azure's cross-layer default-deny enforcement (Standard LB blocks inbound, Storage firewall blocks all requests, Policy denies non-compliant resources) is itself governed by the identity-to-authorization chain: RBAC role assignments determine who can create NSG exceptions and policy exemptions, and the additive RBAC model means identity misconfiguration can silently widen the aperture of both denial layers.
Azure default-deny enforcement spans both governance and network layers through independent mechanisms: the network layer closes traffic by default (Standard LB inbound + storage firewall), while governance uses Policy's explicit-deny system with cumulative most-restrictive evaluation — both cascade through separate hierarchies (subnet/NSG vs management group tree) and must be independently opened.
Microsoft Defender for Cloud auto-monitors three storage items: Defender for Storage enabled, secure transfer required, and network access restricted to specific networks.
The Dependency Agent (separate from Azure Monitor Agent) is required for the VM Insights Map feature.
Azure supports direct VHD upload up to 32 TiB to a managed disk without attaching it to a VM.
Disallowing Shared Key authorization on a storage account forces all requests to use Microsoft Entra ID.
Azure Disk Storage reservations apply only to Premium SSDs P30 or larger.
The Azure DNS virtual IP 168.63.129.16 is a foundational dependency that must be preserved in custom configurations — it serves as the recursive resolver for all VNets, bypasses NSG rules as a host node IP, and must be explicitly included when VPN Gateway uses custom DNS servers.
CNAME records cannot coexist with other record sets of the same name and cannot be created at the zone apex.
Cross-VNet DNS resolution requires using FQDNs — hostname alone is insufficient.
Must specify at least one DNS server IP when configuring custom DNS; otherwise Azure falls back to Azure-provided name resolution.
When custom DNS is configured, Azure provides reddog.microsoft.com as the placeholder DNS suffix instead of internal.cloudapp.net.
Default Azure DNS limits: 250 public DNS zones per subscription, 10,000 record sets per zone, 20 records per record set.
After DNS setting changes, the DHCP lease must be renewed on affected VMs for the new settings to take effect.
After changing VNet DNS settings, DHCP leases must be renewed on all affected VMs for the new settings to take effect.
After changing VNet DNS server settings, DHCP leases must be renewed on all affected VMs for the new settings to take effect.
To disable default reverse DNS, create an empty Private DNS in-addr.arpa zone and link it to the VNet.
Azure DNS uses Etags for optimistic concurrency control on zones and record sets; PowerShell enforces Etag checks by default.
Azure DNS encompasses five distinct services: Public DNS, Private DNS, DNS Private Resolver, Traffic Manager, and DNS Security Policy.
Azure DNS encompasses five distinct services: Public DNS, Private DNS, DNS Private Resolver, Traffic Manager, and DNS Security Policy.
Azure supports four DNS resolution methods: Azure Private DNS zones (preferred), Azure-provided name resolution, customer-managed DNS servers, and Azure DNS Private Resolver.
Azure-managed reverse DNS (PTR) records use the .internal.cloudapp.net suffix, and PTR records are automatically created when a VM starts and removed when the VM is stopped/deallocated.
Azure DNS uses the static IP address 168.63.129.16 for recursive resolution from within VNets.
Linux VMs require manual dnsmasq installation for DNS client-side caching; Windows has built-in DNS caching.
Azure DNS has three operational asymmetries that affect multi-VNet and hybrid architectures: reverse DNS (PTR) lookups are scoped per-VNet so queries for IPs in peered VNets return NXDOMAIN, DHCP leases must be manually renewed on all affected VMs after changing VNet DNS server settings, and cross-VNet name resolution requires FQDNs because hostname-only resolution is insufficient across VNet boundaries.
Azure DNS belongs to the Network Foundations service category alongside Azure Virtual Networks and Azure Private Link.
Network interface DNS settings take precedence over virtual network DNS settings.
Azure DNS does not support domain name purchasing — use App Service domains or third-party registrars.
Azure DNS does not provide domain registration; it only hosts and resolves domains.
Once custom DNS is configured, port 53 traffic bypasses subnet/NIC NSGs.
Port 53 traffic to custom DNS servers bypasses NSGs on subnet and NIC after custom DNS is configured on the VNet.
Azure DNS Private Resolver enables hybrid DNS resolution (on-premises to Azure and vice versa) without deploying VM-based DNS servers.
Azure Private DNS supports autoregistration, which automatically creates DNS records for VMs in private DNS zones.
Azure Private DNS resolves domain names within Azure virtual networks without needing custom DNS servers.
Azure Private DNS zones are the preferred solution for VNet DNS name resolution.
Azure-provided name resolution does not support cross-VNet resolution, manual record registration, or custom DNS suffixes.
Reverse DNS PTR records (using .internal.cloudapp.net) are automatically created when a VM starts and removed when the VM is stopped/deallocated.
Reverse DNS (PTR) lookups are scoped to a single VNet — queries for IPs in peered VNets return NXDOMAIN.
DNS Security Policy operates at the virtual network level and can block known malicious domains via Microsoft Security Response Center (MSRC) threat intelligence feed.
DNS server IPs should not be edited directly inside VMs — they get erased during service heal events.
SOA and CNAME record sets can only contain a single record per DNS standard constraints.
The SOA record host property cannot be modified, and the zone serial number is not auto-updated.
NS and SOA record sets at the zone apex are auto-created and auto-deleted with the zone and cannot be independently deleted.
The SOA record's host property cannot be modified, and the serial number is not automatically updated in Azure DNS.
SPF records must use TXT record type in Azure DNS — the SPF record type is deprecated per RFC 7208.
Tags apply to DNS zone resources only; metadata (name-value pairs) applies to record sets.
Azure-provided DNS throttles queries on a per-VM basis; client-side DNS caching (e.g., dnsmasq on Linux) is recommended to mitigate throttling.
TTL in Azure DNS is set per record set (not per individual record) with a range of 1 to 2,147,483,647 seconds.
DNS TTL is set per record set (not per individual record); range is 1 to 2,147,483,647 seconds.
Azure DNS TXT record sets support up to 4,096 characters total; individual strings are limited to 255 characters.
Wildcard DNS records (using * as the record set name) are supported for all record types except NS and SOA.
Azure DNS supports wildcard records for all record types except NS and SOA; wildcard record sets use \* as the name.
Azure DNS supports wildcard records for all record types except NS and SOA; use \* as the record set name.
Windows DNS forwarding timeout must exceed 4 seconds when forwarding to Azure DNS to avoid Private DNS zone records resolving to public IPs.
DNS zone names must be unique within a resource group, not globally unique.
Azure Elastic SAN is a fully integrated SAN solution using the iSCSI protocol, designed for large-scale IO-intensive workloads (SQL, MariaDB, VMs, AKS).
Azure Elastic SAN supports only LRS and ZRS redundancy options.
Azure encryption at rest operates at service-specific FIPS compliance levels: Key Vault provides tiered FIPS protection (software L1 → asymmetric HSM L2 → single-tenant Managed HSM L3), Storage uses automatic encryption with optional customer-managed keys, and NetApp Files meets FIPS 140-2 at rest — each service addresses a different certification requirement in the same encryption-at-rest framework.
Azure's identity-first data-plane convergence (managed identity as universal authentication, shared key deprecation, user delegation SAS) operates within the Entra dual-model lifecycle framework — system-assigned identities provide zero-config data-plane authentication while user-assigned identities enable cross-resource sharing, making the managed identity lifecycle tradeoff the key design decision for data-plane identity architecture across all Azure services.
ExpressRoute gateway cannot be used as a UDR next hop type in service chaining scenarios.
Of the three on-premises connectivity options (point-to-site VPN, site-to-site VPN, ExpressRoute), only ExpressRoute provides a fully private connection that does not traverse the internet.
Azure Files does not support RA-GRS or RA-GZRS redundancy options.
Azure Files supports SMB, NFS, and REST API protocols and can be mounted from Windows, Linux, and macOS.
Azure governance cascades through a single management group hierarchy with two complementary enforcement mechanisms: RBAC grants accumulate additively downward (broader scopes can only widen access), while Policy restrictions tighten subtractively downward (broader scopes can only narrow what resources may exist) — creating an asymmetric funnel where identity permissions expand and resource constraints contract as scope narrows.
Azure HA SLA is topology-determined across three escalating deployment patterns: Availability Sets provide 99.95% SLA requiring 2+ VMs within a single datacenter, Availability Zones provide 99.99% SLA by distributing across datacenter boundaries within a region, and regional outage protection requires Azure Site Recovery as a separate mechanism — each topology level increases availability but also increases cost and architectural complexity with distinct failure mode coverage.
Azure zone-redundant high availability requires satisfying both tier and zone requirements independently: SQL Database excludes Basic/Standard DTU tiers from zone redundancy, VMSS requires explicit Availability Zone configuration for datacenter protection, and AKS multi-AZ defaults to ZRS storage only from Kubernetes 1.29 — making HA a compound tier+topology decision per service.
Azure high availability design requires satisfying two independent decision axes simultaneously: tier selection determines which zone-redundancy options are available (Basic/Standard DTU excluded, Hyperscale zone-redundancy locked at creation time), while topology selection determines the SLA level (Availability Sets 99.95%, Availability Zones 99.99%, cross-region via ASR), creating a matrix where an incorrect tier choice can eliminate the desired topology option entirely.
Azure zone-redundant HA is an instance of the platform-wide progressive tier pattern: just as ACR gates enterprise features behind Premium and Redis gates clustering behind Premium, zone redundancy is gated behind higher tiers across SQL Database (excludes Basic/Standard DTU), Redis (excludes Basic), and Event Hubs (requires Premium/Dedicated) — tier selection determines not just feature access but also resilience ceiling.
Azure Hybrid Benefit reduces OS licensing costs for customers with existing Windows Server or SQL Server licenses.
Azure is converging toward managed identity as the universal data-plane authentication mechanism: user-assigned identities are the recommended type for cross-resource sharing, user delegation SAS provides the most secure form of delegated access by requiring Entra credentials, and disabling shared key authorization forces all storage requests through Entra ID — creating a consistent identity-first access model that eliminates shared secrets from the data plane.
Immutable storage (WORM) uses legal holds or time-based retention policies — data is readable but not modifiable or deletable during retention.
Azure's infrastructure IP 168.63.129.16 serves as a convergence point for DNS resolution and DHCP, functioning as a host node IP that bypasses NSG rules for these foundational platform services.
Internal standard load balancer provides no outbound connectivity unless explicitly configured with instance-level public IP or public load balancer.
Azure load-balancing decision tree: Traffic Manager (DNS/global) → Front Door (global HTTP with edge) → Application Gateway (regional L7) → Load Balancer (regional L4)
Azure Load Balancer is included with Standard tier VMs but not all VM tiers.
Azure Linux 2.0 security updates ended November 30, 2025; node images will be removed March 31, 2026. Must migrate to Azure Linux 3.
Linux VMs in Azure do not have built-in DNS client-side caching; dnsmasq must be installed manually (Windows has built-in DNS caching).
Azure Load Balancer is included with Standard tier VMs but not all tiers.
Azure Load Balancer is included with Standard tier VMs but not all VM tiers.
Azure Load Balancer provides layer-4 traffic distribution; Application Gateway provides layer-7 distribution with TLS termination.
Azure Monitor Log Analytics is built on top of Azure Data Explorer.
Azure Monitor Log Analytics default query result limit is 1,000 entries.
Empty tables are hidden by default in the Log Analytics Tables view; can be toggled per-session or permanently via settings.
Log Analytics results can be exported to Excel, CSV, or Power BI via the Share menu.
Log Analytics query results can be exported to Excel, CSV, or Power BI, and can be pinned to Azure dashboards, workbooks, or Grafana.
A time range set inside a KQL query overrides the Log Analytics time picker setting.
Log Analytics queries can be saved to query packs for sharing or saved as functions for reuse within other queries.
Log Analytics queries can be saved to query packs for sharing or saved as functions for reusable query logic.
Log Analytics queries can be saved to query packs for sharing or as functions for reusable query logic.
Log Analytics query scope depends on entry point: Azure Monitor/workspace returns all workspace data; specific resource returns scoped data.
Log Analytics queries can be saved to query packs for sharing or saved as functions for reuse within other queries.
Log Analytics search job mode enables running search jobs for large-scale historical queries.
Log Analytics Simple mode auto-refreshes results without a Run button; KQL mode requires explicit Run or Shift+Enter.
Azure Monitor Log Analytics uses Kusto Query Language (KQL), the same language as Azure Data Explorer.
Direct VHD upload to managed disks supports VHDs up to 32 TiB without needing to attach the disk to a VM.
Five managed disk encryption options: SSE (server-side encryption), ADE (Azure Disk Encryption), encryption at host, and confidential disk encryption with either platform-managed or customer-managed keys.
Managed disk snapshots are read-only, crash-consistent full copies of a single disk; they cannot coordinate across multiple disks. Images capture all disks (OS + data) from a generalized VM.
Snapshots are single-disk read-only point-in-time copies; images capture all disks of a generalized (Sysprep'd) VM and are used to create new VMs.
Managed disk snapshots exist independently of the source disk and persist even if the source is deleted.
Subscription limit for managed disks is up to 50,000 disks per type per region per subscription.
Direct VHD upload to Azure Managed Disks supports VHDs up to 32 TiB without requiring attachment to a VM.
Azure Managed Disks come in five types: Ultra Disks, Premium SSD v2, Premium SSD, Standard SSD, and Standard HDD.
A managed disk image captures all disks (OS + data) from a generalized or deallocated VM and can be used to create many VMs.
Limit of 50,000 managed disks per type per subscription per region.
LRS managed disks provide 11 9's of durability; ZRS managed disks provide 12 9's of durability.
Managed Disks are recommended for all new VMs; unmanaged disks can be converted to managed.
Managed disk snapshots are read-only, crash-consistent full copies of a single disk; they exist independently of the source and cannot coordinate across multiple disks.
Managed disks store 3 replicas of data and provide 99.999% availability SLA.
Managed identity credentials are never accessible to the developer.
The limit for managed identities as Federated Identity Credentials on an Entra ID application is 20.
Managed identities for Azure resources are free — no extra cost.
System-assigned managed identity's service principal name matches the Azure resource name; for deployment slots the format is <app-name>/slots/<slot-name>.
User-assigned managed identity is the recommended type for Microsoft services.
Managed identity usage workflow: (1) create identity, (2) assign to source compute resource, (3) authorize on target service via RBAC, (4) use Azure.Identity or MSAL SDK in code to acquire tokens — no secrets needed.
Azure Managed Lustre is a high-performance parallel file system designed for HPC and AI workloads, integrating with Blob Storage and AKS.
Both Azure messaging services converge on at-least-once as the baseline delivery semantic: Event Hubs (including its Kafka endpoint) and Service Bus Peek Lock mode both guarantee message delivery but not exactly-once processing — making idempotent consumer design a universal requirement for Azure messaging workloads regardless of service choice.
Azure migration planning faces compound constraints from two independent systems: tier gates determine the target capability envelope (SQL MI for lift-and-shift, Hyperscale for scale, Premium for network isolation), while reservation and pricing models impose a second constraint layer on ongoing cost (partial compute-only coverage, same total cost regardless of payment schedule) — both must be evaluated together since the tier choice locks in both the capability ceiling and the cost floor.
Azure migration planning is tier-gated at the platform level: SQL Database and Managed Instance targets are constrained by HA/scale tier tradeoffs (General Purpose cold-cache penalty vs Hyperscale distributed architecture), while PaaS services (ACR, Redis, Event Hubs) consistently gate enterprise capabilities behind premium SKUs — architects must map every source workload requirement to the minimum Azure tier across all services in the target architecture.
Action groups define alert responses including email, SMS, push notifications, Azure Functions, Logic Apps, webhooks, automation runbooks, ITSM incidents, and Event Hubs.
Action groups define alert responses including email, SMS, push notifications, Azure Functions, Logic Apps, webhooks, Event Hubs, ITSM incidents, and automation runbooks.
All Azure Monitor activity log alerts are stateless (fire every time the condition is met).
Azure Monitor Agent private keys are rotated every 90 days; agent-to-service communication uses certificate-based authentication on port 443 with TLS 1.2.
Azure Monitor agent communication uses TLS 1.2 (HTTPS) on port 443 with certificate-based authentication; private keys are rotated every 90 days.
Azure Monitor AIOps capabilities include dynamic alert thresholds and smart alerts using machine learning.
Azure Monitor alert conditions are system-managed with two states: fired or resolved.
Azure Monitor alerts operate on a dual-track lifecycle: three alert types (metric, log, activity) trigger system-managed conditions with two states (fired/resolved) that are orthogonal to user-managed response states (New/Acknowledged/Closed) — with alert processing rules providing cross-cutting modification of triggered alerts without editing individual alert rules.
Alert processing rules modify triggered alerts by adding or suppressing action groups, applying filters, or scheduling rule processing windows.
Alert processing rules modify triggered alerts by adding or suppressing action groups, applying filters, or scheduling rule processing windows.
Alert processing rules modify triggered alerts by adding or suppressing action groups, applying filters, or scheduling.
Creating alert rules requires read permission on target resource, write on resource group, and read on action group.
Azure Monitor alert user response has three states: New, Acknowledged, or Closed; these do not change automatically.
Azure Monitor alerts are stored for 30 days then automatically deleted.
Application Insights tracks AI agent performance across Microsoft Foundry, Copilot Studio, and third-party frameworks including token consumption, latency, error rates, and quality scores.
Application Insights is an OpenTelemetry-based APM feature within Azure Monitor.
Autoscale is a built-in feature of Azure Monitor that automatically adjusts resources based on application load, not a separate Azure service.
Autoscale is a feature of Azure Monitor, not a standalone service.
The Auxiliary table plan only supports DCR-based custom tables, not standard Azure resource tables.
The Basic table plan limits KQL queries to a single table, but this can be extended using the lookup operator.
The Basic table plan supports only Simple Log Alerts, not full log search alert rules.
Monitoring Contributor role can create and manage alerts; Monitoring Reader role can only view alerts.
Azure Monitor custom metrics are limited to 10 dimensions.
Data collection rules customize and filter what telemetry data is collected from different sources in Azure Monitor.
The Azure Monitor data platform is shared with Microsoft Defender for Cloud and Microsoft Sentinel.
Data collection rules (DCRs) are the mechanism for customizing and filtering telemetry collected by Azure Monitor.
Data collection rules (DCRs) are the mechanism for customizing and filtering telemetry collected by Azure Monitor from different sources.
Data collection rules (DCRs) are the mechanism for customizing, filtering, and routing telemetry data during collection in Azure Monitor.
Azure Monitor uses a dual data ingestion model: platform/custom metrics are preaggregated in a time-series database at no cost with no configuration, while logs pass through transformation pipelines that can filter and route data to optimize cost and analytics.
Fired Azure Monitor alert instances are read-only and cannot be edited.
Azure Monitor collects four signal types: metrics, logs, traces, and events.
Guest OS metrics sent via Log Analytics agent are retained for 31 days, extendable to 2 years.
Guest OS metrics collected via the Log Analytics agent are retained for 31 days, extendable to 2 years.
Guest OS metrics collected via Log Analytics agent are retained for 31 days, extendable to 2 years.
Guest OS metrics require an agent; Azure Monitor Agent (AMA) is the current recommended agent, replacing legacy Windows diagnostic extension and InfluxData Telegraf agent.
Azure Monitor supports hybrid and multicloud monitoring via Azure Arc and the Azure Monitor pipeline.
KQL (Kusto Query Language) is a read-only query language — it can query and analyze data but cannot modify it.
Log search alerts are charged based on the number of time series created from dimension splits.
Guest OS metrics sent via Log Analytics agent are retained 31 days, extendable to 2 years.
Log Analytics workspaces use KQL for querying; Azure Monitor workspaces use PromQL for querying Prometheus/OpenTelemetry metrics.
Log search alert resolution varies by frequency: 10 minutes for 1-min frequency, 3 periods for 5–15 min, 2 periods for 15 min–11 hr, and 1 period for 11–12 hr frequency.
Log search alert rules are charged based on the number of time series created by dimension splits.
All Azure Monitor Logs table plans support up to 12 years total retention.
Analytics table plan has 30-day default analytics retention (90 days for Sentinel and Application Insights), extendable to 2 years.
Auxiliary table plan has no workspace replication, no Customer Lockbox support, no alerts, no insights, and no data export.
Basic and Auxiliary table plans are not available in legacy pricing tiers.
The Basic table plan in Azure Monitor Logs supports only Simple Log Alerts, not full alert rules.
The Basic table plan supports Simple Log Alerts and full KQL on a single table (extendable via lookup).
Data collection transformations can filter, transform, and route data during ingestion to optimize cost and analytics before it reaches workspace tables.
KQL (Kusto Query Language) used in Azure Monitor Logs is a read-only query language — it can process and analyze data but cannot modify it.
KQL (Kusto Query Language) is a read-only query language used by Azure Monitor Logs — it can analyze millions of records but cannot modify data.
Microsoft Sentinel and Microsoft Defender for Cloud both store their security data in Azure Monitor Log Analytics workspaces.
Summary rules aggregate data from one or more tables as it arrives, producing summarized tables for dashboards and faster queries.
Azure Monitor Logs has three table plans: Analytics (full-featured, standard cost), Basic (reduced cost, single-table KQL), and Auxiliary (minimal cost, slow queries, no alerts/insights/export).
A single metric alert rule can monitor multiple resources of the same type in the same Azure region.
Metric dimension names and values are case-insensitive in Azure Monitor.
The Azure Monitor Metrics Batch REST API supports up to 50 resource IDs per call (same subscription and region).
Metrics Explorer chart query limit is 30 days per single chart; PromQL query max span is 32 days.
Azure Monitor Metrics supports three types: native platform metrics (free, auto-collected), native custom metrics (from apps/agents/API), and Prometheus metrics (from Kubernetes clusters).
Azure Monitor agent-to-service communication uses TLS 1.2 (HTTPS) with certificate-based authentication on port 443; private keys rotated every 90 days.
Azure Monitor Metrics uses TLS 1.2 (HTTPS) on port 443 for all communication; private keys are rotated every 90 days.
Built-in monitoring roles: Monitoring Contributor can create and manage alerts; Monitoring Reader has view-only access.
Monitoring Contributor role can create and manage alerts; Monitoring Reader role can only view alerts.
Moving or renaming an Azure resource may result in loss of metric history.
Native platform and custom metrics are preaggregated; Prometheus metrics store raw data.
Azure Monitor's compound risk surface is coupled to the identity system: Sentinel and Defender (sharing Log Analytics workspaces) consume identity events generated by Entra, while workspace access itself is governed by the same RBAC model that the Entra identity-to-authorization chain provides — monitoring integrity depends on identity integrity.
Azure Monitor workspace configuration is a compound risk surface: workspace decisions (retention, table plans, DCR filtering) simultaneously affect three security/observability consumers (Monitor, Sentinel, Defender) AND govern the dual-track alert lifecycle (system-managed conditions + user response states), making workspace misconfiguration a single point of failure for both security posture and operational alerting.
Azure Monitor pipeline extends data collection into on-premises data centers and other cloud providers, supporting large volumes or intermittent connectivity.
Azure Monitor pipeline extends data collection to on-premises data centers and other cloud providers for large volumes or intermittent connectivity.
Platform and custom metrics are preaggregated in the time-series database; Prometheus metrics store raw data.
Platform metrics can be sent to a Log Analytics workspace via diagnostic settings for long-term retention beyond the 93-day default.
Azure Monitor platform metrics are automatically collected from Azure resources at 1-minute frequency, require no configuration, and have no cost.
Azure Monitor platform metrics are retained for 93 days.
Prometheus alerts use PromQL-based rules against Azure Monitor managed Prometheus metrics (a separate alert type from metric alerts).
Azure Monitor Prometheus metrics are retained for 18 months.
Prometheus metrics are stored in an Azure Monitor workspace (not subscription-level like native metrics).
Recommended (out-of-the-box) alert rules are available for VMs, AKS, and Log Analytics workspaces.
Azure Monitor operational effectiveness requires alignment between the three-tier retention model (93 days platform metrics, 18 months Prometheus, up to 12 years logs) and the dual-track alert lifecycle (system-managed fired/resolved conditions with 30-day alert retention plus user response states) — because alert investigation depends on the underlying metric or log data still being within its retention window, and alert processing rules must account for data availability at each retention tier.
Azure Monitor retention spans three distinct tiers with increasing configurability: platform metrics (93 days fixed), Prometheus metrics (18 months), and logs (up to 12 years across all table plans).
Microsoft Sentinel and Microsoft Defender for Cloud both store their data in Log Analytics workspaces.
Microsoft Sentinel and Microsoft Defender for Cloud both store their data in Log Analytics workspaces.
Azure Monitor's data platform serves as shared infrastructure for three security and observability products — Azure Monitor itself, Microsoft Sentinel, and Microsoft Defender for Cloud — with each inheriting the same retention, alerting, and transformation capabilities.
Azure Monitor has six alert types: metric alerts, log search alerts, simple log search alerts (preview), activity log alerts, smart detection alerts, and Prometheus alerts.
Azure Monitor alerts support dynamic thresholds and smart alerts using machine learning for intelligent alerting.
Smart detection alerts are Application Insights auto-detection of performance and failure anomalies.
Smart detection alerts automatically detect performance and failure anomalies in Application Insights resources.
Smart detection alerts originate from Application Insights and auto-detect performance and failure anomalies.
Stateful alert condition state is stored even after the 30-day alert deletion to prevent re-firing.
Stateful alert condition state is stored even after the 30-day alert deletion period to prevent re-firing of the same condition.
Stateful metric alerts resolve after 3 consecutive checks where the condition is not met.
Azure Monitor has three alert types: metric alerts (regular interval, dynamic thresholds), log alerts (KQL-based, predefined frequency), and activity log alerts (includes Resource Health and Service Health).
Azure Monitor has three alert types: metric alerts (regular interval, dynamic thresholds), log alerts (KQL-based), and activity log alerts (including Resource Health and Service Health).
Three VM alert types: metric alerts (regular interval, support dynamic thresholds), log alerts (KQL-based, predefined frequency), and activity log alerts (includes Resource Health and Service Health).
Azure Monitor Metrics supports three metric types: native platform metrics (free, auto-collected), native custom metrics (from apps/agents/API), and Prometheus metrics (from Kubernetes clusters).
Azure Monitor uses two query languages: KQL for logs/traces in Log Analytics workspaces and PromQL for metrics in Azure Monitor workspaces.
Log Analytics workspace configuration decisions (retention periods, table plans, DCR filtering) directly impact three product consumers — Azure Monitor, Microsoft Sentinel, and Microsoft Defender for Cloud — because the dual ingestion model (metrics time-series + Log Analytics workspace) feeds all three through the shared data platform; a misconfigured workspace degrades security observability, not just operational monitoring.
Azure NetApp Files provides 99.99% availability with locally redundant storage.
Azure NetApp Files provides 99.99% availability with locally redundant storage.
Azure NetApp Files provides 99.99% availability SLA with locally redundant storage; data-in-flight encryption is optional (not default).
Azure NetApp Files provides 99.99% availability SLA with locally redundant storage; data-in-flight encryption is optional (not default).
Azure NetApp Files uses FIPS 140-2 standard for encryption at rest.
Azure NetApp Files data-in-flight is NOT encrypted by default; NFSv4.1 and SMB3 encryption can be optionally enabled. Data stays within the customer-owned VNet.
Azure NetApp Files data-in-flight is NOT encrypted by default; NFSv4.1 and SMB3 encryption can be optionally enabled; data stays within the customer-owned VNet.
VM network interfaces have no separate cost but the number of NICs is limited by VM size.
There is no cost for availability sets or VM scale sets themselves — only per-VM instance charges apply.
Augmented security rules (multiple IPs, ranges, ports in a single rule) are only available in the Resource Manager deployment model.
NSG default rules use priorities 65000, 65001, and 65500; custom rules (max priority 4096) always evaluate first.
ESP and AH protocols in NSG rules can only be configured via ARM templates, not through the Azure portal.
NSG rules evaluate traffic using five-tuple matching: source, source port, destination, destination port, and protocol.
NSG flow logs are retiring on September 30, 2027; users should migrate to VNet flow logs.
Host node IPs 168.63.129.16 and 169.254.169.254 provide DHCP, DNS, IMDS, and health monitoring and are not subject to NSGs by default.
NSG processes inbound traffic after public-to-private IP translation; outbound traffic is processed before private-to-public IP translation.
NSG processes inbound traffic after public-to-private IP translation; outbound traffic is processed before private-to-public IP translation.
NSG processes inbound traffic after public-to-private IP translation; outbound traffic is processed before private-to-public IP translation.
You cannot create two NSG rules with the same priority and direction.
Two NSG rules cannot have the same priority and direction; each priority value must be unique within a given direction (inbound or outbound).
Platform IPs 168.63.129.16 and 169.254.169.254 (DHCP, DNS, IMDS, health monitoring) are not subject to NSG rules by default but can be blocked using service tags AzurePlatformDNS, AzurePlatformIMDS, and AzurePlatformLKM.
Platform IPs 168.63.129.16 and 169.254.169.254 (DHCP, DNS, IMDS, health monitoring) are exempt from NSG rules by default but can be blocked using service tags (AzurePlatformDNS, AzurePlatformIMDS, AzurePlatformLKM).
NSG security rule priority ranges from 100 to 4096; lower number equals higher priority; processing stops at first match.
Removing an NSG rule does not terminate existing connections; only new connections are affected.
Cannot create two NSG rules with the same priority and direction within the same NSG.
Security admin rules from Azure Virtual Network Manager are evaluated before NSG rules; "Always allow" and "Deny" admin rules bypass NSG evaluation entirely.
Outbound port 25 (SMTP) is blocked for most subscription types except standard Enterprise Agreement; subscriptions created after November 15, 2017 generally cannot send email directly over port 25.
NSGs are stateful — if outbound traffic is allowed, the inbound response is automatically allowed (and vice versa).
Network virtual appliances (NVAs) must be deployed in a different subnet than the routed resources to avoid routing loops.
Effective Azure observability requires alignment across three independently configurable systems: the identity chain (Entra→RBAC) determines workspace data access and who can see what telemetry, the governance hierarchy (Policy+RBAC) determines which monitoring policies are enforced across subscriptions, and the network default-deny stack (NSG+firewall) determines whether telemetry data can flow from on-premises and multi-cloud sources to Log Analytics workspaces.
Azure observability effectiveness is doubly gated: the identity-governance chain determines who can access and manage monitoring data (workspace access, alert creation, role-based restrictions), while PaaS tier selection determines what telemetry is available and how deeply it can be retained — both axes must align for effective operational visibility.
OS disk maximum capacity is 4,095 GiB; MBR limits usable size to 2 TiB (convert to GPT for more).
PaaS network isolation is doubly tier-gated: Private Link's triple isolation model (backbone routing + per-resource mapping + private DNS) requires PaaS services at Premium tier or above for private endpoint support, while those same services independently gate operational capabilities (geo-replication, retention, protocol support) by tier — full production-grade isolation is a compound function of networking model and service tier.
Multiple Azure PaaS services (Redis Cache, Event Hubs, ACR) follow a progressive tier pattern where higher tiers unlock additional capabilities (clustering, Kafka support, geo-replication) rather than just scaling existing ones.
Azure PaaS tier selection constrains available capabilities, security features, and network isolation options, making tier choice an important early design decision for PaaS-heavy workloads.
PaaS tier selection has compound impact across two independently gated dimensions: higher tiers unlock both operational capabilities (migration paths, HA options, scale features, Kafka interop) AND security posture (private link access, network isolation, content trust), meaning cost optimization directly trades against both security and migration flexibility at the platform level.
Performance Diagnostics has two modes: continuous (5-second intervals, preview) for ongoing monitoring and on-demand for point-in-time deep analysis.
Platform IPs 168.63.129.16 and 169.254.169.254 (DHCP, DNS, IMDS, health monitoring) are not subject to NSG rules by default, but can be blocked using service tags AzurePlatformDNS, AzurePlatformIMDS, and AzurePlatformLKM.
Platform metrics are stored in Azure Monitor's time-series database and support near real-time alerting with no configuration required.
Azure Arc extends Azure Policy governance to multi-cloud and on-premises datacenters.
Updating a policy definition automatically applies to all existing assignments; assignments always use the latest definition state.
Updating an Azure Policy definition automatically applies to all existing assignments; assignments always use the latest definition state.
auditIfNotExists assesses compliance based on a child or extension resource's properties, not the resource's own properties (unlike audit).
auditIfNotExists assesses compliance based on a child or extension resource's properties, not the resource's own properties (unlike audit).
Azure Policy best practice: always use initiatives even for a single policy definition, for easier scaling later.
Azure Policy best practice: start with audit/auditIfNotExists effects before enforcement effects (deny, modify, deployIfNotExists).
Azure Policy automatic compliance evaluation occurs every 24 hours.
When multiple Azure Policy assignments layer on a resource, the net result is the cumulative most restrictive combination of all applicable effects.
Policy definition displayName max length is 128 characters; description max length is 512 characters.
A policy definition location must be a management group or subscription; resources must be direct members or children of the definition location's hierarchy for assignment.
Policy definition mode all evaluates resource groups, subscriptions, and all resource types; indexed only evaluates types supporting tags and location. Portal defaults to all; Azure CLI defaults to null (equivalent to indexed).
Policy definition displayName max length is 128 characters; description max length is 512 characters.
Azure Policy effect evaluation order: disabled → append/modify → deny → audit → manual → auditIfNotExists → denyAction.
Azure Policy automatic compliance evaluation occurs every 24 hours; additional triggers include resource create/update, new/updated assignment, and policy update.
Azure Policy is an explicit deny system: if any assignment denies a resource, the only way to allow it is to modify the denying assignment.
Azure Policy parameter limits: 20 parameters per policy definition, 400 parameters per initiative; up to 1,000 policies per initiative.
Azure Policy supports up to 400 exclusions (notScopes) per assignment.
Azure Policy limits: 500 definitions per scope, 200 initiative definitions per scope (2,500 per tenant), 200 assignments per scope, 1,000 exemptions per scope, 400 notScopes per assignment.
Each Azure Policy metadata property (version, category, preview, deprecated, portalReview) is capped at 1024 characters.
Policy definition mode all evaluates resource groups, subscriptions, and all resource types; indexed only evaluates types supporting tags and location. Portal defaults to all; Azure CLI defaults to null (equivalent to indexed).
Fully supported Resource Provider modes for Azure Policy: Microsoft.Kubernetes.Data, Microsoft.KeyVault.Data, Microsoft.Network.Data.
Fully supported Resource Provider modes for Azure Policy: Microsoft.Kubernetes.Data, Microsoft.KeyVault.Data, Microsoft.Network.Data; RP modes use only audit, deny, and disabled effects.
Each Azure Policy definition contains exactly one effect in its policyRule.
Policy policyType has three values (read-only, system-set): Builtin (Microsoft-maintained), Custom (customer-created), and Static (Regulatory Compliance with Microsoft ownership).
Policy policyType is read-only (set by system): Builtin (Microsoft-provided), Custom (customer-created), or Static (Regulatory Compliance with Microsoft ownership).
Azure Policy definitions use Major.Minor.Patch versioning: Major for breaking changes, Minor for minor rule/value changes, Patch for string/metadata/security fixes.
Azure Policy evaluates resource state; Azure RBAC evaluates user actions. Policy blocks non-compliant resources regardless of who has permission.
Autoregistration in Azure Private DNS creates A records pointing to VMs' private IP addresses; records are automatically created, updated, and deleted as VMs are provisioned or removed.
A VNet can be linked to only one private DNS zone for autoregistration, but multiple VNets can link to the same private zone.
Best practice: do not use .local as a private DNS zone domain because not all operating systems support it.
Conditional forwarding from Azure to on-premises requires Azure DNS Private Resolver.
Cross-VNet DNS resolution via private DNS zones works without VNet peering — only a virtual network link to the shared private zone is needed.
Azure Private DNS zone data is a global resource, resilient across regions — not tied to a single VNet or region.
Azure Private DNS resolves domain names within Azure virtual networks without needing custom DNS servers.
Reverse DNS for private IPs in non-autoregistration linked VNets returns only a single FQDN with the internal.cloudapp.net suffix.
Reverse DNS for private IPs in autoregistration-enabled VNets returns two FQDNs: one with internal.cloudapp.net suffix and one with the private zone suffix.
Azure Private DNS supports split-horizon DNS: a private and public DNS zone can share the same name, returning different answers depending on whether the query originates from inside the VNet or the public internet.
Azure Private DNS supports split-horizon resolution where private and public zones share names, but reverse DNS behavior is asymmetric: autoregistration-enabled VNets return two FQDNs (internal.cloudapp.net + private zone), while non-autoregistration VNets return only the internal.cloudapp.net FQDN.
Azure Private DNS supports record types: A, AAAA, CNAME, MX, PTR, SOA, SRV, TXT.
A virtual network link connects a VNet to a private DNS zone, granting VMs in that VNet full access to resolve all records in the zone.
Network Security Perimeter is GA in all public cloud regions and complements Private Link for scenarios involving public internet PaaS traffic, creating a secure logical boundary.
A regional (non-zonal) VM has no visibility into which physical or logical zone it occupies, and a failure in any zone can potentially affect it.
Azure reservations combine financial commitment with three dimensions of operational flexibility: scope (which subscriptions receive the discount) can be changed after purchase, monthly and upfront payment options have identical total cost (no premium for installments), and reservations can be exchanged for the same resource type or refunded within the $50,000 rolling 12-month cap — reducing the risk of commitment lock-in.
Azure reservations' partial-coverage model extends consistently from compute to data services: VM reservations cover compute-only (not networking, storage, or Windows licensing), Blob reservations cover capacity-only (not bandwidth or transactions), and SQL reservations cover compute-only (plus zone-redundancy add-on for General Purpose), confirming partial coverage is a platform-wide billing architecture pattern, not a per-service exception.
Azure reservation strategy operates as a partial-coverage-full-flexibility model: reservations universally cover only the primary billable unit (compute for VMs/SQL, throughput for Cosmos DB, capacity for Blob, DBUs for Databricks) while providing three dimensions of operational flexibility (scope reassignment, splitting, exchange for same-type), requiring cost optimization to combine commitment planning for the covered dimension with separate management of uncovered costs.
Azure reservations provide partial cost coverage across multiple services (VM compute, Blob capacity, SQL DTU/vCore, Cosmos DB throughput, Databricks DBU) — each covering only specific cost dimensions while leaving other dimensions at pay-as-you-go rates.
Azure Reservation costs are deducted from Azure Prepayment (formerly monetary commitment) balance first; any overage is billed separately.
Azure Reservation software plans (SUSE Linux, Red Hat, Azure Red Hat OpenShift) cover software costs only, not VM or infrastructure costs.
All Azure Reservations are applied on an hourly basis except Azure Databricks.
Azure Reservations are purely a billing construct and do not affect the runtime state of resources.
Azure Reservations for Blob Storage cover capacity only — not bandwidth or transaction costs.
Azure Reservations can be split into smaller parts after purchase, and the scope can be changed after purchase.
Azure Reservations can be split into smaller parts after purchase, and instance size flexibility can be changed post-purchase.
Azure Reservations for Cosmos DB cover provisioned throughput only — not storage or networking costs.
Azure Reservation costs deduct from Azure Prepayment (Monetary Commitment) balance first; overage is billed separately.
Azure Reservations can be exchanged for the same resource type or refunded within the $50,000 USD rolling 12-month cap.
Azure Reservations can be exchanged for the same resource type, split into smaller parts, or refunded (up to $50,000 USD in a rolling 12-month window).
Azure Reservations can be exchanged for same-type reservations after purchase.
Azure Reservation monthly and up-front payment options have the same total cost — no premium for monthly payments.
Azure Reservation monthly and up-front payment options have the same total cost; there is no premium for choosing monthly payments.
Azure Reservation costs are deducted from Azure Prepayment (formerly monetary commitment) balance first; overage is billed separately.
Azure Reservations can be refunded up to $50,000 USD in a rolling 12-month window.
Azure Reservation scope (which subscriptions/resource groups receive the discount) can be changed after purchase.
Azure Reservation scope controls where savings apply and can be updated after purchase.
Azure Reservations can be split into smaller parts and have instance size flexibility changed after purchase.
Azure Reservations provide billing discounts of up to 72% off pay-as-you-go prices with 1-year or 3-year commitment terms.
Azure reserves 5 IP addresses per subnet: first address (network), last address (broadcast), and 3 for Azure services.
Resource Manager locks prevent storage account deletion but do not prevent data deletion within the account.
To revoke a service SAS with a stored access policy: delete the policy, rename it, or set its expiry to the past.
To revoke a service SAS with a stored access policy: delete the policy, rename it, or set its expiry to the past.
To revoke a user delegation SAS, revoke the user delegation key, which invalidates all SAS tokens signed with that key.
To revoke a user delegation SAS, you must revoke the user delegation key, which invalidates all SAS tokens signed with that key.
To revoke a user delegation SAS, you revoke the user delegation key, which invalidates all SAS tokens signed with that key.
Microsoft Sentinel and Microsoft Defender for Cloud both store their security data in Azure Monitor Log Analytics workspaces.
Service endpoints secure PaaS resources to the VNet over public endpoints; Private Link provides private access to a specific service instance via private IP.
A service SAS not associated with a stored access policy cannot be revoked; best practice is to limit expiry to one hour or less.
Shared managed disks (attached to multiple VMs simultaneously) require a cluster manager such as WSFC or Pacemaker.
Azure Site Recovery enables cross-region failover and is not restricted to paired regions.
Azure Site Recovery supports replication for Azure VMs between regions, on-premises VMs, Azure Stack VMs, and physical servers.
Azure Site Recovery supports testable failover without impacting production workloads.
Soft delete is available for both blobs and containers as separate settings that must be enabled independently.
Azure software plan reservations (SUSE Linux, Red Hat, Azure Red Hat OpenShift) cover software costs only, not VM or infrastructure costs.
Azure Resource Graph Spot pricing history covers 90 days; eviction rate data covers 28 days via the SpotResources table.
Azure Spot VM pricing history (90 days) and eviction rates (28 days) can be queried programmatically via the SpotResources table in Azure Resource Graph.
Spot VMs are available in all Azure regions except Microsoft Azure operated by 21Vianet.
Azure Resource Graph provides 90 days of Spot VM pricing history and 28 days of eviction rate data via the SpotResources table.
B-series and promo-version VM sizes are not supported for Spot VMs.
Spot VMs cannot be converted to standard VMs or vice versa after creation; the Spot flag is set only at creation time.
Azure Spot VM viability is bounded by a compound constraint envelope: operational constraints (eviction with ~30s notice, separate quota pool, no auto-restart, deallocate-to-reprice) combine with workload exclusions (no B-series, no promo SKUs) — a workload must tolerate all constraints simultaneously, not just individually.
The default eviction policy for Azure Spot VMs is Deallocate (not Delete); deallocated Spot VMs still consume quota and incur storage charges.
Evicted Spot VMs are not automatically restarted even if the spot price drops below the configured max price again.
Spot VM eviction rates represent a per-hour probability of eviction based on trailing 7-day historical data.
Spot VM eviction rate is a per-hour probability (e.g., 10% = 10% chance of eviction in the next hour) based on trailing 7-day history.
Spot VM eviction rate is expressed as a per-hour probability based on trailing 7-day historical data.
Spot VM max price can only be changed after the VM is deallocated.
Setting a Spot VM's max price to -1 prevents price-based eviction; the VM is charged at the lesser of current spot price or standard price.
A Spot VM must be deallocated before its maximum price can be changed.
Azure Spot VMs have no SLA and can be evicted with approximately 30 seconds' notice via Azure Scheduled Events.
Evicted Spot VMs are not automatically restarted, even if the spot price drops below the configured max price again.
Azure Spot VMs are available in all regions except Microsoft Azure operated by 21Vianet.
Azure Spot VM constraints compound: the default Deallocate eviction policy preserves disks but continues consuming quota from a separate Spot-specific pool, evicted VMs are never automatically restarted even when prices drop below the configured maximum, and setting max price to -1 prevents only price-based eviction (capacity eviction remains possible) — operators must build explicit recovery automation and quota monitoring.
Spot VMs use a separate quota pool from standard VMs, shared between Spot VMs and Spot scale-set instances.
Spot VMs are supported for Enterprise Agreement, Pay-as-you-go (003P), Sponsored (0036P/0136P), and CSP offer types.
SQL Database and SQL Managed Instance reservations cover compute costs only (plus zone-redundancy add-on for General Purpose tier).
For Azure SQL Database, service endpoint traffic applies only within the same region.
Azure SQL Database service endpoints apply only within the VNet's region.
Standard HDD as an OS disk type is retiring on September 8, 2028.
Standard HDD as OS disk is retiring on September 8, 2028.
Anonymous read access on Azure Blob Storage should be disabled unless explicitly required; it grants read-only access to any client and is a common security misconfiguration.
Anonymous read access on Azure Blob Storage should be disabled by default; it grants read-only access to any client and is a common security misconfiguration.
Cross-tenant object replication can be disallowed to restrict replication policies to same-tenant storage accounts only.
All Azure Storage data is automatically encrypted at rest; customers can optionally manage their own keys via Azure Key Vault.
Azure Storage encrypts all data at rest by default using Microsoft-managed keys.
When Azure Storage firewall rules are enabled, all requests are blocked by default — exceptions must be added for trusted Microsoft services.
When enabling storage account firewall rules, an exception for trusted Microsoft services should be added to avoid blocking Azure portal, logging, and metrics.
Azure Storage supports four authorization methods: Microsoft Entra ID (recommended), Shared Key, SAS tokens, and AD DS (for NetApp Files).
Private endpoints assign a private IP from a VNet to the storage account, routing all traffic over a private link.
Private endpoints assign a private IP from a VNet to the storage account, routing all traffic over a private link.
Secure transfer can be enforced on storage accounts via the supportsHttpsTrafficOnly: true ARM template setting, requiring HTTPS-only connections.
Azure Resource Manager locks protect the storage account from deletion but do NOT prevent data within the account from being deleted.
The secure transfer setting on a storage account requires HTTPS for all requests.
SUSE and Red Hat software plans cover software costs only — not underlying VM compute usage.
System-assigned managed identity is deleted automatically with its parent resource and cannot be shared across resources (1:1 relationship).
System-assigned managed identity service principal name matches the Azure resource name; for deployment slots the pattern is <app-name>/slots/<slot-name>.
Azure Table Storage is now part of Azure Cosmos DB; Cosmos DB for Table offers throughput-optimized tables, global distribution, and automatic secondary indexes.
Windows temporary disk is drive D; Linux temporary disk is /dev/disk/azure/resource.
Temporary disk paths: Linux = /dev/disk/azure/resource, Windows = drive D.
Temporary disk paths: Linux = /dev/disk/azure/resource, Windows = drive D.
Temporary disk paths: Linux = /dev/disk/azure/resource, Windows = drive D.
VMs v5 and newer automatically encrypt temporary and ephemeral OS disks at rest.
The temporary disk is not a managed disk and data can be lost on maintenance events, redeployment, or VM stop.
There are exactly 3 Availability Zones per supported Azure region, each with distinct power, network, and cooling.
Multiple Azure services enforce TLS for data in transit: Azure SQL enforces TLS connections, Redis recommends TLS 1.2 minimum, App Service supports TLS 1.2 configuration, and Key Vault uses TLS for API access — establishing a common encryption-in-transit pattern across the platform.
Azure Traffic Manager is a DNS-based (not network-level) traffic load balancer operating at global scope across Azure regions.
User-assigned managed identities have an independent lifecycle, must be explicitly deleted, and can be shared across multiple Azure resources.
User delegation SAS is the most secure SAS type because it uses Microsoft Entra credentials rather than account keys.
VMs v5+ automatically encrypt temporary disks at rest without additional configuration.
VHDs can be uploaded up to 32 TiB directly to managed disks without attaching to a VM.
Each Azure VM creates associated resources (VNet, NIC, IP addresses, NSG, OS disk, optional data disks) that are each billed separately from the VM compute.
Azure VMs achieve a 99.99% SLA when 2+ instances are deployed across 2+ Availability Zones in the same region.
B-series is the only burstable VM type — it uses a CPU credit model that accumulates credits below baseline and throttles when credits are exhausted.
Best practice is to keep data on a separate managed disk from the OS disk for recoverability and independent management.
Azure VMs are billed per-minute (not per-hour); for partial hours only minutes used are charged.
Azure VMs are billed per-minute for partial hours; storage is billed separately.
Boot diagnostics is enabled by default when creating a VM in the Azure portal.
Cloud-init is supported on most Azure Linux distributions for automated VM provisioning at first boot.
Cloud-init is supported across most Linux distributions for automated deployment and configuration on both VMs and VMSS.
Cloud-init is supported on most Azure Linux distributions for automated VM provisioning.
Azure VM cost is determined by multiple dimensions: compute (instance family and size), OS licensing (with Hybrid Benefit for existing licenses), and reservations (providing discounts on the compute dimension while other dimensions remain at standard rates).
General Purpose D-family is the default recommendation for most production workloads, offering balanced CPU-to-memory ratio.
VM sizes with 'd' in the name (e.g., Dadsv6, Eadsv6) include local NVMe ephemeral storage with sub-millisecond latency, capped at 2,040 GiB, not persisted on deallocation.
VM sizes with 'd' in the name (e.g., Dadsv6) include local NVMe ephemeral disks that are not persisted across deallocation, capped at 2,040 GiB.
Single-region data residency storage is only available in Southeast Asia (Singapore) and Brazil South; all other regions store data at the Geo level.
DC and EC VM families provide confidential computing with hardware-based Trusted Execution Environments (TEEs).
Default Azure VM quota is 20 total cores per region per subscription, which can be raised via support ticket.
Azure subscriptions have a default quota of 20 VM total cores per region, which can be increased via support ticket.
F-family VMs are compute optimized with a high CPU-to-memory ratio, suited for batch processing, web servers, and analytics.
F-family VMs are compute optimized with a high CPU-to-memory ratio, suited for batch processing, web servers, and analytics.
FX-family VMs target specialized compute with high single-core performance for EDA, financial modeling, and scientific simulations.
Azure GPU VM families serve distinct purposes: ND for AI training/inference, NC for GPU compute, NV for visualization/VDI, NGads for gaming.
Azure GPU VM families: NC-series for general GPU compute, ND-series for deep learning training/inference, NV-series for visualization and streaming.
GPU VM families: ND for AI training/inference, NC for compute-intensive GPU, NV for visualization/remote graphics, NGads for gaming.
Guest OS metrics require Azure Monitor Agent (AMA) plus a data collection rule (DCR) to be configured.
HB-family VM sizes support InfiniBand, RDMA, and MPI for tightly coupled parallel HPC workloads.
VM host metrics (CPU, network, disk from Hyper-V session) are collected automatically with no setup required.
Azure HPC VM families: HB for memory-bandwidth-sensitive HPC (weather, CFD), HC for dense computation, HX for extreme memory workloads (EDA).
VM Insights automatically installs Azure Monitor Agent and creates a default DCR; it is the recommended starting point for VM monitoring.
VM Insights Map feature populates four tables: VMBoundPort, VMComputer, VMConnection, and VMProcess; the main DCR writes to the InsightsMetrics table.
VM Insights populates five tables: InsightsMetrics (performance), VMBoundPort, VMComputer, VMConnection, and VMProcess (dependency map data).
L-family VMs are Storage Optimized for high disk throughput and IO, suited for NoSQL databases (Cassandra, MongoDB), Redis, and data warehousing.
L-family VMs are storage optimized with high disk throughput and IO, ideal for NoSQL databases (Cassandra, MongoDB, Redis).
L-family VMs are storage optimized for high disk throughput and IO workloads such as Cassandra, MongoDB, and Redis.
M-family VMs offer the largest memory capacities in Azure (up to multiple TB of RAM) for workloads like SAP HANA and large databases.
Azure Managed Disks are recommended over unmanaged disks for production workloads; unmanaged disks can be converted to managed disks.
Moving a VM between VNets requires deleting and recreating the VM (disks can be retained).
The number of NICs attached to a VM is limited by the VM size; there is no separate cost for NICs.
Virtual NICs have no separate cost but the number of NICs a VM can have is limited by VM size.
NSGs and local temporary disks have no additional cost; NICs have no separate cost.
Azure NSGs and NICs have no additional charge; NIC count limits are determined by VM size.
Azure VM OS disk default size is approximately 127 GiB.
Azure VM OS disks have a default size of approximately 127 GiB (smaller for some images).
Azure VM OS disk is typically 127 GiB (smaller for some images).
Azure VM Performance Diagnostics supports two modes: continuous (5-second intervals, preview) and on-demand (point-in-time deep analysis).
Azure reservations provide only partial cost coverage with explicit exclusions: VM reservations cover compute only (not networking, storage, or Windows licensing), and blob storage reservations cover capacity only (not bandwidth or transactions) — requiring separate cost management for excluded dimensions.
VM reservations cover compute costs only — networking, storage, Windows licensing, and additional software are not included.
The 's' suffix in Azure VM size names indicates Premium Storage (SSD) capability.
Azure VM sizes are categorized into 6 types: General Purpose (A/B/D/DC), Compute Optimized (F/FX), Memory Optimized (E/Eb/EC/M), Storage Optimized (L), GPU Accelerated (N), and FPGA Accelerated (NP).
In VM size names, no CPU letter indicates Intel x86-64, 'a' indicates AMD, and 'p' indicates ARM (Cobalt/Ampere Altra).
Series name omits vCPU count (e.g., DCadsv5); full size name includes Standard prefix and vCPU count (e.g., StandardDC8ads_v5).
VM size version numbers (v5, v6, v7) indicate hardware generations — higher is newer; the first version may omit the version number.
VM size version numbers (v5, v6, v7) indicate hardware generations — higher is newer; first-generation sizes may omit the version number.
VM sizes with 'd' in the name include local NVMe ephemeral storage; data is not persisted across deallocation.
Azure VM families form a specialized compute taxonomy where each series is purpose-built for a distinct workload profile: F-series provides high CPU-to-memory ratio for batch and web workloads, GPU families differentiate by use case (NC for general compute, ND for deep learning training, NV for visualization), and HPC families differentiate by bottleneck type (HB for memory bandwidth, HC for dense computation, HX for extreme memory), requiring workload characterization before VM family selection.
Azure VM storage (OS disk, data disks) is priced and charged separately from compute costs.
Windows temporary disk is drive D; Linux temporary disk is at /dev/disk/azure/resource.
Trusted Launch (secure boot + vTPM) is becoming the default for new Gen2 VMs (preview feature called TLaD).
Trusted Launch as Default (TLaD) is a preview feature where new Gen 2 VMs default to Trusted Launch with secure boot and vTPM enabled.
VMs v5+ automatically encrypt temporary disks at rest without additional configuration.
VMs v5 and newer automatically encrypt temporary and ephemeral OS disks at rest.
Windows VM licensing uses outbound port 1688 to connect to the Key Management Service.
VMSS Flexible orchestration supports up to 1,000 VMs with standard marketplace or Azure Compute Gallery images; managed images cap at 600.
VMSS Flexible orchestration supports mixing Spot and on-demand VM instances within the same scale set.
VMSS Flexible orchestration mode supports mixing Spot and on-demand VMs together in the same scale set.
VMSS Flexible orchestration supports mixing Spot and on-demand VM instances together in the same scale set.
Virtual Machine Scale Sets support up to 1,000 VMs when using Marketplace or Compute Gallery images with managed disks.
There is no extra cost for the VMSS resource itself — you pay only for underlying compute, network, and storage resources.
VMSS orchestration mode (Uniform or Flexible) is set at creation time and cannot be changed later.
Scale sets alone do not protect against datacenter failure — Availability Zones must be used for cross-datacenter protection.
All VM instances in a scale set are created from the same base OS image and configuration.
All VM instances in a scale set are created from the same base OS image and configuration.
Azure Virtual Network itself is free; standard charges apply only to resources deployed within it.
Address space can be added, modified, or deleted on peered VNets without downtime; peers must be synced after each resize. Not supported when peered with a classic VNet.
VNet peering incurs a nominal fee on both ingress and egress traffic.
VNet peering works across subscriptions, Microsoft Entra tenants, deployment models (ARM and classic), and regions.
Default VNet peering limit is 500 peered VNets per VNet; increased to 1,000 with Azure Virtual Network Manager connectivity configuration.
VNet peering provides inter-VNet connectivity over Microsoft's backbone network with non-transitive routing, symmetric bandwidth across regions, and support for cross-subscription/cross-tenant topologies.
A VNet using gateway transit with a remote gateway cannot have its own gateway; the gateway must be in a Resource Manager model VNet.
VNet peering incurs nominal charges for both ingress and egress traffic on peering connections; gateway transit incurs peering charges on the spoke VNet.
VNet peering traffic stays on the Microsoft backbone — no encryption, gateways, or public internet needed.
No downtime occurs when creating VNet peering connections.
VNet peering is not transitive: if A peers with B and B peers with C, A and C are not automatically connected — service chaining or mesh peering is required.
Latency between VMs in peered VNets within the same region equals latency within a single VNet; throughput is limited only by the VM's allowed bandwidth, not the peering.
Latency between VMs in peered VNets within the same region equals latency within a single VNet.
Subnet peering allows peering of specific subnets rather than entire VNet address spaces.
Subnet peering allows peering of specific subnets rather than entire VNets, narrowing the scope of connectivity.
Never associate a route table with a 0.0.0.0/0 route to GatewaySubnet for VPN gateways — it will break gateway functionality.
When multiple service tag routes match, priority is: regional tags (e.g., Storage.EastUS) > top-level tags (e.g., Storage) > AzureCloud regional tags > AzureCloud tag.
VNet service endpoints extend a VNet's private address space and identity to Azure PaaS services (e.g., Storage, SQL Database) over a direct connection on the Azure backbone.
VNet service endpoints extend a VNet's private address space to Azure PaaS resources (e.g., Storage, SQL Database) over a direct connection, securing those services to the VNet.
VNets and subnets span all availability zones in a region automatically — no need to divide by AZ.
When using VPN Gateway with custom DNS servers, the Azure DNS IP 168.63.129.16 must be included in the DNS server list.
When using VPN Gateway with custom DNS servers, 168.63.129.16 must be included in the DNS server list.
Azure SQL Database offers a 99.99% availability SLA
Azure SQL Database guarantees 99.99% SLA availability (up to 99.995% per the Azure SQL family overview).
Azure SQL Database active geo-replication supports up to 4 readable secondary databases in same or different regions
Always Encrypted keeps encryption keys on the client side; even DBAs cannot see plaintext data.
Always Encrypted keeps encryption keys outside the database engine, protecting data even from database administrators — data is encrypted at rest and in use.
SQL Auditing writes audit logs to customer-owned Azure storage, Azure Monitor logs, or Event Hubs.
Azure SQL Database automatic tuning includes automatic index management and automatic plan correction.
Azure SQL Database automatic tuning includes automatic index management and automatic plan correction.
Azure SQL Database backups are compressed with typical 3–4x ratio, but TDE-encrypted transaction log backups are NOT compressed.
Azure SQL backup has three critical constraints that compound during DR planning: TDE prevents transaction log backup compression (reducing backup storage efficiency), geo-restore is disabled when backup redundancy is set to LRS or ZRS (forcing a GRS/GZRS cost commitment for geo-recovery), and server deletion permanently destroys all databases with only LTR blob backups surviving — making redundancy selection, encryption configuration, and operational procedures interdependent DR concerns.
Azure SQL Database provides free backup storage equal to the provisioned max data size; excess is billed per GB/month.
Azure SQL Database automated backups: full weekly, differential every 12h (vCore) or 24h (DTU), transaction log ~10 minutes
Azure SQL Database backup redundancy changes apply only to future backups, may take up to 48 hours, and existing backups remain on original storage.
Azure SQL Database short-term retention (STR) is configurable from 1–35 days (default 7), except Basic tier which is limited to 1–7 days.
Azure SQL Database Basic tier short-term backup retention maximum is 7 days (vs 35 days for other tiers)
Azure SQL Database Business Critical tier runs automated backups on secondary replicas by default, offloading the primary with no extra cost.
Best practice: use custom database roles with least privilege; never assign permissions directly to users; limit db_owner to administrative users only.
Best practice: assign users to database roles with least privilege; avoid direct permission grants to users; limit db_owner role to administrative users only.
Azure SQL Database Business Critical tier takes backups from secondary replicas by default to offload the primary
Azure SQL Database Business Critical tier runs automated backups on secondary replicas by default, offloading the primary with no extra cost.
CLR support is not available in Azure SQL Database but is supported in Managed Instance.
Customer-managed keys (CMK) for TDE can be configured at the logical server level (all databases) or at the individual database level.
Azure SQL deployment model selection determines both security capabilities and connectivity architecture in tandem: Managed Instance provides native VNet integration with private IP and TCP-only protocol but lacks Network Security Perimeter support, while SQL Database requires Private Link for private connectivity but gains NSP — forcing fundamentally different network designs and security tooling per deployment model.
Azure SQL Database cross-subscription restore is not supported for PITR, geo-restore, or LTR; workaround is restore then Resource Move
Azure SQL Database default backup storage redundancy is geo-redundant (GRS); GZRS is Microsoft-recommended for maximum resilience
Azure SQL Database default PITR retention is 7 days (configurable 1–35 days; Basic tier limited to 1–7 days)
Azure SQL Database deleted database restore is only possible on the same server where the original was created
Setting TrustServerCertificate=True in production disables protection against man-in-the-middle attacks; always use TrustServerCertificate=False.
Dynamic Data Masking masks data in query results but does not change the underlying stored data.
Azure SQL Database dynamic scaling is manual with no downtime; automatic autoscaling requires the serverless compute tier.
Azure SQL Database dynamic scaling is manual with no downtime; automatic autoscaling requires serverless tier
Azure SQL Database dynamic scaling is manual (no downtime) while autoscaling is automatic and only available via the serverless compute tier.
Azure SQL Database elastic pools share vCore/DTU resources across multiple databases, optimizing cost for SaaS multitenant patterns with variable workloads
Azure SQL Database elastic pools share resources across multiple databases, ideal for SaaS multitenant patterns with unpredictable usage.
Elastic pools are for Azure SQL Database; instance pools are for Azure SQL Managed Instance.
New SQL Server features release to Azure SQL Database first, then to on-premises SQL Server
IP and VNet firewall rules do NOT apply to Azure SQL Managed Instance; it uses its own networking configuration.
Azure SQL Database completes its first full backup within approximately 30 minutes of database creation.
Azure SQL Database free backup storage equals the provisioned maximum data size; excess is billed per GB/month
Azure SQL Database geo-restore is disabled when backup redundancy is set to LRS or ZRS
Restoring an Azure SQL Database from a GZRS source inherits GZRS redundancy unless explicitly overridden; the restore fails if the target region doesn't support GZRS.
Business Critical / Premium tier uses Always On availability groups with 1 primary and up to 3 secondary replicas with co-located compute and SSD storage.
Read Scale-Out is a Business Critical / Premium feature that offloads read-only queries to secondary replicas at no additional charge.
Azure SQL Database General Purpose zone redundancy uses Zone-Redundant Storage (ZRS) for data and log files.
The manual failover command (Invoke-AzSqlDatabaseFailover) is NOT available for readable secondary replicas of Hyperscale databases.
The manual failover command is not available for readable secondary replicas of Hyperscale databases.
Azure SQL Hyperscale uses a four-layer distributed architecture: stateless compute, page servers (active-active pairs), log service with transaction log storage, and data files in Azure Storage.
Hyperscale zone redundancy can only be set at database creation time; changing it afterward requires database copy, point-in-time restore, or geo-replica.
Hyperscale zone redundancy requires at least one HA compute replica and zone-redundant or geo-zone-redundant backup storage.
Hyperscale zone redundancy requires at least one HA compute replica and zone-redundant or geo-zone-redundant backup storage.
Azure SQL Database local redundancy uses Locally Redundant Storage (LRS), copying data three times within a single datacenter.
Azure SQL Database manual failover is rate-limited to once per 15 minutes per database or elastic pool.
The master database automatically becomes zone-redundant when any database on the logical server is zone-redundant.
Azure SQL Database General Purpose (remote storage model) may experience performance degradation during failover due to cold cache on the new compute node.
Remote storage model (General Purpose) may experience performance degradation during failover due to cold cache startup on the new compute node.
Azure SQL Database RPO is zero (no committed data loss) for both local and zone-redundant configurations.
Azure Service Fabric manages health monitoring and failover across all Azure SQL Database availability models.
Azure SQL Database uses three availability models mapped to service tiers: remote storage (Basic/Standard/General Purpose), local storage (Premium/Business Critical), and Hyperscale (distributed four-layer architecture).
Azure SQL achieves zero RPO (no committed data loss) for both local and zone-redundant HA configurations, but General Purpose tier pays a performance penalty during failover due to cold cache startup on remote storage — making RPO and RTO guarantees asymmetric.
Zone redundancy is NOT available for Azure SQL Database Basic and Standard (DTU) service tiers.
Azure Hybrid Benefit for SQL requires Software Assurance on existing SQL Server licenses.
Azure SQL Database Hyperscale tier supports up to 128 TB storage with independently scalable compute and storage
Azure SQL Hyperscale backup redundancy can only be set at creation time and cannot be modified later
Hyperscale achieves 128 TB scale through a four-layer distributed architecture (stateless compute, page servers, log service, remote storage), with zone redundancy requiring both HA compute replicas and zone-redundant backup storage as co-requisites.
The manual failover command is not available for readable secondary replicas of Hyperscale databases.
Hyperscale uses a four-layer distributed architecture: stateless compute, page servers (active-active pairs), log service with transaction log storage, and data files in Azure Storage.
Azure SQL Hyperscale uses storage snapshots instead of traditional SQL Server backup technology, providing instant backup and fast restore regardless of database size
Hyperscale zone redundancy requires at least one HA compute replica and zone-redundant or geo-zone-redundant backup storage.
Azure SQL Database immutable backups are supported only for long-term retention (LTR), not for PITR or geo-restore
Azure SQL Ledger provides cryptographic proof of data integrity and tamper-evidence for regulatory compliance and auditability.
Azure SQL Ledger provides cryptographic proof of data integrity (tamper-evidence) for regulatory compliance and auditability.
Azure SQL Database long-term retention (LTR) supports up to 10 years of backup retention
The master database on an Azure SQL logical server automatically becomes zone-redundant when any database on that server is zone-redundant.
Azure SQL max database sizes: SQL Database = 128 TB, Managed Instance = 16 TB, SQL VMs = 256 TB.
Azure SQL Database supports up to 128 TB per database, Managed Instance up to 16 TB, and SQL Server on Azure VMs up to 256 TB.
Backups from Azure SQL Managed Instance can be restored to SQL Server 2022 (reverse portability).
Backups from Azure SQL Managed Instance can be restored to SQL Server 2022 (reverse portability).
Azure SQL Managed Instance supports backward compatibility to SQL Server 2008 databases, with direct migration from SQL Server 2005 (upgraded to 2008 compatibility level).
Only COPY_ONLY backups can be user-initiated on Azure SQL Managed Instance; automated backups handle the rest.
Azure Hybrid Benefit for SQL Managed Instance requires Software Assurance on existing SQL Server licenses.
Azure SQL Managed Instance supports stop/start; when stopped, only storage is billed (no compute charges).
A SQL Managed Instance secondary replica designated for DR only incurs no vCore licensing cost (license-free DR replica).
Azure SQL Managed Instance is positioned as the primary lift-and-shift target for on-premises SQL Server: backward compatibility to SQL Server 2008 enables legacy workloads, native VNet deployment with single-tenant isolation preserves network security models, and Managed Instance Link via distributed availability groups enables near-zero-downtime migration with ongoing replication.
Managed Instance link uses distributed availability groups to synchronize data between on-premises SQL Server and SQL MI for hybrid scenarios, DR, and read offload.
Managed Instance link uses distributed availability groups to synchronize data between on-premises SQL Server and SQL MI for hybrid scenarios, DR, and read offload.
Azure SQL Managed Instance link uses distributed availability groups to synchronize databases between on-premises SQL Server and SQL MI for hybrid DR, read offloading, and migration.
Managed Instance link uses distributed availability groups to synchronize databases between on-premises SQL Server and SQL MI for hybrid scenarios, DR, and migration.
Azure SQL Managed Instance supports a maximum database size of 16 TB.
Azure SQL Managed Instance is deployed into a customer's virtual network with dedicated compute/storage and single-tenant isolation.
Azure SQL Managed Instance offers near 100% compatibility with the latest SQL Server Enterprise Edition.
Azure SQL Managed Instance is recommended for most migrations from on-premises SQL Server to Azure.
Azure SQL Managed Instance reserved capacity can save up to 80% on costs compared to pay-as-you-go pricing.
SQL Managed Instance supports server-level roles (fixed or custom); SQL Database does not.
Azure SQL Managed Instance has a 99.99% uptime SLA.
SSIS packages are stored in SSISDB on SQL Managed Instance but executed on Azure-SSIS Integration Runtime in Azure Data Factory.
SSIS packages on SQL Managed Instance are stored in SSISDB but executed on Azure-SSIS Integration Runtime in Azure Data Factory.
Azure SQL Managed Instance supports stop/start capability; when stopped, you pay only for storage.
Azure SQL Managed Instance supports TCP protocol only; named pipes are not supported.
TDE certificates must be migrated when restoring an encrypted database to SQL Managed Instance via native restore.
Azure SQL Managed Instance vCore model offers three hardware options: Standard Series (Gen5) at 5.1 GB RAM/vCore, Premium Series at 7 GB RAM/vCore, and Premium Series Memory-Optimized at 13.6 GB RAM/vCore.
Azure SQL Managed Instance does NOT support VNet Classic deployment model; only ARM is supported.
Azure SQL migration targets are tier-constrained at every level: Managed Instance provides lift-and-shift with SQL Server 2008 backward compatibility but within a 16 TB ceiling, while Database offers scale beyond 128 TB via Hyperscale's distributed architecture but with tier-dependent HA tradeoffs (General Purpose cold-cache penalty vs Business Critical local SSD) — making tier selection inseparable from migration planning.
Network Security Perimeter is in preview and creates logical network boundaries around PaaS resources deployed outside VNets; it does NOT apply to SQL Managed Instance.
Azure SQL Database point-in-time restore (PITR) creates a new database on the same server with a different name; it never overwrites the original
Azure SQL Database point-in-time restore (PITR) creates a new database on the same server with a different name; it never overwrites the original.
Azure SQL Database point-in-time restore (PITR) cannot restore cross-region or cross-subscription; geo-restore and LTR can restore cross-region.
Azure SQL Managed Instance and SQL VMs have native private IP connectivity; Azure SQL Database requires Private Link for private IP access.
Azure SQL Managed Instance and SQL VMs have native private IP; Azure SQL Database requires Azure Private Link for private IP connectivity.
Row-Level Security (RLS) in Azure SQL controls access to individual table rows based on user characteristics and can implement label-based access control.
Row-Level Security (RLS) in Azure SQL controls access to individual rows based on user characteristics or execution context, and can implement label-based security concepts.
Row-Level Security (RLS) in Azure SQL controls access to individual table rows based on user characteristics and can implement label-based access control.
Row-Level Security (RLS) in Azure SQL controls access to individual rows based on user characteristics or execution context, and can implement label-based security concepts.
Azure SQL HA and scale present tier-dependent tradeoffs: General Purpose achieves zero RPO but pays a cold-cache performance penalty on failover due to remote storage architecture, while Hyperscale achieves 128 TB scale through a distributed four-layer architecture (compute, page servers, log service, remote storage) — selecting between them requires weighing maximum storage requirements against failover performance characteristics.
Azure SQL security capabilities diverge by deployment model: SQL Database supports Network Security Perimeter while Managed Instance does not, and MI supports server-level roles that Database lacks — requiring deployment model choice based on security feature requirements.
Azure SQL Ledger provides cryptographic tamper-evidence for data integrity with immutable change records for regulatory compliance.
Azure Network Security Perimeter (preview) applies to Azure SQL Database PaaS resources but does NOT apply to SQL Managed Instance.
Network Security Perimeter (preview) creates logical network boundaries around PaaS resources but does NOT apply to SQL Managed Instance.
Deleting an Azure SQL server permanently deletes all databases (unrecoverable), but LTR backups on blob storage survive server deletion
Azure SQL Database serverless compute is available only in General Purpose and Hyperscale tiers with per-second billing
Azure SQL SLA values: SQL Database = 99.995%, Managed Instance = 99.99%, SQL VMs = 99.95% (availability set) or 99.99% (availability zones with 2 VMs).
Azure SQL Database requires Azure Private Link for private IP access; Managed Instance and SQL VMs have native private IP by default.
SQL Server on Azure VMs SLA (99.95% availability set / 99.99% availability zones) covers infrastructure only, not SQL Server processes; Always On AGs must be implemented separately for database-level HA.
Customer-managed keys (CMK) for TDE can be configured at server level or individual database level via Azure Key Vault.
Transparent Data Encryption (TDE) is enabled by default on all newly created Azure SQL databases.
Azure SQL Database full and differential backups are compressed (3-4x ratio), but transaction log backups are NOT compressed when TDE is enabled.
Azure SQL databases with TDE (Transparent Data Encryption) enabled do not compress transaction log backups.
Azure SQL Database has three encryption layers: TLS (in motion), TDE (at rest), Always Encrypted (in use)
Azure SQL Database provides defense-in-depth data protection through three complementary mechanisms operating at different granularities: three encryption layers (TLS in-motion, TDE at-rest, Always Encrypted in-use) protect data at every lifecycle state, ledger provides cryptographic tamper-evidence with immutable change records for regulatory compliance, and row-level security controls access to individual rows based on user characteristics without application changes.
Azure SQL is a family of three products: Azure SQL Database (PaaS DBaaS), Azure SQL Managed Instance (PaaS), and SQL Server on Azure VMs (IaaS).
TLS is always enforced on Azure SQL (ForceEncryption=Yes); connections without encryption are not possible.
Do NOT set TrustServerCertificate=True in production — it disables protection against man-in-the-middle attacks; use Encrypt=True;TrustServerCertificate=False.
Azure SQL Database has two purchasing models: vCore (independent resource selection, Azure Hybrid Benefit) and DTU (bundled compute/memory/IO)
SQL Server on Azure VMs SLA (99.95%/99.99%) covers infrastructure only — it does not cover SQL Server processes; Always On AGs must be implemented separately for database-level HA.
SQL Server on Azure VMs supports up to 256 TB of storage.
Windows authentication (Kerberos) for Entra principals is available only on SQL Managed Instance, not SQL Database.
In Azure portal, setting workload environment to "Development" defaults backup redundancy to LRS; "Production" defaults to GRS.
Azure SQL Database zone-redundant deployment is available for Premium and Business Critical tiers only
Azure Blob Storage minimum retention periods: Cool = 30 days, Cold = 90 days, Archive = 180 days; early deletion penalties are prorated.
Azure Blob Storage access tiers (Hot, Cool, Cold, Archive) apply only to block blobs, not append or page blobs.
Azure Blob Storage Archive tier cannot be set as the default account access tier; new GPv2 accounts default to Hot.
Azure Blob Storage archived blob metadata remains readable and index tags can be read/written; metadata access is charged at cool tier rates.
Azure Blob Storage Archive tier metadata remains read-only accessible without rehydration; blob index tags can be read or written, but snapshots are not supported for archived blobs.
Azure Blob Storage Archive tier metadata remains read-only accessible and blob index tags can be read or written, but snapshots are not supported for archived blobs.
Azure Blob Storage Archive tier metadata remains read-only accessible, but snapshots are not supported for archived blobs.
Azure Blob Storage Archive tier supports only LRS, GRS, and RA-GRS redundancy — not ZRS, GZRS, or RA-GZRS.
Azure Blob Storage Archive tier rehydration can take up to 15 hours (standard or high priority); archived blobs cannot be read or modified without rehydration.
Azure Blob Storage snapshots are not supported for archived blobs.
Azure Blob Storage Archive tier is offline; blobs cannot be read or modified without rehydration (up to 15 hours).
Using Copy Blob avoids early deletion penalty (source blob remains); Set Blob Tier on a blob before minimum retention triggers the penalty.
Changing Azure Blob Storage default account tier to a cooler tier charges write operations for all inferred-tier blobs; changing to a warmer tier charges read operations plus data retrieval.
Changing Azure Storage account default tier to a cooler tier charges write operations for all inferred-tier blobs; changing to a warmer tier charges read operations and data retrieval.
Changing the default account access tier to a cooler tier charges write operations for all inferred-tier blobs; changing to a warmer tier charges read operations and data retrieval.
Azure Blob Storage blobs using encryption scopes cannot be archived via Set Blob Tier.
Azure Blob Storage blobs using encryption scopes cannot be archived via Set Blob Tier.
Azure Blob Storage last access time tracking updates are billed as "other transactions" at most once every 24 hours per object.
Last access time tracking updates are billed as "other transactions" at most once per 24 hours per object.
Azure Blob Storage lifecycle delete actions do not work on blobs in immutable containers.
Azure Blob Storage lifecycle policies cannot archive blobs that use an encryption scope.
Lifecycle delete actions do not work on blobs in immutable containers.
Lifecycle delete actions do not work on blobs in immutable containers.
Last access time tracking updates are billed as "other transactions" at most once every 24 hours per object.
Last access time tracking updates are billed as "other transactions" at most once per 24 hours per object.
Azure Blob Storage lifecycle management policies cannot rehydrate blobs from the Archive tier.
Each lifecycle rule supports up to 10 case-sensitive prefix filters and 10 blob index tag conditions, combined with logical AND (no exclusion mechanism).
Lifecycle policy runs can be monitored by subscribing to the LifecyclePolicyCompleted event.
Lifecycle policies cannot rehydrate blobs from archive tier to an online tier.
Azure Blob Storage lifecycle management policies must be read or written in full — partial updates are not supported.
Blob lifecycle management policies must be read or written in full — partial updates are not supported.
Azure Blob Storage lifecycle management policies must be read or written in full — partial updates are not supported.
Azure Blob Storage lifecycle management policy changes take up to 24 hours to take effect and begin first execution.
Blob lifecycle policy changes take up to 24 hours to go into effect.
Azure Blob Storage lifecycle management policy changes take up to 24 hours to take effect and begin first execution.
Azure Blob Storage lifecycle management policies are free of charge; billing applies only for underlying Set Blob Tier API calls and transaction costs, and delete operations are free.
Azure Blob Storage lifecycle management policies must be read or written in full; partial updates are not supported.
Azure Blob Storage lifecycle management policies must be read or written in full — partial updates are not supported.
Recommended lifecycle policy deletion procedure: disable all rules first, wait 24 hours, then delete the policy.
Lifecycle policies never affect system containers ($logs, $web).
Lifecycle tier transitions apply only to block blobs; tiering is not supported for append blobs, page blobs, or premium block blob accounts.
All Azure Blob Storage online access tiers (Hot, Cool, Cold) share the same millisecond first-byte latency; only Archive tier has latency measured in hours.
All Azure Blob Storage online tiers (Hot, Cool, Cold) share the same millisecond first-byte latency; only Archive has hours-level latency.
Azure Premium block blob storage accounts cannot tier to hot/cool/cold/archive via Set Blob Tier or lifecycle management.
Azure Premium block blob storage accounts cannot tier blobs to hot/cool/cold/archive via Set Blob Tier or lifecycle management.
Azure Blob Storage Smart tier automatically moves data between hot, cool, and cold tiers based on usage patterns.
Azure Blob Storage provides client libraries for .NET, Java, Node.js, Python, and Go.
Azure Blob Storage supports SFTP and NFS 3.0 protocols in addition to HTTP/HTTPS.
Azure Blob Storage is Microsoft's object storage solution for unstructured data (text and binary).
Azure Blob Storage availability SLAs: Hot = 99.9%, Cool/Cold = 99%, Archive = 99%; with RA-GRS: Hot = 99.99%, others = 99.9%.
Azure Blob Storage tier changes from warmer to cooler are billed as write operations to the destination; cooler to warmer are billed as read operations plus data retrieval from the source.
Moving a blob to a cooler tier is billed as a write operation to the destination tier; moving to a warmer tier is billed as a read operation from the source tier.
Each Azure Blueprint artifact must be ≤ 2 MB in size.
Azure Blueprint objects are backed by Cosmos DB, globally replicated for low latency and high availability.
Blueprint objects are stored in Azure Cosmos DB and globally replicated for low latency and high availability.
Blueprint Contributor can manage blueprint definitions but cannot assign them; Blueprint Operator can assign blueprints but cannot create definitions.
Blueprint Contributor can manage blueprint definitions but cannot assign them; Blueprint Operator can assign blueprints but cannot create or modify definitions.
Azure Blueprints (Preview) is deprecated on July 11, 2026; successor services are Template Specs (definition storage) and Deployment Stacks (lifecycle management).
Azure Blueprints supports four artifact types: Resource Groups, ARM templates, Policy Assignments, and Role Assignments.
Blueprint naming limits: definition name max 48 characters, version max 20 characters, assignment name max 90 characters.
Blueprint-level parameters can only be created via REST API, not the Azure portal.
Unlike ARM templates, Azure Blueprints maintain a persistent relationship between definition and assignment, enabling audit and tracking of deployed resources.
Key differentiator from ARM templates: Blueprints maintain a persistent relationship between definition and assignment for tracking and auditing; ARM templates have no post-deployment connection.
System-assigned managed identity for blueprint deployment requires Owner role on the target subscription; user-assigned managed identity only requires blueprintAssignments/write.
System-assigned managed identity for Blueprint deployment requires the Owner role on the target subscription; user-assigned managed identity only requires blueprintAssignments/write.
A subnet's address range cannot be changed while resources are deployed in it — resources must be moved or deleted first.
A subnet cannot be deleted while it contains resources — all resources must be removed first.
The Microsoft Cloud Security Benchmark provides the control framework that underpins WAF Security pillar guidance.
The AKS cluster autoscaler checks the Metrics API server every 10 seconds and requires RBAC-enabled AKS running Kubernetes 1.10.x+.
The cluster autoscaler schedules node deletion after nodes are unused for 10 minutes (default threshold).
Container supply chain from ACR to AKS runtime can achieve full network isolation: ACR Premium gates content trust and private endpoints while AKS verifies images via Notary V2 and Trusted Launch — and both connect through Private Link's backbone-only routing with per-resource private DNS zones eliminating public internet traversal.
Azure container supply chain verification spans two services: ACR (Premium tier required for content trust and geo-replication) provides image signing and scanning, while AKS provides Notary V2 image verification and Trusted Launch for node integrity.
Azure Data Lake Storage Gen2 is not a separate service; it is a capability of Blob Storage with hierarchical namespace enabled.
Microsoft Defender for Cloud covers multi-cloud workloads across Azure, AWS, and GCP — not Azure-only.
Azure Elastic SAN supports only LRS and ZRS redundancy options — no geo-redundant options.
The Microsoft Entra admin center is accessible at https://entra.microsoft.com.
An application in Microsoft Entra ID can be temporarily deactivated to prevent new token issuance while preserving both the application object and service principal.
An application can be temporarily deactivated to prevent new token issuance without deleting the application object or service principal.
An application can be deactivated to prevent new token issuance without deleting the application object or service principal.
Changes to an application object are reflected only in the home tenant's service principal, not in service principals in other tenants.
Changes to an application object are reflected only in the home tenant's service principal, not in service principals in other tenants.
The application object is the global representation of an application; the service principal is the local representation per tenant.
An application object has a one-to-many relationship with service principals: one app object in the home tenant, one service principal per tenant where the app is used.
Application objects are managed under App registrations; service principals are managed under Enterprise applications in the Entra admin center.
Application objects are managed under the App registrations page; service principals are managed under the Enterprise applications page in the Entra admin center.
Entra application identity requires a two-object model: application objects (managed via App registrations) define the app globally, while service principals (managed via Enterprise applications) instantiate per-tenant access — a service principal must exist in each tenant for sign-in, and the portal auto-creates both objects simultaneously, masking this distinction until multi-tenant scenarios surface it.
Azure AD B2C is end-of-sale for new customers as of May 1, 2025.
Deleting an application object deletes the home tenant service principal; restoring the app via App Registrations does NOT restore the service principal.
When a Microsoft Entra user is deleted, their assigned licenses are freed and become available for other users.
Deleted users in Microsoft Entra ID are soft-deleted and recoverable for 30 days.
Microsoft Entra Domain Services provides managed Kerberos, NTLM, LDAP, and Group Policy services — no domain controllers to maintain.
Dynamic group membership processes all organization-wide rules when any user or device attribute changes, not just rules relevant to the changed attribute.
When any user or device attribute changes, Microsoft Entra re-evaluates all dynamic group membership rules across the entire organization.
Dynamic group membership processes all org-wide dynamic group rules when any user or device attribute changes — not just rules for the affected group.
External guests cannot be assigned to administrative units in Microsoft Entra ID.
Microsoft Entra External ID manages both B2B collaboration (partners/guests) and B2C/CIAM (customer-facing apps) with self-service registration, social login, and one-time passcodes.
Microsoft Entra External ID supports both B2B collaboration (partners/guests) and B2C/CIAM (customer-facing apps with self-service registration and social login).
External members in Microsoft Entra ID authenticate via federation to their home tenant, while internal users have credentials managed directly in the local tenant.
External users in external tenants (Entra External ID) cannot be assigned to administrative units or roles at creation.
Microsoft Entra ID workforce tenants have four user types: internal member, internal guest, external member, and external guest.
Groups Administrator or User Administrator role is required to manage Entra groups; Privileged Role Administrator is required to enable role assignment on groups.
Entra group membership types are: Assigned, Dynamic User, and Dynamic Device.
Microsoft Entra group names cannot start with a space — doing so prevents the group from appearing in role assignment options.
Microsoft Entra group type (Security or Microsoft 365) cannot be changed after creation — must delete and recreate.
Groups Administrator or User Administrator roles are required for group CRUD and membership management in Microsoft Entra ID.
Groups Administrator or User Administrator roles are required for group CRUD and membership management in Microsoft Entra.
Managing Entra groups requires Groups Administrator or User Administrator role; Privileged Role Administrator is required to enable role assignment on groups.
Microsoft Entra ID Governance automates the full identity lifecycle: access requests, assignments, reviews, and automatic provisioning/deprovisioning (e.g., employee onboarding/offboarding).
Microsoft Entra ID Governance automates the full identity lifecycle (joiner, mover, leaver) including access request, assignment, and review workflows.
Every Microsoft Entra ID directory gets an initial domain in the format <tenant>.onmicrosoft.com.
Microsoft Entra ID Protection (risk detection and risk-based Conditional Access) requires a P2 license.
Microsoft Entra ID Protection (risk detection and risk-based Conditional Access) requires a Microsoft Entra ID P2 license.
Microsoft Entra ID Protection detects identity-based risks and enables risk-based Conditional Access policies at low, medium, and high risk levels.
Microsoft Entra ID has its own separate set of built-in roles distinct from Azure RBAC roles.
Entra ID's dual identity model — service principals (app registrations with client credentials) and managed identities (platform-managed, no credential management) — creates a tradeoff between flexibility and operational complexity, with managed identities reducing credential management overhead.
Azure identity-to-authorization follows a two-stage chain with distinct lifecycle and evaluation models: Entra provides identity through either a two-object app/service-principal model (manual lifecycle) or managed identities (auto-lifecycle tied to resource), then RBAC provides authorization through additive union of all role assignments evaluated against ARM scope hierarchy — identity type determines lifecycle complexity while role assignment scope determines access breadth.
Every new Entra directory gets an initial domain like contoso.onmicrosoft.com; custom domains can be added afterward.
Every new Entra directory gets an initial domain in the format <name>.onmicrosoft.com; custom domains can be added afterward.
Microsoft Entra Internet Access replaces traditional web proxies by securing access to internet and SaaS resources with web content filtering by category and domain; it is part of Global Secure Access alongside Private Access.
Microsoft Entra Internet Access secures access to internet resources, SaaS apps, and Microsoft 365 with features like web content filtering.
Microsoft Entra Internet Access secures access to internet resources, SaaS apps, and Microsoft 365 with features like web content filtering.
Microsoft Entra is a product family spanning identity, governance, protection, and network access — not a single product. Entra ID (formerly Azure AD) is the foundational IAM product within it.
Legacy service principals have no associated app registration and are only usable in the tenant where they were created.
Microsoft 365 is the only Entra group type that supports a group email address.
When users are added to a Microsoft 365 group, a welcome email is sent automatically; it can be disabled using the Set-UnifiedGroup cmdlet in Exchange PowerShell.
Welcome emails are sent automatically when users are added to Microsoft 365 groups; they can be disabled using the Set-UnifiedGroup cmdlet in Exchange PowerShell.
For App Service deployment slots, the system-assigned managed identity service principal name follows the format <app-name>/slots/<slot-name>.
Managed identity service principals have no associated application object and cannot be updated or modified directly.
The managed identity workflow is: create/enable identity, assign it to compute resource, grant RBAC roles on target service, use Azure.Identity or MSAL SDK in code to acquire tokens — no secrets needed.
Admin consent for a multitenant app in a consumer tenant creates a service principal in that consumer tenant.
In multitenant scenarios, a service principal is created in a consumer tenant when an admin or user grants consent; single-tenant apps have a service principal only in the home tenant.
Nested groups cannot: add security groups to M365 groups, add M365 groups to security/M365 groups, add on-prem synced groups, add groups to role-assignable groups; nested groups do not inherit shared resource/app access; licenses cannot be applied to nested security groups.
Nested groups inherit Conditional Access policy scopes and membership, but do NOT inherit shared resource or application access.
Nested groups (group within a group) are supported for security groups only, not Microsoft 365 groups.
Groups synced from on-premises Active Directory to Entra ID cannot have other groups added to them as members.
Registering an app via the Azure portal auto-creates both the application object and the service principal; via Microsoft Graph APIs, creating the service principal is a separate step.
Microsoft Entra Private Access replaces VPN by securing access to private apps and corporate networks from any device or network.
The Privileged Authentication Administrator role can delete any user including other admins; the User Administrator role cannot delete admin users.
Role-assignable groups in Microsoft Entra require a P1 or P2 license and the Privileged Role Administrator role, and are locked to Assigned membership type.
A service principal must exist in a tenant for an application to sign in or access resources in that tenant.
Users synced from on-premises AD to Entra ID must be modified in Windows Server AD, not in Entra; changes require waiting for the next sync cycle.
A system-assigned managed identity's service principal name matches the Azure resource name; for deployment slots the format is <app-name>/slots/<slot-name>.
Every Microsoft 365, Office 365, Azure, and Dynamics CRM Online tenant is automatically a Microsoft Entra tenant.
Microsoft Entra ID has three types of service principals: Application, Managed Identity, and Legacy.
Up to 20 groups or roles can be assigned at user creation; only one administrative unit can be assigned.
User type (Member vs Guest) determines privilege level, not whether the account is internal or external.
Microsoft Entra Verified ID is a decentralized identity (DID) credential verification service based on open standards where the user controls their credentials.
Microsoft Entra Workload ID provides IAM for non-human identities: applications, services, containers, and CI/CD pipelines.
Event Grid returns HTTP 413 Payload Too Large when event or event array size exceeds the 1 MB limit.
CloudEvents input schema cannot be transformed to Event Grid output format because CloudEvents supports extension attributes that Event Grid schema does not; Event Grid input can output either format.
Azure Event Grid supports CloudEvents 1.0 in Structured JSON content mode only; Binary content mode is not supported.
When using managed identity to deliver Event Grid events to Event Hubs, the identity needs the Event Hubs Data Sender RBAC role.
Events must always be published to Event Grid as a JSON array, even when sending a single event.
Events must always be published to Event Grid in a JSON array, even for a single event.
Azure Event Grid maximum event size is 1 MB; events over 64 KB are charged in 64 KB increments.
Event Grid maximum event size is 1 MB; events over 64 KB are charged in 64 KB increments (e.g., a 130 KB event is charged as 3 operations).
Event Grid schema metadataVersion is currently only version 1; Event Grid stamps it if omitted.
Publishing events to Event Grid requires SAS token or key authentication.
Azure Event Grid returns 413 Payload Too Large when the event array exceeds the 1 MB size limit.
The Event Grid event schema is proprietary and nonextensible; Microsoft recommends migrating to CloudEvents format, though Event Grid schema is not being retired.
Event Grid proprietary schema is not being retired but will receive no major improvements; CloudEvents is the recommended format.
Event Grid schema required properties are: subject, eventType, eventTime, id, and data; topic is optional (Event Grid stamps it if omitted).
Event Grid schema required properties are: subject, eventType, eventTime, id, and data; topic is optional (Event Grid stamps it if omitted).
Event Grid supports path-based filtering on the subject field (e.g., /A/B/C) and suffix filtering (e.g., .txt) for event routing.
Event Grid supports path-based filtering on the subject field (e.g., /A/B/C) and suffix filtering (e.g., .txt) for event routing.
Event Grid supports path-based filtering on the subject field (e.g., /A/B/C for narrow, /A for broad) and suffix filtering (e.g., .txt), enabling flexible event routing.
Event Grid event subscriptions support filtering by event type and subject, and can have an expiration time for automatic cleanup.
Event Grid event subscriptions can have an expiration time set for automatic cleanup of temporary subscriptions.
Azure Event Grid leverages Azure availability zones for regional high availability and fault tolerance.
Event Grid has three topic types: custom topics (user-created), system topics (built-in from Azure services), and partner topics (from external SaaS/ERP providers via Partner Events).
An Azure Event Hub is an append-only distributed log, equivalent to a Kafka topic; partitions are ordered sequences of events within an event hub.
Azure Event Hubs authentication options include Microsoft Entra ID (RBAC), Shared Access Signatures (SAS), and Managed Identities.
Azure Event Hubs auto-inflate only scales throughput units upward, never downward.
Event Hubs Auto-inflate automatically scales throughput units upward to prevent throttling but does not scale down.
Azure Event Hubs availability zone support is available on Premium and Dedicated tiers only.
Event Hubs Capture archives streaming data to Azure Blob Storage or Data Lake Storage in Avro format (default) or Parquet (via no-code editor).
Event Hubs Capture supports Avro (default) and Parquet (via no-code editor) formats for archival to Blob Storage or Data Lake.
Azure Event Hubs Capture automatically writes streaming data in near-real-time to Azure Blob Storage or Azure Data Lake Storage for long-term retention.
Event Hubs checkpointing (saving current offset for resumption/failover) is the consumer's responsibility, not the service's; best practice is Azure Blob Storage with a separate container per consumer group.
Event Hubs enforces isolated ordered processing through two complementary mechanisms: consumer groups provide independent position tracking where each group maintains its own offset cursor in the partition log, while epoch-based ownership within each group ensures single-owner-per-partition exclusivity by evicting lower-epoch consumers, together preventing both cross-group interference and within-group split-brain concurrent processing.
Event Hubs supports cross-protocol reading and writing: produce via Kafka and consume via AMQP (or vice versa) on the same event hub.
Event Hubs supports cross-protocol reading: produce via Kafka and consume via AMQP, or vice versa.
Event Hubs default consumer group is named $Default; each consumer group independently tracks its own position in the event stream.
Event Hubs delivery guarantee is at-least once; consumers should implement the idempotent consumer pattern for exactly-once semantics.
Sending directly to a specific Event Hubs partition is discouraged because it downgrades availability to partition-level.
Azure Event Hubs encrypts data at rest with Microsoft-managed or customer-managed keys and enforces TLS 1.2 for data in transit.
Event Hubs epoch consumers allow only one owner per partition per consumer group; a higher epoch evicts the lower epoch consumer.
Event Hubs epoch consumers allow only one owner per partition per consumer group; a higher epoch evicts lower epoch consumers.
Epoch consumers allow only one owner per partition per consumer group (higher epoch evicts lower); non-epoch consumers allow up to 5 concurrent readers per partition; an epoch consumer connecting disconnects all non-epoch consumers.
Events in Event Hubs cannot be explicitly deleted; removal is automatic based on the configured retention policy.
Up to 5 non-epoch consumers can read the same Event Hubs partition concurrently; connecting an epoch consumer disconnects all non-epoch consumers on that partition.
Event Hubs provides complete Kafka interoperability: existing Kafka workloads run without code changes, cross-protocol produce/consume is supported (Kafka in, AMQP out or vice versa), and the native AMQP/Kafka/HTTPS protocol stack eliminates the need for a separate Kafka cluster.
Azure Event Hubs Geo-DR provides metadata synchronization and failover to a secondary region.
Event Hubs HTTPS protocol supports send (publish) only — no receive capability; AMQP is used by SDKs for high-throughput bidirectional scenarios.
Exceeding Event Hubs ingress capacity throws an EventHubsException with ServiceBusy reason; exceeding egress capacity is silently capped without exceptions.
Exceeding Event Hubs ingress capacity throws EventHubsException with ServiceBusy reason; exceeding egress capacity is silently capped without exceptions.
Event Hubs Kafka delivery semantic is at-least once; consumers should implement the idempotent consumer pattern.
Event Hubs Kafka compression supports only gzip and is available only in Premium and Dedicated tiers; AMQP consumers can read compressed Kafka traffic as decompressed messages.
Event Hubs Kafka endpoint supports only gzip compression, available in Premium and Dedicated tiers only.
Event Hubs Kafka compression supports only gzip, available in Premium and Dedicated tiers only.
Event Hubs supports cross-protocol reading and writing: produce via Kafka and consume via AMQP, or vice versa.
Azure Event Hubs Kafka endpoint delivery semantic is at-least-once; consumers should implement the idempotent consumer pattern.
Event Hubs Kafka migration scope is tier-determined: full protocol interoperability (no code changes, cross-protocol produce/consume) requires Standard+, while advanced features (Kafka Streams, Transactions, gzip compression) require Premium/Dedicated — making tier selection a prerequisite constraint that must be resolved before scoping any Kafka migration plan.
Existing Apache Kafka workloads can run on Azure Event Hubs without code changes or cluster management.
Event Hubs Kafka endpoint support is available only in Standard, Premium, and Dedicated tiers — not available on Basic.
Event Hubs Kafka endpoint uses SASL mechanism OAUTHBEARER for OAuth 2.0 and PLAIN with username="$ConnectionString" for SAS authentication.
Event Hubs Kafka endpoint uses port 9093 with mandatory TLS encryption (SASL_SSL); OAuth uses OAUTHBEARER mechanism, SAS uses PLAIN mechanism with username="$ConnectionString".
Event Hubs Kafka endpoint uses port 9093 with mandatory TLS encryption (SASL_SSL).
Event Hubs Kafka support requires Standard, Premium, or Dedicated tier — not available on Basic.
Event Hubs SAS connections are not disconnected when the SAS key is regenerated.
SAS connections to the Event Hubs Kafka endpoint are not disconnected when the SAS key is regenerated.
Kafka Streams on Event Hubs is in public preview, available only in Premium and Dedicated tiers; ksqlDB is not available due to Confluent licensing.
Kafka Streams and Kafka Transactions on Event Hubs are in public preview and available only in Premium and Dedicated tiers.
Azure Event Hubs Standard tier allows a maximum of 40 throughput units per namespace, shared across all event hubs in the namespace.
Up to 5 non-epoch consumers can read the same Event Hubs partition concurrently; connecting an epoch consumer disconnects all non-epoch consumers on that partition.
The number of partitions in an Event Hub equals the maximum number of parallel consumers per consumer group.
Event Hubs maximum publish size is 1 MB per operation (batch or individual event).
Azure messaging services comparison: Event Hubs for streaming/telemetry, Service Bus for enterprise messaging with transactions and sessions, Event Grid for reactive serverless event routing.
Event Hubs non-epoch consumers allow up to 5 concurrent readers per partition; an epoch consumer connecting disconnects all non-epoch consumers.
Azure Event Hubs is a fully managed PaaS real-time data streaming platform that ingests millions of events per second with low latency.
Event Hubs partition count cannot be decreased in any tier; in Standard/Basic tiers it cannot be changed at all after creation; Premium/Dedicated tiers allow increases only.
Event Hubs pricing depends on throughput/processing/capacity units, not on partition count.
Event Hubs partition key is hashed to determine partition assignment; if omitted, events are distributed round-robin across partitions.
Event Hubs partition keys use a static hashing function to assign events to partitions; without a key, round-robin assignment is used.
Event Hubs partition keys use a static hashing function to assign events to partitions; without a partition key, round-robin assignment is used. Sending directly to a partition is discouraged as it downgrades availability to partition-level.
Event Hubs partition keys use a static hashing function to assign events to partitions; without a key, round-robin assignment is used.
Event Hubs partitioning is a free architectural decision with deterministic routing: partition count has no pricing impact (billing depends solely on throughput/processing/capacity units), partition keys use static hashing for consistent event-to-partition assignment, and the delivery guarantee is at-least-once regardless of partition configuration — making partition count purely a throughput and ordering design choice.
The number of Event Hubs partitions equals the maximum number of parallel consumers per consumer group, for both AMQP epoch consumers and Kafka consumers.
Event Hubs Premium tier processing units (PUs) are available in discrete values: 1, 2, 4, 6, 8, 10, 12, or 16 per namespace.
Azure Event Hubs Premium tier processing unit (PU) options are discrete values: 1, 2, 4, 6, 8, 10, 12, or 16 per namespace.
Azure Event Hubs Premium tier processing unit (PU) options are discrete: 1, 2, 4, 6, 8, 10, 12, or 16 per namespace.
Event Hubs follows a progressive tier model: Standard provides base functionality, Premium adds Kafka protocol support with configurable processing units, and higher tiers enable additional enterprise capabilities.
Azure Event Hubs natively supports three protocols: AMQP 1.0, Apache Kafka (1.0+), and HTTPS.
Azure Event Hubs Standard tier supports up to 7-day data retention; Premium and Dedicated tiers support up to 90-day retention.
Event Hubs event retention: Standard tier default 1h / max 7 days; Premium and Dedicated default 1h / max 90 days.
Event Hubs event retention maximum is 7 days for Standard tier and 90 days for Premium and Dedicated tiers; default is 1 hour across all tiers.
Event Hubs SAS connections are not disconnected when the SAS key is regenerated; generated SAS tokens are not supported on the Kafka endpoint — only connection strings.
Azure Event Hubs Schema Registry supports Avro and JSON schema formats for centralized schema management across producers and consumers.
Event Hubs uses a single virtual IP as its endpoint rather than per-broker endpoints, simplifying firewall rules compared to self-managed Kafka.
Azure Event Hubs SLA is up to 99.99% depending on tier and configuration.
Azure Event Hubs Standard tier supports up to 7-day data retention; Premium and Dedicated tiers support up to 90-day retention.
One Event Hubs throughput unit (TU) provides up to 1 MB/s or 1,000 events/s ingress and up to 2 MB/s or 4,096 events/s egress; max 40 TUs per Standard tier namespace.
Azure Event Hubs natively supports three protocols: AMQP 1.0, Apache Kafka, and HTTPS.
Event Hubs has three data-plane RBAC roles: Data Owner (full), Data Sender (send only), and Data Receiver (receive only).
Azure Event Hubs has three pricing tiers: Standard, Premium, and Dedicated, differing in retention, features, and SLA.
One Event Hubs throughput unit (TU) provides up to 1 MB/s (or 1,000 events/s) ingress and up to 2 MB/s (or 4,096 events/s) egress — limits are asymmetric.
Event Hubs is for streaming/telemetry (append-only log), Service Bus is for enterprise messaging with transactions/sessions/dead-lettering, Event Grid is for reactive push-based event routing with server-side filtering.
ExpressRoute requires BGP for route exchange; VPN gateways can optionally use BGP.
FTL2 calls Ansible Azure collection modules directly in-process (no subprocess fork), achieving 3-17x speedup over ansible-playbook.
FTL2 auto-installs Azure SDK pip packages (azure-mgmt-*) via autoinstalldeps=True when missing.
FTL2 calls Azure Ansible collection modules directly in-process (no subprocess fork), achieving 3-17x speedup over ansible-playbook.
The FTL2 Azure example script is located at ~/git/faster-than-light2/examples/07-azure/exampleazureweb_stack.py.
FTL2 accesses Azure modules via FQCN pattern: await ftl.azure.azcollection.azurermresourcegroup(...).
FTL2 accesses Azure modules via FQCN pattern: await ftl.azure.azcollection.azurermresourcegroup(...).
FTL2 accesses Azure modules via Ansible FQCN pattern: azure.azcollection.azurerm* — it has no native Azure modules.
FTL2 injects Azure credentials (clientid, secret, subscriptionid, tenant) via glob pattern matching on azure.azcollection.* so scripts never handle raw credentials.
FTL2 secret bindings inject Azure credentials (clientid, secret, subscriptionid, tenant) automatically via glob pattern matching on azure.azcollection.* modules.
FTL2 Azure teardown pattern: delete the resource group with state="absent", forcedeletenonempty=True to remove all contained resources.
FTL2 calls Ansible modules directly in-process (no subprocess fork), achieving 3-17x speedup over ansible-playbook.
FTL2 does not have native Azure modules; all Azure calls go through Ansible module machinery via the azure.azcollection collection.
FTL2 does not have native Azure modules; all Azure calls go through Ansible module machinery via the azure.azcollection collection.
FTL2 secret bindings inject Azure credentials (clientid, secret, subscriptionid, tenant) automatically via glob pattern matching so scripts never see raw credentials.
FTL2 tracks state via .ftl2-state.json enabling idempotent provisioning with crash recovery and provider filtering.
Azure Functions Linux Consumption plan is retiring September 30, 2028; no new features/language versions after September 30, 2025. Migrate to Flex Consumption.
Azure Functions Consumption plan has a default timeout of 5 minutes and a maximum of 10 minutes; all other plans default to 30 minutes with unbounded maximum.
Azure Functions Consumption plan timeout defaults to 5 minutes with a maximum of 10 minutes; all other plans default to 30 minutes with unbounded maximum.
Azure Functions custom handlers enable any language that can receive HTTP requests to run as a function
Azure Functions custom handlers enable any language that can receive HTTP requests to be used as a function runtime.
Durable Functions is an extension for building stateful, event-driven serverless workflows in Azure Functions
Durable Functions is an Azure Functions extension for building stateful, event-driven serverless workflows and orchestrations.
Azure Functions offers five hosting plans: Flex Consumption, Premium, Dedicated (App Service), Container Apps, and Consumption.
Azure Functions natively supports five programming languages: C#, Java, JavaScript, PowerShell, and Python; other languages (Rust, Go) are supported via custom handlers.
Azure Functions Flex Consumption plan supports Linux only.
Azure Functions Flex Consumption plan scales up to 1000 instances with per-function scaling, configurable memory (512/2048/4096 MB), and Linux only.
Flex Consumption subnets cannot contain underscores in their names
Azure Functions Flex Consumption plan uniquely supports per-function scaling where different trigger types scale independently on separate instances (HTTP grouped together, Blob/Event Grid grouped, Durable grouped).
Azure Functions Flex Consumption routes all outbound traffic through the VNet by default (no Route All setting needed), unlike other plans.
Azure Functions Flex Consumption requires planning for 40 IP addresses per function app regardless of actual instance count; recommended subnet size is /27.
Azure Functions Flex Consumption subnet delegation is Microsoft.App/environments, different from Premium/Dedicated plans.
Azure Functions Flex Consumption subnets cannot contain underscores in their names.
Flex Consumption recommended subnet size is /27, planning for 40 IP addresses per function app regardless of actual instance count
Gateway-required VNet integration is only supported on the Dedicated (App Service) plan
Gateway-required VNet integration is only supported on the Dedicated (App Service) plan
Azure Functions HTTP triggers have a 230-second response time hard limit on ALL hosting plans due to Azure Load Balancer; use Durable Functions async pattern for longer processing.
HTTP triggers on Azure Functions are capped at 230 seconds response time across ALL hosting plans due to the Azure Load Balancer idle timeout.
Azure Functions Hybrid Connections (Azure Relay) are Windows only, not supported on Consumption plan or Linux.
Maximum of 5,000 function apps per Azure subscription across all hosting plans.
Azure Functions has a maximum of 5,000 function apps per subscription across all hosting plans.
Azure Functions Consumption plan does not support private endpoints, VNet integration, or outbound IP restrictions
Azure Functions Consumption plan does not support private endpoints, VNet integration, or outbound IP restrictions
Flex Consumption routes all outbound traffic through VNet by default without needing Route All configuration
Flex Consumption function apps use subnet delegation Microsoft.App/environments, which differs from Premium/Dedicated plans
Flex Consumption recommended subnet size is /27, planning for 40 IP addresses per function app regardless of actual instance count
Azure Functions Hybrid Connections (Azure Relay) are Windows only and not supported on Consumption plan or Linux
NSGs on a VNet integration subnet affect outbound traffic only; inbound rules do not apply because VNet integration is outbound-only
NSGs on Azure Functions VNet integration subnets affect outbound traffic only; inbound rules do not apply because VNet integration is outbound-only
Premium/Dedicated function apps: recommended subnet is /24 for Windows, /26 for Linux; each instance consumes 1 IP, usage can temporarily double during scaling
Virtual network triggers (non-HTTP) require either Flex Consumption or Premium plan with Runtime Scale Monitoring enabled for dynamic scaling
No Azure Functions hosting plan supports Windows containers; only Linux containers are supported (on Premium, Dedicated, and Container Apps).
NSGs on Azure Functions VNet integration subnet affect outbound traffic only; inbound rules do not apply because VNet integration is outbound-only.
Azure Functions Premium/Dedicated recommended subnet size is /24 for Windows and /26 for Linux; each instance consumes 1 IP and usage can temporarily double during scaling
Azure Functions Premium/Dedicated plans: each instance consumes 1 IP (can temporarily double during scaling); recommended subnet /24 for Windows, /26 for Linux.
Azure Functions Python runtime requires Linux — no Windows support.
Azure Functions has three main hosting options: Consumption (pay-per-execution, fully serverless), Premium (pre-warmed, fastest response), and Dedicated/App Service (predictable scaling and cost)
Non-HTTP virtual network triggers on Azure Functions require Flex Consumption or Premium plan with Runtime Scale Monitoring enabled for dynamic scaling.
Azure Functions VNet integration is NOT available on the Consumption plan; it is available on Flex Consumption, Premium, Dedicated, and Container Apps plans.
Azure Functions VNet integration is NOT available on the Consumption plan; it is available on Flex Consumption, Premium, Dedicated, and Container Apps.
A dedicated GatewaySubnet is required within the VNet for VPN gateway deployments.
HPA checks the Metrics API every 15 seconds, but the Metrics API refreshes from Kubelet every 60 seconds, making the effective update interval 60 seconds.
HPA has no delay for scale-up events since Kubernetes 1.12; the default scale-down cooldown is 5 minutes.
HPA has no delay for scale-up events since Kubernetes 1.12; default scale-down delay is 5 minutes.
HPA default scale-down delay is 5 minutes; there is no delay for scale-up events since Kubernetes 1.12.
Kubernetes is not safe for hostile multitenant workloads; the security domain is the entire cluster, not individual nodes. Physically isolated clusters are required for true isolation.
Kubernetes persistent volume (PV) to persistent volume claim (PVC) binding is 1:1 — each PVC binds to exactly one PV.
Kubernetes Secret manifest files contain data in base64 format (encoding, not encryption) and should never be committed to source control.
Kubernetes secret volumes use tmpfs and are never written to disk; they are namespace-scoped
Kubernetes Secrets are stored in tmpfs (not written to disk), are namespace-scoped, and are deleted when the last requiring pod is removed.
KEDA uses a CRD called ScaledObject and scales based on event count rather than resource utilization metrics.
Best practice is one Key Vault per application per environment (Dev, Pre-Prod, Prod) to reduce blast radius.
Access control for Key Vault certificates is separate from access control for keys and secrets in the same vault.
Creating a Key Vault certificate automatically creates an addressable key and an addressable secret with the same name.
Certificate issuer objects in Key Vault are vault-scoped and cannot be shared across vaults.
Certificates should be stored as Key Vault certificate objects (not secrets) to enable autorotation
Certificates should be stored as Key Vault certificate objects (not secrets) to enable autorotation
Certificates should be stored as Key Vault certificate objects (not secrets) to enable autorotation.
Key Vault Contributor role is control plane only and does NOT grant access to keys, secrets, or certificates.
Key Vault control plane endpoint is management.azure.com:443; data plane endpoint is <vault-name>.vault.azure.net:443.
Key Vault Crypto User role can create new keys but cannot delete them
Key Vault Crypto User role can create new keys but cannot delete them.
Custom roles for Key Vault data plane operations use DataActions (not Actions).
Key Vault Data Access Administrator can add/remove Key Vault role assignments with ABAC constraints but cannot change the permission model (requires Owner or User Access Administrator).
The Key Vault data plane is multitenant — multiple customer vaults can share the same public IP address.
The Key Vault data plane is multitenant — multiple customer vaults can share the same public IP address.
Key Vault provides defense-in-depth for cryptographic key lifecycle: tiered protection levels (software FIPS 140-2 L1 → asymmetric HSM → single-tenant managed HSM with symmetric keys) secure keys at appropriate cryptographic strength, while layered deletion safeguards (soft-delete → purge protection → purge operator role requirement) prevent accidental or malicious key destruction.
Key Vault encryption uses a key hierarchy where the leaf key is unique per key vault and the root key is unique per security world, protected by FIPS 140-2 Level 3+ validated modules.
The encryption leaf key for secrets at rest is unique per key vault; the root key is unique per security world.
Expired certificates can still be retrieved from Key Vault but may fail TLS validation.
Key Vault contents are automatically replicated within a region and to a secondary region with automatic failover requiring no admin action.
HSM-protected keys in Key Vault are always non-exportable; only RSA and EC key types support exportable private keys.
Key Vault HSM Platform 2 protects keys at FIPS 140-3 Level 3; all new keys and key versions use HSM Platform 2.
Key Vault keys are represented as JSON Web Key (JWK) objects following JOSE specifications.
Key Vault provides three-layer deletion protection: soft-delete enables recovery within 7–90 days, purge protection prevents permanent deletion during retention, and purge itself requires elevated privileges (Purge Operator role or subscription Owner).
Legacy Key Vault access policies have known vulnerabilities and lack PIM (Privileged Identity Management) support; Azure RBAC is preferred.
Azure Key Vault managed HSM pools are validated at FIPS 140-2 Level 3; standard vaults use FIPS 140 validated HSMs at lower levels.
Managed HSM pools are single-tenant with isolated security domains, while standard vaults are multi-tenant.
Azure Key Vault is designed so Microsoft cannot see or extract customer keys.
Key Vault is not a data store — customer configurations, service configs, and general content should use Azure Storage or Cosmos DB instead.
Object-scope RBAC assignments in Key Vault only support read operations; administrative operations require vault-level permissions.
Key Vault best practice is one vault per application, region, and environment to reduce blast radius of security events
Best practice is one Key Vault per application, per region, per environment to reduce blast radius of security events.
Only DigiCert and GlobalSign are partnered certificate issuers in Key Vault supporting automatic TLS/SSL certificate issuance and renewal.
Azure Key Vault Premium tier uses HSM-protected keys (Marvell LiquidSecurity HSMs) validated to FIPS 140-3 Level 3.
Premium HSM key types are RSA-HSM, EC-HSM, and OCT-HSM; these keys never leave the HSM boundary.
Key Vault Premium SKU is required for HSM-protected keys in vaults; Standard SKU supports only software-protected keys.
Key Vault's layered deletion protection (soft-delete, purge protection, purge RBAC) provides key lifecycle isolation, ensuring that cryptographic material cannot be permanently destroyed without satisfying multiple independent controls.
The purge permission is a privileged operation distinct from delete; purge permanently removes a soft-deleted secret.
The purge permission (permanent deletion of soft-deleted secrets) is a privileged operation distinct from delete.
Key Vault purge protection is not enabled by default, requires soft-delete to be enabled first, and prevents purging until the retention period expires.
Key Vault purge protection prevents permanent deletion of soft-deleted objects even after soft delete is enabled.
Purging a Key Vault requires the "Key Vault Purge Operator" built-in role or subscription owner privileges.
Purging a Key Vault requires the "Key Vault Purge Operator" built-in role or subscription owner privileges.
Key Vault RBAC applies only to vaults, not managed HSMs; managed HSMs have their own access control model.
RBAC object-scope assignments on Key Vault only support read operations; administrative operations require vault-level permissions.
Legacy Key Vault access policies have known security vulnerabilities and lack PIM support; Azure RBAC is the recommended permission model
Azure RBAC is preferred over legacy vault access policies for Key Vault; legacy policies have known vulnerabilities and lack PIM support.
Azure RBAC is preferred over legacy vault access policies for Key Vault; legacy policies have known vulnerabilities and lack PIM support.
Azure RBAC is the recommended Key Vault permission model; legacy access policies have known security vulnerabilities and lack PIM support.
Switching to Azure RBAC permission model immediately invalidates all existing Key Vault access policies.
Recovering a soft-deleted Key Vault does not restore Azure RBAC role assignments or Event Grid subscriptions — these must be manually recreated.
Recovering a soft-deleted Key Vault does not restore Azure RBAC role assignments or Event Grid subscriptions; these must be manually recreated.
Key Vault secret access control is per-vault (not per-secret) and is separate from key access control within the same vault.
Key Vault secret access control is per-vault (not per-secret) and is separate from key access control within the same vault.
The Key Vault secret contentType field is optional, max 255 characters, with no predefined values — it serves as a hint for interpreting secret data.
The Key Vault secret contentType field is an optional hint with a maximum length of 255 characters and no predefined values.
Key Vault encryption leaf key is unique per key vault; the root key is unique per security world, protected by FIPS 140-2 Level 3+ validated modules.
The get operation works on expired and not-yet-valid secrets, as an exception to the nbf/exp date-time controls.
The get operation works on expired and not-yet-valid secrets, as an exception to the normal date-time controls.
The get operation works on expired and not-yet-valid secrets, as an exception to the nbf/exp date-time controls.
Key Vault secrets support a maximum of 15 tags, each with a 512-character name and 512-character value; tags are readable by anyone with list or get permission.
Azure Key Vault secrets have a maximum size of 25 KB per secret.
Key Vault secrets follow a permissive read model that differs from typical access-controlled resources: the 25 KB size limit constrains stored content, the contentType field is an optional unvalidated hint (max 255 chars, no predefined values), and the get operation succeeds on both expired and not-yet-valid secrets — meaning nbf/exp date controls are advisory for reads, not enforcement boundaries.
Setting Key Vault publicNetworkAccess: SecuredByPerimeter overrides the "Allow trusted Microsoft services" firewall bypass.
Azure Key Vault soft-delete is enabled by default on new vaults and cannot be disabled once enabled.
Key Vault soft delete retention period is 7–90 days; purge protection adds a second layer preventing permanent deletion even after soft delete
Key Vault soft-delete retention period is configurable from 7 to 90 days (default 90), set at vault creation time, and cannot be changed afterward.
Key Vault soft-delete retention period is configurable from 7–90 days (default 90), set at vault creation time, and cannot be changed afterward.
Key Vault soft delete recovers deleted objects within a 7–90 day retention period; purge protection prevents permanent deletion even after soft delete.
Key Vault soft-delete retention period is configurable from 7 to 90 days (default 90), set at vault creation time and cannot be changed afterward.
A soft-deleted vault's name (and object names within a vault) cannot be reused until the retention period expires.
A soft-deleted vault's name cannot be reused until the retention period expires; same restriction applies to objects within a vault.
Only two operations are possible on soft-deleted Key Vault objects: purge and recover.
Only two operations are possible on soft-deleted Key Vault objects: purge and recover.
Software-protected keys in Key Vault are validated at FIPS 140-2 Level 1 and are only available in vaults (not Managed HSM).
Azure Key Vault Standard tier uses software-protected keys validated to FIPS 140 Level 1.
Azure Key Vault supports TLS 1.2 and TLS 1.3; clients can enforce TLS version during negotiation.
Symmetric keys (oct-HSM: 128, 192, 256-bit) are only supported in Managed HSMs, not in standard vaults.
Key Vault supports three authentication methods in order of recommendation: (1) managed identities (best practice), (2) service principal + certificate, (3) service principal + secret (not recommended).
Key Vault authentication methods in order of recommendation: (1) Managed identities (best), (2) Service principal + certificate, (3) Service principal + secret (not recommended due to bootstrap secret rotation difficulty)
Key Vault enforces a three-tier key protection model: software keys (FIPS 140-2 L1) in Standard vaults, asymmetric HSM keys in Premium vaults, and symmetric/single-tenant HSM keys exclusively in Managed HSM pools.
Azure Key Vault supports TLS 1.2 and 1.3; clients can enforce TLS version during negotiation.
Key Vault has two authorization models: Azure RBAC (management + data plane) and Key Vault access policies (data plane only, legacy).
Azure Key Vault has two container types: vaults (keys, secrets, certificates) and managed HSM pools (HSM-backed keys only).
Key Vault Administrator role provides full data plane access (keys, secrets, certificates) but cannot manage the vault resource itself or manage role assignments.
Key Vault authenticates via Microsoft Entra ID; authorization uses either Azure RBAC (management + data plane) or Key Vault access policy (data plane only).
Best practice is to create one Key Vault per application per environment (Dev, Pre-Prod, Prod) to segregate secrets.
Certificate access control policies in Key Vault are distinct from key and secret access control policies within the same vault.
Certificate contacts in Key Vault are shared across all certificates in the vault.
Creating a Key Vault certificate automatically creates an addressable key and an addressable secret with the same name.
When no X.509 key usage is specified, Key Vault certificate default key operations are sign, verify, wrapKey, and unwrapKey.
Default Key Vault key operations when no X.509 key usage is specified are sign, verify, wrapKey, and unwrapKey.
Certificate issuer objects in Key Vault are vault-scoped and cannot be shared across vaults.
Key Vault certificate lifetime actions support two triggers (days before expiry, lifetime percentage) and two actions (emailContacts, autoRenew).
Only DigiCert and GlobalSign are partnered certificate issuers in Key Vault, supporting automatic TLS/SSL certificate issuance and renewal.
Key Vault Contributor role is control plane only — it does NOT grant access to keys, secrets, or certificates.
Key Vault Contributor role is control plane only and does NOT grant access to keys, secrets, or certificates.
Key Vault control plane endpoint is management.azure.com:443; data plane endpoint is {vault-name}.vault.azure.net:443.
Key Vault control plane endpoint is management.azure.com:443; data plane endpoint is <vault-name>.vault.azure.net:443.
Custom roles for Key Vault data plane operations use DataActions (not Actions).
Key Vault supports EC curves P-256, P-384, P-521, and secp256k1 (P-256K).
Key Vault FIPS compliance: software keys = FIPS 140-2 Level 1; HSM Platform 1 = FIPS 140-2 Level 2; HSM Platform 2 and Managed HSM = FIPS 140-3 Level 3.
Key Vault contents are automatically replicated within a region and to a secondary region; failover is automatic with no admin action required.
Key Vault contents are automatically replicated within a region and to a secondary region; failover is automatic with no admin action needed.
HSM-protected keys in Key Vault are always non-exportable; only RSA and EC key types support exportable private keys.
All new key versions in Key Vault are created on HSM Platform 2 (FIPS 140-3 Level 3).
All new key versions are created on HSM Platform 2, which provides FIPS 140-3 Level 3 protection; HSM Platform 1 (legacy) provides FIPS 140-2 Level 2.
Key Vault keys are represented as JSON Web Key (JWK) objects following JOSE specifications.
Managed HSM pools are single-tenant with isolated security domains, separate from Key Vault vaults.
Managed HSMs support symmetric keys (oct-HSM: 128, 192, 256-bit); standard Key Vault vaults do not support symmetric keys.
Object-scope RBAC in Key Vault cannot fully isolate application teams within a single vault — administrative operations still require vault-level permissions.
oct-HSM 256-bit keys with AES in Managed HSM are considered quantum-resistant per CNSA 2.0.
Key Vault Premium tier uses HSM-protected keys (Marvell LiquidSecurity HSMs) validated at FIPS 140-3 Level 3.
Key Vault Premium tier uses HSM-protected keys (Marvell LiquidSecurity HSMs) validated at FIPS 140-3 Level 3.
Premium HSM key types (RSA-HSM, EC-HSM, OCT-HSM) never leave the HSM boundary.
Azure RBAC for Key Vault applies only to vaults; Managed HSMs have their own separate access control model.
Custom roles for Key Vault data plane operations use DataActions (not Actions) in the role definition.
Azure RBAC for Key Vault applies only to vaults, not to Managed HSMs, which have their own access control model.
Key Vault supports two authorization mechanisms: Azure RBAC (management + data plane) or Key Vault access policy (data plane only).
Key Vault supports RSA key sizes of 2048, 3072, and 4096 bits.
Software-protected keys are only available in Key Vault vaults, not in Managed HSMs.
Key Vault Standard tier uses software-protected keys validated at FIPS 140 Level 1.
Switching to Azure RBAC permission model for Key Vault immediately invalidates all existing access policies.
Admin State can override health probe behavior for maintenance windows on Azure Load Balancer.
Azure Load Balancer backend pools cannot contain Private Endpoints.
Azure Load Balancer backend pools are scoped to a single virtual network; rules cannot span two VNets.
Basic SKU Load Balancer health probes are not supported with Virtual Machine Scale Sets.
Basic SKU Load Balancer does not support HTTPS health probes, outbound rules, or HA ports, and closes all TCP connections on probe failure.
Basic SKU Load Balancer health probes are not supported with Virtual Machine Scale Sets.
Basic SKU Load Balancer health probes are not supported with Virtual Machine Scale Sets.
Azure Load Balancer Basic SKU was retired on September 30, 2025.
Azure Load Balancer does not store customer data — it processes traffic in real-time without persistence.
HA Ports (protocol=all, port=0) are only supported on internal Standard Load Balancer, not on Basic or Public Load Balancers.
Health probe failure stops new connections only; existing connections persist until the flow ends, idle timeout, or VM shutdown.
HTTP health probes cannot use ports 19, 21, 25, 70, 110, 119, 143, 220, or 993.
HTTP/HTTPS health probes succeed only on HTTP 200; any other status code (403, 404, 500, etc.) causes probe failure.
HTTP health probes on Azure Load Balancer do not support hostname-based probing.
HTTP health probes cannot use ports 19, 21, 25, 70, 110, 119, 143, 220, or 993.
For HTTP health probes, explicit responses (200 or non-200) reset the probe threshold immediately; the threshold count only applies when probes time out with no response.
HTTP/HTTPS health probe timeout is 30 seconds; TCP probes have no separate timeout (use the probe interval).
HTTPS health probes require certificates with minimum SHA256 signature hash in the entire chain and do not support mutual authentication with client certificates.
ICMP and IP fragmentation are not supported by Azure Load Balancer load-balancing rules.
Inbound NAT rules do not require a health probe; only load-balancing rules require one.
Inbound NAT rules do not require a health probe; only load balancing rules require one.
Inbound NAT rules forward traffic to a specific VM instance; load-balancing rules distribute to all instances in the backend pool.
Internal Load Balancer frontend IPs are never exposed to internet endpoints; it cannot accept traffic from the internet.
Internal Load Balancer frontend IPs are never exposed to internet endpoints; it cannot accept traffic from the internet.
IP fragmentation is not supported on Azure Load Balancer rules.
An Azure Load Balancer can have multiple frontend IP configurations.
ICMP and IP fragmentation are not supported by Azure Load Balancer load-balancing rules.
An availability set is limited to one public NIC-based Load Balancer and one internal NIC-based Load Balancer; IP-based LBs are exempt from this limit.
Azure Load Balancer operates at Layer 4 (Transport) of the OSI model, handling TCP and UDP only — it is not application-aware.
An outbound flow from a backend VM to the frontend of its own internal Load Balancer will fail.
An outbound flow from a backend VM to the frontend of its own internal Load Balancer will fail.
An outbound flow from a backend VM to the frontend of its own internal Load Balancer will fail.
Azure Load Balancer uses a pass-through architecture with no TLS termination and no proxy, enabling ultra-low latency.
Azure Load Balancer uses a pass-through architecture for ultra-low latency — it does not perform TLS termination or act as a proxy.
Azure Load Balancer uses a pass-through architecture with no TLS termination and no proxy, enabling ultra-low latency.
Outbound connectivity from backend instances is not affected by health probe failure — only inbound new connections are stopped.
Health probe failure affects only inbound connectivity; outbound connectivity from backend instances remains unaffected.
The health probe port and the application port do not have to be the same on Azure Load Balancer.
All IPv4 health probes originate from source IP 168.63.129.16; IPv6 probes use link-local address fe80::1234:5678:9abc.
A public Azure Load Balancer handles both inbound (internet to VMs) and outbound (VMs to internet via private-to-public IP translation) connectivity.
Public load balancer handles both inbound load balancing and outbound NAT by translating private IPs to public IPs.
Public load balancer provides outbound connectivity for VMs by translating private IPs to public IPs (SNAT).
Standard LB: when all probes are down, established TCP flows continue. Basic LB: all TCP flows expire when all probes are down.
Standard Azure Load Balancer is built on the Zero Trust network security model.
Standard Load Balancer and standard public IPs are closed to inbound traffic by default; NSGs must explicitly allow traffic.
Standard Load Balancer implements zero-trust networking by combining a closed-by-default inbound posture with the zero-trust security model — traffic must be explicitly allowed via NSG rules before any backend communication occurs.
Stopped VMs can remain in an Azure Load Balancer backend pool.
Stopped VMs are not probed by load balancer health probes until started again.
Stopped/deallocated VMs can remain in an Azure Load Balancer backend pool.
Azure Load Balancer has three SKUs: Basic (retired), Standard, and Gateway.
VMs can be added to a load balancer backend pool even when in a stopped state.
VMs do not need a public IP address to be in a public load balancer's backend pool.
Azure Load Balancer is built on the Zero Trust network security model and does not store customer data — it processes traffic in real-time without persistence.
Azure Standard Load Balancer is built on the Zero Trust network security model.
Azure Managed Disks only support LRS and ZRS redundancy options.
Azure Managed Disks are stored as page blobs but abstract away blob, container, and storage account management.
Azure managed identity types present a lifecycle tradeoff: system-assigned identities auto-name their service principal to match the resource and auto-delete with it, while user-assigned identities enable cross-resource sharing but require explicit creation, assignment, and deletion.
Managed identity combined with Key Vault references creates a zero-credential application pipeline: identity lifecycle is automatic (system-assigned) or shareable (user-assigned), while Key Vault references inject secrets into App Service settings via @Microsoft.KeyVault syntax — no credential ever appears in code, configuration, or environment variables at any stage.
Azure Resource Manager caches management group hierarchy details for up to 30 minutes — portal may not immediately reflect moves.
Azure Resource Manager caches management group hierarchy details for up to 30 minutes — portal may not reflect moves immediately.
A single Microsoft Entra directory supports up to 10,000 management groups.
Management group hierarchy supports up to 6 levels of depth, excluding the root management group level and the subscription level.
Moving a subscription or management group requires Microsoft.management/managementgroups/write permission on the child, the target parent, and the current parent management group.
Policies and RBAC role assignments on a management group cascade by inheritance to all descendant management groups, subscriptions, resource groups, and resources.
No one has default access to the root management group — only Microsoft Entra Global Admins can elevate themselves to User Access Administrator on the root.
No one has default access to the root management group — only Microsoft Entra Global Admins can elevate themselves to manage it.
The root management group cannot be moved or deleted; its ID equals the Microsoft Entra tenant ID; its display name defaults to "Tenant root group."
Each management group and subscription can have only one parent management group.
Azure management groups enforce a strict single-parent tree hierarchy with cascading RBAC and Policy inheritance, where all subscriptions must be children of a management group under the immovable tenant root.
Azure Resource Manager caches management group hierarchy details for up to 30 minutes — portal may not reflect moves immediately.
Policies and RBAC role assignments on a management group cascade by inheritance to all descendant management groups, subscriptions, resource groups, and resources.
A single Microsoft Entra directory supports up to 10,000 management groups.
Management group hierarchy supports up to 6 levels of depth, excluding the root management group level and the subscription level.
Moving a subscription or management group requires Microsoft.management/managementgroups/write permission on the child, the target parent, and the current parent management group.
No one has default access to the root management group — only Microsoft Entra Global Admins can elevate themselves to manage it.
The root management group cannot be moved or deleted; its ID equals the Microsoft Entra tenant ID, and its default display name is "Tenant root group".
Each management group and subscription can have only one parent management group.
Microsoft Cloud Security Benchmark provides the control framework that underpins WAF Security pillar guidance.
Microsoft recommends Azure Private Link/private endpoints over service endpoints for new deployments.
The Network Contributor built-in role covers all subnet RBAC operations (read, write, delete, join, joinViaServiceEndpoint).
Network Contributor lets you manage networks but does not allow deploying VMs or directly accessing the networks.
The Network Contributor built-in role covers all subnet RBAC operations (read, write, delete, join, joinViaServiceEndpoint).
Network Security Perimeter is GA in all public cloud regions and provides a secure logical boundary for public internet PaaS traffic scenarios, complementary to Private Link.
Route propagation must never be disabled on GatewaySubnet — the gateway will stop functioning.
NSGs provide a complete traffic evaluation model combining ordered five-tuple matching (custom rules priority 1–4096 always before default rules 65000–65500), stateful connection tracking with graceful rule changes, and platform IP exemptions for infrastructure services (168.63.129.16, 169.254.169.254).
NSG rule changes are non-disruptive to established connections: statefulness auto-allows return traffic for permitted flows, and rule removal only blocks new connections without terminating existing ones.
NVAs must be deployed in a different subnet than the routed resources to avoid routing loops.
NVAs must be deployed in a different subnet than the resources whose traffic they route to avoid routing loops.
NVA IP forwarding must be enabled at both the Azure NIC level and the OS level for traffic forwarding to work.
Object replication supports block blobs only (not append or page blobs).
AllowCrossTenantReplication defaults to false for storage accounts created after December 15, 2023.
Customer-managed failover is not supported on either the source or destination account in an object replication policy.
The destination container becomes read-only while a replication policy is active; writes return HTTP 409 Conflict.
Object replication fails if either the source or destination blob is moved to the archive tier.
Azure Blob Storage object replication is supported only on general-purpose v2 and premium block blob storage account types.
Object replication is supported only on general-purpose v2 and premium block blob storage account types.
Each object replication policy supports up to 1,000 rules.
Each object replication policy supports up to 1,000 rules; each rule maps one source container to one destination container.
A source account can replicate to at most 2 destination accounts; a destination account can have at most 2 replication policies.
A destination storage account can have at most 2 replication policies; a source account can replicate to at most 2 destination accounts.
Customer-managed failover is not supported for storage accounts participating in object replication.
Object replication fails for blobs encrypted with customer-provided keys on the source account; Microsoft-managed and customer-managed keys are supported.
Object replication is not supported for storage accounts with hierarchical namespace enabled (Data Lake Storage Gen2).
Object replication does not support storage accounts with hierarchical namespace enabled (ADLS Gen2 / Data Lake Storage).
Object replication policy is created on the destination account first, then linked to the source account using the same policy ID.
Object replication policy is created on the destination account first (with policyId "default"), then linked to the source account using the assigned policy ID.
With priority replication enabled (same continent), 99% of objects replicate within 15 minutes (SLA-backed).
Object replication requires change feed on the source account and blob versioning on both source and destination accounts.
Snapshots are not replicated and version IDs are not preserved during object replication.
Object replication does not preserve version IDs — destination blobs receive new version IDs.
Overriding 0.0.0.0/0 causes all traffic (including to Azure service public IPs) to go through the specified next hop — unless a service endpoint is enabled for that service.
Azure offers two complementary PaaS connectivity models with distinct tradeoff profiles: service endpoints are subnet-scoped, ARM-only, require no DNS changes, but cannot reach from on-premises; Private Link is instance-scoped, routes over the Microsoft backbone, requires private DNS zones, and supports on-premises access via ExpressRoute private peering — service endpoints are simpler to deploy but fundamentally less isolated and less flexible.
Azure Policy assignments use the latest definition state — updating a policy definition automatically applies to all existing assignments without reassignment.
auditIfNotExists assesses compliance based on a child or extension resource's properties, not the resource's own properties (unlike audit); it evaluates after the Resource Provider returns success.
Best practice: start Azure Policy with audit/auditIfNotExists effects before enforcement (deny, modify, deployIfNotExists), and always use initiatives even for a single policy definition.
Azure Policy automatic compliance evaluation occurs every 24 hours; additional triggers include resource create/update, new/updated assignments, and policy definition updates.
When multiple Azure Policy assignments layer on a resource, the net result is cumulative most restrictive — overlapping deny policies block resources; exclusions create exceptions.
Azure Policy definition displayName is capped at 128 characters and description at 512 characters.
An Azure Policy definition must be created at a management group or subscription; it can only be assigned within that scope's hierarchy (direct members or children).
Azure Policy mode all evaluates resource groups, subscriptions, and all resource types; mode indexed only evaluates types supporting tags and location; Azure CLI defaults to null (equivalent to indexed), while the portal defaults to all.
Azure Policy effect evaluation order: disabled → append/modify → deny → audit → manual → auditIfNotExists → denyAction; append/modify run before deny because they may alter the request and prevent a deny.
Azure Policy is an explicit deny system — if any assignment denies a resource, the only way to allow it is to modify the denying assignment; no override mechanism exists.
Azure Policy operates as an explicit deny system with cumulative most-restrictive evaluation — when multiple policies overlap, the strictest wins — orthogonal to RBAC which evaluates user actions rather than resource state, making Policy the resource-centric complement to RBAC's identity-centric access control.
Azure Policy allows maximum 20 parameters per policy definition and 400 parameters per initiative definition.
Azure Policy limits: 500 policy definitions per scope, 200 initiative definitions per scope (2,500 per tenant), 200 assignments per scope, 1,000 exemptions per scope, 1,000 policies per initiative.
Each Azure Policy metadata property (version, category, preview, deprecated, portalReview) is limited to 1024 characters.
Three Resource Provider modes are fully supported (GA): Microsoft.Kubernetes.Data, Microsoft.KeyVault.Data, and Microsoft.Network.Data; RP modes support only audit, deny, and disabled effects.
Each Azure Policy definition contains exactly one effect in its policyRule; multiple effects require multiple policy definitions.
Azure Policy supports 12 effects: addToNetworkGroup, append, audit, auditIfNotExists, deny, denyAction, deployIfNotExists, disabled, manual, modify, mutate.
Azure Policy policyType is read-only (set by the system) with three values: Builtin (Microsoft-maintained), Custom (customer-created), and Static (Regulatory Compliance, Microsoft-managed).
Azure Policy definitions use Major.Minor.Patch versioning; major = breaking changes/new enforcement effects, minor = rule tweaks/new allowed values, patch = string/metadata/security fixes.
Both Azure Private Endpoint and Private Link Service (behind Standard LB) are generally available; individual PaaS services onboard to Private Link on different schedules.
A private endpoint maps to a specific PaaS resource instance (not the entire service), providing data leakage protection.
Azure Private Endpoints require Azure DNS / Private DNS Zones for name resolution of the private endpoint.
Both Azure Private Endpoint and Private Link Service (behind Standard LB) are generally available; individual PaaS services onboard on different schedules.
Azure Monitor tracks data processed (IN/OUT) on both private endpoints and Private Link services, plus NAT port availability for Private Link Service.
Azure Monitor tracks data processed (IN/OUT) on both private endpoints and Private Link services, plus NAT port availability for Private Link Service.
Network Security Perimeter is GA in all public cloud regions and provides a secure logical boundary for public internet PaaS traffic scenarios, complementary to Private Link.
On-premises access to Private Link services uses ExpressRoute private peering or VPN tunnels; Microsoft peering is not required.
Azure DNS / Private DNS Zones are required for name resolution of private endpoints.
Azure Private Link Service requires a Standard Load Balancer (not Basic) as its backend.
Private Link has global reach — a consumer VNet in one region can connect to services behind Private Link in a different region.
Azure Private Link traffic traverses the Microsoft backbone network and never crosses the public internet.
Private Link achieves complete PaaS network isolation through three interlocking mechanisms: backbone-only routing eliminates public internet traversal, single-resource-instance endpoint targeting prevents cross-tenant data leakage, and private DNS zone requirements ensure name resolution stays within the private network — all three must be correctly configured for the isolation model to hold.
Azure Private Link works across different Microsoft Entra tenants with an approval call flow for connection requests.
Azure Private Link spans Availability Zones and is zone resilient.
Public Azure Load Balancer handles both inbound (internet to VMs) and outbound (VMs to internet via private-to-public IP translation) connectivity.
Azure Queue Storage messages have a maximum size of 64 KB; queues can contain millions of messages.
Azure RBAC access evaluation order: token acquisition → retrieve role/deny assignments → check deny → check roles → check conditions.
Actions/NotActions apply to the control plane; DataActions/NotDataActions apply to the data plane.
Azure RBAC enforces an additive authorization model built on Azure Resource Manager: effective permissions are the union of all role assignments with no subtraction, role definition IDs remain stable across renames for automation safety, and the Owner/Contributor split specifically gates role assignment capability — making RBAC a monotonically increasing permission surface where the only way to reduce access is to remove assignments.
Azure RBAC uses an additive model — effective permissions are the union of all role assignments; no role assignment subtracts from another.
The Role Based Access Control Administrator role can assign roles via RBAC but explicitly cannot manage access via Azure Policy.
The Role Based Access Control Administrator role can assign roles via RBAC but cannot manage access via Azure Policy or other mechanisms.
Role Based Access Control Administrator can only manage access via Azure RBAC, not via Azure Policy or other mechanisms.
Azure Resource Manager does not validate management group existence when specified in custom role AssignableScopes.
An Azure RBAC role assignment has exactly three elements: security principal, role definition, and scope.
Azure RBAC is built on Azure Resource Manager; all access decisions flow through ARM's global endpoint.
Conditions on Azure RBAC role assignments are evaluated last; if conditions aren't met, access is denied even if the role grants the action.
Azure RBAC role assignments can include conditions that are evaluated after role matching; access is denied if conditions are not met.
Custom roles cannot set AssignableScopes to the root scope ("/").
Custom roles with DataActions cannot be assigned at management group scope.
Custom roles support a maximum of 2,000 AssignableScopes per role definition.
Custom roles cannot have AssignableScopes set to root scope ("/").
Custom roles cannot set AssignableScopes to root scope ("/").
Wildcards cannot be used in AssignableScopes for custom role definitions.
Only one management group can be defined in a custom role's AssignableScopes.
Azure RBAC permission strings in custom role definitions are case-insensitive; wildcards are supported but limited to one wildcard (*) per action string.
Creating, deleting, or updating custom roles requires Microsoft.Authorization/roleDefinitions/write permission on all AssignableScopes.
REST API input format for custom roles nests permissions under properties.permissions[], differing from the PowerShell/CLI format which uses top-level Actions/NotActions/DataActions/NotDataActions.
Azure has a limit of 5,000 custom roles per tenant (2,000 for 21Vianet).
Azure RBAC data (definitions, assignments, deny assignments) is stored and replicated globally across all Azure regions.
Deny assignments are evaluated before allow role assignments; if a deny applies, access is blocked regardless of role assignments.
Azure RBAC effective permissions are calculated as Actions - NotActions for management plane and DataActions - NotDataActions for data plane.
Azure RBAC has exactly 5 privileged roles: Owner, Contributor, Reader, User Access Administrator, and Role Based Access Control Administrator.
Azure RBAC is included free with every Azure subscription at no additional cost.
Group memberships are transitive for Azure RBAC role assignment purposes — nested group members inherit roles.
All role assignments must be removed before a custom role can be deleted (error: RoleDefinitionHasAssignments).
Network Contributor role allows managing networks but does not grant permission to deploy virtual machines.
Network Contributor role allows managing networks but does not allow deploying VMs or accessing the networks; Virtual Machine Contributor does not grant access to the connected VNet or storage account.
NotActions excludes operations from the allowed Actions set but is not a deny — it simply subtracts from allowed permissions.
NotActions in Azure RBAC role definitions subtracts from the Actions set — it is not a deny rule; a separate role assignment granting excluded actions will still apply.
Owner role can assign roles in Azure RBAC; Contributor role cannot assign roles, manage Blueprints, or share image galleries.
Azure RBAC permission strings (e.g., Microsoft.Compute/*/read) are case-insensitive.
The Azure RBAC Reader role has the immutable ID acdd72a7-3385-48ef-bd42-f606fba81ae7.
Azure RBAC role assignments can include conditions evaluated after role matching; access is denied if conditions are not met.
Azure RBAC role definitions have four permission components: Actions, NotActions, DataActions, and NotDataActions.
Azure RBAC role definition IDs remain stable even if a role is renamed; best practice is to reference roles by ID in automation.
Azure RBAC scope hierarchy from broadest to narrowest: management group > subscription > resource group > resource.
Storage Blob Data Owner role provides full access to blob data including the ability to assign POSIX ACLs.
Storage Blob Data Reader grants access to blob data (data plane); Reader grants management plane visibility only — they are not interchangeable.
User Access Administrator role manages user access to Azure resources but cannot manage the resources themselves.
Virtual Machine Contributor does not grant access to the virtual network or storage account the VM connects to and cannot assign RBAC roles.
Virtual Machine Contributor does not grant access to the connected VNet or storage account, nor allow RBAC assignment.
Virtual Machine Contributor role does not grant access to the connected VNet or storage account, nor allow RBAC assignment.
Wildcards (*) are supported in Azure RBAC permission strings but only one wildcard is allowed per action string.
Azure Cache for Redis connection audit logs use poll-based collection on Premium and event-based collection on Enterprise.
Azure Cache for Redis Basic tier has no SLA and runs on a single VM.
Azure Cache for Redis Basic tier has no SLA and no data replication — suitable for dev/test only.
Azure Cache for Redis C0 cache uses a shared CPU core with minimal memory and noisy-neighbor issues — only for simple dev/test.
Azure Cache for Redis supports the cache-aside pattern where data is loaded into cache only as needed from the backend data store.
Azure Cache for Redis can scale up from Basic to Premium but cannot scale down; Enterprise tiers support scale-up and scale-out only.
Azure Cache for Redis clustering is available only on Premium, Enterprise, and Enterprise Flash tiers.
Azure Cache for Redis client and cache must be in the same Azure region for optimal latency and reliability.
Azure Cache for Redis client application and cache should be placed in the same Azure region to minimize latency.
Data persistence (RDB/AOF) in Azure Cache for Redis requires Premium or Enterprise tier; not available on Basic or Standard.
Azure Cache for Redis Enterprise Flash tier supports only RediSearch (preview) and RedisJSON; full Enterprise tier supports all Redis modules (RediSearch, RedisBloom, RedisJSON, RedisTimeSeries).
Azure Cache for Redis Enterprise Flash tier uses nonvolatile memory with a memory range of 300 GB to 4.5 TB.
Azure Cache for Redis Enterprise Flash tier uses nonvolatile memory to reduce per-GB cost, supporting up to 4.5 TB.
Only Enterprise tiers support Redis Modules (RediSearch, RedisBloom, RedisJSON, RedisTimeSeries).
Azure Cache for Redis Basic/Standard/Premium use single-threaded command processing; Enterprise tiers use multi-threaded Redis Enterprise.
Azure Cache for Redis Enterprise tiers require an Azure Marketplace license; Azure credits and free MSDN subscriptions are not supported.
Azure Cache for Redis Enterprise tier requires an Azure subscription with a valid payment instrument (no free credits/MSDN) and Marketplace purchases must be enabled.
Azure Cache for Redis Enterprise tiers require a valid payment instrument (no free credits/MSDN) and Marketplace purchase permissions.
Azure Cache for Redis Enterprise tier requires an Azure subscription with a valid payment instrument; free credits and MSDN subscriptions are not supported.
Azure Cache for Redis Enterprise tier requires a valid payment instrument; Azure credits and free MSDN subscriptions are not supported.
For Azure Cache for Redis Enterprise tiers, scaling up is recommended before scaling out; for OSS tiers (Basic/Standard/Premium), scaling out improves performance more than scaling up.
Azure Cache for Redis Enterprise tiers should scale up before scaling out (multi-vCPU); OSS tiers benefit more from scaling out than scaling up (single-threaded).
Azure Cache for Redis has five service tiers: Basic, Standard, Premium, Enterprise, and Enterprise Flash.
Azure Cache for Redis offers five service tiers: Basic, Standard, Premium, Enterprise, and Enterprise Flash.
Azure Cache for Redis Premium tier supports passive geo-replication only; Enterprise and Enterprise Flash support active geo-replication.
Azure Cache for Redis Premium tier supports passive geo-replication; Enterprise and Enterprise Flash support active geo-replication.
The Redis KEYS command is expensive and should be avoided in production; use SCAN instead.
Redis modules (RediSearch, RedisBloom, RedisJSON, RedisTimeSeries) are available only on Enterprise tiers of Azure Cache for Redis.
Azure Cache for Redis supports scaling up from Basic to Premium but does not support scaling down to a lower tier.
OSS Redis clustering requires Azure Cache for Redis Premium tier or higher.
Azure Cache for Redis OSS clustering requires Premium tier or higher; not available on Basic or Standard.
Azure Cache for Redis OSS tiers (Basic/Standard/Premium) are single-threaded for command processing; Enterprise tiers utilize multiple vCPUs.
Azure Cache for Redis OSS tiers support Redis versions 4.0.x and 6.0.x; Redis 5.0 was skipped.
Only Premium and Enterprise tiers of Azure Cache for Redis support data persistence (RDB and AOF).
Azure Cache for Redis Premium tier uses Azure Storage for data persistence; Enterprise tier uses Managed Disks.
Azure Cache for Redis certificate pinning should target root CAs (Baltimore CyberTrust Root, Microsoft RSA Root 2017, DigiCert Global Root G2), never intermediate or leaf certificates.
Azure Cache for Redis certificate pinning should target root CAs (Baltimore CyberTrust Root, Microsoft RSA Root 2017, DigiCert Global Root G2), never intermediate or leaf certificates.
When using certificate pinning with Azure Cache for Redis, pin to root certificates — intermediate certificates rotate frequently.
When using certificate pinning with Azure Cache for Redis, pin to root certificates, not intermediate or leaf certificates, since intermediates rotate frequently.
Redis pipelining improves throughput but large responses can consume the timeout window for subsequent responses, causing head-of-line blocking timeouts.
Redis works best with smaller values; large data should be broken into multiple keys rather than stored as large blobs.
Redis works best with smaller values; large data should be broken into multiple keys rather than stored as large blobs.
Azure Cache for Redis supports network isolation via Private Link on all tiers (Basic through Enterprise Flash).
Azure Cache for Redis tiers progressively add capabilities: Basic provides a single-node cache, Standard adds replication, Premium adds clustering and persistence, and Enterprise/Enterprise Flash add Redis Modules — though the capability progression is not strictly additive across all dimensions.
Azure Cache for Redis SLA covers connectivity to cache endpoints only, not data loss protection.
Azure Cache for Redis SLA covers connectivity to cache endpoints only, not data loss protection.
Redis works best with smaller values; large data should be broken into smaller chunks across multiple keys.
Azure Cache for Redis supports OSS Redis versions 4.0.x and 6.0.x; Redis 5.0 was skipped.
Azure Cache for Redis requires TLS by default; TLS 1.2 is the recommended minimum version.
Azure Cache for Redis clients should use the DNS hostname, not public IP addresses, because IPs can change on scale or backend operations.
Azure Cache for Redis skipped Redis version 5.0 — supported versions went from 4.0.x directly to 6.0.x.
Azure Cache for Redis supports Redis versions 4.0.x and 6.0.x; version 5.0 was skipped.
If TLS encrypted connections cannot be used with Azure Cache for Redis, placing cache and client inside a virtual network is the recommended mitigation.
If TLS encryption cannot be used with Azure Cache for Redis, placing cache and client inside a virtual network is the recommended mitigation.
Azure Cache for Redis zone redundancy is available on Standard, Premium, and Enterprise tiers but not on Basic tier.
Azure Cache for Redis zone redundancy is available on Standard tier and above; Basic tier does not support zone redundancy.
Azure Cache for Redis zone redundancy is available on Standard, Premium, and Enterprise tiers — not Basic.
Azure Storage SAS tokens follow a security hierarchy: user delegation SAS (using Entra credentials) is most secure, service SAS provides resource-level scoping, and account SAS grants the broadest access — with user delegation SAS recommended as the preferred option.
Service endpoint policies provide resource-level granularity, allowing only specific Azure service resource instances (e.g., specific storage accounts) over service endpoints.
VNet service endpoints are only available for VNets deployed via Azure Resource Manager (not classic deployment model).
VNet service endpoints are only available for Azure Resource Manager (ARM) deployments, not classic deployments.
VNet service endpoints are triple-constrained: ARM-only (no classic deployments), subnet-scoped (each subnet independently enabled), and inaccessible from on-premises — requiring IP-based whitelisting for any hybrid connectivity to service-endpoint-secured resources.
For Azure SQL Database, service endpoint traffic applies only within the same region.
VNet service endpoints are configured per-subnet, not per-VNet — each subnet must be independently enabled.
VNet and service resource can be in different subscriptions; some services (Storage, Key Vault) support cross-tenant service endpoints.
Disk traffic (managed and unmanaged) is not affected by Azure Storage service endpoint routing changes.
DNS entries for Azure services remain unchanged and continue resolving to public IPs even after enabling VNet service endpoints.
Enabling VNet service endpoints does not change DNS resolution — Azure service FQDNs still resolve to public IP addresses.
DNS entries for Azure services remain unchanged when service endpoints are enabled — they still resolve to public IP addresses.
Enabling or disabling service endpoints closes existing TCP connections — should be avoided during critical operations.
A VNet can be associated with up to 200 different subscriptions and regions per supported service when using service endpoints.
A VNet can be associated with up to 200 different subscriptions and regions per supported service when using service endpoints.
VNet service endpoints have no additional cost and no limit on total service endpoints per VNet; maximum 200 subscriptions/regions per service.
On-premises traffic cannot use VNet service endpoints; on-prem access to service-endpoint-secured resources requires IP firewall rules with NAT/public IPs.
On-premises traffic cannot use VNet service endpoints; on-prem access to service-endpoint-secured resources requires IP firewall rules with NAT/public IPs.
VNet service endpoints cannot be used for on-premises to Azure traffic; on-premises must use public/NAT IPs via IP firewall rules.
On-premises traffic cannot use VNet service endpoints — on-prem access to secured resources requires IP firewall rules with public/NAT IPs.
Service endpoint routes override forced-tunneling and UDRs for Azure service traffic, keeping it on the Azure backbone.
Enabling VNet service endpoints requires the RBAC permission Microsoft.Network/virtualNetworks/subnets/joinViaServiceEndpoint/action.
Enabling VNet service endpoints requires the RBAC permission Microsoft.Network/virtualNetworks/subnets/joinViaServiceEndpoint/action.
VNet service endpoints are only available for VNets deployed via Azure Resource Manager (not classic deployment model).
Enabling VNet service endpoints switches source IP addresses from public IPv4 to private IPv4 for service traffic, which can break existing firewall rules using public IPs.
Service tag route precedence: Regional tag > Top-level tag > AzureCloud regional > AzureCloud; an explicit IP prefix always wins over a service tag.
Azure Service Bus auto-delete on idle minimum interval is 5 minutes.
Azure Service Bus auto-forwarding chains a queue or subscription to another queue or topic within the same namespace.
Azure Service Bus auto-forwarding chains a queue or subscription to another queue or topic only within the same namespace.
Azure Service Bus dead-letter queue is a secondary subqueue on queues and topic subscriptions for holding undeliverable messages.
Azure Service Bus supports duplicate detection — queue or topic discards duplicate copies when a sender resends, enabling safe retries.
Azure Service Bus duplicate detection discards duplicate copies at the broker level when a sender resends due to uncertain outcome.
Azure Service Bus exactly-once processing requires application-level duplicate detection on top of Peek Lock mode.
Express entities are not supported in Azure Service Bus Premium namespaces.
Azure Service Bus Premium Geo-Replication replicates both metadata and data (queues, topics, subscriptions, filters, message data, state changes, namespace configuration).
Azure Service Bus Premium tier supports full JMS 2.0; Standard tier supports only JMS 1.1 for queues.
Azure Service Bus large message batching is not supported.
Azure Service Bus large messages via SBMP or HTTP are capped at 1 MB even in Premium; only AMQP supports up to 100 MB.
Azure Service Bus legacy SDKs (WindowsAzure.ServiceBus, Microsoft.Azure.ServiceBus, com.microsoft.azure.servicebus) retire 30 September 2026.
Azure Service Bus queues enable load leveling: consumers process at average load rather than peak load, reducing infrastructure requirements.
Azure Service Bus message sessions enable FIFO (first-in, first-out) guarantee and request-response patterns.
Azure Service Bus message sessions enable FIFO (first-in-first-out) guarantees and request-response patterns.
Azure Service Bus namespace is a capacity slice of a large cluster spanning dozens of all-active VMs, optionally across three availability zones.
An Azure Service Bus namespace spans dozens of all-active VMs, optionally across three availability zones.
Azure Service Bus namespaces optionally span 3 availability zones for zone-redundant storage.
Azure Service Bus Peek Lock mode provides at-least-once semantics via two-stage receive (lock then complete or abandon).
Azure Service Bus Peek Lock has three failure outcomes: abandon (explicit unlock), lock timeout expiry (automatic unlock), or application crash — all result in the message becoming available again.
Azure Service Bus customer-managed key (CMK) encryption for double encryption is a Premium-only feature, configured once at namespace creation.
Azure Service Bus Premium supports customer-managed key (CMK) encryption for double encryption, configured as a one-time namespace setup; not available on Standard tier.
Azure Service Bus Premium supports customer-managed key (CMK) encryption as a one-time setup per namespace.
Azure Service Bus Premium scaling guidance: scale down below 20% CPU, scale up above 70% CPU.
Azure Service Bus Premium Geo-Replication continuously replicates both metadata and data to a secondary region; any secondary can be promoted to primary near-instantaneously.
Azure Service Bus Premium tier is fully JMS 2.0 compliant; Standard tier supports only JMS 1.1 subset (queues only).
Azure Service Bus Premium tier supports full JMS 2.0; Standard tier supports only JMS 1.1 for queues.
Azure Service Bus Premium supports JMS 1.1 and JMS 2.0; Standard supports only JMS 1.1 for queues.
Azure Service Bus Premium tier supports JMS 2.0; Standard tier supports only a JMS 1.1 subset for queues.
Azure Service Bus Premium tier is fully JMS 2.0 compliant; Standard tier supports only a JMS 1.1 subset focused on queues.
Azure Service Bus Premium tier uses messaging units (MUs) for resource isolation; valid counts are 1, 2, 4, 8, or 16 per namespace.
Azure Service Bus Premium messaging unit (MU) billing is hourly; you only pay for additional MUs during the hours they are active.
Network security features (service tags, service endpoints, private endpoints, IP firewall via portal) are Azure Service Bus Premium-only.
Azure Service Bus Premium partitioning is set at the namespace level (all entities partitioned); Standard/Basic partitioning is per-entity with 16 fixed partitions.
Azure Service Bus primary wire protocol is AMQP 1.0 (ISO/IEC standard); also supports HTTP/REST.
Azure Service Bus delivers messages via pull mode (long-lived pull), not push.
Azure Service Bus queues provide point-to-point messaging; topics provide publish/subscribe (one-to-many) messaging.
Azure Service Bus Receive and Delete mode provides at-most-once semantics; message is lost if consumer crashes before processing.
Azure Service Bus SBMP protocol is retiring September 30, 2026.
Azure Service Bus supports three security mechanisms: SAS (Shared Access Signatures), RBAC, and Managed Identities.
Azure Service Bus Standard tier max message size is 256 KB; Premium supports up to 100 MB (AMQP only).
Azure Service Bus subscription default rule is a true filter that selects all messages from the topic.
Azure Service Bus subscription rules consist of a filter (selects messages) and an optional action (modifies metadata).
Azure Service Bus subscriptions are durable by default but can be configured to auto-expire.
Azure Service Bus transactions scope to a single messaging entity (queue, topic, or subscription).
Azure Service Bus stores messages in triple-redundant storage, spanning availability zones if zone-enabled.
The smallest Azure subnet is /29 (8 IPs total), which yields only 3 usable IPs after the 5 reserved addresses.
Storage Account Contributor is a management plane role that provides access to account keys, enabling Shared Key authorization as an indirect data access path.
Archive access tier is not supported on ZRS, GZRS, or RA-GZRS storage accounts.
Storage Blob Data Owner provides full blob access including POSIX ACL management; Storage Blob Data Contributor provides read/write/delete but cannot manage ACLs.
The Storage Blob Delegator role is required to create user delegation SAS tokens signed with Azure AD.
Storage Delegator roles (Blob, File, Queue, Table) are specifically for creating user delegation SAS tokens signed with Azure AD — they do not grant direct data access.
When Azure Storage firewall rules are enabled, all requests are blocked by default — exceptions must be explicitly added for trusted Microsoft services and allowed IP ranges/subnets.
Geo-replication (GRS/GZRS) is asynchronous, meaning potential data loss on primary region failure; failover is required for write access.
GRS and GZRS both provide 16 nines durability; GRS uses LRS in primary, GZRS uses ZRS in primary; secondary always uses LRS.
GZRS is Microsoft's recommended redundancy option for maximum consistency, durability, availability, and disaster recovery performance.
GZRS (Geo-Zone-Redundant Storage) is Microsoft's recommended redundancy option for maximum consistency, durability, availability, and disaster recovery.
LRS provides 11 nines (99.999999999%) durability by replicating data 3 times within a single datacenter.
LRS replicates data 3 times synchronously within a single datacenter; provides 11 nines durability.
The geo-redundant secondary region is determined by Azure based on the primary region and cannot be changed by the customer.
RA-GRS and RA-GZRS provide 99.99% read availability for the hot tier by allowing reads from the secondary region without failover.
The redundancy setting is shared across all storage services (Blob, Files, Table, Queue) within a storage account.
RA-GRS/RA-GZRS secondary endpoints use the suffix -secondary appended to the account name (e.g., myaccount-secondary.blob.core.windows.net); the same account access keys work for both endpoints.
The secondary region endpoint uses the suffix -secondary (e.g., myaccount-secondary.blob.core.windows.net) and shares the same access keys as the primary.
The geo-redundant secondary region is determined by Azure based on the primary region's paired region and cannot be changed by the customer.
Standard general-purpose v2 (StorageV2) is the only storage account type that supports all redundancy options (LRS, ZRS, GRS, RA-GRS, GZRS, RA-GZRS).
Unmanaged disks do not support ZRS or GZRS redundancy options.
Azure Storage write availability SLA is 99.9% for the hot tier and 99% for cool, cold, and archive tiers across all redundancy options.
ZRS provides 12 nines (99.9999999999%) durability by replicating data synchronously across 3+ availability zones.
ZRS replicates data synchronously across 3+ availability zones in the primary region; provides 12 nines durability.
ZRS is Microsoft's recommended redundancy option for Azure Data Lake Storage and Azure Files workloads.
A subnet can only be deleted if it contains no resources; resources must be removed first.
Subnet delegation cannot be removed if the delegated service still has resources deployed in the subnet.
Subnet operations require Network Contributor role or custom role with Microsoft.Network/virtualNetworks/subnets/* actions; joining requires Microsoft.Network/virtualNetworks/subnets/join/action.
Subnet names should start with a letter, not a number — Application Gateway won't deploy to subnets with numeric-starting names.
NAT gateway, NSG, and route table associated with a subnet must be in the same subscription and location as the VNet.
Subnet network policy for private endpoints controls whether NSGs and route tables apply to private endpoints on the subnet.
Private Subnet (Preview) prevents default outbound internet access for VMs deployed in the subnet.
Private Subnet (Preview) prevents default outbound internet access for VMs deployed in the subnet.
UDRs with next hop type Virtual network gateway are supported only when the gateway is a VPN gateway (not ExpressRoute, Route Server, or Virtual WAN).
UDRs with next hop type Virtual network gateway are supported only when the gateway is a VPN gateway (not ExpressRoute, Route Server, or Virtual WAN).
Virtual Machine Contributor does not grant access to the virtual network or storage account the VM connects to, and cannot assign RBAC roles.
Azure VM ephemeral storage follows a consistent operational model: VM sizes with 'd' suffix include local NVMe storage that does not persist across deallocation, v5+ VMs automatically encrypt this storage at rest, and platform-defined paths (Linux /dev/disk/azure/resource, Windows drive D) provide consistent access — making ephemeral storage predictable but explicitly non-durable.
All VM instances in a scale set are created from the same base OS image and configuration.
VMSS Flexible orchestration supports mixing Spot and on-demand VM instances together in the same scale set.
VMSS instances are created from a shared base image, providing consistent initial configuration across the scale set, though post-creation configuration drift remains possible through extensions and scripts.
The default system route for 0.0.0.0/0 has next hop type Internet; overriding it sends all traffic (including Azure service public IPs) through the specified next hop unless service endpoints provide longer-prefix matches.
Default system routes drop traffic to RFC 1918 (10/8, 172.16/12, 192.168/16) and RFC 6598 (100.64/10) ranges with next hop type None.
When multiple gateways are deployed, the hierarchy is: Route Server > ExpressRoute > VPN.
Virtual appliances (NVAs) should be deployed in a different subnet than the routed resources to avoid routing loops.
If a private address range (RFC 1918/6598) is added to a VNet's address space, its next hop automatically changes from None (drop) to Virtual network.
If a private IP range (RFC 1918/6598) is added to a VNet's address space, its default system route next hop changes from None to Virtual network automatically.
When RFC 1918 or RFC 6598 address ranges are assigned to a VNet's address space, Azure automatically changes their next hop from None to Virtual network.
When RFC 1918 or RFC 6598 address ranges are assigned to a VNet's address space, Azure automatically changes their next hop from None to Virtual network.
Route propagation from gateways can be disabled per-subnet, but must never be disabled on the GatewaySubnet or the gateway will stop functioning.
Route selection priority in Azure VNets is: UDR > BGP > System route (but system routes for VNet/peering/service endpoints are preferred over more-specific BGP routes).
Route Server takes precedence over VPN and ExpressRoute gateways when deployed in the same VNet.
Azure VNet routing uses longest-prefix match to determine which route wins among same-priority routes.
System routes for VNet, peerings, and service endpoints are preferred even over more-specific BGP routes; service endpoint routes override both BGP and UDRs for matching Azure service address prefixes.
Service tag route priority order: regional tags (e.g., Storage.EastUS) > top-level tags (e.g., Storage) > AzureCloud regional tags > AzureCloud tag.
Maximum 25 service-tag routes per route table in Azure UDRs.
System routes are automatically created per subnet and cannot be deleted, only overridden by UDRs or BGP routes.
System routes are automatically created per subnet and cannot be deleted, only overridden by UDRs or BGP routes.
Default UDR limit per route table is 400, expandable to 1,000 with Azure Virtual Network Manager.
Virtual appliances must be deployed in a different subnet than the routed resources to avoid routing loops.
When VPN and ExpressRoute gateways coexist without Route Server, the ExpressRoute gateway takes precedence as the VNet gateway.
The Azure Well-Architected Framework has five pillars: Reliability, Security, Cost Optimization, Operational Excellence, and Performance Efficiency.
The Azure Well-Architected Framework includes an interactive assessment tool (Azure Architecture Review) for evaluating workloads against WAF principles.
WAF protects at Layer 7; Azure DDoS Protection protects at Layer 3/4 — they are complementary
Mission-critical workloads have dedicated WAF guidance focused on always-available, failure-resilient design.
Mission-critical workloads have dedicated WAF guidance focused on always-available, failure-resilient design.
WAF provides workload-specific lenses with tailored guidance for AI, SaaS, SAP, Mission-critical, Oracle on IaaS, Sustainability, Azure VMware Solution, and Azure Virtual Desktop.
Disaster recovery and testing strategies are distinct but complementary practices within the WAF Reliability pillar.
In the WAF Reliability pillar, disaster recovery and testing strategies are distinct but complementary practices.
The WAF Reliability pillar has five core design principles: Design for business requirements, Design for resilience, Design for recovery, Design for operations, and Keep it simple.
Reliability in WAF is achieved through four strategies: redundancy, scaling, self-healing/preservation, and simplicity.
The WAF Reliability pillar includes a maturity model for assessing reliability posture progression.
Site Reliability Engineering (SRE) is identified as a complementary operational discipline to the WAF Reliability pillar for maintaining reliability in production.
Reliability target planning follows a four-step flow: identify flows → failure mode analysis → set targets → monitoring/alerting.
Testing strategy and disaster recovery strategy are distinct but related reliability activities within the WAF Reliability pillar.
Testing strategy and disaster recovery drills are distinct but related activities within the WAF Reliability pillar discipline.
WAF security asset protection covers: segmentation, identity & access management, network protection, encryption, resource hardening, and secrets management.
The three security objectives of the WAF Security pillar are the CIA triad: Confidentiality, Integrity, and Availability.
The WAF Security pillar is organized around the CIA triad (confidentiality, integrity, and availability).
Defense in depth is the overarching security strategy Azure recommends in the WAF Security pillar.
The WAF Security pillar has five design principles: Plan your security readiness, Design to protect confidentiality, Design to protect integrity, Design to protect availability, and Sustain and evolve your security posture.
The WAF security foundation sequence is: security baselines → secure development lifecycle (SDL) → data classification → threat monitoring → threat modeling.
The WAF Security pillar includes a formal security maturity model for assessing organizational readiness.
The WAF Security pillar is organized around the CIA triad: confidentiality, integrity, and availability.
The WAF Security pillar treats security testing and incident response as a continuous improvement validation loop, not a one-time activity.
The Azure Well-Architected Framework provides per-service WAF service guides with pillar-specific recommendations for individual Azure services.
The Azure Well-Architected Framework provides per-service service guides with pillar-specific recommendations for individual Azure services.
WAF service guides provide per-service architectural recommendations aligned with WAF pillars, bridging framework-level principles and individual Azure service configuration.
ACR provides a unified security model for container registry access: five authentication methods cover all identity scenarios, all image transfers are HTTPS/TLS-encrypted, and access governance flows through a single control plane.
AKS achieves full zero-trust protection for secrets at rest when combining infrastructure-level network zero-trust (inherited from Azure's NSG/LB default-deny stack) with Key Vault's network-isolated defense-in-depth key lifecycle for external secret storage.
AKS provides runtime security defense-in-depth across compute and storage layers: AppArmor and seccomp profiles restrict container actions following least-privilege, while managed disks provide automatic encryption at rest for node storage — but the defense-in-depth model has a gap at the application data layer where Kubernetes Secrets use base64 encoding rather than encryption.
AKS provides end-to-end secret protection at rest: customer-managed keys encrypt etcd storage via KMS encryption, backed by Key Vault where Microsoft cannot see or extract the encryption keys — ensuring the full chain from secret storage to key management is cryptographically secured.
AKS provides complete persistent storage coverage across all access modes when Azure Disk supplies ReadWriteOnce with topology-aware zone-aligned provisioning and Azure Files supplies ReadWriteMany — unless the workload requires cross-OS persistent volume sharing in mixed Windows/Linux clusters.
AKS in custom VNet inherits the full Azure zero-trust infrastructure stack: control plane NSG rules (TCP 443, 4443, 9988) operate within a dual-layer filtering model where the foundational infrastructure IP 168.63.129.16 — serving both DNS resolution and health probes — must be preserved while all other traffic defaults to deny, creating a four-layer dependency chain from infrastructure IP through network filtering to control plane access.
App Service can achieve fully network-isolated secret injection: Key Vault references inject secrets via managed identity from a vault whose defense-in-depth key lifecycle (tiered FIPS protection, three-layer deletion safeguards) is completely isolated from public internet through Private Link's triple isolation model — secrets flow from HSM to application runtime without traversing any public network path.
Azure architecture design mandates simultaneous co-design of security and observability within the tier envelope: tier selection constrains the achievable security and observability ceiling (substrate choice is second-order within it), while the circular dependency between monitoring (depends on identity/governance for workspace access) and security (depends on monitoring for detection/response) prevents sequential configuration of these domains.
Compute substrate choice (AKS vs App Service) is architecturally second-order: the tier-governed triple constraint cascade bounds the achievable security, HA, and cost envelope, within which both substrates achieve equivalent defense-in-depth through the same underlying platform stack — making tier selection the first-order decision and substrate selection an implementation detail within it.
Azure Cache for Redis provides a stable, production-grade caching platform with progressive tier capabilities from Standard through Enterprise Flash.
Both AKS and App Service achieve fully encrypted secret lifecycle from platform key management through application delivery when combining platform-independent Key Vault integration with dual-layer FIPS-tiered encryption at rest and universal TLS in transit — unless AKS Kubernetes-native secrets expose an unencrypted gap in etcd storage.
Both AKS and App Service achieve fully network-isolated secret injection through the same underlying Azure platform stack (Key Vault defense-in-depth + Private Link triple isolation + managed identity + NSG default-deny), proving the secret isolation pattern is compute-platform-independent.
Container supply chain network isolation (ACR Premium private endpoints through AKS custom VNet with Private Link) is a specific instance of the broader infrastructure-to-PaaS isolation model, confirming that Azure's Private Link architecture scales consistently from generic PaaS services to specialized container workflows without requiring container-specific isolation mechanisms.
Container supply chain network isolation (ACR Premium → Private Link → AKS custom VNet) is a concrete instance of the platform-wide tier-cascading constraint model: ACR Premium gates private endpoints and content trust, AKS standard LB inherits zero-trust default-deny, and the compound tier requirements across both services demonstrate that multi-service deployment pipelines inherit the tier cascade at each service boundary.
Azure architecture is governed by a triple constraint cascade: tier selection is the root decision that simultaneously constrains HA, security isolation, and operational capability; identity governance independently gates who can configure and observe each tier's capabilities; and observability is the terminal constraint, doubly gated by both tier and identity — making monitoring the first capability to degrade when either upstream constraint is misconfigured.
Azure DNS provides complete hybrid name resolution without VM-based forwarders: Private Resolver handles bidirectional on-premises/Azure resolution, and private zone data is globally resilient across regions — enabling a fully managed DNS architecture for hybrid environments.
The zero-trust infrastructure stack's dependence on 168.63.129.16 for both DNS resolution and health probing creates an operational coupling with DNS asymmetries: misconfiguring custom DNS (which requires preserving the infrastructure IP), failing to renew DHCP after DNS changes, or omitting FQDNs in cross-VNet queries can break the same infrastructure IP that health probes depend on — making DNS configuration errors a cascade failure point for load balancer health.
Azure DNS resolution depends on an immovable infrastructure IP (168.63.129.16) for recursive resolution and health probing while exhibiting three cross-VNet operational asymmetries (PTR scope, DHCP renewal, FQDN requirement) that compound in multi-VNet and hybrid architectures.
Azure achieves fully orthogonal five-dimension security enforcement — where governance, network, identity, data protection, and compute isolation can each be independently configured without hidden cross-plane dependencies — only when no infrastructure-level coupling undermines the assumed independence of the access and data protection planes.
Azure's two nominally orthogonal security planes (governance via RBAC/Policy and network via NSG/LB) share a hidden infrastructure coupling through DNS: the 168.63.129.16 virtual IP underpins both health probing (network plane operational dependency) and recursive name resolution (required by all service discovery), creating a single point of operational risk that compounds with DNS cross-VNet asymmetries to undermine the zero-trust assumptions of both planes.
Azure security operates through two orthogonal enforcement planes that must both be configured: governance (RBAC + Policy cascading through management group hierarchy) controls authorization, while network zero-trust (NSG + LB default-deny + infrastructure IP 168.63.129.16) controls traffic flow — breaching one plane does not bypass the other.
Azure's three independently enforced security pillars (identity, governance, network) are increasingly unified as data-plane access converges toward Entra-based managed identity as the universal authentication mechanism: the convergence reduces the number of independent credential types (deprecating shared keys and non-delegated SAS tokens) while the three-pillar model ensures this identity root is enforced consistently across governance (RBAC), network (Private Link), and cryptographic (Key Vault) boundaries.
Azure identity model choices constrain cryptographic key protection scope: the Entra identity-to-authorization chain determines Key Vault data-plane access, while Key Vault's network-isolated defense-in-depth lifecycle provides tiered FIPS protection — the identity topology (system vs user-assigned MI, app registration across tenants) bounds what key protection levels are reachable.
Azure achieves fully identity-verified end-to-end data-plane access — from Entra authentication through RBAC authorization to cryptographic key access — when the identity-to-authorization chain controls both Key Vault data-plane access and the data-plane security gradient across storage, messaging, and compute services.
Azure migration planning requires explicit resolution of a three-dimensional optimization problem: migration tier gates (SQL MI for lift-and-shift, Hyperscale for scale, Database for new workloads) compound with the tier-cost-security trilemma where selecting a price floor simultaneously constrains the security ceiling and operational capability envelope, making migration target selection inseparable from cost and security posture decisions.
Azure Monitor achieves a complete observability chain — from identity-governed data collection through retention-aligned alerting to automated response — when workspace access controls, retention tiers, and dual-ingestion pipelines all function without auxiliary table plan limitations degrading query and alert capabilities.
Azure Monitor's shared workspace platform provides complete observability coverage where all telemetry flows through Log Analytics with consistent security controls, DCR-based collection, and multi-consumer access (Monitor, Sentinel, Defender).
Azure Monitor observability is fully actionable — all ingested data can trigger alerts, feed insights, and be exported — when dual ingestion (preaggregated metrics plus log collection with DCR transformations) flows through workspaces where compound risk decisions (retention, table plans, filtering) are consistently configured across all three product consumers.
Azure network traffic requires explicit allowlisting at two independent filtering layers: Standard Load Balancer enforces zero-trust default-deny at the load balancer boundary, while NSGs provide stateful, non-disruptive rule enforcement at the subnet/NIC level — both must independently permit traffic for end-to-end flow, and rule changes at either layer are non-disruptive to established connections.
Azure provides end-to-end network isolation from infrastructure to individual PaaS instances: the zero-trust infrastructure stack (default-deny LB + NSG dual filtering + infrastructure IP preservation) secures the VNet perimeter, while Private Link (backbone routing + per-resource mapping + private DNS) extends isolation to individual service instances with no public internet traversal.
Azure networking enforces zero-trust at two orthogonal layers — a foundational infrastructure IP (168.63.129.16) that must be preserved for DNS and health probes, and a dual-layer filtering model (LB default-deny + NSG statefulness) that blocks all other traffic by default — creating a posture where infrastructure services are implicitly trusted while application traffic requires explicit allowlisting at both layers.
Azure observability and security form a circular dependency that must be resolved simultaneously: monitoring depends on governance and identity for workspace access, DCR configuration, and data integrity, while the access-and-data protection planes depend on observability (Sentinel, Defender, alert processing rules) for threat detection and compliance verification — neither can be fully effective without the other.
Azure observability and security must be co-designed within the tier-determined capability envelope: the circular dependency (monitoring depends on identity for workspace access; security depends on monitoring for detection) cannot be resolved sequentially, while the tier cascade simultaneously constrains which monitoring capabilities (table plans, zone redundancy, retention) and security features (private endpoints, network isolation) are available for that co-design.
Azure PaaS network access requires alignment across two independently configured layers — infrastructure-level filtering (Standard LB default-deny + NSG stateful rules) and PaaS-level connectivity (service endpoints for subnet-scoped access or Private Link for per-instance backbone isolation) — either layer independently capable of blocking traffic if misconfigured.
VNet peering extends the dual-layer filtering model across network boundaries: backbone-only routing preserves the Standard LB default-deny posture and NSG stateful evaluation across peered VNets, meaning zero-trust enforcement (explicit allowlisting at both LB and NSG layers) applies consistently within and between peered networks without requiring additional security configuration at the peering boundary.
Azure security converges through three independently enforced pillars that must all be configured consistently for workload-level protection: identity (Entra→RBAC→Key Vault data-plane access via tiered FIPS protection), governance (Policy+RBAC cascading through management group hierarchy with additive-then-deny evaluation), and network (zero-trust dual-layer filtering at infrastructure IP and NSG/firewall levels).
Azure achieves fully identity-verified workload isolation when substrate-independent defense-in-depth (container and PaaS achieving equivalent protection through the same platform stack) operates within three-pillar security convergence (identity, governance, and network all consistently configured).
Azure comprehensive workload security requires independently configuring five enforcement dimensions that decompose into two orthogonal planes: the access plane (identity via Entra, authorization via RBAC, governance via Policy) and the protection plane (network isolation via LB/NSG/Private Link, encryption at-rest and in-transit) — any unconfigured dimension creates a gap regardless of the others.
Azure Spot VMs combined with VMSS Flexible orchestration form a viable mixed-instance production workload model: the compound constraint envelope (eviction with ~30s notice, separate quota pool, no B-series, no conversion after creation) is manageable when Flexible orchestration mixes Spot and on-demand instances in the same scale set for graceful degradation under eviction pressure.
Azure Storage provides defense-in-depth with automatic encryption at rest (optionally customer-managed keys via Key Vault) and firewall rules that block all requests by default until exceptions are explicitly added — unless the workload relies on Resource Manager locks for data protection, since locks prevent account deletion but do not prevent data deletion within the account, leaving a gap between perceived and actual protection.
Azure Storage provides full read-access geo-redundancy (RA-GRS/RA-GZRS) across all storage types, enabling read access to secondaries during primary region outages.
Azure tier selection creates a three-way constraint between cost floor, security ceiling, and operational capability: the progressive tier pattern sets a minimum price to unlock required features (Premium for Private Link, Enterprise for modules), reservations provide partial compute-only savings within the chosen tier, and security isolation capabilities (network isolation, encryption options) are gated by the same tier — optimizing any two necessarily constrains the third.
Azure workload isolation achieves complete coverage across all five security enforcement dimensions — network infrastructure isolation through secrets delivery mapping onto identity, governance, network, data protection, and compute boundaries — when the end-to-end isolation chain from network to secrets is fully intact across all enforcement planes.
End-to-end workload isolation from infrastructure network layer through secrets delivery is achievable independently of compute substrate: the zero-trust infrastructure stack (default-deny LB + NSG filtering) extends via Private Link to PaaS boundaries, and both AKS and App Service inject secrets through the same Key Vault + managed identity stack operating within that isolation boundary — creating a continuous isolation chain from network edge to application runtime.
Both container (AKS) and PaaS (App Service) compute substrates achieve equivalent defense-in-depth through the same underlying Azure platform stack — identity-driven secret injection, private-endpoint network isolation, and orthogonal governance enforcement — making workload security posture independent of compute substrate choice.
Azure SQL automated backups achieve uniform 3–4x compression across full, differential, and transaction log backup types at the configured frequency.
Azure SQL provides comprehensive backup resilience spanning short-term PITR and long-term retention up to 10 years across all three availability models, with Service Fabric managing automatic failover and health monitoring — unless cross-subscription restore is needed, which is not supported for any restore type (PITR, geo-restore, or LTR), requiring a disruptive restore-then-copy workaround.
Azure SQL migration achieves full data protection when tier-constrained path selection (MI for lift-and-shift, Hyperscale for scale) combines with three-layer cryptographic integrity (three encryption layers plus ledger tamper-evidence plus row-level security) — unless the target tier's backup retention ceiling creates a recovery gap.
Container platform from ACR registry to AKS runtime achieves fully Entra-identity-verified defense-in-depth across all security layers — supply chain integrity (content trust + Notary V2 signing) with end-to-end network isolation (Private Link backbone routing + per-resource mapping) and identity-integrated secrets management (managed identity→Key Vault lifecycle) — when all authentication flows consistently use the Entra model.
Container supply chain from ACR to AKS achieves unified Entra-based identity verification: registry authentication, image pull, and deployment authorization all flow through the same Entra identity model with lifecycle-managed credentials.
Azure identity and secrets management form an integrated lifecycle that must be designed together: Entra's dual-model identity system provides authentication (app registrations for multi-tenant, managed identities for Azure-native), while Key Vault's defense-in-depth lifecycle (tiered FIPS + layered deletion protection) secures the cryptographic material accessed via those identities.
Event Hubs Kafka interoperability is production-feature-complete: existing workloads migrate without code changes, cross-protocol produce/consume works natively, and at-least-once delivery semantics match standard Kafka behavior — with no feature gaps blocking production adoption.
Event Hubs provides seamless Kafka migration combining full protocol interoperability (no code changes required) with simplified networking (single virtual IP endpoint instead of per-broker addressing) and tier-gated access.
Azure Functions supports full network isolation with private endpoints, VNet integration, and subnet-scoped outbound control across Premium and Dedicated hosting plans.
Key Vault RBAC provides complete fine-grained access control with separate permission boundaries for keys, secrets, and certificates, replacing legacy access policies that lack PIM support and have known vulnerabilities — unless the workload uses Managed HSM, which has its own access control model entirely outside vault RBAC.
Azure Load Balancer provides a complete Layer-4 traffic model with ultra-low latency pass-through architecture (no TLS termination, no proxy) handling all transport-layer protocols.
Redis Enterprise Flash provides a complete high-performance caching platform combining progressive tier capabilities with extended non-volatile memory range (300GB–4.5TB) and full module ecosystem.
Azure Service Bus Premium provides a complete JMS 2.0 messaging platform with dedicated messaging unit isolation (1, 2, 4, 8, or 16 MUs), AMQP 1.0 wire protocol, and triple-redundant storage — unless the workload depends on large message batching, which Service Bus does not support, requiring application-level message chunking as a workaround.
Azure Service Bus Premium provides enterprise messaging with full geographic replication (metadata and data) and dedicated resource isolation (1–16 messaging units per namespace).
Azure Service Bus provides reliable messaging with three complementary guarantees: duplicate detection prevents double-processing at the broker level, Peek Lock ensures at-least-once delivery via two-stage receive, and message sessions enable strict FIFO ordering — but falls short of exactly-once without application-level deduplication logic.
VNet peering provides full load balancer reachability across regions with latency parity to single-VNet deployments within the same region.