The blueprint
A mock exam here has 60 questions in 90 minutes, split across the domains in the same proportions as the official exam guide. The official pass mark is 75%. FixOps scores practice against a target of 75%.
-
01
Kubernetes Fundamentals
-
02
Container Orchestration
-
03
Cloud Native Application Delivery
-
04
Cloud Native Architecture
Sample questions
Three of the 10 questions in the free diagnostic. Open one to see the answer and why.
A developer asks what Kubernetes actually schedules onto a node. Which object is the smallest unit that Kubernetes deploys and manages?
- A Deployment
- A Pod
- A container image
- A namespace
Answer: A Pod. The Pod is the smallest deployable unit: one or more containers that share a network identity and can share storage. An image is only the template a container starts from, a Deployment manages Pods through ReplicaSets, and a namespace is a scope for names rather than something that runs.
kubectl, the scheduler and every kubelet all need to read and change cluster state. Which control plane component do they all talk to?
- The kube-apiserver
- The kube-controller-manager
- The kube-proxy on each node
- etcd, directly
Answer: The kube-apiserver. The API server is the front end of the control plane: every client, including the other control plane components, goes through it, and only it reads and writes etcd. The controller manager and kube-proxy are themselves clients of the API server.
How does a Service know which Pods to send traffic to?
- By a label selector that matches the Pods' labels
- By annotations on the Pods
- By the Pods' names, listed in the Service
- By the namespace alone: every Pod in it is a backend
Answer: By a label selector that matches the Pods' labels. A Service selects its backends with a label selector, so any ready Pod carrying the matching labels receives traffic. Pod names change with every replacement, a namespace usually holds many unrelated Pods, and annotations are not used for selection.
Revision notes: Kubernetes Fundamentals
The notes for one domain, free to read here and in the app. FixOps Pro has them for all 4 domains.
What a Kubernetes cluster is made of, the resources you create in it, how the API and kubectl work, and how containers are scheduled and run.
Control plane and nodes
- The API server is the front door: every component and every user talks to the cluster through it.
- etcd stores the cluster's state as key-value data; nothing else is the source of truth.
- The scheduler picks a node for each new pod; the controller manager runs the control loops that drive actual state towards desired state.
- The cloud controller manager connects the cluster to a cloud provider's load balancers, nodes and routes.
- On every node, the kubelet starts and watches the pods assigned to it, kube-proxy implements Service networking, and a container runtime runs the containers.
Workload resources
- A pod is the smallest deployable unit: one or more containers that share a network address and volumes.
- A Deployment manages ReplicaSets to run a number of identical pods and roll out new versions.
- A StatefulSet gives pods stable names and their own storage; a DaemonSet runs one pod on every node; a Job runs to completion and a CronJob runs Jobs on a schedule.
- Labels are key-value pairs for selecting objects; annotations hold other metadata; namespaces divide a cluster.
- ConfigMaps hold configuration and Secrets hold sensitive values, both delivered as environment variables or files.
The API and kubectl
- Kubernetes is declarative: you describe the desired state in a manifest and controllers make it so.
- A manifest names an apiVersion, a kind, metadata and usually a spec.
- kubectl apply creates or updates from a file; get, describe and logs inspect; exec runs a command in a container.
- Authentication identifies the caller, RBAC authorises the request, and admission controllers can change or reject it before it is stored.
Scheduling
- The scheduler filters nodes that can run a pod and scores the rest.
- Requests are what a container is guaranteed and what scheduling is based on; limits cap what it may use.
- A node selector or node affinity steers pods to nodes; taints repel pods unless they tolerate them.
- Pod affinity and anti-affinity place pods near to or away from other pods.
Containers
- A container image is a layered, read-only package; a container is a running instance of it, isolated by namespaces and limited by cgroups.
- Kubernetes talks to runtimes through the Container Runtime Interface; containerd and CRI-O are common runtimes.
- The Open Container Initiative defines the image and runtime specifications, so images run on any compliant runtime.
- Images are stored in registries and should be pulled by a specific tag or digest, not latest.
Easy to mix up
- The scheduler decides where a pod runs; the kubelet makes it run there.
- A Deployment is for stateless replicas; a StatefulSet is for pods that need a stable identity and storage.
- Requests are for scheduling; limits are for enforcement.
- Labels select; annotations describe.