← All Certifications Reviewed 30 September 2026 · Red Hat & Linux Foundation

Linux & Kubernetes Exam Prep

Hands-on preparation for RHCSA (EX200), Red Hat's current Ansible administrator exam (EX294), CKA, CKAD, CKS, and LFCS. This page is reviewed against current Red Hat and Linux Foundation owner sources rather than relying on historical exam versions.

Current owner-source baseline: EX200 is based on Red Hat Enterprise Linux 10; CKA, CKAD, and CKS are based on Kubernetes v1.35; LFCS is a two-hour, distribution-agnostic performance exam. Always re-check the linked owner pages before booking because exam versions and policies can change.

What's in this guide

Linux and Kubernetes certifications covered

This page provides structured preparation for six Linux and Kubernetes credentials from Red Hat and the Cloud Native Computing Foundation (CNCF). All are fully performance-based exams: you work in a live terminal environment with no multiple-choice questions. Study material includes practical command references, exam-day task breakdowns, and curated lab environments where you can practise in real clusters and VMs.

Certifications

  • RHCSA (Red Hat Certified System Administrator) — EX200 is a hands-on system-administration exam currently based on Red Hat Enterprise Linux 10. Current objectives include essential tools, software, users and groups, storage, filesystems, running systems, networking, and security.
  • EX294 (Red Hat Certified Advanced System Administrator in Ansible) — Red Hat's current performance-based Ansible administration exam. It covers RHCSA-level administration plus Ansible inventories, configuration, playbooks, variables, facts, roles, content collections, and Vault.
  • CKA (Certified Kubernetes Administrator) — Two-hour, online proctored performance exam currently based on Kubernetes v1.35. The largest current domain is Troubleshooting at 30%.
  • CKAD (Certified Kubernetes Application Developer) — Two-hour, online proctored performance exam currently based on Kubernetes v1.35, focused on designing, building, deploying, configuring, and observing Kubernetes applications.
  • CKS (Certified Kubernetes Security Specialist) — Two-hour, online proctored performance exam currently based on Kubernetes v1.35. Candidates must pass CKA before attempting CKS.
  • LFCS (Linux Foundation Certified System Administrator) — Two-hour, online proctored performance exam. The current LFCS is distribution-agnostic, so candidates no longer select a Linux distribution for the exam.

Study material included

  • Domain study guides — CKA and RHCSA task-level guides covering every exam objective with kubectl command examples, systemd unit syntax, and SELinux context management.
  • Practice scenarios — task-based practice items for CKA and CKAD that mimic the actual exam format: deploy a pod, expose a service, configure a network policy, drain a node.
  • Interactive practice exam — scenario-based mock exam for CKA with per-question scoring and command-level answer explanations.
  • Flashcards and speed rounds — active-recall drills for kubectl commands, YAML resource manifests, Kubernetes object types, and Linux filesystem hierarchy.
  • Curated resources — current Red Hat exam objectives, Linux Foundation curriculum pages and Candidate Handbook links, the included Killer.sh simulations for Linux Foundation exams, Kubernetes documentation, and hands-on lab environments.
EX200 · RHEL 10 · performance-based

RHCSA — Red Hat Certified System Administrator

RHCSA validates core Red Hat Enterprise Linux administration through a hands-on practical exam. Red Hat's current EX200 page states that the exam is based on Red Hat Enterprise Linux 10. RHCSA is also the required foundation for Red Hat Certified Engineer credentials in Enterprise Linux and Ansible.

Exam at a glance

  • Exam code: EX200
  • Format: Hands-on, practical system-administration tasks
  • Current platform: Red Hat Enterprise Linux 10
  • Internet: Not provided during the exam
  • Outside documentation: Notes, books, and other hard-copy or electronic materials are not permitted
  • Product documentation: Red Hat says documentation shipped with the product is available for most exams
  • Preparation: Red Hat recommends RH124 + RH134, RH199, or comparable RHEL administration experience
  • Persistence matters: Required configurations must continue to work after reboot

Exam objectives

Objective 1

Understand & Use Essential Tools

File and directory operations (find, cp, mv, rm, ln), text manipulation (grep, sed, awk, cut, sort), I/O redirection and piping, SSH key-based authentication setup, archive creation and compression (tar, gzip, bzip2), and effective use of man pages to look up options during the exam.

Objective 2

Create Simple Shell Scripts

Write conditionals (if/then/else), loops (for, while, until), process exit codes ($?), use command substitution and variables, and create scripts that complete common system administration tasks. Scripts must be executable and produce correct output without errors.

Objective 3

Operate Running Systems

Boot, reboot, and shut down systems. Interrupt the boot process to gain root access (emergency mode, rescue target). Identify CPU/memory-intensive processes (top, ps), kill signals, tuning profiles with tuned-adm, and setting the system default boot target (multi-user vs graphical).

Objective 4

Configure Local Storage

Partition disks (fdisk, gdisk), create and format filesystems (ext4, xfs), persistent mounts using /etc/fstab (including UUID-based entries), manage swap space, and configure Logical Volume Management (LVM) — create PVs, VGs, LVs, resize LVs, and extend filesystems.

Objective 5

Create & Configure File Systems

Mount and unmount filesystems, configure autofs for NFS automounting, set and report disk usage (du, df), set setuid/setgid/sticky bit permissions, create and use Access Control Lists (getfacl, setfacl), and configure file-system-level quotas for users and groups.

Objective 6

Deploy, Configure & Maintain Systems

Schedule recurring jobs (cron, at), enable and configure network time synchronisation (chronyd), install and update packages with dnf, manage software repositories, configure network interfaces using nmcli and nmtui, and set system locale and time zone.

Objective 7

Manage Basic Networking

Configure static IP addresses, default gateways, and DNS using nmcli. Verify connectivity with ping, traceroute, ss, and netstat. Configure hostname resolution (/etc/hosts, /etc/resolv.conf). Enable and disable network interfaces and configure network bonding and teaming basics.

