Senior Cloud Engineer Interview Preparation Guide - DoorDash

Overview (context as Cloud Engineer)
In cloud-native microservices each service owns its datastore; cross-service transactions require patterns that trade consistency, availability, and operational complexity. I'll describe 2PC, Saga Orchestration, and Saga Choreography with failure modes, guarantees, ops cost, idempotency and compensation.

Two-Phase Commit (2PC)

• Description: Coordinator asks participants to PREPARE, then COMMIT/ROLLBACK.
• Consistency: Strong (atomic across services) if all support XA/transactional commit.
• Failure modes: Coordinator crash blocks participants in PREPARED state; network partitions cause long locks; resource deadlocks.
• Operational complexity: High — requires DBs or middleware supporting distributed transactions, firewall/latency tuning, monitoring for blocked prepares.
• Idempotency/Compensation: Less emphasis on compensations; must implement idempotent commit/rollback RPCs and recovery daemon to resolve uncertain transactions.

Saga — Orchestration

• Description: Central orchestrator issues forward steps; on failure invokes compensating actions in reverse order.
• Consistency: Eventually consistent; business-level atomicity via compensations.
• Failure modes: Orchestrator crash (replay on restart), partial failures in compensation, long-running sagas leading to resource constraints.
• Operational complexity: Medium — implement orchestration service, durable saga state (e.g., DynamoDB, Cloud SQL), retries, dead-letter handling.
• Idempotency/Compensation: Every step and compensating action must be idempotent; use unique saga IDs, causal versioning, and at-least-once delivery with dedup tables.

Saga — Choreography

• Description: Services publish events; subscribers react and emit subsequent events; compensations published on failure.
• Consistency: Eventually consistent; higher coupling via event contracts.
• Failure modes: Missing or out-of-order events, silent failures causing orphaned state, complex failure reasoning across many services.
• Operational complexity: Higher operational visibility needs — event broker (Kafka/SNS+SQS), schema registry, observability, tracing.
• Idempotency/Compensation: Strong requirement for idempotent consumers, deduplication using event IDs, compensating events must be causal and reversible; implement saga correlation IDs and TTLs.

Practical cloud recommendations

• Prefer sagas (orchestration if business workflow centralizes, choreography for decoupling) for cloud-native systems.
• Use durable state stores (DynamoDB, Cloud SQL) for saga state, managed pub/sub (SNS/SQS, EventBridge, Pub/Sub, Kafka) for choreography.
• Implement observability: distributed tracing, saga timelines, replayable logs.
• Always design idempotent APIs, unique saga IDs, durable retry policies, and well-defined compensating actions.

Definitions

Backpressure is a downstream system signaling upstream, explicitly or implicitly, to slow down because it can't keep up. Throttling is proactively capping the rate of requests a system will accept, regardless of whether downstream has said anything. They're related tools for the same problem: protecting a service from being overwhelmed.

Comparing the four techniques

Client-side rate limiting. The client enforces its own cap (e.g., a token bucket that only allows so many requests per second). Cheap and simple, but only works if the client cooperates; it does nothing against a misbehaving or malicious client, so it's a courtesy mechanism, not a real defense.

Server-side throttling with HTTP 429. The server enforces a rate limit (commonly a token bucket or a leaky bucket (which drains requests at a fixed, steady rate, so anything beyond that overflows) per API key or IP) and rejects excess requests immediately with a 429 status and a Retry-After header. This protects the server unconditionally, the client can't opt out, but it only works well if clients actually implement backoff on 429; a client that retries immediately in a loop just keeps hammering the server.

Bounded queueing. Instead of rejecting immediately, admit requests into a fixed-size queue and process them in order. This smooths short bursts (a spike gets absorbed instead of instantly rejected) but the queue MUST be bounded: an unbounded queue under sustained overload grows without limit, and by Little's Law, growing queue length means growing wait time for everyone in it, plus real risk of running out of memory.

Graceful degradation (load shedding). Under overload, deliberately drop or downgrade lower-priority work first, serve a cached/stale response, skip an optional personalization step, to protect the core functionality for everyone else. This requires classifying requests by priority ahead of time; you can't shed intelligently if everything looks the same to the system.

Worked example: why an unbounded queue fails

where $\lambda$ is the arrival rate, $W$ is the average time a request spends in the system, and $L$ is the average number of requests in the system at once.

