Top 30 Advanced Docker & Kubernetes Concepts Quiz

30 questions. Pick an answer, or open “Show the answer” to read it.

Answers are graded in your browser. Nothing is saved, and no XP or streak is earned here. The app keeps score.

1. Question 1 of 30

   What is the primary reason Union File Systems, like Docker's OverlayFS, can exhibit performance overhead for write-intensive applications?

   • aEach modification to an existing file from a lower layer triggers a copy-on-write operation.
   • bAll write operations are first buffered in memory before being committed to disk, causing delays.
   • cThey require frequent re-merging of all layers for every write operation.
   • dThe system must synchronize changes across all containers sharing the same base image.
   Show the answer

   Answer: a · Each modification to an existing file from a lower layer triggers a copy-on-write operation.

   The card states that "The copy-on-write mechanism adds performance overhead for every initial write to a file that exists in a lower layer." This means files from read-only layers must first be copied to the writable layer before they can be modified, which is an extra I/O operation. Distractor A is incorrect because lower layers are read-only and not re-merged on write; changes are isolated to the top writable layer.

   Read the full bite: Union File Systems: Docker's Layered Magic

2. Question 2 of 30

   The OCI Runtime Spec primarily standardizes container execution by defining:

   • aHigh-level APIs for container orchestration systems like Kubernetes.
   • bA universal container image format for distribution.
   • cA set of user-facing commands for managing container lifecycles directly.
   • dThe structure of a filesystem bundle and a config.json for runtime instructions.
   Show the answer

   Answer: d · The structure of a filesystem bundle and a config.json for runtime instructions.

   The OCI Runtime Spec defines the 'filesystem bundle' (a directory containing the root filesystem and a config.json) and the config.json file itself, which specifies how a low-level runtime should execute the container. Option B describes the OCI Image Spec, while options C and D refer to higher-level abstractions or user-facing tools, which the Runtime Spec is explicitly not.

   Read the full bite: OCI Runtime Spec: The 'How to Run' Standard for Containers

3. Question 3 of 30

   Which scenario best illustrates the primary benefit of a container runtime shim?

   • aMultiple containers share the same shim process to reduce system resource consumption.
   • bThe container's filesystem and configuration are prepared by the shim before execution.
   • cA container daemon crashes, but all running containers continue to operate unaffected.
   • dA developer can run a container directly using runc without involving a higher-level daemon.
   Show the answer

   Answer: c · A container daemon crashes, but all running containers continue to operate unaffected.

   The primary benefit of a runtime shim is to decouple the container daemon from the container's lifecycle, allowing the daemon to restart or crash without terminating running containers. Option B is incorrect because the daemon (e.g., containerd) prepares the container's filesystem and configuration, not the shim.

   Read the full bite: Container Runtime Shim: Decoupling the Container Lifecycle

4. Question 4 of 30

   What is the immediate consequence when a process, protected by an active seccomp profile, attempts to execute a forbidden system call?

   • aThe system call is re-routed to a secure, isolated sandbox for execution.
   • bThe system call is logged as a security event and allowed to proceed.
   • cThe process's user ID is automatically changed to a less privileged one.
   • dThe kernel immediately terminates the offending process.
   Show the answer

   Answer: d · The kernel immediately terminates the offending process.

   The card states that any attempt by a process to use a syscall not on the allowlist causes the kernel to terminate the process. Seccomp is an enforcement mechanism, not merely an audit tool that logs events.

   Read the full bite: seccomp: A Kernel-Level Allowlist for Syscalls

5. Question 5 of 30

   What problem do Docker multi-stage builds primarily solve for application deployment?

   • aThe performance overhead of running applications within a containerized environment.
   • bThe excessive size of Docker images due to included build-time dependencies.
   • cThe difficulty of integrating continuous integration/continuous deployment pipelines.
   • dThe complexity of managing multiple Dockerfiles for different environments.
   Show the answer

   Answer: b · The excessive size of Docker images due to included build-time dependencies.

   The card clearly states that multi-stage builds exist because "creating small Docker images was clumsy" and they "keeps images small by excluding build-time dependencies," dramatically reducing the final image size. While consolidating Dockerfile logic (D) is a side benefit, the primary problem addressed is image bloat.

   Read the full bite: Docker Multi-stage Builds: Slimmer, Faster Images

