An OKE cluster for a municipal GIS team was created with a private Kubernetes API endpoint only. What does that imply for how developers run kubectl?
Select an answer to reveal the explanation.
Short Explanation
A private API endpoint is like a locked office phone: it always has a number on your subnet, but you need a badge path—bastion, VPN, or Cloud Shell—to dial in. kubectl still works once that path exists.
Full Explanation
When a municipal GIS OKE cluster is created with a private Kubernetes API endpoint only, developers must still reach that private IP through a path they provide—bastion host, VPN, or Cloud Shell connectivity into the subnet. OKE places the API on a subnet you name; private-only means there is no public API address, so kubectl works only after your workstation or jump path can route to that private endpoint. The control plane is reachable; the network path is your responsibility.
Claiming kubectl is disabled and only the OCI Console can manage workloads fails by concept because kubectl remains the Kubernetes client—privacy of the endpoint is a network property, not a console-only lockout. Saying the API server moves to a different region automatically fails because private versus public endpoint choice does not relocate the cluster’s region. Asserting that public internet clients can reach the API without a path into the VCN fails because that would contradict private-only endpoint semantics; unauthenticated internet reachability is exactly what you opted out of.
Exam caveat: private endpoint still requires correct security lists/NSGs, DNS resolution for the API FQDN, and credentials—network path alone is not authorization. Operational check: from an authorized bastion or VPN session, resolve the cluster API hostname, run kubectl get ns, and confirm failure from an unrouted public laptop so the GIS team documents the required access path.