What Separates a Memorized Answer From Real Cloud Engineer Skill

Interview Insights · Cloud Engineer

What Separates a Memorized Answer From Real Cloud Engineer Skill

SECTION 01The follow-up ladder that exposes a memorized cloud answer

If I ask 'what are the S3 storage classes?', most prepared candidates give a good list. Standard, Intelligent-Tiering, Standard-IA, One Zone-IA, the Glacier classes. That answer is fine, and it tells me almost nothing, because it can be learned from a single page.

So I climb. Rung two: we keep application logs for a year and look at them mostly in the first week. Which classes would you use? Rung three: what goes wrong if someone needs a log from month eight in a hurry? Rung four: the budget is tight and the team wants faster retrieval too. What do you decide? By rung three, the memorized answer usually runs out of material. The applied answer is just getting started.

Interviewer: Logs are read in the first week and kept
for a year. How would you store them?

Candidate: S3 has many storage classes like Standard,
Standard-IA, One Zone-IA, Intelligent-Tiering, Glacier
Instant Retrieval, Glacier Flexible Retrieval and
Glacier Deep Archive. Glacier is the cheapest, so I
would use Glacier.

(Correct facts, but no use of the access pattern,
and no mention of how data moves between classes.)

Interviewer: Same question.

Candidate: The access pattern is hot for a week, then
rare. So I would write to Standard, and add a lifecycle
rule: move to Standard-IA after 30 days, which is the
earliest IA transition allowed, then to Glacier after
about 90, and expire at 365.

The risk is retrieval. Glacier Flexible Retrieval is
not instant, so if people sometimes need old logs fast,
Glacier Instant Retrieval is the safer class for that
period. I would ask how often that really happens.

The applied answer ends with a question back to the interviewer. That is another sign of real skill: the candidate knows the right choice depends on information they do not have yet.

SECTION 02S3 lifecycle rules: a worked example of applied skill

Lifecycle rules are a good test because they force a memorized fact into a working configuration. Writing one correctly means knowing a few practical details that are rarely in summaries: transitions to Standard-IA need objects to be at least 30 days old, small objects are not always worth moving, and versioned buckets need separate rules for non-current versions.

If you can write and explain a rule like the one below, you have crossed from definition to application. If you can also say when you would not use it, you are near the top of the ladder.

{
  "Rules": [
    {
      "ID": "app-logs-tiering",
      "Status": "Enabled",
      "Filter": { "Prefix": "logs/" },
      "Transitions": [
        { "Days": 30, "StorageClass": "STANDARD_IA" },
        { "Days": 90, "StorageClass": "GLACIER" }
      ],
      "Expiration": { "Days": 365 },
      "NoncurrentVersionExpiration": { "NoncurrentDays": 30 }
    }
  ]
}

# Apply the rule (this replaces any existing lifecycle config)
aws s3api put-bucket-lifecycle-configuration \
  --bucket orders-app-logs \
  --lifecycle-configuration file://lifecycle.json

# Confirm what is now active
aws s3api get-bucket-lifecycle-configuration \
  --bucket orders-app-logs

# Check the storage class of a few older objects later
aws s3api list-objects-v2 \
  --bucket orders-app-logs --prefix logs/ \
  --query 'Contents[0:5].[Key,StorageClass,LastModified]' \
  --output table

One detail in the comment above is a strong signal on its own: put-bucket-lifecycle-configuration replaces the whole configuration. A candidate who has used it knows they must include existing rules or they will delete them. Candidates who only memorized the concept rarely know that.

SECTION 03Scaling policy choices that reveal hands-on experience

Auto scaling is the most memorized topic in cloud interviews. Nearly everyone can say it adds instances when load rises. Far fewer can say which policy type they chose, what metric they tracked and what surprised them when they tested it.

The surprise is usually time. A new instance has to launch, boot, install or start the app and pass health checks before it helps. That lag is why real engineers talk about warm-up time, minimum capacity and sometimes scheduled scaling ahead of known peaks. If your answer includes the lag, I know you watched it happen.

# config.json
{
  "PredefinedMetricSpecification": {
    "PredefinedMetricType": "ASGAverageCPUUtilization"
  },
  "TargetValue": 60.0
}

# Attach the policy to the Auto Scaling group
aws autoscaling put-scaling-policy \
  --auto-scaling-group-name orders-api-asg \
  --policy-name cpu-target-60 \
  --policy-type TargetTrackingScaling \
  --target-tracking-configuration file://config.json

'I used target tracking on average CPU at 60 percent.

When I load tested, CPU hit 90 within a minute, but
new instances took a few minutes to launch and pass
the health check. Users saw slow responses in that gap.

Two fixes: I raised the minimum from one to two, so
there was always spare capacity, and I set a default
instance warm-up so new instances were not counted
before they were ready. For a known morning peak,
I would add a scheduled action ahead of it.'

When I train cloud candidates at Uncodemy, I ask them to load test their own Auto Scaling group once and watch the activity history. That one exercise turns scaling from a memorized definition into a story with timing, numbers they set and a fix.

SECTION 04Ladder practice sheet for your own cloud topics

Take the topics on your resume and climb the ladder for each one on paper before the interview. If you cannot fill rung three or four, that topic needs a hands-on lab, not more reading.

TOPIC: ______________________________

Rung 1 - Define (two sentences max):
_____________________________________

Rung 2 - Apply (a specific case and my choice):
_____________________________________

Rung 3 - Break (what fails, what it costs):
_____________________________________

Rung 4 - Decide (under a budget or time limit):
_____________________________________

Surprise I met when I used it: _________

PRACTISE ALL FOUR RUNGS FOR:

- S3 storage classes and lifecycle rules
- Auto Scaling policy types and warm-up
- Security groups (stateful) vs network ACLs
- RDS Multi-AZ vs read replicas
- IAM roles vs users vs groups
- CloudWatch metrics, alarms and logs
- Spot vs On-Demand vs Savings Plans
- Terraform state and drift

Mark each: [ ] 1  [ ] 2  [ ] 3  [ ] 4

FOR EACH TOPIC STUCK BELOW RUNG 3

Small lab to run: _______________________
What I will measure or watch: ___________
What I expect to happen: ________________
What actually happened: _________________
One sentence story for the interview: ____

Remember to clean up afterwards:
aws ec2 describe-instances \
  --filters Name=instance-state-name,Values=running \
  --query 'Reservations[].Instances[].InstanceId'

SECTION 05Habits that turn memorized facts into real skill

Memorizing is not wrong. It is just the first rung. These habits help you climb the rest before an interviewer makes you.

• Learn every fact with a case — For each concept, attach one situation where you would use it and one where you would not.
• Run small labs and watch them — Ten minutes watching an Auto Scaling activity log teaches more than an hour of reading about scaling.
• Collect your surprises — Keep a note of anything that behaved differently from what you expected. Those notes become interview stories.
• Practise with constraints — Answer each topic again with a budget or time limit added. Decisions under limits are the top rung.
• Ask for missing details — When a scenario lacks information, ask for it. Real engineers know the answer depends on context.

SECTION 06Interview Q&A — Memorized vs real skill

SECTION 07Test yourself — Memorized vs real skill quiz

SECTION 08Frequently asked questions

SECTION 09Related reads