FAANG-Standard Interview Preparation Guide: Staff-Level Cloud Engineer

Direct answer

For a read-heavy workload with moderate writes, for example a 90% read / 10% write split, the default lean should be read replicas, because they scale read capacity without adding a second consistency model to reason about. Add a cache on top only for a narrow, measured set of hot keys that replicas still cannot serve cheaply or quickly enough. The decision comes down to three questions: can the application tolerate replication lag or cache staleness, is the read traffic skewed enough that a small cache absorbs most of it, and is there enough engineering capacity to build correct cache invalidation.

Structured elaboration

Decision rule: if managed read replicas are available with a replication lag the application tolerates, start there. Add a cache only where a specific, measured hot-key or hot-query pattern needs sub-database latency or needs to shed load the replicas can't absorb cheaply.

The absorbed framing of a 90% read / 10% write split is the same decision restated: the write share matters because every write still has to land on the primary and propagate down to every replica. At 10% writes this is a non-issue; if the write share climbed toward 40-50%, the datastore choice itself would need revisiting (see write-heavy architecture reasoning), not just the cache-versus-replica question.

Worked example

Assume a baseline read load of 10,000 requests per second (RPS) and, illustratively, that each database read replica sustainably serves 2,000 RPS at acceptable latency.

Without a cache: replicas needed $= 10{,}000 / 2{,}000 = 5$ replica nodes (plus the primary handling writes).

With a cache in front, assume an 80/20 access skew (a common real-world pattern: 20% of keys account for 80% of reads) and a 90% cache hit rate on that hot 20%:

$\text{DB-bound reads} = (0.8 \times 10{,}000 \times (1-0.9)) + (0.2 \times 10{,}000) = (8{,}000 \times 0.1) + 2{,}000 = 800 + 2{,}000 = 2{,}800 \text{ RPS}$

Replicas needed with the cache in place: $\lceil 2{,}800 / 2{,}000 \rceil = 2$ replicas.

That's a drop from 5 replica nodes to 2 from caching just the hot 20% of keys, which is why a targeted cache is usually layered on top of replicas rather than chosen instead of them: it earns its operational cost only where the skew is large enough to matter.

Trade-offs & pitfalls

• Adding a cache first because it "feels faster," without first measuring read skew, risks solving an already-adequate problem while introducing invalidation bugs for no real gain.
• Replicas trade consistency for scale: if a user reads immediately after writing in the same session, that read must be routed to the primary or to a lag-aware router, or the user will see stale data from their own write.
• Cache stampede on a mass invalidation event can hit the primary at exactly the worst moment, right after the thing that made the cache go stale in the first place; request coalescing and staggered TTLs guard against this.
• A self-run cache cluster is a second system to operate, patch, and monitor; a managed database's built-in replicas usually cost less operational attention than they save, which is why replicas are the default and the cache is the exception.

Situation: I led a launch that needed Product, Engineering, and Support to deliver the same outcome, which was reducing customer setup time.

Task: Each team had different priorities, so I needed one shared goal and a way to surface trade-offs early.

Action: I started with a single business metric, then broke it into team-level commitments. Product owned the user flow, Engineering owned reliability, and Support owned readiness. I held a weekly cross-functional checkpoint where each team shared risks, not just status. When conflicts came up, I made the trade-off explicit. For example, we chose to delay one nonessential feature so we could simplify onboarding and reduce support tickets.

Result: The teams stayed aligned, the launch shipped with fewer surprises, and the process made future collaboration easier because everyone knew how decisions would be made.

The key lesson was that shared outcomes work best when the goal is visible, disagreements are discussed early, and trade-offs are decided openly instead of being left to drift.

Causes of cold starts

• Runtime initialization: JIT/AOT, language VM startup (Java/.NET heavy; Node/Python lighter).
• Package size & libs: large deployment bundles slow extraction/load.
• VPC attachments: ENI creation (Lambda historically expensive), extra network setup.
• Container image size (Cloud Run/CF): pulling large images increases latency.
• Idle scaling: platform spins up new execution environment when concurrency exceeds warm instances.

Platform differences

• AWS Lambda: cold starts noticeable for Java/.NET; VPC used to require ENI creation (improved with hyperplane); supports provisioned concurrency.
• Azure Functions: similar behavior; Consumption plan has cold starts; Premium plan reduces them.
• GCP Cloud Functions / Cloud Run: Cloud Run runs containers — startup depends on image; Cloud Run supports min instances (provisioning), Cloud Functions offers gen2 with concurrency improvements.

