Azure AZ-600 common mistakes
Azure AZ-600 · Understand the traps and how to avoid them.
Treating Azure Stack Hub as if it were public Azure and applying public-Azure-only features (availability zones, certain PaaS SKUs, Azure Policy guest configuration) when planning a deployment.
Candidates study general Azure administration first and assume feature parity; Azure Stack Hub is a discrete, validated appliance with a constrained service catalog and its own update cadence.
What to do instead
Anchor every design decision to the Azure Stack Hub service catalog and the validated hardware/software matrix; explicitly state which public-Azure features are absent and design the compensating control instead.
Sizing capacity from VM counts alone without accounting for the infrastructure reserve, the stamp's fault domains, and the requirement to keep headroom for updates and node drain.
Candidates carry over public-Azure elasticity assumptions and forget that an Azure Stack Hub stamp cannot burst; the infrastructure role consumes a fixed slice of compute and storage.
What to do instead
Compute usable capacity by subtracting the infrastructure reserve and update headroom from raw capacity, then map tenant workloads onto fault domains and confirm that a single node's worth of drain still fits.
Confusing the connected and disconnected (air-gapped) deployment paths, including how updates and the marketplace syndication are delivered in each.
Both paths share the same portal experience, so candidates overlook that disconnected stamps need an offline update package, a local marketplace source, and a separate identity decision.
What to do instead
For each scenario, state the connectivity model first, then derive the update mechanism, the marketplace source, and the identity provider from it before answering.
Planning identity with Microsoft Entra ID and AD FS as interchangeable when they impose different constraints on multi-tenancy, guest access, and the operator's own sign-in.
Candidates know Entra ID from public Azure and assume AD FS is a drop-in substitute, missing the differences in tenant onboarding and in how the operator authenticates to the admin portal.
What to do instead
Decide identity up front from the tenancy requirement: Entra ID for multi-tenant and B2B scenarios, AD FS for disconnected or directory-independent stamps, then trace the consequences for tenant registration and admin access.
Granting tenant users operator-level access, or placing operator roles in the tenant directory, when designing the offer/plan/quota delegation model.
The separation between the Azure Stack Hub administrator subscription and tenant subscriptions is easy to blur, and candidates reuse public-Azure RBAC habits without noticing the boundary.
What to do instead
Keep operator roles in the admin directory and tenant roles in the tenant directory; design offers, plans, quotas, and add-ons so tenants self-serve within quota without touching infrastructure roles.
Forgetting to publish or update a plan to make a newly added service or quota change visible, then concluding the service is broken.
Changes to plans and quotas do not propagate to existing subscriptions automatically, and the portal gives little feedback that a republish step is required.
What to do instead
Treat plan changes as a publish-then-verify sequence: update the plan, republish it, and confirm the change appears for an existing subscription before troubleshooting elsewhere.
Answering marketplace questions with the public marketplace as the source, ignoring that Azure Stack Hub needs its own syndicated or offline marketplace content.
The marketplace UI looks identical, so candidates assume items are available on demand; in reality the operator curates and downloads content, and disconnected stamps need a manual import.
What to do instead
Describe the operator's marketplace workflow explicitly: register or download the item, confirm it is available to the intended offer, and for disconnected stamps plan the offline import path.
Diagnosing a failed update or a degraded stamp by restarting services or nodes before checking the update history and the health/alert state of the infrastructure roles.
Candidates default to public-Azure troubleshooting reflexes; on Azure Stack Hub the update engine, the infrastructure role health, and the alert list are the primary diagnostic sources and the order matters.
What to do instead
Follow the documented sequence: read the update run history and current status, review active alerts and infrastructure role health, and only then consider remediation actions such as resume or rerun.
Treating backup of the stamp as equivalent to workload backup, and skipping the requirement to store the operator backup off the appliance and to test restore.
Candidates conflate infrastructure backup (which captures the stamp's control-plane state) with tenant data protection, and underestimate how quickly an on-appliance backup is lost with the stamp.
What to do instead
Separate the two concerns: schedule infrastructure backup to an external SMB location with the required encryption key stored separately, and design tenant data protection independently.
Overlooking the operational prerequisites for servicing: the OEM update package, the partner's firmware step, and the order in which hardware and software updates are applied.
Candidates focus on the Azure-side update and forget that an Azure Stack Hub update is a joint operation with the hardware partner, where skipping the OEM step can block or break the software update.
What to do instead
State the full servicing chain for the scenario: confirm the OEM package and firmware level, apply them in the documented order, verify the stamp is healthy, then run the software update.