Network Security Group (NSG)Azure FirewallApplication Gateway WAF
#1All three filter network traffic, so candidates apply NSGs universally without checking the inspection level required.
Deciding signal
NSGs contain allow/deny rules based on source/destination IP, port, and protocol. They are stateful but simple — no application inspection, no FQDN-based rules, no threat intelligence. They apply at the subnet or NIC level. Azure Firewall is a fully managed stateful firewall with FQDN-based rules (allow or deny by domain name), threat intelligence feed integration, and centralized logging across VNets. Application Gateway WAF is an HTTP/HTTPS reverse proxy with a built-in WAF — it inspects web request content for OWASP top-10 threats and custom rules. The deciding factor is inspection depth: IP/port filter (NSG), FQDN and threat-intelligence rules (Azure Firewall), web-layer content inspection (App Gateway WAF).
Quick check
Is this filtering by IP and port at the subnet level (NSG), applying FQDN rules and threat intelligence at the network layer (Azure Firewall), or inspecting HTTP request content for web attacks (App Gateway WAF)?
Why it looks right
NSGs handle most traffic filtering questions and candidates apply them to scenarios requiring FQDN rules or web-layer inspection. Azure Firewall is specifically correct when outbound FQDN control or threat intelligence is required.
Microsoft Entra ID (Azure AD)Microsoft Entra Domain ServicesActive Directory Domain Services (on-premises)
#2All three are forms of "Active Directory," so candidates treat them as equivalent cloud vs. on-premises options.
Deciding signal
Entra ID (Azure AD) is a cloud identity platform — it handles modern authentication (OAuth, OIDC, SAML), manages users and groups, and is the identity backend for Microsoft 365 and Azure. It does not support legacy Kerberos or LDAP. Entra Domain Services (Azure AD DS) is a managed service that provides traditional LDAP, Kerberos, and NTLM authentication in the cloud — enabling legacy applications that require domain join, Group Policy, or LDAP to run in Azure without on-premises AD. On-premises AD DS runs on Windows Server in your own data center. When a scenario involves lifting and shifting legacy applications that require LDAP or Kerberos to Azure without running domain controllers, Entra Domain Services. When it involves modern cloud identity for Azure and M365, Entra ID.
Quick check
Is this modern cloud identity with OAuth/SAML (Entra ID), managed legacy LDAP/Kerberos for lifted applications in Azure (Entra Domain Services), or traditional on-premises domain controllers (AD DS on-premises)?
Why it looks right
Entra ID is the default "Azure Active Directory" answer. Entra Domain Services is correct when the scenario describes legacy applications requiring domain join, Group Policy, or LDAP in Azure — capabilities that Entra ID does not provide.
VNet PeeringAzure VPN GatewayAzure ExpressRoute
#3All three connect networks, so candidates apply VPN Gateway universally without distinguishing private Azure routing from hybrid connectivity.
Deciding signal
VNet Peering connects two Azure VNets directly over the Microsoft backbone — no gateway, no encryption overhead, low latency, high bandwidth. It is the right answer for VNet-to-VNet connectivity within Azure or across regions (global VNet peering). VPN Gateway connects Azure VNets to on-premises networks via encrypted IPsec tunnels over the public internet, or connects two VNets via a VNet-to-VNet connection. ExpressRoute provides a private dedicated circuit from on-premises to Azure via a connectivity provider — bypassing the public internet with guaranteed bandwidth. The signal is the connectivity scope: Azure-to-Azure (VNet Peering), Azure-to-on-premises via internet (VPN Gateway), Azure-to-on-premises via private circuit (ExpressRoute).
Quick check
Is this connecting two Azure VNets (VNet Peering), connecting Azure to on-premises over an encrypted internet tunnel (VPN Gateway), or connecting Azure to on-premises over a private dedicated circuit (ExpressRoute)?
Why it looks right
VPN Gateway is applied to VNet-to-VNet scenarios where VNet Peering is the simpler, lower-latency, lower-overhead answer. Peering is often overlooked because VPN is the more prominent concept.
Azure Load BalancerAzure Application GatewayAzure Traffic ManagerAzure Front Door
#4All four distribute traffic, so candidates apply Application Gateway universally for any "load balancing" question.
Deciding signal
Azure Load Balancer operates at Layer 4 (TCP/UDP) within a region — it distributes traffic based on IP and port without HTTP inspection. Application Gateway operates at Layer 7 within a region — it routes based on URL path, host header, or cookie; terminates SSL; and includes WAF. Traffic Manager is a DNS-based global router — it resolves DNS to different regional endpoints based on routing methods (Performance, Weighted, Geographic, Priority) without proxying traffic. Front Door is a global HTTP/HTTPS proxy with content delivery, WAF, URL routing, and intelligent failover — it proxies and accelerates both static and dynamic content globally.
Quick check
Is this Layer 4 within a region (Load Balancer), Layer 7 with URL routing and WAF within a region (Application Gateway), DNS-only global routing with no HTTP proxy (Traffic Manager), or global HTTP proxy with WAF and CDN (Front Door)?
Why it looks right
Application Gateway is the prominent web load balancer. Traffic Manager is confused with Front Door because both are "global" — but Traffic Manager only resolves DNS and cannot inspect or proxy HTTP traffic.
Managed IdentityService PrincipalApp Registration
#5All three allow applications to authenticate to Azure services, so candidates apply service principals universally.
Deciding signal
An App Registration is the definition of an application in Entra ID — it creates an application object and a service principal. A Service Principal is the identity of an application or service in a specific tenant — it has credentials (client secret or certificate) that the application uses to authenticate. A Managed Identity is an automatically managed service principal for an Azure resource (VM, App Service, Function App) — Azure handles credential rotation, so no secret is stored or managed by the developer. Managed Identity is the right answer when the scenario involves Azure resources accessing other Azure services (Key Vault, Storage) without credential management. Service Principal with a secret is used when the application runs outside Azure or Managed Identity is not supported.
Quick check
Is this an Azure resource accessing other Azure services without credential management (Managed Identity), an application running outside Azure that needs credentials to authenticate (Service Principal), or defining an application in Entra to enable OAuth flows (App Registration)?
Why it looks right
Service Principals are the traditional app identity mechanism. Managed Identity is the correct answer when the application is an Azure resource — candidates miss that Managed Identity eliminates credential management entirely.
Azure BackupAzure Site RecoveryAzure Snapshots
#6All three protect data against loss, so candidates apply Backup universally without distinguishing backup from DR.
Deciding signal
Azure Snapshots are point-in-time copies of managed disks — they capture the disk state at a specific moment and are stored in Azure Storage. They are taken manually or via scripts and are useful for disk restoration but are not a managed backup service. Azure Backup is a centralized managed backup service with configurable retention policies, lifecycle rules, and cross-region restore capabilities for VMs, databases, file shares, and on-premises workloads. Azure Site Recovery (ASR) provides disaster recovery replication — it continuously replicates VMs to a secondary region so that failover can happen within minutes with a defined RPO and RTO. The distinction: Backup protects against data loss (backup/restore); Site Recovery protects against regional outages (failover/failback).
Quick check
Is this point-in-time disk copies without managed retention (Snapshots), centralized managed backup with retention policies (Azure Backup), or continuous replication for regional DR failover (Site Recovery)?
Why it looks right
Azure Backup is the default "protect data" answer. Site Recovery is correct when the scenario describes a regional disaster scenario with failover objectives — not data corruption or accidental deletion recovery.
All four are Azure Storage redundancy options and candidates memorize acronyms without understanding the failure domains.
Deciding signal
LRS (Locally Redundant Storage) replicates data three times within a single datacenter — protects against hardware failures but not datacenter or zone failures. ZRS (Zone-Redundant Storage) replicates across three availability zones in a region — survives a zone failure. GRS (Geo-Redundant Storage) replicates to a secondary region asynchronously — survives a full regional outage but the secondary is read-only by default until failover. GZRS (Geo-Zone-Redundant Storage) combines zone redundancy in the primary region with geo-replication to a secondary region — the highest protection tier. The exam tests which redundancy option matches the failure domain in the scenario: datacenter (LRS), zone (ZRS), region (GRS or GZRS).
Quick check
Does the scenario require surviving a datacenter failure only (LRS), an AZ failure (ZRS), a full region failure (GRS), or both AZ failure and region failure (GZRS)?
Why it looks right
GRS is often selected as the "safe" answer. ZRS is correct when the requirement is availability zone resilience without geographic replication — and is frequently overlooked.
Both appear in governance questions and both restrict what can happen in a subscription.
Deciding signal
RBAC controls what authenticated users and service principals can do — it grants or denies actions like "create a VM" or "read Key Vault secrets." Azure Policy evaluates resource properties and either audits, denies, or remediates non-compliant configurations — for example, requiring all storage accounts to enforce HTTPS, or requiring specific tags on resources. A user with RBAC permissions to create a storage account can still be blocked by Azure Policy if the storage account configuration does not comply with a policy rule. They operate on different objects: RBAC on identities, Policy on resources.
Quick check
Is the requirement to control what actions a user can perform (RBAC), or to enforce that resources are configured in specific ways regardless of who creates them (Azure Policy)?
Why it looks right
RBAC is the default governance tool for AZ-104 candidates. Azure Policy is correct when the constraint is on resource configuration rather than on user actions — a distinction that matters for compliance scenarios.
Azure Container RegistryAzure Kubernetes ServiceAzure Container Instances
#9All three are described as container services, so candidates blur storage, orchestration, and single-container execution.
Deciding signal
Azure Container Registry (ACR) is an image registry — it stores and versions Docker and OCI container images. It does not run containers. AKS is a managed Kubernetes service that runs and orchestrates containerized workloads at scale — it is the right answer when the scenario involves deploying, scaling, and managing containerized microservices. Container Instances (ACI) runs individual containers directly without orchestration — fast to start, billed per second, suitable for simple containerized tasks or jobs that do not need Kubernetes features. When the scenario involves storing container images, ACR. Orchestrating many containers with scaling and networking, AKS. Running a single container quickly without a cluster, ACI.
Quick check
Is this storing container images (ACR), running a single isolated container task (ACI), or orchestrating many containers with Kubernetes (AKS)?
Why it looks right
AKS is the prominent container service and candidates apply it to single-container scenarios where ACI is the simpler, correct answer. ACI is specifically for running containers without cluster management overhead.
Azure Monitor Diagnostic SettingsAzure Activity LogAzure Resource Logs
#10All three involve logs in Azure Monitor, so candidates treat them as equivalent log sources.
Deciding signal
The Activity Log captures subscription-level management operations — who created, modified, or deleted a resource, and when. It answers "what happened to this subscription or resource at the control plane?" It is automatically captured and retained for 90 days. Resource Logs (formerly Diagnostic Logs) capture data plane operations within a resource — queries on a database, requests to a storage account, operations on a Key Vault. They are not collected by default and must be enabled. Diagnostic Settings are the configuration that routes Activity Logs and Resource Logs to a destination (Log Analytics workspace, Storage Account, Event Hub). When the scenario asks "what was changed in this subscription last week," Activity Log. When it asks for query logs from a specific database, Resource Logs. When it asks how to send logs to a SIEM, Diagnostic Settings.
Quick check
Is this subscription-level management events (Activity Log), resource-level operation logs like database queries (Resource Logs), or the configuration for routing logs to a destination (Diagnostic Settings)?
Why it looks right
Activity Log and Resource Logs are both "logs" and candidates conflate them. Activity Log is the control plane; Resource Logs are the data plane — the target resource and the action plane are different for each.
10 AZ-104 questions. Pattern-tagged with trap analysis. Free, no signup required.
Start AZ-104 Mini-Trainer →