Why Cloud Tools Eliminates More Candidates Than They Expect

Interview Insights · Cloud Tools

Why Cloud Tools Eliminates More Candidates Than They Expect

SECTION 01The gap between knowing a tool and operating it

In a screening call, I may ask 'what is Terraform?' and most candidates answer well. In the tools round, I ask something closer to the job: 'Here is a plan from a pull request. Would you approve it?' The candidate who has only memorised definitions now has nothing to stand on.

The gap is not about intelligence. It is about practice type. Reading output, writing small pieces of configuration and querying data are skills built only by doing. The table shows the shift interviewers make between rounds.

Interviewer: What is Terraform?

Candidate: Terraform is an open-source infrastructure as
code tool by HashiCorp. We write configuration in HCL
and it creates resources in AWS, Azure or GCP.

(Fine for screening. But it tells me nothing about
whether the candidate can review a real change.)

Interviewer: Here is a plan. Would you approve it?

Candidate: The summary says 1 to add, 0 to change and
1 to destroy. That combination on the same name usually
means a replacement. Yes, aws_db_instance.main is marked
-/+ and the engine_version line says forces replacement.

That would delete and recreate the database. I would not
approve this. I would check whether the version change
can be an in-place upgrade instead, and confirm a fresh
snapshot exists before anything.

The operating answer comes from having seen plan output many times. There is no shortcut. If you have never run a plan that wanted to replace something, create one on purpose in a practice account and read it carefully.

SECTION 02Reading Terraform plans and writing a small module

Two Terraform skills come up again and again in tools rounds. The first is reading a plan: knowing what +, -, ~ and -/+ mean and spotting lines that say a change forces replacement. The second is writing a small module, which shows you understand inputs, outputs and reuse rather than one giant file.

Practise both. Write a module for something simple, like an S3 bucket with versioning, and call it twice with different inputs. Then change an attribute that forces replacement and read the plan it produces.

# modules/bucket/variables.tf
variable "name" {
  type        = string
  description = "Bucket name"
}

variable "versioning" {
  type    = bool
  default = true
}

# modules/bucket/main.tf
resource "aws_s3_bucket" "this" {
  bucket = var.name
}

resource "aws_s3_bucket_versioning" "this" {
  bucket = aws_s3_bucket.this.id
  versioning_configuration {
    status = var.versioning ? "Enabled" : "Suspended"
  }
}

# modules/bucket/outputs.tf
output "arn" {
  value = aws_s3_bucket.this.arn
}

# main.tf
module "logs_bucket" {
  source     = "./modules/bucket"
  name       = "myproj-logs-ap-south-1"
  versioning = false
}

module "data_bucket" {
  source = "./modules/bucket"
  name   = "myproj-data-ap-south-1"
}

output "data_bucket_arn" {
  value = module.data_bucket.arn
}

# Then:
# terraform init
# terraform plan
# Changing the 'name' of a bucket later shows -/+
# because S3 bucket names cannot be changed in place.

Renaming a bucket is a safe way to see a forced replacement in your own account, because the bucket is empty. Do it once, read the plan, and you will recognise the pattern immediately when an interviewer shows you one with a database.

SECTION 03Alarms and log queries: the monitoring half of the round

The second half of many tools rounds is monitoring. I may ask a candidate to set up an alert for a web app or to find slow requests in a log group. Candidates who have only read about CloudWatch usually know it collects metrics and logs, but cannot say what a period, a statistic or an evaluation window is.

An alarm is just a rule: watch this metric, aggregate it this way over this period, and alert if it crosses this threshold for this many periods. Once you can say that sentence and fill in each part for a real case, the question becomes easy.

aws cloudwatch put-metric-alarm \
  --alarm-name alb-5xx-high \
  --namespace AWS/ApplicationELB \
  --metric-name HTTPCode_Target_5XX_Count \
  --dimensions Name=LoadBalancer,Value=app/my-alb/0123456789abcdef \
  --statistic Sum \
  --period 60 \
  --evaluation-periods 3 \
  --datapoints-to-alarm 3 \
  --threshold 10 \
  --comparison-operator GreaterThanThreshold \
  --treat-missing-data notBreaching \
  --alarm-actions arn:aws:sns:ap-south-1:123456789012:ops-alerts

# Run against the Lambda log group in CloudWatch Logs Insights
# Five slowest invocations in the selected time range

filter @type = "REPORT"
| fields @timestamp, @requestId, @duration, @maxMemoryUsed
| sort @duration desc
| limit 5

# Error count per 5 minutes
filter @message like /ERROR/
| stats count(*) as errors by bin(5m)

Lambda writes a REPORT line at the end of each invocation with its duration and memory use, which is why the first query filters on @type = "REPORT". Explaining that detail shows you have actually looked at Lambda logs rather than only read about them.

SECTION 04A tools-round preparation plan

Use these three tabs to practise the four skills of a tools round: read, write, query and decide. Each one should be done hands-on in a practice account with a budget alert.

PLAN READING DRILL

1. Create a small stack: bucket, security group, instance.
2. Change one thing at a time and run terraform plan:
   [ ] Add a tag            -> expect ~ update
   [ ] Change instance type -> expect ~ (may stop/start)
   [ ] Rename the bucket    -> expect -/+ replace
   [ ] Remove a resource    -> expect - destroy
3. For each plan, write one line: approve or not, and why.
4. Destroy everything at the end.

WRITE DRILL

[ ] Convert one resource into a module with
    variables.tf, main.tf and outputs.tf
[ ] Call the module twice with different inputs
[ ] Add a validation block to one variable
[ ] Create a CloudWatch alarm from the CLI
[ ] Create the same alarm in Terraform
[ ] Explain every argument out loud

QUERY DRILL

Deploy a small Lambda that logs a message and
sometimes raises an error. Invoke it many times.

Then, in Logs Insights:
[ ] Find the five slowest invocations
[ ] Count errors per 5 minutes
[ ] Show average duration by hour

Finally, decide: at what error count would you
alert someone, and why that number?

SECTION 05How to stop the tools round from eliminating you

Most of the fixes are about how you practise, not how much you study.

• Practise on output, not notes — Spend more time reading real plan output, logs and metrics than reading definitions.
• Break things on purpose — A forced replacement, a failing alarm and an error-filled log group are the best teachers for tools questions.
• Learn the vocabulary of alarms — Metric, statistic, period, threshold, evaluation periods and missing data: be able to explain each in one sentence.
• Write one module properly — A single clean module with variables, outputs and a README teaches more than many copied files.
• Always say the decision — After reading any output, finish with what you would do: approve, stop, alert or investigate further.

SECTION 06Interview Q&A — Cloud tools round

SECTION 07Test yourself — Cloud tools round quiz

SECTION 08Frequently asked questions

SECTION 09Related reads