Exam Pointers

The Kubernetes Special Interest Groups (SIGs) are groups within the Kubernetes community that focus on specific areas such as architecture, networking, and storage. The SIG for certification does not exist within the official Kubernetes SIG structure, making it an invalid option in this context.

Pod affinity allows us to set priorities for which nodes to place our pods based on the attributes of other pods running on those nodes. This works well for grouping pods together in the same node.

Pod Anti-Affinity is used to prevent pods from being scheduled on the same node, which helps in promoting fault tolerance and reliability. By spreading pods across different nodes, the system becomes more resilient to node failures and ensures that critical services remain available.

Open Policy Agent (OPA) is commonly used in Kubernetes clusters to enforce custom policies and governance on Kubernetes objects. It allows administrators to define and enforce policies for resource access control, security, compliance, and other governance requirements within the cluster.

DevOps Engineers are responsible for bridging the gap between development and operations teams. They need to have experience with programming languages to automate processes and improve efficiency, as well as operational tools for deployment, monitoring, and logging to ensure the reliability and performance of applications in production environments.

Scheduler Profiles in Kubernetes are used to define custom scheduling rules and configure different stages of scheduling in the kube-scheduler. This allows you to tailor the scheduling behavior based on the specific needs of different user groups within the cluster.

Nodes in a Kubernetes cluster are responsible for running workloads and applications. They are the worker machines where containers are deployed and executed.

In Kubernetes, a "Job" is a resource used to manage short-lived, batch-processing tasks. It ensures that a specified number of pods successfully complete their tasks and then terminates once the tasks are completed. This makes it ideal for running tasks like data processing, backups, or batch jobs.

Pod topology spread constraints in Kubernetes allow users to define rules for how pods should be spread across different zones, such as physical nodes. By setting up these constraints, the scheduler can ensure that the application is distributed evenly across fault zones, improving resilience and fault tolerance.

Static pods are created by the local kubelet running on each node, without the involvement of the kube-api server. This means that static pods are directly managed by the kubelet on the node where they are running, providing a simple and lightweight way to deploy pods on individual nodes.

When the Kubernetes control plane becomes unavailable, the existing pods on the cluster will continue to run without interruption. This is because the control plane is responsible for managing the cluster's state and resources, but once the pods are scheduled and running on the worker nodes, they can continue to operate independently.

Node selectors in Kubernetes are limited in their ability to handle complex node selection criteria, as they can only match nodes based on a single label key-value pair. This limitation makes it challenging to implement more intricate scheduling requirements for pods.

The Kubernetes Steering Committee is the correct choice as it is the collective group of individuals responsible for overseeing the overall direction of the Kubernetes project within the Cloud Native Computing Foundation (CNCF). They make decisions related to project governance, community management, and technical direction.

The directory /etc/kubernetes/manifests is the well-known local directory that kubelet periodically checks to deploy and manage static pods. Static pods are defined by static PodSpec files placed in this directory, allowing kubelet to manage them without the need for a Kubernetes API server.

Spread constraints in Kubernetes are used to distribute pods of a specific service evenly across all nodes in the cluster. This helps improve load balancing by ensuring that the workload is evenly distributed and no single node is overwhelmed with pods, leading to better resource utilization and performance.

Implementing an external identity provider, such as LDAP or OIDC, is a common practice to manage user authentication and access in a Kubernetes cluster. This allows users to authenticate against their existing credentials stored in the external identity provider, reducing the need to manage user accounts directly within the Kubernetes cluster.

The CNCF created the GitOps Working Group to oversee and define GitOps practices in a vendor-neutral manner. This group focuses specifically on GitOps principles and best practices within the cloud-native ecosystem.

Filtering and Scoring are the two phases used to determine the best node to assign a pod during scheduling in Kubernetes. Filtering involves selecting nodes that meet the pod's resource requirements, constraints, and other criteria. Scoring then ranks the filtered nodes based on various factors, such as resource availability, node capacity, and user-defined preferences, to select the best node for the pod.

A pull-based system like Prometheus does not simplify the configuration of an event-based system for monitoring events. In fact, pull-based systems are more focused on collecting metrics from targets at regular intervals, rather than reacting to specific events in real-time.

When an API is updated to version 1 (v1), it is considered to be in the stable stage of development. At this stage, the API is considered to be mature, reliable, and ready for production use without major changes expected.

Kubernetes follows a release cycle of approximately every four months, resulting in three major releases per year. This regular release cadence allows for the introduction of new features, enhancements, and bug fixes to the Kubernetes platform at a predictable interval. Each week, a new patch version is released.

Taints are indeed set on nodes using the kubectl command. This allows you to mark nodes with specific characteristics that affect which pods can be scheduled on them.

Tolerations are added to the pod definition file to specify which pods can tolerate which taints. By defining the key, value, operator, and effect in the pod definition file, you can control which pods can be scheduled on tainted nodes.

The OCI image spec standard defines the structure, format, and metadata of container images used in containerization technologies like Docker and Kubernetes

The Kubernetes API server is essential for managing and interacting with the Kubernetes cluster. When performing a rolling update of a deployment using kubectl, the API server must be available to receive and process the update commands, ensuring the successful execution of the update process.

Taints and Tolerations in Kubernetes are used to repel a set of pods from a node based on certain criteria, such as hardware requirements or specific workloads. On the other hand, Node Affinity is used to attract pods to a set of nodes based on labels or other node attributes. This fundamental difference allows for precise control over pod placement in the cluster.

The default storage of Secrets in etcd is not encrypted by default. This means that anyone with access to etcd or the cluster can potentially read or modify the Secrets, leading to unauthorized access to sensitive information.

Jenkins X is a GitOps tool that provides a complete set of CI/CD capabilities, including image building, preview environments, and deployment to Kubernetes. It is specifically designed for cloud-native applications and integrates seamlessly with Kubernetes clusters, making it a suitable choice for managing the entire software delivery process.

Changing the effect of the taint to NoExecute will ensure that existing non-production workloads on Node1 and Node2 are evicted immediately.