Lab 01 — Build Your First Kubernetes Cluster

Mission Information

Item	Details
Lab ID	K8S-FND-LAB-01
Difficulty	Beginner
Estimated Time	60–90 minutes
Environment	Local workstation
Platform	Docker Desktop and kind
Cost	Free
Primary Role	Kubernetes Security Engineer
Module	Module 01 — Kubernetes Fundamentals for Security Engineers

Mission Scenario

CloudNova Technologies is preparing to adopt Kubernetes for its internal development and security testing environments.

Before the platform team begins deploying enterprise applications, the Cloud Security team must build a small Kubernetes cluster and verify that its core components are operating correctly.

You have joined the CloudNova Technologies security engineering team as a Junior Kubernetes Security Engineer.

Your mission is to:

Install the required Kubernetes tools
Create a local Kubernetes cluster
Inspect the Control Plane and Worker Node
Review system workloads
Deploy a test application
Expose the application securely for local testing
Perform an initial cluster security review
Collect evidence of successful implementation
Remove the lab resources after completion

This lab establishes the technical foundation for the remaining Kubernetes Security modules.

Learning Objectives

By completing this lab, you will be able to:

Create a local Kubernetes cluster using kind
Connect to the cluster using kubectl
Inspect Kubernetes nodes and system components
Identify the Control Plane and Worker Node
Create and inspect a Namespace
Deploy a containerised application
Create a Kubernetes Service
Review Kubernetes workload configuration
Perform basic cluster security validation
Troubleshoot common cluster deployment issues

Architecture

You will build the following environment:

Windows Workstation
        │
        ▼
Docker Desktop
        │
        ▼
kind Kubernetes Cluster
        │
        ├── Control Plane Node
        │
        └── Worker Node
                │
                ▼
        cloudnova-lab Namespace
                │
                ▼
        NGINX Test Deployment
                │
                ▼
        ClusterIP Service

Lab Outcomes

At the end of this lab, you should have:

One running Kubernetes cluster
One Control Plane node
One Worker Node
One dedicated Namespace
One test Deployment
Two running application Pods
One internal ClusterIP Service
Evidence showing the cluster is operational
A short initial security assessment

Prerequisites

Before starting, ensure that you have:

A Windows 10 or Windows 11 computer
Administrative access to the workstation
At least 8 GB of RAM
Virtualisation enabled
Internet access
Docker Desktop installed
Visual Studio Code installed
PowerShell or Git Bash available

Recommended free disk space:

10 GB or more

Tools Used

Tool	Purpose
Docker Desktop	Runs containers used as Kubernetes nodes
kind	Creates Kubernetes clusters using Docker containers
kubectl	Communicates with the Kubernetes API Server
PowerShell	Executes Windows commands
Git Bash	Optional alternative terminal
Visual Studio Code	Creates and edits Kubernetes manifest files

Lab Safety

This lab runs locally on your workstation.

It does not require:

An AWS account
An Azure account
A Google Cloud account
Paid Kubernetes infrastructure
Public internet exposure of the application

Do not use production credentials or sensitive information in this environment.

Task 01 — Verify Hardware Virtualisation

Docker Desktop requires hardware virtualisation.

Step 1 — Open Task Manager

Press:

Ctrl + Shift + Esc

Select:

Performance → CPU

Confirm that the following shows:

Virtualisation: Enabled

If virtualisation is disabled, enable Intel VT-x or AMD-V in the system BIOS or UEFI settings before continuing.

Task 02 — Install and Verify Docker Desktop

Step 1 — Start Docker Desktop

Open Docker Desktop from the Windows Start menu.

Wait until Docker Desktop reports that the Docker engine is running.

Step 2 — Verify Docker

PowerShell

docker version

Git Bash

docker version

Expected result:

Client:
 Version: ...

Server:
 Engine:
  Version: ...

Both the Docker client and server must be available.

Step 3 — Run a Test Container

PowerShell

docker run --rm hello-world

Git Bash

docker run --rm hello-world

Expected result:

Hello from Docker!

This confirms that Docker can download and execute containers.

Task 03 — Install kubectl

kubectl is the command-line tool used to communicate with Kubernetes.

Option A — Install with Windows Package Manager

Open PowerShell as Administrator.

winget install Kubernetes.kubectl

Close and reopen the terminal after installation.

Option B — Use the kubectl Included with Docker Desktop

Docker Desktop may already provide kubectl.

Verify it before installing another copy.

Step 1 — Verify kubectl

PowerShell

kubectl version --client

Git Bash

kubectl version --client

Expected result:

Client Version: ...

Step 2 — Locate kubectl

PowerShell

Get-Command kubectl

Git Bash

which kubectl

Record the installed location as evidence.

Task 04 — Install kind

kind stands for Kubernetes IN Docker.

It creates Kubernetes nodes as Docker containers and is suitable for:

Local laboratories
Development environments
CI/CD testing
Kubernetes security exercises

Option A — Install Using winget

PowerShell as Administrator

winget install Kubernetes.kind

Option B — Install Using Chocolatey

Use this only when Chocolatey is already installed.

choco install kind

Step 1 — Verify kind

PowerShell

kind version

Git Bash

kind version

Expected result:

kind v...

Task 05 — Create the Lab Workspace

Create a dedicated folder for the lab files.

PowerShell

New-Item -ItemType Directory -Path C:\GoHackersCloud-Labs\kubernetes\lab-01 -Force
Set-Location C:\GoHackersCloud-Labs\kubernetes\lab-01

Git Bash

mkdir -p /c/GoHackersCloud-Labs/kubernetes/lab-01
cd /c/GoHackersCloud-Labs/kubernetes/lab-01

Verify the current directory.

PowerShell

Get-Location

Git Bash

pwd

Task 06 — Create the Kubernetes Cluster Configuration

You will create a two-node Kubernetes cluster containing:

One Control Plane node
One Worker Node

Create a file named:

kind-cluster.yaml

Add the following content:

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4

name: cloudnova-security-lab

nodes:
  - role: control-plane

  - role: worker

Save the file inside:

C:\GoHackersCloud-Labs\kubernetes\lab-01

Validate the File

PowerShell

Get-Content .\kind-cluster.yaml

Git Bash

cat kind-cluster.yaml

Expected content:

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4

name: cloudnova-security-lab

nodes:
  - role: control-plane

  - role: worker

Task 07 — Build the Kubernetes Cluster

Step 1 — Create the Cluster

PowerShell

kind create cluster --config .\kind-cluster.yaml

Git Bash

kind create cluster --config kind-cluster.yaml

The process may take several minutes.

Expected output should show stages similar to:

Creating cluster "cloudnova-security-lab"
Ensuring node image
Preparing nodes
Writing configuration
Starting control-plane
Installing CNI
Installing StorageClass
Joining worker nodes
Set kubectl context

Step 2 — Confirm the Cluster Exists

PowerShell

kind get clusters

Git Bash

kind get clusters

Expected result:

cloudnova-security-lab

Step 3 — Verify the kubectl Context

kubectl config current-context

Expected result:

kind-cloudnova-security-lab

The context tells kubectl which Kubernetes cluster it should manage.

Task 08 — Inspect the Kubernetes Nodes

Step 1 — List Nodes

kubectl get nodes

Expected result:

NAME                                      STATUS   ROLES           AGE   VERSION
cloudnova-security-lab-control-plane      Ready    control-plane   ...   ...
cloudnova-security-lab-worker             Ready    <none>          ...   ...

Both nodes should show:

STATUS: Ready

Step 2 — Display Additional Node Information

kubectl get nodes -o wide

Review:

Node name
Node role
Internal IP address
Kubernetes version
Operating system
Container runtime

Step 3 — Inspect the Control Plane Node

kubectl describe node cloudnova-security-lab-control-plane

Locate and review:

Roles
Labels
Taints
Capacity
Allocatable resources
System information
Running Pods
Node conditions

