DoorDash Cloud Engineer (Entry-Level) Interview Preparation Guide

Responsibilities matrix (IaaS / PaaS / SaaS)

*Shared indicates provider controls underlying network fabric and routing, customer controls VPC, subnets, security groups, and sometimes peering.

Explanation of gray area
Networking is a common ambiguity: in PaaS the cloud provider supplies managed endpoints, load balancers, and service networking, while the customer configures VPCs, subnets, security groups, and ingress/egress rules. Responsibility for secure network design (segmentation, NACLs) is typically the customer’s, but provider-managed components (service endpoints, private link, platform load balancers) require coordination—so security and troubleshooting often become shared. As a cloud engineer I emphasize clear runbooks and shared-responsibility docs to avoid gaps.

Direct answer

Egress charges come from data leaving the boundary the provider bills for: internet-bound traffic to end users, traffic crossing regions, and, on most providers, traffic crossing availability zones within the same region. The practical mitigations all work by moving the boundary closer to where the data is needed, either by caching content at the edge, keeping traffic inside a single zone or region, or by moving less data in the first place, and each of those comes with a real trade-off against latency, consistency, or engineering complexity, so the right mix depends on the traffic pattern, not on applying every technique everywhere.

Structured elaboration

Where the charges come from

• Internet egress: traffic leaving the cloud provider's network to reach end users directly. This is usually the largest line item for a public-facing service and scales with user traffic.
• Cross-region transfer: traffic moving between regions, for replication, multi-region reads, or a service in one region calling a dependency in another.
• Cross-AZ (availability zone) transfer: traffic between zones within the same region. This one catches teams off guard because it's easy to assume "same region" means "free," and on most providers it doesn't.
• Managed-service egress: data leaving object storage, a data warehouse, or a managed database to a destination outside the service's own region incurs the same class of charge, and it's easy to miss because it doesn't look like "network" spend on a dashboard.

Mitigation techniques and their trade-offs

A CDN (content delivery network) caches content geographically close to users, which cuts internet egress for anything cacheable, at the cost of cache-invalidation complexity for content that changes frequently, and it doesn't help traffic that genuinely can't be cached (personalized, real-time responses).

Keeping request paths inside a single availability zone, where the architecture allows it, avoids cross-AZ charges entirely for that traffic, at the cost of reduced resilience if that AZ has an outage, so this is a real availability trade-off, not a free optimization, and it's usually only appropriate for latency-insensitive internal traffic where the redundancy loss is acceptable.

Regional data placement and read replicas serve users from the nearest region instead of routing every request back to a single home region, cutting cross-region transfer, at the cost of higher storage spend (data duplicated across regions) and the operational complexity of managing eventual consistency between replicas.

Private interconnects (a dedicated network link between the cloud provider and on-premises or another network) carry sustained, high-volume transfer more cheaply per byte than public internet egress, at the cost of a fixed monthly commitment that only pays off if the traffic volume is consistently high enough to justify it.

Reducing payload size (compression, more efficient serialization, returning only the fields a client actually needs) cuts the bytes transferred regardless of the transfer path, at the cost of added CPU overhead for compression and, in a few cases, client compatibility work, but it's the one technique that stacks with all the others rather than competing with them.

How to decide which techniques apply
Start from where the traffic actually goes: measure egress by destination (internet, cross-region, cross-AZ) before picking a fix, because a CDN does nothing for cross-AZ database replication traffic, and a private interconnect does nothing for a spiky, low-volume workload that doesn't justify its fixed cost. The decision is driven by traffic pattern and volume, not by adopting every mitigation as a default checklist.

Worked example

A service transfers 50 TB of data to end users over the internet each month, plus 20 TB of cross-AZ traffic between its application tier and its database tier in the same region. At an illustrative internet-egress rate of $0.08/GB and a cross-AZ rate of $0.01/GB per direction:

Putting a CDN in front of the 60% of that internet traffic that's actually cacheable static assets removes 30 TB from the internet-egress bill:

