Ensuring Successful Operation of a Cloud Solution practice questions

Use bq load with an empty file to create the table, then insert data row by row.

Why wrong: Row by row insertion is extremely inefficient.

Export the original table to Cloud Storage as Avro, then load into the new table.

Why wrong: Exporting and loading is slower and incurs additional costs.

Use bq query --destination_table mydataset.newtable 'SELECT * FROM mydataset.original'

Why wrong: This method works but is less efficient than bq cp because it triggers a full table scan and rewrites the data, leading to query costs and slower performance for large tables.

resource.type="compute.googleapis.com/Instance" AND instance="my-instance" AND severity="ERROR"

Why wrong: Incorrect. 'instance' is not a valid field; the correct label is resource.labels.instance_id.

resource.type="gce_instance" AND resource.labels.instance_id="my-instance" AND severity="ERROR"

Why wrong: Incorrect. While the resource type and instance_id are correct, severity='ERROR' only matches exact ERROR level, missing higher severity logs. Use severity>=ERROR to include all error-level logs.

resource.type="gce_instance" AND labels."instance_id"="my-instance" AND severity="ERROR"

Why wrong: Incorrect. Uses labels."instance_id" which is not the correct path; it should be resource.labels.instance_id.

Cordon the node to prevent new pods

Why wrong: Cordoning a node only marks it unschedulable to prevent new pods from being assigned, but it does not evict or terminate existing pods. Although kubectl drain internally cordons the node as its first step, running cordon separately before drain is redundant and does nothing to prepare the node for maintenance. For maintenance you still need a drain to clear running workloads.

Use gcloud container clusters upgrade to upgrade the node

Why wrong: gcloud container clusters upgrade is a higher-level operation that updates the Kubernetes control plane or an entire node pool to a new version, and any node drainage during that process is handled automatically by GKE's rolling upgrade logic. It cannot be used to drain one specific node for routine maintenance, and running it would change the node's software version rather than simply clearing its workloads. Upgrading is a separate maintenance action that might occur before or after a drain, not a substitute for the drain itself.

resource.type = "compute.googleapis.com/Instance" AND severity = "ERROR"

Why wrong: The monitored resource type for Compute Engine instances in Cloud Logging is `gce_instance`, not `compute.googleapis.com/Instance`. The latter is the resource name in the Compute Engine API, not the Cloud Logging resource type. Using an incorrect resource.type means the query will not match any logs from your instances. The severity field itself is correctly specified.

type = "gce_instance" AND level = "ERROR"

Why wrong: This query uses `type` and `level`, which are not valid fields in Cloud Logging's filter syntax. Log entries store the resource type under `resource.type` and the severity under `severity`. Without the `resource.` prefix, `type` is not recognized, and `level` is not a field at all, so the query will fail to match any log entries.

resource.type=gce_instance AND severity=error

Why wrong: Severity values in Cloud Logging are case-sensitive and are reported as uppercase strings, such as `ERROR`, `WARNING`, and `INFO`. The filter `severity=error` with lowercase `error` will not match any logs because the actual value is `ERROR`. While the resource type `gce_instance` is correct, the severity value must be quoted and uppercase for the query to work.

gcloud compute disks snapshot my-disk --snapshot-names my-snapshot --zone us-central1-a

Why wrong: This is the correct command to create a snapshot from a persistent disk in the specified zone. The 'snapshot' verb under 'gcloud compute disks' accepts the disk name as the positional argument, and the '--snapshot-names' flag names the new snapshot. Snapshots are incremental backups stored in Cloud Storage, capturing only changes since the last snapshot, which makes them efficient for backup and disaster recovery. The zone must be provided because a zonal disk's location dictates where the snapshot operation runs.

gcloud compute images create my-snapshot --source-disk my-disk --zone us-central1-a

Why wrong: This command creates a custom machine image or a custom image, not a snapshot. Images are full standalone copies of a disk (including OS, applications, and files) that can be used to create new instances, whereas snapshots are incremental and only store changes since the previous snapshot. Even if this command succeeds, it won't provide the cost-efficient, backup-oriented snapshot behavior you need. The '--source-disk' flag is valid for image creation, but the intended resource type and command structure differ.

