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

1. “What would success look like for a Solutions Architect at 30, 60 and 90 days?”

• Why: clarifies measurable expectations and priorities.
• How it informs decision: if expectations are realistic and aligned with my strengths (e.g., delivering design docs vs. ramping on product), it signals a healthy role fit.
• Early roadmap: map deliverables to milestones (week-by-week deliverables, stakeholder check-ins).

2. “Which clients, deals, or internal projects would I be expected to own immediately, and what’s their status?”

• Why: reveals workload, complexity, and sponsorship.
• Decision: ownership of strategic deals with active sponsors is attractive; purely shadowing roles may be less so.
• Roadmap: prioritize onboarding to the most critical accounts, schedule discovery calls, and review existing artifacts.

3. “Who are the key stakeholders I’ll collaborate with (sales leads, engineering managers, product) and what are their expectations for my role?”

• Why: identifies cross-functional dependencies and communication lines.
• Decision: clear stakeholder alignment reduces ambiguity.
• Roadmap: set 1:1s in week one, create RACI for deliverables.

4. “What architecture standards, templates, and tools are already in use, and how mature is the documentation?”

• Why: evaluates technical debt and ramp time.
• Decision: mature tooling suggests faster impact; lack of standards implies additional upfront work.
• Roadmap: allocate time to learn or establish templates; propose quick wins to standardize.

5. “What are the common failure modes or risks you’ve seen new architects face here?”

• Why: surfaces cultural or process pitfalls.
• Decision: helps judge support and realistic expectations.
• Roadmap: proactively mitigate (e.g., set clearer SLAs, align expectations with sales).

6. “How are handoffs between pre-sales and delivery handled, and what success metrics indicate a smooth transition?”

• Why: critical for solutions continuity.
• Decision: poor handoff processes are a red flag for rework.
• Roadmap: define handoff checklist, ensure documentation and kickoff meetings.

7. “What training or pairing will be provided during ramp-up?”

• Why: measures investment in your success.
• Decision: formal onboarding increases likelihood of early wins.
• Roadmap: follow prescribed training, supplement with targeted learning plan.

8. “Are there immediate architecture constraints or tech decisions I must accept (preferred vendors, reference architectures)?”

• Why: reveals flexibility and autonomy.
• Decision: proprietary/locked stacks might limit your approach; acceptable if aligned with your expertise.
• Roadmap: design within constraints and identify where to propose alternatives later.

9. “How will my performance be measured in the first 90 days, and who will provide feedback?”

• Why: defines cadence for course correction.
• Decision: clear, frequent feedback channels are positive.
• Roadmap: schedule formal checkpoints at 30/60/90 days and adjust priorities based on feedback.

10. “If I accept the role, what would you like me to accomplish by the end of month three that would make you confident I’m the right hire?”

• Why: crystallizes the hiring manager’s top concerns.
• Decision: alignment here is critical to acceptance.
• Roadmap: translate that target into a concrete 90-day plan with milestones, deliverables, and stakeholder sign-off.

Use answers to score offer fit: support level, clarity of expectations, stakeholder sponsorship, and ramp resources. If scores are high, accept and execute the tailored 30/60/90 roadmap; if low, negotiate clarity, resources, or reconsider.

For stateless serverless functions the key is externalizing state to managed services that match access patterns, consistency and latency needs. Below are common patterns, when to use them, and operational/latency trade-offs.

• Managed relational DB (RDS/Aurora Serverless)

  • Use when strong ACID, complex joins or transactions required.
  • Trade-offs: higher latency (cold connections, connection management via proxies/pools), operationally simple (managed backups/replicas) but can need a connection-proxy (RDS Proxy) to scale serverless.

• NoSQL (DynamoDB, CosmosDB)

  • Use for high-scale key/value or document access, single-digit ms reads, predictable throughput.
  • Trade-offs: eventual vs strong consistency options, simpler scaling and low operational overhead, cost model based on RCU/WCU or serverless modes.

• Distributed cache (ElastiCache, Memorystore)

  • Use for sub-ms reads, session caching, read-through patterns.
  • Trade-offs: in-memory volatility (need backing store), additional operational component, network hop adds small latency but faster than DB.

• Durable queues (SQS, Pub/Sub, Kafka)

  • Use for asynchronous processing, retries, offloading heavy work.
  • Trade-offs: higher end-to-end latency (milliseconds to seconds), guarantees (at-least-once), simplifies decoupling and scaling.

