Why Most Cloud Engineer Candidates Can't Defend Their Own Numbers

Interview Insights · Cloud Engineer

Why Most Cloud Engineer Candidates Can't Defend Their Own Numbers

SECTION 01The follow-ups every cloud metric on a resume invites

When I see a number on a cloud resume, I do not judge the size of it. I judge whether the candidate owns it. My questions are always the same four: what was it before, what did you change, how did you measure it, and over what period. A real number survives all four. A borrowed number usually fails at the first.

The most common problem is not lying. It is repeating a team number without knowing its source. Someone in the team said the bill dropped, it went on the resume, and nobody checked the details. In an interview that becomes a problem, because a number you cannot explain makes me doubt everything else on the page.

Interviewer: Your resume says you reduced AWS cost by 40%.
What was the bill before?

Candidate: I don't remember exactly. It was high.

Interviewer: What did you change?

Candidate: We moved some things to reserved instances
and cleaned up resources.

Interviewer: Which part did you do?

Candidate: ... the team decided most of it.

Interviewer: Your resume says you halved the dev account bill.
How do you know?

Candidate: I compared the same two months in Cost Explorer,
grouped by service. EC2 was most of the dev bill, and
the instances ran all night and at weekends.

I added an EventBridge schedule that stopped tagged dev
instances in the evening and started them in the morning.
The next month's EC2 line was roughly half.

One caveat: some of the drop came from a project ending
the same month, so I would say the schedule caused most
of it, not all of it.

The second answer is strong because of the caveat at the end. Admitting that another factor helped makes the rest of the claim more believable, not less. Interviewers who work with real cloud bills know that savings rarely have a single clean cause.

SECTION 02Uptime percentages: do the downtime maths first

Uptime claims are the numbers candidates understand least. Many write 99.9% because it sounds professional, without knowing what it means in minutes. If I ask 'how much downtime does 99.9% allow in a month?', the room often goes quiet. The calculation is simple, and doing it in front of me is a strong signal.

A month has about 30.44 days on average, which is 43,830 minutes. 99.9% availability allows 0.1% of that as downtime, so about 43.8 minutes. Each extra nine divides the allowance by ten. Knowing this also stops you from confusing the provider's service level agreement for one service with your application's actual uptime, which depends on your own design.

MINUTES_PER_MONTH = 30.44 * 24 * 60   # average month

def allowed_downtime(availability_pct):
    return MINUTES_PER_MONTH * (1 - availability_pct / 100)

for a in (99.0, 99.9, 99.95, 99.99):
    print(f"{a}% -> {allowed_downtime(a):.1f} minutes per month")

# Output:
# 99.0% -> 438.3 minutes per month
# 99.9% -> 43.8 minutes per month
# 99.95% -> 21.9 minutes per month
# 99.99% -> 4.4 minutes per month

# Total requests and 5XX errors from targets over 30 days
aws cloudwatch get-metric-statistics \
  --namespace AWS/ApplicationELB --metric-name RequestCount \
  --dimensions Name=LoadBalancer,Value=app/web-alb/0123456789abcdef \
  --start-time 2026-10-01T00:00:00Z --end-time 2026-10-31T00:00:00Z \
  --period 86400 --statistics Sum

aws cloudwatch get-metric-statistics \
  --namespace AWS/ApplicationELB --metric-name HTTPCode_Target_5XX_Count \
  --dimensions Name=LoadBalancer,Value=app/web-alb/0123456789abcdef \
  --start-time 2026-10-01T00:00:00Z --end-time 2026-10-31T00:00:00Z \
  --period 86400 --statistics Sum

# Request success rate = 1 - (sum of 5XX / sum of requests)

Be precise about what you measured. A request success rate from the load balancer is not the same as time-based uptime from an external health check, and neither covers errors the load balancer itself returns, which appear in HTTPCode_ELB_5XX_Count. Saying 'I measured request success rate from ALB metrics, which does not catch every failure' is a mature answer that most candidates never give.

SECTION 03Cost savings: pull the baseline from Cost Explorer

Cost numbers are the easiest to defend, because AWS keeps the data for you. Cost Explorer shows spend by month and by service, and the same data is available from the CLI. If you claim a saving, you should be able to say which service changed, by roughly how much, and which action caused it.