The intuition: a queue can smooth a burst, but it cannot absorb a sustained rate that exceeds your processing capacity, it can only delay the point at which that becomes visible, while making it worse when it does.

Synchronous APIs vs. asynchronous processing

Synchronous, user-facing APIs: a client is actively waiting on the connection. A deep queue here just converts "fast error" into "slow success or eventual error", bad for perceived latency either way. Prefer a small bounded queue plus fast 429 rejection when it's full, combined with graceful degradation (serve a cheaper/cached response) rather than making the user wait behind a long line.

Asynchronous processing (queue consumers, background jobs): nobody is blocked in real time, so a deeper bounded queue plus consumer-side rate limiting is not just acceptable, it's the natural fit; workers catch up when capacity returns, and genuine failures go to a dead-letter queue (a separate holding queue for messages that repeatedly fail to process, so they aren't silently lost) rather than being shed. Backpressure here can also propagate upstream cleanly (the producer slows down when the queue nears its bound) without a user ever noticing.

Direct answer

Ransomware forces continuity decisions before anyone has full information, so the plan has to give explicit authority to declare and communicate under uncertainty rather than waiting for forensics to finish. Declaration happens as soon as the trigger conditions are met, not once damage is fully understood; early communication says clearly what's known, what isn't, and when the next update comes, without speculating on cause or scope; and recovery sequencing is decided service by service against the criticality tiers, weighing restore speed against the real risk of reintroducing a still-compromised backup.

Who declares, and when

This follows the same declaration-authority structure as any other event: a named succession with pre-defined trigger conditions. Declaring is a formal, logged governance act, distinct from an engineer opening a SEV1 page: paging on-call gets people looking at the problem, while declaring activates the continuity plan itself, mobilizing the response team, authorizing emergency spend, and starting the plan's communication sequencing. The wrinkle specific to ransomware is that the trigger condition can't require knowing the full scope first, because that knowledge can take days. A workable trigger is "any Tier 1 or Tier 2 service confirmed encrypted or inaccessible due to suspected malicious activity," declared immediately and explicitly scoped as provisional, pending forensic confirmation, rather than held back until certainty arrives.

Communicating under genuine uncertainty

The discipline is separating what's confirmed from what's suspected, and saying so explicitly rather than overstating confidence or going silent until everything is known.

• Internally: which systems are confirmed affected, what's under investigation, and an honest ETA for the next update, not a resolution time nobody can promise.
• Externally and to regulators or legal, where applicable: factual, reviewed statements limited to what's actually known, because a premature claim about scope or root cause can create exposure that outlives the incident itself.

This is a communications-cadence problem before it's a technical one; it uses the same discipline as any crisis communication plan, just under a harder information constraint.

Recovery sequencing: restore, rebuild, or wait

This is a decision made per service, not once for the whole estate, driven by three inputs: the service's criticality tier (how much delay is tolerable), whether a backup for that service can be verified clean before it goes back into production, and whether forensics needs the current state preserved before anything is touched.

• Tier 1 services with a verified-clean backup restore first.
• Anything where backup integrity can't yet be confirmed waits, even if that extends the outage on an important service, because reintroducing compromised data or a re-infection vector turns one event into a second one.
• Rebuilding from a known-good baseline, rather than restoring a possibly-tainted image, is the fallback where clean-backup confidence can't be established in an acceptable window.

This sequencing decision belongs to the same governance structure that owns declaration and tiering, not to whichever team finishes their piece first, because it's a risk trade-off between speed and re-infection, not a technical task order.

Safeguards that need to already exist

None of the sequencing decision above is possible unless backups have integrity that ransomware itself can't reach. In practice that means an offline or logically isolated (air-gapped) copy that an attacker with production access can't also encrypt or delete, immutability or write-once retention on at least one recent backup generation so it can't be silently altered, and a routine of actually testing restores, not just confirming a backup job completed, so "verified clean" is a real, exercised capability during the event rather than a hope. Without these in place beforehand, the restore-versus-rebuild-versus-wait decision collapses to "wait," because there's no way to trust any backup's integrity.

Worked example

