4.5 Practice Drills and Readiness Markers

Numbers and rules to drill

This domain rewards recall of exact thresholds. Drill these until automatic:

Also fix the error code in memory: capacity rejection returns CapacityLimitExceeded with messages about reaching compute limits.

Streaming and resilience drills

Reliability of long-running and streaming workloads is a recurring theme. A production Structured Streaming notebook must survive interruptions (platform maintenance, transient faults) and restart without reprocessing everything. The correct design uses a checkpoint location: Spark persists offsets and state so the stream resumes from where it stopped, delivering exactly-once or minimal-duplicate processing. Pair this with idempotent writes to the sink so any replayed micro-batch does not create duplicates.

For eventstreams, recall the throttling exception: instead of rejecting the stream, Fabric reduces the CU allocated to keeping it open when the capacity is overloaded, then restores it once the capacity recovers. For Real-Time Intelligence generally, the 20-second interactive delay stage is skipped so latency stays low; throttling only begins at the rejection phase.

Self-test prompts

• Name the surface for: 'why was my interactive job delayed 20 seconds?' (Capacity Metrics throttling chart)
• Name the remedy for: 'reports filter on region and scan too much' (Z-Order on region)
• Name the cause for: 'shortcut broke after upstream folder move' (changed source path)

Readiness markers

You are ready for this domain when, given any stem, you can in one pass: (1) identify the item type and whether the issue is capacity or item-level, (2) choose the monitoring surface that matches the scope and time horizon, (3) select the remediation (maintenance command, config change, or alert), and (4) explain why each distractor is wrong. Track repeated misses to a specific cue — 'I keep choosing bigger SKU when the fault is a schema change' — rather than treating errors as random.

A practical readiness bar: score mixed questions across all four buckets (monitoring, errors, performance, capacity) and confirm the result holds after a one-day break. If smoothing-versus-throttling or the V-Order-versus-Z-Order distinction wobbles, re-drill the table above before moving on. Because this domain is 30-35% of the exam, stability here moves your overall score more than any other single chapter.

A worked capacity drill

To cement smoothing, walk through the official illustrative example. One background operation consumes 1 CU-hour (1 CU for 1 hour = 3,600 CU-seconds). On an F2 capacity, that work is smoothed over 24 hours = 2,880 thirty-second timepoints, so it contributes only 1.25 CUs per timepoint. An F2 supplies 2 CUs/second, i.e. 60 CUs per 30-second timepoint, so the job lands as just ~2.1% of any single timepoint. Even though the job consumed roughly six times the CU available in the next 10 minutes outright, smoothing means no throttling occurs because each timepoint absorbs only a sliver.

The lesson generalizes: heavy background jobs rarely throttle a capacity on their own; throttling comes from many concurrent operations stacking smoothed usage past the limits. When that happens, options are: wait (capacities self-heal as carryforward burns down), temporarily increase the SKU (each timepoint gains idle capacity so carryforward burns down faster), or pause and resume (resets future-capacity usage to zero so new work is accepted immediately, at the cost of a billing event for accumulated usage).

Note also that in-flight operations are never throttled — only requests submitted after throttling begins are delayed or rejected, so jobs already running always finish.

Study cadence and final markers

Drill in short, mixed sets rather than one long block, and always explain the distractors aloud. Rotate through: vocabulary (V-Order vs Z-Order, smoothing vs throttling), workflow order (rerun-from-failed, maintenance order), configuration choices (pool/autoscale/NEE), and full scenarios. You are exam-ready for this domain when you can, without hesitation, name the correct monitoring surface, maintenance command, or capacity action for any stem and justify why the others fail — and that performance survives a one-day break. Given its 30-35% weight, treat this chapter as the anchor of your DP-700 preparation.

One-line answers to rehearse

Rehearse these one-liners until they are reflexive: small files means OPTIMIZE; read-heavy Direct Lake means V-Order; filtered scans means Z-Order; storage cleanup means VACUUM at 7-plus days; stale plan estimates means warehouse statistics; worst historical query means query insights; live sessions means DMVs; automated failure alert means Fabric Activator; historical KQL trends means workspace monitoring; recent runs means the Monitoring hub; CU cost and throttling means the Capacity Metrics app. If any of these mappings is slow to recall, that is precisely the cue to drill before test day.