Objective 8

Manage Users & Groups

Create, modify, and delete local users (useradd, usermod, userdel) and groups. Configure password aging policies (chage). Modify /etc/sudoers for privilege delegation. Configure PAM and login restrictions. Understand the difference between UID 0 root and sudo-based privilege escalation.

Objective 9

Manage Security

Configure firewall rules using firewall-cmd (permanent rules, zones, services, ports). Manage SELinux modes (Enforcing, Permissive, Disabled) using setenforce and /etc/selinux/config. Restore incorrect SELinux file contexts with restorecon. Use ausearch and sealert to diagnose SELinux denials.

Objective 10

Manage Containers

Pull and run container images using Podman (Red Hat's preferred container runtime). Manage container storage and networking, create systemd unit files for rootless container services, and configure containers to start automatically at system boot using Podman and systemd.

Critical RHCSA commands and concepts

Must-know commands

  • systemctl enable|disable|start|stop|status <service> — Service management
  • nmcli con mod <name> ipv4.addresses <ip/cidr> — Set static IP
  • firewall-cmd --add-service=http --permanent && --reload — Open firewall port
  • chcon -t httpd_sys_content_t /path — Set SELinux context
  • restorecon -Rv /path — Restore default SELinux contexts
  • pvcreate / vgcreate / lvcreate / lvextend / resize2fs / xfs_growfs — LVM workflow
  • tar -czf archive.tar.gz /source — Create compressed archive

/etc/fstab entry format

  • UUID=<uuid> /mnt/data xfs defaults 0 0
  • Use blkid to find UUID; always test with mount -a
  • NFS: server:/share /mnt nfs defaults 0 0
  • autofs: requires /etc/auto.master and map files

Password recovery workflow

  • Append rd.break to kernel line in GRUB
  • mount -o remount,rw /sysroot && chroot /sysroot
  • passwd root then touch /.autorelabel
EX294 · Ansible Automation Platform · performance-based

EX294 — Red Hat Certified Advanced System Administrator in Ansible

Red Hat now names EX294 the Red Hat Certified Advanced System Administrator in Ansible exam. It is a hands-on practical exam using Ansible Automation Platform playbooks to configure multiple systems and perform standard administration work. Passing EX294 earns the standalone Advanced System Administrator in Ansible credential and also counts toward Red Hat Certified Engineer in Ansible.

Topic 1

Be an Ansible User

Install and configure Ansible on a control node. Create static and dynamic inventories. Configure ansible.cfg (inventory path, remote user, privilege escalation). Understand and use ad hoc commands (ansible all -m ping, ansible all -m command -a "uptime"). Understand connection types (SSH vs local).

Topic 2

Ansible Playbooks

Write YAML-formatted playbooks with multiple plays and tasks. Use common modules: package, service, copy, template, file, user, group, firewalld, lineinfile, command, shell. Understand task idempotency and when to use creates parameters.

Topic 3

Variables & Facts

Define variables at playbook, inventory, group_vars, and host_vars scope. Use Ansible facts (ansible_hostname, ansible_distribution, ansible_default_ipv4.address). Implement conditionals (when), loops (loop, with_items), and register variables to capture task output.

Topic 4

Ansible Vault & Secret Management

Encrypt sensitive data with ansible-vault encrypt, create, and encrypt_string. Run playbooks with --ask-vault-pass or a vault password file (--vault-password-file). Understand variable precedence and when to keep vault files separate from playbook variables.

Topic 5

Ansible Roles

Create roles using ansible-galaxy init. Understand role directory structure (tasks, handlers, templates, vars, defaults, files, meta). Use roles in playbooks. Download community roles from Ansible Galaxy using ansible-galaxy install and define requirements in requirements.yml.

Topic 6

Jinja2 Templates

Create Jinja2 template files (.j2) for dynamic configuration file generation. Use variables, conditionals ({% if %}), and loops ({% for %}) within templates. Deploy templates using the template module. Understand when to use copy vs template.

Sample Ansible playbook pattern

---
    - name: Configure web servers
      hosts: webservers
      become: true
      vars:
        http_port: 80
      tasks:
        - name: Install httpd
          ansible.builtin.package:
            name: httpd
            state: present
        - name: Deploy index page from template
          ansible.builtin.template:
            src: templates/index.html.j2
            dest: /var/www/html/index.html
        - name: Enable and start httpd
          ansible.builtin.service:
            name: httpd
            state: started
            enabled: true
        - name: Open firewall for http
          ansible.posix.firewalld:
            service: http
            state: enabled
            permanent: true
            immediate: true
2 hours · Kubernetes v1.35 · performance-based

CKA — Certified Kubernetes Administrator

CKA is an online, proctored performance exam completed from a command line running Kubernetes. The Linux Foundation currently lists a two-hour duration and Kubernetes v1.35, with the exam environment moving to recent Kubernetes minor versions on an approximately four-to-eight-week cadence after release.

Exam domains

Domain 1 · 25%

Cluster Architecture, Installation & Configuration

Understand Kubernetes cluster components (kube-apiserver, etcd, kube-scheduler, kube-controller-manager, kubelet, kube-proxy). Install clusters using kubeadm. Manage cluster upgrades (upgrade control plane and worker nodes sequentially using kubeadm upgrade). Configure RBAC: create Roles, ClusterRoles, RoleBindings, and ClusterRoleBindings. Back up and restore etcd using etcdctl snapshot save/restore.

Domain 2 · 15%

Workloads & Scheduling

Create and manage Deployments, ReplicaSets, StatefulSets, and DaemonSets. Configure resource requests and limits on Pods. Use Labels and Selectors for workload targeting. Configure Pod scheduling with nodeSelector, nodeAffinity, taints and tolerations. Manage ConfigMaps and Secrets and inject them into Pods as environment variables or volumes. Scale Deployments manually and with HorizontalPodAutoscaler.

Domain 3 · 20%

Services & Networking

Understand Kubernetes networking model (pod-to-pod, pod-to-service, external). Create ClusterIP, NodePort, and LoadBalancer Services. Configure Ingress resources and Ingress controllers (Nginx Ingress). Implement Network Policies to restrict pod-to-pod traffic. Understand CoreDNS for cluster DNS and debug DNS resolution issues within pods.

Domain 4 · 10%

Storage

Create and use PersistentVolumes (PV) and PersistentVolumeClaims (PVC). Configure StorageClasses and dynamic provisioning. Understand access modes (ReadWriteOnce, ReadOnlyMany, ReadWriteMany) and reclaim policies (Retain, Delete, Recycle). Mount PVCs into Pods via volume definitions and use projected volumes for Secrets and ConfigMaps.

Domain 5 · 30%

Troubleshooting

The highest-weighted domain. Evaluate cluster and node logging. Diagnose application failures by inspecting Pod logs (kubectl logs), events (kubectl describe), and container states. Debug failing nodes (kubelet status, certificate issues, network plugin problems). Monitor cluster component health. Restore broken control plane components. The exam often includes deliberately broken clusters that you must fix.

Essential kubectl commands to memorise

  • kubectl get pods -n <ns> -o wide — List pods with node assignment
  • kubectl describe pod <name> — Events and status detail
  • kubectl logs <pod> -c <container> — Container logs
  • kubectl exec -it <pod> -- bash — Interactive shell in pod
  • kubectl apply -f <file.yaml> — Apply manifest
  • kubectl delete pod <name> --force — Force delete pod
  • kubectl create deployment nginx --image=nginx --replicas=3 — Imperative deployment
  • kubectl expose deployment nginx --port=80 --type=NodePort — Create Service
  • kubectl set image deployment/nginx nginx=nginx:1.21 — Rolling image update
  • kubectl rollout status deployment/nginx — Check rollout progress
  • kubectl rollout undo deployment/nginx — Rollback to previous version
  • kubectl top pods --sort-by=memory — Resource usage
2 hours · Kubernetes v1.35 · performance-based

CKAD — Certified Kubernetes Application Developer

CKAD is an online, proctored performance exam focused on designing, building, deploying, configuring, and observing cloud-native applications on Kubernetes. The Linux Foundation currently lists a two-hour duration and Kubernetes v1.35. There are no prerequisites.

Domain 1 · 20%

Application Design & Build

Define, build, and modify container images using Dockerfiles. Implement init containers for pre-start tasks. Create multi-container Pods (sidecar, ambassador, adapter patterns). Use volumes, ConfigMaps, and Secrets to decouple application configuration from container images.

Domain 2 · 20%

Application Deployment

Manage Deployments, rolling updates, and rollbacks. Implement blue-green and canary deployment strategies using Kubernetes primitives. Use Helm charts for application packaging and deployment. Configure Jobs and CronJobs for batch workloads.

Domain 3 · 15%

Application Observability & Maintenance

Configure liveness, readiness, and startup probes for Pod health monitoring. Implement application debugging techniques: inspect logs, run debug containers, and exec into pods. Monitor application performance and identify issues using pod events and log analysis.

Domain 4 · 25%

Application Environment, Configuration & Security

Create and consume ConfigMaps and Secrets (env vars, volume mounts). Configure ServiceAccounts and RBAC for application identity. Apply SecurityContexts (runAsUser, allowPrivilegeEscalation, readOnlyRootFilesystem, capabilities). Use ResourceQuotas and LimitRanges to constrain namespace resource consumption.

Domain 5 · 20%

Services & Networking

Create and configure Services (ClusterIP, NodePort, LoadBalancer, ExternalName). Configure Ingress resources and path-based routing. Implement NetworkPolicies to control ingress/egress pod traffic. Understand DNS resolution patterns for pod-to-pod and pod-to-service communication within and across namespaces.

2 hours · Kubernetes v1.35 · CKA prerequisite

CKS — Certified Kubernetes Security Specialist

CKS is an online, proctored performance exam covering Kubernetes and cloud-native security across cluster setup, hardening, microservice vulnerabilities, software supply chain security, and runtime monitoring. The Linux Foundation currently lists Kubernetes v1.35 and requires candidates to have passed CKA before attempting CKS.

Domain 1 · 10%

Cluster Setup

Harden Kubernetes cluster components using CIS benchmarks (kube-bench). Configure network security with NetworkPolicies. Use TLS certificates for cluster components and verify API server security settings. Enable and interpret audit logging for suspicious activity detection.

Domain 2 · 15%

Cluster Hardening

Restrict API server access using RBAC — follow least-privilege principle. Use ServiceAccount tokens minimally; disable automounting where not needed. Upgrade Kubernetes to patch known vulnerabilities. Restrict network access using Kubernetes-native NetworkPolicies and external firewalls.

Domain 3 · 15%

System Hardening

Minimise OS footprint — reduce attack surface by limiting installed packages and open ports. Use AppArmor profiles to restrict pod capabilities. Use Seccomp profiles to filter system calls. Restrict kernel capabilities in containers using SecurityContext.

Domain 4 · 20%

Minimise Microservice Vulnerabilities

Implement OPA/Gatekeeper for policy enforcement. Use Pod Security Admission (PSA) with Restricted, Baseline, and Privileged policies. Manage Secrets securely — use etcd encryption at rest, avoid embedding secrets in environment variables unnecessarily. Implement multi-tenancy isolation with namespaces and RBAC.

Domain 5 · 20%

Supply Chain Security

Scan container images for vulnerabilities using Trivy or Anchore. Enforce image signature verification with Cosign. Use only trusted registries and enforce admission controls to reject unsigned or vulnerable images. Validate Kubernetes manifest security with tools like Checkov or kube-score.

Domain 6 · 20%

Monitoring, Logging & Runtime Security

Use Falco to detect and alert on suspicious runtime behaviour (e.g., shell spawned in container, sensitive file reads, network connections from unexpected pods). Analyse and interpret Falco rules. Configure behavioural analytics for container runtime security and respond to real-time security events in a Kubernetes environment.

2 hours · distribution-agnostic · performance-based

LFCS — Linux Foundation Certified System Administrator

LFCS is an online, proctored, command-line performance exam covering practical Linux system administration. The Linux Foundation now describes the exam as independent of distribution-specific tasks, so candidates no longer choose a Linux platform in the exam preparation checklist.

Operations Deployment · 25%

Operations Deployment

Prepare for boot and service operations, scheduling, process and resource management, software lifecycle work, virtualization or container-related administration, and the operational tasks identified in the current LFCS curriculum.

Networking · 25%

Networking

Practice interface and routing configuration, name resolution, service reachability, SSH, firewall concepts, and troubleshooting from the command line. Use distribution-neutral concepts first and verify tool-specific syntax in your lab.

Storage · 20%

Storage

Work with filesystems, mounts, persistent storage, permissions, logical storage concepts, swap, and storage troubleshooting. Practice changes end to end and verify persistence after reboot.

Essential Commands · 20%

Essential Commands

Build speed with shell navigation, file operations, text processing, search, redirection, archives, permissions, process inspection, and command-line documentation.

Users & Groups · 10%

Users & Groups

Create and maintain users and groups, control privileges and file ownership, manage authentication-related configuration, and validate access outcomes from the shell.

Performance-based practice

Practice Scenarios

Performance-based exams require doing, not memorising. These scenarios reflect real exam tasks. Work through each on a live system — time yourself and aim for completion within the given targets.

RHCSA scenarios

Scenario 1 — LVM expansion: A logical volume named /dev/vg_data/lv_web is mounted at /var/www and is formatted ext4. The volume group has 2 GB of free space. Extend the LV by 1.5 GB and ensure the filesystem is resized without unmounting. Verify the new size is visible to the OS.

Solution walkthrough 1. Verify free space: vgdisplay vg_data (check "Free PE")
2. Extend the LV: lvextend -L +1.5G /dev/vg_data/lv_web
3. Resize the filesystem online (ext4): resize2fs /dev/vg_data/lv_web
4. Verify: df -h /var/www — new size should reflect the addition.
Note: For XFS, use xfs_growfs /var/www instead of resize2fs. XFS requires the filesystem to be mounted to grow it.

Scenario 2 — SELinux fix: After moving the Apache DocumentRoot from /var/www/html to /webdata, Apache starts but returns a 403 Forbidden error. The firewall is open, Apache config is correct, and permissions are 755. What is the problem and how do you fix it without disabling SELinux?

Solution walkthrough The problem is an incorrect SELinux file context on /webdata. When files are moved (not created in place), they retain the SELinux context of their original location rather than inheriting httpd_sys_content_t.

1. Verify: ls -Z /webdata — shows non-http context
2. Check denial: ausearch -m avc -ts recent | tail -20
3. Set correct context: semanage fcontext -a -t httpd_sys_content_t "/webdata(/.*)?"
4. Apply: restorecon -Rv /webdata
5. Test: curl localhost — should return the web page

Scenario 3 — Ansible role deployment: Using Ansible, create a role called webserver that installs httpd, deploys a Jinja2 template to /var/www/html/index.html (containing the managed node's hostname and IP), and ensures the service is started and enabled. Deploy this role to all hosts in the [web] inventory group.

Solution walkthrough 1. ansible-galaxy init roles/webserver
2. In roles/webserver/tasks/main.yml: add tasks for package install, template deploy, service start
3. In roles/webserver/templates/index.html.j2: Host: {{ ansible_hostname }} — IP: {{ ansible_default_ipv4.address }}
4. Create site.yml: - hosts: web / roles: [webserver]
5. Run: ansible-playbook -i inventory site.yml — verify with curl <node-ip>

CKA scenarios

Scenario 4 — etcd backup: Context: cluster1. Take a snapshot backup of the etcd database to /opt/etcd-backup.db. The etcd server is running with --data-dir=/var/lib/etcd. TLS certificates are located at /etc/kubernetes/pki/etcd/.

Solution walkthrough ETCDCTL_API=3 etcdctl snapshot save /opt/etcd-backup.db \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key

Verify: etcdctl snapshot status /opt/etcd-backup.db --write-out=table

Scenario 5 — Node troubleshooting: Worker node worker1 is in NotReady state. SSH to the node and diagnose and fix the issue so the node returns to Ready state.

Solution walkthrough 1. kubectl describe node worker1 — read Conditions and Events
2. SSH to worker1: systemctl status kubelet — likely stopped or failed
3. journalctl -u kubelet -n 50 — read error messages
Common fixes: systemctl start kubelet (not running), fix certificate expiry, fix container runtime (containerd/docker not running), fix network plugin. After fix: kubectl get nodes — worker1 should return to Ready within ~60 seconds.
Building hands-on proficiency

Lab Environment Strategy

RHCSA / EX294 lab options

  • Red Hat Developer Subscription: Use Red Hat's developer program to obtain a legitimate RHEL environment for personal development and testing, subject to the current subscription terms.
  • RHEL 10 virtual machines: For current EX200 preparation, practice on RHEL 10 because Red Hat's current exam page identifies RHEL 10 as the exam basis.
  • Other Linux distributions: They remain useful for general command-line practice, but they are not exact substitutes for the RHEL-specific environment and objectives of EX200.
  • Ansible lab: Use multiple disposable RHEL systems for EX294 practice so playbooks can be repeatedly applied to clean targets and verified for the required end state.

CKA / CKAD / CKS lab options

  • Included exam simulator: Linux Foundation currently includes two Killer.sh simulation attempts with CKA, CKAD, CKS, and LFCS enrollment. Use them to become familiar with a timed command-line environment; do not assume simulator question counts match the real exam.
  • Current Kubernetes version: Build practice clusters near the current v1.35 exam baseline and check the owner page before your scheduled date because the exam follows recent Kubernetes minor releases.
  • Local clusters: kubeadm, kind, or other disposable lab environments are useful for repeating administration and application tasks without risking production systems.
  • Owner resources: Review the Linux Foundation Candidate Handbook, curriculum overview, Exam Tips, and FAQ linked from the certification page before exam day.

Exam-day terminal tips

  • Use the included Linux Foundation simulator to become familiar with a timed, browser-delivered command-line environment before exam day.
  • Use Kubernetes documentation heavily during study and verify the current Candidate Handbook and Exam Tips for the exact resource rules that apply on your exam date.
  • Use kubectl explain <resource>.spec to look up field names without opening docs
  • Practise generating safe starter manifests with kubectl create --dry-run=client -o yaml and validating them before applying changes.
  • Set up aliases in the exam terminal: alias k=kubectl and export do="--dry-run=client -o yaml"

Speed-building exercises

  • Practice every RHCSA objective task 5 times from scratch — no notes, timed
  • For CKA: practise each objective category under time pressure, but do not plan around a fixed question count because the owner page describes a set of performance tasks rather than promising a specific live-exam count.
  • Create cheat sheets during study — but practice without them before the exam
  • Simulate exam pressure with a two-hour timed lab and score yourself against clearly defined end states.
Recommended timelines for working professionals

Study Plans

RHCSA — 10-week plan (1.5 hrs/day)

  • Weeks 1–2: Essential tools, file operations, text processing, shell scripting basics
  • Weeks 3–4: User/group management, filesystem permissions, ACLs
  • Weeks 5–6: Storage — partitioning, LVM, filesystems, /etc/fstab, autofs
  • Week 7: Networking — nmcli, static IPs, firewall-cmd
  • Week 8: Security — SELinux (setenforce, semanage, restorecon), SSH hardening
  • Week 9: Services, containers (Podman), system boot & recovery
  • Week 10: Timed full-objective dry runs — use a strict self-imposed time box and verify every task after completion.

CKA — 12-week plan (1.5 hrs/day)

  • Weeks 1–2: Kubernetes architecture, pods, namespaces, deployments, services
  • Weeks 3–4: Scheduling — nodeSelector, affinity, taints, resource limits
  • Weeks 5–6: Networking — NetworkPolicies, Services, Ingress, DNS
  • Week 7: Storage — PVs, PVCs, StorageClasses
  • Weeks 8–9: Cluster administration — RBAC, etcd backup/restore, upgrades
  • Weeks 10–11: Troubleshooting — broken clusters, failing pods, node issues
  • Week 12: Two killer.sh sessions — identify gaps, speed practice

Choose the next credential for the work you actually do

  • RHCSA provides Linux fundamentals essential for Kubernetes node work
  • CKA builds cluster administration skills; CKAD adds developer workflow
  • CKS requires passing CKA first; take it when your work or target role requires deeper Kubernetes security skills.
  • EX294 is a logical Red Hat automation path after RHCSA when Ansible administration is central to your role.

Recommended resources

Study tools · Active recall · LPIC / LFCS / RHCSA

Flashcards & Term-Matching Game

Active recall beats passive reading for long-term retention. Use the flashcards to drill definitions and the matching game to reinforce connections between concepts. Shuffle to mix domains and reset to start fresh. Keyboard navigation supported on flashcards.

Flashcard Deck — Key Terms

Loading flashcards… ensure JavaScript is enabled.

Term-Matching Game

Click a term on the left, then click its matching definition on the right. Correct pairs lock in green; wrong pairs flash red. Complete all pairs to advance to the next round.

Loading matching game… ensure JavaScript is enabled.

Speed Round — True or False

You have 10 seconds per statement. Answer TRUE or FALSE before the timer runs out. Build a combo multiplier for consecutive correct answers and beat your session high score.

Loading speed round… ensure JavaScript is enabled.

Fill in the Blank

Read the clue and type the missing term. One typo is forgiven for longer answers. Use the hint button if you're stuck — but it costs half the question's points.

Loading fill-in-the-blank… ensure JavaScript is enabled.

Domain Sprint — Categorise the Term

A term appears — click the correct exam domain it belongs to. Correct selections score 100 pts; wrong selections deduct 25 pts. Master domain knowledge before exam day.

Loading domain sprint… ensure JavaScript is enabled.

Explore other certification tracks

← All Certifications Cisco Prep → Cloud Certs →
RHCSA EX200 — practice scenarios

Practice Scenarios — RHCSA & Red Hat Ansible

RHCSA is 100% hands-on. These scenarios mirror the task types you will encounter in the exam. Practice each task until you can complete it from memory without referencing documentation — during the real exam you are under time pressure.

Scenario 1 (RHCSA): A server's root password is unknown. You must reset the root password to "RedHat2026" without reinstalling the OS.

  • A) Boot the system normally and use the passwd command
  • B) Interrupt GRUB2 at boot, edit the kernel line to rd.break, mount sysroot, chroot in, and use passwd root
  • C) Boot from a live USB and mount the filesystem
  • D) Use SSH to connect as an admin user and sudo passwd root
