Microsoft Data Engineer Interview Preparation Guide - Mid Level

Direct answer

Don't try to average everyone's position into a compromise nobody's happy with. Ground the negotiation in the shared outcome, make the trade-offs between options explicit with evidence, and force a real decision (with an owner and a documented rationale) within a fixed timeframe. A compromise sticks when people can see why it was chosen, not just that it split the difference.

Structured elaboration

1. Reframe around outcome, not position. Ask each stakeholder what success looks like for them, not what they want built. Two stakeholders who seem opposed on the "what" often agree on the "why," which is where the real compromise lives.
2. Bring evidence, not opinions. Gather whatever is available and relevant: usage data, cost/effort estimates, prior incidents, qualitative feedback. A room full of opinions negotiates forever; a room with a shared set of facts converges faster.
3. Make trade-offs visible. Lay out 2-3 real options with their costs and benefits side by side, instead of a single proposal to accept or reject. People compromise more easily when they're choosing between concrete alternatives than when they're being asked to give up a specific ask.
4. Use a structured negotiation move. Propose a balanced default option first, then invite each side to request a bounded concession from it, rather than starting from each side's maximal ask and negotiating down. Time-box the discussion so it doesn't drift into re-litigating the same points.
5. Document the decision and name an owner. Write down what was decided, why, who owns it, and when it will be revisited. If the group truly can't converge, escalate with a specific recommendation rather than an open question, so the escalation itself doesn't become another unresolved debate.
6. Build in a review point. Treat the agreement as provisional and testable, not permanent. A short follow-up (after the next milestone, or a fixed number of weeks) to check whether the compromise is actually working keeps people bought in because they know it isn't final and unappealable.

Worked example

Three stakeholders disagree on scope for a feature: one wants the full version shipped now, one wants it deferred a quarter, one wants a stripped-down version shipped immediately. Instead of negotiating "how much scope," the facilitator asks each what outcome they're protecting: the first is protecting a customer commitment, the second is protecting engineering capacity for other work, the third is protecting the team's ability to learn before over-investing. That reframing surfaces a real option none of them had proposed: ship a narrow version that satisfies the customer commitment, explicitly scoped as a first iteration, with the deferred work logged and re-prioritized at the next planning cycle. The decision, the scope boundary, and the re-prioritization date are written down and shared with all three stakeholders.

Trade-offs & pitfalls

• Pitfall: false compromise, where everyone gets a token piece of what they asked for and the result satisfies no one's actual underlying need.
• Pitfall: skipping documentation. An undocumented "agreement" gets re-argued the moment someone's memory of it differs.
• Pitfall: treating consensus as required. Some decisions need a single accountable owner to make the call after input, not unanimous agreement, especially under a deadline.
• Senior differentiator: designing the forcing function (a default option, a timebox, a named decision owner) instead of facilitating an open-ended discussion indefinitely. That's what turns "several people who each want something different" into an actual decision.

Schema-on-write means you define and enforce a schema before data is loaded; anything that doesn't fit gets rejected or transformed at load time. Schema-on-read means you store the data as-is and only apply structure when a query actually reads it. The trade-off is agility and ingestion speed versus upfront quality guarantees.

What you gain and give up

Worked example

Say a new upstream system starts sending event data tomorrow, and nobody has fully agreed on its final field list yet. Under schema-on-write, you'd have to design a table schema, build and test a load job, and only then let anyone query it: useful once it's done, but it blocks any exploration until that's finished. Under schema-on-read, you land the raw events immediately and let an analyst start poking at them the same day, at the cost of not knowing yet whether every record is well-formed.

In practice, the two aren't mutually exclusive within one platform. A common pattern is to apply schema-on-read at ingestion (land raw data immediately, so nothing blocks exploration) and then promote a schema-on-write, validated version of the same data for anything the business depends on daily. That gives you the ingestion speed of one model and the quality guarantee of the other, on the same underlying data, at different points in its lifecycle.

Trade-offs and pitfalls

The most common mistake is picking one model as a blanket policy for an entire platform instead of matching it to the actual use case: forcing every new source through a heavyweight schema-on-write pipeline slows down legitimate exploration, while leaving everything permanently schema-on-read (never promoting anything to a validated layer) means business-critical reports are only as reliable as whatever query someone happened to write. The second pitfall is assuming schema-on-read has no cost: without a curated layer or documented conventions, different analysts querying the same raw data can apply subtly different parsing logic and land on different numbers for what should be the same metric.

