A seasonal parks ticket burst should scale Pods with HPA without patching worker instances or babysitting pool capacity. Which OKE node type fits?
Select an answer to reveal the explanation.
Short Explanation
Virtual nodes are the serverless data plane: no worker VM patching, no capacity babysitting, Pods scale with HPA. They need VCN-native pod networking and do not support instance-principal patterns that assume a worker VM—plan IAM accordingly.
Full Explanation
Virtual nodes provide a serverless Kubernetes data plane: Pods scale with HPA without the team patching worker instances or babysitting managed-pool capacity. For a seasonal parks ticket burst, that matches 'scale Pods, skip worker VM ops.' Virtual pools need compatible cluster networking (VCN-native) and an enhanced feature set that unlocks them. Self-managed GPU nodes are a specialty path for custom hardware, not the default for every public HTTP service and not aligned with avoiding worker management for a seasonal burst. Claiming managed nodes only because virtual nodes forbid HPA is false. Virtual nodes are specifically useful with HPA-scaled Deployments; forbidding HPA is not the reason to avoid them. Flannel overlay on managed nodes is a CNI/network choice, not a serverless node type. Virtual nodes require VCN-native networking rather than flannel exclusively—the distractor reverses the networking constraint. Exam caveat: virtual nodes do not support every workload pattern (for example hostPorts, some daemon-style needs, or instance-principal assumptions tied to worker VMs)—validate workload identity and networking before migrating parks tickets entirely. Operational check: confirm the cluster is enhanced with VCN-native networking, deploy onto a virtual node pool, load-test HPA scale-out during a burst simulation, and verify no worker VM patching workflow is required for that pool.