This interview guide is for educational and informational purposes only. It is designed to help readers prepare, but it does not guarantee any interview result, hiring decision, offer, or outcome. Interview questions, hiring criteria, and preferred answers can vary by employer, interviewer, industry, location, and time. The examples and explanations reflect the authors' research and judgment, are provided without warranties of any kind, and should not be treated as the only correct approach. Diagrams are simplified illustrations intended to highlight the main components and their interactions; actual systems and implementations may be more complex. Alternative approaches may be equally valid or better suited to a particular question, context, or interviewer. To the fullest extent permitted by applicable law, the author, contributors, and publisher are not liable for decisions made, actions taken, or losses incurred based on this guide.
Identity, Image, and Privacy Notice
To respect individual privacy, some names, profile photographs, avatars, biographical details, and other identifying information displayed in this guide may be replaced with pseudonyms, licensed stock images, illustrative avatars, composite images, or representative descriptions. Unless a person is expressly identified as an actual contributor, a displayed name, image, or profile should not be understood as depicting or identifying a specific candidate, interviewer, employee, or other real individual. These representations are provided for editorial and illustrative purposes only and do not imply endorsement, employment, participation, or affiliation with this guide or any company mentioned in it. Any resemblance to an actual person is coincidental.
Company Notice
This guide is an independent educational resource and is not affiliated with, endorsed by, sponsored by, or approved by the company named in this guide. Company names are used only to identify interview experiences commonly reported by candidates. Interview practices can change without notice, and inclusion of company-specific content does not mean these questions are official, complete, or guaranteed to be asked. To the fullest extent permitted by law, the author, contributors, and publisher are not responsible for outcomes related to use of this material.
Content Accuracy and Verification
To the fullest extent permitted by applicable law, we do not represent or warrant that interview guides, questions, answers, examples, or diagrams are accurate, complete, current, error-free, or suitable for any particular purpose. You are responsible for independently reviewing and verifying the information before relying on it.
Questions or comments?
Contact us for general questions, or share feedback, technical corrections, and comments with the community.
1. What does etcd store?Containers And KubernetesEasyApple
Short Interview Answer (30-60 seconds)
At a high level, etcd stores the Kubernetes cluster state as persistent key-value data. The main challenge is keeping that state correct and consistent across the control plane. I would explain it in three parts: what data etcd stores, how the API Server reads and writes it, and how etcd members replicate the same data. It stores Pods, Services, ConfigMaps, Secrets, RBAC data, Nodes, Leases, and other API resources. Replication improves availability, but the members must coordinate through Raft consensus.
Detailed Explanation
The goal is to understand where Kubernetes keeps the information that describes a cluster. Kubernetes needs a reliable place to remember what objects exist, what configuration they use, and what state the control plane has recorded. The important point is that etcd stores this information as key-value data. The API Server is the component that directly reads and writes this stored state. The diagram also shows three etcd members holding the same data. I would explain the answer by following that flow from the control-plane components, through the API Server, into etcd.
Useful Questions to Ask the Interviewer
Do you want a high-level answer or examples of Kubernetes objects stored in etcd?
Should I also explain how multiple etcd members keep the stored data consistent?
How to Explain It in an Interview
1. Start with what etcd stores
A simple way to say it is: etcd stores the persistent state of the Kubernetes API. This means it remembers the information Kubernetes needs about the cluster.
The diagram shows cluster state and desired state. Desired state means what the cluster should look like. etcd also stores Kubernetes objects and configuration, including Pods, Services, ConfigMaps, Secrets, and RBAC objects.
2. Explain how the control plane reaches etcd
The next important point is that the API Server directly reads from and writes to etcd. The Controller Manager and Scheduler communicate through the API Server instead of directly changing etcd.
When Kubernetes records new or changed API state, the API Server writes that state to etcd. When control-plane components need the stored state, they get it through the API Server.
3. Give concrete examples of stored data
The diagram gives simple key-value examples. The key /registry/pods/default/nginx points to a stored Pod API object. The key /registry/services/specs/default/web points to a stored Service API object.
etcd also holds workload placement state. For example, a stored Pod object can contain its assigned node. Node objects, EndpointSlices, Leases, Namespaces, RBAC objects, ResourceQuotas, and other API resources are also part of the stored cluster data shown in the diagram.
4. Explain the etcd cluster
The diagram shows three etcd members. These members replicate the same data using Raft consensus. Raft is the method the members use to agree on stored changes.
The three members are copies of the same logical key-value store. They are not separate databases for different Kubernetes objects. With three members, the cluster can still form a majority if one member becomes unavailable.
5. End with the key interview point
The key point is that etcd is Kubernetes' persistent key-value store for API cluster state. The API Server is the direct reader and writer shown in this design.
The benefit of multiple etcd members is better availability while keeping one agreed state. The downside is that the members must coordinate through Raft before accepting changes.
Practical Insights
The benefit is that etcd gives Kubernetes one persistent place for cluster state. The API Server can read and write that data in a consistent way. Multiple etcd members keep copies of the same data. With three members, the cluster can still form a majority if one member fails. The downside is that replication needs coordination. The members use Raft consensus to agree on changes before accepting them. This adds work and can make writes slower than using one simple store. We accept that cost because Kubernetes control-plane state is important, and keeping one agreed version of that state matters.
Why Interviewers Ask This
Interviewers ask this question to check whether you understand a basic Kubernetes control-plane responsibility. They want to see if you know what etcd stores and which component accesses it directly. They may also check whether you understand that etcd members replicate the same cluster state. A strong answer explains these ideas clearly instead of only saying that etcd is a database.
Interviewer may ask next
What happens to this design if one of the three etcd members becomes unavailable?
The basic design stays the same because the remaining etcd members still contain copies of the same cluster data. The three members use Raft consensus to agree on changes. If one member becomes unavailable, the other two still form a majority, so the cluster can continue accepting reads and writes.
The API Server still reads and writes Kubernetes API state through the etcd cluster. Controller Manager and Scheduler continue using the API Server, so their communication path does not change.
The failed member is not a separate source of different cluster information. All members represent the same logical key-value store. When that member returns, it needs to catch up with the state agreed by the cluster.
The main downside is reduced fault tolerance while one member is unavailable. If another member fails before the first one returns, the cluster loses its majority and cannot safely accept new writes.
Why do the Controller Manager and Scheduler use the API Server instead of writing directly to etcd?
They use the API Server because it is the direct reader and writer for Kubernetes API state in this design. The Controller Manager and Scheduler work through that API layer instead of changing stored data themselves.
This keeps one clear path for reading and updating Kubernetes objects. For example, when the Scheduler assigns a Pod to a node, that placement is represented in the Pod API object. The change is then stored through the API Server. Controllers follow the same pattern when they observe or update other cluster objects.
etcd remains the persistent key-value store underneath that API path. Its members replicate the same data using Raft consensus. The Controller Manager and Scheduler therefore do not need their own direct etcd write paths.
The downside is that the API Server becomes an important dependency for control-plane operations. If it cannot process requests, those components cannot bypass it and safely write directly to etcd.
2. What does CNI consist of, and how is it used?Containers And KubernetesMediumApple
Short Interview Answer (30-60 seconds)
At a high level, CNI gives container runtimes a standard way to configure Pod networking. The main challenge is connecting each Pod correctly without making Kubernetes depend on one network provider. I would explain it in three parts: the CNI specification and configuration, the plugin execution flow, and the Pod network that gets created. The runtime reads the network configuration, executes CNI plugins with ADD or DEL, and the plugins create interfaces, routes, and IP addressing. The trade-off is flexibility versus plugin-specific behavior.
Detailed Explanation
The goal is to give each Pod a working network connection when Kubernetes places it on a node. The difficult part is that different environments may use different networking methods. Kubernetes should not need one fixed network provider. The diagram solves this by using a common networking contract called CNI. A container runtime follows that contract and runs selected networking programs. Those programs create the Pod interface, assign its address, and connect it to the node network. I would explain the design through the CNI pieces, the setup flow, and the resulting Pod network.
Useful Questions to Ask the Interviewer
Do you want the CNI specification explained, or also the Kubernetes runtime flow?
Should I include how ADD and DEL handle the Pod network lifecycle?
Should I explain the bridge and IPAM example shown in the design?
How to Explain It in an Interview
1. Start with what CNI consists of
I would say CNI is a standard contract for container networking. The CNI Specification defines the configuration format, commands, and lifecycle behavior between runtimes and plugins.
CNI Plugins are executable programs that perform networking work. The diagram shows bridge, host-local IPAM, portmap, and bandwidth as examples. Network Configuration is stored as JSON in the CNI Configuration Directory at /etc/cni/net.d/. CNI Libraries help runtimes and plugin authors implement the specification and common functions.
2. Follow the Pod setup request
The flow starts when Kubernetes schedules a Pod to a Worker Node. The kubelet then requests a Pod sandbox through CRI, which is the interface between kubelet and the Container Runtime.
The Container Runtime uses its CNI Client library for the CNI interaction. It reads the network configuration and invokes the configured CNI Plugins. kube-proxy is also shown as a Kubernetes component on the node, but it is not the component that performs this CNI Pod interface setup.
3. Explain how the plugins run
For Pod creation, the Container Runtime executes the configured CNI plugin chain with the ADD command. The plugins receive the Pod network configuration.
The plugins can create interfaces, configure routes, and assign an IP address. IPAM means IP Address Management. In the example, the host-local IPAM plugin handles address allocation. Other plugins can add functions such as port mapping or bandwidth handling.
When the Pod is deleted, the runtime invokes the plugins with DEL. DEL lets them remove interfaces and release allocated network resources.
4. Show the network that gets created
The bridge example creates a veth pair. A veth pair is two connected virtual network interfaces.
One end is the Host veth on the Worker Node. It connects to the cni0 bridge. The other end appears as eth0 inside the Pod Network Namespace with 10.244.1.2/24. The container uses that Pod Network Namespace, so it uses the same Pod interface and address.
5. End with what CNI enables and its limits
This model gives Kubernetes pluggable networking instead of one built-in provider. It supports Pod-to-Pod connectivity and IP address management. A chosen plugin may also provide network isolation, L2 or L3 networking, overlays such as VXLAN or Geneve, and policy features.
The important trade-off is flexibility. CNI provides the common contract, but the chosen plugins decide the actual networking behavior and supported features.
Practical Insights
The benefit is that Kubernetes does not need one fixed networking implementation. A Container Runtime can follow the same CNI contract while different plugins provide the actual network behavior. This makes networking pluggable and cloud-neutral. The downside is that features depend on the selected plugin. CNI itself does not automatically guarantee network isolation or every policy feature. A bridge-based setup is simple to understand, but other environments may use overlays or different L2 or L3 designs. Plugin chains also add configuration and lifecycle work. ADD must create the right resources, while DEL must remove them and release allocated addresses.
Why Interviewers Ask This
Interviewers ask this to see whether you understand the boundary between Kubernetes, the Container Runtime, and CNI Plugins. They also want to know whether you can explain the CNI Specification, Network Configuration, ADD and DEL lifecycle, IPAM, and Pod Network Namespace clearly. The important skill is understanding which component performs each networking step, not memorizing plugin names.
Interviewer may ask next
What changes if the CNI plugin must also enforce network isolation between Pods?
I would keep the same CNI setup flow, but the chosen plugin would need to support isolation or policy features. Kubernetes still schedules the Pod, kubelet still requests the Pod sandbox through CRI, and the Container Runtime still invokes the configured CNI plugin chain.
The difference is in what the plugin configures. Besides creating the Pod interface, routes, and IP address, the plugin can also install networking rules needed by its policy implementation. The diagram shows that network isolation depends on the chosen plugin or policy implementation, so I would not describe isolation as an automatic CNI guarantee.
The Pod still gets its eth0 interface inside the Pod Network Namespace. In the bridge example, the Host veth still connects to the cni0 bridge. The main downside is extra plugin-specific configuration and behavior. The CNI contract stays common, but the isolation features depend on that implementation.
What happens to the CNI network setup when a Pod is deleted?
The Container Runtime invokes the CNI plugin chain with DEL instead of ADD. The overall architecture stays the same. kubelet works through the Container Runtime, and the runtime uses the configured CNI Plugins for cleanup.
DEL tells the plugins that the Pod network resources can be removed. In the bridge example, this means cleaning up the interfaces created for the Pod. The IPAM part also releases the allocated IP resources. This matters because leaving old interfaces or addresses behind could waste node networking resources.
The cleanup behavior belongs to the CNI plugin implementation. CNI defines the lifecycle contract, while the plugins perform the actual network changes. The downside is that correct cleanup depends on the relevant plugins handling DEL correctly. The runtime and plugin chain therefore need consistent configuration across both Pod creation and deletion.
3. What do you think of Cilium, and where can it be used?Containers And KubernetesMediumApple
Short Interview Answer (30-60 seconds)
At a high level, I think Cilium is a strong choice for Kubernetes networking, security, and observability because it uses eBPF in the Linux kernel. The main challenge is getting strong policy control and visibility without adding too much packet-processing overhead. I would explain it in three parts: what Cilium provides, how the Cilium Agent manages the kernel datapath, and where Cilium can run. The benefit is fast kernel-level processing. The trade-off is that optional features depend on cluster and kernel configuration.
Detailed Explanation
Cilium helps Kubernetes workloads communicate safely and gives engineers better visibility into network behavior. I think it is a strong choice when a team wants networking, security, and observability in one platform. The hard part is doing this efficiently without adding unnecessary work to every packet. The diagram explains the idea in three steps. It shows the main capabilities, then the worker-node design, and finally the environments where Cilium can be used. It also shows a simple Helm install and notes that optional features depend on cluster configuration.
Useful Questions to Ask the Interviewer
Are you asking mainly about Cilium networking, security, or observability?
Is the Kubernetes environment self-managed or a managed service such as EKS, GKE, or AKS?
Do we need Cilium only for networking, or also for optional features such as kube-proxy replacement?
How to Explain It in an Interview
1. Explain what Cilium provides
I would start by saying that Cilium is an open-source platform built around eBPF. eBPF lets small programs run safely inside the Linux kernel.
The diagram shows four main capabilities. Networking covers service-to-service connectivity, load balancing, and kube-proxy replacement. Security includes network policies, L7 visibility, and pod or identity-based controls. Observability gives visibility into flows, metrics, and troubleshooting. Performance comes from doing important packet work inside the kernel.
2. Explain the worker-node design
Each worker node has Pods, a Cilium Agent, eBPF Maps, and a Linux Kernel eBPF layer. The Cilium Agent is a control component. It programs and manages the eBPF state used by the kernel.
The direct path from Pods to the Linux Kernel is important. It shows that workload traffic is handled by the kernel datapath rather than being forwarded through the Cilium Agent process.
3. Explain the node and cluster interaction
The eBPF Maps and Linux Kernel layer work together on each worker node. The kernel then sends traffic through the Underlay Network, which the diagram labels as VPC, on-prem, or cloud.
The diagram also shows the Kubernetes Control Plane interacting with the cluster. I would keep that explanation simple and avoid claiming extra behavior that is not shown.
4. Explain where Cilium can be used
Cilium can run in supported Kubernetes environments. The diagram includes self-managed clusters and compatible managed services such as EKS, GKE, and AKS.
It also shows public-cloud VPCs, multi-cloud and hybrid deployments, on-premises datacenters, and Linux-based Kubernetes at edge sites, bare-metal systems, and private infrastructure.
5. Finish with the practical trade-off
The benefit is that Cilium combines networking, security, observability, and strong performance around a Linux kernel datapath. This can reduce overhead while giving detailed policy control and visibility.
The downside is that optional behavior depends on the cluster setup. Kernel support and Cilium configuration matter. The Helm command in the diagram installs Cilium, but it does not assume that every optional feature is enabled automatically.
Practical Insights
The benefit is that Cilium moves important networking work into the Linux kernel with eBPF. This can give low-latency packet handling and strong visibility without sending traffic through a separate user-space proxy. It also brings networking, security, and observability into one platform. The downside is that the exact feature set depends on the cluster and Linux kernel configuration. Some optional behavior must be enabled and configured separately. Teams therefore need to understand their Kubernetes environment before turning on advanced features such as kube-proxy replacement. Cilium can simplify operations, but it also becomes an important platform component that engineers must operate carefully.
Why Interviewers Ask This
Interviewers ask this to see whether you understand modern Kubernetes networking beyond basic Services and kube-proxy. They want to know whether you can explain eBPF in simple terms, separate the Cilium Agent from the Linux kernel datapath, and describe realistic places where Cilium can run. They are also checking whether you understand that Cilium can combine networking, security, observability, and performance instead of treating it as only a networking tool.
Interviewer may ask next
How would your answer change if the team wanted to use Cilium as a kube-proxy replacement?
I would keep the same basic Cilium design, but I would treat kube-proxy replacement as an optional cluster feature instead of assuming it is always enabled. The Cilium Agent would still manage the eBPF state on each worker node, and the Linux kernel would still handle the packet datapath.
The main change is that Cilium would also take responsibility for Kubernetes Service load-balancing behavior that kube-proxy normally helps provide. I would first check that the target Kubernetes environment and Cilium configuration support this mode. I would also test Service connectivity carefully before enabling it in production.
The Helm command shown in the diagram is intentionally generic, so I would add the required feature-specific settings only after checking the cluster. The benefit is fewer separate packet-processing components. The downside is that Cilium becomes even more important to Service connectivity, so a configuration mistake can have a wider networking impact.
How would you use Cilium in a hybrid environment with cloud and on-premises Kubernetes clusters?
I would use the same node-level Cilium model in each supported Kubernetes cluster. Every worker node would have a Cilium Agent that manages the eBPF state used by the Linux kernel. The underlying network would still come from each environment. In the cloud, that could be a VPC. On-premises, it could be the datacenter network.
This matches the diagram because Cilium sits above the Underlay Network instead of replacing the physical or cloud network itself. I would keep the networking, security, and observability model as consistent as possible across clusters while respecting the limits of each environment. I would verify each environment separately before rollout.
The benefit is a similar operational model across cloud and on-premises systems. The downside is that the underlay networks and supported Cilium options may differ, so the team must test each cluster type instead of assuming identical behavior everywhere.
Cloud Engineer Resume Examples
Explore the resume examples below to find the one that best matches your target Cloud Engineer role.
Disclaimer: This interview guide is for educational and informational purposes only. It is designed to help readers prepare, but it does not guarantee any interview result, hiring decision, offer, or outcome. Interview questions, hiring criteria, and preferred answers can vary by employer, interviewer, industry, location, and time. The examples and explanations reflect the authors' research and judgment, are provided without warranties of any kind, and should not be treated as the only correct approach. Diagrams are simplified illustrations intended to highlight the main components and their interactions; actual systems and implementations may be more complex. Alternative approaches may be equally valid or better suited to a particular question, context, or interviewer. To the fullest extent permitted by applicable law, the author, contributors, and publisher are not liable for decisions made, actions taken, or losses incurred based on this guide.
Company Notice: This guide is an independent educational resource and is not affiliated with, endorsed by, sponsored by, or approved by the company named in this guide. Company names are used only to identify interview experiences commonly reported by candidates. Interview practices can change without notice, and inclusion of company-specific content does not mean these questions are official, complete, or guaranteed to be asked. To the fullest extent permitted by law, the author, contributors, and publisher are not responsible for outcomes related to use of this material.
Content Accuracy and Verification: To the fullest extent permitted by applicable law, we do not represent or warrant that interview guides, questions, answers, examples, or diagrams are accurate, complete, current, error-free, or suitable for any particular purpose. You are responsible for independently reviewing and verifying the information before relying on it.