A mid-size logistics company detects encrypted files on its warehouse-management and billing systems overnight. The on-call commander declares a provisional continuity event within the hour, under the "confirmed encryption of a Tier 1 service" trigger, without waiting to know if data was exfiltrated. Internal communication at hour one reads: "Warehouse-management and billing confirmed encrypted; scope of other systems still under investigation; next update in 2 hours." Because the backup program maintains an air-gapped nightly copy that predates the infection and its integrity has been tested in prior quarterly exercises, billing (Tier 1, clean backup available) is prioritized for restore first. Warehouse-management's most recent backup can't yet be confirmed clean, so that system is rebuilt from a hardened baseline image instead of restored, extending its outage but avoiding the risk of reintroducing the compromise, a trade-off the commander makes explicitly and logs, rather than leaving it to whichever team is ready first.

Trade-offs and pitfalls

• Waiting for full forensic certainty before declaring or communicating anything feels safer but usually makes things worse: silence gets filled with speculation internally and, if it leaks, externally.
• Restoring quickly from an unverified backup to hit a recovery-time target can cause a second, worse event than the original outage. Speed has to be weighed against verified integrity, not assumed.
• Treating "wait for forensics" as the default for every system ignores the tiering work entirely; some services genuinely can't wait, which is exactly why the criticality tiers exist, to force that trade-off deliberately rather than applying one rule everywhere.
• Backup safeguards, air-gapping, immutability, tested restores, are cheap relative to discovering during a live event that every backup is also encrypted. This is a case where the pre-event investment directly determines whether the sequencing decision has good options at all.

Turning an SLO-breach signal into infrastructure means wiring a CloudWatch alarm on the metric your application already emits to an SNS topic that fans out to whoever needs to act.

Structured elaboration

The alarm needs a comparison operator, an evaluation period count, and a period length that together express "exceeds 0.5% for 5 consecutive minutes" (5 evaluation periods of 60 seconds each, all breaching); treat_missing_data needs an explicit choice (here, notBreaching, so a gap in metric publication does not itself trigger a false alarm, though a stricter policy might prefer breaching for a safety-critical metric, trading false alarms for never missing a real gap). The SNS topic is a separate resource so the alarm and its notification fan-out can be composed independently (e.g., reusing the same topic across several alarms).

Worked example (validated with terraform validate against a real Terraform install, AWS provider ~> 5.0)

resource "aws_sns_topic" "slo_breach_alerts" {
  name = "slo-breach-alerts"
}

resource "aws_cloudwatch_metric_alarm" "api_error_rate_high" {
  alarm_name          = "api-error-rate-high"
  comparison_operator = "GreaterThanThreshold"
  evaluation_periods  = 5
  metric_name         = "api_error_rate"
  namespace           = "Custom/API"
  period              = 60
  statistic           = "Average"
  threshold           = 0.5
  alarm_description   = "Fires when api_error_rate exceeds 0.5% for 5 consecutive 1-minute periods"
  treat_missing_data  = "notBreaching"
  alarm_actions       = [aws_sns_topic.slo_breach_alerts.arn]
}

This configuration passed terraform init and terraform validate cleanly (correct resource schema for both aws_cloudwatch_metric_alarm and aws_sns_topic, and a correctly-formed reference from the alarm's alarm_actions to the topic's ARN).

Trade-offs and pitfalls

The IAM side is easy to forget: CloudWatch needs no special role to publish to SNS when the alarm references the topic directly via alarm_actions (this is a managed, AWS-internal integration), but any SUBSCRIBER of the topic (a Lambda, an HTTP endpoint, a chat-ops integration) needs its own permission to receive from SNS, and that subscription is a separate resource entirely. A custom metric like api_error_rate must actually be published by the application (via the CloudWatch PutMetricData API or an agent); this Terraform only wires the ALARM, not the metric's ingestion, so verify the metric is actually flowing before trusting the alarm.

Direct answer

The criteria that matter are the same whether the trigger is a client asking for a feature, a cost overrun you stumbled onto mid-quarter, or a proposal to cut capacity: put a dollar figure on both sides of the trade (the cost delta and the expected business value or risk avoided), find whoever actually owns the budget being spent and get them in the room instead of just your manager or the requester, and write the reasoning down so the decision can be defended later if someone questions it. The story below is a concrete instance of that pattern.

Structured elaboration

A senior answer to this question is really describing a repeatable decision process, not a one-off negotiation:

1. Quantify both sides in the same unit. Convert the cost delta and the expected upside (revenue, retention, an SLA (service-level agreement) risk avoided, a deadline hit) into dollars wherever possible, even roughly. A trade-off argued as "fast but expensive" versus "slow but cheap" is unresolvable; one argued as "$18k/month for a projected $25k/month in incremental revenue" has a payback period you can debate.
2. Time-box the decision and note reversibility. Is this a one-way door (a schema change, a customer commitment) or something you can walk back next sprint? Reversible decisions can be made faster and revisited; irreversible ones deserve the full stakeholder loop up front.
3. Find the actual budget owner, not just the requester. The person asking for the feature (a product manager, a client-facing lead) usually isn't the person whose budget absorbs the cost. Pulling in finance or whoever owns the line item is what makes the eventual decision defensible instead of just "the loudest voice won."
4. Write a short decision memo. State the options considered, the numbers behind each, and which one was chosen and why. This is the artifact you point back to later, whether that's a performance review, a postmortem, or someone in leadership asking "why did we spend $8k more that month."
5. Instrument the outcome. Put monitoring or a review checkpoint on the decision so you find out if the assumptions were wrong, rather than discovering it a quarter later.

This holds across the variants interviewers tend to ask: a client-facing escalation just changes who's applying pressure and adds a contractual angle to weigh; discovering an overrun after the fact means you're doing steps 1 and 4 retroactively to decide whether to unwind it; a proposal to remove capacity to save money is the same trade-off with the sign flipped, the "feature" being protected is reliability or headroom rather than a new capability.

Worked example

Situation: A product team wanted three new real-time widgets added to a premium analytics dashboard to boost activation. Enabling them at current infrastructure would add roughly $18k/month in compute cost and about three weeks of engineering work.

Task: As the engineer who owned the dashboard backend, I needed to decide between shipping full real-time functionality on schedule or proposing a cost-constrained alternative, and to make that call in a way I could defend afterward.

Action: I built a short memo comparing two options: (A) full real-time rollout, three weeks, +$18k/month ongoing; (B) staggered rollout, ship one real-time widget immediately and batch the other two, same three-week timeline but only +$8k/month initially, with an additional week of follow-up work to add batching that would bring the run-rate down further. I estimated the upside using an existing A/B prototype: full rollout was projected to lift premium activation and retention enough to be worth roughly $25k/month, which made option A defensible on paper, but the team wanted more cost certainty before committing to that run-rate permanently. I brought the memo to the product manager, finance, and our DevOps lead, and we discussed the payback period and the operational risk of running three real-time streams at once.

Result: We chose option B. The team shipped on schedule with a smaller initial cost increase, then implemented batching the following sprint to bring the ongoing cost down further. I added per-widget cost tags and a cost dashboard so finance could see the run-rate without asking, plus an alert if spend moved meaningfully above the agreed baseline, so the next version of this conversation would start from data instead of memory.

Trade-offs and pitfalls

• Conceding without quantifying feels collaborative but sets a bad precedent. If you agree to absorb a cost increase without writing down the number and the reasoning, the next request has no reference point and the team relitigates from zero every time.
• Optimizing for cost alone ships a worse product than necessary. The point of quantifying both sides is to find the cheapest option that still delivers most of the value, not to default to the cheapest option period.
• Skipping the actual budget owner is the most common mistake. A decision made only between engineering and the requesting product manager can get overturned later when someone with financial authority sees the bill and wasn't consulted.
• Treating each trade-off as a one-time negotiation instead of setting a threshold or policy means the same conversation repeats every time a similar request comes in, instead of the team having a standing rule (for example, a cost-increase approval threshold) to fall back on.

What I'd want to know first

Before I put a number on anything, I'd pull four things: the traffic profile (is it steady, bursty, or spiky through the day), the read/write mix (reads and writes scale very differently), the resource cost per request (how much CPU, memory, and database load one typical request consumes), and the existing SLA (service level agreement) or error budget (how much latency and error headroom I'm actually allowed to spend). Skipping this step and jumping straight to "just double everything" is the most common mistake, because growth is rarely uniform across every resource.

Headroom calculation

Say the service peaks at 3,000 requests per second (RPS) today, running on 20 instances. Load testing shows each instance holds a safe ceiling of about 175 RPS before p99 latency (the 99th percentile response time, the slowest 1 in 100 requests) starts climbing. That puts the fleet's tested ceiling at 20 x 175 = 3,500 RPS, so today's headroom is about 500 RPS, roughly 14% of the tested ceiling (500 of 3,500 RPS still unused).

If traffic doubles in 6 months, peak becomes 6,000 RPS. I'd size for that peak plus a buffer for forecast error, say 20%, giving a target ceiling of 7,200 RPS. At 175 RPS per instance that's 7,200 / 175 = about 42 instances, roughly doubling the fleet plus a bit more because the buffer also grows.