6. Question 6 of 30

   What is the primary benefit of integrating Docker image scanning into a CI/CD pipeline?

   • aIt encrypts sensitive configuration data within the image for enhanced security.
   • bIt verifies the functional correctness and performance of the application code.
   • cIt acts as a gate to prevent images with known security flaws from reaching deployment.
   • dIt automatically patches identified vulnerabilities in base images and libraries.
   Show the answer

   Answer: c · It acts as a gate to prevent images with known security flaws from reaching deployment.

   The card states that in a CI/CD pipeline, scanning acts as a gate to automatically fail builds containing critical vulnerabilities, preventing them from being deployed. Option D is incorrect because scanning identifies vulnerabilities; it does not automatically remediate or patch them.

   Read the full bite: Docker Image Scanning: A Background Check for Your Code

7. Question 7 of 30

   What is the primary benefit of using Docker Compose profiles?

   • aTo manage configurations for fundamentally different application stacks within a single compose.yaml file.
   • bTo apply major configuration changes, like resource limits or network settings, uniformly across the majority of services in a project.
   • cTo define and selectively activate optional groups of services, such as debugging tools or environment-specific setups, from a unified compose.yaml.
   • dTo ensure that all services defined in the compose.yaml file are always launched together, simplifying deployment.
   Show the answer

   Answer: c · To define and selectively activate optional groups of services, such as debugging tools or environment-specific setups, from a unified compose.yaml.

   Profiles are designed to enable or disable subsets of services (e.g., debugging tools, dev-specific setups) within a single compose.yaml file, reducing complexity. Option A describes a scenario where separate compose.yaml files are explicitly recommended instead of profiles.

   Read the full bite: Docker Compose Profiles: Activate Service Groups

8. Question 8 of 30

   What is the primary benefit of using extended Docker Compose files for different environments?

   • aTo automatically deploy and manage container orchestration on platforms like Kubernetes.
   • bTo define entirely distinct applications that share no common services.
   • cTo manage environment-specific configuration variations for a single application efficiently.
   • dTo enforce identical resource limits and network settings across all development and production services.
   Show the answer

   Answer: c · To manage environment-specific configuration variations for a single application efficiently.

   The card states that extending Compose files provides a "clean, DRY (Don't Repeat Yourself) way to manage these variations" for a single application across different environments. Option B is incorrect because the card advises against using this for entirely separate applications. Option A is incorrect as Compose is not an orchestrator like Kubernetes, but can be outgrown by it. Option D is incorrect because the purpose is to manage variations, not to enforce identical settings.

   Read the full bite: Extending Compose Files for Different Environments

9. Question 9 of 30

   When using Docker Compose Secrets, how does an application inside a service typically retrieve the sensitive information?

   • aIt reads the secret value from an environment variable automatically set by Compose.
   • bIt accesses a file mounted by Compose into a specific directory within the container.
   • cIt fetches the secret from a dedicated Compose secrets API endpoint.
   • dIt retrieves the secret directly from the docker-compose.yml file at runtime.
   Show the answer

   Answer: b · It accesses a file mounted by Compose into a specific directory within the container.

   Docker Compose Secrets are mounted as files into the container's filesystem at /run/secrets/<secret_name>, which the application then reads. Option A is a common misconception; applications must read secrets from these files, not directly from environment variables, to maintain security.

   Read the full bite: Docker Compose Secrets: Keep Credentials Out of Your Code

10. Question 10 of 30

    How does an OCI Image Manifest primarily ensure the integrity and immutability of a container image?

    • aBy including a digital signature from the image builder within its JSON structure.
    • bThrough the use of cryptographic hashes for the manifest itself, its configuration, and all referenced layers.
    • cBy embedding the complete source code of the application directly within the manifest file.
    • dBy requiring all image layers to be stored in a read-only filesystem during runtime execution.
    Show the answer

    Answer: b · Through the use of cryptographic hashes for the manifest itself, its configuration, and all referenced layers.

    The card explicitly states that "The manifest, its config, and its layers are all content-addressable by their cryptographic hashes, ensuring immutability and verifiability." Option A is incorrect as digital signatures are not the primary mechanism described for the manifest's inherent integrity.

    Read the full bite: OCI Image Manifest: The Recipe for a Container Image

11. Question 11 of 30

    What is the primary reason an enterprise would implement Harbor for its container image management?

    • aTo reduce the overall storage and bandwidth costs associated with large image repositories.
    • bTo provide a universal API for pushing and pulling images across different cloud providers.
    • cTo access a broader selection of community-contributed and open-source container images.
    • dTo establish a private, secure, and auditable repository for managing their software supply chain.
    Show the answer

    Answer: d · To establish a private, secure, and auditable repository for managing their software supply chain.

    Harbor's core purpose is to offer a private, secure, and auditable environment for an organization's software supply chain, enabling features like vulnerability scanning and content signing. While other options might be perceived as benefits of some registries, they are not the primary drivers for adopting Harbor as described in the card.

    Read the full bite: Harbor: A Private, Secure Artifact Registry

