Prompt and context
Enterprise customers want logins, permission changes, data exports, and administrator actions delivered to their SIEM. The product only offers a page and CSV export, so customers say it cannot support detection and compliance response. Decide whether to build audit-log streaming and define an MVP, event contract, delivery reliability, permissions, privacy, cost, and roadmap.
This differs from asking whether to show an admin audit log: the product problem is cross-system delivery, not single-tenant viewing. AWS CloudTrail Lake illustrates external event ingestion and long-lived query needs, while the OpenTelemetry Logs Data Model provides a structured cross-source vocabulary.
What the interviewer is testing
- Validating customer and renewal value instead of building from one request.
- Defining event semantics, tenant isolation, ordering, duplicates, and gaps.
- Choosing among webhooks, object storage, queues, and vendor connectors.
- Handling sensitive fields, residency, retention, replay, and cost.
- Driving roadmap decisions with metrics, pilots, pricing, and stop conditions.
Clarifying questions
- Are target customers regulated enterprises, platform customers, or every tenant? How many renewals or security reviews are blocked?
- Is the need second-level detection, hourly compliance archive, or replayable forensics?
- Which actions and fields are required? Are personal data, request bodies, IPs, admin identity, or custom fields included?
- Which SIEM inputs exist: HTTPS, S3, Syslog, Kafka, or a vendor connector? Who owns retries and receiver credentials?
- Do we already have an audit-event source of truth, event IDs, retention policy, and regional deployment?
30-second answer
Validate whether real-time delivery blocks purchase or renewal, then separate detection from archive and forensics. The MVP offers a stable event contract, tenant-scoped destinations, signed webhooks, and replayable object-storage export with explicit at-least-once semantics. Minimize and redact fields by default, support residency controls, and price by event volume. Pilot with high-value customers; expand connectors only after latency, loss, setup time, destination success, and renewal signals clear thresholds.
Deep-dive answer
1. Validate problem and customer value
Interview security operations, compliance, platform administrators, and procurement. Quantify work spent stitching CSVs, polling APIs, or abandoning integration. Rank renewal risk, competitive gaps, audit findings, and SOC tickets instead of treating one large customer as the whole market.
Separate three jobs: low-latency detection, complete retained compliance archive, and provable forensic context. One delivery channel may not optimize all three.
2. Define an event contract and versions
Each event includes event ID, tenant ID, occurrence and collection time, subject, action, object, result, source, region, and schema version. IDs are globally unique and stable so receivers can deduplicate. Promise ordering only within a tenant or partition, not globally across regions.
Do not send request bodies or complete personal data by default. Document field tiers, optional extensions, and compatibility rules. A breaking change gets a new version and overlap window. OpenTelemetry's resource, time, and attribute layers can inform context, but the product contract still defines business actions.
3. Choose delivery modes
Signed webhooks provide low-friction real-time ingestion; the service owns retries, exponential backoff, dead letters, and replay. Object-storage batches suit archive and high throughput, allowing customers to pull and verify manifests. Queues or vendor connectors suit mature security teams at higher integration and operational cost.
The MVP can offer both webhooks and daily object-storage export: detection is near real time, while the archive is a compensating and forensic source. State at-least-once delivery and require receiver deduplication by event ID; never promise exactly-once.
4. Design security, privacy, and permissions
Only a tenant security administrator can configure a destination. Use short-lived tokens, mTLS, or rotatable signing keys. A tenant receives only its own events; support regional pinning, field redaction, sensitive-event allowlists, and minimum retention.
Logs and replay interfaces never expose credentials or unredacted personal data. Tenant deletion, destination revocation, and key rotation have explicit delay and audit behavior; sensitive events may require a second confirmation.
5. Make delivery reliable and observable
Write events to an immutable internal queue before asynchronous delivery. Record attempts, status, retry causes, first send, last success, and dead-letter location. Circuit-break a destination that repeatedly fails so it cannot harm production; support replay by time range or event ID after recovery.
Track end-to-end p50/p95 latency, success, retries, dead letters, loss, duplicates, replay completion, destination setup success, and setup time. Sample-reconcile delivery with the audit source of truth.
6. Set cost, pricing, and support boundaries
Costs include storage, queues, bandwidth, encryption, connectors, and support. Tier pricing by event volume, retention, destination count, or premium connector, with quotas and explicit overage behavior. Unlimited replay and retention do not belong in the base plan.
Document freshness, at-least-once semantics, regional availability, pause behavior, and receiver responsibility. Provide a test destination, sample events, and health status to reduce manual support investigation.
7. Pilot, roadmap, and stop conditions
Phase one pilots three to five customers with active SIEM projects, delivering webhooks, object storage, event catalog, and health metrics. Phase two adds Kafka, Splunk, filtering, and self-serve replay. Phase three uses adoption to decide on cross-region aggregation and longer retention.
Set gates for setup time, event latency, loss, destination success, monthly active destinations, expansion revenue, and renewal impact. If customers download once, support cost is high, or integrity cannot be proved, stop connector expansion and improve the contract or archive path.
Model answer
I would validate whether real-time streaming truly blocks renewal or compliance, then separate detection, archive, and forensics. The MVP provides tenant-scoped signed webhooks and object-storage export. Events have stable ID, tenant, action, object, time, region, and version; delivery is explicitly at least once and receivers deduplicate by ID.
Security administrators configure destinations with rotatable credentials, minimal and regional fields, and redaction. An immutable internal queue supports backoff, dead letters, circuit breaking, and replay. Pilot high-value customers and measure latency, loss, duplicates, setup time, destination success, and renewal impact before adding connectors, pricing tiers, or longer retention.
Common mistakes
- Committing to a full real-time feed because one customer asked without validating purchase value.
- Treating an audit page, CSV export, and cross-system event delivery as the same problem.
- Promising exactly-once without event IDs, deduplication, or replay.
- Sending request bodies, personal data, and credentials by default.
- Building only a webhook without archive compensation, dead letters, health, or replay.
- Offering unlimited volume and retention without a cost model.
- Adding connectors without pilot gates or stop conditions.
Follow-up questions and answers
Why offer both a webhook and object-storage export in the MVP?
The webhook supports low-latency detection; object storage supports high-throughput archive and compensation. They share a contract but have different freshness guarantees.
Will at-least-once delivery disappoint customers?
Security receivers can deduplicate by stable event ID. Explicit semantics, duplicate metrics, and replay are more trustworthy than an unprovable exactly-once promise.
What if a customer demands complete request bodies?
Confirm forensic value and legal basis, then offer field tiers, redaction, and tenant controls. Sensitive fields are off by default with audit, retention, and residency limits.
What if the destination returns 500 continuously?
Back off into a dead-letter queue, alert the tenant, and circuit-break the destination. After recovery, replay by time range or event ID.
How do you prove events were not lost?
Use the immutable audit source as truth, sample-reconcile delivery records by tenant and time, expose loss, duplicate, and latency metrics, and retain versioned manifests.
When would you stop adding connectors?
When destination use is low, setup and support costs are high, integrity gates fail, or renewal value is absent. Improve the contract, reliability, and archive before expanding breadth.