GCP Engineer interview questions

I would start with Autopilot because the workloads fit its managed operating model and do not need node-level control.

• Google manages nodes, scaling, and many security defaults, but I would still validate required DaemonSets and admission policies against Autopilot restrictions.
• General-purpose workloads on the default Autopilot platform or Balanced and Scale-Out ComputeClasses use Pod-based billing from resource requests, so I would right-size those requests.
• Workloads that select specific machine series or accelerators use node-based billing for whole nodes plus an Autopilot management premium.
• I would choose Standard for privileged host access, specialized node configuration, or tighter control over upgrade timing.

I would use a regional GKE cluster with worker nodes spread across at least three zones.

• The control plane is replicated across zones, so a single zonal failure does not remove Kubernetes API availability.
• I would size node pools so the remaining zones can run critical requests after one zone is unavailable.
• Regional node counts and quotas can multiply across zones, so I would verify the actual total nodes and cost before creation.
• Workloads would also use topology spread constraints and replicated storage that matches the availability requirement.

I would separate these workload classes into node pools with explicit labels, taints, and tolerations.

• A small on-demand system pool would host DNS, metrics, and controllers so batch pressure cannot evict cluster services.
• Regular APIs would use a general-purpose on-demand pool sized for their CPU and memory profile.
• Batch jobs would tolerate a Spot VM pool and handle termination, gaining lower cost without weakening API availability.
• Each pool would have independent autoscaling bounds, upgrade settings, and machine types so one policy does not fit every workload.

I would derive initial requests from load tests and observed percentiles, then refine them with production metrics.

• Requests must cover normal CPU and memory use because the scheduler and cluster autoscaler make placement decisions from them.
• I would set a memory limit above the working set to contain leaks, knowing that crossing it causes an OOM kill.
• I would avoid a tight CPU limit for a latency-sensitive API because CFS throttling can hurt response time even when nodes have spare CPU.
• I would alert on throttling, OOM kills, and the request-to-usage ratio before changing values.

I would let HPA change replica count from traffic signals and use VPA initially in recommendation mode for right-sizing.

• HPA could target CPU utilization plus an external queue-depth metric so it reacts before requests accumulate.
• CPU percentage is measured against CPU requests, so unrealistic requests would also make HPA behavior unrealistic.
• I would not let VPA automatically change the same CPU or memory resource that HPA uses, because the two control loops can fight.
• After observing recommendations, I would update requests through deployment changes or use VPA only for a resource that HPA does not target.

I would set per-pool minimum and maximum nodes from failure capacity, quotas, and the largest pod shape.

• Cluster autoscaler adds nodes only when pods are unschedulable from their requests, not merely when average node CPU is high.
• The pool must offer a machine type that fits the largest pod, or replicas can remain pending even below the maximum node count.
• I would keep a small amount of headroom or use overprovisioning pods when node startup latency is too slow for the burst.
• Scale-down settings must respect PDBs and long-running jobs so savings do not cause avoidable disruption.

I would combine a PodDisruptionBudget with topology spread constraints across zones and nodes.

• A PDB with maxUnavailable: 1 preserves two replicas during voluntary disruptions such as node drains.
• A zone constraint with maxSkew: 1 prevents all replicas from landing in one failure domain.
• A hostname constraint reduces the chance that two replicas share the same node.
• I would verify there is spare capacity, because a strict PDB protects availability but can block a drain when replacement pods cannot schedule.

I would use Workload Identity Federation for GKE and bind the Kubernetes workload to a least-privileged IAM identity.

• The pod receives short-lived credentials through the GKE metadata path instead of mounting a JSON key.
• I would grant only objectViewer on the required bucket, not a project-wide storage role.
• The Kubernetes namespace and service account would be dedicated to that workload to keep the principal boundary clear.
• I would test the binding from the pod and ensure legacy metadata access or key secrets are not left as fallback credentials.

I would apply default-deny ingress and egress NetworkPolicies, then add narrow allow policies for those paths.

• Pod and namespace labels would select the API and internal service rather than relying on changing pod IP addresses.
• A specific egress rule would allow kube-dns on UDP and TCP 53 so name resolution still works.
• Cloud SQL access would be limited to the connector or private endpoint path and required port.
• I would use GKE Dataplane V2 enforcement and remember that VPC firewall rules still govern traffic outside the cluster.

I would choose Gateway API because it separates load-balancer ownership from per-application routing more cleanly.

• The platform team can own Gateway and TLS policy while application teams attach namespace-scoped HTTPRoutes.
• Route attachment rules make cross-namespace delegation explicit instead of sharing one large Ingress object.
• I would still use GKE Ingress for a simple existing application whose supported annotations already meet every requirement.
• Before migration I would compare the exact GKE GatewayClass features, certificates, redirects, and backend policies we need.

