← All Certifications Red Hat & Linux Foundation

Linux & Kubernetes Certification Prep

Domain guides, hands-on lab strategies, and practice scenarios for Red Hat and Linux Foundation certifications — RHCSA, RHCE, CKA, CKAD, CKS, and LFCS. All are performance-based exams: you must demonstrate skills in a live environment, not answer multiple choice.

EX200 · 3 hours · performance-based

RHCSA — Red Hat Certified System Administrator

The entry-level Red Hat certification and the prerequisite for all higher Red Hat credentials. RHCSA is a 3-hour fully hands-on exam conducted on a live RHEL system — no multiple choice. You must complete real system administration tasks within the time limit. Passing score is 210 out of 300 points. There are no prerequisites, but candidates with no Linux experience typically need 2–3 months of daily practice.

Exam at a glance

  • Exam code: EX200
  • Format: Hands-on live system — no multiple choice
  • Duration: 3 hours
  • Passing score: 210/300 points
  • RHEL version: RHEL 9 (current exam version)
  • Prerequisites: None (but real Linux experience required)
  • Key theme: You must accomplish tasks without step-by-step instructions
  • Allowed resources: Local man pages and system documentation only (no internet)
  • Grading: Automated — completed tasks are verified post-exam
  • Reattempt policy: Wait 14 days before retaking

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 · 4 hours · Ansible-based

RHCE — Red Hat Certified Engineer

The professional-level Red Hat credential, focused entirely on Red Hat Ansible Automation. RHCE (EX294) requires an active RHCSA certification. The exam is a 4-hour hands-on test where you use Ansible to automate system administration tasks across a multi-node environment — configuring managed nodes, writing playbooks, managing variables and inventories, and deploying Ansible roles. There is no multiple choice.

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 · performance-based · browser terminal

CKA — Certified Kubernetes Administrator

The Linux Foundation's hands-on Kubernetes administration certification. CKA is a 2-hour proctored exam conducted in a live Kubernetes cluster via a browser-based terminal. You must complete task-based scenarios (15–20 tasks) across multiple clusters. No multiple choice — everything is verified by checking actual cluster state. The exam requires kubectl proficiency: candidates who rely on documentation lookup for basic commands will run out of time.

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 · performance-based

CKAD — Certified Kubernetes Application Developer

The developer-focused counterpart to CKA. CKAD validates the ability to design, build, and deploy cloud-native applications on Kubernetes. The focus is on application workloads — not cluster administration. CKAD is faster-paced than CKA, with simpler individual tasks but more of them. Requires speed and fluency with kubectl imperative commands to complete in time.

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 · requires CKA · performance-based

CKS — Certified Kubernetes Security Specialist

The advanced Kubernetes security certification, requiring an active CKA credential. CKS is widely considered the most difficult Kubernetes exam. It focuses on securing cluster infrastructure and cloud-native workloads — supply chain security, runtime security, network policies, and OPA/Gatekeeper policy enforcement. Ideal for DevSecOps engineers and platform security specialists.

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 · Linux Foundation · performance-based

LFCS — Linux Foundation Certified System Administrator

The Linux Foundation's vendor-neutral Linux system administration certification. Unlike RHCSA (which tests RHEL-specific tools), LFCS covers general Linux system administration skills applicable across distributions. The exam is conducted on Ubuntu or CentOS/Rocky Linux (candidate's choice) via a browser-based terminal.

Domain 1 · 20%

Essential Commands

File operations, text processing tools (grep, sed, awk, cut, sort, uniq, wc), I/O redirection, searching with find and locate, archive and compression, and process management (ps, kill, nice, nohup). Demonstrate ability to work effectively at the command line without GUI tools.

Domain 2 · 25%

Operation of Running Systems

systemd unit management, target configuration (multi-user, graphical, emergency), system boot process, process monitoring and management, schedule tasks with cron and at, and manage system logging (journalctl, rsyslog). Includes system performance monitoring (sar, vmstat, iostat).

Domain 3 · 20%

User and Group Management

Create, modify, and delete users and groups using standard utilities. Configure sudo access, manage password policies, understand PAM (Pluggable Authentication Modules), and implement file ownership and permissions including ACLs and special permission bits.

Domain 4 · 20%

Networking

Configure network interfaces using NetworkManager and ip commands. Set up routing, DNS client configuration, and SSH server hardening. Configure basic firewall rules (ufw on Ubuntu, firewalld on RHEL-based). Diagnose connectivity issues using ip, ss, ping, traceroute, and nmap.

Domain 5 · 15%

Service Configuration