gcloud compute disks create-snapshot my-disk --snapshot-name my-snapshot --zone us-central1-a

Why wrong: The verb 'create-snapshot' is not recognized by the gcloud CLI under the 'disks' resource; the correct verb is 'snapshot'. Additionally, the flag for naming a snapshot is '--snapshot-names' (plural), which accepts a comma-separated list, not '--snapshot-name' (singular). This command would fail syntax validation because both the subcommand and the flag are incorrect. Always use 'gcloud compute disks snapshot' followed by the disk name.

resource.type="gce_instance" AND severity="ERROR" AND "instance" AND timestamp>="-1h"

Why wrong: This filter uses the bare quoted term "instance" as a text substring, which matches the word "instance" in nearly every Compute Engine log entry—including resource labels, resource.type, and messages such as disk-full or network errors. As a result, it fails to isolate the specific startup failure and will return many unrelated ERROR logs. The correct approach requires a unique error phrase like "Could not start instance" to narrow the search to the actual failure event.

resource.type="gce_instance" AND "instance" AND timestamp>="-1h"

Why wrong: This filter lacks a severity constraint, so it returns log entries of every level—DEBUG, INFO, WARNING, ERROR, and CRITICAL—that mention "instance" within the last hour. This includes normal startup completion, routine health checks, configuration changes, and other benign messages, producing an overly broad and noisy result set. To identify only failures to start an instance, severity="ERROR" is essential, not optional.

resource.type="gce_instance" AND severity="ERROR" AND "startup"

Why wrong: This filter is missing the timestamp>="-1h" condition entirely, so it searches across the full log retention period rather than just the past hour as required. Additionally, the term "startup" is overly vague: it can appear in messages about startup scripts, successful boots, or unrelated operations, and it does not exactly match the specific error text "Could not start instance". Thus the filter is both temporally incorrect and textually imprecise for this query.

gcloud compute instances suspend

Why wrong: The gcloud compute instances suspend command is not a valid subcommand in the gcloud CLI for Compute Engine. While the Compute Engine API supports a 'suspend' operation to pause a running VM while preserving its memory state, it must be invoked via the Cloud Console or a direct API call, not through gcloud. Attempting to run this command will produce a parsing error, so it cannot be used to reduce costs by stopping the instance.

gcloud compute instances delete

Why wrong: The delete command permanently removes the instance resource from your project, and by default also deletes its boot disk and any attached persistent disks unless you explicitly specify --keep-disks=all. This is an irreversible, destructive action that would not just temporarily reduce costs but also risk losing the VM's disk data and configuration. Because the goal is to stop and later restart the instance, deleting it would require recreating everything from scratch, so it is not a valid way to pause costs.

gcloud compute instances reset

Why wrong: The reset command forcibly restarts the instance by performing a hard reset of the virtual hardware, analogous to pressing the physical reset button on a server. It does not change the instance's billing status; the VM continues running, and you keep paying for the resources it consumes. While reset might be used to recover from an unresponsive state, it is unrelated to stopping an instance and will not reduce costs.

storage.objectViewer

Why wrong: The storage.objectViewer role is the correct predefined IAM role for users who need to inspect the exported log files. It grants read access to object contents and metadata, enabling you to list, view, and download the log objects without allowing any modifications. This aligns with the principle of least privilege for a viewer-only workflow.

storage.legacyBucketReader

Why wrong: The storage.legacyBucketReader role is a legacy role that only provides read access to bucket metadata and the ability to list objects, not to read the objects themselves. It cannot be used to view the contents of the exported log files, so it is insufficient for this task. Google recommends using the modern storage.objectViewer role instead, as legacy roles are less granular and deprecated in policy recommendations.

storage.admin

Why wrong: The storage.admin role is far too broad for this scenario because it grants full control over the bucket, including deleting the bucket, modifying IAM policies, and managing lifecycle configurations. Granting this role to a log sink or a log viewer violates the principle of least privilege and introduces unnecessary security risks. For exporting logs, only storage.objectCreator is needed; for viewing, only storage.objectViewer is needed.

storage.legacyBucketWriter

