Azure AZ-104Trap Reference

Commonly Confused Services on AZ-104

Azure Administrator confusions cluster around services that differ by a single dimension: network layer, failure domain, or whether the constraint is on identities or resources. Missing that dimension is the mechanism of the wrong answer.

Each section below gives you the deciding signal, a quick check to run when you encounter the confusion, and why the wrong answer keeps looking right.

Network Security Group (NSG)Azure FirewallApplication Gateway WAF
#1

Subnet/NIC traffic filter vs. stateful full-featured firewall vs. web-layer protection

All 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)
#2

Cloud identity provider vs. managed LDAP/Kerberos domain vs. on-premises AD

All 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
#3

Direct Azure-to-Azure routing vs. encrypted internet tunnel vs. dedicated private circuit

All 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
#4

L4 regional vs. L7 regional vs. DNS global vs. HTTP global

All 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
#5

Passwordless Azure resource identity vs. app credential object vs. app definition in Entra

All 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
#6

Centralized backup service vs. disaster recovery replication vs. point-in-time disk copy

All 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.

LRSZRSGRSGZRS
#7

Single datacenter vs. zone-redundant vs. geo-redundant vs. zone-and-geo redundant

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.

Azure PolicyAzure RBAC
#8

Resource configuration compliance vs. identity permission assignment

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
#9

Container image storage vs. container orchestration vs. single-container run

All 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
#10

Routing log data vs. subscription-level events vs. resource operation logs

All 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.

Train these confusions, not just read them

10 AZ-104 questions. Pattern-tagged with trap analysis. Free, no signup required.

Start AZ-104 Mini-Trainer →