Azure AZ-305 common mistakes
Azure AZ-305 · Understand the traps and how to avoid them.
Choosing an Azure Policy definition with the Deny effect (or a plain Audit policy) for a requirement that says new or existing resources must be automatically configured - for example 'every new storage account must have diagnostic settings sent to the central Log Analytics workspace'.
Candidates memorise 'governance = Azure Policy' and stop at the effect name, without mapping the requirement's verb (block vs. audit vs. auto-configure vs. remediate) to the correct effect. Deny only prevents; it never creates the missing configuration.
What to do instead
Build a verb-to-effect mapping before answering: block = Deny; flag = Audit / AuditIfNotExists; auto-configure on create = DeployIfNotExists (plus a managed identity with the needed role and, for existing resources, a remediation task); change an existing resource's properties = Modify; tag inheritance = Modify/Append. If the requirement mentions existing resources, DeployIfNotExists/Modify alone is insufficient - a remediation task is required.
Using Microsoft Entra B2B collaboration when the scenario describes external consumers self-registering on a public-facing app with their own social or email identities and custom branding, or conversely using an external/consumer identity service for partner employees who must access internal Teams and SharePoint.
Both features are described as 'external identities', so candidates treat them as interchangeable and pick whichever name looks familiar in an answer option.
What to do instead
Anchor on the relationship: B2B = guests are represented in your tenant directory and authenticate with their own home credentials to access your resources (partners, vendors, cross-tenant collaboration, Teams/SharePoint). External/consumer identity (B2C-style) = customers sign up into a separate consumer directory with local or social accounts, with custom UI and user flows, and are not members of the workforce tenant. If the users are customers of a product, it is the consumer service; if they are collaborators using your productivity apps, it is B2B.
Proposing an Azure Monitor metric alert on a platform metric to detect high memory usage or low free disk space on virtual machines, and omitting the Azure Monitor Agent / data collection rule from the monitoring design.
The portal's 'Metrics' blade shows CPU, network and disk I/O for VMs, so candidates assume the full guest OS metric set is available natively. Guest-level metrics are emitted by the in-guest agent, not the host.
What to do instead
Classify each metric in the requirement as host/platform (CPU, network in/out, disk IOPS, VM availability) versus guest OS (memory %, free disk space, page file, process counters, Windows event logs, syslog). Any guest-level item forces Azure Monitor Agent with a data collection rule (or the legacy diagnostics extension) sending to Log Analytics, with alerts evaluated on log search or on the collected metric. State the agent explicitly in the design.
Selecting geo-redundant storage (GRS) when the requirement states that users or a reporting system must be able to read the data in the secondary region while the primary region is unavailable, or selecting read-access geo-redundant storage (RA-GRS) where the requirement is only regional resilience with the lowest latency.
All geo options sound like 'data survives a region loss', so the read-access nuance and the fact that zone-redundant storage protects against a datacenter failure within one region get flattened into 'redundancy = good'.
What to do instead
Decide on two axes separately: failure scope (datacenter = LRS/ZRS; region = GRS/GZRS family) and read access during primary unavailability (RA-GRS / RA-GZRS only). Also check the protocol: zone-redundant options exist for standard general-purpose v2, premium block blobs, and certain other account types - verify the specific account kind and region support before promising ZRS. If writes must continue in the secondary region, redundancy alone is not enough; that requires an active-active design.
Choosing Azure SQL Database for a workload whose requirements include cross-database queries, SQL Server Agent jobs, linked servers, or Service Broker, instead of Azure SQL Managed Instance.
All three Azure SQL offerings share the same engine name, so candidates optimise on 'fully managed PaaS is cheaper/simpler' and miss feature-level requirements that only near-100% surface area compatibility satisfies.
What to do instead
Scan the requirement list for instance-scoped features: cross-database/three-part-name queries, SQL Agent, linked servers, Service Broker, CLR, Database Mail, bulk insert from file, server-level roles. Any of these points to Managed Instance. If the requirement is a single database with elastic, unpredictable per-database utilisation across a set of databases, that points to elastic pools. If the requirement is full OS/instance control or a version not supported in PaaS, that points to SQL Server on Azure VMs.
Answering with a partition key or consistency level for Azure Cosmos DB that violates a stated hard constraint - for example selecting Strong consistency to satisfy a freshness requirement on an account that must support multi-region writes, or choosing a high-cardinality-but-skewed partition key such as a timestamp or tenant ID for a hot tenant.
Consistency levels are learned as a ranked list ('Strong is best'), and partition keys are treated as a minor naming detail rather than the unit of scale and the boundary of a transaction.
What to do instead
Treat the requirements as a filter, not a preference order: if multi-region writes are required, Strong and Bounded Staleness are off the table - choose Session or Consistent Prefix. For the partition key, require high cardinality plus even read/write distribution plus use in the queries' filters; note that a change feed or transactional batch cannot span partitions, and that a single logical partition caps throughput, so a skewed key becomes a hot partition.
Treating storage geo-replication or database geo-replication as the disaster-recovery answer for accidental deletion, ransomware, or application-level corruption, with no separate backup or soft-delete layer in the design.
Replication and backup are both described as 'copies in another region', so candidates satisfy the DR requirement with one mechanism and consider it covered.
What to do instead
Separate the threat models: replication and high availability protect against infrastructure failure and replicate destructive writes; backup protects against deletion, corruption and ransomware with point-in-time restore. For each data store, name both: e.g. blob soft delete + versioning + immutable storage for the tamper case, plus Azure Backup or the service's own PITR for restore; for SQL, geo-replication/auto-failover groups for availability plus short-term PITR and long-term retention for recovery.
Quoting an RTO or RPO that the selected service cannot deliver - for example promising a minutes-level RTO from a geo-restore backup, or assuming that every service in a region pair fails over automatically or that paired-region recovery is guaranteed during a widespread event.
Candidates rank services by 'has geo option' rather than by their documented recovery characteristics, and they assume region pairing implies automatic, orchestrated failover.
What to do instead
For each component write RPO and RTO from the design and check them against the mechanism: Azure Site Recovery for VM-level replication with orchestrated recovery plans; active-active or auto-failover groups for near-zero RPO; geo-restore for hours-level RTO; backup vault restore for point-in-time. State explicitly who or what triggers failover (automatic vs. customer-initiated), and include a tested runbook - a design that requires a manual, untested sequence cannot claim a low RTO.
Choosing the wrong layer-7/4 entry point for a web workload - using Traffic Manager where TLS termination, WAF, or URL-path routing is required, using a regional Application Gateway where global anycast routing and multi-region failover are required, or using a standard load balancer for HTTP host/path routing.
All four services are 'load balancers' and are compared on price and familiarity instead of on OSI layer, scope, and feature set.
What to do instead
Filter on three attributes: scope (global vs regional), layer (L4 vs L7), and features (WAF, TLS offload, path/host routing, caching, DNS-only). Global + L7 + WAF/caching = Front Door. Regional + L7 + WAF/path routing = Application Gateway. Global + DNS-based, no TLS termination, non-HTTP protocols allowed = Traffic Manager. Regional + L4, ultra-low latency, HA ports = Load Balancer. Combine them when the design needs both (e.g. Front Door in front of regional Application Gateways).
Designing a hub-and-spoke or multi-VNet topology that assumes VNet peering is transitive, that on-premises traffic will reach a spoke through the hub without gateway transit and route configuration, or that a single NSG at the hub will filter spoke-to-spoke traffic.
Peering reads like 'the networks are connected', so candidates assume full mesh behaviour and skip the routing and gateway-transit plumbing that a real hub-and-spoke needs.
What to do instead
State the routing explicitly: peering is non-transitive, so each spoke must peer with the hub and use a user-defined route (0.0.0.0/0 or the on-prem address space) pointing to a firewall/NVA in the hub, with IP forwarding enabled. Allow gateway transit on the hub peering and use remote gateways on the spoke for on-premises connectivity. Traffic between spokes then transits the hub firewall, where NSGs and Azure Firewall policy apply - NSGs on the hub's own subnet do not filter traffic passing through the appliance.