Cloud Engineer (Senior Level) - FAANG-Standard Interview Preparation Guide

Direct answer

With a managed relational database already at 60% of cloud spend, I'd build a weighted scorecard across three options (stay managed, self-manage, switch engines) that prices out 3-year total cost of ownership (TCO), one-time migration effort, and reliability impact side by side, then let the numbers plus a documented risk tolerance drive the call rather than defaulting to "just self-manage it, it's cheaper."

Structured elaboration

Requirements and constraints

• Business: recovery point/time objectives (RPO/RTO), service-level objectives (SLOs), 3-year growth in queries-per-second and storage, compliance, acceptable migration downtime.
• Technical: current engine/version, features in use (replication, JSON columns, stored procedures), traffic pattern, peak load, latency targets.

Evaluation steps

1. Pick comparison metrics: 3-year TCO, one-time migration effort, ongoing operational full-time-equivalent (FTE) cost, reliability (mean time to recovery, availability delta), performance headroom, feature parity, security/compliance risk, vendor lock-in risk.
2. Quantify TCO per option:
   • Managed: instance cost, storage input/output operations per second (IOPS), backups, network egress, support plan, reserved-capacity discounts.
   • Self-managed: VM/Kubernetes infra, licensing if applicable, high-availability tooling (e.g. Patroni, Orchestrator), backup/restore infrastructure, monitoring, disaster recovery, patching labor, extra redundancy.
   • Engine switch: everything self-managed needs, plus schema/data migration tooling, application code changes, testing, and a fallback plan.
   • Project all three forward 3 years using a conservative growth assumption.
3. Estimate migration effort and risk: data volume, change-data-capture (CDC, streaming database changes to a target system) feasibility, downtime window, schema/SQL-dialect differences, performance and compatibility testing, rollback plan; convert to person-weeks including staging infrastructure and runbooks.
4. Operational overhead and reliability trade-off:
   • Managed: lower ops FTE, vendor SLA, built-in backups/patching, but less control and a shared blast radius during a vendor-side incident.
   • Self-managed: more ops (monitoring, HA, upgrades) but full control over tuning and recovery, at the cost of human-error risk and slower feature rollout.
   • Engine switch: possible reliability gains or regressions; genuine unknowns during and immediately after cutover.
5. Skills matrix: managed needs site reliability engineers (SREs) fluent in vendor administration and cost optimization; self-managed needs deep DBA replication/tuning skills plus automation tooling; an engine switch needs migration engineers, app developers for SQL changes, and QA for compatibility.
6. Score and decide: weighted scorecard, for example TCO 30%, reliability/availability impact 25%, migration risk/effort 20%, feature fit 15%, long-term strategic fit 10%.
7. Decision rule:
   • Managed TCO acceptable, SLOs met, low business risk -> stay managed.
   • Savings exceed the added operational-cost delta AND self-managing genuinely improves control needed for SLOs/compliance -> self-manage.
   • Switch engines only if feature or performance gains justify the migration risk and cost, or lock-in is strategically unacceptable.

Worked example

Pinned, illustrative inputs for a 3-year comparison of stay-managed vs. self-manage:

• Managed: $200,000/year x 3 = $600,000.
• Self-managed: $120,000/year infrastructure + $100,000/year operations FTE = $220,000/year x 3 = $660,000, plus a one-time $80,000 migration/setup cost = $740,000.
• Delta: self-managed costs $140,000 more over 3 years for this workload (about 23% above the managed total), even though the sticker price of self-managed infrastructure alone looks lower than the managed bill.

This is the same shape of trap as a raw-infra-only comparison: the $120,000 self-managed infra line is cheaper than the effective infra portion of the $200,000 managed bill, but the $100,000/year operations FTE more than erases that gap once the one-time migration cost is added. Interpretation: a small remaining delta (here roughly $47,000/year) means the decision should hinge on strategic reasons (control, compliance, avoiding lock-in) rather than cost alone, since the cost case for switching is not decisive at this size.

Trade-offs and pitfalls