Answer: B — Full procedure: 1. At the GRUB2 menu, press e to edit the boot entry. 2. Append rd.break enforcing=0 to the kernel line (the line starting with linux). 3. Press Ctrl+X to boot. 4. At the emergency shell: mount -o remount,rw /sysroot, then chroot /sysroot. 5. Run passwd root and enter the new password. 6. Run touch /.autorelabel to trigger SELinux relabelling on next boot. 7. Exit twice and reboot. This entire procedure is testable on the RHCSA exam.

Scenario 2 (RHCSA): Configure the system to automatically mount the partition /dev/sdb1 to /data at boot using the UUID, formatted as xfs.

  • A) Add the device path to /etc/fstab
  • B) Add the UUID (from blkid) to /etc/fstab with the xfs filesystem type and appropriate options
  • C) Create a systemd mount unit file
  • D) Use the mount command in /etc/rc.local
Answer: B — Full procedure: 1. Format if needed: mkfs.xfs /dev/sdb1. 2. Get UUID: blkid /dev/sdb1. 3. Create mount point: mkdir /data. 4. Edit /etc/fstab and add: UUID=<uuid> /data xfs defaults 0 0. 5. Verify without rebooting: mount -a and check with df -h /data. Using UUID is preferred over device path because device paths can change after reboot (especially in VM environments). The RHCSA exam will test whether the mount persists after a reboot — always verify with mount -a.

