Solutions Architect (Junior Level) - FAANG-Standard Interview Preparation Guide

Situation: During a client-facing design review I was leading, two senior engineers loudly disagreed about using a managed messaging service vs. a self-hosted streaming cluster. The debate became personal in front of the extended team and a technical decision was blocked.

Task: As the Solutions Architect responsible for delivering a defensible, timely architecture and preserving the client's confidence and our team's psychological safety, I needed to de-escalate the moment, reach a well-reasoned decision, and protect team relationships.

Action:

• Immediate de‑escalation: I paused the meeting, thanked both engineers for their passion, and asked for a short break to prevent further escalation. This signaled control without shaming anyone.
• Private 1:1s: During the break I spoke individually with each engineer to acknowledge their concerns, separate technical arguments from personal tone, and confirm they still wanted to resolve the issue collaboratively.
• Recenter on requirements: I brought the meeting back and restated the client constraints (SLA, throughput, time-to-market, ops budget). I proposed a decision framework (criteria: reliability, cost, time-to-delivery, operability) and asked the two to map their proposals to those criteria.
• Evidence-driven path: I suggested quick experiments / metrics (throughput benchmarks, TCO calc) and a risk register with mitigations. We timeboxed the evidence gathering to 3 days and assigned owners.
• Neutral arbitration & documentation: I offered to synthesize results or bring in an impartial SME if disagreements remained. We documented the decision rationale and fallbacks in the architecture doc so the choice is auditable.
• Preserve psychological safety: I used blameless language, publicly thanked both engineers for rigor, and reminded the team that constructive disagreement strengthens outcomes. After the decision I held private feedback conversations and a blameless retrospective to capture process improvements (clearer pre-review agendas, behavior norms).

Result: Within a week we produced a short benchmark and TCO analysis, chose the managed service for initial delivery with a planned migration path, and delivered the design to the client on schedule. The public tension did not recur; both engineers reported feeling heard, and the team adopted the decision framework for future reviews. The approach resolved the technical impasse while preserving trust and psychological safety.

Direct answer

CAP theorem says a distributed system cannot simultaneously guarantee all three of Consistency (every read returns the most recent write), Availability (every request receives a non-error response), and Partition tolerance (the system keeps working when some nodes cannot reach others). Because real networks drop packets and links fail, partition tolerance is not optional, so the actual choice during a partition is between consistency and availability. Systems like Google Cloud Spanner lean CP (some requests are blocked or rejected to stay correct); systems like Cassandra or Riak in their common tuning lean AP (every request gets an answer immediately, even a possibly stale one).

Structured elaboration

The three letters, precisely

• Consistency: every node that answers a read returns the same, most-recent value; there is no "which replica did you happen to hit" effect.
• Availability: every request that reaches a non-failed node gets a response, in bounded time, even if that response can't be proven up to date.
• Partition tolerance: the system continues operating even though some messages between nodes are lost or delayed.

Why "CA" is not a real option
A system that isn't partition tolerant is only correct as long as the network never drops a message, which no real, multi-node network guarantees. So "CA" only describes a single-node system, or a distributed system that hasn't yet been tested by a real partition; it is not a deployable choice for a genuinely distributed service.

CP vs AP

PACELC, the extension worth naming
PACELC (if Partitioned, choose Availability or Consistency; Else, choose Latency or Consistency) points out that CAP only describes what happens during a partition. Even with no partition at all, a system still has to decide, on every write, how synchronously to replicate: wait for every replica to acknowledge (favors consistency, costs latency) or acknowledge after one replica and replicate the rest in the background (favors latency, costs consistency). An AP system's day-to-day behavior is really governed by its PACELC answer, not its CAP answer, since partitions are rare and normal operation is not.

Quorum tuning as the middle ground
Many stores let you tune how many replicas must acknowledge a write (W) and how many must respond to a read (R) out of N total replicas, sliding the same system between CP-like and AP-like behavior per operation rather than committing the whole deployment to one label. The mechanics of quorum protocols are their own topic; the point for this answer is that the CP/AP choice is a dial, not a single global switch.

Worked example

Take three replicas (N = 3) with a write quorum W = 2 and a read quorum R = 2, so that any write and any read are guaranteed to overlap on at least one replica:

