13.11.26

How to Verify Hands-On Kubernetes and Private Endpoint Security Skills When Hiring Platform Engineers

Why CV Keywords Don't Prove Platform Engineering Depth

Every platform engineer CV landing on a Head of Engineering's desk today says the same things: Terraform, Kubernetes, CI/CD, "security-first mindset." In regulated environments — fintech, financial services, anywhere a private endpoint misconfiguration becomes a regulatory incident rather than an inconvenience — that keyword overlap is close to meaningless. We run technical screening conversations with platform engineering candidates every week, and the gap between someone who has configured a hub-and-spoke Azure landing zone under audit pressure and someone who has watched a colleague do it is audible within minutes, if you know what to listen for. This guide sets out the specific probing questions and scenario checks we use to tell the difference, so you can run the same screen before a candidate ever reaches your own technical panel.

Who this is for

• Heads of Engineering and Platform leads hiring AKS/Terraform platform engineers for regulated environments

• Technical hiring managers who need a structured screen to run before committing panel time

• Teams tired of discovering, three weeks into onboarding, that a "senior platform engineer" can recite Terraform syntax but has never owned a security posture end-to-end

Prerequisites

Before you start screening, have the following ready:

• A real (even if lightly anonymised) description of your current AKS/Azure landing zone topology, so you can test candidates against your actual architecture rather than textbook scenarios

• A clear view of which tooling is non-negotiable for your environment (e.g., Terraform vs. Bicep, GitHub Actions vs. Azure DevOps, Buildkite) versus which is "nice to have"

• Agreement internally on what "senior" means for this role — designing original platform solutions and owning trade-off decisions, not just executing tickets

• A scenario or two drawn from a live or recent project, since generic hypotheticals are the easiest thing for a well-coached candidate to talk around

Step 1: Separate "I've touched Kubernetes" from "I've secured Kubernetes in production"

Start by asking which specific managed Kubernetes services the candidate has actually operated, not just "Kubernetes" as a category. One candidate we screened, when pressed on this, confirmed he had hands-on experience across AKS, EKS, and GKE as a multi-cloud specialist working to different client requirements — a materially different answer from someone who name-drops "Kubernetes" without specifying which flavour, in which environment, under what constraints.

Follow-up questions that expose depth:

• "Walk me through a private endpoint you've configured — what was in the spoke, what was in the hub, and why?" One candidate described deploying an AKS cluster within the spoke of a landing zone, connecting an agent on that cluster to Azure OpenAI, and securing the environment specifically using private endpoints — a level of architectural specificity that's very hard to fake.

• "Tell me about a time you had to resolve an Azure policy that was blocking a deployment in a secured environment." The same candidate described exactly this scenario — identifying and resolving a policy hindering deployment in a secured environment, alongside monitoring and security work. A candidate who has genuinely done this will describe the specific policy conflict and the resolution path; a candidate who hasn't will speak in generalities about "following best practice."

• "Have you worked with firewalls alongside your Kubernetes and endpoint work?" Real hands-on candidates can speak to Azure Firewall policies, application rules, and network rules specifically — not just "we had a firewall in place."

Warning sign: A candidate who answers Kubernetes questions entirely in terms of orchestration concepts, without ever naming a specific cluster type, client constraint, or security control they personally configured, is likely describing adjacent exposure rather than ownership.

Step 2: Probe Terraform experience for authorship, not familiarity

"I use Terraform" is the single most over-claimed line on a platform engineering CV. Push past the tool name into how it was actually used.

Ask directly:

• "Did you write the Terraform modules, or did you deploy infrastructure someone else designed?" Strong candidates describe building Terraform repositories specifically for repeatability — standardising how infrastructure gets deployed across a team. That's a different skill from running terraform apply against someone else's code.

• "What did your Terraform deployments actually provision in a secured environment?" One candidate was specific: subnets, VNets, IP address space, and the resource infrastructure underpinning an OpenAI deployment, including the policy and security layers around it. Another described using Terraform to expose networking components to spoke workloads within a hub-and-spoke architecture.

• "Talk me through your solutioning process before you write any Terraform." Depth shows up here: one candidate described a full cycle — stakeholder discussions, design, proposing best practices for cost, performance, security, and scaling aligned to the cloud vendor's own framework, running a proof of concept with the customer, then promoting to live environments. That sequence — design, POC, promote — is a strong marker of someone who owns infrastructure decisions rather than executing a backlog.

Sub-steps for verifying IaC maturity:

• a. Ask what CI/CD tooling wraps their Terraform pipelines — candidates we've screened reference GitHub Actions, Buildkite, Jenkins, Argo CD, and Azure DevOps as the surrounding toolchain

• b. Ask whether they've built approval gates and validation stages into those pipelines, with staged promotion through test, dev, staging, and production environments

• c. Ask about landing zone experience specifically — one strong candidate described building approximately five landing zones for a single client, each involving different applications, firewalls, and Key Vault for secrets management

Step 3: Test network security knowledge against your actual topology