Scenario 3 (RHCSA): Create a group called "developers" and a user "devuser" whose primary group is "developers". The user's home directory must be created, and their shell must be /bin/bash.

  • A) useradd devuser -g developers
  • B) groupadd developers && useradd -g developers -m -s /bin/bash devuser
  • C) addgroup developers && adduser devuser developers
  • D) useradd devuser && usermod -G developers devuser
Answer: B — Commands: groupadd developers creates the group. useradd -g developers -m -s /bin/bash devuser creates the user with: -g developers (primary group), -m (create home directory), -s /bin/bash (login shell). Verify with id devuser and grep devuser /etc/passwd. Option D sets developers as a supplementary group, not the primary group. On RHEL, adduser and addgroup (C) are not available — use useradd and groupadd.

Scenario 4 (CKA): A pod named "web-server" in namespace "production" is failing to start because it cannot pull its container image. Diagnose the issue.

  • A) kubectl get pod web-server -n production
  • B) kubectl describe pod web-server -n production and review Events section for ImagePullBackOff or ErrImagePull details
  • C) kubectl logs web-server -n production
  • D) kubectl exec -it web-server -n production -- bash
Answer: B — Diagnosis workflow: kubectl describe pod web-server -n production shows the Events section with the specific error. Common causes: wrong image name or tag (check the image field under Containers), private registry with no imagePullSecret configured, or the registry is unreachable from the cluster. Fix options: correct the image reference in the pod spec, create an image pull secret with kubectl create secret docker-registry and reference it in the pod's imagePullSecrets field. kubectl logs (C) only works if the container has started.

