Prompt and context
A B2B SaaS service records logins, permission changes, data exports, and administrative actions. Customers have different needs: small customers want to search the last 90 days, while large customers want seven years and evidence for auditors. The team worries about long-term storage cost, sensitive-data exposure, deletion requests, and a complex query experience.
Decide whether to offer tenant-level retention and define the smallest useful scope, pricing, defaults, immutability, and deletion flow. NIST SP 800-92 treats log management as a lifecycle covering generation, protection, retention, and review; the interview tests whether you can turn compliance pressure into an operable product boundary.
What the interviewer evaluates
Cover customer jobs and evidence, retention tiers and defaults, hot/cold cost, log integrity, access control, personal-data minimization, deletion versus legal hold, query latency, audit export, success metrics, and risk guardrails.
Clarifying questions to ask
- Which industries, regions, and contract terms require a specific retention period or immutable storage?
- Which events, time ranges, and fields must an auditor search, and must data export to a customer SIEM?
- What are seven-year event volume, query frequency, encryption, and data-residency requirements?
- If a customer can delete personal data, how should actor, target, and reason fields be minimized?
- What are current storage, indexing, permission, and cost baselines?
A 30-second answer
“Validate compliance risk and audit jobs first, then offer a few retention tiers rather than arbitrary days. Keep recent logs in a searchable hot tier and move long-term data into encrypted, immutable, lower-cost archives with asynchronous retrieval and signed exports. Tenant policies need permissions, approval, billing, and residency controls; deletion and legal hold are separate states. Use adoption, audit-task success, latency, cost, and privacy incidents as guardrails.”
Step-by-step deep dive
Step 1: Validate jobs and segment customers
Interview security owners, compliance owners, and working auditors about the last audit: event types, evidence format, and response time. Separate investigation, compliance retention, legal hold, and day-to-day troubleshooting instead of treating every request to “keep it longer” as one job.
Segment by industry, contractual duty, region, and seat size. Smaller customers can use a common default, while regulated customers get longer tiers and export controls. Retention duration has value only when evidence remains searchable and trustworthy.
Step 2: Offer bounded tiers and defaults
Start with a few tiers such as 90 days, one year, and seven years. Arbitrary days create cache, index, billing, and lifecycle variants. The default should cover common troubleshooting; upgrading should show expected capacity, cost, query latency, and irreversible effects.
Changing policy requires administrator permission, confirmation, and an audit event. Shortening retention must not immediately remove records under legal hold; put them in a pending-deletion state with an effective time.
Step 3: Build hot, warm, and cold storage
Keep recent logs in a filterable hot tier for time, actor, action, and resource queries. Move older data to encrypted object storage or archive with compression and lifecycle rules. Cold retrieval is asynchronous, so the product must show an expected wait rather than pretend that archive search is instant.
Model capacity using tenant event volume, field size, index ratio, replication, and retention days. Separate storage, indexing, restore, and export costs instead of looking only at object-storage price.
Step 4: Protect integrity, access, and privacy
Each event includes time, actor, action, target, result, request trace, and source. Minimize, redact, or separate sensitive fields. Use append-oriented write permissions, encrypted and version-protected archives, and tenant, role, and field authorization on queries.
Viewing sensitive events by an administrator should create a second audit record. An export package should contain scope, generation time, hash, and signature so a customer can verify that its contents were not replaced.
Step 5: Handle deletion and legal hold
Model application deletion, personal-data minimization, audit-evidence retention, and legal hold as separate states. When removing actor information, use a stable irreversible surrogate where appropriate, while preserving the event order, action, and outcome needed for the audit.
Legal hold needs an authorized owner, scope, reason, start and end, and release flow. A tenant cannot shorten held records. The UI should explain the conflict and responsible workflow so a customer does not assume that pressing delete completed every action.
Step 6: Validate query, export, and business value
Run usability tests on real audit jobs: locate a permission change, export a time window, verify a signature, and hand the package to an external auditor. Measure hot-tier p95, cold restore time, export success, result completeness, and permission false positives.
Compare high-tier adoption, net revenue retention, storage gross margin, and support-ticket reduction. If only a few customers adopt long retention, validate with controlled sales and usage billing before building every setting into self-service.
A strong sample answer
I would validate audit jobs and contractual duties first, then offer bounded retention tiers. Recent logs stay in a searchable hot tier; long-term logs move to encrypted, immutable, lower-cost archives with asynchronous retrieval. Tenant policy requires admin permission, billing, residency, and approval controls; deletion and legal hold are separate. I would expand only after measuring audit-task success, query p95, export integrity, unit storage cost, adoption, and privacy incidents.
Common mistakes
- Allowing arbitrary retention days → billing and indexing variants explode → start with bounded tiers.
- Promising long storage only → auditors still cannot find evidence → define search, restore, and export together.
- Keeping every field forever → privacy and deletion risk grows → minimize, redact, and separate fields.
- Treating tenant deletion as legal-hold deletion → evidence can be destroyed → separate states, permissions, and release.
- Looking only at storage price → indexing, restore, and support costs are missed → model the full lifecycle.
Follow-up questions and responses
Follow-up 1: Why not support arbitrary customer-defined days?
Arbitrary periods multiply cache, billing, testing, and lifecycle complexity. Validate a few common tiers first, then expand from adoption and contractual evidence.
Follow-up 2: How do seven-year logs remain verifiable?
Use encrypted, immutable archives with scope, hash, signature, version, and generation time, plus verifiable export packages and restore drills.
Follow-up 3: What if a customer demands immediate personal-data deletion?
Identify legal holds and compliance exceptions, then irreversibly substitute or separately delete actor data while retaining necessary event order and outcome evidence, recording the decision.
Follow-up 4: How do you decide whether to build this?
Measure target-customer willingness to pay, audit-task success, adoption, margin, support tickets, and privacy risk. Validate with controlled sales instead of letting one customer’s longest requirement dictate the whole roadmap.