Advanced Docker & Kubernetes test (Advanced)
40 questions · 40 minutes · Free
Scheduling, networking, operators, security and Helm in production.
Take the Advanced Docker & Kubernetes test
What it covers
- Scheduling, affinity and taints
- Services, ingress and CNI
- RBAC and pod security
- Helm and operators
- Autoscaling and troubleshooting
Interview format
- Questions: 40 questions — 24 multiple choice, 16 multi-answer
- Time: 40 minutes, timed from the first question
- Difficulty: Advanced
- Skill area: DevOps & cloud
- Price: Free
Earn a certificate
The Advanced Docker & Kubernetes test is one of the 8 tests of the Backend Developer: Advanced learning path. Pass it and the other 7 tests at 70% or more and readyforhires issues you a verifiable certificate in your name, with its own code and verify link to share or add to LinkedIn.
Sample questions
5 sample questions from the Advanced Docker & Kubernetes test, with the answers. Samples are taken out of the live test, so you will not meet these when you sit it.
A pod is not being scheduled on a node despite meeting the node affinity rules. What is the most likely reason for this behavior?
- The pod is not being scheduled because the node does not have enough resources.
- The pod is not being scheduled because the node is in a different availability zone.
- The pod is not being scheduled because the node has a taint that is not tolerated by the pod.
- The pod is not being scheduled because the node has a label that is not matched by the pod's node selector.
Answer: C. The pod is not being scheduled because the node has a taint that is not tolerated by the pod.
Sticky scheduling behavior refers to the persistence of pod placement on a node due to affinity rules or taints. In this case, if a pod is not being scheduled despite meeting node affinity rules, the most likely issue is that the node has a taint that is not being tolerated by the pod. Taints prevent pods from being scheduled on a node unless they have a corresponding toleration. This is a common scenario where sticky scheduling behavior can lead to unexpected pod placement issues.
Which of the following statements accurately describes how the Horizontal Pod Autoscaler (HPA) determines the number of pods to scale?
- The Horizontal Pod Autoscaler (HPA) uses metrics from the kube-proxy to determine the number of pods to scale.
- The Horizontal Pod Autoscaler (HPA) uses metrics collected by the kubelet to determine the number of pods to scale.
- The Horizontal Pod Autoscaler (HPA) uses metrics from the metrics server to determine the number of pods to scale.
- The Horizontal Pod Autoscaler (HPA) uses metrics from the kube-scheduler to determine the number of pods to scale.
Answer: C. The Horizontal Pod Autoscaler (HPA) uses metrics from the metrics server to determine the number of pods to scale.
The Horizontal Pod Autoscaler (HPA) relies on metrics collected by the metrics server to evaluate the load on the application and scale the number of pods accordingly. Other options may be misleading as they refer to incorrect sources of metrics (e.g., kubelet, kube-proxy, or other components that are not responsible for providing metrics to HPA).
In a Kubernetes cluster, what is the best practice for setting the ClusterIP range to avoid overlapping with other services in the cluster?
- The ClusterIP range should be set to 172.16.0.0/12 to avoid overlapping with other services in the cluster.
- The ClusterIP range should be set to 10.255.0.0/16 to avoid overlapping with other services in the cluster.
- The ClusterIP range should be set to 10.0.0.0/16 to avoid overlapping with other services in the cluster.
- The ClusterIP range should be set to 192.168.0.0/16 to avoid overlapping with other services in the cluster.
Answer: C. The ClusterIP range should be set to 10.0.0.0/16 to avoid overlapping with other services in the cluster.
In Kubernetes, the ClusterIP range is typically set to a private IP range that does not overlap with other services or networks in the cluster. Using 10.0.0.0/16 is a common choice because it ensures that the ClusterIP addresses are unique within the cluster and do not conflict with other network ranges. Using a public IP range like 192.168.0.0/16 or 172.16.0.0/12 would lead to conflicts with other internal networks, while using a dynamic range like 10.255.0.0/16 could lead to inefficiencies and potential IP exhaustion.
In a production Kubernetes environment, you are configuring the Horizontal Pod Autoscaler (HPA) to monitor CPU utilization for a deployment. Which of the following statements accurately describes the HPA metrics collection interval?
- The HPA metrics collection interval is controlled by the metrics-server component, and defaults to 60 seconds.
- The HPA metrics collection interval is configured via the --horizontal-pod-autoscaler-cadvisor-namespace flag, but it defaults to 15 seconds.
- The HPA metrics collection interval is configured via the --horizontal-pod-autoscaler-metrics-interval flag, and defaults to 30 seconds.
- The HPA metrics collection interval is determined by the kube-controller-manager, and defaults to 5 seconds.
Answer: B. The HPA metrics collection interval is configured via the --horizontal-pod-autoscaler-cadvisor-namespace flag, but it defaults to 15 seconds.
The HPA metrics collection interval is determined by the --horizontal-pod-autoscaler-cadvisor-namespace flag, and if not specified, it defaults to 15 seconds. The other options are either incorrect or describe unrelated aspects of HPA behavior.
Which of the following statements best describes the role of Operator Lifecycle Manager (OLM) in a Kubernetes cluster?
- OLM is responsible for generating Helm charts for Kubernetes applications.
- OLM is used to enforce Pod Security Policies across a Kubernetes cluster.
- OLM is a plugin for the Kubernetes scheduler used to manage resource allocation for Operators.
- Operator Lifecycle Manager (OLM) is used to manage the deployment and upgrades of Operators in a Kubernetes cluster.
Answer: D. Operator Lifecycle Manager (OLM) is used to manage the deployment and upgrades of Operators in a Kubernetes cluster.
Operator Lifecycle Manager (OLM) is a Kubernetes component that enables the deployment, management, and upgrading of Operators, which are custom controllers that manage complex applications on Kubernetes. It provides a standard way to package Operators as OperatorsHub bundles, and ensures their lifecycle is managed consistently across the cluster. The other options are either unrelated to OLM or describe incorrect usage.
Frequently asked questions
- How many questions are in the Advanced Docker & Kubernetes test?
- 40 questions (24 multiple choice, 16 multi-answer), with 40 minutes to answer them.
- What does the Advanced Docker & Kubernetes test cover?
- Scheduling, affinity and taints, Services, ingress and CNI, RBAC and pod security, Helm and operators, Autoscaling and troubleshooting.
- Is the Advanced Docker & Kubernetes test free?
- Yes. It is free to take with a readyforhires account.
- What level is the Advanced Docker & Kubernetes test?
- Advanced, in DevOps & cloud.