Prompt and scope
Enterprise prospects ask for EU, Canadian, and Australian residency. The product currently runs a shared global control plane, stores tenant data in one primary region, sends support diagnostics to a global analytics pipeline, and replicates backups across two regions. Sales says three deals worth $1.2 million in annual contract value are blocked. Engineering estimates a first region-pinning version at two quarters with ongoing operations.
Decide whether to invest, what promise to make, which data classes are in scope, and how to measure the decision. The prompt tests product judgment under regulatory, architectural, and sales constraints; it does not assume that a region selector alone creates legal compliance.
What the interviewer evaluates
- Whether you identify the buyer and the exact job: procurement approval, latency, contractual storage, processing restrictions, or sovereignty.
- Whether you separate data at rest, in-use processing, transit, backups, logs, support access, subprocessors, and disaster recovery.
- Whether you quantify opportunity cost and define a staged experiment instead of accepting an unbounded “global compliance” project.
InterviewStack includes a senior product prompt about a phased multi-region launch constrained by data residency and privacy laws. Cloud providers document narrower promises: Google defines residency primarily as where data is stored at rest, while Microsoft notes that replication and processing can follow separate geography rules. Those sources support precise product boundaries, not a universal compliance claim.
Clarifications before answering
- Which contract language is required? “Stored in Canada” is a different commitment from “processed only in Canada” or “never accessed from outside Canada.”
- Which data is regulated? Include customer content, metadata, backups, telemetry, logs, support attachments, derived indexes, and model prompts rather than only the main tables.
- How many customers need each region? Separate signed demand, procurement blockers, and speculative requests; obtain deal stage, ACV, deadline, and renewal risk.
- What availability target survives a regional outage? A strict residency promise can conflict with cross-region failover, so the customer must choose the allowed recovery boundary.
A 30-second answer
“I would not ship a generic region dropdown. I would validate the three blocked deals and convert each request into a contract matrix covering storage, processing, backups, support, subprocessors, and failover. If signed ACV and expansion justify it, I would pilot one region with a narrow data class and an auditable tenant placement record. The product promise would state what remains regional and what is excluded. I would measure procurement progression, implementation cost, incident rate, latency, and gross margin before expanding to more regions. If a region fails, the service either stays within an approved recovery boundary or goes read-only according to the contract; it must not silently copy data elsewhere.”
Step-by-step deep answer
Step 1: Establish the customer problem.
Interview the security, legal, procurement, and technical buyer separately. Ask which clause blocks signature, whether an approved subprocessor list is enough, and whether the requirement applies to personal data, all tenant content, or only a regulated workload. Rank requests by signed pipeline, deadline, expansion value, and repeatability across segments.
Step 2: Define a residency contract.
Create a data-flow inventory with classes, stores, processors, regions, retention, and access paths. A useful matrix distinguishes primary storage, replicas, backups, in-memory processing, logs, telemetry, support tooling, subprocessors, and disaster recovery. Google’s definition is centered on storage at rest; Microsoft documents that redundancy can stay within a geography while access locations remain a separate question. The UI and contract must expose these boundaries.
Step 3: Choose the smallest viable architecture.
Start with tenant-to-region placement at signup and an immutable placement policy. Route writes and reads to an approved regional data plane, keep the control plane free of tenant content, and block unapproved analytics sinks. Add regional key management, support-access approvals, backup policy, and an export/delete path. Do not promise region pinning until every asynchronous job, cache, index, log, and attachment has an owner and a test.
Step 4: Quantify the investment.
Model build cost, on-call load, duplicate platform work, egress, regional minimum spend, support training, and reduced failover flexibility. Compare that with weighted pipeline value and retention impact. A two-quarter build for $1.2 million of blocked ACV may be attractive, but only after discounting probability of close, gross margin, implementation delay, and future region demand.
Step 5: Pilot and measure.
Choose one region and a small set of design partners. Gate migration on a data inventory, contract sign-off, backup restore test, regional outage exercise, and independent evidence that no scoped class enters a forbidden sink. Track time to procurement approval, pilot conversion, latency, support minutes, cost per tenant, failed jobs, residency violations, and recovery time.
Step 6: Handle outages and exceptions.
Define the approved recovery set before launch. If cross-region recovery is forbidden, state the resulting availability trade-off and offer read-only or queued writes. If a regulated backup must remain regional, do not use a global backup service as an invisible exception. Every break-glass access, temporary transfer, and policy change needs an expiry, approval, audit record, and customer-visible evidence.
High-quality sample answer
“I would treat residency as a contractable capability, not a marketing label. First I would validate the three deals: clause, data classes, deadline, ACV, and whether the same requirement appears in a repeatable segment. Then I would map content, metadata, backups, logs, telemetry, support access, subprocessors, and failover. Google’s documentation frames residency around storage at rest, while Microsoft separates geography, replication, and access; our promise must state which of those we support.
If the weighted pipeline supports the investment, I would pilot one region. Tenant placement is immutable, the regional data plane owns scoped content, asynchronous jobs carry a region policy, and analytics receive only approved aggregates. Backups, keys, support tooling, and restore drills are part of the launch gate. I would measure procurement conversion, gross margin, regional cost, p95 latency, operational incidents, and evidence of zero unauthorized transfers. During an outage, we follow the pre-agreed recovery boundary or go read-only; we never silently fail over outside the contract.”
Common mistakes
- Equating a regional database with residency → logs, backups, support tools, and analytics may still move data → inventory every data flow and assign an owner.
- Promising “compliance” without a legal scope → storage, processing, access, and jurisdiction are different claims → write an explicit contract matrix.
- Building three regions from unqualified requests → sales interest is not committed demand → rank signed pipeline, deadlines, and repeatability.
- Keeping global failover implicit → an outage can violate the promise or the availability target → choose the approved recovery set before launch.
- Measuring only closed revenue → residency adds ongoing cost and operational risk → track margin, incidents, evidence quality, and support load.
Follow-ups and responses
Follow-up 1: A prospect requires Canadian storage but allows support access from the United States. What changes?
Separate storage from access in the contract and data-flow matrix. Keep primary data, replicas, and backups in the approved Canadian boundary, while support tooling receives least-privilege, time-limited access from the United States only when the customer approves it. Log the actor, purpose, fields, duration, and expiry; do not widen the promise to “Canadian processing.”
Follow-up 2: The Canadian region is unavailable and the customer forbids cross-border replication. Do you fail over?
No silent failover. Follow the agreed availability behavior: read-only from surviving regional caches, queued writes with an explicit durability warning, or an outage. Offer cross-border disaster recovery as a separately priced and consented option. The incident review should compare the outage cost with the customer’s stated residency constraint rather than quietly violating it.
Follow-up 3: How do you prove that telemetry does not leak tenant content?
Define an allowlisted event schema, reject free-form payloads, classify fields at SDK and collector boundaries, and sample only approved identifiers or aggregates. Run synthetic canaries containing unique markers through jobs, logs, traces, analytics, and support workflows, then query every sink for the markers. Keep the test results, policy version, and exceptions auditable.