• Object storage (S3, Blob)

  • Use for large binary state, immutable artifacts, or event sourcing.
  • Trade-offs: higher read/write latency than DB for small items, cheap durable storage, good for batch access and CDN integration.

• External session stores (JWT, encrypted cookies, token stores)

  • Use to keep functions stateless while preserving user session info.
  • Trade-offs: JWT reduces backend calls but increases token size/security concerns; session stores require cache/DB (trade latency vs complexity).

• State machines (Step Functions, Durable Functions)

  • Use for orchestrating long-running workflows and reliable checkpoints.
  • Trade-offs: added orchestration latency and cost, but removes complexity from functions and provides visibility/retries.

Recommendation: match data model and SLA — use NoSQL + cache for low-latency scale; relational for transactional needs with a proxy; durable queues and object storage for asynchronous/bulk; state machines for orchestration. Consider cold-starts, connection management, cost model and operational surface when designing.

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

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.

Requirements & constraints:

• Strong isolation per tenant (network + identity), single cloud region, shared platform services (API gateway, auth, logging, data plane), low-latency connectivity, centralized audit/logs, secure cross-account access.

High-level design:

• One AWS account (or cloud management account) for platform/shared services; one separate account per tenant for isolation (VPC-per-account). Use AWS Organizations and SCPs to enforce guardrails.

Subnetting:

• In each tenant account VPC: /22 CIDR (e.g., 10.t.0.0/22) split into:
  • Public /28 for NAT/IP-assigned endpoints (if any)
  • Private application subnets /24 per AZ
  • DB/subnet /26 per AZ (restricted)
• Platform VPC: larger CIDR /20 with service subnets (API, auth, logging, egress).

Routing & connectivity:

• Use AWS Transit Gateway in platform account to connect tenant VPCs across accounts (peer attachments per tenant). Route tables per attachment to enforce access. Only allow routes from tenant VPC -> shared-services subnets, not tenant-to-tenant.
• For high security, use AWS PrivateLink (VPC Endpoints) for shared services (authentication, APIs, logging ingestion). Expose platform services as endpoint services; tenants create Interface Endpoints in their VPCs—no routing through transit gateway needed for service access.

Service endpoints & data plane:

• Use S3 Gateway Endpoints for object storage access (policy-restricted by VPC/account) and Interface Endpoints for critical services (Secrets Manager, KMS, SNS, SQS) where supported.
• KMS keys: customer-managed multi-account keys with grants; keys in platform account but use key policies + cross-account grants.

Security groups & NACLs:

• Default deny at NACL and security group level. Security groups per tier:
  • App SG: allow inbound from ALB SG, outbound to DB SG
  • DB SG: allow inbound only from App SG and platform backups SG
  • Endpoint SGs: allow connections from tenant app SGs
• Use least-privilege SG rules (referencing SG IDs, not IPs). Enforce host-based firewalling on instances.

Identity & cross-account access:

• Centralize identity in platform: use an enterprise IdP (OIDC/SAML) with AWS IAM Identity Center or cloud-native IAM federation. Users get roles via SSO mapped to cross-account IAM Roles.
• Cross-account roles: create roles in tenant accounts with narrowly-scoped permissions (role assumption allowed only from platform account or SSO principal). Use permission boundaries and session tags to enforce tenancy context.

Centralized logging and monitoring:

• All tenants push logs to platform logging ingestion via PrivateLink endpoints (or Transit Gateway with VPC flow logs forwarded). Use Kinesis/Firehose in platform account to ingest, transform, encrypt, and store in S3 (per-tenant prefixes) and forward to SIEM (Splunk/ELK). Enforce encryption with KMS and bucket policies restricting PutObject to tenant principal ARN.
• Central metrics/trace: tenants emit OTLP to collector endpoint in platform via PrivateLink; use tenant-id metadata and RBAC for access.

Security controls & audit:

• Flow logs + GuardDuty in each tenant account, aggregated to platform via Kinesis.
• Use centralized IAM audit: CloudTrail multi-account trails stored in platform S3 with object lockdown, MFA delete for sensitive logs.
• Use automated account/VPC hardening via Infrastructure-as-Code (Terraform) and validate with policy-as-code (Sentinel/Cloud Custodian).

Trade-offs:

• VPC-per-tenant maximizes isolation but increases management overhead; mitigate with automation. PrivateLink reduces lateral attack surface and avoids routing complexity but costs more.

This design gives strong network and identity boundaries, least-privilege access, centralized observability, and scalable onboarding via automation.