Step 4 — Inspect the Worker Node

kubectl describe node cloudnova-security-lab-worker

Compare the Worker Node with the Control Plane node.

Security Observation

The Control Plane node normally includes a taint that discourages ordinary workloads from being scheduled on it.

Locate a value similar to:

node-role.kubernetes.io/control-plane:NoSchedule

This helps separate cluster management components from application workloads.

Task 09 — Inspect the Control Plane Containers

Because kind runs Kubernetes nodes as Docker containers, you can inspect them directly.

Step 1 — List Docker Containers

docker ps

Expected containers:

cloudnova-security-lab-control-plane
cloudnova-security-lab-worker

Step 2 — Inspect the Control Plane Container

PowerShell

docker inspect cloudnova-security-lab-control-plane

Git Bash

docker inspect cloudnova-security-lab-control-plane

Review:

Container name
Network configuration
Mounted volumes
Runtime settings
Container state

Do not modify the control-plane container manually.

Task 10 — Inspect Kubernetes System Components

Kubernetes system components run inside the kube-system Namespace.

Step 1 — List All Namespaces

kubectl get namespaces

Expected Namespaces include:

default
kube-node-lease
kube-public
kube-system
local-path-storage

Step 2 — List System Pods

kubectl get pods -n kube-system

You should see components such as:

CoreDNS
etcd
kube-apiserver
kube-controller-manager
kube-proxy
kube-scheduler

Step 3 — Display Detailed System Information

kubectl get pods -n kube-system -o wide

Identify:

Which Pods run on the Control Plane
Which components run on each node
The IP address assigned to each Pod

Step 4 — Locate the API Server

kubectl get pods -n kube-system | findstr kube-apiserver

Git Bash alternative:

kubectl get pods -n kube-system | grep kube-apiserver

Step 5 — Locate etcd

PowerShell

kubectl get pods -n kube-system | findstr etcd

Git Bash

kubectl get pods -n kube-system | grep etcd

Step 6 — Locate the Scheduler

PowerShell

kubectl get pods -n kube-system | findstr scheduler

Git Bash

kubectl get pods -n kube-system | grep scheduler

Security Observation

The following components are critical security assets:

kube-apiserver
etcd
kube-controller-manager
kube-scheduler

Compromise of these components can lead to complete cluster compromise.

Task 11 — Review Cluster Information

Run:

kubectl cluster-info

Expected output includes:

Kubernetes control plane is running at ...
CoreDNS is running at ...

Run:

kubectl cluster-info dump

This command produces extensive cluster information.

For this lab, you do not need to analyse the complete output. Confirm that cluster information can be retrieved successfully.

Task 12 — Create a Dedicated Namespace

Do not deploy the application into the default Namespace.

Create a dedicated Namespace named:

cloudnova-lab

Step 1 — Create the Namespace

kubectl create namespace cloudnova-lab

Expected result:

namespace/cloudnova-lab created

Step 2 — Verify the Namespace

kubectl get namespace cloudnova-lab

Step 3 — Inspect the Namespace

kubectl describe namespace cloudnova-lab

Step 4 — Add Enterprise Labels

kubectl label namespace cloudnova-lab environment=development
kubectl label namespace cloudnova-lab owner=cloud-security-team
kubectl label namespace cloudnova-lab business-unit=cloudnova-technologies

Step 5 — Review Namespace Labels

kubectl get namespace cloudnova-lab --show-labels

Expected labels should include:

environment=development
owner=cloud-security-team
business-unit=cloudnova-technologies

Task 13 — Create the Test Deployment

Create a file named:

nginx-deployment.yaml

Add the following configuration:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: cloudnova-web
  namespace: cloudnova-lab
  labels:
    app: cloudnova-web
    environment: development
spec:
  replicas: 2
  selector:
    matchLabels:
      app: cloudnova-web
  template:
    metadata:
      labels:
        app: cloudnova-web
        environment: development
    spec:
      containers:
        - name: nginx
          image: nginx:stable
          ports:
            - name: http
              containerPort: 80
              protocol: TCP
          resources:
            requests:
              cpu: 100m
              memory: 64Mi
            limits:
              cpu: 250m
              memory: 128Mi

