How I Spot a Copy-Pasted Cloud Engineer Project in Minutes

Interview Insights · Cloud Engineer

How I Spot a Copy-Pasted Cloud Engineer Project in Minutes

SECTION 01The repo clues I notice in the first two minutes

When a cloud candidate shares a GitHub link, I do not read every file. I skim for a few signals that tell me whether the person made decisions or followed steps. Tutorials leave fingerprints: default names, the same region the tutorial author used, a state file committed by accident, and security rules that were 'temporary' in the video and never tightened.

None of these alone proves copying. Plenty of people learn from tutorials, and I did too. But when several of these clues appear together and the candidate cannot explain any of them, the picture is clear. Here are the clues and what they usually mean.

my-aws-project/
  main.tf            <- resource "aws_s3_bucket" "my-bucket"
  terraform.tfstate  <- committed, contains resource IDs
  terraform.tfstate.backup
  README.md          <- "In this tutorial we will..."

security group in main.tf:
  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

photo-share-infra/
  backend.tf         <- S3 backend with state locking
  network.tf
  compute.tf
  iam.tf
  variables.tf
  .gitignore         <- *.tfstate, .terraform/, *.tfvars
  README.md          <- why I chose each part, what it
                        cost, what broke and how I fixed it

No port 22 at all: instances are reached
through SSM Session Manager.

The most telling file is often the README. A tutorial README describes steps: 'first we create a VPC, then we add subnets'. A builder's README describes decisions: 'I used two private subnets so the app survives one AZ failing, and I dropped the NAT Gateway in dev to save cost'.

SECTION 02The why questions that expose a copied VPC or IAM setup

After the skim, I pick two or three concrete values from the code and ask why. Network ranges and permissions are my favourites, because tutorials almost always use the same values and almost never explain them. If you built the VPC yourself, you made choices about CIDR sizes and subnet placement. If you copied it, those numbers are just numbers.

The question is never 'what is a CIDR block?'. It is 'why did you pick this one?'. A builder may say 'I copied the tutorial range but I understand it gives me this many addresses'. That is fine and honest. A copier says 'that is the standard'.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "*",
      "Resource": "*"
    }
  ]
}

// Works in the demo. Means the app can delete
// every resource in the account if it is compromised.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AppReadWriteUploads",
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": "arn:aws:s3:::photo-share-uploads-dev/*"
    },
    {
      "Sid": "AppListUploads",
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::photo-share-uploads-dev"
    }
  ]
}

Notice the scoped policy splits ListBucket from the object actions. ListBucket applies to the bucket ARN, while GetObject and PutObject apply to objects under it, shown with the /* suffix. A candidate who wrote this themselves usually remembers the first time it failed with AccessDenied because they mixed the two up. That small memory is exactly the kind of detail that proves ownership.

SECTION 03Making a tutorial cloud project genuinely yours

If your current cloud project is mostly a tutorial, you do not need to throw it away. You need to add decisions. The fastest way is to change three things the tutorial did not do, break something on purpose, and write down what you learned. Each of those becomes a story you can tell in the interview.

Good changes are ones that force you to understand the code: moving state to a remote backend, tightening security groups, splitting environments, adding cost controls or replacing SSH with Session Manager. Each one will break something along the way, and fixing it is what makes the project yours.

terraform {
  required_version = ">= 1.5"

  backend "s3" {
    bucket         = "photo-share-tfstate-dev"
    key            = "infra/terraform.tfstate"
    region         = "ap-south-1"
    dynamodb_table = "photo-share-tf-locks"
    encrypt        = true
  }

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

# Then: terraform init -migrate-state
# and delete the local terraform.tfstate from git history.

# Terraform
.terraform/
*.tfstate
*.tfstate.*
crash.log
*.tfvars
*.tfvars.json
override.tf
override.tf.json

# Keep the lock file so provider versions are pinned
!.terraform.lock.hcl

# Never commit credentials
.aws/
*.pem

One more step matters: if your state file or any access key was ever committed, removing it in a new commit is not enough, because it stays in git history. Rotate any exposed keys in IAM and rewrite or recreate the repository. Mentioning that you did this tells an interviewer you understand real security hygiene.

Finally, write a short README section called 'Decisions and mistakes'. Three bullet points are enough. It is the first thing I look for, and it turns a five-minute deep dive into a conversation you control.

SECTION 04Audit your cloud repo before you share it

Run through this audit before you put a cloud project link on your resume. It takes an evening and closes most of the gaps an interviewer would find in the first five minutes.

SECURITY
[ ] No *.tfstate files in the repo or its history
[ ] No access keys, .pem files or secrets anywhere
[ ] No security group with port 22 or 3389 open to 0.0.0.0/0
[ ] No Action "*" with Resource "*" in any policy

OWNERSHIP
[ ] Resource names match my project, not the tutorial
[ ] Region choice is deliberate (and I can say why)
[ ] At least three changes the tutorial did not have

DOCUMENTATION
[ ] README explains decisions, not just steps
[ ] 'Decisions and mistakes' section exists
[ ] Rough monthly cost is written down

Ask a friend to open your repo and pick ANY
three values. For each, answer in under a minute:

1. Why this value?
2. What happens if I change it?
3. Did it ever break? How did you fix it?

Good targets for your friend:
- the VPC and subnet CIDR blocks
- the instance type
- any IAM action list
- the ASG min and max sizes
- the backup or retention settings

If you cannot answer one, fix the project or
learn that part before the interview.

Use this structure when you describe the project:

"I started from a tutorial to learn the basics of
_______. Then I changed three things on my own:

1. __________ because __________
2. __________ because __________
3. __________ because __________

The hardest problem was __________. I found it by
__________ and fixed it by __________.

It costs about ____ a month to run, so I keep it
destroyed when I am not using it."

SECTION 05Ways to present a cloud project that holds up

How you talk about a project matters as much as the code. These habits keep a deep dive in your favour.

• Admit the tutorial early — Saying where you started removes the biggest risk in the conversation and lets you focus on what you changed.
• Lead with a decision — Open with one choice you made and why, such as removing SSH in favour of Session Manager, instead of listing services.
• Know your numbers — Be ready to explain your CIDR sizes, instance types and scaling limits, because these are the values interviewers pick.
• Show the destroy habit — Saying you run terraform destroy when you are not using the project shows cost awareness and confidence in your code.
• Keep one failure story ready — A short story about an AccessDenied error or a broken route that you traced and fixed is the strongest proof of ownership.

SECTION 06Interview Q&A — Copied cloud projects

SECTION 07Test yourself — Copied cloud projects quiz

SECTION 08Frequently asked questions

SECTION 09Related reads