Mitigations

• Provisioned concurrency / min instances (Cloud Run): pay for pre-warmed instances — predictable latency.
• Warmers (synthetic pings): cheap but brittle (may not keep all scaling cases warm) and can add cost.
• Lighter runtimes & smaller packages: strip deps, use native binaries, smaller base images.
• Language choice: prefer Node/Python/Go for low latency; compile languages with smaller cold-start footprint (Go).
• Architectural alternatives: use always-on services (Fargate, ECS, managed K8s) for steady traffic; hybrid design — fast-path via cache/edge + async serverless.
• Optimize VPC: use private networking patterns (AWS Lambda ENI improvements, VPC endpoints) to avoid per-invocation network setup.

Trade-offs

• Cost vs latency: provisioned/min instances increase cost but reduce tail latency.
• Complexity vs control: warmers & custom runtimes add operational overhead; container optimizations require CI/CD changes.
• Predictability vs scalability: always-on services give consistent latency but lose fine-grained autoscaling and pay-for-idle.

I would evaluate traffic patterns, SLOs, and cost budget; for bursty, latency-sensitive paths use provisioned or min instances; for sporadic background jobs accept occasional cold starts and optimize package/runtime.

Clarify goals & constraints

• Run same SaaS on AWS + GCP for redundancy and customer choice
• Minimize operational divergence, keep CI/CD, security, observability and networking consistent
• Accept cloud-native managed services where multi-cloud alternatives exist

High-level architecture

• Two independent Kubernetes clusters per region: one in EKS, one in GKE. Use identical cluster provision via Crossplane/Terraform modules to enforce parity.
• Control plane: GitOps (Argo CD) repositories drive cluster state; single source-of-truth repos for platform, apps, and infra.

CI/CD

• Pipeline: Git -> build (GitHub Actions/GitLab CI) -> container registry (ECR/GCR or a single multi-region Artifact Registry) -> push manifests/Helm -> Argo CD sync.
• Promote artifacts by immutable tags; Argo CD apps parametrized per cloud (values.yaml) to avoid divergent manifests.

Secrets management

• Centralized secrets engine: HashiCorp Vault running in HA with replicas in both clouds or use Vault with auto-unseal using cloud KMS (AWS KMS + GCP KMS) via Transit. Store secrets in Vault; inject into pods via Vault CSI driver.
• For cloud-managed secrets, mirror only metadata in Vault; avoid storing cloud-specific secrets in code.

Cluster networking & service mesh

• Use same CNI where possible (Calico) for consistent network policy semantics.
• Deploy a cloud-agnostic service mesh (Istio or Linkerd) for mTLS, traffic shaping, and global policies. Use Gateway + Ingress per cloud and a global DNS (Route53 + Cloud DNS with health checks) to steer traffic.

Stateful data replication

• Prefer managed cross-cloud databases where possible (CockroachDB, YugabyteDB) for geo-replicated SQL with single logical cluster across clouds.
• If managed DBs per cloud (RDS/Cloud SQL), implement active-passive multi-region replication and global failover orchestrated by a control plane (e.g., Patroni + external failover controller) and async replication with strong automation for cutover.
• Backups: Velero scheduled to object storage in both clouds (S3 and GCS) and cross-copy to ensure recoverability.

Policy consistency

• Policy-as-code: OPA/Gatekeeper policies enforced in all clusters. Use centralized policy repo; CI gates validate manifests against policy.
• Cluster bootstrapping through same modules ensures identical RBAC, node pools, autoscaling settings.

Observability

• Unified telemetry: Collect logs/metrics/traces with OpenTelemetry to a centralized backend (prefer SaaS APM or a multi-tenant observability layer reachable from both clouds). Alternatively run Prometheus + Cortex/Thanos for long-term metrics with object storage backend per cloud and global query layer.
• Traces in Jaeger/Tempo with sampling consistent across clusters; alerts in PagerDuty/Slack unified via Alertmanager federated config.

Operational minimization of divergence

• Infrastructure as code modules, GitOps, shared Helm charts, shared vault/policy repos.
• Run CI/CD, observability, policy tests in centralized pipelines to prevent cluster-specific ad-hoc changes.
• Regular DR runbooks and automated failover drills.

