Kubernetes

What's being tested

These prompts test whether you can turn ambiguous cloud requirements into a concrete Kubernetes architecture, then explain its operational and security consequences. The interviewer is probing knowledge of control-plane and node responsibilities, workload scheduling, networking, storage, identity, observability, and safe delivery—not merely whether you can name Kubernetes objects. Salesforce cares because software engineers must build multi-tenant services that remain secure, deployable, diagnosable, and resilient under partial failure.

Core knowledge

• Control plane versus data plane: `kube-apiserver` authenticates and validates requests; `etcd` stores cluster state; the scheduler assigns Pods; controllers reconcile desired state. Worker nodes run `kubelet`, a container runtime such as `containerd`, and networking components such as `kube-proxy` or an eBPF dataplane.

• Declarative reconciliation: A `Deployment` records desired replicas and a `ReplicaSet` maintains them, while controllers continuously correct drift. Distinguish desired state, observed state, and actual process health; a running container can still fail readiness or serve incorrect traffic.

• Scheduling and capacity: Requests influence placement; limits constrain runtime usage, though CPU limits can cause throttling and memory overuse triggers eviction or OOM termination. Use `nodeSelector`, affinity, taints, tolerations, and topology spread constraints to enforce isolation and availability across zones.

• Service networking: A `Service` provides stable discovery over ephemeral Pod IPs, while an `Ingress` or Gateway handles external HTTP routing. Explain DNS, load balancing, TLS termination, and `NetworkPolicy`; a policy implementation requires a compatible CNI, and default-allow networking is a security risk.

• Availability and autoscaling: Run multiple replicas across failure domains, add Pod disruption budgets, and use readiness probes so traffic avoids unready instances. Horizontal Pod Autoscaler reacts to CPU, memory, or custom metrics; Cluster Autoscaler adds nodes, but neither fixes an application bottleneck or bad resource requests.

• Stateful workloads: Prefer managed databases and queues when operationally possible. If Kubernetes must host state, use `StatefulSet`, persistent volume claims, snapshots, replication, and tested restore procedures. Replicas improve availability, not necessarily durability; define RPO and RTO explicitly.

• Identity and least privilege: RBAC should grant service accounts only the verbs and resources they need, preferably within namespaces. Combine cloud workload identity, short-lived credentials, Pod Security Admission, image-signature verification, secret encryption, and `NetworkPolicy`; never treat namespace separation as a complete tenant boundary.

• Supply-chain security: CI should build immutable, preferably digest-pinned images, scan dependencies and images, sign artifacts, and publish provenance. CD should verify signatures, render manifests or Helm charts, and deploy through an auditable identity rather than allowing arbitrary developer credentials to access the cluster.

• Progressive delivery: A rolling update depends on `maxSurge`, `maxUnavailable`, readiness checks, and a realistic termination grace period. Canary or blue-green deployment reduces blast radius, but requires objective rollback signals such as error rate, latency, saturation, and business-level request failures.

• Observability and incident response: Emit structured logs, metrics, and distributed traces with correlation IDs. Track golden signals—traffic, errors, latency, and saturation—plus deployment and scheduling events. Design alerts around actionable symptoms, and preserve audit logs for API activity, authorization decisions, and deployment history.

• Failure boundaries and scaling assumptions: Ask whether the cluster spans availability zones, what happens if `etcd`, a node pool, a CNI, or a cloud region fails, and how quickly recovery must occur. Capacity planning should include peak replicas, daemon overhead, disruption headroom, and control-plane rate limits.

Worked example

For “Design secure Kubernetes with CI/CD”, start by asking about workload type, regions and availability zones, traffic and `p99` latency targets, compliance requirements, deployment frequency, tenant isolation, RPO/RTO, and whether managed Kubernetes and managed databases are acceptable. Declare an initial assumption such as a stateless, internet-facing service with multi-zone availability, private cluster endpoints, and automated rollback within minutes. Organize the answer around four pillars: cluster architecture and failure domains, workload networking and identity, artifact-to-cluster supply-chain controls, and progressive delivery with observability. Place the control plane in the provider-managed service, use separate node pools where isolation or scaling differs, and keep persistent data outside the cluster unless there is a strong reason not to. Give each workload a dedicated service account with narrowly scoped RBAC, cloud workload identity, default-deny network policies, signed image verification, and encrypted secrets. Explicitly flag the tradeoff between deployment simplicity and isolation: namespaces and policies are efficient for many teams, while separate clusters provide stronger blast-radius and compliance boundaries at higher cost. Define CI as build, test, scan, sign, and publish, and CD as verify, deploy, observe, and automatically halt or roll back on failed health gates. Close by saying that with more time you would model a regional outage, test restore and rollback procedures, and review threat scenarios such as compromised CI credentials or a malicious image.

A second angle

For “Compare cloud compute; design Kubernetes security and CI/CD”, begin by comparing virtual machines, serverless containers, and managed Kubernetes against workload variability, startup latency, operational ownership, portability, and cost. Kubernetes is compelling when there are many services, custom scheduling needs, or a platform team that can absorb cluster complexity; it is not automatically cheaper or simpler than managed containers. The security design should then explain which controls remain the cloud provider’s responsibility and which belong to the engineering team. Close the comparison with a migration and rollout strategy, including workload classification, platform standards, and a fallback when Kubernetes adds more operational burden than business value.

Common pitfalls

Pitfall: Treating “three replicas” as an availability design. If all replicas land on one node or zone, one failure can remove the service; specify topology spread, disruption budgets, readiness behavior, and dependency availability.

A communication mistake is jumping directly into YAML, Helm, or a preferred cloud service without clarifying scale, compliance, tenancy, and recovery objectives. A stronger answer states assumptions first, labels optional choices, and continually ties architecture decisions to those requirements.

Pitfall: Saying “use RBAC and private networking” as though security is complete. Discuss workload identity, secret handling, image provenance, network-policy enforcement, auditability, credential rotation, and what happens if the CI system or a service account is compromised.

Connections

The interviewer may pivot to distributed-systems failure handling, zero-downtime deployment, service discovery, cloud IAM, or observability and SLOs. Be ready to connect Kubernetes mechanisms to application-level idempotency, backpressure, graceful shutdown, and dependency timeouts rather than treating the cluster as a substitute for resilient code.

Further reading

• Kubernetes Documentation: Concepts — authoritative explanations of workloads, networking, storage, configuration, and security primitives.

• Kubernetes Documentation: Security — covers RBAC, Pod Security Standards, Secrets, and control-plane security.

• Google SRE Book: Release Engineering — useful principles for reproducible builds, progressive delivery, and safe rollback.