DevOps Engineer DBMS Concepts Interview Guide

At Read Committed, each statement receives a new snapshot, so later statements can see commits made in between. Higher isolation changes the guarantees and may require retrying serialization failures. Choose isolation from the business invariant, not from an assumption that every transaction freezes all reads.

Check your understanding: Interleave two sessions and document the snapshots each statement sees.

Common trap: Treating transaction atomicity and isolation as identical.

Concept reference: PostgreSQL: transaction isolation

An index is an option, not a command. The planner considers selectivity, statistics, table size and access cost. Read estimated and actual rows, filters and scan types before changing indexes. EXPLAIN ANALYZE executes the statement, so use safe data and transaction handling for writes.

Check your understanding: Compare estimated and actual row counts on representative data.

Common trap: Forcing an index without measuring the full query.

Concept reference: PostgreSQL: reading EXPLAIN plans

Check the grain of each table and whether the join creates several rows for one order. Aggregate at the intended business grain before joining, or use the correct relationship and key. Reconcile totals using a tiny fixture containing multiple child rows and an unmatched parent.

Check your understanding: Use one order with two child records and verify the total remains correct.

Common trap: Using DISTINCT as a universal repair for a wrong join.

Concept reference: PostgreSQL: reading EXPLAIN plans

Readiness controls whether a workload should receive traffic; liveness can trigger a restart. A temporary downstream outage may justify removing traffic without restarting an otherwise healthy process. Use a startup probe for slow initialization where appropriate and test failure behavior explicitly.

Check your understanding: Make a dependency unavailable and observe routing and restart behavior separately.

Common trap: A liveness probe that causes a restart storm during a dependency outage.

Concept reference: Kubernetes: startup, readiness and liveness probes

Define success and abort signals before rollout: error rate, latency and critical workflow correctness. Start with a limited cohort, compare against baseline and keep rollback compatible with any schema changes. A healthy process is not proof that the business workflow still works.

Check your understanding: Inject a bad release into a small cohort and demonstrate rollback.

Common trap: Waiting for the whole fleet to fail before evaluating impact.

Concept reference: Google SRE: handling overload

Scaling adds capacity, which may arrive too late or be limited by dependencies. Backpressure bounds work admitted to existing capacity. Combine queue and concurrency limits with clear retry behavior; monitor saturation and oldest queued work rather than CPU alone.

Check your understanding: Hold capacity fixed and prove a burst does not produce unlimited buffering.

Common trap: Assuming autoscaling removes the need for admission control.

Concept reference: Google SRE: handling overload

First, identify technical constraints and define measurable service objectives. Next, explain how configuration becomes a monitored, recoverable production change. Contrast architectural trade-offs across write cost, read latency, consistency and operational complexity, explicitly mitigate the risk of a partially deployed reader cannot understand the new representation, and confirm system stability using a compatibility contract, expand-and-contract rollout and rollback rehearsal.

Common trap: Reaching for a specific library or framework before defining constraints, failure envelopes, and automated verification criteria.

Prioritise the failure mode exhibiting the highest user blast radius and lowest observability. Formulate an explicit containment boundary, implement idempotent retries with jitter, and establish an automated rollback threshold. Verify resilience through semantic validation results, quarantine records and a replay verification.

Common trap: Relying on passive monitoring dashboards without defining explicit error-budget alerts, rollback triggers, and verified recovery procedures.

Structure the response using Context-Decision-Tradeoff-Result: articulate the business and technical constraints, compare viable alternatives, explain the implementation (explain how configuration becomes a monitored, recoverable production change), and document the accepted trade-off. Provide concrete proof: an explain plan, concurrency test and recovery verification.

Common trap: Speaking only in high-level abstractions or team accomplishments without detailing your direct implementation decisions, trade-offs, and measured results.

Formulate a falsifiable hypothesis from observable telemetry before altering configurations. Then inspect policy changes, deployment events, saturation signals and retry amplification. Isolate the defect to the smallest reproducible boundary, validate root cause with evidence, and confirm full resolution using separate identity and network limits plus an abuse-simulation report.

Common trap: Applying speculative fixes or restarting services blindly without establishing an observable signal connected to a falsifiable hypothesis.

Produce a least-privilege policy diff with a canary metric and recovery drill. Document baseline assumptions, technical mechanism (explain how configuration becomes a monitored, recoverable production change), rejected alternatives, bounded failure envelopes, and deterministic pass criteria. Supply reproducible verification via a trace, a minimal reproduction and a regression test.

Common trap: Presenting architecture diagrams or slides lacking automated unit/integration tests, observable metrics, or automated rollback configurations.