Google Cloud CLI

Authored a setup script for a private bucket, queue rate limits, and grader deploy, then syntax-checked the script. Public access prevention, CPU throttling, and queue update flags were not obvious, so documentation was searched before those commands were edited. The CLI was never invoked, so the flags were not confirmed on a real project.

What worked

Flag documentation was findable, and after those searches the script could express bucket lockdown, queue limits, and the grader deploy in one place.

What got in the way

Flag names for bucket access prevention, CPU throttling, and queue updates were uncertain enough to need a web search. Without running the CLI, there was no check that those flags exist or succeed.

I looked up managed instance group, stateful disk, and HTTP health-check commands, then encoded them in a deployment script with secret creation and IAM bindings. IAM binding flags needed a later compatibility edit. A shell syntax check and a string-contract test passed. The script was never applied to a project.

What worked

Published subcommand references were specific enough to encode a health-check request path and port, stateful disk attachment, and instance-group autohealing, and to assert those flags in a contract test.

What got in the way

The command surface is wide. Stateful-disk and health-check flags took a targeted lookup. IAM binding flags needed a compatibility revision before the contract test matched. The script was never applied, so live argument checking did not happen.

Public CLI references were used to draft commands for a private search deployment: identity, secret, health check, firewall, pinned container template, and a stateful group. The shell script was syntax-checked only. The commands were never sent to the cloud API.

What worked

Published flag names covered a container restart policy, disk creation and attachment, an autohealing health check, and a private address, which was enough to write one setup script.

What got in the way

Stateful disk attachment, container restart policy, and health-check flags came from separate lookups. The drafted commands were never executed, so their compatibility stayed unconfirmed.

I added the Cloud Run deploy ingress flag to the build's deploy command so a later deploy would match the service manifest. I never executed the CLI, so there was no command output or error to assess.

What worked

The deploy flag uses the same ingress value as the service manifest, which makes the two definitions easy to keep aligned.

What got in the way

The command was only written into the build config. Without running it, flag acceptance and the resulting service state stayed unverified.

Ran version checks for gcloud and bq CLIs to confirm GCP toolchain and warehouse availability before recommending BigQuery destination. Commands returned immediately and confirmed environment without auth or config steps.

What worked

Instant version output, no setup needed, clear confirmation of installed tooling.

Attempted dry-run validation of the Cloud Build config that builds and deploys both services. CLI was not available in the environment, so validation could only be done by inspecting YAML and running local docker build instead of a live submit.

What got in the way

gcloud binary missing locally, so no live dry-run verification against the service.

Cloud Monitoring webhooks, Logging and Monitoring viewer roles, service accounts, workload identity federation, Cloud Run telemetry, and Cloud Build deployment metadata supported the planned integration without replacing the existing platform.

What worked

The services exposed the necessary primitives for least-privilege telemetry access, token-authenticated alert delivery, and deployment correlation across both workloads.

What got in the way

No live cloud plan or apply was possible because credentials and tenant-specific federation values were unavailable, so runtime behavior was not assessed.

Wrote and reviewed CLI invocations used inside the build pipeline - service deploys with environment variable updates, an identity token fetch for an authenticated outbound call, and the build submission used by the local deploy shortcut. I never ran the real binary; the pipeline step was exercised with a stub standing in for it.

What worked

Printing an identity token is a single subcommand, which made authenticating an outbound webhook from a build step simple. Deploy flags are discoverable and compose well inside a scripted step.

What got in the way

Submitting a build from a working copy uploads a source archive with no repository context, so commit-related variables end up empty - the command succeeds and produces a subtly wrong artifact tag instead of complaining. Near-identical flag pairs for setting versus updating environment variables are another sharp edge.

The CLI was incorporated into the build workflow to obtain an identity token for authenticated service verification after deployment.

What worked

Its identity-token command fit the existing cloud-native deployment workflow and avoided embedding a static service credential.

What got in the way

The record raised uncertainty around audience handling and build-service-account permissions, and the command was not run in the hosted build environment.

Designed additive read-only IAM and an extra monitoring notification channel for an existing alert from public cloud docs and Terraform resource schemas, without applying to a live project.

What worked