Scaling strategy

For a stateless web tier fronting a database, horizontal scaling (adding more instances of the same size) is usually the right default: no single-instance ceiling to hit, and it's cheaper to add commodity capacity than to keep buying bigger boxes. But I'd check the database write path separately, since it often becomes the actual constraint before the web tier does. If the database is the binding resource, the plan has to include read replicas, connection pooling limits, or a write-path change, not just more web servers.

What I'd benchmark

• A steady-state load test at the projected 6,000 RPS peak with the real production read/write mix, not a synthetic uniform load.
• A soak test (sustained load over hours) to catch memory leaks and connection pool exhaustion that only show up over time.
• A burst test that ramps quickly to the new ceiling, since sustained-load tests can hide how the system behaves under a sudden spike.

Cost versus performance

If each instance costs roughly $140/month, the fleet grows from $2,800/month to about $5,880/month, a cost increase of around 110% to support a 100% traffic increase, which is close to linear and reasonable. If the math came out sharply super-linear (say 300% cost for 100% traffic), that would push me to look at right-sizing the instance type or fixing an inefficiency instead of just buying more of the same box.

Direct answer

Decide by diagnosing which constraint is actually binding right now: if it's a visibility or credibility gap, take the shippable path since it buys proof and goodwill; if it's a capability gap that will bottleneck everything after, invest the depth even though it won't show for a while. When genuinely unsure, default toward shipping, since visible momentum is what buys you the room to go deep later.

Structured elaboration

• Diagnose the binding constraint first. Ask directly: do people doubt I can do the harder thing (a visibility problem, solved by shipping), or can I genuinely not yet do it reliably (a capability problem, solved by depth)?
• Weigh the time horizon of the payoff. Depth work compounds, the skill gets reused across many future situations; shipping is mostly a point-in-time signal. The earlier you are in a role or level, the more depth tends to be worth relative to a single visible win.
• Look for a hybrid slice. Can part of the deep work be carved into something small enough to ship and visible enough to protect the time for the rest? This is often available and often missed.
• The same logic applies over a longer horizon. A lateral move offering real ownership but far less visibility is this same trade-off stretched over months instead of a single decision: the test is whether that ownership will eventually surface as something demonstrable, or whether it's ownership of something structurally invisible with no path to ever becoming visible.

Worked example

I was mid-way through work on a system that badly needed a deeper rewrite, work that wouldn't show results for a couple of months, right when a lower-effort, more visible feature request landed that would help my case going into a review cycle. I asked which was actually the binding constraint: I already had credibility for shipping, what I was missing was proof I could handle harder technical problems, so instead of choosing one or the other outright, I carved out the piece of the deep rewrite causing the most visible pain, framed it publicly as phase one of the larger effort, and used the resulting goodwill to protect time for the rest. The same question came up later at a larger scale, when I considered a lateral move into a role with far more ownership but almost no visibility; I only took it once I'd confirmed the ownership would eventually surface as something demonstrable, rather than staying invisible indefinitely.

Trade-offs & pitfalls

• Always choosing visibility produces a track record that looks credible but is shallow exactly when the next level starts expecting real depth.
• Always choosing depth risks being read as someone who goes quiet and doesn't ship, even when the eventual work is excellent.
• A hybrid slice isn't always available, and pretending there's always a clever middle path is itself a tell that you're avoiding an honest either/or call.
• For the lateral-move version specifically, the trap is accepting invisible ownership indefinitely on the promise it will "pay off eventually," with no concrete idea of how or when it becomes visible.

Direct answer

A credible estimate for a bounded piece of owned technical work is never a single number. It is a range built from a real decomposition of the work, with the assumptions and risk factors named out loud rather than folded silently into padding. Strong candidates separate "the work I can size confidently" from "the unknowns that could blow this up" and present both.

Structured elaboration