• The hardest inputs to quantify honestly are migration risk (unknowns surface mid-cutover) and the true incident cost of losing vendor-backed HA, both of which are easy to under-price relative to line-item infra cost.
• A common mistake is comparing today's managed bill to today's self-managed infra estimate and stopping there, ignoring 3-year growth and the compounding operational-FTE cost.
• Engine switches are frequently pitched on a feature list without pricing the testing and dual-running period, which is usually the most expensive part of the migration.
• A small pilot (migrate one low-risk service or read replica first) validates the person-week and risk assumptions before committing the whole database to a 3-year plan built on estimates.

Direct answer

Mentoring is voluntary, growth-oriented influence without formal accountability. Managing includes formal accountability, resourcing decisions, and real consequences. The line moves the moment a mentee becomes a direct report, because feedback that used to be optional advice now carries formal weight, and the relationship gains structural power (comp, promotion, performance record) it didn't have before.

Where the line actually is

What changes when a mentee becomes a direct report

Private growth conversations now double as input to a formal review, whether that's said out loud or not. Advice that was previously optional is now, in practice, expected to be acted on for role reasons. The relationship carries real structural power (comp, promotion, PIP, short for performance improvement plan: the formal HR process for addressing underperformance) that it didn't have as informal mentoring. The hardest part is that "helping you grow" and "evaluating you" now happen with the same person, often in the same conversation, and separating those framings requires being deliberately transparent about which one is active at a given moment, rather than assuming the mentee can tell.

Worked example

A mentee who'd been mentored informally for a while later became a direct report after a reorg. The explicit adjustment made on day one: naming that some future 1:1 time would now include performance topics, not only growth topics, and being upfront about which kind of conversation was happening in the moment, rather than letting the mentee guess which hat was on.

Trade-offs and pitfalls

A common mistake is continuing to run the relationship exactly as before once it becomes formal, without naming the shift, which reads as inconsistent or even manipulative once the mentee realizes "informal advice" now affects their review. A stronger approach names the shift explicitly rather than letting the mentee discover it the hard way. Another pitfall is using "I'm just mentoring you" framing to soften what is actually a directive, formal expectation, which blurs accountability for both sides.

Assumptions

• 1,000 RPS steady, average request payload 50 KB, responses small (<=100 KB), P95 latency budget 200 ms end-to-end.
• Traffic evenly distributed; tolerate regional failure avoidance (no multi-region DR primary, but possible read-replicas).

High-level architecture (AWS managed services)

• DNS / CDN:
  • Amazon Route 53 for DNS + latency-based routing.
  • Amazon CloudFront in front for caching static assets (reduces origin load).
• Load balancing:
  • Application Load Balancer (ALB) across 3 AZs, health checks, access logs enabled.
• Compute:
  • ECS Fargate (serverless containers) or EKS with autoscaling across 3 AZs. Use target concurrency sizing: if one task handles ~50 RPS, run 20 tasks + buffer → autoscale by CPU/RPS.
• Storage:
  • Amazon S3 for static/object storage (CloudFront origin).
• Database:
  • Amazon RDS (Postgres) Multi-AZ for primary HA, read replicas (optional) for read scaling. Use automated backups and parameter groups.
• Caching:
  • Amazon ElastiCache (Redis) cluster-mode across AZs for session/DB caching; TTLs to reduce DB load.
• Observability & Monitoring:
  • Amazon CloudWatch metrics/alarms, CloudWatch Logs (centralized), AWS X-Ray for tracing, GuardDuty for security alerts.
  • Dashboards for RPS, latency, error rate, instance/task counts, cache hit ratio.
• Security / Resilience:
  • WAF on ALB, IAM least-privilege roles, SGs, NACLs.
  • Backup & snapshot policies for RDS and Redis; S3 versioning.
• Autoscaling & Availability practices:
  • ALB health checks + ECS service autoscaling (target tracking on CPU/custom RPS metric).
  • Distribute tasks across 3 AZs; deployment strategy: rolling updates with health checks.
  • Recovery SLO: leverage Multi-AZ RDS, restart unhealthy tasks automatically; design for 99.95% (allowed ~4.38 min/month downtime).

Capacity & trade-offs

• Calculate per-task throughput via load testing; tune task size and concurrency. CloudFront + Redis should offload majority reads.
• For stricter RTO or region failover, add cross-region read replicas and Route 53 failover routing.
• Cost vs complexity: Fargate simplifies ops; EKS may reduce unit cost at scale.

This design meets 1,000 RPS with high availability, autoscaling, caching, and full observability using AWS managed services.