Why wrong: The storage.legacyBucketWriter role is a legacy role that provides write access to the bucket, including the ability to create and delete objects, but it is not scope-limited to the sink's needs. It is overly permissive and not the recommended practice; the storage.objectCreator role gives precisely the minimal create-only permission required for the log sink. Additionally, using legacy roles is discouraged because they do not align with modern fine-grained IAM design.

gcloud run revisions update revision-2 --traffic=10

Why wrong: The `gcloud run revisions update` command is used to modify configuration of a specific revision, such as concurrency, timeout, or VPC connector settings, but it does not support a `--traffic` flag. Traffic routing is a service-level attribute, not a revision-level attribute; a revision itself is immutable and cannot have a traffic share assigned to it directly. Attempting this would either fail with an unknown flag or have no effect on routing.

gcloud run services set-iam-policy SERVICE policy.yaml

Why wrong: IAM policies control authentication and authorization—who can invoke or manage a Cloud Run service—but they have no influence over how request traffic is distributed across revisions. Traffic splitting is defined in the service's traffic specification, which is separate from IAM bindings. Setting an IAM policy would leave the existing traffic split unchanged, so it cannot accomplish the required 90/10 allocation.

gcloud run deploy SERVICE --image=IMAGE --no-traffic

Why wrong: Deploying with `--no-traffic` creates a new revision and assigns it 0% traffic, leaving all existing traffic on the previously active revision. This does not split traffic between the old revision and the newly deployed revision; it simply stages the new revision for later rollout. After this command, you would still need to run a separate traffic update, such as `gcloud run services update-traffic` or `--to-revisions`, to achieve the desired 90/10 split.

kubectl drain NODE --force

Why wrong: --force is used to bypass checks that would otherwise prevent drain, but it does not automatically handle DaemonSet pods or emptyDir volumes. Using --force alone may cause disruption to critical system components.

kubectl drain NODE --ignore-daemonsets

Why wrong: --ignore-daemonsets ignores DaemonSet-managed pods, but pods with emptyDir volumes will still block the drain unless --delete-emptydir-data is also specified.

kubectl drain NODE --delete-emptydir-data

Why wrong: --delete-emptydir-data allows eviction of pods with emptyDir volumes, but DaemonSet pods are not ignored and may prevent the drain from completing.

Drain all nodes in the node pool using kubectl drain

Why wrong: Manually draining a node pool with `kubectl drain` is not a required step for a standard GKE node pool upgrade because GKE's upgrade process automatically cordons and drains nodes as part of its rolling replacement. If you drain all nodes upfront, you will deliberately remove pods and the nodes will enter a NotReady/scheduling-disabled state, causing unnecessary workload downtime while the upgrade machinery is still preparing replacement nodes. Draining is only needed for manual node maintenance or when you want to deliberately empty a pool for decommissioning, not as a prerequisite for an automatic upgrade.

Create a new node pool and migrate workloads

Why wrong: Creating a brand-new node pool and migrating workloads is a blue/green migration strategy, not a standard step in an in-place upgrade. It is overkill for a routine node pool upgrade because GKE already supports rolling upgrades directly on the existing pool with configurable surge and max-unavailable settings. Moreover, migrating workloads to a new pool would require re-creating the pool, possibly re-attaching persistent disks, and manually moving deployments or using node selectors — none of which are needed when GKE can simply replace nodes in situ. This approach is typically reserved for major version jumps or when you need to change machine type or other immutable node pool settings, not for the typical upgrade process.

The notification channel is not configured to use a Pub/Sub topic

Why wrong: The notification channel is not configured to use a Pub/Sub topic. In Cloud Monitoring, a Pub/Sub channel sends alert messages to a specified topic, and a separate subscriber must forward them to Slack. If the channel type is something else, the topic does not exist, or the service agent lacks permission to publish, the alert fires but no Slack message is delivered. This precisely explains the silent failure.

The log-based alert is not using a valid metric threshold

Why wrong: The log-based alert is not using a valid metric threshold. A log-based alert may indeed use a logs-based metric with a threshold, but an invalid threshold would cause an error when the alert is created or updated, not a silent failure to notify Slack. The alert condition and the notification routing are independent; an invalid threshold would prevent triggering, not the delivery of a triggered alert.

The log query is case-sensitive and mismatched

