Interview Q&A Reference

🟢 warm-up — definitional fluency. 🟡 medium — a structured answer plus a concrete example. 🔴 hard — scenario or trade-off depth. Sections are shown in the weight order one real interview syllabus used; the starred (★) sections were the two heaviest.

A self-service, Mend-scanned golden container image catalogue — hosted on GHCR and consumed by 100+ applications at a large IT-services company — is exactly the artifact a Pod's containers get pulled from. Owning that build gives real fluency in what goes into a Pod, even for someone whose hands-on Kubernetes object orchestration is lighter than their CI/CD and IaC depth.

This is philosophically identical to Terraform's plan/apply cycle: desired state in code, actual state in the provider, and a reconciliation step that closes the gap. The one honest difference is that Terraform reconciles when you run it, while a controller reconciles continuously — which makes controllers immediately familiar to anyone who already thinks this way about infrastructure, even while hands-on Kubernetes time is still ramping.

A 24/7 on-call rotation, including building Slack ChatOps automation for alert remediation at a healthcare-compliance infrastructure company, runs on exactly this distinction — knowing whether an alert means "restart it" or "stop sending it traffic and let it recover" — just applied to VM-based services rather than Pods.

Triaging production resource-exhaustion incidents via Slack ChatOps during a 24/7 on-call rotation builds exactly this instinct — diagnosing "why did this get killed" — just against VM/container memory ceilings rather than a cgroup-enforced Pod limit.

