Task 5.2: Interacting with Google Cloud programmatically.

• AA dedicated test project with real Pub/Sub topics

  Incorrect

  Real topics need network access, create cloud resources and are billed.

• BCloud Shell sessions that run the tests in the cloud

  Incorrect

  Cloud Shell runs in Google Cloud and would test against the real service.

• CThe Cloud Run emulator in the Cloud Code extension

  Incorrect

  That emulator runs a Cloud Run service locally; it does not emulate Pub/Sub.

• DThe Pub/Sub emulator, started with the gcloud CLI

  Correct

  The emulator runs Pub/Sub locally, and the client libraries talk to it once the environment variables point at it.

Cloud emulators exist for Pub/Sub, Bigtable, Spanner and Firestore so that code can be tested locally and in CI without cloud resources.

• AApplication Default Credentials: the attached service account on Cloud Run, gcloud ADC login on laptops

  Correct

  Client libraries find credentials through ADC: on Cloud Run from the attached service account, and locally from credentials created with gcloud auth application-default login.

• BA service account key file built into the container image and named in an environment variable

  Incorrect

  Key files are long-lived credentials that can leak from images; they are the thing to avoid.

• CAn API key passed to each client library constructor, both on laptops and in production

  Incorrect

  A standard API key does not identify a principal that IAM can authorize to read buckets and write tables.

• DA developer's OAuth refresh token kept in Secret Manager and loaded when the service starts

  Incorrect

  Production would then act as a person, with that person's access, instead of a service identity.

Accessing Google APIs well means letting the libraries find credentials through Application Default Credentials and attaching a service account in production, so no code changes and no keys are needed.

• ACommit terraform.tfstate to the team's shared Git repository

  Incorrect

  State can hold sensitive values, and Git gives no locking; Google recommends keeping state out of version control.

• BRun terraform import on every resource before each apply

  Incorrect

  Importing does not change where state is kept, so each engineer would still apply from a separate local copy with no shared lock.

• CA shared Cloud Storage state backend with object versioning

  Correct

  The Cloud Storage backend shares one state and locks it during operations, and versioning lets the team recover earlier state.

• DMake changes to shared resources with gcloud commands instead

  Incorrect

  Dropping Terraform for shared resources loses infrastructure as code rather than fixing collaboration.

Infrastructure as code in a team needs remote state. On Google Cloud the recommended backend is a Cloud Storage bucket, which supports locking and keeps state out of source control.

• ANamed gcloud configurations per environment, switched with activate

  Correct

  Each named configuration holds its own account, project and defaults, and only one is active at a time.

• BRunning gcloud auth login again before every command that is run

  Incorrect

  Re-authenticating each time is slow and still does not tie the project to the account.

• COne CLOUDSDK_CORE_PROJECT value set permanently in the shell profile

  Incorrect

  A single fixed project value cannot express two environments and invites the same mistake.

• DA shared service account key file that both environments can use

  Incorrect

  A shared key removes the separation between environments and adds a long-lived credential.

Working with Google Cloud from the command line is safer with named configurations, which make the active account and project explicit.

• Agsutil with the -m flag added to every command

  Incorrect

  Parallel gsutil can be faster, but gsutil is the legacy tool the team should move away from.

• Bgcloud storage commands in the Google Cloud CLI

  Correct

  Google recommends gcloud storage commands over gsutil, which is a legacy, minimally maintained tool.

• Cbq cp commands that copy files between buckets

  Incorrect

  bq works with BigQuery datasets and tables, not Cloud Storage objects.

• DCloud Storage FUSE mounts with cp in the shell

  Incorrect

  FUSE suits file-based applications; it is not a faster bulk copy tool.

The guide still names gsutil, but Google's documentation now marks it as legacy and points to gcloud storage, which is the CLI to standardize on.

• ARetry with truncated exponential backoff and random jitter

  Correct

  429 and 5xx responses are transient; backing off exponentially with jitter spreads retries and avoids overloading the service.

• BMake retried calls idempotent, for example with preconditions

  Correct

  Retrying a non-idempotent call can create duplicates; idempotent requests produce the same end state when repeated.

• CRetry each failed call immediately in a tight loop

  Incorrect

  Immediate retries add load at the worst moment and tend to fail again.

• DRaise the job's thread count to finish before errors

  Incorrect

  More concurrent calls make throttling worse, not better.

• ESwitch from service account auth to an API key

  Incorrect

  The credential type does not change throttling or server errors.

Accessing Google APIs well means treating 429 and 5xx as retryable with backoff, and making sure retries are safe through idempotency.

• Agcloud auth activate-service-account with a key stored in Secret Manager

  Incorrect

  This still depends on a long-lived key; moving it to Secret Manager does not remove it.

• BService account impersonation, with Token Creator granted to the admins

  Correct

  With the Service Account Token Creator role, administrators can impersonate the account and the gcloud CLI requests short-lived credentials for it.

• COwner granted directly to each administrator on every target project

  Incorrect

  Direct broad grants replace a controlled deployment identity with standing personal privilege.

• DAn API key for each administrator, restricted to the deployment APIs

  Incorrect

  API keys do not carry a principal that IAM can authorize to deploy resources.

Programmatic access without keys: impersonation issues short-lived tokens for a service account to users who are allowed to act as it.