Why wrong: The log query is case-sensitive and mismatched. A case-sensitive query affects whether log entries match and the alert fires at all; it does not affect how an already-fired alert reaches Slack. If the query were mismatched, you would see no incidents in Cloud Monitoring, but the question describes a failure specifically in Slack notification, pointing to the delivery channel instead.

gcloud functions deploy

Why wrong: gcloud functions deploy is used exclusively for Cloud Functions, a separate serverless product that runs single-purpose functions, not containerized workloads. Cloud Run services are deployed from container images, and their resource settings are managed with Cloud Run-specific commands, so this command cannot increase CPU or memory for a Cloud Run service.

gcloud run deploy

Why wrong: gcloud run deploy is intended for releasing a new revision by building or pulling a container image and then deploying it to a Cloud Run service. While it can update a service's configuration as a side effect, its primary purpose is to ship code changes. For a targeted update to existing service settings like CPU and memory without a container build, the dedicated command is gcloud run services update.

gcloud run revisions update

Why wrong: gcloud run revisions update is not a valid gcloud CLI command because Cloud Run revisions are immutable snapshots of a service's container image and configuration. Once a revision is created, its CPU and memory settings cannot be changed in place; the CLI supports only listing, describing, and deleting revisions. To change resource limits, you must update the service, which creates an entirely new revision.

--dry-run --now

Why wrong: --dry-run would only simulate the drain operation and report what would happen, leaving the node fully schedulable and the critical workload untouched; --now is not a valid kubectl drain flag (it belongs to kubectl delete for immediate pod removal). As a result, this pair would not perform any actual node maintenance, so it cannot be the correct answer.

--force --grace-period=0

Why wrong: --force --grace-period=0 is an unsafe, abrupt deletion strategy rather than a proper drain. While kubectl drain does accept --force to override unmanaged pods, combining it with a zero grace period forces immediate termination of running containers, bypassing PodDisruptionBudgets and graceful shutdown hooks, which can crash a critical workload and cause data loss or downtime.

--all-namespaces --selector

Why wrong: --all-namespaces and --selector are resource-filtering flags for kubectl get/delete across multiple namespaces, but kubectl drain operates on a named node and does not accept these options. Passing them to a drain command would cause a flag error or silently select pods across namespaces, so the targeted GKE node would never actually be cordoned or drained.

Detach the disk from the instance

Why wrong: Detaching the disk from the instance while it is running does not quiesce in-flight I/O; the application may still have open file handles or cached writes, so the disk image captured could be inconsistent. Furthermore, detaching a disk that is actively mounted can trigger I/O errors and kernel panics as the guest OS tries to access a missing device. The best practice is to stop the VM, not detach the disk, to ensure a clean, crash-consistent snapshot.

Enable guest OS features for the instance

Why wrong: Guest OS features, such as virtual CPU hotplug or the NVMe interface, are metadata flags that tell the hypervisor which capabilities the OS supports; they have no effect on snapshot consistency. Enabling these features does not cause the guest OS to flush buffers or sync file systems, so the snapshot remains crash-consistent but not application-consistent. They are irrelevant to the snapshot creation process itself.

Use the --no-pause flag when creating the snapshot

Why wrong: The `--no-pause` flag does not exist in the `gcloud compute snapshots create` command; valid options include `--source-disk`, `--storage-location`, and `--snapshot-type`. Pausing a VM is unrelated to creating a snapshot, and no such flag is needed to ensure consistency. To get a crash-consistent snapshot, you should stop the VM rather than rely on non-existent flags.

resource.type:gce_instance AND severity:ERROR

Why wrong: The colon operator ':' in Cloud Logging is not equality but the 'has' operator, which checks for substring presence rather than exact value. Thus resource.type:gce_instance could match a resource type that merely contains that text, and severity:ERROR does not guarantee the severity equals ERROR. To demand exact equality, you must use '=' as in the correct filter.

resource.type == 'gce_instance' && severity == 'ERROR'

Why wrong: Cloud Logging filter syntax does not accept '==' for equality or '&&' for logical AND; it expects single '=' and the keyword AND. Even though the field names resource.type and severity are correct, the operators are invalid, so Cloud Logging would reject the query or require using valid syntax. Use parentheses and the AND keyword if you need to combine conditions.