Direct answer

When you own a backlog with bugs, tech debt, new features, incident response, and ad-hoc requests all competing for the same limited time, the discipline is to score every item against the same small set of explicit criteria, impact, effort, risk, and urgency, rather than deciding case by case from memory or from whoever asked most recently. The score becomes the thing you defend to stakeholders, not your own judgment in the moment, and it's revisited whenever new information genuinely changes one of the inputs.

Structured elaboration

1. Define the criteria concretely, not just by name. Impact: how many users, how much revenue, or how much risk this affects if done, or left undone. Effort: roughly how much time it takes, in the same unit across every item type so a bug and a feature can be compared. Risk: what happens if this is left undone, not just the effort to do it, this is what lets a low-effort security fix outrank a flashier feature. Urgency: whether there's a real external deadline or a decay function (a small bug today becomes a bigger one in a month) versus something that can wait indefinitely with no real cost.
2. Score, don't just rank from memory. Rate each item on impact, effort, and risk on a simple 1-to-5 scale, and use a basic formula like impact plus risk, divided by effort, to get a comparable number across wildly different item types, then sort by that number.
3. Defend the order with the score, not with authority. When a stakeholder asks why their request is ranked fourth instead of first, show them the same criteria applied to their item and to what's ahead of it. The conversation becomes about whether the inputs are right, which is negotiable and often genuinely useful feedback, rather than about whose request matters more, which isn't a productive conversation.
4. Revisit only when an input changes. A new production incident changes the risk score of related items and can legitimately jump them ahead; a stakeholder simply asking again does not change the score and should not move the item. This is what keeps the loudest or most recent request from silently winning over the highest-scoring one.

Worked example

Ranked by score: B (4.0), A (3.0), C (2.0), so the data-consistency bug goes first despite the VP request feeling more urgent socially.

A concrete time this changed what I worked on: a stakeholder pushed hard for Item A to ship before a client demo, using exactly this scoring conversation. We agreed A's risk score was actually higher than my original estimate, missing the demo had real revenue risk I hadn't weighted in, so A's risk moved from 1 to 4, its score rose to (2+4)/1, or 6.0, and it correctly jumped ahead of B. The scoring didn't override the stakeholder's judgment, it gave us a shared way to see that their information changed a real input, rather than the ranking just moving because they asked loudly.

Trade-offs and pitfalls

The most common failure is scoring once and never updating it: a static backlog ranking goes stale the moment a real production incident changes an item's actual risk, and the score has to be a living input, not a one-time exercise. The opposite failure, re-scoring every time someone re-asks without any new information, defeats the entire purpose, since it just means the loudest or most persistent voice wins again, dressed up in a number. Reducing everything to a single formula can also flatten genuinely different kinds of urgency, a compliance deadline is not the same kind of time pressure as a stakeholder wanting something by Friday, so the score should inform the conversation, not replace it entirely when there's a real qualitative reason to override it, as long as that override is stated explicitly rather than silently ignoring the framework.

Direct answer

The transactional outbox pattern gets atomicity between a local database update and publishing an event by writing the event as a plain row in the SAME database transaction as the business change, instead of trying to atomically commit across two separate systems (the database and the message broker). A separate background publisher then reads that outbox table and delivers the events, so the hard part of the problem (getting a message onto a broker) is pushed into an at-least-once delivery loop the consumer can absorb, rather than solved by a distributed commit protocol.

Why not just use a distributed transaction directly

A two-phase commit (2PC) across the database and the broker would need the broker to act as a participant in the same commit protocol as the database: it would have to accept a "prepare" call, hold the message uncommitted, and only make it visible once a coordinator later sends "commit". Kafka's and SQS's client APIs do not expose that kind of prepare/commit participant interface (Kafka has its own separate transactional-producer API, not an XA participant interface, XA being the X/Open standard for coordinating a transaction manager with multiple resource managers), so 2PC across a database and a managed broker directly is not something you can wire up against most production message buses. Even where a broker does support it, the coordinator becomes a blocking point: each participant holds its local lock from "prepare" until it hears back, so a coordinator crash between phases can leave a participant blocked indefinitely.

Outbox table schema

Writing the event

