The city platform team wants virtual nodes, workload identity, and node cycling on their OKE cluster. Which cluster type unlocks those developer features?
Select an answer to reveal the explanation.
Short Explanation
Enhanced versus basic is a feature gate, not a logo. Virtual nodes, granular add-ons, workload identity, node cycling, self-managed nodes, larger scale, and an API-server SLA need enhanced. You can upgrade basic→enhanced when the cluster is VCN-native; you cannot downgrade.
Full Explanation
An enhanced cluster is the OKE cluster type that gates developer features such as virtual nodes, workload identity, node cycling, and related capabilities the city platform team listed. Choosing enhanced unlocks those options (subject to networking and add-on prerequisites); basic clusters intentionally offer a smaller feature set. Basic clusters only is wrong because enhanced is what adds—not removes—virtual nodes and related features. Selecting basic blocks the requested capabilities. Starting from a basic cluster without VCN-native networking and planning to downgrade from enhanced later fails on multiple counts: virtual nodes need VCN-native, and enhanced-to-basic downgrade is not the supported direction. Upgrade basic to enhanced when prerequisites allow; do not design around downgrade. Cloud Guard detector recipes are security posture tooling, not an OKE cluster type. Renaming a recipe does not create enhanced cluster features. Exam caveat: some enhanced features still require VCN-native pod networking and correct IAM; enabling enhanced alone without meeting networking prerequisites will not surface virtual node pools. Operational check: verify cluster type is enhanced in the console or CLI, confirm VCN-native networking where required, and validate that virtual node pool creation, workload identity configuration, and node cycling options are available before committing platform standards.