01 KCNA

The Kubernetes and Cloud Native Associate (KCNA) certification is designed for learners who want to build a strong foundation in:

Cloud-Native Computing

Containers

Kubernetes

Application Delivery

Observability

Cloud-Native Security

KCNA is a good starting point before moving into more hands-on Kubernetes certifications such as:

CKA

CKAD

CKS

The main goal at this stage is not deep cluster administration.

It is to understand:

What Kubernetes is

Why organizations use it

How its major components work

How cloud-native applications are deployed

How modern platforms are observed and secured

Where KCNA Fits

The certification journey in this path is:

KCNA
  ↓
CKA
  ↓
CKAD
  ↓
CKS

From a security-career perspective:

Cloud-Native Fundamentals
        ↓
Kubernetes Fundamentals
        ↓
Administration Skills
        ↓
Security Engineering

Who Should Study KCNA?

KCNA is useful for:

Students

Fresh Graduates

Cloud Beginners

Junior DevOps Engineers

Platform Engineering Beginners

Security Professionals New to Kubernetes

Technical Support Engineers

It can also help professionals who work around Kubernetes but are not yet responsible for administering clusters directly.

KCNA Learning Mindset

At this stage, focus on understanding relationships.

Instead of memorizing:

Pod

Service

Deployment

Container

understand how they connect:

Container Image
      ↓
Pod
      ↓
Deployment
      ↓
Service
      ↓
Application Access

That relationship-based understanding becomes important later when troubleshooting and securing Kubernetes.

Part 01 — Cloud-Native Fundamentals

Before Kubernetes, understand what cloud-native means.

Cloud-native systems are commonly designed around ideas such as:

Containers

Microservices

Automation

APIs

Elastic Infrastructure

Declarative Configuration

Observability

Traditional Application Model

A traditional application may look like:

Large Application
      ↓
Single Server
      ↓
Manual Deployment
      ↓
Manual Scaling

This can work, but modern systems often require greater flexibility.

Cloud-Native Model

A cloud-native application may look like:

Frontend
   ↓
API
   ↓
Backend Services
   ↓
Database

Individual components can be:

Deployed Independently

Scaled Independently

Updated Independently

Why Cloud-Native?

Organizations adopt cloud-native architectures for reasons such as:

Scalability

Automation

Resilience

Faster Deployment

Portability

Developer Productivity

Key Concept — Microservices

A microservices architecture divides application functionality into smaller services.

Example:

Online Store
│
├── User Service
├── Product Service
├── Order Service
├── Payment Service
└── Notification Service

Each service performs a focused function.

Microservices Benefits

Potential benefits include:

Independent Deployment

Independent Scaling

Clear Service Boundaries

Technology Flexibility

Microservices Challenges

They also create complexity around:

Networking

Identity

Observability

Service Discovery

Security

Data Consistency

Kubernetes helps manage some of this operational complexity.

Part 02 — Containers

Containers package applications together with the dependencies they require.

Container Workflow

Application Code
      ↓
Container Image
      ↓
Container Registry
      ↓
Container Runtime
      ↓
Running Container

Container Image

An image is a packaged artifact used to create containers.

It may contain:

Application

Runtime

Libraries

Configuration

Running Container

A container is a running instance of an image.

Conceptually:

Image
  ↓
Start
  ↓
Container

Container vs Virtual Machine

Virtual Machine	Container
Includes guest OS	Shares host kernel
Typically heavier	Typically lighter
Slower startup	Faster startup
Strong VM boundary	Process-level isolation model
Hypervisor based	Container runtime based

Container Registry

Images are commonly stored in registries.

Flow:

Developer
   ↓
Build Image
   ↓
Registry
   ↓
Deployment Platform

Container Security Perspective

Always ask:

Who created the image?

What software is inside it?

Is the image trusted?

Does it contain vulnerabilities?

Does it contain secrets?

Part 03 — Why Kubernetes?

Containers solve application packaging.

But organizations may need to run:

Hundreds

Thousands

or More

containers.

Managing these manually becomes difficult.

Organizations need:

Scheduling

