What Happens When Two Cloud Engineer Candidates Have Identical Resumes

Interview Insights · Cloud Engineer

What Happens When Two Cloud Engineer Candidates Have Identical Resumes

SECTION 01Why so many cloud resumes read exactly the same

Cloud resumes for freshers and early-career engineers tend to share the same skeleton. A certification. A list of AWS services. 'Infrastructure as code using Terraform.' 'CI/CD with Jenkins or GitHub Actions.' 'Containerised applications with Docker.' Many candidates learn from similar labs and copy similar resume templates, so the words line up almost perfectly.

That is not a problem in itself. It just means the resume cannot do the job of separating you. When I have two such resumes for one opening, I stop reading the skills section and start planning follow-up questions for each line. The resume became a list of topics, and the interview becomes the real comparison.

PROJECT: Cloud deployment of e-commerce app
- Deployed app on AWS using EC2, S3, RDS
- Used Terraform for infrastructure as code
- Containerised with Docker
- Set up CI/CD using GitHub Actions
- Monitored using CloudWatch

PROJECT: Cloud deployment of e-commerce app
- Deployed app on AWS using EC2, S3, RDS
- Used Terraform for infrastructure as code
- Containerised with Docker
- Set up CI/CD using GitHub Actions
- Monitored using CloudWatch

(Same words. The difference will only appear
when each candidate explains one line.)

If you want to stand out before the interview, change one bullet per project from a tool name to a decision. 'Stored Terraform state in S3 with DynamoDB locking so two people could not apply at once' already reads differently from the line above.

SECTION 02The one-level-deeper follow-ups that split the tie

My follow-ups are not trick questions. They sit exactly one level below the resume line. If you used Terraform, you met state. If you built a Docker image, you chose a base image. If you set up CloudWatch, you either created an alarm or you did not.

Terraform state is my favourite tie-breaker because it separates hobby use from team use. Someone who ran terraform apply from their laptop with a local state file has used Terraform. Someone who moved state to a remote backend with locking has understood why Terraform can hurt a team when state is handled carelessly.

terraform {
  required_version = ">= 1.5.0"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }

  backend "s3" {
    bucket         = "orders-tfstate-prod"
    key            = "network/terraform.tfstate"
    region         = "ap-south-1"
    dynamodb_table = "terraform-locks"
    encrypt        = true
  }
}

# The DynamoDB table needs a string partition key named LockID.
# The bucket should have versioning on, so old state can be recovered.

# Initialise once, or after changing the backend
terraform init

# Format and validate before anything else
terraform fmt -check
terraform validate

# Save the plan to a file and read it
terraform plan -out=tfplan
terraform show tfplan | grep -E 'destroy|replace' || echo 'no destroys'

# Apply exactly the plan you reviewed
terraform apply tfplan

Newer Terraform versions also offer S3-native locking with a lockfile option instead of DynamoDB. If you know about that, mention it. If you do not, the DynamoDB answer above is still widely used and perfectly fine to explain.

SECTION 03Ownership and evidence finish the tie-break

If both candidates survive the depth follow-ups, I move to ownership. Which decision in this project was yours, and what did it cost you? Real owners can name a trade-off: a cheaper instance type that needed tuning, a managed database that limited some settings, a single region that kept things simple but carries a regional risk.

Then I look for evidence. Not a polished portfolio, just something real. A README that explains how to deploy and destroy the setup. A rough architecture diagram. A commit history that shows the infrastructure growing step by step rather than appearing in one giant commit. Any of these makes a close call much easier.

# orders-api-infra

## What this builds
VPC with 2 public and 2 private subnets in ap-south-1,
an Application Load Balancer, an Auto Scaling group
of EC2 instances, and a MySQL RDS instance.

## Prerequisites
- Terraform 1.5 or newer
- AWS CLI configured with a profile that can create VPC resources

## Deploy
terraform init
terraform plan -out=tfplan
terraform apply tfplan

## Destroy (to avoid charges)
terraform destroy

## Decisions and trade-offs
- Single region for simplicity
- t3.micro instances for lab cost; would load test before prod

Interviewer: Which decision here was yours?

Candidate: Putting the EC2 instances in private subnets.
My first version had them public with SSH open, because
the tutorial did that. I moved them private, removed SSH,
and used Session Manager instead.

The cost was extra setup: the instances needed the SSM
agent and an instance role with the SSM managed policy.
The gain was no open port 22 on the internet.

When I train candidates at Uncodemy, the README is often the most underrated part of a cloud project. It takes an hour to write and it answers half the questions an interviewer would ask before they ask them.

SECTION 04Tie-breaker prep sheet for every resume line

Assume someone else has your exact resume. For each line, prepare the one-level-deeper answer, one decision you made, and one piece of evidence you can point to. These three sheets make that preparation concrete.

FOR EACH SKILL ON MY RESUME

Skill line: ______________________________
One-level-deeper question I expect: ______
My answer with a real value or setting: ___
One limitation of my approach: ___________

Examples to prepare:
- Terraform: state location, locking, drift
- Docker: base image, image size, user
- CI/CD: what fails the build, how deploy is triggered
- CloudWatch: which alarm, which threshold, who is notified

MY DECISIONS IN THIS PROJECT

Decision 1: ______________________________
What I chose instead of: _________________
What it cost me: _________________________
What I would change for production: ______

Decision 2: ______________________________
(same four lines)

Check: [ ] Each decision is mine, not the tutorial's
       [ ] I can say it in under 45 seconds

BEFORE I SEND MY RESUME

[ ] README with deploy and destroy steps
[ ] Architecture diagram with traffic arrows
[ ] Commits that show the build in stages
[ ] No secrets or access keys in the repo history
[ ] A 'decisions and trade-offs' section
[ ] One resume bullet rewritten as a decision

Run before pushing:
git log --oneline | head
git grep -n 'AKIA' || echo 'no access key ids found'

SECTION 05Habits that make your identical resume win

You cannot control who else applies. You can control how much depth sits behind each of your lines.

• Rewrite one bullet as a decision — Change a tool name into a choice and a reason. It is the cheapest way to look different before the interview starts.
• Know one level below every line — If a word is on your resume, expect the next question about it. Remove lines you cannot defend one level deeper.
• Keep your lab alive briefly — Before an interview, redeploy your project once from the README. It refreshes details you have forgotten.
• Name what you would change — A short 'for production I would...' answer shows maturity that a copied project rarely has.
• Clean your repo history — Make sure no keys or passwords ever appear in commits. Interviewers do sometimes look.

SECTION 06Interview Q&A — Identical cloud resumes

SECTION 07Test yourself — Identical cloud resumes quiz

SECTION 08Frequently asked questions

SECTION 09Related reads