FAANG-Standard Interview Preparation Guide: Cloud Architect (Mid-Level)

Direct answer

Don't optimize the layer that looks slow, instrument the request path end to end first. Get a latency budget broken into per-hop numbers (network, serialization, database, business logic) that actually sum to the 200 ms observed, then attack the hop with the best ratio of milliseconds saved to effort required, re-measuring after every change rather than assuming which layer is guilty before the data says so.

Structured elaboration

Method, in order:

1. Baseline with distributed tracing across the full request path, capturing per-hop timing, not just a total.
2. Form one hypothesis per layer (network/TLS overhead, serialization cost, database query time, business logic compute) and check it against the trace data rather than intuition.
3. Rank candidate fixes by (milliseconds likely saved) divided by (implementation effort and risk), not by which one is technically most interesting.
4. Ship the highest-ranked fix, re-measure the full trace, and repeat, because fixing the biggest hop changes which hop is now biggest.

Isolation checks, when tracing alone doesn't localize it: compare with keep-alive/connection pooling on versus off to isolate network/TLS overhead, compare payload size before and after trimming to isolate serialization cost, and compare with and without a query cache or added index to isolate the database's contribution.

Worked example

Assume tracing on the current 200 ms path yields this breakdown (illustrative numbers, chosen to sum to the measured total):

Reproducing the arithmetic: current total $40+15+100+45=200\text{ms}$, matching the measured baseline. Target total $10+5+25+10=50\text{ms}$, matching the 50 ms goal, and the sum of savings $30+10+75+35=150\text{ms}$ accounts for exactly the gap ($200-50=150$). The database hop is the largest single lever (75 ms, half the total savings) and gets prioritized first for that reason, not because it's assumed to be the culprit before measuring.

Trade-offs & pitfalls

• Jumping straight to rewriting business logic when tracing shows the database is half the budget is solving the wrong problem first, always rank by measured contribution, not by which layer is the most familiar to fix.
• Not re-measuring after each change stacks unverified assumptions, a fix that looked good in isolation can interact badly with the next one.
• Chasing 90% of the theoretical win on the hardest 10% of the effort (a protocol rewrite) before taking the cheap 30 ms keep-alive win first wastes the easiest gains.
• Caching for latency introduces a correctness trade-off (staleness) that needs an explicit owner and time-to-live (TTL), "just add a cache" without that ownership is a common wrong turn.
• Reserve architectural changes (removing a network hop entirely, changing the protocol) for after the low-risk, high-yield fixes are exhausted, they carry more deployment and compatibility risk and should be justified by the remaining gap, not reached for first.

Direct answer: Define waves by combining dependency clustering (applications that must move together stay together) with a risk-graduated sequence: pilot, then progressively larger core waves, with explicit gate criteria between each wave rather than a fixed calendar.