Scaling

Recovery

Networking

Configuration

Updates

Kubernetes provides orchestration for these workloads.

Container Orchestration

Container orchestration means managing containers across infrastructure.

Kubernetes can help with:

Deployment

Scheduling

Scaling

Service Discovery

Recovery

Configuration

Resource Management

Desired State

A core Kubernetes concept is:

Desired State

You describe how the environment should look.

Kubernetes continuously works toward that state.

Example:

Desired:
3 Application Pods

If one Pod fails:

3 Pods
   ↓
1 Fails
   ↓
2 Running
   ↓
Kubernetes Creates Replacement
   ↓
3 Running

Declarative Management

Instead of manually issuing every operational action, you define the desired configuration.

Conceptually:

Desired Configuration
        ↓
Kubernetes API
        ↓
Controllers
        ↓
Actual Environment

Part 04 — Kubernetes Architecture

A Kubernetes environment is called a:

Cluster

A cluster generally includes:

Control Plane

Worker Nodes

High-Level Architecture

Kubernetes Cluster
│
├── Control Plane
│
│   ├── API Server
│   ├── Scheduler
│   ├── Controllers
│   └── Cluster State
│
└── Worker Nodes
    │
    ├── Node Components
    ├── Container Runtime
    └── Pods

Control Plane

The control plane manages the cluster.

Think:

Control Plane
     ↓
Makes Decisions
     ↓
Worker Nodes
     ↓
Run Workloads

API Server

The API server is a central Kubernetes component.

Administrative requests commonly flow through it.

User / Automation
       ↓
Kubernetes API
       ↓
Cluster Resources

Security Importance

The Kubernetes API is a critical security boundary because it can control:

Workloads

Permissions

Secrets

Networking Configuration

Cluster Resources

Scheduler

The scheduler determines where workloads should run.

Conceptually:

New Pod
   ↓
Scheduler
   ↓
Select Appropriate Node

The scheduler may consider factors such as:

Available Resources

Placement Requirements

Node Conditions

Scheduling Rules

Controllers

Controllers continually compare:

Desired State

vs

Actual State

Then take action when they differ.

Cluster State

Kubernetes needs a consistent representation of cluster configuration and state.

Security implications include protecting:

Cluster Configuration

Credentials

Sensitive Resource Data

Worker Nodes

Worker nodes run application workloads.

Conceptually:

Worker Node
│
├── Kubernetes Node Components
├── Container Runtime
└── Pods

Node Security

Later security work will examine:

Node Hardening

Runtime Security

Patch Management

Access Control

Part 05 — Pods

The Pod is one of the most important Kubernetes concepts.

A Pod is the smallest commonly deployed Kubernetes workload unit.

Pod Model

Pod
│
├── Container
└── Shared Pod Resources

A Pod can contain more than one container where the design requires it.

Why Not Manage Containers Directly?

Kubernetes typically manages:

Pods

rather than individual containers as isolated scheduling units.

Pod Lifecycle

Pods are generally considered replaceable.

Think:

Pod Fails
   ↓
Replacement Pod Created

rather than:

Repair the Same Pod Forever

Important Mindset

Kubernetes workloads are designed around:

Replace

Reconcile

Automate

rather than manually repairing individual instances.

Part 06 — Deployments

A Deployment manages application replicas and rollout behavior.

Example:

Deployment
    ↓
ReplicaSet
    ↓
Pods

Desired Replicas

Example:

Desired Replicas:
3

Kubernetes attempts to keep:

Pod 1

Pod 2

Pod 3

running.

Scaling

A Deployment can change:

3 Pods
   ↓
5 Pods

to handle increased demand.

Rolling Updates

Deployments can support controlled application updates.

Conceptually:

Version 1 Pods
      ↓
Gradual Replacement
      ↓
Version 2 Pods

This helps reduce service interruption.

Part 07 — ReplicaSets

ReplicaSets help maintain a desired number of Pods.

Relationship:

Deployment
    ↓
ReplicaSet
    ↓
Pods

In many normal workflows, users interact primarily with Deployments rather than manually managing ReplicaSets.