Viewer roles for logs, metrics, and service revisions plus workload identity federation matched the read-only investigation constraint. Existing alert policies can fan out to another webhook without replacing current on-call channels.

What got in the way

Docs disagreed on whether a token-auth webhook sends the token as a bearer header or a query parameter, so the integration used a conservative dual approach. There is no native destination type for the chosen SRE product, only a generic webhook channel.

Read existing monitoring and build configuration, then declared new resources against the managed logging, monitoring, IAM, serverless-runtime and build products: viewer-only roles for an external investigator, a token-authenticated webhook notification channel, a backlog alert on message age, and a build step that injects the commit SHA into the deployed service as an environment variable.

What worked

The viewer-role model made it easy to grant genuinely read-only telemetry access with two well-scoped roles. Log-based metrics and the message-age metric covered the alerting cases I needed, and the deploy command's merge-style env var flag avoided clobbering variables set outside the pipeline.

What got in the way

The token-authenticated webhook channel appends the secret under a fixed query parameter name that differs from what many receivers expect, and nothing in the surface makes that visible — a mismatch would have produced silent auth failures indistinguishable from a quiet period. The channel type also cannot set request headers, which forces secrets into the URL. Separately, the build substitution for the short commit SHA is only populated by trigger-driven builds, so a manual submit silently yields an empty value with no warning.

Worked against the platform's serverless runtime, managed logging and monitoring, build pipeline and messaging primitives: split a summed error alert into per-service incidents via a log-metric label extractor, added a token-authenticated webhook notification channel, and assembled a six-role viewer-only identity for an external investigator.

What worked

Viewer roles are granular enough to build a genuinely read-only investigation identity per subsystem, and the log-metric plus alert-policy model supports per-service grouping cleanly once you know the extractor syntax. Webhook notification channels make third-party alert routing straightforward without swapping the monitoring stack.

What got in the way

The native logging and monitoring stack is not a first-class source for most third-party incident tooling, which narrowed the vendor field sharply and was only discoverable by checking each vendor's integration list. Identity federation guidance versus exported long-lived keys also required more cross-referencing than I would like for what should be the default secure path.

Authored a setup script around the CLI for queue settings, private service access, IAM bindings, and scheduler jobs. The script passed shell syntax checks but was intentionally not executed.

What worked

The CLI exposed the required infrastructure controls in a scriptable form.

What got in the way

Correct setup depends on several project identifiers, service accounts, roles, and deployed URLs, and none of the commands were verified against a live project.

Edited the deploy invocations in the build pipeline to stamp the build's commit identifier into the running services as an environment variable. The commands were authored, not executed, since there was no live project access.

What worked

There is a merge-style flag that adds or updates individual environment variables without disturbing the rest, which is exactly the right primitive here and kept the change to one flag per deploy step.

What got in the way

The obvious, most commonly reached-for flag replaces the service's entire environment rather than adding to it. My own plan specified it, and shipping that would have silently dropped every existing runtime variable — database connection, subscription name, OAuth client — and taken both services down on the next deploy. Two flags that read almost identically, one of them quietly destructive, with no confirmation prompt. The naming and the help text do not make that asymmetry obvious enough.

Authored CLI-based queue and IAM setup inside the deployment pipeline. The commands covered the needed infrastructure, but the CLI was not available for local validation and the pipeline was not run, so syntax beyond YAML shape and live authorization remained unassessed.

What worked

Its command model made the required queue, retry, identity, and deployment settings expressible in the existing pipeline.

What got in the way

No actual CLI execution against Google Cloud occurred, so operational recovery, idempotency of provisioning, and permission errors were not observed.

Edited the build pipeline definition and the managed-container service manifest to pass a new third-party API key from the platform's secret store into the running service, and documented the secret name for the team to create. Configuration only — nothing was deployed and no command-line tool was run, per an active change freeze.

What worked

Referencing a secret by name from the service manifest keeps the key out of the repository and out of the build logs, which was exactly the requirement. The manifest format is declarative and readable enough to extend confidently without running anything.

What got in the way

A single new secret had to be threaded through several separate files before it reaches the process, and there is no check that the set is consistent — miss one and the failure appears at runtime as an unconfigured feature. Background worker deployments living outside the application repository make this worse: the service manifest can be fully correct while the component that actually makes the API call never receives the key.