Inside the same database transaction that updates the business tables (e.g. orders), the application also inserts a row into outbox. Both inserts commit together or not at all, so there is no window where the business change exists without a corresponding outbox row, or vice versa.

Background publisher

A worker process polls with something like SELECT * FROM outbox WHERE status = 'pending' ORDER BY id FOR UPDATE SKIP LOCKED LIMIT 100. FOR UPDATE SKIP LOCKED lets multiple publisher instances run concurrently without two of them claiming the same row: each instance simply skips rows another instance already has locked. The worker publishes each claimed row to the broker, and only after the broker acknowledges does it mark the row sent. As an alternative to polling, a change-data-capture (CDC) tool such as Debezium can tail the database's write-ahead log (WAL, the durability log the database already writes before committing) and stream outbox inserts to the broker with lower latency and no polling interval, without any application code change.

Avoiding duplicates and lost events across a crash

Trace through a concrete run for outbox row id=482:

1. Application transaction commits: orders row and outbox row id=482 (status=pending) both durable together.
2. Publisher polls, claims row 482 via SELECT ... FOR UPDATE SKIP LOCKED.
3. Publisher sends row 482's payload to the broker; broker acknowledges receipt.
4. Publisher crashes before executing UPDATE outbox SET status='sent' WHERE id=482.
5. Publisher restarts, polls again; row 482 is still status='pending', so it gets re-claimed and re-published. The broker now has two copies of the same event.
6. Because row 482's id travels with the payload as a dedup key, the consumer (or the broker's own dedup mechanism) recognizes the second delivery as a repeat and drops or no-ops it.

If the crash instead happens before step 3 (before the publish call), nothing has reached the broker at all: row 482 simply stays pending and gets picked up on the next poll, with no data loss. The pattern never produces a business change with a missing event, only occasional duplicate deliveries, which is why the consumer side still needs to be idempotent or dedup-aware; the outbox guarantees "at least once", not "exactly once", on its own.

sequenceDiagram
    participant App
    participant DB as Database
    participant Pub as Publisher
    participant Bus as Message Bus
    App->>DB: BEGIN TXN
    App->>DB: INSERT orders row
    App->>DB: INSERT outbox row (pending)
    App->>DB: COMMIT
    Pub->>DB: SELECT pending FOR UPDATE SKIP LOCKED
    DB-->>Pub: outbox row id=482
    Pub->>Bus: publish(id=482)
    Bus-->>Pub: ack
    Pub->>DB: UPDATE outbox SET status=sent WHERE id=482

Production checklist

• Alert on outbox backlog depth (rows still pending beyond an expected age), not just publisher liveness, since a stuck publisher looks alive but stops draining the table.
• Retention job to delete or archive sent rows so the table doesn't grow unbounded.
• Partition/order guarantee: publish using aggregate_id as the broker partition key so events about the same entity are delivered in the order they were written.
• Version the payload schema so a newer producer and an older consumer can coexist during a rollout.

Trade-offs & pitfalls

Outbox trades immediate, synchronous cross-system consistency for simple local atomicity plus eventual, at-least-once delivery: the business transaction commits instantly (no waiting on the broker), but there is a real (if usually short) window between the commit and the event actually reaching the broker. A common mistake is treating "broker acknowledged" as "consumer processed": the outbox only guarantees the event left the outbox table, not that the ultimate side effect happened, so end-to-end correctness still depends on consumer idempotency. Another common mistake is forgetting to key on aggregate_id for ordering, or running multiple publisher instances without SKIP LOCKED-style claiming, which produces either out-of-order delivery or duplicate publishes from two workers claiming the same row simultaneously.

Normalization aims to prevent redundancy and maintain data integrity.
Three common anomalies:

• Update anomaly: when redundant data exists, updating one copy but not others causes inconsistency. Example: product price stored in orders; changing price requires updating many rows.
• Insertion anomaly: cannot insert a record without unrelated data. Example: storing customer and order in same table prevents adding a customer until they place an order.
• Deletion anomaly: deleting a row unintentionally removes other needed data. Example: deleting an order row that also contained product details could remove the only copy of a product description.
  Normalization (up to 3NF) separates entities into tables so updates, inserts, and deletes affect only the intended records, preventing these anomalies while preserving referential integrity.

Direct answer