Configure and troubleshoot common services: Apache/Nginx web servers, NFS and Samba file sharing, MariaDB/MySQL basics, SSH key-based authentication configuration, and basic certificate management with OpenSSL for self-signed certificates.

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 / RHCE lab options

  • Red Hat Developer Subscription (free): Provides 16 RHEL instances for personal use. Register at developers.redhat.com. The official and most accurate exam environment.
  • RHEL in VirtualBox or VMware: Run RHEL 9 locally on your machine. Minimum 2 vCPUs and 2 GB RAM per VM. Set up a 2-VM lab (control + managed node) for RHCE Ansible practice.
  • CentOS Stream 9 / Rocky Linux 9: Free RHEL-compatible alternatives. Exam objectives are largely identical. Acceptable substitutes when cost is a barrier.
  • KodeKloud RHCSA labs: Browser-based guided labs aligned to RHCSA objectives. Excellent for targeted practice without local VM setup.

CKA / CKAD / CKS lab options

  • killer.sh: Included free with every CKA/CKAD/CKS exam purchase (2 sessions). The most accurate simulator — harder than the real exam. Complete both sessions. The UI, cluster layout, and task format are identical to the actual exam.
  • KodeKloud CKA course labs: Hands-on labs after each section. Excellent for learning and reinforcement before using killer.sh.
  • kubeadm local cluster: Set up a multi-node cluster on VMs or using kind (Kubernetes in Docker) / k3s for lightweight local practice.
  • Killer Shell practice exams: Additional timed exam sessions at killer.sh — worth purchasing additional sessions for CKS in particular.

Exam-day terminal tips

  • The exam uses a browser-based terminal — practice in the same environment on killer.sh before exam day
  • Bookmark the Kubernetes docs (kubernetes.io/docs) and memorise the search paths to find YAML examples quickly
  • Use kubectl explain <resource>.spec to look up field names without opening docs
  • Copy YAML from docs — never type from memory in the exam. Use kubectl create --dry-run=client -o yaml to generate base YAML
  • 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: complete each objective category in < 5 minutes on average (15 tasks in 2 hours = 8 min/task)
  • Create cheat sheets during study — but practice without them before the exam
  • Simulate exam pressure: set a 2-hour timer, do 15 tasks, score yourself
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 — complete all objectives in 3 hours

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

Recommended path: RHCSA → CKA → CKAD or RHCE

  • RHCSA provides Linux fundamentals essential for Kubernetes node work
  • CKA builds cluster administration skills; CKAD adds developer workflow
  • CKS requires CKA first — take after 6+ months of Kubernetes experience
  • RHCE (Ansible) is ideal after RHCSA for automation-focused engineering roles

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 & RHCE

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

Is RHCSA harder than CKA?

Both are fully performance-based exams with no multiple choice. RHCSA (3 hours on RHEL 9) tests system administration tasks like storage management, user administration, SELinux, and service configuration. CKA (2 hours in a live Kubernetes cluster) tests cluster administration. Most candidates find CKA more time-pressured because Kubernetes tasks require more orchestration. RHCSA tests deeper Linux fundamentals but is more predictable with structured preparation.

Can you use documentation during CKA and CKAD?

Yes. During CKA, CKAD, and CKS exams you are allowed one additional browser tab open to kubernetes.io/docs and kubernetes.io/blog. You cannot access any other websites. Learn to navigate the Kubernetes documentation quickly — especially the kubectl cheat sheet, API reference, and relevant concept pages. Speed matters: you typically have 15–20 tasks in 2 hours.

What order should I take Kubernetes certifications in?

The recommended sequence is CKAD → CKA → CKS. CKAD is the developer exam and easiest entry point for Kubernetes fluency. CKA builds cluster administration skills. CKS (security) is the hardest and requires a currently active CKA certification as a prerequisite. The killer.sh practice environment (2 full simulations included with each exam registration) is the single most important preparation resource.

How do I set up a lab environment for RHCSA?

The most cost-effective approach: install RHEL 9 as a virtual machine using VirtualBox or KVM (Red Hat offers a free developer subscription at developers.redhat.com that includes RHEL). Set up 2–3 VMs to practice multi-machine tasks. Alternatively, use the free Red Hat Learning subscription tier which includes interactive labs. Practise every exam objective multiple times from scratch — muscle memory is what gets you through a 3-hour performance exam.

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

  • Domain 1 — Cluster Configuration: Kubernetes Dashboard should NEVER be exposed; use kubectl proxy + Authentication. Today, kubeadm clusters do not install Dashboard by default.
  • Domain 1 — RBAC: The Dashboard service account had cluster-admin in the misconfigured cluster. RBAC least-privilege would have limited blast radius.
  • Domain 3 — Networking: NetworkPolicies could have prevented outbound connections from Pods to mining pools (CNI must enforce policy — Calico, Cilium).
  • Domain 5 — 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 / RHCE — free resources

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)