🌍 DevOps · flashcards

DevOps Kubernetes Flashcards

72 question-and-answer cards covering Kubernetes as it is examined in DevOps. 24 of them are printed below, taken from across the deck — no signup, no paywall on the preview.

72Cards in deck
24Free preview
26Syllabus topics
~292Chars per answer
FreePrice

24 sample cards from the Kubernetes deck

Sampled from the end of the deck, so these are different cards from the ones shown on the syllabus page.

  1. What is a Kubernetes Operator?

    An Operator is a method of packaging, deploying, and managing a Kubernetes application by encoding human operational knowledge into software. It combines Custom Resource Definitions (CRDs) with a custom controller that continuously reconciles the custom resource, automating tasks like backups, upgrades, and failover for complex stateful apps.

  2. What is a Custom Resource Definition (CRD)?

    A CRD lets you extend the Kubernetes API by defining your own resource kind (a custom resource). Once registered, you can create and manage objects of that new kind with kubectl just like built-in resources. CRDs are the foundation of the Operator pattern.

  3. What is the control loop / reconciliation pattern that Operators and controllers use?

    A controller runs an endless loop that: (1) observes the current state of resources via the API server (watch), (2) compares it to the desired state declared in the spec, and (3) acts to reconcile any difference. This observe-diff-act loop continuously drives actual state toward desired state.

  4. What is a StatefulSet and how does it differ from a Deployment?

    A StatefulSet manages stateful applications, giving each Pod a stable, unique, ordinal network identity (e.g., web-0, web-1) and stable persistent storage via per-Pod PVCs. Unlike a Deployment, whose Pods are interchangeable and randomly named, a StatefulSet maintains ordered, predictable Pod identity and ordered deployment, scaling, and updates.

  5. What guarantees does a StatefulSet provide for Pod ordering?

    StatefulSet Pods are created sequentially in order (0, 1, 2, ...), with each Pod becoming Ready before the next is created, and are terminated in reverse order. Each Pod keeps a stable hostname and its own dedicated PersistentVolumeClaim that persists across rescheduling.

  6. What is a DaemonSet and when would you use one?

    A DaemonSet ensures that a copy of a specific Pod runs on all (or a selected subset of) nodes in the cluster. As nodes are added, Pods are automatically scheduled onto them. It is used for node-level agents such as log collectors (Fluentd), monitoring agents (node-exporter), and networking plugins (CNI, kube-proxy).

  7. What is the difference between a Job and a CronJob?

    A Job creates one or more Pods and ensures a specified number of them successfully complete a task, then terminates (used for batch/one-off work). A CronJob creates Jobs on a repeating time-based schedule, defined with standard cron syntax, for recurring tasks like backups or report generation.

  8. What do the completions and parallelism fields control in a Job?

    completions specifies how many Pods must successfully finish for the Job to be considered complete. parallelism specifies how many Pods are allowed to run at the same time. Together they define non-parallel jobs, fixed-completion-count parallel jobs, and work-queue style parallel jobs.

  9. What is the cron schedule syntax used by a CronJob?

    A CronJob uses standard cron format with five space-separated fields: minute (0–59), hour (0–23), day-of-month (1–31), month (1–12), and day-of-week (0–6, where 0 is Sunday). For example, "$0\ 2\ *\ *\ *$" runs daily at 02:00.

  10. What is the difference between Authentication and Authorization in Kubernetes?

    Authentication (authn) verifies who is making a request (establishing identity via client certificates, bearer tokens, service account tokens, or OIDC). Authorization (authz) determines whether that authenticated identity is allowed to perform the requested action on the resource. Authentication always precedes authorization.

  11. What are the main authorization modes in Kubernetes?

    RBAC (Role-Based Access Control, the most common), ABAC (Attribute-Based Access Control), Node authorization (for kubelets), and Webhook (delegates decisions to an external service). Modes are evaluated in order, and a request is allowed if any enabled module permits it.

  12. Explain the four RBAC objects: Role, ClusterRole, RoleBinding, and ClusterRoleBinding.

    A Role defines permissions (rules) within a single namespace; a ClusterRole defines permissions cluster-wide or for cluster-scoped resources. A RoleBinding grants a Role's (or ClusterRole's) permissions to subjects within a namespace; a ClusterRoleBinding grants a ClusterRole's permissions across the entire cluster.

  13. What is a ServiceAccount in Kubernetes?

    A ServiceAccount provides an identity for processes running inside Pods (as opposed to a UserAccount for humans). Pods use the ServiceAccount's token to authenticate to the API server. Each namespace has a 'default' ServiceAccount, and RBAC bindings control what a ServiceAccount may do.

  14. What is a NetworkPolicy and what is the default behavior without one?

    A NetworkPolicy is a specification of how groups of Pods are allowed to communicate (Layer 3/4 rules selected by labels). By default, with no NetworkPolicy, all Pods can communicate freely (the network is non-isolated/allow-all). Once a Pod is selected by any NetworkPolicy, all traffic not explicitly allowed is denied for the directions specified.

  15. What does a NetworkPolicy require to actually take effect?

    NetworkPolicies are enforced by the cluster's network plugin (CNI). They have no effect unless you use a CNI that supports them, such as Calico, Cilium, or Weave Net. With a non-enforcing CNI, NetworkPolicy objects are accepted but ignored.

  16. What are ingress and egress in the context of a NetworkPolicy?

    Ingress rules control incoming traffic to the selected Pods (who may connect to them). Egress rules control outgoing traffic from the selected Pods (which destinations they may connect to). A policy specifies policyTypes (Ingress, Egress, or both) and lists allowed sources/destinations and ports.

  17. What were PodSecurityPolicies (PSPs) and what is their current status?

    PodSecurityPolicies were a cluster-level admission control resource that restricted the security-sensitive aspects of a Pod's spec (e.g., privileged mode, host namespaces, volume types, running as root). PSPs were deprecated in Kubernetes v1.21 and removed in v1.25.

  18. What replaced PodSecurityPolicy after its removal?

    Pod Security Admission (PSA), a built-in admission controller that enforces the Pod Security Standards at the namespace level. It is configured via namespace labels and offers three modes: enforce, audit, and warn.

  19. What are the three Pod Security Standards levels?

    Privileged (unrestricted, allows known privilege escalations), Baseline (minimally restrictive, prevents known privilege escalations while allowing common Pod specs), and Restricted (heavily restricted, follows current Pod hardening best practices such as non-root users and dropped capabilities).

  20. What is a securityContext in a Pod or container spec?

    A securityContext defines privilege and access control settings for a Pod or container, such as runAsUser/runAsNonRoot, fsGroup, readOnlyRootFilesystem, allowPrivilegeEscalation, privileged, and Linux capabilities to add or drop. It is the per-workload mechanism for enforcing least-privilege after PSPs were removed.

  21. How does Kubernetes use liveness, readiness, and startup probes?

    A liveness probe detects when a container is unhealthy and restarts it. A readiness probe determines when a container is ready to receive traffic; failing it removes the Pod from Service endpoints without restarting it. A startup probe protects slow-starting containers by delaying liveness/readiness checks until the app has started.

  22. What is the difference between resource requests and limits for a container?

    A request is the guaranteed minimum amount of CPU/memory reserved for the container and is used by the scheduler to place the Pod. A limit is the maximum the container may use; exceeding a memory limit causes the container to be OOM-killed, while exceeding a CPU limit causes throttling.

  23. How are CPU and memory resource quantities expressed in Kubernetes?

    CPU is measured in cores; $1$ CPU equals $1000$ millicores, written as "1000m", so "500m" means half a core. Memory is measured in bytes with power-of-two suffixes such as Ki, Mi, Gi (e.g., "256Mi") or decimal suffixes K, M, G.

  24. What is the difference between a taint and a toleration?

    A taint is applied to a node to repel Pods that do not tolerate it (key=value:effect, where effect is NoSchedule, PreferNoSchedule, or NoExecute). A toleration is applied to a Pod to allow (but not require) it to be scheduled onto nodes with matching taints. Taints and tolerations work together to keep Pods off inappropriate nodes.

What this deck covers

The Kubernetes deck follows the DevOps Kubernetes syllabus — 8 chapters and 26 topics — so questions land on material that is genuinely examinable rather than trivia around it. That works out to roughly 9.0 cards per chapter.

Answers are written to be recallable, not just readable — averaging about 292 characters, which is long enough to carry the reasoning and short enough to say out loud.

A deck like this earns its keep on the second and third pass. Read the syllabus first so you know the shape of the subject, then use the cards to find the specific facts that have not stuck.

Kubernetes flashcards FAQ

How many Kubernetes flashcards are in this DevOps deck?

72 cards. This page previews 24 of them, sampled evenly across the deck so you can judge the difficulty before installing anything.

Are these DevOps flashcards free?

Yes. The preview here is free to read with no signup, and the full 72-card deck is free inside the Examius app.

What do the Kubernetes cards cover?

They follow the DevOps Kubernetes syllabus — 8 chapters and 26 topics — so the questions track what is actually examinable.

How should I use these flashcards?

Read the syllabus first so you know the shape of the subject, then drill the deck. Examius schedules each card with spaced repetition, so cards you keep missing come back sooner and ones you know drift further apart.