Product Knowledge Foundation Questions

Baseline understanding of the company and its primary product or service: what problem it solves, who the users or customers are, the product value proposition, key features and capabilities, major components and high level technical architecture, and how it competes in the market. Candidates are expected to have researched the product enough to clearly summarize its purpose, target users, core workflows, and business goals, and to explain at a basic level how the technology and integrations enable those outcomes. Interviewers use this to assess research preparation, domain comprehension, ability to synthesize product information, and clear communication of product value rather than deep technical expertise.

EasyTechnical

83 practiced

You are interviewing for an SRE role at a company whose primary product you've researched. In two minutes give a concise product pitch that includes: the customer problem the product solves, the primary target users, the core value proposition, and the top two user-facing features. Focus on outcomes and why customers care rather than implementation details.

EasyTechnical

71 practiced

Based on the product's target customers, describe whether it is most likely multi-tenant SaaS, single-tenant, or on-prem. For the model you pick explain two operational implications relevant to SRE (isolation, patching cadence, resource utilization, observability) and how that should affect monitoring and runbooks.

EasyTechnical

93 practiced

Explain two market differentiators the product uses to compete (for example: latency, security/compliance, price, integrations). For each differentiator describe how it changes SRE priorities, monitoring, or target SLAs, and why the product team may accept additional operational costs to maintain it.

MediumTechnical

92 practiced

Design SLOs and error budget policies for a feature used by three customer tiers: free users, paid users, and enterprise customers. Explain which SLIs you choose, proposed SLO targets per tier, how to allocate a global error budget across teams, and how SRE enforces budgets during deployments and feature rollouts.

Sample Answer

Requirements & constraints:- Feature must meet different expectations per tier (free, paid, enterprise).- Want measurable, customer-facing indicators, actionable error budgets, and clear enforcement for rollouts.

Chosen SLIs (user-facing, measurable):- Successful request rate: % of user requests that return a correct response within threshold latency.- P95 latency: response time experienced by 95% of requests.- Feature availability / degradation detection: fraction of time feature is not in degraded mode (e.g., returns fallback).- Data correctness (if applicable): % of operations without data loss or corruption.

Proposed SLO targets (per 30-day window, example values):- Enterprise: Successful request rate ≥ 99.95%; P95 latency ≤ 200ms; availability ≥ 99.99%- Paid: Successful request rate ≥ 99.9%; P95 latency ≤ 400ms; availability ≥ 99.95%- Free: Successful request rate ≥ 99.0%; P95 latency ≤ 800ms; availability ≥ 99.0%Rationale: higher SLAs for higher-paying tiers; free tier tolerates more errors/latency.

Global error budget allocation:- Compute error budget as (1 − SLO) × requests per tier. Convert to budgeted error minutes or failed requests.- Reserve 20% of total global error budget as cross-team contingency for cascading failures.- Allocate remaining budget to owning teams proportional to traffic weight and business priority (example: enterprise-heavy services get stricter burn controls).- Maintain per-team and per-tier burn rates; store budgets centrally in a dashboard.

Enforcement during deployments / rollouts:- Pre-deploy checks: validate canary config, capacity, and test-suite success. Block if canary traffic share or heuristics not set.- Progressive rollouts gated by error budget: allow canary → 5% → 25% → 100% only while burn rate < threshold. If burn rate > 1.5× expected, pause/roll back automatically.- Tier-aware rollouts: for risky changes, deploy to free tier first, then paid, then enterprise. For enterprise-impacting changes, require manual approval and extended canary windows.- Automation: integrate monitoring (SLI telemetry), CI/CD, and an automated policy engine to pause rollouts and create incidents when budget burns rapidly.- Post-incident: require blameless postmortem and mitigation plan; reallocate future budget (reduce planned risk) until improvements verified.

Operational practices:- Alerting on SLI breaches with severity tied to tier impact.- Regular review of SLOs with product/account teams; adjust targets when business needs or traffic patterns change.- Use error budget as currency: feature launches, experiments, and marketing pushes consume budget—prioritize accordingly.

This approach ties customer expectations to measurable SLOs, gives teams clear budgets and automated enforcement, and preserves enterprise reliability while enabling innovation.

HardSystem Design

74 practiced

Design a multi-region deployment plan for the product that requires full failover within 5 minutes for region outages and must maintain session consistency for transactional operations. Describe active-active vs active-passive options, data replication approaches, DNS failover considerations, session management, conflict resolution, and a testing plan for failover exercises.

Sample Answer

