Cloud Engineer Projects That Actually Create Conversation

CONVERSATION PROJECT — FIRST 90 SECONDS:

Interviewer: "Tell me about a cloud project
you're proud of."

Candidate: "Sure. Let me start with the
problem, because that's where the
conversation is.

We had a 4-service app — API, worker, a
nightly ETL, and a reporting service — all on
EC2 with on-demand instances. The monthly bill
was $12K, and the ETL alone was $4K because it
ran on an on-demand m5.2xlarge for 6 hours a
night.

What I did: three changes.

One: I moved the API and worker to ECS Fargate
— the cost is less control over the host, but
we stopped paying for idle EC2 capacity, and
the autoscaling is per-task instead of
per-instance.

Two: I rightsized the instances — 30 days of
CloudWatch showed 40 instances running under
15% CPU. I downsized them and added an
autoscaling group that scales past the old
size if CPU crosses 70%.

Three: I moved the ETL to spot with a
fallback to on-demand after 3 minutes. The
cost: the ETL is occasionally 20 minutes late.
We accepted it because the SLA is 6 AM and the
ETL finishes by 4.

The trade-off I'd revisit: the spot move
saves the most, but it's the most likely to
page someone. If it pages more than twice a
quarter, I'd move it back to on-demand.

The result: the bill went from $12K to $8K —
32% — and the on-call load didn't go up.

I can show you the cost breakdown and the
fallback."

What the interviewer thinks in 90 seconds:
- "They started with a problem." ✅
- "Three changes, each with a cost." ✅
- "The fallback is designed, not hoped for." ✅
- "The result is a number: 32%." ✅
- "I want to ask about the spot fallback." ✅

Signal: conversation. The next 20 minutes are
about the project.

SILENT PROJECT — FIRST 90 SECONDS:

Interviewer: "Tell me about a cloud project
you're proud of."

Candidate: "I built a 3-tier app on AWS. I
used EC2 for the web tier, RDS for the
database, and S3 for static assets. I set up a
VPC with public and private subnets, and I
used a load balancer. I deployed it with
Terraform and it worked well."

What the interviewer thinks in 90 seconds:
- "A service list, not a problem." ❌
- "No cost, no number." ❌
- "No failure mode." ❌
- "This is the AWS tutorial with a different
  name." ❌
- "I have no follow-up question." ❌

What happens next:
- The interviewer asks "What was the cost?"
- The candidate says "It was within the free
  tier."
- The interviewer asks "What would you do
  differently at scale?"
- The candidate gives a generic answer.

Signal: silence. The project doesn't create
conversation because it has no problem, no
cost, and no failure.

Why it failed:
❌ Service list, not a problem
❌ No cost
❌ No failure mode
❌ No trade-off
❌ The description is the same as every
  other AWS tutorial

COST BREAKDOWN — WHAT DECIDES:

Interviewer: "Walk me through the 32%."

WHAT THE CANDIDATE SAYS:
"Three changes, and each has a number and a
cost.

Change one: rightsizing. I pulled 30 days of
CloudWatch and found 40 instances running
under 15% CPU. I downsized m5.2xlarge to
m5.large — that's $2K a month, about 17% of
the bill. The risk: a traffic spike. I added
an autoscaling group that scales past the old
size if CPU crosses 70%, and I ran the
downsized instances through a load test
first.

Change two: spot for the ETL. The nightly ETL
ran on on-demand for 6 hours — $4K a month.
Spot is 70% cheaper, so it's $1.2K. The cost:
the spot can be reclaimed. I added a fallback
to on-demand after 3 minutes, and the ETL is
occasionally 20 minutes late. The SLA is 6 AM;
the ETL finishes by 4.

Change three: Fargate for the API and worker.
We were paying for idle EC2 capacity — about
60% idle at night. Fargate is per-task, so
the idle cost goes away. That's $0.5K a month.
The cost: less control over the host, and a
cold start on scale-out.

The total: $2K + $2.8K + $0.5K — wait, let me
be precise. The spot save is $2.8K, not $1.5K.
So: $2K rightsizing + $2.8K spot + $0.5K
Fargate = $5.3K. The bill went from $12K to
$6.7K, so the actual save was 44%, not 32%.
The 32% was after I added the canary and the
logging costs back.

