GCP Engineer interview questions

GCP organizes resources as organization, folders, projects, and service resources.

• The organization is the top node for a company and can contain folders and projects.
• Folders group projects by team, environment, or business unit and may be nested.
• Projects contain resources such as VM instances, buckets, and databases.
• IAM and organization policies applied higher in the hierarchy can be inherited below.

A project is the main boundary for enabling APIs, assigning IAM access, tracking quotas, and attributing costs.

• The project name is a human-readable label that can be changed and need not be unique.
• The project ID is globally unique, chosen at creation, and cannot be changed later.
• The project number is a unique numeric identifier assigned by Google.
• Resources usually belong to one project even when they communicate with resources in another project.

A billing account pays for usage from linked projects, while budgets and exports help track that usage.

• A project must be linked to an active billing account to use most paid services.
• Costs are recorded by project and can be further attributed with labels and billing data.
• Budget alerts notify selected recipients at thresholds but do not automatically cap spending.
• Cloud Billing export can send detailed cost and usage rows to BigQuery for analysis.

A region is a geographic area, while a zone is an isolated deployment area within a region.

• A regional service can spread resources across zones, while a zonal resource lives in one zone.
• Separate zones reduce exposure to a single facility failure but do not replace cross-region planning.
• Choose a region based on user latency, data residency, service availability, and cost.
• Examples are the region us-central1 and the zone us-central1-a.

Quotas limit resource consumption or request rates to protect capacity and prevent accidental overuse.

• A quota may apply per project, region, service, or API metric.
• Examples include CPUs in a region and API requests per minute.
• Check quota usage before a planned deployment and request increases early because approval can take time.
• Monitor usage near the limit instead of treating a quota error as a reason to retry indefinitely.

Choose a machine family by matching the workload's CPU, memory, accelerator, and price needs.

• General-purpose families such as E2 or N series fit web servers and balanced workloads.
• Compute-optimized families fit CPU-heavy processing, while memory-optimized families fit large in-memory workloads.
• Machine types provide fixed vCPU and memory combinations, and supported families also offer custom shapes.
• Start from measured requirements and resize later rather than choosing the largest type by default.

A Compute Engine image is a reusable template for creating boot disks with an operating system and initial software.

• Public images are maintained by vendors such as Google, Debian, Ubuntu, and Microsoft.
• Custom images capture a configured disk so the same baseline can be reused across instances.
• An image family points to its latest non-deprecated image, which is useful for managed updates.
• Pin an exact image version when a deployment must be reproducible.

Compute Engine mainly uses persistent block storage for durable boot and data disks, with Local SSD for temporary high-speed data.

• Persistent Disk and Hyperdisk are separate resources, but an attached disk survives VM deletion only when its autoDelete setting is false.
• Balanced and SSD-backed options trade price, IOPS, and throughput for different workloads.
• Zonal disks reside in one zone, while regional persistent disks replicate across two zones in a region.
• Local SSD is physically attached and its data is ephemeral, so it must not hold the only copy of important data.

A snapshot is an incremental point-in-time backup of a persistent disk that can create new disks later.

• The first snapshot stores the needed blocks, and later snapshots store changed blocks while remaining independently usable.
• Snapshots are separate resources, so deleting the source disk does not automatically delete them.
• A restored disk can be created in a compatible zone or region chosen for the new workload.
• For databases, coordinate flushing or application-aware backup steps when crash consistency is not enough.

An instance template is a reusable VM configuration used to create consistent instances and managed instance groups.

• It can define the machine type, image, disks, metadata, network interfaces, and service account.
• Templates are immutable, so a configuration change requires a new template rather than editing the old one.
• Versioned templates make rollouts and rollbacks easier to understand.
• Keep secrets out of startup scripts and template metadata, and retrieve them through an approved secret service.

A managed instance group maintains a group of similar VMs from an instance template.

• A target size tells the group how many instances it should run.
• Autoscaling can adjust that size from signals such as CPU utilization or load-balancing capacity.
• Autohealing can recreate instances that fail a configured health check.
• Rolling updates replace instances gradually when the group moves to a new template.

Spot VMs suit interruptible workloads because they cost less but Google Cloud can stop them at any time.

• Good candidates include batch jobs, rendering, disposable workers, and fault-tolerant test workloads.
• They have no availability SLA and must not be the only capacity for a workload that cannot tolerate interruption.
• Save progress outside the VM and make work retryable so preemption does not lose the entire job.
• A mixed managed instance group can combine regular and Spot capacity when some stable capacity is required.

A GCP VPC is a global network that contains regional subnets and can connect resources across regions.

• The network is not created separately in every region.
• Each subnet owns an IP range in one region, and resources attach through that regional subnet.
• Routes and firewall rules belong to the VPC and can support communication between its regions.

No, a GCP subnet has no built-in public or private type.

• A VM's reachability depends on external IP assignment, routes, firewall rules, and the services around the subnet.
• A VM with no external IP cannot receive a direct unsolicited connection from the internet.
• Cloud NAT can provide outbound internet access for eligible resources without external IPv4 addresses.
• Private Google Access lets eligible internal IPs reach supported Google APIs without assigning an external IP.

Routes tell traffic matching a destination prefix which next hop to use.

• GCP creates subnet routes so resources can reach the IP ranges of VPC subnets.
• Custom static routes can point to next hops such as a VPN tunnel or appliance VM.
• Dynamic routes are learned through Cloud Router with BGP for hybrid connectivity.
• Route selection considers the most specific destination, while lower numeric priority wins among applicable routes of the same specificity.

VPC firewall rules allow or deny ingress or egress traffic, and a lower priority number has higher precedence.

• A rule specifies direction, action, protocols and ports, sources or destinations, and targets.
• Priority 1000 is evaluated before priority 2000 when both rules otherwise apply.
• VPC firewall rules are stateful, so allowed connection return traffic is permitted automatically.
• The network has implied deny ingress and allow egress behavior unless higher-priority rules change the result.

Firewall rules can target selected VM interfaces by network tag or by the VM's attached service account.

• A target tag applies the rule to instances carrying that tag in the same VPC.
• A target service account ties the rule to workload identity rather than an editable descriptive label.
• Network tags used by firewall rules are not IAM roles and are different from resource labels.

VPC Network Peering privately connects two VPC networks so their resources can communicate through internal IP addresses.

• It exchanges eligible subnet routes, so traffic stays on Google's network without requiring public IP addresses.
• Each VPC keeps separate IAM policies and firewall rules; peering does not merge administration or create allow rules.
• Peering is non-transitive: if VPC A peers with B and B peers with C, A cannot reach C through B.
• Peered networks cannot have overlapping subnet IP ranges, so address planning must happen before the connection.

Cloud DNS is Google's managed authoritative DNS service for publishing DNS records.

• A public managed zone answers queries from the internet, while a private zone is visible only to authorized VPC networks.
• Record sets map names to data such as A, AAAA, CNAME, MX, or TXT values.
• The TTL tells resolvers how long they may cache a record, so it affects how quickly a change is observed.

A Google Cloud load balancer accepts traffic on a frontend and distributes it to healthy backends.

• The frontend defines an IP address, protocol, and port that clients use.
• A backend service connects instance groups, network endpoint groups, or other supported backends to the load balancer.
• Health checks keep unhealthy backends from receiving new traffic.
• Application Load Balancers handle HTTP or HTTPS features, while Network Load Balancers serve Layer 4 traffic such as TCP or UDP.