Model Solution: Kubernetes Assessment 01 – Fundamentals
Difficulty level: Fundamentals
Language: English
Type: model solution / expected answer guide
This file is the matching solution for
01-fundamentals-kubernetes-assessment-EN.md.
The commands and manifests are intended for a lab cluster. Do not use production cluster contexts and do not use real credentials.
1. Usage Notes
This model solution shows a complete, traceable Fundamentals submission. Concrete outputs such as Pod names, cluster name, node names, IP addresses and Kubernetes versions will differ in a real lab. What matters is that the candidate:
- works in namespace
exam-fundamentals, - submits resources as YAML manifests,
- validates rollout and Service through
kubectl, - does not use real Secrets,
- investigates error patterns methodically with status, events, logs and Endpoints.
Recommended working variable:
export NS=exam-fundamentals
2. Part A: Model Answers to Knowledge Questions
1. Purpose of Kubernetes and declarative desired state
Kubernetes is a platform for declaratively orchestrating containerized applications. You describe the desired state in resources such as Deployments, Services, ConfigMaps or Secrets. Kubernetes stores this state through the API Server, and controllers continuously compare it with the observed current state. Deviations are corrected through reconciliation, for example by creating a replacement Pod if one is missing.
Validation:
kubectl get deployment,pod,svc -n exam-fundamentals
kubectl describe deployment web -n exam-fundamentals
Typical mistake: Kubernetes reconciles an incorrect manifest just as reliably as a correct one.
2. Role of the API Server
The API Server is the central interface of the cluster. kubectl, controllers, the scheduler and other components communicate with the Kubernetes API through it. It authenticates requests, authorizes them, performs Admission checks and persists accepted objects into cluster state.
Validation:
kubectl cluster-info
kubectl api-resources
3. Why etcd is critical
etcd stores the cluster state, including Kubernetes objects, configuration and, depending on configuration, Secrets. If etcd fails or data is lost, the cluster can no longer reliably reconstruct its desired state. In production, backup, restore tests, access protection and encryption are relevant.
Fundamentals classification: you do not need to operate etcd yourself, but you must understand its criticality.
4. Scheduler, Controller Manager and kubelet
| Component | Role |
|---|---|
| Scheduler | assigns new Pods to suitable Nodes |
| Controller Manager | runs controller loops, for example Deployment, ReplicaSet and Node controllers |
| kubelet | runs on every Node and implements PodSpecs through the container runtime |
Validation for Pod problems:
kubectl get pod -o wide -n exam-fundamentals
kubectl describe pod <pod> -n exam-fundamentals
5. Difference between Pod, ReplicaSet and Deployment
A Pod is the smallest deployable unit. A ReplicaSet ensures that a desired number of equivalent Pods is running. A Deployment manages ReplicaSets and provides rollouts, rollback and scalable declarative updates.
For stateless applications, you normally create Deployments rather than individual Pods.
6. Why Pods are rarely created directly
Directly created Pods are not automatically replaced by a higher-level controller if they are deleted or changed. Deployments, StatefulSets, Jobs or DaemonSets provide reconciliation, rollouts, scaling and operational semantics.
Owner-chain validation:
kubectl get pod -n exam-fundamentals -o yaml | grep -A5 ownerReferences
7. How a Service finds its Pods
A Service finds Pods through Label selectors. The Service selector must match the Labels on the Pods. The Service does not know fixed Pod names.
Check:
kubectl get pods --show-labels -n exam-fundamentals
kubectl get svc web -o yaml -n exam-fundamentals
kubectl get endpoints,endpointslices -n exam-fundamentals
8. Difference between Label and Annotation
Labels are short selectable metadata used for grouping and selection. Services and Deployments use Labels through selectors. Annotations are non-selecting metadata for tools, descriptions or additional information.
Example:
labels:
app: web
environment: exam
annotations:
description: "Fundamentals assessment workload"
9. Namespace and security boundary
A Namespace organizes Kubernetes resources logically and enables separate views, RBAC, quotas, LimitRanges and policies. A Namespace does not replace full security isolation. Without RBAC, NetworkPolicy, Pod Security and quotas, risks may still cross namespace boundaries.
10. ConfigMaps and Secrets
ConfigMaps contain non-sensitive configuration such as feature flags, URLs or operating modes. Secrets are intended for sensitive values such as tokens or passwords. In the lab only example values are used.
Important: Kubernetes Secrets are not automatically secure simply because they are stored as Secret resources. Access, storage and rotation must be protected.
11. Why Base64 is not encryption
Base64 is only an encoding. Anyone can decode Base64-encoded values. Protection for Kubernetes Secrets comes from RBAC, encryption of sensitive data at rest, access protection for backups and secure Secret processes.
Example:
echo bm90LWEtcmVhbC1zZWNyZXQ= | base64 -d
12. First commands for typical errors
| Error pattern | First diagnostic commands | Typical cause |
|---|---|---|
ImagePullBackOff |
kubectl describe pod <pod> and events |
wrong image name, tag, registry or Pull Secret |
CrashLoopBackOff |
kubectl logs <pod> and kubectl logs <pod> --previous |
process exits, invalid configuration |
| Service without Endpoints | kubectl get endpoints, check Labels and Service selector |
Selector does not match Pod Labels or Pods are not ready |
Pod Pending |
kubectl describe pod <pod> and events |
resources, node selector, taints or PVC block scheduling |
3. Part B: Manifest Analysis
Input manifest:
apiVersion: apps/v1
kind: Deployment
metadata:
name: web
namespace: exam-fundamentals
labels:
app: web
tier: frontend
spec:
replicas: 2
selector:
matchLabels:
app: web
template:
metadata:
labels:
app: web
tier: frontend
spec:
containers:
- name: nginx
image: nginx:1.27
ports:
- containerPort: 80
Answers
| Question | Model answer |
|---|---|
| API group and version | apps/v1; the resource belongs to the Apps API group. |
| Resource | A Deployment named web. |
| Desired state | The desired state is under spec, for example replicas: 2 and the Pod template. |
| Deployment Labels | The Deployment receives app=web and tier=frontend. |
| Pod Labels | Pods receive app=web and tier=frontend in the template. |
Role of spec.selector.matchLabels |
The selector defines which Pods are managed by the Deployment. |
| Why selector and Pod template Labels must match | If they do not match, the Deployment cannot manage its Pods correctly; for Deployments the selector is also effectively immutable. |
| Indirectly created resource | The Deployment creates a ReplicaSet, and the ReplicaSet creates Pods. |
| Rollout check | kubectl rollout status deployment/web -n exam-fundamentals plus kubectl get deployment,rs,pod -n exam-fundamentals. |
4. Part C: Practical Solution
C1: Prepare namespace
namespace.yml
apiVersion: v1
kind: Namespace
metadata:
name: exam-fundamentals
labels:
environment: exam
level: fundamentals
Apply and check:
kubectl config current-context
kubectl get nodes -o wide
kubectl apply -f namespace.yml
kubectl get namespace exam-fundamentals
kubectl version --client
Optional namespace default:
kubectl config set-context --current --namespace=exam-fundamentals
C2: Roll out Deployment
configmap.yml
apiVersion: v1
kind: ConfigMap
metadata:
name: web-config
namespace: exam-fundamentals
labels:
app: web
environment: exam
data:
APP_MODE: exam
WELCOME_TEXT: "Hello from the Fundamentals assessment"
secret.yml
apiVersion: v1
kind: Secret
metadata:
name: web-secret
namespace: exam-fundamentals
labels:
app: web
environment: exam
type: Opaque
stringData:
DEMO_PASSWORD: "not-a-real-secret"
deployment.yml
apiVersion: apps/v1
kind: Deployment
metadata:
name: web
namespace: exam-fundamentals
labels:
app: web
tier: frontend
environment: exam
spec:
replicas: 2
selector:
matchLabels:
app: web
template:
metadata:
labels:
app: web
tier: frontend
environment: exam
spec:
containers:
- name: nginx
image: nginx:1.27
ports:
- name: http
containerPort: 80
env:
- name: APP_MODE
valueFrom:
configMapKeyRef:
name: web-config
key: APP_MODE
volumeMounts:
- name: demo-secret
mountPath: /etc/demo-secret
readOnly: true
volumes:
- name: demo-secret
secret:
secretName: web-secret
Apply:
kubectl apply --dry-run=server -f configmap.yml
kubectl apply --dry-run=server -f secret.yml
kubectl apply --dry-run=server -f deployment.yml
kubectl apply -f configmap.yml
kubectl apply -f secret.yml
kubectl apply -f deployment.yml
kubectl rollout status deployment/web -n exam-fundamentals
kubectl get deployment,replicaset,pod -n exam-fundamentals
Validate ConfigMap and Secret mounting:
POD=$(kubectl get pod -l app=web -n exam-fundamentals -o jsonpath='{.items[0].metadata.name}')
kubectl exec "$POD" -n exam-fundamentals -- printenv APP_MODE
kubectl exec "$POD" -n exam-fundamentals -- ls -l /etc/demo-secret
kubectl exec "$POD" -n exam-fundamentals -- cat /etc/demo-secret/DEMO_PASSWORD
Expected:
APP_MODEprintsexam./etc/demo-secretcontains a fileDEMO_PASSWORD.- The value is only a lab example value.
C3: Create Service
service.yml
apiVersion: v1
kind: Service
metadata:
name: web
namespace: exam-fundamentals
labels:
app: web
environment: exam
spec:
type: ClusterIP
selector:
app: web
ports:
- name: http
port: 80
targetPort: 80
Apply and check:
kubectl apply --dry-run=server -f service.yml
kubectl apply -f service.yml
kubectl get svc,endpoints,endpointslices -n exam-fundamentals
kubectl describe svc web -n exam-fundamentals
Optional functional test:
kubectl run curl --rm -i --tty --restart=Never \
--image=curlimages/curl:8.8.0 \
-n exam-fundamentals -- http://web
Alternative if interactive Pods behave differently:
kubectl run curl --restart=Never --image=curlimages/curl:8.8.0 -n exam-fundamentals -- sleep 3600
kubectl wait --for=condition=Ready pod/curl -n exam-fundamentals --timeout=60s
kubectl exec curl -n exam-fundamentals -- curl -s http://web
kubectl delete pod curl -n exam-fundamentals
C4: ConfigMap and Secret mounting
The mounting is already included in deployment.yml. A good answer additionally explains:
- ConfigMap values can be mounted as environment variables or files.
- Secret values can also be mounted as environment variables or volumes.
- Secret volumes should be mounted read-only.
- Real Secrets do not belong in this assessment and should not be stored unencrypted in Git.
C5: Rollout, scaling and rollback
kubectl scale deployment/web --replicas=3 -n exam-fundamentals
kubectl rollout status deployment/web -n exam-fundamentals
kubectl get pods -l app=web -n exam-fundamentals
kubectl set image deployment/web nginx=nginx:1.26 -n exam-fundamentals
kubectl rollout status deployment/web -n exam-fundamentals
kubectl rollout history deployment/web -n exam-fundamentals
kubectl get deployment web -n exam-fundamentals -o jsonpath='{.spec.template.spec.containers[0].image}{"\n"}'
kubectl rollout undo deployment/web -n exam-fundamentals
kubectl rollout status deployment/web -n exam-fundamentals
kubectl get deployment web -n exam-fundamentals -o jsonpath='{.spec.template.spec.containers[0].image}{"\n"}'
Expected:
- After scaling, three desired replicas run.
- After
set image, the Deployment showsnginx:1.26. - After
rollout undo, the previous revision is active again, in this model solutionnginx:1.27.
5. Part D: Diagnosis and Operations Note
D1: Service without Endpoints
Intentionally wrong Service selector:
selector:
app: wrong-web
Symptom:
kubectl get endpoints web -n exam-fundamentals
Typical output:
NAME ENDPOINTS AGE
web <none> ...
Diagnosis:
kubectl get pods -n exam-fundamentals --show-labels
kubectl get svc web -n exam-fundamentals -o yaml
kubectl describe svc web -n exam-fundamentals
kubectl get endpoints,endpointslices -n exam-fundamentals
Cause:
The Service searches for Pods with app=wrong-web, but the actual Pods have app=web.
Fix:
selector:
app: web
Validation:
kubectl apply -f service.yml
kubectl get endpoints web -n exam-fundamentals
kubectl get endpointslices -l kubernetes.io/service-name=web -n exam-fundamentals
D2: Explain error patterns
| Error pattern | Diagnosis | Most likely cause | Fix |
|---|---|---|---|
ImagePullBackOff |
kubectl describe pod <pod> and events |
image name, tag, registry or Pull Secret wrong | set correct image, check registry access |
CrashLoopBackOff |
kubectl logs <pod> and kubectl logs <pod> --previous |
process exits repeatedly | fix command/configuration, validate rollout |
| Service without Endpoints | kubectl get endpoints, Labels and Service selector |
selector does not match Pod Labels or Pods are not ready | correct selector or readiness problem |
Pod Pending |
kubectl describe pod, scheduling events and node resources |
insufficient resources, node selector, taints or PVC | fix scheduling constraint or resource/storage issue |
D3: Example evidence.md
# Evidence: Fundamentals Assessment
## Context and namespace
- Context: `<lab-context>`
- Namespace: `exam-fundamentals`
- Node count: `<n>`
## Applied manifests
- namespace.yml
- configmap.yml
- secret.yml
- deployment.yml
- service.yml
## Validation
```bash
kubectl get deployment,rs,pod,svc,endpoints,endpointslices -n exam-fundamentals
kubectl rollout status deployment/web -n exam-fundamentals
kubectl describe svc web -n exam-fundamentals
Error and fix
The Service selector was intentionally changed to app=wrong-web. The Service had no Endpoints. The fix was to restore the selector to app=web.
Cleanup
Delete resources via manifests or delete the namespace.
---
## 6. Expected Submission Files
A complete submission contains:
```text
01-fundamentals-submission/
answers.md
namespace.yml
deployment.yml
service.yml
configmap.yml
secret.yml
evidence.md
cleanup.md
The content must be reproducible. The examiner does not need exact Pod names or IP addresses, but the validation path must be clear.
7. Cleanup
Recommended cleanup:
kubectl delete namespace exam-fundamentals
If namespace deletion is not allowed:
kubectl delete -f service.yml --ignore-not-found
kubectl delete -f deployment.yml --ignore-not-found
kubectl delete -f secret.yml --ignore-not-found
kubectl delete -f configmap.yml --ignore-not-found
kubectl delete -f namespace.yml --ignore-not-found
Verify:
kubectl get all -n exam-fundamentals
kubectl get namespace exam-fundamentals
8. Grading and Examiner Notes
A strong solution:
- explains desired state and reconciliation without overcomplicating it,
- distinguishes Pod, ReplicaSet and Deployment clearly,
- uses Service selectors and EndpointSlices correctly,
- treats Secrets as sensitive even though only example values are used,
- validates every step with
kubectl, - isolates broken Service selectors methodically,
- provides a safe cleanup path.
Common deductions:
| Issue | Deduction |
|---|---|
| No namespace or wrong namespace | high |
| Deployment works, but Service has wrong selector | medium to high |
| no evidence of rollout validation | medium |
| ConfigMap or Secret not actually referenced | medium |
| real password or token submitted | knockout or high |
| no cleanup documented | medium |