Common Cloud Engineer Interview Mistakes & Solutions

Fundamentals — Answer Drill

DRILL 1: Requirement → Service → Trade-off
Q: "How would you host a static site?"
✓ "It's read-heavy and public, so S3 + CloudFront.
   Trade-off: cache invalidation adds deployment steps,
   but egress cost drops and latency improves globally."

DRILL 2: Honest gap
Q: "How does EKS Fargate pricing work?"
✓ "I've used EKS with managed node groups, not Fargate.
   I know Fargate prices per pod-second and removes node
   management — I'd check the docs for exact tiering
   before designing around it."
✗ Never invent numbers you don't know.

DRILL 3: Cost line
Q: "Design a log pipeline."
✓ "...and cost-wise, log retention is the main lever —
   move older logs to cheaper storage after 30 days."

DRILL 4: IAM
Q: "How does the app read from S3?"
✓ "An IAM role attached to the compute, scoped to
   one bucket and read-only. No access keys in code."

Self-Review after every answer:

□ Did I say what I actually know vs assume?
□ Did I name a requirement before a service?
□ Did I mention cost at least once?
□ Did I mention security / IAM?
□ Was I under 90 seconds?

If any box is unchecked, redo the same answer aloud.
Same question, better structure — not a new question.

System design — 6-point checklist

1. CLARIFY (60 seconds, before anything else)
   ☐ Expected traffic / users
   ☐ Read vs write ratio
   ☐ Consistency requirement
   ☐ Budget sensitivity
   ☐ Compliance / data residency

2. SKETCH THE FLOW
   ☐ Client → entry point → compute → data
   ☐ Where does state live?

3. FAILURE
   ☐ Multi-AZ? Multi-region?
   ☐ What happens if the DB is down?

4. OBSERVABILITY
   ☐ Logs, metrics, traces
   ☐ Which alert fires first?

5. COST
   ☐ Biggest cost driver named
   ☐ One optimisation suggested

6. DELIVERY
   ☐ How does code get there?
   ☐ How do you roll back?

Trade-off script (use this sentence structure):

"Given , I'd choose 
 because . The cost of that is .
 If  changed, I'd switch to ."

Example:
"Given the read-heavy traffic, I'd put CloudFront in
 front of the API because it cuts latency and egress.
 The cost is cache invalidation complexity. If the data
 became user-specific and uncacheable, I'd drop
 CloudFront for the API path and keep it for static
 assets only."

Why this works:
- You show the requirement drove the choice
- You show you know the downside
- You show you can adapt if conditions change

STAR for cloud engineers — 90 seconds

SITUATION (15s)
"Our staging cluster was failing deploys every Friday
 release because the node pool ran out of memory."

TASK (10s)
"I owned the deploy pipeline for that service and was
 asked to make releases predictable."

ACTION (40s)
"I did three things:
 1. Added a memory limit and HPA on the deployment.
 2. Moved the build to a separate node group so it
    couldn't starve app pods.
 3. Added a pre-deploy check that blocked the pipeline
    if memory headroom was under 20%."

RESULT (15s)
"Deploy failures dropped from 3 a month to zero over
 the next quarter, and release time went from 45 to
 12 minutes."

Why it works:
- One metric in, one metric out
- "I did three things" — countable actions
- No blame, just the system fix

Red flags in your own answers — cut these:

✗ "We just kind of figured it out"
✗ "The DevOps team never gave us..."  (blame)
✗ "It was a huge improvement"          (no number)
✗ "We used a lot of tools"             (no specifics)
✗ Two-minute setup before any action
✗ A story with no decision you made
✗ A "failure" that wasn't actually a failure
✗ Saying "I don't really remember the details"

Replace each with:
✓ The specific decision you made
✓ The measurable before/after
✓ What you'd do differently
✓ Who you worked with and how

Cost question template:
"How would you reduce our cloud bill?"

Structure:
1. WHERE THE MONEY GOES
   "First I'd pull the cost explorer by service and tag.
    Usually compute, storage and egress dominate."

2. THE BIGGEST LEVER
   "Right-sizing and reserved capacity usually beat
    micro-optimisations. I'd check utilisation first."

3. NON-OBVIOUS COSTS
   "Storage lifecycle, idle resources, cross-AZ traffic
    and log retention are the quiet ones."

4. ONE SAFE FIRST WIN
   "Turn on lifecycle policies for old logs — low risk,
    immediate saving, no code change."

5. HOW YOU'D MEASURE IT
   "Before/after monthly cost on the same workload,
    not just the total bill."

Security question template:
"How do you secure this?"

Structure:
1. IDENTITY
   "Human access through SSO + role, service access
    through IAM roles — no long-lived keys in code."

2. LEAST PRIVILEGE
   "Policies scoped to the specific resource and action.
    Start narrow, widen only with a reason."

3. NETWORK
   "Private subnets for compute and data, security
    groups deny by default, no public DB endpoints."

4. DATA
   "Encryption at rest and in transit, key rotation,
    backups tested with a restore drill."

5. DETECTION
   "CloudTrail and access logs enabled, alerts on
    root login, policy changes and permission
    escalations."

Availability question template:
"What happens if this fails?"

Structure:
1. BLAST RADIUS
   "A single AZ failure takes down  for .
    Here's what's affected and what isn't."

2. FAILURE MODES
   "Instance loss, AZ loss, region loss, dependency
    outage — each has a different response."

3. MITIGATION
   "Multi-AZ by default. Read replicas for the DB.
    Health checks to drain unhealthy targets."

4. DEGRADATION
   "If the recommendation service is down, we serve
    a static fallback rather than erroring."

5. RECOVERY
   "RTO/RPO targets, backup restore tested quarterly,
    and an alert that fires before users notice."