Prompt and context
A multi-tenant SaaS has many long-inactive customers. Infrastructure cost and data obligations keep growing. Product wants to reclaim tenant resources, sales fears deleting a customer by mistake, and legal requires contract, audit, and deletion-request compliance. How would you decide whether to automate offboarding and design notification, export, retention, deletion, recovery, and audit flows?
The AWS SaaS Lens recommends a per-tenant resource inventory, an offboarding runbook, and an approval workflow; before decommissioning, a recoverable or compliance copy may be needed. NIST SP 800-88 Rev. 2 defines sanitization as making target data infeasible to access at a given level of effort. This article synthesizes public material and does not claim to be a company-specific interview question.
What the interviewer is testing
The interviewer wants you to turn “automation” into reversible state transitions rather than a delete button. A strong answer distinguishes suspension, archival, logical deletion, and physical sanitization, and covers customer notice, export, legal hold, contract terms, resource recovery, recovery windows, and audit evidence. A weak answer talks only about cloud savings.
Questions to clarify first
- Is inactivity defined by login, business events, contract status, or payment status?
- Does the tenant have retention periods, deletion requests, regulatory duties, or a legal hold?
- What export formats, recovery window, and post-recovery service level does the customer need?
- Which shared resources, backups, logs, indexes, and third-party integrations are affected?
A 30-second answer
“I would not delete by login age alone. I would define states for notice, write restriction, archive, pending deletion, and sanitized, with notice, approval, export, and idempotent records at each transition. Contracts, legal holds, and deletion requests define the retention boundary; the recovery window determines cold-storage cost. I would rehearse in non-production and roll out by cohort, measuring reclaimable cost, false-offboarding rate, recovery success, and complaints. Any ambiguous state pauses automated sanitization.”
Step-by-step solution
Start with an asset inventory: database partitions, object storage, indexes, queues, backups, keys, domains, and external integrations. Each asset records tenant ownership, retention policy, deletion dependency, and verification method. Without the inventory, you cannot prove deletion or estimate the recovery benefit.
Use a state machine instead of a timer-driven delete. Notice sends communication; suspension blocks new writes but keeps reads; archive moves data to lower-cost storage; pending deletion waits for approval and final notice; sanitization deletes in dependency order and creates evidence. Transitions must be idempotent, retryable, and manually pausable.
Notice and export are product value. Notify tenant administrators and billing contacts multiple times with dates, impact, export links, and an appeal path. An export package includes checksums, scope, expiry, and encryption details. Large tenants use a resumable asynchronous job so one download cannot block the offboarding state machine.
Retention follows contract and risk. A legal hold, unsettled dispute, regulatory retention, or security investigation may block sanitization. Backups, logs, and replicas need independent expiry rules so deleting primary data does not create indefinite retention. When data must become unrecoverable, use a method appropriate to the media and risk and record verification; deleting database rows alone is not media sanitization.
Recovery needs an explicit boundary. Archive and suspension are usually reversible; physical sanitization is not. Show the current state, expected completion time, and recovery cost. Recovery drills check tenant identity, permissions, indexes, keys, webhooks, and billing status, not just one table. Isolate the tenant during recovery so old credentials or expired configuration cannot reactivate.
Use approvals and guardrails. High-value, recently active, held, or ambiguously classified tenants enter a human queue; others may progress automatically. Set batch caps, a circuit breaker, and a global pause switch. Rehearse in test, then roll out by tenant cohort. Audit records capture the trigger, notices, approver, per-asset result, and abnormal retries.
Example of a strong answer
I would first test whether automation is worthwhile. Benefits are measurable resource recovery and fewer manual errors; risks are false offboarding, contractual retention, export failure, and failed recovery. Product states would be notice, write restriction, archive, pending deletion, and sanitized, advanced from the tenant asset inventory. Contracts, legal holds, deletion requests, and investigations define retention; completed export, notice acknowledgement, and approval are prerequisites for sanitization.
Automation uses idempotent jobs, batch caps, a circuit breaker, and human pause. I would rehearse outside production and roll out by cohort. Metrics include reclaimed cost, false-offboarding rate, recovery success, export failure, completeness of sanitization evidence, and complaints. Archives can recover; physical sanitization cannot. Recovery drills cover permissions, indexes, keys, webhooks, and billing. Public SLA states timing, export format, recovery window, and the irreversible point.
Common mistakes
- Symptom → Delete solely by login age; why it fails → Contract, payment, integration, and legal-hold signals are ignored; fix → Use multiple signals and human guardrails.
- Symptom → Delete only primary database rows; why it fails → Backups, indexes, logs, and object replicas may remain; fix → Maintain an asset inventory and per-asset evidence.
- Symptom → Notify after sanitization; why it fails → Customers lose export and appeal options; fix → Make notice, export, and approval prerequisites.
- Symptom → Promise every deletion is recoverable; why it fails → Archive and physical sanitization have different reversibility; fix → State recovery window, cost, and irreversible point.
- Symptom → Launch globally in one batch; why it fails → A small mistake becomes a cross-tenant incident; fix → Rehearse, cohort, cap batches, and provide a kill switch.
Follow-up questions and answers
How do you define an inactive tenant?
Use combined signals: contract and payment status, administrator confirmation, key business events, recent login, and support tickets. Login is only one signal. Conflicts or missing data go to human review rather than automatic sanitization.
What if a customer requests immediate deletion but the contract requires retention?
Legal should identify fields and copies that must remain, for how long, and who may access them. Split the request into immediately deletable, restricted-retention, and expiry-deletable scopes. Explain the basis, timing, and appeal path, and record the decision.
How do you prove a tenant was sanitized?
Use the asset inventory as the baseline and record each resource operation, version, time, verification, and retry. Confirm backups and third-party copies independently. State scope and limitations instead of presenting one database query as end-to-end proof.
How do you measure whether automation worked?
Track recovered resource value, processing time, false-offboarding rate, recovery success, export failures, evidence completeness, human intervention, and complaints. If cost falls while false offboarding or recovery failure rises, pause expansion and return work to the human queue.