Part 08 — Namespaces

Namespaces logically organize Kubernetes resources.

Example:

Cluster
│
├── Development Namespace
├── Testing Namespace
├── Production Namespace
└── Security Namespace

Namespace Use Cases

Namespaces can help with:

Organization

Access Control

Resource Separation

Policy Scope

Security Perspective

Namespaces should not automatically be treated as complete security boundaries.

Additional controls may still be required, including:

RBAC

Network Policies

Admission Policies

Workload Security

Part 09 — Labels and Selectors

Labels provide metadata used to organize and identify resources.

Conceptually:

Pod
  ↓
Label:
app=frontend

A selector can identify resources matching that label.

Example:

Selector:
app=frontend

Why Labels Matter

Labels are used throughout Kubernetes for:

Service Selection

Deployment Management

Scheduling

Policy

Organization

Part 10 — Kubernetes Services

Pods may be replaced and their network identities can change.

Applications therefore need a stable way to reach workloads.

A Kubernetes Service provides this abstraction.

Service Flow

Client
  ↓
Service
  ↓
Pod 1
Pod 2
Pod 3

Service Selection

The Service commonly identifies backend Pods through labels.

Service
  ↓
Selector
  ↓
Matching Pods

Why Services Matter

Services provide:

Stable Application Access

Load Distribution

Service Discovery

Part 11 — Kubernetes Networking

Kubernetes networking connects:

Pods

Services

Nodes

External Clients

Basic Traffic Flow

Client
  ↓
Ingress / External Entry
  ↓
Service
  ↓
Pod

Pod-to-Pod Communication

Applications may require communication such as:

Frontend
   ↓
Backend
   ↓
Database

Security Perspective

Later, this becomes a security question:

Should every Pod communicate
with every other Pod?

Usually, the desired model is:

Only Required Communication

This leads to Kubernetes NetworkPolicies.

Part 12 — DNS and Service Discovery

Applications need to locate other services.

Instead of hardcoding changing Pod addresses:

Application
   ↓
Service Name
   ↓
DNS
   ↓
Kubernetes Service

This supports dynamic environments.

Part 13 — Ingress

Ingress commonly provides controlled HTTP/HTTPS routing into applications.

Conceptually:

Internet
   ↓
Ingress
   ↓
Service
   ↓
Pods

Ingress may support routing based on:

Hostname

Path

TLS

Security Perspective

Ingress is an important security point because it may handle:

External Exposure

TLS

Application Routing

Part 14 — Configuration

Applications require configuration.

Kubernetes commonly separates configuration from application images.

ConfigMap

ConfigMaps can hold non-sensitive configuration.

Examples:

Application Mode

Feature Setting

Service Endpoint

Configuration Flow

ConfigMap
    ↓
Application Pod

Why Separate Configuration?

Benefits include:

Reusable Images

Environment-Specific Configuration

Easier Deployment Management

Part 15 — Secrets

Applications also require sensitive information.

Examples:

Passwords

Tokens

API Keys

Certificates

Kubernetes provides Secret resources for managing sensitive values within its resource model.

Important Security Principle

Do not assume:

Kubernetes Secret
      =
Automatically Fully Protected

Security still depends on:

RBAC

Storage Protection

Secret Distribution

Logging

Rotation

Workload Access

Secret Risk

If a user can read sensitive Secrets:

Secret Access
     ↓
Credential Access
     ↓
External System Access

This becomes important in CKS-level security.

Part 16 — Storage

Containers are often temporary.

But applications may require persistent data.

Kubernetes provides storage concepts such as:

Persistent Volume

Persistent Volume Claim

Storage Class

Storage Flow

Application
    ↓
Persistent Volume Claim
    ↓
Persistent Storage

Persistent Volume

A Persistent Volume represents storage available to the cluster.

Persistent Volume Claim

A workload requests storage through a claim.

Conceptually:

Pod
 ↓
PVC
 ↓
PV
 ↓
Storage

Storage Security

Security questions include:

What data is stored?

Who can access it?

Is it encrypted?

Where is it physically or logically hosted?