Framework: assess against development effort, relevance/control, feature velocity, total cost (TCO), data privacy, and scaling. Then recommend based on business priorities (time-to-market, customization, cost sensitivity, regulatory constraints).

Summary comparison (high-level):

• Custom search engine

  • Development effort: Very high — build indexer, tokenizer, ranking, query parser, monitoring.
  • Relevance/control: Maximal — full control over ranking signals, ML models, bespoke relevance tuning.
  • Feature velocity: Low unless large dedicated team — every feature is in-house.
  • TCO: High up-front and ongoing (engineering, infra, R&D); unpredictable as features expand.
  • Data privacy: Best possible if kept on-prem/VPC; you control access and encryption.
  • Scaling: Flexible but engineering-heavy — must design sharding, consistency, failover, autoscaling.

• Managed Elasticsearch (e.g., AWS OpenSearch Service)

  • Development effort: Moderate — core search infra managed, you integrate indexing and tuning.
  • Relevance/control: High — Elasticsearch provides analyzers, custom scoring, plugins (some limits on managed tiers).
  • Feature velocity: Moderate — OSS features available quickly; custom advanced features require dev effort.
  • TCO: Mid-range — predictable infra costs, lower ops headcount but licensing (if commercial) adds cost.
  • Data privacy: Good — runs in your cloud account/VPC; compliance achievable with configs.
  • Scaling: Good — provider assists scaling, but large-scale tuning and shard management still needed.

• SaaS search (e.g., Algolia)

  • Development effort: Low — quick onboarding, SDKs, hosted APIs, UI widgets.
  • Relevance/control: Medium — rich relevance features and A/B tools, but limited low-level access and custom ranking internals.
  • Feature velocity: High — vendor adds features and ML ranking improvements regularly.
  • TCO: Can be low for small/medium traffic but rises with index size, record count, and query volume; predictable subscription pricing but can be expensive at scale.
  • Data privacy: Varies — vendor-hosted data; acceptable with contracts and SOC compliance but risky for strict data residency/regulatory needs.
  • Scaling: Excellent — built for high query throughput, low-latency global delivery (edge CDN).

Recommendation guidance:

• If primary need = fastest launch, low engineering ops, and relevance tunability within provided knobs → choose SaaS.
• If need = strong relevance control, enterprise integrations, and predictable long-term costs with in-cloud ops team → choose managed Elasticsearch.
• If need = unique ranking algorithms, proprietary ML models, strict data residency, or cost optimization at extreme scale → build custom (only with senior engineering investment).

Operational considerations: hybrid patterns (SaaS for storefront + managed ES for analytics/experimentation), staged migration plan, clear KPIs (latency, relevance metrics, cost per query), and contractual SLAs/data processing agreements.

Direct answer

Atomic multi-service reconciliation over a dependency graph needs the SAME "all succeed or safe rollback" guarantee a database transaction provides, but GitOps has no equivalent of a database's native transaction mechanism, each service's manifests apply independently through the underlying Kubernetes API, so the operator has to construct that guarantee itself: track each service's individual reconciliation status against the dependency graph's required ORDER, and on ANY service's failure, actively COMPENSATE (roll back) every service that had already succeeded in this same multi-service change, rather than leaving a partially-applied graph in an inconsistent state.

Structured elaboration

Data model. A MultiServiceChange custom resource capturing: the SET of services involved in this specific coordinated change, their DEPENDENCY ORDER (a directed acyclic graph, service B cannot reconcile until service A, which it depends on, has succeeded), each service's OWN manifest reference (a Git commit/digest), and, critically, each service's PRIOR successful state (the last known-good manifest reference for that service, needed as the compensation target if a rollback becomes necessary).

Reconciliation loop. Processes services in DEPENDENCY ORDER (a topological sort of the graph), reconciling each only once its dependencies have themselves reached a succeeded state; this is the mechanism that gives ordering guarantees a plain, independent per-service reconciliation loop does not provide on its own.