Requirements & constraints:- RTO ≤ 5 minutes for full-region outage; maintain transactional session consistency (no lost or divergent transactions).- Multi-region for HA and latency.- SRE focus: automation, monitoring, repeatable runbooks, periodic drills.

High-level options- Active-Passive: - Primary region handles all traffic; secondary is warm/cold standby. - Pros: simpler consistency (single writer), easier conflict avoidance, simpler DB topology. - Cons: longer failover complexity, potential wasted capacity, failover cutover risk. - Use when strict serializability and minimal conflict risk are required.

- Active-Active: - All regions accept traffic concurrently with cross-region data replication. - Pros: lower latency for users, built-in capacity, faster regional continuity. - Cons: conflict resolution, higher complexity in transactional consistency, more expensive.

Data replication approaches- Single-writer with geo-replica (recommended if transactional consistency paramount): - Primary region performs writes; replicas in other regions replicate asynchronously or semi-sync. - To meet 5-min failover: ensure replica lag SLAs (monitoring & automated promotion).- Multi-master / active-active: - Use a globally-distributed transactional DB that supports strong consistency (e.g., Spanner, CockroachDB) or implement consensus (Paxos/Raft across regions). - If using async replication (RDBMS + CDC), add conflict detection.- Hybrid: colocate write-master per shard (geo-partitioning) to limit cross-region transactions.

Consistency & transactions- Prefer global transactional DB that supports external consistency (TrueTime/Spanner semantics) if budget allows.- Otherwise, implement: - Distributed transactions via two-phase commit only for cross-region critical ops (minimize usage). - Idempotent operations, monotonic counters, and careful ordering keys.- For critical operations, route writes to single-writer region or shard.

Session management & session consistency- Avoid in-memory sticky sessions across nodes/regions.- Use token-based sessions or centralized session store: - JWT with short TTL + refresh token pattern (stateless) for read-heavy flows. - For transactional session state, use a regional/session store with synchronous replication or strongly-consistent global store (Redis with active-active or DynamoDB with conditional writes).- Ensure session-affinity routing for in-region operations; on failover, session rehydration via centralized store or replay of last-known commands.

DNS and traffic failover- Use Global Load Balancer / GSLB with health checks and Anycast (Cloud CDN/GCLB, AWS Global Accelerator) for fast global failover and BGP convergence.- DNS-only failover risks TTL and propagation delays; use short TTL (30–60s) combined with health-aware GSLB to meet 5-min RTO.- Configure health checks at LB and application layers; automated failover orchestration to change active endpoints and update route weights.

Conflict resolution- Avoid conflicts by design (single-writer or partitioned ownership).- When unavoidable: - Deterministic conflict resolution: CRDTs for mergeable data, last-writer-wins with vector clocks only when acceptable. - Application-level reconciliation for business-critical records with manual review or compensating transactions. - Audit logs & change streams (CDC) to detect and reconcile divergence.

Operations, monitoring & automation- Telemetry: replication lag, write latency, error rates, regional health, queue/backlog sizes, SLOs.- Automated promotion scripts for replica->primary with prechecks (data integrity, replica lag thresholds).- Runbooks: clear step-by-step failover and failback procedures, pre-checks, rollback steps.- Access controls & automated approvals for runbook execution (reduce human error).

Testing plan (failover exercises)- Continuous: synthetic traffic, replication-lag SLO alerts, chaos experiments that simulate region loss.- Quarterly full DR drills that: - Simulate primary region outage, trigger automated failover, measure RTO and recovery correctness (<5 minutes). - Validate session continuity: confirm in-flight transactions either committed or rolled back consistently. - Verify DNS/LoadBalancer behavior and client reconnection. - Post-mortem with metrics: RTO, RPO, data divergence, customer impact. Update runbooks and automation.- Canary failovers: partial traffic shifts to validate promotion scripts without full outage.

Trade-offs & recommendation- If strict session consistency and transactional correctness are highest priority: choose active-passive or global single-writer model with fast automated promotion and synchronous-ish replication/monitoring.- If low-latency global reads and continuous availability are dominant and budget/complexity acceptable: use active-active with a strongly-consistent distributed DB (Spanner/CockroachDB) plus CRDTs/compensation for non-transactional data.- Implement comprehensive automation, health checks, and frequent DR drills to guarantee ≤5-min failover while preserving transactional integrity.

Unlock Full Question Bank

Get access to hundreds of Product Knowledge Foundation interview questions and detailed answers.

Join thousands of developers preparing for their dream job.