Model Solution: Kubernetes Assessment 01 – Fundamentals · Kubernetes

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_MODE prints exam.
/etc/demo-secret contains a file DEMO_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 shows nginx:1.26.
After rollout undo, the previous revision is active again, in this model solution nginx: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

Model Solution: Kubernetes Assessment 01 – Fundamentals

1. Usage Notes

2. Part A: Model Answers to Knowledge Questions

1. Purpose of Kubernetes and declarative desired state

2. Role of the API Server

3. Why etcd is critical

4. Scheduler, Controller Manager and kubelet

5. Difference between Pod, ReplicaSet and Deployment

6. Why Pods are rarely created directly

7. How a Service finds its Pods

8. Difference between Label and Annotation

9. Namespace and security boundary

10. ConfigMaps and Secrets

11. Why Base64 is not encryption

12. First commands for typical errors

3. Part B: Manifest Analysis

Answers

4. Part C: Practical Solution

C1: Prepare namespace

namespace.yml

C2: Roll out Deployment

configmap.yml

secret.yml

deployment.yml

C3: Create Service

service.yml

C4: ConfigMap and Secret mounting

C5: Rollout, scaling and rollback

5. Part D: Diagnosis and Operations Note

D1: Service without Endpoints

D2: Explain error patterns

D3: Example evidence.md

Error and fix

Cleanup

7. Cleanup

8. Grading and Examiner Notes

31 modules ως ενιαία διαδρομή μάθησης.

3. Why `etcd` is critical

`namespace.yml`

`configmap.yml`

`secret.yml`

`deployment.yml`

`service.yml`

D3: Example `evidence.md`