What to Expect in the Wiz System Design Interview

Question

Design Gurus · Accepted Answer

Wiz's system design interview draws on one of the more distinctive platforms in enterprise software: an agentless cloud-security system that connects to customers' AWS, Azure, and GCP accounts via APIs, inventories everything (compute, storage, identities, network paths, secrets), and assembles it into the Security Graph, where the product's signature analysis happens: finding toxic combinations, chains of individually modest issues that compose into critical attack paths. Design prompts orbit that machinery: ingestion at billions-of-resources scale, graph storage and query, prioritization pipelines, and multi-tenancy where the tenants are security-sensitive enterprises and the data is the map of their weaknesses.

Post-acquisition context matters here too: Wiz's multicloud commitment inside Google Cloud makes provider-agnostic design (clean abstractions over three clouds' APIs) not just good engineering but company strategy.

The Question Territory

Design the cloud inventory and ingestion pipeline. Connect to a customer's cloud accounts (API-only, no agents), enumerate all resources and configurations across providers, keep the picture fresh against constant change, and do it within provider rate limits. Probes: full-scan versus event-driven incremental updates, rate-limit budgeting, and normalizing three providers' wildly different resource models.
Design the Security Graph. Store hundreds of millions of nodes (resources, identities, permissions, network paths) per large tenant, support the queries that find attack paths ("internet-exposed VM with a role that can read the crown-jewel bucket"), and keep query latency interactive for the console. The graph-modeling and traversal-at-scale conversation is the house specialty.
Design the risk prioritization engine. Turn millions of findings into a ranked queue humans can act on: toxic-combination detection (multi-hop graph patterns), severity scoring with customer context, deduplication, and the noise problem that defines the security-tooling industry.
Design multi-tenant isolation for a security platform. The stakes inversion: your customers' data is a map of their vulnerabilities. Tenant isolation, credential handling for customer cloud access (the platform holds keys to everything), and blast-radius thinking about the platform itself as a target.
Design scan scheduling and freshness. Millions of accounts, varied change velocities, provider rate limits, and the freshness-versus-cost curve: what must be near-real-time (new public exposure) versus daily (config drift in dev accounts).

What Interviewers Are Probing

API-constrained ingestion realism. The agentless model means living inside cloud providers' APIs: pagination, rate limits, eventual consistency, and permission scopes. Candidates who design cheerful unlimited-throughput crawlers reveal unfamiliarity; candidates who budget API calls like money fit the domain.
Graph thinking at scale. The toxic-combination idea is multi-hop graph query at hundreds-of-millions-of-nodes scale: precompute versus query-time traversal, incremental graph updates as resources change, and indexing for the hot patterns. You need graph-store literacy (property graphs, adjacency modeling, traversal costs), not a specific product's syntax.
The noise-to-signal obsession. Security tools die by alert fatigue; Wiz won partly by prioritization. Designs that treat ranking, deduplication, and context (is this bucket actually reachable? does it actually contain sensitive data?) as core architecture, not post-processing, match the product thesis.
Security-of-the-security-platform instincts. Handling customer cloud credentials, least-privilege access patterns, per-tenant encryption, and honest reasoning about the platform as a high-value target. Raising this unprompted is a strong domain signal.
Multicloud abstraction judgment. Where to normalize (a common resource model for analysis) versus preserve provider fidelity (the details attacks actually exploit): the tension is real and interviewers probe whether you feel it.

Walkthrough Sketch: The Ingestion Pipeline and Graph Refresh

Requirements first: a large tenant has, say, 50 cloud accounts across three providers with tens of millions of resources; the security picture must reflect critical changes (new public exposure, new admin grant) within minutes and everything else within hours; and provider API rate limits are hard constraints per account. Architect in two planes and say why: a snapshot plane (periodic full enumeration per account for completeness, because event streams miss things) and an event plane (provider change feeds: CloudTrail-style events, driving targeted re-scans for freshness), reconciled so the graph converges even when events are lost.

Ingestion workers are per-provider adapters normalizing into a common resource model, with per-account rate budgets enforced by token buckets and scan schedulers that spend the budget by risk: identity and network-exposure resources re-enumerate hourly, inert storage metadata daily. Everything lands in a staging store, then diffs against the current graph: only changes propagate, which keeps graph writes tractable. The graph itself: nodes for resources, identities, and network endpoints; edges for permissions, trust, and reachability; partitioned by tenant (hard isolation, per-tenant encryption keys) and updated incrementally with the diff stream. Toxic-combination detection runs as materialized pattern queries: the known dangerous patterns (public exposure + privilege path + sensitive data) precompute incrementally as edges change, with alert-on-transition semantics so customers hear when a path opens, not on every scan. Failure and trust handling close it: a provider API outage degrades freshness visibly (per-account staleness surfaced in the console, never silently stale), credential handling uses short-lived scoped tokens per scan with an audited broker, and the reconciliation between snapshot and event planes is itself monitored, because the worst failure in this product is confident incompleteness: telling a customer they are safe on a partial picture.

How to Prepare

Foundations and depth: Grokking the System Design Interview for the method, Grokking System Design Fundamentals for the blocks, and Advanced System Design Interview, Volume II for the partitioning, consistency, and incremental-computation depth these rounds reach.
Rehearse the two house designs: the API-constrained ingestion pipeline and the tenant-partitioned security graph with incremental pattern detection. Their vocabulary covers most Wiz prompts.
Refresh cloud-provider mechanics: IAM models, resource enumeration APIs, event feeds, and rate-limit realities across AWS, Azure, and GCP: the domain texture that separates informed designs from generic ones.
Practice the security-stakes pass: for every design, one explicit paragraph on credentials, isolation, and the platform-as-target: at Wiz it is graded the way DX is graded at Vercel.

For the full loop, see What is the Wiz interview process like?, and prepare the culture dimension with Top Wiz behavioral interview questions and your answer to "Why Wiz?"