Deploying a Kubernetes App on a New GKE Cluster
The development team has provided you with a Kubernetes Deployment file. You have no infrastructure yet and need to deploy the application. What should you do?
Community Insight
The test measures whether you know which tool provisions GKE infrastructure versus which tool drives an existing cluster; the trap is assuming Deployment Manager can apply a Kubernetes Deployment YAML, which it cannot.
When no infrastructure exists and a Kubernetes Deployment file is provided, the cluster must be provisioned first with the Google Cloud CLI (gcloud container clusters create) and the workload applied afterwards with kubectl. This question tests the correct division of labor between gcloud (GKE infrastructure provisioning) and kubectl (cluster workload management), and confirms that answer B is the standard workflow.
Option A is the most tempting wrong answer: learners reason that because we have a Deployment file, Deployment Manager should handle it. Deployment Manager provisions Google Cloud infrastructure templates, not Kubernetes resources inside a cluster — applying a Deployment manifest requires kubectl (or the GKE API via kubectl-compatible tooling).
Community Discussion (82 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
Option B matches the canonical GKE workflow. Because there is no infrastructure yet, the cluster must be created first, and the supported CLI for that isgcloud container clusters create <name> --zone <zone>, which provisions a managed control plane and node pools. Once the cluster exists and credentials are fetched, kubectl apply -f deployment.yaml (or kubectl create -f) submits the development team's Deployment manifest to the Kubernetes API server, exactly the mechanism the file was written for. Community members spell this out with real commands, e.g. "gcloud container clusters create my-cluster --zone us-central1-a" followed by "kubectl apply -f file.yml". This two-tool split is the officially documented deployment path for GKE.Why the Other Options Are Wrong
Option C and D are invalid because kubectl cannot create a GKE cluster: kubectl is a Kubernetes API client and only works once a cluster and an API endpoint already exist, so "Use kubectl to create a Kubernetes cluster" is impossible in this scenario. Option A uses the correct cluster-creation step but then points to Deployment Manager for the application deployment; Deployment Manager provisions Google Cloud resources from configuration templates (VMs, disks, networks), it does not apply Kubernetes workload manifests to a cluster. As one commenter noted, "Deployment Manager is used to automate the process of provisioning infrastructure," which overlaps with gcloud and still leaves kubectl as the only correct tool for the Deployment file. There is no option that mixes both tools correctly other than B.Community Comment Notes
The community is overwhelmingly and correctly aligned on B, with MeasService stating plainly "It has to be B. gcloud for creating cluster and kubectl for deploying." KouShikyou's question "May I ask why C is correct? I thought B was correct" reflects confusion worth addressing: C is wrong because kubectl cannot provision a GKE cluster. lynx256 asks why Deployment Manager cannot be used instead of kubectl in option A, and ghadxx's reply resolves it — Deployment Manager automates provisioning of infrastructure, not in-cluster Kubernetes objects. Multiple commenters supply working command sequences (gadxx's two-step, GtanNar's create/run/expose pipeline) that independently confirm B.Official Reference
Exam Strategy
When a question gives you no existing infrastructure, always look for the option that provisions the managed service with gcloud first, then performs the Kubernetes-specific action with kubectl. Eliminate any option where kubectl is asked to create a cluster — it is a client tool, not a provisioner.
Frequently Asked Questions
Why can't Deployment Manager apply the Kubernetes Deployment file (option A)?
Deployment Manager provisions Google Cloud infrastructure from templates (VMs, networks, disks); it does not create Kubernetes workload objects. A Deployment manifest must be submitted through kubectl against a running cluster's API server.
Why is 'Use kubectl to create a Kubernetes cluster' wrong in options C and D?
kubectl is a client for an existing Kubernetes API endpoint, so it cannot provision a GKE cluster. Creating a cluster on Google Cloud is done with gcloud container clusters create, the Console, or Terraform.
Related Analysis
Practice All PCA Questions
Access 81 questions with complete answers and detailed explanations.
View Full PCA Practice Test →