PwC DevOps Engineer Interview Questions 2026: GCP, Terraform, GKE & Kubernetes | 4–6 Years Experience
PwC DevOps Engineer Interview Questions 2026: GCP, Terraform, GKE & Kubernetes | 4–6 Years Experience
28 Scenario-Based Interview Questions | Simple Explanations | Production Examples | Commands | Candidate-Style Answers
You have 4–6 years of DevOps experience. You know Terraform, Docker, Kubernetes, and cloud platforms.
But in an interview, the questions become different.
The interviewer may ask:
How would you design reusable Terraform modules for four environments?
What happens if two engineers run
terraform applysimultaneously?How does a GKE application access Google Cloud Storage without storing credentials?
What happens when a Kubernetes worker node fails in Production?
How would you troubleshoot a pod that is stuck in
Pending?
These questions test more than tool knowledge. They test whether you understand how infrastructure works in real environments.
In this guide, we’ll break down 28 targeted practice questions for Terraform, GCP, GKE, and Kubernetes in simple language, with production examples, commands, common interview mistakes, candidate-style answers, and memory tricks.
Disclaimer: These are targeted practice questions based on common DevOps engineering responsibilities, not verified questions from an official PwC interview.
Round 1: Terraform and Reusable Modules
<text size=”sm” color=”secondary”>Priority: Very High</text>
Q1. How do you design reusable Terraform modules for Dev, QA, UAT, and Production?
1. Simple Concept
Think of a Terraform module as a reusable building block.
Instead of writing separate infrastructure code for every environment, you create a module once and pass different values to it.
2. Why Do We Need It?
Without reusable modules, teams often copy and paste Terraform code. Over time, one environment gets updated while another is forgotten.
Reusable modules reduce duplication and make infrastructure easier to maintain.
3. How Does It Work?
Create modules for common infrastructure, such as VPCs, GKE clusters, IAM, and storage. Each environment calls the modules with its own configuration.
terraform-gcp/
├── modules/
│ ├── vpc/
│ ├── gke/
│ └── iam/
└── environments/
├── dev/
├── qa/
├── uat/
└── prod/Dev might use smaller nodes. Production might require regional availability, stricter permissions, and additional capacity.
4. Production Example
Your company has four environments. The networking team changes a standard subnet configuration.
Instead of editing four copied configurations, you update the reusable module, test the change, and upgrade each environment through a controlled process.
5. Command / Configuration
module "vpc" {
source = "../../modules/vpc"
network_name = "dev-network"
subnet_cidr = "10.10.0.0/20"
region = "asia-south1"
}6. Common Interview Trap
Reusable does not mean identical everywhere. Production and Dev may need different security, availability, and capacity settings.
7. Candidate-Style Answer
“I create reusable modules for components such as VPC, GKE, and IAM. Each environment has its own configuration and state, while modules expose configurable inputs and outputs. I version modules, test changes in lower environments, and use approval-based pipelines for Production.”
8. Memory Trick
One building block, multiple configurations.
Q2. Explain the folder structure of a Terraform project containing reusable modules.
1. Simple Concept
The folder structure separates reusable code from the configuration used by individual environments.
2. Why Do We Need It?
It makes the repository easier to understand, test, review, and maintain as the infrastructure grows.
3. How Does It Work?
terraform-gcp/
├── modules/
│ ├── vpc/
│ │ ├── main.tf
│ │ ├── variables.tf
│ │ └── outputs.tf
│ └── gke/
├── environments/
│ ├── dev/
│ ├── qa/
│ └── prod/
└── README.mdmain.tf: Defines resources and module calls.variables.tf: Defines input variables.outputs.tf: Exposes useful values.terraform.tfvars: Supplies environment-specific values.
4. Production Example
A new engineer needs to understand how Production creates its GKE cluster. They can inspect the Production configuration, follow the module call, and locate the cluster implementation without searching through duplicated files.
5. Command
terraform fmt -check -recursive
terraform init
terraform validateRun these commands from the appropriate root module.
6. Common Interview Trap
A directory structure alone does not make infrastructure reusable. Modules need clear interfaces, documented inputs, outputs, and versioning.
7. Candidate-Style Answer
“I keep reusable components under modules and environment-specific root configurations under environments. This separates implementation from configuration and allows each environment to use the same tested components with different values.”
8. Memory Trick
Modules define how; environments define what values.
Q3. How do you pass environment-specific values using variables, terraform.tfvars, and locals?
1. Simple Concept
Variables are inputs, terraform.tfvars supplies values, and locals calculate reusable values.
2. Why Do We Need It?
Hardcoding environment values throughout Terraform makes changes difficult and increases the risk of deploying the wrong configuration.
3. How Does It Work?
variable "environment" {
type = string
}
variable "region" {
type = string
}
locals {
cluster_name = "${var.environment}-gke"
}In terraform.tfvars:
environment = "dev"
region = "asia-south1"The local expression produces a cluster name such as dev-gke.
4. Production Example
Dev uses smaller node pools, while Production uses larger machines. Both environments reuse the same module but supply different values.
5. Command
terraform plan -var-file="terraform.tfvars"6. Common Interview Trap
Locals are not input variables. They are expressions calculated inside the configuration.
7. Candidate-Style Answer
“I define typed input variables, provide environment-specific values through variable files, and use locals for calculated values such as resource names and common tags. This keeps the configuration reusable and easier to review.”
8. Memory Trick
Variable = input. TFVars = value. Local = calculation.
Q4. Write a reusable Terraform module to create a GCP VPC, subnet, and firewall rules.
1. Simple Concept
A VPC is a private network in Google Cloud. A subnet provides an IP address range inside that network. Firewall rules control allowed traffic.
2. Why Do We Need It?
Applications and GKE nodes need planned network connectivity. Firewall rules help prevent unwanted access.
3. How Does It Work?
The module creates a custom VPC, creates a subnet, and adds carefully scoped firewall rules.
Example VPC and subnet resources:
resource "google_compute_network" "this" {
name = var.network_name
auto_create_subnetworks = false
}
resource "google_compute_subnetwork" "this" {
name = var.subnet_name
region = var.region
ip_cidr_range = var.subnet_cidr
network = google_compute_network.this.id
}Example variables:
variable "network_name" {
type = string
}
variable "subnet_name" {
type = string
}
variable "region" {
type = string
}
variable "subnet_cidr" {
type = string
}4. Production Example
A GKE cluster uses the subnet for node addresses and may need additional secondary IP ranges for Pods and Services, depending on the networking configuration.
Firewall rules should allow only the required sources, protocols, and ports.
5. Command
terraform init
terraform validate
terraform plan6. Common Interview Trap
Creating a VPC and subnet does not automatically make a GKE networking design production-ready. IP planning, secondary ranges, private access, routing, and firewall requirements also matter.
7. Candidate-Style Answer
“I build the VPC, subnet, and firewall rules as a reusable module. I expose CIDR ranges, names, and region as variables, and use outputs to connect the module to GKE. In Production, I validate IP capacity and follow least-privilege network rules.”
8. Memory Trick
VPC = network. Subnet = address range. Firewall = traffic control.
Q5. How do you create a GKE cluster using a reusable Terraform module?
1. Simple Concept
A GKE module packages the configuration needed to create a Kubernetes cluster so different environments can use the same implementation.
2. Why Do We Need It?
Manually creating clusters for every environment can lead to inconsistent networking, security settings, and node configurations.
3. How Does It Work?
The module accepts inputs such as project ID, region, network, subnet, cluster name, and node-pool settings.
Example module call:
module "gke" {
source = "../../modules/gke"
project_id = var.project_id
region = var.region
cluster_name = "${var.environment}-gke"
network = module.vpc.network_id
subnetwork = module.vpc.subnet_id
}The actual module defines the GKE cluster, node pools, and required settings.
4. Production Example
The same module creates a small Dev cluster and a regional Production cluster with appropriate availability, identity, monitoring, and autoscaling settings.
5. Command
terraform plan
terraform applyRun these commands through the approved workflow and review the plan before applying it.
6. Common Interview Trap
A module call is not a complete cluster implementation. The underlying module must correctly configure networking, IAM, node pools, and cluster-specific requirements.
7. Candidate-Style Answer
“I create a GKE module with configurable cluster, networking, and node-pool inputs. I expose outputs required by other components and maintain environment-specific settings separately. I test changes in Dev before promoting them to Production.”
8. Memory Trick
Build the cluster once; configure each environment separately.
Q6. How do you manage Terraform remote state using a GCS bucket?
1. Simple Concept
Terraform state records which real infrastructure resources belong to your Terraform configuration.
Remote state stores that information in a shared location instead of only on a developer’s laptop.
2. Why Do We Need It?
When several engineers work on the same infrastructure, everyone needs a consistent state. Local state files make collaboration and recovery difficult.
3. How Does It Work?
Configure the GCS backend:
terraform {
backend "gcs" {
bucket = "company-terraform-state"
prefix = "gke/dev"
}
}The bucket must exist and have appropriate access permissions before the backend can use it.
4. Production Example
Your DevOps team manages GKE through a CI/CD pipeline. The pipeline uses the shared backend so authorized runs operate against the same state.
Use separate state locations for independently managed environments, restrict bucket IAM access, and enable appropriate recovery controls such as object versioning.
5. Command
terraform init
terraform plan6. Common Interview Trap
Terraform state can contain sensitive information. Remote state does not mean the data is automatically safe.
7. Candidate-Style Answer
“I use a dedicated GCS bucket for remote state, restrict access with IAM, enable recovery controls, and separate state by environment. The GCS backend supports state locking, which helps prevent conflicting operations against the same state.”
8. Memory Trick
State is Terraform’s record of reality. Protect it.
Q7. How do you implement state locking and prevent concurrent Terraform deployments?
1. Simple Concept
State locking prevents supported concurrent Terraform operations from modifying the same state simultaneously.
2. Why Do We Need It?
Imagine two engineers updating the same infrastructure at the same time. One is changing a subnet while the other is replacing a cluster. Concurrent operations can conflict and produce unexpected results.
3. How Does It Work?
The GCS backend supports locking for Terraform state operations. Terraform acquires a lock when required and releases it when the operation completes.
You should also configure CI/CD concurrency controls so only one apply runs against a given state at a time.
4. Production Example
A developer starts a Production apply. Another pipeline attempts an apply against the same state. The second operation should wait or fail rather than run concurrently.
5. Command
terraform plan
terraform applyUse the normal backend locking behavior and investigate lock errors before taking corrective action.
6. Common Interview Trap
Do not casually force-unlock state. First verify whether another process is still running. Force-unlock is appropriate only when you have confirmed a stale lock and understand the consequences.
7. Candidate-Style Answer
“I use a backend that supports locking, along with pipeline concurrency controls. If Terraform reports a lock error, I check active runs and lock ownership before acting. I never remove a lock just to make a failed deployment proceed.”
8. Memory Trick
One state, one active writer at a time.
Q8. What is the difference between count and for_each?
1. Simple Concept
Both create multiple resources. count uses numeric indexes, while for_each uses identifiable keys.
2. Why Do We Need It?
Choosing the right method makes infrastructure easier to maintain when resources are added or removed.
3. How Does It Work?
Using count:
resource "google_compute_network" "example" {
count = 2
name = "network-${count.index}"
auto_create_subnetworks = false
}Using for_each:
resource "google_compute_network" "example" {
for_each = toset(["dev", "qa"])
name = "${each.key}-network"
auto_create_subnetworks = false
}4. Production Example
Use for_each when creating named environment resources or a collection of individually identified buckets. Use count when managing a simple number of similar resources.
5. Command
terraform planReview the resource addresses in the plan before changing between count and for_each.
6. Common Interview Trap
Changing resource addressing can cause Terraform to propose resource replacement or recreation unless state addresses are handled correctly.
7. Candidate-Style Answer
“I use count for simple numeric repetition and for_each when resources have meaningful identities. For infrastructure such as named buckets or environments, for_each often gives more stable and understandable resource addresses.”
8. Memory Trick
Count counts. For_each names.
Q9. How do you handle secrets and sensitive variables in Terraform?
1. Simple Concept
Secrets are credentials or confidential values that should not be exposed to unauthorized users.
2. Why Do We Need It?
A leaked service account key or password can allow an attacker to access infrastructure or application data.
3. How Does It Work?
Use Secret Manager for application secrets, IAM to restrict access, and short-lived credentials where possible. Avoid committing secrets to Git.
Example variable:
variable "application_password" {
type = string
sensitive = true
}The sensitive flag redacts certain displayed values. It does not automatically remove the value from Terraform state.
4. Production Example
A CI/CD pipeline provisions cloud infrastructure using an authorized identity. An application retrieves its secret from Secret Manager using its runtime identity rather than a hardcoded password.
5. Command
git diff --check
git statusThese commands help inspect repository changes, but use secret-scanning tools and secure pipeline controls as well. They do not replace proper secrets management.
6. Common Interview Trap
Marking a variable sensitive does not encrypt every copy of that value or prevent it from appearing in state.
7. Candidate-Style Answer
“I avoid hardcoded credentials, use Secret Manager and short-lived identity-based access where possible, restrict access to state, and ensure secrets are not exposed in logs or artifacts. I understand that sensitive = true controls display, not storage.”
8. Memory Trick
Hide the output, secure the storage, restrict the access.
Q10. What is Terraform drift, and how do you detect and remediate it?
1. Simple Concept
Drift occurs when real infrastructure changes outside the expected Terraform configuration and state.
2. Why Do We Need It?
A manual firewall change may allow unexpected traffic. A manually resized cluster may increase costs or diverge from approved configuration.
3. How Does It Work?
Run a plan to compare the desired configuration with the infrastructure Terraform observes.
terraform planInvestigate proposed changes before deciding whether to update the code or restore the intended infrastructure.
4. Production Example
Someone manually changes a firewall rule in GCP. Terraform detects the difference. The team investigates whether the change was authorized and then updates the configuration or restores the approved rule.
5. Command
terraform plan -refresh-onlyA refresh-only plan can help review state updates reflecting observed infrastructure. It does not itself fix the underlying configuration drift.
6. Common Interview Trap
Do not blindly apply Terraform just because a plan shows changes. A plan may contain resource replacements or destructive actions.
7. Candidate-Style Answer
“I detect drift through regular Terraform plans and controlled checks. I investigate the source of the change, decide whether it should be retained, update configuration accordingly, and review the final plan before applying.”
8. Memory Trick
Detect the difference, investigate the cause, correct the desired state.
Q11. How do you import an existing GCP resource into Terraform state?
1. Simple Concept
Importing tells Terraform that an existing resource should be managed by a particular resource address in the configuration.
2. Why Do We Need It?
Companies often have infrastructure created manually or by earlier automation. Recreating it may cause downtime or unnecessary cost.
3. How Does It Work?
Write the matching resource block, then import the existing resource.
terraform import \
google_compute_network.main \
projects/PROJECT_ID/global/networks/NETWORK_NAMEThe exact identifier depends on the resource type.
4. Production Example
A team has a manually created VPC. They define the matching Terraform resource, import it, and reconcile the configuration with the actual settings.
5. Command
terraform planAfter import, inspect the plan carefully.
6. Common Interview Trap
Importing does not automatically create a complete Terraform configuration. You must define and reconcile the resource configuration yourself.
7. Candidate-Style Answer
“I define the resource block, back up or otherwise protect the state, import the resource using its provider-specific identifier, and run a plan to identify differences before making changes.”
8. Memory Trick
Import connects existing infrastructure to Terraform management.
Q12. How would you upgrade a reusable Terraform module without impacting existing environments?
1. Simple Concept
A module upgrade changes shared infrastructure logic. The objective is to introduce improvements without causing unexpected resource changes.
2. Why Do We Need It?
A faulty module upgrade can replace a production resource, interrupt services, or change network behavior.
3. How Does It Work?
Version the module, review its changes, test in lower environments, and promote the tested version gradually.
4. Production Example
You upgrade a GKE module to support a new node-pool configuration. Test it in Dev and QA, review plans in UAT, and promote it to Production with approval.
5. Command
terraform init -upgrade
terraform planUse -upgrade deliberately because it can update dependency selections. Pin module and provider versions according to your release strategy.
6. Common Interview Trap
Updating a module version does not guarantee that infrastructure remains unchanged. Review the plan for replacement and destructive actions.
7. Candidate-Style Answer
“I use versioned modules and test upgrades in non-production environments. I inspect plans for every affected environment, verify compatibility, and require approval before applying changes to Production.”
8. Memory Trick
Version, test, plan, approve, promote.
Q13. How do you implement conditional resource creation using count, for_each, and dynamic blocks?
1. Simple Concept
Conditional creation lets Terraform create resources or nested configuration only when needed.
2. Why Do We Need It?
Dev might not need every optional component that Production requires.
3. How Does It Work?
Use count or for_each to conditionally create resources:
variable "enable_logging_bucket" {
type = bool
default = true
}
resource "google_storage_bucket" "logs" {
count = var.enable_logging_bucket ? 1 : 0
name = "example-application-logs"
location = "ASIA-SOUTH1"
}Dynamic blocks generate supported nested blocks from collections.
4. Production Example
A module creates an optional logging bucket or configures different firewall rules based on approved environment settings.
5. Command
terraform validate
terraform plan6. Common Interview Trap
Use dynamic blocks only when the resource schema supports repeatable nested blocks. They are not a replacement for ordinary resource blocks.
7. Candidate-Style Answer
“I use conditional expressions with count or for_each for optional resources and dynamic blocks for supported repeated nested configuration. I validate the configuration and review plans for every environment.”
8. Memory Trick
Condition controls resources; dynamic blocks control nested configuration.
Q14. Terraform workspaces versus separate environment directories: which would you choose?
1. Simple Concept
Workspaces provide separate state instances for a configuration. Separate environment directories provide distinct root configurations for different environments.
2. Why Do We Need It?
Different environments may require different network layouts, access controls, approval processes, and infrastructure settings.
3. How Does It Work?
A workspace can be useful when environments are structurally similar. Separate directories make configuration and deployment boundaries more explicit.
4. Production Example
A company may use independent root configurations and state locations for Dev and Production because Production has stricter approvals and different networking requirements.
5. Command
terraform workspace list
terraform workspace show6. Common Interview Trap
Workspaces are not a security boundary by themselves. Selecting a workspace does not automatically provide separate IAM permissions or approval controls.
7. Candidate-Style Answer
“I choose based on how different the environments are. For enterprise environments with different access and release controls, separate root configurations and state locations are often easier to govern. Workspaces are useful when the configurations are similar.”
8. Memory Trick
Similar configurations: workspaces may fit. Different controls: explicit separation helps.
Q15. How do you implement Terraform plan, approval, and apply stages in CI/CD?
1. Simple Concept
A Terraform pipeline checks infrastructure changes before allowing them to be applied.
2. Why Do We Need It?
A developer should not accidentally delete a Production database or replace a critical network resource without review.
3. How Does It Work?
Pull Request
|
v
Format and Validate
|
v
Security Checks
|
v
Terraform Plan
|
v
Review and Approval
|
v
Terraform Apply4. Production Example
A pull request changes GKE node-pool settings. The pipeline produces a plan, the team reviews replacements and cost implications, and an authorized person approves the deployment.
5. Command
terraform fmt -check -recursive
terraform init
terraform validate
terraform plan -out=tfplan
terraform apply tfplanThe apply stage should use the reviewed plan artifact in a secure, controlled workflow. Manage plan files carefully because they can contain sensitive information.
6. Common Interview Trap
A successful terraform validate does not guarantee that an infrastructure change is safe. It checks configuration validity, not every real-world impact.
7. Candidate-Style Answer
“My pipeline runs formatting, validation, security checks, and planning before approval. The apply stage uses the reviewed plan, controlled cloud credentials, protected state, and concurrency controls. Production changes require explicit authorization.”
8. Memory Trick
Validate before planning. Review before applying.
Round 2: GKE and Kubernetes
<text size=”sm” color=”secondary”>Priority: Very High</text>
Q16. How do you deploy a highly available GKE cluster using Terraform?
1. Simple Concept
High availability means designing the system so a single failure does not automatically make the application unavailable.
2. Why Do We Need It?
If a zone or node fails, a Production application should continue serving requests wherever possible.
3. How Does It Work?
Use a regional GKE cluster where appropriate, distribute workloads across zones, configure multiple replicas, and provide enough capacity for workloads to recover.
4. Production Example
An online service runs application replicas across three zones. If one zone becomes unavailable, replicas in other zones can continue serving traffic, provided the application and its dependencies support that recovery.
5. Command
gcloud container clusters describe CLUSTER_NAME \
--region=asia-south1 \
--project=PROJECT_IDUse this to inspect a regional cluster’s configuration.
6. Common Interview Trap
A regional control plane alone does not guarantee application availability. Workload placement, storage, capacity, and application dependencies matter too.
7. Candidate-Style Answer
“I provision a regional cluster using Terraform, distribute workloads across zones, configure replicas and topology spread, and enable appropriate autoscaling and monitoring. I also validate recovery from node and zonal failures.”
8. Memory Trick
High availability needs resilient control plane, workloads, and dependencies.
Q17. Explain the complete architecture of a production-ready GKE cluster.
1. Simple Concept
A production GKE architecture includes networking, the Kubernetes cluster, application workloads, deployment automation, security, and monitoring.
2. Why Do We Need It?
A cluster that merely runs Pods is not enough for an enterprise application. It must also handle traffic, identity, failures, deployments, and operational visibility.
3. How Does It Work?
Developer
|
v
Git Repository
|
v
CI/CD Pipeline
|
+--> Test and Scan
|
v
Artifact Registry
|
v
GKE Cluster
|
+--> Zone A: Pods
+--> Zone B: Pods
+--> Zone C: Pods
|
v
Service / Gateway
|
v
Users
Security: IAM + Workload Identity
Operations: Logging + Monitoring
Infrastructure: Terraform + VPC4. Production Example
A developer merges code. The pipeline tests and scans the application, builds its container image, pushes it to Artifact Registry, and deploys it to GKE. Monitoring detects failures after deployment.
5. Command
kubectl get nodes
kubectl get pods -A
kubectl get services -AThese commands provide a basic view of the cluster’s nodes, workloads, and Services.
6. Common Interview Trap
Do not describe only Kubernetes resources. Explain how traffic enters the system, how images reach the cluster, how workloads obtain cloud permissions, and how failures are detected.
7. Candidate-Style Answer
“I design GKE as part of an end-to-end platform. Terraform manages infrastructure, CI/CD builds and deploys images, the cluster runs workloads across appropriate failure domains, IAM controls access, and Cloud Logging and Monitoring provide operational visibility.”
8. Memory Trick
Build, secure, deploy, expose, observe.
Q18. What is the difference between regional and zonal GKE clusters?
1. Simple Concept
A zonal cluster has its control plane associated with one zone. A regional cluster provides a replicated control plane across multiple zones in a region.
2. Why Do We Need It?
The cluster topology determines how resilient cluster management is to a zonal failure.
3. How Does It Work?
Regional clusters distribute control-plane availability across zones. Node pools and application workloads must also be configured appropriately for workload resilience.
4. Production Example
A development environment with modest availability requirements may use a zonal cluster. A business-critical application may use a regional cluster with workloads spread across zones.
5. Command
gcloud container clusters list \
--project=PROJECT_IDInspect the cluster’s location and configuration.
6. Common Interview Trap
A regional cluster may cost more and does not automatically make the application highly available.
7. Candidate-Style Answer
“I select zonal or regional topology based on availability requirements, cost, and failure domains. For critical workloads, I typically evaluate regional GKE and also ensure that node pools, replicas, and application dependencies are resilient.”
8. Memory Trick
Zonal: one zone for the control plane. Regional: replicated control plane across zones.
Q19. How do you configure multiple node pools for different workloads?
1. Simple Concept
A node pool is a group of worker nodes with a particular configuration.
2. Why Do We Need It?
Different applications have different resource requirements. A memory-intensive service may need different machines from a lightweight API.
3. How Does It Work?
Create node pools with suitable machine types, scaling limits, labels, taints, and upgrade settings.
Use Kubernetes scheduling rules to place workloads on appropriate nodes.
4. Production Example
A company uses one pool for general applications and another for memory-intensive workloads. Taints and tolerations prevent unrelated workloads from being scheduled on dedicated nodes.
5. Command
kubectl get nodes --show-labels
kubectl describe node NODE_NAME6. Common Interview Trap
Creating a separate node pool does not automatically place the correct workloads on it. Scheduling rules must match the intended placement.
7. Candidate-Style Answer
“I create node pools based on workload requirements and configure machine types, autoscaling, labels, and taints. I then use selectors, affinity, and tolerations to control placement and avoid resource contention.”
8. Memory Trick
Node pool defines capacity; scheduling rules decide placement.
Q20. How do you enable autoscaling for GKE node pools and Kubernetes Pods?
1. Simple Concept
Autoscaling adjusts resources when application demand changes.
2. Why Do We Need It?
Too little capacity causes performance problems. Too much capacity wastes money.
3. How Does It Work?
HPA adjusts the number of Pod replicas.
VPA recommends or adjusts CPU and memory requests, depending on configuration.
Cluster Autoscaler adjusts node count when scheduling demand requires more or fewer nodes.
4. Production Example
Traffic increases, so HPA creates additional replicas. If the existing nodes lack capacity, Cluster Autoscaler can add nodes to accommodate pending Pods.
5. Command
kubectl get hpa -A
kubectl describe hpa HPA_NAME -n NAMESPACE
kubectl get pods -n NAMESPACE6. Common Interview Trap
HPA cannot create usable capacity if scheduling is blocked and the cluster cannot add suitable nodes. Resource requests and node-pool limits matter.
7. Candidate-Style Answer
“I use HPA for application replica scaling and Cluster Autoscaler for node capacity. VPA helps right-size resource requests. I monitor metrics, scheduling constraints, and interactions between scaling mechanisms.”
8. Memory Trick
HPA scales Pods. VPA adjusts requests. Cluster Autoscaler scales nodes.
Q21. How do you configure a private GKE cluster and securely access the Kubernetes API?
1. Simple Concept
Private GKE nodes use internal IP addresses instead of public node IPs. Access to the Kubernetes API must also be designed and restricted appropriately.
2. Why Do We Need It?
Private networking reduces direct exposure of cluster nodes to the public internet.
3. How Does It Work?
Use private nodes, restrict control-plane access, configure authorized access paths, and grant only the required IAM permissions.
Administrators and CI/CD runners must have a supported network path to the API endpoint.
4. Production Example
A company runs GKE workloads in private subnets. Engineers administer the cluster through an approved private network path, while CI/CD uses a controlled identity and authorized connectivity.
5. Command
gcloud container clusters describe CLUSTER_NAME \
--region=asia-south1 \
--project=PROJECT_IDReview the cluster’s private networking and endpoint configuration.
6. Common Interview Trap
Private nodes do not automatically mean the Kubernetes API is unreachable from every unauthorized location. Endpoint configuration and access policies still matter.
7. Candidate-Style Answer
“I use private nodes, restrict control-plane connectivity, enforce IAM least privilege, and provide a secure administrative path. I also validate egress connectivity for image pulls and required external services.”
8. Memory Trick
Private nodes, restricted API, controlled access.
Q22. How does a GKE workload access a GCS bucket without storing service account keys?
1. Simple Concept
Workload Identity Federation for GKE allows a Kubernetes workload to obtain Google Cloud permissions through an identity-based mechanism instead of a long-lived service account key.
2. Why Do We Need It?
Storing service account keys in application containers or Kubernetes Secrets increases the risk of credential theft.
3. How Does It Work?
Configure the Kubernetes service account, the required identity association or impersonation mechanism, and the necessary Google Cloud IAM permissions.
The workload runs as the configured Kubernetes service account and obtains authorized access to Google Cloud resources.
4. Production Example
A report-generation Pod needs to read files from a specific GCS bucket. It uses its workload identity to access those objects without storing a downloaded JSON key.
5. Command
kubectl get serviceaccounts -n production
kubectl describe serviceaccount APP_KSA -n productionVerify the Kubernetes service account configuration, then validate the relevant Google Cloud IAM setup and test the workload’s access.
6. Common Interview Trap
Creating a Kubernetes service account alone does not grant access to GCS. The identity configuration and required IAM permissions must also be correct.
7. Candidate-Style Answer
“I use Workload Identity Federation for GKE to avoid long-lived service account keys. I configure the workload identity association and grant the minimum required GCS permissions to the workload’s identity.”
8. Memory Trick
Workload identity replaces stored keys with configured identity and permissions.
Q23. How do you troubleshoot Pods stuck in Pending, CrashLoopBackOff, or ImagePullBackOff?
1. Simple Concept
These statuses indicate different problems. The correct fix depends on what Kubernetes reports and what the container logs show.
2. Why Do We Need It?
Production applications can fail because of resource shortages, incorrect configuration, application crashes, or image registry access.
3. How Does It Work?
Start with:
kubectl get pods -n production
kubectl describe pod POD_NAME -n production
kubectl get events -n production \
--sort-by=.metadata.creationTimestamp
kubectl logs POD_NAME -n production
kubectl logs POD_NAME -n production --previousPending: Check resource availability, taints, selectors, quotas, and storage.
CrashLoopBackOff: Check application logs, exit codes, startup commands, environment variables, and probes.
ImagePullBackOff: Check image names, tags, registry permissions, authentication, and network connectivity.
4. Production Example
A deployment fails after a release because the new container image references an incorrect tag. Events show image-pull failures. Correct the image reference, verify registry access, and redeploy.
5. Command
kubectl describe pod POD_NAME -n production
kubectl logs POD_NAME -n production --previous6. Common Interview Trap
Do not immediately delete the Pod. A controller may recreate it with the same problem, and you may lose useful evidence.
7. Candidate-Style Answer
“I start with Pod status, events, and logs. For Pending, I investigate scheduling and capacity. For CrashLoopBackOff, I inspect the application and previous logs. For ImagePullBackOff, I verify the image reference, registry permissions, and connectivity.”
8. Memory Trick
Pending = scheduling. CrashLoop = execution. ImagePull = retrieval.
Q24. What happens when a Kubernetes worker node fails?
1. Simple Concept
When a worker node becomes unhealthy, Kubernetes detects the failure and may reschedule managed workloads onto healthy nodes.
2. Why Do We Need It?
Hardware problems, network failures, and node maintenance can interrupt workloads.
3. How Does It Work?
The control plane detects the unhealthy node. Recovery depends on controller behavior, node failure detection, available capacity, storage, and scheduling rules.
4. Production Example
One node fails in a regional cluster. Other replicas continue serving traffic, and managed workloads can be recreated on healthy nodes if capacity and constraints permit.
5. Command
kubectl get nodes
kubectl describe node NODE_NAME
kubectl get pods -A -o wide6. Common Interview Trap
A PodDisruptionBudget does not protect against every involuntary failure. Also, a single-replica application may remain unavailable until recovery completes.
7. Candidate-Style Answer
“I check node health and affected workloads, confirm that replicas are distributed across healthy nodes, and investigate capacity and scheduling constraints. I then validate application recovery and examine why the node failed.”
8. Memory Trick
Detect the failed node, recover the workloads, investigate the cause.
Q25. How do you deploy an application across multiple zones with high availability?
1. Simple Concept
Spread application replicas across different zones so a single-zone failure does not take down every replica.
2. Why Do We Need It?
If all replicas run in one zone, the application can become unavailable when that zone fails.
3. How Does It Work?
Use multiple replicas, suitable topology spread constraints or pod anti-affinity, sufficient node capacity, health checks, and an appropriate Service or Gateway configuration.
4. Production Example
A customer-facing API runs several replicas distributed across three zones. If one zone fails, healthy replicas in the remaining zones can continue serving traffic.
5. YAML Example
apiVersion: apps/v1
kind: Deployment
metadata:
name: payments-api
spec:
replicas: 3
selector:
matchLabels:
app: payments-api
template:
metadata:
labels:
app: payments-api
spec:
topologySpreadConstraints:
- maxSkew: 1
topologyKey: topology.kubernetes.io/zone
whenUnsatisfiable: DoNotSchedule
labelSelector:
matchLabels:
app: payments-api
containers:
- name: api
image: REGION-docker.pkg.dev/PROJECT/REPO/payments-api:1.0.0This is an illustrative deployment. Real configurations also need appropriate resource requests, probes, image references, and compatible cluster capacity.
6. Common Interview Trap
Three replicas do not guarantee three-zone distribution. Scheduling constraints, node availability, and capacity determine placement.
7. Candidate-Style Answer
“I deploy multiple replicas and use topology spread constraints to distribute them across zones. I ensure sufficient capacity, configure health checks and traffic routing, and test the application’s behavior during a simulated node or zonal failure.”
8. Memory Trick
Multiple replicas, multiple zones, enough capacity.
Q26. Explain Deployment, StatefulSet, DaemonSet, and Job.
1. Simple Concept
These Kubernetes resources manage different kinds of workloads.
2. Why Do We Need It?
A web API, a database, a node-level monitoring agent, and a one-time migration do not all behave the same way.
3. How Does It Work?
ResourcePurposeExampleDeploymentManages replicated, generally stateless applicationsREST APIStatefulSetProvides stable identity and often persistent storageStateful database workloadDaemonSetRuns a Pod on each eligible nodeLogging agentJobRuns a finite task to completionData migration
4. Production Example
A company uses a Deployment for its API, a DaemonSet for a node-level logging agent, and a Job for a database migration during a release.
5. Command
kubectl get deployments,statefulsets,daemonsets,jobs -A6. Common Interview Trap
A StatefulSet does not automatically make a database highly available. The database’s replication, backup, failover, and storage design still matter.
7. Candidate-Style Answer
“I use Deployments for stateless applications, StatefulSets when stable identity or storage behavior is required, DaemonSets for node-level agents, and Jobs for finite tasks. I select the controller based on the workload’s lifecycle.”
8. Memory Trick
Deployment = replicas. StatefulSet = identity. DaemonSet = each eligible node. Job = completion.
Q27. How do you troubleshoot a GKE application that is running but not accessible?
1. Simple Concept
A running Pod does not guarantee that users can reach the application.
2. Why Do We Need It?
The application may be healthy inside the container while the Service, Gateway, DNS, firewall, or backend health configuration is incorrect.
3. How Does It Work?
Trace the request path:
User
|
v
DNS
|
v
Load Balancer / Gateway
|
v
Kubernetes Service
|
v
PodCheck each component rather than assuming the application is the problem.
4. Production Example
A new release creates healthy Pods, but the load balancer returns errors. You discover that the Service selector does not match the Pod labels, leaving no usable endpoints.
5. Commands
kubectl get pods -n production --show-labels
kubectl get svc -n production
kubectl get endpointslices -n production
kubectl describe svc SERVICE_NAME -n production
kubectl get ingress -n productionFor Gateway-based deployments, inspect the relevant Gateway and route resources as well.
6. Common Interview Trap
Restarting the application will not fix a Service selector mismatch or an incorrect DNS record.
7. Candidate-Style Answer
“I trace traffic from DNS through the load balancer, Gateway or Ingress, Service, and Pods. I verify health checks, selectors, EndpointSlices, ports, network rules, and application logs to isolate the failing layer.”
8. Memory Trick
Trace traffic from the user to the Pod.
Q28. How do you implement a safe Kubernetes deployment and rollback strategy?
1. Simple Concept
A deployment strategy controls how a new application version replaces the existing version.
2. Why Do We Need It?
A faulty release can introduce errors, cause downtime, or affect every user simultaneously.
3. How Does It Work?
Use controlled rollouts, readiness probes, sensible resource settings, monitoring, and an agreed rollback procedure. Depending on requirements, use rolling updates, canary releases, or blue-green deployments with appropriate tooling.
4. Production Example
A new API version causes elevated error rates after rollout. The team checks metrics and logs, stops further promotion, and rolls back to the previous known-good ReplicaSet if the Deployment history and compatibility permit.
5. Commands
kubectl rollout status deployment/payments-api -n production
kubectl rollout history deployment/payments-api -n production
kubectl rollout undo deployment/payments-api -n production6. Common Interview Trap
A Kubernetes rollback does not automatically reverse database schema changes or external infrastructure changes. Application and data compatibility must be considered.
7. Candidate-Style Answer
“I use controlled rollout strategies and readiness checks, monitor error rates and application health, and define rollback criteria before deployment. If the release fails, I restore the previous version where safe and investigate the root cause before retrying.”
8. Memory Trick
Deploy gradually, verify health, roll back safely.
How to Prepare for the Interview
Don’t memorize all 28 answers word for word. Learn to explain each concept in your own language.
For every question, practise answering these five things:
What is it?
Why do we need it?
Where is it used in Production?
What can go wrong?
How would you troubleshoot it?
Then practise speaking your answer aloud in 30–60 seconds. Follow up with the relevant command, YAML, Terraform configuration, or architecture diagram.
For an engineer with 4–6 years of experience, the interviewer wants to see that you can make decisions, understand trade-offs, investigate failures, and explain why a solution is appropriate.
Final Thoughts
Terraform helps teams build repeatable infrastructure. GCP provides cloud services. GKE runs containerized workloads. Kubernetes manages application scheduling and recovery. CI/CD connects code changes to controlled releases.
But the real skill is understanding how all these components work together when something goes wrong.
Don’t just learn how to deploy an application. Learn how to secure it, monitor it, troubleshoot it, and recover it when Production breaks.
That’s how you move from knowing DevOps tools to thinking like a DevOps Engineer.
Connect with me
Medium: https://medium.com/@arvindverma021
LinkedIn: https://www.linkedin.com/in/arvindverma021/
Substack:
DevOps Resources: https://topmate.io/arvindverma021/
#DevOps #PwC #GCP #Terraform #GKE #Kubernetes #Docker #CICD #GoogleCloud #DevSecOps #CloudEngineering #SRE #PlatformEngineering #DevOpsInterview #DevOpsCareer
Arvind Verma is free today. But if you enjoyed this post, you can tell Arvind Verma that their writing is valuable by pledging a future subscription. You won't be charged unless they enable payments.
© 2026 Arvind Verma
548 Market Street PMB 72296, San Francisco, CA 94104