I can show you the cost breakdown in
Cost Explorer."

What the interviewer thinks:
- "Three changes, each with a number." ✅
- "Each has a risk and a mitigation." ✅
- "The math is self-corrected, not
  hand-waved." ✅
- "The canary and logging costs are added
  back honestly." ✅
- "This is someone who reads the bill." ✅

Signal: confirmed conversation.

Why it decides:
✅ Changes have numbers
✅ Risks have mitigations
✅ Math is self-corrected
✅ Net cost is honest
✅ The interviewer has three follow-ups

SECURITY TRADE-OFF — WHAT DECIDES:

Interviewer: "What about security?"

WHAT THE CANDIDATE SAYS:
"Three security decisions, and each has a
trade-off.

Decision one: secrets. The app read a
database password from an environment
variable. That's a static key — it doesn't
rotate, and it shows up in a container
inspect. I moved it to Secrets Manager with
30-day rotation. The cost: the app restarts
every 30 days to pick up the new secret, and
that's a 10-second blip. I accepted that
because a static key is a breach waiting to
happen.

Decision two: network. The RDS instance was
in a public subnet. I moved it to a private
subnet with a security group that only allows
traffic from the API. The cost: debugging is
harder — I have to use a bastion or SSM
Session Manager. I chose SSM because it
doesn't need a bastion host, and it logs every
session.

Decision three: IAM. The worker had
AdministratorAccess — it was set up that way
'just to get it working.' I scoped it to the
three actions it actually uses: SQS receive,
S3 put, and CloudWatch put. The cost: a new
feature needs an IAM update, which is a
5-minute ticket. I accepted that because an
over-privileged role is the most common
breach vector.

The trade-off I'd revisit: the 30-day secret
rotation is aggressive. At 90 days it would
blip less often. I chose 30 because the
database password is the highest-value secret
in the app.

The result: the security review passed
without a finding."

What the interviewer thinks:
- "Three decisions, each with a trade-off." ✅
- "The cost of each is named." ✅
- "The reasoning is risk-based." ✅
- "The revisit has a justification." ✅
- "This is production thinking." ✅

Signal: confirmed conversation.

Why it decides:
✅ Decisions are specific
✅ Trade-offs are named
✅ Reasoning is risk-based
✅ Revisit is justified
✅ The result is a review outcome

DEBUGGING STORY — CONVERSATION VS. SILENT:

Scenario: "Tell me about a cloud incident."

SILENT SIGNAL:
"One time an EC2 instance went down and I
restarted it. It was fine after that."
What the interviewer thinks:
- "No root cause."
- "No prevention."
- "That's an ops ticket, not an incident."
- Signal: silent.

CONVERSATION SIGNAL:
"The API had a 40-minute outage on a Friday.
Here's the timeline and what I changed.

The timeline: 14:02, the p99 latency alarm
fires. 14:08, the API is timing out. 14:12, I
see the RDS connection count is at max. 14:20,
I add a read replica and route the reporting
queries to it. 14:42, the API recovers.

The root cause: a new reporting query scanned
the whole orders table without an index. It
held connections for 30 seconds each, and the
pool of 20 was exhausted. The query had passed
code review — no one caught the missing index.

The fix: I added the index, and I added a
connection pool alert at 80% utilization, so
the next query like this pages before it takes
down the API.

The prevention: I added a query-time check in
CI — any query over 5 seconds on a staging
dataset fails the build. That caught two more
unindexed queries in the same month.

The trade-off: the read replica doubles the
RDS cost — about $800 a month. I accepted it
because 40 minutes of API downtime costs far
more than $800, and the reporting queries
will keep growing.

The lesson: a connection pool is a shared
resource, and one slow query can exhaust it.
I now alert on pool utilization before the
latency alarm."

What the interviewer thinks:
- "They owned the timeline." ✅
- "The root cause is specific: a missing
  index." ✅
- "The fix is a prevention, not a patch." ✅
- "The cost of the prevention is named." ✅
- "This is a production operator." ✅
- Signal: confirmed conversation.