With limited engineering capacity and a backlog of data-quality issues of varying severity, prioritize using a framework that weighs business impact, likelihood of recurrence, and ease of fix together, rather than working purely by reported severity or purely by whichever issue is loudest, and build cross-team alignment around a shared solution by making the cost of NOT solving it collectively visible to everyone who would otherwise keep patching their own symptom independently.

Structured elaboration

• Prioritization framework: score each issue on business impact (revenue, trust, or compliance risk if unaddressed), likelihood of recurrence (a one-time fluke versus a systemic pattern likely to keep causing incidents), and ease of fix (quick win versus multi-quarter investment), and use the combination, not any single dimension alone, since a high-impact-but-nearly-impossible-to-fix issue and a low-impact-but-trivial-to-fix issue both deserve very different treatment than a mid-impact, systemic, moderately-hard-to-fix issue that might actually be the highest-leverage item on the list.
• Building cross-team alignment: when multiple teams each want their own fix prioritized, the highest-leverage move is often identifying that several teams' individually-requested fixes are actually symptoms of the same underlying, systemic root cause (a shared schema-registry gap, a missing common validation framework); making that shared root cause visible reframes the conversation from "whose fix goes first" to "let's jointly fund the one fix that helps everyone," which is a fundamentally easier negotiation.
• Getting commitment without direct authority: bring data, not opinions, to the prioritization conversation (quantified incident counts, quantified business impact per team) and let the shared, objective picture do the persuading, rather than relying on personal influence alone.

Worked example

Three different teams each separately request their own data-quality fix be prioritized this quarter. Digging into the actual root cause of all three reveals they all stem from the same underlying gap: no shared schema-registry enforcement across producer teams. Reframing the ask from three competing, team-specific requests into one shared infrastructure investment, with each team's incident history used as concrete evidence of the collective cost of not fixing it, turns three competing priorities into one aligned, jointly-funded initiative that serves all three teams' actual underlying need. Scoring this alongside two other backlog items on a simple 1 (low) to 3 (high) scale per dimension, and summing the three scores, makes the trade-off concrete rather than just narrated:

The schema-registry gap wins the priority order (7, then 6, then 5) precisely because it combines high impact with high recurrence, even though it is the hardest of the three to fix, which is the case the framework is built to catch: scoring on ease of fix alone would have wrongly ranked the two quick patches above the systemic, harder, but far higher-leverage fix.

Trade-offs and pitfalls

The temptation under pressure is to simply work the backlog in the order requests arrived, or to prioritize whichever team is loudest, both of which systematically under-invest in quieter-but-higher-leverage systemic fixes in favor of whoever advocates hardest for their specific, narrower issue. A framework that explicitly scores business impact and recurrence likelihood, and actively looks for shared root causes across seemingly-separate requests, protects against exactly that bias.

Direct answer

A backfill is running a pipeline's transformation logic against a range of already-elapsed time (or already-landed data) to produce the output that should exist for that range, because it never ran, ran incorrectly, or needs to reflect a rule that did not exist when the data was first processed. It targets the past on demand, unlike the pipeline's normal incremental run, which only ever moves forward onto newly arriving data.

Structured elaboration

A backfill is forced by one of a small number of situations, and naming which one you're in changes how you'd run it:

1. Outage / gap: the pipeline simply did not run for some window (a scheduler failure, an upstream source down), so there is no output for that period at all.
2. Bug in the transform: the pipeline ran, but the logic was wrong, so a past window's output needs replacing, not filling in.
3. Definition change: a metric or feature's meaning changes (a new business rule, a corrected calculation), and history needs to reflect the new definition for comparability.
4. Late-arriving source data: upstream systems deliver records after the window that consumed them already closed and published.
5. New pipeline / dataset onboarding: a pipeline is switched on today but needs history from before it existed.
6. Upstream schema or identifier change: already-landed raw data needs reprocessing once a mapping or fix is available.
7. Disaster recovery: a downstream table was lost or corrupted and needs to be rebuilt from immutable raw sources.

The first three are the ones that actually change what the output should say (correction, redefinition); the rest are about filling in output that should already exist. That distinction matters because a correction or redefinition backfill has to reconcile with whatever already consumed the old, wrong output, while a gap-fill or historical load usually does not.

Worked example

A daily active users pipeline retains 400 days of partitioned output. A dedupe bug is found that undercounted the metric for the last 40 days only; the other 360 days were computed before the bug was introduced. The backfill only needs to touch the 40 affected date partitions, not the full 400:

$\frac{40}{400} = 0.10$

so the reprocessing cost is proportional to 10% of the retained table, not 100%, because the affected range is scoped by partition. Compare that to onboarding this same pipeline fresh today with no prior output: that backfill has to cover all 400 days, a full historical load, because there is no "already correct" portion to leave alone. The cost driver in both cases is the same: how many partitions actually need to change, not the size of the whole table.

Trade-offs & pitfalls

Scoping a backfill to only the affected partitions (using deterministic, idempotent writes keyed by partition) is what keeps the cost proportional to the actual damage; reprocessing the whole table "to be safe" trades a real, avoidable compute cost for a false sense of thoroughness. Blindly appending backfilled rows instead of overwriting the affected partitions atomically produces duplicates. The most common wrong turn is forgetting that anything materialized on top of the reprocessed table (rollups, dashboards, downstream models) also has stale output for that same window and needs its own rerun once the backfill lands, a backfill that stops at the first table it touches leaves the corruption one layer further downstream.

Direct answer. Confirm the OR is defeating index usage by checking whether each branch, on its own, would use an index efficiently but the combined OR forces the optimizer to consider matches from either branch and fall back to a scan; the fix is to rewrite the OR as a UNION ALL of the individual branches, each independently indexable, or an IN-list where the branches are all equality checks on the same column.

Structured elaboration. Many optimizers can use an index efficiently for a single equality or range predicate, but a compound OR across DIFFERENT columns (or a mix of predicate shapes) often can't be satisfied by walking a single index in one pass, since the matching rows for each branch could live anywhere relative to each other in that index's ordering. Rewriting the OR as a UNION ALL of separately-filtered queries lets each branch use its own most-appropriate index independently, with the results combined afterward, rather than forcing one combined scan to somehow satisfy both conditions at once. When every branch of the OR is an equality check on the SAME column, an IN-list is the more natural and equally effective rewrite instead of a UNION ALL.

Worked example. I verified this rewrite preserves results exactly with a small dataset of three events (click, view, purchase) filtered for (type = 'click' OR type = 'view') AND created_at > '2025-01-01':

-- OR across the same column: index usage depends on the optimizer's transform ability
SELECT * FROM events
WHERE (type = 'click' OR type = 'view') AND created_at > TIMESTAMP '2025-01-01';

-- explicit UNION ALL: each branch can use its own index independently
SELECT * FROM events WHERE type = 'click' AND created_at > TIMESTAMP '2025-01-01'
UNION ALL
SELECT * FROM events WHERE type = 'view'  AND created_at > TIMESTAMP '2025-01-01';

Both forms return the same two matching rows (the click and view events, correctly excluding the purchase event), confirming the rewrite is correctness-preserving for this predicate shape.