Direct answer

Isolate the layer before you fix anything: reproduce the failure, then check, in order, whether API Gateway is timing out waiting on Lambda, its own hard cap for REST APIs is 29 seconds, whether Lambda is timing out or throttling while waiting on the database, whether the database itself is refusing connections because the connection pool or max_connections is exhausted, and separately, whether the errors cluster around a Multi-AZ failover event, which produces its own distinct burst of connection errors that looks like an outage but is actually the database behaving as designed. Each layer leaves a different fingerprint in its own logs and metrics, and the fix is different for each, so conflating them, for example raising a timeout when the real cause is failover, just delays finding the actual root cause.

Structured elaboration

Layer-by-layer fingerprints

Why a Multi-AZ failover itself causes a client-visible error burst

Multi-AZ failover is not invisible to clients, and that is expected AWS behavior, not a bug to chase:

• The DB instance endpoint is a DNS CNAME that gets repointed from the old primary to the newly promoted standby. Any client, or connection pool, already holding an open TCP connection to the old primary's IP has that connection become invalid the moment the old primary demotes; those connections need to be dropped and re-established, and in-flight queries on them fail.
• Many database drivers and JVM-based clients cache DNS resolution more aggressively than the CNAME's low TTL assumes, the JVM in particular caches indefinitely unless explicitly tuned, so even after the CNAME has repointed, some clients keep retrying the old IP until something forces a fresh DNS lookup: an existing connection error, an explicit pool refresh, or a client restart.
• The practical result: at the moment of failover, you get a short, simultaneous burst of connection resets or "could not connect" errors across many concurrent clients, followed by a clean return to normal once clients reconnect through the new CNAME target. That burst-then-recover shape is the tell that distinguishes a failover event from a genuine capacity or code problem, which tends to build up or persist rather than spike and clear.
• RDS Proxy specifically exists to blunt this: it keeps client-facing connections open across a failover and reconnects on the backend transparently, so clients behind Proxy see far fewer, ideally none, of these errors compared to clients connecting directly to the instance endpoint.

How to isolate quickly

• Correlate the error timestamps against the RDS event log first; if they line up with a failover event, you likely do not have an application bug, you have an application that is not resilient to a documented, expected RDS behavior.
• Invoke the Lambda function directly, bypassing API Gateway, with the same payload to see whether it fails identically, isolating whether API Gateway's own timeout is even in play.
• Check the database connection count over the same window: a value pinned at the ceiling implicates pool exhaustion; a single vertical jump then a return to baseline implicates failover.

Worked example

Say RDS events show a failover completing at a specific timestamp, and your API error logs show several hundred connection-reset errors clustered in the fourteen seconds around that same timestamp, then zero errors afterward. That short, all-at-once cluster immediately followed by a clean recovery is inconsistent with a connection-pool-exhaustion story, which would typically show errors building up as load rises and persisting until load drops or capacity is added, and is exactly the shape you would expect from open connections to the old primary becoming invalid all at once. Being consistent with the RDS event timestamp is the actual evidence here, not a guess.

Trade-offs and pitfalls

• Do not "fix" a failover-driven error burst by raising Lambda or API Gateway timeouts; that does not address the actual cause, stale connections to a now-demoted instance, and just makes each retry attempt slower.
• The right fixes for failover sensitivity are: put RDS Proxy in front of the database so clients do not hold direct connections to the instance endpoint, make application code retry transient connection errors with backoff instead of surfacing them straight to the caller, and avoid aggressive DNS caching in the client runtime.
• Conflating a failover burst with a capacity problem leads to over-provisioning, a bigger instance or more Lambda concurrency, that does not reduce failover frequency or its client impact at all, since failovers happen for reasons unrelated to load, maintenance, AZ issues, or manual triggers.
• Genuine connection-pool exhaustion and failover bursts can both produce connection errors in application logs; the RDS event timeline and the shape of the error cluster, instantaneous spike-and-clear versus gradual buildup, is what actually distinguishes them, do not rely on the error message text alone.

Direct answer

Idempotency means performing the same operation multiple times has the exact same effect as performing it once. It matters for retries because network failures make it impossible for a client to reliably tell "the request failed" apart from "the request succeeded but the response was lost"; without idempotency, a client that retries after a timeout risks creating a duplicate side effect, like charging a customer twice for one order.