This is where CV keyword-matchers fall apart fastest, because private endpoint and network security questions can't be answered from memorised terminology — they require the candidate to reason about a specific topology.

Scenario-based questions:

• Describe your own hub-and-spoke (or equivalent) setup in outline and ask: "Where would you place a private endpoint here, and what would break if you didn't?" Candidates with genuine experience will reference VNets, NSGs (network security groups), and private endpoints as a connected set of decisions, not isolated vocabulary.

• "Have you built a landing zone that included firewall configuration as a core deliverable, not an afterthought?" Candidates should be able to describe firewalls as part of the same deployment as their subnet and IP addressing work, not a separate team's responsibility.

• Ask how they've handled zero trust or secure-by-design requirements in a mature organisation. One candidate described working at an organisation already at a mature stage of zero trust adoption, where the ongoing work was automating and eliminating manual processes while continuing to secure pipelines — a meaningfully different conversation from a candidate who has only worked in greenfield environments with no existing security posture to integrate with.

Note: If a candidate can describe what a private endpoint does but cannot describe a specific instance where they configured one inside a spoke, against a specific policy constraint, treat that as a CV keyword match rather than hands-on depth.

Step 4: Distinguish senior platform engineers from infrastructure operators

Seniority in platform engineering isn't tenure — it's the ability to originate a solution and defend the trade-offs behind it under scrutiny.

The questions that reveal this:

• "Give me an example of an architectural trade-off you made and defend it." A hiring consultant prepping a candidate for a principal-engineer panel put it plainly: the panel wants to see the candidate "demonstrate that you've got a level of knowledge that you can actually make that decision yourself," not default to "it's based off the requirement I was given". Strong candidates can walk through something like evaluating one database option against another with concrete reasoning about underlying design principles.

• "Tell me about a new capability or technology you introduced, from problem to design to rollout." One senior candidate described identifying a new need, creating the infrastructure design, building the scaling approach, and writing the Terraform modules to support it — entirely self-directed, in a small team where she took the lead on new solutions.

• "Do you mentor other engineers, and what does that look like day to day?" Genuine seniority often comes with a people dimension — one candidate described managing a team of eight end-to-end, from technical interviewing to unblocking engineers stuck on problems.

Warning sign: A candidate who, when asked to defend an architectural choice, immediately pivots back to "the client's requirements dictated that" without ever articulating their own reasoning is very likely an operator, not a designer — valuable, but not what a senior or lead platform engineering job spec actually requires.

Tips & Best Practices

• Ask for the specific client constraint, not the general claim. "I've worked with private endpoints" tells you nothing; "I secured an AKS-to-Azure-OpenAI connection using private endpoints inside a spoke, within a secured environment with existing policy constraints" tells you everything.

• Test multi-cloud claims by asking for a comparative example. Candidates who claim equal strength across AWS, Azure, and GCP should be able to articulate where their depth genuinely sits — one candidate we screened was explicit that GCP was "good, not expert" while AWS and Azure were end-to-end strengths. Be suspicious of candidates who claim uniform expertise everywhere with no gradient.

• Use your own environment as the test case wherever possible. Candidates who have genuinely done the work will ask you clarifying questions about your topology before answering — a sign they're reasoning about your actual constraints, not reciting a rehearsed answer.

• Check observability and monitoring depth alongside security. Strong platform engineers can name their actual tooling — Prometheus, Grafana, Datadog, Azure Monitor, CloudWatch — and describe what they monitor for, not just that monitoring "exists".

• Don't treat contract-end timing as a red flag on its own. Several strong, technically deep candidates are simply reaching the end of a fixed contract term and actively exploring their next role — that's a normal market signal, not a quality indicator.

Troubleshooting Common Screening Pitfalls

"The candidate answers every question correctly but in generic terms." Push for the specific environment, the specific policy, the specific client constraint. Genuine depth always comes with a story attached — a named tool, a named problem, a named outcome.

"The candidate claims expertise across AWS, Azure, and GCP equally." Ask them to pick the platform where they'd be most comfortable being challenged by a principal engineer. Candidates with real depth will volunteer where their strength genuinely sits rather than insisting on uniform mastery.

"I can't tell if they designed the infrastructure or just deployed someone else's design." Ask specifically about the solutioning phase — stakeholder discussions, design proposals, proof-of-concept work before deployment. Operators skip straight to "I deployed X"; designers describe the reasoning that preceded deployment.

Summary

Screening platform engineers for regulated environments means refusing to accept tool names as proof of capability. The candidates worth putting in front of your technical panel can describe a specific private endpoint they configured, a specific policy conflict they resolved, a specific Terraform module they authored for repeatability, and a specific architectural trade-off they defended under scrutiny. Those who can only speak in categories — "I know Kubernetes," "I've used Terraform," "security is important to me" — are telling you they've been near the work, not that they've owned it. Build your screening conversation around your own topology, press for the client constraint behind every claim, and you'll separate genuine AKS and network security depth from CV keyword-matching long before it costs you a failed hire in a regulated environment.