The Interview Showed Me Where My Cloud Learning Was Still Thin

I could reason through a real failure, but I could not always retrieve the Linux basics under pressure.

I left a cloud support interview with two opposite impressions.

I could reason through a real troubleshooting story. I could explain how I followed a failure across several systems, documented what I found, and escalated to the team that owned the code.

Then I was asked what swap memory was.

I could not retrieve the answer quickly.

That contrast was more useful than a simple pass-or-fail feeling. It showed me that I had built a reasonable troubleshooting mindset, but I had not made the Linux fundamentals reliable under pressure.

The questions were basic on purpose

The technical part moved through ordinary support-engineering territory:

• What would you check when an application reports no space left on device?

• What if df -h still shows free space?

• How would you know whether customers are reaching a web application?

• Which logs contain HTTP status codes?

• What does 404 mean?

• What does dig tell you?

• What is an inode?

• How do you inspect and change Linux permissions?

• What are chmod and chown for?

• How do you check memory?

• What is swap?

• What does load average mean, and what are the 1, 5 and 15 minute values?

None of these questions required advanced architecture. They tested whether the basic tools and distinctions were available when I needed them.

That matters in support work. An engineer may have a runbook, documentation and an AI assistant available. But the first response still depends on recognising the layer of the failure and choosing a safe next check without turning every simple question into a long search.

Where I was stronger

The interviewer also asked for the most difficult technical issue I had handled. My strongest example came from customer support, not AWS.

A client's page-view events were working, but the purchase event failed during checkout. The symptom appeared in the advertising account, but the failure could have been in the platform, the tracking code or the e-commerce system.

I compared the working and failing paths. Events Manager showed that the pixel was active and receiving page-view signals. Pixel Helper showed that the purchase event did not fire at checkout. That narrowed the fault to the e-commerce trigger path.

I documented the evidence and escalated it to the team that owned the website code. I did not claim to know the exact internal defect, and I did not make unrelated changes just to look active.

That answer reflected real work I had done. The sequence was clear because the experience was real:

1. define the scope;

2. compare a healthy path with a failing path;

3. isolate the layer;

4. document what the evidence proved;

5. hand the problem to the right owner with the evidence documented.

This is the part of my background I should carry forward. Moving into cloud engineering does not erase the operational habits I built in customer support.

Where the gap appeared

The gap appeared when the interviewer wanted a short factual answer and I returned to a general method.

When asked where I would see customers accessing a website, I discussed health checks and DNS. Those can be useful checks, but the direct answer was access logs and request telemetry. When asked about CloudTrail, I mixed AWS API activity with external customer activity. The interviewer had to clarify that CloudTrail records actions in the AWS account, not ordinary website browsing.

When asked about DNS, I knew dig belonged to DNS, but I described it partly as if it showed traffic. The precise boundary is simpler: dig tells me what DNS answer was returned. It does not prove that the route, port, TLS handshake or application is healthy.

When asked about permissions, I knew the commands were similar but initially confused chmod and chown. When asked about logs, I mentioned /var/log but also associated top with logs. top is a live process and resource view. It is not a historical log search.

These were not dramatic mistakes. They were retrieval failures and evidence-boundary failures. In a support role, both still matter.

The small distinctions I need to own

I wrote the corrections down after the interview because they are exactly the kind of facts that should become automatic:

• df -h checks filesystem byte usage.

• df -i checks inode usage.

• An inode stores filesystem metadata associated with a file.

• chmod changes permission bits.

• chown changes ownership or group ownership.

• dig checks DNS resolution.

• Access logs show requests and recorded HTTP status codes.

• journalctl queries the systemd journal.

• CloudTrail records AWS API activity.

• 401 means authentication is missing or invalid.

• 403 means the request was understood but access is forbidden.

• 404 means the server was reached but the resource was not found.

• Load average shows recent runnable or waiting work over 1, 5 and 15 minutes.

• Swap is disk space used for less-active memory pages when RAM is under pressure.

The point is not to memorise a glossary for its own sake. Each distinction changes the next safe action.

If df -h shows free bytes but the application cannot create a file, I should check inodes, the actual mount and deleted-but-open files. If DNS resolves but HTTPS fails, I should move to the port, route, security controls, TLS and application layers. If access logs contain no requests, I should not immediately conclude that there are no customers. I should check the logging path, time range and layer I am inspecting.

Exposure is not retrieval

I had studied these topics. I had seen the commands. I had written notes about them. That created a feeling of familiarity.

The interview exposed the difference between recognising a concept on a page and producing the answer with the notes closed.

My study system had been good at collecting and organising information. It was weaker at forcing short, timed retrieval. I could explain a long troubleshooting method, but that method sometimes became a way to avoid the smaller question in front of me.

The repair is not another giant document.

The repair is a loop:

1. close the notes;

2. answer one exact question in one or two sentences;

3. name the check or command;

4. state what the evidence proves and what it does not prove;

5. test the idea in a small safe environment when needed;

6. record the correction;

7. repeat it later without looking.

This is less satisfying than reading another course module. It is also closer to the pressure of the job.

The behavioral lesson was similar

The behavioral part showed the same pattern in a different form.

I had credible experiences and a strong customer-support example, but I sometimes answered a specific question with the story of my entire transition into cloud engineering. When the interviewer asked for one recent thing I had learned, I described Hermes, AI-assisted learning, documentation and my second brain instead of naming one bounded topic, one obstacle, one exercise and one result.

The interviewer kept asking for one real example. That was useful feedback. A learning system is not the same as a learning event.

A hypothetical answer template, not a claim about what I actually did, would be something like:

I recently learned how VPC route tables and security controls work together. I chose the topic because networking was still unfamiliar. I studied the AWS material, tested one small path in a controlled lab, compared the expected route with the observed result, and wrote down what each layer proved. The result was that I could explain why a correct route table alone does not prove end-to-end connectivity. This was training, not production AWS work.

That answer is smaller, but it gives the listener something they can evaluate.

What I will do differently

Before another technical interview, I will use closed-notes Linux drills instead of another passive reading cycle. I will answer the direct question first, state what the check proves and what it does not prove, and practise one bounded learning story. The cloud transition is context, not the example. The example needs one topic, one difficulty, one small action, evidence and a result.

The interview also confirmed that my previous support experience is relevant. I should not present it as cloud production experience, but I should not throw it away either. Customer impact, investigation, documentation, escalation and careful ownership are the operating habits on which the technical layer can grow.

The useful outcome

I still do not know whether the interview will lead to another stage. The transcript cannot prove that.

But it gave me a more precise map than another week of broad studying would have given me.

I do not need to become a different person before I can work in cloud support. I need to make the fundamentals more retrievable, the answers more direct and the evidence boundaries more precise.

The interview did not only ask whether I knew AWS. It asked whether I could notice what a check actually tells me, choose the next safe action and explain it without hiding behind a framework.

That is the work now.