1. Define done first. Before sizing anything, pin down what "done" actually means (what gets tested, what gets deployed, who signs off). An estimate against a fuzzy definition of done is not an estimate, it is a guess.
2. Decompose into small stages. Break the work into pieces small enough that each one is individually estimable (roughly a day to a few days each), not one lump. Small stages make errors easier to catch and let you re-forecast partway through instead of waiting until the end to discover you were wrong.
3. Name your assumptions explicitly. Write down what you are assuming about scope, existing tooling, data availability, and team support. These assumptions are exactly what turns out to be wrong later, so writing them down is what lets you catch it early.
4. Identify the risk factors that could blow up the estimate, separately from the baseline work itself: unfamiliar technology, an external dependency you do not control, environment or data-access delays, and any stage that depends on something you have not verified yet. The biggest risk to a technical estimate is almost always one of these, not the raw coding effort.
5. Estimate each stage as a range (an optimistic case if nothing goes wrong, and a likely case), then add contingency sized to the risk factors you named, rather than a flat percentage applied blindly everywhere.
6. Present timeline, resourcing, and confidence as one package: the stage breakdown, the range with a stated confidence level, the top two or three named risks that could move the number, and the checkpoint at which you will re-confirm the estimate once the biggest unknown is retired.

Worked example

Take automating a regression suite. Decomposition: audit the existing manual suite and select which cases to automate (2 days), extend the automation framework (3 days), author automated tests for 30 selected cases at roughly half a day each (15 days), stabilize flaky tests and wire into CI (continuous integration, the automated pipeline that runs tests on every code change) (3 days). Baseline sum: 2 + 3 + 15 + 3 = 23 days.

The two named risk factors: the automation framework may need real rework if the underlying application's UI changes mid-project, and test-environment access could be delayed. Contingency for those two risks adds roughly 3 days, giving a likely estimate of 26 days. Optimistic case (framework needs no rework, stabilization goes smoothly): 21 days. Pessimistic case (environment access is delayed by a full week): 26 + 5 = 31 days.

What I would present to stakeholders: "roughly 5 to 6 weeks (about 26 working days) at medium confidence, with a realistic range of 21 to 31 days depending on two named risks: framework rework and environment access. I will check back in at day 10, once the framework and audit stages are done, and re-confirm or revise the range."

The same shape applies just as directly to a reporting-dashboard build for a Business Intelligence or Data Analyst: decomposition might run source-data validation (2 days), query and metric-definition build (4 days), visual build and stakeholder review cycles (5 days), and a final accuracy reconciliation against a known source of truth (2 days), for a baseline of 13 days. The named risk factors shift to data-quality gaps discovered during reconciliation and a slow stakeholder review turnaround, rather than framework rework, but the same discipline holds: present a range with a stated confidence level, name the top risks, and set a checkpoint (for example, after the query and metric-definition stage) to re-confirm the estimate rather than wait until the deadline.

Trade-offs and pitfalls

Padding the number silently instead of naming the actual risk teaches stakeholders nothing about what to watch. Giving a single point estimate as if it were a fact invites a commitment you cannot actually make good on. Not re-forecasting at a natural checkpoint means the first time anyone learns the estimate was wrong is at the deadline. And anchoring the estimate to the requester's preferred date, then reverse-engineering a plan to fit it, is the fastest way to lose credibility the next time you estimate anything.

High-level approach
Create a central network-services account that owns a Transit Gateway (TGW), shared-services VPC (DNS, monitoring, SSM endpoints), an egress inspection VPC (NGFW or inline AWS Network Firewall + NAT), and central logging. Staging and Prod each have their own VPCs and AWS accounts attached to the TGW with segmented route tables to enforce isolation.

Components

• Transit Gateway in network-services for hub-and-spoke connectivity.
• TGW route tables: separate tables for Prod, Staging, and Shared services.
• VPC attachments: one per environment/account (TGW attachments).
• AWS RAM to share TGW route table associations or resource attachments where necessary.
• Egress inspection VPC with an NGFW (3rd-party or AWS Network Firewall) + NAT Gateway for internet access.
• Shared-services VPC hosting Route 53 Resolver endpoints (inbound/outbound), Prometheus/CloudWatch endpoints, and SSM endpoints.
• VPC endpoints (Gateway/Interface) for S3, KMS, CloudWatch to avoid internet egress.
• Flow Logs, VPC Traffic Mirroring (if deeper inspection needed), centralized S3/CloudWatch Logs.

Traffic flow

• Intra-account app traffic: VPC -> TGW -> VPC (route tables restrict cross-environment).
• Shared services access: app VPCs route DNS/monitoring traffic to shared-services via TGW table shared with all attachments.
• Egress: app VPCs route 0.0.0.0/0 to the egress route table in TGW, which forwards to the egress inspection VPC where firewall/NAT performs inspection, logging, and then to IGW.
• Management/SSM: use VPC endpoints plus IAM roles for cross-account access; no direct internet required.