Scenario 5 (CKS): A Kubernetes cluster has pods running as root. You need to enforce that all pods in the "secure" namespace must run as a non-root user using Pod Security Admission.

  • A) Create a NetworkPolicy in the secure namespace
  • B) Add the label pod-security.kubernetes.io/enforce: restricted to the secure namespace
  • C) Create a PodSecurityPolicy (PSP) resource
  • D) Configure a ValidatingWebhookConfiguration
Answer: B — Implementation: Pod Security Admission (PSA) replaced PodSecurityPolicy (deprecated in Kubernetes 1.21, removed in 1.25). Apply the label to the namespace: kubectl label namespace secure pod-security.kubernetes.io/enforce=restricted. The restricted policy requires: runAsNonRoot: true, non-root UID, read-only root filesystem, dropped ALL capabilities, and no privilege escalation. Existing pods violating the policy will continue running but new pods will be rejected. Use warn mode first to identify violations before switching to enforce.
CKAD — Certified Kubernetes Application Developer

Practice Scenarios — CKAD

CKAD focuses on application developer tasks in Kubernetes — designing pods, configuring services, managing state, and observability. The exam is 2 hours, performance-based, in a live cluster. Speed matters: practise kubectl until it is automatic.

Scenario 1 (CKAD): Create a pod named "web" using the nginx:1.25 image with a memory request of 64Mi and a CPU limit of 200m, in the default namespace. Which is the FASTEST way?

  • A) Write a full pod YAML from scratch
  • B) Generate the pod manifest with --dry-run=client -o yaml, redirect to a file, edit the resources block, then apply
  • C) Use kubectl run --image=nginx:1.25 web
  • D) Edit an existing pod's YAML