a saving of $2,400/month, while the cross-AZ traffic, which a CDN does nothing for, stays at $200/month unless the application and database tiers are moved into the same AZ, which is a separate decision with its own resilience trade-off. This is the concrete version of the point above: the CDN was the right fix for the internet-egress line item specifically, and applying it did nothing for the smaller but distinct cross-AZ line item.

Trade-offs and pitfalls

The most common mistake is applying a technique because it's a known best practice rather than because the traffic pattern calls for it, like standing up a private interconnect for traffic volume too low to ever recoup its fixed cost. A second is treating "same region" as free; cross-AZ charges are a frequent surprise specifically because they don't map to the mental model of "only crossing regions costs money." A third is chasing egress cost reduction hard enough to sacrifice resilience, particularly single-AZ architectures adopted purely to avoid cross-AZ charges, which trades a real cost saving for a real availability risk that should be a deliberate, documented decision, not a side effect of a cost optimization pass.

Direct answer
When B must roll back but A stays on its new (backward-compatible) version, the core problem is that B's incompatible writes may have already happened before you detect the issue, so the fix isn't just "redeploy old B," it's identifying and correcting whatever inconsistent state those writes left behind, while B's rollback itself is straightforward since A's compatibility means A doesn't need to change at all.

Structured elaboration

1. Stop further damage: roll back B's code immediately (this part is simple exactly because A is backward-compatible with B's old version, no coordination needed there), which stops NEW incompatible writes from happening, but doesn't undo ones that already occurred.
2. Identify what's actually inconsistent: determine which writes B made in its brief new-version window were the problematic, incompatible ones, versus which writes (even during that window) were fine; this typically requires either an audit log of what changed, or a way to distinguish "written by new B" from "written by old B" (a version marker on the data itself, if you have one, or inferring from timestamps against the deploy window).
3. In-flight requests specifically: any request that started against new-B logic but hasn't yet completed when the rollback happens needs explicit handling, either let it finish against the code it started with (avoiding a mid-request logic switch) and then reconcile its result afterward if needed, or, if that's not safe, actively cancel/retry it against the now-rolled-back old B.
4. Reconciliation toward eventual consistency: for the identified inconsistent writes, either a compensating action (a corrective write that brings the data back to what old-B's logic would have produced) or, if the incompatible writes are numerous and hard to individually correct, a broader reconciliation job that recomputes affected records from source data, run once B is confirmed stable on the old version again.
5. Idempotency throughout: both the rollback itself and any compensating/reconciliation actions need to be safely re-runnable, since this kind of recovery work is exactly the scenario where a retry (from a nervous on-call engineer, or from an automated retry mechanism) is likely.

Worked example
Service B's new version wrote records in a new, incompatible format for roughly 8 minutes before the regression was caught and B rolled back. An audit log (or a version-tagged field on the written records) identifies exactly which records fall in that window; a reconciliation job re-derives the correct, old-format value for each of those specific records from upstream source data, run idempotently (safe to re-trigger if it's interrupted partway through) so a retry doesn't double-apply the correction.

Trade-offs and pitfalls
The scope of this problem is directly proportional to how LONG the incompatible version was live before detection, which is a strong argument for the fast, automated rollback-trigger discipline covered elsewhere in this topic; a regression caught in 30 seconds via automated detection leaves a much smaller reconciliation problem than one caught 30 minutes later via a human noticing something looked off. The common mistake is treating the code rollback as the end of the incident, when the DATA reconciliation is often the harder, longer-running part of actually resolving it.

A Well-Architected Review is a structured, repeatable health check where an architect walks a workload through Amazon Web Services' (AWS) six pillars, operational excellence, security, reliability, performance efficiency, cost optimization, and sustainability, using a standard set of interview questions. The goal is to surface risks, like a single point of failure or an exposed database, before they cause an outage or a security incident, not to grade the team. You walk away with a prioritized list of fixes ranked by business impact, not a wall of jargon.

What happens in the review