How is it backed up?

Part 17 — Stateful vs Stateless Applications

Stateless

A stateless application does not depend on local instance data.

Example:

Web Frontend

Instances can often be replaced more easily.

Stateful

A stateful application maintains important data.

Examples:

Database

Message Platform

Stateful Processing System

Stateful systems require careful attention to:

Storage

Identity

Backup

Recovery

Part 18 — Jobs and CronJobs

Not all workloads run continuously.

Job

A Job runs work intended to complete.

Example:

Data Processing Task

CronJob

A CronJob schedules recurring work.

Example:

Nightly Backup Task

Security Perspective

Scheduled workloads also require security review.

Ask:

Which identity do they use?

What resources can they access?

What secrets do they receive?

Part 19 — Resource Management

Applications consume:

CPU

Memory

Kubernetes allows workloads to define resource expectations.

Requests

Requests describe resources a workload expects.

Limits

Limits restrict resource consumption.

Conceptually:

Request
  ↓
Scheduling Decision

Limit
  ↓
Maximum Resource Usage

Why Resource Management Matters

Without good resource management:

One Workload
     ↓
Consumes Excessive Resources
     ↓
Impacts Other Workloads

This can affect reliability and security.

Part 20 — Scheduling

The scheduler decides where Pods should run.

Basic decision:

Pod
 ↓
Requirements
 ↓
Available Nodes
 ↓
Selected Node

Scheduling Controls

Later you may encounter:

Node Selectors

Affinity

Anti-Affinity

Taints

Tolerations

At KCNA level, understand why placement controls exist.

Part 21 — Taints and Tolerations

Taints can discourage or prevent workloads from being scheduled onto particular nodes unless they tolerate the taint.

Conceptually:

Special Node
    ↓
Taint
    ↓
Only Approved Workload
with Toleration

This can help dedicate nodes for specific purposes.

Part 22 — Observability

Cloud-native systems require visibility.

Observability commonly includes:

Logs

Metrics

Traces

Logs

Logs answer:

What happened?

Metrics

Metrics answer:

How is the system behaving?

Examples:

CPU Usage

Memory Usage

Request Rate

Error Rate

Traces

Tracing helps understand how requests move across distributed systems.

Example:

User Request
     ↓
Frontend
     ↓
API
     ↓
Payment Service
     ↓
Database

Why Observability Matters

Without visibility:

Failure Occurs
   ↓
No Evidence
   ↓
Slow Troubleshooting

With good observability:

Failure
  ↓
Telemetry
  ↓
Analysis
  ↓
Root Cause

Security Connection

Observability also supports:

Detection

Investigation

Incident Response

Part 23 — Application Health

Kubernetes needs to determine whether applications are working correctly.

Common health concepts include:

Startup

Readiness

Liveness

Readiness

Answers:

Can this workload receive traffic?

Liveness

Answers:

Is this workload still functioning?

Startup

Helps accommodate applications that require additional startup time.

Operational Benefit

Health checks help Kubernetes make better recovery and traffic-management decisions.

Part 24 — Application Delivery

Modern cloud-native applications often use automated delivery.

A simplified pipeline:

Developer
   ↓
Source Control
   ↓
Build
   ↓
Test
   ↓
Container Image
   ↓
Registry
   ↓
Kubernetes

CI

Continuous Integration commonly focuses on:

Build

Test

Validate

CD

Continuous Delivery or deployment focuses on delivering changes toward production environments.

Security Connection

Security should become part of this lifecycle:

Code
 ↓
Security Checks
 ↓
Image
 ↓
Security Checks
 ↓
Deployment Policy
 ↓
Runtime Monitoring

This becomes important in DevSecOps and CKS.

Part 25 — GitOps

GitOps commonly uses version-controlled declarative configuration as a source for platform changes.

Conceptually:

Git Repository
      ↓
Desired Configuration
      ↓
Automation
      ↓
Kubernetes

Benefits

Potential benefits include:

Version History

Review

Consistency

Automation

Rollback Support

Security Consideration

If Git controls production configuration, repository security becomes critical.