Answer: B — Full procedure: kubectl run web --image=nginx:1.25 --dry-run=client -o yaml > pod.yaml. Edit pod.yaml to add under spec.containers[0]: resources: { requests: { memory: "64Mi" }, limits: { cpu: "200m" } }. Apply: kubectl apply -f pod.yaml. Verify: kubectl describe pod web | grep -A 4 Limits. The --dry-run=client pattern is the most-used shortcut on CKAD — never write YAML from scratch when kubectl can generate the skeleton.

Scenario 2 (CKAD): An application pod must read a configuration value at startup from a ConfigMap. Which approach makes the config available as an environment variable?

  • A) kubectl create configmap app-config --from-literal=API_URL=https://api.example.com, then reference in pod spec with envFrom.configMapRef.name: app-config (or env.valueFrom.configMapKeyRef for a single key)
  • B) Hardcode the config in the container image
  • C) Pass the config as a command-line argument
  • D) Store the config in a Secret
Answer: A — Implementation: ConfigMaps decouple config from images. Create: kubectl create configmap app-config --from-literal=API_URL=https://api.example.com. Mount as env vars (all keys): envFrom: [{ configMapRef: { name: app-config } }]. Or single key: env: [{ name: API_URL, valueFrom: { configMapKeyRef: { name: app-config, key: API_URL } } }]. Updates to ConfigMaps do NOT automatically restart pods — use a rollout restart or annotation hash. Secrets (D) are for sensitive data, not general config.

Scenario 3 (CKAD): A pod's container fails its liveness probe and gets killed repeatedly, causing CrashLoopBackOff. What should you check first?

  • A) kubectl logs pod-name --previous to see the logs of the last killed container instance
  • B) Delete the pod and re-create it
  • C) Scale up the deployment
  • D) Disable the liveness probe
Answer: A — Diagnosis: kubectl logs pod-name --previous retrieves logs from the previous container instance (the one that was killed) — essential for diagnosing crash loops since current logs are empty if the new container has not started yet. Also useful: kubectl describe pod to see liveness probe failure events. Common causes: probe URL/port wrong, application slow to start (tune initialDelaySeconds), application crashing on startup (check logs), or resource limits too low. Disabling the probe (D) hides the symptom but does not fix the issue.