Handling of partial failures. If a service in the middle of the ordered sequence FAILS to reconcile (after its own bounded retry), the operator does NOT continue reconciling the REMAINING, not-yet-processed services in the graph (since they may depend on the failed one, and even if they don't directly, the overall multi-service change is now incomplete); it transitions the MultiServiceChange to a compensating state and begins rollback.

Rollback/compensation semantics. Roll back every service that ALREADY succeeded in THIS multi-service change, in REVERSE dependency order (a service's dependents must be rolled back before the service itself, mirroring the forward order's own logic), reverting each to its recorded PRIOR successful state (not simply "delete," since the prior state may itself be a specific, meaningful configuration, not merely "nothing"); the never-reconciled remaining services in the graph need no compensation at all, since they were never actually changed.

Worked example

A MultiServiceChange spanning three services with dependency order network-policy before auth-service before checkout-service (checkout depends on auth, auth depends on the network policy being in place first):

1. network-policy reconciles successfully first (no dependencies).
2. auth-service reconciles successfully second (its dependency, network-policy, already succeeded).
3. checkout-service FAILS to reconcile (its new manifest references a config value that does not exist yet).
4. The operator transitions to compensating: rolls back auth-service to its PRIOR successful manifest first (checkout, the failed one, was never actually applied, so it needs no rollback, just needs to stop being retried), then rolls back network-policy to its prior state.
5. Final state: all three services back at their PRE-CHANGE configuration, a clean, fully-compensated failure, rather than network-policy and auth-service left on their NEW configuration while checkout alone failed, which would have been a genuinely inconsistent, partially-migrated state.

Trade-offs and pitfalls

• Common mistake: rolling back services in the SAME order they were applied, rather than REVERSE dependency order. Per the worked example, rolling back network-policy (which auth-service depends on) WHILE auth-service is still running its new configuration risks auth-service operating against a network policy that no longer matches what it expects, briefly recreating the exact kind of inconsistency the whole compensation mechanism exists to avoid; reverse-order rollback (dependents first, dependencies last) is what keeps every INTERMEDIATE state during the rollback itself consistent too, not just the final state.
• "Roll back to the prior successful state" requires that prior state to have actually been RECORDED before the new change began, an operator that only tracks the CURRENT desired state, with no memory of what preceded it, cannot perform this rollback at all; this is a real, easy-to-omit data-model requirement, not an implementation detail.
• A service that was never reached in the forward pass (because an earlier dependency failed first) needs NO compensation, per the worked example's checkout-service, attempting to "roll back" a service that was never actually changed is at best a wasted no-op and at worst risks touching a resource the operator has no legitimate reason to be modifying right now.
• This entire mechanism assumes the dependency graph itself is ACCURATE and complete: a graph missing a real dependency risks reconciling (or worse, considering "successful") a service whose actual prerequisite was never satisfied, defeating the ordering guarantee the whole design exists to provide.

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.

Requirements clarification (validated with stakeholders)

• Hard constraints: required country/region for data residency, acceptable max inter-region latency (ms), compliance standards (e.g., GDPR, HIPAA, PCI), contractual SLAs.
• Soft constraints: cost sensitivity (% of infra budget), preferred managed services, vendor lock-in tolerance, migration timeline.

Evaluation criteria (weighted)

• Data residency and compliance (25%)
• Network latency & topology (20%)
• Cost (TCO) — compute, storage, egress, inter-region traffic (20%)
• Services fit & maturity (managed DBs, IAM, KMS) (15%)
• Operational tooling & support (monitoring, SLAs, enterprise support) (10%)
• Risk: vendor lock-in, exit strategy (10%)

Scoring rubric (0–5 per criterion)

• 0: does not meet / high risk
• 1–2: poor fit / major gaps
• 3: acceptable with mitigations
• 4: good fit, minor gaps
• 5: excellent fit, fully meets needs
  Multiply by weights → normalized score.

Recommendation process

1. Run quick elimination (hard constraints like no region presence → exclude).
2. Measure latency: run pilot probes between key sites and cloud regions; record 95th percentile.
3. Estimate TCO for a representative workload over 3 years (incl. egress, backups, DR).
4. Proof-of-Concept for security/compliance: encryption at rest/in-transit, KMS residency, audit logs.
5. Score providers, present top choice + mitigations, fallback plan, and migration timeline.

Example trade-offs

• Azure may win on data residency in certain countries (more local regions) but cost for inter-region egress could be higher — trade lower latency vs higher ongoing costs.
• GCP often has lower inter-region network costs and global backbone (better latency) but fewer enterprise support constructs in some locales.
• AWS has broad service maturity and marketplace but may introduce complexity and higher licensing costs.

Provider-specific feature that can sway decision

• If the customer requires a BYOK/HSM key that never leaves the country and a managed HSM with local legal controls, Azure Dedicated HSM or AWS CloudHSM’s regional offerings (with FIPS/PCI attestations) could be decisive. Example: Azure offers sovereign cloud contracts and extensive regional presence in certain regulated markets — if legal requires sovereign cloud, that feature may override a slightly higher TCO.

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.