Ensuring the successful operation of a cloud solution practice questions

Snapshot schedules are Compute Engine resource policies that automatically create incremental snapshots of a persistent disk on a defined cadence and delete them after a retention window.

A snapshot schedule attached to the disk takes the daily snapshot and enforces the 14-day retention without any scripts, cron jobs, or human action. Snapshots are incremental, so a 2 TB disk backs up efficiently after the first snapshot. Custom images and machine images are templates for provisioning rather than a rotation-managed backup mechanism, and rsync to Cloud Storage is an unmanaged, file-level workaround.

1. Create the policy: gcloud compute resource-policies create snapshot-schedule daily-backup --max-retention-days=14 --daily-schedule --start-time=03:00 --region=REGION.
2. Attach it to the disk: gcloud compute disks add-resource-policies DISK_NAME --resource-policies=daily-backup --zone=ZONE.
3. Verify snapshots appear daily with gcloud compute snapshots list and that ones older than 14 days are auto-deleted.

Exam tip: For automated periodic disk backups with retention, attach a snapshot schedule resource policy to the disk.

Custom images capture a configured boot disk as a reusable, geo-replicated template (a golden image) for provisioning identical Compute Engine instances anywhere.

Creating a custom image from the prepared boot disk gives the operations team a single artifact that every new VM, MIG, or instance template can reference, in any region, with guaranteed consistency. Snapshots are backups rather than a provisioning standard, instance templates require an image (they cannot point at a running VM), and startup-script rebuilds are slow and prone to drift.

1. Stop the VM (or use --force-create carefully) so the disk is consistent.
2. Create the image: gcloud compute images create golden-v1 --source-disk=DISK --source-disk-zone=ZONE.
3. Reference the image in instance templates or gcloud compute instances create --image=golden-v1 for new VMs in any region.
4. Optionally organize versions with an image family so templates always pick up the latest build.

Exam tip: Use custom images (optionally in an image family) as the golden build for launching identical VMs; snapshots are for backup.

Snapshots are standalone project resources managed with the gcloud compute snapshots command group; they survive disk deletion and accrue storage costs until explicitly deleted.

gcloud compute snapshots list supports --filter expressions on fields such as creationTimestamp, letting you find snapshots older than a cutoff date, and gcloud compute snapshots delete removes each one. Because snapshots are decoupled from their source disks, disk- or image-level commands cannot manage them, and no detachment is required before deletion.

1. List old snapshots: gcloud compute snapshots list --filter="creationTimestamp<'2026-05-01'" --format="value(name)".
2. Review the list to confirm none are needed for restores or compliance.
3. Delete them: gcloud compute snapshots delete SNAP1 SNAP2 ... (accepts multiple names).
4. Prevent recurrence by attaching snapshot schedules with --max-retention-days to active disks.

Exam tip: Old snapshots keep billing after their disks are gone — audit with snapshots list --filter and clean up with snapshots delete.

Cluster inventory in GKE is a kubectl task: gcloud manages the cluster resource itself, while kubectl queries the Kubernetes API for live objects like nodes, Pods, and Services.

kubectl get pods --all-namespaces (or -A) is the one command that enumerates every Pod regardless of namespace or owning controller, and the -o wide output format appends the NODE column you need. Node listings, gcloud describe output, and Deployment summaries each answer a different question and would miss Pods or their placement.

1. Fetch credentials: gcloud container clusters get-credentials CLUSTER_NAME --region=REGION.
2. Run kubectl get pods --all-namespaces -o wide to list every Pod with its node, IP, and status.
3. Follow up on any anomaly with kubectl describe pod POD -n NAMESPACE for events and details.

Exam tip: kubectl get pods -A -o wide is the fastest full-cluster Pod inventory, including node placement.

GKE nodes authenticate to Artifact Registry as the node pool's service account. Same-project pulls usually work via the default compute service account's project roles, but cross-project repositories require an explicit Artifact Registry read grant.

A 403 on image pull is an authorization failure: the node service account in team-apps has no roles/artifactregistry.reader binding in shared-registry. Granting that role on the repository (or the shared-registry project) lets kubelet pull the image and the Pods start. Node sizing is unrelated to a 403, imagePullSecrets with exported keys is an anti-pattern when IAM can authorize the pull, and API enablement matters in the repository's project and produces a different error.

1. Identify the node pool's service account: gcloud container node-pools describe POOL --cluster=CLUSTER --format="value(config.serviceAccount)".
2. Grant it read access: gcloud artifacts repositories add-iam-policy-binding REPO --project=shared-registry --location=LOCATION --member=serviceAccount:NODE_SA --role=roles/artifactregistry.reader.
3. Delete the failing Pods (or wait for backoff retry) so kubelet re-attempts the pull.
4. Confirm with kubectl get pods that the Pods reach Running.

Exam tip: ImagePullBackOff with a 403 on GKE means the node service account lacks roles/artifactregistry.reader on the image's repository.

In GKE Standard, hardware characteristics (machine type, GPUs, local SSD) are properties of a node pool. Heterogeneous workloads are served by running multiple node pools in one cluster.

Creating a GPU node pool with --accelerator adds GPU-equipped nodes alongside the existing pool. The ML Pods then request GPUs (resources.limits nvidia.com/gpu: 1) and use a node selector such as cloud.google.com/gke-accelerator to land on those nodes. Existing workloads and nodes are unaffected. Node pools cannot have accelerators bolted on after creation, Standard clusters don't provision hardware from Pod specs alone, and moving to Cloud Run is out of scope.

1. Create the pool: gcloud container node-pools create gpu-pool --cluster=CLUSTER --accelerator type=nvidia-l4,count=1 --machine-type=g2-standard-4 --num-nodes=1.
2. Ensure the NVIDIA device drivers are installed (GKE can auto-install them via the gpu-driver-version option).
3. Add resources.limits with nvidia.com/gpu: 1 and a gke-accelerator node selector to the inference Pod spec.
4. Apply the manifests and verify placement with kubectl get pods -o wide.

Exam tip: Add capabilities like GPUs to a GKE cluster by creating a dedicated node pool — node pool hardware can't be edited in place.