Security & least privilege

• Enforce environment isolation via TGW route table separation; only allow explicit routes between Staging and Prod if required (recommend none).
• Security groups and NACLs per environment; firewall policies for egress control.
• Use AWS RAM to share TGW attachments/resources with fine-grained principals (organization units).
• Cross-account IAM roles with least-privilege for operations (no broad account-wide access).
• Centralize logging (CloudWatch/S3) with KMS keys and bucket policies allowing write-only from source accounts.

Onboarding new accounts

• Automate with IaC (CloudFormation/Terraform): create VPC, TGW attachment, route table association via RAM share, required endpoints, security baseline.
• Provide a bootstrap pipeline that requests TGW attachment and is approved via an Ops ticket/automation.

Trade-offs & justification

• TGW hub-and-spoke (chosen): scales well, centralizes egress/inspection, simpler route management for many accounts. Slightly higher cost than VPC peering but avoids N^2 connectivity.
• VPC Peering: cheaper for 2–3 VPCs but doesn’t support transitive routing or central egress easily—poor fit for multi-account scale.
• Single NGFW in egress VPC: centralizes inspection and logging but is a single control plane—mitigate with HA pairs across AZs and multiple inspection endpoints per region.
• AWS Network Firewall vs 3rd-party: AWS Firewall reduces management overhead and integrates with Flow Logs; 3rd-party may offer richer DPI features if required.

This topology meets isolation, centralized inspection/logging, shared services, least-privilege cross-account access, and automatable onboarding.

Direct answer

Before committing to a plan, spend the first days mapping every team your work actually depends on, get an explicit, dated commitment from each one on what they will deliver, and track those commitments in one visible place so a slip surfaces the moment it happens instead of at the deadline.

Structured elaboration

Map the dependency graph early, not incidentally

Run a short cross-functional session at kickoff specifically to list what you need from other teams: what, by when, and in what form. Treat this as a deliverable of the kickoff, not a side conversation that happens if someone remembers to ask.

Get commitments, not assumptions

"They know we need this" is not a commitment. A commitment has an owner, a date, and an explicit acceptance criterion, meaning what "done" looks like from your side, not just theirs. Ambiguous handoffs are where dependencies quietly slip.

Make status visible continuously, not just at standups

A shared dependency tracker, checked weekly at minimum, with a clear ready, at risk, or blocked status per item, turns a hidden slip into a visible one while there is still time to react.

If you are joining an initiative already in motion

The mapping happens differently. Your first days are spent finding out who currently owns each piece, which may not match the org chart or what the original plan assumed, and estimating the time-to-impact for each dependency, meaning how long before a slip there would actually hit your own critical path (the specific chain of dependent tasks whose delay would directly delay your own delivery date, unlike a dependency that has slack to spare), before you commit to a timeline of your own. Committing to a date before doing this is committing to someone else's assumptions.

Worked example

A project depends on three other teams: one providing a new data feed, one exposing an API endpoint, and one delivering a design system component. At kickoff, the team runs a short dependency-mapping session and gets each provider to commit to a specific date and a specific definition of ready, for the API that means a documented contract and a staging environment, not just "the code exists." These commitments go into a shared tracker with a status column, reviewed weekly.

In week two, the API team's status moves to at risk because their own upstream dependency slipped. Because the tracker surfaced this immediately rather than at the original deadline, there is still time to either help unblock the API team or replan the timeline around a slower path, instead of discovering the problem in the final week when no good options remain.

For the joining-in-progress case: an engineer joins a multi-team initiative already underway. In the first few days, instead of accepting the existing plan at face value, they interview each team named in the plan to confirm who currently owns each dependency, since ownership has quietly shifted since the plan was written, and estimate the time-to-impact of each one: the API dependency would only hurt the timeline if it slipped more than two weeks, while the data-feed dependency has almost no buffer at all. Only after that mapping do they commit to a delivery date of their own, rather than inheriting the original plan's assumptions unchecked.

Trade-offs and pitfalls

A heavy dependency-tracking process on a small, low-risk project wastes more time than it saves; scale the rigor to the size and risk of the dependency rather than applying it uniformly everywhere.

The most common failure is treating the mapping as a one-time kickoff exercise instead of a living tracker. A dependency list that is accurate on day one and never updated again is exactly as useless as never having made one, because the whole point is catching drift as it happens.