12. Question 12 of 30

    How does modern container image signing, like Sigstore, primarily ensure both the authenticity and integrity of an image?

    • aBy relying on developers to securely manage and use long-lived private/public key pairs.
    • bBy trusting the image registry to guarantee that published images have not been tampered with.
    • cBy linking a short-lived signing key to a verified identity via OIDC, recorded in a public transparency log.
    • dBy encrypting the image digest to prevent unauthorized access or modification.
    Show the answer

    Answer: c · By linking a short-lived signing key to a verified identity via OIDC, recorded in a public transparency log.

    The card explains that modern systems like Sigstore use short-lived, ephemeral keys, verify the signer's identity via an OIDC provider, and record this information in a public transparency log. This process establishes both authenticity and integrity. Option A describes traditional signing, which modern systems aim to improve upon.

    Read the full bite: Container Image Signing: Verifying What You Run

13. Question 13 of 30

    Which task is generally NOT best managed by a Kubernetes controller's continuous reconciliation loop?

    • aEnsuring configuration consistency across all instances of a distributed system.
    • bGuaranteeing a specific number of application replicas are always available.
    • cExecuting a database schema migration script once after a new deployment.
    • dAutomatically restoring a service to its desired state after an unexpected failure.
    Show the answer

    Answer: c · Executing a database schema migration script once after a new deployment.

    The card states that the controller pattern is for maintaining a continuous state, and tasks that run once and terminate, like a database migration script, should use Kubernetes Jobs or CronJobs instead. Options A, B, and D all describe continuous state management, which is the core purpose of a controller.

    Read the full bite: Kubernetes Controllers: The Reconciliation Loop

14. Question 14 of 30

    What is the kube-scheduler's definitive action after selecting the best Node for a new Pod?

    • aIt modifies the Pod object in the API server by setting its .spec.nodeName field.
    • bIt reserves the required resources (CPU, memory) on the selected Node for the Pod.
    • cIt updates the Pod's status field to "Running" once the Node is confirmed.
    • dIt instructs the kubelet on the chosen Node to begin Pod initialization.
    Show the answer

    Answer: a · It modifies the Pod object in the API server by setting its .spec.nodeName field.

    The kube-scheduler's role is to assign a Pod to a Node by updating the Pod's .spec.nodeName field. It does not directly initiate Pod startup or reserve resources; those are subsequent actions handled by the kubelet on the assigned Node.

    Read the full bite: kube-scheduler: The Cluster's Matchmaker

15. Question 15 of 30

    Which statement best describes how the kube-controller-manager ensures the Kubernetes cluster's desired state?

    • aIt acts as the central API endpoint, receiving all declarative commands from users.
    • bIt bundles various control loops that continuously monitor the API server for resource state discrepancies and initiate corrective actions.
    • cIt is solely responsible for scheduling pods onto healthy nodes and managing their lifecycle.
    • dIt directly executes user-defined application logic to manage custom resources.
    Show the answer

    Answer: b · It bundles various control loops that continuously monitor the API server for resource state discrepancies and initiate corrective actions.

    Option B is correct because the kube-controller-manager is described as a single daemon bundling many independent control loops, each watching the API server for mismatches between desired and actual state and taking corrective action. Option A is incorrect as the API server is the central endpoint, not the controller manager.

    Read the full bite: kube-controller-manager: The Cluster's Reconciliation Engine

16. Question 16 of 30

    Why is setting CPU and memory limits equal to requests solely to achieve Guaranteed QoS considered an anti-pattern for a typical web server?

    • aIt causes the kubelet to evict the pod before BestEffort pods under node pressure
    • bIt ensures the pod will never be evicted, even if the node is truly out of memory
    • cIt guarantees faster CPU performance than Burstable pods
    • dIt removes burst capacity, potentially throttling CPU and causing OOM kills during spikes
    Show the answer

    Answer: d · It removes burst capacity, potentially throttling CPU and causing OOM kills during spikes

    The card warns that setting limits equal to requests to chase a Guaranteed badge throttles workloads during traffic spikes and can cause unnecessary OOM kills if the limit is too low. Option B is tempting because Guaranteed pods are evicted last, but they are still killed when the node is truly out of memory.

    Read the full bite: Pod QoS Classes: Guaranteed, Burstable, BestEffort

