Section 1: Every Machine in Azure Is Talking - Problem Understanding & Clarifications

Executive Summary: The first ten minutes of a Staff/Principal interview on a planet-sized prompt: the platform that collects security telemetry from all of Azure. We break the sentence into what, who, why and how, then ask clarifying questions in six areas, each removing or fixing a piece of the design: strict tenant isolation with one policy-gated exception, detection as a consumer, logs over metrics, seconds rather than milliseconds, retention of 30 days, 1 year and 7 years, and no loss after an acknowledgement. We finish with written assumptions, an out-of-scope list with reasons, and what the interviewer was scoring.

The interviewer reads one sentence and puts the marker down:

"Design the platform that collects security telemetry from all of Azure — every VM, container host and platform service, for internal Microsoft security teams and for tens of thousands of customer tenants — and stores it so it can be searched in seconds for recent data and kept for years for compliance."

Nothing about this prompt is small, and that's the trap: the scale tempts you to start drawing Kafka clusters right away. But the real problem at this altitude is deciding which of the many systems hidden in that sentence you are building. Your first ten minutes make that decision, out loud.

Key Insight: With a planet-scale prompt, clarification is how you cut the work down. Every answer should delete a subsystem, fix a number, or draw a boundary. Otherwise, don't ask.

Decomposing the Sentence

Before any question, map the territory aloud in four strokes:

• What it does. Four verbs: collect, ingest, store, serve. Nothing says "detect" or "alert", and you'll confirm that, because it decides whether you're designing one system or two.
• Who uses it. Three groups, and they want different things. Internal Microsoft security teams: threat intelligence analysts, and the people building Defender- and Sentinel-like products on top. External enterprise SOCs: analysts in customer tenants hunting through their own data. Platform producers: the agents on VMs and container hosts, plus Azure services that emit sign-in, control-plane and diagnostic records. The first two groups read; the third writes, and a design that ignores the writers fails at ingestion.
• Why it exists. You can't detect, investigate or prove compliance with data you didn't keep. Every downstream security product depends on it, so its failures become blind spots, which is exactly what an attacker wants.
• How it's used. Producers push batches in. Analysts and scheduled jobs pull query results out. A stream hand-off feeds downstream consumers such as detection.