Security Controls Included

This Deployment includes:

A dedicated Namespace
Workload labels
Two replicas for availability
CPU requests and limits
Memory requests and limits
A named container port
No public Service exposure

Additional workload hardening will be introduced in later modules.

Step 1 — Apply the Deployment

PowerShell

kubectl apply -f .\nginx-deployment.yaml

Git Bash

kubectl apply -f nginx-deployment.yaml

Expected result:

deployment.apps/cloudnova-web created

Step 2 — Check Deployment Status

kubectl get deployments -n cloudnova-lab

Expected result:

NAME             READY   UP-TO-DATE   AVAILABLE
cloudnova-web    2/2     2            2

Step 3 — Check the Pods

kubectl get pods -n cloudnova-lab

Both Pods should show:

STATUS: Running

Step 4 — Display Pod Placement

kubectl get pods -n cloudnova-lab -o wide

Review:

Pod names
Pod IP addresses
Worker Node assignment
Pod status

The application Pods should normally run on the Worker Node rather than the Control Plane.

Task 14 — Inspect the Deployment Hierarchy

The Deployment creates a ReplicaSet, and the ReplicaSet creates Pods.

Step 1 — View the Deployment

kubectl get deployment cloudnova-web -n cloudnova-lab

Step 2 — View the ReplicaSet

kubectl get replicasets -n cloudnova-lab

Step 3 — View the Pods

kubectl get pods -n cloudnova-lab

The relationship should be:

Deployment
    │
    ▼
ReplicaSet
    │
    ├── Pod 1
    └── Pod 2

Step 4 — Inspect the Deployment

kubectl describe deployment cloudnova-web -n cloudnova-lab

Review:

Replicas
Pod template
Container image
Resource settings
Labels
Events

Step 5 — Inspect One Pod

First, copy one Pod name from:

kubectl get pods -n cloudnova-lab

Then run:

kubectl describe pod <POD-NAME> -n cloudnova-lab

Replace <POD-NAME> with the real Pod name.

Review:

Container image
Container state
Node placement
Pod IP
Resource limits
Service Account
Events

Task 15 — Create an Internal Kubernetes Service

Create a file named:

nginx-service.yaml

Add:

apiVersion: v1
kind: Service
metadata:
  name: cloudnova-web-service
  namespace: cloudnova-lab
  labels:
    app: cloudnova-web
spec:
  type: ClusterIP
  selector:
    app: cloudnova-web
  ports:
    - name: http
      protocol: TCP
      port: 80
      targetPort: 80

Why ClusterIP?

ClusterIP exposes the application only inside the Kubernetes cluster.

This reduces unnecessary public exposure.

Step 1 — Apply the Service

PowerShell

kubectl apply -f .\nginx-service.yaml

Git Bash

kubectl apply -f nginx-service.yaml

Step 2 — Verify the Service

kubectl get services -n cloudnova-lab

Expected result:

NAME                     TYPE        CLUSTER-IP      PORT(S)
cloudnova-web-service    ClusterIP   ...             80/TCP

Step 3 — Inspect the Service

kubectl describe service cloudnova-web-service -n cloudnova-lab

Review:

Service type
Selector
Cluster IP
Port
Target port
Endpoints

Step 4 — Review Service Endpoints

kubectl get endpoints -n cloudnova-lab

The Service endpoints should correspond to the two Pod IP addresses.

Task 16 — Test the Application

Because the Service is internal, use port forwarding for local testing.

Step 1 — Start Port Forwarding

kubectl port-forward service/cloudnova-web-service 8080:80 -n cloudnova-lab

Expected output:

Forwarding from 127.0.0.1:8080 -> 80

Keep this terminal open.

Step 2 — Open the Application

Open a browser and visit:

http://localhost:8080

You should see the default NGINX welcome page.

