✅ Correct Answer:

B. kube-scheduler

Explanation:

The kube-scheduler is the control plane component responsible for assigning pods to nodes in a Kubernetes cluster. It decides which node is the best fit for a pod based on several factors like:

• Resource availability (CPU, memory)

• Node taints and tolerations

• Affinity and anti-affinity rules

• Pod priority

• Custom scheduling policies

Once a pod is scheduled to a node, the kubelet on that node picks it up and starts it.

❌ Why the Other Options Are Incorrect:

• A. kube-proxy

  • Handles network routing and load balancing of services on each node. It is not involved in scheduling.

• C. kubelet

  • Runs on each node and executes the pod assigned by the scheduler, but does not schedule pods.

• D. kube-apiserver

  • The front-end for the Kubernetes control plane. It receives and processes REST API calls, but it does not make scheduling decisions.

✅ Correct Answer:

B. Declarative

Explanation:

• Declarative style means you describe the desired state of the system (e.g., "I want 3 replicas of this app running"), and Kubernetes automatically works to maintain that state.

• This approach is more reliable, scalable, and easier to manage for cloud-native apps because Kubernetes constantly monitors and reconciles the actual state with the desired state.

❌ Why the Other Options Are Incorrect:

• A. JSON

  • JSON is a data format used to express configurations or communicate with APIs, not an operational style.

• C. Imperative

  • Imperative operations involve manually running commands to change system state step-by-step (e.g., kubectl scale deployment).

  • While still used, imperative operations are less scalable and less preferred compared to declarative in modern Kubernetes workflows.

The correct answer is:

✅ C. Isolation

✅ Explanation: Control Groups (cgroups) and Isolation

Control Groups, or cgroups, are a Linux kernel feature used by container runtimes (like Docker or containerd) and Kubernetes to:

• Limit resources (CPU, memory, disk I/O, etc.)

• Prioritize workloads

• Account for resource usage

• Isolate containers from each other in terms of resource access

This helps ensure that one container doesn’t consume all the resources and affect the performance or stability of other containers on the same host.

So, cgroups provide isolation at the resource level — a core feature that makes containerization effective.

❌ Incorrect Options:

• A. Permission

  • Permissions (like file access and user roles) are handled by Linux user/group permissions or security modules like AppArmor and SELinux, not cgroups.

• B. Image Storage

  • Image storage is managed by container runtimes and container registries, not by cgroups.

• D. Logging

  • Logging is typically handled by the application, sidecar containers, or node-level agents — not by cgroups.

✅ Correct Answer:

B. Kubernetes RBAC states which users can perform which actions against which resource

Explanation:

Kubernetes RBAC is a authorization mechanism that defines who (which users or groups) can perform what actions (verbs like get, list, create, delete) on which resources (pods, services, deployments, etc.) within the cluster.

• It controls permissions by creating Roles and ClusterRoles that specify allowed actions on resources.

• These Roles are then bound to users or groups via RoleBindings or ClusterRoleBindings.

❌ Why the Other Options Are Incorrect:

• A. Kubernetes does not do RBAC

  • This is false; RBAC is a core Kubernetes feature and widely used for authorization.

• C. Kubernetes RBAC lists which operations on which resources are denied to users

  • RBAC is allow-based, meaning it explicitly grants permissions rather than denying them.

• D. Kubernetes RBAC is responsible for authenticating subjects such as users and groups

  • Authentication (verifying identity) is handled by other mechanisms like certificates, OpenID Connect, or OAuth.

  • RBAC is about authorization (what an authenticated user is allowed to do).

✅ Correct Answer:

A. Kubernetes API

Explanation:

The Kubernetes API is the primary interface used to communicate with and control a Kubernetes cluster. It allows:

• Users (via kubectl or clients)

• System components (like controllers and schedulers)

• External tools (like CI/CD systems or monitoring platforms)

...to interact with the cluster by sending HTTP requests (usually in JSON format) to create, update, retrieve, or delete Kubernetes resources such as pods, deployments, services, and more.

Everything in Kubernetes is a resource managed through its API server, which is the entry point to the Kubernetes control plane.

❌ Why the Other Options Are Incorrect:

• B. Kubelet

  • An agent that runs on each node and communicates with the API server, but it's not the main interface for interacting with the cluster — it’s a worker component.

• C. YAML

  • YAML is a configuration file format used to define Kubernetes objects, but it’s not an interface. YAML files are submitted through the API (often via kubectl).

• D. Control Plane

  • The control plane is a set of components (API server, scheduler, etc.) that manage the cluster. The API is part of the control plane, but “control plane” is not the interface itself.

• E. JSON

  • Like YAML, JSON is a data format. The API supports JSON input/output, but again, it's not the interface — the API is.

The correct answer is:

✅ A. Sidecar container logging

✅ Explanation: Sidecar Container Logging

This is a design pattern in Kubernetes where you run a second container alongside your main application container in the same Pod. This second container is responsible for handling logging tasks — such as collecting, processing, or forwarding logs from the main application.