• Kickoff: the architect and stakeholders agree on which workload is in scope, the business goals it serves, and any compliance constraints. This shapes which risks matter most for this specific review.
• Discovery: the architect reviews architecture diagrams, cost reports, and operational logs, and interviews the engineers who run the system day to day.
• Assessment: findings are answered against a standard pillar-by-pillar questionnaire inside the AWS Well-Architected Tool (a free AWS service built for exactly this process), and each risk is tagged low, medium, or high.
• Remediation planning: risks become a prioritized backlog with rough effort estimates.
• Readout: results are presented to stakeholders in plain business language, for example "this database has no failover, so a single hardware fault takes down checkout for hours," alongside a proposed roadmap.

What you get out of it (deliverables)

• An executive summary that translates technical risk into business risk, with an overall risk rating.
• A findings catalog: each risk mapped to a pillar, given a severity, and linked to the specific AWS best practice it violates.
• A prioritized remediation backlog: what to fix first and why, with rough effort.
• Updated architecture diagrams showing the recommended target state.
• Supporting evidence: the review lives inside the AWS Well-Architected Tool, which stores your answers, generates a milestone report, and lets you re-run the review later to show whether risk actually went down.

Worked example

Picture an e-commerce workload review. Discovery turns up three things: the order database runs on a single virtual server with no standby, deployments go straight to production with no rollback plan, and nobody currently reviews the AWS bill. Mapped to pillars, that is one reliability finding (single point of failure), one operational excellence finding (no safe deployment process), and one cost optimization finding (no cost governance). The remediation backlog ranks the database failover fix as "high impact, low effort" (turn on a standby replica), the deployment process as "high impact, medium effort" (add a rollback step to the pipeline), and the cost review as "low impact, low effort" (a monthly cost report). That ranked, concrete list is what a stakeholder actually receives, not just a pillar checklist.

Trade-offs and pitfalls

• A review is a snapshot, not a guarantee: it reflects the architecture and the answers given on that day, so scope it narrowly and re-run it periodically. The Well-Architected Tool's milestone feature exists specifically to track that progress over time.
• The value comes from acting on the backlog, not from the report itself. Treat every high-severity finding like a ticket with an owner and a date, or the review becomes a document nobody reads again.
• A review can turn into a box-checking compliance exercise if it skips the interviews with the engineers who actually run the system; that step is what surfaces the real risk, not the questionnaire alone.
• For a regulated workload, pair the standard AWS lens with a custom lens (a tailored question set) so the review also captures the organization's own compliance requirements, not just AWS's generic best practices.

Direct answer

DNS-based failover works by changing the authoritative record (A, AAAA, or CNAME) for a name once a health check detects the current target is down, so future lookups resolve to the healthy endpoint. The catch is caching: recursive resolvers, OS stub resolvers, and some client libraries hold the old answer and are not obligated to re-check before the TTL expires, so a client that resolved the name right before the failure can keep sending traffic to a dead endpoint for up to a full TTL, even though the authoritative record already changed.

Structured elaboration

sequenceDiagram
    participant Client
    participant Resolver
    participant AuthDNS as Authoritative DNS
    participant HealthCheck as Health Checker
    participant OriginA as Origin A (primary)
    participant OriginB as Origin B (standby)

    Client->>Resolver: Resolve api.example.com
    Resolver->>AuthDNS: Query (cache miss)
    AuthDNS-->>Resolver: A record = Origin A (TTL 300s)
    Resolver-->>Client: Origin A (cached 300s)
    Client->>OriginA: Request
    Note over OriginA: Origin A fails
    HealthCheck->>OriginA: Health probe fails twice (60s)
    HealthCheck->>AuthDNS: Update A record to Origin B
    Note over Client,Resolver: Cache still holds Origin A until TTL expires
    Client->>OriginA: Request still routed to dead origin
    Note over Resolver: TTL expires
    Client->>Resolver: Re-resolve api.example.com
    Resolver->>AuthDNS: Query (cache miss)
    AuthDNS-->>Resolver: A record = Origin B
    Client->>OriginB: Request now routed correctly

How TTL bounds the blast radius. The authoritative TTL is an upper bound, not the whole story. Worst case for a client is roughly detection time (how long health checks take to notice the endpoint died) plus record update propagation (usually seconds for managed DNS) plus up to a full TTL for a resolver that cached the record right before the failure. Best case is a client whose cache had already expired at the moment of failure, seeing the change almost immediately.