17. Question 17 of 30

    Which of the following scenarios is a Pod Disruption Budget (PDB) specifically designed to prevent or mitigate?

    • aAn application pod failing due to an unhandled exception and restarting.
    • bA node experiencing a sudden hardware failure, causing all its running pods to crash.
    • cA resource quota being exceeded, leading to new pod creation failures.
    • dA Kubernetes cluster upgrade process terminating too many application pods simultaneously.
    Show the answer

    Answer: d · A Kubernetes cluster upgrade process terminating too many application pods simultaneously.

    PDBs are designed to prevent self-inflicted outages during voluntary disruptions, such as those caused by planned cluster maintenance like node drains or upgrades, by ensuring a minimum number of application pods remain available. They do not protect against involuntary disruptions like node crashes or application-specific failures.

    Read the full bite: Pod Disruption Budgets: Stop Upgrades From Killing Your App

18. Question 18 of 30

    To maximize a stateless service's availability by spreading its replicas across different availability zones, while still ensuring pods can be scheduled even if perfect zone distribution isn't always achievable, which configuration is most appropriate?

    • apodAntiAffinity with requiredDuringSchedulingIgnoredDuringExecution and topologyKey: topology.kubernetes.io/zone
    • bpodAffinity with preferredDuringSchedulingIgnoredDuringExecution and topologyKey: topology.kubernetes.io/zone
    • cpodAntiAffinity with preferredDuringSchedulingIgnoredDuringExecution and topologyKey: topology.kubernetes.io/zone
    • dpodAntiAffinity with preferredDuringSchedulingIgnoredDuringExecution and topologyKey: kubernetes.io/hostname
    Show the answer

    Answer: c · podAntiAffinity with preferredDuringSchedulingIgnoredDuringExecution and topologyKey: topology.kubernetes.io/zone

    Option C correctly uses podAntiAffinity to spread pods for high availability across different availability zones (topology.kubernetes.io/zone). The 'preferred' type ensures schedulability even if the ideal distribution cannot be strictly met. Option A's 'required' rule would prevent scheduling if strict zone separation is impossible.

    Read the full bite: Pod Affinity: Grouping or Separating Your Pods

19. Question 19 of 30

    During a rolling update, 100 Pod IPs change for a Service with 3,000 endpoints. How does EndpointSlice mitigate the quadratic scalability problem?

    • aBy distributing watch connections across multiple API server instances to spread control plane load
    • bBy dividing endpoints across multiple smaller objects so only changed slices trigger watch events
    • cBy caching the full endpoint list in etcd and serving incremental diffs to watchers rather than full objects
    • dBy aggregating Pod IP changes into a single batched event sent to all watchers at a fixed interval
    Show the answer

    Answer: b · By dividing endpoints across multiple smaller objects so only changed slices trigger watch events

    EndpointSlice shards endpoints across multiple smaller objects, so only slices containing changed Pods are updated, bounding watch event size and avoiding the legacy Endpoints behavior of redistributing the entire list. Distractor A is tempting because diffing sounds efficient, but the card states the legacy API forces watchers to receive and process the entire object again on any change.

    Read the full bite: EndpointSlice: Splitting the Monolithic Endpoints List

20. Question 20 of 30

    What is the immediate effect on a pod's network traffic once it is selected by *any* Kubernetes NetworkPolicy?

    • aAll incoming and outgoing traffic to the pod is explicitly allowed by default, unless a specific rule denies it.
    • bOnly traffic explicitly permitted by the policy's rules is allowed; all other traffic, both incoming and outgoing, is blocked.
    • cOnly incoming traffic is affected, being blocked by default, while outgoing traffic remains unrestricted.
    • dThe pod's network traffic becomes entirely unrestricted, allowing communication with any other pod or external service.
    Show the answer

    Answer: b · Only traffic explicitly permitted by the policy's rules is allowed; all other traffic, both incoming and outgoing, is blocked.

    The card states, "If a pod is selected by any policy, it enters a 'deny-by-default' mode. Any traffic not explicitly allowed by a rule is dropped." This means only explicitly permitted traffic is allowed, making option B correct. Option A describes the opposite behavior, which is a common misconception about how NetworkPolicies enforce security.

    Read the full bite: Kubernetes NetworkPolicy: A Firewall for Pods