I would promote one immutable image digest through environments instead of rebuilding per environment.

• Cloud Build would push to a regional Docker repository near the runtimes and record the sha256 digest.
• Deployment manifests would reference that digest, so moving a tag cannot silently change production.
• Writer access would belong only to build identities, while runtime identities receive repository reader access.
• Cleanup policies would retain released and recently used images while deleting old untagged build artifacts.

I would enforce Binary Authorization with attestations produced only after the approved build and security checks pass.

• The pipeline would sign the image digest, not a mutable tag, using a protected attestor key.
• The production policy would require that attestation and allow only explicitly approved registries.
• I would first run the policy in audit mode to identify system images and legitimate exceptions before enforcement.
• Break-glass deployment would require a controlled reason, narrow IAM access, and an audit review rather than a permanent bypass.

I would use Helm for reusable application packaging and Kustomize for small environment overlays when both add clear value.

• A Helm chart fits repeated objects, optional components, and versioned releases consumed by several teams.
• Kustomize fits patches such as replica counts, project names, and Gateway references without turning every field into a template value.
• If the application is simple, I would choose one tool because layered rendering makes the final manifest harder to review.
• CI would render every environment and validate the resulting YAML before Argo CD or Cloud Deploy receives it.

I would use a regional Cloud Build private pool connected to the VPC that hosts the private dependencies.

• The pool's network path and firewall rules would allow only the repository, package mirror, Artifact Registry, and required Google APIs.
• If public dependencies are required, I would mirror them or use an approved proxy because disabling worker external IPs removes direct internet access.
• The build service account would have narrow artifact and logging roles, with no broad project Editor permission.
• I would size worker machines and pool concurrency from measured build demand because private pool capacity has direct cost.

I would define a Cloud Deploy delivery pipeline with a canary strategy and explicit approval before full rollout.

• Skaffold would render the same release artifact for the target, avoiding a rebuild between percentages.
• The canary phases would shift 10%, then 30%, then 100% through supported GKE service networking.
• Verification jobs would compare error rate and latency against the stable version at each phase.
• A verification failure stops advancement but does not itself restore stable traffic, so I would trigger an explicit rollback or configure Cloud Deploy repair automation to do so under defined criteria.

I would make Git the desired-state source and give Argo CD only the cluster permissions needed for its assigned namespaces.

• Separate Argo CD projects would restrict allowed repositories, destinations, namespaces, and resource kinds for each team.
• Protected branches and reviewed pull requests would gate production changes before reconciliation.
• Auto-sync could handle low-risk environments, while production uses sync windows or explicit promotion according to policy.
• Drift would be visible in Argo CD, and emergency manual changes would either be reverted or immediately captured back in Git.

I would keep environment configuration outside the image and render versioned ConfigMaps through the deployment pipeline.

• The same image digest would move through dev and production while overlays supply endpoints, flags, and resource settings.
• A checksum of the ConfigMap would be placed on the pod template so a changed config triggers a controlled rollout.
• Large or frequently changing configuration would use a dedicated configuration service or mounted file rather than hundreds of environment variables.
• Schema validation in CI would reject missing keys and invalid values before Kubernetes accepts the manifest.

I would use the Secret Manager add-on or CSI driver with Workload Identity Federation for GKE and never store the password in Git.

• I would grant roles/secretmanager.secretAccessor to the workload principal on the secret resource because IAM access is not granted on an individual secret version.
• The SecretProviderClass or add-on configuration would reference an explicit resource version such as versions/7 instead of latest, making the consumed value deterministic.
• Rotation would create the new database credential and secret version, update that pinned reference, roll and verify consumers, and only then retire the old credential and version.
• Secret Manager Data Access logs would confirm which principal read the value during the change.

I would place the VPC, subnets, routes, and central firewall controls in a host project and attach the three service projects.

• Application resources stay in service projects for billing and IAM separation while using host-project subnets.
• Network administrators manage the host, and application deployers receive only subnet-level Network User access where needed.
• I would allocate non-overlapping regional CIDR ranges with room for GKE pods, services, and future growth.
• Central ownership would not replace service-project IAM, so resource and network permissions remain separate responsibilities.

I would enforce the broad deny at the folder level and add a narrow higher-priority allowance for the approved administration path.

• The allow rule would target secured resources with service accounts or secure tags instead of a wide network CIDR.
• SSH from 0.0.0.0/0 would be denied centrally so project owners cannot override the guardrail with a lower-level VPC rule.
• Rule priorities and inheritance would be documented because a higher-level match can prevent child policies from taking effect.
• I would test policy impact on a non-production project before applying it to the full folder.