Reducing client-visible downtime

• Shorten TTL ahead of planned risk windows (deploys, maintenance) at the cost of more DNS query volume.
• Put a health-checked global load balancer or CDN in front of origins: it does fast, active health checking and reroutes without waiting on client-side DNS caches at all, since clients only ever resolve to the load balancer's stable address.
• Use anycast so the same IP is announced from multiple locations and failover happens at the routing layer, bypassing DNS caching entirely.

Worked example

Health checks poll every 30 seconds and require 2 consecutive failures before triggering failover, to avoid flapping on a single missed check: detection time = 60 seconds. A managed DNS provider's record update completes in about 5 seconds.

At TTL = 300 seconds, worst-case client-visible downtime (client cached the record 1 second before failure):

Best case, client's cache had already expired at the moment of failure:

If TTL is tuned down to 30 seconds ahead of a risky change:

That is a 3.8x improvement in worst-case client-visible downtime, but caches now expire 10 times more often ($300/30$), meaning roughly 10 times more queries hit the authoritative nameservers for the same client population, a real cost and load trade-off, not a free win.

Trade-offs & pitfalls

• Some resolvers and client libraries do not strictly honor TTL, a small minority cache longer or shorter than instructed; design for the worst case, not the documented one.
• Setting TTL near zero everywhere, permanently, trades a failover problem for a cost and latency problem, since every request now pays a fresh DNS lookup and some providers charge per query.
• DNS failover alone cannot verify the new target is actually healthy from the client's network path; combine it with active health checks at the load balancer or CDN layer rather than relying on DNS as the sole signal.
• A common mistake is failing over DNS but leaving the client's connection pool holding an open connection to the dead endpoint. DNS failover only affects new lookups, not already-established connections, so client-side connection timeouts and retry logic matter just as much as the TTL.

Objective
Master Terraform (for AWS) to confidently author modular IaC, run CI/CD pipelines, manage remote state, and implement policy/testing within 4 weeks.

High-level plan & timeboxes

• Week 1 (Foundations, 10–12 hrs): Read docs, watch 2–3 focused tutorials, learn HCL syntax, providers, resources.
• Week 2 (Core skills, 12–15 hrs): Build three small stacks (VPC, EC2 + IAM, S3 + lifecycle). Learn remote state (S3/Dynamo) and workspaces.
• Week 3 (Modules & testing, 10–12 hrs): Refactor into reusable modules, write unit-like tests with terraform validate and Terratest, add CI pipeline (GitHub Actions).
• Week 4 (Hardening & real-world polish, 8–10 hrs): Implement state locking, secrets via Vault/SSM, drift detection, cost estimation, and a mini migration task.

Hands-on tasks

• Init/plan/apply/destroy cycles in a sandbox AWS account
• Create/version modules with inputs/outputs and examples
• Add automated plan checks in PRs; run Terratest for critical modules
• Simulate failures (state lock, provider error) and recover

Tracking progress & metrics

• Kanban board with tasks and timeboxes; weekly demos
• Success criteria: automated PR plan, 3 modules, CI passing, recovery playbook
• Metrics: number of successful apply/destroy runs, test pass rate, time-to-recover

Risks & mitigations

• Risk: State corruption — mitigate with remote state + backups + locks
• Risk: IAM misconfig — use least-privilege service accounts and test in isolated account
• Risk: Scope creep — enforce weekly goals and refuse additional features until core objectives met

This plan balances learning, practice, and measurable outcomes suitable for a Cloud Engineer role.

Difference: stateful vs stateless

• Stateful services keep client-specific data on the server between requests (e.g., in-memory sessions, sticky load‑balancer). Easier per‑user logic but harder to scale, failover, and upgrade.
• Stateless services treat each request independently; any required state is sent with the request or fetched from external stores. Easier to scale horizontally, simpler failover and routing.

Concrete conversion: session‑sticky web server → stateless

Situation: web app uses sticky sessions so user session lives in app memory. I would:

• Remove sticky sessions from the load balancer so any instance can handle requests.
• Add an external session store (Redis/ElastiCache) to persist session data; update app to read/write session by session id stored in cookie.
• Or replace server sessions with signed JWTs stored in a secure HttpOnly cookie; tokens carry claims and optionally a short expiry; use refresh tokens for long sessions.
• Introduce centralized configuration (feature flags) and shared cache for user data; add session encryption and rotation keys in AWS KMS or Vault.
• Update health checks and autoscaling policies to use instance‑agnostic metrics.

Trade‑offs

• Redis: simple, supports big session objects, central point of failure (mitigate with clustering/replication), extra network latency.
• JWTs: reduce server state and network calls, larger cookies, harder to revoke (needs token blacklist or short expiry + refresh), sensitive to token size.
• Operational: moving state out improves scalability and deployment flexibility but increases complexity in security (key management), monitoring, and latency.

Direct answer

Build trust before you need anything, by being reliable on small things, transparent about your constraints and capacity, and by giving the other person visibility into your world so they aren't surprised later. Waiting to invest in the relationship until you need a favor makes the ask feel transactional.

Framework

Lead with reliability on small things. Deliver on small, early commitments, answer a question promptly, show up to their planning session, so your word has a track record before there's a high-stakes ask on either side.

Be transparent about constraints. Proactively share capacity, risk, and known limitations rather than letting the other person find out the hard way, mid-project.

Give visibility into your world. Invite them into a review or share a roadmap or dashboard, so they understand your constraints without needing you to explain from scratch every time.

Make it reciprocal early. Ask what they need and what's on their plate too. Trust runs both directions, not just from you demonstrating value to them.

Worked example

Situation: a new product manager joins and will depend on your team, for example a platform or infrastructure team, for their roadmap.
Action: in the first couple of weeks, gave the PM read access to the team's capacity and roadmap view along with a short walkthrough, rather than waiting for them to ask. Proactively flagged one known constraint, a piece of infrastructure that was close to capacity, before it affected their planning. Followed through quickly and visibly on a small early request, answering a scoping question the same day, to establish reliability before anything high-stakes came up.
Result: by the time the PM had a genuinely high-stakes ask, an accelerated timeline, there was already a working relationship and a shared understanding of constraints. The conversation started from what's actually possible given what you already know, instead of starting from zero.

Trade-offs and pitfalls

• Trust-building gestures can look like busywork if they aren't tied to something concrete. Keep them small and genuinely useful, not performative.
• Over-sharing every constraint upfront can read as excuse-making before there's even a request. Calibrate to what's actually relevant to their planning.
• The senior differentiator is doing this proactively, before there's a need, rather than scrambling to build rapport only once you need something from the other person, which reads as transactional.

Direct answer. I'd want a small, coherent evidence package proving three things: the program identifies what actually matters to the business (a current business impact analysis and criticality ranking), the plan has been tested against reality on a regular cadence with findings tracked to closure, and it's actively maintained rather than signed once and shelved. What makes documentation credible to an examiner is version history, dated exercise records with named participants and findings, and open corrective actions with owners and target dates, not how polished the plan document itself looks.

1. Program foundation documents

A current business impact analysis, or BIA (the process that identifies which business functions are critical and quantifies the cost of their downtime over time), is what the rest of the program's priorities trace back to. "Current" means dated and tied to a defined refresh cadence, not a one-time artifact from years ago. Alongside it: the continuity plan itself at the business-function level, describing what each critical function needs to keep operating or recover and who's responsible; and a declaration and activation framework naming who has the authority to formally invoke the plan and the escalation path if that person is unreachable.

2. Evidence the plan has been tested, not just written

