Ensuring Successful Operation of a Cloud Solution practice questions

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

Why it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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.

gcloud run revisions traffic my-service --to-revision new-revision --percent 10

Why it fails: The `gcloud run revisions traffic` command does not exist; the `gcloud run revisions` group only manages revision lifecycle operations such as listing and describing. Traffic routing is a service-level setting, not a revision-level one, so it must be adjusted with `gcloud run services update-traffic`. Running this command will fail with a usage error because `traffic` is not a recognized subcommand of `gcloud run revisions`.

gcloud run services update my-service --image gcr.io/my-project/my-image:new

Why it fails: The `gcloud run services update` command with the `--image` flag deploys a new revision, but it does not let you explicitly control the percentage of traffic that revision receives. This command shifts traffic according to the service's deployment strategy, typically all or nothing, and cannot specify a 10% slice to a particular revision. To set a precise traffic percentage to a named revision, `gcloud run services update-traffic` is required.

gcloud run deploy my-service --image gcr.io/my-project/my-image:new --traffic new-revision=10

Why it fails: The `gcloud run deploy --traffic` flag is intended for the initial deployment of a service, not for adjusting traffic on an existing service. When used on a service that already exists, it does not reliably set 10% of traffic to `new-revision` because it triggers a new deployment and may reset the traffic configuration. The recommended way to change the split on a live service is `gcloud run services update-traffic`.

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

Why it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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.

Pub/Sub

Why it fails: Pub/Sub is the correct notification channel type for this use case because Cloud Monitoring can send alert notifications to a Pub/Sub topic, and a separate subscriber (such as a Cloud Function or Cloud Run service) can then forward those messages to Slack using an incoming webhook. Unlike email or PagerDuty, Pub/Sub is not a direct end-user notification mechanism; instead it acts as a highly scalable, event-driven integration bus that decouples alert generation from downstream delivery. This pattern is the officially recommended way to connect Cloud Monitoring alerts to Slack, since Slack has no native notification channel in Cloud Monitoring.

PagerDuty

Why it fails: PagerDuty is an incorrect choice here because Cloud Monitoring supports PagerDuty as a first-class notification channel type, meaning alerting sends an HTTP webhook directly to PagerDuty's API without needing Pub/Sub as an intermediary. The question is about delivering alerts to Slack, not PagerDuty, and unlike Slack, PagerDuty has its own native integration. Even though Pub/Sub could theoretically be used to feed PagerDuty, doing so would bypass the built-in integration and add unnecessary complexity, so it would not be the appropriate solution for a Slack destination.

Email

Why it fails: Email is a direct notification channel in Cloud Monitoring that sends alert messages to configured email addresses via the Cloud Monitoring backend. While it is a native channel type, it is wrong for this question because email delivers to an inbox, not to a Slack channel; it cannot be used to post messages into Slack unless you manually forward or use a separate email-to-Slack gateway. Additionally, email is a push notification mechanism from Cloud Monitoring itself, and it does not leverage Pub/Sub, which is the key requirement for the desired Slack integration. Thus, email is incorrect because it neither targets Slack nor uses Pub/Sub as the delivery mechanism.

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

Why it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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.

kubectl apply -f updated-deployment.yaml

Why it fails: kubectl apply -f updated-deployment.yaml requires a pre-modified manifest file. This is a declarative command that reconciles the file's state with the cluster, so you must manually edit the YAML to include the new image before running it. It does not accept an image flag and is not the direct, imperative command the question asks for. It may also produce unintended changes if the file is not aligned with the live resource's last-applied-configuration.

kubectl update deployment my-app --image=my-image:v2

Why it fails: kubectl update is an invalid subcommand in kubectl—no such verb exists. The correct imperative verb for modifying an image is set image, not update. Even if you meant set image, the syntax requires a container name in the form CONTAINER=IMAGE, so this command lacks that component. Running it would fail with an unknown command error, never reaching the deployment.

kubectl edit deployment my-app --image=my-image:v2

Why it fails: kubectl edit opens the deployment's manifest in an interactive editor; it does not accept an --image flag. The --image argument would be treated as an unrecognized flag, causing the command to error out before opening the editor. Even if you used the editor, it would be a manual, interactive process rather than a single nondestructive command. For an automated update, kubectl set image or kubectl patch are the appropriate choices.

storage.objectViewer

Why it fails: 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 it fails: 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 it fails: 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 it fails: 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.

kubectl apply -f updated-deployment.yaml and kubectl rollout undo

Why it fails: While `kubectl apply -f updated-deployment.yaml` does update the Deployment from a manifest (a declarative approach), `kubectl rollout undo` reverts the Deployment to a previous revision rather than verifying that the freshly applied update completed. Executing an undo after an apply would deliberately roll back the very change you just made, so it cannot confirm the new rollout succeeded. To monitor progress, you would need `kubectl rollout status deployment/my-deployment`, not an undo.

kubectl edit deployment and kubectl rollout history

Why it fails: `kubectl edit deployment` opens the current Deployment definition in an editor so you can manually change fields like the container image, but it does not itself report when or whether the resulting rollout finishes. `kubectl rollout history` only lists the existing revisions and their change causes; it does not show live rollout progress, pod readiness, or whether the latest update has reached the desired state. Therefore, you lack confirmation of completion; `kubectl rollout status` or `kubectl rollout status deployment/my-deployment` is needed for that.

kubectl run my-deployment --image=gcr.io/my-project/my-image:v2 and kubectl get pods

Why it fails: `kubectl run my-deployment --image=...` is a convenience command that creates a brand-new Deployment object with the specified name and image; it does not modify an existing Deployment's pod template. If a Deployment named `my-deployment` already exists, this command would either conflict or produce unintended resource behavior, not a clean in-place image update. Additionally, `kubectl get pods` only lists current pods and does not track rollout progress or pod readiness relative to the new ReplicaSet, so it cannot validate a successful update.

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

Why it fails: 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 it fails: 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 it fails: 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.

Drain all nodes in the node pool using kubectl drain

Why it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: --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 it fails: --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 it fails: --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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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.

--grace-period=0

Why it fails: This flag sets the termination grace period to zero seconds, meaning that after the termination signal, the pod is immediately killed with SIGKILL. This defeats the purpose of a graceful drain because containers get no time to shut down cleanly, potentially disrupting active connections or losing state. The correct approach is to use the default grace period or a value that fits your application's shutdown sequence.

--disable-eviction

Why it fails: This flag does not exist in the kubectl drain command. The valid flags include --delete-emptydir-data, --force, --ignore-daemonsets, --grace-period, and --pod-selector, among others. Running `kubectl drain` with a non-existent flag will result in an error and no drain will occur. Always verify available options with `kubectl drain --help`.

--force

Why it fails: The --force flag is required when draining a node that contains pods not managed by a controller, such as standalone pods. Since the workloads here are managed by a DaemonSet, they are controlled and --force is unnecessary. Using --force indiscriminately can bypass safety checks and lead to data loss or unintended evictions, so it should only be used when truly needed.