The city runs a general managed pool for web APIs and a separate GPU self-managed pool for model inference on one OKE cluster. What unit holds shape, image, subnet, and Kubernetes version for each capacity group?
Select an answer to reveal the explanation.
Short Explanation
A node pool is the capacity bucket: shape, image, subnet, and Kubernetes version live there. You can run more than one pool—general managed beside GPU self-managed—and aim workloads with labels and taints. That is cluster capacity design for developers, not a tenancy landing-zone exam.
Full Explanation
A node pool is the OKE capacity unit that carries shape, image, subnet, and Kubernetes version for a group of workers you scale and upgrade together. Running a general managed pool for web APIs beside a GPU self-managed pool for inference on one cluster is exactly multi-pool design: each pool holds its own capacity attributes, and workloads target them with labels, taints, and tolerations. An OCI tenancy landing zone document alone does not create cluster capacity. Landing zones guide tenancy layout; without cluster-side pool objects there are no workers with defined shapes and versions for Pods to schedule onto. A single cluster-wide ConfigMap cannot override every worker shape at once. Worker shape and image are pool/instance properties managed through OKE node pool APIs, not ConfigMap keys the kubelet treats as shape selectors for the whole cluster. Deployment replica count only asks for more Pods; it does not select worker images or define GPU versus CPU capacity pools. Replicas without suitable node pools just Pending. Exam caveat: multiple pools share one control plane but isolate capacity characteristics—mislabeling nodes or omitting taints can place GPU jobs on CPU pools or vice versa. Operational check: list node pools and their shapes/images, confirm web Deployments tolerate/select the managed pool and inference Pods bind to the GPU pool, and scale each pool independently without resizing the other.