Trade-offs & risks

• Cross-cloud data consistency and latency: choose database topology based on consistency vs availability trade-offs.
• Vault HA across clouds increases complexity; alternative is per-cloud Vault clusters with replication.
• Egress and inter-cloud costs for data replication.

Metrics of success

• RPO/RTO targets met in runbooks; successful automated failover tests; <= 10% config drift measured by nightly scans; consistent SLOs/alerts across clouds.

This design balances parity via automation and GitOps, centralizes policies/observability, and uses multi-cloud-ready stateful solutions to minimize operational divergence.

Answer (Cloud Engineer perspective)

What to log

• Authentication events: successful/failed logins, token issuance/renewal, MFA events, auth backend decisions.
• Secret lifecycle: read/get, list, create/write, update, delete/rotate, revoke, lease renewals, access denial.
• Policy & config changes: ACL/policy edits, role bindings, secret engine enable/disable, plugin changes.
• Admin actions & emergency keys: root/admin login, key unseal, master key usage, key rotations.
• System events: audit device lifecycle, replication/sync, backup/restore, service restarts, anomalous rate spikes.
• Always log metadata (timestamp, principal, principal ID, IP, user agent, request ID, secret path) but never log secret values.

Retention

• Hot/nearline: keep full, searchable logs for 90–365 days to support investigations.
• Cold/archival: retain immutable archives 3–7 years (or longer per regulation: e.g., PCI/HIPAA/GLBA requirements).
• Implement tiered storage: CloudWatch/Logs Insights or Stackdriver for hot; S3/Blob/GCS with Glacier/Archive for cold.

Protecting logs from tampering

• Use append-only, immutable storage (S3 Object Lock with Governance/Compliance mode, GCS Object Holds).
• Encrypt logs with KMS-managed keys; restrict KMS key usage to a separate audit account.
• Isolate logging write paths: forward logs to a different AWS/GCP/Azure account or subscription with strict IAM.
• Enable log signing and integrity checks (digest or signed audit entries) where supported.
• Enable multi-admin approval for retention/lock changes; use MFA and conditional IAM for log deletion.
• Integrate with SIEM (Splunk/ELK/Chronicle) and alert on audit config changes, log deletion attempts, or missing log flow.

These choices ensure forensic fidelity, meet compliance retention, and make tampering difficult while avoiding exposure of secret material.

Direct answer

Don't argue the premise. Reframe scope as breadth of impact rather than headcount of teams touched, surface concrete evidence that your depth already produced value beyond your immediate team, and pair it with a dated, checkable plan for closing whatever gap is real.

Structured elaboration

• Separate whether the pushback is right from whether it's complete. Even genuinely deep, narrow work usually throws off reusable artifacts, informal mentoring, or unsolicited cross-team requests, find and name those rather than assuming the panel has the full picture.
• Categories of scope evidence beyond team headcount: tools or practices other teams adopted from your work, standards that outlived the original project, unsolicited requests for your input from outside your team, an improvement whose benefit reached other teams indirectly, and direct peer or stakeholder statements about your influence.
• The milder version of this same move, quantifying your influence on company-level KPIs (key performance indicators), not just team-level ones, is worth building into a promotion case proactively, even without a panel pushing back, rather than only pulling it out defensively when challenged.
• Acknowledge any genuine gap honestly, then attach a plan scoped to the next one or two review cycles with specific, checkable milestones, not a vague intention to "do more cross-team work."
• Tone matters as much as content. Agreeing with the legitimate part of the feedback lands better than arguing the premise; panels respond to "here's what already extended beyond my team, and here's exactly how I close the rest," not to defensiveness.

Worked example

When a promotion committee told me my influence looked narrow after a long stretch deep on one product, I didn't argue the premise. I went back through the year and pulled out everything that had actually left that product's boundaries: a utility I'd built for my own use that two other teams had since adopted, a set of monitoring practices another team copied after seeing them in a review, and specific unsolicited messages from peers on other teams asking me to weigh in on their design decisions. I hadn't been tracking any of that as "scope," only as good engineering. I paired that evidence with a concrete plan for the next two review cycles, naming the two teams I'd deliberately extend work toward and a milestone I could point to at each checkpoint. The panel's read shifted from "narrow" to "narrow so far, but closing on a plan."

Trade-offs & pitfalls