Making a payment-creation endpoint safe to retry

The standard mechanism is a client-generated idempotency key attached to the request:

1. The client generates a unique key (a UUID) once per logical operation, before the first attempt, and sends it on every retry of that same logical operation in a header such as Idempotency-Key.
2. The server does an atomic check-and-set against a persistent store keyed by that idempotency key: if the key is new, it proceeds with the charge; if the key already exists, it returns the previously stored result instead of processing the charge again.
3. The check-and-set has to be atomic (a single transactional operation, not a read followed by a separate write) so two near-simultaneous retries can't both see "key doesn't exist" and both proceed.
4. The stored result includes enough to reconstruct the original response (status, charge ID, amount) and a status field (in_progress, succeeded, failed) so a retry that arrives while the first attempt is still executing gets told to wait or gets the eventual result, rather than racing ahead.
5. Keys are kept with a bounded TTL (commonly 24 to 72 hours) since indefinite retention is unnecessary once a client has almost certainly given up retrying, and TTL bounds the storage cost of the idempotency table.

sequenceDiagram
  participant Client
  participant API as API Region A
  participant Store as Idempotency Store
  participant PG as Payment Gateway
  Client->>API: POST charges Idempotency-Key K1
  API->>Store: check-and-set K1 in_progress
  Store-->>API: new key proceed
  API->>PG: create charge
  PG-->>API: charge succeeded
  API->>Store: save result for K1
  API-->>Client: 200 OK response lost in transit
  Client->>API: retry POST charges Idempotency-Key K1
  API->>Store: check K1
  Store-->>API: found status succeeded
  API-->>Client: 200 OK cached result no new charge

Worked example

In the sequence above, the server actually completes the charge and writes the success result to the idempotency store, but the client's connection drops before the 200 response arrives, so from the client's point of view the request timed out. The client retries with the same key K1. The server's check-and-set finds K1 already marked succeeded, so it returns the stored response (the original charge ID and amount) directly and never calls the payment gateway again. Exactly one charge exists, regardless of how many times the client retries.

Harder extension: retries across a cross-region failover

The same duplicate-request risk gets worse if the retry lands on a different region than the original attempt. Say the first request goes to Region A, and before the response comes back, DNS or Anycast reroutes the client (as part of a regional failover) so the retry with the same idempotency key goes to Region B. If the idempotency store is region-local and not replicated, Region B has never heard of K1, sees it as a new key, and processes a second charge, exactly the failure the mechanism was supposed to prevent.

The fix is that the idempotency store itself has to be as available and as replicated as the failover design assumes the rest of the system is: either a globally consistent store (accepting the added write latency) or, more commonly for payments specifically, delegating idempotency to the payment gateway itself, which usually supports its own idempotency keys and is already a single global system of record regardless of which region initiated the call. Relying on the gateway's own dedupe as the backstop means even a fully region-local idempotency store failing open during a failover doesn't result in a real double charge.

Trade-offs & pitfalls

Idempotency keys add a write to the hot path (the check-and-set) and a storage system that has to be highly available, since if the idempotency store itself is down, you're forced to choose between blocking the write entirely or risking a duplicate. TTL choice is a real trade-off: too short and a legitimately slow client retry after the TTL expires creates a duplicate; too long and the storage grows unnecessarily and stale in-progress records from crashed requests linger. The most common mistake is only deduplicating the write itself while forgetting downstream side effects (an email receipt, a webhook fired to a third party) that happen inside the same logical operation and need to be gated by the same check, not fired unconditionally every time the handler runs.

Direct answer

After a drill I run a structured post-exercise review that classifies every finding as people, process, or technology, scores it for severity, assigns a single named owner and a due date scaled to that severity, and requires an independent verification test before the finding can be closed, not just the owner's word that it's fixed. Individual findings then roll up into a small set of trend metrics that a recurring governance review looks at, so leadership can tell whether the continuity program is actually improving over time rather than just accumulating a backlog of open tickets.

Structured elaboration

Classification. People (training, staffing, or awareness gaps, like nobody being reachable at the right time), process (a missing, wrong, or unclear runbook step), or technology (a system or tooling failure). Many findings are genuinely two categories at once, for example an automated failover script that failed is a technology issue, but nobody catching the error before the drill is a process issue in the review or testing procedure itself; classify the root cause that, if fixed, prevents recurrence, not just the surface symptom.