Ask:

Who can modify production configuration?

Who approves changes?

How are credentials protected?

Part 26 — Autoscaling

Cloud-native environments may automatically adapt to workload demand.

Conceptually:

Traffic Increases
      ↓
Resource Demand Increases
      ↓
Additional Capacity

Kubernetes supports different scaling patterns depending on architecture and implementation.

At KCNA level, understand the purpose of elasticity.

Part 27 — Resilience

Cloud-native systems should be designed to tolerate failure.

Remember:

Failure Is Expected

Kubernetes supports recovery through reconciliation.

Example:

Pod Failure
   ↓
Controller Detects Difference
   ↓
Replacement Created

High Availability

Production platforms may distribute workloads and control-plane components to reduce single points of failure.

Security Connection

Availability is part of the:

CIA Triad

Therefore resilience is also a security concern.

Part 28 — Cloud-Native Security Fundamentals

Security should exist throughout the lifecycle.

Think:

Code
 ↓
Build
 ↓
Image
 ↓
Registry
 ↓
Deployment
 ↓
Runtime

Security Layers

Layer 1 — Source

Protect:

Repositories

Developer Accounts

Code Changes

Layer 2 — Build

Protect:

CI/CD

Build Workers

Dependencies

Credentials

Layer 3 — Image

Protect:

Base Images

Packages

Vulnerabilities

Image Integrity

Layer 4 — Registry

Protect:

Image Access

Image Modification

Image Provenance

Layer 5 — Kubernetes

Protect:

API

RBAC

Secrets

Network

Workloads

Layer 6 — Runtime

Monitor:

Processes

Network Connections

File Activity

Unexpected Behavior

Part 29 — Kubernetes Authentication

Authentication answers:

Who are you?

Kubernetes environments may integrate with:

Certificates

Tokens

External Identity Providers

Cloud Identity Platforms

Authentication Flow

User
 ↓
Authentication
 ↓
Kubernetes API

Security Principle

Strong authentication should protect high-risk administrative access.

Part 30 — Kubernetes Authorization

After authentication, Kubernetes determines:

What can you do?

One major authorization model is:

RBAC

RBAC Model

User / Service Account
        ↓
Role
        ↓
Permissions

KCNA-Level Goal

At this stage, understand:

Authentication
      ≠
Authorization

You will explore RBAC much more deeply in later Kubernetes security labs.

Part 31 — Service Accounts

Applications also need identities.

Kubernetes provides:

Service Accounts

for workloads.

Example:

Pod
 ↓
Service Account
 ↓
API Permissions

Security Question

Ask:

Does the Pod actually require
Kubernetes API access?

If yes:

What exact permissions does it require?

Part 32 — Network Security

Applications require network access, but unrestricted connectivity can create risk.

Think:

Frontend
   ↓
Backend
   ↓
Database

The desired policy should generally allow required communication while limiting unnecessary connectivity.

Network Policies

NetworkPolicies can help control:

Ingress

Egress

You will explore these deeply in the Kubernetes Network Policies lab.

Part 33 — Workload Security

Workloads should be configured securely.

Important considerations include:

Root Execution

Privileged Mode

Capabilities

Host Access

Service Accounts

Secrets

Image Security

Security Question

For every Pod ask:

What happens if this application
is compromised?

Then determine:

Which permissions?

Which networks?

Which secrets?

Which host resources?

the attacker could potentially reach.

Part 34 — Policy Enforcement

Organizations need consistent security controls.

Manual process:

Security Standard
      ↓
Developer Reads Document
      ↓
Developer Creates Workload

Automated approach:

Deployment
   ↓
Policy Validation
   ↓
Allow / Reject

Technologies such as:

Kyverno

OPA Gatekeeper

can support Kubernetes policy enforcement.

These are covered later in the labs.

Part 35 — Runtime Security

A workload can be secure at deployment time and still become compromised later.

Runtime monitoring may detect:

Unexpected Shell

Unexpected Process

Suspicious File Access

Privilege Escalation

Unexpected Network Connection

This becomes a major topic in Kubernetes security specialization.