Why it decides:
✅ Timeline is specific
✅ Root cause is a missing index
✅ Fix prevents the class
✅ Cost is named
✅ Lesson is reusable

TAKE-HOME REVIEW — CONVERSATION VS. SILENT:

Scenario: "Review this take-home. Both
candidates deployed a 3-tier app."

SILENT TAKE-HOME:
- EC2, RDS, S3, a load balancer
- Terraform that deploys the happy path
- No cost estimate
- No failure handling
- No README

What the interviewer thinks:
- "It's the AWS tutorial."
- "No cost, no failure handling."
- "I can't tell what they'd do in
  production."
- Signal: silent.

CONVERSATION TAKE-HOME:
- The same 3-tier app, plus:
- A cost estimate: $340/month, with a
  breakdown by service
- A failure section: "If the RDS instance
  fails, the app is down for 10 minutes —
  here's why I didn't add Multi-AZ ($180
  more a month) and when I would"
- A security note: "Secrets in SSM, not
  env vars; IAM scoped to 3 actions"
- A README with: the design decisions,
  the trade-offs, the cost, and a "what I'd
  change at 10x scale" section
- A backup and restore test: "I deleted the
  database and restored from the snapshot in
  8 minutes"

What the interviewer thinks:
- "The cost is estimated, not guessed." ✅
- "The failure section is honest about
  Multi-AZ." ✅
- "Security is scoped." ✅
- "The README has decisions and
  trade-offs." ✅
- "They tested the restore." ✅
- Signal: confirmed conversation.

Why it decides:
✅ Cost is estimated
✅ Failure is honest
✅ Security is scoped
✅ README has trade-offs
✅ Restore is tested

Cloud Project Conversation Checklist:

FIRST 90 SECONDS:
☐ Name a problem: the bill, the outage,
  the slow deploy
☐ Name a cost with a number: $12K → $8K,
  40 min → 6 min
☐ Name a failure mode: spot reclaim,
  missing probe, exhausted pool
☐ Avoid "I built a 3-tier app on AWS"

WHAT DECIDES:
☐ Break the cost down by change
☐ Name a fallback for the failure
☐ Name a security trade-off: secrets,
  network, IAM
☐ Name a trade-off you'd revisit with a
  trigger

WHAT CONFIRMS:
☐ Show a live app, a repo, or a diagram
☐ Estimate the monthly cost by service
☐ Test the restore or the rollback
☐ Name the next step at 10x scale
☐ Answer "what breaks?" without pausing

RED FLAGS:
❌ A service list with no problem
❌ No cost
❌ No failure mode
❌ No trade-offs
❌ "It worked well"
❌ Hard-coded secrets
❌ No README
❌ "I used the free tier"

Why this works:
- The first 90 seconds set the signal
- The rest of the conversation confirms or
  overturns it
- A cost, a failure, and a trade-off are
  the three things that create a
  conversation

30-DAY BUILD PLAN (FOR CANDIDATES):

Week 1 — Pick a real problem
☐ Find a problem in your own life, a
  club, or a side project
☐ Deploy the simplest version: one
  service, one database, one bucket
☐ Measure the cost: run it for a week and
  read the bill

Week 2 — Add a cost change
☐ Rightsize: pull 7 days of metrics, find
  the underused resource
☐ Move one batch job to spot or a
  scheduled task
☐ Measure the before/after cost
☐ Write the trade-off: what could break?

Week 3 — Add a failure and a fallback
☐ Break it on purpose: kill the instance,
  revoke the secret
☐ Write the fallback: retry, canary,
  multi-AZ
☐ Write the cost of the fallback
☐ Test the restore or the rollback

Week 4 — Add security and a README
☐ Move secrets to a managed store
☐ Scope the IAM role to what the app uses
☐ Write the README: problem, cost,
  failure, trade-offs, next step
☐ Record a 90-second walkthrough

Signs it's working:
✅ You start with a problem, not a
  service
✅ You have a cost number
✅ You have a fallback for a failure
✅ You have a security trade-off
✅ You can answer "what breaks?"
✅ The interviewer asks "tell me more"
  instead of "what else did you use?"