Severity and ownership. Score each finding by business impact: does it threaten a documented recovery time objective (RTO, the target time to get a function working again) or recovery point objective (RPO, how much recent data the function can afford to lose, measured in time), or does it block declaration authority (who has the standing to formally declare and activate the plan) entirely? Assign one accountable owner per finding, with a sponsor who can escalate if it stalls. Critical findings get the shortest fuse and the most visible tracking.

Verification before closure. The distinction that matters most: "marked done" is not the same as "closed." A finding should only close once there's an independent verification test, ideally at the next scheduled exercise from the tabletop-to-full-scale ladder, confirming the fix actually works, not a self-report from the person who made the change.

Governance cadence and trend metrics. Individual findings feed a recurring review, for example a quarterly continuity steering meeting, that tracks two things at the aggregate level: how quickly findings are actually closing (with verification, not just ticket status), and whether the same root cause is recurring across drills, which indicates the underlying plan or system was never really fixed the first time. This is what turns a series of one-off reviews into evidence the program is maturing, and it's also the artifact regulators and auditors typically want (see the regulatory-obligations answer on this topic for what a compliance program expects to see documented).

Tooling. Track findings in a central, auditable system (a ticketing tool with status, owner, and due date, not a slide deck that gets archived and forgotten), since the whole point of the review is a defensible trail from finding to verified fix.

Worked example

A team ran four quarterly drills and tracked how many days it took to close each Critical finding, from the day it was logged to the day its verification test passed. In Q3, five Critical findings closed with these lead times in days: 12, 18, 21, 25, and 29.

That 21-day average, tracked quarter over quarter alongside a second metric (the percentage of findings that recur in a later drill), is what the quarterly steering review actually looks at. A shrinking average close time with a low recurrence rate is real evidence the program is improving; a shrinking close time with a high recurrence rate usually means findings are being marked closed to hit the metric without the underlying gap actually being fixed, which is exactly why the verification-test requirement exists.

Trade-offs and pitfalls

Measuring only closure speed creates a perverse incentive to close findings before they're actually fixed, which is why speed has to be paired with a recurrence-rate metric, not tracked alone. Remediation work reliably stalls when the team is busy with feature delivery unless a named executive sponsor has the standing to protect capacity for it; without that sponsor, "we'll get to it" quietly becomes never. It's also worth being explicit about what this process is not: it's a review of the continuity plan and program itself, not a technical incident post-mortem of a system failure, so the findings and remediation often land on documentation, staffing, and ownership as often as they land on a system fix.

Direct answer

Tailoring a pitch means finding out what that specific stakeholder is actually measured on or afraid of, and reframing the same underlying facts through that lens, rather than repeating your own rationale and hoping it lands. The facts stay fixed; only the framing and the risk language change per audience.

Structured elaboration

Incentive-mapping framework. Before drafting anything, identify what the stakeholder optimizes for and what they fear, then reframe the same evidence in that currency:

A common variant of this: translating a technical or security risk into business-impact terms to win executive buy-in. The reframe isn't inventing a new argument; it's restating the same risk in the currency the executive is accountable for (revenue at risk, compliance exposure, customer churn) instead of engineering terms (a vulnerability class, a latency percentile).

Worked example

Situation. At a platform company, engineering wanted budget approval to fix an authentication vulnerability class a penetration test had flagged. The CFO's first read was that this belonged in the engineering backlog, not an urgent ask.

Stakes. The unpatched vulnerability class carried real breach and compliance exposure, but it was competing for the same budget cycle as revenue-generating projects, and the CFO wasn't going to fund it on engineering language alone.

The influence moves.

• Learned the CFO's actual incentive: quarterly budget defensibility and avoiding one-time crisis spend, not an abstract security posture.
• Reframed the same evidence in the CFO's terms: translated "session tokens that don't expire" into an exposure-window estimate and a cost comparison against the company's own past incident-response spend, the same kind of trade-off the CFO already used elsewhere.
• Built a separate, differently framed one-pager for the security lead from the same underlying evidence: audit and control-mapping language, naming which control had failed and which policy clause it mapped to, instead of repeating the CFO pitch.
• Verified the incentive rather than assuming it, by asking the CFO's chief of staff beforehand what kind of comparison the CFO typically used to evaluate risk spend.

