DoorDash Cloud Engineer (Entry-Level) Interview Preparation Guide

Direct answer

Break the cost into four buckets tied to concrete volumes rather than one blended number: storage (split by hot/warm/cold tier), ingest compute, egress, and query compute. Once each bucket is a formula in terms of raw ingest volume, retention days, and downsample ratio, every proposed knob (sampling, retention, downsampling, precomputing queries) is just a parameter change you can re-run through the same formulas, which is what makes the model defensible to finance: they're not trusting your intuition, they're trusting arithmetic they can re-check.

Structured elaboration

The four cost buckets and what drives each:

Retention tiers as the main storage lever: hot (short window, full resolution, most expensive per byte), warm (downsampled, medium retention, mid-cost), cold (heavily downsampled, long retention, cheapest per byte, e.g. object storage archive class). Storage cost is the sum of the three tiers, each computed from its own retention window and downsample ratio, not one blended "storage cost per byte."

Which knobs move the number, and by how much: sampling rate reduces raw ingest volume directly, which cascades into every downstream bucket. Retention shortening only affects the tier whose window changed. Downsampling more aggressively in a tier only affects that tier and everything colder than it. Query precomputation (materialized views, discussed in depth as its own system-design question in this topic) reduces query compute without touching storage or ingest at all. These don't all move the same line item, which is exactly the point when explaining trade-offs to a non-architecture stakeholder: "cut retention" and "sample harder" save different money for different reasons.

Worked example

Baseline: 1 PB/month raw ingest ($I = 1{,}000$ TB/month), three retention tiers.

Illustrative unit costs (chosen only to demonstrate how the model moves, not a vendor quote, since real pricing varies by provider, region, and contract):

• Hot storage: $0.023/GB-month. Warm: $0.010/GB-month. Cold archive: $0.0018/GB-month.
• Ingest compute: $2/TB processed. Egress: $0.05/GB. Query compute: $0.005/GB scanned.

Retention plan: hot 7 days (full resolution), warm 90 days (10x downsampled), cold 730 days (100x downsampled from raw).

At 5% of raw volume egressing to external dashboards/consumers:

At 200,000 dashboard queries/day averaging 50MB scanned each (already benefiting from the materialized-view design, not a raw scan):

Storage is 59.5% of the bill, egress 16.9%, ingest 13.5%, query 10.1%. Storage dominates, which tells the stakeholder conversation where to start.

Sensitivity: which knobs actually move the number.

(Trace sampling: assuming traces are 40% of the 1PB raw volume and are sampled down to keeping 10%, raw ingest drops to $1{,}000 - 0.4 \times 1{,}000 \times 0.9 = 640$ TB, which scales storage, ingest, and egress together since all three are proportional to $I$; query cost is held fixed because it depends on materialized-view cardinality, not raw ingest volume.)

The trace-sampling knob moves the most money here because it's the only one that reduces the ingest-side volume driving three of the four buckets at once, not just one storage tier.

Trade-offs & pitfalls

Presenting this to a stakeholder who won't read the architecture diagram: lead with the four-bucket table and the "storage is 60% of the bill" headline, then show the sensitivity table as a menu: "shorten hot retention and you save about $3,067/month but lose the ability to debug anything past 3 days at full resolution; sample traces harder and you save more, about $4,790/month, but rare-event tracing gets less reliable." Frame every knob as a cost-versus-capability trade the business is choosing, not an engineering decision made in isolation.

Common wrong turns: reporting a single blended "$/GB" number across all tiers, which hides that hot storage is over 12x more expensive per byte than cold in this model and makes every optimization conversation vaguer than it needs to be; sizing the model off total data stored ever, rather than steady-state storage per tier (a tier's storage is bounded by its own retention window, not by cumulative ingest since the platform launched); and treating cross-cloud portability as free optionality when discussing a "buy versus build" version of this trade-off: egress pricing and archive-tier retrieval fees differ enough between providers that a cost model built on one provider's numbers doesn't transfer without re-deriving the tier costs.

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.

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.

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.

High-level approach

• Mirror a subset of production traffic to ephemeral capture targets, apply eBPF-based filtering + sampling at the host/kernel level to limit volume, save pcap snippets to short-lived encrypted storage, and automate capture start/stop on anomaly detection. Use cloud-native monitoring to trigger capture workflows and serverless functions to manage lifecycle and purge.

Architecture & components

• Traffic mirroring: AWS VPC Traffic Mirroring (or GCP Packet Mirroring) to send traffic from ENIs to capture fleet.
• Ephemeral capture targets: Autoscaled capture EC2/GKE DaemonSet nodes with instance role, small local NVMe for fast writes.
• eBPF filtering & sampling: libbpf/bcc program or Cilium Hubble that attaches to XDP/tc to apply BPF filters + systematic sampling (e.g., 1:1000) before writing.
• Capture agent: tcpdump or libpcap-based writer producing rotated pcaps (e.g., 10s / 100MB).
• Storage: short-lived S3 bucket with SSE-KMS; lifecycle rules + object lock disabled for quick purge.
• Automation & triggers: CloudWatch/Prometheus -> Alertmanager -> Lambda/Cloud Function or Step Function to start capture, and another to stop and archive metadata.
• Orchestration: SSM / Kubernetes API to scale capture pods, and signed pre-signed S3 URLs for upload.

eBPF filter + sampling example

• BPF pseudo-config: match src/dst/subnet, port, and sample 1/N (hash packet fields mod N).
• tcpdump capture command on capture node:

# capture with BPF filter (example) and rotate files every 10MB
tcpdump -i eth0 -s 0 -w /tmp/capture-%Y%m%d%H%M%S.pcap -C 10 'tcp and (host 10.0.1.0/24 or host 10.0.2.0/24) and port 80'

• Prefer eBPF program to pre-drop unsampled packets; sample via 64-bit hash:

// (pseudocode) if (hash(src, dst, sport, dport, seq) % N != 0) return DROP;

Automation lifecycle

1. Detection: CloudWatch metric anomaly / high p99 latency triggers Alarm -> SNS -> Lambda.
2. Start: Lambda invokes SSM RunCommand or scales capture ASG / K8s DaemonSet with capture flag + applies BPF program and sampling config.
3. Capture window: Agents rotate pcaps to local fast disk and stream periodically to S3 via multipart upload; metadata written to DynamoDB with capture-id, start/stop, filter.
4. Stop: scheduled Lambda stops captures after timeout or on manual stop; agents flush and upload remaining files.
5. Purge/archive: Lifecycle rules move to Glacier (if needed) or delete after retention; Lambda can enforce immediate purge on policy violation.

Security

• Least-privilege IAM roles for capture nodes; KMS CMK for S3 SSE; VPC endpoints for S3 so traffic never leaves VPC.
• Access control: grant devs access via temporary STS tokens and pre-signed URLs limited by time and IP.
• Audit: CloudTrail logs for start/stop operations and KMS decrypt events; object tagging for provenance.
• Data minimization: apply BPF to remove payload or mask sensitive fields before storing; redact PII in post-processing pipeline.

Cost & performance trade-offs

• Sampling ratio + BPF pre-filtering minimize storage and CPU; mirror only needed ENIs; ephemeral nodes sized for burst writes to NVMe to avoid impacting production.
• Use short capture windows (e.g., 30–120s) and automated retention policies to bound cost.

Operational notes / safeguards

• Test filters in staging; include dry-run mode to estimate capture volume.
• Canary alarms to avoid runaway captures; quota checks before creating captures.
• Provide a one-click retrieval playbook: capture-id -> Lambda returns pre-signed URLs + metadata.

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.