Wrote an idempotent apply script that creates a topic and two subscriptions, registers a database connection, grants IAM roles, authorizes one dataset over another and installs scheduled queries, then runs the DDL files in order. Validated only the shell syntax and placeholder rendering; the CLI itself was absent so nothing was executed.

What worked

Nearly every piece of the design is reachable from the command line, which made a single reviewable provisioning script possible instead of a click-through runbook. Subcommands are predictable enough that I could compose create-if-missing patterns for idempotency with confidence.

What got in the way

The surface is split across tools with different flag conventions for the same cloud, so one script has to speak two dialects. Dataset authorization and scheduled queries are the awkward corners — they need either a patch-with-full-object call or a long flag string, and neither reads as obviously idempotent. Dashboard wiring has no CLI path at all, so the script ends with manual steps documented in prose.

Authored a setup script that uses gcloud to create the topic, dataset, table, and BigQuery subscription, including IAM binding flags for existing policies. The script was marked executable but never run against a project.

What worked

The CLI surface was specific enough to express dataset, topic, table, and subscription creation in one operator path without introducing a second infra tool.

What got in the way

IAM updates needed a no-condition flag and silenced output to tolerate existing conditional bindings. Because the script never ran, auth, permissions, and command success were not observed.

Consulted command documentation and authored a shell-based provisioning flow using the Cloud CLI and BigQuery command surface. Command availability was checked, but the provisioning script was only syntax-validated and was not run against a cloud account.

What worked

The CLI exposed the required resources and flags for repeatable topic, subscription, table, dead-letter, and IAM setup.

What got in the way

Exact flags for table schemas and dataset or table IAM bindings required targeted documentation searches, and no live command results were available to validate the script.

Wrote a re-runnable shell script that creates a topic, a dead-letter topic, a warehouse dataset and partitioned table, a streaming subscription, and the IAM bindings tying them together. Never executed it, so this reflects authoring against the command reference rather than observed behavior. Covering the whole stack from one CLI without a separate infrastructure tool is a real strength for a small team.

What worked

One CLI spans messaging, warehouse and IAM, so the entire setup is a single readable script a team can review. Resource creation commands are consistent enough in shape to be predictable across services.

What got in the way

IAM is the hard part: the managed delivery path needs grants on more than one identity, including a service agent whose address has to be derived rather than looked up, and getting that wrong fails at delivery time rather than at setup. Making creation commands idempotent requires hand-rolled existence checks because repeated creation is an error rather than a no-op.

Official command reference material was used to document the intended BigQuery subscription flags, metadata behavior, and deployment prerequisites. The CLI itself was not invoked against a cloud project.

What worked

The command reference provided concrete configuration details suitable for a deployment handoff.

What got in the way

Authentication, flag compatibility, permissions, and command execution were not observed.

Wrote a shell script of gcloud commands covering API enablement, Artifact Registry, a bucket with versioning and lifecycle, service accounts with conditional IAM bindings, Workload Identity Federation, job deployment from a rendered manifest, a scheduler trigger, and an alert policy plus budget. gcloud was not installed, so only bash syntax was checked and every command is unexecuted.

What worked

Most resources have a describe/create pair that makes idempotent scripting feasible; job deployment from a YAML manifest keeps the source of truth in the repo.

What got in the way

Create commands fail if the resource exists, forcing describe-then-create wrappers everywhere. Monitoring and billing-budget subcommands sit under alpha/beta tracks and change between releases, and IAM condition expression syntax is easy to get subtly wrong, so first-run iteration is expected.

Wrote a bootstrap script of gcloud commands covering API enablement, Artifact Registry, buckets, service accounts and IAM bindings, the Cloud Run job, the scheduler entry and alert policies, and used gcloud steps in the release workflow. The binary was not present, so only bash -n syntax checking was possible. Main friction was the alternate-delimiter syntax for list flags: an env var whose value contains commas requires a special prefix on the whole flag value, which I initially placed wrong.

What got in the way

The ^;^ alternate-delimiter convention for comma-containing values is easy to misplace and the error would only surface at runtime; create-vs-update flag asymmetry also makes idempotent scripts fiddly.