Design a Confidential Computing Solution — System Design Interview Practice

Interview prompt

Design a confidential-computing platform that protects sensitive data while it is processed, attests the workload and code identity, and releases keys only to an approved trusted execution environment.

• Define workload images, measurements, attestation claims, tenant keys, and encrypted input/output as the trust boundary.
• Make key release conditional on hardware attestation, policy version, identity, region, and approved code measurement.
• Keep plaintext inside the enclave or confidential VM and minimize host, operator, logging, and debugging exposure.
• Explain enclave failure, key rotation, side-channel risk, performance cost, audit evidence, and safe recovery.

Requirements and scale assumptions

• Register approved workloads, upload encrypted inputs, request attestation, release scoped keys, and run confidential jobs.
• Expose job state, measurement, attestation result, policy decision, resource usage, and encrypted output retrieval.
• Support tenant isolation, key rotation and revocation, workload upgrades, deletion, audit export, and incident quarantine.
• Keep sensitive plaintext out of host memory, ordinary logs, crash dumps, and operator access by policy.
• Scale attestation and key-release decisions without one tenant key or policy service becoming a hot dependency.
• Never release keys to an unapproved measurement; make job retries safe without duplicating external effects.
• Fail closed for key release while preserving encrypted inputs, audit events, and resumable job state.
• Support 1,000 confidential jobs per minute across multiple regions and regulated tenant partitions.
• Partition key-release policy by tenant and workload measurement; isolate large jobs and attestation bursts.
• Retain encrypted inputs, signed attestations, policy decisions, and audit evidence while keeping enclave state ephemeral.

• Confidential jobs: 1K/min peak — Drives attestation capacity, key-service quotas, enclave pools, and admission control.
• Attestation decision: p95 <=2s — Key release can be slower than ordinary API reads but must have a bounded decision budget.
• Durable boundary: Committed before async — Signed workload measurements, attestation evidence, policy version, and key-release audit are authoritative.
• Async boundary: At-least-once workers — Keep long-running confidential computation, re-attestation, scanning, and audit export asynchronous.

Key entities

• ResourceSpecresourceId, tenantId, desiredState, version, policyVersion, updatedAt

  Versioned desired state for a confidential computing solution managed resource.

• OperationoperationId, resourceId, requestHash, step, attempt, status

  Durable confidential computing solution reconciliation operation with per-step progress.

• PolicyVersionpolicyId, scope, version, rules, effectiveAt, status

  Auditable confidential computing solution policy evaluated before provisioning or mutation.

• ReconciliationCheckpointresourceId, provider, observedVersion, cursor, lastError, updatedAt

  Provider-specific confidential computing solution observation and recovery cursor.

Data flow

1. 1. Accept a desired-state commandThe confidential computing solution control plane authenticates the tenant, validates policy and quotas, checks the expected version, and records the desired state.
2. 2. Plan a safe operationA planner turns confidential computing solution desired state into ordered, bounded steps with dependency checks, blast-radius limits, and rollback metadata.
3. 3. Reconcile providers asynchronouslyWorkers apply confidential computing solution operations through provider adapters, persist checkpoints, rate-limit calls, and treat unknown outcomes as observable state.
4. 4. Publish observed healthThe serving projection joins desired and observed confidential computing solution state with operation status, policy version, freshness, and actionable errors.
5. 5. Recover and auditRetries, dead letters, drift detection, and operator approvals repair confidential computing solution resources without losing the original command or provider evidence.

Deep dives and trade-offs

• Desired versus observed stateKeep confidential computing solution desired state separate from provider-observed state and show both to operators. Make every reconciliation step conditional and resumable so a worker crash does not restart unsafe effects. Version policy and resource state so old operations cannot overwrite newer intent.
• Provider failures and unknown outcomesUse provider-specific idempotency tokens and query-after-timeout behavior for confidential computing solution operations. Bound retries with exponential backoff, circuit breakers, and per-provider quotas. Route irreconcilable drift to an approval or quarantine path instead of retrying forever.
• Blast radius and operationsPartition confidential computing solution work by tenant, region, cluster, or resource class and cap concurrent mutations. Audit who changed desired state, which policy allowed it, and what provider evidence was observed. Alert on drift age, operation backlog, failed steps, policy denials, and stale observations.
• Push versus pull reconciliationUse event triggers for fast response and periodic scans for missed events, drift, and recovery. A push-only confidential computing solution controller silently misses changes when a provider event is lost.
• Central control plane versus provider-native controllersKeep policy, intent, and audit centralized while isolating provider-specific application logic behind adapters. A monolithic controller becomes hard to scale and couples unrelated provider failure domains.
• Automatic repair versus approvalAutomate low-risk, reversible confidential computing solution changes and require approval for destructive or high-blast-radius operations. Full automation without policy or blast-radius controls can turn a transient signal into a widespread outage.