Records from an exercise programme across different depths: a tabletop exercise (a facilitated discussion where the team talks through a scenario without actually executing anything), a functional exercise (a partial, real execution of specific procedures), and periodically a full-scale exercise, each with a date, scope, participants, and a documented outcome. A hotwash or after-action report for each one (the structured debrief run immediately afterward, capturing what worked, what didn't, and why), not just a pass or fail note. A corrective action log tying each finding back to a specific exercise, with an owner and a target date, and a record of which items actually closed versus which are still open. An examiner is generally less interested in whether every exercise went flawlessly and more interested in whether findings get followed through on.

3. Evidence the documentation reflects the business today, not the business as it was

Version control on the plan: a change log showing when it was last updated, by whom, and why, ideally tied to specific triggers (an org restructure, a new critical system, a new key supplier) rather than a periodic rubber stamp. A management review record showing leadership periodically reviewing the program's health, including whether resourcing and risk-acceptance decisions were actually made. And training and awareness records for the people named in the plan, since a plan naming a role that no longer exists, or a person who's left, is itself evidence the program isn't current.

4. Regulatory and compliance framing

These are examples of different regulatory regimes, not a checklist to memorize in full: which one applies to you, if any, depends on your sector and jurisdiction. Different regulators expect different levels of prescriptiveness. In the US, financial-sector examiners work from the Federal Financial Institutions Examination Council (FFIEC)'s IT Examination Handbook, which describes practices examiners use to evaluate business continuity management (BCM) governance, resilience strategy, training, exercises, and maintenance, scaled to an institution's size and complexity, rather than imposing a fixed checklist of requirements. The EU's Digital Operational Resilience Act (DORA) is more prescriptive for financial entities: it requires maintaining and periodically testing information and communication technology (ICT) continuity plans, with standard testing performed at least annually and more intensive testing on a longer cycle for larger institutions, and requires records of that testing to be kept. ISO 22301, the international management-system standard for business continuity, lays out the shape a mature program has structurally regardless of sector: a policy, a scope, a BIA and risk assessment, documented strategies and plans, an exercising programme, and the ordinary management-system disciplines of internal audit, management review, and corrective action closed out rather than just logged. Building the evidence package to that shape tends to answer the question before an examiner from any of these regimes asks it.

Worked example

A mid-size organization preparing for an examiner visit assembles: a BIA refreshed nine months earlier and due for its annual refresh in three months, listing the top twelve critical functions and their maximum tolerable downtime; the continuity plan for each function, with a change log showing two revisions in the past year, one triggered by a platform migration and one by a reorganization of the team owning a critical function; records of two tabletop exercises and one functional exercise in the past twelve months, each with a hotwash summary; a corrective action log showing eleven findings raised across those exercises, nine closed with evidence and two still open with named owners and dates inside the next quarter; and quarterly risk-committee minutes showing the program's status was reviewed and the two open items were acknowledged with a committed resourcing decision. That combination, current inputs, a tested cadence, and traceable follow-through, is what makes a program read as alive rather than as a binder written once and never reopened.

Trade-offs & pitfalls. A beautifully written plan with no exercise history behind it is a bigger red flag to an experienced examiner than a rougher plan with a real testing record, since untested plans reliably fail in ways nobody predicted. Closing corrective actions by simply marking them closed without evidence is worse than leaving them visibly open, because an examiner who spot-checks one and finds it wasn't actually fixed calls the whole log's credibility into question. And treating the BIA as a one-time project rather than a maintained artifact is the most common gap of all: businesses change what's critical to them faster than a plan written once accounts for, and an examiner asking how you know this is still accurate is really asking whether a refresh cadence exists at all.

Direct answer

Reconstructing an outage from Git history and CI artifacts means treating the repository and pipeline as a FORENSIC RECORD, not just a deployment mechanism: the investigation order should move from COARSE to FINE, first establishing WHICH change window is even in scope (correlating the outage's start time against deployment/sync timestamps), then WHAT changed in that window (the commit diff), then WHY it was believed safe (the PR's review and CI-check history), then WHAT ACTUALLY HAPPENED when it deployed (the CI/CD run's own logs and the deployment tool's own record of what it did), each step narrowing the investigation using evidence the PREVIOUS step surfaced, rather than jumping straight to reading diffs without first confirming the right window.

Structured elaboration

Git data points, and the order to examine them.

1. Deployment/sync timestamps first, correlating the outage's observed START time against the GitOps controller's own sync history (or CI's deployment-job timestamps) identifies WHICH deploy(s) fall in the causally-relevant window, before reading any code at all; skipping this and reading recent commits chronologically risks anchoring on a change that turns out to be outside the actual causal window.
2. The commit/PR diff for deploys in that window, read alongside the PR's own description and linked ticket for stated INTENT, what the change was supposed to do, which frames whether the actual outage behavior looks like an intended-but-flawed change or something unexpected even relative to its own stated goal.
3. The PR's review and approval history, who approved, and critically, whether any review comment raised a concern that was addressed, dismissed, or simply not resolved before merge, sometimes the clearest signal of what to investigate further is a reviewer's own unresolved question.
4. CI check results for that specific commit, which checks ran and passed, and just as importantly, which checks did NOT run or were skipped (a required check bypassed by an admin override, a specific test suite that does not cover the code path that actually failed).

CI outputs, and the order to examine them.
5. The deployment job's own execution log, not just its pass/fail status, the actual output (for IaC (infrastructure-as-code) specifically, the terraform apply or GitOps sync log) shows exactly what actions were taken against real infrastructure, which is the ground truth for "what changed," more reliable than reasoning from the diff alone about what the change SHOULD have done.
6. Any POST-DEPLOY validation or smoke-test results from that same run, if present, showing whether the pipeline itself detected a problem immediately and, if so, whether that signal was acted on or missed.
7. Deployment metadata correlating this deploy to any OTHER concurrent or recent change (a different service's deploy around the same time, an infrastructure change from a separate pipeline), since an outage's true cause is sometimes an INTERACTION between two independently-safe-looking changes, not either one alone.

Worked example

A concrete reconstruction for an outage that began at 14:32:

1. Query the GitOps controller's sync history for deploys completing between roughly 14:20 and 14:32 (allowing a reasonable propagation window before symptoms became visible); this identifies ONE deploy at 14:28, commit a1b2c3d, as the sole candidate in the causal window, before reading its content at all.
2. Read the PR for a1b2c3d: stated intent was "increase connection pool size," a narrower, seemingly-safe change relative to what actually broke.
3. Check the PR's review history: one reviewer commented "did we check this against the DB's own max-connections limit?", the author replied "should be fine" with no evidence attached, and the PR was approved and merged anyway, a concrete lead directly relevant to a connection-related outage.
4. Check CI: the standard plan/policy checks passed; there was no automated check for "does this pool size exceed the target database's configured connection limit," a gap in test coverage now identified as directly relevant.
5. Read the deployment job's own log: confirms the new pool-size value was actually applied at 14:28 exactly as the PR intended, ruling out "the deploy itself malfunctioned" as a contributing factor and confirming the investigation should focus on the CHANGE's content, not the deployment mechanism.
6. Conclusion supported by evidence gathered in this specific order: the change was correctly deployed exactly as reviewed and intended, but the reviewer's flagged concern (connection pool size versus the database's actual configured limit) was the root cause, and it was RAISED but not adequately investigated before merge, a finding for the blameless postmortem to address at the PROCESS level (why did an unresolved reviewer comment not block merge), not merely the technical level (revert the pool-size change).

Trade-offs and pitfalls

• Common mistake: starting the investigation by reading recent commits chronologically, rather than first correlating deploy timestamps against the outage's actual start time. This risks anchoring on whichever recent change LOOKS most suspicious rather than the one that is actually in the causally-relevant window, a real, common way postmortems arrive at a plausible-but-wrong root cause.
• A reviewer's unresolved, dismissed, or unaddressed comment is one of the highest-value single data points in this whole process and is easy to miss if only the FINAL diff is read, without looking at the PR's actual comment thread; the finished code shows what shipped, the comment thread shows what was KNOWN and not acted on.
• Reading only the diff and reasoning about what it SHOULD have done, without also reading the deployment job's own execution log, risks missing a case where the deployment mechanism itself behaved unexpectedly (a partial apply, an unexpected side effect of a dependency), a separate class of cause from "the change itself was wrong," and confusing the two leads to fixing the wrong thing.
• A blameless postmortem needs the PROCESS-level finding (why did a flagged concern not block merge), not just the technical one (what value was actually wrong), per the worked example above; stopping the investigation once the technical cause is found, without asking why the existing review process did not catch it, forfeits the improvement a genuinely blameless postmortem is meant to produce.