Resolution. The CFO approved the fix as a scheduled, budgeted project rather than an emergency spend, because the exposure was quantified and mapped to a comparison already familiar from other risk trade-offs.

What a senior candidate does differently. A mid-level candidate builds one deck and hopes it lands for everyone. A senior candidate keeps the underlying evidence fixed and swaps only the framing and incentive language per audience, and can explain, in the room, why that phrasing fits that specific person.

Trade-offs and pitfalls

• Tailoring is not spin. The underlying facts must be identical across audiences. If the CFO version and the CISO version (CISO: Chief Information Security Officer, the same person referred to earlier in this example as "the security lead") would lead a skeptical listener to different conclusions about severity, that's manipulation, not tailoring.
• Guessing the wrong incentive misses as badly as not tailoring at all. Verify the incentive with a quick question rather than assuming it from a title.
• Prep cost. Building a separately framed pitch per audience takes real time; reserve heavy tailoring for stakeholders whose buy-in is genuinely load-bearing for the decision.

Direct answer

Scaling a team from roughly 5 to 50 people while preserving candor and psychological safety means deliberately converting practices that worked informally at small scale (everyone just knew the norms) into explicit, documented structures before the informal version breaks down, rather than waiting until it already has.

Structured elaboration

1. Hiring criteria. Screen explicitly for candor and comfort with feedback, not just technical skill, since a small number of hires who are defensive about critique can quietly shift a team's norms faster than any process can counter. Include a structured interview stage that probes how a candidate has handled being wrong or challenged in the past.
2. Organizational structure. Split into smaller sub-teams (pods or chapters of 5 to 8) before the whole-group size makes candor feel risky, since psychological safety is much easier to sustain in a group where everyone knows everyone than in a room of 50. Keep a clear owner for culture within each pod, not just at the top.
3. Onboarding. Make the team's actual norms around candor and mistake-reporting an explicit part of onboarding, with real examples, rather than assuming new hires will absorb it by observation, since observation-only onboarding is exactly what breaks down as headcount grows and new hires increasingly onboard from peers who are also new.
4. Communication rituals. Preserve at least one regular, small-group forum (not just all-hands) where junior members interact directly with senior leadership, since large-group settings systematically suppress the same voices that a 5-person team never had to worry about.
5. Decision rights. Document who decides what as the team grows, since ambiguity about decision rights at scale creates exactly the kind of quiet frustration and unaddressed disagreement that erodes safety over time.
6. Propagation and drift detection. Run a lightweight, anonymous pulse check periodically, segmented by pod or tenure, specifically to catch drift early (newer joiners or a particular pod reporting lower safety) before it becomes a pattern across the whole organization.

Worked example

At 8 people, the team relies on a single weekly meeting where anyone can raise anything, and it works because everyone already trusts everyone. At 25 people, that same meeting has quietly become a forum where only the four most senior people speak, so the team splits into pods of 6, each running its own version of that ritual, with a monthly all-pod sync led by rotating hosts rather than always the most senior voice. At 50 people, a pulse survey shows one newer pod reporting noticeably lower safety scores than the others; investigating finds that pod's lead came from a much more hierarchical background and had not been through the same onboarding on the team's norms, which gets addressed directly rather than assumed away.

Trade-offs and pitfalls

The main pitfall is assuming that what worked informally at small scale will simply continue to work if you just keep doing the same things, without noticing that the same practice (one big meeting, one set of unwritten norms) has different, worse effects at 10x the headcount. A second pitfall is over-formalizing too early, turning a small, trusted team into a bureaucracy before it needs one, which can suppress the very candor it is trying to protect.

Direct answer
Write a resource block of the correct type declaring only the arguments you intend to manage, run terraform import (or a declarative import block) to attach the real resource's ID to that address, then run terraform plan repeatedly, reconciling your HCL against what it reports, until plan shows no diff. Only then does apply touch anything, and by that point it's a no-op. Nothing about the live VPC or database changes during any of this, because import only writes state and plan never mutates anything, so the "without downtime" requirement is really just discipline about not applying until plan is clean.

Structured elaboration