Part 36 — CNCF and the Cloud-Native Ecosystem

Kubernetes belongs to a broader cloud-native ecosystem.

You should understand that organizations may combine Kubernetes with technologies for:

Monitoring

Logging

Networking

Service Mesh

Security

Storage

Delivery

The goal is not to memorize every project.

Understand that Kubernetes often functions as one component within a larger platform ecosystem.

Part 37 — Service Mesh Concept

A service mesh can help manage communication between distributed services.

Conceptually:

Service A
    ↓
Service Communication Layer
    ↓
Service B

Capabilities may include:

Traffic Management

Observability

Service Identity

Encryption

At KCNA level, understand the purpose rather than deep implementation.

Part 38 — Serverless and Cloud-Native

Cloud-native computing is broader than Kubernetes.

Organizations may also use:

Serverless Functions

Managed Containers

Platform Services

Event-Driven Systems

KCNA knowledge should therefore include broader cloud-native concepts, not Kubernetes alone.

Part 39 — Cloud-Native Security Lifecycle

Use this model:

Design
  ↓
Develop
  ↓
Build
  ↓
Package
  ↓
Deploy
  ↓
Operate
  ↓
Monitor
  ↓
Improve

Security should be integrated throughout.

Shift Left

The idea of shifting security left means identifying problems earlier.

Instead of:

Production
   ↓
Security Finds Problem

prefer:

Development
   ↓
Security Validation
   ↓
Build
   ↓
Security Validation
   ↓
Deployment

Do Not Forget Runtime

Shift-left does not mean security ends before production.

Use:

Build-Time Security
        +
Runtime Security

Part 40 — Practical KCNA Lab Journey

Before moving to CKA, practice the basics.

Exercise 01 — Identify Kubernetes Components

Draw:

Control Plane

Worker Node

API Server

Scheduler

Controller

Pod

Explain the purpose of each.

Exercise 02 — Workload Relationship

Create this conceptual map:

Deployment
    ↓
ReplicaSet
    ↓
Pods
    ↓
Service

Explain what each component provides.

Exercise 03 — Application Architecture

Design:

Internet
   ↓
Frontend
   ↓
Backend
   ↓
Database

Identify:

Which components could run in Kubernetes?

Which component requires persistent storage?

Which traffic flows are required?

Exercise 04 — Configuration

Separate:

Application Image

Non-Sensitive Configuration

Sensitive Configuration

into:

Image

ConfigMap

Secret

conceptually.

Exercise 05 — Security Review

For a workload, answer:

Which image does it use?

Which service account?

Which namespace?

Which service exposes it?

Which secrets can it access?

This introduces the Kubernetes security mindset.

KCNA Study Strategy

Use this learning cycle:

Learn Concept
     ↓
Draw Architecture
     ↓
Explain in Your Own Words
     ↓
Practice
     ↓
Review

Avoid Passive Study

Do not only:

Watch Videos

Read Notes

Memorize Terms

Also:

Draw

Build

Inspect

Explain

Troubleshoot

Concept Comparison Practice

Make sure you can confidently explain:

Concept A	Concept B
Container	Pod
Pod	Deployment
Deployment	Service
ConfigMap	Secret
Node	Cluster
Control Plane	Worker Node
Authentication	Authorization
Logs	Metrics
Stateless	Stateful

KCNA Security Thinking

For every concept, add one security question.

Example:

Container Image

Is the image trusted?

Kubernetes API

Who can access it?

Service Account

Which permissions does it have?

Secret

Who can read it?

Service

Who can reach it?

Storage

What sensitive information does it contain?

This habit prepares you for CKS long before you study CKS directly.

Common KCNA Preparation Mistakes

Mistake 1 — Learning Kubernetes Before Containers

Understand containers first.

Mistake 2 — Memorizing Definitions Without Relationships

Kubernetes resources work together.

Mistake 3 — Ignoring Networking

Networking becomes increasingly important in CKA and CKS.

Mistake 4 — Ignoring Security Until CKS

Begin developing security thinking now.

Mistake 5 — Trying to Memorize the Entire Cloud-Native Ecosystem