type='gce_instance' AND level='ERROR'

Why wrong: This query uses valid operators but references incorrect field names. The monitored resource type is stored in the resource.type field, not a top-level 'type' field, and the log severity is exposed as 'severity', not 'level'. Without the proper field names, Cloud Logging will not match any error logs, even if all other syntax is correct.

Stop the VM before taking each snapshot

Why wrong: Stopping the VM before taking each snapshot is the correct procedure because it ensures crash consistency across all attached disks. When a VM is running, in-memory state and pending I/O operations may not be flushed to disk; a snapshot taken at that moment can capture an inconsistent state where some writes are present and others are not. By shutting down the instance cleanly, all applications flush their data and file systems are in a quiesced state, so the snapshot is a reliable recovery point. After the snapshot is completed, the VM can be restarted.

Use gcloud compute images create to create a custom image from the snapshot, then export to a different region

Why wrong: Using `gcloud compute images create` to create an image from the snapshot and then exporting it to a different region is not the standard or most direct DR method. Images are designed for boot disks and instance templates, not for general-purpose cross-region backup of stateful data. While an image can be exported to Cloud Storage and then imported, that process is more cumbersome and does not preserve snapshot-specific metadata like incremental snapshots. Directly copying the snapshot with `--source-snapshot` is simpler, faster, and maintains snapshot capabilities such as incremental backups.

Use gcloud compute snapshots create with the --source-disk flag while the VM is running

Why wrong: Using `gcloud compute snapshots create` with the `--source-disk` flag while the VM is running does not guarantee crash consistency, even though it can complete successfully. Snapshots taken from a live VM capture only what has already been written to disk at the moment the snapshot is taken, which may be in the middle of a write operation. This can result in corrupted data or an inconsistent filesystem state, making the snapshot unreliable for recovery. The recommended practice is to stop the VM before snapshotting, as the correct answer indicates, or to use a crash-consistent snapshot feature if the VM is shut down.

resource.type="gce_instance" severity=ERROR timestamp>="-1h"

Why wrong: severity=ERROR only matches exactly ERROR, not WARNING or CRITICAL. The requirement is 'ERROR or higher'.

resource.type="compute.googleapis.com/Instance" severity>=ERROR timestamp<"-1h"

Why wrong: resource.type format is incorrect; it should be gce_instance. Also timestamp<"-1h" would exclude logs from the last hour.

resource.labels.instance_id="*" severity>=ERROR timestamp>="-3600s"

Why wrong: instance_id wildcard is not standard; resource.type must be specified. Using seconds is acceptable but not the primary issue.

1. gcloud compute snapshots create backup-snapshot --disk DISK_NAME 2. gcloud compute instances set-machine-type VM_NAME --machine-type n1-standard-8 3. gcloud compute instances start VM_NAME

Why wrong: set-machine-type requires the instance to be stopped, but the instance is running. Also snapshot while running may cause inconsistent data.

1. gcloud compute instances stop VM_NAME 2. gcloud compute snapshots create backup-snapshot --source-disk DISK_NAME --source-disk-zone ZONE 3. gcloud compute instances set-machine-type VM_NAME --machine-type n1-standard-8 4. gcloud compute instances start VM_NAME

Why wrong: The snapshot command uses --source-disk flag incorrectly. Should be --disk. The snapshot creation before changing machine type is acceptable, but syntax error makes it wrong.

1. gcloud compute instances set-machine-type VM_NAME --machine-type n1-standard-8 2. gcloud compute snapshots create backup-snapshot --disk DISK_NAME 3. gcloud compute instances start VM_NAME

Why wrong: set-machine-type on a running instance will fail; snapshot after change would capture the new machine type's disk? Not relevant.

Upgrade the control plane to the latest version

Why wrong: Autoscaling does not require a control plane upgrade.

Run gcloud container clusters update CLUSTER_NAME --node-pool POOL_NAME --enable-autoscaling

Why wrong: Incorrect syntax; node-pool updates use gcloud container node-pools update, not cluster update.

Set the --autoscaling-profile option to 'optimize-utilization'

Why wrong: This is an optional profile setting, not a required step.