• Getting defensive or arguing the panel is simply wrong is the most common failure mode, even when you privately disagree.
• Overclaiming influence with specifics you can't stand behind under questioning is worse than admitting the gap plainly; panels probe.
• A plan with no dates or checkpoints reads as a promise, not a plan; always attach a review-cycle timeline.
• Confusing volume of your own output with scope; breadth means other teams' work changed because of yours, not how much of your own work you personally did.

Set the policy by working backward from what each query pattern actually needs, then verify the storage savings with the arithmetic rather than picking round numbers and hoping. A reasonable concrete policy: raw metrics at native resolution for 14 days, 5-minute rollups for 1 year, hourly rollups for years 2 through 5; full traces for 30 days, then 1% sampled for the following 11 months.

Rationale by window

flowchart LR
  A[Raw ingest: native res] -->|14 days| B[Raw tier: hot]
  B -->|downsample| C[5-min tier: 1 year]
  C -->|downsample| D[Hourly tier: years 2-5]
  D -->|expire| E[Deleted]
  F[Trace ingest] -->|30 days full| G[Full trace tier]
  G -->|sample 1%| H[Sampled trace tier: 11 months]

• 14 days raw: covers essentially all incident debugging, since almost every retro or root-cause investigation happens within two weeks of the event, and alerting needs full resolution on recent data to avoid missing short spikes.
• 1 year at 5-minute rollups: supports capacity planning and seasonal comparisons (week-over-week, month-over-month) without needing per-second precision; 5 minutes is short enough to still show diurnal patterns clearly.
• Years 2-5 at hourly rollups: supports long-term trend and year-over-year growth analysis; anything finer than hourly at this age is rarely queried and expensive to keep.
• 30 days full traces: matches the raw-metrics window for the same reason, full-fidelity root cause work happens fast, and traces are the most expensive telemetry type per unit.
• 1% sampled for 11 more months: preserves enough statistical signal for "did this class of error exist a few months ago" investigations without paying for full trace volume; always retain 100% of traces tied to errors or SLO breaches regardless of the sampling rate (a fixed-percentage sample can otherwise miss the rare traces investigators actually want).

Verifying the storage savings

For 1,000,000 active series, using the same 2-bytes/compressed-raw-sample and 8-bytes/downsampled-point (4 aggregates: min, max, sum, count, at roughly 2 bytes each) assumptions used elsewhere in TSDB capacity planning:

series = 1_000_000
compressed_bytes_per_raw_sample = 2
agg_bytes_per_downsampled_point = 8

def samples(days, interval_s):
    return series * (days * 86400 / interval_s)

raw_bytes = samples(14, 15) * compressed_bytes_per_raw_sample
ds_bytes = samples(365, 300) * agg_bytes_per_downsampled_point
hourly_bytes = samples(1460, 3600) * agg_bytes_per_downsampled_point
total_tiered_bytes = raw_bytes + ds_bytes + hourly_bytes

allraw_bytes = samples(14 + 365 + 1460, 15) * compressed_bytes_per_raw_sample

Result: raw tier = 161.28 GB, 5-min tier = 840.96 GB, hourly tier = 280.32 GB, total tiered storage over the full 5-year window ≈ 1.283 TB, versus an all-raw-forever equivalent of ≈ 21.19 TB for the same window, a 16.5x reduction. The 5-minute tier dominates total storage (840 GB of the 1.28 TB) precisely because it covers the most time (1 year) at the finest surviving resolution; that's useful to know when deciding whether to push the raw window shorter or the 5-minute window's resolution coarser if the budget gets tighter.

For traces, at 10,000 traces/sec with an assumed 4 KB compressed size per trace: full 30-day retention stores about 103.68 TB, while the following 11 months at 1% sampling adds roughly 11.40 TB, so the sampled tail costs about 11% as much as the initial 30-day full window despite covering over 10x the time span.

What you can and can't still answer after each window closes

Trade-offs and pitfalls

