What a Blank Stare During a Cloud Tools Question Really Means

Interview Insights · Cloud Tools

What a Blank Stare During a Cloud Tools Question Really Means

SECTION 01The three kinds of blank stare I see

Not every blank stare means the same thing. Over many interviews, I have learned to separate three kinds, because each one calls for a different follow-up from me and a different recovery from you.

The first is the console-only stare: the candidate has done the task, but only by clicking, and the CLI or code version is unfamiliar. The second is the name mismatch: they have used the thing but never heard its proper name. The third is the genuine gap: the tool is new to them. Only the third is really a knowledge gap, and even that can be handled well.

Interviewer: How would you list all running EC2 instances
in a region from the command line?

Candidate: (long silence)

Interviewer: Have you used the CLI at all?

Candidate: I always used the console.

(What I hear: this person has not scripted or
automated anything yet.)

Interviewer: How would you list all running EC2 instances
in a region from the command line?

Candidate: I have mostly done this in the console, under
EC2, filtered by state. In the CLI I believe it is
aws ec2 describe-instances with a filter on the instance
state, running, and the region flag.
I would check the exact filter name in the help.

(What I hear: has the right mental model and knows how
to find the detail. Good enough to continue.)

The recovered version is not perfect, and it does not need to be. It shows that the candidate understands what the command must do. That is what turns a blank stare into a small pause.

SECTION 02Closing the console-only gap with the CLI

The fastest way to stop the console-only stare is to repeat your console tasks in the CLI. Every time you click through a task, do it again with a command. Soon you will notice the console and CLI use the same names: instances, volumes, security groups, filters. That makes tools questions feel familiar instead of foreign.

The skill that impresses most interviewers is the --query option, which uses JMESPath to pick out only the fields you need. Being able to explain a query is a clear sign you have actually used the CLI.

# Running instances: ID, type, private IP and Name tag
aws ec2 describe-instances \
  --region ap-south-1 \
  --filters Name=instance-state-name,Values=running \
  --query 'Reservations[].Instances[].{ID:InstanceId,Type:InstanceType,IP:PrivateIpAddress,Name:Tags[?Key==`Name`]|[0].Value}' \
  --output table

# How to explain it:
# Reservations[].Instances[]  -> flatten all instances
# {ID:..., Type:...}           -> build a small object per instance
# Tags[?Key==`Name`]|[0].Value -> pick the Name tag's value

#!/usr/bin/env bash
# Stop every running instance tagged Env=dev (end of day)
set -euo pipefail

ids=$(aws ec2 describe-instances \
  --filters Name=tag:Env,Values=dev \
            Name=instance-state-name,Values=running \
  --query 'Reservations[].Instances[].InstanceId' \
  --output text)

if [ -n "$ids" ]; then
  aws ec2 stop-instances --instance-ids $ids
else
  echo "No running dev instances"
fi

Notice that --filters narrows results on the AWS side, while --query reshapes them on your machine. Interviewers sometimes ask for exactly that difference. If you can say it calmly, the tools section of the interview usually goes well.

The script is also a good project line. A small automation that stops dev instances at the end of the day is easy to explain, saves cost and shows you have moved beyond the console.

SECTION 03Recovering when the tool is genuinely new

Sometimes the tool really is unfamiliar. A job post may mention Pulumi, Azure Bicep, Datadog or Google Cloud Deployment Manager, and you have only used Terraform and CloudWatch. A blank stare here costs more than the gap itself, because silence hides the knowledge you do have.

The recovery is a bridge: say honestly that you have not used it, name the category it belongs to and explain how a tool you know does the same job. Interviewers often care more about the category understanding than the specific product.

Interviewer: Have you used Azure Bicep?

Candidate: Not directly. I have used Terraform and read
some CloudFormation. Bicep is Azure's own way of declaring
resources as code, so I would expect the same ideas:
resources, parameters, outputs and a deployment that
shows what will change. In Terraform I would run plan;
I believe Azure has a what-if command for Bicep.
I would start by converting one of my Terraform modules
to Bicep to learn the syntax.

# Who am I / which account?
aws sts get-caller-identity
az account show

# List virtual machines
aws ec2 describe-instances --output table
az vm list --output table

# List storage
aws s3 ls
az storage account list --output table

# Shape output (both use JMESPath)
aws ec2 describe-instances --query 'Reservations[].Instances[].InstanceId'
az vm list --query '[].name' --output tsv

Both the AWS CLI and the Azure CLI use JMESPath for --query. Mentioning that one fact often turns an 'I have not used Azure' answer into a positive moment, because it shows you understand tools at a level that carries across.

SECTION 04A practice plan to end the cloud tools blank stare

These three tabs turn console knowledge into tools knowledge. Do one tab each week before your interviews, and keep a notes file of every command you run.

CONSOLE TO CLI DRILL

For each task you did in the console, write and run
the CLI version:

[ ] Launch and stop an instance
[ ] Create a bucket and upload a file
[ ] Create a security group and add one rule
[ ] Create an IAM role and attach a policy
[ ] Tail logs of a Lambda function
[ ] Check identity with sts get-caller-identity

Add --query to at least three of them.

NAMES I SHOULD RECOGNISE

JMESPath     - query language behind --query
Instance profile - wrapper that attaches a role to EC2
Named profile    - CLI credentials set in ~/.aws/config
Remote state     - Terraform state stored centrally
Log group        - CloudWatch container for log streams
Metric filter    - turns log patterns into metrics
What-if          - Azure preview of a deployment

For each: one sentence + where I used it.

BRIDGE PRACTICE (with a friend)

Friend names a tool you have not used.
You answer in this order, within 20 seconds:

1. Honest: "I haven't used it directly."
2. Category: "It is a ... tool."
3. Known tool: "I have used ..., which does ..."
4. Learning step: "I would start by ..."

Repeat with 10 tools from real job posts.

SECTION 05Habits that keep tools questions from freezing you

Tools questions feel easier when tools are part of how you practise every day. These habits make that happen.

• Do every task twice — Once in the console to see it, once in the CLI or code to own it.
• Keep a command journal — A plain text file of commands you have run, with one line on what each does, becomes your best revision sheet.
• Start with get-caller-identity — Running it first in every session builds the habit of checking which account and role you are using.
• Read job posts for tool names — Note every tool you do not recognise and prepare a bridge sentence for each one.
• Say the category first — When unsure about a tool, naming its category gives you a safe starting point and a few seconds to think.

SECTION 06Interview Q&A — Cloud tools

SECTION 07Test yourself — Cloud tools quiz

SECTION 08Frequently asked questions

SECTION 09Related reads