21. Question 21 of 30

    How does kube-proxy primarily enable Kubernetes Services to direct traffic to healthy pods?

    • aBy programming node-local network rules (iptables/IPVS) to forward packets to backend pods.
    • bBy acting as a DNS server, resolving Service names to individual pod IPs.
    • cBy maintaining a centralized load balancer that distributes traffic across all cluster nodes.
    • dBy inspecting application-layer headers to route requests based on URL paths.
    Show the answer

    Answer: a · By programming node-local network rules (iptables/IPVS) to forward packets to backend pods.

    kube-proxy's core function is to program the node's local networking stack (using iptables or IPVS) to translate a Service's virtual IP into the IP of a healthy backend pod. It is a Layer 4 packet forwarder and does not inspect Layer 7 application data, making option D incorrect.

    Read the full bite: kube-proxy: The Plumber for Kubernetes Services

22. Question 22 of 30

    What is the primary function of the External Secrets Operator (ESO) in a Kubernetes cluster?

    • aTo continuously synchronize secrets from an external secret management system into standard Kubernetes Secret objects.
    • bTo encrypt all native Kubernetes Secrets at rest and manage their lifecycle within the cluster.
    • cTo serve as a secure, in-cluster secret storage solution, replacing external secret managers.
    • dTo enable applications to directly retrieve secrets from external providers using a unified API.
    Show the answer

    Answer: a · To continuously synchronize secrets from an external secret management system into standard Kubernetes Secret objects.

    ESO's core function is to act as a 'courier,' fetching secrets from an external source of truth (like AWS Secrets Manager or Vault) and injecting them into native Kubernetes Secrets, keeping them in sync. It is explicitly stated that ESO is 'not a secret store itself,' making option C incorrect.

    Read the full bite: External Secrets Operator: Sync Secrets into Kubernetes

23. Question 23 of 30

    What makes a SealedSecret safe to store in a public Git repository?

    • aIt is encrypted using a public key, and only the cluster's private key can decrypt it.
    • bIt contains no sensitive data itself, only references to secrets stored in an external vault.
    • cIt is obfuscated, not truly encrypted, making it difficult for attackers to reverse engineer.
    • dIt can only be decrypted by the kubeseal tool, which requires specific authentication.
    Show the answer

    Answer: a · It is encrypted using a public key, and only the cluster's private key can decrypt it.

    Sealed Secrets uses asymmetric encryption; the public key encrypts the secret, and only the corresponding private key, held securely within the target Kubernetes cluster, can decrypt it. This cryptographic protection makes the encrypted SealedSecret safe to store publicly. The kubeseal tool is used for encryption, not decryption, and the SealedSecret itself contains the encrypted data, not just references.

    Read the full bite: Sealed Secrets: Safely Commit K8s Secrets to Git

24. Question 24 of 30

    Which CSI component is primarily responsible for translating a PersistentVolumeClaim into a request for a new volume from an external storage system?

    • aThe kubelet, by interacting with the CSI node plugin
    • bThe CSI node plugin, which runs on each worker node
    • cThe Kubernetes API server, after validating the PersistentVolumeClaim
    • dThe external-provisioner sidecar within a CSI controller plugin
    Show the answer

    Answer: d · The external-provisioner sidecar within a CSI controller plugin

    The external-provisioner sidecar, part of the CSI controller plugin, watches for new PersistentVolumeClaims and initiates the creation of the actual storage volume with the external system. The kubelet and CSI node plugin handle node-specific operations like mounting, while the Kubernetes API server accepts the PVC but does not directly provision storage.

    Read the full bite: Container Storage Interface (CSI): The Universal Adapter for K8s Storage

25. Question 25 of 30

    What is the primary reason Kubernetes Volume Snapshots are explicitly cautioned against being treated as a complete, disaster-proof backup solution?

    • aThey only capture the state of the PersistentVolume, not the application's runtime memory.
    • bThey cannot be used to restore data to a different Kubernetes cluster or cloud provider.
    • cThey require manual intervention to ensure application-level data consistency before creation.
    • dThey typically reside within the same storage system or availability zone as the original volume.
    Show the answer

    Answer: d · They typically reside within the same storage system or availability zone as the original volume.

    The card explicitly states that snapshots are not disaster-proof because they often reside in the same storage system or availability zone as the source volume, making them vulnerable to the same failures. While application consistency (option C) is a critical concern, it is distinct from the snapshot's resilience to a storage system's catastrophic failure, which is the focus of the 'disaster-proof' warning.

    Read the full bite: Kubernetes Volume Snapshots: A Save Point for Data

