Interview Prep

The saving is durable only if it's a control loop, not a project: usage drifts, so recommendations must run continuously (VPA in recommendation mode) with policy-as-code preventing regression at admission time. The trade is a defined headroom band derived from our latency SLO, we intentionally leave slack as priced insurance against tail latency, because queueing behavior makes the last few points of utilization the most expensive in latency terms. I report the result as both cost per month and days of runway added, and I can show the slack-versus-risk curve we're operating on.

The impostor syndrome: "I cut it once, but if it creeps back they'll say I never really fixed anything, and I can't promise it won't." The reality: You're not being asked to promise permanence; you're being asked to show a control loop and a named safety margin. "Durable because it's continuous, bounded because it's tied to our SLO" is a stronger answer than any one-time number, and it's true.

Three bounds. First, high-criticality workloads run VPA in recommendation mode with a human gate, not auto-eviction. Second, min/max request bounds cap how far any recommendation can move, and PodDisruptionBudgets cap concurrent eviction. Third, I treat CPU and memory asymmetrically: CPU under-provisioning throttles and self-heals, so I tune it tighter; memory under-provisioning OOMKills, so I keep a wider margin. And I never run HPA and VPA on the same CPU signal, they fight. The failure mode is contained to graceful degradation, not cascading crash.

The impostor syndrome: "If I let automation set requests and it takes down a service, that's on me, maybe I shouldn't automate at all." The reality: Bounding blast radius is a design skill, not a leap of faith. Recommendation-mode gating, min/max bounds, PDBs, and the CPU/memory asymmetry are concrete guardrails; knowing them is exactly what separates competent automation from reckless automation, and you now know them.

Cost allocation by namespace and labels, surfaced as per-team showback under the FinOps Inform phase, so the engineer who sets the request sees the bill, that closes the externality where the app team feels the pager but not the cost. We enforce request presence and sane request-to-limit ratios with admission policy (OPA/Kyverno), so "no unbounded pods" is a control, not a convention, which is simultaneously a cost guardrail and an availability guardrail against noisy-neighbor starvation. Ownership sits with the app teams via a platform paved road; the platform team provides the capability, not a policing function.

The impostor syndrome: "I can fix the config, but making other teams own their costs sounds like org politics I have no authority over." The reality: You don't need authority to change behavior, you need visibility. Showback and a thin admission-policy floor let the incentive do the work; you're building a paved road, not policing people, and that's system design, not a political campaign.

This is a pillar collision between Security (encryption-in-transit/at-rest) and Performance (latency) and Team Velocity (launch timeline). Do not pretend there is a "right answer", there is a business trade-off to be made. Frame it this way:

"Encryption overhead is real, and the 15% latency tax is quantifiable. Our question is: What is the customer value of launching in 6 weeks vs. 12 weeks with strong encryption? If the market window is critical (launch before a competitor), we may delay encryption and implement it post-launch, accepting temporary risk. If our customers are data-sensitive (fintech, healthcare), the encryption delay is unacceptable. If we're building internal tools, the launch timeline wins. This is not a technical question, it's a business prioritization question, and the CSO, CTO, and CPO must decide together."

The impostor syndrome: "I don't know enough about encryption to make this call." The reality: You don't need to. You need to translate technical constraint into business trade-off language so executives can decide.

Spot instances have a termination risk. AWS can reclaim them with 2 minutes' notice. Reducing backup redundancy means longer Recovery Time Objective (RTO) if a region fails. The hidden costs are:

Operational risk: When a spot instance terminates mid-deployment, on-call engineers must scramble. This increases MTTR and on-call fatigue.

Reliability risk: Losing backup redundancy means a regional failure could result in multi-hour or multi-day recovery, triggering SLA penalties and customer churn.

Hidden cost: The "savings" of 20% ($X) may be offset by:

SLA penalties for missed uptime targets ($ of lost revenue)

On-call overtime and engineer burnout (turnover cost)

Customer churn from service degradation (lifetime value loss)

"The 20% cost reduction is real, but the residual risk is higher. We should model the probability of spot terminations and regional failures, then calculate expected financial impact. If the risk-adjusted cost of SLA breaches exceeds the $X savings, we should reject this initiative."

The impostor syndrome: "I'm not qualified to make CFO-level financial arguments." The reality: You are translating risk into language the CFO understands (expected value, SLA penalties, customer churn). That's your job as a technical leader.

No. The AWS review tool is a diagnostic, not a verdict. An 85/100 score might mean:

You have strong Security and Reliability (your business priorities), and weak Cost Optimization (intentional trade-off).

Or you have weak Performance and Operational Excellence (because you're a startup and launch velocity matters more).

A 95/100 score on all pillars equally is actually a red flag, it suggests you're over-provisioned, over-engineered, and burning money on pillars that don't matter to your business.

The right question is not "Are we well-architected?" but "Are we architected according to our business priorities?" If Security and Reliability are your pillars, and you score 95 on both with 70 on Cost, that's better than 85 on all five.

"A well-architected system is one that consciously prioritizes the pillars that protect shareholder value and explicitly accepts lower scores on pillars that are secondary. We should never aim for a high score on all pillars, that's over-engineering."

The impostor syndrome: "We didn't score 95, so we must be doing something wrong." The reality: Lower scores on secondary pillars are intentional and defensible business decisions.

“I don’t trust the generation, I gate it. The plan runs through policy-as-code (Checkov / OPA) enforcing least-privilege and CIS Benchmark baselines before it can merge; I reason about blast radius if a credential leaks, and I check the change against my side of the Shared Responsibility line for this service tier. The model’s job is a first draft; the control is the gate, and I own the gate.”

“Because generation got cheap and verification didn’t. Someone has to catch the plausible-but-wrong output, and accountability for a control attestation can’t be automated. Hiring and growing that verifier is also how you manufacture your next senior engineer, skip it and you’re buying senior talent in a thin market in three years at a premium. I’m the investment that protects revenue now and the pipeline later.”

“Authorship is irrelevant to threat modeling. I map data flows and trust boundaries, enumerate adversary tactics against each boundary using MITRE ATT&CK, and assume breach rather than assume correctness. AI-generated systems specifically demand this because surface area expands faster than informal review can track, so I model the system as it runs, not as it was written.”