--- schema_version: "1.0" project_name: "reasons" updated_at: "2026-06-05T02:22:59+00:00" node_count: 1830 generator: ftl-reasons/0.43.0 --- # Belief Registry ## Repos - Date: 2026-03-11 - Source: entries/2026/03/11/waf-security.md - Source hash: 8d4db94cc716a02a ## Claims ### acr-admin-account-disabled-by-default [IN] OBSERVATION The ACR admin account is disabled by default, has two independently regenerable passwords, and is not recommended for production or multi-user scenarios. - Source: entries/2026/03/11/acr-authentication.md - Source hash: 40b120fe7745132a - Date: 2026-03-11 ### acr-admin-account-disabled-by-default-two-passwords [IN] OBSERVATION 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. - Source: entries/2026/03/11/acr-authentication.md - Source hash: 40b120fe7745132a - Date: 2026-03-11 ### acr-admin-password-regen-60-seconds [IN] OBSERVATION ACR admin account password regeneration takes approximately 60 seconds to replicate. - Source: entries/2026/03/11/acr-authentication.md - Source hash: 40b120fe7745132a - Date: 2026-03-11 ### acr-admin-password-regeneration-60-seconds [IN] OBSERVATION Password regeneration for ACR admin accounts takes approximately 60 seconds to replicate. - Source: entries/2026/03/11/acr-authentication.md - Source hash: 40b120fe7745132a - Date: 2026-03-11 ### acr-all-transfers-https-tls [IN] OBSERVATION All ACR image transfers use HTTPS with TLS encryption. - Source: entries/2026/03/11/acr-overview.md - Source hash: 1049dd5525df627e - Date: 2026-03-11 ### acr-api-rate-limits-per-replica [IN] OBSERVATION ACR API rate limits (throttling) apply independently per geo-replica, not globally across the registry. - Source: entries/2026/03/11/acr-geo-replication.md - Source hash: b1260d73ca116959 - Date: 2026-03-11 ### acr-auth-entra-service-principal-admin [IN] OBSERVATION ACR authentication options are Azure identity, Microsoft Entra service principal, or admin account; all image transfers use HTTPS with TLS. - Source: entries/2026/03/11/acr-overview.md - Source hash: 1049dd5525df627e - Date: 2026-03-11 ### acr-auth-token-valid-3-hours [IN] OBSERVATION The access token from `az acr login` is valid for 3 hours and must be renewed. - Source: entries/2026/03/11/acr-authentication.md - Source hash: 40b120fe7745132a - Date: 2026-03-11 ### acr-authentication-entra-service-principal-admin [IN] OBSERVATION ACR authentication options are Azure identity, Microsoft Entra service principal, or admin account. - Source: entries/2026/03/11/acr-overview.md - Source hash: 1049dd5525df627e - Date: 2026-03-11 ### acr-best-practice-same-region-as-deployments [IN] OBSERVATION Best practice is to create an ACR registry in the same Azure region as deployment targets for network-close storage and reduced latency. - Source: entries/2026/03/11/acr-overview.md - Source hash: 1049dd5525df627e - Date: 2026-03-11 ### acr-content-trust-premium-only [IN] OBSERVATION Content trust (image tag signing) in ACR is a Premium-only feature. - Source: entries/2026/03/11/acr-overview.md - Source hash: 1049dd5525df627e - Date: 2026-03-11 ### acr-dedicated-resource-group-recommended [IN] OBSERVATION ACR registries should be placed in a dedicated resource group to avoid accidental deletion when cleaning up container host resources. - Source: entries/2026/03/11/acr-best-practices.md - Source hash: 70474533d4130f6b - Date: 2026-03-11 ### acr-disabled-replica-still-syncs-and-costs [IN] OBSERVATION Disabling `--region-endpoint-enabled` on an ACR geo-replica excludes it from global routing but data still syncs and storage costs still accrue. - Source: entries/2026/03/11/acr-geo-replication.md - Source hash: b1260d73ca116959 - Date: 2026-03-11 ### acr-docker-command-env-var-alternative-tools [IN] OBSERVATION The `DOCKER_COMMAND` environment variable can be set to switch `az acr login` to alternative container tools like podman. - Source: entries/2026/03/11/acr-authentication.md - Source hash: 40b120fe7745132a - Date: 2026-03-11 ### acr-docker-command-env-var-podman [IN] OBSERVATION The `DOCKER_COMMAND` environment variable can be set to switch `az acr login` to use alternative container tools like `podman`. - Source: entries/2026/03/11/acr-authentication.md - Source hash: 40b120fe7745132a - Date: 2026-03-11 ### acr-expose-token-username-all-zeros [IN] OBSERVATION When using `az acr login --expose-token`, the username for `docker login` is the all-zeros GUID `00000000-0000-0000-0000-000000000000`. - Source: entries/2026/03/11/acr-authentication.md - Source hash: 40b120fe7745132a - Date: 2026-03-11 ### acr-five-authentication-methods [IN] OBSERVATION ACR supports five authentication methods: individual Microsoft Entra identity, service principal, managed identity, admin user, and non-Microsoft Entra token-based permissions. - Source: entries/2026/03/11/acr-authentication.md - Source hash: 40b120fe7745132a - Date: 2026-03-11 ### acr-geo-api-rate-limits-per-replica [IN] OBSERVATION ACR API rate limits (read/write throttling) apply independently to each geo-replica. - Source: entries/2026/03/11/acr-geo-replication.md - Source hash: b1260d73ca116959 - Date: 2026-03-11 ### acr-geo-home-region-outage-blocks-property-changes [IN] OBSERVATION 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. - Source: entries/2026/03/11/acr-geo-replication.md - Source hash: b1260d73ca116959 - Date: 2026-03-11 ### acr-geo-replica-zone-redundancy-auto-enabled [IN] OBSERVATION Zone redundancy is automatically enabled for ACR geo-replicas in regions that support it. - Source: entries/2026/03/11/acr-geo-replication.md - Source hash: b1260d73ca116959 - Date: 2026-03-11 ### acr-geo-replicated-storage-usage-home-region-only [IN] OBSERVATION Storage usage in a geo-replicated ACR is reported for the home region only; multiply by replica count for total consumption. - Source: entries/2026/03/11/acr-best-practices.md - Source hash: 70474533d4130f6b - Date: 2026-03-11 ### acr-geo-replication-active-active [IN] OBSERVATION ACR geo-replication uses an active-active model where all replicas are writable — push and pull work from any replica. - Source: entries/2026/03/11/acr-geo-replication.md - Source hash: b1260d73ca116959 - Date: 2026-03-11 ### acr-geo-replication-active-active-model [IN] OBSERVATION 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. - Source: entries/2026/03/11/acr-geo-replication.md - Source hash: b1260d73ca116959 - Date: 2026-03-11 ### acr-geo-replication-eventual-consistency [IN] OBSERVATION ACR geo-replication uses eventual consistency — there is a replication lag window after push before content appears in all replicas. - Source: entries/2026/03/11/acr-geo-replication.md - Source hash: b1260d73ca116959 - Date: 2026-03-11 ### acr-geo-replication-operational-constraints [IN] OBSERVATION 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-premium-sku-only [IN] OBSERVATION ACR geo-replication requires the Premium SKU. - Source: entries/2026/03/11/acr-geo-replication.md - Source hash: b1260d73ca116959 - Date: 2026-03-11 ### acr-geo-replication-requires-premium [IN] OBSERVATION ACR geo-replication requires the Premium SKU. - Source: entries/2026/03/11/acr-best-practices.md - Source hash: 70474533d4130f6b - Date: 2026-03-11 ### acr-geo-replication-requires-premium-sku [IN] OBSERVATION ACR geo-replication requires the Premium SKU. - Source: entries/2026/03/11/acr-best-practices.md - Source hash: 70474533d4130f6b - Date: 2026-03-11 ### acr-geo-storage-usage-home-region-only [IN] OBSERVATION Storage usage in a geo-replicated ACR is reported for the home region only; multiply by replica count for total consumption. - Source: entries/2026/03/11/acr-best-practices.md - Source hash: 70474533d4130f6b - Date: 2026-03-11 ### acr-global-endpoint-routes-by-network-performance [IN] OBSERVATION The ACR global endpoint (`myregistry.azurecr.io`) routes to the geo-replica with the best network performance, not necessarily geographic proximity. - Source: entries/2026/03/11/acr-geo-replication.md - Source hash: b1260d73ca116959 - Date: 2026-03-11 ### acr-home-region-outage-blocks-property-changes [IN] OBSERVATION 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. - Source: entries/2026/03/11/acr-geo-replication.md - Source hash: b1260d73ca116959 - Date: 2026-03-11 ### acr-included-storage-basic-10-standard-100-premium-500 [IN] OBSERVATION ACR included storage: Basic 10 GiB, Standard 100 GiB, Premium 500 GiB; additional storage billed per-GiB. - Source: entries/2026/03/11/acr-skus.md - Source hash: d054f451541c8df4 - Date: 2026-03-11 ### acr-login-token-valid-3-hours [IN] OBSERVATION Individual login tokens from `az acr login` are valid for 3 hours and must be renewed. - Source: entries/2026/03/11/acr-authentication.md - Source hash: 40b120fe7745132a - Date: 2026-03-11 ### acr-max-image-layer-200gib-manifest-4mib [IN] OBSERVATION ACR max image layer size is 200 GiB and max manifest size is 4 MiB across all SKUs. - Source: entries/2026/03/11/acr-skus.md - Source hash: d054f451541c8df4 - Date: 2026-03-11 ### acr-max-image-layer-size-200gib [IN] OBSERVATION ACR maximum image layer size is 200 GiB across all SKUs. - Source: entries/2026/03/11/acr-skus.md - Source hash: d054f451541c8df4 - Date: 2026-03-11 ### acr-max-storage-basic-standard-40tib-premium-100tib [IN] OBSERVATION ACR maximum storage limits: Basic/Standard max 40 TiB, Premium max 100 TiB. - Source: entries/2026/03/11/acr-skus.md - Source hash: d054f451541c8df4 - Date: 2026-03-11 ### acr-network-close-deployment-same-region [IN] OBSERVATION ACR should be placed in the same Azure region as container hosts to minimize latency and avoid cross-region egress fees. - Source: entries/2026/03/11/acr-best-practices.md - Source hash: 70474533d4130f6b - Date: 2026-03-11 ### acr-non-entra-tokens-basic-100-standard-500-premium-50000 [IN] OBSERVATION ACR non-Entra token limits: Basic 100, Standard 500, Premium 50,000. - Source: entries/2026/03/11/acr-skus.md - Source hash: d054f451541c8df4 - Date: 2026-03-11 ### acr-optimal-image-layer-count-5-to-10 [IN] OBSERVATION Optimal container image layer count for ACR is 5–10 layers, balancing layer reuse/caching against pull overhead. - Source: entries/2026/03/11/acr-best-practices.md - Source hash: 70474533d4130f6b - Date: 2026-03-11 ### acr-optimal-image-layers-5-to-10 [IN] OBSERVATION The optimal number of layers per container image is 5–10, balancing layer reuse/caching against pull overhead. - Source: entries/2026/03/11/acr-best-practices.md - Source hash: 70474533d4130f6b - Date: 2026-03-11 ### acr-premium-enterprise-feature-gate [IN] OBSERVATION 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 [IN] OBSERVATION 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. - Source: entries/2026/03/11/acr-skus.md - Source hash: d054f451541c8df4 - Date: 2026-03-11 ### acr-premium-exclusive-features-list [IN] OBSERVATION 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. - Source: entries/2026/03/11/acr-skus.md - Source hash: d054f451541c8df4 - Date: 2026-03-11 ### acr-premium-only-features [IN] OBSERVATION 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. - Source: entries/2026/03/11/acr-skus.md - Source hash: d054f451541c8df4 - Date: 2026-03-11 ### acr-premium-only-geo-replication-content-trust-private-endpoints [IN] OBSERVATION ACR Premium-only features include geo-replication, content trust (image tag signing), and private endpoints with private link. - Source: entries/2026/03/11/acr-overview.md - Source hash: 1049dd5525df627e - Date: 2026-03-11 ### acr-registry-dedicated-resource-group [IN] OBSERVATION Best practice: place ACR in a dedicated resource group to avoid accidental deletion when cleaning up container host resources. - Source: entries/2026/03/11/acr-best-practices.md - Source hash: 70474533d4130f6b - Date: 2026-03-11 ### acr-service-principal-password-default-1-year [IN] OBSERVATION ACR service principal passwords have a default expiry of 1 year. - Source: entries/2026/03/11/acr-authentication.md - Source hash: 40b120fe7745132a - Date: 2026-03-11 ### acr-service-principal-password-default-expiry-1-year [IN] OBSERVATION ACR service principal passwords have a default expiry of 1 year. - Source: entries/2026/03/11/acr-authentication.md - Source hash: 40b120fe7745132a - Date: 2026-03-11 ### acr-sku-change-no-downtime [IN] OBSERVATION 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). - Source: entries/2026/03/11/acr-skus.md - Source hash: d054f451541c8df4 - Date: 2026-03-11 ### acr-supports-docker-helm-oci-artifacts [IN] OBSERVATION ACR supports Docker container images (Windows and Linux), Helm charts, and OCI-format images. - Source: entries/2026/03/11/acr-overview.md - Source hash: 1049dd5525df627e - Date: 2026-03-11 ### acr-supports-oci-and-helm-charts [IN] OBSERVATION ACR supports Docker container images, OCI-format images, and Helm charts as stored artifacts. - Source: entries/2026/03/11/acr-overview.md - Source hash: 1049dd5525df627e - Date: 2026-03-11 ### acr-tasks-trigger-on-commit-and-base-image-update [IN] OBSERVATION ACR Tasks can build container images on demand or automatically via triggers including source code commits and base image updates. - Source: entries/2026/03/11/acr-overview.md - Source hash: 1049dd5525df627e - Date: 2026-03-11 ### acr-three-sku-tiers [IN] OBSERVATION Azure Container Registry offers three SKU tiers: Basic (dev/test), Standard (most production), and Premium (high-volume/enterprise). - Source: entries/2026/03/11/acr-overview.md - Source hash: 1049dd5525df627e - Date: 2026-03-11 ### acr-three-skus-basic-standard-premium [IN] OBSERVATION ACR offers three SKU tiers: Basic (dev/test), Standard (production), Premium (high-volume/enterprise). - Source: entries/2026/03/11/acr-skus.md - Source hash: d054f451541c8df4 - Date: 2026-03-11 ### acr-throttling-http-429-exponential-backoff [IN] OBSERVATION ACR returns HTTP 429 errors during high request volume; mitigate with retry logic, exponential backoff, and reducing concurrency. - Source: entries/2026/03/11/acr-skus.md - Source hash: d054f451541c8df4 - Date: 2026-03-11 ### acr-token-permissions-no-entra-rbac [IN] OBSERVATION ACR token-based repository permissions are not integrated with Microsoft Entra ID and do not support RBAC role assignments. - Source: entries/2026/03/11/acr-authentication.md - Source hash: 40b120fe7745132a - Date: 2026-03-11 ### acr-token-permissions-not-entra-rbac [IN] OBSERVATION ACR token-based repository permissions are not integrated with Microsoft Entra ID and do not support RBAC role assignments. - Source: entries/2026/03/11/acr-authentication.md - Source hash: 40b120fe7745132a - Date: 2026-03-11 ### acr-untagged-manifest-retention-policy [IN] OBSERVATION Untagged (dangling/orphaned) container images in ACR can be managed via a retention policy for untagged manifests. - Source: entries/2026/03/11/acr-best-practices.md - Source hash: 70474533d4130f6b - Date: 2026-03-11 ### acr-untagged-manifests-retention-policy [IN] OBSERVATION Untagged (dangling/orphaned) container images in ACR can be managed via a retention policy for untagged manifests. - Source: entries/2026/03/11/acr-best-practices.md - Source hash: 70474533d4130f6b - Date: 2026-03-11 ### acr-webhooks-basic-2-standard-10-premium-500 [IN] OBSERVATION ACR webhook limits: Basic 2, Standard 10, Premium 500. - Source: entries/2026/03/11/acr-skus.md - Source hash: d054f451541c8df4 - Date: 2026-03-11 ### aks-api-server-guard-throttles-non-system [IN] OBSERVATION 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. - Source: entries/2026/03/11/aks-scaling.md - Source hash: 702f7cac1d8bd152 - Date: 2026-03-11 ### aks-api-server-guard-throttling [IN] OBSERVATION 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. - Source: entries/2026/03/10/aks-scaling.md - Source hash: efeece6890d5beba - Date: 2026-03-11 ### aks-api-server-public-by-default [IN] OBSERVATION The AKS API server is public by default; access can be restricted via authorized IP ranges or by creating a private cluster. - Source: entries/2026/03/10/aks-security.md - Source hash: 9e88c3c016f40527 - Date: 2026-03-10 ### aks-apiserver-guard-throttles-non-system [IN] OBSERVATION 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. - Source: entries/2026/03/11/aks-scaling.md - Source hash: 702f7cac1d8bd152 - Date: 2026-03-11 ### aks-apiserver-guard-throttling [IN] OBSERVATION 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. - Source: entries/2026/03/10/aks-scaling.md - Source hash: efeece6890d5beba - Date: 2026-03-11 ### aks-apparmor-seccomp-container-restriction [IN] OBSERVATION AKS supports AppArmor and seccomp profiles to restrict container actions following the principle of least privilege. - Source: entries/2026/03/10/aks-security.md - Source hash: 9e88c3c016f40527 - Date: 2026-03-11 ### aks-apparmor-seccomp-container-restrictions [IN] OBSERVATION AKS supports AppArmor and seccomp profiles to restrict container actions following the least-privilege principle. - Source: entries/2026/03/10/aks-security.md - Source hash: 9e88c3c016f40527 - Date: 2026-03-11 ### aks-azure-disk-readwriteonce [IN] OBSERVATION Azure Disk volumes in AKS are mounted as ReadWriteOnce (single node); Azure Files supports ReadWriteMany (multi-node) - Source: entries/2026/03/10/aks-storage.md - Source hash: 2e3c2adbaaad9035 - Date: 2026-03-10 ### aks-azure-disks-single-pod-files-multi-pod [IN] OBSERVATION Azure Disks CSI provides single-pod access; Azure Files CSI provides multiple concurrent pod access. - Source: entries/2026/03/10/aks-overview.md - Source hash: 3214c74f62a2db31 - Date: 2026-03-10 ### aks-azure-files-smb-311-nfs-41 [IN] OBSERVATION Azure Files CSI driver supports SMB 3.1.1 and NFS 4.1 protocols, enabling multi-node and multi-pod concurrent access. - Source: entries/2026/03/11/aks-storage.md - Source hash: 7425bded78249c68 - Date: 2026-03-11 ### aks-bring-your-own-cni-supported [IN] OBSERVATION AKS supports bring-your-own CNI for third-party networking plugins in addition to Azure-provided CNI options. - Source: entries/2026/03/10/aks-overview.md - Source hash: 3214c74f62a2db31 - Date: 2026-03-11 ### aks-cncf-certified [IN] OBSERVATION AKS is a CNCF-certified conformant Kubernetes distribution. - Source: entries/2026/03/10/aks-overview.md - Source hash: 3214c74f62a2db31 - Date: 2026-03-10 ### aks-cncf-certified-conformance [IN] OBSERVATION AKS is CNCF-certified, meaning it passes Kubernetes conformance testing. - Source: entries/2026/03/11/aks-overview.md - Source hash: 037904afa6a5387f - Date: 2026-03-11 ### aks-cncf-certified-kubernetes [IN] OBSERVATION AKS is CNCF-certified, meaning it passes official Kubernetes conformance testing. - Source: entries/2026/03/11/aks-overview.md - Source hash: 037904afa6a5387f - Date: 2026-03-11 ### aks-compliance-soc-iso-pci-hipaa [IN] OBSERVATION AKS is compliant with SOC, ISO, PCI DSS, and HIPAA standards. - Source: entries/2026/03/10/aks-overview.md - Source hash: 3214c74f62a2db31 - Date: 2026-03-10 ### aks-confidential-computing-hardware-tee [IN] OBSERVATION AKS supports confidential computing nodes that run containers in hardware-based trusted execution environments (TEE). - Source: entries/2026/03/11/aks-overview.md - Source hash: 037904afa6a5387f - Date: 2026-03-11 ### aks-confidential-containers-sev-snp [IN] OBSERVATION AKS Confidential Containers (preview) use Kata-based isolation with AMD SEV-SNP hardware memory encryption to prevent clear-text memory access. - Source: entries/2026/03/10/aks-security.md - Source hash: 9e88c3c016f40527 - Date: 2026-03-10 ### aks-containerd-only-runtime [IN] OBSERVATION containerd is the sole supported container runtime in AKS for Linux (Kubernetes 1.19+) and Windows (Kubernetes 1.23+). - Source: entries/2026/03/10/aks-concepts-clusters.md - Source hash: a9eb987365010a52 - Date: 2026-03-10 ### aks-control-plane-free [IN] OBSERVATION The AKS control plane is provided at no cost; users only pay for worker nodes. - Source: entries/2026/03/10/aks-overview.md - Source hash: 3214c74f62a2db31 - Date: 2026-03-10 ### aks-control-plane-managed-by-azure [IN] OBSERVATION 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. - Source: entries/2026/03/10/aks-concepts-clusters.md - Source hash: a9eb987365010a52 - Date: 2026-03-10 ### aks-control-plane-scaling-multi-dimensional [IN] OBSERVATION AKS control plane scaling is multi-dimensional — scaling one dimension (e.g., pod count) reduces capacity in others (e.g., pod churn rate). - Source: entries/2026/03/11/aks-scaling.md - Source hash: 702f7cac1d8bd152 - Date: 2026-03-11 ### aks-control-plane-scaling-multidimensional [IN] OBSERVATION 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). - Source: entries/2026/03/11/aks-scaling.md - Source hash: 702f7cac1d8bd152 - Date: 2026-03-11 ### aks-csi-default-1-21-intree-removed-1-26 [IN] OBSERVATION CSI drivers are default in AKS from Kubernetes 1.21; in-tree driver support removed from Kubernetes 1.26 - Source: entries/2026/03/10/aks-storage.md - Source hash: 2e3c2adbaaad9035 - Date: 2026-03-10 ### aks-custom-vnet-nsg-ports-443-4443-9988 [IN] OBSERVATION 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. - Source: entries/2026/03/10/aks-networking.md - Source hash: ee1b8af5cbdfad92 - Date: 2026-03-11 ### aks-custom-vnet-nsg-required-ports [IN] OBSERVATION 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. - Source: entries/2026/03/11/aks-networking.md - Source hash: 84d67eb57a4b5c58 - Date: 2026-03-11 ### aks-custom-vnet-nsg-tcp-443-4443-9988 [IN] OBSERVATION 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. - Source: entries/2026/03/11/aks-networking.md - Source hash: 84d67eb57a4b5c58 - Date: 2026-03-11 ### aks-custom-vnet-zero-trust-control-plane [IN] OBSERVATION 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-default-ephemeral-os-disk [IN] OBSERVATION AKS defaults to ephemeral OS disks when the VM SKU supports them - Source: entries/2026/03/10/aks-storage.md - Source hash: 2e3c2adbaaad9035 - Date: 2026-03-10 ### aks-default-namespaces-four [IN] OBSERVATION AKS clusters include four default namespaces: `default`, `kube-node-lease`, `kube-public`, and `kube-system`. - Source: entries/2026/03/11/aks-concepts-clusters.md - Source hash: b31e5c8943b60e69 - Date: 2026-03-11 ### aks-default-os-ubuntu-linux [IN] OBSERVATION The default operating system for AKS nodes is Ubuntu Linux; Azure Linux and Windows Server 2022 are also available as options. - Source: entries/2026/03/10/aks-concepts-clusters.md - Source hash: a9eb987365010a52 - Date: 2026-03-11 ### aks-default-outbound-access-retirement-march-2026 [IN] OBSERVATION Default outbound internet access for AKS-managed VNet clusters retires March 31, 2026 (defaultOutboundAccess=false); BYO VNet clusters are unaffected. - Source: entries/2026/03/10/aks-networking.md - Source hash: ee1b8af5cbdfad92 - Date: 2026-03-10 ### aks-default-storage-class-managed-csi [IN] OBSERVATION AKS default storage class is `managed-csi` backed by Standard SSD LRS - Source: entries/2026/03/10/aks-storage.md - Source hash: 2e3c2adbaaad9035 - Date: 2026-03-10 ### aks-default-storage-classes-reconciled [IN] OBSERVATION AKS reconciles built-in default storage classes — manual changes to them are overwritten by the platform. - Source: entries/2026/03/11/aks-storage.md - Source hash: 7425bded78249c68 - Date: 2026-03-11 ### aks-do-not-deploy-apps-to-kube-system [IN] OBSERVATION Applications should not be deployed to the kube-system namespace in AKS; it is reserved for critical system pods. - Source: entries/2026/03/10/aks-concepts-clusters.md - Source hash: a9eb987365010a52 - Date: 2026-03-11 ### aks-do-not-modify-nic-level-nsgs [IN] OBSERVATION AKS auto-manages NIC-level NSGs; users must not modify them. Custom traffic rules should use subnet-level NSGs instead. - Source: entries/2026/03/10/aks-security.md - Source hash: 9e88c3c016f40527 - Date: 2026-03-10 ### aks-egress-unrestricted-by-default [IN] OBSERVATION AKS clusters have unrestricted outbound internet access by default, but it can be restricted via outbound type configuration. - Source: entries/2026/03/10/aks-networking.md - Source hash: ee1b8af5cbdfad92 - Date: 2026-03-10 ### aks-ephemeral-os-disk-requires-128gib-temp [IN] OBSERVATION Ephemeral OS disk default sizing in AKS requires the VM SKU to have at least 128 GiB of temporary storage. - Source: entries/2026/03/11/aks-storage.md - Source hash: 7425bded78249c68 - Date: 2026-03-11 ### aks-etcd-secrets-encryption-customer-keys [IN] OBSERVATION Secrets stored in etcd can be encrypted at rest using customer-managed keys via AKS KMS etcd encryption. - Source: entries/2026/03/10/aks-security.md - Source hash: 9e88c3c016f40527 - Date: 2026-03-10 ### aks-flat-network-no-snat-pod-ip-visible [IN] OBSERVATION 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. - Source: entries/2026/03/11/aks-networking.md - Source hash: 84d67eb57a4b5c58 - Date: 2026-03-11 ### aks-flatcar-immutable-cross-cloud-selinux [IN] OBSERVATION Flatcar Container Linux (preview) is a vendor-neutral, CNCF-based immutable container OS with SELinux, usable cross-cloud on AKS. - Source: entries/2026/03/11/aks-security.md - Source hash: 6ab7bfd9e7cc03b4 - Date: 2026-03-11 ### aks-flatcar-immutable-os-selinux [IN] OBSERVATION Flatcar Container Linux (preview) is a vendor-neutral, CNCF-based immutable OS using SELinux, cross-cloud compatible, with cryptographic integrity protection. - Source: entries/2026/03/11/aks-security.md - Source hash: 6ab7bfd9e7cc03b4 - Date: 2026-03-11 ### aks-hpa-requires-metrics-server [IN] OBSERVATION The Horizontal Pod Autoscaler requires Metrics Server to be deployed in the cluster (available since Kubernetes 1.8+). - Source: entries/2026/03/10/aks-scaling.md - Source hash: efeece6890d5beba - Date: 2026-03-11 ### aks-immutable-os-guard-fips-selinux [IN] OBSERVATION Azure Linux OS Guard (preview) is an immutable, read-only OS that enforces FIPS + Trusted Launch and uses SELinux for mandatory access control. - Source: entries/2026/03/11/aks-security.md - Source hash: 6ab7bfd9e7cc03b4 - Date: 2026-03-11 ### aks-immutable-os-options-os-guard-flatcar [IN] OBSERVATION 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. - Source: entries/2026/03/10/aks-security.md - Source hash: 9e88c3c016f40527 - Date: 2026-03-11 ### aks-istio-service-mesh-addon [IN] OBSERVATION AKS offers an Istio-based service mesh add-on as a managed option. - Source: entries/2026/03/11/aks-overview.md - Source hash: 037904afa6a5387f - Date: 2026-03-11 ### aks-kube-proxy-every-node [IN] OBSERVATION kube-proxy runs on every AKS node to provide network features. - Source: entries/2026/03/10/aks-networking.md - Source hash: ee1b8af5cbdfad92 - Date: 2026-03-10 ### aks-managed-disks-encrypted-at-rest [IN] OBSERVATION AKS node storage uses Azure Managed Disks with automatic encryption at rest. - Source: entries/2026/03/10/aks-security.md - Source hash: 9e88c3c016f40527 - Date: 2026-03-10 ### aks-managed-helm-prefix [IN] OBSERVATION AKS manages Helm releases prefixed with `aks-managed` and labels managed components with `kubernetes.azure.com/managedby: aks`. - Source: entries/2026/03/10/aks-concepts-clusters.md - Source hash: a9eb987365010a52 - Date: 2026-03-11 ### aks-managed-helm-releases-prefix [IN] OBSERVATION AKS-managed Helm releases use the `aks-managed` prefix; increasing revision counts on these are expected and safe. - Source: entries/2026/03/11/aks-concepts-clusters.md - Source hash: b31e5c8943b60e69 - Date: 2026-03-11 ### aks-managed-os-disk-sizing-by-vcpu [IN] OBSERVATION AKS managed OS disk defaults scale by vCPU count: 1-7→P10/128G, 8-15→P15/256G, 16-63→P20/512G, 64+→P30/1024G - Source: entries/2026/03/10/aks-storage.md - Source hash: 2e3c2adbaaad9035 - Date: 2026-03-10 ### aks-multi-az-zrs-default-k8s-1-29 [IN] OBSERVATION AKS multi-AZ clusters default to ZRS storage from Kubernetes 1.29 - Source: entries/2026/03/10/aks-storage.md - Source hash: 2e3c2adbaaad9035 - Date: 2026-03-10 ### aks-nap-based-on-karpenter [IN] OBSERVATION Node Autoprovisioning (NAP) is a preview feature based on Karpenter that dynamically selects optimal VM SKU and quantity for pending pod requirements. - Source: entries/2026/03/10/aks-scaling.md - Source hash: efeece6890d5beba - Date: 2026-03-10 ### aks-network-policies-pod-level [IN] OBSERVATION Kubernetes network policies control pod-to-pod traffic based on labels, namespace, or port; NSGs control node-level traffic. - Source: entries/2026/03/10/aks-networking.md - Source hash: ee1b8af5cbdfad92 - Date: 2026-03-10 ### aks-node-authorization-default-1-24 [IN] OBSERVATION Node authorization is enabled by default on AKS 1.24+, authorizing kubelet API requests to protect against East-West attacks. - Source: entries/2026/03/10/aks-security.md - Source hash: 9e88c3c016f40527 - Date: 2026-03-10 ### aks-node-pools-backed-by-vmss [IN] OBSERVATION AKS node pools are backed by Azure VM scale sets (VMSS), and during scale-down the VMSS API determines which nodes are removed. - Source: entries/2026/03/10/aks-concepts-clusters.md - Source hash: a9eb987365010a52 - Date: 2026-03-11 ### aks-node-resource-reservations [IN] OBSERVATION AKS reserves CPU and memory on each node for system functions, so allocatable resources are less than total node resources. - Source: entries/2026/03/10/aks-concepts-clusters.md - Source hash: a9eb987365010a52 - Date: 2026-03-10 ### aks-nodes-no-public-ip [IN] OBSERVATION AKS nodes have no public IP addresses by default and are deployed to private subnets. - Source: entries/2026/03/10/aks-security.md - Source hash: 9e88c3c016f40527 - Date: 2026-03-10 ### aks-notary-v2-image-signatures [IN] OBSERVATION AKS supports Notary V2 for attaching and verifying container image signatures in the registry as part of the secure supply chain. - Source: entries/2026/03/11/aks-security.md - Source hash: 6ab7bfd9e7cc03b4 - Date: 2026-03-11 ### aks-notary-v2-image-signing [IN] OBSERVATION AKS supports Notary V2 to attach signatures to container images for trusted deployment verification. - Source: entries/2026/03/10/aks-security.md - Source hash: 9e88c3c016f40527 - Date: 2026-03-11 ### aks-nsg-auto-configured-for-loadbalancer [IN] OBSERVATION Azure auto-configures NSG rules when LoadBalancer Services are created in AKS; no manual NSG configuration needed for standard scenarios. - Source: entries/2026/03/10/aks-networking.md - Source hash: ee1b8af5cbdfad92 - Date: 2026-03-10 ### aks-nvme-data-disks-ephemeral [IN] OBSERVATION Ephemeral NVMe data disks in AKS provide high-performance temporary storage; data is lost on deallocation and they are managed via Azure Container Storage. - Source: entries/2026/03/11/aks-storage.md - Source hash: 7425bded78249c68 - Date: 2026-03-11 ### aks-nvme-data-disks-ephemeral-container-storage [IN] OBSERVATION NVMe data disks in AKS are ephemeral (data lost on deallocation) and are managed via Azure Container Storage. - Source: entries/2026/03/11/aks-storage.md - Source hash: 7425bded78249c68 - Date: 2026-03-11 ### aks-os-disk-size-immutable [IN] OBSERVATION AKS OS disk size cannot be changed after cluster or node pool creation - Source: entries/2026/03/10/aks-storage.md - Source hash: 2e3c2adbaaad9035 - Date: 2026-03-10 ### aks-os-guard-immutable-fips-selinux [IN] OBSERVATION Azure Linux OS Guard (preview) is a Microsoft-created immutable container OS that enforces FIPS + Trusted Launch and uses SELinux for mandatory access control. - Source: entries/2026/03/11/aks-security.md - Source hash: 6ab7bfd9e7cc03b4 - Date: 2026-03-11 ### aks-overlay-vs-flat-networking [IN] OBSERVATION 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). - Source: entries/2026/03/10/aks-networking.md - Source hash: ee1b8af5cbdfad92 - Date: 2026-03-10 ### aks-pv-not-shared-windows-linux [IN] OBSERVATION Persistent volumes cannot be shared between Windows and Linux pods in AKS - Source: entries/2026/03/10/aks-storage.md - Source hash: 2e3c2adbaaad9035 - Date: 2026-03-10 ### aks-pv-pvc-binding-one-to-one [IN] OBSERVATION Persistent Volume (PV) to Persistent Volume Claim (PVC) binding is a 1:1 mapping in Kubernetes. - Source: entries/2026/03/11/aks-storage.md - Source hash: 7425bded78249c68 - Date: 2026-03-11 ### aks-pv-to-pvc-binding-one-to-one [IN] OBSERVATION Persistent Volume (PV) to Persistent Volume Claim (PVC) binding in Kubernetes is a 1:1 mapping — each PV binds to exactly one PVC. - Source: entries/2026/03/11/aks-storage.md - Source hash: 7425bded78249c68 - Date: 2026-03-11 ### aks-reconciles-default-storage-classes [IN] OBSERVATION AKS reconciles built-in default storage classes — manual changes to built-in classes are overwritten by the platform. - Source: entries/2026/03/10/aks-storage.md - Source hash: 2e3c2adbaaad9035 - Date: 2026-03-11 ### aks-registry-signatures-notary-v2 [IN] OBSERVATION Azure secure supply chain uses Notary V2 to attach signatures to container images for trusted deployment verification. - Source: entries/2026/03/11/aks-security.md - Source hash: 6ab7bfd9e7cc03b4 - Date: 2026-03-11 ### aks-secret-base64-encoding-not-encryption [IN] OBSERVATION 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. - Source: entries/2026/03/11/aks-security.md - Source hash: 6ab7bfd9e7cc03b4 - Date: 2026-03-11 ### aks-secret-manifests-base64-not-encrypted [IN] OBSERVATION Kubernetes Secret manifest files contain data in base64 format (encoding, not encryption) and should never be committed to source control. - Source: entries/2026/03/10/aks-security.md - Source hash: 9e88c3c016f40527 - Date: 2026-03-11 ### aks-secret-watches-expensive-control-plane [IN] OBSERVATION Watches on Kubernetes secrets are disproportionately expensive for the AKS control plane compared to watches on other resource types. - Source: entries/2026/03/11/aks-scaling.md - Source hash: 702f7cac1d8bd152 - Date: 2026-03-11 ### aks-secrets-base64-not-encrypted [IN] OBSERVATION Raw Kubernetes secret manifests contain data in base64 format, which is encoding, not encryption. - Source: entries/2026/03/11/aks-security.md - Source hash: 6ab7bfd9e7cc03b4 - Date: 2026-03-11 ### aks-secrets-base64-not-encryption [IN] OBSERVATION 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. - Source: entries/2026/03/11/aks-security.md - Source hash: 6ab7bfd9e7cc03b4 - Date: 2026-03-11 ### aks-ssh-internal-ip-default-disable-preview [IN] OBSERVATION AKS nodes have SSH enabled by default via internal IP only (no public IPs); disabling SSH entirely is available in preview. - Source: entries/2026/03/11/aks-security.md - Source hash: 6ab7bfd9e7cc03b4 - Date: 2026-03-11 ### aks-ssh-internal-ip-only-default [IN] OBSERVATION SSH on AKS nodes is enabled by default but accessible only via internal IP (no public IPs); SSH can be disabled in preview. - Source: entries/2026/03/11/aks-security.md - Source hash: 6ab7bfd9e7cc03b4 - Date: 2026-03-11 ### aks-storage-disks-single-files-multi-netapp-throughput-containerstore-block [IN] OBSERVATION 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). - Source: entries/2026/03/11/aks-overview.md - Source hash: 037904afa6a5387f - Date: 2026-03-11 ### aks-supply-chain-verification [IN] OBSERVATION 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-os-ubuntu-azurelinux-windows [IN] OBSERVATION AKS supported node operating systems are Ubuntu (default Linux), Azure Linux, and Windows Server 2022. - Source: entries/2026/03/11/aks-concepts-clusters.md - Source hash: b31e5c8943b60e69 - Date: 2026-03-11 ### aks-supported-os-ubuntu-default [IN] OBSERVATION AKS supports Ubuntu (default for Linux), Azure Linux, and Windows Server 2022 as node operating systems. - Source: entries/2026/03/11/aks-concepts-clusters.md - Source hash: b31e5c8943b60e69 - Date: 2026-03-11 ### aks-system-vs-user-node-pools [IN] OBSERVATION AKS distinguishes system node pools (hosting critical system pods like CoreDNS, konnectivity) from user node pools (hosting application workloads). - Source: entries/2026/03/10/aks-concepts-clusters.md - Source hash: a9eb987365010a52 - Date: 2026-03-10 ### aks-three-autoscaling-mechanisms [IN] OBSERVATION AKS supports three autoscaling mechanisms: cluster autoscaler (node-level), horizontal pod autoscaler (pod-level), and KEDA (event-driven). - Source: entries/2026/03/10/aks-overview.md - Source hash: 3214c74f62a2db31 - Date: 2026-03-10 ### aks-three-pricing-tiers [IN] OBSERVATION AKS has three pricing tiers: Free, Standard, and Premium. - Source: entries/2026/03/10/aks-concepts-clusters.md - Source hash: a9eb987365010a52 - Date: 2026-03-10 ### aks-trusted-launch-gen2-secure-boot-vtpm [IN] OBSERVATION AKS Trusted Launch requires Azure Gen2 VMs and combines secure boot with vTPM to verify boot chain integrity. - Source: entries/2026/03/11/aks-security.md - Source hash: 6ab7bfd9e7cc03b4 - Date: 2026-03-11 ### aks-two-cluster-modes [IN] OBSERVATION AKS has two cluster modes: Automatic (fully managed, preconfigured) and Standard (more control over node pools, scaling, settings). - Source: entries/2026/03/10/aks-concepts-clusters.md - Source hash: a9eb987365010a52 - Date: 2026-03-10 ### aks-two-resource-groups [IN] OBSERVATION AKS automatically creates two resource groups: one user-specified and one auto-created containing all infrastructure resources (VMs, VMSS, storage). - Source: entries/2026/03/10/aks-concepts-clusters.md - Source hash: a9eb987365010a52 - Date: 2026-03-10 ### aks-virtual-nodes-burst-to-aci [IN] OBSERVATION Virtual nodes enable bursting from AKS to Azure Container Instances (ACI) for rapid serverless pod scaling. - Source: entries/2026/03/10/aks-overview.md - Source hash: 3214c74f62a2db31 - Date: 2026-03-10 ### aks-virtual-nodes-separate-subnet [IN] OBSERVATION Virtual nodes (ACI burst) deploy into a separate subnet within the same VNet as the AKS cluster; no application modifications are required. - Source: entries/2026/03/10/aks-scaling.md - Source hash: efeece6890d5beba - Date: 2026-03-10 ### aks-vm-size-dynamic-selection [IN] OBSERVATION As of May 2025, AKS dynamically selects the default VM SKU based on available capacity and quota if not specified by the user. - Source: entries/2026/03/10/aks-concepts-clusters.md - Source hash: a9eb987365010a52 - Date: 2026-03-11 ### aks-vm-size-dynamically-selected [IN] OBSERVATION As of May 2025, AKS dynamically selects the default VM SKU based on available capacity and quota if no VM size is specified. - Source: entries/2026/03/10/aks-concepts-clusters.md - Source hash: a9eb987365010a52 - Date: 2026-03-11 ### aks-vmss-determines-scale-down-node-removal [IN] OBSERVATION For VMSS-backed AKS clusters, the VMSS API determines which nodes are removed during scale-down operations. - Source: entries/2026/03/10/aks-scaling.md - Source hash: efeece6890d5beba - Date: 2026-03-11 ### aks-waitforfirstconsumer-topology-aware [IN] OBSERVATION Setting `volumeBindingMode: WaitForFirstConsumer` on an AKS StorageClass enables topology-aware provisioning, delaying volume binding until a pod is scheduled. - Source: entries/2026/03/10/aks-storage.md - Source hash: 2e3c2adbaaad9035 - Date: 2026-03-11 ### aks-windows-containers-multi-os-node-pools [IN] OBSERVATION AKS supports Windows Server containers via multi-OS (Linux + Windows) node pools within a single cluster. - Source: entries/2026/03/11/aks-overview.md - Source hash: 037904afa6a5387f - Date: 2026-03-11 ### aks-windows-containers-multi-os-pools [IN] OBSERVATION AKS supports Windows Server containers via mixed OS (Linux + Windows) node pools within a single cluster. - Source: entries/2026/03/11/aks-overview.md - Source hash: 037904afa6a5387f - Date: 2026-03-11 ### aks-windows-server-containers-multi-os-node-pools [IN] OBSERVATION AKS supports Windows Server containers via multi-OS node pools within a single cluster. - Source: entries/2026/03/11/aks-overview.md - Source hash: 037904afa6a5387f - Date: 2026-03-11 ### aks-windows-volume-mount-drive-letter [IN] OBSERVATION Windows containers in AKS use drive letters for volume mount paths (e.g., `mountPath: "d:"`) instead of Unix-style paths. - Source: entries/2026/03/10/aks-storage.md - Source hash: 2e3c2adbaaad9035 - Date: 2026-03-11 ### appgw-backend-pool-cross-vnet-requires-peering-or-vpn [IN] OBSERVATION Application Gateway backend pool members in other VNets require VNet peering or VPN gateway for connectivity. - Source: entries/2026/03/11/appgw-components.md - Source hash: a92795409da11fe2 - Date: 2026-03-11 ### appgw-backend-pool-not-tied-availability-set [IN] OBSERVATION Application Gateway backend pool members are not tied to an availability set. - Source: entries/2026/03/11/appgw-components.md - Source hash: a92795409da11fe2 - Date: 2026-03-11 ### appgw-backend-pool-not-tied-to-availability-set [IN] OBSERVATION Application Gateway backend pool members are not tied to an availability set — they can be distributed freely. - Source: entries/2026/03/11/appgw-components.md - Source hash: a92795409da11fe2 - Date: 2026-03-11 ### appgw-backend-pool-not-tied-to-availability-sets [IN] OBSERVATION Application Gateway backend pool members are not tied to availability sets and can span cross-cluster, cross-datacenter, or outside Azure (requires IP connectivity). - Source: entries/2026/03/10/appgw-components.md - Source hash: f6ba324b1d3b161e - Date: 2026-03-11 ### appgw-cross-vnet-backend-requires-peering [IN] OBSERVATION Application Gateway backend pool members in other VNets require VNet peering or VPN gateway for connectivity. - Source: entries/2026/03/11/appgw-components.md - Source hash: a92795409da11fe2 - Date: 2026-03-11 ### appgw-cross-vnet-requires-peering-or-vpn [IN] OBSERVATION Application Gateway backend pool members in other VNets require VNet peering or VPN gateway for connectivity; on-premises backends need ExpressRoute or VPN tunnels. - Source: entries/2026/03/11/appgw-components.md - Source hash: a92795409da11fe2 - Date: 2026-03-11 ### appgw-custom-health-probes-per-backend [IN] OBSERVATION 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. - Source: entries/2026/03/11/appgw-components.md - Source hash: a92795409da11fe2 - Date: 2026-03-11 ### appgw-dns-name-stable-for-lifetime [IN] OBSERVATION Application Gateway DNS name is stable for the gateway's lifetime — use a CNAME alias pointing to it. - Source: entries/2026/03/10/appgw-components.md - Source hash: f6ba324b1d3b161e - Date: 2026-03-11 ### appgw-end-to-end-tls-via-http-settings [IN] OBSERVATION Application Gateway end-to-end TLS encryption is controlled by the HTTP settings component (port and protocol configuration to backend). - Source: entries/2026/03/10/appgw-components.md - Source hash: f6ba324b1d3b161e - Date: 2026-03-11 ### appgw-http2-disabled-by-default-client-only [IN] OBSERVATION Application Gateway HTTP/2 is disabled by default and works only between client and gateway (backend always HTTP/1.1) - Source: entries/2026/03/10/appgw-components.md - Source hash: f6ba324b1d3b161e - Date: 2026-03-10 ### appgw-layer-7-lb-layer-4 [IN] OBSERVATION Application Gateway is a Layer 7 load balancer; Azure Load Balancer is Layer 4 - Source: entries/2026/03/10/appgw-overview.md - Source hash: 3c804b6bec0a5478 - Date: 2026-03-10 ### appgw-multisite-100-plus-websites-wildcard [IN] OBSERVATION Application Gateway multi-site listeners support 100+ websites per gateway and wildcard hostnames (up to 5 hostnames per listener) - Source: entries/2026/03/10/appgw-components.md - Source hash: f6ba324b1d3b161e - Date: 2026-03-10 ### appgw-one-listener-one-routing-rule [IN] OBSERVATION Each Application Gateway listener maps to one routing rule - Source: entries/2026/03/10/appgw-components.md - Source hash: f6ba324b1d3b161e - Date: 2026-03-10 ### appgw-one-public-one-private-ip-max [IN] OBSERVATION Application Gateway supports only one public and one private frontend IP address per gateway instance. - Source: entries/2026/03/11/appgw-components.md - Source hash: a92795409da11fe2 - Date: 2026-03-11 ### appgw-path-routing-url-path-only [IN] OBSERVATION Application Gateway path-based routing matches URL path only, not query parameters - Source: entries/2026/03/10/appgw-components.md - Source hash: f6ba324b1d3b161e - Date: 2026-03-10 ### appgw-private-link-zero-trust [IN] OBSERVATION Application Gateway supports Private Link for private connectivity to backends and private-only deployment to eliminate data exfiltration risk, enabling zero-trust architectures. - Source: entries/2026/03/11/appgw-overview.md - Source hash: 1bf7a76e0a05993d - Date: 2026-03-11 ### appgw-routes-by-http-attributes [IN] OBSERVATION Application Gateway makes routing decisions based on HTTP attributes (URL path, host headers), not just IP/port - Source: entries/2026/03/10/appgw-overview.md - Source hash: 3c804b6bec0a5478 - Date: 2026-03-10 ### appgw-ssl-tls-termination-offload [IN] OBSERVATION Application Gateway provides SSL/TLS termination, offloading encryption processing from backend servers. - Source: entries/2026/03/11/appgw-overview.md - Source hash: 1bf7a76e0a05993d - Date: 2026-03-11 ### appgw-supports-autoscaling-and-zone-redundancy [IN] OBSERVATION Application Gateway (V2) supports autoscaling based on traffic demand and zone redundancy across availability zones. - Source: entries/2026/03/11/appgw-overview.md - Source hash: 1bf7a76e0a05993d - Date: 2026-03-11 ### appgw-supports-zone-redundancy-autoscaling [IN] OBSERVATION Application Gateway supports autoscaling based on traffic demand and zone redundancy across availability zones for high availability. - Source: entries/2026/03/11/appgw-overview.md - Source hash: 1bf7a76e0a05993d - Date: 2026-03-11 ### appgw-use-cname-for-dns [IN] OBSERVATION A CNAME alias should be used for Application Gateway's DNS name because it does not change over the gateway's lifecycle. - Source: entries/2026/03/11/appgw-components.md - Source hash: a92795409da11fe2 - Date: 2026-03-11 ### appgw-v1-dynamic-ip-changes-on-stop-start [IN] OBSERVATION Application Gateway V1 dynamic public IP only changes on gateway stop/start, not during failures or updates. - Source: entries/2026/03/11/appgw-components.md - Source hash: a92795409da11fe2 - Date: 2026-03-11 ### appgw-v1-dynamic-ip-changes-on-stop-start-only [IN] OBSERVATION Application Gateway V1 dynamic public IP only changes on gateway stop/start, not during failures or updates. - Source: entries/2026/03/11/appgw-components.md - Source hash: a92795409da11fe2 - Date: 2026-03-11 ### appgw-v1-port-3389-blocked [IN] OBSERVATION Application Gateway V1 SKU blocks port 3389; V2 blocks ports 22 (Private Link) and 53. - Source: entries/2026/03/11/appgw-components.md - Source hash: a92795409da11fe2 - Date: 2026-03-11 ### appgw-v2-blocked-ports-22-53 [IN] OBSERVATION Application Gateway V2 blocks ports 22 (Private Link) and 53; V1 blocks port 3389 - Source: entries/2026/03/10/appgw-components.md - Source hash: f6ba324b1d3b161e - Date: 2026-03-10 ### appgw-v2-ports-1-64999-v1-ports-1-65502 [IN] OBSERVATION Application Gateway V2 supports ports 1–64999 (ports 22 and 53 blocked); V1 supports ports 1–65502 (port 3389 blocked). - Source: entries/2026/03/11/appgw-components.md - Source hash: a92795409da11fe2 - Date: 2026-03-11 ### appgw-v2-static-public-ip-v1-dynamic-only [IN] OBSERVATION Application Gateway V2 supports static public IP; V1 supports only dynamic public IP (changes only on stop/start) - Source: entries/2026/03/10/appgw-components.md - Source hash: f6ba324b1d3b161e - Date: 2026-03-10 ### appgw-vmss-unhealthy-until-upgraded [IN] OBSERVATION VMSS backends in Application Gateway show unhealthy until instances are upgraded after being added to the pool - Source: entries/2026/03/10/appgw-components.md - Source hash: f6ba324b1d3b161e - Date: 2026-03-10 ### appgw-websocket-always-enabled [IN] OBSERVATION Application Gateway WebSocket support is enabled by default and cannot be disabled - Source: entries/2026/03/10/appgw-components.md - Source hash: f6ba324b1d3b161e - Date: 2026-03-10 ### appservice-access-restrictions-max-512-rules [IN] OBSERVATION App Service supports up to 512 access restriction rules per app, evaluated in priority order. - Source: entries/2026/03/11/appservice-networking.md - Source hash: eb6bba5040269d2a - Date: 2026-03-11 ### appservice-artifacts-deploy-to-wwwroot [IN] OBSERVATION Deployment artifacts in Azure App Service are placed at `/home/site/wwwroot`, a mounted storage location shared by all instances. - Source: entries/2026/03/11/appservice-deployment.md - Source hash: e2e603718b50aa93 - Date: 2026-03-11 ### appservice-ase-single-tenant-dedicated-vnet [IN] OBSERVATION 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. - Source: entries/2026/03/11/appservice-networking.md - Source hash: eb6bba5040269d2a - Date: 2026-03-11 ### appservice-ase-single-tenant-vnet-forces-tls12 [IN] OBSERVATION 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. - Source: entries/2026/03/11/appservice-networking.md - Source hash: eb6bba5040269d2a - Date: 2026-03-11 ### appservice-ase-single-tenant-vnet-isolation [IN] OBSERVATION App Service Environment (ASE) is single-tenant, runs inside the customer's VNet, supports private IP addresses via ILB, and forces TLS 1.2. - Source: entries/2026/03/11/appservice-networking.md - Source hash: eb6bba5040269d2a - Date: 2026-03-11 ### appservice-billing-model-by-tier [IN] OBSERVATION App Service billing: Free = no cost; Shared = per-app CPU quota; Dedicated tiers = per VM instance; IsolatedV2 = per worker. - Source: entries/2026/03/11/appservice-plans.md - Source hash: 9376862ce3439634 - Date: 2026-03-11 ### appservice-billing-model-per-tier [IN] OBSERVATION Azure App Service billing: Free = no cost; Shared = per-app CPU quota; Dedicated (Basic–PremiumV4) = per VM instance; IsolatedV2 = per worker - Source: entries/2026/03/11/appservice-plans.md - Source hash: 9376862ce3439634 - Date: 2026-03-11 ### appservice-container-tag-commit-id-not-latest [IN] OBSERVATION Container images deployed to App Service should be tagged with git commit ID or timestamp — avoid using the default `latest` tag. - Source: entries/2026/03/11/appservice-deployment.md - Source hash: e2e603718b50aa93 - Date: 2026-03-11 ### appservice-default-min-tls-1-2-both-sites [IN] OBSERVATION Azure App Service default minimum TLS version is 1.2; must be configured separately for both the web app and SCM site - Source: entries/2026/03/11/appservice-security.md - Source hash: 80f5e8e7840cc453 - Date: 2026-03-11 ### appservice-default-minimum-tls-1-2 [IN] OBSERVATION Azure App Service default minimum TLS version is 1.2; must be configured separately for both the web app and SCM site. - Source: entries/2026/03/11/appservice-security.md - Source hash: 80f5e8e7840cc453 - Date: 2026-03-11 ### appservice-default-minimum-tls-1-2-both-sites [IN] OBSERVATION App Service default minimum TLS version is 1.2; must be configured separately for both the web app and the SCM site. - Source: entries/2026/03/11/appservice-security.md - Source hash: 80f5e8e7840cc453 - Date: 2026-03-11 ### appservice-deploy-artifacts-home-site-wwwroot [IN] OBSERVATION App Service deployment artifacts are placed at `/home/site/wwwroot`, a mounted storage location shared by all instances. - Source: entries/2026/03/11/appservice-deployment.md - Source hash: e2e603718b50aa93 - Date: 2026-03-11 ### appservice-deployment-artifacts-home-site-wwwroot [IN] OBSERVATION App Service deployment artifacts are placed in `/home/site/wwwroot`, a mounted storage location shared by all instances. - Source: entries/2026/03/11/appservice-deployment.md - Source hash: e2e603718b50aa93 - Date: 2026-03-11 ### appservice-deployment-slots-consume-plan-resources [IN] OBSERVATION App Service deployment slots count as active apps competing for resources in the plan. - Source: entries/2026/03/11/appservice-plans.md - Source hash: 9376862ce3439634 - Date: 2026-03-11 ### appservice-deployment-slots-count-as-apps [IN] OBSERVATION Azure App Service deployment slots count as active apps competing for resources within the plan - Source: entries/2026/03/11/appservice-plans.md - Source hash: 9376862ce3439634 - Date: 2026-03-11 ### appservice-deployment-slots-staging [IN] OBSERVATION Azure App Service deployment slots enable staging environments for zero-downtime deployments - Source: entries/2026/03/11/appservice-overview.md - Source hash: 7778109a3978cb82 - Date: 2026-03-11 ### appservice-deployment-slots-standard-tier-and-above [IN] OBSERVATION App Service deployment slots are available at Standard tier and above; swap operations provide zero-downtime deployment and instant rollback. - Source: entries/2026/03/11/appservice-deployment.md - Source hash: e2e603718b50aa93 - Date: 2026-03-11 ### appservice-deployment-slots-standard-tier-minimum [IN] OBSERVATION App Service deployment slots require Standard tier or above. - Source: entries/2026/03/11/appservice-deployment.md - Source hash: e2e603718b50aa93 - Date: 2026-03-11 ### appservice-free-managed-tls-certificates [IN] OBSERVATION Azure App Service provides free managed TLS certificates for custom domains - Source: entries/2026/03/11/appservice-overview.md - Source hash: 7778109a3978cb82 - Date: 2026-03-11 ### appservice-free-shared-no-scale-out [IN] OBSERVATION Azure App Service Free and Shared tiers cannot scale out and run on shared VMs with other customers - Source: entries/2026/03/11/appservice-plans.md - Source hash: 9376862ce3439634 - Date: 2026-03-11 ### appservice-free-shared-no-scale-out-shared-vms [IN] OBSERVATION App Service Free and Shared tiers cannot scale out and run on shared VMs with other customers. - Source: entries/2026/03/11/appservice-plans.md - Source hash: 9376862ce3439634 - Date: 2026-03-11 ### appservice-free-shared-no-scaleout-shared-vms [IN] OBSERVATION App Service Free and Shared tiers cannot scale out and run on shared VMs with other customers. - Source: entries/2026/03/11/appservice-plans.md - Source hash: 9376862ce3439634 - Date: 2026-03-11 ### appservice-ftp-webdeploy-bypass-kudu [IN] OBSERVATION FTP and WebDeploy deployments do not go through Kudu in App Service. - Source: entries/2026/03/11/appservice-deployment.md - Source hash: e2e603718b50aa93 - Date: 2026-03-11 ### appservice-gateway-vnet-integration-cross-region-windows-only [IN] OBSERVATION 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. - Source: entries/2026/03/11/appservice-networking.md - Source hash: eb6bba5040269d2a - Date: 2026-03-11 ### appservice-gateway-vnet-integration-windows-only-cross-region [IN] OBSERVATION Gateway-required VNet integration is legacy, Windows plans only, does not work with ExpressRoute, but can connect cross-region without peering. - Source: entries/2026/03/11/appservice-networking.md - Source hash: eb6bba5040269d2a - Date: 2026-03-11 ### appservice-hybrid-connections-no-vnet-port-443 [IN] OBSERVATION App Service Hybrid Connections are outbound only, require port 443, use Azure Relay, and do not require a VNet. - Source: entries/2026/03/11/appservice-networking.md - Source hash: eb6bba5040269d2a - Date: 2026-03-11 ### appservice-hybrid-connections-outbound-no-vnet [IN] OBSERVATION Hybrid Connections are outbound only, require port 443, use Azure Relay, and do not require a VNet; Hybrid Connection Manager requires Windows Server 2012+. - Source: entries/2026/03/11/appservice-networking.md - Source hash: eb6bba5040269d2a - Date: 2026-03-11 ### appservice-hybrid-connections-outbound-port-443-no-vnet [IN] OBSERVATION App Service Hybrid Connections are outbound only, use Azure Relay on port 443, and do not require a VNet. - Source: entries/2026/03/11/appservice-networking.md - Source hash: eb6bba5040269d2a - Date: 2026-03-11 ### appservice-inbound-outbound-features-separate [IN] OBSERVATION 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. - Source: entries/2026/03/11/appservice-networking.md - Source hash: eb6bba5040269d2a - Date: 2026-03-11 ### appservice-isolatedv2-network-and-compute-isolation [IN] OBSERVATION Azure App Service IsolatedV2 is the only tier providing both network and compute isolation, running on dedicated VNets via App Service Environment - Source: entries/2026/03/11/appservice-plans.md - Source hash: 9376862ce3439634 - Date: 2026-03-11 ### appservice-java-zipdeploy-jar-wardeploy-war [IN] OBSERVATION For Java App Service deployments, use zipdeploy for JAR files and wardeploy for WAR/EAR files. - Source: entries/2026/03/11/appservice-deployment.md - Source hash: e2e603718b50aa93 - Date: 2026-03-11 ### appservice-keyvault-reference-syntax [IN] OBSERVATION Azure App Service Key Vault references use syntax `@Microsoft.KeyVault(SecretUri=https://.vault.azure.net/secrets/)` in app settings - Source: entries/2026/03/11/appservice-security.md - Source hash: 80f5e8e7840cc453 - Date: 2026-03-11 ### appservice-keyvault-secure-configuration [IN] OBSERVATION 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. ### appservice-kudu-separate-process-windows-container-linux [IN] OBSERVATION Kudu runs as a separate process on Windows App Service and as a second container on Linux App Service. - Source: entries/2026/03/11/appservice-deployment.md - Source hash: e2e603718b50aa93 - Date: 2026-03-11 ### appservice-kudu-windows-process-linux-container [IN] OBSERVATION Kudu runs as a separate process on Windows and as a second container on Linux. - Source: entries/2026/03/11/appservice-deployment.md - Source hash: e2e603718b50aa93 - Date: 2026-03-11 ### appservice-local-cache-not-for-cms-use-with-slots [IN] OBSERVATION 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. - Source: entries/2026/03/11/appservice-deployment.md - Source hash: e2e603718b50aa93 - Date: 2026-03-11 ### appservice-managed-instance-rdp-not-persisted [IN] OBSERVATION Azure App Service Managed Instance persistent changes must be scripted via install scripts; RDP changes are not persisted across restarts - Source: entries/2026/03/11/appservice-overview.md - Source hash: 7778109a3978cb82 - Date: 2026-03-11 ### appservice-managed-instance-windows-only [IN] OBSERVATION Azure App Service Managed Instance (preview) supports Windows only — no Linux, containers, or ASE support; requires Pv4/Pmv4 SKUs - Source: entries/2026/03/11/appservice-overview.md - Source hash: 7778109a3978cb82 - Date: 2026-03-11 ### appservice-managed-instance-windows-only-no-linux-containers [IN] OBSERVATION App Service Managed Instance (preview) supports Windows only — it does not support Linux, containers, or ASE. - Source: entries/2026/03/11/appservice-overview.md - Source hash: 7778109a3978cb82 - Date: 2026-03-11 ### appservice-managed-instance-windows-only-no-persist-rdp [IN] OBSERVATION 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. - Source: entries/2026/03/11/appservice-overview.md - Source hash: 7778109a3978cb82 - Date: 2026-03-11 ### appservice-max-512-access-restriction-rules [IN] OBSERVATION App Service supports a maximum of 512 access restriction rules per app, evaluated in priority order. - Source: entries/2026/03/11/appservice-networking.md - Source hash: eb6bba5040269d2a - Date: 2026-03-11 ### appservice-mutual-tls-client-certificates [IN] OBSERVATION App Service supports mutual TLS (client certificate authentication) for B2B or internal app scenarios. - Source: entries/2026/03/11/appservice-security.md - Source hash: 80f5e8e7840cc453 - Date: 2026-03-11 ### appservice-networking-inbound-outbound-separate [IN] OBSERVATION App Service inbound and outbound networking features are distinct — inbound features cannot solve outbound problems and vice versa. - Source: entries/2026/03/11/appservice-networking.md - Source hash: eb6bba5040269d2a - Date: 2026-03-11 ### appservice-new-apps-ftps-only-by-default [IN] OBSERVATION New Azure App Service apps default to FTPS-only; basic auth should be disabled in favor of Entra ID OAuth 2.0. - Source: entries/2026/03/11/appservice-security.md - Source hash: 80f5e8e7840cc453 - Date: 2026-03-11 ### appservice-new-apps-ftps-only-default [IN] OBSERVATION New Azure App Service apps default to FTPS-only; basic auth should be disabled in favor of Entra ID OAuth 2.0 - Source: entries/2026/03/11/appservice-security.md - Source hash: 80f5e8e7840cc453 - Date: 2026-03-11 ### appservice-new-apps-ftps-only-disable-basic-auth [IN] OBSERVATION New App Service apps default to FTPS-only; basic auth should be disabled in favor of Entra ID OAuth 2.0 tokens. - Source: entries/2026/03/11/appservice-security.md - Source hash: 80f5e8e7840cc453 - Date: 2026-03-11 ### appservice-outbound-ips-change-on-vm-family-switch [IN] OBSERVATION App Service outbound IP addresses change when switching between VM families (e.g., Standard → PremiumV2 → PremiumV3 → PremiumV4). - Source: entries/2026/03/11/appservice-networking.md - Source hash: eb6bba5040269d2a - Date: 2026-03-11 ### appservice-plan-all-apps-share-vm-instances [IN] OBSERVATION All apps in an App Service plan share the same VM instances; scaling the plan scales all apps together. - Source: entries/2026/03/11/appservice-plans.md - Source hash: 9376862ce3439634 - Date: 2026-03-11 ### appservice-plan-apps-share-vm-instances [IN] OBSERVATION All apps in an Azure App Service plan share the same VM instances; scaling the plan scales all apps together - Source: entries/2026/03/11/appservice-plans.md - Source hash: 9376862ce3439634 - Date: 2026-03-11 ### appservice-plan-billing-model-by-tier [IN] OBSERVATION App Service billing: Free = no cost; Shared = per-app CPU quota; Dedicated tiers = per VM instance; IsolatedV2 = per worker. - Source: entries/2026/03/11/appservice-plans.md - Source hash: 9376862ce3439634 - Date: 2026-03-11 ### appservice-pmv3-memory-optimized-high-density [IN] OBSERVATION App Service P*mv3 tiers are memory-optimized for high-density hosting (more apps per VM). - Source: entries/2026/03/11/appservice-overview.md - Source hash: 7778109a3978cb82 - Date: 2026-03-11 ### appservice-port-445-blocked-sandbox [IN] OBSERVATION Port 445 (SMB) is blocked by default in the App Service sandbox. - Source: entries/2026/03/11/appservice-networking.md - Source hash: eb6bba5040269d2a - Date: 2026-03-11 ### appservice-port-445-smb-blocked [IN] OBSERVATION Port 445 (SMB) is blocked by default in the App Service sandbox. - Source: entries/2026/03/11/appservice-networking.md - Source hash: eb6bba5040269d2a - Date: 2026-03-11 ### appservice-possible-outbound-addresses-property [IN] OBSERVATION The `possibleOutboundAddresses` app property lists all potential outbound IPs an app might use in a scale unit. - Source: entries/2026/03/11/appservice-networking.md - Source hash: eb6bba5040269d2a - Date: 2026-03-11 ### appservice-premiumv4-no-outbound-ip-exposed [IN] OBSERVATION PremiumV4 SKU does not expose outbound IP addresses. - Source: entries/2026/03/11/appservice-networking.md - Source hash: eb6bba5040269d2a - Date: 2026-03-11 ### appservice-private-endpoints-inbound-only [IN] OBSERVATION Azure App Service private endpoints are inbound only and prevent data exfiltration via Private Link. - Source: entries/2026/03/11/appservice-networking.md - Source hash: eb6bba5040269d2a - Date: 2026-03-11 ### appservice-recommended-apps-per-plan-limits [IN] OBSERVATION Recommended max apps per App Service plan: B1/S1/P1v2 = 8, B3/S3/P3v2 = 32, P3v3/P3v4/I3v2 = 64. - Source: entries/2026/03/11/appservice-plans.md - Source hash: 9376862ce3439634 - Date: 2026-03-11 ### appservice-scale-before-deploy-at-90pct [IN] OBSERVATION If App Service CPU/memory exceeds 90%, scale up instance count temporarily before deploying. - Source: entries/2026/03/11/appservice-deployment.md - Source hash: e2e603718b50aa93 - Date: 2026-03-11 ### appservice-scm-do-build-during-deployment-false [IN] OBSERVATION Setting `SCM_DO_BUILD_DURING_DEPLOYMENT=false` disables Kudu builds when using an external build service (applies to Node.js and .NET). - Source: entries/2026/03/11/appservice-deployment.md - Source hash: e2e603718b50aa93 - Date: 2026-03-11 ### appservice-scm-do-build-false-external-pipeline [IN] OBSERVATION Setting `SCM_DO_BUILD_DURING_DEPLOYMENT=false` disables Kudu builds when using an external build service (Node or .NET). - Source: entries/2026/03/11/appservice-deployment.md - Source hash: e2e603718b50aa93 - Date: 2026-03-11 ### appservice-secrets-encrypted-at-rest-decrypted-at-startup [IN] OBSERVATION App Service stores secrets encrypted at rest and decrypts them only at process startup into memory; encryption keys are rotated regularly. - Source: entries/2026/03/11/appservice-security.md - Source hash: 80f5e8e7840cc453 - Date: 2026-03-11 ### appservice-settings-encrypted-at-rest [IN] OBSERVATION Azure App Service app settings are stored encrypted at rest and decrypted only at process startup into memory; encryption keys are rotated regularly - Source: entries/2026/03/11/appservice-security.md - Source hash: 80f5e8e7840cc453 - Date: 2026-03-11 ### appservice-slots-consume-plan-resources [IN] OBSERVATION Deployment slots count as active apps and compete for resources within the App Service plan. - Source: entries/2026/03/11/appservice-plans.md - Source hash: 9376862ce3439634 - Date: 2026-03-11 ### appservice-slots-require-standard-tier [IN] OBSERVATION Deployment slots in Azure App Service require Standard tier or above. - Source: entries/2026/03/11/appservice-deployment.md - Source hash: e2e603718b50aa93 - Date: 2026-03-11 ### appservice-sni-tls-free-ip-tls-charged [IN] OBSERVATION SNI-based TLS connections on App Service are free; IP-based TLS connections are charged (one free IP-based binding with Standard+ tiers). - Source: entries/2026/03/11/appservice-plans.md - Source hash: 9376862ce3439634 - Date: 2026-03-11 ### appservice-supports-windows-linux-containers [IN] OBSERVATION Azure App Service supports .NET, Java, Node.js, Python, and PHP runtimes on both Windows and Linux, plus custom container deployments - Source: entries/2026/03/11/appservice-overview.md - Source hash: 7778109a3978cb82 - Date: 2026-03-11 ### appservice-swap-warms-then-switches-instant-rollback [IN] OBSERVATION 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. - Source: entries/2026/03/11/appservice-deployment.md - Source hash: e2e603718b50aa93 - Date: 2026-03-11 ### appservice-swap-warmup-and-rollback [IN] OBSERVATION 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). - Source: entries/2026/03/11/appservice-deployment.md - Source hash: e2e603718b50aa93 - Date: 2026-03-11 ### appservice-three-auth-layers [IN] OBSERVATION Azure App Service has three distinct auth layers: RBAC (management plane), Easy Auth (application plane), and Managed Identities (app-to-resource) - Source: entries/2026/03/11/appservice-security.md - Source hash: 80f5e8e7840cc453 - Date: 2026-03-11 ### appservice-three-auth-layers-rbac-easyauth-managedid [IN] OBSERVATION App Service has three distinct auth layers: RBAC (management plane), Easy Auth (application plane), and Managed Identities (app-to-resource). - Source: entries/2026/03/11/appservice-security.md - Source hash: 80f5e8e7840cc453 - Date: 2026-03-11 ### appservice-three-auth-layers-rbac-easyauth-mi [IN] OBSERVATION App Service has three distinct authentication layers: RBAC (management plane), Easy Auth (application plane), and Managed Identities (app-to-resource). - Source: entries/2026/03/11/appservice-security.md - Source hash: 80f5e8e7840cc453 - Date: 2026-03-11 ### appservice-tier-scaling-boundary [IN] OBSERVATION 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. ### appservice-vnet-integration-outbound-same-region [IN] OBSERVATION App Service VNet integration is outbound only and requires the VNet to be in the same region as the app. - Source: entries/2026/03/11/appservice-networking.md - Source hash: eb6bba5040269d2a - Date: 2026-03-11 ### appservice-vnet-integration-outbound-same-region-only [IN] OBSERVATION App Service VNet integration is outbound only and requires the VNet to be in the same region as the app. - Source: entries/2026/03/11/appservice-networking.md - Source hash: eb6bba5040269d2a - Date: 2026-03-11 ### azure-access-and-data-orthogonal-protection-planes [IN] OBSERVATION 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. ### azure-activity-log-subscription-level-automatic [IN] OBSERVATION The Activity log captures subscription-level events (e.g., VM created, VM started) and is collected automatically in a separate store. - Source: entries/2026/03/10/vm-monitoring.md - Source hash: a823dc688cfe1ef4 - Date: 2026-03-11 ### azure-activity-log-subscription-level-separate-store [IN] OBSERVATION 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. - Source: entries/2026/03/11/vm-monitoring.md - Source hash: e56f62adfe29d125 - Date: 2026-03-11 ### azure-advisor-reliability-recommendations [IN] OBSERVATION Azure Advisor provides built-in reliability recommendations as part of the WAF Reliability pillar. - Source: entries/2026/03/10/waf-reliability.md - Source hash: c706e67e28c0714e - Date: 2026-03-10 ### azure-availability-set-requires-2-plus-vms [IN] OBSERVATION Availability Sets require 2 or more VMs to meet the 99.95% Azure SLA. - Source: entries/2026/03/11/vm-availability.md - Source hash: 7f8d5732698f537b - Date: 2026-03-11 ### azure-availability-set-sla-99-95-percent [IN] OBSERVATION Availability Sets provide a 99.95% SLA and require 2 or more VMs for high availability. - Source: entries/2026/03/10/vm-availability.md - Source hash: 959915516a33492a - Date: 2026-03-10 ### azure-availability-zones-dc-loss-asr-regional-outages [IN] OBSERVATION Availability Zones protect against datacenter loss; Azure Site Recovery protects against regional outages. - Source: entries/2026/03/10/vm-availability.md - Source hash: 959915516a33492a - Date: 2026-03-11 ### azure-availability-zones-sla-99-99-percent [IN] OBSERVATION Availability Zones SLA is 99.99% with 2+ VM instances across 2+ zones. - Source: entries/2026/03/10/vm-linux.md - Source hash: 9d3c30a406cb3ab3 - Date: 2026-03-10 ### azure-availability-zones-vs-site-recovery-scope [IN] OBSERVATION Availability Zones protect against datacenter-level failure; Azure Site Recovery protects against region-level outages. - Source: entries/2026/03/10/vm-availability.md - Source hash: 959915516a33492a - Date: 2026-03-11 ### azure-basic-lb-no-global-peering [IN] OBSERVATION Basic load balancer front-end IPs are not reachable across global VNet peering; Standard load balancers are required. - Source: entries/2026/03/10/vnet-peering.md - Source hash: 8e93f76569ceaac3 - Date: 2026-03-10 ### azure-blob-reservation-capacity-only [IN] OBSERVATION Blob storage reservations cover capacity only — not bandwidth or transaction costs. - Source: entries/2026/03/11/vm-reserved-instances.md - Source hash: 6aa7254007a1fe73 - Date: 2026-03-11 ### azure-blob-storage-reservation-capacity-only [IN] OBSERVATION Azure Blob Storage reservations cover storage capacity only — not bandwidth or transaction costs. - Source: entries/2026/03/11/vm-reserved-instances.md - Source hash: 6aa7254007a1fe73 - Date: 2026-03-11 ### azure-block-storage-no-geo-redundancy [IN] OBSERVATION Azure Managed Disks support only LRS and ZRS redundancy — no GRS option exists — meaning disk data is not automatically replicated across Azure regions. ### azure-cache-for-redis-retirement [IN] OBSERVATION All Azure Cache for Redis SKUs are being retired; migration to Azure Managed Redis is recommended. - Source: entries/2026/03/10/redis-best-practices.md - Source hash: a047d725bfd7ac64 - Date: 2026-03-10 ### azure-cache-redis-skus-retiring [IN] OBSERVATION All Azure Cache for Redis SKUs have been announced for retirement; Microsoft recommends migrating to Azure Managed Redis. - Source: entries/2026/03/10/redis-tiers.md - Source hash: 594849f96a5c7b03 - Date: 2026-03-10 ### azure-cloud-init-supported-most-linux [IN] OBSERVATION Cloud-init is supported on most Azure Linux distros for automated VM provisioning. - Source: entries/2026/03/10/vm-windows.md - Source hash: 662dc218304d5937 - Date: 2026-03-11 ### azure-cloud-init-supported-most-linux-distributions [IN] OBSERVATION Cloud-init is supported on most Azure Linux distributions for automated deployment and configuration on VMs and VMSS. - Source: entries/2026/03/11/vm-linux.md - Source hash: 6595565e73896e7a - Date: 2026-03-11 ### azure-cloud-init-supported-most-linux-distros [IN] OBSERVATION Cloud-init is supported on most Azure Linux distributions for automated VM provisioning. - Source: entries/2026/03/10/vm-linux.md - Source hash: 9d3c30a406cb3ab3 - Date: 2026-03-11 ### azure-compute-gallery-renamed-from-shared-image [IN] OBSERVATION Azure Compute Gallery (formerly Shared Image Gallery) is needed for custom images at the 1,000-VM VMSS scale limit. - Source: entries/2026/03/10/vm-scale-sets.md - Source hash: a596f2076e7310d3 - Date: 2026-03-11 ### azure-compute-gallery-renamed-from-shared-image-gallery [IN] OBSERVATION Azure Compute Gallery (formerly Shared Image Gallery) enables custom images with the higher 1,000-VM scale set limit. - Source: entries/2026/03/10/vm-scale-sets.md - Source hash: a596f2076e7310d3 - Date: 2026-03-11 ### azure-container-solutions-spectrum [IN] OBSERVATION 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). - Source: entries/2026/03/10/aks-overview.md - Source hash: 3214c74f62a2db31 - Date: 2026-03-11 ### azure-container-storage-k8s-native-volume-mgmt [IN] OBSERVATION Azure Container Storage is a Kubernetes-native volume orchestration and management service that uses existing Azure Storage offerings as backing storage. - Source: entries/2026/03/11/storage-overview.md - Source hash: addad2bc68f34f7f - Date: 2026-03-11 ### azure-cosmos-db-reservation-throughput-only [IN] OBSERVATION Cosmos DB reservations cover provisioned throughput only — not storage or networking costs. - Source: entries/2026/03/11/vm-reserved-instances.md - Source hash: 6aa7254007a1fe73 - Date: 2026-03-11 ### azure-cosmosdb-reservation-throughput-only [IN] OBSERVATION Cosmos DB reservations cover provisioned throughput only — storage and networking are not included. - Source: entries/2026/03/10/vm-reserved-instances.md - Source hash: 76a74aefb970f033 - Date: 2026-03-11 ### azure-cost-optimization-dual-constraint-model [IN] OBSERVATION 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. ### azure-cross-vnet-dns-requires-fqdn [IN] OBSERVATION Cross-VNet DNS resolution requires using FQDNs; hostname-only queries are insufficient for resolving names across peered or linked VNets. - Source: entries/2026/03/11/vnet-dns.md - Source hash: 3ca61552c4ae8d0d - Date: 2026-03-11 ### azure-data-encryption-dual-layer-enforcement [IN] OBSERVATION 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-security-gradient [IN] OBSERVATION 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-identity-convergence [IN] OBSERVATION 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-reservation-dbu-only [IN] OBSERVATION Azure Databricks reservations cover DBU costs only — not compute, storage, or networking; Databricks is the only service where reservations are not applied hourly. - Source: entries/2026/03/11/vm-reserved-instances.md - Source hash: 6aa7254007a1fe73 - Date: 2026-03-11 ### azure-dcr-many-to-many-with-vms [IN] OBSERVATION A single DCR can be associated with multiple VMs, and a single VM can be associated with multiple DCRs. - Source: entries/2026/03/10/vm-monitoring.md - Source hash: a823dc688cfe1ef4 - Date: 2026-03-10 ### azure-default-deny-cross-layer-pattern [IN] OBSERVATION 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-default-deny-identity-rooted [IN] OBSERVATION 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-spans-governance-and-network [IN] OBSERVATION 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. ### azure-defender-cloud-auto-monitors-three-storage-items [IN] OBSERVATION Microsoft Defender for Cloud auto-monitors three storage items: Defender for Storage enabled, secure transfer required, and network access restricted to specific networks. - Source: entries/2026/03/10/storage-security.md - Source hash: 06ede0dd3e80f917 - Date: 2026-03-10 ### azure-dependency-agent-required-for-vm-insights-map [IN] OBSERVATION The Dependency Agent (separate from Azure Monitor Agent) is required for the VM Insights Map feature. - Source: entries/2026/03/10/vm-monitoring.md - Source hash: a823dc688cfe1ef4 - Date: 2026-03-10 ### azure-direct-vhd-upload-32-tib-max [IN] OBSERVATION Azure supports direct VHD upload up to 32 TiB to a managed disk without attaching it to a VM. - Source: entries/2026/03/11/vm-managed-disks.md - Source hash: 943eec739dc0f12d - Date: 2026-03-11 ### azure-disallow-shared-key-forces-entra-id [IN] OBSERVATION Disallowing Shared Key authorization on a storage account forces all requests to use Microsoft Entra ID. - Source: entries/2026/03/10/storage-security.md - Source hash: 06ede0dd3e80f917 - Date: 2026-03-10 ### azure-disk-storage-reservations-premium-ssd-p30-plus [IN] OBSERVATION Azure Disk Storage reservations apply only to Premium SSDs P30 or larger. - Source: entries/2026/03/10/vm-reserved-instances.md - Source hash: 76a74aefb970f033 - Date: 2026-03-10 ### azure-dns-168-63-129-16-foundational-dependency [IN] OBSERVATION 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. ### azure-dns-cname-restrictions [IN] OBSERVATION CNAME records cannot coexist with other record sets of the same name and cannot be created at the zone apex. - Source: entries/2026/03/10/dns-zones.md - Source hash: 448dcd9de3799ef8 - Date: 2026-03-10 ### azure-dns-cross-vnet-requires-fqdn [IN] OBSERVATION Cross-VNet DNS resolution requires using FQDNs — hostname alone is insufficient. - Source: entries/2026/03/11/vnet-dns.md - Source hash: 3ca61552c4ae8d0d - Date: 2026-03-11 ### azure-dns-custom-must-specify-one-server [IN] OBSERVATION Must specify at least one DNS server IP when configuring custom DNS; otherwise Azure falls back to Azure-provided name resolution. - Source: entries/2026/03/10/vnet-dns.md - Source hash: 7b2e1a4dd3a7be51 - Date: 2026-03-11 ### azure-dns-custom-placeholder-reddog [IN] OBSERVATION When custom DNS is configured, Azure provides `reddog.microsoft.com` as the placeholder DNS suffix instead of `internal.cloudapp.net`. - Source: entries/2026/03/10/vnet-dns.md - Source hash: 7b2e1a4dd3a7be51 - Date: 2026-03-10 ### azure-dns-default-limits [IN] OBSERVATION Default Azure DNS limits: 250 public DNS zones per subscription, 10,000 record sets per zone, 20 records per record set. - Source: entries/2026/03/10/dns-zones.md - Source hash: 448dcd9de3799ef8 - Date: 2026-03-10 ### azure-dns-dhcp-renew-after-change [IN] OBSERVATION After DNS setting changes, the DHCP lease must be renewed on affected VMs for the new settings to take effect. - Source: entries/2026/03/10/vnet-dns.md - Source hash: 7b2e1a4dd3a7be51 - Date: 2026-03-11 ### azure-dns-dhcp-renewal-after-dns-change [IN] OBSERVATION After changing VNet DNS settings, DHCP leases must be renewed on all affected VMs for the new settings to take effect. - Source: entries/2026/03/11/vnet-dns.md - Source hash: 3ca61552c4ae8d0d - Date: 2026-03-11 ### azure-dns-dhcp-renewal-required-after-dns-change [IN] OBSERVATION After changing VNet DNS server settings, DHCP leases must be renewed on all affected VMs for the new settings to take effect. - Source: entries/2026/03/11/vnet-dns.md - Source hash: 3ca61552c4ae8d0d - Date: 2026-03-11 ### azure-dns-disable-reverse-dns-empty-arpa-zone [IN] OBSERVATION To disable default reverse DNS, create an empty Private DNS `in-addr.arpa` zone and link it to the VNet. - Source: entries/2026/03/10/vnet-dns.md - Source hash: 7b2e1a4dd3a7be51 - Date: 2026-03-11 ### azure-dns-etag-concurrency [IN] OBSERVATION Azure DNS uses Etags for optimistic concurrency control on zones and record sets; PowerShell enforces Etag checks by default. - Source: entries/2026/03/10/dns-zones.md - Source hash: 448dcd9de3799ef8 - Date: 2026-03-10 ### azure-dns-five-distinct-services [IN] OBSERVATION Azure DNS encompasses five distinct services: Public DNS, Private DNS, DNS Private Resolver, Traffic Manager, and DNS Security Policy. - Source: entries/2026/03/11/dns-overview.md - Source hash: 27a05a12b39b0861 - Date: 2026-03-11 ### azure-dns-five-services [IN] OBSERVATION Azure DNS encompasses five distinct services: Public DNS, Private DNS, DNS Private Resolver, Traffic Manager, and DNS Security Policy. - Source: entries/2026/03/11/dns-overview.md - Source hash: 27a05a12b39b0861 - Date: 2026-03-11 ### azure-dns-four-resolution-methods [IN] OBSERVATION Azure supports four DNS resolution methods: Azure Private DNS zones (preferred), Azure-provided name resolution, customer-managed DNS servers, and Azure DNS Private Resolver. - Source: entries/2026/03/11/vnet-dns.md - Source hash: 3ca61552c4ae8d0d - Date: 2026-03-11 ### azure-dns-internal-suffix-internal-cloudapp-net [IN] OBSERVATION 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. - Source: entries/2026/03/11/vnet-dns.md - Source hash: 3ca61552c4ae8d0d - Date: 2026-03-11 ### azure-dns-ip-168-63-129-16 [IN] OBSERVATION Azure DNS uses the static IP address 168.63.129.16 for recursive resolution from within VNets. - Source: entries/2026/03/10/vnet-dns.md - Source hash: 7b2e1a4dd3a7be51 - Date: 2026-03-10 ### azure-dns-linux-requires-dnsmasq-for-caching [IN] OBSERVATION Linux VMs require manual dnsmasq installation for DNS client-side caching; Windows has built-in DNS caching. - Source: entries/2026/03/11/vnet-dns.md - Source hash: 3ca61552c4ae8d0d - Date: 2026-03-11 ### azure-dns-multi-vnet-operational-asymmetries [IN] OBSERVATION 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-network-foundations-category [IN] OBSERVATION Azure DNS belongs to the Network Foundations service category alongside Azure Virtual Networks and Azure Private Link. - Source: entries/2026/03/10/dns-overview.md - Source hash: f384b545fe263a12 - Date: 2026-03-11 ### azure-dns-nic-settings-override-vnet [IN] OBSERVATION Network interface DNS settings take precedence over virtual network DNS settings. - Source: entries/2026/03/10/vnet-dns.md - Source hash: 7b2e1a4dd3a7be51 - Date: 2026-03-10 ### azure-dns-no-domain-purchasing [IN] OBSERVATION Azure DNS does not support domain name purchasing — use App Service domains or third-party registrars. - Source: entries/2026/03/10/dns-zones.md - Source hash: 448dcd9de3799ef8 - Date: 2026-03-10 ### azure-dns-no-domain-registration [IN] OBSERVATION Azure DNS does not provide domain registration; it only hosts and resolves domains. - Source: entries/2026/03/10/dns-overview.md - Source hash: f384b545fe263a12 - Date: 2026-03-10 ### azure-dns-port-53-bypasses-nsg-custom [IN] OBSERVATION Once custom DNS is configured, port 53 traffic bypasses subnet/NIC NSGs. - Source: entries/2026/03/10/vnet-dns.md - Source hash: 7b2e1a4dd3a7be51 - Date: 2026-03-11 ### azure-dns-port-53-bypasses-nsgs-custom-dns [IN] OBSERVATION Port 53 traffic to custom DNS servers bypasses NSGs on subnet and NIC after custom DNS is configured on the VNet. - Source: entries/2026/03/11/vnet-dns.md - Source hash: 3ca61552c4ae8d0d - Date: 2026-03-11 ### azure-dns-private-resolver-hybrid-no-vms [IN] OBSERVATION Azure DNS Private Resolver enables hybrid DNS resolution (on-premises to Azure and vice versa) without deploying VM-based DNS servers. - Source: entries/2026/03/10/dns-overview.md - Source hash: f384b545fe263a12 - Date: 2026-03-10 ### azure-dns-private-zone-autoregistration [IN] OBSERVATION Azure Private DNS supports autoregistration, which automatically creates DNS records for VMs in private DNS zones. - Source: entries/2026/03/10/dns-overview.md - Source hash: f384b545fe263a12 - Date: 2026-03-10 ### azure-dns-private-zones-no-custom-dns-servers [IN] OBSERVATION Azure Private DNS resolves domain names within Azure virtual networks without needing custom DNS servers. - Source: entries/2026/03/10/dns-overview.md - Source hash: f384b545fe263a12 - Date: 2026-03-11 ### azure-dns-private-zones-preferred [IN] OBSERVATION Azure Private DNS zones are the preferred solution for VNet DNS name resolution. - Source: entries/2026/03/10/vnet-dns.md - Source hash: 7b2e1a4dd3a7be51 - Date: 2026-03-10 ### azure-dns-provided-no-cross-vnet [IN] OBSERVATION Azure-provided name resolution does not support cross-VNet resolution, manual record registration, or custom DNS suffixes. - Source: entries/2026/03/10/vnet-dns.md - Source hash: 7b2e1a4dd3a7be51 - Date: 2026-03-10 ### azure-dns-reverse-ptr-removed-on-deallocation [IN] OBSERVATION Reverse DNS PTR records (using `.internal.cloudapp.net`) are automatically created when a VM starts and removed when the VM is stopped/deallocated. - Source: entries/2026/03/11/vnet-dns.md - Source hash: 3ca61552c4ae8d0d - Date: 2026-03-11 ### azure-dns-reverse-ptr-scoped-per-vnet [IN] OBSERVATION Reverse DNS (PTR) lookups are scoped to a single VNet — queries for IPs in peered VNets return NXDOMAIN. - Source: entries/2026/03/10/vnet-dns.md - Source hash: 7b2e1a4dd3a7be51 - Date: 2026-03-10 ### azure-dns-security-policy-vnet-level-msrc [IN] OBSERVATION DNS Security Policy operates at the virtual network level and can block known malicious domains via Microsoft Security Response Center (MSRC) threat intelligence feed. - Source: entries/2026/03/10/dns-overview.md - Source hash: f384b545fe263a12 - Date: 2026-03-10 ### azure-dns-server-ips-not-edit-inside-vm [IN] OBSERVATION DNS server IPs should not be edited directly inside VMs — they get erased during service heal events. - Source: entries/2026/03/10/vnet-dns.md - Source hash: 7b2e1a4dd3a7be51 - Date: 2026-03-11 ### azure-dns-soa-cname-single-record-per-set [IN] OBSERVATION SOA and CNAME record sets can only contain a single record per DNS standard constraints. - Source: entries/2026/03/10/dns-zones.md - Source hash: 448dcd9de3799ef8 - Date: 2026-03-11 ### azure-dns-soa-host-not-modifiable [IN] OBSERVATION The SOA record `host` property cannot be modified, and the zone serial number is not auto-updated. - Source: entries/2026/03/10/dns-zones.md - Source hash: 448dcd9de3799ef8 - Date: 2026-03-11 ### azure-dns-soa-ns-auto-created [IN] OBSERVATION NS and SOA record sets at the zone apex are auto-created and auto-deleted with the zone and cannot be independently deleted. - Source: entries/2026/03/10/dns-zones.md - Source hash: 448dcd9de3799ef8 - Date: 2026-03-10 ### azure-dns-soa-serial-not-auto-updated [IN] OBSERVATION The SOA record's `host` property cannot be modified, and the serial number is not automatically updated in Azure DNS. - Source: entries/2026/03/11/dns-zones.md - Source hash: 903a87076cb39952 - Date: 2026-03-11 ### azure-dns-spf-must-use-txt-type [IN] OBSERVATION SPF records must use TXT record type in Azure DNS — the SPF record type is deprecated per RFC 7208. - Source: entries/2026/03/10/dns-zones.md - Source hash: 448dcd9de3799ef8 - Date: 2026-03-10 ### azure-dns-tags-on-zones-metadata-on-record-sets [IN] OBSERVATION Tags apply to DNS zone resources only; metadata (name-value pairs) applies to record sets. - Source: entries/2026/03/10/dns-zones.md - Source hash: 448dcd9de3799ef8 - Date: 2026-03-11 ### azure-dns-throttling-per-vm [IN] OBSERVATION Azure-provided DNS throttles queries on a per-VM basis; client-side DNS caching (e.g., dnsmasq on Linux) is recommended to mitigate throttling. - Source: entries/2026/03/10/vnet-dns.md - Source hash: 7b2e1a4dd3a7be51 - Date: 2026-03-11 ### azure-dns-ttl-per-record-set [IN] OBSERVATION TTL in Azure DNS is set per record set (not per individual record) with a range of 1 to 2,147,483,647 seconds. - Source: entries/2026/03/11/dns-zones.md - Source hash: 903a87076cb39952 - Date: 2026-03-11 ### azure-dns-ttl-per-record-set-not-per-record [IN] OBSERVATION DNS TTL is set per record set (not per individual record); range is 1 to 2,147,483,647 seconds. - Source: entries/2026/03/11/dns-zones.md - Source hash: 903a87076cb39952 - Date: 2026-03-11 ### azure-dns-txt-record-limits [IN] OBSERVATION Azure DNS TXT record sets support up to 4,096 characters total; individual strings are limited to 255 characters. - Source: entries/2026/03/11/dns-zones.md - Source hash: 903a87076cb39952 - Date: 2026-03-11 ### azure-dns-wildcard-all-except-ns-soa [IN] OBSERVATION Wildcard DNS records (using `*` as the record set name) are supported for all record types except NS and SOA. - Source: entries/2026/03/10/dns-zones.md - Source hash: 448dcd9de3799ef8 - Date: 2026-03-11 ### azure-dns-wildcard-all-types-except-ns-soa [IN] OBSERVATION Azure DNS supports wildcard records for all record types except NS and SOA; wildcard record sets use `\*` as the name. - Source: entries/2026/03/11/dns-zones.md - Source hash: 903a87076cb39952 - Date: 2026-03-11 ### azure-dns-wildcard-records-all-types-except-ns-soa [IN] OBSERVATION Azure DNS supports wildcard records for all record types except NS and SOA; use `\*` as the record set name. - Source: entries/2026/03/11/dns-zones.md - Source hash: 903a87076cb39952 - Date: 2026-03-11 ### azure-dns-windows-forwarding-timeout-4s [IN] OBSERVATION Windows DNS forwarding timeout must exceed 4 seconds when forwarding to Azure DNS to avoid Private DNS zone records resolving to public IPs. - Source: entries/2026/03/10/vnet-dns.md - Source hash: 7b2e1a4dd3a7be51 - Date: 2026-03-10 ### azure-dns-zone-unique-within-resource-group [IN] OBSERVATION DNS zone names must be unique within a resource group, not globally unique. - Source: entries/2026/03/10/dns-zones.md - Source hash: 448dcd9de3799ef8 - Date: 2026-03-10 ### azure-elastic-san-iscsi-protocol [IN] OBSERVATION Azure Elastic SAN is a fully integrated SAN solution using the iSCSI protocol, designed for large-scale IO-intensive workloads (SQL, MariaDB, VMs, AKS). - Source: entries/2026/03/11/storage-overview.md - Source hash: addad2bc68f34f7f - Date: 2026-03-11 ### azure-elastic-san-only-lrs-zrs [IN] OBSERVATION Azure Elastic SAN supports only LRS and ZRS redundancy options. - Source: entries/2026/03/11/storage-redundancy.md - Source hash: b199b348e6151287 - Date: 2026-03-11 ### azure-encryption-at-rest-tiered-by-service [IN] OBSERVATION 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-entra-identity-data-plane-lifecycle [IN] OBSERVATION 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. ### azure-expressroute-gateway-not-udr-next-hop [IN] OBSERVATION ExpressRoute gateway cannot be used as a UDR next hop type in service chaining scenarios. - Source: entries/2026/03/10/vnet-peering.md - Source hash: 8e93f76569ceaac3 - Date: 2026-03-10 ### azure-expressroute-private-no-internet [IN] OBSERVATION 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. - Source: entries/2026/03/10/vnet-overview.md - Source hash: b35bdec5b58da622 - Date: 2026-03-10 ### azure-files-no-ra-grs-ra-gzrs [IN] OBSERVATION Azure Files does not support RA-GRS or RA-GZRS redundancy options. - Source: entries/2026/03/10/storage-redundancy.md - Source hash: b3f097a42931505d - Date: 2026-03-10 ### azure-files-smb-nfs-rest [IN] OBSERVATION Azure Files supports SMB, NFS, and REST API protocols and can be mounted from Windows, Linux, and macOS. - Source: entries/2026/03/10/storage-overview.md - Source hash: 7de2f80c18a9ae0b - Date: 2026-03-10 ### azure-governance-hierarchy-dual-enforcement [IN] OBSERVATION 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-topology-determined [IN] OBSERVATION 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-ha-tier-and-zone-dual-requirement [IN] OBSERVATION 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-ha-tier-topology-dual-alignment [IN] OBSERVATION 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-ha-zone-redundancy-follows-tier-pattern [IN] OBSERVATION 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 [IN] OBSERVATION Azure Hybrid Benefit reduces OS licensing costs for customers with existing Windows Server or SQL Server licenses. - Source: entries/2026/03/10/vm-overview.md - Source hash: 13602ec377e5a2fd - Date: 2026-03-10 ### azure-identity-first-data-plane-convergence [IN] OBSERVATION 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. ### azure-immutable-storage-uses-legal-holds-or-time-based-retention [IN] OBSERVATION Immutable storage (WORM) uses legal holds or time-based retention policies — data is readable but not modifiable or deletable during retention. - Source: entries/2026/03/10/storage-security.md - Source hash: 06ede0dd3e80f917 - Date: 2026-03-10 ### azure-infrastructure-ip-168-63-129-16-convergence [IN] OBSERVATION 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. ### azure-internal-standard-lb-no-outbound [IN] OBSERVATION Internal standard load balancer provides no outbound connectivity unless explicitly configured with instance-level public IP or public load balancer. - Source: entries/2026/03/10/vnet-overview.md - Source hash: b35bdec5b58da622 - Date: 2026-03-10 ### azure-lb-decision-tree [IN] OBSERVATION Azure load-balancing decision tree: Traffic Manager (DNS/global) → Front Door (global HTTP with edge) → Application Gateway (regional L7) → Load Balancer (regional L4) - Source: entries/2026/03/10/appgw-overview.md - Source hash: 3c804b6bec0a5478 - Date: 2026-03-10 ### azure-lb-included-with-standard-tier-vms [IN] OBSERVATION Azure Load Balancer is included with Standard tier VMs but not all VM tiers. - Source: entries/2026/03/11/vm-availability.md - Source hash: 7f8d5732698f537b - Date: 2026-03-11 ### azure-linux-2-eol-nov-2025 [IN] OBSERVATION Azure Linux 2.0 security updates ended November 30, 2025; node images will be removed March 31, 2026. Must migrate to Azure Linux 3. - Source: entries/2026/03/10/aks-concepts-clusters.md - Source hash: a9eb987365010a52 - Date: 2026-03-10 ### azure-linux-dns-caching-requires-dnsmasq [IN] OBSERVATION Linux VMs in Azure do not have built-in DNS client-side caching; `dnsmasq` must be installed manually (Windows has built-in DNS caching). - Source: entries/2026/03/11/vnet-dns.md - Source hash: 3ca61552c4ae8d0d - Date: 2026-03-11 ### azure-load-balancer-included-standard-tier [IN] OBSERVATION Azure Load Balancer is included with Standard tier VMs but not all tiers. - Source: entries/2026/03/11/vm-availability.md - Source hash: 7f8d5732698f537b - Date: 2026-03-11 ### azure-load-balancer-included-standard-tier-vms [IN] OBSERVATION Azure Load Balancer is included with Standard tier VMs but not all VM tiers. - Source: entries/2026/03/10/vm-availability.md - Source hash: 959915516a33492a - Date: 2026-03-11 ### azure-load-balancer-layer4-appgw-layer7 [IN] OBSERVATION Azure Load Balancer provides layer-4 traffic distribution; Application Gateway provides layer-7 distribution with TLS termination. - Source: entries/2026/03/10/vm-scale-sets.md - Source hash: a596f2076e7310d3 - Date: 2026-03-10 ### azure-log-analytics-built-on-azure-data-explorer [IN] OBSERVATION Azure Monitor Log Analytics is built on top of Azure Data Explorer. - Source: entries/2026/03/10/monitor-log-analytics.md - Source hash: 87ebfd5d63a4f8fd - Date: 2026-03-10 ### azure-log-analytics-default-result-limit-1000 [IN] OBSERVATION Azure Monitor Log Analytics default query result limit is 1,000 entries. - Source: entries/2026/03/10/monitor-log-analytics.md - Source hash: 87ebfd5d63a4f8fd - Date: 2026-03-10 ### azure-log-analytics-empty-tables-hidden-by-default [IN] OBSERVATION Empty tables are hidden by default in the Log Analytics Tables view; can be toggled per-session or permanently via settings. - Source: entries/2026/03/10/monitor-log-analytics.md - Source hash: 87ebfd5d63a4f8fd - Date: 2026-03-11 ### azure-log-analytics-export-excel-csv-powerbi [IN] OBSERVATION Log Analytics results can be exported to Excel, CSV, or Power BI via the Share menu. - Source: entries/2026/03/11/monitor-log-analytics.md - Source hash: 43037e93cc4f2dbe - Date: 2026-03-11 ### azure-log-analytics-export-to-excel-csv-powerbi [IN] OBSERVATION Log Analytics query results can be exported to Excel, CSV, or Power BI, and can be pinned to Azure dashboards, workbooks, or Grafana. - Source: entries/2026/03/10/monitor-log-analytics.md - Source hash: 87ebfd5d63a4f8fd - Date: 2026-03-11 ### azure-log-analytics-kql-time-range-overrides-picker [IN] OBSERVATION A time range set inside a KQL query overrides the Log Analytics time picker setting. - Source: entries/2026/03/10/monitor-log-analytics.md - Source hash: 87ebfd5d63a4f8fd - Date: 2026-03-10 ### azure-log-analytics-queries-save-to-packs-or-functions [IN] OBSERVATION Log Analytics queries can be saved to query packs for sharing or saved as functions for reuse within other queries. - Source: entries/2026/03/11/monitor-log-analytics.md - Source hash: 43037e93cc4f2dbe - Date: 2026-03-11 ### azure-log-analytics-queries-saved-to-packs-or-functions [IN] OBSERVATION Log Analytics queries can be saved to query packs for sharing or saved as functions for reusable query logic. - Source: entries/2026/03/10/monitor-log-analytics.md - Source hash: 87ebfd5d63a4f8fd - Date: 2026-03-11 ### azure-log-analytics-queries-saved-to-query-packs-or-functions [IN] OBSERVATION Log Analytics queries can be saved to query packs for sharing or as functions for reusable query logic. - Source: entries/2026/03/10/monitor-log-analytics.md - Source hash: 87ebfd5d63a4f8fd - Date: 2026-03-11 ### azure-log-analytics-query-scope-depends-on-entry-point [IN] OBSERVATION Log Analytics query scope depends on entry point: Azure Monitor/workspace returns all workspace data; specific resource returns scoped data. - Source: entries/2026/03/10/monitor-log-analytics.md - Source hash: 87ebfd5d63a4f8fd - Date: 2026-03-10 ### azure-log-analytics-save-to-query-packs-or-functions [IN] OBSERVATION Log Analytics queries can be saved to query packs for sharing or saved as functions for reuse within other queries. - Source: entries/2026/03/11/monitor-log-analytics.md - Source hash: 43037e93cc4f2dbe - Date: 2026-03-11 ### azure-log-analytics-search-job-mode-for-historical [IN] OBSERVATION Log Analytics search job mode enables running search jobs for large-scale historical queries. - Source: entries/2026/03/10/monitor-log-analytics.md - Source hash: 87ebfd5d63a4f8fd - Date: 2026-03-11 ### azure-log-analytics-simple-mode-auto-refreshes [IN] OBSERVATION Log Analytics Simple mode auto-refreshes results without a Run button; KQL mode requires explicit Run or Shift+Enter. - Source: entries/2026/03/10/monitor-log-analytics.md - Source hash: 87ebfd5d63a4f8fd - Date: 2026-03-10 ### azure-log-analytics-uses-kql [IN] OBSERVATION Azure Monitor Log Analytics uses Kusto Query Language (KQL), the same language as Azure Data Explorer. - Source: entries/2026/03/10/monitor-log-analytics.md - Source hash: 87ebfd5d63a4f8fd - Date: 2026-03-10 ### azure-managed-disk-direct-upload-32-tib [IN] OBSERVATION Direct VHD upload to managed disks supports VHDs up to 32 TiB without needing to attach the disk to a VM. - Source: entries/2026/03/11/vm-managed-disks.md - Source hash: 943eec739dc0f12d - Date: 2026-03-11 ### azure-managed-disk-five-encryption-options [IN] OBSERVATION 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. - Source: entries/2026/03/10/vm-managed-disks.md - Source hash: 7da004de8c26ad53 - Date: 2026-03-11 ### azure-managed-disk-snapshot-single-disk-crash-consistent [IN] OBSERVATION 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. - Source: entries/2026/03/11/vm-managed-disks.md - Source hash: 943eec739dc0f12d - Date: 2026-03-11 ### azure-managed-disk-snapshot-vs-image [IN] OBSERVATION 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. - Source: entries/2026/03/10/vm-managed-disks.md - Source hash: 7da004de8c26ad53 - Date: 2026-03-11 ### azure-managed-disk-snapshots-independent-of-source [IN] OBSERVATION Managed disk snapshots exist independently of the source disk and persist even if the source is deleted. - Source: entries/2026/03/10/vm-managed-disks.md - Source hash: 7da004de8c26ad53 - Date: 2026-03-11 ### azure-managed-disks-50000-per-type-per-region [IN] OBSERVATION Subscription limit for managed disks is up to 50,000 disks per type per region per subscription. - Source: entries/2026/03/11/vm-managed-disks.md - Source hash: 943eec739dc0f12d - Date: 2026-03-11 ### azure-managed-disks-direct-upload-32-tib [IN] OBSERVATION Direct VHD upload to Azure Managed Disks supports VHDs up to 32 TiB without requiring attachment to a VM. - Source: entries/2026/03/11/vm-managed-disks.md - Source hash: 943eec739dc0f12d - Date: 2026-03-11 ### azure-managed-disks-five-types [IN] OBSERVATION Azure Managed Disks come in five types: Ultra Disks, Premium SSD v2, Premium SSD, Standard SSD, and Standard HDD. - Source: entries/2026/03/10/vm-managed-disks.md - Source hash: 7da004de8c26ad53 - Date: 2026-03-10 ### azure-managed-disks-image-captures-all-disks [IN] OBSERVATION A managed disk image captures all disks (OS + data) from a generalized or deallocated VM and can be used to create many VMs. - Source: entries/2026/03/11/vm-managed-disks.md - Source hash: 943eec739dc0f12d - Date: 2026-03-11 ### azure-managed-disks-limit-50000-per-type-per-sub-per-region [IN] OBSERVATION Limit of 50,000 managed disks per type per subscription per region. - Source: entries/2026/03/10/vm-managed-disks.md - Source hash: 7da004de8c26ad53 - Date: 2026-03-10 ### azure-managed-disks-lrs-11-nines-zrs-12-nines [IN] OBSERVATION LRS managed disks provide 11 9's of durability; ZRS managed disks provide 12 9's of durability. - Source: entries/2026/03/10/vm-managed-disks.md - Source hash: 7da004de8c26ad53 - Date: 2026-03-10 ### azure-managed-disks-recommended-over-unmanaged [IN] OBSERVATION Managed Disks are recommended for all new VMs; unmanaged disks can be converted to managed. - Source: entries/2026/03/11/vm-linux.md - Source hash: 6595565e73896e7a - Date: 2026-03-11 ### azure-managed-disks-snapshot-single-disk-crash-consistent [IN] OBSERVATION 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. - Source: entries/2026/03/11/vm-managed-disks.md - Source hash: 943eec739dc0f12d - Date: 2026-03-11 ### azure-managed-disks-three-replicas-99-999-availability [IN] OBSERVATION Managed disks store 3 replicas of data and provide 99.999% availability SLA. - Source: entries/2026/03/10/vm-managed-disks.md - Source hash: 7da004de8c26ad53 - Date: 2026-03-10 ### azure-managed-identity-credentials-never-accessible [IN] OBSERVATION Managed identity credentials are never accessible to the developer. - Source: entries/2026/03/10/entra-managed-identities.md - Source hash: 0939df3c5ee17c6d - Date: 2026-03-10 ### azure-managed-identity-fic-limit-20 [IN] OBSERVATION The limit for managed identities as Federated Identity Credentials on an Entra ID application is 20. - Source: entries/2026/03/10/entra-managed-identities.md - Source hash: 0939df3c5ee17c6d - Date: 2026-03-10 ### azure-managed-identity-no-cost [IN] OBSERVATION Managed identities for Azure resources are free — no extra cost. - Source: entries/2026/03/10/entra-managed-identities.md - Source hash: 0939df3c5ee17c6d - Date: 2026-03-10 ### azure-managed-identity-system-assigned-sp-name-matches-resource [IN] OBSERVATION System-assigned managed identity's service principal name matches the Azure resource name; for deployment slots the format is `/slots/`. - Source: entries/2026/03/10/entra-managed-identities.md - Source hash: 0939df3c5ee17c6d - Date: 2026-03-11 ### azure-managed-identity-user-assigned-recommended [IN] OBSERVATION User-assigned managed identity is the recommended type for Microsoft services. - Source: entries/2026/03/10/entra-managed-identities.md - Source hash: 0939df3c5ee17c6d - Date: 2026-03-10 ### azure-managed-identity-workflow-four-steps [IN] OBSERVATION 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. - Source: entries/2026/03/11/entra-managed-identities.md - Source hash: fa85eb1b63928b9c - Date: 2026-03-11 ### azure-managed-lustre-hpc-ai-workloads [IN] OBSERVATION Azure Managed Lustre is a high-performance parallel file system designed for HPC and AI workloads, integrating with Blob Storage and AKS. - Source: entries/2026/03/11/storage-overview.md - Source hash: addad2bc68f34f7f - Date: 2026-03-11 ### azure-messaging-at-least-once-universal [IN] OBSERVATION 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-cost-compound-constraint [IN] OBSERVATION 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-tier-gating-platform-wide [IN] OBSERVATION 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. ### azure-monitor-action-group-notification-types [IN] OBSERVATION Action groups define alert responses including email, SMS, push notifications, Azure Functions, Logic Apps, webhooks, automation runbooks, ITSM incidents, and Event Hubs. - Source: entries/2026/03/10/monitor-alerts.md - Source hash: 1da7e54b95a86564 - Date: 2026-03-11 ### azure-monitor-action-group-response-types [IN] OBSERVATION Action groups define alert responses including email, SMS, push notifications, Azure Functions, Logic Apps, webhooks, Event Hubs, ITSM incidents, and automation runbooks. - Source: entries/2026/03/11/monitor-alerts.md - Source hash: ebc188a8f08e7266 - Date: 2026-03-11 ### azure-monitor-activity-log-alerts-always-stateless [IN] OBSERVATION All Azure Monitor activity log alerts are stateless (fire every time the condition is met). - Source: entries/2026/03/10/monitor-alerts.md - Source hash: 1da7e54b95a86564 - Date: 2026-03-10 ### azure-monitor-agent-private-key-rotation-90-days [IN] OBSERVATION 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. - Source: entries/2026/03/11/monitor-metrics.md - Source hash: f74dfa95b13fa011 - Date: 2026-03-11 ### azure-monitor-agent-tls-12-cert-auth-port-443 [IN] OBSERVATION Azure Monitor agent communication uses TLS 1.2 (HTTPS) on port 443 with certificate-based authentication; private keys are rotated every 90 days. - Source: entries/2026/03/11/monitor-metrics.md - Source hash: f74dfa95b13fa011 - Date: 2026-03-11 ### azure-monitor-aiops-dynamic-thresholds-smart-alerts [IN] OBSERVATION Azure Monitor AIOps capabilities include dynamic alert thresholds and smart alerts using machine learning. - Source: entries/2026/03/10/monitor-overview.md - Source hash: 17de0eaea4cb54d1 - Date: 2026-03-11 ### azure-monitor-alert-conditions-fired-or-resolved [IN] OBSERVATION Azure Monitor alert conditions are system-managed with two states: fired or resolved. - Source: entries/2026/03/10/monitor-alerts.md - Source hash: 1da7e54b95a86564 - Date: 2026-03-10 ### azure-monitor-alert-dual-track-lifecycle [IN] OBSERVATION 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. ### azure-monitor-alert-processing-rules [IN] OBSERVATION Alert processing rules modify triggered alerts by adding or suppressing action groups, applying filters, or scheduling rule processing windows. - Source: entries/2026/03/11/monitor-alerts.md - Source hash: ebc188a8f08e7266 - Date: 2026-03-11 ### azure-monitor-alert-processing-rules-modify-triggered [IN] OBSERVATION Alert processing rules modify triggered alerts by adding or suppressing action groups, applying filters, or scheduling rule processing windows. - Source: entries/2026/03/11/monitor-alerts.md - Source hash: ebc188a8f08e7266 - Date: 2026-03-11 ### azure-monitor-alert-processing-rules-modify-triggered-alerts [IN] OBSERVATION Alert processing rules modify triggered alerts by adding or suppressing action groups, applying filters, or scheduling. - Source: entries/2026/03/10/monitor-alerts.md - Source hash: 1da7e54b95a86564 - Date: 2026-03-11 ### azure-monitor-alert-rbac-requirements [IN] OBSERVATION Creating alert rules requires read permission on target resource, write on resource group, and read on action group. - Source: entries/2026/03/10/monitor-alerts.md - Source hash: 1da7e54b95a86564 - Date: 2026-03-10 ### azure-monitor-alert-user-response-states [IN] OBSERVATION Azure Monitor alert user response has three states: New, Acknowledged, or Closed; these do not change automatically. - Source: entries/2026/03/10/monitor-alerts.md - Source hash: 1da7e54b95a86564 - Date: 2026-03-10 ### azure-monitor-alerts-retained-30-days [IN] OBSERVATION Azure Monitor alerts are stored for 30 days then automatically deleted. - Source: entries/2026/03/10/monitor-alerts.md - Source hash: 1da7e54b95a86564 - Date: 2026-03-10 ### azure-monitor-application-insights-ai-agent-monitoring [IN] OBSERVATION Application Insights tracks AI agent performance across Microsoft Foundry, Copilot Studio, and third-party frameworks including token consumption, latency, error rates, and quality scores. - Source: entries/2026/03/10/monitor-overview.md - Source hash: 17de0eaea4cb54d1 - Date: 2026-03-11 ### azure-monitor-application-insights-opentelemetry-based [IN] OBSERVATION Application Insights is an OpenTelemetry-based APM feature within Azure Monitor. - Source: entries/2026/03/10/monitor-overview.md - Source hash: 17de0eaea4cb54d1 - Date: 2026-03-10 ### azure-monitor-autoscale-is-built-in-feature [IN] OBSERVATION Autoscale is a built-in feature of Azure Monitor that automatically adjusts resources based on application load, not a separate Azure service. - Source: entries/2026/03/11/monitor-overview.md - Source hash: 18a0e29551e2a614 - Date: 2026-03-11 ### azure-monitor-autoscale-is-monitor-feature [IN] OBSERVATION Autoscale is a feature of Azure Monitor, not a standalone service. - Source: entries/2026/03/10/monitor-overview.md - Source hash: 17de0eaea4cb54d1 - Date: 2026-03-10 ### azure-monitor-auxiliary-plan-dcr-custom-tables-only [IN] OBSERVATION The Auxiliary table plan only supports DCR-based custom tables, not standard Azure resource tables. - Source: entries/2026/03/11/monitor-logs.md - Source hash: 110d65756a36ba5d - Date: 2026-03-11 ### azure-monitor-basic-plan-kql-single-table-with-lookup [IN] OBSERVATION The Basic table plan limits KQL queries to a single table, but this can be extended using the `lookup` operator. - Source: entries/2026/03/11/monitor-logs.md - Source hash: 110d65756a36ba5d - Date: 2026-03-11 ### azure-monitor-basic-plan-simple-log-alerts-only [IN] OBSERVATION The Basic table plan supports only Simple Log Alerts, not full log search alert rules. - Source: entries/2026/03/11/monitor-logs.md - Source hash: 110d65756a36ba5d - Date: 2026-03-11 ### azure-monitor-contributor-creates-alerts-reader-views-only [IN] OBSERVATION Monitoring Contributor role can create and manage alerts; Monitoring Reader role can only view alerts. - Source: entries/2026/03/10/monitor-alerts.md - Source hash: 1da7e54b95a86564 - Date: 2026-03-11 ### azure-monitor-custom-metrics-10-dimension-limit [IN] OBSERVATION Azure Monitor custom metrics are limited to 10 dimensions. - Source: entries/2026/03/10/monitor-metrics.md - Source hash: b5b450daf86cf03e - Date: 2026-03-10 ### azure-monitor-data-collection-rules-customize-telemetry [IN] OBSERVATION Data collection rules customize and filter what telemetry data is collected from different sources in Azure Monitor. - Source: entries/2026/03/10/monitor-overview.md - Source hash: 17de0eaea4cb54d1 - Date: 2026-03-11 ### azure-monitor-data-platform-shared-with-sentinel-defender [IN] OBSERVATION The Azure Monitor data platform is shared with Microsoft Defender for Cloud and Microsoft Sentinel. - Source: entries/2026/03/10/monitor-overview.md - Source hash: 17de0eaea4cb54d1 - Date: 2026-03-10 ### azure-monitor-dcr-customizes-and-filters-telemetry [IN] OBSERVATION Data collection rules (DCRs) are the mechanism for customizing and filtering telemetry collected by Azure Monitor. - Source: entries/2026/03/11/monitor-overview.md - Source hash: 18a0e29551e2a614 - Date: 2026-03-11 ### azure-monitor-dcr-customizes-data-collection [IN] OBSERVATION Data collection rules (DCRs) are the mechanism for customizing and filtering telemetry collected by Azure Monitor from different sources. - Source: entries/2026/03/11/monitor-overview.md - Source hash: 18a0e29551e2a614 - Date: 2026-03-11 ### azure-monitor-dcrs-customize-and-filter-collection [IN] OBSERVATION Data collection rules (DCRs) are the mechanism for customizing, filtering, and routing telemetry data during collection in Azure Monitor. - Source: entries/2026/03/11/monitor-overview.md - Source hash: 18a0e29551e2a614 - Date: 2026-03-11 ### azure-monitor-dual-ingestion-model [IN] OBSERVATION 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. ### azure-monitor-fired-alerts-read-only [IN] OBSERVATION Fired Azure Monitor alert instances are read-only and cannot be edited. - Source: entries/2026/03/10/monitor-alerts.md - Source hash: 1da7e54b95a86564 - Date: 2026-03-10 ### azure-monitor-four-signal-types [IN] OBSERVATION Azure Monitor collects four signal types: metrics, logs, traces, and events. - Source: entries/2026/03/10/monitor-overview.md - Source hash: 17de0eaea4cb54d1 - Date: 2026-03-10 ### azure-monitor-guest-os-log-analytics-agent-retention-31-days [IN] OBSERVATION Guest OS metrics sent via Log Analytics agent are retained for 31 days, extendable to 2 years. - Source: entries/2026/03/11/monitor-metrics.md - Source hash: f74dfa95b13fa011 - Date: 2026-03-11 ### azure-monitor-guest-os-metrics-log-analytics-31d-to-2y [IN] OBSERVATION Guest OS metrics collected via the Log Analytics agent are retained for 31 days, extendable to 2 years. - Source: entries/2026/03/10/monitor-metrics.md - Source hash: b5b450daf86cf03e - Date: 2026-03-11 ### azure-monitor-guest-os-metrics-log-analytics-agent-31-days [IN] OBSERVATION Guest OS metrics collected via Log Analytics agent are retained for 31 days, extendable to 2 years. - Source: entries/2026/03/10/monitor-metrics.md - Source hash: b5b450daf86cf03e - Date: 2026-03-11 ### azure-monitor-guest-os-metrics-via-ama [IN] OBSERVATION Guest OS metrics require an agent; Azure Monitor Agent (AMA) is the current recommended agent, replacing legacy Windows diagnostic extension and InfluxData Telegraf agent. - Source: entries/2026/03/11/monitor-metrics.md - Source hash: f74dfa95b13fa011 - Date: 2026-03-11 ### azure-monitor-hybrid-multicloud-via-arc [IN] OBSERVATION Azure Monitor supports hybrid and multicloud monitoring via Azure Arc and the Azure Monitor pipeline. - Source: entries/2026/03/10/monitor-overview.md - Source hash: 17de0eaea4cb54d1 - Date: 2026-03-10 ### azure-monitor-kql-read-only-language [IN] OBSERVATION KQL (Kusto Query Language) is a read-only query language — it can query and analyze data but cannot modify it. - Source: entries/2026/03/11/monitor-logs.md - Source hash: 110d65756a36ba5d - Date: 2026-03-11 ### azure-monitor-log-alert-charge-based-on-time-series [IN] OBSERVATION Log search alerts are charged based on the number of time series created from dimension splits. - Source: entries/2026/03/10/monitor-alerts.md - Source hash: 1da7e54b95a86564 - Date: 2026-03-11 ### azure-monitor-log-analytics-retention-31-days-extendable-2-years [IN] OBSERVATION Guest OS metrics sent via Log Analytics agent are retained 31 days, extendable to 2 years. - Source: entries/2026/03/11/monitor-metrics.md - Source hash: f74dfa95b13fa011 - Date: 2026-03-11 ### azure-monitor-log-analytics-workspaces-use-kql-monitor-workspaces-use-promql [IN] OBSERVATION Log Analytics workspaces use KQL for querying; Azure Monitor workspaces use PromQL for querying Prometheus/OpenTelemetry metrics. - Source: entries/2026/03/10/monitor-overview.md - Source hash: 17de0eaea4cb54d1 - Date: 2026-03-10 ### azure-monitor-log-search-alert-resolution-timing [IN] OBSERVATION 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. - Source: entries/2026/03/11/monitor-alerts.md - Source hash: ebc188a8f08e7266 - Date: 2026-03-11 ### azure-monitor-log-search-alerts-charged-by-time-series [IN] OBSERVATION Log search alert rules are charged based on the number of time series created by dimension splits. - Source: entries/2026/03/11/monitor-alerts.md - Source hash: ebc188a8f08e7266 - Date: 2026-03-11 ### azure-monitor-logs-all-plans-12-year-retention [IN] OBSERVATION All Azure Monitor Logs table plans support up to 12 years total retention. - Source: entries/2026/03/10/monitor-logs.md - Source hash: 8a8cfd71a055c935 - Date: 2026-03-10 ### azure-monitor-logs-analytics-plan-30-day-default-retention [IN] OBSERVATION Analytics table plan has 30-day default analytics retention (90 days for Sentinel and Application Insights), extendable to 2 years. - Source: entries/2026/03/10/monitor-logs.md - Source hash: 8a8cfd71a055c935 - Date: 2026-03-10 ### azure-monitor-logs-auxiliary-plan-limitations [IN] OBSERVATION Auxiliary table plan has no workspace replication, no Customer Lockbox support, no alerts, no insights, and no data export. - Source: entries/2026/03/10/monitor-logs.md - Source hash: 8a8cfd71a055c935 - Date: 2026-03-10 ### azure-monitor-logs-basic-auxiliary-not-in-legacy-pricing [IN] OBSERVATION Basic and Auxiliary table plans are not available in legacy pricing tiers. - Source: entries/2026/03/10/monitor-logs.md - Source hash: 8a8cfd71a055c935 - Date: 2026-03-10 ### azure-monitor-logs-basic-plan-simple-log-alerts-only [IN] OBSERVATION The Basic table plan in Azure Monitor Logs supports only Simple Log Alerts, not full alert rules. - Source: entries/2026/03/11/monitor-logs.md - Source hash: 110d65756a36ba5d - Date: 2026-03-11 ### azure-monitor-logs-basic-plan-supports-simple-log-alerts [IN] OBSERVATION The Basic table plan supports Simple Log Alerts and full KQL on a single table (extendable via lookup). - Source: entries/2026/03/10/monitor-logs.md - Source hash: 8a8cfd71a055c935 - Date: 2026-03-11 ### azure-monitor-logs-data-collection-transformations [IN] OBSERVATION Data collection transformations can filter, transform, and route data during ingestion to optimize cost and analytics before it reaches workspace tables. - Source: entries/2026/03/11/monitor-logs.md - Source hash: 110d65756a36ba5d - Date: 2026-03-11 ### azure-monitor-logs-kql-read-only [IN] OBSERVATION 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. - Source: entries/2026/03/11/monitor-logs.md - Source hash: 110d65756a36ba5d - Date: 2026-03-11 ### azure-monitor-logs-kql-read-only-language [IN] OBSERVATION 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. - Source: entries/2026/03/10/monitor-logs.md - Source hash: 8a8cfd71a055c935 - Date: 2026-03-11 ### azure-monitor-logs-sentinel-defender-use-log-analytics [IN] OBSERVATION Microsoft Sentinel and Microsoft Defender for Cloud both store their security data in Azure Monitor Log Analytics workspaces. - Source: entries/2026/03/11/monitor-logs.md - Source hash: 110d65756a36ba5d - Date: 2026-03-11 ### azure-monitor-logs-summary-rules-aggregate-data [IN] OBSERVATION Summary rules aggregate data from one or more tables as it arrives, producing summarized tables for dashboards and faster queries. - Source: entries/2026/03/10/monitor-logs.md - Source hash: 8a8cfd71a055c935 - Date: 2026-03-10 ### azure-monitor-logs-three-table-plans [IN] OBSERVATION 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). - Source: entries/2026/03/10/monitor-logs.md - Source hash: 8a8cfd71a055c935 - Date: 2026-03-10 ### azure-monitor-metric-alert-multi-resource-same-type-same-region [IN] OBSERVATION A single metric alert rule can monitor multiple resources of the same type in the same Azure region. - Source: entries/2026/03/10/monitor-alerts.md - Source hash: 1da7e54b95a86564 - Date: 2026-03-10 ### azure-monitor-metric-dimensions-case-insensitive [IN] OBSERVATION Metric dimension names and values are case-insensitive in Azure Monitor. - Source: entries/2026/03/11/monitor-metrics.md - Source hash: f74dfa95b13fa011 - Date: 2026-03-11 ### azure-monitor-metrics-batch-api-50-resource-ids [IN] OBSERVATION The Azure Monitor Metrics Batch REST API supports up to 50 resource IDs per call (same subscription and region). - Source: entries/2026/03/10/monitor-metrics.md - Source hash: b5b450daf86cf03e - Date: 2026-03-10 ### azure-monitor-metrics-explorer-chart-limit-30-days [IN] OBSERVATION Metrics Explorer chart query limit is 30 days per single chart; PromQL query max span is 32 days. - Source: entries/2026/03/10/monitor-metrics.md - Source hash: b5b450daf86cf03e - Date: 2026-03-10 ### azure-monitor-metrics-three-types [IN] OBSERVATION 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). - Source: entries/2026/03/10/monitor-metrics.md - Source hash: b5b450daf86cf03e - Date: 2026-03-11 ### azure-monitor-metrics-tls-12-cert-auth-port-443 [IN] OBSERVATION Azure Monitor agent-to-service communication uses TLS 1.2 (HTTPS) with certificate-based authentication on port 443; private keys rotated every 90 days. - Source: entries/2026/03/11/monitor-metrics.md - Source hash: f74dfa95b13fa011 - Date: 2026-03-11 ### azure-monitor-metrics-tls-12-keys-rotated-90-days [IN] OBSERVATION Azure Monitor Metrics uses TLS 1.2 (HTTPS) on port 443 for all communication; private keys are rotated every 90 days. - Source: entries/2026/03/10/monitor-metrics.md - Source hash: b5b450daf86cf03e - Date: 2026-03-11 ### azure-monitor-monitoring-contributor-and-reader-roles [IN] OBSERVATION Built-in monitoring roles: Monitoring Contributor can create and manage alerts; Monitoring Reader has view-only access. - Source: entries/2026/03/11/monitor-alerts.md - Source hash: ebc188a8f08e7266 - Date: 2026-03-11 ### azure-monitor-monitoring-contributor-creates-reader-views [IN] OBSERVATION Monitoring Contributor role can create and manage alerts; Monitoring Reader role can only view alerts. - Source: entries/2026/03/10/monitor-alerts.md - Source hash: 1da7e54b95a86564 - Date: 2026-03-11 ### azure-monitor-moving-resource-may-lose-metric-history [IN] OBSERVATION Moving or renaming an Azure resource may result in loss of metric history. - Source: entries/2026/03/10/monitor-metrics.md - Source hash: b5b450daf86cf03e - Date: 2026-03-10 ### azure-monitor-native-metrics-preaggregated-prometheus-raw [IN] OBSERVATION Native platform and custom metrics are preaggregated; Prometheus metrics store raw data. - Source: entries/2026/03/11/monitor-metrics.md - Source hash: f74dfa95b13fa011 - Date: 2026-03-11 ### azure-monitor-observability-depends-on-identity-chain [IN] OBSERVATION 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-observability-security-compound-risk [IN] OBSERVATION 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-to-on-premises [IN] OBSERVATION Azure Monitor pipeline extends data collection into on-premises data centers and other cloud providers, supporting large volumes or intermittent connectivity. - Source: entries/2026/03/11/monitor-overview.md - Source hash: 18a0e29551e2a614 - Date: 2026-03-11 ### azure-monitor-pipeline-extends-to-onprem-multicloud [IN] OBSERVATION Azure Monitor pipeline extends data collection to on-premises data centers and other cloud providers for large volumes or intermittent connectivity. - Source: entries/2026/03/11/monitor-overview.md - Source hash: 18a0e29551e2a614 - Date: 2026-03-11 ### azure-monitor-platform-custom-metrics-preaggregated [IN] OBSERVATION Platform and custom metrics are preaggregated in the time-series database; Prometheus metrics store raw data. - Source: entries/2026/03/10/monitor-metrics.md - Source hash: b5b450daf86cf03e - Date: 2026-03-11 ### azure-monitor-platform-metrics-long-term-via-diagnostic-settings [IN] OBSERVATION Platform metrics can be sent to a Log Analytics workspace via diagnostic settings for long-term retention beyond the 93-day default. - Source: entries/2026/03/11/monitor-metrics.md - Source hash: f74dfa95b13fa011 - Date: 2026-03-11 ### azure-monitor-platform-metrics-no-config-no-cost [IN] OBSERVATION Azure Monitor platform metrics are automatically collected from Azure resources at 1-minute frequency, require no configuration, and have no cost. - Source: entries/2026/03/10/monitor-metrics.md - Source hash: b5b450daf86cf03e - Date: 2026-03-10 ### azure-monitor-platform-metrics-retention-93-days [IN] OBSERVATION Azure Monitor platform metrics are retained for 93 days. - Source: entries/2026/03/10/monitor-metrics.md - Source hash: b5b450daf86cf03e - Date: 2026-03-10 ### azure-monitor-prometheus-alerts-use-promql [IN] OBSERVATION Prometheus alerts use PromQL-based rules against Azure Monitor managed Prometheus metrics (a separate alert type from metric alerts). - Source: entries/2026/03/10/monitor-alerts.md - Source hash: 1da7e54b95a86564 - Date: 2026-03-11 ### azure-monitor-prometheus-metrics-retention-18-months [IN] OBSERVATION Azure Monitor Prometheus metrics are retained for 18 months. - Source: entries/2026/03/10/monitor-metrics.md - Source hash: b5b450daf86cf03e - Date: 2026-03-10 ### azure-monitor-prometheus-metrics-stored-in-workspace [IN] OBSERVATION Prometheus metrics are stored in an Azure Monitor workspace (not subscription-level like native metrics). - Source: entries/2026/03/10/monitor-metrics.md - Source hash: b5b450daf86cf03e - Date: 2026-03-10 ### azure-monitor-recommended-alert-rules-vms-aks-law [IN] OBSERVATION Recommended (out-of-the-box) alert rules are available for VMs, AKS, and Log Analytics workspaces. - Source: entries/2026/03/11/monitor-alerts.md - Source hash: ebc188a8f08e7266 - Date: 2026-03-11 ### azure-monitor-retention-alerting-alignment-required [IN] OBSERVATION 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-three-tier-model [IN] OBSERVATION 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). ### azure-monitor-sentinel-defender-store-data-in-log-analytics [IN] OBSERVATION Microsoft Sentinel and Microsoft Defender for Cloud both store their data in Log Analytics workspaces. - Source: entries/2026/03/10/monitor-logs.md - Source hash: 8a8cfd71a055c935 - Date: 2026-03-11 ### azure-monitor-sentinel-defender-store-in-log-analytics-workspaces [IN] OBSERVATION Microsoft Sentinel and Microsoft Defender for Cloud both store their data in Log Analytics workspaces. - Source: entries/2026/03/10/monitor-logs.md - Source hash: 8a8cfd71a055c935 - Date: 2026-03-11 ### azure-monitor-shared-platform-three-consumers [IN] OBSERVATION 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-six-alert-types [IN] OBSERVATION 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. - Source: entries/2026/03/11/monitor-alerts.md - Source hash: ebc188a8f08e7266 - Date: 2026-03-11 ### azure-monitor-smart-alerts-dynamic-thresholds-ml [IN] OBSERVATION Azure Monitor alerts support dynamic thresholds and smart alerts using machine learning for intelligent alerting. - Source: entries/2026/03/11/monitor-overview.md - Source hash: 18a0e29551e2a614 - Date: 2026-03-11 ### azure-monitor-smart-detection-alerts [IN] OBSERVATION Smart detection alerts are Application Insights auto-detection of performance and failure anomalies. - Source: entries/2026/03/11/monitor-alerts.md - Source hash: ebc188a8f08e7266 - Date: 2026-03-11 ### azure-monitor-smart-detection-alerts-app-insights [IN] OBSERVATION Smart detection alerts automatically detect performance and failure anomalies in Application Insights resources. - Source: entries/2026/03/11/monitor-alerts.md - Source hash: ebc188a8f08e7266 - Date: 2026-03-11 ### azure-monitor-smart-detection-from-app-insights [IN] OBSERVATION Smart detection alerts originate from Application Insights and auto-detect performance and failure anomalies. - Source: entries/2026/03/11/monitor-alerts.md - Source hash: ebc188a8f08e7266 - Date: 2026-03-11 ### azure-monitor-stateful-alert-condition-persists-after-deletion [IN] OBSERVATION Stateful alert condition state is stored even after the 30-day alert deletion to prevent re-firing. - Source: entries/2026/03/10/monitor-alerts.md - Source hash: 1da7e54b95a86564 - Date: 2026-03-11 ### azure-monitor-stateful-condition-persists-after-deletion [IN] OBSERVATION Stateful alert condition state is stored even after the 30-day alert deletion period to prevent re-firing of the same condition. - Source: entries/2026/03/11/monitor-alerts.md - Source hash: ebc188a8f08e7266 - Date: 2026-03-11 ### azure-monitor-stateful-metric-alert-resolves-after-3-checks [IN] OBSERVATION Stateful metric alerts resolve after 3 consecutive checks where the condition is not met. - Source: entries/2026/03/10/monitor-alerts.md - Source hash: 1da7e54b95a86564 - Date: 2026-03-10 ### azure-monitor-three-alert-types [IN] OBSERVATION 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). - Source: entries/2026/03/11/vm-monitoring.md - Source hash: e56f62adfe29d125 - Date: 2026-03-11 ### azure-monitor-three-alert-types-metric-log-activity [IN] OBSERVATION 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). - Source: entries/2026/03/11/vm-monitoring.md - Source hash: e56f62adfe29d125 - Date: 2026-03-11 ### azure-monitor-three-alert-types-vm [IN] OBSERVATION 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). - Source: entries/2026/03/11/vm-monitoring.md - Source hash: e56f62adfe29d125 - Date: 2026-03-11 ### azure-monitor-three-metric-types [IN] OBSERVATION 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). - Source: entries/2026/03/11/monitor-metrics.md - Source hash: f74dfa95b13fa011 - Date: 2026-03-11 ### azure-monitor-two-query-languages-kql-promql [IN] OBSERVATION Azure Monitor uses two query languages: KQL for logs/traces in Log Analytics workspaces and PromQL for metrics in Azure Monitor workspaces. - Source: entries/2026/03/11/monitor-overview.md - Source hash: 18a0e29551e2a614 - Date: 2026-03-11 ### azure-monitor-workspace-security-nexus [IN] OBSERVATION 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-99-99-availability [IN] OBSERVATION Azure NetApp Files provides 99.99% availability with locally redundant storage. - Source: entries/2026/03/11/storage-overview.md - Source hash: addad2bc68f34f7f - Date: 2026-03-11 ### azure-netapp-files-9999-availability [IN] OBSERVATION Azure NetApp Files provides 99.99% availability with locally redundant storage. - Source: entries/2026/03/11/storage-overview.md - Source hash: addad2bc68f34f7f - Date: 2026-03-11 ### azure-netapp-files-9999-sla [IN] OBSERVATION Azure NetApp Files provides 99.99% availability SLA with locally redundant storage; data-in-flight encryption is optional (not default). - Source: entries/2026/03/10/storage-overview.md - Source hash: 7de2f80c18a9ae0b - Date: 2026-03-11 ### azure-netapp-files-9999-sla-locally-redundant [IN] OBSERVATION Azure NetApp Files provides 99.99% availability SLA with locally redundant storage; data-in-flight encryption is optional (not default). - Source: entries/2026/03/10/storage-overview.md - Source hash: 7de2f80c18a9ae0b - Date: 2026-03-11 ### azure-netapp-files-fips-140-2-at-rest [IN] OBSERVATION Azure NetApp Files uses FIPS 140-2 standard for encryption at rest. - Source: entries/2026/03/11/storage-overview.md - Source hash: addad2bc68f34f7f - Date: 2026-03-11 ### azure-netapp-files-inflight-not-encrypted-by-default [IN] OBSERVATION 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. - Source: entries/2026/03/11/storage-overview.md - Source hash: addad2bc68f34f7f - Date: 2026-03-11 ### azure-netapp-files-inflight-not-encrypted-default [IN] OBSERVATION 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. - Source: entries/2026/03/11/storage-overview.md - Source hash: addad2bc68f34f7f - Date: 2026-03-11 ### azure-nic-no-separate-cost-limited-by-vm-size [IN] OBSERVATION VM network interfaces have no separate cost but the number of NICs is limited by VM size. - Source: entries/2026/03/10/vm-linux.md - Source hash: 9d3c30a406cb3ab3 - Date: 2026-03-11 ### azure-no-cost-for-availability-sets-or-scale-sets [IN] OBSERVATION There is no cost for availability sets or VM scale sets themselves — only per-VM instance charges apply. - Source: entries/2026/03/10/vm-availability.md - Source hash: 959915516a33492a - Date: 2026-03-10 ### azure-nsg-augmented-rules-resource-manager-only [IN] OBSERVATION Augmented security rules (multiple IPs, ranges, ports in a single rule) are only available in the Resource Manager deployment model. - Source: entries/2026/03/10/vnet-nsg.md - Source hash: cafae416ca6beb29 - Date: 2026-03-10 ### azure-nsg-default-rule-priorities [IN] OBSERVATION NSG default rules use priorities 65000, 65001, and 65500; custom rules (max priority 4096) always evaluate first. - Source: entries/2026/03/10/vnet-nsg.md - Source hash: cafae416ca6beb29 - Date: 2026-03-10 ### azure-nsg-esp-ah-arm-templates-only [IN] OBSERVATION ESP and AH protocols in NSG rules can only be configured via ARM templates, not through the Azure portal. - Source: entries/2026/03/11/vnet-nsg.md - Source hash: 7770db13ddbe6897 - Date: 2026-03-11 ### azure-nsg-five-tuple-matching [IN] OBSERVATION NSG rules evaluate traffic using five-tuple matching: source, source port, destination, destination port, and protocol. - Source: entries/2026/03/11/vnet-nsg.md - Source hash: 7770db13ddbe6897 - Date: 2026-03-11 ### azure-nsg-flow-logs-retiring-sept-2027 [IN] OBSERVATION NSG flow logs are retiring on September 30, 2027; users should migrate to VNet flow logs. - Source: entries/2026/03/10/vnet-nsg.md - Source hash: cafae416ca6beb29 - Date: 2026-03-11 ### azure-nsg-host-ips-bypass-nsg [IN] OBSERVATION 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. - Source: entries/2026/03/10/vnet-nsg.md - Source hash: cafae416ca6beb29 - Date: 2026-03-11 ### azure-nsg-inbound-after-nat-outbound-before [IN] OBSERVATION NSG processes inbound traffic after public-to-private IP translation; outbound traffic is processed before private-to-public IP translation. - Source: entries/2026/03/10/vnet-nsg.md - Source hash: cafae416ca6beb29 - Date: 2026-03-11 ### azure-nsg-inbound-after-nat-outbound-before-nat [IN] OBSERVATION NSG processes inbound traffic after public-to-private IP translation; outbound traffic is processed before private-to-public IP translation. - Source: entries/2026/03/11/vnet-nsg.md - Source hash: 7770db13ddbe6897 - Date: 2026-03-11 ### azure-nsg-nat-translation-order [IN] OBSERVATION NSG processes inbound traffic after public-to-private IP translation; outbound traffic is processed before private-to-public IP translation. - Source: entries/2026/03/11/vnet-nsg.md - Source hash: 7770db13ddbe6897 - Date: 2026-03-11 ### azure-nsg-no-duplicate-priority-and-direction [IN] OBSERVATION You cannot create two NSG rules with the same priority and direction. - Source: entries/2026/03/11/vnet-nsg.md - Source hash: 7770db13ddbe6897 - Date: 2026-03-11 ### azure-nsg-no-duplicate-priority-direction [IN] OBSERVATION Two NSG rules cannot have the same priority and direction; each priority value must be unique within a given direction (inbound or outbound). - Source: entries/2026/03/10/vnet-nsg.md - Source hash: cafae416ca6beb29 - Date: 2026-03-11 ### azure-nsg-platform-ips-exempt-but-blockable [IN] OBSERVATION 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`. - Source: entries/2026/03/11/vnet-nsg.md - Source hash: 7770db13ddbe6897 - Date: 2026-03-11 ### azure-nsg-platform-ips-exempt-by-default [IN] OBSERVATION 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). - Source: entries/2026/03/11/vnet-nsg.md - Source hash: 7770db13ddbe6897 - Date: 2026-03-11 ### azure-nsg-priority-range-100-4096 [IN] OBSERVATION NSG security rule priority ranges from 100 to 4096; lower number equals higher priority; processing stops at first match. - Source: entries/2026/03/10/vnet-nsg.md - Source hash: cafae416ca6beb29 - Date: 2026-03-10 ### azure-nsg-rule-removal-no-terminate [IN] OBSERVATION Removing an NSG rule does not terminate existing connections; only new connections are affected. - Source: entries/2026/03/10/vnet-nsg.md - Source hash: cafae416ca6beb29 - Date: 2026-03-10 ### azure-nsg-same-priority-direction-unique [IN] OBSERVATION Cannot create two NSG rules with the same priority and direction within the same NSG. - Source: entries/2026/03/10/vnet-nsg.md - Source hash: cafae416ca6beb29 - Date: 2026-03-11 ### azure-nsg-security-admin-rules-precedence [IN] OBSERVATION Security admin rules from Azure Virtual Network Manager are evaluated before NSG rules; "Always allow" and "Deny" admin rules bypass NSG evaluation entirely. - Source: entries/2026/03/10/vnet-nsg.md - Source hash: cafae416ca6beb29 - Date: 2026-03-10 ### azure-nsg-smtp-port-25-blocked [IN] OBSERVATION 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. - Source: entries/2026/03/10/vnet-nsg.md - Source hash: cafae416ca6beb29 - Date: 2026-03-10 ### azure-nsg-stateful [IN] OBSERVATION NSGs are stateful — if outbound traffic is allowed, the inbound response is automatically allowed (and vice versa). - Source: entries/2026/03/10/vnet-nsg.md - Source hash: cafae416ca6beb29 - Date: 2026-03-10 ### azure-nva-deploy-in-separate-subnet [IN] OBSERVATION Network virtual appliances (NVAs) must be deployed in a different subnet than the routed resources to avoid routing loops. - Source: entries/2026/03/11/vnet-routing.md - Source hash: 2c51a396b7832ca2 - Date: 2026-03-11 ### azure-observability-depends-on-governance-and-identity [IN] OBSERVATION 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-doubly-gated-by-tier-and-identity [IN] OBSERVATION 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. ### azure-os-disk-max-4095-gib-mbr-limits-2-tib [IN] OBSERVATION OS disk maximum capacity is 4,095 GiB; MBR limits usable size to 2 TiB (convert to GPT for more). - Source: entries/2026/03/10/vm-managed-disks.md - Source hash: 7da004de8c26ad53 - Date: 2026-03-10 ### azure-paas-isolation-doubly-tier-gated [IN] OBSERVATION 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. ### azure-paas-progressive-tier-pattern [IN] OBSERVATION 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-cascading-constraint-model [IN] OBSERVATION 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. ### azure-paas-tier-constrains-capability-and-security [IN] OBSERVATION 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. ### azure-performance-diagnostics-continuous-and-on-demand [IN] OBSERVATION Performance Diagnostics has two modes: continuous (5-second intervals, preview) for ongoing monitoring and on-demand for point-in-time deep analysis. - Source: entries/2026/03/11/vm-monitoring.md - Source hash: e56f62adfe29d125 - Date: 2026-03-11 ### azure-platform-ips-exempt-from-nsgs [IN] OBSERVATION 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`. - Source: entries/2026/03/11/vnet-nsg.md - Source hash: 7770db13ddbe6897 - Date: 2026-03-11 ### azure-platform-metrics-time-series-near-realtime-alerting [IN] OBSERVATION Platform metrics are stored in Azure Monitor's time-series database and support near real-time alerting with no configuration required. - Source: entries/2026/03/10/vm-monitoring.md - Source hash: a823dc688cfe1ef4 - Date: 2026-03-11 ### azure-policy-arc-extends-to-multicloud-onprem [IN] OBSERVATION Azure Arc extends Azure Policy governance to multi-cloud and on-premises datacenters. - Source: entries/2026/03/11/policy-overview.md - Source hash: 218b91d31a6ddd65 - Date: 2026-03-11 ### azure-policy-assignments-inherit-latest-definition [IN] OBSERVATION Updating a policy definition automatically applies to all existing assignments; assignments always use the latest definition state. - Source: entries/2026/03/11/policy-overview.md - Source hash: 218b91d31a6ddd65 - Date: 2026-03-11 ### azure-policy-assignments-use-latest-definition [IN] OBSERVATION Updating an Azure Policy definition automatically applies to all existing assignments; assignments always use the latest definition state. - Source: entries/2026/03/11/policy-overview.md - Source hash: 218b91d31a6ddd65 - Date: 2026-03-11 ### azure-policy-audit-if-not-exists-checks-child-resources [IN] OBSERVATION auditIfNotExists assesses compliance based on a child or extension resource's properties, not the resource's own properties (unlike audit). - Source: entries/2026/03/11/policy-effects.md - Source hash: c0891933480973a9 - Date: 2026-03-11 ### azure-policy-audit-if-not-exists-evaluates-child-resource [IN] OBSERVATION `auditIfNotExists` assesses compliance based on a child or extension resource's properties, not the resource's own properties (unlike `audit`). - Source: entries/2026/03/11/policy-effects.md - Source hash: c0891933480973a9 - Date: 2026-03-11 ### azure-policy-best-practice-always-use-initiatives [IN] OBSERVATION Azure Policy best practice: always use initiatives even for a single policy definition, for easier scaling later. - Source: entries/2026/03/11/policy-overview.md - Source hash: 218b91d31a6ddd65 - Date: 2026-03-11 ### azure-policy-best-practice-start-with-audit [IN] OBSERVATION Azure Policy best practice: start with audit/auditIfNotExists effects before enforcement effects (deny, modify, deployIfNotExists). - Source: entries/2026/03/11/policy-overview.md - Source hash: 218b91d31a6ddd65 - Date: 2026-03-11 ### azure-policy-compliance-evaluation-every-24-hours [IN] OBSERVATION Azure Policy automatic compliance evaluation occurs every 24 hours. - Source: entries/2026/03/11/policy-overview.md - Source hash: 218b91d31a6ddd65 - Date: 2026-03-11 ### azure-policy-cumulative-most-restrictive [IN] OBSERVATION When multiple Azure Policy assignments layer on a resource, the net result is the cumulative most restrictive combination of all applicable effects. - Source: entries/2026/03/11/policy-effects.md - Source hash: c0891933480973a9 - Date: 2026-03-11 ### azure-policy-definition-displayname-128-description-512 [IN] OBSERVATION Policy definition `displayName` max length is 128 characters; `description` max length is 512 characters. - Source: entries/2026/03/11/policy-definition-structure.md - Source hash: d6433507e5e7252d - Date: 2026-03-11 ### azure-policy-definition-location-determines-assignment-scope [IN] OBSERVATION 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. - Source: entries/2026/03/11/policy-definition-structure.md - Source hash: d6433507e5e7252d - Date: 2026-03-11 ### azure-policy-definition-mode-all-vs-indexed [IN] OBSERVATION 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`). - Source: entries/2026/03/11/policy-definition-structure.md - Source hash: d6433507e5e7252d - Date: 2026-03-11 ### azure-policy-displayname-128-description-512 [IN] OBSERVATION Policy definition `displayName` max length is 128 characters; `description` max length is 512 characters. - Source: entries/2026/03/11/policy-definition-structure.md - Source hash: d6433507e5e7252d - Date: 2026-03-11 ### azure-policy-effect-evaluation-order [IN] OBSERVATION Azure Policy effect evaluation order: disabled → append/modify → deny → audit → manual → auditIfNotExists → denyAction. - Source: entries/2026/03/11/policy-effects.md - Source hash: c0891933480973a9 - Date: 2026-03-11 ### azure-policy-evaluation-cycle-24-hours [IN] OBSERVATION Azure Policy automatic compliance evaluation occurs every 24 hours; additional triggers include resource create/update, new/updated assignment, and policy update. - Source: entries/2026/03/11/policy-overview.md - Source hash: 218b91d31a6ddd65 - Date: 2026-03-11 ### azure-policy-explicit-deny-system [IN] OBSERVATION 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. - Source: entries/2026/03/11/policy-overview.md - Source hash: 218b91d31a6ddd65 - Date: 2026-03-11 ### azure-policy-max-20-params-definition-400-initiative [IN] OBSERVATION Azure Policy parameter limits: 20 parameters per policy definition, 400 parameters per initiative; up to 1,000 policies per initiative. - Source: entries/2026/03/11/policy-overview.md - Source hash: 218b91d31a6ddd65 - Date: 2026-03-11 ### azure-policy-max-400-notscopes-per-assignment [IN] OBSERVATION Azure Policy supports up to 400 exclusions (notScopes) per assignment. - Source: entries/2026/03/11/policy-overview.md - Source hash: 218b91d31a6ddd65 - Date: 2026-03-11 ### azure-policy-max-500-definitions-per-scope [IN] OBSERVATION 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. - Source: entries/2026/03/11/policy-overview.md - Source hash: 218b91d31a6ddd65 - Date: 2026-03-11 ### azure-policy-metadata-property-limit-1024-chars [IN] OBSERVATION Each Azure Policy metadata property (version, category, preview, deprecated, portalReview) is capped at 1024 characters. - Source: entries/2026/03/11/policy-definition-structure.md - Source hash: d6433507e5e7252d - Date: 2026-03-11 ### azure-policy-mode-all-vs-indexed [IN] OBSERVATION 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`). - Source: entries/2026/03/11/policy-definition-structure.md - Source hash: d6433507e5e7252d - Date: 2026-03-11 ### azure-policy-rp-modes-fully-supported [IN] OBSERVATION Fully supported Resource Provider modes for Azure Policy: `Microsoft.Kubernetes.Data`, `Microsoft.KeyVault.Data`, `Microsoft.Network.Data`. - Source: entries/2026/03/11/policy-definition-structure.md - Source hash: d6433507e5e7252d - Date: 2026-03-11 ### azure-policy-rp-modes-kubernetes-keyvault-network [IN] OBSERVATION 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. - Source: entries/2026/03/11/policy-definition-structure.md - Source hash: d6433507e5e7252d - Date: 2026-03-11 ### azure-policy-single-effect-per-definition [IN] OBSERVATION Each Azure Policy definition contains exactly one effect in its policyRule. - Source: entries/2026/03/11/policy-effects.md - Source hash: c0891933480973a9 - Date: 2026-03-11 ### azure-policy-three-types-builtin-custom-static [IN] OBSERVATION Policy `policyType` has three values (read-only, system-set): Builtin (Microsoft-maintained), Custom (customer-created), and Static (Regulatory Compliance with Microsoft ownership). - Source: entries/2026/03/11/policy-definition-structure.md - Source hash: d6433507e5e7252d - Date: 2026-03-11 ### azure-policy-type-readonly-three-values [IN] OBSERVATION Policy `policyType` is read-only (set by system): `Builtin` (Microsoft-provided), `Custom` (customer-created), or `Static` (Regulatory Compliance with Microsoft ownership). - Source: entries/2026/03/11/policy-definition-structure.md - Source hash: d6433507e5e7252d - Date: 2026-03-11 ### azure-policy-versioning-major-minor-patch [IN] OBSERVATION Azure Policy definitions use `Major.Minor.Patch` versioning: Major for breaking changes, Minor for minor rule/value changes, Patch for string/metadata/security fixes. - Source: entries/2026/03/11/policy-definition-structure.md - Source hash: d6433507e5e7252d - Date: 2026-03-11 ### azure-policy-vs-rbac-state-vs-actions [IN] OBSERVATION Azure Policy evaluates resource state; Azure RBAC evaluates user actions. Policy blocks non-compliant resources regardless of who has permission. - Source: entries/2026/03/11/policy-overview.md - Source hash: 218b91d31a6ddd65 - Date: 2026-03-11 ### azure-private-dns-autoregistration-creates-a-records [IN] OBSERVATION 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. - Source: entries/2026/03/11/dns-private.md - Source hash: 0d9cfc7a53b0dc0e - Date: 2026-03-11 ### azure-private-dns-autoregistration-one-zone-per-vnet [IN] OBSERVATION A VNet can be linked to only one private DNS zone for autoregistration, but multiple VNets can link to the same private zone. - Source: entries/2026/03/10/dns-private.md - Source hash: 30b90cb323c3c59e - Date: 2026-03-10 ### azure-private-dns-avoid-local-domain [IN] OBSERVATION Best practice: do not use `.local` as a private DNS zone domain because not all operating systems support it. - Source: entries/2026/03/10/dns-private.md - Source hash: 30b90cb323c3c59e - Date: 2026-03-10 ### azure-private-dns-conditional-forwarding-requires-resolver [IN] OBSERVATION Conditional forwarding from Azure to on-premises requires Azure DNS Private Resolver. - Source: entries/2026/03/10/dns-private.md - Source hash: 30b90cb323c3c59e - Date: 2026-03-10 ### azure-private-dns-cross-vnet-no-peering [IN] OBSERVATION Cross-VNet DNS resolution via private DNS zones works without VNet peering — only a virtual network link to the shared private zone is needed. - Source: entries/2026/03/10/dns-private.md - Source hash: 30b90cb323c3c59e - Date: 2026-03-10 ### azure-private-dns-global-resource [IN] OBSERVATION Azure Private DNS zone data is a global resource, resilient across regions — not tied to a single VNet or region. - Source: entries/2026/03/10/dns-private.md - Source hash: 30b90cb323c3c59e - Date: 2026-03-10 ### azure-private-dns-no-custom-dns-servers [IN] OBSERVATION Azure Private DNS resolves domain names within Azure virtual networks without needing custom DNS servers. - Source: entries/2026/03/10/dns-overview.md - Source hash: f384b545fe263a12 - Date: 2026-03-11 ### azure-private-dns-reverse-dns-non-autoreg-single-fqdn [IN] OBSERVATION Reverse DNS for private IPs in non-autoregistration linked VNets returns only a single FQDN with the `internal.cloudapp.net` suffix. - Source: entries/2026/03/10/dns-private.md - Source hash: 30b90cb323c3c59e - Date: 2026-03-11 ### azure-private-dns-reverse-dns-two-fqdns [IN] OBSERVATION 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. - Source: entries/2026/03/10/dns-private.md - Source hash: 30b90cb323c3c59e - Date: 2026-03-10 ### azure-private-dns-split-horizon [IN] OBSERVATION 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. - Source: entries/2026/03/11/dns-private.md - Source hash: 0d9cfc7a53b0dc0e - Date: 2026-03-11 ### azure-private-dns-split-horizon-asymmetric-reverse [IN] OBSERVATION 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-supported-record-types [IN] OBSERVATION Azure Private DNS supports record types: A, AAAA, CNAME, MX, PTR, SOA, SRV, TXT. - Source: entries/2026/03/10/dns-private.md - Source hash: 30b90cb323c3c59e - Date: 2026-03-10 ### azure-private-dns-vnet-link-required [IN] OBSERVATION 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. - Source: entries/2026/03/10/dns-private.md - Source hash: 30b90cb323c3c59e - Date: 2026-03-11 ### azure-private-link-network-security-perimeter-ga [IN] OBSERVATION 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. - Source: entries/2026/03/11/vnet-private-link.md - Source hash: 3d8a7a6f7417970f - Date: 2026-03-11 ### azure-regional-vm-no-zone-visibility [IN] OBSERVATION 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. - Source: entries/2026/03/10/vm-availability.md - Source hash: 959915516a33492a - Date: 2026-03-10 ### azure-reservation-operational-flexibility [IN] OBSERVATION 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-reservation-partial-coverage-extends-to-data-services [IN] OBSERVATION 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-partial-coverage-full-flexibility [IN] OBSERVATION 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-reservation-partial-coverage-platform-universal [IN] OBSERVATION 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-prepayment-deducted-first [IN] OBSERVATION Azure Reservation costs are deducted from Azure Prepayment (formerly monetary commitment) balance first; any overage is billed separately. - Source: entries/2026/03/11/vm-reserved-instances.md - Source hash: 6aa7254007a1fe73 - Date: 2026-03-11 ### azure-reservation-software-plans-cover-software-not-infra [IN] OBSERVATION Azure Reservation software plans (SUSE Linux, Red Hat, Azure Red Hat OpenShift) cover software costs only, not VM or infrastructure costs. - Source: entries/2026/03/10/vm-reserved-instances.md - Source hash: 76a74aefb970f033 - Date: 2026-03-11 ### azure-reservations-applied-hourly-except-databricks [IN] OBSERVATION All Azure Reservations are applied on an hourly basis except Azure Databricks. - Source: entries/2026/03/10/vm-reserved-instances.md - Source hash: 76a74aefb970f033 - Date: 2026-03-10 ### azure-reservations-billing-only-no-runtime-impact [IN] OBSERVATION Azure Reservations are purely a billing construct and do not affect the runtime state of resources. - Source: entries/2026/03/10/vm-reserved-instances.md - Source hash: 76a74aefb970f033 - Date: 2026-03-10 ### azure-reservations-blob-capacity-only [IN] OBSERVATION Azure Reservations for Blob Storage cover capacity only — not bandwidth or transaction costs. - Source: entries/2026/03/11/vm-reserved-instances.md - Source hash: 6aa7254007a1fe73 - Date: 2026-03-11 ### azure-reservations-can-be-split-and-scope-changed [IN] OBSERVATION Azure Reservations can be split into smaller parts after purchase, and the scope can be changed after purchase. - Source: entries/2026/03/11/vm-reserved-instances.md - Source hash: 6aa7254007a1fe73 - Date: 2026-03-11 ### azure-reservations-can-be-split-post-purchase [IN] OBSERVATION Azure Reservations can be split into smaller parts after purchase, and instance size flexibility can be changed post-purchase. - Source: entries/2026/03/10/vm-reserved-instances.md - Source hash: 76a74aefb970f033 - Date: 2026-03-11 ### azure-reservations-cosmosdb-throughput-only [IN] OBSERVATION Azure Reservations for Cosmos DB cover provisioned throughput only — not storage or networking costs. - Source: entries/2026/03/11/vm-reserved-instances.md - Source hash: 6aa7254007a1fe73 - Date: 2026-03-11 ### azure-reservations-deduct-from-prepayment-first [IN] OBSERVATION Azure Reservation costs deduct from Azure Prepayment (Monetary Commitment) balance first; overage is billed separately. - Source: entries/2026/03/10/vm-reserved-instances.md - Source hash: 76a74aefb970f033 - Date: 2026-03-11 ### azure-reservations-exchange-same-type-or-refund [IN] OBSERVATION Azure Reservations can be exchanged for the same resource type or refunded within the $50,000 USD rolling 12-month cap. - Source: entries/2026/03/11/vm-reserved-instances.md - Source hash: 6aa7254007a1fe73 - Date: 2026-03-11 ### azure-reservations-exchangeable-and-splittable [IN] OBSERVATION 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). - Source: entries/2026/03/11/vm-reserved-instances.md - Source hash: 6aa7254007a1fe73 - Date: 2026-03-11 ### azure-reservations-exchangeable-same-type [IN] OBSERVATION Azure Reservations can be exchanged for same-type reservations after purchase. - Source: entries/2026/03/10/vm-reserved-instances.md - Source hash: 76a74aefb970f033 - Date: 2026-03-11 ### azure-reservations-monthly-upfront-same-cost [IN] OBSERVATION Azure Reservation monthly and up-front payment options have the same total cost — no premium for monthly payments. - Source: entries/2026/03/11/vm-reserved-instances.md - Source hash: 6aa7254007a1fe73 - Date: 2026-03-11 ### azure-reservations-monthly-upfront-same-total-cost [IN] OBSERVATION Azure Reservation monthly and up-front payment options have the same total cost; there is no premium for choosing monthly payments. - Source: entries/2026/03/11/vm-reserved-instances.md - Source hash: 6aa7254007a1fe73 - Date: 2026-03-11 ### azure-reservations-prepayment-deducted-first [IN] OBSERVATION Azure Reservation costs are deducted from Azure Prepayment (formerly monetary commitment) balance first; overage is billed separately. - Source: entries/2026/03/11/vm-reserved-instances.md - Source hash: 6aa7254007a1fe73 - Date: 2026-03-11 ### azure-reservations-refund-cap-50k-12-months [IN] OBSERVATION Azure Reservations can be refunded up to $50,000 USD in a rolling 12-month window. - Source: entries/2026/03/10/vm-reserved-instances.md - Source hash: 76a74aefb970f033 - Date: 2026-03-10 ### azure-reservations-scope-changeable-after-purchase [IN] OBSERVATION Azure Reservation scope (which subscriptions/resource groups receive the discount) can be changed after purchase. - Source: entries/2026/03/11/vm-reserved-instances.md - Source hash: 6aa7254007a1fe73 - Date: 2026-03-11 ### azure-reservations-scope-updatable-after-purchase [IN] OBSERVATION Azure Reservation scope controls where savings apply and can be updated after purchase. - Source: entries/2026/03/10/vm-reserved-instances.md - Source hash: 76a74aefb970f033 - Date: 2026-03-11 ### azure-reservations-splittable-after-purchase [IN] OBSERVATION Azure Reservations can be split into smaller parts and have instance size flexibility changed after purchase. - Source: entries/2026/03/10/vm-reserved-instances.md - Source hash: 76a74aefb970f033 - Date: 2026-03-11 ### azure-reservations-up-to-72-percent-discount [IN] OBSERVATION Azure Reservations provide billing discounts of up to 72% off pay-as-you-go prices with 1-year or 3-year commitment terms. - Source: entries/2026/03/10/vm-reserved-instances.md - Source hash: 76a74aefb970f033 - Date: 2026-03-10 ### azure-reserves-5-ips-per-subnet [IN] OBSERVATION Azure reserves 5 IP addresses per subnet: first address (network), last address (broadcast), and 3 for Azure services. - Source: entries/2026/03/10/vnet-subnets.md - Source hash: 65ce293e7b4bbd7b - Date: 2026-03-10 ### azure-resource-manager-lock-prevents-account-deletion-not-data [IN] OBSERVATION Resource Manager locks prevent storage account deletion but do not prevent data deletion within the account. - Source: entries/2026/03/10/storage-security.md - Source hash: 06ede0dd3e80f917 - Date: 2026-03-10 ### azure-revoke-service-sas-stored-access-policy [IN] OBSERVATION To revoke a service SAS with a stored access policy: delete the policy, rename it, or set its expiry to the past. - Source: entries/2026/03/10/storage-security.md - Source hash: 06ede0dd3e80f917 - Date: 2026-03-11 ### azure-revoke-service-sas-via-stored-access-policy [IN] OBSERVATION To revoke a service SAS with a stored access policy: delete the policy, rename it, or set its expiry to the past. - Source: entries/2026/03/10/storage-security.md - Source hash: 06ede0dd3e80f917 - Date: 2026-03-11 ### azure-revoke-user-delegation-sas-revoke-delegation-key [IN] OBSERVATION To revoke a user delegation SAS, revoke the user delegation key, which invalidates all SAS tokens signed with that key. - Source: entries/2026/03/10/storage-security.md - Source hash: 06ede0dd3e80f917 - Date: 2026-03-11 ### azure-revoke-user-delegation-sas-revoke-key [IN] OBSERVATION To revoke a user delegation SAS, you must revoke the user delegation key, which invalidates all SAS tokens signed with that key. - Source: entries/2026/03/11/storage-security.md - Source hash: 07106caa167c5877 - Date: 2026-03-11 ### azure-revoke-user-delegation-sas-revokes-all [IN] OBSERVATION To revoke a user delegation SAS, you revoke the user delegation key, which invalidates all SAS tokens signed with that key. - Source: entries/2026/03/11/storage-security.md - Source hash: 07106caa167c5877 - Date: 2026-03-11 ### azure-sentinel-defender-store-in-log-analytics-workspaces [IN] OBSERVATION Microsoft Sentinel and Microsoft Defender for Cloud both store their security data in Azure Monitor Log Analytics workspaces. - Source: entries/2026/03/11/monitor-logs.md - Source hash: 110d65756a36ba5d - Date: 2026-03-11 ### azure-service-endpoints-vs-private-link [IN] OBSERVATION Service endpoints secure PaaS resources to the VNet over public endpoints; Private Link provides private access to a specific service instance via private IP. - Source: entries/2026/03/10/vnet-overview.md - Source hash: b35bdec5b58da622 - Date: 2026-03-10 ### azure-service-sas-without-stored-access-policy-cannot-be-revoked [IN] OBSERVATION A service SAS not associated with a stored access policy cannot be revoked; best practice is to limit expiry to one hour or less. - Source: entries/2026/03/10/storage-security.md - Source hash: 06ede0dd3e80f917 - Date: 2026-03-10 ### azure-shared-disks-require-cluster-manager [IN] OBSERVATION Shared managed disks (attached to multiple VMs simultaneously) require a cluster manager such as WSFC or Pacemaker. - Source: entries/2026/03/10/vm-managed-disks.md - Source hash: 7da004de8c26ad53 - Date: 2026-03-10 ### azure-site-recovery-not-restricted-to-paired-regions [IN] OBSERVATION Azure Site Recovery enables cross-region failover and is not restricted to paired regions. - Source: entries/2026/03/10/vm-linux.md - Source hash: 9d3c30a406cb3ab3 - Date: 2026-03-10 ### azure-site-recovery-supports-four-replication-sources [IN] OBSERVATION Azure Site Recovery supports replication for Azure VMs between regions, on-premises VMs, Azure Stack VMs, and physical servers. - Source: entries/2026/03/10/vm-availability.md - Source hash: 959915516a33492a - Date: 2026-03-10 ### azure-site-recovery-testable-failover [IN] OBSERVATION Azure Site Recovery supports testable failover without impacting production workloads. - Source: entries/2026/03/10/vm-windows.md - Source hash: 662dc218304d5937 - Date: 2026-03-11 ### azure-soft-delete-separate-for-blobs-and-containers [IN] OBSERVATION Soft delete is available for both blobs and containers as separate settings that must be enabled independently. - Source: entries/2026/03/10/storage-security.md - Source hash: 06ede0dd3e80f917 - Date: 2026-03-10 ### azure-software-plans-cover-software-not-infra [IN] OBSERVATION Azure software plan reservations (SUSE Linux, Red Hat, Azure Red Hat OpenShift) cover software costs only, not VM or infrastructure costs. - Source: entries/2026/03/10/vm-reserved-instances.md - Source hash: 76a74aefb970f033 - Date: 2026-03-11 ### azure-spot-arg-pricing-90d-eviction-28d [IN] OBSERVATION Azure Resource Graph Spot pricing history covers 90 days; eviction rate data covers 28 days via the SpotResources table. - Source: entries/2026/03/11/vm-spot.md - Source hash: e5c61f75e25f7c2e - Date: 2026-03-11 ### azure-spot-pricing-history-via-resource-graph [IN] OBSERVATION Azure Spot VM pricing history (90 days) and eviction rates (28 days) can be queried programmatically via the `SpotResources` table in Azure Resource Graph. - Source: entries/2026/03/10/vm-spot.md - Source hash: 32e542d7d5d0848e - Date: 2026-03-11 ### azure-spot-vm-all-regions-except-21vianet [IN] OBSERVATION Spot VMs are available in all Azure regions except Microsoft Azure operated by 21Vianet. - Source: entries/2026/03/10/vm-spot.md - Source hash: 32e542d7d5d0848e - Date: 2026-03-11 ### azure-spot-vm-arg-pricing-90d-eviction-28d [IN] OBSERVATION Azure Resource Graph provides 90 days of Spot VM pricing history and 28 days of eviction rate data via the SpotResources table. - Source: entries/2026/03/11/vm-spot.md - Source hash: e5c61f75e25f7c2e - Date: 2026-03-11 ### azure-spot-vm-b-series-not-supported [IN] OBSERVATION B-series and promo-version VM sizes are not supported for Spot VMs. - Source: entries/2026/03/10/vm-spot.md - Source hash: 32e542d7d5d0848e - Date: 2026-03-10 ### azure-spot-vm-cannot-convert-after-creation [IN] OBSERVATION Spot VMs cannot be converted to standard VMs or vice versa after creation; the Spot flag is set only at creation time. - Source: entries/2026/03/10/vm-spot.md - Source hash: 32e542d7d5d0848e - Date: 2026-03-10 ### azure-spot-vm-compound-constraint-envelope [IN] OBSERVATION 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. ### azure-spot-vm-default-eviction-policy-deallocate [IN] OBSERVATION The default eviction policy for Azure Spot VMs is Deallocate (not Delete); deallocated Spot VMs still consume quota and incur storage charges. - Source: entries/2026/03/10/vm-spot.md - Source hash: 32e542d7d5d0848e - Date: 2026-03-10 ### azure-spot-vm-evicted-not-auto-restarted [IN] OBSERVATION Evicted Spot VMs are not automatically restarted even if the spot price drops below the configured max price again. - Source: entries/2026/03/10/vm-spot.md - Source hash: 32e542d7d5d0848e - Date: 2026-03-11 ### azure-spot-vm-eviction-rate-per-hour-7day-trailing [IN] OBSERVATION Spot VM eviction rates represent a per-hour probability of eviction based on trailing 7-day historical data. - Source: entries/2026/03/11/vm-spot.md - Source hash: e5c61f75e25f7c2e - Date: 2026-03-11 ### azure-spot-vm-eviction-rate-per-hour-trailing-7d [IN] OBSERVATION 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. - Source: entries/2026/03/11/vm-spot.md - Source hash: e5c61f75e25f7c2e - Date: 2026-03-11 ### azure-spot-vm-eviction-rate-per-hour-trailing-7day [IN] OBSERVATION Spot VM eviction rate is expressed as a per-hour probability based on trailing 7-day historical data. - Source: entries/2026/03/11/vm-spot.md - Source hash: e5c61f75e25f7c2e - Date: 2026-03-11 ### azure-spot-vm-max-price-change-requires-deallocation [IN] OBSERVATION Spot VM max price can only be changed after the VM is deallocated. - Source: entries/2026/03/10/vm-spot.md - Source hash: 32e542d7d5d0848e - Date: 2026-03-11 ### azure-spot-vm-max-price-minus-1-no-price-eviction [IN] OBSERVATION 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. - Source: entries/2026/03/10/vm-spot.md - Source hash: 32e542d7d5d0848e - Date: 2026-03-10 ### azure-spot-vm-must-deallocate-to-change-max-price [IN] OBSERVATION A Spot VM must be deallocated before its maximum price can be changed. - Source: entries/2026/03/11/vm-spot.md - Source hash: e5c61f75e25f7c2e - Date: 2026-03-11 ### azure-spot-vm-no-sla-30s-eviction [IN] OBSERVATION Azure Spot VMs have no SLA and can be evicted with approximately 30 seconds' notice via Azure Scheduled Events. - Source: entries/2026/03/10/vm-spot.md - Source hash: 32e542d7d5d0848e - Date: 2026-03-10 ### azure-spot-vm-not-auto-restarted-after-eviction [IN] OBSERVATION Evicted Spot VMs are not automatically restarted, even if the spot price drops below the configured max price again. - Source: entries/2026/03/10/vm-spot.md - Source hash: 32e542d7d5d0848e - Date: 2026-03-11 ### azure-spot-vm-not-available-21vianet [IN] OBSERVATION Azure Spot VMs are available in all regions except Microsoft Azure operated by 21Vianet. - Source: entries/2026/03/10/vm-spot.md - Source hash: 32e542d7d5d0848e - Date: 2026-03-11 ### azure-spot-vm-operational-constraints [IN] OBSERVATION 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. ### azure-spot-vm-separate-quota-pool [IN] OBSERVATION Spot VMs use a separate quota pool from standard VMs, shared between Spot VMs and Spot scale-set instances. - Source: entries/2026/03/10/vm-spot.md - Source hash: 32e542d7d5d0848e - Date: 2026-03-10 ### azure-spot-vm-supported-offer-types [IN] OBSERVATION Spot VMs are supported for Enterprise Agreement, Pay-as-you-go (003P), Sponsored (0036P/0136P), and CSP offer types. - Source: entries/2026/03/10/vm-spot.md - Source hash: 32e542d7d5d0848e - Date: 2026-03-11 ### azure-sql-reservation-compute-only [IN] OBSERVATION SQL Database and SQL Managed Instance reservations cover compute costs only (plus zone-redundancy add-on for General Purpose tier). - Source: entries/2026/03/11/vm-reserved-instances.md - Source hash: 6aa7254007a1fe73 - Date: 2026-03-11 ### azure-sql-service-endpoint-same-region-only [IN] OBSERVATION For Azure SQL Database, service endpoint traffic applies only within the same region. - Source: entries/2026/03/11/vnet-service-endpoints.md - Source hash: b67307e3ae3272c1 - Date: 2026-03-11 ### azure-sql-service-endpoints-same-region-only [IN] OBSERVATION Azure SQL Database service endpoints apply only within the VNet's region. - Source: entries/2026/03/10/vnet-service-endpoints.md - Source hash: e9acb2ed1bb8de24 - Date: 2026-03-11 ### azure-standard-hdd-os-disk-retiring-sep-2028 [IN] OBSERVATION Standard HDD as an OS disk type is retiring on September 8, 2028. - Source: entries/2026/03/11/vm-managed-disks.md - Source hash: 943eec739dc0f12d - Date: 2026-03-11 ### azure-standard-hdd-os-disk-retiring-sept-2028 [IN] OBSERVATION Standard HDD as OS disk is retiring on September 8, 2028. - Source: entries/2026/03/10/vm-managed-disks.md - Source hash: 7da004de8c26ad53 - Date: 2026-03-10 ### azure-storage-anonymous-read-access-disable-by-default [IN] OBSERVATION 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. - Source: entries/2026/03/11/storage-security.md - Source hash: 07106caa167c5877 - Date: 2026-03-11 ### azure-storage-anonymous-read-access-disabled-recommended [IN] OBSERVATION 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. - Source: entries/2026/03/11/storage-security.md - Source hash: 07106caa167c5877 - Date: 2026-03-11 ### azure-storage-disallow-cross-tenant-object-replication [IN] OBSERVATION Cross-tenant object replication can be disallowed to restrict replication policies to same-tenant storage accounts only. - Source: entries/2026/03/11/storage-security.md - Source hash: 07106caa167c5877 - Date: 2026-03-11 ### azure-storage-encryption-at-rest-automatic [IN] OBSERVATION All Azure Storage data is automatically encrypted at rest; customers can optionally manage their own keys via Azure Key Vault. - Source: entries/2026/03/10/storage-overview.md - Source hash: 7de2f80c18a9ae0b - Date: 2026-03-10 ### azure-storage-encrypts-all-data-at-rest-by-default [IN] OBSERVATION Azure Storage encrypts all data at rest by default using Microsoft-managed keys. - Source: entries/2026/03/10/storage-security.md - Source hash: 06ede0dd3e80f917 - Date: 2026-03-10 ### azure-storage-firewall-blocks-all-by-default [IN] OBSERVATION When Azure Storage firewall rules are enabled, all requests are blocked by default — exceptions must be added for trusted Microsoft services. - Source: entries/2026/03/11/storage-security.md - Source hash: 07106caa167c5877 - Date: 2026-03-11 ### azure-storage-firewall-trusted-microsoft-services-exception [IN] OBSERVATION When enabling storage account firewall rules, an exception for trusted Microsoft services should be added to avoid blocking Azure portal, logging, and metrics. - Source: entries/2026/03/10/storage-security.md - Source hash: 06ede0dd3e80f917 - Date: 2026-03-11 ### azure-storage-four-auth-methods [IN] OBSERVATION Azure Storage supports four authorization methods: Microsoft Entra ID (recommended), Shared Key, SAS tokens, and AD DS (for NetApp Files). - Source: entries/2026/03/10/storage-overview.md - Source hash: 7de2f80c18a9ae0b - Date: 2026-03-10 ### azure-storage-private-endpoints-assign-private-ip [IN] OBSERVATION Private endpoints assign a private IP from a VNet to the storage account, routing all traffic over a private link. - Source: entries/2026/03/11/storage-security.md - Source hash: 07106caa167c5877 - Date: 2026-03-11 ### azure-storage-private-endpoints-private-ip-from-vnet [IN] OBSERVATION Private endpoints assign a private IP from a VNet to the storage account, routing all traffic over a private link. - Source: entries/2026/03/11/storage-security.md - Source hash: 07106caa167c5877 - Date: 2026-03-11 ### azure-storage-require-secure-transfer-https-only [IN] OBSERVATION Secure transfer can be enforced on storage accounts via the `supportsHttpsTrafficOnly: true` ARM template setting, requiring HTTPS-only connections. - Source: entries/2026/03/11/storage-security.md - Source hash: 07106caa167c5877 - Date: 2026-03-11 ### azure-storage-resource-manager-lock-does-not-protect-data [IN] OBSERVATION Azure Resource Manager locks protect the storage account from deletion but do NOT prevent data within the account from being deleted. - Source: entries/2026/03/11/storage-security.md - Source hash: 07106caa167c5877 - Date: 2026-03-11 ### azure-storage-secure-transfer-requires-https [IN] OBSERVATION The secure transfer setting on a storage account requires HTTPS for all requests. - Source: entries/2026/03/10/storage-security.md - Source hash: 06ede0dd3e80f917 - Date: 2026-03-11 ### azure-suse-redhat-plans-software-only [IN] OBSERVATION SUSE and Red Hat software plans cover software costs only — not underlying VM compute usage. - Source: entries/2026/03/11/vm-reserved-instances.md - Source hash: 6aa7254007a1fe73 - Date: 2026-03-11 ### azure-system-assigned-identity-lifecycle [IN] OBSERVATION System-assigned managed identity is deleted automatically with its parent resource and cannot be shared across resources (1:1 relationship). - Source: entries/2026/03/10/entra-managed-identities.md - Source hash: 0939df3c5ee17c6d - Date: 2026-03-10 ### azure-system-assigned-identity-sp-name-matches-resource [IN] OBSERVATION System-assigned managed identity service principal name matches the Azure resource name; for deployment slots the pattern is `/slots/`. - Source: entries/2026/03/10/entra-managed-identities.md - Source hash: 0939df3c5ee17c6d - Date: 2026-03-11 ### azure-table-storage-part-of-cosmos-db [IN] OBSERVATION Azure Table Storage is now part of Azure Cosmos DB; Cosmos DB for Table offers throughput-optimized tables, global distribution, and automatic secondary indexes. - Source: entries/2026/03/11/storage-overview.md - Source hash: addad2bc68f34f7f - Date: 2026-03-11 ### azure-temp-disk-drive-letters-windows-d-linux-dev-resource [IN] OBSERVATION Windows temporary disk is drive D; Linux temporary disk is `/dev/disk/azure/resource`. - Source: entries/2026/03/10/vm-managed-disks.md - Source hash: 7da004de8c26ad53 - Date: 2026-03-11 ### azure-temp-disk-path-linux-resource-windows-d [IN] OBSERVATION Temporary disk paths: Linux = `/dev/disk/azure/resource`, Windows = drive D. - Source: entries/2026/03/11/vm-managed-disks.md - Source hash: 943eec739dc0f12d - Date: 2026-03-11 ### azure-temp-disk-paths-linux-resource-windows-d [IN] OBSERVATION Temporary disk paths: Linux = `/dev/disk/azure/resource`, Windows = drive D. - Source: entries/2026/03/11/vm-managed-disks.md - Source hash: 943eec739dc0f12d - Date: 2026-03-11 ### azure-temp-disk-paths-linux-windows [IN] OBSERVATION Temporary disk paths: Linux = `/dev/disk/azure/resource`, Windows = drive D. - Source: entries/2026/03/11/vm-managed-disks.md - Source hash: 943eec739dc0f12d - Date: 2026-03-11 ### azure-temp-disk-v5-plus-auto-encrypt [IN] OBSERVATION VMs v5 and newer automatically encrypt temporary and ephemeral OS disks at rest. - Source: entries/2026/03/11/vm-managed-disks.md - Source hash: 943eec739dc0f12d - Date: 2026-03-11 ### azure-temporary-disk-not-managed-disk [IN] OBSERVATION The temporary disk is not a managed disk and data can be lost on maintenance events, redeployment, or VM stop. - Source: entries/2026/03/10/vm-managed-disks.md - Source hash: 7da004de8c26ad53 - Date: 2026-03-10 ### azure-three-availability-zones-per-supported-region [IN] OBSERVATION There are exactly 3 Availability Zones per supported Azure region, each with distinct power, network, and cooling. - Source: entries/2026/03/10/vm-availability.md - Source hash: 959915516a33492a - Date: 2026-03-10 ### azure-tls-enforcement-universal-pattern [IN] OBSERVATION 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-dns-based-global [IN] OBSERVATION Azure Traffic Manager is a DNS-based (not network-level) traffic load balancer operating at global scope across Azure regions. - Source: entries/2026/03/10/dns-overview.md - Source hash: f384b545fe263a12 - Date: 2026-03-10 ### azure-user-assigned-identity-shareable [IN] OBSERVATION User-assigned managed identities have an independent lifecycle, must be explicitly deleted, and can be shared across multiple Azure resources. - Source: entries/2026/03/10/entra-managed-identities.md - Source hash: 0939df3c5ee17c6d - Date: 2026-03-10 ### azure-user-delegation-sas-uses-entra-credentials [IN] OBSERVATION User delegation SAS is the most secure SAS type because it uses Microsoft Entra credentials rather than account keys. - Source: entries/2026/03/10/storage-security.md - Source hash: 06ede0dd3e80f917 - Date: 2026-03-10 ### azure-v5-plus-vms-auto-encrypt-temp-disks [IN] OBSERVATION VMs v5+ automatically encrypt temporary disks at rest without additional configuration. - Source: entries/2026/03/10/vm-managed-disks.md - Source hash: 7da004de8c26ad53 - Date: 2026-03-11 ### azure-vhd-direct-upload-max-32-tib [IN] OBSERVATION VHDs can be uploaded up to 32 TiB directly to managed disks without attaching to a VM. - Source: entries/2026/03/10/vm-managed-disks.md - Source hash: 7da004de8c26ad53 - Date: 2026-03-11 ### azure-vm-associated-resources-billed-separately [IN] OBSERVATION 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. - Source: entries/2026/03/10/vm-overview.md - Source hash: 13602ec377e5a2fd - Date: 2026-03-11 ### azure-vm-availability-zones-sla-99-99 [IN] OBSERVATION Azure VMs achieve a 99.99% SLA when 2+ instances are deployed across 2+ Availability Zones in the same region. - Source: entries/2026/03/10/vm-overview.md - Source hash: 13602ec377e5a2fd - Date: 2026-03-10 ### azure-vm-b-series-cpu-credit-model [IN] OBSERVATION 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. - Source: entries/2026/03/10/vm-sizes.md - Source hash: 916833c248c3e584 - Date: 2026-03-10 ### azure-vm-best-practice-separate-data-disk [IN] OBSERVATION Best practice is to keep data on a separate managed disk from the OS disk for recoverability and independent management. - Source: entries/2026/03/10/vm-overview.md - Source hash: 13602ec377e5a2fd - Date: 2026-03-11 ### azure-vm-billed-per-minute [IN] OBSERVATION Azure VMs are billed per-minute (not per-hour); for partial hours only minutes used are charged. - Source: entries/2026/03/10/vm-linux.md - Source hash: 9d3c30a406cb3ab3 - Date: 2026-03-10 ### azure-vm-billing-per-minute [IN] OBSERVATION Azure VMs are billed per-minute for partial hours; storage is billed separately. - Source: entries/2026/03/10/vm-windows.md - Source hash: 662dc218304d5937 - Date: 2026-03-10 ### azure-vm-boot-diagnostics-enabled-by-default [IN] OBSERVATION Boot diagnostics is enabled by default when creating a VM in the Azure portal. - Source: entries/2026/03/10/vm-monitoring.md - Source hash: a823dc688cfe1ef4 - Date: 2026-03-10 ### azure-vm-cloud-init-linux [IN] OBSERVATION Cloud-init is supported on most Azure Linux distributions for automated VM provisioning at first boot. - Source: entries/2026/03/10/vm-windows.md - Source hash: 662dc218304d5937 - Date: 2026-03-11 ### azure-vm-cloud-init-supported-linux-vmss [IN] OBSERVATION Cloud-init is supported across most Linux distributions for automated deployment and configuration on both VMs and VMSS. - Source: entries/2026/03/11/vm-overview.md - Source hash: 033703b5aa9da0e8 - Date: 2026-03-11 ### azure-vm-cloud-init-supported-most-linux [IN] OBSERVATION Cloud-init is supported on most Azure Linux distributions for automated VM provisioning. - Source: entries/2026/03/10/vm-overview.md - Source hash: 13602ec377e5a2fd - Date: 2026-03-11 ### azure-vm-cost-three-dimensions [IN] OBSERVATION 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). ### azure-vm-d-family-default-general-purpose [IN] OBSERVATION General Purpose D-family is the default recommendation for most production workloads, offering balanced CPU-to-memory ratio. - Source: entries/2026/03/10/vm-sizes.md - Source hash: 916833c248c3e584 - Date: 2026-03-11 ### azure-vm-d-suffix-local-nvme [IN] OBSERVATION 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. - Source: entries/2026/03/10/vm-windows.md - Source hash: 662dc218304d5937 - Date: 2026-03-10 ### azure-vm-d-suffix-local-nvme-ephemeral [IN] OBSERVATION 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. - Source: entries/2026/03/10/vm-overview.md - Source hash: 13602ec377e5a2fd - Date: 2026-03-10 ### azure-vm-data-residency-single-region-sea-brazil [IN] OBSERVATION Single-region data residency storage is only available in Southeast Asia (Singapore) and Brazil South; all other regions store data at the Geo level. - Source: entries/2026/03/10/vm-windows.md - Source hash: 662dc218304d5937 - Date: 2026-03-10 ### azure-vm-dc-ec-confidential-computing [IN] OBSERVATION DC and EC VM families provide confidential computing with hardware-based Trusted Execution Environments (TEEs). - Source: entries/2026/03/10/vm-sizes.md - Source hash: 916833c248c3e584 - Date: 2026-03-10 ### azure-vm-default-core-quota-20-per-region [IN] OBSERVATION Default Azure VM quota is 20 total cores per region per subscription, which can be raised via support ticket. - Source: entries/2026/03/10/vm-linux.md - Source hash: 9d3c30a406cb3ab3 - Date: 2026-03-10 ### azure-vm-default-quota-20-cores-per-region [IN] OBSERVATION Azure subscriptions have a default quota of 20 VM total cores per region, which can be increased via support ticket. - Source: entries/2026/03/10/vm-overview.md - Source hash: 13602ec377e5a2fd - Date: 2026-03-10 ### azure-vm-f-family-compute-optimized-high-cpu-ratio [IN] OBSERVATION F-family VMs are compute optimized with a high CPU-to-memory ratio, suited for batch processing, web servers, and analytics. - Source: entries/2026/03/11/vm-sizes.md - Source hash: f9da63a0b4470367 - Date: 2026-03-11 ### azure-vm-f-family-high-cpu-to-memory-ratio [IN] OBSERVATION F-family VMs are compute optimized with a high CPU-to-memory ratio, suited for batch processing, web servers, and analytics. - Source: entries/2026/03/11/vm-sizes.md - Source hash: f9da63a0b4470367 - Date: 2026-03-11 ### azure-vm-fx-family-high-single-core-performance [IN] OBSERVATION FX-family VMs target specialized compute with high single-core performance for EDA, financial modeling, and scientific simulations. - Source: entries/2026/03/11/vm-sizes.md - Source hash: f9da63a0b4470367 - Date: 2026-03-11 ### azure-vm-gpu-families-nd-nc-nv-ngads [IN] OBSERVATION Azure GPU VM families serve distinct purposes: ND for AI training/inference, NC for GPU compute, NV for visualization/VDI, NGads for gaming. - Source: entries/2026/03/11/vm-sizes.md - Source hash: f9da63a0b4470367 - Date: 2026-03-11 ### azure-vm-gpu-nc-compute-nd-training-nv-visualization [IN] OBSERVATION Azure GPU VM families: NC-series for general GPU compute, ND-series for deep learning training/inference, NV-series for visualization and streaming. - Source: entries/2026/03/10/vm-sizes.md - Source hash: 916833c248c3e584 - Date: 2026-03-11 ### azure-vm-gpu-nd-training-nc-compute-nv-visualization [IN] OBSERVATION GPU VM families: ND for AI training/inference, NC for compute-intensive GPU, NV for visualization/remote graphics, NGads for gaming. - Source: entries/2026/03/11/vm-sizes.md - Source hash: f9da63a0b4470367 - Date: 2026-03-11 ### azure-vm-guest-metrics-require-ama-plus-dcr [IN] OBSERVATION Guest OS metrics require Azure Monitor Agent (AMA) plus a data collection rule (DCR) to be configured. - Source: entries/2026/03/10/vm-monitoring.md - Source hash: a823dc688cfe1ef4 - Date: 2026-03-10 ### azure-vm-hb-family-infiniband-rdma-mpi [IN] OBSERVATION HB-family VM sizes support InfiniBand, RDMA, and MPI for tightly coupled parallel HPC workloads. - Source: entries/2026/03/10/vm-sizes.md - Source hash: 916833c248c3e584 - Date: 2026-03-11 ### azure-vm-host-metrics-collected-automatically [IN] OBSERVATION VM host metrics (CPU, network, disk from Hyper-V session) are collected automatically with no setup required. - Source: entries/2026/03/10/vm-monitoring.md - Source hash: a823dc688cfe1ef4 - Date: 2026-03-10 ### azure-vm-hpc-hb-memory-hc-compute-hx-extreme [IN] OBSERVATION Azure HPC VM families: HB for memory-bandwidth-sensitive HPC (weather, CFD), HC for dense computation, HX for extreme memory workloads (EDA). - Source: entries/2026/03/11/vm-sizes.md - Source hash: f9da63a0b4470367 - Date: 2026-03-11 ### azure-vm-insights-auto-installs-ama-creates-dcr [IN] OBSERVATION VM Insights automatically installs Azure Monitor Agent and creates a default DCR; it is the recommended starting point for VM monitoring. - Source: entries/2026/03/10/vm-monitoring.md - Source hash: a823dc688cfe1ef4 - Date: 2026-03-10 ### azure-vm-insights-map-populates-four-tables [IN] OBSERVATION VM Insights Map feature populates four tables: `VMBoundPort`, `VMComputer`, `VMConnection`, and `VMProcess`; the main DCR writes to the `InsightsMetrics` table. - Source: entries/2026/03/11/vm-monitoring.md - Source hash: e56f62adfe29d125 - Date: 2026-03-11 ### azure-vm-insights-tables [IN] OBSERVATION VM Insights populates five tables: InsightsMetrics (performance), VMBoundPort, VMComputer, VMConnection, and VMProcess (dependency map data). - Source: entries/2026/03/10/vm-monitoring.md - Source hash: a823dc688cfe1ef4 - Date: 2026-03-11 ### azure-vm-l-family-high-disk-throughput-io [IN] OBSERVATION L-family VMs are Storage Optimized for high disk throughput and IO, suited for NoSQL databases (Cassandra, MongoDB), Redis, and data warehousing. - Source: entries/2026/03/10/vm-sizes.md - Source hash: 916833c248c3e584 - Date: 2026-03-11 ### azure-vm-l-family-storage-optimized-high-io [IN] OBSERVATION L-family VMs are storage optimized with high disk throughput and IO, ideal for NoSQL databases (Cassandra, MongoDB, Redis). - Source: entries/2026/03/11/vm-sizes.md - Source hash: f9da63a0b4470367 - Date: 2026-03-11 ### azure-vm-l-family-storage-optimized-high-throughput [IN] OBSERVATION L-family VMs are storage optimized for high disk throughput and IO workloads such as Cassandra, MongoDB, and Redis. - Source: entries/2026/03/10/vm-sizes.md - Source hash: 916833c248c3e584 - Date: 2026-03-11 ### azure-vm-m-family-largest-memory [IN] OBSERVATION M-family VMs offer the largest memory capacities in Azure (up to multiple TB of RAM) for workloads like SAP HANA and large databases. - Source: entries/2026/03/10/vm-sizes.md - Source hash: 916833c248c3e584 - Date: 2026-03-10 ### azure-vm-managed-disks-recommended-convertible [IN] OBSERVATION Azure Managed Disks are recommended over unmanaged disks for production workloads; unmanaged disks can be converted to managed disks. - Source: entries/2026/03/10/vm-overview.md - Source hash: 13602ec377e5a2fd - Date: 2026-03-11 ### azure-vm-move-between-vnets-requires-recreate [IN] OBSERVATION Moving a VM between VNets requires deleting and recreating the VM (disks can be retained). - Source: entries/2026/03/10/vnet-overview.md - Source hash: b35bdec5b58da622 - Date: 2026-03-10 ### azure-vm-nic-count-limited-by-size [IN] OBSERVATION The number of NICs attached to a VM is limited by the VM size; there is no separate cost for NICs. - Source: entries/2026/03/10/vm-windows.md - Source hash: 662dc218304d5937 - Date: 2026-03-11 ### azure-vm-nic-count-limited-by-vm-size [IN] OBSERVATION Virtual NICs have no separate cost but the number of NICs a VM can have is limited by VM size. - Source: entries/2026/03/11/vm-linux.md - Source hash: 6595565e73896e7a - Date: 2026-03-11 ### azure-vm-nsg-local-disk-no-cost [IN] OBSERVATION NSGs and local temporary disks have no additional cost; NICs have no separate cost. - Source: entries/2026/03/10/vm-windows.md - Source hash: 662dc218304d5937 - Date: 2026-03-10 ### azure-vm-nsg-nic-no-charge [IN] OBSERVATION Azure NSGs and NICs have no additional charge; NIC count limits are determined by VM size. - Source: entries/2026/03/10/vm-overview.md - Source hash: 13602ec377e5a2fd - Date: 2026-03-10 ### azure-vm-os-disk-default-127gib [IN] OBSERVATION Azure VM OS disk default size is approximately 127 GiB. - Source: entries/2026/03/10/vm-windows.md - Source hash: 662dc218304d5937 - Date: 2026-03-10 ### azure-vm-os-disk-default-size-127gib [IN] OBSERVATION Azure VM OS disks have a default size of approximately 127 GiB (smaller for some images). - Source: entries/2026/03/10/vm-overview.md - Source hash: 13602ec377e5a2fd - Date: 2026-03-10 ### azure-vm-os-disk-typically-127-gib [IN] OBSERVATION Azure VM OS disk is typically 127 GiB (smaller for some images). - Source: entries/2026/03/10/vm-linux.md - Source hash: 9d3c30a406cb3ab3 - Date: 2026-03-10 ### azure-vm-performance-diagnostics-continuous-and-ondemand [IN] OBSERVATION Azure VM Performance Diagnostics supports two modes: continuous (5-second intervals, preview) and on-demand (point-in-time deep analysis). - Source: entries/2026/03/11/vm-monitoring.md - Source hash: e56f62adfe29d125 - Date: 2026-03-11 ### azure-vm-reservation-partial-cost-coverage [IN] OBSERVATION 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. ### azure-vm-reservations-cover-compute-only [IN] OBSERVATION VM reservations cover compute costs only — networking, storage, Windows licensing, and additional software are not included. - Source: entries/2026/03/10/vm-reserved-instances.md - Source hash: 76a74aefb970f033 - Date: 2026-03-10 ### azure-vm-s-suffix-premium-storage [IN] OBSERVATION The 's' suffix in Azure VM size names indicates Premium Storage (SSD) capability. - Source: entries/2026/03/10/vm-sizes.md - Source hash: 916833c248c3e584 - Date: 2026-03-10 ### azure-vm-six-size-categories [IN] OBSERVATION 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). - Source: entries/2026/03/10/vm-sizes.md - Source hash: 916833c248c3e584 - Date: 2026-03-10 ### azure-vm-size-cpu-vendor-letters [IN] OBSERVATION In VM size names, no CPU letter indicates Intel x86-64, 'a' indicates AMD, and 'p' indicates ARM (Cobalt/Ampere Altra). - Source: entries/2026/03/10/vm-sizes.md - Source hash: 916833c248c3e584 - Date: 2026-03-10 ### azure-vm-size-series-vs-size-naming [IN] OBSERVATION Series name omits vCPU count (e.g., DCads_v5); full size name includes Standard prefix and vCPU count (e.g., Standard_DC8ads_v5). - Source: entries/2026/03/11/vm-sizes.md - Source hash: f9da63a0b4470367 - Date: 2026-03-11 ### azure-vm-size-version-higher-is-newer [IN] OBSERVATION VM size version numbers (v5, v6, v7) indicate hardware generations — higher is newer; the first version may omit the version number. - Source: entries/2026/03/10/vm-sizes.md - Source hash: 916833c248c3e584 - Date: 2026-03-11 ### azure-vm-size-version-numbers-indicate-hw-generation [IN] OBSERVATION VM size version numbers (v5, v6, v7) indicate hardware generations — higher is newer; first-generation sizes may omit the version number. - Source: entries/2026/03/10/vm-sizes.md - Source hash: 916833c248c3e584 - Date: 2026-03-11 ### azure-vm-sizes-with-d-include-local-nvme-ephemeral [IN] OBSERVATION VM sizes with 'd' in the name include local NVMe ephemeral storage; data is not persisted across deallocation. - Source: entries/2026/03/10/vm-linux.md - Source hash: 9d3c30a406cb3ab3 - Date: 2026-03-10 ### azure-vm-specialized-compute-family-taxonomy [IN] OBSERVATION 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-priced-separately-from-compute [IN] OBSERVATION Azure VM storage (OS disk, data disks) is priced and charged separately from compute costs. - Source: entries/2026/03/11/vm-overview.md - Source hash: 033703b5aa9da0e8 - Date: 2026-03-11 ### azure-vm-temp-disk-drive-letters [IN] OBSERVATION Windows temporary disk is drive D; Linux temporary disk is at /dev/disk/azure/resource. - Source: entries/2026/03/10/vm-managed-disks.md - Source hash: 7da004de8c26ad53 - Date: 2026-03-11 ### azure-vm-trusted-launch-default-gen2 [IN] OBSERVATION Trusted Launch (secure boot + vTPM) is becoming the default for new Gen2 VMs (preview feature called TLaD). - Source: entries/2026/03/10/vm-windows.md - Source hash: 662dc218304d5937 - Date: 2026-03-10 ### azure-vm-trusted-launch-default-gen2-preview [IN] OBSERVATION Trusted Launch as Default (TLaD) is a preview feature where new Gen 2 VMs default to Trusted Launch with secure boot and vTPM enabled. - Source: entries/2026/03/10/vm-overview.md - Source hash: 13602ec377e5a2fd - Date: 2026-03-10 ### azure-vm-v5-plus-auto-encrypt-temp-disk [IN] OBSERVATION VMs v5+ automatically encrypt temporary disks at rest without additional configuration. - Source: entries/2026/03/10/vm-managed-disks.md - Source hash: 7da004de8c26ad53 - Date: 2026-03-11 ### azure-vm-v5-plus-auto-encrypt-temp-disks [IN] OBSERVATION VMs v5 and newer automatically encrypt temporary and ephemeral OS disks at rest. - Source: entries/2026/03/11/vm-managed-disks.md - Source hash: 943eec739dc0f12d - Date: 2026-03-11 ### azure-vm-windows-licensing-port-1688 [IN] OBSERVATION Windows VM licensing uses outbound port 1688 to connect to the Key Management Service. - Source: entries/2026/03/10/vnet-nsg.md - Source hash: cafae416ca6beb29 - Date: 2026-03-11 ### azure-vmss-flexible-max-1000-vms [IN] OBSERVATION VMSS Flexible orchestration supports up to 1,000 VMs with standard marketplace or Azure Compute Gallery images; managed images cap at 600. - Source: entries/2026/03/10/vm-scale-sets.md - Source hash: a596f2076e7310d3 - Date: 2026-03-10 ### azure-vmss-flexible-supports-mixed-spot-ondemand [IN] OBSERVATION VMSS Flexible orchestration supports mixing Spot and on-demand VM instances within the same scale set. - Source: entries/2026/03/10/vm-scale-sets.md - Source hash: a596f2076e7310d3 - Date: 2026-03-11 ### azure-vmss-flexible-supports-spot-and-ondemand-mix [IN] OBSERVATION VMSS Flexible orchestration mode supports mixing Spot and on-demand VMs together in the same scale set. - Source: entries/2026/03/11/vm-scale-sets.md - Source hash: 7c4c932daee55fde - Date: 2026-03-11 ### azure-vmss-flexible-supports-spot-and-ondemand-mixed [IN] OBSERVATION VMSS Flexible orchestration supports mixing Spot and on-demand VM instances together in the same scale set. - Source: entries/2026/03/11/vm-scale-sets.md - Source hash: 7c4c932daee55fde - Date: 2026-03-11 ### azure-vmss-max-1000-vms-marketplace-images [IN] OBSERVATION Virtual Machine Scale Sets support up to 1,000 VMs when using Marketplace or Compute Gallery images with managed disks. - Source: entries/2026/03/11/vm-managed-disks.md - Source hash: 943eec739dc0f12d - Date: 2026-03-11 ### azure-vmss-no-additional-cost [IN] OBSERVATION There is no extra cost for the VMSS resource itself — you pay only for underlying compute, network, and storage resources. - Source: entries/2026/03/10/vm-scale-sets.md - Source hash: a596f2076e7310d3 - Date: 2026-03-10 ### azure-vmss-orchestration-mode-immutable [IN] OBSERVATION VMSS orchestration mode (Uniform or Flexible) is set at creation time and cannot be changed later. - Source: entries/2026/03/10/vm-scale-sets.md - Source hash: a596f2076e7310d3 - Date: 2026-03-10 ### azure-vmss-requires-availability-zones-for-dc-protection [IN] OBSERVATION Scale sets alone do not protect against datacenter failure — Availability Zones must be used for cross-datacenter protection. - Source: entries/2026/03/10/vm-scale-sets.md - Source hash: a596f2076e7310d3 - Date: 2026-03-10 ### azure-vmss-same-base-image-and-config [IN] OBSERVATION All VM instances in a scale set are created from the same base OS image and configuration. - Source: entries/2026/03/11/vm-scale-sets.md - Source hash: 7c4c932daee55fde - Date: 2026-03-11 ### azure-vmss-same-base-image-config [IN] OBSERVATION All VM instances in a scale set are created from the same base OS image and configuration. - Source: entries/2026/03/11/vm-scale-sets.md - Source hash: 7c4c932daee55fde - Date: 2026-03-11 ### azure-vnet-free [IN] OBSERVATION Azure Virtual Network itself is free; standard charges apply only to resources deployed within it. - Source: entries/2026/03/10/vnet-overview.md - Source hash: b35bdec5b58da622 - Date: 2026-03-10 ### azure-vnet-peering-address-resize-no-downtime [IN] OBSERVATION 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. - Source: entries/2026/03/11/vnet-peering.md - Source hash: f75674f68b190e02 - Date: 2026-03-11 ### azure-vnet-peering-charges-ingress-egress [IN] OBSERVATION VNet peering incurs a nominal fee on both ingress and egress traffic. - Source: entries/2026/03/10/vnet-peering.md - Source hash: 8e93f76569ceaac3 - Date: 2026-03-11 ### azure-vnet-peering-cross-subscription-tenant [IN] OBSERVATION VNet peering works across subscriptions, Microsoft Entra tenants, deployment models (ARM and classic), and regions. - Source: entries/2026/03/10/vnet-peering.md - Source hash: 8e93f76569ceaac3 - Date: 2026-03-10 ### azure-vnet-peering-default-limit-500 [IN] OBSERVATION Default VNet peering limit is 500 peered VNets per VNet; increased to 1,000 with Azure Virtual Network Manager connectivity configuration. - Source: entries/2026/03/10/vnet-peering.md - Source hash: 8e93f76569ceaac3 - Date: 2026-03-10 ### azure-vnet-peering-enterprise-backbone-connectivity [IN] OBSERVATION 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. ### azure-vnet-peering-gateway-transit-one-gateway [IN] OBSERVATION A VNet using gateway transit with a remote gateway cannot have its own gateway; the gateway must be in a Resource Manager model VNet. - Source: entries/2026/03/10/vnet-peering.md - Source hash: 8e93f76569ceaac3 - Date: 2026-03-10 ### azure-vnet-peering-ingress-egress-charges [IN] OBSERVATION VNet peering incurs nominal charges for both ingress and egress traffic on peering connections; gateway transit incurs peering charges on the spoke VNet. - Source: entries/2026/03/11/vnet-peering.md - Source hash: f75674f68b190e02 - Date: 2026-03-11 ### azure-vnet-peering-microsoft-backbone [IN] OBSERVATION VNet peering traffic stays on the Microsoft backbone — no encryption, gateways, or public internet needed. - Source: entries/2026/03/10/vnet-peering.md - Source hash: 8e93f76569ceaac3 - Date: 2026-03-10 ### azure-vnet-peering-no-downtime [IN] OBSERVATION No downtime occurs when creating VNet peering connections. - Source: entries/2026/03/10/vnet-peering.md - Source hash: 8e93f76569ceaac3 - Date: 2026-03-10 ### azure-vnet-peering-not-transitive [IN] OBSERVATION 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. - Source: entries/2026/03/11/vnet-peering.md - Source hash: f75674f68b190e02 - Date: 2026-03-11 ### azure-vnet-peering-same-region-latency-equal [IN] OBSERVATION 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. - Source: entries/2026/03/10/vnet-peering.md - Source hash: 8e93f76569ceaac3 - Date: 2026-03-11 ### azure-vnet-peering-same-region-same-latency [IN] OBSERVATION Latency between VMs in peered VNets within the same region equals latency within a single VNet. - Source: entries/2026/03/10/vnet-peering.md - Source hash: 8e93f76569ceaac3 - Date: 2026-03-11 ### azure-vnet-peering-subnet-level [IN] OBSERVATION Subnet peering allows peering of specific subnets rather than entire VNet address spaces. - Source: entries/2026/03/11/vnet-peering.md - Source hash: f75674f68b190e02 - Date: 2026-03-11 ### azure-vnet-peering-subnet-peering [IN] OBSERVATION Subnet peering allows peering of specific subnets rather than entire VNets, narrowing the scope of connectivity. - Source: entries/2026/03/10/vnet-peering.md - Source hash: 8e93f76569ceaac3 - Date: 2026-03-11 ### azure-vnet-routing-never-associate-default-route-to-gatewaysubnet [IN] OBSERVATION Never associate a route table with a 0.0.0.0/0 route to GatewaySubnet for VPN gateways — it will break gateway functionality. - Source: entries/2026/03/11/vnet-routing.md - Source hash: 2c51a396b7832ca2 - Date: 2026-03-11 ### azure-vnet-routing-service-tag-priority-order [IN] OBSERVATION 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. - Source: entries/2026/03/11/vnet-routing.md - Source hash: 2c51a396b7832ca2 - Date: 2026-03-11 ### azure-vnet-service-endpoints-extend-private-address-space [IN] OBSERVATION 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. - Source: entries/2026/03/11/vnet-overview.md - Source hash: 8facfec87e00d937 - Date: 2026-03-11 ### azure-vnet-service-endpoints-extend-private-space [IN] OBSERVATION 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. - Source: entries/2026/03/11/vnet-overview.md - Source hash: 8facfec87e00d937 - Date: 2026-03-11 ### azure-vnet-subnets-span-all-azs [IN] OBSERVATION VNets and subnets span all availability zones in a region automatically — no need to divide by AZ. - Source: entries/2026/03/10/vnet-overview.md - Source hash: b35bdec5b58da622 - Date: 2026-03-10 ### azure-vpn-gateway-custom-dns-must-include-168 [IN] OBSERVATION When using VPN Gateway with custom DNS servers, the Azure DNS IP `168.63.129.16` must be included in the DNS server list. - Source: entries/2026/03/11/vnet-dns.md - Source hash: 3ca61552c4ae8d0d - Date: 2026-03-11 ### azure-vpn-gateway-custom-dns-requires-azure-dns-ip [IN] OBSERVATION When using VPN Gateway with custom DNS servers, `168.63.129.16` must be included in the DNS server list. - Source: entries/2026/03/11/vnet-dns.md - Source hash: 3ca61552c4ae8d0d - Date: 2026-03-11 ### azuresql-99-99-availability-sla [IN] OBSERVATION Azure SQL Database offers a 99.99% availability SLA - Source: entries/2026/03/10/azuresql-database.md - Source hash: 63957c0208ffead0 - Date: 2026-03-10 ### azuresql-99-99-sla [IN] OBSERVATION Azure SQL Database guarantees 99.99% SLA availability (up to 99.995% per the Azure SQL family overview). - Source: entries/2026/03/11/azuresql-database.md - Source hash: 18a4a03ce657ec62 - Date: 2026-03-11 ### azuresql-active-geo-replication-4-secondaries [IN] OBSERVATION Azure SQL Database active geo-replication supports up to 4 readable secondary databases in same or different regions - Source: entries/2026/03/10/azuresql-database.md - Source hash: 63957c0208ffead0 - Date: 2026-03-10 ### azuresql-always-encrypted-client-side-keys [IN] OBSERVATION Always Encrypted keeps encryption keys on the client side; even DBAs cannot see plaintext data. - Source: entries/2026/03/10/azuresql-security.md - Source hash: 9180bb356c162c2c - Date: 2026-03-10 ### azuresql-always-encrypted-protects-from-dbas [IN] OBSERVATION Always Encrypted keeps encryption keys outside the database engine, protecting data even from database administrators — data is encrypted at rest and in use. - Source: entries/2026/03/11/azuresql-security.md - Source hash: bbdfa23555c23515 - Date: 2026-03-11 ### azuresql-audit-destinations-storage-monitor-eventhubs [IN] OBSERVATION SQL Auditing writes audit logs to customer-owned Azure storage, Azure Monitor logs, or Event Hubs. - Source: entries/2026/03/11/azuresql-security.md - Source hash: bbdfa23555c23515 - Date: 2026-03-11 ### azuresql-automatic-tuning-index-and-plan [IN] OBSERVATION Azure SQL Database automatic tuning includes automatic index management and automatic plan correction. - Source: entries/2026/03/11/azuresql-database.md - Source hash: 18a4a03ce657ec62 - Date: 2026-03-11 ### azuresql-automatic-tuning-index-plan [IN] OBSERVATION Azure SQL Database automatic tuning includes automatic index management and automatic plan correction. - Source: entries/2026/03/11/azuresql-database.md - Source hash: 18a4a03ce657ec62 - Date: 2026-03-11 ### azuresql-backup-compression-3-4x-tde-log-exception [IN] OBSERVATION Azure SQL Database backups are compressed with typical 3–4x ratio, but TDE-encrypted transaction log backups are NOT compressed. - Source: entries/2026/03/11/azuresql-backup.md - Source hash: c4ccd56c4fb10fa3 - Date: 2026-03-11 ### azuresql-backup-dr-planning-constraints [IN] OBSERVATION 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. ### azuresql-backup-free-storage-equals-max-data-size [IN] OBSERVATION Azure SQL Database provides free backup storage equal to the provisioned max data size; excess is billed per GB/month. - Source: entries/2026/03/11/azuresql-backup.md - Source hash: c4ccd56c4fb10fa3 - Date: 2026-03-11 ### azuresql-backup-frequency [IN] OBSERVATION Azure SQL Database automated backups: full weekly, differential every 12h (vCore) or 24h (DTU), transaction log ~10 minutes - Source: entries/2026/03/10/azuresql-backup.md - Source hash: b7947157003043b3 - Date: 2026-03-10 ### azuresql-backup-redundancy-change-48h-future-only [IN] OBSERVATION Azure SQL Database backup redundancy changes apply only to future backups, may take up to 48 hours, and existing backups remain on original storage. - Source: entries/2026/03/11/azuresql-backup.md - Source hash: c4ccd56c4fb10fa3 - Date: 2026-03-11 ### azuresql-backup-str-max-35-days-basic-7 [IN] OBSERVATION 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. - Source: entries/2026/03/11/azuresql-backup.md - Source hash: c4ccd56c4fb10fa3 - Date: 2026-03-11 ### azuresql-basic-tier-max-retention-7-days [IN] OBSERVATION Azure SQL Database Basic tier short-term backup retention maximum is 7 days (vs 35 days for other tiers) - Source: entries/2026/03/11/azuresql-backup.md - Source hash: c4ccd56c4fb10fa3 - Date: 2026-03-11 ### azuresql-bc-backups-on-secondary-replicas [IN] OBSERVATION Azure SQL Database Business Critical tier runs automated backups on secondary replicas by default, offloading the primary with no extra cost. - Source: entries/2026/03/10/azuresql-backup.md - Source hash: b7947157003043b3 - Date: 2026-03-11 ### azuresql-best-practice-custom-roles-least-privilege [IN] OBSERVATION Best practice: use custom database roles with least privilege; never assign permissions directly to users; limit db_owner to administrative users only. - Source: entries/2026/03/11/azuresql-security.md - Source hash: bbdfa23555c23515 - Date: 2026-03-11 ### azuresql-best-practice-roles-least-privilege [IN] OBSERVATION Best practice: assign users to database roles with least privilege; avoid direct permission grants to users; limit db_owner role to administrative users only. - Source: entries/2026/03/11/azuresql-security.md - Source hash: bbdfa23555c23515 - Date: 2026-03-11 ### azuresql-business-critical-backups-from-secondary [IN] OBSERVATION Azure SQL Database Business Critical tier takes backups from secondary replicas by default to offload the primary - Source: entries/2026/03/11/azuresql-backup.md - Source hash: c4ccd56c4fb10fa3 - Date: 2026-03-11 ### azuresql-business-critical-backups-on-secondary [IN] OBSERVATION Azure SQL Database Business Critical tier runs automated backups on secondary replicas by default, offloading the primary with no extra cost. - Source: entries/2026/03/10/azuresql-backup.md - Source hash: b7947157003043b3 - Date: 2026-03-11 ### azuresql-clr-not-in-sql-database [IN] OBSERVATION CLR support is not available in Azure SQL Database but is supported in Managed Instance. - Source: entries/2026/03/10/azuresql-overview.md - Source hash: 2922382d91c42f93 - Date: 2026-03-10 ### azuresql-cmk-tde-server-or-database-level [IN] OBSERVATION Customer-managed keys (CMK) for TDE can be configured at the logical server level (all databases) or at the individual database level. - Source: entries/2026/03/11/azuresql-security.md - Source hash: bbdfa23555c23515 - Date: 2026-03-11 ### azuresql-connectivity-architecture-diverges-by-deployment-model [IN] OBSERVATION 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. ### azuresql-cross-subscription-restore-not-supported [IN] OBSERVATION Azure SQL Database cross-subscription restore is not supported for PITR, geo-restore, or LTR; workaround is restore then Resource Move - Source: entries/2026/03/11/azuresql-backup.md - Source hash: c4ccd56c4fb10fa3 - Date: 2026-03-11 ### azuresql-default-backup-redundancy-grs [IN] OBSERVATION Azure SQL Database default backup storage redundancy is geo-redundant (GRS); GZRS is Microsoft-recommended for maximum resilience - Source: entries/2026/03/10/azuresql-backup.md - Source hash: b7947157003043b3 - Date: 2026-03-10 ### azuresql-default-pitr-retention-7-days [IN] OBSERVATION Azure SQL Database default PITR retention is 7 days (configurable 1–35 days; Basic tier limited to 1–7 days) - Source: entries/2026/03/10/azuresql-backup.md - Source hash: b7947157003043b3 - Date: 2026-03-10 ### azuresql-deleted-db-restore-same-server-only [IN] OBSERVATION Azure SQL Database deleted database restore is only possible on the same server where the original was created - Source: entries/2026/03/11/azuresql-backup.md - Source hash: c4ccd56c4fb10fa3 - Date: 2026-03-11 ### azuresql-do-not-set-trustservercertificate-true [IN] OBSERVATION Setting TrustServerCertificate=True in production disables protection against man-in-the-middle attacks; always use TrustServerCertificate=False. - Source: entries/2026/03/11/azuresql-security.md - Source hash: bbdfa23555c23515 - Date: 2026-03-11 ### azuresql-dynamic-data-masking-no-stored-change [IN] OBSERVATION Dynamic Data Masking masks data in query results but does not change the underlying stored data. - Source: entries/2026/03/10/azuresql-security.md - Source hash: 9180bb356c162c2c - Date: 2026-03-10 ### azuresql-dynamic-scaling-manual-no-downtime [IN] OBSERVATION Azure SQL Database dynamic scaling is manual with no downtime; automatic autoscaling requires the serverless compute tier. - Source: entries/2026/03/11/azuresql-database.md - Source hash: 18a4a03ce657ec62 - Date: 2026-03-11 ### azuresql-dynamic-scaling-manual-not-auto [IN] OBSERVATION Azure SQL Database dynamic scaling is manual with no downtime; automatic autoscaling requires serverless tier - Source: entries/2026/03/11/azuresql-database.md - Source hash: 18a4a03ce657ec62 - Date: 2026-03-11 ### azuresql-dynamic-scaling-vs-autoscaling [IN] OBSERVATION Azure SQL Database dynamic scaling is manual (no downtime) while autoscaling is automatic and only available via the serverless compute tier. - Source: entries/2026/03/10/azuresql-database.md - Source hash: 63957c0208ffead0 - Date: 2026-03-11 ### azuresql-elastic-pool-shared-resources [IN] OBSERVATION Azure SQL Database elastic pools share vCore/DTU resources across multiple databases, optimizing cost for SaaS multitenant patterns with variable workloads - Source: entries/2026/03/11/azuresql-database.md - Source hash: 18a4a03ce657ec62 - Date: 2026-03-11 ### azuresql-elastic-pool-shared-resources-saas [IN] OBSERVATION Azure SQL Database elastic pools share resources across multiple databases, ideal for SaaS multitenant patterns with unpredictable usage. - Source: entries/2026/03/11/azuresql-database.md - Source hash: 18a4a03ce657ec62 - Date: 2026-03-11 ### azuresql-elastic-pools-vs-instance-pools [IN] OBSERVATION Elastic pools are for Azure SQL Database; instance pools are for Azure SQL Managed Instance. - Source: entries/2026/03/10/azuresql-overview.md - Source hash: 2922382d91c42f93 - Date: 2026-03-10 ### azuresql-features-ship-first [IN] OBSERVATION New SQL Server features release to Azure SQL Database first, then to on-premises SQL Server - Source: entries/2026/03/10/azuresql-database.md - Source hash: 63957c0208ffead0 - Date: 2026-03-10 ### azuresql-firewall-rules-not-apply-to-mi [IN] OBSERVATION IP and VNet firewall rules do NOT apply to Azure SQL Managed Instance; it uses its own networking configuration. - Source: entries/2026/03/10/azuresql-security.md - Source hash: 9180bb356c162c2c - Date: 2026-03-10 ### azuresql-first-full-backup-30-minutes [IN] OBSERVATION Azure SQL Database completes its first full backup within approximately 30 minutes of database creation. - Source: entries/2026/03/11/azuresql-backup.md - Source hash: c4ccd56c4fb10fa3 - Date: 2026-03-11 ### azuresql-free-backup-storage-equals-max-data-size [IN] OBSERVATION Azure SQL Database free backup storage equals the provisioned maximum data size; excess is billed per GB/month - Source: entries/2026/03/11/azuresql-backup.md - Source hash: c4ccd56c4fb10fa3 - Date: 2026-03-11 ### azuresql-geo-restore-requires-grs-or-gzrs [IN] OBSERVATION Azure SQL Database geo-restore is disabled when backup redundancy is set to LRS or ZRS - Source: entries/2026/03/10/azuresql-backup.md - Source hash: b7947157003043b3 - Date: 2026-03-10 ### azuresql-gzrs-restore-inherits-unless-overridden [IN] OBSERVATION 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. - Source: entries/2026/03/11/azuresql-backup.md - Source hash: c4ccd56c4fb10fa3 - Date: 2026-03-11 ### azuresql-ha-business-critical-always-on-ag-replicas [IN] OBSERVATION 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. - Source: entries/2026/03/10/azuresql-ha.md - Source hash: ee5d08f2258a7843 - Date: 2026-03-10 ### azuresql-ha-business-critical-read-scale-out-no-extra-cost [IN] OBSERVATION Read Scale-Out is a Business Critical / Premium feature that offloads read-only queries to secondary replicas at no additional charge. - Source: entries/2026/03/10/azuresql-ha.md - Source hash: ee5d08f2258a7843 - Date: 2026-03-10 ### azuresql-ha-general-purpose-zone-uses-zrs [IN] OBSERVATION Azure SQL Database General Purpose zone redundancy uses Zone-Redundant Storage (ZRS) for data and log files. - Source: entries/2026/03/10/azuresql-ha.md - Source hash: ee5d08f2258a7843 - Date: 2026-03-10 ### azuresql-ha-hyperscale-failover-cmd-not-for-secondaries [IN] OBSERVATION The manual failover command (Invoke-AzSqlDatabaseFailover) is NOT available for readable secondary replicas of Hyperscale databases. - Source: entries/2026/03/11/azuresql-ha.md - Source hash: 34fb7e3ba659b336 - Date: 2026-03-11 ### azuresql-ha-hyperscale-failover-not-for-readable-secondary [IN] OBSERVATION The manual failover command is not available for readable secondary replicas of Hyperscale databases. - Source: entries/2026/03/10/azuresql-ha.md - Source hash: ee5d08f2258a7843 - Date: 2026-03-11 ### azuresql-ha-hyperscale-four-layer-architecture [IN] OBSERVATION 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. - Source: entries/2026/03/10/azuresql-ha.md - Source hash: ee5d08f2258a7843 - Date: 2026-03-11 ### azuresql-ha-hyperscale-zone-redundancy-creation-only [IN] OBSERVATION Hyperscale zone redundancy can only be set at database creation time; changing it afterward requires database copy, point-in-time restore, or geo-replica. - Source: entries/2026/03/10/azuresql-ha.md - Source hash: ee5d08f2258a7843 - Date: 2026-03-10 ### azuresql-ha-hyperscale-zone-requires-ha-replica [IN] OBSERVATION Hyperscale zone redundancy requires at least one HA compute replica and zone-redundant or geo-zone-redundant backup storage. - Source: entries/2026/03/11/azuresql-ha.md - Source hash: 34fb7e3ba659b336 - Date: 2026-03-11 ### azuresql-ha-hyperscale-zr-requires-ha-replica [IN] OBSERVATION Hyperscale zone redundancy requires at least one HA compute replica and zone-redundant or geo-zone-redundant backup storage. - Source: entries/2026/03/10/azuresql-ha.md - Source hash: ee5d08f2258a7843 - Date: 2026-03-11 ### azuresql-ha-local-redundancy-lrs-three-copies [IN] OBSERVATION Azure SQL Database local redundancy uses Locally Redundant Storage (LRS), copying data three times within a single datacenter. - Source: entries/2026/03/10/azuresql-ha.md - Source hash: ee5d08f2258a7843 - Date: 2026-03-10 ### azuresql-ha-manual-failover-rate-limit-15min [IN] OBSERVATION Azure SQL Database manual failover is rate-limited to once per 15 minutes per database or elastic pool. - Source: entries/2026/03/10/azuresql-ha.md - Source hash: ee5d08f2258a7843 - Date: 2026-03-10 ### azuresql-ha-master-db-auto-zone-redundant [IN] OBSERVATION The master database automatically becomes zone-redundant when any database on the logical server is zone-redundant. - Source: entries/2026/03/11/azuresql-ha.md - Source hash: 34fb7e3ba659b336 - Date: 2026-03-11 ### azuresql-ha-remote-storage-cold-cache-degradation [IN] OBSERVATION Azure SQL Database General Purpose (remote storage model) may experience performance degradation during failover due to cold cache on the new compute node. - Source: entries/2026/03/10/azuresql-ha.md - Source hash: ee5d08f2258a7843 - Date: 2026-03-11 ### azuresql-ha-remote-storage-cold-cache-failover [IN] OBSERVATION Remote storage model (General Purpose) may experience performance degradation during failover due to cold cache startup on the new compute node. - Source: entries/2026/03/11/azuresql-ha.md - Source hash: 34fb7e3ba659b336 - Date: 2026-03-11 ### azuresql-ha-rpo-zero-local-and-zone [IN] OBSERVATION Azure SQL Database RPO is zero (no committed data loss) for both local and zone-redundant configurations. - Source: entries/2026/03/10/azuresql-ha.md - Source hash: ee5d08f2258a7843 - Date: 2026-03-10 ### azuresql-ha-service-fabric-manages-failover [IN] OBSERVATION Azure Service Fabric manages health monitoring and failover across all Azure SQL Database availability models. - Source: entries/2026/03/11/azuresql-ha.md - Source hash: 34fb7e3ba659b336 - Date: 2026-03-11 ### azuresql-ha-three-availability-models [IN] OBSERVATION 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). - Source: entries/2026/03/11/azuresql-ha.md - Source hash: 34fb7e3ba659b336 - Date: 2026-03-11 ### azuresql-ha-zero-rpo-cold-cache-tradeoff [IN] OBSERVATION 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. ### azuresql-ha-zone-redundancy-not-available-basic-standard [IN] OBSERVATION Zone redundancy is NOT available for Azure SQL Database Basic and Standard (DTU) service tiers. - Source: entries/2026/03/10/azuresql-ha.md - Source hash: ee5d08f2258a7843 - Date: 2026-03-10 ### azuresql-hybrid-benefit-requires-software-assurance [IN] OBSERVATION Azure Hybrid Benefit for SQL requires Software Assurance on existing SQL Server licenses. - Source: entries/2026/03/10/azuresql-managed-instance.md - Source hash: 0c4b7ba9f2036eb6 - Date: 2026-03-11 ### azuresql-hyperscale-128tb-max [IN] OBSERVATION Azure SQL Database Hyperscale tier supports up to 128 TB storage with independently scalable compute and storage - Source: entries/2026/03/10/azuresql-database.md - Source hash: 63957c0208ffead0 - Date: 2026-03-10 ### azuresql-hyperscale-backup-redundancy-immutable [IN] OBSERVATION Azure SQL Hyperscale backup redundancy can only be set at creation time and cannot be modified later - Source: entries/2026/03/10/azuresql-backup.md - Source hash: b7947157003043b3 - Date: 2026-03-10 ### azuresql-hyperscale-distributed-scale-architecture [IN] OBSERVATION 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. ### azuresql-hyperscale-failover-not-for-readable-secondaries [IN] OBSERVATION The manual failover command is not available for readable secondary replicas of Hyperscale databases. - Source: entries/2026/03/10/azuresql-ha.md - Source hash: ee5d08f2258a7843 - Date: 2026-03-11 ### azuresql-hyperscale-four-layer-architecture [IN] OBSERVATION 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. - Source: entries/2026/03/10/azuresql-ha.md - Source hash: ee5d08f2258a7843 - Date: 2026-03-11 ### azuresql-hyperscale-snapshot-based-backups [IN] OBSERVATION Azure SQL Hyperscale uses storage snapshots instead of traditional SQL Server backup technology, providing instant backup and fast restore regardless of database size - Source: entries/2026/03/10/azuresql-backup.md - Source hash: b7947157003043b3 - Date: 2026-03-10 ### azuresql-hyperscale-zone-requires-ha-replica-and-zr-backup [IN] OBSERVATION Hyperscale zone redundancy requires at least one HA compute replica and zone-redundant or geo-zone-redundant backup storage. - Source: entries/2026/03/10/azuresql-ha.md - Source hash: ee5d08f2258a7843 - Date: 2026-03-11 ### azuresql-immutable-backups-ltr-only [IN] OBSERVATION Azure SQL Database immutable backups are supported only for long-term retention (LTR), not for PITR or geo-restore - Source: entries/2026/03/11/azuresql-backup.md - Source hash: c4ccd56c4fb10fa3 - Date: 2026-03-11 ### azuresql-ledger-cryptographic-tamper-evidence [IN] OBSERVATION Azure SQL Ledger provides cryptographic proof of data integrity and tamper-evidence for regulatory compliance and auditability. - Source: entries/2026/03/11/azuresql-security.md - Source hash: bbdfa23555c23515 - Date: 2026-03-11 ### azuresql-ledger-tamper-evidence [IN] OBSERVATION Azure SQL Ledger provides cryptographic proof of data integrity (tamper-evidence) for regulatory compliance and auditability. - Source: entries/2026/03/11/azuresql-security.md - Source hash: bbdfa23555c23515 - Date: 2026-03-11 ### azuresql-ltr-up-to-10-years [IN] OBSERVATION Azure SQL Database long-term retention (LTR) supports up to 10 years of backup retention - Source: entries/2026/03/10/azuresql-backup.md - Source hash: b7947157003043b3 - Date: 2026-03-10 ### azuresql-master-db-auto-zone-redundant [IN] OBSERVATION The master database on an Azure SQL logical server automatically becomes zone-redundant when any database on that server is zone-redundant. - Source: entries/2026/03/11/azuresql-ha.md - Source hash: 34fb7e3ba659b336 - Date: 2026-03-11 ### azuresql-max-database-sizes [IN] OBSERVATION Azure SQL max database sizes: SQL Database = 128 TB, Managed Instance = 16 TB, SQL VMs = 256 TB. - Source: entries/2026/03/10/azuresql-overview.md - Source hash: 2922382d91c42f93 - Date: 2026-03-10 ### azuresql-max-db-sizes-by-product [IN] OBSERVATION 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. - Source: entries/2026/03/11/azuresql-overview.md - Source hash: 91d7ffcb9cc16b97 - Date: 2026-03-11 ### azuresql-mi-backup-restore-to-sql-server-2022 [IN] OBSERVATION Backups from Azure SQL Managed Instance can be restored to SQL Server 2022 (reverse portability). - Source: entries/2026/03/11/azuresql-managed-instance.md - Source hash: 90c5dbd6f0d04103 - Date: 2026-03-11 ### azuresql-mi-backups-restorable-to-sql-server-2022 [IN] OBSERVATION Backups from Azure SQL Managed Instance can be restored to SQL Server 2022 (reverse portability). - Source: entries/2026/03/11/azuresql-managed-instance.md - Source hash: 90c5dbd6f0d04103 - Date: 2026-03-11 ### azuresql-mi-backward-compat-sql-server-2008 [IN] OBSERVATION Azure SQL Managed Instance supports backward compatibility to SQL Server 2008 databases, with direct migration from SQL Server 2005 (upgraded to 2008 compatibility level). - Source: entries/2026/03/10/azuresql-managed-instance.md - Source hash: 0c4b7ba9f2036eb6 - Date: 2026-03-10 ### azuresql-mi-copy-only-backups-user-initiated [IN] OBSERVATION Only COPY_ONLY backups can be user-initiated on Azure SQL Managed Instance; automated backups handle the rest. - Source: entries/2026/03/10/azuresql-managed-instance.md - Source hash: 0c4b7ba9f2036eb6 - Date: 2026-03-10 ### azuresql-mi-hybrid-benefit-requires-sa [IN] OBSERVATION Azure Hybrid Benefit for SQL Managed Instance requires Software Assurance on existing SQL Server licenses. - Source: entries/2026/03/10/azuresql-managed-instance.md - Source hash: 0c4b7ba9f2036eb6 - Date: 2026-03-11 ### azuresql-mi-instance-stop-storage-only-billing [IN] OBSERVATION Azure SQL Managed Instance supports stop/start; when stopped, only storage is billed (no compute charges). - Source: entries/2026/03/11/azuresql-managed-instance.md - Source hash: 90c5dbd6f0d04103 - Date: 2026-03-11 ### azuresql-mi-license-free-dr-replica [IN] OBSERVATION A SQL Managed Instance secondary replica designated for DR only incurs no vCore licensing cost (license-free DR replica). - Source: entries/2026/03/11/azuresql-managed-instance.md - Source hash: 90c5dbd6f0d04103 - Date: 2026-03-11 ### azuresql-mi-lift-shift-migration-target [IN] OBSERVATION 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. ### azuresql-mi-link-distributed-ag [IN] OBSERVATION 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. - Source: entries/2026/03/10/azuresql-managed-instance.md - Source hash: 0c4b7ba9f2036eb6 - Date: 2026-03-11 ### azuresql-mi-link-distributed-ag-hybrid [IN] OBSERVATION 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. - Source: entries/2026/03/10/azuresql-managed-instance.md - Source hash: 0c4b7ba9f2036eb6 - Date: 2026-03-11 ### azuresql-mi-managed-instance-link-dag [IN] OBSERVATION 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. - Source: entries/2026/03/11/azuresql-managed-instance.md - Source hash: 90c5dbd6f0d04103 - Date: 2026-03-11 ### azuresql-mi-managed-instance-link-distributed-ag [IN] OBSERVATION Managed Instance link uses distributed availability groups to synchronize databases between on-premises SQL Server and SQL MI for hybrid scenarios, DR, and migration. - Source: entries/2026/03/11/azuresql-managed-instance.md - Source hash: 90c5dbd6f0d04103 - Date: 2026-03-11 ### azuresql-mi-max-16tb [IN] OBSERVATION Azure SQL Managed Instance supports a maximum database size of 16 TB. - Source: entries/2026/03/11/azuresql-overview.md - Source hash: 91d7ffcb9cc16b97 - Date: 2026-03-11 ### azuresql-mi-native-vnet-single-tenant [IN] OBSERVATION Azure SQL Managed Instance is deployed into a customer's virtual network with dedicated compute/storage and single-tenant isolation. - Source: entries/2026/03/10/azuresql-managed-instance.md - Source hash: 0c4b7ba9f2036eb6 - Date: 2026-03-10 ### azuresql-mi-near-100pct-sql-server-compatibility [IN] OBSERVATION Azure SQL Managed Instance offers near 100% compatibility with the latest SQL Server Enterprise Edition. - Source: entries/2026/03/10/azuresql-managed-instance.md - Source hash: 0c4b7ba9f2036eb6 - Date: 2026-03-10 ### azuresql-mi-recommended-for-most-migrations [IN] OBSERVATION Azure SQL Managed Instance is recommended for most migrations from on-premises SQL Server to Azure. - Source: entries/2026/03/10/azuresql-overview.md - Source hash: 2922382d91c42f93 - Date: 2026-03-10 ### azuresql-mi-reservations-save-up-to-80pct [IN] OBSERVATION Azure SQL Managed Instance reserved capacity can save up to 80% on costs compared to pay-as-you-go pricing. - Source: entries/2026/03/10/azuresql-managed-instance.md - Source hash: 0c4b7ba9f2036eb6 - Date: 2026-03-11 ### azuresql-mi-server-level-roles-supported [IN] OBSERVATION SQL Managed Instance supports server-level roles (fixed or custom); SQL Database does not. - Source: entries/2026/03/10/azuresql-security.md - Source hash: 9180bb356c162c2c - Date: 2026-03-10 ### azuresql-mi-sla-99-99 [IN] OBSERVATION Azure SQL Managed Instance has a 99.99% uptime SLA. - Source: entries/2026/03/10/azuresql-managed-instance.md - Source hash: 0c4b7ba9f2036eb6 - Date: 2026-03-10 ### azuresql-mi-ssis-executed-on-adf-ir [IN] OBSERVATION SSIS packages are stored in SSISDB on SQL Managed Instance but executed on Azure-SSIS Integration Runtime in Azure Data Factory. - Source: entries/2026/03/10/azuresql-managed-instance.md - Source hash: 0c4b7ba9f2036eb6 - Date: 2026-03-11 ### azuresql-mi-ssis-on-azure-ssis-ir-in-adf [IN] OBSERVATION SSIS packages on SQL Managed Instance are stored in SSISDB but executed on Azure-SSIS Integration Runtime in Azure Data Factory. - Source: entries/2026/03/10/azuresql-managed-instance.md - Source hash: 0c4b7ba9f2036eb6 - Date: 2026-03-11 ### azuresql-mi-stop-start-storage-only-billing [IN] OBSERVATION Azure SQL Managed Instance supports stop/start capability; when stopped, you pay only for storage. - Source: entries/2026/03/10/azuresql-managed-instance.md - Source hash: 0c4b7ba9f2036eb6 - Date: 2026-03-11 ### azuresql-mi-tcp-only-no-named-pipes [IN] OBSERVATION Azure SQL Managed Instance supports TCP protocol only; named pipes are not supported. - Source: entries/2026/03/10/azuresql-managed-instance.md - Source hash: 0c4b7ba9f2036eb6 - Date: 2026-03-10 ### azuresql-mi-tde-cert-migration-required [IN] OBSERVATION TDE certificates must be migrated when restoring an encrypted database to SQL Managed Instance via native restore. - Source: entries/2026/03/11/azuresql-managed-instance.md - Source hash: 90c5dbd6f0d04103 - Date: 2026-03-11 ### azuresql-mi-three-hardware-series [IN] OBSERVATION 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. - Source: entries/2026/03/10/azuresql-managed-instance.md - Source hash: 0c4b7ba9f2036eb6 - Date: 2026-03-10 ### azuresql-mi-vnet-classic-not-supported [IN] OBSERVATION Azure SQL Managed Instance does NOT support VNet Classic deployment model; only ARM is supported. - Source: entries/2026/03/10/azuresql-managed-instance.md - Source hash: 0c4b7ba9f2036eb6 - Date: 2026-03-10 ### azuresql-migration-path-tier-constrained [IN] OBSERVATION 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. ### azuresql-network-security-perimeter-preview-not-mi [IN] OBSERVATION 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. - Source: entries/2026/03/11/azuresql-security.md - Source hash: bbdfa23555c23515 - Date: 2026-03-11 ### azuresql-pitr-creates-new-database [IN] OBSERVATION 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 - Source: entries/2026/03/11/azuresql-backup.md - Source hash: c4ccd56c4fb10fa3 - Date: 2026-03-11 ### azuresql-pitr-creates-new-database-same-server [IN] OBSERVATION 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. - Source: entries/2026/03/11/azuresql-backup.md - Source hash: c4ccd56c4fb10fa3 - Date: 2026-03-11 ### azuresql-pitr-no-cross-region-or-subscription [IN] OBSERVATION Azure SQL Database point-in-time restore (PITR) cannot restore cross-region or cross-subscription; geo-restore and LTR can restore cross-region. - Source: entries/2026/03/10/azuresql-backup.md - Source hash: b7947157003043b3 - Date: 2026-03-11 ### azuresql-private-ip-mi-native-sqldb-private-link [IN] OBSERVATION Azure SQL Managed Instance and SQL VMs have native private IP connectivity; Azure SQL Database requires Private Link for private IP access. - Source: entries/2026/03/11/azuresql-overview.md - Source hash: 91d7ffcb9cc16b97 - Date: 2026-03-11 ### azuresql-private-ip-mi-native-sqldb-requires-private-link [IN] OBSERVATION Azure SQL Managed Instance and SQL VMs have native private IP; Azure SQL Database requires Azure Private Link for private IP connectivity. - Source: entries/2026/03/11/azuresql-overview.md - Source hash: 91d7ffcb9cc16b97 - Date: 2026-03-11 ### azuresql-rls-label-based-row-access [IN] OBSERVATION Row-Level Security (RLS) in Azure SQL controls access to individual table rows based on user characteristics and can implement label-based access control. - Source: entries/2026/03/10/azuresql-security.md - Source hash: 9180bb356c162c2c - Date: 2026-03-11 ### azuresql-rls-label-based-security [IN] OBSERVATION 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. - Source: entries/2026/03/11/azuresql-security.md - Source hash: bbdfa23555c23515 - Date: 2026-03-11 ### azuresql-rls-row-level-access-control [IN] OBSERVATION Row-Level Security (RLS) in Azure SQL controls access to individual table rows based on user characteristics and can implement label-based access control. - Source: entries/2026/03/10/azuresql-security.md - Source hash: 9180bb356c162c2c - Date: 2026-03-11 ### azuresql-row-level-security-user-context [IN] OBSERVATION 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. - Source: entries/2026/03/11/azuresql-security.md - Source hash: bbdfa23555c23515 - Date: 2026-03-11 ### azuresql-scale-vs-failover-tier-tradeoff [IN] OBSERVATION 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. ### azuresql-security-diverges-by-deployment-model [IN] OBSERVATION 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. ### azuresql-security-ledger-tamper-evidence [IN] OBSERVATION Azure SQL Ledger provides cryptographic tamper-evidence for data integrity with immutable change records for regulatory compliance. - Source: entries/2026/03/10/azuresql-security.md - Source hash: 9180bb356c162c2c - Date: 2026-03-11 ### azuresql-security-network-perimeter-not-for-mi [IN] OBSERVATION Azure Network Security Perimeter (preview) applies to Azure SQL Database PaaS resources but does NOT apply to SQL Managed Instance. - Source: entries/2026/03/10/azuresql-security.md - Source hash: 9180bb356c162c2c - Date: 2026-03-11 ### azuresql-security-network-perimeter-preview-not-mi [IN] OBSERVATION Network Security Perimeter (preview) creates logical network boundaries around PaaS resources but does NOT apply to SQL Managed Instance. - Source: entries/2026/03/11/azuresql-security.md - Source hash: bbdfa23555c23515 - Date: 2026-03-11 ### azuresql-server-deletion-permanent [IN] OBSERVATION Deleting an Azure SQL server permanently deletes all databases (unrecoverable), but LTR backups on blob storage survive server deletion - Source: entries/2026/03/10/azuresql-backup.md - Source hash: b7947157003043b3 - Date: 2026-03-10 ### azuresql-serverless-general-purpose-hyperscale [IN] OBSERVATION Azure SQL Database serverless compute is available only in General Purpose and Hyperscale tiers with per-second billing - Source: entries/2026/03/10/azuresql-database.md - Source hash: 63957c0208ffead0 - Date: 2026-03-10 ### azuresql-sla-values [IN] OBSERVATION 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). - Source: entries/2026/03/10/azuresql-overview.md - Source hash: 2922382d91c42f93 - Date: 2026-03-10 ### azuresql-sql-database-requires-private-link-for-private-ip [IN] OBSERVATION Azure SQL Database requires Azure Private Link for private IP access; Managed Instance and SQL VMs have native private IP by default. - Source: entries/2026/03/11/azuresql-overview.md - Source hash: 91d7ffcb9cc16b97 - Date: 2026-03-11 ### azuresql-sql-vm-infra-sla-not-sql-processes [IN] OBSERVATION 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. - Source: entries/2026/03/11/azuresql-overview.md - Source hash: 91d7ffcb9cc16b97 - Date: 2026-03-11 ### azuresql-tde-cmk-server-or-database-level [IN] OBSERVATION Customer-managed keys (CMK) for TDE can be configured at server level or individual database level via Azure Key Vault. - Source: entries/2026/03/10/azuresql-security.md - Source hash: 9180bb356c162c2c - Date: 2026-03-11 ### azuresql-tde-enabled-by-default [IN] OBSERVATION Transparent Data Encryption (TDE) is enabled by default on all newly created Azure SQL databases. - Source: entries/2026/03/10/azuresql-security.md - Source hash: 9180bb356c162c2c - Date: 2026-03-10 ### azuresql-tde-log-backups-not-compressed [IN] OBSERVATION Azure SQL Database full and differential backups are compressed (3-4x ratio), but transaction log backups are NOT compressed when TDE is enabled. - Source: entries/2026/03/11/azuresql-backup.md - Source hash: c4ccd56c4fb10fa3 - Date: 2026-03-11 ### azuresql-tde-no-log-backup-compression [IN] OBSERVATION Azure SQL databases with TDE (Transparent Data Encryption) enabled do not compress transaction log backups. - Source: entries/2026/03/10/azuresql-backup.md - Source hash: b7947157003043b3 - Date: 2026-03-11 ### azuresql-three-encryption-layers [IN] OBSERVATION Azure SQL Database has three encryption layers: TLS (in motion), TDE (at rest), Always Encrypted (in use) - Source: entries/2026/03/10/azuresql-database.md - Source hash: 63957c0208ffead0 - Date: 2026-03-10 ### azuresql-three-layer-data-protection [IN] OBSERVATION 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. ### azuresql-three-products [IN] OBSERVATION 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). - Source: entries/2026/03/10/azuresql-overview.md - Source hash: 2922382d91c42f93 - Date: 2026-03-10 ### azuresql-tls-always-enforced [IN] OBSERVATION TLS is always enforced on Azure SQL (ForceEncryption=Yes); connections without encryption are not possible. - Source: entries/2026/03/10/azuresql-security.md - Source hash: 9180bb356c162c2c - Date: 2026-03-10 ### azuresql-tls-do-not-trust-server-certificate-production [IN] OBSERVATION Do NOT set TrustServerCertificate=True in production — it disables protection against man-in-the-middle attacks; use Encrypt=True;TrustServerCertificate=False. - Source: entries/2026/03/11/azuresql-security.md - Source hash: bbdfa23555c23515 - Date: 2026-03-11 ### azuresql-vcore-vs-dtu-models [IN] OBSERVATION Azure SQL Database has two purchasing models: vCore (independent resource selection, Azure Hybrid Benefit) and DTU (bundled compute/memory/IO) - Source: entries/2026/03/10/azuresql-database.md - Source hash: 63957c0208ffead0 - Date: 2026-03-10 ### azuresql-vm-infra-sla-not-sql-processes [IN] OBSERVATION 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. - Source: entries/2026/03/11/azuresql-overview.md - Source hash: 91d7ffcb9cc16b97 - Date: 2026-03-11 ### azuresql-vm-max-256tb [IN] OBSERVATION SQL Server on Azure VMs supports up to 256 TB of storage. - Source: entries/2026/03/11/azuresql-overview.md - Source hash: 91d7ffcb9cc16b97 - Date: 2026-03-11 ### azuresql-windows-auth-kerberos-mi-only [IN] OBSERVATION Windows authentication (Kerberos) for Entra principals is available only on SQL Managed Instance, not SQL Database. - Source: entries/2026/03/10/azuresql-security.md - Source hash: 9180bb356c162c2c - Date: 2026-03-10 ### azuresql-workload-env-dev-lrs-prod-grs [IN] OBSERVATION In Azure portal, setting workload environment to "Development" defaults backup redundancy to LRS; "Production" defaults to GRS. - Source: entries/2026/03/11/azuresql-backup.md - Source hash: c4ccd56c4fb10fa3 - Date: 2026-03-11 ### azuresql-zone-redundant-premium-bc-only [IN] OBSERVATION Azure SQL Database zone-redundant deployment is available for Premium and Business Critical tiers only - Source: entries/2026/03/10/azuresql-database.md - Source hash: 63957c0208ffead0 - Date: 2026-03-10 ### blob-access-tier-min-retention-cool30-cold90-archive180 [IN] OBSERVATION Azure Blob Storage minimum retention periods: Cool = 30 days, Cold = 90 days, Archive = 180 days; early deletion penalties are prorated. - Source: entries/2026/03/10/storage-blob-access-tiers.md - Source hash: b971fa839ae7f2ba - Date: 2026-03-10 ### blob-access-tiers-block-blobs-only [IN] OBSERVATION Azure Blob Storage access tiers (Hot, Cool, Cold, Archive) apply only to block blobs, not append or page blobs. - Source: entries/2026/03/10/storage-blob-access-tiers.md - Source hash: b971fa839ae7f2ba - Date: 2026-03-10 ### blob-archive-cannot-be-default-account-tier [IN] OBSERVATION Azure Blob Storage Archive tier cannot be set as the default account access tier; new GPv2 accounts default to Hot. - Source: entries/2026/03/10/storage-blob-access-tiers.md - Source hash: b971fa839ae7f2ba - Date: 2026-03-10 ### blob-archive-metadata-readable-cool-rates [IN] OBSERVATION Azure Blob Storage archived blob metadata remains readable and index tags can be read/written; metadata access is charged at cool tier rates. - Source: entries/2026/03/10/storage-blob-access-tiers.md - Source hash: b971fa839ae7f2ba - Date: 2026-03-11 ### blob-archive-metadata-readable-no-snapshots [IN] OBSERVATION 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. - Source: entries/2026/03/11/storage-blob-access-tiers.md - Source hash: ee81fa1644d4080c - Date: 2026-03-11 ### blob-archive-metadata-readable-snapshots-not-supported [IN] OBSERVATION 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. - Source: entries/2026/03/11/storage-blob-access-tiers.md - Source hash: ee81fa1644d4080c - Date: 2026-03-11 ### blob-archive-metadata-readable-snapshots-unsupported [IN] OBSERVATION Azure Blob Storage Archive tier metadata remains read-only accessible, but snapshots are not supported for archived blobs. - Source: entries/2026/03/11/storage-blob-access-tiers.md - Source hash: ee81fa1644d4080c - Date: 2026-03-11 ### blob-archive-redundancy-lrs-grs-ragrs-only [IN] OBSERVATION Azure Blob Storage Archive tier supports only LRS, GRS, and RA-GRS redundancy — not ZRS, GZRS, or RA-GZRS. - Source: entries/2026/03/10/storage-blob-access-tiers.md - Source hash: b971fa839ae7f2ba - Date: 2026-03-10 ### blob-archive-rehydration-up-to-15-hours [IN] OBSERVATION 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. - Source: entries/2026/03/11/storage-blob-access-tiers.md - Source hash: ee81fa1644d4080c - Date: 2026-03-11 ### blob-archive-snapshots-not-supported [IN] OBSERVATION Azure Blob Storage snapshots are not supported for archived blobs. - Source: entries/2026/03/10/storage-blob-access-tiers.md - Source hash: b971fa839ae7f2ba - Date: 2026-03-11 ### blob-archive-tier-offline [IN] OBSERVATION Azure Blob Storage Archive tier is offline; blobs cannot be read or modified without rehydration (up to 15 hours). - Source: entries/2026/03/10/storage-blob-access-tiers.md - Source hash: b971fa839ae7f2ba - Date: 2026-03-10 ### blob-copy-blob-avoids-early-deletion-penalty [IN] OBSERVATION Using Copy Blob avoids early deletion penalty (source blob remains); Set Blob Tier on a blob before minimum retention triggers the penalty. - Source: entries/2026/03/10/storage-blob-access-tiers.md - Source hash: b971fa839ae7f2ba - Date: 2026-03-10 ### blob-default-tier-change-billing-cooler-write-warmer-read [IN] OBSERVATION 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. - Source: entries/2026/03/10/storage-blob-access-tiers.md - Source hash: b971fa839ae7f2ba - Date: 2026-03-11 ### blob-default-tier-change-billing-direction [IN] OBSERVATION 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. - Source: entries/2026/03/11/storage-blob-access-tiers.md - Source hash: ee81fa1644d4080c - Date: 2026-03-11 ### blob-default-tier-change-charges-all-inferred [IN] OBSERVATION 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. - Source: entries/2026/03/11/storage-blob-access-tiers.md - Source hash: ee81fa1644d4080c - Date: 2026-03-11 ### blob-encryption-scope-blocks-archive [IN] OBSERVATION Azure Blob Storage blobs using encryption scopes cannot be archived via Set Blob Tier. - Source: entries/2026/03/10/storage-blob-access-tiers.md - Source hash: b971fa839ae7f2ba - Date: 2026-03-11 ### blob-encryption-scopes-cannot-archive [IN] OBSERVATION Azure Blob Storage blobs using encryption scopes cannot be archived via Set Blob Tier. - Source: entries/2026/03/10/storage-blob-access-tiers.md - Source hash: b971fa839ae7f2ba - Date: 2026-03-11 ### blob-last-access-time-billed-once-per-24h [IN] OBSERVATION Azure Blob Storage last access time tracking updates are billed as "other transactions" at most once every 24 hours per object. - Source: entries/2026/03/11/storage-blob-lifecycle.md - Source hash: 4f106f28c9727168 - Date: 2026-03-11 ### blob-lifecycle-access-time-billing-once-per-24h [IN] OBSERVATION Last access time tracking updates are billed as "other transactions" at most once per 24 hours per object. - Source: entries/2026/03/10/storage-blob-lifecycle.md - Source hash: 415948315dfd5298 - Date: 2026-03-11 ### blob-lifecycle-delete-blocked-by-immutable [IN] OBSERVATION Azure Blob Storage lifecycle delete actions do not work on blobs in immutable containers. - Source: entries/2026/03/11/storage-blob-lifecycle.md - Source hash: 4f106f28c9727168 - Date: 2026-03-11 ### blob-lifecycle-encryption-scope-no-archive [IN] OBSERVATION Azure Blob Storage lifecycle policies cannot archive blobs that use an encryption scope. - Source: entries/2026/03/11/storage-blob-lifecycle.md - Source hash: 4f106f28c9727168 - Date: 2026-03-11 ### blob-lifecycle-immutable-blocks-delete [IN] OBSERVATION Lifecycle delete actions do not work on blobs in immutable containers. - Source: entries/2026/03/10/storage-blob-lifecycle.md - Source hash: 415948315dfd5298 - Date: 2026-03-11 ### blob-lifecycle-immutable-containers-block-delete [IN] OBSERVATION Lifecycle delete actions do not work on blobs in immutable containers. - Source: entries/2026/03/11/storage-blob-lifecycle.md - Source hash: 4f106f28c9727168 - Date: 2026-03-11 ### blob-lifecycle-last-access-billed-once-per-24h [IN] OBSERVATION Last access time tracking updates are billed as "other transactions" at most once every 24 hours per object. - Source: entries/2026/03/11/storage-blob-lifecycle.md - Source hash: 4f106f28c9727168 - Date: 2026-03-11 ### blob-lifecycle-last-access-billing-once-per-24h [IN] OBSERVATION Last access time tracking updates are billed as "other transactions" at most once per 24 hours per object. - Source: entries/2026/03/10/storage-blob-lifecycle.md - Source hash: 415948315dfd5298 - Date: 2026-03-11 ### blob-lifecycle-management-cannot-rehydrate-archive [IN] OBSERVATION Azure Blob Storage lifecycle management policies cannot rehydrate blobs from the Archive tier. - Source: entries/2026/03/10/storage-blob-access-tiers.md - Source hash: b971fa839ae7f2ba - Date: 2026-03-10 ### blob-lifecycle-max-10-prefixes-10-tags [IN] OBSERVATION Each lifecycle rule supports up to 10 case-sensitive prefix filters and 10 blob index tag conditions, combined with logical AND (no exclusion mechanism). - Source: entries/2026/03/10/storage-blob-lifecycle.md - Source hash: 415948315dfd5298 - Date: 2026-03-10 ### blob-lifecycle-monitor-event [IN] OBSERVATION Lifecycle policy runs can be monitored by subscribing to the LifecyclePolicyCompleted event. - Source: entries/2026/03/10/storage-blob-lifecycle.md - Source hash: 415948315dfd5298 - Date: 2026-03-11 ### blob-lifecycle-no-archive-rehydration [IN] OBSERVATION Lifecycle policies cannot rehydrate blobs from archive tier to an online tier. - Source: entries/2026/03/10/storage-blob-lifecycle.md - Source hash: 415948315dfd5298 - Date: 2026-03-10 ### blob-lifecycle-no-partial-update [IN] OBSERVATION Azure Blob Storage lifecycle management policies must be read or written in full — partial updates are not supported. - Source: entries/2026/03/11/storage-blob-lifecycle.md - Source hash: 4f106f28c9727168 - Date: 2026-03-11 ### blob-lifecycle-no-partial-updates [IN] OBSERVATION Blob lifecycle management policies must be read or written in full — partial updates are not supported. - Source: entries/2026/03/10/storage-blob-lifecycle.md - Source hash: 415948315dfd5298 - Date: 2026-03-11 ### blob-lifecycle-policies-no-partial-update [IN] OBSERVATION Azure Blob Storage lifecycle management policies must be read or written in full — partial updates are not supported. - Source: entries/2026/03/11/storage-blob-lifecycle.md - Source hash: 4f106f28c9727168 - Date: 2026-03-11 ### blob-lifecycle-policy-24h-activation [IN] OBSERVATION Azure Blob Storage lifecycle management policy changes take up to 24 hours to take effect and begin first execution. - Source: entries/2026/03/11/storage-blob-lifecycle.md - Source hash: 4f106f28c9727168 - Date: 2026-03-11 ### blob-lifecycle-policy-24h-propagation [IN] OBSERVATION Blob lifecycle policy changes take up to 24 hours to go into effect. - Source: entries/2026/03/10/storage-blob-lifecycle.md - Source hash: 415948315dfd5298 - Date: 2026-03-10 ### blob-lifecycle-policy-24h-to-take-effect [IN] OBSERVATION Azure Blob Storage lifecycle management policy changes take up to 24 hours to take effect and begin first execution. - Source: entries/2026/03/11/storage-blob-lifecycle.md - Source hash: 4f106f28c9727168 - Date: 2026-03-11 ### blob-lifecycle-policy-free-of-charge [IN] OBSERVATION 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. - Source: entries/2026/03/10/storage-blob-lifecycle.md - Source hash: 415948315dfd5298 - Date: 2026-03-10 ### blob-lifecycle-policy-full-read-write-only [IN] OBSERVATION Azure Blob Storage lifecycle management policies must be read or written in full; partial updates are not supported. - Source: entries/2026/03/11/storage-blob-lifecycle.md - Source hash: 4f106f28c9727168 - Date: 2026-03-11 ### blob-lifecycle-policy-no-partial-updates [IN] OBSERVATION Azure Blob Storage lifecycle management policies must be read or written in full — partial updates are not supported. - Source: entries/2026/03/10/storage-blob-lifecycle.md - Source hash: 415948315dfd5298 - Date: 2026-03-11 ### blob-lifecycle-safe-delete-procedure [IN] OBSERVATION Recommended lifecycle policy deletion procedure: disable all rules first, wait 24 hours, then delete the policy. - Source: entries/2026/03/10/storage-blob-lifecycle.md - Source hash: 415948315dfd5298 - Date: 2026-03-10 ### blob-lifecycle-system-containers-excluded [IN] OBSERVATION Lifecycle policies never affect system containers ($logs, $web). - Source: entries/2026/03/10/storage-blob-lifecycle.md - Source hash: 415948315dfd5298 - Date: 2026-03-10 ### blob-lifecycle-tiering-block-blobs-only [IN] OBSERVATION Lifecycle tier transitions apply only to block blobs; tiering is not supported for append blobs, page blobs, or premium block blob accounts. - Source: entries/2026/03/10/storage-blob-lifecycle.md - Source hash: 415948315dfd5298 - Date: 2026-03-10 ### blob-online-tiers-millisecond-first-byte-latency [IN] OBSERVATION 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. - Source: entries/2026/03/11/storage-blob-access-tiers.md - Source hash: ee81fa1644d4080c - Date: 2026-03-11 ### blob-online-tiers-millisecond-latency [IN] OBSERVATION All Azure Blob Storage online tiers (Hot, Cool, Cold) share the same millisecond first-byte latency; only Archive has hours-level latency. - Source: entries/2026/03/11/storage-blob-access-tiers.md - Source hash: ee81fa1644d4080c - Date: 2026-03-11 ### blob-premium-block-blob-cannot-tier [IN] OBSERVATION Azure Premium block blob storage accounts cannot tier to hot/cool/cold/archive via Set Blob Tier or lifecycle management. - Source: entries/2026/03/10/storage-blob-access-tiers.md - Source hash: b971fa839ae7f2ba - Date: 2026-03-11 ### blob-premium-block-cannot-tier-lifecycle [IN] OBSERVATION Azure Premium block blob storage accounts cannot tier blobs to hot/cool/cold/archive via Set Blob Tier or lifecycle management. - Source: entries/2026/03/10/storage-blob-access-tiers.md - Source hash: b971fa839ae7f2ba - Date: 2026-03-11 ### blob-smart-tier-auto-moves-hot-cool-cold [IN] OBSERVATION Azure Blob Storage Smart tier automatically moves data between hot, cool, and cold tiers based on usage patterns. - Source: entries/2026/03/10/storage-blob-access-tiers.md - Source hash: b971fa839ae7f2ba - Date: 2026-03-11 ### blob-storage-client-libraries-five-languages [IN] OBSERVATION Azure Blob Storage provides client libraries for .NET, Java, Node.js, Python, and Go. - Source: entries/2026/03/11/storage-blob-overview.md - Source hash: 6156339300d79f80 - Date: 2026-03-11 ### blob-storage-sftp-nfs-support [IN] OBSERVATION Azure Blob Storage supports SFTP and NFS 3.0 protocols in addition to HTTP/HTTPS. - Source: entries/2026/03/10/storage-blob-overview.md - Source hash: 7fb2f9c5ddacc43e - Date: 2026-03-10 ### blob-storage-unstructured-data [IN] OBSERVATION Azure Blob Storage is Microsoft's object storage solution for unstructured data (text and binary). - Source: entries/2026/03/10/storage-blob-overview.md - Source hash: 7fb2f9c5ddacc43e - Date: 2026-03-10 ### blob-tier-availability-hot999-cool-cold99 [IN] OBSERVATION Azure Blob Storage availability SLAs: Hot = 99.9%, Cool/Cold = 99%, Archive = 99%; with RA-GRS: Hot = 99.99%, others = 99.9%. - Source: entries/2026/03/10/storage-blob-access-tiers.md - Source hash: b971fa839ae7f2ba - Date: 2026-03-10 ### blob-tier-billing-warmer-cooler-write-cooler-warmer-read [IN] OBSERVATION 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. - Source: entries/2026/03/10/storage-blob-access-tiers.md - Source hash: b971fa839ae7f2ba - Date: 2026-03-11 ### blob-tier-change-billing-direction [IN] OBSERVATION 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. - Source: entries/2026/03/11/storage-blob-access-tiers.md - Source hash: ee81fa1644d4080c - Date: 2026-03-11 ### blueprints-artifact-size-limit-2mb [IN] OBSERVATION Each Azure Blueprint artifact must be ≤ 2 MB in size. - Source: entries/2026/03/11/blueprints-overview.md - Source hash: 83ae383716d2fd3a - Date: 2026-03-11 ### blueprints-backed-by-cosmos-db [IN] OBSERVATION Azure Blueprint objects are backed by Cosmos DB, globally replicated for low latency and high availability. - Source: entries/2026/03/11/blueprints-overview.md - Source hash: 83ae383716d2fd3a - Date: 2026-03-11 ### blueprints-backed-by-cosmosdb-global-replication [IN] OBSERVATION Blueprint objects are stored in Azure Cosmos DB and globally replicated for low latency and high availability. - Source: entries/2026/03/11/blueprints-overview.md - Source hash: 83ae383716d2fd3a - Date: 2026-03-11 ### blueprints-contributor-cannot-assign-operator-cannot-create [IN] OBSERVATION Blueprint Contributor can manage blueprint definitions but cannot assign them; Blueprint Operator can assign blueprints but cannot create definitions. - Source: entries/2026/03/11/blueprints-overview.md - Source hash: 83ae383716d2fd3a - Date: 2026-03-11 ### blueprints-contributor-vs-operator-roles [IN] OBSERVATION Blueprint Contributor can manage blueprint definitions but cannot assign them; Blueprint Operator can assign blueprints but cannot create or modify definitions. - Source: entries/2026/03/11/blueprints-overview.md - Source hash: 83ae383716d2fd3a - Date: 2026-03-11 ### blueprints-deprecated-july-2026 [IN] OBSERVATION Azure Blueprints (Preview) is deprecated on July 11, 2026; successor services are Template Specs (definition storage) and Deployment Stacks (lifecycle management). - Source: entries/2026/03/11/blueprints-overview.md - Source hash: 83ae383716d2fd3a - Date: 2026-03-11 ### blueprints-four-artifact-types [IN] OBSERVATION Azure Blueprints supports four artifact types: Resource Groups, ARM templates, Policy Assignments, and Role Assignments. - Source: entries/2026/03/11/blueprints-overview.md - Source hash: 83ae383716d2fd3a - Date: 2026-03-11 ### blueprints-naming-limits [IN] OBSERVATION Blueprint naming limits: definition name max 48 characters, version max 20 characters, assignment name max 90 characters. - Source: entries/2026/03/11/blueprints-overview.md - Source hash: 83ae383716d2fd3a - Date: 2026-03-11 ### blueprints-parameters-via-rest-api-only [IN] OBSERVATION Blueprint-level parameters can only be created via REST API, not the Azure portal. - Source: entries/2026/03/11/blueprints-overview.md - Source hash: 83ae383716d2fd3a - Date: 2026-03-11 ### blueprints-persistent-definition-assignment-relationship [IN] OBSERVATION Unlike ARM templates, Azure Blueprints maintain a persistent relationship between definition and assignment, enabling audit and tracking of deployed resources. - Source: entries/2026/03/11/blueprints-overview.md - Source hash: 83ae383716d2fd3a - Date: 2026-03-11 ### blueprints-persistent-relationship-vs-arm [IN] OBSERVATION 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. - Source: entries/2026/03/11/blueprints-overview.md - Source hash: 83ae383716d2fd3a - Date: 2026-03-11 ### blueprints-system-identity-requires-owner [IN] OBSERVATION System-assigned managed identity for blueprint deployment requires Owner role on the target subscription; user-assigned managed identity only requires blueprintAssignments/write. - Source: entries/2026/03/11/blueprints-overview.md - Source hash: 83ae383716d2fd3a - Date: 2026-03-11 ### blueprints-system-mi-requires-owner [IN] OBSERVATION System-assigned managed identity for Blueprint deployment requires the Owner role on the target subscription; user-assigned managed identity only requires blueprintAssignments/write. - Source: entries/2026/03/11/blueprints-overview.md - Source hash: 83ae383716d2fd3a - Date: 2026-03-11 ### cannot-change-subnet-address-range-with-resources [IN] OBSERVATION A subnet's address range cannot be changed while resources are deployed in it — resources must be moved or deleted first. - Source: entries/2026/03/10/vnet-subnets.md - Source hash: 65ce293e7b4bbd7b - Date: 2026-03-10 ### cannot-delete-subnet-with-resources [IN] OBSERVATION A subnet cannot be deleted while it contains resources — all resources must be removed first. - Source: entries/2026/03/11/vnet-subnets.md - Source hash: d70de809fbdd3d75 - Date: 2026-03-11 ### cloud-security-benchmark-underpins-waf-security [IN] OBSERVATION The Microsoft Cloud Security Benchmark provides the control framework that underpins WAF Security pillar guidance. - Source: entries/2026/03/11/waf-security.md - Source hash: 8d4db94cc716a02a - Date: 2026-03-11 ### cluster-autoscaler-checks-every-10s [IN] OBSERVATION The AKS cluster autoscaler checks the Metrics API server every 10 seconds and requires RBAC-enabled AKS running Kubernetes 1.10.x+. - Source: entries/2026/03/10/aks-scaling.md - Source hash: efeece6890d5beba - Date: 2026-03-10 ### cluster-autoscaler-scale-in-10min-idle [IN] OBSERVATION The cluster autoscaler schedules node deletion after nodes are unused for 10 minutes (default threshold). - Source: entries/2026/03/10/aks-scaling.md - Source hash: efeece6890d5beba - Date: 2026-03-10 ### container-supply-chain-network-isolated-end-to-end [IN] OBSERVATION 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. ### container-supply-chain-registry-to-runtime [IN] OBSERVATION 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. ### datalake-gen2-built-on-blob [IN] OBSERVATION Azure Data Lake Storage Gen2 is not a separate service; it is a capability of Blob Storage with hierarchical namespace enabled. - Source: entries/2026/03/10/storage-blob-overview.md - Source hash: 7fb2f9c5ddacc43e - Date: 2026-03-10 ### defender-for-cloud-multi-cloud [IN] OBSERVATION Microsoft Defender for Cloud covers multi-cloud workloads across Azure, AWS, and GCP — not Azure-only. - Source: entries/2026/03/10/waf-security.md - Source hash: a29b9ac02e1f9e3c - Date: 2026-03-10 ### elastic-san-only-lrs-zrs [IN] OBSERVATION Azure Elastic SAN supports only LRS and ZRS redundancy options — no geo-redundant options. - Source: entries/2026/03/11/storage-redundancy.md - Source hash: b199b348e6151287 - Date: 2026-03-11 ### entra-admin-center-url [IN] OBSERVATION The Microsoft Entra admin center is accessible at https://entra.microsoft.com. - Source: entries/2026/03/11/entra-overview.md - Source hash: 30c520ae3012b259 - Date: 2026-03-11 ### entra-app-deactivation-preserves-objects [IN] OBSERVATION An application in Microsoft Entra ID can be temporarily deactivated to prevent new token issuance while preserving both the application object and service principal. - Source: entries/2026/03/11/entra-service-principals.md - Source hash: c987aff7abc3204c - Date: 2026-03-11 ### entra-app-deactivation-prevents-tokens [IN] OBSERVATION An application can be temporarily deactivated to prevent new token issuance without deleting the application object or service principal. - Source: entries/2026/03/11/entra-service-principals.md - Source hash: c987aff7abc3204c - Date: 2026-03-11 ### entra-app-deactivation-prevents-tokens-preserves-objects [IN] OBSERVATION An application can be deactivated to prevent new token issuance without deleting the application object or service principal. - Source: entries/2026/03/11/entra-service-principals.md - Source hash: c987aff7abc3204c - Date: 2026-03-11 ### entra-app-object-changes-reflect-home-sp-only [IN] OBSERVATION Changes to an application object are reflected only in the home tenant's service principal, not in service principals in other tenants. - Source: entries/2026/03/10/entra-service-principals.md - Source hash: 22f34ce4ab8c61c8 - Date: 2026-03-11 ### entra-app-object-changes-reflect-home-tenant-only [IN] OBSERVATION Changes to an application object are reflected only in the home tenant's service principal, not in service principals in other tenants. - Source: entries/2026/03/11/entra-service-principals.md - Source hash: c987aff7abc3204c - Date: 2026-03-11 ### entra-app-object-global-sp-local [IN] OBSERVATION The application object is the global representation of an application; the service principal is the local representation per tenant. - Source: entries/2026/03/10/entra-service-principals.md - Source hash: 22f34ce4ab8c61c8 - Date: 2026-03-10 ### entra-app-object-one-to-many-service-principals [IN] OBSERVATION 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. - Source: entries/2026/03/10/entra-service-principals.md - Source hash: 22f34ce4ab8c61c8 - Date: 2026-03-10 ### entra-app-registrations-vs-enterprise-applications [IN] OBSERVATION Application objects are managed under App registrations; service principals are managed under Enterprise applications in the Entra admin center. - Source: entries/2026/03/10/entra-service-principals.md - Source hash: 22f34ce4ab8c61c8 - Date: 2026-03-11 ### entra-app-registrations-vs-enterprise-apps-portal [IN] OBSERVATION Application objects are managed under the App registrations page; service principals are managed under the Enterprise applications page in the Entra admin center. - Source: entries/2026/03/10/entra-service-principals.md - Source hash: 22f34ce4ab8c61c8 - Date: 2026-03-11 ### entra-application-two-object-model [IN] OBSERVATION 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. ### entra-azure-ad-b2c-end-of-sale-may-2025 [IN] OBSERVATION Azure AD B2C is end-of-sale for new customers as of May 1, 2025. - Source: entries/2026/03/10/entra-users.md - Source hash: e6ca62bbc7b38940 - Date: 2026-03-10 ### entra-delete-app-deletes-home-sp-no-restore [IN] OBSERVATION Deleting an application object deletes the home tenant service principal; restoring the app via App Registrations does NOT restore the service principal. - Source: entries/2026/03/10/entra-service-principals.md - Source hash: 22f34ce4ab8c61c8 - Date: 2026-03-10 ### entra-deleted-user-frees-licenses [IN] OBSERVATION When a Microsoft Entra user is deleted, their assigned licenses are freed and become available for other users. - Source: entries/2026/03/11/entra-users.md - Source hash: c65156a0dc6c6a6e - Date: 2026-03-11 ### entra-deleted-users-recoverable-30-days [IN] OBSERVATION Deleted users in Microsoft Entra ID are soft-deleted and recoverable for 30 days. - Source: entries/2026/03/10/entra-users.md - Source hash: e6ca62bbc7b38940 - Date: 2026-03-10 ### entra-domain-services-managed-kerberos-ldap [IN] OBSERVATION Microsoft Entra Domain Services provides managed Kerberos, NTLM, LDAP, and Group Policy services — no domain controllers to maintain. - Source: entries/2026/03/10/entra-overview.md - Source hash: 4e443bc2b765a028 - Date: 2026-03-10 ### entra-dynamic-group-org-wide-reevaluation [IN] OBSERVATION Dynamic group membership processes all organization-wide rules when any user or device attribute changes, not just rules relevant to the changed attribute. - Source: entries/2026/03/11/entra-groups.md - Source hash: 028fea02f16b47c9 - Date: 2026-03-11 ### entra-dynamic-membership-org-wide-reevaluation [IN] OBSERVATION When any user or device attribute changes, Microsoft Entra re-evaluates all dynamic group membership rules across the entire organization. - Source: entries/2026/03/11/entra-groups.md - Source hash: 028fea02f16b47c9 - Date: 2026-03-11 ### entra-dynamic-membership-orgwide-reevaluation [IN] OBSERVATION Dynamic group membership processes all org-wide dynamic group rules when any user or device attribute changes — not just rules for the affected group. - Source: entries/2026/03/11/entra-groups.md - Source hash: 028fea02f16b47c9 - Date: 2026-03-11 ### entra-external-guests-no-admin-units [IN] OBSERVATION External guests cannot be assigned to administrative units in Microsoft Entra ID. - Source: entries/2026/03/11/entra-users.md - Source hash: c65156a0dc6c6a6e - Date: 2026-03-11 ### entra-external-id-b2b-and-b2c [IN] OBSERVATION 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. - Source: entries/2026/03/11/entra-overview.md - Source hash: 30c520ae3012b259 - Date: 2026-03-11 ### entra-external-id-b2b-and-ciam [IN] OBSERVATION Microsoft Entra External ID supports both B2B collaboration (partners/guests) and B2C/CIAM (customer-facing apps with self-service registration and social login). - Source: entries/2026/03/10/entra-overview.md - Source hash: 4e443bc2b765a028 - Date: 2026-03-11 ### entra-external-member-federates-to-home-tenant [IN] OBSERVATION External members in Microsoft Entra ID authenticate via federation to their home tenant, while internal users have credentials managed directly in the local tenant. - Source: entries/2026/03/11/entra-users.md - Source hash: c65156a0dc6c6a6e - Date: 2026-03-11 ### entra-external-tenant-users-no-admin-units-at-creation [IN] OBSERVATION External users in external tenants (Entra External ID) cannot be assigned to administrative units or roles at creation. - Source: entries/2026/03/10/entra-users.md - Source hash: e6ca62bbc7b38940 - Date: 2026-03-11 ### entra-four-workforce-user-types [IN] OBSERVATION Microsoft Entra ID workforce tenants have four user types: internal member, internal guest, external member, and external guest. - Source: entries/2026/03/10/entra-users.md - Source hash: e6ca62bbc7b38940 - Date: 2026-03-10 ### entra-group-admin-roles [IN] OBSERVATION Groups Administrator or User Administrator role is required to manage Entra groups; Privileged Role Administrator is required to enable role assignment on groups. - Source: entries/2026/03/10/entra-groups.md - Source hash: 6c99d892c6c40c75 - Date: 2026-03-11 ### entra-group-membership-types [IN] OBSERVATION Entra group membership types are: Assigned, Dynamic User, and Dynamic Device. - Source: entries/2026/03/10/entra-groups.md - Source hash: 6c99d892c6c40c75 - Date: 2026-03-10 ### entra-group-name-no-leading-space [IN] OBSERVATION Microsoft Entra group names cannot start with a space — doing so prevents the group from appearing in role assignment options. - Source: entries/2026/03/11/entra-groups.md - Source hash: 028fea02f16b47c9 - Date: 2026-03-11 ### entra-group-type-immutable [IN] OBSERVATION Microsoft Entra group type (Security or Microsoft 365) cannot be changed after creation — must delete and recreate. - Source: entries/2026/03/10/entra-groups.md - Source hash: 6c99d892c6c40c75 - Date: 2026-03-10 ### entra-groups-admin-roles [IN] OBSERVATION Groups Administrator or User Administrator roles are required for group CRUD and membership management in Microsoft Entra ID. - Source: entries/2026/03/11/entra-groups.md - Source hash: 028fea02f16b47c9 - Date: 2026-03-11 ### entra-groups-admin-roles-groups-or-user-administrator [IN] OBSERVATION Groups Administrator or User Administrator roles are required for group CRUD and membership management in Microsoft Entra. - Source: entries/2026/03/11/entra-groups.md - Source hash: 028fea02f16b47c9 - Date: 2026-03-11 ### entra-groups-admin-roles-required [IN] OBSERVATION Managing Entra groups requires Groups Administrator or User Administrator role; Privileged Role Administrator is required to enable role assignment on groups. - Source: entries/2026/03/10/entra-groups.md - Source hash: 6c99d892c6c40c75 - Date: 2026-03-11 ### entra-id-governance-access-lifecycle [IN] OBSERVATION Microsoft Entra ID Governance automates the full identity lifecycle: access requests, assignments, reviews, and automatic provisioning/deprovisioning (e.g., employee onboarding/offboarding). - Source: entries/2026/03/11/entra-overview.md - Source hash: 30c520ae3012b259 - Date: 2026-03-11 ### entra-id-governance-lifecycle-automation [IN] OBSERVATION Microsoft Entra ID Governance automates the full identity lifecycle (joiner, mover, leaver) including access request, assignment, and review workflows. - Source: entries/2026/03/10/entra-overview.md - Source hash: 4e443bc2b765a028 - Date: 2026-03-11 ### entra-id-initial-domain-onmicrosoft [IN] OBSERVATION Every Microsoft Entra ID directory gets an initial domain in the format `.onmicrosoft.com`. - Source: entries/2026/03/11/entra-overview.md - Source hash: 30c520ae3012b259 - Date: 2026-03-11 ### entra-id-protection-requires-p2 [IN] OBSERVATION Microsoft Entra ID Protection (risk detection and risk-based Conditional Access) requires a P2 license. - Source: entries/2026/03/11/entra-overview.md - Source hash: 30c520ae3012b259 - Date: 2026-03-11 ### entra-id-protection-requires-p2-license [IN] OBSERVATION Microsoft Entra ID Protection (risk detection and risk-based Conditional Access) requires a Microsoft Entra ID P2 license. - Source: entries/2026/03/11/entra-overview.md - Source hash: 30c520ae3012b259 - Date: 2026-03-11 ### entra-id-protection-risk-based-conditional-access [IN] OBSERVATION Microsoft Entra ID Protection detects identity-based risks and enables risk-based Conditional Access policies at low, medium, and high risk levels. - Source: entries/2026/03/10/entra-overview.md - Source hash: 4e443bc2b765a028 - Date: 2026-03-11 ### entra-id-roles-separate-from-azure-rbac [IN] OBSERVATION Microsoft Entra ID has its own separate set of built-in roles distinct from Azure RBAC roles. - Source: entries/2026/03/10/rbac-built-in-roles.md - Source hash: 537994bcf7a587c3 - Date: 2026-03-10 ### entra-identity-dual-model-lifecycle [IN] OBSERVATION 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. ### entra-identity-to-authorization-chain [IN] OBSERVATION 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. ### entra-initial-domain-onmicrosoft [IN] OBSERVATION Every new Entra directory gets an initial domain like `contoso.onmicrosoft.com`; custom domains can be added afterward. - Source: entries/2026/03/10/entra-overview.md - Source hash: 4e443bc2b765a028 - Date: 2026-03-11 ### entra-initial-domain-onmicrosoft-com [IN] OBSERVATION Every new Entra directory gets an initial domain in the format `.onmicrosoft.com`; custom domains can be added afterward. - Source: entries/2026/03/10/entra-overview.md - Source hash: 4e443bc2b765a028 - Date: 2026-03-11 ### entra-internet-access-replaces-web-proxies [IN] OBSERVATION 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. - Source: entries/2026/03/11/entra-overview.md - Source hash: 30c520ae3012b259 - Date: 2026-03-11 ### entra-internet-access-web-content-filtering [IN] OBSERVATION Microsoft Entra Internet Access secures access to internet resources, SaaS apps, and Microsoft 365 with features like web content filtering. - Source: entries/2026/03/10/entra-overview.md - Source hash: 4e443bc2b765a028 - Date: 2026-03-11 ### entra-internet-access-web-filtering [IN] OBSERVATION Microsoft Entra Internet Access secures access to internet resources, SaaS apps, and Microsoft 365 with features like web content filtering. - Source: entries/2026/03/10/entra-overview.md - Source hash: 4e443bc2b765a028 - Date: 2026-03-11 ### entra-is-product-family-not-single-product [IN] OBSERVATION 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. - Source: entries/2026/03/10/entra-overview.md - Source hash: 4e443bc2b765a028 - Date: 2026-03-10 ### entra-legacy-sp-no-app-registration [IN] OBSERVATION Legacy service principals have no associated app registration and are only usable in the tenant where they were created. - Source: entries/2026/03/10/entra-service-principals.md - Source hash: 22f34ce4ab8c61c8 - Date: 2026-03-10 ### entra-m365-group-email [IN] OBSERVATION Microsoft 365 is the only Entra group type that supports a group email address. - Source: entries/2026/03/10/entra-groups.md - Source hash: 6c99d892c6c40c75 - Date: 2026-03-10 ### entra-m365-group-welcome-email-auto [IN] OBSERVATION 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. - Source: entries/2026/03/11/entra-groups.md - Source hash: 028fea02f16b47c9 - Date: 2026-03-11 ### entra-m365-group-welcome-email-disable-set-unifiedgroup [IN] OBSERVATION 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. - Source: entries/2026/03/11/entra-groups.md - Source hash: 028fea02f16b47c9 - Date: 2026-03-11 ### entra-managed-identity-deployment-slot-name [IN] OBSERVATION For App Service deployment slots, the system-assigned managed identity service principal name follows the format `/slots/`. - Source: entries/2026/03/11/entra-managed-identities.md - Source hash: fa85eb1b63928b9c - Date: 2026-03-11 ### entra-managed-identity-sp-no-app-object [IN] OBSERVATION Managed identity service principals have no associated application object and cannot be updated or modified directly. - Source: entries/2026/03/10/entra-service-principals.md - Source hash: 22f34ce4ab8c61c8 - Date: 2026-03-10 ### entra-managed-identity-token-workflow [IN] OBSERVATION 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. - Source: entries/2026/03/11/entra-managed-identities.md - Source hash: fa85eb1b63928b9c - Date: 2026-03-11 ### entra-multitenant-consent-creates-sp-in-consumer-tenant [IN] OBSERVATION Admin consent for a multitenant app in a consumer tenant creates a service principal in that consumer tenant. - Source: entries/2026/03/11/entra-service-principals.md - Source hash: c987aff7abc3204c - Date: 2026-03-11 ### entra-multitenant-sp-created-on-consent [IN] OBSERVATION 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. - Source: entries/2026/03/10/entra-service-principals.md - Source hash: 22f34ce4ab8c61c8 - Date: 2026-03-11 ### entra-nested-group-restrictions [IN] OBSERVATION 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. - Source: entries/2026/03/10/entra-groups.md - Source hash: 6c99d892c6c40c75 - Date: 2026-03-10 ### entra-nested-groups-inherit-conditional-access [IN] OBSERVATION Nested groups inherit Conditional Access policy scopes and membership, but do NOT inherit shared resource or application access. - Source: entries/2026/03/10/entra-groups.md - Source hash: 6c99d892c6c40c75 - Date: 2026-03-11 ### entra-nested-groups-security-only [IN] OBSERVATION Nested groups (group within a group) are supported for security groups only, not Microsoft 365 groups. - Source: entries/2026/03/10/entra-groups.md - Source hash: 6c99d892c6c40c75 - Date: 2026-03-11 ### entra-on-prem-synced-groups-no-nested-additions [IN] OBSERVATION Groups synced from on-premises Active Directory to Entra ID cannot have other groups added to them as members. - Source: entries/2026/03/11/entra-groups.md - Source hash: 028fea02f16b47c9 - Date: 2026-03-11 ### entra-portal-creates-both-app-and-sp [IN] OBSERVATION 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. - Source: entries/2026/03/10/entra-service-principals.md - Source hash: 22f34ce4ab8c61c8 - Date: 2026-03-10 ### entra-private-access-replaces-vpn [IN] OBSERVATION Microsoft Entra Private Access replaces VPN by securing access to private apps and corporate networks from any device or network. - Source: entries/2026/03/10/entra-overview.md - Source hash: 4e443bc2b765a028 - Date: 2026-03-10 ### entra-privileged-auth-admin-can-delete-any-user [IN] OBSERVATION The Privileged Authentication Administrator role can delete any user including other admins; the User Administrator role cannot delete admin users. - Source: entries/2026/03/11/entra-users.md - Source hash: c65156a0dc6c6a6e - Date: 2026-03-11 ### entra-role-assignable-groups-require-p1-p2 [IN] OBSERVATION 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. - Source: entries/2026/03/10/entra-groups.md - Source hash: 6c99d892c6c40c75 - Date: 2026-03-10 ### entra-sp-required-for-tenant-access [IN] OBSERVATION A service principal must exist in a tenant for an application to sign in or access resources in that tenant. - Source: entries/2026/03/10/entra-service-principals.md - Source hash: 22f34ce4ab8c61c8 - Date: 2026-03-11 ### entra-synced-users-modify-in-onprem-ad [IN] OBSERVATION 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. - Source: entries/2026/03/10/entra-users.md - Source hash: e6ca62bbc7b38940 - Date: 2026-03-10 ### entra-system-assigned-identity-sp-name-matches-resource [IN] OBSERVATION A system-assigned managed identity's service principal name matches the Azure resource name; for deployment slots the format is `/slots/`. - Source: entries/2026/03/11/entra-managed-identities.md - Source hash: fa85eb1b63928b9c - Date: 2026-03-11 ### entra-tenant-auto-created-with-m365-azure [IN] OBSERVATION Every Microsoft 365, Office 365, Azure, and Dynamics CRM Online tenant is automatically a Microsoft Entra tenant. - Source: entries/2026/03/10/entra-overview.md - Source hash: 4e443bc2b765a028 - Date: 2026-03-10 ### entra-three-service-principal-types [IN] OBSERVATION Microsoft Entra ID has three types of service principals: Application, Managed Identity, and Legacy. - Source: entries/2026/03/10/entra-service-principals.md - Source hash: 22f34ce4ab8c61c8 - Date: 2026-03-10 ### entra-user-creation-max-20-groups-1-admin-unit [IN] OBSERVATION Up to 20 groups or roles can be assigned at user creation; only one administrative unit can be assigned. - Source: entries/2026/03/10/entra-users.md - Source hash: e6ca62bbc7b38940 - Date: 2026-03-10 ### entra-user-type-determines-privilege-level [IN] OBSERVATION User type (Member vs Guest) determines privilege level, not whether the account is internal or external. - Source: entries/2026/03/10/entra-users.md - Source hash: e6ca62bbc7b38940 - Date: 2026-03-10 ### entra-verified-id-uses-did-standards [IN] OBSERVATION Microsoft Entra Verified ID is a decentralized identity (DID) credential verification service based on open standards where the user controls their credentials. - Source: entries/2026/03/10/entra-overview.md - Source hash: 4e443bc2b765a028 - Date: 2026-03-10 ### entra-workload-id-non-human-identities [IN] OBSERVATION Microsoft Entra Workload ID provides IAM for non-human identities: applications, services, containers, and CI/CD pipelines. - Source: entries/2026/03/10/entra-overview.md - Source hash: 4e443bc2b765a028 - Date: 2026-03-10 ### eventgrid-413-payload-too-large [IN] OBSERVATION Event Grid returns HTTP 413 Payload Too Large when event or event array size exceeds the 1 MB limit. - Source: entries/2026/03/11/eventgrid-event-schema.md - Source hash: 9dcb5e16de1448bb - Date: 2026-03-11 ### eventgrid-cloudevents-input-cannot-output-eventgrid-format [IN] OBSERVATION 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. - Source: entries/2026/03/11/eventgrid-event-schema.md - Source hash: 9dcb5e16de1448bb - Date: 2026-03-11 ### eventgrid-cloudevents-structured-json-only [IN] OBSERVATION Azure Event Grid supports CloudEvents 1.0 in Structured JSON content mode only; Binary content mode is not supported. - Source: entries/2026/03/11/eventgrid-concepts.md - Source hash: e98a8400fa982297 - Date: 2026-03-11 ### eventgrid-eventhubs-handler-requires-data-sender-role [IN] OBSERVATION When using managed identity to deliver Event Grid events to Event Hubs, the identity needs the Event Hubs Data Sender RBAC role. - Source: entries/2026/03/11/eventgrid-concepts.md - Source hash: e98a8400fa982297 - Date: 2026-03-11 ### eventgrid-events-must-publish-as-array [IN] OBSERVATION Events must always be published to Event Grid as a JSON array, even when sending a single event. - Source: entries/2026/03/11/eventgrid-concepts.md - Source hash: e98a8400fa982297 - Date: 2026-03-11 ### eventgrid-events-published-as-array [IN] OBSERVATION Events must always be published to Event Grid in a JSON array, even for a single event. - Source: entries/2026/03/11/eventgrid-concepts.md - Source hash: e98a8400fa982297 - Date: 2026-03-11 ### eventgrid-max-event-size-1mb [IN] OBSERVATION Azure Event Grid maximum event size is 1 MB; events over 64 KB are charged in 64 KB increments. - Source: entries/2026/03/11/eventgrid-concepts.md - Source hash: e98a8400fa982297 - Date: 2026-03-11 ### eventgrid-max-event-size-1mb-charged-64kb [IN] OBSERVATION 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). - Source: entries/2026/03/11/eventgrid-concepts.md - Source hash: e98a8400fa982297 - Date: 2026-03-11 ### eventgrid-metadata-version-only-1 [IN] OBSERVATION Event Grid schema `metadataVersion` is currently only version `1`; Event Grid stamps it if omitted. - Source: entries/2026/03/11/eventgrid-event-schema.md - Source hash: 9dcb5e16de1448bb - Date: 2026-03-11 ### eventgrid-publish-auth-sas-or-key [IN] OBSERVATION Publishing events to Event Grid requires SAS token or key authentication. - Source: entries/2026/03/11/eventgrid-concepts.md - Source hash: e98a8400fa982297 - Date: 2026-03-11 ### eventgrid-schema-413-payload-too-large [IN] OBSERVATION Azure Event Grid returns 413 Payload Too Large when the event array exceeds the 1 MB size limit. - Source: entries/2026/03/11/eventgrid-event-schema.md - Source hash: 9dcb5e16de1448bb - Date: 2026-03-11 ### eventgrid-schema-not-extensible-cloudevents-recommended [IN] OBSERVATION The Event Grid event schema is proprietary and nonextensible; Microsoft recommends migrating to CloudEvents format, though Event Grid schema is not being retired. - Source: entries/2026/03/11/eventgrid-event-schema.md - Source hash: 9dcb5e16de1448bb - Date: 2026-03-11 ### eventgrid-schema-not-retired-but-no-improvements [IN] OBSERVATION Event Grid proprietary schema is not being retired but will receive no major improvements; CloudEvents is the recommended format. - Source: entries/2026/03/11/eventgrid-event-schema.md - Source hash: 9dcb5e16de1448bb - Date: 2026-03-11 ### eventgrid-schema-required-fields [IN] OBSERVATION Event Grid schema required properties are: `subject`, `eventType`, `eventTime`, `id`, and `data`; `topic` is optional (Event Grid stamps it if omitted). - Source: entries/2026/03/11/eventgrid-event-schema.md - Source hash: 9dcb5e16de1448bb - Date: 2026-03-11 ### eventgrid-schema-required-properties [IN] OBSERVATION Event Grid schema required properties are: `subject`, `eventType`, `eventTime`, `id`, and `data`; `topic` is optional (Event Grid stamps it if omitted). - Source: entries/2026/03/11/eventgrid-event-schema.md - Source hash: 9dcb5e16de1448bb - Date: 2026-03-11 ### eventgrid-subject-path-and-suffix-filtering [IN] OBSERVATION Event Grid supports path-based filtering on the `subject` field (e.g., `/A/B/C`) and suffix filtering (e.g., `.txt`) for event routing. - Source: entries/2026/03/11/eventgrid-event-schema.md - Source hash: 9dcb5e16de1448bb - Date: 2026-03-11 ### eventgrid-subject-path-based-filtering [IN] OBSERVATION Event Grid supports path-based filtering on the `subject` field (e.g., `/A/B/C`) and suffix filtering (e.g., `.txt`) for event routing. - Source: entries/2026/03/11/eventgrid-event-schema.md - Source hash: 9dcb5e16de1448bb - Date: 2026-03-11 ### eventgrid-subject-path-filtering [IN] OBSERVATION 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. - Source: entries/2026/03/11/eventgrid-event-schema.md - Source hash: 9dcb5e16de1448bb - Date: 2026-03-11 ### eventgrid-subscription-expiration-and-filtering [IN] OBSERVATION Event Grid event subscriptions support filtering by event type and subject, and can have an expiration time for automatic cleanup. - Source: entries/2026/03/11/eventgrid-concepts.md - Source hash: e98a8400fa982297 - Date: 2026-03-11 ### eventgrid-subscription-expiration-time [IN] OBSERVATION Event Grid event subscriptions can have an expiration time set for automatic cleanup of temporary subscriptions. - Source: entries/2026/03/11/eventgrid-concepts.md - Source hash: e98a8400fa982297 - Date: 2026-03-11 ### eventgrid-supports-availability-zones [IN] OBSERVATION Azure Event Grid leverages Azure availability zones for regional high availability and fault tolerance. - Source: entries/2026/03/11/eventgrid-concepts.md - Source hash: e98a8400fa982297 - Date: 2026-03-11 ### eventgrid-three-topic-types [IN] OBSERVATION 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). - Source: entries/2026/03/11/eventgrid-concepts.md - Source hash: e98a8400fa982297 - Date: 2026-03-11 ### eventhubs-append-only-log-kafka-topic-equivalent [IN] OBSERVATION 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. - Source: entries/2026/03/11/eventhubs-features.md - Source hash: 4c5f5c81bbdc4c92 - Date: 2026-03-11 ### eventhubs-auth-entra-sas-managed-identity [IN] OBSERVATION Azure Event Hubs authentication options include Microsoft Entra ID (RBAC), Shared Access Signatures (SAS), and Managed Identities. - Source: entries/2026/03/11/eventhubs-overview.md - Source hash: 05ba7297e20a7930 - Date: 2026-03-11 ### eventhubs-auto-inflate-scales-up-only [IN] OBSERVATION Azure Event Hubs auto-inflate only scales throughput units upward, never downward. - Source: entries/2026/03/11/eventhubs-scalability.md - Source hash: c87dca499620c8c8 - Date: 2026-03-11 ### eventhubs-auto-inflate-up-only [IN] OBSERVATION Event Hubs Auto-inflate automatically scales throughput units upward to prevent throttling but does not scale down. - Source: entries/2026/03/11/eventhubs-scalability.md - Source hash: c87dca499620c8c8 - Date: 2026-03-11 ### eventhubs-az-zones-premium-dedicated-only [IN] OBSERVATION Azure Event Hubs availability zone support is available on Premium and Dedicated tiers only. - Source: entries/2026/03/11/eventhubs-overview.md - Source hash: 05ba7297e20a7930 - Date: 2026-03-11 ### eventhubs-capture-avro-default-parquet-optional [IN] OBSERVATION Event Hubs Capture archives streaming data to Azure Blob Storage or Data Lake Storage in Avro format (default) or Parquet (via no-code editor). - Source: entries/2026/03/11/eventhubs-features.md - Source hash: 4c5f5c81bbdc4c92 - Date: 2026-03-11 ### eventhubs-capture-formats-avro-parquet [IN] OBSERVATION Event Hubs Capture supports Avro (default) and Parquet (via no-code editor) formats for archival to Blob Storage or Data Lake. - Source: entries/2026/03/11/eventhubs-features.md - Source hash: 4c5f5c81bbdc4c92 - Date: 2026-03-11 ### eventhubs-capture-to-blob-or-datalake [IN] OBSERVATION 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. - Source: entries/2026/03/11/eventhubs-overview.md - Source hash: 05ba7297e20a7930 - Date: 2026-03-11 ### eventhubs-checkpointing-consumer-responsibility [IN] OBSERVATION 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. - Source: entries/2026/03/11/eventhubs-features.md - Source hash: 4c5f5c81bbdc4c92 - Date: 2026-03-11 ### eventhubs-consumer-ownership-isolation-model [IN] OBSERVATION 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. ### eventhubs-cross-protocol-produce-consume [IN] OBSERVATION Event Hubs supports cross-protocol reading and writing: produce via Kafka and consume via AMQP (or vice versa) on the same event hub. - Source: entries/2026/03/11/eventhubs-kafka.md - Source hash: f58402c60f2129f5 - Date: 2026-03-11 ### eventhubs-cross-protocol-read-write [IN] OBSERVATION Event Hubs supports cross-protocol reading: produce via Kafka and consume via AMQP, or vice versa. - Source: entries/2026/03/11/eventhubs-kafka.md - Source hash: f58402c60f2129f5 - Date: 2026-03-11 ### eventhubs-default-consumer-group-dollar-default [IN] OBSERVATION Event Hubs default consumer group is named `$Default`; each consumer group independently tracks its own position in the event stream. - Source: entries/2026/03/11/eventhubs-features.md - Source hash: 4c5f5c81bbdc4c92 - Date: 2026-03-11 ### eventhubs-delivery-semantic-at-least-once [IN] OBSERVATION Event Hubs delivery guarantee is at-least once; consumers should implement the idempotent consumer pattern for exactly-once semantics. - Source: entries/2026/03/11/eventhubs-kafka.md - Source hash: f58402c60f2129f5 - Date: 2026-03-11 ### eventhubs-direct-partition-send-discouraged [IN] OBSERVATION Sending directly to a specific Event Hubs partition is discouraged because it downgrades availability to partition-level. - Source: entries/2026/03/11/eventhubs-features.md - Source hash: 4c5f5c81bbdc4c92 - Date: 2026-03-11 ### eventhubs-encryption-at-rest-and-tls12 [IN] OBSERVATION Azure Event Hubs encrypts data at rest with Microsoft-managed or customer-managed keys and enforces TLS 1.2 for data in transit. - Source: entries/2026/03/11/eventhubs-overview.md - Source hash: 05ba7297e20a7930 - Date: 2026-03-11 ### eventhubs-epoch-consumer-one-owner-per-partition [IN] OBSERVATION Event Hubs epoch consumers allow only one owner per partition per consumer group; a higher epoch evicts the lower epoch consumer. - Source: entries/2026/03/11/eventhubs-features.md - Source hash: 4c5f5c81bbdc4c92 - Date: 2026-03-11 ### eventhubs-epoch-consumer-one-per-partition [IN] OBSERVATION Event Hubs epoch consumers allow only one owner per partition per consumer group; a higher epoch evicts lower epoch consumers. - Source: entries/2026/03/11/eventhubs-features.md - Source hash: 4c5f5c81bbdc4c92 - Date: 2026-03-11 ### eventhubs-epoch-one-owner-nonepoch-five-readers [IN] OBSERVATION 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. - Source: entries/2026/03/11/eventhubs-features.md - Source hash: 4c5f5c81bbdc4c92 - Date: 2026-03-11 ### eventhubs-events-cannot-be-explicitly-deleted [IN] OBSERVATION Events in Event Hubs cannot be explicitly deleted; removal is automatic based on the configured retention policy. - Source: entries/2026/03/11/eventhubs-features.md - Source hash: 4c5f5c81bbdc4c92 - Date: 2026-03-11 ### eventhubs-five-nonepoch-readers-per-partition [IN] OBSERVATION 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. - Source: entries/2026/03/11/eventhubs-scalability.md - Source hash: c87dca499620c8c8 - Date: 2026-03-11 ### eventhubs-full-kafka-interop [IN] OBSERVATION 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. ### eventhubs-geo-dr-metadata-sync [IN] OBSERVATION Azure Event Hubs Geo-DR provides metadata synchronization and failover to a secondary region. - Source: entries/2026/03/11/eventhubs-overview.md - Source hash: 05ba7297e20a7930 - Date: 2026-03-11 ### eventhubs-https-send-only [IN] OBSERVATION Event Hubs HTTPS protocol supports send (publish) only — no receive capability; AMQP is used by SDKs for high-throughput bidirectional scenarios. - Source: entries/2026/03/11/eventhubs-features.md - Source hash: 4c5f5c81bbdc4c92 - Date: 2026-03-11 ### eventhubs-ingress-exceeds-throws-egress-silent [IN] OBSERVATION Exceeding Event Hubs ingress capacity throws an EventHubsException with ServiceBusy reason; exceeding egress capacity is silently capped without exceptions. - Source: entries/2026/03/11/eventhubs-scalability.md - Source hash: c87dca499620c8c8 - Date: 2026-03-11 ### eventhubs-ingress-throws-egress-silent [IN] OBSERVATION Exceeding Event Hubs ingress capacity throws `EventHubsException` with `ServiceBusy` reason; exceeding egress capacity is silently capped without exceptions. - Source: entries/2026/03/11/eventhubs-scalability.md - Source hash: c87dca499620c8c8 - Date: 2026-03-11 ### eventhubs-kafka-at-least-once-delivery [IN] OBSERVATION Event Hubs Kafka delivery semantic is at-least once; consumers should implement the idempotent consumer pattern. - Source: entries/2026/03/11/eventhubs-kafka.md - Source hash: f58402c60f2129f5 - Date: 2026-03-11 ### eventhubs-kafka-compression-gzip-only-premium-dedicated [IN] OBSERVATION 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. - Source: entries/2026/03/11/eventhubs-kafka.md - Source hash: f58402c60f2129f5 - Date: 2026-03-11 ### eventhubs-kafka-compression-gzip-premium-dedicated [IN] OBSERVATION Event Hubs Kafka endpoint supports only gzip compression, available in Premium and Dedicated tiers only. - Source: entries/2026/03/11/eventhubs-kafka.md - Source hash: f58402c60f2129f5 - Date: 2026-03-11 ### eventhubs-kafka-compression-gzip-premium-dedicated-only [IN] OBSERVATION Event Hubs Kafka compression supports only `gzip`, available in Premium and Dedicated tiers only. - Source: entries/2026/03/11/eventhubs-kafka.md - Source hash: f58402c60f2129f5 - Date: 2026-03-11 ### eventhubs-kafka-cross-protocol-read-write [IN] OBSERVATION Event Hubs supports cross-protocol reading and writing: produce via Kafka and consume via AMQP, or vice versa. - Source: entries/2026/03/11/eventhubs-kafka.md - Source hash: f58402c60f2129f5 - Date: 2026-03-11 ### eventhubs-kafka-delivery-at-least-once [IN] OBSERVATION Azure Event Hubs Kafka endpoint delivery semantic is at-least-once; consumers should implement the idempotent consumer pattern. - Source: entries/2026/03/11/eventhubs-kafka.md - Source hash: f58402c60f2129f5 - Date: 2026-03-11 ### eventhubs-kafka-migration-tier-prerequisite [IN] OBSERVATION 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. ### eventhubs-kafka-no-code-changes [IN] OBSERVATION Existing Apache Kafka workloads can run on Azure Event Hubs without code changes or cluster management. - Source: entries/2026/03/11/eventhubs-overview.md - Source hash: 05ba7297e20a7930 - Date: 2026-03-11 ### eventhubs-kafka-not-basic-tier [IN] OBSERVATION Event Hubs Kafka endpoint support is available only in Standard, Premium, and Dedicated tiers — not available on Basic. - Source: entries/2026/03/11/eventhubs-kafka.md - Source hash: f58402c60f2129f5 - Date: 2026-03-11 ### eventhubs-kafka-oauth-oauthbearer-sas-plain [IN] OBSERVATION Event Hubs Kafka endpoint uses SASL mechanism `OAUTHBEARER` for OAuth 2.0 and `PLAIN` with `username="$ConnectionString"` for SAS authentication. - Source: entries/2026/03/11/eventhubs-kafka.md - Source hash: f58402c60f2129f5 - Date: 2026-03-11 ### eventhubs-kafka-port-9093-sasl-ssl [IN] OBSERVATION Event Hubs Kafka endpoint uses port 9093 with mandatory TLS encryption (`SASL_SSL`); OAuth uses `OAUTHBEARER` mechanism, SAS uses `PLAIN` mechanism with `username="$ConnectionString"`. - Source: entries/2026/03/11/eventhubs-kafka.md - Source hash: f58402c60f2129f5 - Date: 2026-03-11 ### eventhubs-kafka-port-9093-tls-mandatory [IN] OBSERVATION Event Hubs Kafka endpoint uses port 9093 with mandatory TLS encryption (`SASL_SSL`). - Source: entries/2026/03/11/eventhubs-kafka.md - Source hash: f58402c60f2129f5 - Date: 2026-03-11 ### eventhubs-kafka-requires-standard-or-higher [IN] OBSERVATION Event Hubs Kafka support requires Standard, Premium, or Dedicated tier — not available on Basic. - Source: entries/2026/03/11/eventhubs-kafka.md - Source hash: f58402c60f2129f5 - Date: 2026-03-11 ### eventhubs-kafka-sas-key-regen-no-disconnect [IN] OBSERVATION Event Hubs SAS connections are not disconnected when the SAS key is regenerated. - Source: entries/2026/03/11/eventhubs-kafka.md - Source hash: f58402c60f2129f5 - Date: 2026-03-11 ### eventhubs-kafka-sas-not-disconnected-on-key-regen [IN] OBSERVATION SAS connections to the Event Hubs Kafka endpoint are not disconnected when the SAS key is regenerated. - Source: entries/2026/03/11/eventhubs-kafka.md - Source hash: f58402c60f2129f5 - Date: 2026-03-11 ### eventhubs-kafka-streams-preview-premium-dedicated [IN] OBSERVATION Kafka Streams on Event Hubs is in public preview, available only in Premium and Dedicated tiers; ksqlDB is not available due to Confluent licensing. - Source: entries/2026/03/11/eventhubs-kafka.md - Source hash: f58402c60f2129f5 - Date: 2026-03-11 ### eventhubs-kafka-streams-transactions-preview-premium-dedicated [IN] OBSERVATION Kafka Streams and Kafka Transactions on Event Hubs are in public preview and available only in Premium and Dedicated tiers. - Source: entries/2026/03/11/eventhubs-kafka.md - Source hash: f58402c60f2129f5 - Date: 2026-03-11 ### eventhubs-max-40-tus-per-namespace [IN] OBSERVATION Azure Event Hubs Standard tier allows a maximum of 40 throughput units per namespace, shared across all event hubs in the namespace. - Source: entries/2026/03/11/eventhubs-scalability.md - Source hash: c87dca499620c8c8 - Date: 2026-03-11 ### eventhubs-max-5-nonepoch-consumers-per-partition [IN] OBSERVATION 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. - Source: entries/2026/03/11/eventhubs-scalability.md - Source hash: c87dca499620c8c8 - Date: 2026-03-11 ### eventhubs-max-parallel-consumers-equals-partitions [IN] OBSERVATION The number of partitions in an Event Hub equals the maximum number of parallel consumers per consumer group. - Source: entries/2026/03/11/eventhubs-scalability.md - Source hash: c87dca499620c8c8 - Date: 2026-03-11 ### eventhubs-max-publish-size-1mb [IN] OBSERVATION Event Hubs maximum publish size is 1 MB per operation (batch or individual event). - Source: entries/2026/03/11/eventhubs-features.md - Source hash: 4c5f5c81bbdc4c92 - Date: 2026-03-11 ### eventhubs-messaging-comparison [IN] OBSERVATION 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. - Source: entries/2026/03/11/eventhubs-overview.md - Source hash: 05ba7297e20a7930 - Date: 2026-03-11 ### eventhubs-non-epoch-max-5-readers-per-partition [IN] OBSERVATION Event Hubs non-epoch consumers allow up to 5 concurrent readers per partition; an epoch consumer connecting disconnects all non-epoch consumers. - Source: entries/2026/03/11/eventhubs-features.md - Source hash: 4c5f5c81bbdc4c92 - Date: 2026-03-11 ### eventhubs-paas-streaming-platform [IN] OBSERVATION Azure Event Hubs is a fully managed PaaS real-time data streaming platform that ingests millions of events per second with low latency. - Source: entries/2026/03/11/eventhubs-overview.md - Source hash: 05ba7297e20a7930 - Date: 2026-03-11 ### eventhubs-partition-count-cannot-decrease [IN] OBSERVATION 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. - Source: entries/2026/03/11/eventhubs-features.md - Source hash: 4c5f5c81bbdc4c92 - Date: 2026-03-11 ### eventhubs-partition-count-no-pricing-impact [IN] OBSERVATION Event Hubs pricing depends on throughput/processing/capacity units, not on partition count. - Source: entries/2026/03/11/eventhubs-scalability.md - Source hash: c87dca499620c8c8 - Date: 2026-03-11 ### eventhubs-partition-key-hash-round-robin-if-omitted [IN] OBSERVATION Event Hubs partition key is hashed to determine partition assignment; if omitted, events are distributed round-robin across partitions. - Source: entries/2026/03/11/eventhubs-features.md - Source hash: 4c5f5c81bbdc4c92 - Date: 2026-03-11 ### eventhubs-partition-key-static-hash [IN] OBSERVATION Event Hubs partition keys use a static hashing function to assign events to partitions; without a key, round-robin assignment is used. - Source: entries/2026/03/11/eventhubs-scalability.md - Source hash: c87dca499620c8c8 - Date: 2026-03-11 ### eventhubs-partition-key-static-hash-or-round-robin [IN] OBSERVATION 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. - Source: entries/2026/03/11/eventhubs-scalability.md - Source hash: c87dca499620c8c8 - Date: 2026-03-11 ### eventhubs-partition-key-static-hash-roundrobin-default [IN] OBSERVATION Event Hubs partition keys use a static hashing function to assign events to partitions; without a key, round-robin assignment is used. - Source: entries/2026/03/11/eventhubs-scalability.md - Source hash: c87dca499620c8c8 - Date: 2026-03-11 ### eventhubs-partitioning-free-architectural-choice [IN] OBSERVATION 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. ### eventhubs-partitions-equal-max-parallel-consumers [IN] OBSERVATION The number of Event Hubs partitions equals the maximum number of parallel consumers per consumer group, for both AMQP epoch consumers and Kafka consumers. - Source: entries/2026/03/11/eventhubs-scalability.md - Source hash: c87dca499620c8c8 - Date: 2026-03-11 ### eventhubs-premium-pu-options [IN] OBSERVATION Event Hubs Premium tier processing units (PUs) are available in discrete values: 1, 2, 4, 6, 8, 10, 12, or 16 per namespace. - Source: entries/2026/03/11/eventhubs-scalability.md - Source hash: c87dca499620c8c8 - Date: 2026-03-11 ### eventhubs-premium-pu-options-1-2-4-6-8-10-12-16 [IN] OBSERVATION Azure Event Hubs Premium tier processing unit (PU) options are discrete values: 1, 2, 4, 6, 8, 10, 12, or 16 per namespace. - Source: entries/2026/03/11/eventhubs-scalability.md - Source hash: c87dca499620c8c8 - Date: 2026-03-11 ### eventhubs-premium-pu-options-discrete [IN] OBSERVATION Azure Event Hubs Premium tier processing unit (PU) options are discrete: 1, 2, 4, 6, 8, 10, 12, or 16 per namespace. - Source: entries/2026/03/11/eventhubs-scalability.md - Source hash: c87dca499620c8c8 - Date: 2026-03-11 ### eventhubs-progressive-tier-gating [IN] OBSERVATION 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. ### eventhubs-protocols-amqp-kafka-https [IN] OBSERVATION Azure Event Hubs natively supports three protocols: AMQP 1.0, Apache Kafka (1.0+), and HTTPS. - Source: entries/2026/03/11/eventhubs-overview.md - Source hash: 05ba7297e20a7930 - Date: 2026-03-11 ### eventhubs-retention-standard-7-premium-90 [IN] OBSERVATION Azure Event Hubs Standard tier supports up to 7-day data retention; Premium and Dedicated tiers support up to 90-day retention. - Source: entries/2026/03/11/eventhubs-overview.md - Source hash: 05ba7297e20a7930 - Date: 2026-03-11 ### eventhubs-retention-standard-7d-premium-90d [IN] OBSERVATION Event Hubs event retention: Standard tier default 1h / max 7 days; Premium and Dedicated default 1h / max 90 days. - Source: entries/2026/03/11/eventhubs-features.md - Source hash: 4c5f5c81bbdc4c92 - Date: 2026-03-11 ### eventhubs-retention-standard-7d-premium-dedicated-90d [IN] OBSERVATION 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. - Source: entries/2026/03/11/eventhubs-features.md - Source hash: 4c5f5c81bbdc4c92 - Date: 2026-03-11 ### eventhubs-sas-key-regen-no-disconnect [IN] OBSERVATION 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. - Source: entries/2026/03/11/eventhubs-kafka.md - Source hash: f58402c60f2129f5 - Date: 2026-03-11 ### eventhubs-schema-registry-avro-json [IN] OBSERVATION Azure Event Hubs Schema Registry supports Avro and JSON schema formats for centralized schema management across producers and consumers. - Source: entries/2026/03/11/eventhubs-overview.md - Source hash: 05ba7297e20a7930 - Date: 2026-03-11 ### eventhubs-single-virtual-ip-endpoint [IN] OBSERVATION Event Hubs uses a single virtual IP as its endpoint rather than per-broker endpoints, simplifying firewall rules compared to self-managed Kafka. - Source: entries/2026/03/11/eventhubs-kafka.md - Source hash: f58402c60f2129f5 - Date: 2026-03-11 ### eventhubs-sla-up-to-9999 [IN] OBSERVATION Azure Event Hubs SLA is up to 99.99% depending on tier and configuration. - Source: entries/2026/03/11/eventhubs-overview.md - Source hash: 05ba7297e20a7930 - Date: 2026-03-11 ### eventhubs-standard-retention-7-days [IN] OBSERVATION Azure Event Hubs Standard tier supports up to 7-day data retention; Premium and Dedicated tiers support up to 90-day retention. - Source: entries/2026/03/11/eventhubs-overview.md - Source hash: 05ba7297e20a7930 - Date: 2026-03-11 ### eventhubs-standard-tu-limits [IN] OBSERVATION 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. - Source: entries/2026/03/11/eventhubs-scalability.md - Source hash: c87dca499620c8c8 - Date: 2026-03-11 ### eventhubs-three-protocols-amqp-kafka-https [IN] OBSERVATION Azure Event Hubs natively supports three protocols: AMQP 1.0, Apache Kafka, and HTTPS. - Source: entries/2026/03/11/eventhubs-overview.md - Source hash: 05ba7297e20a7930 - Date: 2026-03-11 ### eventhubs-three-rbac-roles [IN] OBSERVATION Event Hubs has three data-plane RBAC roles: Data Owner (full), Data Sender (send only), and Data Receiver (receive only). - Source: entries/2026/03/11/eventhubs-features.md - Source hash: 4c5f5c81bbdc4c92 - Date: 2026-03-11 ### eventhubs-three-tiers-standard-premium-dedicated [IN] OBSERVATION Azure Event Hubs has three pricing tiers: Standard, Premium, and Dedicated, differing in retention, features, and SLA. - Source: entries/2026/03/11/eventhubs-overview.md - Source hash: 05ba7297e20a7930 - Date: 2026-03-11 ### eventhubs-tu-1mb-ingress-2mb-egress [IN] OBSERVATION 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. - Source: entries/2026/03/11/eventhubs-scalability.md - Source hash: c87dca499620c8c8 - Date: 2026-03-11 ### eventhubs-vs-servicebus-vs-eventgrid [IN] OBSERVATION 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. - Source: entries/2026/03/11/eventhubs-overview.md - Source hash: 05ba7297e20a7930 - Date: 2026-03-11 ### expressroute-requires-bgp-vpn-optional [IN] OBSERVATION ExpressRoute requires BGP for route exchange; VPN gateways can optionally use BGP. - Source: entries/2026/03/10/vnet-routing.md - Source hash: e235d55a05668d3b - Date: 2026-03-11 ### ftl2-ansible-azure-in-process-3-17x-speedup [IN] OBSERVATION FTL2 calls Ansible Azure collection modules directly in-process (no subprocess fork), achieving 3-17x speedup over ansible-playbook. - Source: entries/2026/03/11/ftl2-azure.md - Source hash: 699ce52e188e6141 - Date: 2026-03-11 ### ftl2-auto-install-azure-sdk-deps [IN] OBSERVATION FTL2 auto-installs Azure SDK pip packages (azure-mgmt-*) via `auto_install_deps=True` when missing. - Source: entries/2026/03/11/ftl2-azure.md - Source hash: 699ce52e188e6141 - Date: 2026-03-11 ### ftl2-azure-ansible-in-process-3-17x-speedup [IN] OBSERVATION FTL2 calls Azure Ansible collection modules directly in-process (no subprocess fork), achieving 3-17x speedup over ansible-playbook. - Source: entries/2026/03/11/ftl2-azure.md - Source hash: 699ce52e188e6141 - Date: 2026-03-11 ### ftl2-azure-example-path [IN] OBSERVATION The FTL2 Azure example script is located at ~/git/faster-than-light2/examples/07-azure/example_azure_web_stack.py. - Source: entries/2026/03/11/ftl2-azure.md - Source hash: 699ce52e188e6141 - Date: 2026-03-11 ### ftl2-azure-fqcn-azcollection [IN] OBSERVATION FTL2 accesses Azure modules via FQCN pattern: `await ftl.azure.azcollection.azure_rm_resourcegroup(...)`. - Source: entries/2026/03/11/ftl2-azure.md - Source hash: 699ce52e188e6141 - Date: 2026-03-11 ### ftl2-azure-fqcn-pattern [IN] OBSERVATION FTL2 accesses Azure modules via FQCN pattern: `await ftl.azure.azcollection.azure_rm_resourcegroup(...)`. - Source: entries/2026/03/11/ftl2-azure.md - Source hash: 699ce52e188e6141 - Date: 2026-03-11 ### ftl2-azure-modules-via-ansible-fqcn [IN] OBSERVATION FTL2 accesses Azure modules via Ansible FQCN pattern: `azure.azcollection.azure_rm_*` — it has no native Azure modules. - Source: entries/2026/03/11/ftl2-azure.md - Source hash: 699ce52e188e6141 - Date: 2026-03-11 ### ftl2-azure-secret-bindings-glob-pattern [IN] OBSERVATION FTL2 injects Azure credentials (client_id, secret, subscription_id, tenant) via glob pattern matching on `azure.azcollection.*` so scripts never handle raw credentials. - Source: entries/2026/03/11/ftl2-azure.md - Source hash: 699ce52e188e6141 - Date: 2026-03-11 ### ftl2-azure-secret-bindings-inject-credentials [IN] OBSERVATION FTL2 secret bindings inject Azure credentials (client_id, secret, subscription_id, tenant) automatically via glob pattern matching on `azure.azcollection.*` modules. - Source: entries/2026/03/11/ftl2-azure.md - Source hash: 699ce52e188e6141 - Date: 2026-03-11 ### ftl2-azure-teardown-delete-resource-group [IN] OBSERVATION FTL2 Azure teardown pattern: delete the resource group with `state="absent", force_delete_nonempty=True` to remove all contained resources. - Source: entries/2026/03/11/ftl2-azure.md - Source hash: 699ce52e188e6141 - Date: 2026-03-11 ### ftl2-calls-ansible-modules-in-process [IN] OBSERVATION FTL2 calls Ansible modules directly in-process (no subprocess fork), achieving 3-17x speedup over ansible-playbook. - Source: entries/2026/03/11/ftl2-azure.md - Source hash: 699ce52e188e6141 - Date: 2026-03-11 ### ftl2-no-native-azure-modules [IN] OBSERVATION FTL2 does not have native Azure modules; all Azure calls go through Ansible module machinery via the azure.azcollection collection. - Source: entries/2026/03/11/ftl2-azure.md - Source hash: 699ce52e188e6141 - Date: 2026-03-11 ### ftl2-no-native-azure-modules-uses-ansible [IN] OBSERVATION FTL2 does not have native Azure modules; all Azure calls go through Ansible module machinery via the azure.azcollection collection. - Source: entries/2026/03/11/ftl2-azure.md - Source hash: 699ce52e188e6141 - Date: 2026-03-11 ### ftl2-secret-bindings-inject-azure-credentials [IN] OBSERVATION FTL2 secret bindings inject Azure credentials (client_id, secret, subscription_id, tenant) automatically via glob pattern matching so scripts never see raw credentials. - Source: entries/2026/03/11/ftl2-azure.md - Source hash: 699ce52e188e6141 - Date: 2026-03-11 ### ftl2-state-tracking-idempotent-crash-recovery [IN] OBSERVATION FTL2 tracks state via `.ftl2-state.json` enabling idempotent provisioning with crash recovery and provider filtering. - Source: entries/2026/03/11/ftl2-azure.md - Source hash: 699ce52e188e6141 - Date: 2026-03-11 ### functions-consumption-linux-retiring-sept-2028 [IN] OBSERVATION Azure Functions Linux Consumption plan is retiring September 30, 2028; no new features/language versions after September 30, 2025. Migrate to Flex Consumption. - Source: entries/2026/03/11/functions-hosting.md - Source hash: a9c0e18cd66aa42e - Date: 2026-03-11 ### functions-consumption-timeout-5min-default-10min-max [IN] OBSERVATION 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. - Source: entries/2026/03/11/functions-hosting.md - Source hash: a9c0e18cd66aa42e - Date: 2026-03-11 ### functions-consumption-timeout-default-5-max-10 [IN] OBSERVATION 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. - Source: entries/2026/03/11/functions-hosting.md - Source hash: a9c0e18cd66aa42e - Date: 2026-03-11 ### functions-custom-handlers-any-http-language [IN] OBSERVATION Azure Functions custom handlers enable any language that can receive HTTP requests to run as a function - Source: entries/2026/03/11/functions-overview.md - Source hash: 96a4ec1329f9cca9 - Date: 2026-03-11 ### functions-custom-handlers-any-language-http [IN] OBSERVATION Azure Functions custom handlers enable any language that can receive HTTP requests to be used as a function runtime. - Source: entries/2026/03/11/functions-overview.md - Source hash: 96a4ec1329f9cca9 - Date: 2026-03-11 ### functions-durable-functions-stateful-workflows [IN] OBSERVATION Durable Functions is an extension for building stateful, event-driven serverless workflows in Azure Functions - Source: entries/2026/03/11/functions-overview.md - Source hash: 96a4ec1329f9cca9 - Date: 2026-03-11 ### functions-durable-stateful-workflows [IN] OBSERVATION Durable Functions is an Azure Functions extension for building stateful, event-driven serverless workflows and orchestrations. - Source: entries/2026/03/11/functions-overview.md - Source hash: 96a4ec1329f9cca9 - Date: 2026-03-11 ### functions-five-hosting-plans [IN] OBSERVATION Azure Functions offers five hosting plans: Flex Consumption, Premium, Dedicated (App Service), Container Apps, and Consumption. - Source: entries/2026/03/11/functions-hosting.md - Source hash: a9c0e18cd66aa42e - Date: 2026-03-11 ### functions-five-native-languages [IN] OBSERVATION Azure Functions natively supports five programming languages: C#, Java, JavaScript, PowerShell, and Python; other languages (Rust, Go) are supported via custom handlers. - Source: entries/2026/03/11/functions-overview.md - Source hash: 96a4ec1329f9cca9 - Date: 2026-03-11 ### functions-flex-consumption-linux-only [IN] OBSERVATION Azure Functions Flex Consumption plan supports Linux only. - Source: entries/2026/03/11/functions-hosting.md - Source hash: a9c0e18cd66aa42e - Date: 2026-03-11 ### functions-flex-consumption-max-1000-instances [IN] OBSERVATION Azure Functions Flex Consumption plan scales up to 1000 instances with per-function scaling, configurable memory (512/2048/4096 MB), and Linux only. - Source: entries/2026/03/11/functions-hosting.md - Source hash: a9c0e18cd66aa42e - Date: 2026-03-11 ### functions-flex-consumption-no-subnet-underscores [IN] OBSERVATION Flex Consumption subnets cannot contain underscores in their names - Source: entries/2026/03/11/functions-networking.md - Source hash: 1cfbb950bb236d1d - Date: 2026-03-11 ### functions-flex-consumption-per-function-scaling [IN] OBSERVATION 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). - Source: entries/2026/03/11/functions-hosting.md - Source hash: a9c0e18cd66aa42e - Date: 2026-03-11 ### functions-flex-consumption-routes-all-traffic-through-vnet [IN] OBSERVATION Azure Functions Flex Consumption routes all outbound traffic through the VNet by default (no Route All setting needed), unlike other plans. - Source: entries/2026/03/11/functions-networking.md - Source hash: 1cfbb950bb236d1d - Date: 2026-03-11 ### functions-flex-consumption-subnet-40-ips-per-app [IN] OBSERVATION Azure Functions Flex Consumption requires planning for 40 IP addresses per function app regardless of actual instance count; recommended subnet size is /27. - Source: entries/2026/03/11/functions-networking.md - Source hash: 1cfbb950bb236d1d - Date: 2026-03-11 ### functions-flex-consumption-subnet-delegation-microsoft-app [IN] OBSERVATION Azure Functions Flex Consumption subnet delegation is `Microsoft.App/environments`, different from Premium/Dedicated plans. - Source: entries/2026/03/11/functions-networking.md - Source hash: 1cfbb950bb236d1d - Date: 2026-03-11 ### functions-flex-consumption-subnet-no-underscores [IN] OBSERVATION Azure Functions Flex Consumption subnets cannot contain underscores in their names. - Source: entries/2026/03/11/functions-networking.md - Source hash: 1cfbb950bb236d1d - Date: 2026-03-11 ### functions-flex-consumption-subnet-size-27 [IN] OBSERVATION Flex Consumption recommended subnet size is /27, planning for 40 IP addresses per function app regardless of actual instance count - Source: entries/2026/03/11/functions-networking.md - Source hash: 1cfbb950bb236d1d - Date: 2026-03-11 ### functions-gateway-required-vnet-dedicated-only [IN] OBSERVATION Gateway-required VNet integration is only supported on the Dedicated (App Service) plan - Source: entries/2026/03/11/functions-networking.md - Source hash: 1cfbb950bb236d1d - Date: 2026-03-11 ### functions-gateway-vnet-integration-dedicated-only [IN] OBSERVATION Gateway-required VNet integration is only supported on the Dedicated (App Service) plan - Source: entries/2026/03/11/functions-networking.md - Source hash: 1cfbb950bb236d1d - Date: 2026-03-11 ### functions-http-230s-hard-limit-all-plans [IN] OBSERVATION 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. - Source: entries/2026/03/11/functions-hosting.md - Source hash: a9c0e18cd66aa42e - Date: 2026-03-11 ### functions-http-trigger-230s-hard-limit [IN] OBSERVATION HTTP triggers on Azure Functions are capped at 230 seconds response time across ALL hosting plans due to the Azure Load Balancer idle timeout. - Source: entries/2026/03/11/functions-hosting.md - Source hash: a9c0e18cd66aa42e - Date: 2026-03-11 ### functions-hybrid-connections-windows-only [IN] OBSERVATION Azure Functions Hybrid Connections (Azure Relay) are Windows only, not supported on Consumption plan or Linux. - Source: entries/2026/03/11/functions-networking.md - Source hash: 1cfbb950bb236d1d - Date: 2026-03-11 ### functions-max-5000-apps-per-subscription [IN] OBSERVATION Maximum of 5,000 function apps per Azure subscription across all hosting plans. - Source: entries/2026/03/11/functions-hosting.md - Source hash: a9c0e18cd66aa42e - Date: 2026-03-11 ### functions-max-5000-per-subscription [IN] OBSERVATION Azure Functions has a maximum of 5,000 function apps per subscription across all hosting plans. - Source: entries/2026/03/11/functions-hosting.md - Source hash: a9c0e18cd66aa42e - Date: 2026-03-11 ### functions-networking-consumption-no-vnet [IN] OBSERVATION Azure Functions Consumption plan does not support private endpoints, VNet integration, or outbound IP restrictions - Source: entries/2026/03/11/functions-networking.md - Source hash: 1cfbb950bb236d1d - Date: 2026-03-11 ### functions-networking-consumption-no-vnet-integration [IN] OBSERVATION Azure Functions Consumption plan does not support private endpoints, VNet integration, or outbound IP restrictions - Source: entries/2026/03/11/functions-networking.md - Source hash: 1cfbb950bb236d1d - Date: 2026-03-11 ### functions-networking-flex-consumption-routes-all-by-default [IN] OBSERVATION Flex Consumption routes all outbound traffic through VNet by default without needing Route All configuration - Source: entries/2026/03/11/functions-networking.md - Source hash: 1cfbb950bb236d1d - Date: 2026-03-11 ### functions-networking-flex-consumption-subnet-delegation [IN] OBSERVATION Flex Consumption function apps use subnet delegation `Microsoft.App/environments`, which differs from Premium/Dedicated plans - Source: entries/2026/03/11/functions-networking.md - Source hash: 1cfbb950bb236d1d - Date: 2026-03-11 ### functions-networking-flex-consumption-subnet-size-27 [IN] OBSERVATION Flex Consumption recommended subnet size is /27, planning for 40 IP addresses per function app regardless of actual instance count - Source: entries/2026/03/11/functions-networking.md - Source hash: 1cfbb950bb236d1d - Date: 2026-03-11 ### functions-networking-hybrid-connections-windows-only [IN] OBSERVATION Azure Functions Hybrid Connections (Azure Relay) are Windows only and not supported on Consumption plan or Linux - Source: entries/2026/03/11/functions-networking.md - Source hash: 1cfbb950bb236d1d - Date: 2026-03-11 ### functions-networking-nsg-integration-subnet-outbound-only [IN] OBSERVATION NSGs on a VNet integration subnet affect outbound traffic only; inbound rules do not apply because VNet integration is outbound-only - Source: entries/2026/03/11/functions-networking.md - Source hash: 1cfbb950bb236d1d - Date: 2026-03-11 ### functions-networking-nsgs-outbound-only [IN] OBSERVATION NSGs on Azure Functions VNet integration subnets affect outbound traffic only; inbound rules do not apply because VNet integration is outbound-only - Source: entries/2026/03/11/functions-networking.md - Source hash: 1cfbb950bb236d1d - Date: 2026-03-11 ### functions-networking-premium-dedicated-subnet-sizes [IN] OBSERVATION Premium/Dedicated function apps: recommended subnet is /24 for Windows, /26 for Linux; each instance consumes 1 IP, usage can temporarily double during scaling - Source: entries/2026/03/11/functions-networking.md - Source hash: 1cfbb950bb236d1d - Date: 2026-03-11 ### functions-networking-virtual-network-triggers-require-scale-monitoring [IN] OBSERVATION Virtual network triggers (non-HTTP) require either Flex Consumption or Premium plan with Runtime Scale Monitoring enabled for dynamic scaling - Source: entries/2026/03/11/functions-networking.md - Source hash: 1cfbb950bb236d1d - Date: 2026-03-11 ### functions-no-windows-containers-any-plan [IN] OBSERVATION No Azure Functions hosting plan supports Windows containers; only Linux containers are supported (on Premium, Dedicated, and Container Apps). - Source: entries/2026/03/11/functions-hosting.md - Source hash: a9c0e18cd66aa42e - Date: 2026-03-11 ### functions-nsg-integration-subnet-outbound-only [IN] OBSERVATION NSGs on Azure Functions VNet integration subnet affect outbound traffic only; inbound rules do not apply because VNet integration is outbound-only. - Source: entries/2026/03/11/functions-networking.md - Source hash: 1cfbb950bb236d1d - Date: 2026-03-11 ### functions-premium-dedicated-subnet-size-24-windows-26-linux [IN] OBSERVATION 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 - Source: entries/2026/03/11/functions-networking.md - Source hash: 1cfbb950bb236d1d - Date: 2026-03-11 ### functions-premium-dedicated-subnet-sizes [IN] OBSERVATION Azure Functions Premium/Dedicated plans: each instance consumes 1 IP (can temporarily double during scaling); recommended subnet /24 for Windows, /26 for Linux. - Source: entries/2026/03/11/functions-networking.md - Source hash: 1cfbb950bb236d1d - Date: 2026-03-11 ### functions-python-requires-linux [IN] OBSERVATION Azure Functions Python runtime requires Linux — no Windows support. - Source: entries/2026/03/11/functions-hosting.md - Source hash: a9c0e18cd66aa42e - Date: 2026-03-11 ### functions-three-main-hosting-plans [IN] OBSERVATION 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) - Source: entries/2026/03/11/functions-overview.md - Source hash: 96a4ec1329f9cca9 - Date: 2026-03-11 ### functions-virtual-network-triggers-require-runtime-scale-monitoring [IN] OBSERVATION Non-HTTP virtual network triggers on Azure Functions require Flex Consumption or Premium plan with Runtime Scale Monitoring enabled for dynamic scaling. - Source: entries/2026/03/11/functions-networking.md - Source hash: 1cfbb950bb236d1d - Date: 2026-03-11 ### functions-vnet-not-available-consumption [IN] OBSERVATION Azure Functions VNet integration is NOT available on the Consumption plan; it is available on Flex Consumption, Premium, Dedicated, and Container Apps plans. - Source: entries/2026/03/11/functions-hosting.md - Source hash: a9c0e18cd66aa42e - Date: 2026-03-11 ### functions-vnet-not-available-consumption-plan [IN] OBSERVATION Azure Functions VNet integration is NOT available on the Consumption plan; it is available on Flex Consumption, Premium, Dedicated, and Container Apps. - Source: entries/2026/03/11/functions-hosting.md - Source hash: a9c0e18cd66aa42e - Date: 2026-03-11 ### gateway-subnet-required-for-vpn-gateway [IN] OBSERVATION A dedicated GatewaySubnet is required within the VNet for VPN gateway deployments. - Source: entries/2026/03/11/vnet-subnets.md - Source hash: d70de809fbdd3d75 - Date: 2026-03-11 ### hpa-effective-update-interval-60s [IN] OBSERVATION 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. - Source: entries/2026/03/10/aks-scaling.md - Source hash: efeece6890d5beba - Date: 2026-03-10 ### hpa-no-scale-up-delay-since-1-12 [IN] OBSERVATION HPA has no delay for scale-up events since Kubernetes 1.12; the default scale-down cooldown is 5 minutes. - Source: entries/2026/03/11/aks-scaling.md - Source hash: 702f7cac1d8bd152 - Date: 2026-03-11 ### hpa-no-scale-up-delay-since-k8s-1-12 [IN] OBSERVATION HPA has no delay for scale-up events since Kubernetes 1.12; default scale-down delay is 5 minutes. - Source: entries/2026/03/11/aks-scaling.md - Source hash: 702f7cac1d8bd152 - Date: 2026-03-11 ### hpa-scale-down-cooldown-5min [IN] OBSERVATION HPA default scale-down delay is 5 minutes; there is no delay for scale-up events since Kubernetes 1.12. - Source: entries/2026/03/10/aks-scaling.md - Source hash: efeece6890d5beba - Date: 2026-03-10 ### k8s-not-safe-hostile-multitenant [IN] OBSERVATION 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. - Source: entries/2026/03/10/aks-security.md - Source hash: 9e88c3c016f40527 - Date: 2026-03-10 ### k8s-pv-pvc-binding-one-to-one [IN] OBSERVATION Kubernetes persistent volume (PV) to persistent volume claim (PVC) binding is 1:1 — each PVC binds to exactly one PV. - Source: entries/2026/03/10/aks-storage.md - Source hash: 2e3c2adbaaad9035 - Date: 2026-03-11 ### k8s-secret-base64-not-encryption [IN] OBSERVATION Kubernetes Secret manifest files contain data in base64 format (encoding, not encryption) and should never be committed to source control. - Source: entries/2026/03/10/aks-security.md - Source hash: 9e88c3c016f40527 - Date: 2026-03-11 ### k8s-secret-volumes-use-tmpfs [IN] OBSERVATION Kubernetes secret volumes use tmpfs and are never written to disk; they are namespace-scoped - Source: entries/2026/03/10/aks-storage.md - Source hash: 2e3c2adbaaad9035 - Date: 2026-03-10 ### k8s-secrets-tmpfs-namespace-scoped [IN] OBSERVATION Kubernetes Secrets are stored in tmpfs (not written to disk), are namespace-scoped, and are deleted when the last requiring pod is removed. - Source: entries/2026/03/10/aks-security.md - Source hash: 9e88c3c016f40527 - Date: 2026-03-10 ### keda-uses-scaledobject-crd [IN] OBSERVATION KEDA uses a CRD called ScaledObject and scales based on event count rather than resource utilization metrics. - Source: entries/2026/03/10/aks-scaling.md - Source hash: efeece6890d5beba - Date: 2026-03-10 ### keyvault-best-practice-one-vault-per-app [IN] OBSERVATION Best practice is one Key Vault per application per environment (Dev, Pre-Prod, Prod) to reduce blast radius. - Source: entries/2026/03/11/keyvault-overview.md - Source hash: a30c6d1fe11088da - Date: 2026-03-11 ### keyvault-cert-access-control-separate [IN] OBSERVATION Access control for Key Vault certificates is separate from access control for keys and secrets in the same vault. - Source: entries/2026/03/11/keyvault-certificates.md - Source hash: 8d74a28114d5d769 - Date: 2026-03-11 ### keyvault-cert-creates-key-and-secret [IN] OBSERVATION Creating a Key Vault certificate automatically creates an addressable key and an addressable secret with the same name. - Source: entries/2026/03/11/keyvault-certificates.md - Source hash: 8d74a28114d5d769 - Date: 2026-03-11 ### keyvault-cert-issuer-vault-scoped [IN] OBSERVATION Certificate issuer objects in Key Vault are vault-scoped and cannot be shared across vaults. - Source: entries/2026/03/11/keyvault-certificates.md - Source hash: 8d74a28114d5d769 - Date: 2026-03-11 ### keyvault-certificates-as-certificate-objects [IN] OBSERVATION Certificates should be stored as Key Vault certificate objects (not secrets) to enable autorotation - Source: entries/2026/03/11/keyvault-best-practices.md - Source hash: 9728058a03e5fdc2 - Date: 2026-03-11 ### keyvault-certificates-as-certificate-objects-not-secrets [IN] OBSERVATION Certificates should be stored as Key Vault certificate objects (not secrets) to enable autorotation - Source: entries/2026/03/11/keyvault-best-practices.md - Source hash: 9728058a03e5fdc2 - Date: 2026-03-11 ### keyvault-certificates-store-as-certificate-objects [IN] OBSERVATION Certificates should be stored as Key Vault certificate objects (not secrets) to enable autorotation. - Source: entries/2026/03/11/keyvault-best-practices.md - Source hash: 9728058a03e5fdc2 - Date: 2026-03-11 ### keyvault-contributor-no-data-access [IN] OBSERVATION Key Vault Contributor role is control plane only and does NOT grant access to keys, secrets, or certificates. - Source: entries/2026/03/11/keyvault-rbac.md - Source hash: 4f4dc086f18c4560 - Date: 2026-03-11 ### keyvault-control-plane-endpoint [IN] OBSERVATION Key Vault control plane endpoint is `management.azure.com:443`; data plane endpoint is `.vault.azure.net:443`. - Source: entries/2026/03/11/keyvault-rbac.md - Source hash: 4f4dc086f18c4560 - Date: 2026-03-11 ### keyvault-crypto-user-cannot-delete-keys [IN] OBSERVATION Key Vault Crypto User role can create new keys but cannot delete them - Source: entries/2026/03/11/keyvault-basic-concepts.md - Source hash: 92d17342f4ee0c84 - Date: 2026-03-11 ### keyvault-crypto-user-create-not-delete [IN] OBSERVATION Key Vault Crypto User role can create new keys but cannot delete them. - Source: entries/2026/03/11/keyvault-basic-concepts.md - Source hash: 92d17342f4ee0c84 - Date: 2026-03-11 ### keyvault-custom-roles-use-dataactions [IN] OBSERVATION Custom roles for Key Vault data plane operations use `DataActions` (not `Actions`). - Source: entries/2026/03/11/keyvault-rbac.md - Source hash: 4f4dc086f18c4560 - Date: 2026-03-11 ### keyvault-data-access-admin-cannot-change-permission-model [IN] OBSERVATION 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). - Source: entries/2026/03/11/keyvault-rbac.md - Source hash: 4f4dc086f18c4560 - Date: 2026-03-11 ### keyvault-data-plane-multitenant [IN] OBSERVATION The Key Vault data plane is multitenant — multiple customer vaults can share the same public IP address. - Source: entries/2026/03/11/keyvault-security.md - Source hash: 95dc2cd1abc3fa8c - Date: 2026-03-11 ### keyvault-data-plane-multitenant-shared-ip [IN] OBSERVATION The Key Vault data plane is multitenant — multiple customer vaults can share the same public IP address. - Source: entries/2026/03/11/keyvault-security.md - Source hash: 95dc2cd1abc3fa8c - Date: 2026-03-11 ### keyvault-defense-in-depth-key-lifecycle [IN] OBSERVATION 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. ### keyvault-encryption-leaf-key-per-vault-root-per-world [IN] OBSERVATION 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. - Source: entries/2026/03/11/keyvault-secrets.md - Source hash: 1c111a4773efed1b - Date: 2026-03-11 ### keyvault-encryption-leaf-key-unique-per-vault [IN] OBSERVATION The encryption leaf key for secrets at rest is unique per key vault; the root key is unique per security world. - Source: entries/2026/03/11/keyvault-secrets.md - Source hash: 1c111a4773efed1b - Date: 2026-03-11 ### keyvault-expired-certs-retrievable-but-inoperable [IN] OBSERVATION Expired certificates can still be retrieved from Key Vault but may fail TLS validation. - Source: entries/2026/03/11/keyvault-certificates.md - Source hash: 8d74a28114d5d769 - Date: 2026-03-11 ### keyvault-ha-auto-replication-secondary-region [IN] OBSERVATION Key Vault contents are automatically replicated within a region and to a secondary region with automatic failover requiring no admin action. - Source: entries/2026/03/11/keyvault-overview.md - Source hash: a30c6d1fe11088da - Date: 2026-03-11 ### keyvault-hsm-keys-always-non-exportable [IN] OBSERVATION HSM-protected keys in Key Vault are always non-exportable; only RSA and EC key types support exportable private keys. - Source: entries/2026/03/11/keyvault-certificates.md - Source hash: 8d74a28114d5d769 - Date: 2026-03-11 ### keyvault-hsm-platform-2-fips-140-3-level-3 [IN] OBSERVATION Key Vault HSM Platform 2 protects keys at FIPS 140-3 Level 3; all new keys and key versions use HSM Platform 2. - Source: entries/2026/03/11/keyvault-keys.md - Source hash: b6f0399ca9967f2a - Date: 2026-03-11 ### keyvault-keys-json-web-key-format [IN] OBSERVATION Key Vault keys are represented as JSON Web Key (JWK) objects following JOSE specifications. - Source: entries/2026/03/11/keyvault-keys.md - Source hash: b6f0399ca9967f2a - Date: 2026-03-11 ### keyvault-layered-deletion-protection [IN] OBSERVATION 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). ### keyvault-legacy-access-policies-lack-pim-support [IN] OBSERVATION Legacy Key Vault access policies have known vulnerabilities and lack PIM (Privileged Identity Management) support; Azure RBAC is preferred. - Source: entries/2026/03/11/keyvault-security.md - Source hash: 95dc2cd1abc3fa8c - Date: 2026-03-11 ### keyvault-managed-hsm-fips-140-2-level-3 [IN] OBSERVATION Azure Key Vault managed HSM pools are validated at FIPS 140-2 Level 3; standard vaults use FIPS 140 validated HSMs at lower levels. - Source: entries/2026/03/11/keyvault-basic-concepts.md - Source hash: 92d17342f4ee0c84 - Date: 2026-03-11 ### keyvault-managed-hsm-single-tenant [IN] OBSERVATION Managed HSM pools are single-tenant with isolated security domains, while standard vaults are multi-tenant. - Source: entries/2026/03/11/keyvault-keys.md - Source hash: b6f0399ca9967f2a - Date: 2026-03-11 ### keyvault-microsoft-never-sees-keys [IN] OBSERVATION Azure Key Vault is designed so Microsoft cannot see or extract customer keys. - Source: entries/2026/03/11/keyvault-basic-concepts.md - Source hash: 92d17342f4ee0c84 - Date: 2026-03-11 ### keyvault-not-a-data-store [IN] OBSERVATION Key Vault is not a data store — customer configurations, service configs, and general content should use Azure Storage or Cosmos DB instead. - Source: entries/2026/03/11/keyvault-security.md - Source hash: 95dc2cd1abc3fa8c - Date: 2026-03-11 ### keyvault-object-scope-rbac-read-only [IN] OBSERVATION Object-scope RBAC assignments in Key Vault only support read operations; administrative operations require vault-level permissions. - Source: entries/2026/03/11/keyvault-best-practices.md - Source hash: 9728058a03e5fdc2 - Date: 2026-03-11 ### keyvault-one-vault-per-app-region-env [IN] OBSERVATION Key Vault best practice is one vault per application, region, and environment to reduce blast radius of security events - Source: entries/2026/03/11/keyvault-best-practices.md - Source hash: 9728058a03e5fdc2 - Date: 2026-03-11 ### keyvault-one-vault-per-app-region-environment [IN] OBSERVATION Best practice is one Key Vault per application, per region, per environment to reduce blast radius of security events. - Source: entries/2026/03/11/keyvault-best-practices.md - Source hash: 9728058a03e5fdc2 - Date: 2026-03-11 ### keyvault-partnered-issuers-digicert-globalsign [IN] OBSERVATION Only DigiCert and GlobalSign are partnered certificate issuers in Key Vault supporting automatic TLS/SSL certificate issuance and renewal. - Source: entries/2026/03/11/keyvault-certificates.md - Source hash: 8d74a28114d5d769 - Date: 2026-03-11 ### keyvault-premium-fips-140-3-level-3 [IN] OBSERVATION Azure Key Vault Premium tier uses HSM-protected keys (Marvell LiquidSecurity HSMs) validated to FIPS 140-3 Level 3. - Source: entries/2026/03/11/keyvault-overview.md - Source hash: a30c6d1fe11088da - Date: 2026-03-11 ### keyvault-premium-hsm-key-types [IN] OBSERVATION Premium HSM key types are RSA-HSM, EC-HSM, and OCT-HSM; these keys never leave the HSM boundary. - Source: entries/2026/03/11/keyvault-overview.md - Source hash: a30c6d1fe11088da - Date: 2026-03-11 ### keyvault-premium-sku-required-for-hsm-keys [IN] OBSERVATION Key Vault Premium SKU is required for HSM-protected keys in vaults; Standard SKU supports only software-protected keys. - Source: entries/2026/03/11/keyvault-keys.md - Source hash: b6f0399ca9967f2a - Date: 2026-03-11 ### keyvault-private-endpoint-key-lifecycle-isolation [IN] OBSERVATION 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. ### keyvault-purge-distinct-from-delete [IN] OBSERVATION The `purge` permission is a privileged operation distinct from `delete`; purge permanently removes a soft-deleted secret. - Source: entries/2026/03/11/keyvault-secrets.md - Source hash: 1c111a4773efed1b - Date: 2026-03-11 ### keyvault-purge-privileged-operation [IN] OBSERVATION The `purge` permission (permanent deletion of soft-deleted secrets) is a privileged operation distinct from `delete`. - Source: entries/2026/03/11/keyvault-secrets.md - Source hash: 1c111a4773efed1b - Date: 2026-03-11 ### keyvault-purge-protection-not-default-requires-soft-delete [IN] OBSERVATION Key Vault purge protection is not enabled by default, requires soft-delete to be enabled first, and prevents purging until the retention period expires. - Source: entries/2026/03/11/keyvault-soft-delete.md - Source hash: c76076ec5e4f0a9b - Date: 2026-03-11 ### keyvault-purge-protection-prevents-permanent-deletion [IN] OBSERVATION Key Vault purge protection prevents permanent deletion of soft-deleted objects even after soft delete is enabled. - Source: entries/2026/03/11/keyvault-security.md - Source hash: 95dc2cd1abc3fa8c - Date: 2026-03-11 ### keyvault-purge-requires-purge-operator-or-owner [IN] OBSERVATION Purging a Key Vault requires the "Key Vault Purge Operator" built-in role or subscription owner privileges. - Source: entries/2026/03/11/keyvault-soft-delete.md - Source hash: c76076ec5e4f0a9b - Date: 2026-03-11 ### keyvault-purge-requires-purge-operator-or-sub-owner [IN] OBSERVATION Purging a Key Vault requires the "Key Vault Purge Operator" built-in role or subscription owner privileges. - Source: entries/2026/03/11/keyvault-soft-delete.md - Source hash: c76076ec5e4f0a9b - Date: 2026-03-11 ### keyvault-rbac-not-for-managed-hsm [IN] OBSERVATION Key Vault RBAC applies only to vaults, not managed HSMs; managed HSMs have their own access control model. - Source: entries/2026/03/11/keyvault-rbac.md - Source hash: 4f4dc086f18c4560 - Date: 2026-03-11 ### keyvault-rbac-object-scope-read-only [IN] OBSERVATION RBAC object-scope assignments on Key Vault only support read operations; administrative operations require vault-level permissions. - Source: entries/2026/03/11/keyvault-security.md - Source hash: 95dc2cd1abc3fa8c - Date: 2026-03-11 ### keyvault-rbac-over-access-policies [IN] OBSERVATION Legacy Key Vault access policies have known security vulnerabilities and lack PIM support; Azure RBAC is the recommended permission model - Source: entries/2026/03/11/keyvault-best-practices.md - Source hash: 9728058a03e5fdc2 - Date: 2026-03-11 ### keyvault-rbac-preferred-over-access-policies [IN] OBSERVATION Azure RBAC is preferred over legacy vault access policies for Key Vault; legacy policies have known vulnerabilities and lack PIM support. - Source: entries/2026/03/11/keyvault-security.md - Source hash: 95dc2cd1abc3fa8c - Date: 2026-03-11 ### keyvault-rbac-preferred-over-legacy-access-policies [IN] OBSERVATION Azure RBAC is preferred over legacy vault access policies for Key Vault; legacy policies have known vulnerabilities and lack PIM support. - Source: entries/2026/03/11/keyvault-security.md - Source hash: 95dc2cd1abc3fa8c - Date: 2026-03-11 ### keyvault-rbac-recommended-over-access-policies [IN] OBSERVATION Azure RBAC is the recommended Key Vault permission model; legacy access policies have known security vulnerabilities and lack PIM support. - Source: entries/2026/03/11/keyvault-best-practices.md - Source hash: 9728058a03e5fdc2 - Date: 2026-03-11 ### keyvault-rbac-switch-invalidates-access-policies [IN] OBSERVATION Switching to Azure RBAC permission model immediately invalidates all existing Key Vault access policies. - Source: entries/2026/03/11/keyvault-rbac.md - Source hash: 4f4dc086f18c4560 - Date: 2026-03-11 ### keyvault-recovery-does-not-restore-rbac-or-eventgrid [IN] OBSERVATION Recovering a soft-deleted Key Vault does not restore Azure RBAC role assignments or Event Grid subscriptions — these must be manually recreated. - Source: entries/2026/03/11/keyvault-soft-delete.md - Source hash: c76076ec5e4f0a9b - Date: 2026-03-11 ### keyvault-recovery-no-rbac-no-eventgrid [IN] OBSERVATION Recovering a soft-deleted Key Vault does not restore Azure RBAC role assignments or Event Grid subscriptions; these must be manually recreated. - Source: entries/2026/03/11/keyvault-soft-delete.md - Source hash: c76076ec5e4f0a9b - Date: 2026-03-11 ### keyvault-secret-access-control-per-vault [IN] OBSERVATION Key Vault secret access control is per-vault (not per-secret) and is separate from key access control within the same vault. - Source: entries/2026/03/11/keyvault-secrets.md - Source hash: 1c111a4773efed1b - Date: 2026-03-11 ### keyvault-secret-access-control-per-vault-separate-from-keys [IN] OBSERVATION Key Vault secret access control is per-vault (not per-secret) and is separate from key access control within the same vault. - Source: entries/2026/03/11/keyvault-secrets.md - Source hash: 1c111a4773efed1b - Date: 2026-03-11 ### keyvault-secret-contenttype-255-chars-no-predefined [IN] OBSERVATION The Key Vault secret `contentType` field is optional, max 255 characters, with no predefined values — it serves as a hint for interpreting secret data. - Source: entries/2026/03/11/keyvault-secrets.md - Source hash: 1c111a4773efed1b - Date: 2026-03-11 ### keyvault-secret-contenttype-max-255-chars [IN] OBSERVATION The Key Vault secret `contentType` field is an optional hint with a maximum length of 255 characters and no predefined values. - Source: entries/2026/03/11/keyvault-secrets.md - Source hash: 1c111a4773efed1b - Date: 2026-03-11 ### keyvault-secret-encryption-leaf-key-per-vault-root-per-world [IN] OBSERVATION 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. - Source: entries/2026/03/11/keyvault-secrets.md - Source hash: 1c111a4773efed1b - Date: 2026-03-11 ### keyvault-secret-get-works-expired-and-not-yet-valid [IN] OBSERVATION The `get` operation works on expired and not-yet-valid secrets, as an exception to the `nbf`/`exp` date-time controls. - Source: entries/2026/03/11/keyvault-secrets.md - Source hash: 1c111a4773efed1b - Date: 2026-03-11 ### keyvault-secret-get-works-on-expired [IN] OBSERVATION The `get` operation works on expired and not-yet-valid secrets, as an exception to the normal date-time controls. - Source: entries/2026/03/11/keyvault-secrets.md - Source hash: 1c111a4773efed1b - Date: 2026-03-11 ### keyvault-secret-get-works-on-expired-and-not-yet-valid [IN] OBSERVATION The `get` operation works on expired and not-yet-valid secrets, as an exception to the `nbf`/`exp` date-time controls. - Source: entries/2026/03/11/keyvault-secrets.md - Source hash: 1c111a4773efed1b - Date: 2026-03-11 ### keyvault-secret-max-15-tags [IN] OBSERVATION 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. - Source: entries/2026/03/11/keyvault-secrets.md - Source hash: 1c111a4773efed1b - Date: 2026-03-11 ### keyvault-secret-max-size-25kb [IN] OBSERVATION Azure Key Vault secrets have a maximum size of 25 KB per secret. - Source: entries/2026/03/11/keyvault-secrets.md - Source hash: 1c111a4773efed1b - Date: 2026-03-11 ### keyvault-secret-permissive-read-model [IN] OBSERVATION 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. ### keyvault-secured-by-perimeter-overrides-trusted-services [IN] OBSERVATION Setting Key Vault `publicNetworkAccess: SecuredByPerimeter` overrides the "Allow trusted Microsoft services" firewall bypass. - Source: entries/2026/03/11/keyvault-best-practices.md - Source hash: 9728058a03e5fdc2 - Date: 2026-03-11 ### keyvault-soft-delete-enabled-by-default-cannot-disable [IN] OBSERVATION Azure Key Vault soft-delete is enabled by default on new vaults and cannot be disabled once enabled. - Source: entries/2026/03/11/keyvault-soft-delete.md - Source hash: c76076ec5e4f0a9b - Date: 2026-03-11 ### keyvault-soft-delete-retention-7-90-days [IN] OBSERVATION Key Vault soft delete retention period is 7–90 days; purge protection adds a second layer preventing permanent deletion even after soft delete - Source: entries/2026/03/11/keyvault-best-practices.md - Source hash: 9728058a03e5fdc2 - Date: 2026-03-11 ### keyvault-soft-delete-retention-7-90-days-default-90 [IN] OBSERVATION 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. - Source: entries/2026/03/11/keyvault-soft-delete.md - Source hash: c76076ec5e4f0a9b - Date: 2026-03-11 ### keyvault-soft-delete-retention-7-90-days-default-90-immutable [IN] OBSERVATION Key Vault soft-delete retention period is configurable from 7–90 days (default 90), set at vault creation time, and cannot be changed afterward. - Source: entries/2026/03/11/keyvault-soft-delete.md - Source hash: c76076ec5e4f0a9b - Date: 2026-03-11 ### keyvault-soft-delete-retention-7-to-90-days [IN] OBSERVATION Key Vault soft delete recovers deleted objects within a 7–90 day retention period; purge protection prevents permanent deletion even after soft delete. - Source: entries/2026/03/11/keyvault-best-practices.md - Source hash: 9728058a03e5fdc2 - Date: 2026-03-11 ### keyvault-soft-delete-retention-7-to-90-days-default-90-immutable [IN] OBSERVATION 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. - Source: entries/2026/03/11/keyvault-soft-delete.md - Source hash: c76076ec5e4f0a9b - Date: 2026-03-11 ### keyvault-soft-deleted-name-cannot-be-reused [IN] OBSERVATION A soft-deleted vault's name (and object names within a vault) cannot be reused until the retention period expires. - Source: entries/2026/03/11/keyvault-soft-delete.md - Source hash: c76076ec5e4f0a9b - Date: 2026-03-11 ### keyvault-soft-deleted-name-cannot-reuse [IN] OBSERVATION A soft-deleted vault's name cannot be reused until the retention period expires; same restriction applies to objects within a vault. - Source: entries/2026/03/11/keyvault-soft-delete.md - Source hash: c76076ec5e4f0a9b - Date: 2026-03-11 ### keyvault-soft-deleted-objects-only-purge-or-recover [IN] OBSERVATION Only two operations are possible on soft-deleted Key Vault objects: purge and recover. - Source: entries/2026/03/11/keyvault-soft-delete.md - Source hash: c76076ec5e4f0a9b - Date: 2026-03-11 ### keyvault-soft-deleted-objects-two-operations [IN] OBSERVATION Only two operations are possible on soft-deleted Key Vault objects: purge and recover. - Source: entries/2026/03/11/keyvault-soft-delete.md - Source hash: c76076ec5e4f0a9b - Date: 2026-03-11 ### keyvault-software-keys-fips-140-2-level-1 [IN] OBSERVATION Software-protected keys in Key Vault are validated at FIPS 140-2 Level 1 and are only available in vaults (not Managed HSM). - Source: entries/2026/03/11/keyvault-keys.md - Source hash: b6f0399ca9967f2a - Date: 2026-03-11 ### keyvault-standard-fips-140-level-1 [IN] OBSERVATION Azure Key Vault Standard tier uses software-protected keys validated to FIPS 140 Level 1. - Source: entries/2026/03/11/keyvault-overview.md - Source hash: a30c6d1fe11088da - Date: 2026-03-11 ### keyvault-supports-tls-12-and-13 [IN] OBSERVATION Azure Key Vault supports TLS 1.2 and TLS 1.3; clients can enforce TLS version during negotiation. - Source: entries/2026/03/11/keyvault-security.md - Source hash: 95dc2cd1abc3fa8c - Date: 2026-03-11 ### keyvault-symmetric-keys-managed-hsm-only [IN] OBSERVATION Symmetric keys (oct-HSM: 128, 192, 256-bit) are only supported in Managed HSMs, not in standard vaults. - Source: entries/2026/03/11/keyvault-keys.md - Source hash: b6f0399ca9967f2a - Date: 2026-03-11 ### keyvault-three-auth-methods-managed-identity-recommended [IN] OBSERVATION 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). - Source: entries/2026/03/11/keyvault-basic-concepts.md - Source hash: 92d17342f4ee0c84 - Date: 2026-03-11 ### keyvault-three-auth-methods-ranked [IN] OBSERVATION 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) - Source: entries/2026/03/11/keyvault-basic-concepts.md - Source hash: 92d17342f4ee0c84 - Date: 2026-03-11 ### keyvault-tiered-key-protection-model [IN] OBSERVATION 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. ### keyvault-tls-12-and-13 [IN] OBSERVATION Azure Key Vault supports TLS 1.2 and 1.3; clients can enforce TLS version during negotiation. - Source: entries/2026/03/11/keyvault-security.md - Source hash: 95dc2cd1abc3fa8c - Date: 2026-03-11 ### keyvault-two-authorization-models [IN] OBSERVATION Key Vault has two authorization models: Azure RBAC (management + data plane) and Key Vault access policies (data plane only, legacy). - Source: entries/2026/03/11/keyvault-overview.md - Source hash: a30c6d1fe11088da - Date: 2026-03-11 ### keyvault-two-container-types [IN] OBSERVATION Azure Key Vault has two container types: vaults (keys, secrets, certificates) and managed HSM pools (HSM-backed keys only). - Source: entries/2026/03/11/keyvault-basic-concepts.md - Source hash: 92d17342f4ee0c84 - Date: 2026-03-11 ### kv-administrator-role-full-data-no-management [IN] OBSERVATION Key Vault Administrator role provides full data plane access (keys, secrets, certificates) but cannot manage the vault resource itself or manage role assignments. - Source: entries/2026/03/11/keyvault-rbac.md - Source hash: 4f4dc086f18c4560 - Date: 2026-03-11 ### kv-auth-entra-authz-rbac-or-access-policy [IN] OBSERVATION Key Vault authenticates via Microsoft Entra ID; authorization uses either Azure RBAC (management + data plane) or Key Vault access policy (data plane only). - Source: entries/2026/03/11/keyvault-overview.md - Source hash: a30c6d1fe11088da - Date: 2026-03-11 ### kv-best-practice-one-vault-per-app [IN] OBSERVATION Best practice is to create one Key Vault per application per environment (Dev, Pre-Prod, Prod) to segregate secrets. - Source: entries/2026/03/11/keyvault-overview.md - Source hash: a30c6d1fe11088da - Date: 2026-03-11 ### kv-cert-access-control-separate [IN] OBSERVATION Certificate access control policies in Key Vault are distinct from key and secret access control policies within the same vault. - Source: entries/2026/03/11/keyvault-certificates.md - Source hash: 8d74a28114d5d769 - Date: 2026-03-11 ### kv-cert-contacts-shared-across-vault [IN] OBSERVATION Certificate contacts in Key Vault are shared across all certificates in the vault. - Source: entries/2026/03/11/keyvault-certificates.md - Source hash: 8d74a28114d5d769 - Date: 2026-03-11 ### kv-cert-creates-key-and-secret [IN] OBSERVATION Creating a Key Vault certificate automatically creates an addressable key and an addressable secret with the same name. - Source: entries/2026/03/11/keyvault-certificates.md - Source hash: 8d74a28114d5d769 - Date: 2026-03-11 ### kv-cert-default-key-operations [IN] OBSERVATION When no X.509 key usage is specified, Key Vault certificate default key operations are sign, verify, wrapKey, and unwrapKey. - Source: entries/2026/03/11/keyvault-certificates.md - Source hash: 8d74a28114d5d769 - Date: 2026-03-11 ### kv-cert-default-key-ops [IN] OBSERVATION Default Key Vault key operations when no X.509 key usage is specified are sign, verify, wrapKey, and unwrapKey. - Source: entries/2026/03/11/keyvault-certificates.md - Source hash: 8d74a28114d5d769 - Date: 2026-03-11 ### kv-cert-issuer-vault-scoped [IN] OBSERVATION Certificate issuer objects in Key Vault are vault-scoped and cannot be shared across vaults. - Source: entries/2026/03/11/keyvault-certificates.md - Source hash: 8d74a28114d5d769 - Date: 2026-03-11 ### kv-cert-lifetime-actions-two-triggers-two-actions [IN] OBSERVATION Key Vault certificate lifetime actions support two triggers (days before expiry, lifetime percentage) and two actions (emailContacts, autoRenew). - Source: entries/2026/03/11/keyvault-certificates.md - Source hash: 8d74a28114d5d769 - Date: 2026-03-11 ### kv-cert-partnered-issuers-digicert-globalsign [IN] OBSERVATION Only DigiCert and GlobalSign are partnered certificate issuers in Key Vault, supporting automatic TLS/SSL certificate issuance and renewal. - Source: entries/2026/03/11/keyvault-certificates.md - Source hash: 8d74a28114d5d769 - Date: 2026-03-11 ### kv-contributor-control-plane-only [IN] OBSERVATION Key Vault Contributor role is control plane only — it does NOT grant access to keys, secrets, or certificates. - Source: entries/2026/03/11/keyvault-rbac.md - Source hash: 4f4dc086f18c4560 - Date: 2026-03-11 ### kv-contributor-no-data-access [IN] OBSERVATION Key Vault Contributor role is control plane only and does NOT grant access to keys, secrets, or certificates. - Source: entries/2026/03/11/keyvault-rbac.md - Source hash: 4f4dc086f18c4560 - Date: 2026-03-11 ### kv-control-plane-endpoint-management-azure [IN] OBSERVATION Key Vault control plane endpoint is management.azure.com:443; data plane endpoint is {vault-name}.vault.azure.net:443. - Source: entries/2026/03/11/keyvault-rbac.md - Source hash: 4f4dc086f18c4560 - Date: 2026-03-11 ### kv-control-plane-endpoint-management-azure-com [IN] OBSERVATION Key Vault control plane endpoint is `management.azure.com:443`; data plane endpoint is `.vault.azure.net:443`. - Source: entries/2026/03/11/keyvault-rbac.md - Source hash: 4f4dc086f18c4560 - Date: 2026-03-11 ### kv-custom-roles-use-dataactions [IN] OBSERVATION Custom roles for Key Vault data plane operations use `DataActions` (not `Actions`). - Source: entries/2026/03/11/keyvault-rbac.md - Source hash: 4f4dc086f18c4560 - Date: 2026-03-11 ### kv-ec-curves-p256-p384-p521-secp256k1 [IN] OBSERVATION Key Vault supports EC curves P-256, P-384, P-521, and secp256k1 (P-256K). - Source: entries/2026/03/11/keyvault-keys.md - Source hash: b6f0399ca9967f2a - Date: 2026-03-11 ### kv-fips-compliance-levels [IN] OBSERVATION 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. - Source: entries/2026/03/11/keyvault-keys.md - Source hash: b6f0399ca9967f2a - Date: 2026-03-11 ### kv-ha-auto-replication-secondary-region [IN] OBSERVATION Key Vault contents are automatically replicated within a region and to a secondary region; failover is automatic with no admin action required. - Source: entries/2026/03/11/keyvault-overview.md - Source hash: a30c6d1fe11088da - Date: 2026-03-11 ### kv-ha-automatic-secondary-region-replication [IN] OBSERVATION Key Vault contents are automatically replicated within a region and to a secondary region; failover is automatic with no admin action needed. - Source: entries/2026/03/11/keyvault-overview.md - Source hash: a30c6d1fe11088da - Date: 2026-03-11 ### kv-hsm-keys-always-non-exportable [IN] OBSERVATION HSM-protected keys in Key Vault are always non-exportable; only RSA and EC key types support exportable private keys. - Source: entries/2026/03/11/keyvault-certificates.md - Source hash: 8d74a28114d5d769 - Date: 2026-03-11 ### kv-hsm-platform-2-all-new-keys [IN] OBSERVATION All new key versions in Key Vault are created on HSM Platform 2 (FIPS 140-3 Level 3). - Source: entries/2026/03/11/keyvault-keys.md - Source hash: b6f0399ca9967f2a - Date: 2026-03-11 ### kv-hsm-platform-2-fips-140-3-level-3 [IN] OBSERVATION 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. - Source: entries/2026/03/11/keyvault-keys.md - Source hash: b6f0399ca9967f2a - Date: 2026-03-11 ### kv-keys-jwk-representation [IN] OBSERVATION Key Vault keys are represented as JSON Web Key (JWK) objects following JOSE specifications. - Source: entries/2026/03/11/keyvault-keys.md - Source hash: b6f0399ca9967f2a - Date: 2026-03-11 ### kv-managed-hsm-single-tenant-isolated [IN] OBSERVATION Managed HSM pools are single-tenant with isolated security domains, separate from Key Vault vaults. - Source: entries/2026/03/11/keyvault-keys.md - Source hash: b6f0399ca9967f2a - Date: 2026-03-11 ### kv-managed-hsm-supports-symmetric-keys [IN] OBSERVATION Managed HSMs support symmetric keys (oct-HSM: 128, 192, 256-bit); standard Key Vault vaults do not support symmetric keys. - Source: entries/2026/03/11/keyvault-keys.md - Source hash: b6f0399ca9967f2a - Date: 2026-03-11 ### kv-object-scope-rbac-cannot-isolate-teams [IN] OBSERVATION Object-scope RBAC in Key Vault cannot fully isolate application teams within a single vault — administrative operations still require vault-level permissions. - Source: entries/2026/03/11/keyvault-rbac.md - Source hash: 4f4dc086f18c4560 - Date: 2026-03-11 ### kv-oct-hsm-256-quantum-resistant-cnsa [IN] OBSERVATION oct-HSM 256-bit keys with AES in Managed HSM are considered quantum-resistant per CNSA 2.0. - Source: entries/2026/03/11/keyvault-keys.md - Source hash: b6f0399ca9967f2a - Date: 2026-03-11 ### kv-premium-fips-140-3-level-3 [IN] OBSERVATION Key Vault Premium tier uses HSM-protected keys (Marvell LiquidSecurity HSMs) validated at FIPS 140-3 Level 3. - Source: entries/2026/03/11/keyvault-overview.md - Source hash: a30c6d1fe11088da - Date: 2026-03-11 ### kv-premium-fips-140-3-level-3-marvell [IN] OBSERVATION Key Vault Premium tier uses HSM-protected keys (Marvell LiquidSecurity HSMs) validated at FIPS 140-3 Level 3. - Source: entries/2026/03/11/keyvault-overview.md - Source hash: a30c6d1fe11088da - Date: 2026-03-11 ### kv-premium-hsm-keys-never-leave-boundary [IN] OBSERVATION Premium HSM key types (RSA-HSM, EC-HSM, OCT-HSM) never leave the HSM boundary. - Source: entries/2026/03/11/keyvault-overview.md - Source hash: a30c6d1fe11088da - Date: 2026-03-11 ### kv-rbac-applies-to-vaults-not-managed-hsm [IN] OBSERVATION Azure RBAC for Key Vault applies only to vaults; Managed HSMs have their own separate access control model. - Source: entries/2026/03/11/keyvault-rbac.md - Source hash: 4f4dc086f18c4560 - Date: 2026-03-11 ### kv-rbac-custom-roles-use-dataactions [IN] OBSERVATION Custom roles for Key Vault data plane operations use DataActions (not Actions) in the role definition. - Source: entries/2026/03/11/keyvault-rbac.md - Source hash: 4f4dc086f18c4560 - Date: 2026-03-11 ### kv-rbac-not-for-managed-hsm [IN] OBSERVATION Azure RBAC for Key Vault applies only to vaults, not to Managed HSMs, which have their own access control model. - Source: entries/2026/03/11/keyvault-rbac.md - Source hash: 4f4dc086f18c4560 - Date: 2026-03-11 ### kv-rbac-vs-access-policy-authorization [IN] OBSERVATION Key Vault supports two authorization mechanisms: Azure RBAC (management + data plane) or Key Vault access policy (data plane only). - Source: entries/2026/03/11/keyvault-overview.md - Source hash: a30c6d1fe11088da - Date: 2026-03-11 ### kv-rsa-key-sizes-2048-3072-4096 [IN] OBSERVATION Key Vault supports RSA key sizes of 2048, 3072, and 4096 bits. - Source: entries/2026/03/11/keyvault-keys.md - Source hash: b6f0399ca9967f2a - Date: 2026-03-11 ### kv-software-keys-not-in-managed-hsm [IN] OBSERVATION Software-protected keys are only available in Key Vault vaults, not in Managed HSMs. - Source: entries/2026/03/11/keyvault-keys.md - Source hash: b6f0399ca9967f2a - Date: 2026-03-11 ### kv-standard-fips-140-level-1 [IN] OBSERVATION Key Vault Standard tier uses software-protected keys validated at FIPS 140 Level 1. - Source: entries/2026/03/11/keyvault-overview.md - Source hash: a30c6d1fe11088da - Date: 2026-03-11 ### kv-switching-rbac-invalidates-access-policies [IN] OBSERVATION Switching to Azure RBAC permission model for Key Vault immediately invalidates all existing access policies. - Source: entries/2026/03/11/keyvault-rbac.md - Source hash: 4f4dc086f18c4560 - Date: 2026-03-11 ### lb-admin-state-overrides-health-probe [IN] OBSERVATION Admin State can override health probe behavior for maintenance windows on Azure Load Balancer. - Source: entries/2026/03/10/lb-overview.md - Source hash: c84c463d50802194 - Date: 2026-03-11 ### lb-backend-pool-cannot-contain-private-endpoints [IN] OBSERVATION Azure Load Balancer backend pools cannot contain Private Endpoints. - Source: entries/2026/03/11/lb-components.md - Source hash: 380735c432c279d1 - Date: 2026-03-11 ### lb-backend-pool-scoped-single-vnet [IN] OBSERVATION Azure Load Balancer backend pools are scoped to a single virtual network; rules cannot span two VNets. - Source: entries/2026/03/10/lb-components.md - Source hash: 302ec225fc410c80 - Date: 2026-03-10 ### lb-basic-health-probes-not-supported-with-vmss [IN] OBSERVATION Basic SKU Load Balancer health probes are not supported with Virtual Machine Scale Sets. - Source: entries/2026/03/10/lb-health-probes.md - Source hash: e30e33d0860ed87f - Date: 2026-03-11 ### lb-basic-no-https-probes-no-outbound-rules [IN] OBSERVATION Basic SKU Load Balancer does not support HTTPS health probes, outbound rules, or HA ports, and closes all TCP connections on probe failure. - Source: entries/2026/03/10/lb-components.md - Source hash: 302ec225fc410c80 - Date: 2026-03-10 ### lb-basic-probe-not-supported-vmss [IN] OBSERVATION Basic SKU Load Balancer health probes are not supported with Virtual Machine Scale Sets. - Source: entries/2026/03/11/lb-health-probes.md - Source hash: 82e6e26ca0d1378d - Date: 2026-03-11 ### lb-basic-probes-not-supported-with-vmss [IN] OBSERVATION Basic SKU Load Balancer health probes are not supported with Virtual Machine Scale Sets. - Source: entries/2026/03/11/lb-health-probes.md - Source hash: 82e6e26ca0d1378d - Date: 2026-03-11 ### lb-basic-sku-retired-sept-2025 [IN] OBSERVATION Azure Load Balancer Basic SKU was retired on September 30, 2025. - Source: entries/2026/03/10/lb-overview.md - Source hash: c84c463d50802194 - Date: 2026-03-10 ### lb-does-not-store-customer-data [IN] OBSERVATION Azure Load Balancer does not store customer data — it processes traffic in real-time without persistence. - Source: entries/2026/03/11/lb-overview.md - Source hash: a1be26783998b452 - Date: 2026-03-11 ### lb-ha-ports-internal-standard-only [IN] OBSERVATION HA Ports (protocol=all, port=0) are only supported on internal Standard Load Balancer, not on Basic or Public Load Balancers. - Source: entries/2026/03/10/lb-components.md - Source hash: 302ec225fc410c80 - Date: 2026-03-10 ### lb-health-probe-failure-new-connections-only [IN] OBSERVATION Health probe failure stops new connections only; existing connections persist until the flow ends, idle timeout, or VM shutdown. - Source: entries/2026/03/10/lb-components.md - Source hash: 302ec225fc410c80 - Date: 2026-03-10 ### lb-http-probe-blocked-ports [IN] OBSERVATION HTTP health probes cannot use ports 19, 21, 25, 70, 110, 119, 143, 220, or 993. - Source: entries/2026/03/11/lb-health-probes.md - Source hash: 82e6e26ca0d1378d - Date: 2026-03-11 ### lb-http-probe-fails-on-non-200 [IN] OBSERVATION HTTP/HTTPS health probes succeed only on HTTP 200; any other status code (403, 404, 500, etc.) causes probe failure. - Source: entries/2026/03/10/lb-health-probes.md - Source hash: e30e33d0860ed87f - Date: 2026-03-10 ### lb-http-probe-no-hostname-probing [IN] OBSERVATION HTTP health probes on Azure Load Balancer do not support hostname-based probing. - Source: entries/2026/03/11/lb-health-probes.md - Source hash: 82e6e26ca0d1378d - Date: 2026-03-11 ### lb-http-probe-restricted-ports [IN] OBSERVATION HTTP health probes cannot use ports 19, 21, 25, 70, 110, 119, 143, 220, or 993. - Source: entries/2026/03/11/lb-health-probes.md - Source hash: 82e6e26ca0d1378d - Date: 2026-03-11 ### lb-http-probe-threshold-immediate-on-explicit-response [IN] OBSERVATION 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. - Source: entries/2026/03/10/lb-health-probes.md - Source hash: e30e33d0860ed87f - Date: 2026-03-11 ### lb-http-probe-timeout-30-seconds [IN] OBSERVATION HTTP/HTTPS health probe timeout is 30 seconds; TCP probes have no separate timeout (use the probe interval). - Source: entries/2026/03/10/lb-health-probes.md - Source hash: e30e33d0860ed87f - Date: 2026-03-10 ### lb-https-probe-requires-sha256-no-mutual-auth [IN] OBSERVATION HTTPS health probes require certificates with minimum SHA256 signature hash in the entire chain and do not support mutual authentication with client certificates. - Source: entries/2026/03/10/lb-health-probes.md - Source hash: e30e33d0860ed87f - Date: 2026-03-10 ### lb-icmp-ip-fragmentation-not-supported [IN] OBSERVATION ICMP and IP fragmentation are not supported by Azure Load Balancer load-balancing rules. - Source: entries/2026/03/11/lb-components.md - Source hash: 380735c432c279d1 - Date: 2026-03-11 ### lb-inbound-nat-rules-no-health-probe-required [IN] OBSERVATION Inbound NAT rules do not require a health probe; only load-balancing rules require one. - Source: entries/2026/03/11/lb-health-probes.md - Source hash: 82e6e26ca0d1378d - Date: 2026-03-11 ### lb-inbound-nat-rules-no-probe-required [IN] OBSERVATION Inbound NAT rules do not require a health probe; only load balancing rules require one. - Source: entries/2026/03/11/lb-health-probes.md - Source hash: 82e6e26ca0d1378d - Date: 2026-03-11 ### lb-inbound-nat-specific-vs-rule-all [IN] OBSERVATION Inbound NAT rules forward traffic to a specific VM instance; load-balancing rules distribute to all instances in the backend pool. - Source: entries/2026/03/10/lb-components.md - Source hash: 302ec225fc410c80 - Date: 2026-03-10 ### lb-internal-frontend-never-exposed-to-internet [IN] OBSERVATION Internal Load Balancer frontend IPs are never exposed to internet endpoints; it cannot accept traffic from the internet. - Source: entries/2026/03/11/lb-components.md - Source hash: 380735c432c279d1 - Date: 2026-03-11 ### lb-internal-never-exposed-to-internet [IN] OBSERVATION Internal Load Balancer frontend IPs are never exposed to internet endpoints; it cannot accept traffic from the internet. - Source: entries/2026/03/11/lb-components.md - Source hash: 380735c432c279d1 - Date: 2026-03-11 ### lb-ip-fragmentation-not-supported [IN] OBSERVATION IP fragmentation is not supported on Azure Load Balancer rules. - Source: entries/2026/03/10/lb-components.md - Source hash: 302ec225fc410c80 - Date: 2026-03-11 ### lb-multiple-frontend-ips-supported [IN] OBSERVATION An Azure Load Balancer can have multiple frontend IP configurations. - Source: entries/2026/03/10/lb-components.md - Source hash: 302ec225fc410c80 - Date: 2026-03-11 ### lb-no-icmp-no-ip-fragmentation [IN] OBSERVATION ICMP and IP fragmentation are not supported by Azure Load Balancer load-balancing rules. - Source: entries/2026/03/11/lb-components.md - Source hash: 380735c432c279d1 - Date: 2026-03-11 ### lb-one-public-one-internal-nic-lb-per-availability-set [IN] OBSERVATION 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. - Source: entries/2026/03/11/lb-components.md - Source hash: 380735c432c279d1 - Date: 2026-03-11 ### lb-operates-at-layer-4-tcp-udp [IN] OBSERVATION Azure Load Balancer operates at Layer 4 (Transport) of the OSI model, handling TCP and UDP only — it is not application-aware. - Source: entries/2026/03/10/lb-overview.md - Source hash: c84c463d50802194 - Date: 2026-03-10 ### lb-outbound-flow-to-own-internal-frontend-fails [IN] OBSERVATION An outbound flow from a backend VM to the frontend of its own internal Load Balancer will fail. - Source: entries/2026/03/11/lb-components.md - Source hash: 380735c432c279d1 - Date: 2026-03-11 ### lb-outbound-from-backend-to-own-internal-frontend-fails [IN] OBSERVATION An outbound flow from a backend VM to the frontend of its own internal Load Balancer will fail. - Source: entries/2026/03/11/lb-components.md - Source hash: 380735c432c279d1 - Date: 2026-03-11 ### lb-outbound-to-own-internal-frontend-fails [IN] OBSERVATION An outbound flow from a backend VM to the frontend of its own internal Load Balancer will fail. - Source: entries/2026/03/11/lb-components.md - Source hash: 380735c432c279d1 - Date: 2026-03-11 ### lb-pass-through-no-tls-termination [IN] OBSERVATION Azure Load Balancer uses a pass-through architecture with no TLS termination and no proxy, enabling ultra-low latency. - Source: entries/2026/03/11/lb-overview.md - Source hash: a1be26783998b452 - Date: 2026-03-11 ### lb-passthrough-no-tls-termination [IN] OBSERVATION Azure Load Balancer uses a pass-through architecture for ultra-low latency — it does not perform TLS termination or act as a proxy. - Source: entries/2026/03/11/lb-overview.md - Source hash: a1be26783998b452 - Date: 2026-03-11 ### lb-passthrough-no-tls-termination-no-proxy [IN] OBSERVATION Azure Load Balancer uses a pass-through architecture with no TLS termination and no proxy, enabling ultra-low latency. - Source: entries/2026/03/11/lb-overview.md - Source hash: a1be26783998b452 - Date: 2026-03-11 ### lb-probe-failure-no-effect-on-outbound [IN] OBSERVATION Outbound connectivity from backend instances is not affected by health probe failure — only inbound new connections are stopped. - Source: entries/2026/03/11/lb-health-probes.md - Source hash: 82e6e26ca0d1378d - Date: 2026-03-11 ### lb-probe-outbound-unaffected [IN] OBSERVATION Health probe failure affects only inbound connectivity; outbound connectivity from backend instances remains unaffected. - Source: entries/2026/03/11/lb-health-probes.md - Source hash: 82e6e26ca0d1378d - Date: 2026-03-11 ### lb-probe-port-can-differ-from-app-port [IN] OBSERVATION The health probe port and the application port do not have to be the same on Azure Load Balancer. - Source: entries/2026/03/11/lb-health-probes.md - Source hash: 82e6e26ca0d1378d - Date: 2026-03-11 ### lb-probe-source-ip-168-63-129-16 [IN] OBSERVATION All IPv4 health probes originate from source IP 168.63.129.16; IPv6 probes use link-local address fe80::1234:5678:9abc. - Source: entries/2026/03/10/lb-health-probes.md - Source hash: e30e33d0860ed87f - Date: 2026-03-10 ### lb-public-handles-inbound-and-outbound [IN] OBSERVATION A public Azure Load Balancer handles both inbound (internet to VMs) and outbound (VMs to internet via private-to-public IP translation) connectivity. - Source: entries/2026/03/11/lb-overview.md - Source hash: a1be26783998b452 - Date: 2026-03-11 ### lb-public-lb-inbound-and-outbound-nat [IN] OBSERVATION Public load balancer handles both inbound load balancing and outbound NAT by translating private IPs to public IPs. - Source: entries/2026/03/10/lb-overview.md - Source hash: c84c463d50802194 - Date: 2026-03-11 ### lb-public-lb-provides-outbound-nat [IN] OBSERVATION Public load balancer provides outbound connectivity for VMs by translating private IPs to public IPs (SNAT). - Source: entries/2026/03/10/lb-overview.md - Source hash: c84c463d50802194 - Date: 2026-03-11 ### lb-standard-all-probes-down-tcp-continues [IN] OBSERVATION Standard LB: when all probes are down, established TCP flows continue. Basic LB: all TCP flows expire when all probes are down. - Source: entries/2026/03/10/lb-health-probes.md - Source hash: e30e33d0860ed87f - Date: 2026-03-10 ### lb-standard-built-on-zero-trust [IN] OBSERVATION Standard Azure Load Balancer is built on the Zero Trust network security model. - Source: entries/2026/03/11/lb-overview.md - Source hash: a1be26783998b452 - Date: 2026-03-11 ### lb-standard-closed-inbound-by-default [IN] OBSERVATION Standard Load Balancer and standard public IPs are closed to inbound traffic by default; NSGs must explicitly allow traffic. - Source: entries/2026/03/10/lb-overview.md - Source hash: c84c463d50802194 - Date: 2026-03-10 ### lb-standard-zero-trust-default-deny [IN] OBSERVATION 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. ### lb-stopped-vms-can-remain-in-backend-pool [IN] OBSERVATION Stopped VMs can remain in an Azure Load Balancer backend pool. - Source: entries/2026/03/11/lb-components.md - Source hash: 380735c432c279d1 - Date: 2026-03-11 ### lb-stopped-vms-not-probed [IN] OBSERVATION Stopped VMs are not probed by load balancer health probes until started again. - Source: entries/2026/03/10/lb-health-probes.md - Source hash: e30e33d0860ed87f - Date: 2026-03-11 ### lb-stopped-vms-remain-in-backend-pool [IN] OBSERVATION Stopped/deallocated VMs can remain in an Azure Load Balancer backend pool. - Source: entries/2026/03/11/lb-components.md - Source hash: 380735c432c279d1 - Date: 2026-03-11 ### lb-three-skus-basic-standard-gateway [IN] OBSERVATION Azure Load Balancer has three SKUs: Basic (retired), Standard, and Gateway. - Source: entries/2026/03/10/lb-overview.md - Source hash: c84c463d50802194 - Date: 2026-03-10 ### lb-vms-can-join-backend-pool-when-stopped [IN] OBSERVATION VMs can be added to a load balancer backend pool even when in a stopped state. - Source: entries/2026/03/10/lb-components.md - Source hash: 302ec225fc410c80 - Date: 2026-03-11 ### lb-vms-no-public-ip-needed-for-public-lb [IN] OBSERVATION VMs do not need a public IP address to be in a public load balancer's backend pool. - Source: entries/2026/03/10/lb-components.md - Source hash: 302ec225fc410c80 - Date: 2026-03-10 ### lb-zero-trust-no-customer-data-stored [IN] OBSERVATION 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. - Source: entries/2026/03/11/lb-overview.md - Source hash: a1be26783998b452 - Date: 2026-03-11 ### lb-zero-trust-security-model [IN] OBSERVATION Azure Standard Load Balancer is built on the Zero Trust network security model. - Source: entries/2026/03/11/lb-overview.md - Source hash: a1be26783998b452 - Date: 2026-03-11 ### managed-disks-only-lrs-zrs [IN] OBSERVATION Azure Managed Disks only support LRS and ZRS redundancy options. - Source: entries/2026/03/10/storage-redundancy.md - Source hash: b3f097a42931505d - Date: 2026-03-10 ### managed-disks-stored-as-page-blobs [IN] OBSERVATION Azure Managed Disks are stored as page blobs but abstract away blob, container, and storage account management. - Source: entries/2026/03/10/storage-overview.md - Source hash: 7de2f80c18a9ae0b - Date: 2026-03-10 ### managed-identity-lifecycle-tradeoff [IN] OBSERVATION 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-to-keyvault-zero-credential-pipeline [IN] OBSERVATION 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. ### mgmt-group-arm-caches-hierarchy-30-minutes [IN] OBSERVATION Azure Resource Manager caches management group hierarchy details for up to 30 minutes — portal may not immediately reflect moves. - Source: entries/2026/03/11/management-groups.md - Source hash: 4ffa2f9d19e2cc59 - Date: 2026-03-11 ### mgmt-group-hierarchy-cache-30-minutes [IN] OBSERVATION Azure Resource Manager caches management group hierarchy details for up to 30 minutes — portal may not reflect moves immediately. - Source: entries/2026/03/11/management-groups.md - Source hash: 4ffa2f9d19e2cc59 - Date: 2026-03-11 ### mgmt-group-max-10000-per-directory [IN] OBSERVATION A single Microsoft Entra directory supports up to 10,000 management groups. - Source: entries/2026/03/11/management-groups.md - Source hash: 4ffa2f9d19e2cc59 - Date: 2026-03-11 ### mgmt-group-max-6-levels-depth [IN] OBSERVATION Management group hierarchy supports up to 6 levels of depth, excluding the root management group level and the subscription level. - Source: entries/2026/03/11/management-groups.md - Source hash: 4ffa2f9d19e2cc59 - Date: 2026-03-11 ### mgmt-group-move-requires-write-on-child-target-current [IN] OBSERVATION Moving a subscription or management group requires `Microsoft.management/managementgroups/write` permission on the child, the target parent, and the current parent management group. - Source: entries/2026/03/11/management-groups.md - Source hash: 4ffa2f9d19e2cc59 - Date: 2026-03-11 ### mgmt-group-policies-rbac-cascade-to-descendants [IN] OBSERVATION Policies and RBAC role assignments on a management group cascade by inheritance to all descendant management groups, subscriptions, resource groups, and resources. - Source: entries/2026/03/11/management-groups.md - Source hash: 4ffa2f9d19e2cc59 - Date: 2026-03-11 ### mgmt-group-root-access-global-admin-elevate-only [IN] OBSERVATION 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. - Source: entries/2026/03/11/management-groups.md - Source hash: 4ffa2f9d19e2cc59 - Date: 2026-03-11 ### mgmt-group-root-access-requires-global-admin-elevation [IN] OBSERVATION No one has default access to the root management group — only Microsoft Entra Global Admins can elevate themselves to manage it. - Source: entries/2026/03/11/management-groups.md - Source hash: 4ffa2f9d19e2cc59 - Date: 2026-03-11 ### mgmt-group-root-cannot-move-or-delete [IN] OBSERVATION 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." - Source: entries/2026/03/11/management-groups.md - Source hash: 4ffa2f9d19e2cc59 - Date: 2026-03-11 ### mgmt-group-single-parent-rule [IN] OBSERVATION Each management group and subscription can have only one parent management group. - Source: entries/2026/03/11/management-groups.md - Source hash: 4ffa2f9d19e2cc59 - Date: 2026-03-11 ### mgmt-group-strict-hierarchy-model [IN] OBSERVATION 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. ### mgmt-groups-arm-cache-hierarchy-30-minutes [IN] OBSERVATION Azure Resource Manager caches management group hierarchy details for up to 30 minutes — portal may not reflect moves immediately. - Source: entries/2026/03/11/management-groups.md - Source hash: 4ffa2f9d19e2cc59 - Date: 2026-03-11 ### mgmt-groups-inheritance-cascades-to-all-descendants [IN] OBSERVATION Policies and RBAC role assignments on a management group cascade by inheritance to all descendant management groups, subscriptions, resource groups, and resources. - Source: entries/2026/03/11/management-groups.md - Source hash: 4ffa2f9d19e2cc59 - Date: 2026-03-11 ### mgmt-groups-max-10000-per-directory [IN] OBSERVATION A single Microsoft Entra directory supports up to 10,000 management groups. - Source: entries/2026/03/11/management-groups.md - Source hash: 4ffa2f9d19e2cc59 - Date: 2026-03-11 ### mgmt-groups-max-6-levels-depth [IN] OBSERVATION Management group hierarchy supports up to 6 levels of depth, excluding the root management group level and the subscription level. - Source: entries/2026/03/11/management-groups.md - Source hash: 4ffa2f9d19e2cc59 - Date: 2026-03-11 ### mgmt-groups-move-requires-write-on-child-target-current [IN] OBSERVATION Moving a subscription or management group requires `Microsoft.management/managementgroups/write` permission on the child, the target parent, and the current parent management group. - Source: entries/2026/03/11/management-groups.md - Source hash: 4ffa2f9d19e2cc59 - Date: 2026-03-11 ### mgmt-groups-root-access-global-admin-elevate [IN] OBSERVATION No one has default access to the root management group — only Microsoft Entra Global Admins can elevate themselves to manage it. - Source: entries/2026/03/11/management-groups.md - Source hash: 4ffa2f9d19e2cc59 - Date: 2026-03-11 ### mgmt-groups-root-cannot-move-or-delete [IN] OBSERVATION 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". - Source: entries/2026/03/11/management-groups.md - Source hash: 4ffa2f9d19e2cc59 - Date: 2026-03-11 ### mgmt-groups-single-parent-rule [IN] OBSERVATION Each management group and subscription can have only one parent management group. - Source: entries/2026/03/11/management-groups.md - Source hash: 4ffa2f9d19e2cc59 - Date: 2026-03-11 ### microsoft-cloud-security-benchmark-underpins-waf [IN] OBSERVATION Microsoft Cloud Security Benchmark provides the control framework that underpins WAF Security pillar guidance. - Source: entries/2026/03/11/waf-security.md - Source hash: 8d4db94cc716a02a - Date: 2026-03-11 ### microsoft-recommends-private-link-over-service-endpoints [IN] OBSERVATION Microsoft recommends Azure Private Link/private endpoints over service endpoints for new deployments. - Source: entries/2026/03/10/vnet-service-endpoints.md - Source hash: e9acb2ed1bb8de24 - Date: 2026-03-10 ### network-contributor-covers-all-subnet-operations [IN] OBSERVATION The Network Contributor built-in role covers all subnet RBAC operations (read, write, delete, join, joinViaServiceEndpoint). - Source: entries/2026/03/11/vnet-subnets.md - Source hash: d70de809fbdd3d75 - Date: 2026-03-11 ### network-contributor-no-vm-deployment [IN] OBSERVATION Network Contributor lets you manage networks but does not allow deploying VMs or directly accessing the networks. - Source: entries/2026/03/11/rbac-built-in-roles.md - Source hash: a6ab58d61750d4bf - Date: 2026-03-11 ### network-contributor-role-covers-subnet-operations [IN] OBSERVATION The Network Contributor built-in role covers all subnet RBAC operations (read, write, delete, join, joinViaServiceEndpoint). - Source: entries/2026/03/11/vnet-subnets.md - Source hash: d70de809fbdd3d75 - Date: 2026-03-11 ### network-security-perimeter-ga-all-public-regions [IN] OBSERVATION 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. - Source: entries/2026/03/11/vnet-private-link.md - Source hash: 3d8a7a6f7417970f - Date: 2026-03-11 ### never-disable-route-propagation-on-gatewaysubnet [IN] OBSERVATION Route propagation must never be disabled on GatewaySubnet — the gateway will stop functioning. - Source: entries/2026/03/10/vnet-routing.md - Source hash: e235d55a05668d3b - Date: 2026-03-10 ### nsg-infrastructure-aware-stateful-evaluation [IN] OBSERVATION 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-stateful-graceful-rule-changes [IN] OBSERVATION 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. ### nva-deploy-different-subnet-avoid-loops [IN] OBSERVATION NVAs must be deployed in a different subnet than the routed resources to avoid routing loops. - Source: entries/2026/03/10/vnet-routing.md - Source hash: e235d55a05668d3b - Date: 2026-03-11 ### nva-deploy-in-different-subnet-avoid-loops [IN] OBSERVATION NVAs must be deployed in a different subnet than the resources whose traffic they route to avoid routing loops. - Source: entries/2026/03/10/vnet-routing.md - Source hash: e235d55a05668d3b - Date: 2026-03-11 ### nva-ip-forwarding-required-nic-and-os [IN] OBSERVATION NVA IP forwarding must be enabled at both the Azure NIC level and the OS level for traffic forwarding to work. - Source: entries/2026/03/10/vnet-routing.md - Source hash: e235d55a05668d3b - Date: 2026-03-10 ### object-replication-block-blobs-only [IN] OBSERVATION Object replication supports block blobs only (not append or page blobs). - Source: entries/2026/03/10/storage-blob-replication.md - Source hash: 37d2dced847c90c7 - Date: 2026-03-10 ### object-replication-cross-tenant-default-false [IN] OBSERVATION AllowCrossTenantReplication defaults to false for storage accounts created after December 15, 2023. - Source: entries/2026/03/10/storage-blob-replication.md - Source hash: 37d2dced847c90c7 - Date: 2026-03-10 ### object-replication-customer-managed-failover-not-supported [IN] OBSERVATION Customer-managed failover is not supported on either the source or destination account in an object replication policy. - Source: entries/2026/03/11/storage-blob-replication.md - Source hash: e20e13834f4c3b87 - Date: 2026-03-11 ### object-replication-destination-readonly [IN] OBSERVATION The destination container becomes read-only while a replication policy is active; writes return HTTP 409 Conflict. - Source: entries/2026/03/10/storage-blob-replication.md - Source hash: 37d2dced847c90c7 - Date: 2026-03-10 ### object-replication-fails-archive-tier [IN] OBSERVATION Object replication fails if either the source or destination blob is moved to the archive tier. - Source: entries/2026/03/10/storage-blob-replication.md - Source hash: 37d2dced847c90c7 - Date: 2026-03-11 ### object-replication-gpv2-premium-block-blob-only [IN] OBSERVATION Azure Blob Storage object replication is supported only on general-purpose v2 and premium block blob storage account types. - Source: entries/2026/03/11/storage-blob-replication.md - Source hash: e20e13834f4c3b87 - Date: 2026-03-11 ### object-replication-gpv2-premium-block-only [IN] OBSERVATION Object replication is supported only on general-purpose v2 and premium block blob storage account types. - Source: entries/2026/03/11/storage-blob-replication.md - Source hash: e20e13834f4c3b87 - Date: 2026-03-11 ### object-replication-max-1000-rules [IN] OBSERVATION Each object replication policy supports up to 1,000 rules. - Source: entries/2026/03/10/storage-blob-replication.md - Source hash: 37d2dced847c90c7 - Date: 2026-03-10 ### object-replication-max-1000-rules-per-policy [IN] OBSERVATION Each object replication policy supports up to 1,000 rules; each rule maps one source container to one destination container. - Source: entries/2026/03/11/storage-blob-replication.md - Source hash: e20e13834f4c3b87 - Date: 2026-03-11 ### object-replication-max-2-destinations [IN] OBSERVATION A source account can replicate to at most 2 destination accounts; a destination account can have at most 2 replication policies. - Source: entries/2026/03/10/storage-blob-replication.md - Source hash: 37d2dced847c90c7 - Date: 2026-03-10 ### object-replication-max-2-policies-per-destination [IN] OBSERVATION A destination storage account can have at most 2 replication policies; a source account can replicate to at most 2 destination accounts. - Source: entries/2026/03/11/storage-blob-replication.md - Source hash: e20e13834f4c3b87 - Date: 2026-03-11 ### object-replication-no-customer-managed-failover [IN] OBSERVATION Customer-managed failover is not supported for storage accounts participating in object replication. - Source: entries/2026/03/10/storage-blob-replication.md - Source hash: 37d2dced847c90c7 - Date: 2026-03-11 ### object-replication-no-customer-provided-keys [IN] OBSERVATION Object replication fails for blobs encrypted with customer-provided keys on the source account; Microsoft-managed and customer-managed keys are supported. - Source: entries/2026/03/10/storage-blob-replication.md - Source hash: 37d2dced847c90c7 - Date: 2026-03-11 ### object-replication-no-hierarchical-namespace [IN] OBSERVATION Object replication is not supported for storage accounts with hierarchical namespace enabled (Data Lake Storage Gen2). - Source: entries/2026/03/10/storage-blob-replication.md - Source hash: 37d2dced847c90c7 - Date: 2026-03-11 ### object-replication-no-hns-adls-gen2 [IN] OBSERVATION Object replication does not support storage accounts with hierarchical namespace enabled (ADLS Gen2 / Data Lake Storage). - Source: entries/2026/03/11/storage-blob-replication.md - Source hash: e20e13834f4c3b87 - Date: 2026-03-11 ### object-replication-policy-created-on-destination [IN] OBSERVATION Object replication policy is created on the destination account first, then linked to the source account using the same policy ID. - Source: entries/2026/03/11/storage-blob-replication.md - Source hash: e20e13834f4c3b87 - Date: 2026-03-11 ### object-replication-policy-created-on-destination-first [IN] OBSERVATION Object replication policy is created on the destination account first (with policyId "default"), then linked to the source account using the assigned policy ID. - Source: entries/2026/03/11/storage-blob-replication.md - Source hash: e20e13834f4c3b87 - Date: 2026-03-11 ### object-replication-priority-sla-15min [IN] OBSERVATION With priority replication enabled (same continent), 99% of objects replicate within 15 minutes (SLA-backed). - Source: entries/2026/03/10/storage-blob-replication.md - Source hash: 37d2dced847c90c7 - Date: 2026-03-10 ### object-replication-requires-changefeed-versioning [IN] OBSERVATION Object replication requires change feed on the source account and blob versioning on both source and destination accounts. - Source: entries/2026/03/10/storage-blob-replication.md - Source hash: 37d2dced847c90c7 - Date: 2026-03-10 ### object-replication-snapshots-not-replicated [IN] OBSERVATION Snapshots are not replicated and version IDs are not preserved during object replication. - Source: entries/2026/03/10/storage-blob-replication.md - Source hash: 37d2dced847c90c7 - Date: 2026-03-10 ### object-replication-version-ids-not-preserved [IN] OBSERVATION Object replication does not preserve version IDs — destination blobs receive new version IDs. - Source: entries/2026/03/11/storage-blob-replication.md - Source hash: e20e13834f4c3b87 - Date: 2026-03-11 ### override-default-route-redirects-all-traffic [IN] OBSERVATION 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. - Source: entries/2026/03/10/vnet-routing.md - Source hash: e235d55a05668d3b - Date: 2026-03-11 ### paas-connectivity-dual-model [IN] OBSERVATION 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. ### policy-assignment-updates-with-definition [IN] OBSERVATION Azure Policy assignments use the latest definition state — updating a policy definition automatically applies to all existing assignments without reassignment. - Source: entries/2026/03/11/policy-overview.md - Source hash: 218b91d31a6ddd65 - Date: 2026-03-11 ### policy-audit-if-not-exists-evaluates-child-resources [IN] OBSERVATION `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. - Source: entries/2026/03/11/policy-effects.md - Source hash: c0891933480973a9 - Date: 2026-03-11 ### policy-best-practice-start-with-audit [IN] OBSERVATION Best practice: start Azure Policy with `audit`/`auditIfNotExists` effects before enforcement (`deny`, `modify`, `deployIfNotExists`), and always use initiatives even for a single policy definition. - Source: entries/2026/03/11/policy-overview.md - Source hash: 218b91d31a6ddd65 - Date: 2026-03-11 ### policy-compliance-evaluation-every-24-hours [IN] OBSERVATION Azure Policy automatic compliance evaluation occurs every 24 hours; additional triggers include resource create/update, new/updated assignments, and policy definition updates. - Source: entries/2026/03/11/policy-overview.md - Source hash: 218b91d31a6ddd65 - Date: 2026-03-11 ### policy-cumulative-most-restrictive [IN] OBSERVATION When multiple Azure Policy assignments layer on a resource, the net result is cumulative most restrictive — overlapping deny policies block resources; exclusions create exceptions. - Source: entries/2026/03/11/policy-effects.md - Source hash: c0891933480973a9 - Date: 2026-03-11 ### policy-definition-displayname-128-description-512 [IN] OBSERVATION Azure Policy definition `displayName` is capped at 128 characters and `description` at 512 characters. - Source: entries/2026/03/11/policy-definition-structure.md - Source hash: d6433507e5e7252d - Date: 2026-03-11 ### policy-definition-location-determines-assignment-scope [IN] OBSERVATION 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). - Source: entries/2026/03/11/policy-definition-structure.md - Source hash: d6433507e5e7252d - Date: 2026-03-11 ### policy-definition-mode-all-vs-indexed [IN] OBSERVATION 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`. - Source: entries/2026/03/11/policy-definition-structure.md - Source hash: d6433507e5e7252d - Date: 2026-03-11 ### policy-effect-evaluation-order [IN] OBSERVATION 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. - Source: entries/2026/03/11/policy-effects.md - Source hash: c0891933480973a9 - Date: 2026-03-11 ### policy-explicit-deny-system [IN] OBSERVATION 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. - Source: entries/2026/03/11/policy-overview.md - Source hash: 218b91d31a6ddd65 - Date: 2026-03-11 ### policy-governance-enforcement-model [IN] OBSERVATION 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. ### policy-max-20-params-definition-400-initiative [IN] OBSERVATION Azure Policy allows maximum 20 parameters per policy definition and 400 parameters per initiative definition. - Source: entries/2026/03/11/policy-overview.md - Source hash: 218b91d31a6ddd65 - Date: 2026-03-11 ### policy-max-500-definitions-per-scope [IN] OBSERVATION 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. - Source: entries/2026/03/11/policy-overview.md - Source hash: 218b91d31a6ddd65 - Date: 2026-03-11 ### policy-metadata-property-limit-1024-chars [IN] OBSERVATION Each Azure Policy metadata property (`version`, `category`, `preview`, `deprecated`, `portalReview`) is limited to 1024 characters. - Source: entries/2026/03/11/policy-definition-structure.md - Source hash: d6433507e5e7252d - Date: 2026-03-11 ### policy-resource-provider-modes-three-ga [IN] OBSERVATION 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. - Source: entries/2026/03/11/policy-definition-structure.md - Source hash: d6433507e5e7252d - Date: 2026-03-11 ### policy-single-effect-per-definition [IN] OBSERVATION Each Azure Policy definition contains exactly one effect in its `policyRule`; multiple effects require multiple policy definitions. - Source: entries/2026/03/11/policy-effects.md - Source hash: c0891933480973a9 - Date: 2026-03-11 ### policy-twelve-supported-effects [IN] OBSERVATION Azure Policy supports 12 effects: `addToNetworkGroup`, `append`, `audit`, `auditIfNotExists`, `deny`, `denyAction`, `deployIfNotExists`, `disabled`, `manual`, `modify`, `mutate`. - Source: entries/2026/03/11/policy-effects.md - Source hash: c0891933480973a9 - Date: 2026-03-11 ### policy-type-read-only-three-values [IN] OBSERVATION 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). - Source: entries/2026/03/11/policy-definition-structure.md - Source hash: d6433507e5e7252d - Date: 2026-03-11 ### policy-versioning-major-minor-patch [IN] OBSERVATION 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. - Source: entries/2026/03/11/policy-definition-structure.md - Source hash: d6433507e5e7252d - Date: 2026-03-11 ### private-endpoint-and-private-link-service-ga [IN] OBSERVATION Both Azure Private Endpoint and Private Link Service (behind Standard LB) are generally available; individual PaaS services onboard to Private Link on different schedules. - Source: entries/2026/03/10/vnet-private-link.md - Source hash: d9bb65140f89bf1f - Date: 2026-03-11 ### private-endpoint-maps-to-single-resource-instance [IN] OBSERVATION A private endpoint maps to a specific PaaS resource instance (not the entire service), providing data leakage protection. - Source: entries/2026/03/10/vnet-private-link.md - Source hash: d9bb65140f89bf1f - Date: 2026-03-10 ### private-endpoint-requires-private-dns-zones [IN] OBSERVATION Azure Private Endpoints require Azure DNS / Private DNS Zones for name resolution of the private endpoint. - Source: entries/2026/03/10/vnet-private-link.md - Source hash: d9bb65140f89bf1f - Date: 2026-03-11 ### private-link-both-endpoint-and-service-ga [IN] OBSERVATION Both Azure Private Endpoint and Private Link Service (behind Standard LB) are generally available; individual PaaS services onboard on different schedules. - Source: entries/2026/03/10/vnet-private-link.md - Source hash: d9bb65140f89bf1f - Date: 2026-03-11 ### private-link-monitor-data-processed-nat-port [IN] OBSERVATION Azure Monitor tracks data processed (IN/OUT) on both private endpoints and Private Link services, plus NAT port availability for Private Link Service. - Source: entries/2026/03/10/vnet-private-link.md - Source hash: d9bb65140f89bf1f - Date: 2026-03-11 ### private-link-monitor-data-processed-nat-ports [IN] OBSERVATION Azure Monitor tracks data processed (IN/OUT) on both private endpoints and Private Link services, plus NAT port availability for Private Link Service. - Source: entries/2026/03/10/vnet-private-link.md - Source hash: d9bb65140f89bf1f - Date: 2026-03-11 ### private-link-network-security-perimeter-ga [IN] OBSERVATION 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. - Source: entries/2026/03/11/vnet-private-link.md - Source hash: 3d8a7a6f7417970f - Date: 2026-03-11 ### private-link-on-premises-via-expressroute-private-peering [IN] OBSERVATION On-premises access to Private Link services uses ExpressRoute private peering or VPN tunnels; Microsoft peering is not required. - Source: entries/2026/03/10/vnet-private-link.md - Source hash: d9bb65140f89bf1f - Date: 2026-03-10 ### private-link-requires-private-dns-zones [IN] OBSERVATION Azure DNS / Private DNS Zones are required for name resolution of private endpoints. - Source: entries/2026/03/10/vnet-private-link.md - Source hash: d9bb65140f89bf1f - Date: 2026-03-11 ### private-link-service-requires-standard-load-balancer [IN] OBSERVATION Azure Private Link Service requires a Standard Load Balancer (not Basic) as its backend. - Source: entries/2026/03/10/vnet-private-link.md - Source hash: d9bb65140f89bf1f - Date: 2026-03-10 ### private-link-supports-cross-region-connectivity [IN] OBSERVATION Private Link has global reach — a consumer VNet in one region can connect to services behind Private Link in a different region. - Source: entries/2026/03/10/vnet-private-link.md - Source hash: d9bb65140f89bf1f - Date: 2026-03-10 ### private-link-traffic-stays-on-microsoft-backbone [IN] OBSERVATION Azure Private Link traffic traverses the Microsoft backbone network and never crosses the public internet. - Source: entries/2026/03/10/vnet-private-link.md - Source hash: d9bb65140f89bf1f - Date: 2026-03-10 ### private-link-triple-isolation-model [IN] OBSERVATION 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. ### private-link-works-cross-tenant [IN] OBSERVATION Azure Private Link works across different Microsoft Entra tenants with an approval call flow for connection requests. - Source: entries/2026/03/10/vnet-private-link.md - Source hash: d9bb65140f89bf1f - Date: 2026-03-10 ### private-link-zone-resilient [IN] OBSERVATION Azure Private Link spans Availability Zones and is zone resilient. - Source: entries/2026/03/10/vnet-private-link.md - Source hash: d9bb65140f89bf1f - Date: 2026-03-10 ### public-lb-handles-inbound-and-outbound [IN] OBSERVATION Public Azure Load Balancer handles both inbound (internet to VMs) and outbound (VMs to internet via private-to-public IP translation) connectivity. - Source: entries/2026/03/11/lb-overview.md - Source hash: a1be26783998b452 - Date: 2026-03-11 ### queue-storage-max-message-64kb [IN] OBSERVATION Azure Queue Storage messages have a maximum size of 64 KB; queues can contain millions of messages. - Source: entries/2026/03/10/storage-overview.md - Source hash: 7de2f80c18a9ae0b - Date: 2026-03-10 ### rbac-access-evaluation-order [IN] OBSERVATION Azure RBAC access evaluation order: token acquisition → retrieve role/deny assignments → check deny → check roles → check conditions. - Source: entries/2026/03/11/rbac-overview.md - Source hash: 1df2167c7b7fb402 - Date: 2026-03-11 ### rbac-actions-control-plane-dataactions-data-plane [IN] OBSERVATION Actions/NotActions apply to the control plane; DataActions/NotDataActions apply to the data plane. - Source: entries/2026/03/10/rbac-built-in-roles.md - Source hash: 537994bcf7a587c3 - Date: 2026-03-10 ### rbac-additive-arm-authorization-model [IN] OBSERVATION 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. ### rbac-additive-model [IN] OBSERVATION Azure RBAC uses an additive model — effective permissions are the union of all role assignments; no role assignment subtracts from another. - Source: entries/2026/03/10/rbac-overview.md - Source hash: d859b0b444a547a4 - Date: 2026-03-10 ### rbac-admin-cannot-manage-via-policy [IN] OBSERVATION The Role Based Access Control Administrator role can assign roles via RBAC but explicitly cannot manage access via Azure Policy. - Source: entries/2026/03/11/rbac-built-in-roles.md - Source hash: a6ab58d61750d4bf - Date: 2026-03-11 ### rbac-admin-role-cannot-use-azure-policy [IN] OBSERVATION The Role Based Access Control Administrator role can assign roles via RBAC but cannot manage access via Azure Policy or other mechanisms. - Source: entries/2026/03/11/rbac-built-in-roles.md - Source hash: a6ab58d61750d4bf - Date: 2026-03-11 ### rbac-administrator-role-rbac-only-not-policy [IN] OBSERVATION Role Based Access Control Administrator can only manage access via Azure RBAC, not via Azure Policy or other mechanisms. - Source: entries/2026/03/10/rbac-built-in-roles.md - Source hash: 537994bcf7a587c3 - Date: 2026-03-11 ### rbac-arm-no-validate-mg-in-assignable-scopes [IN] OBSERVATION Azure Resource Manager does not validate management group existence when specified in custom role AssignableScopes. - Source: entries/2026/03/11/rbac-custom-roles.md - Source hash: 49f4e6e3d4fc5a34 - Date: 2026-03-11 ### rbac-assignment-three-elements [IN] OBSERVATION An Azure RBAC role assignment has exactly three elements: security principal, role definition, and scope. - Source: entries/2026/03/10/rbac-overview.md - Source hash: d859b0b444a547a4 - Date: 2026-03-10 ### rbac-built-on-arm [IN] OBSERVATION Azure RBAC is built on Azure Resource Manager; all access decisions flow through ARM's global endpoint. - Source: entries/2026/03/11/rbac-overview.md - Source hash: 1df2167c7b7fb402 - Date: 2026-03-11 ### rbac-conditions-evaluated-last [IN] OBSERVATION Conditions on Azure RBAC role assignments are evaluated last; if conditions aren't met, access is denied even if the role grants the action. - Source: entries/2026/03/11/rbac-overview.md - Source hash: 1df2167c7b7fb402 - Date: 2026-03-11 ### rbac-conditions-on-role-assignments [IN] OBSERVATION Azure RBAC role assignments can include conditions that are evaluated after role matching; access is denied if conditions are not met. - Source: entries/2026/03/10/rbac-overview.md - Source hash: d859b0b444a547a4 - Date: 2026-03-11 ### rbac-custom-role-cannot-scope-to-root [IN] OBSERVATION Custom roles cannot set AssignableScopes to the root scope (`"/"`). - Source: entries/2026/03/10/rbac-custom-roles.md - Source hash: b1213904ef0695fb - Date: 2026-03-11 ### rbac-custom-role-dataactions-no-management-group-scope [IN] OBSERVATION Custom roles with DataActions cannot be assigned at management group scope. - Source: entries/2026/03/10/rbac-custom-roles.md - Source hash: b1213904ef0695fb - Date: 2026-03-10 ### rbac-custom-role-max-2000-assignable-scopes [IN] OBSERVATION Custom roles support a maximum of 2,000 AssignableScopes per role definition. - Source: entries/2026/03/10/rbac-custom-roles.md - Source hash: b1213904ef0695fb - Date: 2026-03-10 ### rbac-custom-role-no-root-scope [IN] OBSERVATION Custom roles cannot have AssignableScopes set to root scope (`"/"`). - Source: entries/2026/03/11/rbac-custom-roles.md - Source hash: 49f4e6e3d4fc5a34 - Date: 2026-03-11 ### rbac-custom-role-no-root-scope-assignable [IN] OBSERVATION Custom roles cannot set AssignableScopes to root scope (`"/"`). - Source: entries/2026/03/10/rbac-custom-roles.md - Source hash: b1213904ef0695fb - Date: 2026-03-11 ### rbac-custom-role-no-wildcards-in-assignable-scopes [IN] OBSERVATION Wildcards cannot be used in AssignableScopes for custom role definitions. - Source: entries/2026/03/10/rbac-custom-roles.md - Source hash: b1213904ef0695fb - Date: 2026-03-10 ### rbac-custom-role-one-management-group-in-assignable-scopes [IN] OBSERVATION Only one management group can be defined in a custom role's AssignableScopes. - Source: entries/2026/03/10/rbac-custom-roles.md - Source hash: b1213904ef0695fb - Date: 2026-03-10 ### rbac-custom-role-permission-strings-case-insensitive [IN] OBSERVATION Azure RBAC permission strings in custom role definitions are case-insensitive; wildcards are supported but limited to one wildcard (`*`) per action string. - Source: entries/2026/03/11/rbac-custom-roles.md - Source hash: 49f4e6e3d4fc5a34 - Date: 2026-03-11 ### rbac-custom-role-requires-write-on-all-assignable-scopes [IN] OBSERVATION Creating, deleting, or updating custom roles requires `Microsoft.Authorization/roleDefinitions/write` permission on all AssignableScopes. - Source: entries/2026/03/10/rbac-custom-roles.md - Source hash: b1213904ef0695fb - Date: 2026-03-10 ### rbac-custom-role-rest-api-format-differs [IN] OBSERVATION 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`. - Source: entries/2026/03/10/rbac-custom-roles.md - Source hash: b1213904ef0695fb - Date: 2026-03-11 ### rbac-custom-roles-limit-5000-per-tenant [IN] OBSERVATION Azure has a limit of 5,000 custom roles per tenant (2,000 for 21Vianet). - Source: entries/2026/03/10/rbac-custom-roles.md - Source hash: b1213904ef0695fb - Date: 2026-03-10 ### rbac-data-globally-replicated [IN] OBSERVATION Azure RBAC data (definitions, assignments, deny assignments) is stored and replicated globally across all Azure regions. - Source: entries/2026/03/10/rbac-overview.md - Source hash: d859b0b444a547a4 - Date: 2026-03-10 ### rbac-deny-assignments-take-precedence [IN] OBSERVATION Deny assignments are evaluated before allow role assignments; if a deny applies, access is blocked regardless of role assignments. - Source: entries/2026/03/10/rbac-overview.md - Source hash: d859b0b444a547a4 - Date: 2026-03-10 ### rbac-effective-permissions-formula [IN] OBSERVATION Azure RBAC effective permissions are calculated as `Actions - NotActions` for management plane and `DataActions - NotDataActions` for data plane. - Source: entries/2026/03/11/rbac-overview.md - Source hash: 1df2167c7b7fb402 - Date: 2026-03-11 ### rbac-five-privileged-roles [IN] OBSERVATION Azure RBAC has exactly 5 privileged roles: Owner, Contributor, Reader, User Access Administrator, and Role Based Access Control Administrator. - Source: entries/2026/03/11/rbac-built-in-roles.md - Source hash: a6ab58d61750d4bf - Date: 2026-03-11 ### rbac-free-with-every-subscription [IN] OBSERVATION Azure RBAC is included free with every Azure subscription at no additional cost. - Source: entries/2026/03/10/rbac-overview.md - Source hash: d859b0b444a547a4 - Date: 2026-03-10 ### rbac-group-membership-transitive [IN] OBSERVATION Group memberships are transitive for Azure RBAC role assignment purposes — nested group members inherit roles. - Source: entries/2026/03/10/rbac-overview.md - Source hash: d859b0b444a547a4 - Date: 2026-03-10 ### rbac-must-remove-assignments-before-deleting-custom-role [IN] OBSERVATION All role assignments must be removed before a custom role can be deleted (error: RoleDefinitionHasAssignments). - Source: entries/2026/03/10/rbac-custom-roles.md - Source hash: b1213904ef0695fb - Date: 2026-03-10 ### rbac-network-contributor-cannot-deploy-vms [IN] OBSERVATION Network Contributor role allows managing networks but does not grant permission to deploy virtual machines. - Source: entries/2026/03/10/rbac-built-in-roles.md - Source hash: 537994bcf7a587c3 - Date: 2026-03-11 ### rbac-network-contributor-no-vm-deploy [IN] OBSERVATION 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. - Source: entries/2026/03/11/rbac-built-in-roles.md - Source hash: a6ab58d61750d4bf - Date: 2026-03-11 ### rbac-notactions-exclude-not-deny [IN] OBSERVATION NotActions excludes operations from the allowed Actions set but is not a deny — it simply subtracts from allowed permissions. - Source: entries/2026/03/10/rbac-custom-roles.md - Source hash: b1213904ef0695fb - Date: 2026-03-11 ### rbac-notactions-subtraction-not-deny [IN] OBSERVATION `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. - Source: entries/2026/03/11/rbac-custom-roles.md - Source hash: 49f4e6e3d4fc5a34 - Date: 2026-03-11 ### rbac-owner-vs-contributor-role-assignment [IN] OBSERVATION Owner role can assign roles in Azure RBAC; Contributor role cannot assign roles, manage Blueprints, or share image galleries. - Source: entries/2026/03/10/rbac-built-in-roles.md - Source hash: 537994bcf7a587c3 - Date: 2026-03-10 ### rbac-permission-strings-case-insensitive [IN] OBSERVATION Azure RBAC permission strings (e.g., `Microsoft.Compute/*/read`) are case-insensitive. - Source: entries/2026/03/10/rbac-custom-roles.md - Source hash: b1213904ef0695fb - Date: 2026-03-11 ### rbac-reader-role-id-guid [IN] OBSERVATION The Azure RBAC Reader role has the immutable ID `acdd72a7-3385-48ef-bd42-f606fba81ae7`. - Source: entries/2026/03/10/rbac-built-in-roles.md - Source hash: 537994bcf7a587c3 - Date: 2026-03-10 ### rbac-role-assignment-conditions [IN] OBSERVATION Azure RBAC role assignments can include conditions evaluated after role matching; access is denied if conditions are not met. - Source: entries/2026/03/10/rbac-overview.md - Source hash: d859b0b444a547a4 - Date: 2026-03-11 ### rbac-role-four-permission-components [IN] OBSERVATION Azure RBAC role definitions have four permission components: Actions, NotActions, DataActions, and NotDataActions. - Source: entries/2026/03/10/rbac-built-in-roles.md - Source hash: 537994bcf7a587c3 - Date: 2026-03-10 ### rbac-role-ids-stable-across-renames [IN] OBSERVATION Azure RBAC role definition IDs remain stable even if a role is renamed; best practice is to reference roles by ID in automation. - Source: entries/2026/03/10/rbac-custom-roles.md - Source hash: b1213904ef0695fb - Date: 2026-03-10 ### rbac-scope-hierarchy [IN] OBSERVATION Azure RBAC scope hierarchy from broadest to narrowest: management group > subscription > resource group > resource. - Source: entries/2026/03/10/rbac-overview.md - Source hash: d859b0b444a547a4 - Date: 2026-03-10 ### rbac-storage-blob-data-owner-includes-posix-acl [IN] OBSERVATION Storage Blob Data Owner role provides full access to blob data including the ability to assign POSIX ACLs. - Source: entries/2026/03/10/rbac-built-in-roles.md - Source hash: 537994bcf7a587c3 - Date: 2026-03-11 ### rbac-storage-blob-data-reader-vs-reader [IN] OBSERVATION Storage Blob Data Reader grants access to blob data (data plane); Reader grants management plane visibility only — they are not interchangeable. - Source: entries/2026/03/10/rbac-built-in-roles.md - Source hash: 537994bcf7a587c3 - Date: 2026-03-11 ### rbac-user-access-admin-manages-access-not-resources [IN] OBSERVATION User Access Administrator role manages user access to Azure resources but cannot manage the resources themselves. - Source: entries/2026/03/10/rbac-built-in-roles.md - Source hash: 537994bcf7a587c3 - Date: 2026-03-10 ### rbac-vm-contributor-no-vnet-storage-access [IN] OBSERVATION Virtual Machine Contributor does not grant access to the virtual network or storage account the VM connects to and cannot assign RBAC roles. - Source: entries/2026/03/11/rbac-built-in-roles.md - Source hash: a6ab58d61750d4bf - Date: 2026-03-11 ### rbac-vm-contributor-no-vnet-storage-rbac [IN] OBSERVATION Virtual Machine Contributor does not grant access to the connected VNet or storage account, nor allow RBAC assignment. - Source: entries/2026/03/10/rbac-built-in-roles.md - Source hash: 537994bcf7a587c3 - Date: 2026-03-11 ### rbac-vm-contributor-no-vnet-storage-rbac-access [IN] OBSERVATION Virtual Machine Contributor role does not grant access to the connected VNet or storage account, nor allow RBAC assignment. - Source: entries/2026/03/10/rbac-built-in-roles.md - Source hash: 537994bcf7a587c3 - Date: 2026-03-11 ### rbac-wildcard-one-per-action-string [IN] OBSERVATION Wildcards (`*`) are supported in Azure RBAC permission strings but only one wildcard is allowed per action string. - Source: entries/2026/03/11/rbac-custom-roles.md - Source hash: 49f4e6e3d4fc5a34 - Date: 2026-03-11 ### redis-audit-logs-premium-poll-enterprise-event [IN] OBSERVATION Azure Cache for Redis connection audit logs use poll-based collection on Premium and event-based collection on Enterprise. - Source: entries/2026/03/10/redis-tiers.md - Source hash: 594849f96a5c7b03 - Date: 2026-03-11 ### redis-basic-tier-no-sla [IN] OBSERVATION Azure Cache for Redis Basic tier has no SLA and runs on a single VM. - Source: entries/2026/03/10/redis-tiers.md - Source hash: 594849f96a5c7b03 - Date: 2026-03-10 ### redis-basic-tier-no-sla-no-replication [IN] OBSERVATION Azure Cache for Redis Basic tier has no SLA and no data replication — suitable for dev/test only. - Source: entries/2026/03/10/redis-best-practices.md - Source hash: a047d725bfd7ac64 - Date: 2026-03-10 ### redis-c0-shared-cpu-core [IN] OBSERVATION Azure Cache for Redis C0 cache uses a shared CPU core with minimal memory and noisy-neighbor issues — only for simple dev/test. - Source: entries/2026/03/10/redis-best-practices.md - Source hash: a047d725bfd7ac64 - Date: 2026-03-10 ### redis-cache-aside-pattern [IN] OBSERVATION Azure Cache for Redis supports the cache-aside pattern where data is loaded into cache only as needed from the backend data store. - Source: entries/2026/03/11/redis-overview.md - Source hash: 2c7d68916db1c411 - Date: 2026-03-11 ### redis-cannot-scale-down-tiers [IN] OBSERVATION Azure Cache for Redis can scale up from Basic to Premium but cannot scale down; Enterprise tiers support scale-up and scale-out only. - Source: entries/2026/03/10/redis-overview.md - Source hash: e04a9410d8e51b95 - Date: 2026-03-10 ### redis-clustering-premium-and-enterprise-only [IN] OBSERVATION Azure Cache for Redis clustering is available only on Premium, Enterprise, and Enterprise Flash tiers. - Source: entries/2026/03/11/redis-tiers.md - Source hash: deccd39ea90a84e4 - Date: 2026-03-11 ### redis-collocate-client-cache-same-region [IN] OBSERVATION Azure Cache for Redis client and cache must be in the same Azure region for optimal latency and reliability. - Source: entries/2026/03/11/redis-best-practices.md - Source hash: be9f03cd23d9ad49 - Date: 2026-03-11 ### redis-colocate-client-cache-same-region [IN] OBSERVATION Azure Cache for Redis client application and cache should be placed in the same Azure region to minimize latency. - Source: entries/2026/03/10/redis-best-practices.md - Source hash: a047d725bfd7ac64 - Date: 2026-03-11 ### redis-data-persistence-premium-or-enterprise [IN] OBSERVATION Data persistence (RDB/AOF) in Azure Cache for Redis requires Premium or Enterprise tier; not available on Basic or Standard. - Source: entries/2026/03/10/redis-overview.md - Source hash: e04a9410d8e51b95 - Date: 2026-03-10 ### redis-enterprise-flash-limited-modules [IN] OBSERVATION Azure Cache for Redis Enterprise Flash tier supports only RediSearch (preview) and RedisJSON; full Enterprise tier supports all Redis modules (RediSearch, RedisBloom, RedisJSON, RedisTimeSeries). - Source: entries/2026/03/11/redis-tiers.md - Source hash: deccd39ea90a84e4 - Date: 2026-03-11 ### redis-enterprise-flash-memory-range-300gb-4-5tb [IN] OBSERVATION Azure Cache for Redis Enterprise Flash tier uses nonvolatile memory with a memory range of 300 GB to 4.5 TB. - Source: entries/2026/03/10/redis-tiers.md - Source hash: 594849f96a5c7b03 - Date: 2026-03-11 ### redis-enterprise-flash-nonvolatile-memory [IN] OBSERVATION Azure Cache for Redis Enterprise Flash tier uses nonvolatile memory to reduce per-GB cost, supporting up to 4.5 TB. - Source: entries/2026/03/10/redis-overview.md - Source hash: e04a9410d8e51b95 - Date: 2026-03-10 ### redis-enterprise-modules-only [IN] OBSERVATION Only Enterprise tiers support Redis Modules (RediSearch, RedisBloom, RedisJSON, RedisTimeSeries). - Source: entries/2026/03/10/redis-tiers.md - Source hash: 594849f96a5c7b03 - Date: 2026-03-10 ### redis-enterprise-multi-threaded-oss-single-threaded [IN] OBSERVATION Azure Cache for Redis Basic/Standard/Premium use single-threaded command processing; Enterprise tiers use multi-threaded Redis Enterprise. - Source: entries/2026/03/10/redis-overview.md - Source hash: e04a9410d8e51b95 - Date: 2026-03-10 ### redis-enterprise-requires-marketplace-license [IN] OBSERVATION Azure Cache for Redis Enterprise tiers require an Azure Marketplace license; Azure credits and free MSDN subscriptions are not supported. - Source: entries/2026/03/10/redis-tiers.md - Source hash: 594849f96a5c7b03 - Date: 2026-03-11 ### redis-enterprise-requires-marketplace-payment [IN] OBSERVATION 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. - Source: entries/2026/03/11/redis-overview.md - Source hash: 2c7d68916db1c411 - Date: 2026-03-11 ### redis-enterprise-requires-marketplace-purchase [IN] OBSERVATION Azure Cache for Redis Enterprise tiers require a valid payment instrument (no free credits/MSDN) and Marketplace purchase permissions. - Source: entries/2026/03/10/redis-overview.md - Source hash: e04a9410d8e51b95 - Date: 2026-03-11 ### redis-enterprise-requires-payment-instrument [IN] OBSERVATION Azure Cache for Redis Enterprise tier requires an Azure subscription with a valid payment instrument; free credits and MSDN subscriptions are not supported. - Source: entries/2026/03/11/redis-overview.md - Source hash: 2c7d68916db1c411 - Date: 2026-03-11 ### redis-enterprise-requires-valid-payment-instrument [IN] OBSERVATION Azure Cache for Redis Enterprise tier requires a valid payment instrument; Azure credits and free MSDN subscriptions are not supported. - Source: entries/2026/03/11/redis-tiers.md - Source hash: deccd39ea90a84e4 - Date: 2026-03-11 ### redis-enterprise-scale-up-before-out [IN] OBSERVATION 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. - Source: entries/2026/03/11/redis-overview.md - Source hash: 2c7d68916db1c411 - Date: 2026-03-11 ### redis-enterprise-scale-up-before-out-oss-scale-out [IN] OBSERVATION 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). - Source: entries/2026/03/10/redis-tiers.md - Source hash: 594849f96a5c7b03 - Date: 2026-03-11 ### redis-five-service-tiers [IN] OBSERVATION Azure Cache for Redis has five service tiers: Basic, Standard, Premium, Enterprise, and Enterprise Flash. - Source: entries/2026/03/10/redis-overview.md - Source hash: e04a9410d8e51b95 - Date: 2026-03-10 ### redis-five-tiers [IN] OBSERVATION Azure Cache for Redis offers five service tiers: Basic, Standard, Premium, Enterprise, and Enterprise Flash. - Source: entries/2026/03/10/redis-tiers.md - Source hash: 594849f96a5c7b03 - Date: 2026-03-10 ### redis-geo-replication-passive-premium-active-enterprise [IN] OBSERVATION Azure Cache for Redis Premium tier supports passive geo-replication only; Enterprise and Enterprise Flash support active geo-replication. - Source: entries/2026/03/10/redis-overview.md - Source hash: e04a9410d8e51b95 - Date: 2026-03-10 ### redis-geo-replication-passive-vs-active [IN] OBSERVATION Azure Cache for Redis Premium tier supports passive geo-replication; Enterprise and Enterprise Flash support active geo-replication. - Source: entries/2026/03/10/redis-tiers.md - Source hash: 594849f96a5c7b03 - Date: 2026-03-10 ### redis-keys-command-avoid-production [IN] OBSERVATION The Redis `KEYS` command is expensive and should be avoided in production; use `SCAN` instead. - Source: entries/2026/03/10/redis-best-practices.md - Source hash: a047d725bfd7ac64 - Date: 2026-03-10 ### redis-modules-enterprise-only [IN] OBSERVATION Redis modules (RediSearch, RedisBloom, RedisJSON, RedisTimeSeries) are available only on Enterprise tiers of Azure Cache for Redis. - Source: entries/2026/03/10/redis-overview.md - Source hash: e04a9410d8e51b95 - Date: 2026-03-10 ### redis-no-scale-down-tier [IN] OBSERVATION Azure Cache for Redis supports scaling up from Basic to Premium but does not support scaling down to a lower tier. - Source: entries/2026/03/10/redis-tiers.md - Source hash: 594849f96a5c7b03 - Date: 2026-03-10 ### redis-oss-clustering-requires-premium [IN] OBSERVATION OSS Redis clustering requires Azure Cache for Redis Premium tier or higher. - Source: entries/2026/03/10/redis-overview.md - Source hash: e04a9410d8e51b95 - Date: 2026-03-11 ### redis-oss-clustering-requires-premium-or-higher [IN] OBSERVATION Azure Cache for Redis OSS clustering requires Premium tier or higher; not available on Basic or Standard. - Source: entries/2026/03/10/redis-overview.md - Source hash: e04a9410d8e51b95 - Date: 2026-03-11 ### redis-oss-single-threaded-enterprise-multi-vcpu [IN] OBSERVATION Azure Cache for Redis OSS tiers (Basic/Standard/Premium) are single-threaded for command processing; Enterprise tiers utilize multiple vCPUs. - Source: entries/2026/03/10/redis-tiers.md - Source hash: 594849f96a5c7b03 - Date: 2026-03-10 ### redis-oss-versions-4-and-6-skipped-5 [IN] OBSERVATION Azure Cache for Redis OSS tiers support Redis versions 4.0.x and 6.0.x; Redis 5.0 was skipped. - Source: entries/2026/03/11/redis-tiers.md - Source hash: deccd39ea90a84e4 - Date: 2026-03-11 ### redis-persistence-premium-enterprise-only [IN] OBSERVATION Only Premium and Enterprise tiers of Azure Cache for Redis support data persistence (RDB and AOF). - Source: entries/2026/03/10/redis-tiers.md - Source hash: 594849f96a5c7b03 - Date: 2026-03-10 ### redis-persistence-storage-premium-managed-disks-enterprise [IN] OBSERVATION Azure Cache for Redis Premium tier uses Azure Storage for data persistence; Enterprise tier uses Managed Disks. - Source: entries/2026/03/11/redis-tiers.md - Source hash: deccd39ea90a84e4 - Date: 2026-03-11 ### redis-pin-root-ca-not-intermediate [IN] OBSERVATION 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. - Source: entries/2026/03/10/redis-best-practices.md - Source hash: a047d725bfd7ac64 - Date: 2026-03-11 ### redis-pin-root-ca-not-intermediate-leaf [IN] OBSERVATION 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. - Source: entries/2026/03/10/redis-best-practices.md - Source hash: a047d725bfd7ac64 - Date: 2026-03-11 ### redis-pin-root-certificates-not-intermediates [IN] OBSERVATION When using certificate pinning with Azure Cache for Redis, pin to root certificates — intermediate certificates rotate frequently. - Source: entries/2026/03/11/redis-best-practices.md - Source hash: be9f03cd23d9ad49 - Date: 2026-03-11 ### redis-pin-root-certs-not-intermediates [IN] OBSERVATION When using certificate pinning with Azure Cache for Redis, pin to root certificates, not intermediate or leaf certificates, since intermediates rotate frequently. - Source: entries/2026/03/11/redis-best-practices.md - Source hash: be9f03cd23d9ad49 - Date: 2026-03-11 ### redis-pipelining-head-of-line-blocking [IN] OBSERVATION Redis pipelining improves throughput but large responses can consume the timeout window for subsequent responses, causing head-of-line blocking timeouts. - Source: entries/2026/03/11/redis-best-practices.md - Source hash: be9f03cd23d9ad49 - Date: 2026-03-11 ### redis-prefer-many-small-values [IN] OBSERVATION Redis works best with smaller values; large data should be broken into multiple keys rather than stored as large blobs. - Source: entries/2026/03/10/redis-best-practices.md - Source hash: a047d725bfd7ac64 - Date: 2026-03-11 ### redis-prefer-smaller-values [IN] OBSERVATION Redis works best with smaller values; large data should be broken into multiple keys rather than stored as large blobs. - Source: entries/2026/03/10/redis-best-practices.md - Source hash: a047d725bfd7ac64 - Date: 2026-03-11 ### redis-private-link-all-tiers [IN] OBSERVATION Azure Cache for Redis supports network isolation via Private Link on all tiers (Basic through Enterprise Flash). - Source: entries/2026/03/11/redis-overview.md - Source hash: 2c7d68916db1c411 - Date: 2026-03-11 ### redis-progressive-tier-capability-ladder [IN] OBSERVATION 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. ### redis-sla-covers-connectivity-not-data-loss [IN] OBSERVATION Azure Cache for Redis SLA covers connectivity to cache endpoints only, not data loss protection. - Source: entries/2026/03/11/redis-overview.md - Source hash: 2c7d68916db1c411 - Date: 2026-03-11 ### redis-sla-covers-connectivity-only [IN] OBSERVATION Azure Cache for Redis SLA covers connectivity to cache endpoints only, not data loss protection. - Source: entries/2026/03/11/redis-overview.md - Source hash: 2c7d68916db1c411 - Date: 2026-03-11 ### redis-smaller-values-better-performance [IN] OBSERVATION Redis works best with smaller values; large data should be broken into smaller chunks across multiple keys. - Source: entries/2026/03/11/redis-best-practices.md - Source hash: be9f03cd23d9ad49 - Date: 2026-03-11 ### redis-supported-versions-4-and-6 [IN] OBSERVATION Azure Cache for Redis supports OSS Redis versions 4.0.x and 6.0.x; Redis 5.0 was skipped. - Source: entries/2026/03/11/redis-tiers.md - Source hash: deccd39ea90a84e4 - Date: 2026-03-11 ### redis-tls-12-required-by-default [IN] OBSERVATION Azure Cache for Redis requires TLS by default; TLS 1.2 is the recommended minimum version. - Source: entries/2026/03/10/redis-best-practices.md - Source hash: a047d725bfd7ac64 - Date: 2026-03-10 ### redis-use-hostname-not-ip [IN] OBSERVATION Azure Cache for Redis clients should use the DNS hostname, not public IP addresses, because IPs can change on scale or backend operations. - Source: entries/2026/03/10/redis-best-practices.md - Source hash: a047d725bfd7ac64 - Date: 2026-03-10 ### redis-version-5-skipped [IN] OBSERVATION Azure Cache for Redis skipped Redis version 5.0 — supported versions went from 4.0.x directly to 6.0.x. - Source: entries/2026/03/11/redis-overview.md - Source hash: 2c7d68916db1c411 - Date: 2026-03-11 ### redis-versions-4x-6x-skipped-5 [IN] OBSERVATION Azure Cache for Redis supports Redis versions 4.0.x and 6.0.x; version 5.0 was skipped. - Source: entries/2026/03/10/redis-tiers.md - Source hash: 594849f96a5c7b03 - Date: 2026-03-11 ### redis-vnet-fallback-when-no-tls [IN] OBSERVATION If TLS encrypted connections cannot be used with Azure Cache for Redis, placing cache and client inside a virtual network is the recommended mitigation. - Source: entries/2026/03/11/redis-best-practices.md - Source hash: be9f03cd23d9ad49 - Date: 2026-03-11 ### redis-vnet-fallback-when-tls-not-possible [IN] OBSERVATION If TLS encryption cannot be used with Azure Cache for Redis, placing cache and client inside a virtual network is the recommended mitigation. - Source: entries/2026/03/11/redis-best-practices.md - Source hash: be9f03cd23d9ad49 - Date: 2026-03-11 ### redis-zone-redundancy-not-basic [IN] OBSERVATION Azure Cache for Redis zone redundancy is available on Standard, Premium, and Enterprise tiers but not on Basic tier. - Source: entries/2026/03/10/redis-overview.md - Source hash: e04a9410d8e51b95 - Date: 2026-03-11 ### redis-zone-redundancy-standard-and-above [IN] OBSERVATION Azure Cache for Redis zone redundancy is available on Standard tier and above; Basic tier does not support zone redundancy. - Source: entries/2026/03/11/redis-tiers.md - Source hash: deccd39ea90a84e4 - Date: 2026-03-11 ### redis-zone-redundancy-standard-premium-enterprise [IN] OBSERVATION Azure Cache for Redis zone redundancy is available on Standard, Premium, and Enterprise tiers — not Basic. - Source: entries/2026/03/10/redis-tiers.md - Source hash: 594849f96a5c7b03 - Date: 2026-03-11 ### sas-token-security-hierarchy [IN] OBSERVATION 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-resource-level-granularity [IN] OBSERVATION Service endpoint policies provide resource-level granularity, allowing only specific Azure service resource instances (e.g., specific storage accounts) over service endpoints. - Source: entries/2026/03/11/vnet-service-endpoints.md - Source hash: b67307e3ae3272c1 - Date: 2026-03-11 ### service-endpoints-arm-only [IN] OBSERVATION VNet service endpoints are only available for VNets deployed via Azure Resource Manager (not classic deployment model). - Source: entries/2026/03/11/vnet-service-endpoints.md - Source hash: b67307e3ae3272c1 - Date: 2026-03-11 ### service-endpoints-arm-only-not-classic [IN] OBSERVATION VNet service endpoints are only available for Azure Resource Manager (ARM) deployments, not classic deployments. - Source: entries/2026/03/10/vnet-service-endpoints.md - Source hash: e9acb2ed1bb8de24 - Date: 2026-03-11 ### service-endpoints-arm-subnet-scoped-no-hybrid [IN] OBSERVATION 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. ### service-endpoints-azure-sql-same-region-only [IN] OBSERVATION For Azure SQL Database, service endpoint traffic applies only within the same region. - Source: entries/2026/03/11/vnet-service-endpoints.md - Source hash: b67307e3ae3272c1 - Date: 2026-03-11 ### service-endpoints-configured-per-subnet [IN] OBSERVATION VNet service endpoints are configured per-subnet, not per-VNet — each subnet must be independently enabled. - Source: entries/2026/03/10/vnet-service-endpoints.md - Source hash: e9acb2ed1bb8de24 - Date: 2026-03-10 ### service-endpoints-cross-tenant-storage-keyvault [IN] OBSERVATION VNet and service resource can be in different subscriptions; some services (Storage, Key Vault) support cross-tenant service endpoints. - Source: entries/2026/03/11/vnet-service-endpoints.md - Source hash: b67307e3ae3272c1 - Date: 2026-03-11 ### service-endpoints-disk-traffic-not-affected [IN] OBSERVATION Disk traffic (managed and unmanaged) is not affected by Azure Storage service endpoint routing changes. - Source: entries/2026/03/10/vnet-service-endpoints.md - Source hash: e9acb2ed1bb8de24 - Date: 2026-03-11 ### service-endpoints-dns-entries-unchanged [IN] OBSERVATION DNS entries for Azure services remain unchanged and continue resolving to public IPs even after enabling VNet service endpoints. - Source: entries/2026/03/10/vnet-service-endpoints.md - Source hash: e9acb2ed1bb8de24 - Date: 2026-03-11 ### service-endpoints-dns-unchanged [IN] OBSERVATION Enabling VNet service endpoints does not change DNS resolution — Azure service FQDNs still resolve to public IP addresses. - Source: entries/2026/03/11/vnet-service-endpoints.md - Source hash: b67307e3ae3272c1 - Date: 2026-03-11 ### service-endpoints-dns-unchanged-public-ips [IN] OBSERVATION DNS entries for Azure services remain unchanged when service endpoints are enabled — they still resolve to public IP addresses. - Source: entries/2026/03/11/vnet-service-endpoints.md - Source hash: b67307e3ae3272c1 - Date: 2026-03-11 ### service-endpoints-enabling-closes-tcp-connections [IN] OBSERVATION Enabling or disabling service endpoints closes existing TCP connections — should be avoided during critical operations. - Source: entries/2026/03/10/vnet-service-endpoints.md - Source hash: e9acb2ed1bb8de24 - Date: 2026-03-10 ### service-endpoints-max-200-associations [IN] OBSERVATION A VNet can be associated with up to 200 different subscriptions and regions per supported service when using service endpoints. - Source: entries/2026/03/11/vnet-service-endpoints.md - Source hash: b67307e3ae3272c1 - Date: 2026-03-11 ### service-endpoints-max-200-subscription-region-associations [IN] OBSERVATION A VNet can be associated with up to 200 different subscriptions and regions per supported service when using service endpoints. - Source: entries/2026/03/11/vnet-service-endpoints.md - Source hash: b67307e3ae3272c1 - Date: 2026-03-11 ### service-endpoints-no-cost-no-limit [IN] OBSERVATION VNet service endpoints have no additional cost and no limit on total service endpoints per VNet; maximum 200 subscriptions/regions per service. - Source: entries/2026/03/10/vnet-service-endpoints.md - Source hash: e9acb2ed1bb8de24 - Date: 2026-03-10 ### service-endpoints-no-on-premises-traffic [IN] OBSERVATION On-premises traffic cannot use VNet service endpoints; on-prem access to service-endpoint-secured resources requires IP firewall rules with NAT/public IPs. - Source: entries/2026/03/11/vnet-service-endpoints.md - Source hash: b67307e3ae3272c1 - Date: 2026-03-11 ### service-endpoints-not-available-from-on-premises [IN] OBSERVATION On-premises traffic cannot use VNet service endpoints; on-prem access to service-endpoint-secured resources requires IP firewall rules with NAT/public IPs. - Source: entries/2026/03/11/vnet-service-endpoints.md - Source hash: b67307e3ae3272c1 - Date: 2026-03-11 ### service-endpoints-not-for-on-premises-traffic [IN] OBSERVATION VNet service endpoints cannot be used for on-premises to Azure traffic; on-premises must use public/NAT IPs via IP firewall rules. - Source: entries/2026/03/10/vnet-service-endpoints.md - Source hash: e9acb2ed1bb8de24 - Date: 2026-03-11 ### service-endpoints-onprem-cannot-use [IN] OBSERVATION On-premises traffic cannot use VNet service endpoints — on-prem access to secured resources requires IP firewall rules with public/NAT IPs. - Source: entries/2026/03/11/vnet-service-endpoints.md - Source hash: b67307e3ae3272c1 - Date: 2026-03-11 ### service-endpoints-override-forced-tunneling [IN] OBSERVATION Service endpoint routes override forced-tunneling and UDRs for Azure service traffic, keeping it on the Azure backbone. - Source: entries/2026/03/10/vnet-service-endpoints.md - Source hash: e9acb2ed1bb8de24 - Date: 2026-03-10 ### service-endpoints-rbac-join-action-required [IN] OBSERVATION Enabling VNet service endpoints requires the RBAC permission Microsoft.Network/virtualNetworks/subnets/joinViaServiceEndpoint/action. - Source: entries/2026/03/10/vnet-service-endpoints.md - Source hash: e9acb2ed1bb8de24 - Date: 2026-03-11 ### service-endpoints-require-joinviaserviceendpoint-action [IN] OBSERVATION Enabling VNet service endpoints requires the RBAC permission `Microsoft.Network/virtualNetworks/subnets/joinViaServiceEndpoint/action`. - Source: entries/2026/03/10/vnet-service-endpoints.md - Source hash: e9acb2ed1bb8de24 - Date: 2026-03-11 ### service-endpoints-resource-manager-only [IN] OBSERVATION VNet service endpoints are only available for VNets deployed via Azure Resource Manager (not classic deployment model). - Source: entries/2026/03/11/vnet-service-endpoints.md - Source hash: b67307e3ae3272c1 - Date: 2026-03-11 ### service-endpoints-switch-source-ip-public-to-private [IN] OBSERVATION 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. - Source: entries/2026/03/10/vnet-service-endpoints.md - Source hash: e9acb2ed1bb8de24 - Date: 2026-03-10 ### service-tag-route-precedence-regional-over-toplevel [IN] OBSERVATION Service tag route precedence: Regional tag > Top-level tag > AzureCloud regional > AzureCloud; an explicit IP prefix always wins over a service tag. - Source: entries/2026/03/10/vnet-routing.md - Source hash: e235d55a05668d3b - Date: 2026-03-11 ### servicebus-auto-delete-idle-min-5min [IN] OBSERVATION Azure Service Bus auto-delete on idle minimum interval is 5 minutes. - Source: entries/2026/03/10/servicebus-overview.md - Source hash: 36dd266742cf1bec - Date: 2026-03-10 ### servicebus-auto-forwarding-same-namespace [IN] OBSERVATION Azure Service Bus auto-forwarding chains a queue or subscription to another queue or topic within the same namespace. - Source: entries/2026/03/10/servicebus-overview.md - Source hash: 36dd266742cf1bec - Date: 2026-03-11 ### servicebus-auto-forwarding-same-namespace-only [IN] OBSERVATION Azure Service Bus auto-forwarding chains a queue or subscription to another queue or topic only within the same namespace. - Source: entries/2026/03/11/servicebus-overview.md - Source hash: d816e1f20663ade9 - Date: 2026-03-11 ### servicebus-dlq-secondary-subqueue [IN] OBSERVATION Azure Service Bus dead-letter queue is a secondary subqueue on queues and topic subscriptions for holding undeliverable messages. - Source: entries/2026/03/10/servicebus-overview.md - Source hash: 36dd266742cf1bec - Date: 2026-03-10 ### servicebus-duplicate-detection [IN] OBSERVATION Azure Service Bus supports duplicate detection — queue or topic discards duplicate copies when a sender resends, enabling safe retries. - Source: entries/2026/03/11/servicebus-overview.md - Source hash: d816e1f20663ade9 - Date: 2026-03-11 ### servicebus-duplicate-detection-broker-level [IN] OBSERVATION Azure Service Bus duplicate detection discards duplicate copies at the broker level when a sender resends due to uncertain outcome. - Source: entries/2026/03/10/servicebus-overview.md - Source hash: 36dd266742cf1bec - Date: 2026-03-11 ### servicebus-exactly-once-requires-app-dedup [IN] OBSERVATION Azure Service Bus exactly-once processing requires application-level duplicate detection on top of Peek Lock mode. - Source: entries/2026/03/10/servicebus-queues-topics.md - Source hash: f28b26b73c9243cf - Date: 2026-03-10 ### servicebus-express-entities-not-supported-premium [IN] OBSERVATION Express entities are not supported in Azure Service Bus Premium namespaces. - Source: entries/2026/03/10/servicebus-premium.md - Source hash: 7f58120bda62cab6 - Date: 2026-03-10 ### servicebus-geo-replication-metadata-and-data [IN] OBSERVATION Azure Service Bus Premium Geo-Replication replicates both metadata and data (queues, topics, subscriptions, filters, message data, state changes, namespace configuration). - Source: entries/2026/03/10/servicebus-premium.md - Source hash: 7f58120bda62cab6 - Date: 2026-03-11 ### servicebus-jms-premium-2-standard-1-1-queues [IN] OBSERVATION Azure Service Bus Premium tier supports full JMS 2.0; Standard tier supports only JMS 1.1 for queues. - Source: entries/2026/03/11/servicebus-premium.md - Source hash: 8b980fccfb73e181 - Date: 2026-03-11 ### servicebus-large-message-batching-not-supported [IN] OBSERVATION Azure Service Bus large message batching is not supported. - Source: entries/2026/03/10/servicebus-premium.md - Source hash: 7f58120bda62cab6 - Date: 2026-03-11 ### servicebus-large-msg-sbmp-http-1mb-limit [IN] OBSERVATION Azure Service Bus large messages via SBMP or HTTP are capped at 1 MB even in Premium; only AMQP supports up to 100 MB. - Source: entries/2026/03/10/servicebus-premium.md - Source hash: 7f58120bda62cab6 - Date: 2026-03-10 ### servicebus-legacy-sdk-retire-sep-2026 [IN] OBSERVATION Azure Service Bus legacy SDKs (WindowsAzure.ServiceBus, Microsoft.Azure.ServiceBus, com.microsoft.azure.servicebus) retire 30 September 2026. - Source: entries/2026/03/10/servicebus-queues-topics.md - Source hash: f28b26b73c9243cf - Date: 2026-03-10 ### servicebus-load-leveling-average-not-peak [IN] OBSERVATION Azure Service Bus queues enable load leveling: consumers process at average load rather than peak load, reducing infrastructure requirements. - Source: entries/2026/03/11/servicebus-queues-topics.md - Source hash: 39b6b8b383d8c76a - Date: 2026-03-11 ### servicebus-message-sessions-enable-fifo [IN] OBSERVATION Azure Service Bus message sessions enable FIFO (first-in, first-out) guarantee and request-response patterns. - Source: entries/2026/03/11/servicebus-overview.md - Source hash: d816e1f20663ade9 - Date: 2026-03-11 ### servicebus-message-sessions-fifo [IN] OBSERVATION Azure Service Bus message sessions enable FIFO (first-in-first-out) guarantees and request-response patterns. - Source: entries/2026/03/10/servicebus-overview.md - Source hash: 36dd266742cf1bec - Date: 2026-03-11 ### servicebus-namespace-dozens-active-vms [IN] OBSERVATION Azure Service Bus namespace is a capacity slice of a large cluster spanning dozens of all-active VMs, optionally across three availability zones. - Source: entries/2026/03/11/servicebus-overview.md - Source hash: d816e1f20663ade9 - Date: 2026-03-11 ### servicebus-namespace-dozens-of-vms [IN] OBSERVATION An Azure Service Bus namespace spans dozens of all-active VMs, optionally across three availability zones. - Source: entries/2026/03/11/servicebus-overview.md - Source hash: d816e1f20663ade9 - Date: 2026-03-11 ### servicebus-namespace-spans-3-azs [IN] OBSERVATION Azure Service Bus namespaces optionally span 3 availability zones for zone-redundant storage. - Source: entries/2026/03/10/servicebus-overview.md - Source hash: 36dd266742cf1bec - Date: 2026-03-11 ### servicebus-peek-lock-at-least-once [IN] OBSERVATION Azure Service Bus Peek Lock mode provides at-least-once semantics via two-stage receive (lock then complete or abandon). - Source: entries/2026/03/10/servicebus-queues-topics.md - Source hash: f28b26b73c9243cf - Date: 2026-03-10 ### servicebus-peek-lock-three-failure-outcomes [IN] OBSERVATION 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. - Source: entries/2026/03/11/servicebus-queues-topics.md - Source hash: 39b6b8b383d8c76a - Date: 2026-03-11 ### servicebus-premium-cmk-encryption [IN] OBSERVATION Azure Service Bus customer-managed key (CMK) encryption for double encryption is a Premium-only feature, configured once at namespace creation. - Source: entries/2026/03/11/servicebus-premium.md - Source hash: 8b980fccfb73e181 - Date: 2026-03-11 ### servicebus-premium-cmk-encryption-one-time-setup [IN] OBSERVATION 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. - Source: entries/2026/03/11/servicebus-premium.md - Source hash: 8b980fccfb73e181 - Date: 2026-03-11 ### servicebus-premium-cmk-one-time-setup [IN] OBSERVATION Azure Service Bus Premium supports customer-managed key (CMK) encryption as a one-time setup per namespace. - Source: entries/2026/03/10/servicebus-premium.md - Source hash: 7f58120bda62cab6 - Date: 2026-03-11 ### servicebus-premium-cpu-scaling-thresholds [IN] OBSERVATION Azure Service Bus Premium scaling guidance: scale down below 20% CPU, scale up above 70% CPU. - Source: entries/2026/03/10/servicebus-premium.md - Source hash: 7f58120bda62cab6 - Date: 2026-03-10 ### servicebus-premium-geo-replication-metadata-and-data [IN] OBSERVATION 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. - Source: entries/2026/03/11/servicebus-premium.md - Source hash: 8b980fccfb73e181 - Date: 2026-03-11 ### servicebus-premium-jms-20-standard-jms-11 [IN] OBSERVATION Azure Service Bus Premium tier is fully JMS 2.0 compliant; Standard tier supports only JMS 1.1 subset (queues only). - Source: entries/2026/03/11/servicebus-overview.md - Source hash: d816e1f20663ade9 - Date: 2026-03-11 ### servicebus-premium-jms-20-standard-jms-11-queues [IN] OBSERVATION Azure Service Bus Premium tier supports full JMS 2.0; Standard tier supports only JMS 1.1 for queues. - Source: entries/2026/03/11/servicebus-overview.md - Source hash: d816e1f20663ade9 - Date: 2026-03-11 ### servicebus-premium-jms2-standard-jms1-queues-only [IN] OBSERVATION Azure Service Bus Premium supports JMS 1.1 and JMS 2.0; Standard supports only JMS 1.1 for queues. - Source: entries/2026/03/11/servicebus-premium.md - Source hash: 8b980fccfb73e181 - Date: 2026-03-11 ### servicebus-premium-jms2-standard-jms11 [IN] OBSERVATION Azure Service Bus Premium tier supports JMS 2.0; Standard tier supports only a JMS 1.1 subset for queues. - Source: entries/2026/03/10/servicebus-premium.md - Source hash: 7f58120bda62cab6 - Date: 2026-03-11 ### servicebus-premium-jms20-standard-jms11-subset [IN] OBSERVATION Azure Service Bus Premium tier is fully JMS 2.0 compliant; Standard tier supports only a JMS 1.1 subset focused on queues. - Source: entries/2026/03/10/servicebus-premium.md - Source hash: 7f58120bda62cab6 - Date: 2026-03-11 ### servicebus-premium-messaging-units-1-2-4-8-16 [IN] OBSERVATION Azure Service Bus Premium tier uses messaging units (MUs) for resource isolation; valid counts are 1, 2, 4, 8, or 16 per namespace. - Source: entries/2026/03/10/servicebus-premium.md - Source hash: 7f58120bda62cab6 - Date: 2026-03-10 ### servicebus-premium-mu-billing-hourly [IN] OBSERVATION Azure Service Bus Premium messaging unit (MU) billing is hourly; you only pay for additional MUs during the hours they are active. - Source: entries/2026/03/11/servicebus-premium.md - Source hash: 8b980fccfb73e181 - Date: 2026-03-11 ### servicebus-premium-network-security-features [IN] OBSERVATION Network security features (service tags, service endpoints, private endpoints, IP firewall via portal) are Azure Service Bus Premium-only. - Source: entries/2026/03/10/servicebus-premium.md - Source hash: 7f58120bda62cab6 - Date: 2026-03-10 ### servicebus-premium-partitioning-namespace-level [IN] OBSERVATION Azure Service Bus Premium partitioning is set at the namespace level (all entities partitioned); Standard/Basic partitioning is per-entity with 16 fixed partitions. - Source: entries/2026/03/10/servicebus-premium.md - Source hash: 7f58120bda62cab6 - Date: 2026-03-10 ### servicebus-primary-protocol-amqp [IN] OBSERVATION Azure Service Bus primary wire protocol is AMQP 1.0 (ISO/IEC standard); also supports HTTP/REST. - Source: entries/2026/03/10/servicebus-overview.md - Source hash: 36dd266742cf1bec - Date: 2026-03-10 ### servicebus-pull-mode-delivery [IN] OBSERVATION Azure Service Bus delivers messages via pull mode (long-lived pull), not push. - Source: entries/2026/03/10/servicebus-overview.md - Source hash: 36dd266742cf1bec - Date: 2026-03-10 ### servicebus-queue-point-to-point-topic-pub-sub [IN] OBSERVATION Azure Service Bus queues provide point-to-point messaging; topics provide publish/subscribe (one-to-many) messaging. - Source: entries/2026/03/10/servicebus-queues-topics.md - Source hash: f28b26b73c9243cf - Date: 2026-03-10 ### servicebus-receive-delete-at-most-once [IN] OBSERVATION Azure Service Bus Receive and Delete mode provides at-most-once semantics; message is lost if consumer crashes before processing. - Source: entries/2026/03/10/servicebus-queues-topics.md - Source hash: f28b26b73c9243cf - Date: 2026-03-10 ### servicebus-sbmp-retiring-sep-2026 [IN] OBSERVATION Azure Service Bus SBMP protocol is retiring September 30, 2026. - Source: entries/2026/03/10/servicebus-premium.md - Source hash: 7f58120bda62cab6 - Date: 2026-03-11 ### servicebus-security-sas-rbac-managed-identities [IN] OBSERVATION Azure Service Bus supports three security mechanisms: SAS (Shared Access Signatures), RBAC, and Managed Identities. - Source: entries/2026/03/10/servicebus-overview.md - Source hash: 36dd266742cf1bec - Date: 2026-03-11 ### servicebus-standard-max-256kb-premium-max-100mb [IN] OBSERVATION Azure Service Bus Standard tier max message size is 256 KB; Premium supports up to 100 MB (AMQP only). - Source: entries/2026/03/10/servicebus-premium.md - Source hash: 7f58120bda62cab6 - Date: 2026-03-10 ### servicebus-subscription-default-filter-true [IN] OBSERVATION Azure Service Bus subscription default rule is a true filter that selects all messages from the topic. - Source: entries/2026/03/10/servicebus-queues-topics.md - Source hash: f28b26b73c9243cf - Date: 2026-03-10 ### servicebus-subscription-rules-filter-plus-action [IN] OBSERVATION Azure Service Bus subscription rules consist of a filter (selects messages) and an optional action (modifies metadata). - Source: entries/2026/03/11/servicebus-overview.md - Source hash: d816e1f20663ade9 - Date: 2026-03-11 ### servicebus-subscriptions-durable-by-default [IN] OBSERVATION Azure Service Bus subscriptions are durable by default but can be configured to auto-expire. - Source: entries/2026/03/10/servicebus-overview.md - Source hash: 36dd266742cf1bec - Date: 2026-03-10 ### servicebus-transactions-single-entity [IN] OBSERVATION Azure Service Bus transactions scope to a single messaging entity (queue, topic, or subscription). - Source: entries/2026/03/10/servicebus-overview.md - Source hash: 36dd266742cf1bec - Date: 2026-03-10 ### servicebus-triple-redundant-storage [IN] OBSERVATION Azure Service Bus stores messages in triple-redundant storage, spanning availability zones if zone-enabled. - Source: entries/2026/03/10/servicebus-overview.md - Source hash: 36dd266742cf1bec - Date: 2026-03-10 ### smallest-subnet-29-gives-3-usable-ips [IN] OBSERVATION The smallest Azure subnet is /29 (8 IPs total), which yields only 3 usable IPs after the 5 reserved addresses. - Source: entries/2026/03/10/vnet-subnets.md - Source hash: 65ce293e7b4bbd7b - Date: 2026-03-10 ### storage-account-contributor-grants-key-access [IN] OBSERVATION Storage Account Contributor is a management plane role that provides access to account keys, enabling Shared Key authorization as an indirect data access path. - Source: entries/2026/03/10/rbac-built-in-roles.md - Source hash: 537994bcf7a587c3 - Date: 2026-03-10 ### storage-archive-not-supported-zrs-gzrs [IN] OBSERVATION Archive access tier is not supported on ZRS, GZRS, or RA-GZRS storage accounts. - Source: entries/2026/03/10/storage-redundancy.md - Source hash: b3f097a42931505d - Date: 2026-03-10 ### storage-blob-data-owner-includes-posix-acl [IN] OBSERVATION Storage Blob Data Owner provides full blob access including POSIX ACL management; Storage Blob Data Contributor provides read/write/delete but cannot manage ACLs. - Source: entries/2026/03/11/rbac-built-in-roles.md - Source hash: a6ab58d61750d4bf - Date: 2026-03-11 ### storage-blob-delegator-required-for-user-delegation-sas [IN] OBSERVATION The Storage Blob Delegator role is required to create user delegation SAS tokens signed with Azure AD. - Source: entries/2026/03/10/rbac-built-in-roles.md - Source hash: 537994bcf7a587c3 - Date: 2026-03-10 ### storage-delegator-roles-for-sas-not-data [IN] OBSERVATION 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. - Source: entries/2026/03/11/rbac-built-in-roles.md - Source hash: a6ab58d61750d4bf - Date: 2026-03-11 ### storage-firewall-blocks-all-by-default [IN] OBSERVATION 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. - Source: entries/2026/03/11/storage-security.md - Source hash: 07106caa167c5877 - Date: 2026-03-11 ### storage-geo-replication-async [IN] OBSERVATION Geo-replication (GRS/GZRS) is asynchronous, meaning potential data loss on primary region failure; failover is required for write access. - Source: entries/2026/03/10/storage-redundancy.md - Source hash: b3f097a42931505d - Date: 2026-03-10 ### storage-grs-gzrs-16-nines [IN] OBSERVATION GRS and GZRS both provide 16 nines durability; GRS uses LRS in primary, GZRS uses ZRS in primary; secondary always uses LRS. - Source: entries/2026/03/10/storage-redundancy.md - Source hash: b3f097a42931505d - Date: 2026-03-10 ### storage-gzrs-microsoft-recommended [IN] OBSERVATION GZRS is Microsoft's recommended redundancy option for maximum consistency, durability, availability, and disaster recovery performance. - Source: entries/2026/03/11/storage-redundancy.md - Source hash: b199b348e6151287 - Date: 2026-03-11 ### storage-gzrs-recommended-max-resilience [IN] OBSERVATION GZRS (Geo-Zone-Redundant Storage) is Microsoft's recommended redundancy option for maximum consistency, durability, availability, and disaster recovery. - Source: entries/2026/03/11/storage-redundancy.md - Source hash: b199b348e6151287 - Date: 2026-03-11 ### storage-lrs-11-nines-durability [IN] OBSERVATION LRS provides 11 nines (99.999999999%) durability by replicating data 3 times within a single datacenter. - Source: entries/2026/03/11/storage-redundancy.md - Source hash: b199b348e6151287 - Date: 2026-03-11 ### storage-lrs-3-replicas-single-datacenter [IN] OBSERVATION LRS replicates data 3 times synchronously within a single datacenter; provides 11 nines durability. - Source: entries/2026/03/10/storage-redundancy.md - Source hash: b3f097a42931505d - Date: 2026-03-10 ### storage-paired-region-cannot-be-changed [IN] OBSERVATION The geo-redundant secondary region is determined by Azure based on the primary region and cannot be changed by the customer. - Source: entries/2026/03/11/storage-redundancy.md - Source hash: b199b348e6151287 - Date: 2026-03-11 ### storage-ra-grs-read-availability-9999 [IN] OBSERVATION RA-GRS and RA-GZRS provide 99.99% read availability for the hot tier by allowing reads from the secondary region without failover. - Source: entries/2026/03/10/storage-redundancy.md - Source hash: b3f097a42931505d - Date: 2026-03-10 ### storage-redundancy-shared-across-all-services [IN] OBSERVATION The redundancy setting is shared across all storage services (Blob, Files, Table, Queue) within a storage account. - Source: entries/2026/03/11/storage-redundancy.md - Source hash: b199b348e6151287 - Date: 2026-03-11 ### storage-secondary-endpoint-suffix [IN] OBSERVATION 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. - Source: entries/2026/03/10/storage-redundancy.md - Source hash: b3f097a42931505d - Date: 2026-03-11 ### storage-secondary-endpoint-suffix-secondary [IN] OBSERVATION 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. - Source: entries/2026/03/11/storage-redundancy.md - Source hash: b199b348e6151287 - Date: 2026-03-11 ### storage-secondary-region-paired-cannot-change [IN] OBSERVATION The geo-redundant secondary region is determined by Azure based on the primary region's paired region and cannot be changed by the customer. - Source: entries/2026/03/11/storage-redundancy.md - Source hash: b199b348e6151287 - Date: 2026-03-11 ### storage-storagev2-all-redundancy-options [IN] OBSERVATION Standard general-purpose v2 (StorageV2) is the only storage account type that supports all redundancy options (LRS, ZRS, GRS, RA-GRS, GZRS, RA-GZRS). - Source: entries/2026/03/10/storage-redundancy.md - Source hash: b3f097a42931505d - Date: 2026-03-11 ### storage-unmanaged-disks-no-zrs-gzrs [IN] OBSERVATION Unmanaged disks do not support ZRS or GZRS redundancy options. - Source: entries/2026/03/11/storage-redundancy.md - Source hash: b199b348e6151287 - Date: 2026-03-11 ### storage-write-availability-sla-999-hot [IN] OBSERVATION Azure Storage write availability SLA is 99.9% for the hot tier and 99% for cool, cold, and archive tiers across all redundancy options. - Source: entries/2026/03/10/storage-redundancy.md - Source hash: b3f097a42931505d - Date: 2026-03-11 ### storage-zrs-12-nines-durability [IN] OBSERVATION ZRS provides 12 nines (99.9999999999%) durability by replicating data synchronously across 3+ availability zones. - Source: entries/2026/03/11/storage-redundancy.md - Source hash: b199b348e6151287 - Date: 2026-03-11 ### storage-zrs-3-availability-zones [IN] OBSERVATION ZRS replicates data synchronously across 3+ availability zones in the primary region; provides 12 nines durability. - Source: entries/2026/03/10/storage-redundancy.md - Source hash: b3f097a42931505d - Date: 2026-03-10 ### storage-zrs-recommended-datalake-files [IN] OBSERVATION ZRS is Microsoft's recommended redundancy option for Azure Data Lake Storage and Azure Files workloads. - Source: entries/2026/03/11/storage-redundancy.md - Source hash: b199b348e6151287 - Date: 2026-03-11 ### subnet-cannot-delete-with-resources [IN] OBSERVATION A subnet can only be deleted if it contains no resources; resources must be removed first. - Source: entries/2026/03/10/vnet-subnets.md - Source hash: 65ce293e7b4bbd7b - Date: 2026-03-11 ### subnet-delegation-cannot-remove-with-deployed-resources [IN] OBSERVATION Subnet delegation cannot be removed if the delegated service still has resources deployed in the subnet. - Source: entries/2026/03/10/vnet-subnets.md - Source hash: 65ce293e7b4bbd7b - Date: 2026-03-10 ### subnet-join-requires-join-action-rbac [IN] OBSERVATION Subnet operations require Network Contributor role or custom role with `Microsoft.Network/virtualNetworks/subnets/*` actions; joining requires `Microsoft.Network/virtualNetworks/subnets/join/action`. - Source: entries/2026/03/10/vnet-subnets.md - Source hash: 65ce293e7b4bbd7b - Date: 2026-03-11 ### subnet-names-should-start-with-letter [IN] OBSERVATION Subnet names should start with a letter, not a number — Application Gateway won't deploy to subnets with numeric-starting names. - Source: entries/2026/03/10/vnet-subnets.md - Source hash: 65ce293e7b4bbd7b - Date: 2026-03-10 ### subnet-nat-nsg-route-table-same-subscription-location [IN] OBSERVATION NAT gateway, NSG, and route table associated with a subnet must be in the same subscription and location as the VNet. - Source: entries/2026/03/11/vnet-subnets.md - Source hash: d70de809fbdd3d75 - Date: 2026-03-11 ### subnet-network-policy-controls-private-endpoint-nsg [IN] OBSERVATION Subnet network policy for private endpoints controls whether NSGs and route tables apply to private endpoints on the subnet. - Source: entries/2026/03/10/vnet-subnets.md - Source hash: 65ce293e7b4bbd7b - Date: 2026-03-11 ### subnet-private-preview-no-default-outbound [IN] OBSERVATION Private Subnet (Preview) prevents default outbound internet access for VMs deployed in the subnet. - Source: entries/2026/03/11/vnet-subnets.md - Source hash: d70de809fbdd3d75 - Date: 2026-03-11 ### subnet-private-preview-prevents-default-outbound [IN] OBSERVATION Private Subnet (Preview) prevents default outbound internet access for VMs deployed in the subnet. - Source: entries/2026/03/10/vnet-subnets.md - Source hash: 65ce293e7b4bbd7b - Date: 2026-03-11 ### udr-virtual-network-gateway-next-hop-vpn-only [IN] OBSERVATION 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). - Source: entries/2026/03/10/vnet-routing.md - Source hash: e235d55a05668d3b - Date: 2026-03-11 ### udr-virtual-network-gateway-vpn-only [IN] OBSERVATION 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). - Source: entries/2026/03/10/vnet-routing.md - Source hash: e235d55a05668d3b - Date: 2026-03-11 ### vm-contributor-no-vnet-storage-access [IN] OBSERVATION Virtual Machine Contributor does not grant access to the virtual network or storage account the VM connects to, and cannot assign RBAC roles. - Source: entries/2026/03/11/rbac-built-in-roles.md - Source hash: a6ab58d61750d4bf - Date: 2026-03-11 ### vm-ephemeral-storage-operational-model [IN] OBSERVATION 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. ### vmss-all-instances-same-base-image [IN] OBSERVATION All VM instances in a scale set are created from the same base OS image and configuration. - Source: entries/2026/03/11/vm-scale-sets.md - Source hash: 7c4c932daee55fde - Date: 2026-03-11 ### vmss-flexible-supports-spot-and-ondemand-mix [IN] OBSERVATION VMSS Flexible orchestration supports mixing Spot and on-demand VM instances together in the same scale set. - Source: entries/2026/03/11/vm-scale-sets.md - Source hash: 7c4c932daee55fde - Date: 2026-03-11 ### vmss-immutable-infrastructure-model [IN] OBSERVATION 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. ### vnet-default-route-0000-internet [IN] OBSERVATION 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. - Source: entries/2026/03/11/vnet-routing.md - Source hash: 2c51a396b7832ca2 - Date: 2026-03-11 ### vnet-default-routes-rfc1918-drop [IN] OBSERVATION 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. - Source: entries/2026/03/10/vnet-routing.md - Source hash: e235d55a05668d3b - Date: 2026-03-10 ### vnet-gateway-hierarchy-routeserver-expressroute-vpn [IN] OBSERVATION When multiple gateways are deployed, the hierarchy is: Route Server > ExpressRoute > VPN. - Source: entries/2026/03/10/vnet-routing.md - Source hash: e235d55a05668d3b - Date: 2026-03-10 ### vnet-nva-deploy-different-subnet-avoid-loop [IN] OBSERVATION Virtual appliances (NVAs) should be deployed in a different subnet than the routed resources to avoid routing loops. - Source: entries/2026/03/11/vnet-routing.md - Source hash: 2c51a396b7832ca2 - Date: 2026-03-11 ### vnet-private-range-added-changes-next-hop [IN] OBSERVATION 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. - Source: entries/2026/03/10/vnet-routing.md - Source hash: e235d55a05668d3b - Date: 2026-03-11 ### vnet-private-range-added-changes-nexthop-to-virtualnetwork [IN] OBSERVATION 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. - Source: entries/2026/03/10/vnet-routing.md - Source hash: e235d55a05668d3b - Date: 2026-03-11 ### vnet-rfc1918-assigned-changes-next-hop-to-virtual-network [IN] OBSERVATION 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. - Source: entries/2026/03/11/vnet-routing.md - Source hash: 2c51a396b7832ca2 - Date: 2026-03-11 ### vnet-rfc1918-assigned-changes-nexthop-to-virtualnetwork [IN] OBSERVATION 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. - Source: entries/2026/03/11/vnet-routing.md - Source hash: 2c51a396b7832ca2 - Date: 2026-03-11 ### vnet-route-propagation-never-disable-gatewaysubnet [IN] OBSERVATION Route propagation from gateways can be disabled per-subnet, but must never be disabled on the GatewaySubnet or the gateway will stop functioning. - Source: entries/2026/03/11/vnet-routing.md - Source hash: 2c51a396b7832ca2 - Date: 2026-03-11 ### vnet-route-selection-priority-udr-bgp-system [IN] OBSERVATION 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). - Source: entries/2026/03/10/vnet-routing.md - Source hash: e235d55a05668d3b - Date: 2026-03-10 ### vnet-route-server-precedence-over-vpn-expressroute [IN] OBSERVATION Route Server takes precedence over VPN and ExpressRoute gateways when deployed in the same VNet. - Source: entries/2026/03/10/vnet-routing.md - Source hash: e235d55a05668d3b - Date: 2026-03-11 ### vnet-routing-longest-prefix-match [IN] OBSERVATION Azure VNet routing uses longest-prefix match to determine which route wins among same-priority routes. - Source: entries/2026/03/10/vnet-routing.md - Source hash: e235d55a05668d3b - Date: 2026-03-10 ### vnet-service-endpoint-routes-override-bgp-and-udr [IN] OBSERVATION 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. - Source: entries/2026/03/11/vnet-routing.md - Source hash: 2c51a396b7832ca2 - Date: 2026-03-11 ### vnet-service-tag-priority-regional-first [IN] OBSERVATION Service tag route priority order: regional tags (e.g., Storage.EastUS) > top-level tags (e.g., Storage) > AzureCloud regional tags > AzureCloud tag. - Source: entries/2026/03/11/vnet-routing.md - Source hash: 2c51a396b7832ca2 - Date: 2026-03-11 ### vnet-service-tag-routes-max-25-per-table [IN] OBSERVATION Maximum 25 service-tag routes per route table in Azure UDRs. - Source: entries/2026/03/10/vnet-routing.md - Source hash: e235d55a05668d3b - Date: 2026-03-10 ### vnet-system-routes-auto-created-cannot-delete [IN] OBSERVATION System routes are automatically created per subnet and cannot be deleted, only overridden by UDRs or BGP routes. - Source: entries/2026/03/10/vnet-routing.md - Source hash: e235d55a05668d3b - Date: 2026-03-11 ### vnet-system-routes-cannot-be-deleted [IN] OBSERVATION System routes are automatically created per subnet and cannot be deleted, only overridden by UDRs or BGP routes. - Source: entries/2026/03/10/vnet-routing.md - Source hash: e235d55a05668d3b - Date: 2026-03-11 ### vnet-udr-limit-400-expandable-to-1000 [IN] OBSERVATION Default UDR limit per route table is 400, expandable to 1,000 with Azure Virtual Network Manager. - Source: entries/2026/03/10/vnet-routing.md - Source hash: e235d55a05668d3b - Date: 2026-03-10 ### vnet-virtual-appliance-different-subnet-avoid-loop [IN] OBSERVATION Virtual appliances must be deployed in a different subnet than the routed resources to avoid routing loops. - Source: entries/2026/03/11/vnet-routing.md - Source hash: 2c51a396b7832ca2 - Date: 2026-03-11 ### vnet-vpn-expressroute-coexist-expressroute-precedence [IN] OBSERVATION When VPN and ExpressRoute gateways coexist without Route Server, the ExpressRoute gateway takes precedence as the VNet gateway. - Source: entries/2026/03/11/vnet-routing.md - Source hash: 2c51a396b7832ca2 - Date: 2026-03-11 ### waf-five-pillars [IN] OBSERVATION The Azure Well-Architected Framework has five pillars: Reliability, Security, Cost Optimization, Operational Excellence, and Performance Efficiency. - Source: entries/2026/03/10/waf-overview.md - Source hash: 6097aa3bedfa31b9 - Date: 2026-03-10 ### waf-includes-assessment-tool [IN] OBSERVATION The Azure Well-Architected Framework includes an interactive assessment tool (Azure Architecture Review) for evaluating workloads against WAF principles. - Source: entries/2026/03/10/waf-overview.md - Source hash: 6097aa3bedfa31b9 - Date: 2026-03-10 ### waf-l7-ddos-protection-l3l4 [IN] OBSERVATION WAF protects at Layer 7; Azure DDoS Protection protects at Layer 3/4 — they are complementary - Source: entries/2026/03/10/appgw-overview.md - Source hash: 3c804b6bec0a5478 - Date: 2026-03-10 ### waf-mission-critical-always-available-guidance [IN] OBSERVATION Mission-critical workloads have dedicated WAF guidance focused on always-available, failure-resilient design. - Source: entries/2026/03/11/waf-overview.md - Source hash: 60abb83ca7865308 - Date: 2026-03-11 ### waf-mission-critical-dedicated-guidance [IN] OBSERVATION Mission-critical workloads have dedicated WAF guidance focused on always-available, failure-resilient design. - Source: entries/2026/03/10/waf-overview.md - Source hash: 6097aa3bedfa31b9 - Date: 2026-03-11 ### waf-provides-workload-specific-lenses [IN] OBSERVATION 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. - Source: entries/2026/03/10/waf-overview.md - Source hash: 6097aa3bedfa31b9 - Date: 2026-03-10 ### waf-reliability-disaster-recovery-and-testing-complementary [IN] OBSERVATION Disaster recovery and testing strategies are distinct but complementary practices within the WAF Reliability pillar. - Source: entries/2026/03/10/waf-reliability.md - Source hash: c706e67e28c0714e - Date: 2026-03-11 ### waf-reliability-disaster-recovery-and-testing-distinct [IN] OBSERVATION In the WAF Reliability pillar, disaster recovery and testing strategies are distinct but complementary practices. - Source: entries/2026/03/10/waf-reliability.md - Source hash: c706e67e28c0714e - Date: 2026-03-11 ### waf-reliability-five-design-principles [IN] OBSERVATION 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. - Source: entries/2026/03/10/waf-reliability.md - Source hash: c706e67e28c0714e - Date: 2026-03-10 ### waf-reliability-four-strategies [IN] OBSERVATION Reliability in WAF is achieved through four strategies: redundancy, scaling, self-healing/preservation, and simplicity. - Source: entries/2026/03/10/waf-reliability.md - Source hash: c706e67e28c0714e - Date: 2026-03-10 ### waf-reliability-maturity-model [IN] OBSERVATION The WAF Reliability pillar includes a maturity model for assessing reliability posture progression. - Source: entries/2026/03/10/waf-reliability.md - Source hash: c706e67e28c0714e - Date: 2026-03-10 ### waf-reliability-sre-complementary [IN] OBSERVATION Site Reliability Engineering (SRE) is identified as a complementary operational discipline to the WAF Reliability pillar for maintaining reliability in production. - Source: entries/2026/03/11/waf-reliability.md - Source hash: ba069c7ef6970408 - Date: 2026-03-11 ### waf-reliability-target-process [IN] OBSERVATION Reliability target planning follows a four-step flow: identify flows → failure mode analysis → set targets → monitoring/alerting. - Source: entries/2026/03/10/waf-reliability.md - Source hash: c706e67e28c0714e - Date: 2026-03-10 ### waf-reliability-testing-and-dr-distinct [IN] OBSERVATION Testing strategy and disaster recovery strategy are distinct but related reliability activities within the WAF Reliability pillar. - Source: entries/2026/03/11/waf-reliability.md - Source hash: ba069c7ef6970408 - Date: 2026-03-11 ### waf-reliability-testing-and-dr-drills [IN] OBSERVATION Testing strategy and disaster recovery drills are distinct but related activities within the WAF Reliability pillar discipline. - Source: entries/2026/03/11/waf-reliability.md - Source hash: ba069c7ef6970408 - Date: 2026-03-11 ### waf-security-asset-protection-layers [IN] OBSERVATION WAF security asset protection covers: segmentation, identity & access management, network protection, encryption, resource hardening, and secrets management. - Source: entries/2026/03/10/waf-security.md - Source hash: a29b9ac02e1f9e3c - Date: 2026-03-10 ### waf-security-cia-triad [IN] OBSERVATION The three security objectives of the WAF Security pillar are the CIA triad: Confidentiality, Integrity, and Availability. - Source: entries/2026/03/10/waf-security.md - Source hash: a29b9ac02e1f9e3c - Date: 2026-03-11 ### waf-security-cia-triad-structure [IN] OBSERVATION The WAF Security pillar is organized around the CIA triad (confidentiality, integrity, and availability). - Source: entries/2026/03/11/waf-security.md - Source hash: 8d4db94cc716a02a - Date: 2026-03-11 ### waf-security-defense-in-depth [IN] OBSERVATION Defense in depth is the overarching security strategy Azure recommends in the WAF Security pillar. - Source: entries/2026/03/10/waf-security.md - Source hash: a29b9ac02e1f9e3c - Date: 2026-03-10 ### waf-security-five-design-principles [IN] OBSERVATION 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. - Source: entries/2026/03/10/waf-security.md - Source hash: a29b9ac02e1f9e3c - Date: 2026-03-10 ### waf-security-foundation-sequence [IN] OBSERVATION The WAF security foundation sequence is: security baselines → secure development lifecycle (SDL) → data classification → threat monitoring → threat modeling. - Source: entries/2026/03/10/waf-security.md - Source hash: a29b9ac02e1f9e3c - Date: 2026-03-10 ### waf-security-maturity-model [IN] OBSERVATION The WAF Security pillar includes a formal security maturity model for assessing organizational readiness. - Source: entries/2026/03/10/waf-security.md - Source hash: a29b9ac02e1f9e3c - Date: 2026-03-10 ### waf-security-organized-around-cia-triad [IN] OBSERVATION The WAF Security pillar is organized around the CIA triad: confidentiality, integrity, and availability. - Source: entries/2026/03/11/waf-security.md - Source hash: 8d4db94cc716a02a - Date: 2026-03-11 ### waf-security-validation-loop-continuous [IN] OBSERVATION The WAF Security pillar treats security testing and incident response as a continuous improvement validation loop, not a one-time activity. - Source: entries/2026/03/11/waf-security.md - Source hash: 8d4db94cc716a02a - Date: 2026-03-11 ### waf-service-guides-per-azure-service [IN] OBSERVATION The Azure Well-Architected Framework provides per-service WAF service guides with pillar-specific recommendations for individual Azure services. - Source: entries/2026/03/10/waf-overview.md - Source hash: 6097aa3bedfa31b9 - Date: 2026-03-11 ### waf-service-guides-per-service [IN] OBSERVATION The Azure Well-Architected Framework provides per-service service guides with pillar-specific recommendations for individual Azure services. - Source: entries/2026/03/10/waf-overview.md - Source hash: 6097aa3bedfa31b9 - Date: 2026-03-11 ### waf-service-guides-per-service-recommendations [IN] OBSERVATION WAF service guides provide per-service architectural recommendations aligned with WAF pillars, bridging framework-level principles and individual Azure service configuration. - Source: entries/2026/03/11/waf-overview.md - Source hash: 60abb83ca7865308 - Date: 2026-03-11 ### acr-unified-security-model [OUT] OBSERVATION 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-full-zero-trust-secrets-at-rest [OUT] OBSERVATION 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-runtime-security-defense-in-depth [OUT] OBSERVATION 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-secrets-end-to-end-protected [OUT] OBSERVATION 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-storage-complete-cross-os [OUT] OBSERVATION 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-zero-trust-infrastructure-inheritance [OUT] OBSERVATION 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. ### appservice-secret-injection-network-isolated [OUT] OBSERVATION 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-co-design-mandate [OUT] OBSERVATION 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. ### azure-architecture-substrate-within-tier-envelope [OUT] OBSERVATION 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-redis-stable-tier-investment [OUT] OBSERVATION Azure Cache for Redis provides a stable, production-grade caching platform with progressive tier capabilities from Standard through Enterprise Flash. ### azure-compute-encryption-fully-verified [OUT] OBSERVATION 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. ### azure-compute-secret-isolation-platform-independent [OUT] OBSERVATION 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. ### azure-container-isolation-follows-platform-pattern [OUT] OBSERVATION 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. ### azure-container-isolation-tier-cascade-instance [OUT] OBSERVATION 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-design-triple-constraint-cascade [OUT] OBSERVATION 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-complete-hybrid-resolution [OUT] OBSERVATION 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. ### azure-dns-operational-risk-compounds-zero-trust [OUT] OBSERVATION 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-infrastructure-coupled-to-asymmetries [OUT] OBSERVATION 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-five-dimension-security-fully-orthogonal [OUT] OBSERVATION 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-governance-dns-hidden-coupling [OUT] OBSERVATION 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-governance-network-orthogonal-security-planes [OUT] OBSERVATION 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-identity-convergence-reinforces-security-pillars [OUT] OBSERVATION 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-drives-key-protection-scope [OUT] OBSERVATION 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-identity-verified-end-to-end-data-plane [OUT] OBSERVATION 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-trilemma-resolution-required [OUT] OBSERVATION 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-complete-observability-chain [OUT] OBSERVATION 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-complete-workspace-coverage [OUT] OBSERVATION 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-fully-actionable-all-table-plans [OUT] OBSERVATION 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-dual-layer-filtering [OUT] OBSERVATION 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-network-isolation-infrastructure-to-paas [OUT] OBSERVATION 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-network-zero-trust-infrastructure-stack [OUT] OBSERVATION 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-security-circular-dependency [OUT] OBSERVATION 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-security-codesign-tier-bounded [OUT] OBSERVATION 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-dual-layer-requirement [OUT] OBSERVATION 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. ### azure-peering-extends-zero-trust-across-vnets [OUT] OBSERVATION 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-platform-security-three-pillar-convergence [OUT] OBSERVATION 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-secure-workload-isolation-fully-identity-verified [OUT] OBSERVATION 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-security-five-dimension-enforcement [OUT] OBSERVATION 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-vm-viable-mixed-production-workload [OUT] OBSERVATION 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-defense-in-depth-complete [OUT] OBSERVATION 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-full-geo-read-access [OUT] OBSERVATION 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-cost-security-capability-trilemma [OUT] OBSERVATION 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-five-dimension-isolation-complete [OUT] OBSERVATION 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. ### azure-workload-isolation-network-to-secrets [OUT] OBSERVATION 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. ### azure-workload-isolation-substrate-independent [OUT] OBSERVATION 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. ### azuresql-backup-uniform-compression [OUT] OBSERVATION Azure SQL automated backups achieve uniform 3–4x compression across full, differential, and transaction log backup types at the configured frequency. ### azuresql-comprehensive-backup-resilience [OUT] OBSERVATION 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. ### azuresql-migration-with-full-data-protection [OUT] OBSERVATION 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-identity-verified-defense-in-depth [OUT] OBSERVATION 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-identity-unified [OUT] OBSERVATION 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. ### entra-identity-keyvault-secrets-lifecycle-integration [OUT] OBSERVATION 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. ### eventhubs-kafka-production-feature-complete [OUT] OBSERVATION 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. ### eventhubs-kafka-seamless-topology-migration [OUT] OBSERVATION 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. ### functions-full-network-isolation [OUT] OBSERVATION Azure Functions supports full network isolation with private endpoints, VNet integration, and subnet-scoped outbound control across Premium and Dedicated hosting plans. ### keyvault-rbac-complete-access-model [OUT] OBSERVATION 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. ### lb-complete-layer-4-traffic-model [OUT] OBSERVATION 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-complete-module-platform [OUT] OBSERVATION 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. ### servicebus-premium-complete-jms-platform [OUT] OBSERVATION 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. ### servicebus-premium-geo-replicated-enterprise-messaging [OUT] OBSERVATION Azure Service Bus Premium provides enterprise messaging with full geographic replication (metadata and data) and dedicated resource isolation (1–16 messaging units per namespace). ### servicebus-reliable-messaging-complete [OUT] OBSERVATION 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-global-peering-full-lb-reachability [OUT] OBSERVATION VNet peering provides full load balancer reachability across regions with latency parity to single-VNet deployments within the same region.