Trade-offs and pitfalls. UNION ALL, not UNION, is the correct rewrite whenever the original OR's branches can't produce overlapping duplicate rows (as here, since a row can't simultaneously be type='click' and type='view'); using UNION instead would silently add an unnecessary deduplication pass. When branches CAN overlap and produce genuine duplicates under a UNION ALL rewrite, you need either a UNION (accepting its dedup cost) or an explicit condition making the branches mutually exclusive.

Complexity

This rewrite doesn't change the total rows scanned in the worst case, but it changes each branch from a potential full scan to an independent, appropriately-indexed lookup, which is where the real savings comes from.

Edge cases

If the OR's branches can produce the exact same row (for example, an OR across ranges on the SAME column that overlap), a UNION ALL rewrite would duplicate that row in the output; verify the branches are genuinely mutually exclusive before choosing UNION ALL over UNION.

Situation: As a data engineer in a distributed org, we need async-first conventions that reduce interruptions but allow rapid unblocking across timezones.

Conventions (high-level):

• Async-first culture: prefer tickets + channels; use DMs only for truly private issues.
• Follow “15-minute rule”: if no meaningful async progress in 15 minutes during overlapping working hours, escalate.

Channel naming patterns:

• #data-prod-<team>-alerts — automated pipeline/monitoring alerts (read-only for infra)
• #data-ops-incident — active incidents (create per incident thread)
• #data-requests-<team> — developer requests, onboarding, schema changes
• #data-arch-<topic> — design discussions (persistent)
• @oncall-<team> — pager for paging rotations

Ticket priority definitions (must map to SLAs):

• P0 (Sev1): Production pipelines down, data consumers blocked, SLA breach imminent. Response target: 15 min, follow-on updates every 15 min.
• P1 (Sev2): Partial data degradation, non-critical downstream failures. Response target: 1 hour, updates every 2 hours.
• P2: Feature work, schema changes, requests that block dev but not production. Response target: next business day.
• P3: Backlog, enhancements, docs. Response target: within 5 business days.

Recommended incident message templates (post to #data-ops-incident and ticket):

• Incident start:
  • [INCIDENT] <short title>
  • Impact: <who is affected, e.g., "analytics and reporting; daily ETL job failed; 200k rows missing">
  • Detection time: <UTC>
  • Owner: <name, oncall>
  • Current state: <what's known>
  • Next step & ETA: <what we're doing and when next update will be>
• Status update:
  • [UPDATE][INCIDENT] <time UTC> — <progress>, <blocking>, <next ETA>
• Incident resolved:
  • [RESOLVED][INCIDENT] <time UTC>
  • Root cause (brief), remediation, rollback if any, follow-up ticket # for postmortem

Ticket template (for P0/P1):

• Title: [P1][PipelineName] Short problem
• Description: Steps to reproduce, logs, job IDs, last successful run, recent deploys, data samples
• Impact: who/how
• Attempts: what we've tried
• Owner & suggested next action
• Timezone of reporter and required overlap window

Escalation rules to synchronous calls:

• Call immediately (within 15 min) if: P0 AND data consumers are actively blocked now (e.g., dashboards down during business hours) OR mitigation requires live coordination across teams.
• Schedule short, agenda-led bridge (max 30 min) if: repeated rapid exchanges (>5 messages in 10 min) without convergence during overlapping hours.
• Avoid calls across non-overlapping timezones unless there is a P0; instead document runbook steps and assign oncall in target timezone.
• Use "call only" label on ticket to require voice if consented by owner and oncall.

Best practices:

• Every alert must link to runbook; if none, create one post-incident.
• Use thread replies for updates to avoid channel noise.
• Tag only the required people: @oncall, @team, not broad @channel.
• End every async update with explicit next step and ETA.

This set balances quiet focus with clear, measurable SLAs and simple escalation triggers so teams can unblock quickly without unnecessary disruption.

Direct answer

I shipped a change to a signup flow that looked correct in every test environment but broke for users on a specific combination of browser and network condition we hadn't covered, and it was a customer, not our monitoring, who found it first, mid-demo, which made the failure both technical and painfully visible. Working out why it failed meant separating the actual technical root cause from the process gap that let it ship at all, and the fix that stuck was the one that closed the process gap, not just the code.

What happened and how I investigated

The change passed our automated tests and looked fine in manual quality testing, but broke for a subset of users because of an interaction between a caching layer and a redirect that only showed up under a specific, uncommon network condition. It surfaced when a prospective customer hit it during a live demo, which told me something important on its own: our alerting wasn't watching for this failure mode at all, so if the customer hadn't hit it live, it could have persisted undetected. Rather than just fixing the immediate bug, I traced two separate things: the technical root cause, the caching and redirect interaction, and the process gap, which was that our test matrix didn't cover that network condition and our monitoring had no signal that would have caught it in production either.

What I said and to whom, while it was still broken

As soon as I confirmed the cause, I told my manager and the account team handling that customer directly, with the specific technical explanation and an honest estimate of the fix timeline, rather than a vague "we're looking into it." That let the account team manage the customer conversation with real information instead of a placeholder.

What changed as a result

The immediate fix addressed the caching and redirect bug. The change that outlived the incident was adding the specific network condition to our test matrix and adding a monitoring alert for that class of redirect failure, so the next similar bug would be caught by our own systems instead of by a customer mid-demo. I also flagged that our sign-off process treated "tests pass" as equivalent to "ready to ship" with no explicit check for untested conditions, which is a narrower and more honest description of what our tests actually covered.

Trade-offs and pitfalls

The pitfall is stopping at the technical fix and treating the incident as resolved, when the more durable failure was the process gap that let something with an untested condition ship in the first place. A failure caught by monitoring and one caught by a customer can share the identical root cause, but they are different signals about how much your detection is actually covering.