Appendix F

Command-Line Reference

Scope. Every gcloud command this book uses, grouped by task, with the flags that carry a security decision and the section that uses it. The invocation, not the explanation. Prerequisites. None. Each entry's section reference is where the command is explained. Verified against. Google Cloud console and API surface as of 2026-09, Cloud SDK 583.0.0; every command path and every flag below re-resolved against the installed SDK; see sources at end.

The book runs 1,063 gcloud invocations across its chapters and appendices. This appendix is the 196 distinct commands worth looking up, sorted by task rather than by the chapter that happened to need them first.

Read the flag column as "the flags that decide something", not as a synopsis. Most real invocations in the book are longer than a printed line — 297 of the 348 in-book occurrences of these commands exceed 100 characters — so a full command with all its arguments belongs in the section that shows it, and that is what the § column is for. The commands here are gcloud only: the book contains no gsutil, bq, or kubectl invocation in a runnable block.

Two entries use a Preview surface and are labeled where they appear. gcloud beta terraform vet has a GA alternative, gcloud scc iac-validation-reports create, and §22.12 owns that choice; a Preview surface must never be a production dependency.

F.1 gcloud Configuration §

The only section here with no provenance in the book: these are the commands you run before any of the others, and the book never has to show them because every chapter assumes a configured SDK. The section references therefore point at the nearest owning section rather than at a section that runs the command, and that is worth knowing before you follow one. Two habits are worth forming early. Set the project once with gcloud config set rather than passing --project on every invocation, because a forgotten --project is how a command lands in the wrong estate. And keep separate named configurations for the SaaS and enterprise organizations, so switching between them is explicit rather than a matter of remembering which one is active.

F.2 Authentication §

Identity setup and the impersonation chain. Note what is absent: nothing here downloads a service account key, because the estate forbids them (§3.25). gcloud auth activate-service-account is listed only so it is recognized as the anti-pattern it is.

F.3 Project Management §

The hierarchy: organizations, folders, projects, and the policy that hangs off each. gcloud projects update accepts only --name; a label change on an existing project goes through Terraform or the API (§2.12).

F.4 IAM §

Roles, bindings, conditions, and deny policies. The asymmetry to remember is that add-iam-policy-binding is additive and safe to script, while set-iam-policy is authoritative and will silently remove any binding not in the file you pass.

F.5 Compute §

Instances, disks, images, and snapshots. The flags that carry security decisions are the shielded-VM and confidential-computing ones, and --no-address, which is what keeps an instance off the public internet.

F.6 Networking §

The largest section, because the network surface is the largest. Two command groups are easy to confuse and are not interchangeable: compute firewall-policies is hierarchical, taking --organization or --folder, while compute network-firewall-policies is VPC-scoped and takes --global or --region (§5.31).

F.7 GKE §

Cluster and node-pool lifecycle. Most of the hardening surface is on clusters create and cannot be changed afterward without recreating the cluster or the node pool (§9.30).

F.8 Cloud Run §

Services, jobs, and the invoker binding that decides who can call them. --no-allow-unauthenticated exists on run deploy and not on run services update, so hardening a service that is already public means removing the invoker binding (§10.13).

F.9 Storage §

Buckets and objects. Note that gcloud storage buckets create has no --versioning flag; versioning, retention, and log routing are all set on update (§11.14).

F.10 SQL §

Cloud SQL instances, backups, and the connection controls. Two flags here are effectively permanent. CMEK is creation-time only, so --disk-encryption-key on create is a decision that cannot be revisited without rebuilding the instance (§12.14). Private IP is the same: an instance created without it needs a migration, not a patch. --connector-enforcement is the one control that changes the connection model outright — setting it to REQUIRED disables every existing authorized network in the same operation, so it belongs in a maintenance window rather than in a routine patch (§12.17).

F.11 Logging §

Sinks, buckets, views, and the read path. logging read is for investigation; a sink is what makes a log durable beyond its bucket's retention (§17.11).

F.12 Monitoring §

Alerting policies, notification channels, and uptime checks. Policies and channels are defined in files rather than in flags, which is the property that makes them reviewable in version control and diffable in a pull request (§18.15). That is also why this section is short: most of the configuration lives in the YAML or JSON the command consumes, not in the command line, and the section that owns each policy shows the document. The one alpha surface in the whole book appears here, and a GA equivalent exists at §18.19.

F.13 Security §

The security surface across services: organization policy, Security Command Center, KMS, Secret Manager, and Binary Authorization. Every write to an organization policy goes through set-policy and a file — there is no allow or deny subcommand (§31.1).

Sources §

Every command and flag in this appendix was resolved against the installed Cloud SDK rather than from documentation, so the authority is the SDK itself:

• Google Cloud SDK 583.0.0, gcloud <command> --help, resolved offline for all 196 entries (last validated 2026-09-04)
• https://cloud.google.com/sdk/gcloud/reference (last validated 2026-09-04)