Structured elaboration. Grouping criteria: primary driver is dependency clustering (two apps sharing a database or synchronous API call generally must migrate in the same wave or via a coexistence pattern spanning the gap); secondary driver is similar migration approach (batch apps using the same target-service pattern together, for efficiency of the migration team's tooling and runbooks). Pilot vs core wave sizing: pilot is intentionally small (3-8 low-risk, well-understood applications) purely to validate tooling, runbooks, and rollback mechanics under real conditions; core waves scale up progressively (10, then 20-30 apps per wave) once the pilot proves the process, since early waves are where undiscovered problems in the PROCESS ITSELF (not just individual apps) get found. Risk thresholds: a wave's aggregate risk score (sum or max of its members') gates its size, not just its member count, since one high-risk app effectively caps how many other apps can safely share its cutover window. Rollback windows: each wave gets an explicit rollback decision deadline (e.g., 4 hours post-cutover) beyond which the team commits forward rather than leaving a rollback option open indefinitely, which tends to produce ambiguous half-migrated states. Acceptance criteria: defined per wave before it starts (specific smoke tests, performance thresholds, error-rate ceilings) so "done" isn't a judgment call made under pressure during the cutover window. Operational metrics between waves: performance (latency/error-rate deltas vs. pre-migration baseline), cost (actual vs. estimated), and runbook readiness (did the runbook match what actually happened, or did the team improvise?) all feed into whether the NEXT wave proceeds as planned or gets adjusted.

Worked example. For 200 scored applications: pilot wave of 5 apps (lowest risk, no shared dependencies with anything outside the pilot); wave 2 of 15 apps once pilot's acceptance criteria and rollback windows are validated; waves 3-6 of 30-40 apps each, grouped by dependency cluster and roughly similar risk profile; a final wave of the highest-risk/highest-dependency-count applications, executed last when the team has the most process maturity.

Trade-offs & pitfalls. Grouping purely by "similar technology stack" without checking dependencies is a common mistake: two apps on the same stack but with a synchronous cross-call still need to move together or need an explicit coexistence seam, regardless of how similar their migration mechanics are.

Approach summary
Design an observability + optimization pipeline that measures per-request latency distribution, resource efficiency, and cost, then uses profiling and adaptive batching/autoscaling to meet SLOs at 50k qps.

Instrumentation & metrics

• Request-level: p50/p95/p99 latency, request arrival timestamp, model id, payload size, queue wait time, inference time, end-to-end time.
• Batch-level: batch size distribution, batch latency, batch processing time, queue depth, dropped requests.
• Resource: GPU utilization, GPU memory used/free, GPU SM/PCIe metrics, CPU utilization, RSS/container memory, network I/O, disk I/O.
• Business: throughput (qps), error rate, cost per minute.
• Correlate traces using request-id (distributed tracing).

Profiling techniques

• Microbenchmarks per model: single-shot and batched throughput on target instance types.
• GPU profilers: NVIDIA Nsight Systems/Compute for kernel times, PCIe stalls, memcpy.
• Sys profilers: perf, eBPF traces for CPU-side bottlenecks; container metrics via cAdvisor.
• Periodic A/B trace sampling (1% traffic) to avoid overhead.

Batching strategies

• Dynamic batching (latency-aware): target max batch size but cut off when per-request queue wait > slack.
• Timeout-based batching: small timeout window (e.g., 1–5 ms) to form batches at high qps.
• Auto-adjust batch size per model/instance using feedback loop that monitors p95/p99.
• Hybrid: prioritize low-latency classes (no batching) and best-effort classes (larger batches).

Memory footprint controls

• Limit model resident memory: shard models across nodes, use model eviction LRU with warm-up.
• Use memory pools for CUDA to avoid fragmentation (cuMemPool/CUDA IPC).
• Enforce container OOM/kubepod memory requests/limits and soft limits to prevent thrashing.
• Prefer float16/int8 where acceptable; mixed precision to reduce footprint.

Autoscaling

• Multi-dimensional autoscaler: scale on inbound queue depth, p95 latency, and GPU utilization.
• Warm pools / standby nodes to reduce cold-start latency for large models.
• Scale-down with hysteresis to avoid flapping.

Cost-per-inference calculation

cost_per_inference = (instance_hourly_cost * hours_active + gpu_hourly_cost * hours_active + storage_cost + networking_cost) / total_inferences

Plain: measure total cloud spend for inference tier over period divided by number of inferences.

Trade-offs: larger batches vs latency SLOs

• Larger batches: higher throughput and lower cost-per-inference (better GPU utilization), but increased queue wait → raises p95/p99.
• Smaller batches: lower latency and SLO compliance, but lower GPU efficiency and higher cost.
• Mitigation: adaptive batching, traffic classification, prioritized queues, reserve capacity; choose batch-size target that achieves SLO at required cost curve from profiling.

Operational plan

• Run load tests to map batch size → p99 vs throughput for each model and instance type.
• Encode policies: batch size caps per model class, autoscale thresholds, warm pools.
• Alerting: p95/p99 breach, rising queue depth, sustained high GPU memory pressure.
• Continuous optimization: weekly profiling, spot-instance experiments, mixed-precision rollout with validation.

Definition & purpose

• Quorum selection determines how many nodes must agree for reads/writes in distributed replication to ensure consistency and availability.

Majority quorums

• Requirement: more than half nodes must respond (N/2+1). Guarantees at most one commit leader set and strong consistency.
• Effect: higher write latency across regions because write must wait for majority acknowledgements; better consistency and partition safety.

Configurable read/write quorums (R/W)

• Use parameters R (reads) and W (writes) with N replicas. Consistency when R + W > N.
• Tuning: choose smaller W to reduce write latency (at cost of potential stale reads) or smaller R for faster reads.

Cross-region impacts

• Large quorum spread across regions increases latency (inter-region RTTs) but improves fault tolerance. Placing quorums within a latency-aware subset (region-majority) reduces latency but risks availability during region outages.

Trade-offs (CAP prism)

• Strong consistency (large quorum) reduces availability under partitions. Smaller quorums increase availability and lower latency but can return stale data.

Choose quorum size/location based on workload: critical financial writes prefer majority with low-latency links; read-heavy global services may favor eventual consistency with tuned R/W.

Direct answer

Waiting stops being the right call once the delay is on your critical path (the chain of work that directly determines your deadline) with no updated ETA, or once the cost of continuing to wait (rework, workarounds, compounding risk) is clearly larger than the cost of escalating. Decide the trigger in advance, not in the moment, and escalate by framing it around the shared deadline and offering to help unblock, not by assigning blame, so the relationship survives the conversation.

Structured elaboration

1. Set the trigger before you need it. At the point you first take on a dependency, agree on what "stalled" means and when you'll escalate if there's no movement, for example, "if there's no updated ETA by [date], I'll raise it." Deciding this ahead of time keeps the eventual call from being an emotionally loaded, in-the-moment judgment.
2. Watch for the signals that waiting has become the wrong call, even without a pre-set trigger: no visible progress or updated estimate, the delay has moved onto your own critical path, you're already absorbing compounding cost (rework, a growing workaround), or the nature of their blocker changed without anyone telling you.
3. Escalate at the right altitude, in order. Start with a direct conversation with the owner (not their manager first, which reads as going around them), then their lead if that doesn't move things, then a cross-functional or executive conversation only if the first two steps don't resolve it. Skipping straight to the top burns trust even when you're right to escalate.
4. Frame the escalation around the shared goal. Bring what you've tried and the concrete impact of the delay, and lead with an offer to help (extra hands, a clearer spec, a joint troubleshooting session) rather than a demand for status. This keeps the conversation collaborative instead of adversarial.
5. When the dependency is an external vendor rather than an internal team, the escalation lever is fundamentally different. There's no peer relationship conversation to have in the same sense: the path runs through contract renegotiation (invoking SLA, or service level agreement, terms, escalating through the vendor's account team) and executive/customer communication about timeline impact, because a vendor delay usually has stakeholders beyond your own working team (customers waiting on the date, your own leadership needing to manage expectations upward). The internal escalation ladder in step 3 assumes a peer relationship you can repair with tone and framing; the vendor case assumes a commercial relationship you manage with contract terms and proactive, honest communication about the schedule impact instead.

Worked example

Two weeks into waiting on an internal platform team's API, with no updated ETA since the first week and the launch date now two weeks out, the trigger from step 1 (no ETA update within a week) has already been crossed. The escalation opens with the owner directly: "This is now going to affect our launch date. What's actually blocking it, and is there anything I can do to help, pair on it, provide test data, take a piece of the work?" Only if that doesn't produce movement within a short, stated window does it go to their lead, framed the same way: shared deadline, concrete impact, an offer to help.

If instead the dependency were owned by an external vendor who'd gone quiet for two weeks on a contracted deliverable, the move isn't a peer conversation with an individual, it's raising the delay through the account relationship against the SLA in the contract, while separately and proactively telling internal leadership (and, if relevant, the customer waiting on the date) what the timeline impact now looks like, rather than continuing to absorb the delay silently and hoping the vendor resolves it before anyone notices.

Trade-offs & pitfalls

• Pitfall: escalating without a pre-agreed trigger, so the decision looks reactive or, worse, personal, when it happens.
• Pitfall: skipping escalation levels internally (going straight to a director) when a direct conversation with the owner hadn't been tried yet, damaging a relationship you'll need again.
• Pitfall: treating a vendor delay like an internal one, i.e., waiting patiently and being "collaborative" with a counterparty who has no equivalent incentive to preserve the relationship the way an internal peer does.
• Senior differentiator: pre-negotiating the escalation threshold when the dependency is first created, not two weeks into silence, and recognizing early which kind of dependency (peer relationship vs. commercial contract) you're actually managing, since that changes which lever you reach for.

A safe restart uses kubectl rollout restart, which recreates pods through the normal RollingUpdate strategy rather than deleting them directly, so the same availability guarantees that protect a routine deployment protect the restart too.

Commands

Trigger and watch a rolling restart:

kubectl rollout restart deployment my-app -n prod
kubectl rollout status deployment my-app -n prod --watch

View rollout history and inspect a specific revision:

kubectl rollout history deployment my-app -n prod
kubectl rollout history deployment my-app -n prod --revision=3

Roll back:

kubectl rollout undo deployment my-app -n prod --to-revision=3
kubectl rollout status deployment my-app -n prod

Ship an image change with a recorded reason (the --record flag some older references use for this is deprecated; annotate explicitly instead):

kubectl set image deployment/my-app my-app=registry/app:1.2.3 -n prod
kubectl annotate deployment my-app kubernetes.io/change-cause="bump to 1.2.3, ticket OPS-441" --overwrite -n prod

What keeps a restart from becoming a cascading failure

• RollingUpdate parameters: maxUnavailable and maxSurge (both default to 25% of desired replicas) bound how many old pods can be down and how many extra new pods can exist at once. For a consumer-facing service, a conservative setting (for example maxUnavailable: 0, maxSurge: 1) never drops capacity below the current replica count during the restart, at the cost of briefly running more pods than the steady-state count.
• Readiness probes: a Service only sends traffic to pods that pass their readiness probe, so a newly restarted pod that's still initializing doesn't receive requests it can't yet handle. This is the single biggest lever against a restart-induced error spike; without a readiness probe, the rollout has no signal that a "new" pod is actually ready and can start routing traffic to it immediately.
• PodDisruptionBudget (PDB): guarantees a minimum number (or percentage) of replicas stay available throughout the restart, independent of the Deployment's own maxUnavailable setting, which matters when other voluntary disruptions (a node drain, a cluster upgrade) happen to overlap with the restart window.
• Graceful shutdown: a preStop hook plus a terminationGracePeriodSeconds long enough for in-flight requests to finish, combined with the Service removing the pod's endpoint before the container actually stops, avoids dropping requests that were already in progress when the restart began.
• Staged rollout for risk-sensitive services: restarting (or deploying) to a small subset first, watching error rate and latency, then proceeding, catches a bad new revision before it reaches full traffic; this is a general staged-rollout practice, not a specific traffic-splitting mechanism (traffic-splitting techniques like weighted canary routing are a load-balancing/ingress-layer concern, not something the Deployment object itself provides).

Trade-offs and pitfalls

• kubectl rollout restart only recreates pods; it does not change the Deployment's spec, so rollout history records it as a new revision with the same template, which is easy to forget when later trying to undo your way back past a restart that changed nothing.
• Setting maxUnavailable: 0 guarantees no capacity loss but requires enough spare cluster capacity for maxSurge extra pods to schedule; on a tightly packed cluster this can leave the rollout stuck Pending on the surge pods instead of proceeding.
• A rollback only restores the pod template (image, env, resource requests, and so on). If the Deployment reads a ConfigMap or Secret by a fixed name and that ConfigMap was edited in place rather than replaced with a new name or hash-suffixed name, rolling the Deployment back does not restore the old configuration content, only the old pod template pointing at the same (already-mutated) ConfigMap. This is the most common way a rollback fails to actually roll back.
• The same gap applies to a PersistentVolumeClaim (PVC): a Deployment's rollback restores the pod template's volume mount references, not the data on the volume itself. If the new version wrote a schema migration or otherwise mutated data in place on that volume, rolling the Deployment back gives you the old code pointing at already-changed data, not the old data. Anything stateful needs its own restore path (a volume snapshot or application-level backup) alongside the Deployment rollback, not instead of thinking about it separately.

Direct answer
Speaking up when you notice leadership or business behavior running against a stated principle, or discovering a values-violating practice yourself, is a career-risk-aware judgment call. The strongest answers show that you assessed the risk of speaking up honestly, chose a channel and framing proportionate to the issue, and can describe a concrete outcome, even a partial or mixed one.

Structured elaboration

• Assessing: what made you decide this was worth raising rather than letting go, whether it was a one-off or a pattern, and how material the impact was.
• Channel: who you raised it with first, and why (a direct manager rather than jumping straight to a skip-level or a formal channel, unless the severity warranted it).
• Framing: leading with concrete impact or evidence rather than an accusation, which is what makes an objection hearable rather than confrontational.
• Outcome: what actually changed, or didn't. An honest "it partially worked" or "nothing changed and here is what I did next" is a legitimate and often more credible answer than a perfectly clean resolution.
• The self-discovered variant: if you found the issue yourself, in your own work rather than someone else's, the same shape applies, but the story should show you didn't just quietly fix it and move on. Escalating a self-discovered gap through the proper channel, rather than silently patching it, is the part that demonstrates the competency.

Worked example
While reviewing a data-handling process they had built, a candidate noticed it retained a category of information longer than the stated retention policy required. Rather than quietly deleting the excess and saying nothing, they flagged the specific gap to their manager and the relevant policy owner along with a proposed fix, since a silent fix would have hidden that the gap had existed and might recur elsewhere. The fix was implemented, and the review also surfaced one other process with the same gap that would not have been found otherwise.

Trade-offs and pitfalls
Escalating everything regardless of materiality can read as poor judgment rather than integrity; the strongest answers show calibration about what is worth raising. An outcome of "nothing changed" is realistic and acceptable, but the answer should still show a proportionate attempt, not that you gave up after one try or escalated aggressively without cause. Framing a self-discovered gap as "I caught someone doing something wrong" when the honest version is closer to "I found a gap in a process I owned" overstates the story; the self-discovered version is common and doesn't need to be dressed up as catching someone else.

Direct answer

Build a self-service catalog of pre-approved, versioned modules that engineers request through a PR or portal instead of filing a ticket to a central platform team, gated by an automated policy check (not a human reviewer) at plan time, applied into a team-isolated state and account, with every request logged to an audit trail by construction. The central team's job shifts from doing the provisioning to maintaining the catalog and the policy rules that gate it, which is what lets a small platform team support a thousand engineers without becoming the bottleneck.

Core components and the request flow

flowchart LR
  A[Engineer] --> B[Self-Service Catalog]
  B --> C[Module Registry]
  B --> D[CI/CD Pipeline]
  D --> E[Policy Gate: OPA/Sentinel]
  E -->|pass| F[Apply: Team-Isolated State]
  E -->|fail| G[Rejected + Reason]
  F --> H[Cloud Account]
  F --> I[Audit Log]
  F --> J[Observability: Dashboards/Alerts]

This is the full operating model, piece by piece:

• Repo strategy: one repo per module family (networking, compute, data stores), not one giant monorepo of everything, so ownership and review scope stay clear.
• Module versioning and discovery: modules are semver-tagged and published to a private registry; the catalog is literally a browsable, filtered view of that registry.
• CI/CD orchestration: the pipeline in the diagram, triggered by a PR against a team's environment repo that references a catalog module.
• Remote-state isolation between teams: one state file (or workspace) per team, per environment, per account, never a shared giant state that couples unrelated teams' blast radius together.
• Least-privilege access control: short-lived, OIDC-issued credentials scoped to exactly the account and role a given team's workspace targets, no long-lived static keys.
• Automated policy enforcement: the Policy Gate in the diagram runs OPA or Sentinel against the plan, automatically, on every request, not a human eyeballing a diff.

The same architecture also scales down cleanly: for an org with dozens of engineering groups (rather than a thousand engineers) provisioning their own dev, test, and prod environments, the operating model doesn't change, only the catalog's environment presets and the team-to-workspace mapping get smaller.

Two more things the catalog can carry

Ephemeral, customer-like sandboxes. The same catalog also serves a different use case: ephemeral environments engineers spin up to experiment or benchmark against something that looks like production traffic, not to run production itself. Give these a short TTL enforced by an automatic teardown job, a lower cost ceiling baked into the module defaults (smaller instance sizes, no cross-AZ redundancy), and the same telemetry pipe as production, so a benchmark result taken in the sandbox is actually trustworthy.

Auto-provisioned observability. Every catalog module that stands up a service also provisions its own dashboards, alerts, and log retention as part of the same apply, parameterized per environment (a dev sandbox might get 7-day log retention and no paging; prod gets 90-day retention and paged alerts). Changing that monitoring config itself goes through the same Policy Gate, so a team can't quietly disable its own alerting, and alert thresholds are suppressed for a short window right after a deploy completes so a routine rollout doesn't page anyone. A service isn't considered successfully provisioned by the pipeline until its dashboards and runbook link are live too, that's part of the validation stage, not an afterthought.

Worked example: a catalog entry and its policy gate

# catalog module: a team calls this from their environment repo
module "team_service" {
  source  = "app.terraform.io/org/service/aws"
  version = "2.3.0"

  team        = "checkout"
  environment = "staging"
  size        = "small"
}

# policy gate: deny anything without required tags or a public bucket
package terraform.policy

deny[msg] {
  input.resource_changes[_].change.after.tags["team"] == null
  msg := "every resource must carry a team tag"
}

deny[msg] {
  rc := input.resource_changes[_]
  rc.type == "aws_s3_bucket"
  rc.change.after.acl == "public-read"
  msg := "public S3 buckets are not allowed through the self-service catalog"
}

A team opens a PR referencing the module, CI runs a plan, the plan is evaluated against policies like the ones above, and only on a clean pass does the pipeline apply into that team's isolated workspace and account. No step in this path requires a person from the central team to act.

Coordinating across cloud and on-prem, and where a human fits in

For a deployment that spans both cloud and on-prem systems in one workflow (say, provisioning a cloud database, then updating an on-prem load balancer's config to point at it), the CI/CD pipeline becomes an event-driven orchestrator rather than one linear job: each step publishes a completion event, the next step subscribes and runs with its own retry and backoff, and a failed step's blast radius stays local to that step instead of leaving the whole workflow half-applied. A human approval step fits specifically between the cloud-side apply and the on-prem step, because on-prem changes are usually the harder one to roll back automatically, that's exactly the point where automation should hand off to a person rather than before it.

Trade-offs and pitfalls

• The catalog itself becomes the bottleneck if only a few people can maintain modules for a thousand engineers' worth of use cases; treat catalog module ownership as distributed (each domain team owns and reviews its own modules) with the central team owning only shared primitives and the policy layer.
• Standardization versus autonomy is a real trade-off: too rigid a catalog pushes teams to route around it with hand-rolled Terraform, too loose and you lose the guardrails the whole design exists for.
• A managed platform (Terraform Enterprise/HCP Terraform) reduces the glue work (registry, RBAC, run queue built in) but costs a license; the open-source equivalent (Atlantis, a self-hosted registry, OPA, S3/DynamoDB or S3-native locking) is free but is more infrastructure the platform team itself has to run and keep available.
• Pinned module versions prevent a breaking change from silently reaching every team at once, but stale pins across a thousand engineers' worth of environments also mean security patches don't roll out automatically; budget for a deliberate version-bump campaign, not just 'teams will update eventually.'

Situation & goals (one line)
Design a cost‑optimized, high‑availability DDoS resilience strategy for a public API with spiky traffic and strict SLAs: keep API reachable, minimize false positives, and control costs.

High‑level architecture

• Global anycast fronted CDN (edge caching + TLS termination) for absorb/terminate and to reduce origin load.
• Provider DDoS protection: always‑on basic network protection at edge (e.g., AWS Shield Standard / GCP/Cloudflare baseline) + on‑demand advanced scrubbing for large attacks.
• Web Application Firewall (WAF) and managed bot management at the edge.
• Autoscaling origin behind API gateway with warm pools / preinitialized instances, circuit breakers, and a request queue (rate limiting + graceful degradation).
• Telemetry/alerts + automated escalation to scrubbing provider + runbooks.

Why each piece

• CDN caching reduces requests to origin for cacheable endpoints (static or cached JSON). Even partial cache hit rate saves origin compute and cost.
• Always‑on baseline protects from common volumetric attacks cheaply; on‑demand scrubbing is cost‑efficient for rare, massive attacks because you avoid constant higher fees.
• WAF + bot management block layer‑7 abuse and credential stuffing while preserving legitimate traffic.
• Autoscaling with warm pools shortens scale time and meets SLA during spikes; backpressure + rate limiting preserve stability.
• Traffic scrubbing (scrubbing centers or provider advanced service) handles large volumetric or application floods when edge controls hit capacity.

Trade‑offs

• Always‑on advanced scrubbing: highest cost but simplest SLA guarantees. Use if attacks are frequent.
• On‑demand scrubbing: lower steady cost, slightly longer mitigation ramp time — acceptable if attacks are rare and SLA tolerates short mitigation windows.
• Aggressive CDN caching: reduces load and cost but requires careful cache invalidation and not appropriate for highly dynamic user‑specific endpoints.
• Autoscaling vs warm pools: pure autoscale is cheap but slow; warm pools cost more (idle instances) but ensure lower cold‑start latency for SLAs.
• Bot management false positives: tighter rules reduce cost and load but risk blocking users — prefer progressive challenges (JS/browser challenge) and adaptive ML.

Operational controls & KPIs

• SLOs: availability %, RTO for mitigation activation, max acceptable cold‑start time.
• Monitor: edge requests, origin 5xx, latency, error budget burn, anomaly detection.
• Runbooks: automated cutovers to scrubbers, temporary increased caching, rate limit adjustments.

Final recommendation
Use CDN + always‑on baseline DDoS + edge WAF/bot management + autoscaling with warm pools. Enable on‑demand scrubbing for catastrophic attacks. Tune cache policies and rate limits to balance cost vs availability; automate detection→scrub workflow and maintain playbooks to meet strict SLAs.

Direct answer
Code review becomes a coaching tool the moment you separate what has to change before this merges from what's worth teaching, and handle each differently, since blocking mixes poorly with explaining. What counts as the important risk to teach toward also shifts by what's being reviewed: correctness and style for typical application code, reproducibility and data leakage for ML work, and blast radius for infrastructure changes.

Separate blocking feedback from teaching feedback

• Mark comments explicitly as blocking versus non-blocking (or use a similar convention), so the author isn't left guessing what actually has to change before merge. Teaching comments that aren't required for merge belong in the non-blocking bucket, otherwise you either water down real teaching moments to keep the change unblocked, or block a mergeable change to make a point.
• Ask before you tell: a comment phrased as a question ("what happens if this list is empty?") invites the author to find the issue themselves, which teaches the underlying reasoning; a comment phrased as an instruction just transmits the fix.

What "the important risk" means shifts by artifact type

• Typical application code: the coaching focus is usually correctness, readability, and test coverage; the failure mode being taught against is a defect shipping or the next person not being able to follow the change.
• ML notebooks and experiment configs: the review risk is different in kind, not just degree. The critical things to check and teach toward are reproducibility (is the seed pinned, is the environment specified, can someone else get the same result) and data leakage (does the training data have any path back to the evaluation set, directly or through a shared preprocessing step). A notebook can be clean, readable code and still be dangerously wrong for reasons that have nothing to do with code style.
• Terraform and other infrastructure-as-code changes: the review risk is blast radius, not defects in the traditional sense. A small, correct-looking diff can still be catastrophic if it touches a shared resource or removes a safeguard. Coaching here means teaching someone to ask what does this affect beyond what's in the diff before asking is this line correct.

Making it a genuine teaching moment, not just a gate

• When there's something worth teaching, don't just fix it in the comment; explain the why, and where useful, point to a real example elsewhere in the codebase rather than a generic principle.
• For anything too deep to unpack asynchronously in a comment thread, offer a short pairing session instead of a long comment chain; some things teach faster live than in writing.
• Close the loop: after a pattern comes up more than once for the same person, raise it directly in a 1:1 rather than only ever surfacing it inside individual review threads, so it becomes a recognized growth area instead of a recurring surprise.

Worked example
Reviewing a teammate's change that added a new model training script, the code itself was clean and well-tested in the conventional sense. The actual coaching moment was elsewhere: the evaluation split was built after a preprocessing step that had already seen the full dataset, which meant the reported accuracy was optimistic in a way unit tests would never catch. Rather than just fixing the split order and moving on, the comment walked through why that ordering matters (what leakage actually does to the reported number) and pointed to another script in the repo where the split happened correctly, before the shared preprocessing step. That change did get blocked, since the leakage was a real correctness issue, but the teaching part was the explanation of why, not the fact that it was blocked.

Trade-offs and pitfalls

• Making every comment a teaching moment, including on merge-blocking issues, slows delivery and can read as review turning into a lecture; save the deeper explanations for the genuinely worthwhile ones and keep routine fixes routine.
• Applying the same review lens (say, defect-finding) to every artifact type misses the risks that matter most for that artifact; a Terraform change reviewed like application code will pass style and correctness checks while missing blast radius entirely.
• If teaching moments only ever show up as isolated review comments and never get named directly to the person as a pattern, growth stays implicit and slower than it needs to be.