Prompt and context
Your B2B SaaS currently uses platform-managed encryption at rest. Three large customers ask for their own KMS keys: one will sign an annual contract, while the other two list it only as a security-questionnaire requirement. Would you offer customer-managed encryption keys in the next two quarters? Explain customer value, product boundaries, operating responsibility, failure impact, pricing, and validation.
This is a product judgment question for B2B SaaS, platform, security, and enterprise-product roles. It does not ask you to build a complete key-management service. It asks when a high-responsibility capability deserves product investment. Assume tenant data is already isolated and the platform still owns the application, backups, and availability. Customer-managed keys change the authorization boundary for decrypting data at rest; they do not automatically provide end-to-end encryption, field-level authorization, or a promise that the customer can never receive plaintext.
What the interviewer is testing
A strong answer separates three claims: whether the customer truly needs control over decryption, whether sales is treating “a key option” as a purchasing gate, and whether the team can recover service when a customer key fails. AWS and Google Cloud both describe customer-managed keys as an option that gives customers control over key policy, audit, or disablement, not as a universal requirement for every resource.
The interviewer also wants to see whether you can turn a request into buying evidence. A checkbox in a security questionnaire proves that a requirement exists; it does not prove that a customer will enable the feature, pay for it, or operate the key safely. A public Google customer-security role also emphasizes identifying technical blockers, supporting customer adoption, and prioritizing solutions with product teams. The product answer therefore has to connect the blocker to an adoption path.
Questions to clarify first
- What does the customer need to control? If the need is key-use audit or the ability to block platform decryption at contract exit, customer-managed keys have clear value. If the need is simply “data must be encrypted,” platform-managed keys may already meet it.
- Which data must be covered? List the primary database, object storage, search indexes, backups, logs, caches, and exports. Covering the primary store while exports still use platform keys creates a false security promise.
- Who owns availability? When the customer disables, deletes, or misconfigures a key policy, does the platform reject reads and writes, provide controlled recovery, or keep decrypted cache entries briefly? The answer defines the product contract and support burden.
- What is the buying signal? Ask for contract language, target launch date, existing KMS ownership, willingness to run a configuration exercise, required data domains, and the person responsible for customer-side key operations.
- What is success in two quarters? It could be signed revenue, activation, an audit pass, fewer security blockers, or margin. Without a priority, you cannot decide whether to consume platform capacity.
A 30-second answer framework
“I would not commit to a full rollout because three questionnaires mention it. I would first establish whether customers need auditability, decryption revocation, or a regulatory boundary, then map the required storage and backup coverage. If one customer has a contract, a date, and KMS capability, I would run a paid pilot over a bounded data domain: the customer supplies the key policy, the platform uses envelope encryption and records each authorization, and an unavailable key blocks new decryption instead of silently falling back to a platform key. In two quarters I would use activation, configuration success, key-failure recovery time, support load, and renewal blockers to decide whether to expand. For questionnaire-only customers, I would start with architecture evidence and an operating-responsibility matrix rather than building the entire service.”
Step-by-step deep answer
Define the customer value
Customer-managed keys usually provide control: the customer can inspect key-use audit, change authorization policy, or block platform decryption for a defined event. They do not replace tenant isolation, encryption in transit, least privilege, or backup governance. Product language must state the boundary between “the customer controls key authorization” and “the customer exclusively controls plaintext.”
Choose the smallest useful scope
Start with the resources supported by the strongest evidence, such as the primary data store and object storage. Keep a per-tenant key identifier, version, region, state, and last successful authorization. Encrypt data with a random data-encryption key, then wrap that key with the customer key. Search indexes, backups, exports, and temporary files must each be marked covered or uncovered; one “encrypted” label is not a coverage model.
After authorization is configured, the platform unwraps data keys on read and records tenant, resource, key version, result, and reason. A cache may hold decrypted results briefly, but its lifetime and purge behavior must be explicit. Otherwise, an old cache can expose data after the customer revokes the key.
Make failure part of the contract
When a customer key is disabled, a policy denies access, a region is unreachable, or rotation fails, the platform should distinguish “temporarily unavailable” from “permanently denied.” The write path must not accept data it cannot encrypt; the read path must not silently switch to a platform key. Expose a queryable state, bounded retries, and customer instructions, and replay affected work only after the key is restored.
Use adoption evidence to expand
Before the pilot, define completion: configure a key in an isolated environment, rotate it, intentionally revoke it, restore it, and confirm that the database, objects, backups, and exports match the agreed coverage. Track activation, time to first success, recovery time, policy errors, support load, performance impact, and whether renewal blockers fall—not just signed contracts.
If a customer has no KMS owner, pilot cost may exceed the sales value. Offer a coverage matrix, audit evidence, and a customer-responsibility checklist first. Invest in multi-region, backup, and more complex external-key management only when several customers have clear regulation, budget, and launch windows.
High-quality sample answer
“I would treat this as an enterprise capability with an operating obligation, not a settings toggle. I would interview the three customers to separate a need for key-use audit, decryption control at contract exit, and a request to prove that we encrypt data at rest. I would run a paid pilot in two quarters only for the customer that has a contract value, a launch date, and a KMS team that can operate the key.
The pilot would cover the primary database and object storage first, while listing backups, search, exports, and temporary files in a coverage matrix. Random data keys would encrypt the data and customer keys would wrap those data keys. Every unwrap would record tenant, resource, version, and result. If the customer disables the key, new writes and decryptions would enter an explicit unavailable state; the service would not switch to a platform key. Work would remain retryable and replay after authorization is restored.
Success would mean that the customer can configure, rotate, revoke, and restore independently, that the platform can explain failures within the agreed time, and that no tenant or backup domain is silently omitted. I would track activation, time to first success, key-failure recovery, support load, and renewal blockers. If questionnaire-only customers will not run the exercise, I would sell audit evidence and a responsibility boundary first, then expand coverage when real adoption evidence appears.”
Common mistakes
- Mistake: Commit to a full build because three customers mentioned it. → Why it fails: It treats questionnaire demand as proof of payment and activation. → Fix: Filter pilot customers using contract, launch date, and a configuration exercise.
- Mistake: Say only that “data is encrypted with the customer key.” → Why it fails: It hides the coverage boundary for backups, exports, indexes, and caches. → Fix: Create a resource-by-resource coverage matrix and put exclusions in the contract.
- Mistake: Fall back to a platform key when the customer key fails. → Why it fails: It breaks revocation semantics and audit trust. → Fix: Define an unavailable state, recovery path, and replay boundary.
- Mistake: Treat rotation as a one-click migration. → Why it fails: It ignores old versions, concurrent writes, and rollback. → Fix: Version keys, allow controlled reads of old and new versions, and disable the old version only after verification.
- Mistake: Use “compliance” as the only product metric. → Why it fails: It cannot show that the capability reduces a purchasing blocker or is used continuously. → Fix: Track activation, recovery, support cost, and renewal outcomes together.
Follow-ups and responses
What if a customer requires every database, backup, and log to be covered on day one?
Split the request into what law requires, what procurement must see, and what the customer prefers. If the contract truly requires full coverage, make that scope a launch gate; do not call a primary-database pilot complete. Otherwise, deliver the database, objects, and backups first, and assign an owner and date to logs and temporary data. State the current exposure and compensating control for each exclusion.
What if the customer disables the key but the business demands continued reads?
First determine whether the disablement is an incident or an intentional revocation. Do not bypass the customer’s control. Return an explicit unavailable state, retain task metadata without plaintext, and notify the customer to restore authorization. If the contract permits emergency recovery, it needs pre-approved controls, two-person approval, a time limit, and a complete audit; do not invent a backdoor during an incident.
What if the customer owns the key but the platform cannot guarantee access in every region?
Put regional availability in the contract. Either require a customer key in each data region or constrain data residency; do not promise multi-region availability with a single-region key. Inject regional isolation and KMS throttling in the pilot, then measure recovery time, failed reads and writes, and retry pressure.
What if sales wants it free while engineering estimates two quarters?
Separate one-time build cost from ongoing operations: key integration, migration, audit, rotation support, failure exercises, and customer success all need long-term owners. Offer a bounded design partnership or paid pilot, but do not make a high-responsibility capability permanent free customization. If sales cannot provide a contract or adoption commitment, validate demand with documentation and audit evidence first.