• Percentile aggregates (p95, p99) do not survive naive downsampling: averaging five 1-minute p99 values is not the same number as the true p99 across that 5-minute window. If percentile fidelity matters at the rollup tier, you need to store enough of a histogram or sketch (not just min/max/sum/count) to recompute percentiles, which raises the per-point byte cost above the 8-byte assumption used here.
• A fixed sampling percentage for traces (1% flat) will statistically under-represent rare-but-important request types unless it's stratified or combined with the always-keep-errors/SLO-breach rule; a pure random sample optimizes for "typical" traffic, which is exactly what you don't need for debugging.
• Retention policy that isn't enforced automatically (a manual cleanup job, or "we'll get to it") tends to silently become the accidental real retention policy; tie expiry to the storage engine's native TTL/compaction mechanism rather than a side script.
• Communicating the policy to teams matters as much as setting it: if engineers don't know that a 3-week-old spike is only visible at 5-minute resolution, they'll draw wrong conclusions from a smoothed-out graph without realizing detail was lost.

Direct answer

Spot is the cheapest option on paper, but the deadline matters as much as the price. Given the historical retry overhead is only about 10%, the interruption-adjusted spot cost still comes in well below on-demand or reserved, so spot is the right primary choice for this fault-tolerant batch job, with a fallback to on-demand if progress tracking shows the job is at risk of missing the 48-hour window.

Structured elaboration

How to compute each option correctly

• On-demand and reserved are straightforward: hourly rate times hours needed.
• Spot needs an adjustment: the quoted spot rate applies to the hours actually run, but interruptions mean you re-run some work, so the effective hours are higher than the raw 1,000-hour requirement. The retry overhead has to be added to the hour count before multiplying by the spot rate, not applied as a discount on top of a naive calculation.

$\text{Monthly}_{\text{spot}} = \text{Hours} \times (1 + \text{RetryOverhead}) \times \text{SpotRate}$

The actual decision rule isn't "pick the cheapest", it's "pick the cheapest option that still comfortably meets the deadline with acceptable risk." That means checking whether the interruption-adjusted runtime still fits inside 48 hours with margin, not just comparing the three monthly dollar figures.

When you'd override the cheap answer:

• The job isn't actually resumable (no checkpointing), so an interruption means restarting from scratch rather than continuing, which would blow well past the modeled 10% overhead.
• The deadline is tight relative to how variable interruptions have historically been, leaving little margin if a bad week of interruptions happens to land during this run.
• A downstream process depends on a guaranteed completion time rather than a "usually finishes on time" completion time.

Worked example

Comparisons:

$\$60.00 - \$22.00 = \$38.00, \quad \frac{38}{60} \approx 63.3\% \text{ cheaper than reserved}$

$\$100.00 - \$22.00 = \$78.00, \quad 78\% \text{ cheaper than on-demand}$

$\$100.00 - \$60.00 = \$40.00, \quad 40\% \text{ cheaper than on-demand}$

Recommendation: use spot as the primary option, since $22/month with a comfortable 10% historical overhead still leaves plenty of margin inside a 48-hour window for a fault-tolerant, presumably parallelizable batch job. Pair it with a simple fallback policy: monitor remaining work against time-to-deadline, and if the trend suggests the job won't finish in time, fall back to on-demand (or the already-purchased reserved capacity, if any) to guarantee completion rather than risk missing the deadline to save the last few dollars.

Trade-offs and pitfalls

• Comparing sticker prices ($0.02 vs. $0.10) without the retry adjustment understates spot's real cost. The correct comparison already accounts for it above, but it's a common shortcut that overstates the savings.
• Choosing spot for a job that isn't actually fault-tolerant is the biggest risk. If the job can't checkpoint or resume cleanly, an interruption means restarting from zero, and the historical 10% overhead figure, which presumably reflects jobs that can resume, would badly understate the real cost and risk for this one.
• Committing to a 1-year reserved instance for an occasional batch job locks in cost for a usage pattern that doesn't need it. Reserved capacity is the right tool for steady-state, predictable, always-on usage, not for a job that runs occasionally and can tolerate flexible scheduling.

Direct answer

Default to additive-only changes (new optional fields with sane defaults), never silently repurpose an existing field's name or meaning, and when the meaning genuinely has to change, introduce it as a new versioned field and dual-emit both the old and new during a defined deprecation window so every consumer (dashboards, alerts, downstream jobs) has time to migrate before the old one disappears.

Structured elaboration

Additive changes are the default and the cheap case
Adding a brand-new field with a sensible default (or simply absent, if consumers already tolerate unknown fields) is safe: existing dashboards and alerts that don't reference it are unaffected, and new tooling can start using it immediately. Most schema evolution should fit this case; if it doesn't, that's a signal the change is more than "add a field."