1. Inspect the real resource before writing HCL
Don't write the resource block from memory. Look up the actual current attributes (via the console, CLI, or the provider's data source) so your first draft doesn't propose spurious changes the moment you import.

2. Write the minimal matching resource block
Keep it to the arguments you actually plan to manage going forward; leave out fields you expect the provider to compute (endpoints, generated ARNs) rather than guessing values for them.

resource "aws_db_instance" "example" {
  identifier = "my-db-identifier"
  # do not add attributes you expect AWS to compute (endpoint, address)
}

3. Import

terraform import aws_db_instance.example my-db-identifier

As of Terraform 1.5+ you can express the same step declaratively with an import block plus terraform plan -generate-config-out=generated.tf, which scaffolds a starting resource block for you instead of hand-writing one, useful when importing many resources at once.

4. Reconcile computed and drifted attributes
Run terraform plan. Anything present in the real resource but missing or different in your HCL shows up as a proposed change. For attributes the provider computes and you don't want Terraform fighting over (an RDS endpoint, a final snapshot identifier), either add the real value explicitly if you want to manage it, or mark it in a lifecycle block so Terraform stops treating drift there as something to fix.

lifecycle {
  ignore_changes = [endpoint, address]
}

5. Verify, then only apply if you mean to change something
terraform state show aws_db_instance.example confirms the mapped ID and attributes. Keep iterating on plan until it's clean. If you genuinely want to change a value going forward, that apply is a deliberate, reviewed change, not an accidental side effect of the import.

Nested/child resources aren't imported automatically
A hand-built VPC or database typically has dependent pieces, a DB subnet group, associated security groups, route tables, that each need their own import call. Importing the parent resource doesn't pull its children into management for you.

Worked example
Importing a hand-built RDS instance end to end:

terraform import aws_db_instance.example my-db-identifier
terraform state show aws_db_instance.example
terraform plan

A first plan on a genuinely hand-built instance will usually show a handful of proposed changes on computed fields like endpoint, address, and tags_all, since those were never in your HCL to begin with. You add ignore_changes for the ones you don't want to manage and explicit values for the ones you do, then re-run plan until it's a clean no-op, which is your confirmation that apply is now safe.

Trade-offs & pitfalls
Skipping the "inspect the real resource first" step is the most common way this goes wrong: you import, run plan, and discover it wants to replace the DB instance's engine or storage_type because you guessed a value instead of reading the real one, right after the whole point was to avoid touching it. Always back up state before starting (terraform state pull > backup.tfstate), and where possible rehearse the import against a non-production copy of the resource type first. Bulk-importing dozens of hand-built resources one CLI call at a time doesn't scale, that's what the 1.5+ import block with -generate-config-out is for.

Direct answer

The real difference isn't seniority, it's what you spend your energy multiplying. An individual contributor multiplies impact by going deeper into their own craft; a manager multiplies impact through other people's work, spending most of the day on unblocking, coaching, and prioritizing rather than building it themselves. Say which pull is stronger for you right now, and back it with a concrete signal, not just a stated preference.

Structured elaboration

To build the answer:

1. Name the actual mechanism each track uses to create impact, deepening a skill versus multiplying people.
2. Self-assess honestly against a real moment: did you want to take the hard problem yourself, or did you want someone else to grow by taking it?
3. Note the choice usually isn't permanent, many organizations support lateral moves or parallel tracks, which softens the stakes of naming a current lean.
4. Answer with a directional preference plus the evidence, not a hedge like "I like both equally."

Worked example

"A few months ago I had a choice: take point on a hard, ambiguous problem myself, or step back and let a newer teammate lead it while I coached from the side. I chose the second, on purpose, and noticed I got more satisfaction watching them work through the ambiguity and land the decision than I think I'd have gotten from solving it myself. That's the kind of moment I look back on when I say I'm currently drawn toward management, not just a stated preference."

Trade-offs & pitfalls

• Answering only in the abstract, "management is about people, the other track is about the work", with no self-assessment signal is incomplete.
• Presenting one track as inherently more senior or more valuable is a red flag to interviewers whose organizations run dual-track ladders on purpose.
• Treating the choice as permanent and irreversible, when in most organizations it isn't, overstates the stakes.
• A flat "I like both equally" with no lean reads as indecisive. Better to name a lean plus what genuinely still appeals about the other path.