The sidecar container shares the network and storage with the main container, so it can easily access application logs and perform tasks like:

• Log shipping to a central logging system (e.g., ELK, Fluentd, etc.)

• Real-time log analysis

• Log rotation and compression

This is part of the broader sidecar pattern, commonly used in cloud-native environments.

❌ B. Node level logging

• In node-level logging, logs are collected at the node (VM or physical server) level, often using an agent like Fluentd or Logstash that gathers logs from all pods on that node.

• This is a broader approach than sidecar logging and doesn’t involve adding a container inside each pod.

❌ C. Application level logging

• This refers to the application itself handling logging (e.g., writing logs to stdout or a file).

• It’s a log generation strategy, not a collection pattern like the sidecar.

❌ D. Cluster level logging

• This involves collecting and managing logs across the entire Kubernetes cluster, typically by aggregating logs from all nodes.

• Tools like Elasticsearch, Fluentd, Kibana (EFK) stack or Loki + Grafana are used.

• Again, this is more centralized and not related to adding a container per pod.

✅ Correct Answer:

D. Load Balancing AutoScaler

Explanation:

Kubernetes provides several autoscaling strategies to automatically adjust resources based on workload demand:

✅ Valid Kubernetes Autoscaling Strategies:

1. Horizontal Pod Autoscaler (HPA)

   • Automatically increases or decreases the number of pod replicas based on metrics like CPU usage or custom metrics.

   • Commonly used for scaling stateless applications.

2. Vertical Pod Autoscaler (VPA)

   • Adjusts the CPU and memory requests/limits for individual pods.

   • Useful for optimizing resource usage for stateful or monolithic apps.

3. Cluster Autoscaler

   • Automatically adds or removes nodes in a cluster based on the scheduling needs of pods.

   • Works with cloud providers like AWS, GCP, and Azure.

❌ Incorrect Option:

• D. Load Balancing AutoScaler

  • This is not a recognized Kubernetes autoscaling strategy.

  • Load balancing is handled by Kubernetes Services (e.g., ClusterIP, NodePort, LoadBalancer) or Ingress, but it is not tied directly to an autoscaler.

  • There is no built-in "Load Balancing AutoScaler" in Kubernetes.

✅ Correct Answer:

A. kubectl get pods -o json

Explanation:

• The -o (or --output) flag specifies the output format for the kubectl get command.

• Using -o json outputs the full pod data in JSON format.

❌ Why the Other Options Are Incorrect:

• B. kubectl get pods --all-namespaces

  • Lists pods from all namespaces, but output format defaults to a table, not JSON.

• C. kubectl get pods -o wide

  • Provides more details than default, but still outputs in a human-readable table format, not JSON.

• D. kubectl get pods -o jsonpath

  • Outputs based on a custom JSONPath template, used for extracting specific fields, not the full JSON data.

✅ Correct Answer: A. Cloud Native Computing Foundation

The Cloud Native Computing Foundation (CNCF) is an open-source software foundation under the Linux Foundation. It was established in 2015 to promote the development and adoption of cloud-native technologies. These technologies are designed to help organizations build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds.

Key technologies hosted by CNCF include:

• Kubernetes (container orchestration)

• Prometheus (monitoring)

• Envoy (service proxy)

• Helm (Kubernetes package manager)

• And many others

The CNCF provides:

• Vendor-neutral governance

• Certifications (like CKA, CKAD)

• Community support and events (like KubeCon)

❌ Incorrect Answer: B. Cloud Native Cloud Foundation

This is not a real organization. The phrase is redundant and incorrect — it repeats "cloud" unnecessarily. "Cloud Native Cloud Foundation" sounds awkward and does not refer to any existing or recognized group in the tech industry.

❌ Incorrect Answer: C. Cloud Native Container Foundation

While this might sound plausible because CNCF deals with containers (like Docker and Kubernetes), it's not the correct name. The CNCF's scope is broader than just containers — it covers the entire ecosystem needed for cloud-native computing, including service meshes, observability, CI/CD, and storage.

✅ Correct Answer:

D. Container Image

Explanation:

A container image is a lightweight, standalone, executable package that includes everything needed to run a piece of software, such as:

• The application code

• Runtime environment

• Libraries and dependencies

• Configuration files

Once a container image is created, it can be used to launch one or more containers, which are isolated environments that run from the image.

❌ Why the Other Options Are Incorrect:

• A. Container Repository

  • A container repository (like Docker Hub or Amazon ECR) is a storage location where container images are stored and shared. It does not contain the app itself in a runnable form — it hosts the images.

• B. Container Runtime

  • A container runtime (e.g., containerd, runc) is the software that executes the container image on the host system. It doesn't contain the application but rather runs the container based on an image.

• C. Docker

  • Docker is a platform/toolset that uses container images and runtimes to build, ship, and run containers. It is not itself a ready-to-run software package.