4 of the 8 questions we have for this objective, shown with the answer and the reasoning.
Configuring compute systems
Cobalt Ridge Manufacturing has 300 long-lived Compute Engine VMs running a mix of Windows Server and Linux across several projects. Production VMs carry the label env=prod. Security policy requires critical OS updates to be applied every Saturday between 01:00 and 04:00, one zone at a time, with a report of which VMs succeeded or failed. The team wants to use a managed Google Cloud service rather than custom scripts.
What should you configure?
- AA startup script on each VM that installs available updates whenever the VM bootsStartup scripts run only at boot, so long-lived VMs would rarely be patched, and there is no schedule, zone-by-zone rollout, or compliance reporting.
- BA Cloud Scheduler job that calls a Cloud Run functions function to reboot all env=prod VMs each SaturdayRebooting VMs does not install updates by itself, and building rollout logic and reporting in a custom function is the scripted approach the team wants to avoid.
- CWeekly recreation of every VM from the latest public image familyImage-based replacement suits stateless managed instance groups, but these are long-lived individual VMs whose state would be lost or need migration on every rebuild.
- DVM Manager OS patch management with a recurring patch deployment that targets VMs labeled env=prod, a Saturday 01:00 schedule with a three-hour duration, and a zone-by-zone rolloutOS patch management in VM Manager schedules patch jobs for Windows and Linux VMs, filters targets by labels, supports zonal rollouts and maintenance windows, and reports per-VM patch results.
Why: VM Manager is the Compute Engine suite for fleet operations, and its OS patch management service is designed for patching long-lived VMs at scale. A patch deployment defines targets with instance filters such as labels and zones, a recurring schedule and duration, rollout options that patch zone by zone, and per-OS settings such as Windows update classifications. Results are visible in the patch job details and the patch compliance dashboard. Image-based replacement is the better practice for immutable, stateless fleets, but it does not fit long-lived VMs like these.
Configuring compute systems
Petalworks, an online florist, lets customers upload photos to a Cloud Storage bucket named uploads-raw. Each photo must be resized into three thumbnails within seconds of upload. Uploads are bursty and sometimes stop for hours, and the company wants no servers to manage and to pay nothing when there are no uploads.
Which solution should you implement?
- AA Cloud Run functions function triggered by the Cloud Storage object finalized event on uploads-rawAn event-driven function runs once per new object within seconds, scales automatically with bursts, scales to zero when idle, and requires no server management.
- BA Compute Engine VM that polls uploads-raw every minute and processes new objectsA polling VM runs and bills continuously, adds latency, and must be patched and managed.
- CA Cloud Scheduler job that runs a Cloud Run job every hour to process new uploadsAn hourly batch cannot produce thumbnails within seconds of each upload.
- DA GKE Standard cluster running a Deployment that watches uploads-raw through Pub/Sub notificationsThe design would work, but it requires running and paying for cluster nodes even when no photos arrive, which conflicts with the cost and management constraints.
Why: Event-driven, short-lived processing of storage events is the core use case for Cloud Run functions. The function subscribes to the object finalized event through Eventarc, so each upload invokes it with the object details, and the platform handles scaling from zero to many instances. You pay only while invocations run, which matches bursty traffic with long idle periods. Polling and scheduled designs are the usual distractors because they work, but they fail the latency or cost constraint.
Configuring compute systems
Larchmont Learning is moving a customer-facing course API to GKE Standard. The API runs as a Deployment with six replicas. During the last pilot, a zonal cluster's control plane was unavailable during a version upgrade, and node upgrades briefly took too many replicas offline at once. The business requires the API and the Kubernetes API server to stay available through upgrades and through the loss of a single zone.
Which two actions should you perform? Each correct answer presents part of the solution.
- ACreate the cluster as a regional cluster with nodes in three zonesA regional cluster replicates the control plane across zones and spreads nodes across zones, so control plane upgrades and a single zone loss do not make the API server or all replicas unavailable.
- BCreate a PodDisruptionBudget for the API Deployment with minAvailable set to 4A PodDisruptionBudget limits how many replicas voluntary disruptions such as node drains during upgrades can take down at once.
- CCreate a zonal cluster with a node pool that spans three zonesA multi-zonal node pool spreads nodes, but a zonal cluster still has a single control plane that is unavailable during its upgrades and lost if its zone fails.
- DDisable node auto-upgrade and remove the cluster from all release channelsAvoiding upgrades leaves the cluster behind on security fixes, and GKE still upgrades clusters that reach end of support, so this does not provide availability during upgrades.
- ERun the API as a DaemonSet instead of a DeploymentA DaemonSet runs one Pod per node and does not provide disruption control during drains, so it does not address either problem.
Why: GKE availability through upgrades has two layers. The cluster layer is decided at creation: regional clusters run multiple control plane replicas across zones, so the Kubernetes API stays available during control plane upgrades and zone failures, while zonal clusters do not. The workload layer is controlled with PodDisruptionBudgets, which GKE respects when it drains nodes during surge upgrades, together with enough replicas spread across zones. Turning off upgrades is a tempting distractor, but it trades short-term stability for security risk and is not supported indefinitely.
Configuring compute systems
Northgate Media runs a VPC-native GKE Standard cluster named media-prod in subnet gke-subnet, with a Pod secondary range of /20 and the default maximum of 110 Pods per node. After a traffic increase, the cluster autoscaler cannot add nodes, and events show that the Pod IP address range is exhausted. The node subnet still has plenty of free addresses. The cluster cannot be recreated or taken offline.
What should you do to let the cluster add nodes?
- AExpand the primary IP range of gke-subnetThe primary range supplies node IP addresses, which are not the constraint; Pod IP addresses come from the secondary range, so expanding the primary range does not help.
- BConvert media-prod to a routes-based cluster so Pods use custom static routes instead of alias IP rangesAn existing VPC-native cluster cannot be converted to routes-based networking, and routes-based clusters are a legacy mode with route quotas that make them a poor choice.
- CAdd a new secondary range to gke-subnet and create a new node pool that uses it as an additional Pod IPv4 rangeDiscontiguous multi-Pod CIDR lets a node pool use a Pod range other than the cluster default, so new nodes receive Pod addresses from the added range without recreating the cluster.
- DCreate a Cloud NAT gateway for gke-subnet so Pods share the node IP addressesCloud NAT handles outbound internet traffic and does not change how GKE allocates Pod IP addresses to nodes.
Why: In a VPC-native cluster each node reserves a block of Pod addresses from a secondary range, sized from the maximum Pods per node; with 110 Pods per node each node takes a /24, so a /20 Pod range supports only 16 nodes. When the Pod range is exhausted, GKE lets you add more Pod address space by attaching an additional secondary range to the subnet and creating node pools that use it, which is called discontiguous multi-Pod CIDR. Lowering the maximum Pods per node on new node pools is another lever because it shrinks each node's block. The primary subnet range and NAT are common traps because they look like IP fixes but address different traffic.