Stamp Expansion and Capacity Planning Under a Fixed Budget
Contoso operates a connected Azure Stack Hub integrated system with 4 nodes, each with 384 GB RAM and 12 TB of raw NVMe. The stamp hosts three plans: Dev, Shared, and Production. Production currently uses 62 percent of the stamp's memory and 71 percent of its storage. The capacity model shows that adding a single node requires a full stamp update plus an on-site hardware visit that the datacenter can schedule only once per quarter. Finance approved budget for exactly one node this fiscal year. The platform team wants to onboard a new analytics workload that needs 1.5 TB of memory and 8 TB of storage, but only for the first six weeks of each quarter. Leadership asks whether to add the node now, defer it, or reclaim capacity from Dev.
1. Recommend how the team should satisfy the analytics demand this fiscal year, and justify the decision using the stamp's capacity and operational constraints.
Read the worked answer
The analytics demand is bursty (six weeks per quarter) and large (1.5 TB memory, 8 TB storage). Adding one node to a 4-node stamp increases aggregate memory by 384 GB, which is far below the 1.5 TB the analytics workload needs. So a single node does not solve the problem regardless of timing. The correct move is to reclaim capacity from Dev and Shared first, and to negotiate a smaller analytics footprint or accept a scheduled burst window.
Reasoning steps:
- Compare the ask to the increment. One node adds 384 GB; the requirement is 1.5 TB. The increment is insufficient, so buying the node now does not satisfy the demand.
- Protect Production headroom. Production is at 62 percent memory and 71 percent storage. Adding tenants that push Production past safe thresholds risks throttling and failed updates, because stamp updates need headroom to drain and migrate workloads.
- Use the burst pattern. Because analytics runs only six weeks per quarter, the team can time onboarding to quarterly maintenance windows and use quotas to cap Dev during the burst.
- Treat the single-node purchase as a resilience and growth investment, not as analytics capacity. Schedule it for the next quarterly hardware window and use the time to right-size Dev quotas.
The judgment the exam is testing: do not confuse an approved purchase with a sufficient one. Reclaim, re-time, and right-size before committing hardware.
2. Production is at 71 percent storage. What operational risk does this create during a stamp update, and what should be done before the next update?
Read the worked answer
Stamp updates run infrastructure and service updates across the stamp and may require draining, migrating, or restarting tenant workloads. If storage is near capacity, the stamp may not have room to perform those migrations, and updates can stall or fail. A failed update on an integrated system is a high-severity event that often requires Microsoft support engagement.
Recommended actions before the update:
- Bring storage utilization down to a level that leaves room for update operations; the platform team should define and document a threshold and enforce it with quotas.
- Identify orphaned disks, snapshots, and unneeded backups in Production and remove them.
- Move cold data to a different plan or to external storage where the workload allows.
- Cap Dev and Shared storage quotas so they cannot consume the headroom needed for updates.
- Validate the headroom against the published capacity guidance for the specific update package before scheduling the window.
The key judgment: capacity headroom is an operational prerequisite for updates, not merely a performance concern. Treating storage as full when it is 71 percent used is a planning failure, not a surprise.