Never repurpose a field in place
Changing what an existing field means (e.g., a latency field that used to be measured in milliseconds and is now measured in microseconds, keeping the same name) is the most dangerous kind of change, because it fails silently: old dashboards keep running the same query and now show numbers that are wrong by a constant factor, with no error to alert anyone. A rename or unit change should always get a new field name (latency_ms retired in favor of latency_us, both emitted for a transition period), never an in-place redefinition.

Version the schema explicitly
Tag every emitted record with a schema_version. Consumers that need to branch on shape (a downstream parser, a strict dashboard query) can check the version rather than guessing from field presence. This also gives you a clean place to document exactly which version introduced which change.

Deprecation as a process, not an event

1. Announce the field's replacement and the planned sunset date.
2. Dual-emit: write both the old and new field for a fixed window.
3. Track actual usage of the old field (query logs, dashboard/alert definitions referencing it) to confirm consumers have migrated, not just assume they have.
4. Only stop emitting the old field once usage has genuinely dropped to zero (or the sunset date passes and remaining consumers have been explicitly notified they'll break).

Testing the transition
Contract tests (automated checks that a producer's output still satisfies what a known consumer expects) and shadow validation (running the old and new emission side by side and diffing the derived metrics they produce) catch the case where the "safe" additive change turns out to interact badly with an existing aggregation, before it reaches production dashboards.

Worked example

A service currently emits {"latency": 245, ...} where latency is milliseconds, and the team wants to switch to microsecond precision.

Wrong approach (in-place redefinition): change the emitter to write {"latency": 245000, ...} under the same field name. A dashboard panel computing avg(latency) over the last hour now silently reports a number 1000x larger with zero errors or warnings; anyone glancing at the dashboard sees "avg latency: 245000ms" and either panics or, worse, doesn't notice because the panel has no sanity bound configured.

Correct approach: add latency_us alongside the existing latency field, dual-emit both for a stated transition window (e.g., until every dashboard query referencing latency has been rewritten to use latency_us, confirmed by grepping the dashboard/alert config repository for the old field name), then drop latency only after that grep returns zero references.

The key diagnostic in this example: the failure mode is not "the pipeline throws an error," it's "the pipeline keeps running and produces a wrong number that looks plausible." That's why additive-with-a-new-name is the default, not an optional extra step.

Trade-offs & pitfalls

• Dual-emitting indefinitely accumulates cost and confusion; every deprecation needs an explicit sunset date, not an open-ended "eventually."
• Tracking actual field usage (rather than assuming consumers migrated because you announced it) is the step most teams skip, and it's exactly the step that prevents a surprise outage when the old field is finally dropped.
• Additive changes still need CI-enforced schema compatibility checks (backward/forward compatibility validation), because "just add a field" can still break a strict consumer that rejects unknown fields.
• A silent semantic change is strictly worse than a loud break: a query that errors gets noticed and fixed; a query that keeps returning a plausible-looking wrong number can go unnoticed for months.

Direct answer

Automated misconfiguration detection for a multi-account AWS environment layers three native services and two external tool categories into one pipeline, AWS Config and Security Hub for continuous configuration and finding aggregation, GuardDuty for behavioral threat detection, IaC (infrastructure-as-code) scanning (Checkov/tfsec) for pre-deployment prevention, and policy engines (OPA/Sentinel) for plan-time enforcement, feeding one central dashboard; the design decision that matters most is not which tools to use, all of these are reasonably standard choices, it is which findings get automated remediation versus which get routed to a human, since that boundary determines whether the system is trustworthy or dangerous.

Structured elaboration

Native service roles. AWS Config continuously evaluates every resource's configuration against managed and custom rules across every account, the primary source of configuration-drift and misconfiguration findings. Security Hub aggregates findings from Config, GuardDuty, and any third-party integrated tool into one normalized finding format and one dashboard, serving as the central aggregation point rather than each source having its own separate view. GuardDuty adds behavioral, threat-intelligence-driven detection (an unusual API call pattern, a known-malicious IP contacted) that configuration-based Config rules structurally cannot provide, since Config checks state, not behavior over time.

IaC scanning role. Checkov or tfsec run in the CI (continuous integration) pipeline against every infrastructure-as-code change before it merges, catching a misconfiguration before it is ever deployed, the cheapest point in the whole pipeline to catch a finding, since it requires no live cloud resource to exist yet.

Policy engine role. OPA/Sentinel evaluates the fully-resolved terraform plan output (or an equivalent for another IaC tool) at plan time, catching a misconfiguration that only resolves once variables and modules are fully computed, which static IaC scanning alone can miss; this is a preventive gate specifically for changes that go through the IaC pipeline, distinct from Config's detective, always-on coverage of the account regardless of how a resource got there.

How findings flow to a central dashboard

Every source (IaC scanning, policy-engine plan-time checks, Config, GuardDuty) emits findings in, or normalized into, the AWS Security Finding Format, feeding into Security Hub, which serves as Aggregation account's own delegated-administrator view across every member account in the AWS Organization, consistent with the delegated-administrator pattern used for centralized security tooling throughout this domain. From Security Hub, findings route into the organization's existing ticketing system (via an EventBridge rule triggering a Lambda function or a native integration), so the dashboard is not the only place a finding lives, it also becomes tracked, assigned work in the tool the responsible team already uses daily.

Prioritization

Findings are scored by a combination of severity (the source tool's own rating), exploitability (is the affected resource internet-reachable right now), and business context (is the account tagged as production, does the resource hold sensitive data), rather than a flat severity list that would treat a critical finding on an isolated development resource the same as an identical finding on an internet-facing production one.

Automated remediation versus human-reviewed remediation

Automated remediation is reserved for a narrow, explicitly reviewed list of finding types where the fix is unambiguous and reversible (re-enabling S3 Block Public Access, closing a security-group rule matching a known-bad pattern with no legitimate business justification ever recorded for it), triggered directly from a Config rule's non-compliant state via an automated remediation action (a Systems Manager Automation document, or an equivalent), with the remediation action itself logged as its own auditable event. Everything else routes to human review: a finding whose "correct" fix depends on context the automated system cannot evaluate (an unusually broad but potentially legitimate permission grant, a resource whose configuration might be intentional for a specific business reason) becomes a ticket with a severity-based service-level agreement (SLA), not an automatic action, since auto-remediating a context-dependent finding risks breaking a legitimate configuration the automated system had no way to distinguish from a genuine misconfiguration.

Worked example

A developer's Terraform pull request adding a new S3 bucket without Block Public Access enabled is caught by Checkov at the IaC-scanning stage, blocking merge before any resource is created, the cheapest possible catch. A separate, unrelated change made directly through the console (bypassing IaC entirely) opens a security-group rule to 0.0.0.0/0 on port 22; AWS Config's continuous evaluation flags this within its next scheduled evaluation cycle, and because this exact pattern (SSH open to the world, no recorded business justification) is on the narrow auto-remediation list, an automated remediation action reverts the rule within minutes, logging the action and notifying the resource's owning team after the fact. A third finding, a database security group permitting inbound access from a broader internal CIDR range than the organization's general policy prefers, does not match any auto-remediation pattern (the "correct" fix depends on whether a specific application dependency actually needs that broader range), so it routes to a ticket with a 7-day SLA for the owning team to review and either narrow the rule or document the justification.

Trade-offs and pitfalls

• The auto-remediation list is the single highest-stakes design decision in this architecture, and it needs to stay narrow and under continuous review, not grow opportunistically every time a new "obviously safe" pattern is proposed; the worked example's SSH-open-to-the-world case is genuinely unambiguous, but a broader or more context-dependent pattern added to the same list without the same scrutiny risks an automated action breaking a legitimate configuration.
• GuardDuty's behavioral detection and Config's configuration-state detection catch fundamentally different things, and a design that treats them as redundant (or worse, only implements one) misses half of what this layered approach is built to catch; Config would never flag an unusual API call pattern, and GuardDuty would never flag a static, unchanging misconfiguration that was simply never actually exploited.
• IaC scanning and Config together still leave a real gap: a change made entirely outside the IaC pipeline, caught only by Config's own continuous, out-of-band evaluation, not prevented at merge time. The worked example's console-made security-group change demonstrates this directly; the design's real strength is that Config's detective coverage exists specifically because IaC scanning's preventive coverage cannot see everything.
• Routing every finding to Security Hub and then to a ticketing system only delivers real value if the ticket routing correctly identifies the owning team via resource tagging; a finding routed to the wrong team, or to no team at all because tagging was incomplete, sits unactioned regardless of how well the detection and aggregation layers themselves are working.