Scenario 4 (CKAD): An application deployment must perform a rolling update with no more than 25% of pods unavailable and at most 25% extra pods during the rollout. How is this configured?

  • A) Set maxSurge: 50% in the Deployment strategy
  • B) Set Deployment.spec.strategy.type: RollingUpdate, maxUnavailable: 25%, maxSurge: 25%
  • C) Use a StatefulSet instead
  • D) Manually delete and recreate pods one by one
Answer: B — Spec: spec.strategy.type: RollingUpdate with rollingUpdate: { maxUnavailable: 25%, maxSurge: 25% }. These are the defaults. maxUnavailable controls how many pods can be down at once (capacity floor); maxSurge controls how many extra pods can be created during the rollout (capacity ceiling). For a 12-pod deployment with 25%/25%, the rollout will keep at least 9 pods available and create at most 15 pods temporarily. Set both to 0 (one at a time) only when application-tier constraints require it.

Scenario 5 (CKA): A node is marked NotReady. You need to safely drain it for maintenance without disrupting workloads with PodDisruptionBudgets.

  • A) kubectl delete node node-1 immediately
  • B) kubectl cordon node-1 to prevent new scheduling, then kubectl drain node-1 --ignore-daemonsets --delete-emptydir-data and let the drain respect PodDisruptionBudgets
  • C) Restart the node directly
  • D) kubectl drain --force --grace-period=0 node-1
Answer: B — Procedure: 1) kubectl cordon node-1 marks the node unschedulable. 2) kubectl drain node-1 --ignore-daemonsets --delete-emptydir-data evicts pods gracefully (DaemonSet pods are tied to nodes so they are skipped, not evicted). The drain respects PodDisruptionBudgets — if eviction would violate the PDB, drain blocks and reports which PDB. 3) After maintenance: kubectl uncordon node-1. Using --force --grace-period=0 (D) skips graceful termination and ignores PDBs — only use during emergencies.
LFCS — Linux Foundation Certified System Administrator

Practice Questions — LFCS

LFCS is the Linux Foundation's distribution-neutral sysadmin credential. Like RHCSA, it is 100% performance-based (2 hours, live Linux system). Unlike RHCSA, it tests on Ubuntu and CentOS variants — administrators must handle apt and dnf, systemd quirks across distributions, and both nftables and iptables.

1. (LFCS) You need to find all files larger than 100 MB owned by user "alice", modified in the last 7 days, anywhere on the filesystem. Which command does this?

  • A) ls -la / | grep alice | grep 100M
  • B) find / -user alice -size +100M -mtime -7 2>/dev/null
  • C) du -sh /home/alice
  • D) locate alice 100M
Answer: B find is the most powerful sysadmin tool tested on every Linux certification. Breakdown: / = search from root; -user alice = files owned by alice; -size +100M = larger than 100 MB; -mtime -7 = modified less than 7 days ago; 2>/dev/null = suppress permission denied errors. Other useful: -perm (permissions), -name (filename pattern), -exec (run command on each match), -type f|d|l (file, directory, symlink). Memorise these — find appears in every LFCS/RHCSA exam.

2. (LFCS) A systemd service named "myapp" is failing to start. What command provides the MOST detailed diagnostic information?

  • A) systemctl status myapp + journalctl -u myapp -n 50 --no-pager
  • B) ls /etc/systemd/system/
  • C) ps aux | grep myapp
  • D) cat /var/log/messages
Answer: A — Diagnostic workflow: systemctl status myapp shows the recent log entries inline plus the unit's current state, active/inactive, exit code, and main PID. For more lines: journalctl -u myapp -n 50 --no-pager. For live tailing: journalctl -u myapp -f. For boot-specific: journalctl -u myapp -b. To find why a service fails to start, look for "Process exited" lines and the preceding error. journalctl supersedes /var/log/messages on systemd systems — old syslog patterns may not capture systemd unit output.

3. (LFCS) You need to allow SSH from 192.168.1.0/24 only and block all other inbound traffic using firewalld. Which command sequence accomplishes this?

  • A) firewall-cmd --permanent --zone=drop --add-source=0.0.0.0/0, firewall-cmd --permanent --zone=trusted --add-source=192.168.1.0/24, firewall-cmd --permanent --zone=trusted --add-service=ssh, firewall-cmd --reload
  • B) iptables -A INPUT -j DROP
  • C) firewall-cmd --zone=public --add-port=22/tcp
  • D) ufw allow 22
Answer: A — Zone-based firewalld: firewalld uses zones. Strategy: place the source IP range in a zone where SSH is allowed, and default everything else to a restrictive zone. --zone=trusted with --add-source binds the 192.168.1.0/24 subnet to that zone. The drop zone for 0.0.0.0/0 silently drops everything not matched by a more specific zone. Use --permanent to persist; reload to activate. firewalld is the default on RHEL/CentOS/Fedora; ufw (D) is Ubuntu's tool — LFCS tests both.

4. (LFCS) A user is trying to write to /shared/data and gets "Permission denied" even though they are in a group that has write access to the directory. What is the MOST likely cause?

  • A) Their UID changed
  • B) The group membership has not been refreshed in their current session — they need to log out and back in, or run newgrp to pick up the new group
  • C) The filesystem is read-only
  • D) SELinux is in permissive mode
Answer: B Group membership is read at login time. After running usermod -aG groupname user, the user's existing login sessions still hold the old group list. They must log out and back in, or run newgrp groupname in the current shell, or use su - username. Verify with id user (shows all current group memberships) versus groups user (shows configured). This trips up many candidates because they verify with id and see the group, not realising the user's active shell doesn't have it.
Common questions

Linux & Kubernetes Certification FAQ

What versions are these exams using now?

As reviewed on 30 September 2026, Red Hat's EX200 page says RHCSA is based on Red Hat Enterprise Linux 10. Linux Foundation's CKA, CKAD, and CKS pages list Kubernetes v1.35. Those Kubernetes exams are updated toward recent minor releases, so re-check the owner page before your scheduled exam.

