# Complete Kubernetes (CKA / CKAD), Docker, Linux (LPIC-1 / RHCSA) & Git CI/CD DevOps Study Guide

> Hands-on DevOps and Cloud Native engineering curriculum covering Linux System Administration (LPIC-1 / RHCSA), Docker containerization, Kubernetes architecture, workloads, networking and RBAC (CKA / CKAD), Git/GitHub Actions CI/CD, ArgoCD GitOps, and Prometheus/Grafana SRE observability

- **Canonical URL:** https://flashcards.world/guides/en/pillar-kubernetes-cka-ckad-docker-linux-rhcsa-git-cicd-study-guide/
- **Markdown URL:** https://flashcards.world/guides/en/pillar-kubernetes-cka-ckad-docker-linux-rhcsa-git-cicd-study-guide.md
- **Topic / Curriculum:** Kubernetes (CKA / CKAD), Docker Containers, Linux (LPIC-1 / RHCSA) & Git CI/CD
- **Language:** en

# Complete Kubernetes (CKA / CKAD), Docker, Linux (LPIC-1 / RHCSA) & Git CI/CD DevOps Study Guide

> **Comprehensive Active-Recall Curriculum**: Hands-on DevOps and Cloud Native engineering curriculum covering Linux System Administration (LPIC-1 / RHCSA), Docker containerization, Kubernetes architecture, workloads, networking and RBAC (CKA / CKAD), Git/GitHub Actions CI/CD, ArgoCD GitOps, and Prometheus/Grafana SRE observability. Practice **6 progressive flashcard decks (192 cards total)** spanning foundational principles (`basic`), intermediate problem-solving (`intermediate`), and advanced exam mastery (`advanced`).