$W + R > N \quad\Rightarrow\quad 2 + 2 > 3$

Now a partition splits the three replicas into a group of 2 and a group of 1.

• The group of 2 can still assemble a quorum (2 out of the required 2), so it keeps serving reads and writes: consistent and available, on that side.
• The lone replica cannot assemble a quorum (1 is short of 2), so it must refuse requests rather than answer from possibly-stale local data: it sacrifices availability to avoid sacrificing consistency.

If the same store were instead configured for W = 1, R = 1 (an AP-leaning setting), both sides could keep accepting writes independently during the same partition, and the two sides would need to reconcile any conflicting writes once the partition heals; nothing here changes the network, only the dial.

Two alternate ways to see the same trade, folded in from adjacent scenarios: to a non-engineer stakeholder, the choice can be framed without the theorem's name at all: "during an outage, would you rather the app show a slightly out-of-date number and stay up, or freeze and show an error until we're sure the number is right?" That question is CAP in plain language. The same trade also shows up in machine learning infrastructure: an online feature store serving features to a live model at inference time typically leans AP (serve the last known values within a freshness window rather than block the request), while the offline pipeline that snapshots those same features for a training run typically leans CP (a training set built from a partially-written snapshot silently corrupts the model, so the pipeline waits for a consistent point-in-time snapshot instead).

Trade-offs & pitfalls

• Treating "pick 2 of 3" as one permanent, whole-system architecture decision, instead of a per-operation or even per-data-type decision a single platform can make differently in different places.
• Conflating CAP's "C" with the "C" in ACID (atomicity, consistency, isolation, durability): CAP consistency is about replicas agreeing with each other; ACID consistency is about the database enforcing its own integrity constraints. They answer different questions and can both be true or false independently.
• Forgetting PACELC: an AP system still owes an answer to "how synchronously do you replicate during normal operation," since that decision affects latency and staleness every day, not just during rare partitions.
• Citing "CA" as if it were a legitimate label for a real distributed deployment, rather than a description of a single-node system or an untested assumption.

Direct answer

Real alignment shows up in specifics: how the team talks about growth in concrete, checkable terms, named examples of people who advanced, real scope handed to individuals, rather than slogans, plus evidence the organization actually invests in it. The harder test is whether it holds up at both horizons: a role can look right for the next year or two while quietly falling short of your longer five-year path, so the strongest answers name both the near-term signals and how they'd check the longer one.

Structured elaboration

