Ensuring the successful operation of a cloud solution

Several Pods in a GKE Standard cluster stay in the Pending state because no existing node has enough free CPU to schedule them. Which mechanism is responsible for adding capacity, and on what basis does it act?

• AThe cluster autoscaler, because it adds nodes to a node pool when Pods cannot be scheduled for want of resources, and later removes nodes that stay underutilised.check_circle Correct
• BThe Horizontal Pod Autoscaler, because it watches aggregate node CPU and provisions extra nodes into the pool once utilisation crosses its configured target.
• CThe Vertical Pod Autoscaler, because it recreates the Pending Pods with smaller resource requests until they fit onto the nodes that already exist.
• DThe kube-scheduler, because when it finds no fit it directly requests a new Compute Engine VM and binds the Pending Pods to it as soon as the VM registers.

Why A is correct: The cluster autoscaler resizes node pools based on scheduling pressure, adding nodes when Pods are unschedulable due to insufficient resources and removing nodes that remain underutilised.

Why B is wrong: This is tempting because the HPA reacts to CPU, but it scales Pod replica counts, not nodes, so it cannot resolve Pending Pods caused by a shortage of node capacity.

Why C is wrong: The VPA does adjust resource requests, but it is meant to right-size Pods rather than force-fit them, and it does not add the node capacity the Pending Pods actually need.

Why D is wrong: The scheduler only assigns Pods to nodes that already exist and reports failures when none fit; it does not create VMs, which is the cluster autoscaler's job.

An engineer deployed a Cloud Run revision named orders-blue with --no-traffic and verified it. Live traffic still sits entirely on orders-green. They now want a canary that sends 10 percent of requests to orders-blue while orders-green keeps the remaining 90 percent. Which command achieves this split?

gcloud run services update-traffic orders <FLAGS>

• AUse --update-traffic=orders-blue=10 because that is the documented subcommand flag for assigning a weighted percentage to a single named revision.
• BUse --to-latest so the most recently deployed revision immediately begins receiving the standard canary share of the incoming production traffic.
• CUse --to-revisions=orders-blue=10,orders-green=10 so both revisions are pinned and the platform normalises the two equal weights across the service.
• DUse --to-revisions=orders-blue=10 so Cloud Run routes 10 percent to orders-blue and automatically leaves the balance on the currently serving revision orders-green.check_circle Correct

Why A is wrong: Tempting as a plausible flag name, but --update-traffic is not a real flag on this subcommand; the split is expressed with --to-revisions and would fail as written.

Why B is wrong: Tempting because orders-blue is the latest revision, but --to-latest sends 100 percent to it rather than a 10 percent slice, which is a full cutover, not a canary.

Why C is wrong: Tempting because it names both revisions, but the weights must total 100; two values of 10 do not sum correctly and the command is rejected rather than normalised.

Why D is correct: Correct: naming only orders-blue=10 assigns it 10 percent, and Cloud Run keeps the remaining 90 percent on the existing serving revision, giving the intended canary split.

An administrator wants a lifecycle rule to act only on objects created before 1 January 2025, regardless of their current age. Which lifecycle condition expresses this?

• AThe age condition set to the number of days since 1 January 2025, because age measures the calendar cut-off date for the rule.
• BThe matchesStorageClass condition set to a date value, because it filters objects by the date on which they entered their storage class.
• CThe createdBefore condition set to 2025-01-01, because it selects objects whose creation time is earlier than the given date.check_circle Correct
• DThe numNewerVersions condition set to the target date, because it selects objects generated before the specified calendar date.

Why A is wrong: The age condition counts days since each object was created, not a fixed calendar date, so it cannot pin the rule to objects made before a specific day.

Why B is wrong: matchesStorageClass filters by storage class name, not by any date, so it cannot select objects according to when they were created.

Why C is correct: createdBefore matches objects created earlier than the supplied date, so it targets exactly the pre-2025 objects independent of how old each one is now.

Why D is wrong: numNewerVersions counts how many newer noncurrent generations exist and takes an integer, not a date, so it cannot express a creation-date cut-off.

An SRE team runs a fleet of Compute Engine VMs and wants to be paged when sustained CPU pressure indicates the fleet is undersized. They decide the failure condition is any instance whose CPU utilisation stays above 90 percent for 5 minutes. Which Cloud Monitoring alerting policy condition matches this requirement?

• AA metric-absence condition on compute.googleapis.com/instance/cpu/utilization that fires when the metric stops reporting for a rolling 5 minute window.
• BA metric-threshold condition on the instance CPU utilisation metric that fires when the value is above 0.9 for 5 minutes.check_circle Correct
• CA log-based alerting policy that counts Cloud Logging entries containing the phrase high cpu and triggers once the count passes 90 in 5 minutes.
• DAn uptime check against each VM that reports the instance unhealthy whenever its processor load climbs past the 90 percent mark.

Why A is wrong: Tempting because it names the right CPU metric and a 5 minute window, but metric absence alerts on missing data, not on a value staying above a threshold, so it never detects high utilisation.

Why B is correct: Correct: a threshold condition on the resource CPU metric with a comparison of above 0.9 and a 5 minute duration is exactly how Cloud Monitoring detects a sustained breach and opens an incident.

Why C is wrong: Tempting because it mentions CPU and a count, but CPU utilisation is a numeric time series, not a log entry, so a log-based policy cannot read the metric or its percentage threshold.

Why D is wrong: Tempting as a health signal, but uptime checks probe an endpoint for reachability and latency; they do not read CPU utilisation and cannot evaluate a processor threshold.

A fleet of Compute Engine virtual machines has no external IP addresses, yet the operations team needs them to download operating-system patches from public repositories on the internet. Which Google Cloud service provides this outbound connectivity?

• ACloud DNS, which resolves public hostnames to IP addresses so the private instances can locate the repositories they must reach.
• BA custom static route with the default internet gateway as its next hop, granting the instances a usable path outward.
• CAn external HTTP load balancer, which fronts the instances with a public address and forwards their outbound patch requests.
• DCloud NAT, which lets instances without external IP addresses initiate outbound connections to the internet while blocking unsolicited inbound traffic.check_circle Correct

Why A is wrong: Name resolution is only part of the problem; Cloud DNS returns an address but provides no path for a machine with no external IP to actually route packets to the internet.

Why B is wrong: The default route to the internet gateway already exists, but it is only usable by instances that hold an external IP, so adding another such route changes nothing for address-less machines.

Why C is wrong: A load balancer distributes inbound client traffic to backends and does not provide instance-initiated egress, so it cannot pull patches out on the machines' behalf.

Why D is correct: Cloud NAT performs source network address translation for egress, so private instances reach public endpoints without any external IP being assigned to them.