👉 **[Explore All Kubernetes (CKA / CKAD), Docker Containers, Linux (LPIC-1 / RHCSA) & Git CI/CD Flashcard Decks on Flashcards.World →](https://flashcards.world/flashcards/?q=Kubernetes%20%28CKA%20/%20CKAD%29%2C%20Docker%20Containers%2C%20Linux%20%28LPIC-1%20/%20RHCSA%29%20%26%20Git%20CI/CD&back_lng=en)**

---

## Why Active Recall & Spaced Repetition Work for This Exam

Mastering **Kubernetes (CKA / CKAD), Docker Containers, Linux (LPIC-1 / RHCSA) & Git CI/CD** requires retrieving precise definitions, formulas, diagnostic rules, and edge-case distinctions under timed pressure. Passive re-reading creates an illusion of competence; **active recall** (testing yourself before viewing the answer) and **spaced repetition** strengthen long-term synaptic retrieval pathways.

| Study Phase | Decks Covered | Target Mastery Level | Daily Active-Recall Protocol |
| :--- | :--- | :--- | :--- |
| **Phase 1: Foundations (Weeks 1–2)** | Decks 1 & 2 (`Basic`) | 90%+ Instant Recall | 32 new cards/day + full review of missed concepts |
| **Phase 2: Application (Weeks 3–5)** | Decks 3 & 4 (`Intermediate`) | Multi-step synthesis | 32 new cards/day + interleaved Phase 1 review |
| **Phase 3: Exam Mastery (Weeks 6–8)** | Decks 5 & 6 (`Advanced`) | Timed exam readiness | Full 192-card spaced-repetition rotation + weak-spot drills |

---

## Deck 1: Linux Administration (Filesystem, Permissions, systemd, LVM, Networking & Shell) (32 Cards — Basic)

**What this deck covers**: Core Linux systems engineering mastery for RHCSA, LPIC-1, and CKA prerequisites covering the Filesystem Hierarchy Standard (FHS), inodes and links, permissions and special bits (SUID/SGID/Sticky), ACLs, SELinux/AppArmor, systemd and journalctl, LVM storage, process signals, Linux networking, and Bash shell piping.

| High-Yield Prompt / Question | Verified Answer & Exam Application |
| :--- | :--- |
| **What are the roles of `/etc`, `/var`, `/proc`, `/sys`, `/boot`, and `/usr` in the Linux Filesystem Hierarchy Standard (FHS)?** | `/etc`: Host-specific system-wide configuration files. `/var`: Variable data files that change continuously during normal operation (logs in `/var/log`, spools, databases, container layers). `/proc`: Virtual pseudo-filesystem in RAM exposing kernel and process runtime state (`/proc/<PID>`, `/proc/cpuinfo`, `/proc/sys`). `/sys`: Virtual sysfs filesystem exposing kernel device/driver topology and cgroups. `/boot`: Kernel (`vmlinuz`), `initramfs`, and GRUB bootloader. `/usr`: Read-only userland binaries, libraries, and documentation. |
| **What information is stored inside a Linux filesystem Inode, and what is NOT stored inside the Inode?** | Stored in the Inode: File metadata including file type, POSIX permissions (`mode`), Owner UID, Group GID, file size in bytes, link count, timestamps (`atime`, `mtime`, `ctime`, `crtime`), and pointers to the data blocks on disk. NOT stored in the Inode: The filename itself! Filenames are stored in directory entries (`dentries`) which map human-readable filenames to Inode numbers. |
| **Why can a Linux filesystem fail with `No space left on device` when `df -h` shows plenty of free gigabytes?** | The filesystem has exhausted its Inode table (100% `IUse%`), typically caused by millions of tiny or zero-byte files (e.g., uncleaned session files, mail queues, or cache files). Verify with `df -i` and locate the directory containing the highest file count to delete unnecessary files. |
| **Compare Hard Links (`ln source link`) and Symbolic/Soft Links (`ln -s target link`) in Linux.** | Hard Link: Points directly to the exact same Inode number and disk data blocks as the original file; increments the inode's link count; cannot cross filesystem/partition boundaries; cannot link directories; data persists until the last hard link is deleted (and no process holds an open file descriptor). Symbolic (Soft) Link: Creates a new inode with file type `l` storing the text path string to the target; can cross filesystems and link directories; becomes a broken ('dangling') link if the target is moved or deleted. |
| **How do the `r` (4), `w` (2), and `x` (1) permission bits behave differently on a Linux Directory compared to a Regular File?** | On a Regular File: `r` allows reading file contents; `w` allows modifying file contents; `x` allows executing the file as a program. On a Directory: `r` allows listing the filenames inside the directory (`ls`); `w` allows creating, renaming, or deleting files inside the directory (even if you don't own the file, unless Sticky bit is set!) ONLY IF `x` is also set; `x` (traverse/search bit) allows `cd`-ing into the directory and accessing known files/inodes inside it. |
| **Explain the three Linux special permission bits: SUID (`4000`), SGID (`2000`), and Sticky Bit (`1000`).** | SUID (`4000`, `u+s`, shown as `s` in owner execute): When set on an executable binary (like `/usr/bin/passwd`), the process runs with the Effective UID of the file OWNER (e.g., `root`) rather than the user who ran it. SGID (`2000`, `g+s`): On an executable, runs with the file's Group GID; on a DIRECTORY, any new files/subdirectories created inside automatically inherit the directory's Group GID instead of the creator's primary group. Sticky Bit (`1000`, `o+t`, shown as `t` on `/tmp`): On a shared writable directory, prevents users from deleting or renaming files owned by other users. |
| **What does an uppercase `S` or `T` (instead of lowercase `s` or `t`) mean in the output of `ls -l`?** | It indicates that the special bit (SUID/SGID `S` or Sticky Bit `T`) is set, but the underlying standard execute bit (`x`) for that category is NOT set (e.g., `chmod 1666 dir` produces `drw-rw-rwT`, whereas `chmod 1777 dir` produces `drwxrwxrwt`). |
| **How does `umask` work in Linux, and what default permissions result from `umask 0022` vs. `umask 0027`?** | The `umask` (user file-creation mode mask) clears permission bits from the system base creation modes: `0666` for new regular files (Linux never grants execute by default on new files) and `0777` for new directories (calculated via bitwise `BASE & ~UMASK`). With `umask 0022`, new files get `0644` (`rw-r--r--`) and directories get `0755` (`rwxr-xr-x`). With `umask 0027`, new files get `0640` (`rw-r-----`) and directories get `0750` (`rwxr-x---`). |
| **How do you view and configure POSIX Access Control Lists (ACLs) on Linux files and directories using `getfacl` and `setfacl`?** | `getfacl <path>` displays standard and extended ACL entries (indicated by a `+` at the end of `ls -l` permissions). `setfacl -m u:alice:rw file.txt` grants user `alice` read/write access; `setfacl -m d:g:devs:rwx /shared` sets a Default ACL on a directory so all future files created inside inherit that ACL; `setfacl -x u:alice file.txt` removes a specific entry; `setfacl -b file.txt` strips all extended ACL entries. |
| **Compare the three SELinux operational modes (`Enforcing`, `Permissive`, `Disabled`) and the commands to inspect or switch them.** | `Enforcing`: SELinux Mandatory Access Control (MAC) policy is enforced and unauthorized actions are blocked and logged as `AVC denied` in `/var/log/audit/audit.log`. `Permissive`: SELinux does not block access, but logs all policy violations that would have been denied (ideal for troubleshooting). `Disabled`: SELinux is completely off (switching from Disabled to Enforcing requires a full filesystem relabel via `/.autorelabel` on reboot). Use `getenforce`/`sestatus` to check, `setenforce 0\|1` to toggle runtime mode, and `/etc/selinux/config` for persistent boot config. |
| **Why should you use `semanage fcontext` + `restorecon` instead of `chcon` when fixing SELinux file contexts (e.g., for a custom Apache/NGINX web root)?** | `chcon -t httpd_sys_content_t /web` changes the SELinux type label directly on the file's extended attributes, but does NOT update the system SELinux policy database—meaning a future `restorecon` or filesystem relabel will wipe out your change! Instead, run `semanage fcontext -a -t httpd_sys_content_t '/web(/.*)?'` to register the rule in the policy database, then run `restorecon -Rv /web` to apply the default policy labels. |
| **Where are `systemd` unit files located in order of precedence, and what command must you run after editing a unit file?** | From highest to lowest precedence: 1. `/etc/systemd/system/` (local administrator overrides and custom units); 2. `/run/systemd/system/` (runtime transient units); 3. `/usr/lib/systemd/system/` or `/lib/systemd/system/` (vendor/package default units—never edit directly; use `systemctl edit <unit>` to create a drop-in override in `/etc/systemd/system/<unit>.d/override.conf`). Always run `systemctl daemon-reload` after modifying unit files. |

👉 **[Practice Deck 1: Linux Administration (Filesystem, Permissions, systemd, LVM, Networking & Shell) (32 Flashcards) →](https://flashcards.world/flashcards/sets/c3de089c-4490-4419-adb6-69f7b655f6b0/)**  
🔍 **[Browse All Basic Kubernetes (CKA / CKAD), Docker Containers, Linux (LPIC-1 / RHCSA) & Git CI/CD Sets →](https://flashcards.world/flashcards/?q=Kubernetes%20%28CKA%20/%20CKAD%29%2C%20Docker%20Containers%2C%20Linux%20%28LPIC-1%20/%20RHCSA%29%20%26%20Git%20CI/CD&back_lng=en&expertise_level=basic)**

---

## Deck 2: Docker Containers (Dockerfile, Multi-stage Builds, Volumes, Networks & Security) (32 Cards — Basic)

**What this deck covers**: Deep-dive Docker and OCI containerization mastery covering Linux kernel namespaces and cgroups, OverlayFS layers, Dockerfile instructions (CMD vs ENTRYPOINT, COPY vs ADD, ARG vs ENV), multi-stage builds, storage (Volumes vs Bind Mounts), container networking, and container security hardening.

| High-Yield Prompt / Question | Verified Answer & Exam Application |
| :--- | :--- |
| **How do Containers differ architecturally from Virtual Machines (VMs), and what two Linux kernel features make containers possible?** | Virtual Machines run a full Guest Operating System and kernel on top of virtualized hardware managed by a Hypervisor (KVM, Hyper-V, ESXi), incurring higher boot time and memory overhead. Containers share the Host OS Linux Kernel directly and isolate processes using two core kernel features: 1. Namespaces (which isolate what a process can SEE), and 2. Control Groups / `cgroups` (which limit how much hardware resources—CPU, RAM, Block I/O, PIDs—a process can USE). |
| **List and explain the seven Linux Kernel Namespaces used by container runtimes (`runc` / `containerd`).** | 1. `pid`: Isolates the Process ID number space (the container's entrypoint becomes `PID 1` inside the container); 2. `net`: Isolates network interfaces, loopback, routing tables, and `iptables`/ports; 3. `mnt`: Isolates filesystem mount points (`chroot`/`pivot_root`); 4. `uts`: Isolates hostname and NIS domain name; 5. `ipc`: Isolates System V IPC and POSIX message queues; 6. `user`: Maps root (`UID 0`) inside the container to an unprivileged non-root UID on the host; 7. `cgroup`: Isolates the view of the cgroup hierarchy. |
| **How does Docker's OverlayFS (`overlay2`) storage driver work with `lowerdir`, `upperdir`, `merged`, and Copy-on-Write (CoW)?** | Container images consist of immutable, read-only layers stacked as `lowerdir` (shared across all containers running the same image). When a container starts, Docker adds a thin writable container layer on top called `upperdir`, and presents the unified view at `merged`. Under Copy-on-Write (CoW), if a container modifies an existing file from a read-only image layer, `overlay2` copies that file up into `upperdir` and modifies the copy, leaving the underlying image layer untouched. |
| **Compare `CMD` and `ENTRYPOINT` in a `Dockerfile`, and explain how they interact when both are specified.** | `ENTRYPOINT` configures the container to run as a specific executable binary; `CMD` provides default arguments (or a default command if `ENTRYPOINT` is not set). When ANY trailing arguments are passed to `docker run <image> <args>`, they OVERRIDE `CMD`, whereas `ENTRYPOINT` is NOT overridden unless `--entrypoint` is explicitly passed. Best practice: combine Exec-form `ENTRYPOINT ["nginx"]` with `CMD ["-g", "daemon off;"]` so `CMD` acts as default flags passed into `ENTRYPOINT`. |
| **What is the critical difference between Exec Form (`["executable", "param1"]`) and Shell Form (`executable param1`) in `CMD` and `ENTRYPOINT`?** | Shell Form (`CMD node server.js`) wraps the command in `/bin/sh -c`, making `/bin/sh` run as `PID 1` inside the container instead of your application! Because `/bin/sh` does not forward POSIX signals like `SIGTERM` (sent by `docker stop` or Kubernetes pod termination) to child processes, your app never receives `SIGTERM`, hangs for the 10s/30s grace period, and gets killed violently with `SIGKILL` (`137`). Exec Form (`CMD ["node", "server.js"]`) runs your app directly as `PID 1` so it receives `SIGTERM` cleanly. |
| **Why do processes running as `PID 1` inside a container need special signal and zombie-reaping handling (e.g., `docker run --init` or `tini`)?** | In Linux, `PID 1` has two unique kernel responsibilities: 1. The kernel ignores default signal handlers (like `SIGTERM`) on `PID 1` unless the process explicitly registers a signal handler in code; 2. If any child process inside the container becomes orphaned, it is re-parented to container `PID 1`—if `PID 1` (e.g., Java, Node, Python, or bash script) does not call `wait()` to reap dead children, zombie processes accumulate. Passing `--init` (or using `tini` as `ENTRYPOINT`) runs a tiny init wrapper as `PID 1` that forwards signals and reaps zombies. |
| **Compare `COPY` and `ADD` instructions in a `Dockerfile` and state which is preferred.** | `COPY` strictly copies local files and directories from the build context into the container image—it is explicit, predictable, and ALWAYS PREFERRED by Docker best practices. `ADD` has two extra magic behaviors: 1. It automatically extracts local compressed tar archives (`.tar.gz`, `.tar.bz2`, `.tar.xz`) into the destination directory; 2. It can fetch remote URLs (though `curl`/`wget` + `rm` in a `RUN` layer is often preferred or `ADD --checksum` in BuildKit). |
| **Compare `ARG` and `ENV` instructions in a `Dockerfile`, and explain why `ARG` must NEVER be used for secrets.** | `ARG` defines build-time variables (passed via `docker build --build-arg VAR=val`) that are available ONLY during `docker build` and do NOT persist in the running container environment. `ENV` defines environment variables that exist both during build AND persist inside running containers (overridable via `docker run -e`). WARNING: `ARG` values are baked in plain text into the image's layer history (`docker history <image>`), so passing secrets via `ARG` leaks them! Use BuildKit secret mounts (`RUN --mount=type=secret,id=mysecret`) instead. |
| **What is a Multi-Stage Build in Docker and why is it essential for production images?** | A Multi-Stage `Dockerfile` uses multiple `FROM` statements (e.g., `FROM golang:1.22 AS builder` followed by `FROM gcr.io/distroless/static-debian12`). You compile source code, install SDKs/compilers (`gcc`, `maven`, `npm`), and run tests in the heavy builder stage, then use `COPY --from=builder /app/bin /app/bin` to copy ONLY the compiled artifact into a minimal final runtime image—slashing image size by 80–98% and eliminating compilers, shells, and CVEs from production. |
| **How does Docker Layer Caching work during `docker build`, and how should you order instructions in a `Dockerfile` to maximize cache hits?** | Docker caches each instruction layer sequentially; as soon as ONE layer's cache is invalidated (e.g., a file in `COPY` changed), ALL subsequent layers in the `Dockerfile` must be rebuilt from scratch. Therefore, order instructions from LEAST frequently changing at the top to MOST frequently changing at the bottom: 1. Base OS packages (`RUN apt-get...`); 2. Copy ONLY dependency manifests (`COPY package.json package-lock.json ./`); 3. Install dependencies (`RUN npm ci`); 4. Copy application source code (`COPY . .`) last. |
| **Why should `apt-get update` and `apt-get install` ALWAYS be combined into a single `RUN` instruction alongside cache cleanup?** | 1. Cache Busting Bug: If `RUN apt-get update` is on its own line, Docker will cache that layer for weeks; later when you add a package to a separate `RUN apt-get install` line, Docker reuses the stale cached package index and fails with `404 Not Found`. 2. Layer Bloat: Deleting `/var/lib/apt/lists/*` in a LATER `RUN` layer does not reduce image size because the files are already committed to the previous immutable layer! Always combine: `RUN apt-get update && apt-get install -y --no-install-recommends curl && rm -rf /var/lib/apt/lists/*`. |
| **What is the Docker Build Context and what role does `.dockerignore` play?** | When you run `docker build .`, the Docker CLI archives and sends the directory contents (the 'Build Context') to the Docker daemon/BuildKit builder. Without a `.dockerignore` file, massive folders like `.git/`, `node_modules/`, `venv/`, build artifacts, and sensitive `.env` or `.aws` files are uploaded to the builder and can accidentally be baked into the image via `COPY . .`, causing slow builds, broken layer caches, and credential leaks. |

👉 **[Practice Deck 2: Docker Containers (Dockerfile, Multi-stage Builds, Volumes, Networks & Security) (32 Flashcards) →](https://flashcards.world/flashcards/sets/0ccde664-3c18-4dbd-a8d5-1435453addca/)**  
🔍 **[Browse All Basic Kubernetes (CKA / CKAD), Docker Containers, Linux (LPIC-1 / RHCSA) & Git CI/CD Sets →](https://flashcards.world/flashcards/?q=Kubernetes%20%28CKA%20/%20CKAD%29%2C%20Docker%20Containers%2C%20Linux%20%28LPIC-1%20/%20RHCSA%29%20%26%20Git%20CI/CD&back_lng=en&expertise_level=basic)**

---

## Deck 3: Kubernetes Architecture, Pods, Deployments, Services & Ingress (CKA/CKAD) (32 Cards — Intermediate)

**What this deck covers**: Certified Kubernetes Administrator (CKA) and Application Developer (CKAD) core mastery covering Control Plane and Worker Node components, etcd Raft consensus and backup/restore, multi-container Pod patterns, Liveness/Readiness/Startup Probes, Workload controllers (Deployments, DaemonSets, StatefulSets, Jobs), Services, Ingress/Gateway API, and NetworkPolicies.

| High-Yield Prompt / Question | Verified Answer & Exam Application |
| :--- | :--- |
| **What are the four core Control Plane components of a Kubernetes cluster and their responsibilities?** | 1. `kube-apiserver`: The sole frontend REST gateway to the cluster; handles authentication, authorization (RBAC), admission control, schema validation, and is the ONLY component that talks directly to `etcd`. 2. `etcd`: Distributed, consistent key-value store persisting all cluster state. 3. `kube-scheduler`: Watches for newly created Pods with no `nodeName` and selects an optimal node via Filtering and Scoring phases. 4. `kube-controller-manager`: Runs reconciliation control loops (Node, Replication, Endpoints/EndpointSlice, ServiceAccount controllers). |
| **What are the three core Worker Node components in Kubernetes and how do they interact?** | 1. `kubelet`: Node agent that watches the `kube-apiserver` for PodSpecs assigned to its node, instructs the container runtime to start containers, executes probes, mounts volumes, and reports node/pod status. 2. Container Runtime (`containerd` or `CRI-O`): Implements the Container Runtime Interface (CRI) to pull images and manage OCI containers (Note: `dockershim` was removed in K8s v1.24). 3. `kube-proxy`: Runs on every node to program `iptables`, `IPVS`, or `nftables` rules that route Service ClusterIP virtual IPs to backend Pod IPs. |
| **Trace the step-by-step lifecycle of what happens in Kubernetes when you run `kubectl create deployment nginx --image=nginx`.** | 1. `kubectl` sends an HTTP `POST` to `kube-apiserver` -> 2. API server authenticates, authorizes (RBAC), runs Mutating & Validating Admission Webhooks, and writes the `Deployment` object to `etcd` -> 3. Deployment controller (in `kube-controller-manager`) notices via watch and creates a `ReplicaSet` via API server -> 4. ReplicaSet controller creates `Pod` objects (status `Pending`, `nodeName` empty) -> 5. `kube-scheduler` binds Pods to a healthy node (`nodeName: node01`) -> 6. `kubelet` on `node01` sees the bound Pod, calls `containerd` (CRI) and CNI plugin to allocate IP and start the container, updating status to `Running`. |
| **How does `etcd` use the Raft consensus algorithm to determine quorum, and why should you deploy an odd number of `etcd` nodes (3 or 5)?** | Raft requires a strict majority quorum of $\lfloor N/2 \rfloor + 1$ healthy nodes to elect a leader and commit writes. A 3-node cluster requires 2 nodes for quorum (tolerates 1 failure). Adding a 4th node increases the quorum requirement to 3 nodes, so a 4-node cluster STILL only tolerates 1 failure while slowing down write replication! A 5-node cluster requires 3 nodes for quorum and tolerates 2 node failures. |
| **What are the exact `etcdctl` commands to take a snapshot backup and restore an `etcd` cluster in the CKA exam?** | Backup: `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 /tmp/etcd-backup.db` (verify with `etcdctl snapshot status /tmp/etcd-backup.db -w table`). Restore: `ETCDCTL_API=3 etcdctl snapshot restore /tmp/etcd-backup.db --data-dir=/var/lib/etcd-restored`, then update `hostPath` in `/etc/kubernetes/manifests/etcd.yaml` to point to `/var/lib/etcd-restored`. |
| **What resources do multiple containers inside the same Kubernetes Pod share with one another?** | All containers in a Pod share: 1. The same Network Namespace (initialized by the hidden `pause` / sandbox container)—they share the exact same IP address and port space and communicate with each other over `localhost`; 2. The same IPC Namespace (shared memory); 3. Optionally the same PID Namespace (`shareProcessNamespace: true`); 4. Any Pod-level `volumes` mounted into their respective `volumeMounts` paths. |
| **Compare the four multi-container Pod design patterns: Init Container, Sidecar, Adapter, and Ambassador.** | 1. Init Container (`spec.initContainers`): Runs sequentially to completion BEFORE any main `containers` start (e.g., waiting for a DB service, running schema migrations, cloning config). 2. Sidecar: Runs alongside the main container (supported natively in K8s 1.28+ via `initContainers` with `restartPolicy: Always`) to provide auxiliary tasks like log shipping (Fluent Bit) or service mesh mTLS (Envoy). 3. Adapter: Standardizes/transforms heterogeneous app output (e.g., converting custom logs/metrics into Prometheus format). 4. Ambassador: Local proxy on `localhost` simplifying outbound connections to external shards/services. |
| **What is a Static Pod in Kubernetes, how do you identify one, and where are its manifests stored on a `kubeadm` node?** | A Static Pod is managed directly by the `kubelet` daemon on a specific node without the `kube-apiserver` or `kube-scheduler` (used by `kubeadm` to bootstrap `kube-apiserver`, `etcd`, `kube-scheduler`, and `kube-controller-manager`). `kubelet` watches `staticPodPath` (configured in `/var/lib/kubelet/config.yaml`, defaulting to `/etc/kubernetes/manifests/`). It creates a read-only 'Mirror Pod' in the API server whose name always ends with the node hostname suffix (e.g., `etcd-controlplane`). Deleting a Mirror Pod via `kubectl delete pod` will NOT remove it; you must move/delete the YAML from `/etc/kubernetes/manifests/`. |
| **Compare `startupProbe`, `readinessProbe`, and `livenessProbe` in a Kubernetes Pod, including what happens when each fails.** | 1. `startupProbe`: Runs first; disables both liveness and readiness checks until it succeeds (prevents slow-starting legacy/JVM apps from being killed before they finish booting; if it fails `failureThreshold` times, the container is killed and restarted). 2. `livenessProbe`: Checks if the container is deadlocked; if it fails, `kubelet` kills and restarts the container according to `restartPolicy`. 3. `readinessProbe`: Checks if the Pod is ready to accept traffic; if it fails, the Pod is NOT restarted, but its IP is removed from Service `Endpoints`/`EndpointSlices`. |
| **What are the four probe check mechanisms supported by Kubernetes `livenessProbe`, `readinessProbe`, and `startupProbe`?** | 1. `httpGet`: Sends an HTTP GET request to a specified `port`, `path`, and `httpHeaders`; succeeds if HTTP status code is `200 <= code < 400`. 2. `tcpSocket`: Attempts to open a TCP connection on the specified `port`; succeeds if the socket connects. 3. `exec`: Executes a command inside the container; succeeds if the command exits with status code `0`. 4. `grpc`: Performs a native gRPC health check on the configured `port` and `service`. |
| **Explain the step-by-step sequence of a Graceful Pod Termination in Kubernetes when `kubectl delete pod` is executed.** | 1. Pod status changes to `Terminating` and a `deletionGracePeriodSeconds` (default `30s`) timer starts. 2. Concurrently (in parallel!): (a) Endpoint controller removes the Pod IP from Service `Endpoints`/`EndpointSlices` so `kube-proxy` and Ingress stop routing new traffic to it; AND (b) `kubelet` runs the `preStop` lifecycle hook (if defined) inside the container, then sends `SIGTERM` to container `PID 1`. 3. If the container is still running when `terminationGracePeriodSeconds` expires, `kubelet` sends immediate `SIGKILL` (`9`). Tip: Add a brief `sleep 5` in `preStop` so `kube-proxy`/ALB endpoint removal propagates before the app stops accepting connections! |
| **How do `maxSurge` and `maxUnavailable` control a Kubernetes Deployment's `RollingUpdate` strategy?** | Given a Deployment with `replicas: 10`: `maxUnavailable` (default `25%`) is the maximum number of Pods that can be unavailable during the update (at least $10 - 2 = 8$ Pods must remain available). `maxSurge` (default `25%`) is the maximum number of extra Pods that can be created above the desired replica count during the update (up to $10 + 3 = 13$ total Pods). Setting `maxSurge: 1, maxUnavailable: 0` ensures a new Pod is completely Ready before an old Pod is terminated. |

👉 **[Practice Deck 3: Kubernetes Architecture, Pods, Deployments, Services & Ingress (CKA/CKAD) (32 Flashcards) →](https://flashcards.world/flashcards/sets/d9e3775a-2a02-4ed6-a840-564b4390a887/)**  
🔍 **[Browse All Intermediate Kubernetes (CKA / CKAD), Docker Containers, Linux (LPIC-1 / RHCSA) & Git CI/CD Sets →](https://flashcards.world/flashcards/?q=Kubernetes%20%28CKA%20/%20CKAD%29%2C%20Docker%20Containers%2C%20Linux%20%28LPIC-1%20/%20RHCSA%29%20%26%20Git%20CI/CD&back_lng=en&expertise_level=intermediate)**

---

## Deck 4: Kubernetes ConfigMaps, Secrets, RBAC, PersistentVolumes, Helm & Troubleshooting (32 Cards — Intermediate)

**What this deck covers**: Intermediate-to-advanced Kubernetes administration and security covering ConfigMaps and Secrets, RBAC (Roles/ClusterRoles/ServiceAccounts), SecurityContexts, CSI Storage (PV/PVC/StorageClass), Advanced Scheduling (Affinity, Taints/Tolerations, QoS classes, HPA/VPA), Helm charts, and CKA cluster troubleshooting.

| High-Yield Prompt / Question | Verified Answer & Exam Application |
| :--- | :--- |
| **What are the ways to inject a `ConfigMap` or `Secret` into a Pod, and which methods automatically update when the `ConfigMap`/`Secret` is modified?** | 1. Environment Variables (`env.valueFrom.configMapKeyRef`/`secretKeyRef` or `envFrom`): Injected only at container startup; does NOT update dynamically if the ConfigMap/Secret changes (requires Pod restart). 2. Volume Mount (`volumes[].configMap`/`secret`): `kubelet` periodically syncs changes and atomically swaps symlinked files inside the running container! EXCEPTION: If the `volumeMount` uses `subPath` (to mount a single file without hiding the target directory), it does NOT receive automatic updates! |
| **Why are Kubernetes `Secret` objects NOT secure by default, and how do you secure them in production?** | By default, Kubernetes `Secrets` are merely Base64-encoded strings (`echo -n 'pass' \| base64`), NOT encrypted, and are stored in plain text inside `etcd`! Anyone with RBAC `get`/`list`/`watch` on `secrets` (or access to an `etcd` snapshot) can read them. To secure Secrets: 1. Enable Encryption at Rest on `kube-apiserver` (`--encryption-provider-config` using `aescbc`, `secretbox`, or KMS provider v2); 2. Restrict RBAC `watch`/`list` on Secrets; 3. Use External Secrets Operator or CSI Secret Store Driver with Vault/Cloud KMS. |
| **What does setting `immutable: true` on a Kubernetes `ConfigMap` or `Secret` accomplish?** | Marking a `ConfigMap` or `Secret` as `immutable: true` prevents any future modifications to its `data` (to change values, you must create a new uniquely named `ConfigMap`/`Secret` v2 and update the Deployment). This protects against accidental bad config rollouts AND dramatically improves cluster scalability because `kubelet` stops polling/watching the `kube-apiserver` for changes to that resource across thousands of nodes. |
| **Compare `Role` vs. `ClusterRole` and `RoleBinding` vs. `ClusterRoleBinding` in Kubernetes RBAC.** | `Role`: Namespaced object defining permissions (`verbs` on `resources`/`apiGroups`) within a single namespace. `ClusterRole`: Cluster-scoped object defining permissions on cluster-wide resources (like `nodes`, `persistentvolumes`, `namespaces`), non-resource URLs (`/healthz`), OR namespaced resources across all namespaces. `RoleBinding`: Grants a `Role` OR a `ClusterRole` to subjects (`User`, `Group`, `ServiceAccount`), scoped strictly to the RoleBinding's single namespace. `ClusterRoleBinding`: Grants a `ClusterRole` across the entire cluster. |
| **Why is binding a `ClusterRole` using a `RoleBinding` (instead of a `ClusterRoleBinding`) a powerful RBAC design pattern?** | It allows cluster administrators to define standard reusable permission templates once at the cluster level (such as the built-in `admin`, `edit`, or `view` `ClusterRoles`) and then bind them via a namespaced `RoleBinding` in `namespace: team-a`. The subject receives those permissions ONLY inside `team-a`, avoiding having to duplicate identical `Role` definitions in every namespace. |
| **How do you test RBAC permissions in Kubernetes using `kubectl auth can-i` and impersonation?** | Check your own permissions: `kubectl auth can-i create deployments -n prod`. Check what a specific ServiceAccount or User can do using `--as`: `kubectl auth can-i delete pods --as=system:serviceaccount:dev:backend-sa -n dev`, or list everything a principal is allowed to do with `kubectl auth can-i --list --as=jane`. |
| **How have Kubernetes `ServiceAccount` tokens changed since Kubernetes v1.22 / v1.24 (TokenRequest API)?** | Prior to v1.24, creating a `ServiceAccount` automatically generated a non-expiring Secret containing a static JWT token. In modern Kubernetes (v1.24+), no long-lived Secret token is auto-created; instead, `kubelet` uses the `TokenRequest` API and projected volumes to mount a time-bound (e.g., 1-hour auto-rotating), audience-bound JWT token into the Pod at `/var/run/secrets/kubernetes.io/serviceaccount/token` (can be disabled via `automountServiceAccountToken: false`). |
| **What security settings can be configured in a Pod or Container `securityContext`, and what are Pod Security Standards (PSS)?** | `securityContext` settings include: `runAsNonRoot: true`, `runAsUser: 10001`, `runAsGroup: 10001`, `fsGroup: 2000` (Pod-level: sets group ownership on mounted volumes), `readOnlyRootFilesystem: true`, `allowPrivilegeEscalation: false`, `capabilities: { drop: ["ALL"] }`, and `seccompProfile: { type: RuntimeDefault }`. Pod Security Admission enforces three built-in Pod Security Standards via namespace labels (`pod-security.kubernetes.io/enforce`): `privileged`, `baseline`, and `restricted`. |
| **Explain the lifecycle and binding relationship between `PersistentVolume` (PV), `PersistentVolumeClaim` (PVC), and `StorageClass` (SC).** | A `PersistentVolume` (PV) is a cluster-scoped piece of storage provisioned either statically by an admin or dynamically by a `StorageClass` CSI provisioner. A `PersistentVolumeClaim` (PVC) is a namespaced request by a user for storage (`accessModes`, `resources.requests.storage`, `storageClassName`). When a PVC is created with a `StorageClass`, the CSI driver dynamically creates the underlying cloud disk and binds the PV 1-to-1 (`Bound`) to the PVC. Setting `volumeBindingMode: WaitForFirstConsumer` delays disk creation until the Pod is scheduled to a specific Availability Zone! |
| **Compare the four PersistentVolume Access Modes (`RWO`, `ROX`, `RWX`, `RWOP`) and three Reclaim Policies (`Retain`, `Delete`, `Recycle`).** | Access Modes: `ReadWriteOnce` (`RWO`: mounted read-write by a single Node—multiple Pods on that same node can share it); `ReadOnlyMany` (`ROX`: mounted read-only by many Nodes); `ReadWriteMany` (`RWX`: mounted read-write by many Nodes simultaneously, e.g., NFS, CephFS, Azure Files, EFS); `ReadWriteOncePod` (`RWOP`: mounted read-write by only a single Pod in the whole cluster). Reclaim Policies (when PVC is deleted): `Retain` (keeps PV and data for manual recovery; default for manual PVs), `Delete` (deletes PV and cloud disk; default for dynamic StorageClasses). |
| **What happens when a `PersistentVolume` with `persistentVolumeReclaimPolicy: Retain` has its `PersistentVolumeClaim` deleted, and how do you reuse that PV?** | When the PVC is deleted, the PV transitions from `Bound` to `Released` (NOT `Available`!). A `Released` PV cannot be bound by any new PVC because it still holds the previous claimant's `spec.claimRef` pointer and old data. To make the existing PV `Available` again for a new PVC without deleting the PV, edit the PV (`kubectl edit pv <name>`) and delete the `spec.claimRef` block. |
| **Compare `nodeName`, `nodeSelector`, and `nodeAffinity` for scheduling Pods onto specific Kubernetes nodes.** | `nodeName`: Bypasses `kube-scheduler` completely and forces `kubelet` on that exact node to run the Pod. `nodeSelector`: Simplest scheduler filter requiring exact equality on node labels (e.g., `disktype: ssd`). `nodeAffinity`: Expressive scheduling rules supporting `In`, `NotIn`, `Exists`, `DoesNotExist`, `Gt`, `Lt` operators and two modes: `requiredDuringSchedulingIgnoredDuringExecution` (hard requirement: Pod stays `Pending` if unmatched) vs `preferredDuringSchedulingIgnoredDuringExecution` (soft weighted preference). |

👉 **[Practice Deck 4: Kubernetes ConfigMaps, Secrets, RBAC, PersistentVolumes, Helm & Troubleshooting (32 Flashcards) →](https://flashcards.world/flashcards/sets/3ba35e02-a1c6-4e32-aaf4-2447b73bd7e3/)**  
🔍 **[Browse All Intermediate Kubernetes (CKA / CKAD), Docker Containers, Linux (LPIC-1 / RHCSA) & Git CI/CD Sets →](https://flashcards.world/flashcards/?q=Kubernetes%20%28CKA%20/%20CKAD%29%2C%20Docker%20Containers%2C%20Linux%20%28LPIC-1%20/%20RHCSA%29%20%26%20Git%20CI/CD&back_lng=en&expertise_level=intermediate)**

---

## Deck 5: Terraform IaC (State, Modules, Providers, Workspaces & Lifecycle) (32 Cards — Advanced)

**What this deck covers**: Advanced Infrastructure as Code (IaC) mastery for HashiCorp Terraform Associate & Professional covering HCL syntax, the core Terraform workflow, remote state backends and locking, state manipulation and import, count vs for_each, dynamic blocks, variable precedence, lifecycle meta-arguments, modules, workspaces, and drift detection.

| High-Yield Prompt / Question | Verified Answer & Exam Application |
| :--- | :--- |
| **Explain the five core stages of the Terraform workflow: `Write` -> `init` -> `validate` -> `plan` -> `apply` (`destroy`).** | 1. `Write`: Author declarative HCL (`.tf`) configuration files. 2. `terraform init`: Initializes the working directory, downloads required Provider plugins (into `.terraform/providers`), downloads Modules, and initializes the State Backend. 3. `terraform validate`: Statically checks HCL syntax and internal attribute consistency without accessing remote APIs/state. 4. `terraform plan`: Refreshes state against real cloud APIs and computes the execution diff (`+` create, `~` update in-place, `-/+` destroy and recreate). 5. `terraform apply`: Executes the planned changes and updates `terraform.tfstate`. |
| **What is the purpose of `.terraform.lock.hcl` (the Dependency Lock File) and should it be committed to Git?** | Created and updated by `terraform init`, `.terraform.lock.hcl` records the exact version numbers and cryptographic SHA-256 hashes of every Provider plugin selected for the project. YES, `.terraform.lock.hcl` MUST be committed to version control (Git) so that every developer and CI/CD pipeline runs the exact same provider binary ( whereas the `.terraform/` directory and `*.tfstate` files must be ignored in `.gitignore`). Run `terraform init -upgrade` to intentionally update provider versions within constraints. |
| **Why does Terraform require a State file (`terraform.tfstate`), and why must Remote State with State Locking be used in team environments?** | Terraform State maps declarative HCL resource blocks (`aws_instance.web`) to real-world cloud resource IDs (`i-0abcd1234`), tracks resource dependency metadata, and caches attribute values for performance. Storing state locally fails in teams because: 1. Concurrent `terraform apply` runs corrupt state without State Locking; 2. State lacks shared visibility; 3. State files contain sensitive plaintext secrets! Remote backends (e.g., AWS S3 + DynamoDB lock / S3 native lock, Azure Blob Storage with native lease locking, GCS with native object locking, HCP Terraform) provide encryption at rest, shared access, and atomic locking. |
| **What happens if a Terraform run crashes mid-apply and leaves a Remote State Lock stuck, and what precautions apply to `terraform force-unlock`?** | If a CI runner dies abruptly, the remote backend lock (e.g., DynamoDB lock item or Azure Blob lease) may remain locked, blocking subsequent runs. After verifying with 100% certainty that no other person or CI job is actively running `plan`/`apply` against that state, run `terraform force-unlock <LOCK_ID>` using the unique Lock ID printed in the error output. |
| **Compare the `count` and `for_each` meta-arguments in Terraform, and explain why `for_each` is almost always safer for collections of resources.** | `count` creates resources indexed by numeric list position (`aws_subnet.private[0]`, `aws_subnet.private[1]`, `aws_subnet.private[2]`). If you remove the first item from a list passed to `count`, every subsequent item shifts down an index (`[1]` becomes `[0]`, `[2]` becomes `[1]`), causing Terraform to DESTROY and RECREATE all remaining resources! `for_each` accepts a `map` or `set(string)` and indexes resources by stable string key (`aws_subnet.private["us-east-1a"]`), so removing one key only destroys that single resource. |
| **How do you write an idiomatic conditional resource creation (`0` or `1` instance) in Terraform?** | Use `count` with a ternary expression: `count = var.enable_nat_gateway ? 1 : 0`. When `var.enable_nat_gateway` is `false`, `count` evaluates to `0` and the resource is not created. Because `count` turns the resource into a list of length 0 or 1, reference its attributes elsewhere using index `[0]` or the splat expression `one(aws_nat_gateway.this[*].id)`. |
| **What are `dynamic` blocks in Terraform and when should they be used vs. avoided?** | `dynamic` blocks generate repeatable nested configuration blocks INSIDE a resource (such as multiple `ingress` rule blocks inside an `aws_security_group` or `setting` blocks in an App Service) using `for_each` and a `content { ... }` body (referencing the iterator via `<block_name>.key` and `<block_name>.value`). Overusing `dynamic` blocks makes HCL hard to read and maintain; use them only when repeating nested blocks dynamically based on input variables. |
| **What is the exact order of Variable Precedence in Terraform from lowest priority to highest priority (winner)?** | From lowest to highest precedence: 1. `default` value inside the `variable` block; 2. Environment variables (`TF_VAR_<name>`); 3. The `terraform.tfvars` file (if present); 4. The `terraform.tfvars.json` file; 5. Any `*.auto.tfvars` or `*.auto.tfvars.json` files (processed in lexical alphabetical order); 6. Command-line `-var` and `-var-file` flags passed on the CLI (processed in the order provided; highest precedence!). |
| **Compare Input `variable` blocks, `locals` blocks, and `output` blocks in Terraform.** | Input `variable` blocks act like function parameters passed into a module from outside (`type`, `default`, `description`, `validation`, `sensitive`, `nullable`). `locals` blocks act like private local constants/expressions computed inside a module to avoid repeating DRY expressions (cannot be overridden directly from CLI flags). `output` blocks act like function return values, exposing selected resource attributes to the CLI after `apply`, to a parent module (`module.<name>.<output>`), or to `terraform_remote_state`. |
| **How does marking a variable or output with `sensitive = true` protect secrets in Terraform, and what does it NOT protect?** | Setting `sensitive = true` (or using the `sensitive()` function) redacts the value from appearing in `terraform plan` and `terraform apply` console/CLI log output (`(sensitive value)`), and Terraform requires any output derived from a sensitive variable to also be marked `sensitive = true`. CRITICAL: `sensitive = true` does NOT encrypt or hide the secret inside `terraform.tfstate`! The raw secret value is still written in plain text in the state JSON file (though ephemeral values/write-only attributes in Terraform 1.10+ help avoid storing ephemeral credentials in state). |
| **Explain the four `lifecycle` meta-arguments in Terraform: `create_before_destroy`, `prevent_destroy`, `ignore_changes`, and `replace_triggered_by`.** | 1. `create_before_destroy = true`: Reverses Terraform's default replacement order when a resource must be recreated (`+/-` instead of `-/+`), provisioning the replacement resource BEFORE destroying the old one (essential for zero-downtime Launch Templates, TLS certificates, or API Gateway deployments). 2. `prevent_destroy = true`: Causes Terraform to error out and reject any plan that would destroy the resource (so long as the block remains in HCL). 3. `ignore_changes = [tags, ami]`: Tells Terraform to ignore external drift on specified attributes (e.g., autoscaling `desired_capacity` or Azure/AWS auto-tags). 4. `replace_triggered_by`: Forces replacement when a referenced resource/attribute changes. |
| **How do `precondition` and `postcondition` blocks inside a resource's `lifecycle` block (plus `check` blocks) improve infrastructure reliability?** | Introduced in Terraform 1.2+, `precondition` validates assumptions BEFORE Terraform creates/updates a resource (e.g., verifying an AMI is `x86_64`), while `postcondition` validates guarantees AFTER a resource is created/read using `self.<attr>` (e.g., asserting `self.encrypted == true`). If either fails, Terraform halts execution with your custom `error_message`. Standalone `check` blocks (Terraform 1.5+) run continuous assertions (including scoped data sources like HTTP health checks) at the end of `plan`/`apply` producing warnings without blocking provisioning. |

👉 **[Practice Deck 5: Terraform IaC (State, Modules, Providers, Workspaces & Lifecycle) (32 Flashcards) →](https://flashcards.world/flashcards/sets/8bc6ec2b-01fc-42bb-a124-844111af5385/)**  
🔍 **[Browse All Advanced Kubernetes (CKA / CKAD), Docker Containers, Linux (LPIC-1 / RHCSA) & Git CI/CD Sets →](https://flashcards.world/flashcards/?q=Kubernetes%20%28CKA%20/%20CKAD%29%2C%20Docker%20Containers%2C%20Linux%20%28LPIC-1%20/%20RHCSA%29%20%26%20Git%20CI/CD&back_lng=en&expertise_level=advanced)**

---

## Deck 6: CI/CD Pipelines, GitOps (ArgoCD), Prometheus/Grafana Observability & SRE SLIs/SLOs (32 Cards — Advanced)

**What this deck covers**: Senior DevOps and Site Reliability Engineering (SRE) mastery covering deployment strategies (Blue/Green, Canary, Shadow, Feature Flags), GitOps principles, ArgoCD and Flux architecture, the Three Pillars of Observability, OpenTelemetry, Prometheus TSDB and PromQL, the Four Golden Signals, RED/USE methods, and SRE SLIs/SLOs/Error Budgets.

| High-Yield Prompt / Question | Verified Answer & Exam Application |
| :--- | :--- |
| **Compare the four progressive CI/CD deployment strategies: Rolling Update, Blue/Green, Canary, and Shadow (Dark Traffic Mirroring).** | 1. Rolling Update: Gradually replaces old instances with new ones in-place (zero extra infra cost, but slow rollback and mixed versions serve live traffic). 2. Blue/Green: Provisions a full duplicate 'Green' environment alongside live 'Blue', runs smoke tests, then flips the Load Balancer/router 100% from Blue to Green (instant rollback by flipping back; 2x infra cost during cutover). 3. Canary: Routes a small fraction (e.g., 1% -> 5% -> 25% -> 100%) of live traffic to the new version while monitoring error/latency SLIs (Argo Rollouts / Flagger). 4. Shadow / Dark Launch: Mirrors a duplicate copy of live production requests to v2 asynchronously without returning v2's responses to users. |
| **How does decoupling 'Deployment' from 'Release' using Feature Flags (Feature Toggles) improve CI/CD safety and trunk-based development?** | Deployment is the technical act of pushing and running new binary/container code in production; Release is the business decision to expose a new feature to end users. With Feature Flags (e.g., LaunchDarkly, OpenFeature, Unleash), engineers merge incomplete or high-risk code into `main` daily deployed behind an `OFF` flag, then progressively enable the feature at runtime for internal QA users, 5% of beta customers, or specific regions—and can kill a broken feature in milliseconds via a config toggle without rolling back or redeploying containers! |
| **What are the Four Core Principles of GitOps as defined by the OpenGitOps / CNCF specification?** | 1. Declarative: A system managed by GitOps must have its desired state expressed declaratively (e.g., K8s YAML, Helm, Kustomize). 2. Versioned and Immutable: Desired state is stored in Git in a way that enforces immutability, versioning, and retains a complete audit trail. 3. Pulled Automatically: Software agents (ArgoCD / Flux) automatically pull the desired state declarations from the source. 4. Continuously Reconciled: Software agents continuously observe actual system state and attempt to apply the desired state (closed-loop drift remediation). |
| **Compare Push-Based CI/CD vs. Pull-Based GitOps for Kubernetes cluster security and drift detection.** | Push-Based CI/CD (e.g., GitHub Actions / Jenkins running `kubectl apply` or `helm upgrade`): Requires storing powerful cluster-admin Kubernetes credentials inside the external CI server and exposing the K8s API server to CI runners; furthermore, CI only runs when a commit happens, so it never detects manual `kubectl edit` drift in the cluster! Pull-Based GitOps (ArgoCD / Flux running INSIDE the cluster): The agent pulls outbound from Git, so external CI never needs cluster credentials (CI only builds the image and opens a PR updating the image digest in the GitOps config repo), and the agent continuously detects and reverts live cluster drift. |
| **Explain the architecture of ArgoCD (`argocd-server`, `argocd-repo-server`, `argocd-application-controller`) and the `Application` vs. `ApplicationSet` CRDs.** | 1. `argocd-server`: API/gRPC server and Web UI. 2. `argocd-repo-server`: Clones Git repositories and renders Helm charts / Kustomize overlays / Jsonnet into plain Kubernetes YAML manifests. 3. `argocd-application-controller`: Continuously compares the rendered target manifests against live Kubernetes cluster objects, reporting `Synced` vs `OutOfSync` and `Healthy` vs `Degraded`. The `Application` CRD maps ONE Git `source` to ONE cluster/namespace `destination`; the `ApplicationSet` CRD uses Generators (Git directory, Cluster, Matrix, Pull Request) to template dozens of `Applications` automatically. |
| **What is the difference between `prune: true` and `selfHeal: true` in an ArgoCD `Application` automated `syncPolicy`?** | `prune: true`: When a manifest file is DELETED from the Git repository, ArgoCD automatically deletes the corresponding live resource from the Kubernetes cluster (by default `prune` is `false` to prevent accidental deletions). `selfHeal: true`: When someone manually modifies or deletes a live resource directly inside the Kubernetes cluster (`kubectl edit`/`delete`) causing live drift from Git, ArgoCD automatically overwrites the manual change and reconciles the cluster back to the exact state in Git. |
| **How do Sync Waves and Resource Hooks (`PreSync`, `Sync`, `PostSync`, `SyncFail`) control deployment ordering in ArgoCD?** | Sync Waves (`argocd.argoproj.io/sync-wave: "-1"`) order how resources are applied: lower (including negative) integers are applied first, and ArgoCD waits for all resources in wave $N$ to become `Healthy` before applying wave $N+1$ (e.g., Wave `-1`: Namespace & CRDs -> Wave `0`: DB Deployment -> Wave `1`: Backend App). Resource Hooks (`argocd.argoproj.io/hook: PreSync`) run one-off Kubernetes `Jobs` at specific lifecycle phases—for example, running a database schema migration Job in `PreSync` before new application pods roll out in `Sync`, or sending a Slack alert on `SyncFail`. |
| **How do you safely store encrypted secrets inside a public or private GitOps repository using Sealed Secrets vs. SOPS vs. External Secrets Operator (ESO)?** | 1. Bitnami Sealed Secrets: Asymmetric crypto (`kubeseal` CLI encrypts a Secret using the cluster controller's public key into a safe-to-commit `SealedSecret` CRD; only the in-cluster controller holds the private key to decrypt it). 2. Mozilla SOPS (Secrets OPerationS): Encrypts only the YAML/JSON *values* (leaving keys readable for git diffs) backed by AWS KMS, GCP KMS, Azure Key Vault, or `age` keys. 3. External Secrets Operator (ESO): Stores NO secret ciphertext in Git at all—Git only stores an `ExternalSecret` CRD containing the key name/path reference, which ESO fetches dynamically at runtime from Vault/AWS Secrets Manager/Key Vault. |
| **What are the Three Pillars of Observability, and what distinct question does each pillar answer during an incident?** | 1. Metrics (numeric time-series aggregations stored in Prometheus/VictoriaMetrics/Mimir): Answers 'WHAT is broken and WHEN did it start?' (fast, constant-overhead alerting on symptom trends like error rate or P99 latency). 2. Logs (structured JSON discrete event records stored in Loki/Elasticsearch/ClickHouse): Answers 'WHY did this specific instance fail?' (exact stack trace, error message, and context). 3. Distributed Traces (end-to-end request spans across microservices stored in Tempo/Jaeger): Answers 'WHERE in the distributed call graph is the latency bottleneck or failure occurring?' |
| **What is OpenTelemetry (OTel) and how does the OpenTelemetry Collector pipeline (`Receivers` -> `Processors` -> `Exporters`) work?** | OpenTelemetry is the CNCF vendor-neutral standard combining APIs, SDKs, semantic conventions, and the OTLP (OpenTelemetry Protocol over gRPC `4317` / HTTP `4318`) for Traces, Metrics, and Logs. The OTel Collector decouples apps from observability backends via a 3-stage pipeline: 1. `Receivers` (ingest telemetry via OTLP, Prometheus scrape, Host metrics, Filelog); 2. `Processors` (batching, memory limiting, PII redaction, tail-based sampling, adding k8s metadata via `k8sattributes`); 3. `Exporters` (fan-out to Prometheus, Jaeger/Tempo, Loki, Datadog, or Cloud Operations). |
| **How does W3C Trace Context propagation (`traceparent` HTTP header) link spans across microservices, and how do Head Sampling vs. Tail Sampling differ?** | Every instrumented service injects and extracts the W3C standard `traceparent` HTTP/gRPC header (`00-<128-bit-trace-id>-<64-bit-parent-span-id>-<trace-flags>`), linking all downstream child spans to the same `trace_id`. Head Sampling makes the keep/drop decision at the very first ingress span (e.g., randomly sample 1% of requests—cheap and stateless, but misses 99% of rare error traces!). Tail Sampling buffers spans of a trace in an OTel Collector tier and makes the sampling decision AFTER the request finishes—keeping 100% of traces containing an HTTP 5xx error or latency >2s, while sampling only 1% of boring 200 OK traces. |
| **How does Prometheus's Pull-based architecture work, and when should you use the Prometheus `Pushgateway`?** | Prometheus periodically scrapes (HTTP `GET /metrics`) configured targets discovered via Kubernetes Service Discovery (`kubernetes_sd_configs`), Consul, or EC2/GCP APIs. Pull makes it trivial to tell if a target is down (`up == 0`) and prevents overloaded targets from DDoS-ing the monitoring server. The `Pushgateway` should ONLY be used for short-lived, ephemeral batch/cron jobs that finish and exit before Prometheus's scrape interval (`15s–60s`) can pull from them (never use Pushgateway for long-running services). |

👉 **[Practice Deck 6: CI/CD Pipelines, GitOps (ArgoCD), Prometheus/Grafana Observability & SRE SLIs/SLOs (32 Flashcards) →](https://flashcards.world/flashcards/sets/25d0f180-68ea-4a29-aa36-7b4c8d594091/)**  
🔍 **[Browse All Advanced Kubernetes (CKA / CKAD), Docker Containers, Linux (LPIC-1 / RHCSA) & Git CI/CD Sets →](https://flashcards.world/flashcards/?q=Kubernetes%20%28CKA%20/%20CKAD%29%2C%20Docker%20Containers%2C%20Linux%20%28LPIC-1%20/%20RHCSA%29%20%26%20Git%20CI/CD&back_lng=en&expertise_level=advanced)**

---

## Complete 6-Deck Quick-Access Directory

| Deck # | Deck Title | Level | Cards | Direct Practice Link |
| :--- | :--- | :--- | :--- | :--- |
| **Deck 1** | Linux Administration (Filesystem, Permissions, systemd, LVM, Networking & Shell) | `basic` | 32 | [Open Deck 1 →](https://flashcards.world/flashcards/sets/c3de089c-4490-4419-adb6-69f7b655f6b0/) |
| **Deck 2** | Docker Containers (Dockerfile, Multi-stage Builds, Volumes, Networks & Security) | `basic` | 32 | [Open Deck 2 →](https://flashcards.world/flashcards/sets/0ccde664-3c18-4dbd-a8d5-1435453addca/) |
| **Deck 3** | Kubernetes Architecture, Pods, Deployments, Services & Ingress (CKA/CKAD) | `intermediate` | 32 | [Open Deck 3 →](https://flashcards.world/flashcards/sets/d9e3775a-2a02-4ed6-a840-564b4390a887/) |
| **Deck 4** | Kubernetes ConfigMaps, Secrets, RBAC, PersistentVolumes, Helm & Troubleshooting | `intermediate` | 32 | [Open Deck 4 →](https://flashcards.world/flashcards/sets/3ba35e02-a1c6-4e32-aaf4-2447b73bd7e3/) |
| **Deck 5** | Terraform IaC (State, Modules, Providers, Workspaces & Lifecycle) | `advanced` | 32 | [Open Deck 5 →](https://flashcards.world/flashcards/sets/8bc6ec2b-01fc-42bb-a124-844111af5385/) |
| **Deck 6** | CI/CD Pipelines, GitOps (ArgoCD), Prometheus/Grafana Observability & SRE SLIs/SLOs | `advanced` | 32 | [Open Deck 6 →](https://flashcards.world/flashcards/sets/25d0f180-68ea-4a29-aa36-7b4c8d594091/) |

👉 **[Launch Full Kubernetes (CKA / CKAD), Docker Containers, Linux (LPIC-1 / RHCSA) & Git CI/CD Spaced-Repetition Track →](https://flashcards.world/flashcards/?q=Kubernetes%20%28CKA%20/%20CKAD%29%2C%20Docker%20Containers%2C%20Linux%20%28LPIC-1%20/%20RHCSA%29%20%26%20Git%20CI/CD&back_lng=en)**

## Curated Flashcard Decks & Practice Sets

- **Linux Administration (Filesystem, Permissions, systemd, LVM, Networking & Shell)**: [Interactive Deck](https://flashcards.world/flashcards/sets/c3de089c-4490-4419-adb6-69f7b655f6b0/) | [Markdown (.md)](https://flashcards.world/flashcards/sets/c3de089c-4490-4419-adb6-69f7b655f6b0.md)
- **Docker Containers (Dockerfile, Multi-stage Builds, Volumes, Networks & Security)**: [Interactive Deck](https://flashcards.world/flashcards/sets/0ccde664-3c18-4dbd-a8d5-1435453addca/) | [Markdown (.md)](https://flashcards.world/flashcards/sets/0ccde664-3c18-4dbd-a8d5-1435453addca.md)
- **Kubernetes Architecture, Pods, Deployments, Services & Ingress (CKA/CKAD)**: [Interactive Deck](https://flashcards.world/flashcards/sets/d9e3775a-2a02-4ed6-a840-564b4390a887/) | [Markdown (.md)](https://flashcards.world/flashcards/sets/d9e3775a-2a02-4ed6-a840-564b4390a887.md)
- **Kubernetes ConfigMaps, Secrets, RBAC, PersistentVolumes, Helm & Troubleshooting**: [Interactive Deck](https://flashcards.world/flashcards/sets/3ba35e02-a1c6-4e32-aaf4-2447b73bd7e3/) | [Markdown (.md)](https://flashcards.world/flashcards/sets/3ba35e02-a1c6-4e32-aaf4-2447b73bd7e3.md)
- **Terraform IaC (State, Modules, Providers, Workspaces & Lifecycle)**: [Interactive Deck](https://flashcards.world/flashcards/sets/8bc6ec2b-01fc-42bb-a124-844111af5385/) | [Markdown (.md)](https://flashcards.world/flashcards/sets/8bc6ec2b-01fc-42bb-a124-844111af5385.md)
- **CI/CD Pipelines, GitOps (ArgoCD), Prometheus/Grafana Observability & SRE SLIs/SLOs**: [Interactive Deck](https://flashcards.world/flashcards/sets/25d0f180-68ea-4a29-aa36-7b4c8d594091/) | [Markdown (.md)](https://flashcards.world/flashcards/sets/25d0f180-68ea-4a29-aa36-7b4c8d594091.md)