1. Separate signal categories. What's explicit in the job description (ownership language, mentorship, cross-functional exposure) versus what you'd have to ask about directly (promotion cadence, real examples of people who've grown here, how leveling actually gets decided).
2. Watch for vague versus concrete language. "Fast-paced growth environment" is marketing. "You'll own this end to end within six months" is a real signal.
3. Apply the near-term versus longer-path escalation. Even when near-term signals look strong, explicitly check whether the team can plausibly support your longer five-year path too. Ask what the next two or three steps look like for someone in this role, and listen for whether the answer plausibly reaches your longer destination or quietly stops short.
4. Decide what to do with a partial mismatch. A company might genuinely support your next one to two years but not obviously your longer five-year path. That's not automatically a reason to decline, it's a reason to be explicit with yourself about treating the role as a deliberate, time-boxed stop rather than assuming it's the whole path.

Worked example

"In a recent process I was evaluating a role that had all the near-term signals I look for: a specific line about a mentor being assigned, and a real example of someone promoted twice into a role like the one I wanted next. What I didn't get a clean answer on was what came after that. When I asked what the path looked like three steps out, the answer got vague. I decided the role was still worth taking for what it clearly offered near-term, but I went in treating it explicitly as a deliberate stop along the way rather than assuming it would carry me the whole distance, and said as much to my own network so I'd actually revisit it on schedule."

Trade-offs & pitfalls

• Taking any mention of "growth" in a job description at face value without asking for a concrete example is the most common way people get burned.
• Only checking the near-term horizon and assuming the longer path takes care of itself misses the harder, more valuable version of this question.
• Overcorrecting into cynicism, assuming no company can ever support a long personal horizon, and declining otherwise-strong roles over a mismatch that's actually normal and manageable.
• Failing to distinguish "this doesn't support my longer path" from "this is a bad role." Often the right move is accepting a partial match deliberately, not searching for a mythical perfect one.

Direct answer

I would draw the normal state once, then give each failure its own diagram overlay and its own runbook page, with the same four headings every time: what the user sees, what data is at risk, how we recover, and who decides. A single "resilient architecture" picture hides the difference between losing the link between regions and losing the primary database, and those are different problems with different recoveries.

The diagram (deployment view: which software runs where, in which region, with the two scenarios marked)

flowchart LR
  U[Users] --> G[Global traffic routing]
  G --> A[Region A: app tier]
  G -.->|"only if A is declared down"| B[Region B: app tier]
  A --> P[(Primary database)]
  P ==>|"async replication, lag shown on dashboard"| R[(Replica in Region B)]
  B -.-> R
  X1{{"Scenario 1: link between regions is cut (strikes the replication path)"}} -.-> R
  X2{{"Scenario 2: primary database is lost"}} -.-> P

How to read it: solid arrows are the normal path; the dotted arrow from global routing to Region B is used only after Region A is declared down (a named person or an agreed rule, for example health checks failing for 3 minutes, formally decides A is out); the thick arrow is data replication; each hexagon marks where a scenario strikes: scenario 1 touches the replica end of the thick replication arrow (Mermaid cannot point at an arrow itself), scenario 2 touches the primary. Alert on lag during scenario 1, because the lag is the data you would lose.

Beside the picture, always state: the consistency model (what readers are promised to see after a write; here replication is asynchronous, meaning the primary confirms a write before the replica has it, so the replica trails), the RPO (recovery point objective: the most data we accept losing, measured in time) and the RTO (recovery time objective: how long recovery may take). Put real values on the page, for example RPO 5 seconds and RTO 15 minutes. Measured lag of 4 seconds fits inside the 5 second RPO; lag of 30 seconds would not, and the dashboard should alert before that.

Scenario pages

A runbook is the step-by-step operating procedure an on-call engineer follows during an incident. A filled scenario 2 page, for example: User sees: checkout fails for up to 15 minutes. Data at risk: up to 4 seconds of orders (current lag). Recover: confirm the primary is truly gone, promote the Region B replica, repoint the app, build a new replica. Decides: the incident commander (the person in charge during the incident), after 3 minutes of failed health checks.

Split-brain and flapping

Split-brain means two regions both believe they are the primary and both accept writes, so their data diverges. The docs must state the single-writer rule: only the holder of the current write lease (an expiring right to write) may accept writes, and each promotion increments an epoch number (a counter that only goes up) so an old primary is rejected when it returns. Traced: Region A is primary in epoch 7. A goes dark and B's replica is promoted in epoch 8. When A returns it still thinks it is epoch 7, but the storage layer and gateway only accept writes stamped epoch 8 or higher, so A's writes are rejected and A must resync as a replica. Flapping means leadership bouncing back and forth on a shaky link. The runbook adds a hold-down time (a minimum wait before another promotion) and forbids automatic promotion on a partition alone.

Make lag visible

The topology diagram links to a live dashboard showing replication lag, because the recovery decision ("how much would we lose?") is answered by that number.

Trade-offs and pitfalls

• Drawn failovers that skip fail-back (returning to the original primary after the outage) leave teams stuck with the wrong primary. Document the return path.
• Do not promise a zero RPO with asynchronous replication.

Direct answer

The gap between someone productive in days and someone still struggling after months is usually explained by a handful of concrete factors, not raw talent: how much prior related experience carries over, how good the available material is, whether they have access to someone who already knows it, how fast their feedback loop is while learning, and how much of what they're doing is high-stakes enough to force caution. The fastest thing I can do for myself is identify which of those I'm weakest on and deliberately fix it, rather than just trying harder.

Structured elaboration

Worked example

Two engineers on a team picked up the same unfamiliar infrastructure tool around the same time. One had a colleague nearby who already knew it well and a sandbox environment to experiment in freely; the other had neither, and was mostly working directly against a shared environment where mistakes were visible and costly, which understandably made them cautious and slow. When I was in a similar position picking up something unfamiliar, I noticed I had neither advantage either, so rather than just working harder, I deliberately asked for a sandbox account to be set up so I could iterate quickly without the cost of a mistake, and asked a colleague who'd used the tool elsewhere for a short walkthrough of the two or three things that usually trip people up early. Both of those closed most of the gap: the sandbox gave me a fast, cheap feedback loop, and the short conversation gave me a shortcut past the mistakes that would otherwise have taken me weeks to discover on my own.

Trade-offs and pitfalls

The biggest trap is attributing the gap to talent or aptitude, which is both usually wrong and actively demotivating, since it points at nothing you can actually do anything about. A second trap is fixing only one factor when several are compounding, for instance getting a sandbox but never asking anyone for help, which leaves a slower path than fixing both. And simply not being willing to ask for the resource that would help, a better source, a person's time, a safe place to practice, out of a sense that you should be able to figure it out alone, is often the single biggest thing standing between the two outcomes.

Direct answer

The claim "we collaborate closely" is easy to say and hard to fake consistently, so I'd look for concrete, checkable evidence rather than take the statement at face value: specific recent examples instead of platitudes, whether people from both teams describe the relationship the same way, and how they talk about the last time they actually disagreed.

Structured elaboration

A few concrete signals to look for over the course of a loop:

• Specificity versus platitude: asking "tell me about a recent example of these two teams working together" either produces a concrete story (a named project, a specific decision, a friction point that got resolved) or vague language like "we're very collaborative" with no example attached. The second is the tell.
• Cross-loop consistency: if the loop includes interviewers from both teams, do they describe the same touchpoints, the same rituals (joint planning, shared reviews, a shared roadmap document), and the same account of how decisions get made? Genuine collaboration produces a matching story from both sides; a one-directional relationship usually produces two different stories.
• Shared ownership artifacts: does something concrete exist that both teams actually maintain together, like a joint on-call rotation, a shared design review, or shared goals, versus one team simply being a requester and the other being treated like a vendor?
• How friction is described: asking about the last real disagreement and how it got resolved is one of the highest-signal questions available. Real collaboration produces an honest, specific account with a resolution mechanism (an escalation path, a joint decision meeting). A performative version either claims there's never been friction, or describes it being resolved unilaterally by whichever side is more senior.
• Structural distance: do the two teams share a leader within a couple of levels, or sit in entirely separate parts of the org with no shared incentive to cooperate? A large structural distance is a risk signal even when interviewers insist things work well.

Worked example

Imagine interviewing for a Software Engineer role where a Platform team and Product Engineering are supposed to work closely on an API contract. The hiring manager says "we work really closely with Platform." Later in the loop, a Platform-team interviewer gets asked the equivalent question: "walk me through the last time your team and Product Engineering disagreed about an API change." If that interviewer describes a specific incident, a proposed breaking change, a joint review meeting, and a documented decision, that corroborates the hiring manager's claim. If instead they say "I don't really remember friction, we mostly just tell them what to build," the same "close collaboration" claim from the hiring manager is revealed as one-directional direction-giving, not collaboration. A follow-up worth trying: ask whether a shared design-review document or joint roadmap actually exists; teams that only say they collaborate often can't point to one.

Trade-offs and pitfalls

A loop only gives a few hours across a handful of people, so it isn't practical to fact-check every claim; prioritize the one or two claims that matter most for day-to-day happiness in the role. Framing the friction question as genuine curiosity rather than as a trap matters, since it can otherwise come across as adversarial. A single negative data point could reflect one interviewer's bad day rather than a systemic issue, so look for a pattern across multiple interviewers before concluding the collaboration is mostly performative rather than concluding it from one comment.

Direct answer

Training and inference are different workloads that should usually run on different compute, sized for different bottlenecks. Training wants maximum sustained throughput across many accelerators, with tolerance for job-level restarts, while online inference wants low, predictable per-request latency with enough headroom to autoscale to traffic. A right-sized training cluster and a right-sized inference fleet are not the same purchase, even when they serve the same model.

Compute options by workload

Training. Characteristics: long-running batch jobs, where accelerator memory capacity and interconnect bandwidth (how fast accelerators can exchange data with each other) matter as much as raw accelerator count, since multi-accelerator jobs need fast accelerator-to-accelerator communication, not just many chips. Training jobs can usually tolerate preemption if checkpointing is solid, and cost is dominated by total accelerator-hours. Compute options: large multi-GPU instances (graphics processing units, now the general workhorse for parallel numeric computation) or accelerator pods purchased on spot or preemptible pricing (much cheaper capacity the provider can reclaim with short notice) where checkpointing exists, since training's restart tolerance makes it a good fit for interruptible capacity, plus a reserved or committed baseline if training runs nearly continuously.

Online inference. Characteristics: short per-request compute, where tail latency (the slow end of the response-time distribution, not the average) matters more than raw throughput per accelerator, unpredictable request volume that needs to scale quickly, and a workload that typically runs constantly, so it can't be fully spot-based without a fallback, since interruption directly hurts a live user. Compute options: smaller GPU-backed instances, or CPU-only if the model is small enough, behind an autoscaled fleet (containers on an orchestrated platform are the common shape, since they give fast, controlled autoscaling), with a reserved baseline for steady traffic plus on-demand burst capacity, and serving-time optimizations (batching requests together, quantizing the model to shrink it) to make a smaller, cheaper accelerator tier viable.

Worked example

For training, use spot or preemptible multi-GPU nodes for the bulk of the epochs, checkpointing every few minutes so a preemption loses at most that much progress, and keep a small on-demand fallback reserved for the final convergence run, where an uninterrupted window is worth paying for directly. For inference, keep a minimum of two always-on GPU instances as a high-availability floor, autoscale further on a p95-latency or queue-depth metric, and enable request batching up to a batching-latency budget small enough that it doesn't push the response past the target p95.

Trade-offs and pitfalls

A common wrong turn is sizing the inference fleet the way the training cluster was sized (fewer, bigger, less redundant instances) because "that's what worked for training." That trades away exactly the failover redundancy inference needs. Another is running training jobs on capacity reserved for inference "since it's free at night," which only works with strong isolation; a runaway training job must not be able to starve inference of accelerators during a traffic spike. Recommend explicit, separate capacity pools for the two workloads rather than one shared pool governed by priority rules you hope hold under pressure.

Direct answer

Keep alignment across time zones with three levers: shrink what actually needs real-time overlap by defaulting to async updates on a fixed template, protect a small deliberately scheduled overlap window for anything that truly needs live discussion, and make handoffs explicit in writing so context transfers cleanly across the boundary instead of depending on someone's memory.

Framework

Reduce dependence on overlap. Default to async status updates on a fixed cadence, and use written decision docs rather than requiring a live meeting for every decision. Most updates don't need a room, only genuinely ambiguous or high-stakes calls do.

Protect a deliberate overlap window. Negotiate a recurring block, even a short one, and rotate who takes the inconvenient time so the burden doesn't always fall on the same region.

Make handoffs explicit. When work crosses a time-zone boundary, produce a short written artifact rather than relying on a quick chat message. This matters most in ops-heavy, always-on contexts.

Worked example

Consider an on-call rotation providing 24/7 production coverage across three time zones (for example [Region A], [Region B], and [Region C]), where the two outer regions have little or no live overlap with each other.

• Shadow and overlap periods: the incoming region's on-call shadows the outgoing region's on-call for a short deliberate window at the shift boundary, even 15 to 30 minutes, to ask questions live before the outgoing engineer signs off.
• Written handoff template: a standard document filled at every handoff covering open incidents, any systems in a degraded state, changes deployed in the last shift, and explicit 'known risk' or 'do not touch' notes.
• Escalation expectations: a written policy defining what counts as page-worthy versus a handoff note, who the secondary on-call is in each region, and how long the incoming engineer has to acknowledge before it auto-escalates.
  Result: even with zero live overlap between two of the three regions, the written handoff plus the short shadow window from the middle region means each incoming on-call starts already briefed, instead of reconstructing state from raw logs.
  For non-ops roles the same mechanism applies with a different artifact, for example a design or product handoff might be a written decision log plus a recorded walkthrough rather than an incident handoff, but the principle (explicit written handoff over a live conversation) is the same.

Trade-offs and pitfalls

• Repeatedly scheduling occasional syncs at painful hours burns out whichever time zone draws the short straw. Rotate it deliberately.
• Async-only breaks down for genuinely ambiguous or high-stakes decisions. Some live channel for true emergencies still has to exist.
• A handoff template that's too heavy gets skipped under time pressure. Keep it short enough to fill in within a few minutes.
• Assuming a chat message counts as a handoff is the actual failure mode this whole approach is designed to prevent. The structured artifact is the point, not the tool it's written in.

Direct answer

When throughput, high availability, and data residency are unknown, the right move is not to guess at numbers, it is to buy optionality: build on managed, horizontally-friendly primitives that are cheap to run small and do not require a rewrite to run big, and explicitly defer the decisions you lack information for rather than baking a guess into the architecture.

Structured elaboration

Isolating the unknowns

List each unknown non-functional requirement and attach a cheap, reversible default plus a trigger for revisiting it:

• Throughput unknown: default to a small compute tier behind a load balancer, or a serverless/function-as-a-service (FaaS) tier that scales to near-zero, with autoscaling on from day one so "how much traffic" never requires an architecture change, only a scale-out.
• High-availability requirement unknown: default to single-region, multi-availability-zone (deploy across at least two isolated data-center locations within one region) rather than single-instance, because that is a small cost delta that buys real resilience. Defer multi-region until a contract or service-level agreement (SLA) actually requires it.
• Data residency unknown: default to a region you are confident is acceptable for the client's most likely jurisdiction, and choose a database and storage layer that supports regional migration or replication later without a schema rewrite.

Pragmatic architecture approach

• Favor managed services over self-hosted infrastructure for everything that is not the product's core differentiator: managed database, managed object storage, managed authentication. This buys speed now and defers the "should we self-host this" decision until real usage data exists to justify it.
• Keep the compute tier stateless from day one, even before knowing if you need to scale out, because retrofitting statelessness later is far more expensive than building it in when the codebase is small.
• Instrument observability, metrics, logs, and basic tracing from the start. This is how the unknowns get resolved: after a few weeks of real usage there will be real throughput numbers, real latency numbers, and real answers to where users actually are.

Migration path to enterprise-grade

Define concrete, metric-based triggers rather than a calendar date: if p95 (95th-percentile) latency exceeds the service-level objective (SLO) for two weeks running, move the database to a larger tier or add a read replica; if a customer contract requires 99.95 percent uptime, add multi-availability-zone failover automation and a documented recovery time objective; if a customer requires data to stay in a specific country, add regional data partitioning before onboarding them. This turns unknown non-functional requirements from a blocker into a backlog with entry criteria, so the MVP architecture is never wrong, only intentionally incomplete.

Worked example

A 3-month, fixed-budget MVP for a B2B scheduling tool with no committed customers yet chooses: a managed relational database, single region, one primary with automated backups; a stateless API tier on a managed container or serverless platform with autoscaling enabled; managed object storage for file uploads; and a managed authentication service instead of building auth. The unknowns are tracked as three backlog items: add multi-region if a customer requires it, add a read replica if p95 database latency exceeds 150ms, add multi-availability-zone failover if a signed contract requires an uptime SLA above what single-zone typically delivers. None of these require re-architecting the application layer when triggered, because the compute tier was already stateless and the database already supports read replicas and regional failover as an upgrade, not a rewrite.

flowchart LR
    subgraph MVP["MVP, month 0 to 3"]
        A[Stateless API tier, autoscaling] --> B[(Managed DB, single region)]
        A --> C[(Managed object storage)]
        A --> D[Managed auth]
    end
    MVP -->|"trigger: p95 latency SLO breach"| E[Add read replica]
    MVP -->|"trigger: signed SLA requiring HA"| F[Add multi-AZ failover]
    MVP -->|"trigger: contract requires data locality"| G[Add regional partitioning]

Trade-offs and pitfalls

• The main risk of deferring everything is deferring something that is actually cheap to build in now and expensive to retrofit, statelessness being the classic example. The discipline is to defer numbers, how much throughput, how available, but not defer structural choices, like statelessness, that are cheap now and costly later.
• Choosing a database or storage layer that looks cheap now but hard-binds you to one region's proprietary replication format is a common trap: it turns "add data residency later" into a full migration rather than a configuration change.
• A pragmatic MVP architecture can look under-engineered to a stakeholder expecting "enterprise-grade" on day one. Presenting the trigger-based backlog explicitly makes the gaps look intentional and monitored rather than accidental.

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.