Step 3 — Stop Port Forwarding

Return to the terminal and press:

Ctrl + C

Security Note

Port forwarding creates a temporary local connection.

It does not create a permanent public Kubernetes Service.

Task 17 — Validate Kubernetes Self-Healing

You will delete one Pod and observe the ReplicaSet create a replacement.

Step 1 — List the Pods

kubectl get pods -n cloudnova-lab

Copy one Pod name.

Step 2 — Delete One Pod

kubectl delete pod <POD-NAME> -n cloudnova-lab

Replace <POD-NAME> with the selected Pod name.

Step 3 — Watch Kubernetes Recover

kubectl get pods -n cloudnova-lab --watch

Observe:

The selected Pod terminates
A replacement Pod is created
The replacement enters the Running state

Press:

Ctrl + C

when the replacement Pod is ready.

Security and Resilience Observation

Kubernetes restored the desired number of replicas automatically.

This demonstrates:

Self-healing
Desired-state management
ReplicaSet functionality
Application resilience

Task 18 — Scale the Application

Step 1 — Scale to Three Replicas

kubectl scale deployment cloudnova-web --replicas=3 -n cloudnova-lab

Step 2 — Verify Scaling

kubectl get deployment cloudnova-web -n cloudnova-lab

kubectl get pods -n cloudnova-lab

You should now have three Pods.

Step 3 — Return to Two Replicas

kubectl scale deployment cloudnova-web --replicas=2 -n cloudnova-lab

Verify:

kubectl get pods -n cloudnova-lab

Task 19 — Perform an Initial Security Review

This is a foundational cluster rather than a fully hardened production environment.

Perform the following checks.

Check 1 — Confirm the Application Uses a Dedicated Namespace

kubectl get all -n cloudnova-lab

Expected result:

The application resources exist inside cloudnova-lab.

Check 2 — Confirm the Service is Not Public

kubectl get service cloudnova-web-service -n cloudnova-lab

Expected Service type:

ClusterIP

The Service should not be:

NodePort
LoadBalancer

Check 3 — Confirm Resource Limits Exist

kubectl get deployment cloudnova-web -n cloudnova-lab -o yaml

Locate:

resources:
  requests:
  limits:

Resource controls help reduce resource exhaustion risks.

Check 4 — Review the Default Service Account

kubectl get serviceaccounts -n cloudnova-lab

Expected result:

default

The workload currently uses the default Service Account.

In production, dedicated Service Accounts should be created with minimum permissions.

Check 5 — Check Pod Security Context

kubectl get deployment cloudnova-web -n cloudnova-lab -o yaml

Search for:

securityContext

The current Deployment does not yet contain a complete security context.

Record this as a security improvement opportunity.

Later modules will implement controls such as:

runAsNonRoot
allowPrivilegeEscalation: false
Read-only root filesystem
Dropped Linux capabilities
Seccomp profiles

Check 6 — Review Cluster Permissions

kubectl auth can-i --list -n cloudnova-lab

This displays the actions your current identity can perform.

Because this is a local administrative lab cluster, your current context will likely have extensive permissions.

Production users should not receive unrestricted cluster administration permissions.

Check 7 — Review API Resources

kubectl api-resources

Observe the number of Kubernetes resource types controlled through the API Server.

This demonstrates why API access must be protected.

Task 20 — Review Cluster Events

Cluster events help with troubleshooting and security investigations.

Namespace Events

kubectl get events -n cloudnova-lab --sort-by=.metadata.creationTimestamp

All Namespace Events

kubectl get events --all-namespaces --sort-by=.metadata.creationTimestamp

Review events related to:

Pod scheduling
Image pulling
Container creation
Pod termination
Replica creation
Scaling

Task 21 — Review Container Logs

Step 1 — Get a Pod Name

kubectl get pods -n cloudnova-lab

Step 2 — Read Logs

kubectl logs <POD-NAME> -n cloudnova-lab

Replace <POD-NAME> with a running Pod.

After accessing the application through port forwarding, the log may contain an HTTP request similar to:

GET / HTTP/1.1

Step 3 — View Logs by Deployment

kubectl logs deployment/cloudnova-web -n cloudnova-lab

Logs provide valuable information during troubleshooting and incident investigations.

Task 22 — Collect Lab Evidence

Capture evidence for the following items.

Evidence 01 — Tool Installation

docker version
kubectl version --client
kind version

Evidence 02 — Cluster

kind get clusters
kubectl config current-context
kubectl cluster-info

Evidence 03 — Nodes

kubectl get nodes -o wide

Evidence 04 — System Components

kubectl get pods -n kube-system -o wide

Evidence 05 — Namespace

kubectl get namespace cloudnova-lab --show-labels

Evidence 06 — Application Resources

kubectl get all -n cloudnova-lab

Evidence 07 — Resource Configuration

kubectl describe deployment cloudnova-web -n cloudnova-lab

Evidence 08 — Service

kubectl get service cloudnova-web-service -n cloudnova-lab

Evidence 09 — Running Application

Capture the NGINX page displayed at:

http://localhost:8080

Evidence 10 — Self-Healing

Capture the replacement Pod created after deleting the original Pod.

Task 23 — Complete the Security Assessment

Create a file named:

initial-security-assessment.md

Use the following template:

# CloudNova Kubernetes Initial Security Assessment

## Environment

- Cluster name:
- Cluster type:
- Number of Control Plane nodes:
- Number of Worker Nodes:
- Kubernetes context:

## Implemented Controls

- Dedicated application Namespace:
- Namespace labels:
- Internal ClusterIP Service:
- Resource requests:
- Resource limits:
- Multiple application replicas:
- Control Plane workload separation:

## Identified Security Gaps

- Dedicated Service Account:
- Pod security context:
- Network Policy:
- RBAC restrictions:
- Image vulnerability scanning:
- Runtime security monitoring:
- Secrets management:
- Audit logging review:

## Risk Summary

Describe the primary risks that would need to be addressed before this environment could be used for production workloads.

## Recommended Next Actions

1.
2.
3.
4.
5.

## Assessment Status

- Suitable for local learning:
- Suitable for development:
- Suitable for production:

Suggested Assessment Conclusion

Your conclusion should recognise that the cluster is:

Suitable for local learning and controlled development testing.

It is not yet suitable for production because additional controls are required.

Task 24 — Clean Up the Application Resources

Before deleting the complete cluster, remove the application resources individually.

Step 1 — Delete the Service

PowerShell

kubectl delete -f .\nginx-service.yaml

Git Bash

kubectl delete -f nginx-service.yaml

Step 2 — Delete the Deployment

PowerShell

kubectl delete -f .\nginx-deployment.yaml

Git Bash

kubectl delete -f nginx-deployment.yaml

Step 3 — Delete the Namespace

kubectl delete namespace cloudnova-lab

Step 4 — Confirm Removal

kubectl get namespace cloudnova-lab

Expected result:

NotFound

Task 25 — Delete the Kubernetes Cluster

Step 1 — Delete the Cluster

kind delete cluster --name cloudnova-security-lab

Expected result:

Deleted nodes:
cloudnova-security-lab-control-plane
cloudnova-security-lab-worker

Step 2 — Confirm Cluster Removal

kind get clusters

The cluster should no longer appear.

Step 3 — Confirm Docker Containers Were Removed

docker ps

The kind Control Plane and Worker Node containers should no longer be running.

Troubleshooting Guide

Issue 01 — Docker Command Not Found

Error:

docker is not recognized

Resolution:

Confirm Docker Desktop is installed.
Restart the terminal.
Restart Docker Desktop.
Confirm Docker is included in the system PATH.

Issue 02 — Docker Engine Is Not Running

Error:

Cannot connect to the Docker daemon

Resolution:

Start Docker Desktop.
Wait for the engine to report that it is running.
Run docker version again.

Issue 03 — kind Command Not Found

Error:

kind is not recognized

Resolution:

Close and reopen PowerShell.
Confirm installation using winget list.
Check whether the kind executable is in the system PATH.

Issue 04 — Cluster Creation Fails

Possible causes:

Docker Desktop is not running
Insufficient memory
Virtualisation is disabled
Previous cluster resources exist
Security software is blocking Docker networking

Check:

docker ps
kind get clusters

Delete a failed cluster:

kind delete cluster --name cloudnova-security-lab

Then retry:

kind create cluster --config kind-cluster.yaml

Issue 05 — Nodes Show NotReady

Check:

kubectl get nodes
kubectl get pods -n kube-system
kubectl describe node cloudnova-security-lab-worker

Wait for system Pods to finish starting.

Docker Desktop may require additional CPU or memory.

Issue 06 — Pods Remain Pending

Check:

kubectl describe pod <POD-NAME> -n cloudnova-lab

Review the Events section for:

Scheduling failures
Resource shortages
Image pull errors
Node readiness issues

Issue 07 — ImagePullBackOff

Check:

kubectl describe pod <POD-NAME> -n cloudnova-lab

Confirm:

Internet access is available
Docker can reach the image registry
The image name is correct

Issue 08 — Port 8080 Is Already in Use

Use another local port:

kubectl port-forward service/cloudnova-web-service 8081:80 -n cloudnova-lab

Open:

http://localhost:8081

Validation Checklist

Confirm that you successfully completed the following:

Knowledge Check

Question 1

What does kind use to create Kubernetes nodes?

A. Physical servers
B. Docker containers
C. AWS Lambda functions
D. Virtual private networks

Answer: B

Question 2

Which tool communicates with the Kubernetes API Server?

A. Git
B. Docker Compose
C. kubectl
D. Visual Studio Code

Answer: C

Question 3

Why was the application deployed into a dedicated Namespace?

A. To make the image smaller
B. To provide logical organisation and separation
C. To replace the Worker Node
D. To encrypt all network traffic

Answer: B

Question 4

Which Kubernetes object maintained the required number of application Pods?

A. Service
B. ConfigMap
C. ReplicaSet
D. Namespace

Answer: C

Question 5

Why was a ClusterIP Service selected?

A. To expose the application publicly
B. To provide an internal stable endpoint
C. To create a Worker Node
D. To store application data

Answer: B

Question 6

What happened when one Pod was deleted?

A. The complete cluster stopped.
B. Kubernetes created a replacement Pod.
C. The Namespace was deleted.
D. The Service became a LoadBalancer.

Answer: B

Question 7

Which identified security gap should be addressed in a later workload-hardening lab?

A. Kubernetes does not support containers.
B. The Deployment lacks a complete Pod security context.
C. The cluster contains a Worker Node.
D. The application uses a Service.

Answer: B

Skills Developed

By completing this lab, you practised:

Kubernetes cluster provisioning
Kubernetes command-line administration
Control Plane inspection
Worker Node inspection
Namespace management
Deployment management
ReplicaSet inspection
Pod troubleshooting
Service configuration
Port forwarding
Self-healing validation
Resource configuration review
Basic Kubernetes security assessment
Evidence collection
Secure resource cleanup

Lab Summary

In this lab, you built your first Kubernetes cluster for CloudNova Technologies.

You created a two-node cluster containing a Control Plane and Worker Node, inspected the Kubernetes system components, deployed a containerised application, created an internal Service, validated self-healing, and completed an initial security review.

You also identified several controls that must be implemented before the cluster could support production workloads, including:

Dedicated Service Accounts
RBAC restrictions
Pod security contexts
Network Policies
Image vulnerability scanning
Runtime monitoring
Secrets management
Audit log analysis

This cluster-building experience provides the foundation for every Kubernetes security assessment, hardening activity, and incident investigation you will perform later in the learning path.

What’s Next?

In the next lab, you will deploy an application using stronger workload controls and begin applying security principles directly to Kubernetes resources.

➡️ Next Lab: Lab 02 — Deploy Your First Secure Application