Are RHCSA, CKA, CKAD, CKS, and LFCS hands-on exams?

Yes. Red Hat describes EX200 as a hands-on practical exam. Linux Foundation describes CKA, CKAD, CKS, and LFCS as online, proctored, performance-based exams completed from a command line. Use the current owner page and candidate handbook for exact delivery and resource rules.

Do I need CKA before CKS?

Yes. Linux Foundation states that candidates must have taken and passed the Certified Kubernetes Administrator exam before attempting the Certified Kubernetes Security Specialist exam.

Does LFCS still make you choose a Linux distribution?

No. Linux Foundation currently describes LFCS as independent of distribution-specific tasks and says selecting a platform in the exam preparation checklist is no longer required.

Interactive · Timed · Fully explained

Interactive Practice Exam — Certified Kubernetes Administrator (CKA)

CKA is a hands-on performance exam, so this practice test validates the CONCEPTS you will need to apply at the kubectl prompt — control-plane components, scheduling, networking, storage, RBAC, upgrades, and troubleshooting. Pair with killer.sh practice sessions for full hands-on rehearsal.

Loading the interactive practice exam… If it does not load, ensure JavaScript is enabled.

Case study · Apply CKA troubleshooting

Real-World Walkthrough: The 2018 Tesla Kubernetes Dashboard Cryptojack

A short but vivid case for CKA-track candidates: how a single misconfigured Kubernetes dashboard turned into a public cryptomining incident. Every step maps to CKA Domain 1 (Cluster Configuration) and Domain 5 (Troubleshooting).

What happened

  • Tesla ran a Kubernetes cluster on AWS to manage telemetry and engineering data.
  • The Kubernetes Dashboard was exposed to the public internet WITHOUT authentication.
  • RedLock researchers (now part of Palo Alto Networks) discovered the exposed dashboard, which gave them access to a Pod with AWS credentials in environment variables — credentials with read access to S3 buckets containing telemetry data.
  • The same researchers found that attackers had ALREADY discovered the cluster and deployed a cryptominer in a non-default Pod. To evade detection, the miner used non-public Stratum pools and CPU-throttled itself below normal monitoring thresholds.
  • Tesla remediated within hours of disclosure; no customer data was exfiltrated, but the precedent established Kubernetes-as-attack-surface in enterprise security planning.

Map to the CKA curriculum

  • Cluster Architecture, Installation & Configuration: Kubernetes Dashboard should NEVER be exposed; use kubectl proxy + Authentication. Today, kubeadm clusters do not install Dashboard by default.
  • RBAC: The Dashboard service account had cluster-admin in the misconfigured cluster. RBAC least-privilege would have limited blast radius.
  • Services & Networking: NetworkPolicies could have prevented outbound connections from Pods to mining pools (CNI must enforce policy — Calico, Cilium).
  • Troubleshooting: Anomalous Pods with unfamiliar images are red flags. kubectl get pods -A + image audit + Pod Security Admission baseline / restricted profile catch most cryptominers.
  • CKS extension: The Certified Kubernetes Security Specialist (CKS) builds on this — image scanning with Trivy, runtime detection with Falco, admission control with OPA Gatekeeper / Kyverno.
  • Secrets management: AWS credentials should never be in env vars; use IRSA (EKS) or workload identity (GKE) so credentials never leave the cluster.
Free & reputable only · Verified links

Helpful Materials — RHCSA / CKA / Linux Foundation

All resources below are free or free-tier. The most effective preparation for performance-based Linux and Kubernetes exams is browser-in-browser practice environments — use them daily rather than videos alone.

Kubernetes — official free resources

Free interactive Kubernetes labs

Free Linux learning

RHCSA / Red Hat Ansible — official resources

Linux Foundation owner sources

Free CNCF training

Communities

Quick reference · Speed matters in CKA

kubectl Cheatsheet for CKA

The exam is bandwidth-limited by your kubectl speed. Memorise these patterns and the --dry-run=client -o yaml trick for fast manifest scaffolding.

Speed aliases (set at exam start)

  • alias k=kubectl
  • export do='--dry-run=client -o yaml'
  • export now='--force --grace-period=0'
  • Source completion: source <(kubectl completion bash) then complete -F __start_kubectl k

Manifest scaffolding

  • k run nginx --image=nginx $do > pod.yaml
  • k create deploy web --image=nginx --replicas=3 $do > dep.yaml
  • k create svc clusterip web --tcp=80:8080 $do
  • k create cm app-cfg --from-literal=KEY=val $do
  • k create secret generic db --from-literal=password=secret $do

Troubleshooting commands

  • k describe pod <p> — events at bottom
  • k logs <p> --previous -c <c>
  • k get events --sort-by=.lastTimestamp -A
  • k top pods --sort-by=memory -A
  • k exec -it <p> -- sh
  • k debug node/<n> --image=busybox -it

Cluster admin essentials

  • kubeadm token create --print-join-command
  • kubeadm upgrade plan / upgrade apply
  • k drain <node> --ignore-daemonsets --delete-emptydir-data
  • k uncordon <node>
  • k taint nodes <n> key=val:NoSchedule

etcd backup & restore

  • ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
  • --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  • --cert=/etc/kubernetes/pki/etcd/server.crt \
  • --key=/etc/kubernetes/pki/etcd/server.key \
  • snapshot save /opt/backup.db
  • Restore: etcdctl snapshot restore /opt/backup.db --data-dir=/var/lib/etcd-new

Resource short names

  • po (pods), deploy (deployments), svc (services), ns (namespaces)
  • rs (replicasets), sts (statefulsets), ds (daemonsets), ing (ingress)
  • cm (configmaps), pv (persistentvolumes), pvc (persistentvolumeclaims)
  • sa (serviceaccounts), netpol (networkpolicies), pdb (poddisruptionbudgets)