Prompt and scope
A company is preparing for post-quantum migration but cannot tell which systems use RSA, elliptic curves, or shared keys. Design a cryptographic inventory service covering collection, deduplication, risk scoring, access control, change detection, and migration handoff.
This is an asset-governance design question, not a request to predict when quantum computers arrive. RFC 9958 connects inventories, key-establishment versus signature use, cryptographic agility, and migration evidence; NIST has finalized ML-KEM, ML-DSA, and SLH-DSA standards.
What the interviewer evaluates
- Distinguishing algorithms, keys, certificates, protocol suites, and data lifetimes.
- Connecting code scans, runtime telemetry, certificate data, and HSM APIs into traceable facts.
- Handling duplicate findings, stale records, unknown algorithms, and opaque vendors.
- Designing tenant isolation, least privilege, versioned evidence, and audit queries.
- Linking risk scores to migration batches, stop lines, and rollback instead of producing a dashboard only.
Clarifying questions
- Which environments are in scope: source, containers, mobile clients, firmware, cloud KMS, HSMs, and SaaS vendors?
- Is the identity a key, certificate, call site, service, or data flow? Is cross-system key reuse allowed?
- How long must history be retained, and who may see algorithm names or sensitive business labels?
- Is scoring for compliance evidence, engineering planning, or automatic deployment blocking?
- When collection fails, may the system estimate, or must it mark unknown and prevent a completed claim?
End-to-end design
Collectors write static-scan results, certificate parses, KMS/HSM audit events, service configuration, and runtime handshake summaries to an immutable event stream. A normalization layer maps algorithm, purpose, key identifier, caller, confidentiality lifetime, source, time, and confidence into a versioned schema. Entity resolution uses tenant_id + asset_namespace + provider_id + local_id as a candidate key and deduplicates with certificate fingerprints, key ARNs, deployment IDs, and time windows. Records that cannot be proven identical stay linked rather than being merged.
The query API returns metadata and evidence links, never private keys or complete ciphertexts. A policy layer scores assets by data lifetime, algorithm status, exposure, un-updatable client share, and evidence freshness. Scores store the input snapshot, rule version, and override reason. A migration orchestrator consumes high-risk assets to create batches, owners, compatibility matrices, and acceptance metrics; it must not replace production keys directly.
Consistency and change detection
Because the stream is at-least-once, each finding carries source_event_id and collector version; consumers use idempotent writes. Asset state is folded from events, and deletion is a timed revocation event so a missing scan does not look like disappearance. Scheduled scans and runtime heartbeats update last_seen; records outside the freshness window become unknown.
Compute separate content digests for code, certificates, and configuration. A digest change creates a new version instead of overwriting history. Rule upgrades recompute scores while retaining old scores, allowing an audit of why an asset was approved then. Conflicts show fields, source precedence, and a confirmation task; the system must not silently pick a source.
Access, privacy, and reliability
Enforce row-level authorization by tenant, domain, and asset labels. Security can see algorithms and exposure; application teams see only their migration tasks. Key material, tokens, and raw traffic never enter the inventory; runtime collection keeps handshake metadata and redacted identifiers. Every read and manual edit is audited.
Offline collectors buffer locally and replay. Quotas and backpressure protect the event stream. Queries expose an as-of time and evidence freshness so stale inventories are not presented as live truth. Multi-region deployments use partitioned writes and a global read index; replication failures report coverage gaps instead of claiming full state.
Trade-offs and boundaries
Static scans cover broadly but can miss dynamic negotiation; runtime telemetry is closer to actual use but constrained by traffic and privacy. Store both with distinct confidence. A central graph simplifies dependency queries but increases blast radius; domain partitions simplify authorization, with cross-domain read-only links.
Blocking new algorithms automatically reduces new debt but can break unknown vendors. Start with approval gates for high-risk rules, then decide on enforcement using false-positive rate, unknown-asset share, and rollback success. The inventory owns facts and prioritization; library upgrades, certificate issuance, and business migration remain separate pipelines.
Failure drills and scoring rubric
If an HSM does not expose key purpose, record “purpose unknown” and create an evidence task; never infer it from a service name. If a certificate appears in multiple tenants, retain the sharing relationship and trigger isolation review. If a collector upgrade causes a sudden asset spike, compare raw events and rule versions before accepting a new baseline.
A strong answer includes multiple source types, immutable evidence, idempotency and expiry semantics, least privilege, explainable scoring, and migration handoff. Extra credit goes to explicit unknown states, retention, conflict handling, rollback boundaries, and inventory-completeness metrics. A database and dashboard alone are insufficient.
Follow-up questions and reference answers
Why not infer the algorithm from a service name?
A service can call multiple libraries, protocols, or vendors; its name does not prove key purpose or negotiated behavior. Keep source evidence and mark inference as low confidence.
How do you define inventory completeness?
Use environment coverage, source freshness, unknown-asset share, duplicate rate, event latency, and sampled human-verification accuracy. Asset count alone is not proof of completeness.
How does migration consume the inventory?
The orchestrator batches assets by risk and updatability, reads compatibility and performance budgets, and runs canaries, observation, and rollback. The inventory supplies facts and evidence; it does not change production crypto settings.