No direct hands-on bridge here is a common honest gap — say so plainly, and pivot to how quickly adjacent tools transfer (Terraform's declarative, reconcile-toward-desired-state model maps onto this faster than a cold start would suggest).

Designing multi-AZ placement and availability strategies for 10+ production AWS applications is the same "don't put all replicas in one failure domain" reasoning, just expressed through ECS task placement and AZ-aware Auto Scaling Groups instead of the Kubernetes scheduler.

This is squarely familiar territory for anyone who's run a staged platform migration — migrating 50+ Jenkins pipelines to GitHub Actions, or cutting a Terraform Enterprise estate over to Terraform Cloud with zero downtime and 100% data integrity, both require exactly this discipline: staged rollout, a defined rollback path, and verification gates before the old path is retired.

Provisioning and managing durable, encrypted storage for HIPAA-compliant systems and PCI-scope AWS architectures means the requirements this maps to — durability, access control, reclaim behavior — are ones that already had to get right under compliance audit, even where the CSI/PVC mechanics themselves are newer than Terraform-driven storage provisioning.

Designing AWS Auto Scaling Group and ECS service scaling policies with min/max guardrails across 10+ production applications is the same reactive-scaling-on-metrics model — even without having personally operated Karpenter, which is worth saying directly if asked rather than bluffing.

This is a direct extension of production-support work and a prior 24/7 on-call rotation building Slack ChatOps for alert remediation — the same systematic "confirm symptom, check logs, check recent changes, isolate the layer" discipline, just against Pods and Services instead of VMs and pipelines.

The clearest parallel is AWS itself: provisioning and scaling EC2 and Auto Scaling Group fleets through the AWS API and Terraform is the same pattern — a control plane orchestrating a fleet of workers — just expressed through cloud APIs instead of etcd and a scheduler. That mental model of a control plane managing a fleet of nodes is one plenty of AWS/IaC-heavy engineers already operate in practice, even where direct Kubernetes cluster administration is lighter than their IaC and CI/CD depth.

Not having hands-on Cluster API experience is worth saying directly rather than faking it. What transfers is depth with Terraform and IaC generally: the declarative, reconcile-toward-desired-state pattern CAPI uses is one many engineers have operated with for years, just not yet with these specific CRDs and provider controllers.

Not having run a CAPI pivot specifically is fine to admit — but the underlying concern, moving control of a system from one place to another without losing anything mid-flight, is exercised directly by anyone who's migrated CI/CD pipelines from Jenkins to GitHub Actions at scale: verify the new system is fully healthy before cutting traffic over, keep the old system alive until the new one is confirmed working, and have a rollback path ready. That's the same operational discipline CAPI's pivot requires.

No direct hands-on bridge here is a common honest gap — say so plainly, and pivot to how quickly adjacent tools transfer (Terraform's declarative, reconcile-toward-desired-state model maps onto this faster than a cold start would suggest).

The Provider → Composition → Managed Resource layering is structurally the same pattern as Terraform's provider → module → resource hierarchy — built and refactored across dozens of projects, including a Terraform Enterprise-to-Cloud migration — so the vocabulary maps quickly even without hands-on Crossplane time.

The L2→L3 shift from reusable infra bundles to a curated, guardrail-enforced self-service catalog is exactly the pattern behind a CIS-hardened golden image catalogue and a self-service golden container image catalogue built at a large IT-services company — different tooling, same platform-engineering instinct of hiding complexity behind a golden path.

Not having written a Crossplane Composition Function is a fair gap to name — but the underlying need, programmatic logic (loops, conditionals, derived values) beyond what static templating can express, is one that's solved repeatedly with Terraform's `for_each`/`dynamic` blocks and conditional, templated logic in golden-image build pipelines.

Per-team ProviderConfig/credential isolation is the same class of problem solved with workspace-scoped variable sets and access controls during a Terraform Enterprise-to-Cloud migration, and with segregation-of-duties and least-privilege requirements across 100+ PCI compliance assessments at a fintech company.

The base-plus-overlay-per-environment pattern is conceptually identical to structuring Terraform modules with environment-specific variables and workspaces for reusable, environment-based provisioning across dozens of projects.

No direct hands-on bridge here is a common honest gap — say so plainly, and pivot to how quickly adjacent tools transfer (Terraform's declarative, reconcile-toward-desired-state model maps onto this faster than a cold start would suggest).

Not having run Argo CD or Flux in production is worth naming plainly — but the underlying discipline, treat the repository as the only place changes are made, and fix forward by reverting a commit rather than hand-patching live state, is the same discipline enforced with Terraform: every environment change flows through version-controlled state and a PR, not a manual console fix. That habit gets reinforced hard during any Jenkins-to-GitHub-Actions CI/CD migration, where moving pipeline logic into version control is the whole point.

This isn't theoretical for anyone who's spent years living inside Terraform state, module, and workspace management — including leading a migration from Terraform Enterprise to Terraform Cloud enterprise-wide with 100% data integrity and zero downtime.

Deep hands-on AWS account, IAM, and governance experience — AWS Certified Solutions Architect – Professional, plus 100+ PCI compliance assessments spanning multiple environments — is a strong base, even when Azure's management-group/subscription hierarchy is still conceptual, self-study knowledge picked up by mapping it directly onto the AWS constructs already known cold.

Not having run Crossplane hands-on is a fair gap — but ownership of enterprise-wide reusable Terraform module standardization and a Terraform Enterprise → Terraform Cloud migration (100% data integrity, zero downtime) is exactly the IaC-tool-consolidation problem this question is really probing, so it's worth being upfront that Crossplane itself is self-study while framing the answer around that real consolidation experience.

Building the equivalent entry-point pattern at the AWS layer — API Gateway and ALB doing host/path routing in front of ECS services — makes the "one entry point, host/path rules, routed to backends" mental model behind Ingress map directly, even though the object names differ.

He hasn't run Gateway API hands-on, but the "platform team owns the shared infrastructure primitive, product teams self-serve on top of it" split is exactly the pattern he already built with the self-service Golden Image and Golden Container Image Catalogues at a large IT-services company — same governance model, different layer of the stack.

Not having run cert-manager/external-dns/ESO hands-on is worth naming plainly — but the underlying compliance territory is familiar: 100+ PCI DSS technical assessments directly covered TLS configuration validation, certificate lifecycle, and secrets-handling controls, so the requirements these operators automate are ones already assessed for compliance, even where the Kubernetes-native tooling itself is self-study right now.

No explicit Kubernetes RBAC line on a CV doesn't mean the model is unfamiliar — the same least-privilege, verb-on-resource permission model maps directly onto scoped AWS IAM policies architected for ECS/Lambda/API Gateway/Cognito apps, and the access-control reviews run across 100+ PCI compliance assessments.

The network-segmentation and scope-reduction logic behind namespace/NetworkPolicy isolation is exactly what gets assessed and enforced across PCI-DSS compliance reviews, where isolating the cardholder-data environment from the rest of the network is the core requirement.

The core pattern — never let secrets live in pipeline config, pull them from a managed store and inject at runtime — is exactly what gets executed at scale migrating 50+ Jenkins pipelines (with their credential-store secrets) into GitHub Actions secrets, and in managing sensitive Terraform Enterprise/Cloud workspace variables.

The supply-chain half of this — SCA scanning, shift-left, and fixing a vulnerability once at a golden image so every downstream app inherits the fix — is something built hands-on via Trivy scanning (a real 30% vulnerability reduction) and a Mend-scanned, CIS-hardened golden container image catalogue across 100+ applications, though the Kubernetes-native admission-control and runtime-detection layer specifically (OPA/Gatekeeper, Kyverno, Falco) is conceptual/self-study, worth saying plainly if probed.