26. Question 26 of 30

    What is the primary mechanism by which Pod Priority ensures critical workloads run on a full Kubernetes node?

    • aIt instructs the scheduler to evict lower-priority pods to free up necessary resources.
    • bIt prevents any new low-priority pods from being scheduled on the node until space is available.
    • cIt reserves a dedicated portion of node resources exclusively for high-priority pods.
    • dIt triggers the automatic provisioning of new nodes to accommodate the critical workload.
    Show the answer

    Answer: a · It instructs the scheduler to evict lower-priority pods to free up necessary resources.

    The card explicitly states that when a high-priority pod needs space on a full node, the scheduler preempts (evicts) lower-priority pods to make room. Option C is incorrect because Pod Priority enables eviction, not resource reservation.

    Read the full bite: Pod Priority: Deciding Who Gets Evicted in Kubernetes

27. Question 27 of 30

    For a latency-sensitive, real-time application requiring predictable performance, which CPU management policy should be used on the Kubernetes node?

    • anone, as the default Linux scheduler provides optimal performance for all workloads.
    • bstatic, as it dedicates exclusive CPU cores to specific Guaranteed QoS pods.
    • cnone, as it efficiently shares CPU time across all pods for maximum density.
    • dstatic, as it allows fractional CPU requests to be efficiently allocated to shared pools.
    Show the answer

    Answer: b · static, as it dedicates exclusive CPU cores to specific Guaranteed QoS pods.

    The static policy is chosen for latency-sensitive applications because it dedicates exclusive CPU cores to Guaranteed QoS pods, eliminating jitter. The 'none' policy, while maximizing utilization, shares CPU time, making it unsuitable for real-time performance.

    Read the full bite: Kubernetes CPU Management: Static vs. None Policy

28. Question 28 of 30

    A cluster administrator needs to implement a highly specific pod placement strategy that goes beyond standard Kubernetes features. When would the Scheduler Framework be the most appropriate solution?

    • aTo simplify the configuration of basic node affinity and anti-affinity rules for common applications.
    • bTo enforce complex business rules for pod placement or enable advanced scheduling patterns like gang scheduling.
    • cTo replace the default kube-scheduler entirely with a custom-built scheduling engine.
    • dTo improve the overall performance and speed of pod scheduling for all types of workloads in the cluster.
    Show the answer

    Answer: b · To enforce complex business rules for pod placement or enable advanced scheduling patterns like gang scheduling.

    The card states the framework is for "implementing custom resource management, enforcing complex business rules... or enabling advanced scheduling patterns like gang scheduling" when default features are insufficient. It explicitly advises against using it for standard cases or to improve general performance, as it adds complexity and slow plugins can bottleneck the system.

    Read the full bite: Kubernetes Scheduler Framework: A Plugin System for Pod Placement

29. Question 29 of 30

    What is the primary security concern if a request fails to authenticate through any configured module in the Kubernetes API server?

    • aThe API server will always reject the request with a 401 error, causing service disruption.
    • bThe request will be re-routed to an external identity provider for secondary authentication.
    • cThe authentication chain will enter an infinite loop, consuming excessive API server resources.
    • dThe request might be processed as system:anonymous, potentially inheriting dangerous, broad permissions.
    Show the answer

    Answer: d · The request might be processed as system:anonymous, potentially inheriting dangerous, broad permissions.

    The card highlights that if no authenticator succeeds, a request can be treated as system:anonymous, and granting broad permissions to this user is a 'major risk' or 'footgun'. While a 401 rejection is possible, the critical security concern arises when the request is processed as system:anonymous with unintended privileges.

    Read the full bite: K8s Authentication: Proving Who You Are to the API Server

30. Question 30 of 30

    How does the Kubernetes API server determine authorization for a request when configured with Node,RBAC?

    • aThe request is denied if any module in the chain explicitly denies it, regardless of other modules' opinions.
    • bThe module with the most restrictive policy dictates the final authorization decision.
    • cThe request is allowed only if both the Node and RBAC modules explicitly grant access.
    • dIf the Node module allows the request, it's immediately granted; otherwise, the RBAC module's decision is considered.
    Show the answer

    Answer: d · If the Node module allows the request, it's immediately granted; otherwise, the RBAC module's decision is considered.

    The correct answer is B because the authorization chain processes modules in order, granting access immediately upon the first "allow" decision. If a module has "no opinion," the request proceeds to the next module in the chain. Option C is incorrect because it implies all modules must agree, which contradicts the "first allow" rule.

    Read the full bite: Kubernetes API Server Authorization Modules