# Belief Registry ## 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. ### 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. ### acr-admin-password-regen-60-seconds [IN] OBSERVATION ACR admin account password regeneration takes approximately 60 seconds to replicate. ### acr-admin-password-regeneration-60-seconds [IN] OBSERVATION Password regeneration for ACR admin accounts takes approximately 60 seconds to replicate. ### acr-all-transfers-https-tls [IN] OBSERVATION All ACR image transfers use HTTPS with TLS encryption. ### acr-api-rate-limits-per-replica [IN] OBSERVATION ACR API rate limits (throttling) apply independently per geo-replica, not globally across the registry. ### 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. ### acr-auth-token-valid-3-hours [IN] OBSERVATION The access token from `az acr login` is valid for 3 hours and must be renewed. ### acr-authentication-entra-service-principal-admin [IN] OBSERVATION ACR authentication options are Azure identity, Microsoft Entra service principal, or admin account. ### 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. ### acr-content-trust-premium-only [IN] OBSERVATION Content trust (image tag signing) in ACR is a Premium-only feature. ### 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. ### 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. ### 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. ### 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`. ### 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`. ### 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. ### acr-geo-api-rate-limits-per-replica [IN] OBSERVATION ACR API rate limits (read/write throttling) apply independently to each geo-replica. ### 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. ### acr-geo-replica-zone-redundancy-auto-enabled [IN] OBSERVATION Zone redundancy is automatically enabled for ACR geo-replicas in regions that support it. ### 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. ### 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. ### 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. ### 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. ### 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. ### acr-geo-replication-requires-premium [IN] OBSERVATION ACR geo-replication requires the Premium SKU. ### acr-geo-replication-requires-premium-sku [IN] OBSERVATION ACR geo-replication requires the Premium SKU. ### 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. ### 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. ### 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. ### 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. ### acr-login-token-valid-3-hours [IN] OBSERVATION Individual login tokens from `az acr login` are valid for 3 hours and must be renewed. ### 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. ### acr-max-image-layer-size-200gib [IN] OBSERVATION ACR maximum image layer size is 200 GiB across all SKUs. ### acr-max-storage-basic-standard-40tib-premium-100tib [IN] OBSERVATION ACR maximum storage limits: Basic/Standard max 40 TiB, Premium max 100 TiB. ### 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. ### acr-non-entra-tokens-basic-100-standard-500-premium-50000 [IN] OBSERVATION ACR non-Entra token limits: Basic 100, Standard 500, Premium 50,000. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### acr-service-principal-password-default-1-year [IN] OBSERVATION ACR service principal passwords have a default expiry of 1 year. ### acr-service-principal-password-default-expiry-1-year [IN] OBSERVATION ACR service principal passwords have a default expiry of 1 year. ### 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). ### acr-supports-docker-helm-oci-artifacts [IN] OBSERVATION ACR supports Docker container images (Windows and Linux), Helm charts, and OCI-format images. ### acr-supports-oci-and-helm-charts [IN] OBSERVATION ACR supports Docker container images, OCI-format images, and Helm charts as stored artifacts. ### 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. ### acr-three-sku-tiers [IN] OBSERVATION Azure Container Registry offers three SKU tiers: Basic (dev/test), Standard (most production), and Premium (high-volume/enterprise). ### acr-three-skus-basic-standard-premium [IN] OBSERVATION ACR offers three SKU tiers: Basic (dev/test), Standard (production), Premium (high-volume/enterprise). ### 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. ### 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. ### 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. ### acr-untagged-manifest-retention-policy [IN] OBSERVATION Untagged (dangling/orphaned) container images in ACR can be managed via a retention policy for untagged manifests. ### acr-untagged-manifests-retention-policy [IN] OBSERVATION Untagged (dangling/orphaned) container images in ACR can be managed via a retention policy for untagged manifests. ### acr-webhooks-basic-2-standard-10-premium-500 [IN] OBSERVATION ACR webhook limits: Basic 2, Standard 10, Premium 500. ### 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. ### 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. ### 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. ### 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. ### 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. ### aks-apparmor-seccomp-container-restriction [IN] OBSERVATION AKS supports AppArmor and seccomp profiles to restrict container actions following the principle of least privilege. ### aks-apparmor-seccomp-container-restrictions [IN] OBSERVATION AKS supports AppArmor and seccomp profiles to restrict container actions following the least-privilege principle. ### aks-azure-disk-readwriteonce [IN] OBSERVATION Azure Disk volumes in AKS are mounted as ReadWriteOnce (single node); Azure Files supports ReadWriteMany (multi-node) ### 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. ### 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. ### 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. ### aks-cncf-certified [IN] OBSERVATION AKS is a CNCF-certified conformant Kubernetes distribution. ### aks-cncf-certified-conformance [IN] OBSERVATION AKS is CNCF-certified, meaning it passes Kubernetes conformance testing. ### aks-cncf-certified-kubernetes [IN] OBSERVATION AKS is CNCF-certified, meaning it passes official Kubernetes conformance testing. ### aks-compliance-soc-iso-pci-hipaa [IN] OBSERVATION AKS is compliant with SOC, ISO, PCI DSS, and HIPAA standards. ### aks-confidential-computing-hardware-tee [IN] OBSERVATION AKS supports confidential computing nodes that run containers in hardware-based trusted execution environments (TEE). ### 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. ### 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+). ### aks-control-plane-free [IN] OBSERVATION The AKS control plane is provided at no cost; users only pay for worker nodes. ### 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. ### 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). ### 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). ### 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 ### 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. ### 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. ### 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. ### 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 ### aks-default-namespaces-four [IN] OBSERVATION AKS clusters include four default namespaces: `default`, `kube-node-lease`, `kube-public`, and `kube-system`. ### 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. ### 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. ### aks-default-storage-class-managed-csi [IN] OBSERVATION AKS default storage class is `managed-csi` backed by Standard SSD LRS ### aks-default-storage-classes-reconciled [IN] OBSERVATION AKS reconciles built-in default storage classes — manual changes to them are overwritten by the platform. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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+). ### 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. ### 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. ### aks-istio-service-mesh-addon [IN] OBSERVATION AKS offers an Istio-based service mesh add-on as a managed option. ### aks-kube-proxy-every-node [IN] OBSERVATION kube-proxy runs on every AKS node to provide network features. ### aks-managed-disks-encrypted-at-rest [IN] OBSERVATION AKS node storage uses Azure Managed Disks with automatic encryption at rest. ### aks-managed-helm-prefix [IN] OBSERVATION AKS manages Helm releases prefixed with `aks-managed` and labels managed components with `kubernetes.azure.com/managedby: aks`. ### 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. ### 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 ### aks-multi-az-zrs-default-k8s-1-29 [IN] OBSERVATION AKS multi-AZ clusters default to ZRS storage from Kubernetes 1.29 ### 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. ### 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. ### 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. ### 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. ### 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. ### aks-nodes-no-public-ip [IN] OBSERVATION AKS nodes have no public IP addresses by default and are deployed to private subnets. ### 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. ### aks-notary-v2-image-signing [IN] OBSERVATION AKS supports Notary V2 to attach signatures to container images for trusted deployment verification. ### 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. ### 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. ### 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. ### aks-os-disk-size-immutable [IN] OBSERVATION AKS OS disk size cannot be changed after cluster or node pool creation ### 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. ### 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). ### aks-pv-not-shared-windows-linux [IN] OBSERVATION Persistent volumes cannot be shared between Windows and Linux pods in AKS ### 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. ### 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. ### 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. ### aks-registry-signatures-notary-v2 [IN] OBSERVATION Azure secure supply chain uses Notary V2 to attach signatures to container images for trusted deployment verification. ### 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. ### 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. ### 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. ### aks-secrets-base64-not-encrypted [IN] OBSERVATION Raw Kubernetes secret manifests contain data in base64 format, which is encoding, not encryption. ### 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. ### 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. ### 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. ### 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). ### 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. ### aks-supported-os-ubuntu-default [IN] OBSERVATION AKS supports Ubuntu (default for Linux), Azure Linux, and Windows Server 2022 as node operating systems. ### 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). ### aks-three-autoscaling-mechanisms [IN] OBSERVATION AKS supports three autoscaling mechanisms: cluster autoscaler (node-level), horizontal pod autoscaler (pod-level), and KEDA (event-driven). ### aks-three-pricing-tiers [IN] OBSERVATION AKS has three pricing tiers: Free, Standard, and Premium. ### 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. ### aks-two-cluster-modes [IN] OBSERVATION AKS has two cluster modes: Automatic (fully managed, preconfigured) and Standard (more control over node pools, scaling, settings). ### 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). ### aks-virtual-nodes-burst-to-aci [IN] OBSERVATION Virtual nodes enable bursting from AKS to Azure Container Instances (ACI) for rapid serverless pod scaling. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### aks-windows-containers-multi-os-pools [IN] OBSERVATION AKS supports Windows Server containers via mixed OS (Linux + Windows) node pools within a single cluster. ### aks-windows-server-containers-multi-os-node-pools [IN] OBSERVATION AKS supports Windows Server containers via multi-OS node pools within a single cluster. ### 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. ### 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. ### appgw-backend-pool-not-tied-availability-set [IN] OBSERVATION Application Gateway backend pool members are not tied to an availability set. ### 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. ### 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). ### appgw-cross-vnet-backend-requires-peering [IN] OBSERVATION Application Gateway backend pool members in other VNets require VNet peering or VPN gateway for connectivity. ### 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. ### 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. ### 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. ### 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). ### 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) ### appgw-layer-7-lb-layer-4 [IN] OBSERVATION Application Gateway is a Layer 7 load balancer; Azure Load Balancer is Layer 4 ### 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) ### appgw-one-listener-one-routing-rule [IN] OBSERVATION Each Application Gateway listener maps to one routing rule ### appgw-one-public-one-private-ip-max [IN] OBSERVATION Application Gateway supports only one public and one private frontend IP address per gateway instance. ### appgw-path-routing-url-path-only [IN] OBSERVATION Application Gateway path-based routing matches URL path only, not query parameters ### 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. ### appgw-routes-by-http-attributes [IN] OBSERVATION Application Gateway makes routing decisions based on HTTP attributes (URL path, host headers), not just IP/port ### appgw-ssl-tls-termination-offload [IN] OBSERVATION Application Gateway provides SSL/TLS termination, offloading encryption processing from backend servers. ### appgw-supports-autoscaling-and-zone-redundancy [IN] OBSERVATION Application Gateway (V2) supports autoscaling based on traffic demand and zone redundancy across availability zones. ### appgw-supports-zone-redundancy-autoscaling [IN] OBSERVATION Application Gateway supports autoscaling based on traffic demand and zone redundancy across availability zones for high availability. ### 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. ### 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. ### 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. ### appgw-v1-port-3389-blocked [IN] OBSERVATION Application Gateway V1 SKU blocks port 3389; V2 blocks ports 22 (Private Link) and 53. ### appgw-v2-blocked-ports-22-53 [IN] OBSERVATION Application Gateway V2 blocks ports 22 (Private Link) and 53; V1 blocks port 3389 ### 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). ### 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) ### appgw-vmss-unhealthy-until-upgraded [IN] OBSERVATION VMSS backends in Application Gateway show unhealthy until instances are upgraded after being added to the pool ### appgw-websocket-always-enabled [IN] OBSERVATION Application Gateway WebSocket support is enabled by default and cannot be disabled ### appservice-access-restrictions-max-512-rules [IN] OBSERVATION App Service supports up to 512 access restriction rules per app, evaluated in priority order. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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 ### 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. ### 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 ### 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. ### 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. ### 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. ### 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. ### appservice-deployment-slots-consume-plan-resources [IN] OBSERVATION App Service deployment slots count as active apps competing for resources in the plan. ### appservice-deployment-slots-count-as-apps [IN] OBSERVATION Azure App Service deployment slots count as active apps competing for resources within the plan ### appservice-deployment-slots-staging [IN] OBSERVATION Azure App Service deployment slots enable staging environments for zero-downtime deployments ### 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. ### appservice-deployment-slots-standard-tier-minimum [IN] OBSERVATION App Service deployment slots require Standard tier or above. ### appservice-free-managed-tls-certificates [IN] OBSERVATION Azure App Service provides free managed TLS certificates for custom domains ### 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 ### 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. ### 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. ### appservice-ftp-webdeploy-bypass-kudu [IN] OBSERVATION FTP and WebDeploy deployments do not go through Kudu in App Service. ### 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. ### 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. ### 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. ### 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+. ### 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. ### 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. ### 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 ### appservice-java-zipdeploy-jar-wardeploy-war [IN] OBSERVATION For Java App Service deployments, use zipdeploy for JAR files and wardeploy for WAR/EAR files. ### 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 ### 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. ### appservice-kudu-windows-process-linux-container [IN] OBSERVATION Kudu runs as a separate process on Windows and as a second container on Linux. ### 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. ### 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 ### 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 ### 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. ### 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. ### appservice-max-512-access-restriction-rules [IN] OBSERVATION App Service supports a maximum of 512 access restriction rules per app, evaluated in priority order. ### appservice-mutual-tls-client-certificates [IN] OBSERVATION App Service supports mutual TLS (client certificate authentication) for B2B or internal app scenarios. ### 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. ### 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. ### 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 ### 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. ### 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). ### 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. ### 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 ### 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. ### appservice-pmv3-memory-optimized-high-density [IN] OBSERVATION App Service P*mv3 tiers are memory-optimized for high-density hosting (more apps per VM). ### appservice-port-445-blocked-sandbox [IN] OBSERVATION Port 445 (SMB) is blocked by default in the App Service sandbox. ### appservice-port-445-smb-blocked [IN] OBSERVATION Port 445 (SMB) is blocked by default in the App Service sandbox. ### appservice-possible-outbound-addresses-property [IN] OBSERVATION The `possibleOutboundAddresses` app property lists all potential outbound IPs an app might use in a scale unit. ### appservice-premiumv4-no-outbound-ip-exposed [IN] OBSERVATION PremiumV4 SKU does not expose outbound IP addresses. ### appservice-private-endpoints-inbound-only [IN] OBSERVATION Azure App Service private endpoints are inbound only and prevent data exfiltration via Private Link. ### 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. ### appservice-scale-before-deploy-at-90pct [IN] OBSERVATION If App Service CPU/memory exceeds 90%, scale up instance count temporarily before deploying. ### 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). ### 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). ### 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. ### 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 ### appservice-slots-consume-plan-resources [IN] OBSERVATION Deployment slots count as active apps and compete for resources within the App Service plan. ### appservice-slots-require-standard-tier [IN] OBSERVATION Deployment slots in Azure App Service require Standard tier or above. ### 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). ### 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 ### 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. ### 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). ### 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) ### 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). ### 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). ### 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. ### 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. ### 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. ### 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. ### azure-advisor-reliability-recommendations [IN] OBSERVATION Azure Advisor provides built-in reliability recommendations as part of the WAF Reliability pillar. ### azure-availability-set-requires-2-plus-vms [IN] OBSERVATION Availability Sets require 2 or more VMs to meet the 99.95% Azure SLA. ### 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. ### azure-availability-zones-dc-loss-asr-regional-outages [IN] OBSERVATION Availability Zones protect against datacenter loss; Azure Site Recovery protects against regional outages. ### azure-availability-zones-sla-99-99-percent [IN] OBSERVATION Availability Zones SLA is 99.99% with 2+ VM instances across 2+ zones. ### azure-availability-zones-vs-site-recovery-scope [IN] OBSERVATION Availability Zones protect against datacenter-level failure; Azure Site Recovery protects against region-level outages. ### 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. ### azure-blob-reservation-capacity-only [IN] OBSERVATION Blob storage reservations cover capacity only — not bandwidth or transaction costs. ### azure-blob-storage-reservation-capacity-only [IN] OBSERVATION Azure Blob Storage reservations cover storage capacity only — not bandwidth or transaction costs. ### 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. ### 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. ### azure-cloud-init-supported-most-linux [IN] OBSERVATION Cloud-init is supported on most Azure Linux distros for automated VM provisioning. ### 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. ### azure-cloud-init-supported-most-linux-distros [IN] OBSERVATION Cloud-init is supported on most Azure Linux distributions for automated VM provisioning. ### 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. ### 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. ### 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). ### 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. ### azure-cosmos-db-reservation-throughput-only [IN] OBSERVATION Cosmos DB reservations cover provisioned throughput only — not storage or networking costs. ### azure-cosmosdb-reservation-throughput-only [IN] OBSERVATION Cosmos DB reservations cover provisioned throughput only — storage and networking are not included. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### azure-disk-storage-reservations-premium-ssd-p30-plus [IN] OBSERVATION Azure Disk Storage reservations apply only to Premium SSDs P30 or larger. ### 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. ### azure-dns-cross-vnet-requires-fqdn [IN] OBSERVATION Cross-VNet DNS resolution requires using FQDNs — hostname alone is insufficient. ### 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. ### 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`. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### azure-dns-nic-settings-override-vnet [IN] OBSERVATION Network interface DNS settings take precedence over virtual network DNS settings. ### azure-dns-no-domain-purchasing [IN] OBSERVATION Azure DNS does not support domain name purchasing — use App Service domains or third-party registrars. ### azure-dns-no-domain-registration [IN] OBSERVATION Azure DNS does not provide domain registration; it only hosts and resolves domains. ### azure-dns-port-53-bypasses-nsg-custom [IN] OBSERVATION Once custom DNS is configured, port 53 traffic bypasses subnet/NIC NSGs. ### 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. ### 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. ### azure-dns-private-zone-autoregistration [IN] OBSERVATION Azure Private DNS supports autoregistration, which automatically creates DNS records for VMs in private DNS zones. ### 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. ### azure-dns-private-zones-preferred [IN] OBSERVATION Azure Private DNS zones are the preferred solution for VNet DNS name resolution. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### azure-dns-zone-unique-within-resource-group [IN] OBSERVATION DNS zone names must be unique within a resource group, not globally unique. ### 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). ### azure-elastic-san-only-lrs-zrs [IN] OBSERVATION Azure Elastic SAN supports only LRS and ZRS redundancy options. ### 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. ### 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. ### azure-files-no-ra-grs-ra-gzrs [IN] OBSERVATION Azure Files does not support RA-GRS or RA-GZRS redundancy options. ### 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. ### 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. ### 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. ### 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. ### 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) ### azure-lb-included-with-standard-tier-vms [IN] OBSERVATION Azure Load Balancer is included with Standard tier VMs but not all VM tiers. ### 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. ### 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). ### azure-load-balancer-included-standard-tier [IN] OBSERVATION Azure Load Balancer is included with Standard tier VMs but not all tiers. ### azure-load-balancer-included-standard-tier-vms [IN] OBSERVATION Azure Load Balancer is included with Standard tier VMs but not all VM tiers. ### 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. ### azure-log-analytics-built-on-azure-data-explorer [IN] OBSERVATION Azure Monitor Log Analytics is built on top of Azure Data Explorer. ### azure-log-analytics-default-result-limit-1000 [IN] OBSERVATION Azure Monitor Log Analytics default query result limit is 1,000 entries. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### azure-log-analytics-search-job-mode-for-historical [IN] OBSERVATION Log Analytics search job mode enables running search jobs for large-scale historical queries. ### 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. ### azure-log-analytics-uses-kql [IN] OBSERVATION Azure Monitor Log Analytics uses Kusto Query Language (KQL), the same language as Azure Data Explorer. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### azure-managed-disks-recommended-over-unmanaged [IN] OBSERVATION Managed Disks are recommended for all new VMs; unmanaged disks can be converted to managed. ### 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. ### azure-managed-disks-three-replicas-99-999-availability [IN] OBSERVATION Managed disks store 3 replicas of data and provide 99.999% availability SLA. ### azure-managed-identity-credentials-never-accessible [IN] OBSERVATION Managed identity credentials are never accessible to the developer. ### azure-managed-identity-fic-limit-20 [IN] OBSERVATION The limit for managed identities as Federated Identity Credentials on an Entra ID application is 20. ### azure-managed-identity-no-cost [IN] OBSERVATION Managed identities for Azure resources are free — no extra cost. ### 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/`. ### azure-managed-identity-user-assigned-recommended [IN] OBSERVATION User-assigned managed identity is the recommended type for Microsoft services. ### 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. ### 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. ### 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. ### 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. ### azure-monitor-activity-log-alerts-always-stateless [IN] OBSERVATION All Azure Monitor activity log alerts are stateless (fire every time the condition is met). ### 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. ### 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. ### azure-monitor-aiops-dynamic-thresholds-smart-alerts [IN] OBSERVATION Azure Monitor AIOps capabilities include dynamic alert thresholds and smart alerts using machine learning. ### azure-monitor-alert-conditions-fired-or-resolved [IN] OBSERVATION Azure Monitor alert conditions are system-managed with two states: fired or resolved. ### 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. ### 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. ### 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. ### 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. ### 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. ### azure-monitor-alerts-retained-30-days [IN] OBSERVATION Azure Monitor alerts are stored for 30 days then automatically deleted. ### 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. ### azure-monitor-application-insights-opentelemetry-based [IN] OBSERVATION Application Insights is an OpenTelemetry-based APM feature within Azure Monitor. ### 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. ### azure-monitor-autoscale-is-monitor-feature [IN] OBSERVATION Autoscale is a feature of Azure Monitor, not a standalone service. ### 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. ### 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. ### 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. ### 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. ### azure-monitor-custom-metrics-10-dimension-limit [IN] OBSERVATION Azure Monitor custom metrics are limited to 10 dimensions. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### azure-monitor-four-signal-types [IN] OBSERVATION Azure Monitor collects four signal types: metrics, logs, traces, and events. ### 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. ### 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. ### 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. ### 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. ### azure-monitor-hybrid-multicloud-via-arc [IN] OBSERVATION Azure Monitor supports hybrid and multicloud monitoring via Azure Arc and the Azure Monitor pipeline. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### azure-monitor-logs-all-plans-12-year-retention [IN] OBSERVATION All Azure Monitor Logs table plans support up to 12 years total retention. ### 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. ### 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. ### azure-monitor-logs-basic-auxiliary-not-in-legacy-pricing [IN] OBSERVATION Basic and Auxiliary table plans are not available in legacy pricing tiers. ### 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. ### 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). ### 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. ### 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. ### 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. ### 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. ### 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. ### 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). ### 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. ### azure-monitor-metric-dimensions-case-insensitive [IN] OBSERVATION Metric dimension names and values are case-insensitive in Azure Monitor. ### 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). ### 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. ### 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). ### 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. ### 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. ### 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. ### azure-monitor-monitoring-contributor-creates-reader-views [IN] OBSERVATION Monitoring Contributor role can create and manage alerts; Monitoring Reader role can only view alerts. ### azure-monitor-moving-resource-may-lose-metric-history [IN] OBSERVATION Moving or renaming an Azure resource may result in loss of metric history. ### azure-monitor-native-metrics-preaggregated-prometheus-raw [IN] OBSERVATION Native platform and custom metrics are preaggregated; Prometheus metrics store raw data. ### 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. ### 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. ### azure-monitor-platform-custom-metrics-preaggregated [IN] OBSERVATION Platform and custom metrics are preaggregated in the time-series database; Prometheus metrics store raw data. ### 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. ### 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. ### azure-monitor-platform-metrics-retention-93-days [IN] OBSERVATION Azure Monitor platform metrics are retained for 93 days. ### 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). ### azure-monitor-prometheus-metrics-retention-18-months [IN] OBSERVATION Azure Monitor Prometheus metrics are retained for 18 months. ### azure-monitor-prometheus-metrics-stored-in-workspace [IN] OBSERVATION Prometheus metrics are stored in an Azure Monitor workspace (not subscription-level like native metrics). ### 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. ### 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. ### 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. ### 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. ### azure-monitor-smart-alerts-dynamic-thresholds-ml [IN] OBSERVATION Azure Monitor alerts support dynamic thresholds and smart alerts using machine learning for intelligent alerting. ### azure-monitor-smart-detection-alerts [IN] OBSERVATION Smart detection alerts are Application Insights auto-detection of performance and failure anomalies. ### azure-monitor-smart-detection-alerts-app-insights [IN] OBSERVATION Smart detection alerts automatically detect performance and failure anomalies in Application Insights resources. ### azure-monitor-smart-detection-from-app-insights [IN] OBSERVATION Smart detection alerts originate from Application Insights and auto-detect performance and failure anomalies. ### 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. ### 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. ### 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. ### 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). ### 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). ### 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). ### 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). ### 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. ### 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. ### azure-netapp-files-9999-availability [IN] OBSERVATION Azure NetApp Files provides 99.99% availability with locally redundant storage. ### 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). ### 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). ### azure-netapp-files-fips-140-2-at-rest [IN] OBSERVATION Azure NetApp Files uses FIPS 140-2 standard for encryption at rest. ### 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. ### 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. ### 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. ### 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. ### 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. ### azure-nsg-default-rule-priorities [IN] OBSERVATION NSG default rules use priorities 65000, 65001, and 65500; custom rules (max priority 4096) always evaluate first. ### 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. ### azure-nsg-five-tuple-matching [IN] OBSERVATION NSG rules evaluate traffic using five-tuple matching: source, source port, destination, destination port, and protocol. ### 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. ### 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. ### 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. ### 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. ### 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. ### azure-nsg-no-duplicate-priority-and-direction [IN] OBSERVATION You cannot create two NSG rules with the same priority and direction. ### 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). ### 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`. ### 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). ### 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. ### azure-nsg-rule-removal-no-terminate [IN] OBSERVATION Removing an NSG rule does not terminate existing connections; only new connections are affected. ### azure-nsg-same-priority-direction-unique [IN] OBSERVATION Cannot create two NSG rules with the same priority and direction within the same NSG. ### 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. ### 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. ### azure-nsg-stateful [IN] OBSERVATION NSGs are stateful — if outbound traffic is allowed, the inbound response is automatically allowed (and vice versa). ### 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. ### 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). ### 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. ### 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`. ### 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. ### azure-policy-arc-extends-to-multicloud-onprem [IN] OBSERVATION Azure Arc extends Azure Policy governance to multi-cloud and on-premises datacenters. ### 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. ### 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. ### 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). ### 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`). ### 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. ### azure-policy-best-practice-start-with-audit [IN] OBSERVATION Azure Policy best practice: start with audit/auditIfNotExists effects before enforcement effects (deny, modify, deployIfNotExists). ### azure-policy-compliance-evaluation-every-24-hours [IN] OBSERVATION Azure Policy automatic compliance evaluation occurs every 24 hours. ### 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. ### azure-policy-definition-displayname-128-description-512 [IN] OBSERVATION Policy definition `displayName` max length is 128 characters; `description` max length is 512 characters. ### 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. ### 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`). ### azure-policy-displayname-128-description-512 [IN] OBSERVATION Policy definition `displayName` max length is 128 characters; `description` max length is 512 characters. ### azure-policy-effect-evaluation-order [IN] OBSERVATION Azure Policy effect evaluation order: disabled → append/modify → deny → audit → manual → auditIfNotExists → denyAction. ### 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. ### 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. ### 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. ### azure-policy-max-400-notscopes-per-assignment [IN] OBSERVATION Azure Policy supports up to 400 exclusions (notScopes) per assignment. ### 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. ### azure-policy-metadata-property-limit-1024-chars [IN] OBSERVATION Each Azure Policy metadata property (version, category, preview, deprecated, portalReview) is capped at 1024 characters. ### 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`). ### 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`. ### 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. ### azure-policy-single-effect-per-definition [IN] OBSERVATION Each Azure Policy definition contains exactly one effect in its policyRule. ### 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). ### 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). ### 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. ### 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. ### 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. ### 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. ### 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. ### azure-private-dns-conditional-forwarding-requires-resolver [IN] OBSERVATION Conditional forwarding from Azure to on-premises requires Azure DNS Private Resolver. ### 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. ### 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. ### azure-private-dns-no-custom-dns-servers [IN] OBSERVATION Azure Private DNS resolves domain names within Azure virtual networks without needing custom DNS servers. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### azure-reservations-applied-hourly-except-databricks [IN] OBSERVATION All Azure Reservations are applied on an hourly basis except Azure Databricks. ### 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. ### azure-reservations-blob-capacity-only [IN] OBSERVATION Azure Reservations for Blob Storage cover capacity only — not bandwidth or transaction costs. ### 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. ### 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. ### azure-reservations-cosmosdb-throughput-only [IN] OBSERVATION Azure Reservations for Cosmos DB cover provisioned throughput only — not storage or networking costs. ### azure-reservations-deduct-from-prepayment-first [IN] OBSERVATION Azure Reservation costs deduct from Azure Prepayment (Monetary Commitment) balance first; overage is billed separately. ### 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. ### 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). ### azure-reservations-exchangeable-same-type [IN] OBSERVATION Azure Reservations can be exchanged for same-type reservations after purchase. ### 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. ### 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. ### azure-reservations-prepayment-deducted-first [IN] OBSERVATION Azure Reservation costs are deducted from Azure Prepayment (formerly monetary commitment) balance first; overage is billed separately. ### 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. ### azure-reservations-scope-changeable-after-purchase [IN] OBSERVATION Azure Reservation scope (which subscriptions/resource groups receive the discount) can be changed after purchase. ### azure-reservations-scope-updatable-after-purchase [IN] OBSERVATION Azure Reservation scope controls where savings apply and can be updated after purchase. ### azure-reservations-splittable-after-purchase [IN] OBSERVATION Azure Reservations can be split into smaller parts and have instance size flexibility changed after purchase. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### azure-site-recovery-not-restricted-to-paired-regions [IN] OBSERVATION Azure Site Recovery enables cross-region failover and is not restricted to paired regions. ### 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. ### azure-site-recovery-testable-failover [IN] OBSERVATION Azure Site Recovery supports testable failover without impacting production workloads. ### 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. ### 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. ### 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. ### 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. ### azure-spot-vm-all-regions-except-21vianet [IN] OBSERVATION Spot VMs are available in all Azure regions except Microsoft Azure operated by 21Vianet. ### 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. ### azure-spot-vm-b-series-not-supported [IN] OBSERVATION B-series and promo-version VM sizes are not supported for Spot VMs. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### azure-spot-vm-max-price-change-requires-deallocation [IN] OBSERVATION Spot VM max price can only be changed after the VM is deallocated. ### 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. ### azure-spot-vm-must-deallocate-to-change-max-price [IN] OBSERVATION A Spot VM must be deallocated before its maximum price can be changed. ### 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. ### 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. ### azure-spot-vm-not-available-21vianet [IN] OBSERVATION Azure Spot VMs are available in all regions except Microsoft Azure operated by 21Vianet. ### 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. ### 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. ### 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). ### azure-sql-service-endpoint-same-region-only [IN] OBSERVATION For Azure SQL Database, service endpoint traffic applies only within the same region. ### azure-sql-service-endpoints-same-region-only [IN] OBSERVATION Azure SQL Database service endpoints apply only within the VNet's region. ### azure-standard-hdd-os-disk-retiring-sep-2028 [IN] OBSERVATION Standard HDD as an OS disk type is retiring on September 8, 2028. ### azure-standard-hdd-os-disk-retiring-sept-2028 [IN] OBSERVATION Standard HDD as OS disk is retiring on September 8, 2028. ### 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. ### 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. ### 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. ### 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. ### azure-storage-encrypts-all-data-at-rest-by-default [IN] OBSERVATION Azure Storage encrypts all data at rest by default using Microsoft-managed keys. ### 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. ### 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. ### 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). ### 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. ### 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. ### 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. ### 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. ### azure-storage-secure-transfer-requires-https [IN] OBSERVATION The secure transfer setting on a storage account requires HTTPS for all requests. ### azure-suse-redhat-plans-software-only [IN] OBSERVATION SUSE and Red Hat software plans cover software costs only — not underlying VM compute usage. ### 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). ### 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/`. ### 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. ### 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`. ### azure-temp-disk-path-linux-resource-windows-d [IN] OBSERVATION Temporary disk paths: Linux = `/dev/disk/azure/resource`, Windows = drive D. ### azure-temp-disk-paths-linux-resource-windows-d [IN] OBSERVATION Temporary disk paths: Linux = `/dev/disk/azure/resource`, Windows = drive D. ### azure-temp-disk-paths-linux-windows [IN] OBSERVATION Temporary disk paths: Linux = `/dev/disk/azure/resource`, Windows = drive D. ### azure-temp-disk-v5-plus-auto-encrypt [IN] OBSERVATION VMs v5 and newer automatically encrypt temporary and ephemeral OS disks at rest. ### 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. ### 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. ### 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. ### 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. ### 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. ### azure-v5-plus-vms-auto-encrypt-temp-disks [IN] OBSERVATION VMs v5+ automatically encrypt temporary disks at rest without additional configuration. ### 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. ### 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. ### 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. ### 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. ### 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. ### azure-vm-billed-per-minute [IN] OBSERVATION Azure VMs are billed per-minute (not per-hour); for partial hours only minutes used are charged. ### azure-vm-billing-per-minute [IN] OBSERVATION Azure VMs are billed per-minute for partial hours; storage is billed separately. ### azure-vm-boot-diagnostics-enabled-by-default [IN] OBSERVATION Boot diagnostics is enabled by default when creating a VM in the Azure portal. ### azure-vm-cloud-init-linux [IN] OBSERVATION Cloud-init is supported on most Azure Linux distributions for automated VM provisioning at first boot. ### 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. ### azure-vm-cloud-init-supported-most-linux [IN] OBSERVATION Cloud-init is supported on most Azure Linux distributions for automated VM provisioning. ### 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. ### 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. ### 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. ### 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. ### azure-vm-dc-ec-confidential-computing [IN] OBSERVATION DC and EC VM families provide confidential computing with hardware-based Trusted Execution Environments (TEEs). ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### azure-vm-hb-family-infiniband-rdma-mpi [IN] OBSERVATION HB-family VM sizes support InfiniBand, RDMA, and MPI for tightly coupled parallel HPC workloads. ### 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. ### 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). ### 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. ### 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. ### azure-vm-insights-tables [IN] OBSERVATION VM Insights populates five tables: InsightsMetrics (performance), VMBoundPort, VMComputer, VMConnection, and VMProcess (dependency map data). ### 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. ### 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). ### 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. ### 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. ### 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. ### azure-vm-move-between-vnets-requires-recreate [IN] OBSERVATION Moving a VM between VNets requires deleting and recreating the VM (disks can be retained). ### 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. ### 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. ### azure-vm-nsg-local-disk-no-cost [IN] OBSERVATION NSGs and local temporary disks have no additional cost; NICs have no separate cost. ### azure-vm-nsg-nic-no-charge [IN] OBSERVATION Azure NSGs and NICs have no additional charge; NIC count limits are determined by VM size. ### azure-vm-os-disk-default-127gib [IN] OBSERVATION Azure VM OS disk default size is approximately 127 GiB. ### 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). ### azure-vm-os-disk-typically-127-gib [IN] OBSERVATION Azure VM OS disk is typically 127 GiB (smaller for some images). ### 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). ### 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. ### azure-vm-s-suffix-premium-storage [IN] OBSERVATION The 's' suffix in Azure VM size names indicates Premium Storage (SSD) capability. ### 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). ### 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). ### 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). ### 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. ### 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. ### 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. ### 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. ### azure-vm-temp-disk-drive-letters [IN] OBSERVATION Windows temporary disk is drive D; Linux temporary disk is at /dev/disk/azure/resource. ### 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). ### 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. ### azure-vm-v5-plus-auto-encrypt-temp-disk [IN] OBSERVATION VMs v5+ automatically encrypt temporary disks at rest without additional configuration. ### azure-vm-v5-plus-auto-encrypt-temp-disks [IN] OBSERVATION VMs v5 and newer automatically encrypt temporary and ephemeral OS disks at rest. ### azure-vm-windows-licensing-port-1688 [IN] OBSERVATION Windows VM licensing uses outbound port 1688 to connect to the Key Management Service. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### azure-vmss-orchestration-mode-immutable [IN] OBSERVATION VMSS orchestration mode (Uniform or Flexible) is set at creation time and cannot be changed later. ### 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. ### 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. ### 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. ### azure-vnet-free [IN] OBSERVATION Azure Virtual Network itself is free; standard charges apply only to resources deployed within it. ### 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. ### azure-vnet-peering-charges-ingress-egress [IN] OBSERVATION VNet peering incurs a nominal fee on both ingress and egress traffic. ### azure-vnet-peering-cross-subscription-tenant [IN] OBSERVATION VNet peering works across subscriptions, Microsoft Entra tenants, deployment models (ARM and classic), and regions. ### 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. ### 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. ### 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. ### azure-vnet-peering-microsoft-backbone [IN] OBSERVATION VNet peering traffic stays on the Microsoft backbone — no encryption, gateways, or public internet needed. ### azure-vnet-peering-no-downtime [IN] OBSERVATION No downtime occurs when creating VNet peering connections. ### 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. ### 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. ### 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. ### azure-vnet-peering-subnet-level [IN] OBSERVATION Subnet peering allows peering of specific subnets rather than entire VNet address spaces. ### azure-vnet-peering-subnet-peering [IN] OBSERVATION Subnet peering allows peering of specific subnets rather than entire VNets, narrowing the scope of connectivity. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### azuresql-99-99-availability-sla [IN] OBSERVATION Azure SQL Database offers a 99.99% availability SLA ### azuresql-99-99-sla [IN] OBSERVATION Azure SQL Database guarantees 99.99% SLA availability (up to 99.995% per the Azure SQL family overview). ### 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 ### azuresql-always-encrypted-client-side-keys [IN] OBSERVATION Always Encrypted keeps encryption keys on the client side; even DBAs cannot see plaintext data. ### 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. ### azuresql-audit-destinations-storage-monitor-eventhubs [IN] OBSERVATION SQL Auditing writes audit logs to customer-owned Azure storage, Azure Monitor logs, or Event Hubs. ### azuresql-automatic-tuning-index-and-plan [IN] OBSERVATION Azure SQL Database automatic tuning includes automatic index management and automatic plan correction. ### azuresql-automatic-tuning-index-plan [IN] OBSERVATION Azure SQL Database automatic tuning includes automatic index management and automatic plan correction. ### 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. ### 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. ### azuresql-backup-frequency [IN] OBSERVATION Azure SQL Database automated backups: full weekly, differential every 12h (vCore) or 24h (DTU), transaction log ~10 minutes ### 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. ### 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. ### 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) ### 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. ### 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. ### 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. ### 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 ### 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. ### azuresql-clr-not-in-sql-database [IN] OBSERVATION CLR support is not available in Azure SQL Database but is supported in Managed Instance. ### 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. ### 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 ### 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 ### 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) ### 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 ### 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. ### 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. ### 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. ### azuresql-dynamic-scaling-manual-not-auto [IN] OBSERVATION Azure SQL Database dynamic scaling is manual with no downtime; automatic autoscaling requires serverless tier ### 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. ### 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 ### 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. ### azuresql-elastic-pools-vs-instance-pools [IN] OBSERVATION Elastic pools are for Azure SQL Database; instance pools are for Azure SQL Managed Instance. ### azuresql-features-ship-first [IN] OBSERVATION New SQL Server features release to Azure SQL Database first, then to on-premises SQL Server ### 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. ### azuresql-first-full-backup-30-minutes [IN] OBSERVATION Azure SQL Database completes its first full backup within approximately 30 minutes of database creation. ### 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 ### 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 ### 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. ### 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. ### 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. ### 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. ### 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. ### azuresql-ha-hyperscale-failover-not-for-readable-secondary [IN] OBSERVATION The manual failover command is not available for readable secondary replicas of Hyperscale databases. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### azuresql-ha-service-fabric-manages-failover [IN] OBSERVATION Azure Service Fabric manages health monitoring and failover across all Azure SQL Database availability models. ### 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). ### 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. ### azuresql-hybrid-benefit-requires-software-assurance [IN] OBSERVATION Azure Hybrid Benefit for SQL requires Software Assurance on existing SQL Server licenses. ### azuresql-hyperscale-128tb-max [IN] OBSERVATION Azure SQL Database Hyperscale tier supports up to 128 TB storage with independently scalable compute and storage ### azuresql-hyperscale-backup-redundancy-immutable [IN] OBSERVATION Azure SQL Hyperscale backup redundancy can only be set at creation time and cannot be modified later ### 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. ### 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. ### 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 ### 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. ### 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 ### azuresql-ledger-cryptographic-tamper-evidence [IN] OBSERVATION Azure SQL Ledger provides cryptographic proof of data integrity and tamper-evidence for regulatory compliance and auditability. ### azuresql-ledger-tamper-evidence [IN] OBSERVATION Azure SQL Ledger provides cryptographic proof of data integrity (tamper-evidence) for regulatory compliance and auditability. ### azuresql-ltr-up-to-10-years [IN] OBSERVATION Azure SQL Database long-term retention (LTR) supports up to 10 years of backup retention ### 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. ### azuresql-max-database-sizes [IN] OBSERVATION Azure SQL max database sizes: SQL Database = 128 TB, Managed Instance = 16 TB, SQL VMs = 256 TB. ### 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. ### 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). ### 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). ### 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). ### 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. ### azuresql-mi-hybrid-benefit-requires-sa [IN] OBSERVATION Azure Hybrid Benefit for SQL Managed Instance requires Software Assurance on existing SQL Server licenses. ### 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). ### 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). ### 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. ### 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. ### 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. ### 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. ### azuresql-mi-max-16tb [IN] OBSERVATION Azure SQL Managed Instance supports a maximum database size of 16 TB. ### 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. ### azuresql-mi-near-100pct-sql-server-compatibility [IN] OBSERVATION Azure SQL Managed Instance offers near 100% compatibility with the latest SQL Server Enterprise Edition. ### azuresql-mi-recommended-for-most-migrations [IN] OBSERVATION Azure SQL Managed Instance is recommended for most migrations from on-premises SQL Server to Azure. ### 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. ### azuresql-mi-server-level-roles-supported [IN] OBSERVATION SQL Managed Instance supports server-level roles (fixed or custom); SQL Database does not. ### azuresql-mi-sla-99-99 [IN] OBSERVATION Azure SQL Managed Instance has a 99.99% uptime SLA. ### 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. ### 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. ### azuresql-mi-stop-start-storage-only-billing [IN] OBSERVATION Azure SQL Managed Instance supports stop/start capability; when stopped, you pay only for storage. ### azuresql-mi-tcp-only-no-named-pipes [IN] OBSERVATION Azure SQL Managed Instance supports TCP protocol only; named pipes are not supported. ### 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. ### 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. ### azuresql-mi-vnet-classic-not-supported [IN] OBSERVATION Azure SQL Managed Instance does NOT support VNet Classic deployment model; only ARM is supported. ### 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. ### 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 ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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 ### 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 ### 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). ### 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. ### 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. ### 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. ### azuresql-tde-enabled-by-default [IN] OBSERVATION Transparent Data Encryption (TDE) is enabled by default on all newly created Azure SQL databases. ### 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. ### azuresql-tde-no-log-backup-compression [IN] OBSERVATION Azure SQL databases with TDE (Transparent Data Encryption) enabled do not compress transaction log backups. ### azuresql-three-encryption-layers [IN] OBSERVATION Azure SQL Database has three encryption layers: TLS (in motion), TDE (at rest), Always Encrypted (in use) ### 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). ### azuresql-tls-always-enforced [IN] OBSERVATION TLS is always enforced on Azure SQL (ForceEncryption=Yes); connections without encryption are not possible. ### 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. ### 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) ### 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. ### azuresql-vm-max-256tb [IN] OBSERVATION SQL Server on Azure VMs supports up to 256 TB of storage. ### azuresql-windows-auth-kerberos-mi-only [IN] OBSERVATION Windows authentication (Kerberos) for Entra principals is available only on SQL Managed Instance, not SQL Database. ### 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. ### azuresql-zone-redundant-premium-bc-only [IN] OBSERVATION Azure SQL Database zone-redundant deployment is available for Premium and Business Critical tiers only ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### blob-archive-snapshots-not-supported [IN] OBSERVATION Azure Blob Storage snapshots are not supported for archived blobs. ### 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). ### 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. ### 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. ### 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. ### 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. ### blob-encryption-scope-blocks-archive [IN] OBSERVATION Azure Blob Storage blobs using encryption scopes cannot be archived via Set Blob Tier. ### blob-encryption-scopes-cannot-archive [IN] OBSERVATION Azure Blob Storage blobs using encryption scopes cannot be archived via Set Blob Tier. ### 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. ### 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. ### blob-lifecycle-delete-blocked-by-immutable [IN] OBSERVATION Azure Blob Storage lifecycle delete actions do not work on blobs in immutable containers. ### blob-lifecycle-encryption-scope-no-archive [IN] OBSERVATION Azure Blob Storage lifecycle policies cannot archive blobs that use an encryption scope. ### blob-lifecycle-immutable-blocks-delete [IN] OBSERVATION Lifecycle delete actions do not work on blobs in immutable containers. ### blob-lifecycle-immutable-containers-block-delete [IN] OBSERVATION Lifecycle delete actions do not work on blobs in immutable containers. ### 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. ### 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. ### blob-lifecycle-management-cannot-rehydrate-archive [IN] OBSERVATION Azure Blob Storage lifecycle management policies cannot rehydrate blobs from the Archive tier. ### 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). ### blob-lifecycle-monitor-event [IN] OBSERVATION Lifecycle policy runs can be monitored by subscribing to the LifecyclePolicyCompleted event. ### blob-lifecycle-no-archive-rehydration [IN] OBSERVATION Lifecycle policies cannot rehydrate blobs from archive tier to an online tier. ### 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. ### blob-lifecycle-no-partial-updates [IN] OBSERVATION Blob lifecycle management policies must be read or written in full — partial updates are not supported. ### 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. ### 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. ### blob-lifecycle-policy-24h-propagation [IN] OBSERVATION Blob lifecycle policy changes take up to 24 hours to go into effect. ### 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. ### 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. ### 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. ### 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. ### blob-lifecycle-safe-delete-procedure [IN] OBSERVATION Recommended lifecycle policy deletion procedure: disable all rules first, wait 24 hours, then delete the policy. ### blob-lifecycle-system-containers-excluded [IN] OBSERVATION Lifecycle policies never affect system containers ($logs, $web). ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### blob-storage-client-libraries-five-languages [IN] OBSERVATION Azure Blob Storage provides client libraries for .NET, Java, Node.js, Python, and Go. ### blob-storage-sftp-nfs-support [IN] OBSERVATION Azure Blob Storage supports SFTP and NFS 3.0 protocols in addition to HTTP/HTTPS. ### blob-storage-unstructured-data [IN] OBSERVATION Azure Blob Storage is Microsoft's object storage solution for unstructured data (text and binary). ### 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%. ### 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. ### 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. ### blueprints-artifact-size-limit-2mb [IN] OBSERVATION Each Azure Blueprint artifact must be ≤ 2 MB in size. ### blueprints-backed-by-cosmos-db [IN] OBSERVATION Azure Blueprint objects are backed by Cosmos DB, globally replicated for low latency and high availability. ### 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. ### 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. ### 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. ### 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). ### blueprints-four-artifact-types [IN] OBSERVATION Azure Blueprints supports four artifact types: Resource Groups, ARM templates, Policy Assignments, and Role Assignments. ### blueprints-naming-limits [IN] OBSERVATION Blueprint naming limits: definition name max 48 characters, version max 20 characters, assignment name max 90 characters. ### blueprints-parameters-via-rest-api-only [IN] OBSERVATION Blueprint-level parameters can only be created via REST API, not the Azure portal. ### 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. ### 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. ### 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. ### 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. ### 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. ### cannot-delete-subnet-with-resources [IN] OBSERVATION A subnet cannot be deleted while it contains resources — all resources must be removed first. ### cloud-security-benchmark-underpins-waf-security [IN] OBSERVATION The Microsoft Cloud Security Benchmark provides the control framework that underpins WAF Security pillar guidance. ### 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+. ### cluster-autoscaler-scale-in-10min-idle [IN] OBSERVATION The cluster autoscaler schedules node deletion after nodes are unused for 10 minutes (default threshold). ### 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. ### defender-for-cloud-multi-cloud [IN] OBSERVATION Microsoft Defender for Cloud covers multi-cloud workloads across Azure, AWS, and GCP — not Azure-only. ### elastic-san-only-lrs-zrs [IN] OBSERVATION Azure Elastic SAN supports only LRS and ZRS redundancy options — no geo-redundant options. ### entra-admin-center-url [IN] OBSERVATION The Microsoft Entra admin center is accessible at https://entra.microsoft.com. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### entra-deleted-users-recoverable-30-days [IN] OBSERVATION Deleted users in Microsoft Entra ID are soft-deleted and recoverable for 30 days. ### 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. ### 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. ### 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. ### 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. ### entra-external-guests-no-admin-units [IN] OBSERVATION External guests cannot be assigned to administrative units in Microsoft Entra ID. ### 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. ### 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). ### 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. ### 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. ### 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. ### 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. ### entra-group-membership-types [IN] OBSERVATION Entra group membership types are: Assigned, Dynamic User, and Dynamic Device. ### 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. ### entra-group-type-immutable [IN] OBSERVATION Microsoft Entra group type (Security or Microsoft 365) cannot be changed after creation — must delete and recreate. ### entra-groups-admin-roles [IN] OBSERVATION Groups Administrator or User Administrator roles are required for group CRUD and membership management in Microsoft Entra ID. ### 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. ### 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. ### 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). ### 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. ### entra-id-initial-domain-onmicrosoft [IN] OBSERVATION Every Microsoft Entra ID directory gets an initial domain in the format `.onmicrosoft.com`. ### entra-id-protection-requires-p2 [IN] OBSERVATION Microsoft Entra ID Protection (risk detection and risk-based Conditional Access) requires a P2 license. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### entra-m365-group-email [IN] OBSERVATION Microsoft 365 is the only Entra group type that supports a group email address. ### 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. ### 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. ### 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/`. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### entra-nested-groups-security-only [IN] OBSERVATION Nested groups (group within a group) are supported for security groups only, not Microsoft 365 groups. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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/`. ### 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. ### entra-three-service-principal-types [IN] OBSERVATION Microsoft Entra ID has three types of service principals: Application, Managed Identity, and Legacy. ### 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. ### entra-user-type-determines-privilege-level [IN] OBSERVATION User type (Member vs Guest) determines privilege level, not whether the account is internal or external. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### eventgrid-events-published-as-array [IN] OBSERVATION Events must always be published to Event Grid in a JSON array, even for a single event. ### 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. ### 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). ### eventgrid-metadata-version-only-1 [IN] OBSERVATION Event Grid schema `metadataVersion` is currently only version `1`; Event Grid stamps it if omitted. ### eventgrid-publish-auth-sas-or-key [IN] OBSERVATION Publishing events to Event Grid requires SAS token or key authentication. ### 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. ### 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. ### 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. ### 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). ### 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). ### 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. ### 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. ### 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. ### 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. ### eventgrid-subscription-expiration-time [IN] OBSERVATION Event Grid event subscriptions can have an expiration time set for automatic cleanup of temporary subscriptions. ### eventgrid-supports-availability-zones [IN] OBSERVATION Azure Event Grid leverages Azure availability zones for regional high availability and fault tolerance. ### 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). ### 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. ### 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. ### eventhubs-auto-inflate-scales-up-only [IN] OBSERVATION Azure Event Hubs auto-inflate only scales throughput units upward, never downward. ### eventhubs-auto-inflate-up-only [IN] OBSERVATION Event Hubs Auto-inflate automatically scales throughput units upward to prevent throttling but does not scale down. ### eventhubs-az-zones-premium-dedicated-only [IN] OBSERVATION Azure Event Hubs availability zone support is available on Premium and Dedicated tiers only. ### 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). ### 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. ### 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. ### 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. ### 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. ### eventhubs-cross-protocol-read-write [IN] OBSERVATION Event Hubs supports cross-protocol reading: produce via Kafka and consume via AMQP, or vice versa. ### 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. ### 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. ### eventhubs-direct-partition-send-discouraged [IN] OBSERVATION Sending directly to a specific Event Hubs partition is discouraged because it downgrades availability to partition-level. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### eventhubs-kafka-at-least-once-delivery [IN] OBSERVATION Event Hubs Kafka delivery semantic is at-least once; consumers should implement the idempotent consumer pattern. ### 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. ### eventhubs-kafka-compression-gzip-premium-dedicated [IN] OBSERVATION Event Hubs Kafka endpoint supports only gzip compression, available in Premium and Dedicated tiers only. ### eventhubs-kafka-compression-gzip-premium-dedicated-only [IN] OBSERVATION Event Hubs Kafka compression supports only `gzip`, available in Premium and Dedicated tiers only. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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"`. ### eventhubs-kafka-port-9093-tls-mandatory [IN] OBSERVATION Event Hubs Kafka endpoint uses port 9093 with mandatory TLS encryption (`SASL_SSL`). ### eventhubs-kafka-requires-standard-or-higher [IN] OBSERVATION Event Hubs Kafka support requires Standard, Premium, or Dedicated tier — not available on Basic. ### eventhubs-kafka-sas-key-regen-no-disconnect [IN] OBSERVATION Event Hubs SAS connections are not disconnected when the SAS key is regenerated. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### eventhubs-max-publish-size-1mb [IN] OBSERVATION Event Hubs maximum publish size is 1 MB per operation (batch or individual event). ### 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. ### 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. ### 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. ### 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. ### eventhubs-partition-count-no-pricing-impact [IN] OBSERVATION Event Hubs pricing depends on throughput/processing/capacity units, not on partition count. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### eventhubs-sla-up-to-9999 [IN] OBSERVATION Azure Event Hubs SLA is up to 99.99% depending on tier and configuration. ### 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. ### 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. ### eventhubs-three-protocols-amqp-kafka-https [IN] OBSERVATION Azure Event Hubs natively supports three protocols: AMQP 1.0, Apache Kafka, and HTTPS. ### 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). ### 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. ### 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. ### 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. ### expressroute-requires-bgp-vpn-optional [IN] OBSERVATION ExpressRoute requires BGP for route exchange; VPN gateways can optionally use BGP. ### 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. ### ftl2-auto-install-azure-sdk-deps [IN] OBSERVATION FTL2 auto-installs Azure SDK pip packages (azure-mgmt-*) via `auto_install_deps=True` when missing. ### 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. ### 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. ### ftl2-azure-fqcn-azcollection [IN] OBSERVATION FTL2 accesses Azure modules via FQCN pattern: `await ftl.azure.azcollection.azure_rm_resourcegroup(...)`. ### ftl2-azure-fqcn-pattern [IN] OBSERVATION FTL2 accesses Azure modules via FQCN pattern: `await ftl.azure.azcollection.azure_rm_resourcegroup(...)`. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### ftl2-state-tracking-idempotent-crash-recovery [IN] OBSERVATION FTL2 tracks state via `.ftl2-state.json` enabling idempotent provisioning with crash recovery and provider filtering. ### 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. ### 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. ### 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. ### 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 ### 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. ### functions-durable-functions-stateful-workflows [IN] OBSERVATION Durable Functions is an extension for building stateful, event-driven serverless workflows in Azure Functions ### functions-durable-stateful-workflows [IN] OBSERVATION Durable Functions is an Azure Functions extension for building stateful, event-driven serverless workflows and orchestrations. ### functions-five-hosting-plans [IN] OBSERVATION Azure Functions offers five hosting plans: Flex Consumption, Premium, Dedicated (App Service), Container Apps, and Consumption. ### 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. ### functions-flex-consumption-linux-only [IN] OBSERVATION Azure Functions Flex Consumption plan supports Linux only. ### 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. ### functions-flex-consumption-no-subnet-underscores [IN] OBSERVATION Flex Consumption subnets cannot contain underscores in their names ### 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). ### 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. ### 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. ### functions-flex-consumption-subnet-delegation-microsoft-app [IN] OBSERVATION Azure Functions Flex Consumption subnet delegation is `Microsoft.App/environments`, different from Premium/Dedicated plans. ### functions-flex-consumption-subnet-no-underscores [IN] OBSERVATION Azure Functions Flex Consumption subnets cannot contain underscores in their names. ### 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 ### functions-gateway-required-vnet-dedicated-only [IN] OBSERVATION Gateway-required VNet integration is only supported on the Dedicated (App Service) plan ### functions-gateway-vnet-integration-dedicated-only [IN] OBSERVATION Gateway-required VNet integration is only supported on the Dedicated (App Service) plan ### 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. ### 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. ### functions-hybrid-connections-windows-only [IN] OBSERVATION Azure Functions Hybrid Connections (Azure Relay) are Windows only, not supported on Consumption plan or Linux. ### functions-max-5000-apps-per-subscription [IN] OBSERVATION Maximum of 5,000 function apps per Azure subscription across all hosting plans. ### functions-max-5000-per-subscription [IN] OBSERVATION Azure Functions has a maximum of 5,000 function apps per subscription across all hosting plans. ### functions-networking-consumption-no-vnet [IN] OBSERVATION Azure Functions Consumption plan does not support private endpoints, VNet integration, or outbound IP restrictions ### functions-networking-consumption-no-vnet-integration [IN] OBSERVATION Azure Functions Consumption plan does not support private endpoints, VNet integration, or outbound IP restrictions ### 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 ### functions-networking-flex-consumption-subnet-delegation [IN] OBSERVATION Flex Consumption function apps use subnet delegation `Microsoft.App/environments`, which differs from Premium/Dedicated plans ### 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 ### 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 ### 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 ### 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 ### 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 ### 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 ### 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). ### 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. ### 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 ### 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. ### functions-python-requires-linux [IN] OBSERVATION Azure Functions Python runtime requires Linux — no Windows support. ### 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) ### 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. ### 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. ### 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. ### gateway-subnet-required-for-vpn-gateway [IN] OBSERVATION A dedicated GatewaySubnet is required within the VNet for VPN gateway deployments. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### k8s-secret-volumes-use-tmpfs [IN] OBSERVATION Kubernetes secret volumes use tmpfs and are never written to disk; they are namespace-scoped ### 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. ### keda-uses-scaledobject-crd [IN] OBSERVATION KEDA uses a CRD called ScaledObject and scales based on event count rather than resource utilization metrics. ### 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. ### 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. ### 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. ### keyvault-cert-issuer-vault-scoped [IN] OBSERVATION Certificate issuer objects in Key Vault are vault-scoped and cannot be shared across vaults. ### keyvault-certificates-as-certificate-objects [IN] OBSERVATION Certificates should be stored as Key Vault certificate objects (not secrets) to enable autorotation ### keyvault-certificates-as-certificate-objects-not-secrets [IN] OBSERVATION Certificates should be stored as Key Vault certificate objects (not secrets) to enable autorotation ### keyvault-certificates-store-as-certificate-objects [IN] OBSERVATION Certificates should be stored as Key Vault certificate objects (not secrets) to enable autorotation. ### 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. ### keyvault-control-plane-endpoint [IN] OBSERVATION Key Vault control plane endpoint is `management.azure.com:443`; data plane endpoint is `.vault.azure.net:443`. ### keyvault-crypto-user-cannot-delete-keys [IN] OBSERVATION Key Vault Crypto User role can create new keys but cannot delete them ### keyvault-crypto-user-create-not-delete [IN] OBSERVATION Key Vault Crypto User role can create new keys but cannot delete them. ### keyvault-custom-roles-use-dataactions [IN] OBSERVATION Custom roles for Key Vault data plane operations use `DataActions` (not `Actions`). ### 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). ### keyvault-data-plane-multitenant [IN] OBSERVATION The Key Vault data plane is multitenant — multiple customer vaults can share the same public IP address. ### 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. ### 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. ### 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. ### keyvault-expired-certs-retrievable-but-inoperable [IN] OBSERVATION Expired certificates can still be retrieved from Key Vault but may fail TLS validation. ### 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. ### 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. ### 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. ### keyvault-keys-json-web-key-format [IN] OBSERVATION Key Vault keys are represented as JSON Web Key (JWK) objects following JOSE specifications. ### 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. ### 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. ### keyvault-managed-hsm-single-tenant [IN] OBSERVATION Managed HSM pools are single-tenant with isolated security domains, while standard vaults are multi-tenant. ### keyvault-microsoft-never-sees-keys [IN] OBSERVATION Azure Key Vault is designed so Microsoft cannot see or extract customer keys. ### 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. ### 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. ### 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 ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### keyvault-purge-privileged-operation [IN] OBSERVATION The `purge` permission (permanent deletion of soft-deleted secrets) is a privileged operation distinct from `delete`. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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 ### 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. ### 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. ### 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. ### keyvault-rbac-switch-invalidates-access-policies [IN] OBSERVATION Switching to Azure RBAC permission model immediately invalidates all existing Key Vault access policies. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### keyvault-secret-max-size-25kb [IN] OBSERVATION Azure Key Vault secrets have a maximum size of 25 KB per secret. ### 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. ### 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. ### 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 ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### keyvault-soft-deleted-objects-only-purge-or-recover [IN] OBSERVATION Only two operations are possible on soft-deleted Key Vault objects: purge and recover. ### keyvault-soft-deleted-objects-two-operations [IN] OBSERVATION Only two operations are possible on soft-deleted Key Vault objects: purge and recover. ### 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). ### keyvault-standard-fips-140-level-1 [IN] OBSERVATION Azure Key Vault Standard tier uses software-protected keys validated to FIPS 140 Level 1. ### 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. ### 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. ### 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). ### 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) ### 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. ### 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). ### 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). ### 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. ### 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). ### 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. ### 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. ### kv-cert-contacts-shared-across-vault [IN] OBSERVATION Certificate contacts in Key Vault are shared across all certificates in the vault. ### 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. ### 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. ### 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. ### kv-cert-issuer-vault-scoped [IN] OBSERVATION Certificate issuer objects in Key Vault are vault-scoped and cannot be shared across vaults. ### 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). ### 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. ### 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. ### 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. ### 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. ### 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`. ### kv-custom-roles-use-dataactions [IN] OBSERVATION Custom roles for Key Vault data plane operations use `DataActions` (not `Actions`). ### kv-ec-curves-p256-p384-p521-secp256k1 [IN] OBSERVATION Key Vault supports EC curves P-256, P-384, P-521, and secp256k1 (P-256K). ### 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. ### 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. ### 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. ### 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. ### 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). ### 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. ### kv-keys-jwk-representation [IN] OBSERVATION Key Vault keys are represented as JSON Web Key (JWK) objects following JOSE specifications. ### kv-managed-hsm-single-tenant-isolated [IN] OBSERVATION Managed HSM pools are single-tenant with isolated security domains, separate from Key Vault vaults. ### 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. ### 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. ### 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. ### 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. ### 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. ### kv-premium-hsm-keys-never-leave-boundary [IN] OBSERVATION Premium HSM key types (RSA-HSM, EC-HSM, OCT-HSM) never leave the HSM boundary. ### 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. ### kv-rbac-custom-roles-use-dataactions [IN] OBSERVATION Custom roles for Key Vault data plane operations use DataActions (not Actions) in the role definition. ### 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. ### 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). ### kv-rsa-key-sizes-2048-3072-4096 [IN] OBSERVATION Key Vault supports RSA key sizes of 2048, 3072, and 4096 bits. ### kv-software-keys-not-in-managed-hsm [IN] OBSERVATION Software-protected keys are only available in Key Vault vaults, not in Managed HSMs. ### kv-standard-fips-140-level-1 [IN] OBSERVATION Key Vault Standard tier uses software-protected keys validated at FIPS 140 Level 1. ### kv-switching-rbac-invalidates-access-policies [IN] OBSERVATION Switching to Azure RBAC permission model for Key Vault immediately invalidates all existing access policies. ### lb-admin-state-overrides-health-probe [IN] OBSERVATION Admin State can override health probe behavior for maintenance windows on Azure Load Balancer. ### lb-backend-pool-cannot-contain-private-endpoints [IN] OBSERVATION Azure Load Balancer backend pools cannot contain Private Endpoints. ### 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. ### lb-basic-health-probes-not-supported-with-vmss [IN] OBSERVATION Basic SKU Load Balancer health probes are not supported with Virtual Machine Scale Sets. ### 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. ### lb-basic-probe-not-supported-vmss [IN] OBSERVATION Basic SKU Load Balancer health probes are not supported with Virtual Machine Scale Sets. ### lb-basic-probes-not-supported-with-vmss [IN] OBSERVATION Basic SKU Load Balancer health probes are not supported with Virtual Machine Scale Sets. ### lb-basic-sku-retired-sept-2025 [IN] OBSERVATION Azure Load Balancer Basic SKU was retired on September 30, 2025. ### lb-does-not-store-customer-data [IN] OBSERVATION Azure Load Balancer does not store customer data — it processes traffic in real-time without persistence. ### 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. ### 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. ### lb-http-probe-blocked-ports [IN] OBSERVATION HTTP health probes cannot use ports 19, 21, 25, 70, 110, 119, 143, 220, or 993. ### 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. ### lb-http-probe-no-hostname-probing [IN] OBSERVATION HTTP health probes on Azure Load Balancer do not support hostname-based probing. ### lb-http-probe-restricted-ports [IN] OBSERVATION HTTP health probes cannot use ports 19, 21, 25, 70, 110, 119, 143, 220, or 993. ### 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. ### 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). ### 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. ### lb-icmp-ip-fragmentation-not-supported [IN] OBSERVATION ICMP and IP fragmentation are not supported by Azure Load Balancer load-balancing rules. ### 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. ### lb-inbound-nat-rules-no-probe-required [IN] OBSERVATION Inbound NAT rules do not require a health probe; only load balancing rules require one. ### 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. ### 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. ### 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. ### lb-ip-fragmentation-not-supported [IN] OBSERVATION IP fragmentation is not supported on Azure Load Balancer rules. ### lb-multiple-frontend-ips-supported [IN] OBSERVATION An Azure Load Balancer can have multiple frontend IP configurations. ### lb-no-icmp-no-ip-fragmentation [IN] OBSERVATION ICMP and IP fragmentation are not supported by Azure Load Balancer load-balancing rules. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### lb-probe-outbound-unaffected [IN] OBSERVATION Health probe failure affects only inbound connectivity; outbound connectivity from backend instances remains unaffected. ### 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. ### 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. ### 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. ### 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. ### lb-public-lb-provides-outbound-nat [IN] OBSERVATION Public load balancer provides outbound connectivity for VMs by translating private IPs to public IPs (SNAT). ### 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. ### lb-standard-built-on-zero-trust [IN] OBSERVATION Standard Azure Load Balancer is built on the Zero Trust network security model. ### 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. ### 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. ### lb-stopped-vms-not-probed [IN] OBSERVATION Stopped VMs are not probed by load balancer health probes until started again. ### lb-stopped-vms-remain-in-backend-pool [IN] OBSERVATION Stopped/deallocated VMs can remain in an Azure Load Balancer backend pool. ### lb-three-skus-basic-standard-gateway [IN] OBSERVATION Azure Load Balancer has three SKUs: Basic (retired), Standard, and Gateway. ### 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. ### 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. ### 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. ### lb-zero-trust-security-model [IN] OBSERVATION Azure Standard Load Balancer is built on the Zero Trust network security model. ### managed-disks-only-lrs-zrs [IN] OBSERVATION Azure Managed Disks only support LRS and ZRS redundancy options. ### 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. ### 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. ### 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. ### mgmt-group-max-10000-per-directory [IN] OBSERVATION A single Microsoft Entra directory supports up to 10,000 management groups. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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." ### mgmt-group-single-parent-rule [IN] OBSERVATION Each management group and subscription can have only one parent management group. ### 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. ### 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. ### mgmt-groups-max-10000-per-directory [IN] OBSERVATION A single Microsoft Entra directory supports up to 10,000 management groups. ### 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. ### 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. ### 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. ### 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". ### mgmt-groups-single-parent-rule [IN] OBSERVATION Each management group and subscription can have only one parent management group. ### microsoft-cloud-security-benchmark-underpins-waf [IN] OBSERVATION Microsoft Cloud Security Benchmark provides the control framework that underpins WAF Security pillar guidance. ### microsoft-recommends-private-link-over-service-endpoints [IN] OBSERVATION Microsoft recommends Azure Private Link/private endpoints over service endpoints for new deployments. ### network-contributor-covers-all-subnet-operations [IN] OBSERVATION The Network Contributor built-in role covers all subnet RBAC operations (read, write, delete, join, joinViaServiceEndpoint). ### network-contributor-no-vm-deployment [IN] OBSERVATION Network Contributor lets you manage networks but does not allow deploying VMs or directly accessing the networks. ### network-contributor-role-covers-subnet-operations [IN] OBSERVATION The Network Contributor built-in role covers all subnet RBAC operations (read, write, delete, join, joinViaServiceEndpoint). ### 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. ### never-disable-route-propagation-on-gatewaysubnet [IN] OBSERVATION Route propagation must never be disabled on GatewaySubnet — the gateway will stop functioning. ### 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. ### 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. ### 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. ### object-replication-block-blobs-only [IN] OBSERVATION Object replication supports block blobs only (not append or page blobs). ### object-replication-cross-tenant-default-false [IN] OBSERVATION AllowCrossTenantReplication defaults to false for storage accounts created after December 15, 2023. ### 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. ### object-replication-destination-readonly [IN] OBSERVATION The destination container becomes read-only while a replication policy is active; writes return HTTP 409 Conflict. ### object-replication-fails-archive-tier [IN] OBSERVATION Object replication fails if either the source or destination blob is moved to the archive tier. ### 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. ### object-replication-gpv2-premium-block-only [IN] OBSERVATION Object replication is supported only on general-purpose v2 and premium block blob storage account types. ### object-replication-max-1000-rules [IN] OBSERVATION Each object replication policy supports up to 1,000 rules. ### 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. ### 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. ### 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. ### object-replication-no-customer-managed-failover [IN] OBSERVATION Customer-managed failover is not supported for storage accounts participating in object replication. ### 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. ### object-replication-no-hierarchical-namespace [IN] OBSERVATION Object replication is not supported for storage accounts with hierarchical namespace enabled (Data Lake Storage Gen2). ### object-replication-no-hns-adls-gen2 [IN] OBSERVATION Object replication does not support storage accounts with hierarchical namespace enabled (ADLS Gen2 / Data Lake Storage). ### 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. ### 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. ### object-replication-priority-sla-15min [IN] OBSERVATION With priority replication enabled (same continent), 99% of objects replicate within 15 minutes (SLA-backed). ### 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. ### object-replication-snapshots-not-replicated [IN] OBSERVATION Snapshots are not replicated and version IDs are not preserved during object replication. ### object-replication-version-ids-not-preserved [IN] OBSERVATION Object replication does not preserve version IDs — destination blobs receive new version IDs. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### policy-definition-displayname-128-description-512 [IN] OBSERVATION Azure Policy definition `displayName` is capped at 128 characters and `description` at 512 characters. ### 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). ### 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`. ### 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. ### 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. ### 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. ### 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. ### policy-metadata-property-limit-1024-chars [IN] OBSERVATION Each Azure Policy metadata property (`version`, `category`, `preview`, `deprecated`, `portalReview`) is limited to 1024 characters. ### 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. ### policy-single-effect-per-definition [IN] OBSERVATION Each Azure Policy definition contains exactly one effect in its `policyRule`; multiple effects require multiple policy definitions. ### policy-twelve-supported-effects [IN] OBSERVATION Azure Policy supports 12 effects: `addToNetworkGroup`, `append`, `audit`, `auditIfNotExists`, `deny`, `denyAction`, `deployIfNotExists`, `disabled`, `manual`, `modify`, `mutate`. ### 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). ### 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. ### 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. ### 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. ### private-endpoint-requires-private-dns-zones [IN] OBSERVATION Azure Private Endpoints require Azure DNS / Private DNS Zones for name resolution of the private endpoint. ### 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. ### 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. ### 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. ### 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. ### 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. ### private-link-requires-private-dns-zones [IN] OBSERVATION Azure DNS / Private DNS Zones are required for name resolution of private endpoints. ### private-link-service-requires-standard-load-balancer [IN] OBSERVATION Azure Private Link Service requires a Standard Load Balancer (not Basic) as its backend. ### 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. ### private-link-traffic-stays-on-microsoft-backbone [IN] OBSERVATION Azure Private Link traffic traverses the Microsoft backbone network and never crosses the public internet. ### 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. ### private-link-zone-resilient [IN] OBSERVATION Azure Private Link spans Availability Zones and is zone resilient. ### 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. ### queue-storage-max-message-64kb [IN] OBSERVATION Azure Queue Storage messages have a maximum size of 64 KB; queues can contain millions of messages. ### rbac-access-evaluation-order [IN] OBSERVATION Azure RBAC access evaluation order: token acquisition → retrieve role/deny assignments → check deny → check roles → check conditions. ### rbac-actions-control-plane-dataactions-data-plane [IN] OBSERVATION Actions/NotActions apply to the control plane; DataActions/NotDataActions apply to the data plane. ### 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. ### 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. ### 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. ### 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. ### 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. ### rbac-assignment-three-elements [IN] OBSERVATION An Azure RBAC role assignment has exactly three elements: security principal, role definition, and scope. ### rbac-built-on-arm [IN] OBSERVATION Azure RBAC is built on Azure Resource Manager; all access decisions flow through ARM's global endpoint. ### 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. ### 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. ### rbac-custom-role-cannot-scope-to-root [IN] OBSERVATION Custom roles cannot set AssignableScopes to the root scope (`"/"`). ### rbac-custom-role-dataactions-no-management-group-scope [IN] OBSERVATION Custom roles with DataActions cannot be assigned at management group scope. ### rbac-custom-role-max-2000-assignable-scopes [IN] OBSERVATION Custom roles support a maximum of 2,000 AssignableScopes per role definition. ### rbac-custom-role-no-root-scope [IN] OBSERVATION Custom roles cannot have AssignableScopes set to root scope (`"/"`). ### rbac-custom-role-no-root-scope-assignable [IN] OBSERVATION Custom roles cannot set AssignableScopes to root scope (`"/"`). ### rbac-custom-role-no-wildcards-in-assignable-scopes [IN] OBSERVATION Wildcards cannot be used in AssignableScopes for custom role definitions. ### rbac-custom-role-one-management-group-in-assignable-scopes [IN] OBSERVATION Only one management group can be defined in a custom role's AssignableScopes. ### 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. ### 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. ### 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`. ### rbac-custom-roles-limit-5000-per-tenant [IN] OBSERVATION Azure has a limit of 5,000 custom roles per tenant (2,000 for 21Vianet). ### rbac-data-globally-replicated [IN] OBSERVATION Azure RBAC data (definitions, assignments, deny assignments) is stored and replicated globally across all Azure regions. ### 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. ### rbac-effective-permissions-formula [IN] OBSERVATION Azure RBAC effective permissions are calculated as `Actions - NotActions` for management plane and `DataActions - NotDataActions` for data plane. ### 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. ### rbac-free-with-every-subscription [IN] OBSERVATION Azure RBAC is included free with every Azure subscription at no additional cost. ### rbac-group-membership-transitive [IN] OBSERVATION Group memberships are transitive for Azure RBAC role assignment purposes — nested group members inherit roles. ### 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). ### rbac-network-contributor-cannot-deploy-vms [IN] OBSERVATION Network Contributor role allows managing networks but does not grant permission to deploy virtual machines. ### 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. ### 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. ### 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. ### 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. ### rbac-permission-strings-case-insensitive [IN] OBSERVATION Azure RBAC permission strings (e.g., `Microsoft.Compute/*/read`) are case-insensitive. ### rbac-reader-role-id-guid [IN] OBSERVATION The Azure RBAC Reader role has the immutable ID `acdd72a7-3385-48ef-bd42-f606fba81ae7`. ### 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. ### rbac-role-four-permission-components [IN] OBSERVATION Azure RBAC role definitions have four permission components: Actions, NotActions, DataActions, and NotDataActions. ### 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. ### rbac-scope-hierarchy [IN] OBSERVATION Azure RBAC scope hierarchy from broadest to narrowest: management group > subscription > resource group > resource. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### redis-basic-tier-no-sla [IN] OBSERVATION Azure Cache for Redis Basic tier has no SLA and runs on a single VM. ### 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. ### 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. ### 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. ### 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. ### redis-clustering-premium-and-enterprise-only [IN] OBSERVATION Azure Cache for Redis clustering is available only on Premium, Enterprise, and Enterprise Flash tiers. ### 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. ### 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. ### 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. ### 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). ### 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. ### 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. ### redis-enterprise-modules-only [IN] OBSERVATION Only Enterprise tiers support Redis Modules (RediSearch, RedisBloom, RedisJSON, RedisTimeSeries). ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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). ### redis-five-service-tiers [IN] OBSERVATION Azure Cache for Redis has five service tiers: Basic, Standard, Premium, Enterprise, and Enterprise Flash. ### redis-five-tiers [IN] OBSERVATION Azure Cache for Redis offers five service tiers: Basic, Standard, Premium, Enterprise, and Enterprise Flash. ### 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. ### 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. ### redis-keys-command-avoid-production [IN] OBSERVATION The Redis `KEYS` command is expensive and should be avoided in production; use `SCAN` instead. ### redis-modules-enterprise-only [IN] OBSERVATION Redis modules (RediSearch, RedisBloom, RedisJSON, RedisTimeSeries) are available only on Enterprise tiers of Azure Cache for Redis. ### 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. ### redis-oss-clustering-requires-premium [IN] OBSERVATION OSS Redis clustering requires Azure Cache for Redis Premium tier or higher. ### 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. ### 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. ### 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. ### redis-persistence-premium-enterprise-only [IN] OBSERVATION Only Premium and Enterprise tiers of Azure Cache for Redis support data persistence (RDB and AOF). ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### redis-private-link-all-tiers [IN] OBSERVATION Azure Cache for Redis supports network isolation via Private Link on all tiers (Basic through Enterprise Flash). ### 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. ### redis-sla-covers-connectivity-only [IN] OBSERVATION Azure Cache for Redis SLA covers connectivity to cache endpoints only, not data loss protection. ### redis-smaller-values-better-performance [IN] OBSERVATION Redis works best with smaller values; large data should be broken into smaller chunks across multiple keys. ### 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. ### redis-tls-12-required-by-default [IN] OBSERVATION Azure Cache for Redis requires TLS by default; TLS 1.2 is the recommended minimum version. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### redis-zone-redundancy-standard-premium-enterprise [IN] OBSERVATION Azure Cache for Redis zone redundancy is available on Standard, Premium, and Enterprise tiers — not Basic. ### 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. ### service-endpoints-arm-only [IN] OBSERVATION VNet service endpoints are only available for VNets deployed via Azure Resource Manager (not classic deployment model). ### service-endpoints-arm-only-not-classic [IN] OBSERVATION VNet service endpoints are only available for Azure Resource Manager (ARM) deployments, not classic deployments. ### 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. ### service-endpoints-configured-per-subnet [IN] OBSERVATION VNet service endpoints are configured per-subnet, not per-VNet — each subnet must be independently enabled. ### 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. ### service-endpoints-disk-traffic-not-affected [IN] OBSERVATION Disk traffic (managed and unmanaged) is not affected by Azure Storage service endpoint routing changes. ### 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. ### service-endpoints-dns-unchanged [IN] OBSERVATION Enabling VNet service endpoints does not change DNS resolution — Azure service FQDNs still resolve to public IP addresses. ### 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. ### service-endpoints-enabling-closes-tcp-connections [IN] OBSERVATION Enabling or disabling service endpoints closes existing TCP connections — should be avoided during critical operations. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### service-endpoints-rbac-join-action-required [IN] OBSERVATION Enabling VNet service endpoints requires the RBAC permission Microsoft.Network/virtualNetworks/subnets/joinViaServiceEndpoint/action. ### service-endpoints-require-joinviaserviceendpoint-action [IN] OBSERVATION Enabling VNet service endpoints requires the RBAC permission `Microsoft.Network/virtualNetworks/subnets/joinViaServiceEndpoint/action`. ### service-endpoints-resource-manager-only [IN] OBSERVATION VNet service endpoints are only available for VNets deployed via Azure Resource Manager (not classic deployment model). ### 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. ### 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. ### servicebus-auto-delete-idle-min-5min [IN] OBSERVATION Azure Service Bus auto-delete on idle minimum interval is 5 minutes. ### 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. ### 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. ### 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. ### servicebus-duplicate-detection [IN] OBSERVATION Azure Service Bus supports duplicate detection — queue or topic discards duplicate copies when a sender resends, enabling safe retries. ### 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. ### 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. ### servicebus-express-entities-not-supported-premium [IN] OBSERVATION Express entities are not supported in Azure Service Bus Premium namespaces. ### 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). ### 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. ### servicebus-large-message-batching-not-supported [IN] OBSERVATION Azure Service Bus large message batching is not supported. ### 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. ### 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. ### 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. ### servicebus-message-sessions-enable-fifo [IN] OBSERVATION Azure Service Bus message sessions enable FIFO (first-in, first-out) guarantee and request-response patterns. ### servicebus-message-sessions-fifo [IN] OBSERVATION Azure Service Bus message sessions enable FIFO (first-in-first-out) guarantees and request-response patterns. ### 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. ### servicebus-namespace-dozens-of-vms [IN] OBSERVATION An Azure Service Bus namespace spans dozens of all-active VMs, optionally across three availability zones. ### servicebus-namespace-spans-3-azs [IN] OBSERVATION Azure Service Bus namespaces optionally span 3 availability zones for zone-redundant storage. ### 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). ### 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. ### 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. ### 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. ### 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. ### servicebus-premium-cpu-scaling-thresholds [IN] OBSERVATION Azure Service Bus Premium scaling guidance: scale down below 20% CPU, scale up above 70% CPU. ### 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. ### 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). ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### servicebus-primary-protocol-amqp [IN] OBSERVATION Azure Service Bus primary wire protocol is AMQP 1.0 (ISO/IEC standard); also supports HTTP/REST. ### servicebus-pull-mode-delivery [IN] OBSERVATION Azure Service Bus delivers messages via pull mode (long-lived pull), not push. ### 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. ### 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. ### servicebus-sbmp-retiring-sep-2026 [IN] OBSERVATION Azure Service Bus SBMP protocol is retiring September 30, 2026. ### servicebus-security-sas-rbac-managed-identities [IN] OBSERVATION Azure Service Bus supports three security mechanisms: SAS (Shared Access Signatures), RBAC, and Managed Identities. ### 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). ### servicebus-subscription-default-filter-true [IN] OBSERVATION Azure Service Bus subscription default rule is a true filter that selects all messages from the topic. ### 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). ### servicebus-subscriptions-durable-by-default [IN] OBSERVATION Azure Service Bus subscriptions are durable by default but can be configured to auto-expire. ### servicebus-transactions-single-entity [IN] OBSERVATION Azure Service Bus transactions scope to a single messaging entity (queue, topic, or subscription). ### servicebus-triple-redundant-storage [IN] OBSERVATION Azure Service Bus stores messages in triple-redundant storage, spanning availability zones if zone-enabled. ### 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. ### 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. ### storage-archive-not-supported-zrs-gzrs [IN] OBSERVATION Archive access tier is not supported on ZRS, GZRS, or RA-GZRS storage accounts. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### storage-gzrs-microsoft-recommended [IN] OBSERVATION GZRS is Microsoft's recommended redundancy option for maximum consistency, durability, availability, and disaster recovery performance. ### 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. ### storage-lrs-11-nines-durability [IN] OBSERVATION LRS provides 11 nines (99.999999999%) durability by replicating data 3 times within a single datacenter. ### storage-lrs-3-replicas-single-datacenter [IN] OBSERVATION LRS replicates data 3 times synchronously within a single datacenter; provides 11 nines durability. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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). ### storage-unmanaged-disks-no-zrs-gzrs [IN] OBSERVATION Unmanaged disks do not support ZRS or GZRS redundancy options. ### 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. ### storage-zrs-12-nines-durability [IN] OBSERVATION ZRS provides 12 nines (99.9999999999%) durability by replicating data synchronously across 3+ availability zones. ### storage-zrs-3-availability-zones [IN] OBSERVATION ZRS replicates data synchronously across 3+ availability zones in the primary region; provides 12 nines durability. ### storage-zrs-recommended-datalake-files [IN] OBSERVATION ZRS is Microsoft's recommended redundancy option for Azure Data Lake Storage and Azure Files workloads. ### subnet-cannot-delete-with-resources [IN] OBSERVATION A subnet can only be deleted if it contains no resources; resources must be removed first. ### 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. ### 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`. ### 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. ### 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. ### 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. ### subnet-private-preview-no-default-outbound [IN] OBSERVATION Private Subnet (Preview) prevents default outbound internet access for VMs deployed in the subnet. ### subnet-private-preview-prevents-default-outbound [IN] OBSERVATION Private Subnet (Preview) prevents default outbound internet access for VMs deployed in the subnet. ### 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). ### 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). ### 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. ### 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. ### 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. ### 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. ### 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. ### vnet-gateway-hierarchy-routeserver-expressroute-vpn [IN] OBSERVATION When multiple gateways are deployed, the hierarchy is: Route Server > ExpressRoute > VPN. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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). ### vnet-route-server-precedence-over-vpn-expressroute [IN] OBSERVATION Route Server takes precedence over VPN and ExpressRoute gateways when deployed in the same VNet. ### vnet-routing-longest-prefix-match [IN] OBSERVATION Azure VNet routing uses longest-prefix match to determine which route wins among same-priority routes. ### 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. ### 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. ### vnet-service-tag-routes-max-25-per-table [IN] OBSERVATION Maximum 25 service-tag routes per route table in Azure UDRs. ### 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. ### 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. ### 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. ### 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. ### 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. ### waf-five-pillars [IN] OBSERVATION The Azure Well-Architected Framework has five pillars: Reliability, Security, Cost Optimization, Operational Excellence, and Performance Efficiency. ### 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. ### waf-l7-ddos-protection-l3l4 [IN] OBSERVATION WAF protects at Layer 7; Azure DDoS Protection protects at Layer 3/4 — they are complementary ### waf-mission-critical-always-available-guidance [IN] OBSERVATION Mission-critical workloads have dedicated WAF guidance focused on always-available, failure-resilient design. ### waf-mission-critical-dedicated-guidance [IN] OBSERVATION Mission-critical workloads have dedicated WAF guidance focused on always-available, failure-resilient design. ### 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. ### waf-reliability-disaster-recovery-and-testing-complementary [IN] OBSERVATION Disaster recovery and testing strategies are distinct but complementary practices within the WAF Reliability pillar. ### waf-reliability-disaster-recovery-and-testing-distinct [IN] OBSERVATION In the WAF Reliability pillar, disaster recovery and testing strategies are distinct but complementary practices. ### 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. ### waf-reliability-four-strategies [IN] OBSERVATION Reliability in WAF is achieved through four strategies: redundancy, scaling, self-healing/preservation, and simplicity. ### waf-reliability-maturity-model [IN] OBSERVATION The WAF Reliability pillar includes a maturity model for assessing reliability posture progression. ### 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. ### waf-reliability-target-process [IN] OBSERVATION Reliability target planning follows a four-step flow: identify flows → failure mode analysis → set targets → monitoring/alerting. ### 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. ### 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. ### waf-security-asset-protection-layers [IN] OBSERVATION WAF security asset protection covers: segmentation, identity & access management, network protection, encryption, resource hardening, and secrets management. ### waf-security-cia-triad [IN] OBSERVATION The three security objectives of the WAF Security pillar are the CIA triad: Confidentiality, Integrity, and Availability. ### waf-security-cia-triad-structure [IN] OBSERVATION The WAF Security pillar is organized around the CIA triad (confidentiality, integrity, and availability). ### waf-security-defense-in-depth [IN] OBSERVATION Defense in depth is the overarching security strategy Azure recommends in the WAF Security pillar. ### 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. ### waf-security-foundation-sequence [IN] OBSERVATION The WAF security foundation sequence is: security baselines → secure development lifecycle (SDL) → data classification → threat monitoring → threat modeling. ### waf-security-maturity-model [IN] OBSERVATION The WAF Security pillar includes a formal security maturity model for assessing organizational readiness. ### waf-security-organized-around-cia-triad [IN] OBSERVATION The WAF Security pillar is organized around the CIA triad: confidentiality, integrity, and availability. ### 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. ### 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. ### 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. ### 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.