The most defensible cost claims are about specific, simple actions: stopping idle dev instances outside working hours, deleting unattached EBS volumes and old snapshots, right-sizing an over-sized instance after checking CPU, or moving rarely read S3 data to a cheaper storage class. Each has a clear before, a clear change and a clear after.

# Monthly cost per service for two months
aws ce get-cost-and-usage \
  --time-period Start=2026-09-01,End=2026-11-01 \
  --granularity MONTHLY \
  --metrics UnblendedCost \
  --group-by Type=DIMENSION,Key=SERVICE \
  --query "ResultsByTime[].{Month:TimePeriod.Start,Groups:Groups[].[Keys[0],Metrics.UnblendedCost.Amount]}"

# Note: End date is exclusive, so this covers
# September and October.

# Unattached EBS volumes (paying for storage, used by nothing)
aws ec2 describe-volumes \
  --filters Name=status,Values=available \
  --query "Volumes[].{Id:VolumeId,SizeGiB:Size,Type:VolumeType,Created:CreateTime}" \
  --output table

# Average CPU of an instance over 14 days, one value per day
aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=i-0abc1234def567890 \
  --start-time 2026-10-28T00:00:00Z --end-time 2026-11-11T00:00:00Z \
  --period 86400 --statistics Average Maximum

Read the output service by service rather than only the total. A total that dropped can hide one service that grew, and an interviewer who works with cloud bills may ask exactly that: did anything go up while the main line went down?

If you only worked on a personal or free-tier account, your numbers will be tiny. That is fine. 'My lab bill went from a few hundred rupees to almost nothing after I added a destroy habit and a budget alarm' is a real, defensible story. Small and true beats large and borrowed every time.

SECTION 04Worksheet to rebuild every number on your resume

Go through your resume line by line. For each number, fill in this worksheet. If you cannot complete it, rewrite the line with a smaller claim you can support, or replace the number with a clear description of what you did.

RESUME LINE: _________________________________

BASELINE
  Value before: __________  Period: __________
  Source: Cost Explorer / CloudWatch / logs / other: ____

CHANGE
  What I personally did: ___________________________
  What the team did: _______________________________

METHOD
  How the after value was measured: ________________

RESULT
  Value after: __________  Same length period? Y / N

CAVEAT
  Anything else that could explain the change: ______

BEFORE: Reduced AWS cost by 40%.
AFTER:  Scheduled nightly stops for tagged dev EC2
        instances with EventBridge; the dev account's
        EC2 cost roughly halved the following month.

BEFORE: Maintained 99.9% uptime.
AFTER:  Moved the app to a two-AZ Auto Scaling group
        behind an ALB with health checks; tracked request
        success rate from ALB metrics.

BEFORE: Improved deployment speed significantly.
AFTER:  Added Docker layer caching to the CI build,
        cutting the image build step noticeably.

Have a friend ask these about EACH number:

1. What was it before, exactly?
2. Over what time period?
3. Where did you read the figure?
4. What did YOU do, not the team?
5. What else changed at the same time?
6. How would you measure it again today?

Pass rule: you answer all six without saying
'I think' or 'roughly, I don't know'.
If you fail one, fix the resume line tonight.

SECTION 05Habits that keep your cloud numbers honest

Numbers are powerful on a cloud resume when they come with evidence. These habits make sure every figure helps you instead of trapping you.

• Write the baseline down — When you make a change at work or in a lab, note the before value and the date the same day. You will not remember it later.
• Separate you from the team — Use 'I' for what you did and 'we' for the team result, so the interviewer never has to guess your share.
• Name the tool — Saying 'Cost Explorer grouped by service' or 'ALB 5XX metrics' immediately makes a number sound measured rather than remembered.
• Add one caveat — Mentioning another factor that may have helped makes your main claim more credible to experienced interviewers.
• Drop what you cannot rebuild — If you cannot trace a number to data, replace it with a clear description of the change. A clear action is still a strong line.

SECTION 06Interview Q&A — Cloud resume numbers

SECTION 07Test yourself — Cloud resume numbers quiz

SECTION 08Frequently asked questions

SECTION 09Related reads