Prompt and context
A SaaS product lets support agents, analysts, and administrators view customer records. Security wants support to see partial contact data, analysts to see irreversible masks, and only a few compliant roles to see full values. The current product authorizes an entire table, so customers bypass the page restriction through exports.
Decide whether to offer field-level dynamic masking and define the smallest useful policy, role, audit, and export experience. BigQuery and Snowflake both document query-time, column-level masking policies; the interview tests whether you can turn that capability into clear customer value and risk boundaries.
What the interviewer evaluates
Cover customer jobs and threat model, sensitive-field classification, role and condition policies, reversible versus irreversible transforms, query and cache performance, export/API consistency, policy misconfiguration, audit, and commercial validation.
Clarifying questions to ask
- Which fields and roles require masking, and are region, tenant, or purpose constraints involved?
- Do customers need partial display, hash matching, format preservation, or complete hiding?
- Which UI, API, export, search-index, and cache paths must honor the policy?
- On a masking failure, should the default be deny, null, or aborting the query?
- Is there an existing classification taxonomy, permission directory, and audit-event baseline?
A 30-second answer
“Validate high-risk fields and concrete jobs first, then offer a small set of composable role and purpose policies. Default to minimum disclosure and enforce at query time; exports and APIs reuse the same engine. Reversible reveal needs extra approval and audit, while irreversible masks serve analysis. Measure exposure, denial, query p95, export consistency, and paid adoption.”
Step-by-step deep dive
Step 1: Identify jobs, fields, and risk
Interview security, support, analytics, and compliance roles about viewing, searching, matching, exporting, and correcting data. Classify fields as public, internal, personal, or highly sensitive instead of using one global sensitive switch.
Bind a policy to subject, resource, purpose, and environment. Region, tenant, device trust, and ticket state may affect the decision, but the first version should support a small set of explainable conditions.
Step 2: Design transforms and defaults
Offer bounded transforms such as full hide, partial display, hashing, format-preserving masking, and a controlled custom function. Declare reversibility, whether ordering or matching is preserved, and maximum input length.
Default to minimum disclosure. If a policy is missing or evaluation fails, deny plaintext. Reversible values require short-lived authorization, confirmation, and a reason; irreversible masks can support aggregation and deduplication but are not encryption.
Step 3: Unify UI, API, export, and cache
Make masking a shared policy decision, with the UI only rendering its result. API, bulk export, search indexes, asynchronous jobs, and caches must carry subject, tenant, policy version, and purpose context; hiding a page field must not expose a download endpoint.
Never reuse a plaintext cache entry for a lower-privilege subject. Policy updates invalidate affected caches and record the impact of old and new versions.
Step 4: Control performance and failure
Compile common policies into cacheable decision plans instead of parsing them for every row. Use chunking, rate limits, and asynchronous jobs for large exports. Measure policy evaluation, underlying query, and transform-function latency separately.
When the policy service is unavailable, a short-lived snapshot may serve low-risk non-sensitive fields, while highly sensitive fields deny plaintext. A timed-out transform must not silently return the original value; provide a recoverable error and support path.
Step 5: Close the audit and governance loop
Record policy version, subject, field label, purpose, decision, transform type, and export scope without writing plaintext into the audit log. Highly sensitive reveals trigger separate alerts, approval, and review.
Before release, run conflict checks, sample replays, and two-person approval. Show “who can see what under which conditions” so customers do not mistake a permission decision for lost data.
Step 6: Validate value and guardrails
Test real customer jobs: support handling a ticket, analysts matching duplicates, and auditors exporting evidence. Measure plaintext exposure, legitimate-request denial, query p95, export consistency, and stale-cache exposure after policy changes.
Compare adoption in regulated industries, expansion revenue, support-ticket reduction, and security events. Pilot with controlled sales before self-service policy editing; one customer’s complex conditions should not burden every tenant.
A strong sample answer
I would validate high-risk fields and jobs, then offer limited role, purpose, and environment conditions. Default to minimum disclosure and share one policy engine across UI, API, exports, search, and caches; reversible plaintext needs short-lived approval and audit, while irreversible masks support analysis. Version and explain policies, deny sensitive plaintext when the service fails, and expand only after measuring exposure, denial, query p95, export consistency, and paid adoption.
Common mistakes
- Hiding only page fields → APIs or exports still leak → enforce one policy on every output path.
- Calling masking encryption → customers misunderstand reversibility → state transform and key boundaries explicitly.
- Returning plaintext when evaluation fails → an outage becomes a leak → deny sensitive plaintext by default.
- Caching without policy version → a low-privilege user receives old plaintext → isolate by subject, version, and purpose.
- Supporting arbitrary conditions → explanations, testing, and billing become impossible → start with limited composable conditions.
Follow-up questions and responses
Follow-up 1: When do you choose partial display versus hashing?
Partial display supports human recognition and callbacks; hashing supports matching and deduplication. Explain collision, inference, and format-leak risks, and never treat either as access control.
Follow-up 2: How can support temporarily view a full value?
Require a ticket or business reason, short-lived authorization, confirmation, and complete audit. Revoke automatically and restrict bulk export and copying.
Follow-up 3: Will policy evaluation slow reports?
Cache compiled plans, evaluate subject and purpose per query batch, and make large jobs asynchronous. Monitor independent p95 for policy, query, and transform functions.
Follow-up 4: How do you prove there is no bypass path?
Enumerate UI, API, export, search, cache, and asynchronous jobs; run a permission matrix and cross-role replay, checking policy version, result shape, and audit record on every path.