Focus on concepts and use cases.

Mistake 6 — Thinking Kubernetes Automatically Makes Applications Secure

Kubernetes provides capabilities.

Security still requires correct:

Configuration

Identity

Networking

Workload Controls

Monitoring

KCNA Career Connection

KCNA-level knowledge can support your progression toward:

Cloud Engineer

Junior DevOps Engineer

Junior Platform Engineer

Technical Support Engineer

Cloud Security Engineer

It is primarily a foundation rather than the final career destination.

From KCNA to Cloud Security

A cloud security learner may progress:

KCNA
  ↓
Kubernetes Fundamentals
  ↓
CKA-Level Administration
  ↓
RBAC
  ↓
Network Policies
  ↓
Workload Security
  ↓
Runtime Security
  ↓
CKS

From KCNA to DevOps

KCNA
  ↓
Kubernetes Administration
  ↓
CKA
  ↓
CI/CD
  ↓
GitOps
  ↓
Platform Engineering

From KCNA to Development

KCNA
  ↓
Kubernetes Application Design
  ↓
CKAD
  ↓
Cloud-Native Development

Interview Preparation

Be ready to answer:

What is cloud-native computing?
What is Kubernetes?
Why do organizations use Kubernetes?
What problem does container orchestration solve?
What is a container?
What is a container image?
What is a container registry?
What is the difference between a container and a VM?
What is a Kubernetes cluster?
What is the control plane?
What is a worker node?
What is the Kubernetes API server?
What does the scheduler do?
What does a controller do?
What is desired state?
What is reconciliation?
What is a Pod?
What is a Deployment?
What is a ReplicaSet?
What is a Service?
Why do Kubernetes applications use Services?
What is a Namespace?
What are labels and selectors?
What is a ConfigMap?
What is a Secret?
What is a Persistent Volume?
What is a Persistent Volume Claim?
What is the difference between stateful and stateless?
What is a Job?
What is a CronJob?
What are resource requests?
What are resource limits?
What is Kubernetes ingress?
What is service discovery?
What are logs?
What are metrics?
What are traces?
What is Kubernetes RBAC?
What is a service account?
Why is Kubernetes security a shared responsibility across multiple layers?

KCNA Readiness Checklist

Cloud-Native Fundamentals

Kubernetes Architecture

Kubernetes Workloads

Networking

Configuration and Storage

Observability

Application Delivery

Understand container registries
Understand CI/CD conceptually
Understand GitOps conceptually
Understand automated delivery

Security

Understand authentication
Understand authorization
Understand RBAC conceptually
Understand service accounts
Understand workload security concepts
Understand network security concepts
Understand runtime security concepts

Practical Readiness Milestone

Before moving deeper into Kubernetes administration, you should be able to look at:

Deployment
   ↓
Pods
   ↓
Service
   ↓
Users

and explain:

Why each resource exists

How the resources relate

Where configuration lives

How networking works

Where identity appears

Where security controls should be applied

Final KCNA Mental Model

Remember this architecture:

Developer
   ↓
Application
   ↓
Container Image
   ↓
Registry
   ↓
Kubernetes Deployment
   ↓
Pods
   ↓
Service
   ↓
Users

Around this architecture are:

Configuration

Storage

Networking

Observability

Security

Automation

That is the foundation of cloud-native Kubernetes knowledge.

Certification Outcome

After completing KCNA preparation, you should move from:

I Have Heard of Kubernetes

to:

I Understand How
Cloud-Native Systems,
Containers,
and Kubernetes
Fit Together.

That foundation prepares you for deeper hands-on administration.

What’s Next?

➡️ 02 — CKA

In the next lesson, you will move from Kubernetes concepts into practical cluster administration and operational skills covering:

Cluster Architecture
        ↓
Workload Management
        ↓
Scheduling
        ↓
Services and Networking
        ↓
Storage
        ↓
Cluster Administration
        ↓
Troubleshooting

The progression is:

KCNA
  ↓
Understand Kubernetes
  ↓
CKA
  ↓
Operate Kubernetes