Google Associate Cloud Engineer (ACE) — Questions 376–450

The command `gcloud auth activate-service-account --key-file=KEY_FILE` is the correct way to authenticate gcloud with a service account using its private key JSON file. It reads the key file, derives the service account email, and establishes that identity as the active authenticated account for gcloud CLI operations. This command both authenticates and activates the service account in one step, enabling subsequent gcloud commands to inherit that identity.

BigQuery is correct because it is a serverless, fully-managed data warehouse that can run SQL queries over terabytes of structured data with high speed. It supports direct querying of external data in Cloud Storage through federated queries or external tables, avoiding the need to import data. BigQuery's columnar storage and massive parallelism make it the appropriate analytical engine for this scenario.

The error 'no available instance' occurs when a request arrives and all existing Cloud Run instances are processing requests, and the service has already reached its configured maximum number of instances. Cloud Run can only scale out to the max-instances setting; if that cap is too low relative to a spike in traffic, new requests are rejected with HTTP 503 and this log message. Increasing max instances or using instance-based concurrency tuning can mitigate this.

The correct workflow is to provision a Cloud KMS asymmetric signing key, create a Container Analysis note, and define a Binary Authorization attestor that references both the note and the KMS key. After that, add a Cloud Build step (for example, using the `gcloud container binauthz attestations sign-and-create` command or the official attestation helper) to sign the image digest and create an attestation in Container Analysis. Finally, set the BinAuthz admission policy on the GKE cluster to require attestations from that attestor; the cluster then permits only images bearing a valid signature. This sequence maps the cryptographic trust chain to the actual enforcement point.

Configuring Cloud NAT on the VPC's Cloud Router for the subnet is correct because it provides source network address translation for instances with private IPs. The NAT gateway maps the private source addresses to a shared public IP, allowing outbound internet connections while keeping the instances themselves unreachable from the outside. This makes apt-get, pip, and similar package managers work without assigning per-VM external IPs.

Changing the Service's label selector from version: blue to version: green repoints the Service's Endpoints to the green Pods immediately, because Kubernetes Services route traffic by matching Pod labels, not by any explicit backend list. Since the blue Deployment remains untouched, it stays running with its Pods intact, making a rollback as simple as reverting the selector back to blue. No downtime occurs because the green Pods are already healthy and registered as ready before the switch, and the Service's ClusterIP and DNS name remain unchanged.

A PersistentVolumeClaim (PVC) backed by a GCE persistent disk StorageClass provides durable, network-attached block storage that is provisioned independently of any specific node. When a Pod using this PVC is rescheduled, the underlying PersistentVolume (a GCE PD) is detached from the old node and attached to the new node, preserving all application-written data. This makes it the correct choice for stateful workloads that must survive Pod restarts or node failures. Note that the PD is zonal, so the new node must be in the same zone as the disk.

GKE Autopilot is the correct choice because it fully abstracts node management: Google provisions, scales, and optimizes the underlying nodes, and you only pay for Pod resource requests. There are no node pools or machine types to configure, and the cluster automatically right-sizes workloads, delivering truly minimal operational overhead.

Cloud NAT is implemented as a NAT gateway configured on a Cloud Router, and this pair is the required core of the service. The Cloud Router holds the NAT IP addresses and manages the dynamic routes (via BGP) that allow private instances to use them, while the NAT gateway performs source address translation for outbound connections. Without a NAT gateway, a Cloud Router alone cannot translate addresses, which is why both components are mandatory for a functioning Cloud NAT.

Creating a project lien is the correct way to prevent accidental or even intentional deletion of a project. A lien blocks the resourcemanager.projects.delete operation on the project, and any deletion attempt will fail until the lien is removed via the Cloud Resource Manager API or using the 'gcloud resource-manager liens' commands, even for users who have the delete permission. This is the only option that directly and reliably protects the project from deletion.

This correct command creates a zonal GKE cluster because --zone targets a single zone, us-central1-a, and the cluster's control plane and nodes are both provisioned there. The --num-nodes=3 flag defines the initial size of the default node pool, and --machine-type=e2-standard-4 sets each node's VM shape. This exactly meets the requirement for a 3-node zonal cluster.

Admin Activity audit logs capture all changes to configurations and metadata, including every IAM role binding, service account creation or deletion, and project-level policy modification. These logs are enabled by default for all projects and cannot be disabled, making them the authoritative source for answering 'who changed an IAM policy and when.' Each entry includes the actor, the action, the affected resource, and the request metadata, so this is the correct log type to audit IAM policy changes.

kubectl set image directly updates the Deployment's pod template to reference the v2 image, which triggers a rolling update orchestrated by the Deployment controller. kubectl rollout status then watches that update to completion, returning a non-zero exit code if the rollout fails (e.g., due to crash-loops or insufficient readiness), which is the correct signal for conditional rollback. kubectl rollout undo reverts to the previous revision, but note it should be gated on that failure in practice; even so, this is the only option that uses the proper Kubernetes-native commands for image update, rollout monitoring, and rollback.

This is the correct command because it targets an existing node pool (`my-pool`) within the specified cluster and toggles the GKE cluster autoscaler on for that pool. The `--min-nodes=1` and `--max-nodes=10` flags define the scaling boundaries, allowing the pool to resize within those limits based on resource demand. The `--cluster` flag scopes the operation to the right cluster, and the update command modifies the live pool without recreating it.

Configuring a cross-region read replica in us-west1 uses asynchronous replication from the primary Cloud SQL instance to a read-only instance in the chosen region. This replica continuously applies changes, with replication lag typically in seconds, making the RPO low enough to approach the under-five-second requirement under normal conditions. If the primary region fails, you can promote the read replica to a standalone primary, enabling a managed cross-region disaster recovery path without needing to operate an external Compute Engine instance.

The Database Migration Service requires a pre-provisioned Cloud SQL instance as the destination, so creating one first defines the target tier, storage, and network configuration before any migration job is started. Without an existing instance, DMS has nowhere to replicate the initial snapshot or stream incoming changes. This is the necessary first step in a low-downtime migration, even though the actual data movement happens later via a DMS job.

Granting roles/iam.securityReviewer at the folder level is correct because IAM permissions propagate through the resource hierarchy. This predefined role includes resourcemanager.folders.getIamPolicy and resourcemanager.projects.getIamPolicy, allowing the user to read IAM policies on the folder and every project, folder, and resource beneath it. Because the audit scope is the entire folder hierarchy, one grant at the folder root covers all child projects without per-project assignments, satisfying the requirement efficiently and with least privilege.

`gcloud auth application-default login` is the canonical command for locally developing with Google Cloud client libraries because it downloads OAuth2 user credentials and stores them in `application_default_credentials.json` in the well-known gcloud config directory. This file is one of the primary sources in the ADC lookup chain, so client libraries automatically discover these credentials without any further configuration. Unlike `gcloud auth login`, which only authenticates the gcloud CLI, this command specifically populates the credentials that your application code will find when it calls the ADC helper.

Global external HTTPS load balancing leverages a single anycast IP address and Google's global backbone to forward each user request to the optimal backend based on latency and health. It performs traffic distribution at L7 to the nearest available region, allowing active/active serving across multiple regions without DNS round-robin. This is the standard control plane that unifies multi-region deployments into one global endpoint.

The alerting policy is the actual alerting mechanism in Cloud Logging. It defines the conditions that trigger an incident, such as a threshold on a metric (e.g., a log-based metric exceeding a value) and specifies the notification channels (email, Slack, etc.) to receive alerts. Without an alerting policy, a log-based metric only counts or samples log entries; it does not perform any active monitoring or notify anyone.

The organization policy constraint iam.allowedPolicyMemberDomains is the canonical mechanism to restrict which domains can be granted IAM roles. When this constraint lists example.com, any attempt to add a principal outside that domain to a bucket policy, project, or folder is rejected. Because it is inherited from the organization, it protects all resources under that hierarchy without per-resource configuration.

VPC Network Peering directly connects two VPC networks over Google's private backbone, allowing instances in each network to communicate using internal RFC 1918 addresses without needing public IPs or a VPN. It is the recommended method for inter-VPC connectivity because it offers low latency, no bandwidth restrictions, and no single point of failure. Peering works across projects and organizations, and it automatically exchanges routes for all subnets in the peered networks, so it fully satisfies the requirement to connect multiple VPC networks.

A new Cloud VPN gateway in europe-west1 with its own Cloud Router gives the on-premises router a second BGP session and a new set of routes to the europe-west1 subnets, allowing traffic to enter GCP at the closest region. By adjusting BGP route priority or MED values, you can gradually shift a percentage of traffic to the new tunnel while monitoring application health and roll back if needed. Because both tunnels remain up during the transition, there is no downtime and the Cloud Router can automatically fail over if one tunnel fails.

Admin Activity audit logs are enabled by default and capture all API calls that modify the configuration or metadata of resources, including IAM policy updates. For an organization with multiple folders, these logs at the org level record IAM binding changes on any resource in the hierarchy, such as 'setIamPolicy' from projects or folders. They provide an audit trail of who changed what, when, from where, and for which resource, making them the correct log type for investigating IAM policy modifications.

The `envFrom` field with a `configMapRef` entry creates environment variables for every key in the `app-config` ConfigMap, with the key name becoming the variable name. This is the correct, declarative way to inject an entire ConfigMap's data as environment variables without listing each key individually. Note that the variables are snapshotted at pod creation; later ConfigMap updates do not update the already-running container's environment.

The subscription's backlog size is the primary indicator of delivery problems: it counts messages that have been published but not yet acknowledged. When troubleshooting a subscription that is not delivering, an ever-growing backlog means messages are arriving faster than the subscriber can process them, or the subscriber has stopped pulling entirely. Large backlog also correlates with slow processing and can help you decide whether to scale out subscribers or inspect subscriber logs.

A managed instance group (MIG) is the correct backend infrastructure because it maintains a pool of identical VM instances across multiple zones, enabling the HTTP(S) load balancer to distribute traffic and automatically heal failed instances. MIGs support autoscaling based on load, which is essential for a scalable web application, and they provide the instance-level health checking that the load balancer relies on to route requests only to healthy VMs.

Apigee provides all required features: per-key rate limiting, built-in developer portal for partner onboarding, detailed API analytics, and scales to billions of requests.

Versioning retains noncurrent versions when objects are deleted, providing an audit trail. The lifecycle rule deletes current versions after 30 days, and the noncurrent versions remain (or can be deleted later with a separate rule). This combination meets both requirements.

Storing the key in Secret Manager and referencing it as a secret environment variable is the correct approach because Cloud Functions integrates natively with Secret Manager through the --set-secrets flag. At runtime, the function's service account fetches the secret value using the IAM role roles/secretmanager.secretAccessor, and the secret is injected into the function environment without ever being stored in the function configuration or visible in the console, gcloud, or Cloud Monitoring metadata.

`kubectl top pods --containers -n [NAMESPACE]` is the correct command because it queries the metrics-server API to show real-time CPU and memory utilization per individual container inside each Pod. This granularity is essential in GKE because a Pod often runs sidecars alongside the main application, and aggregating metrics at the Pod level can hide which container is consuming excessive memory. By comparing each container's usage to its requests and limits, you can pinpoint the leaking container and confirm the diagnosis before taking any remediation action.

An ingress rule in VPC Service Controls is the precise mechanism for allowing an external identity, such as the Cloud Run service account, to access protected resources inside the perimeter. The rule specifies the source identity (the service account), the source project (the Cloud Run project), and the exact target resources (particular BigQuery datasets and Storage buckets), limiting exposure to only what the service genuinely needs. This is the least-privileged and context-aware approach, and it is the only option that correctly addresses the boundary enforcement.

Creating a budget in the Cloud Billing console is the foundational action that enables all budget alerting. You define the total budget amount, optionally scope it to specific projects, folders, or billing accounts, and then attach alert threshold rules. Without an actual budget object, there is nothing to trigger a notification, so this is the non-negotiable first step in the workflow.

A Deployment is the core workload resource that declaratively manages a set of identical pods through a ReplicaSet. It defines the desired state—container image, replicas, and labels—and performs rolling updates and rollbacks, ensuring pods converge to that state. For a stateless microservice, a Deployment is mandatory to run the application reliably; scaling (manually or via HPA) and service selection all operate on the Deployment's pod labels. Without it, you would have no managed pod lifecycle, no self-healing, and no update strategy.

CoreDNS is the standard in-cluster DNS server for Kubernetes. It automatically creates DNS records for every Service in the format `[service].[namespace].svc.cluster.local`, so Pods can resolve those names to cluster IPs and reach Services without hardcoding IPs. This built-in DNS is the foundation of service-to-service discovery on GKE, requiring no additional configuration or external DNS infrastructure.

The serial port 1 (COM1) output in the Google Cloud console is the canonical way to see the full boot sequence, kernel messages, and any startup script output or errors. Unlike network-based access (RDP/SSH), serial output is available even if the instance has not fully booted or has no network connectivity. This is why Cloud Console provides a 'Serial port 1' view under the instance's 'Logs' section, and it is the first place to look for startup script failures.

Running `kubectl expose deployment my-service --type=LoadBalancer` creates a Service of type LoadBalancer, which on GKE signals the cloud controller manager to provision a Google Cloud TCP/UDP load balancer. This load balancer receives a stable external IP address that persists for the lifetime of the Service, independent of node lifecycle. It is the standard way to expose a single deployment to the internet, as it also automatically forwards traffic to the backing pods.

This flag directly associates the Cloud Function with a Pub/Sub topic. When a message is published to that topic, Pub/Sub delivers it as an event to the function, which is how you configure a message-triggered function. Unlike other triggers, this is the standard and only appropriate flag for Pub/Sub message events in the gcloud beta functions deploy command. It ensures the function is invoked asynchronously with the message payload as the event data.

gcloud projects add-iam-policy-binding PROJECT_ID --member=user:email@example.com --role=roles/viewer is the correct command because it performs an additive update to the project's IAM policy. It reads the current policy, appends the new binding (role + member) to the existing set, and writes the merged policy back atomically, leaving all other bindings untouched. This is the standard CLI operation for granting a specific role to a user at the project scope.

Ensures no metadata-based keys exist; OS Login then becomes the only method.

`gcloud storage buckets add-iam-policy-binding` is the dedicated command to add a single IAM binding on a specific Cloud Storage bucket. You specify the bucket name with `--member` and `--role` to grant that role directly to a user, group, or service account at the bucket level. This is a valid, surgical way to grant permissions to exactly that bucket and no other resource.

A signed URL with a 24-hour expiration provides a time-limited, authenticated upload (HTTP PUT) link for a specific Cloud Storage object path. The URL is signed with a service account private key that you retain, and the vendor does not need a Google account or any extra credentials—they simply perform an HTTP PUT to the unique, query-parameter-bearing URL. Once 24 hours pass, the link expires and access is automatically revoked, making it the ideal solution for a one-time, temporary external upload.

This is the correct command to retrieve the IAM policy for a specific project, and using `--format json` explicitly instructs the CLI to output the policy as a JSON object. The `--format` flag does not change the underlying policy data, but it provides a structured, machine-readable representation that is ideal for scripting with tools like `jq` or for programmatic inspection. Without this flag, the same data would be rendered in YAML by default, so this flag only ensures the output format is standard and predictable.

A single alerting policy can define two separate conditions — one on p99 latency and one on 5xx error rate — and use an OR combiner so that the policy enters the firing state if either condition is breached. Each condition can be built on the appropriate Cloud Monitoring time series, such as a distribution-valued metric for the 99th percentile latency and a ratio metric for the error rate, with its own threshold and duration window. This approach creates a single incident and sends one notification when any condition fires, reducing noise while still covering both critical signals. It is also easier to maintain and update because the notification channels, documentation, and incident grouping are centralized in one policy.

Cloud Functions (Gen 2) is the right choice because it offers first-class event triggers from Cloud Storage through Eventarc, letting you run code directly when an object is finalized or deleted. It is fully serverless, scales automatically from zero, and you only pay for execution time, which is ideal for a small startup. The maximum timeout of 60 minutes comfortably covers the stated 10-minute processing requirement, and the function is invoked automatically without any polling or VM management.

Firestore is a flexible, scalable NoSQL document database designed natively for mobile app development, with real-time listeners that push data changes to clients instantly and offline data persistence that automatically syncs when connectivity returns. Its client SDKs for iOS, Android, and web handle multi-device synchronization, conflict resolution, and data integrity out of the box, making it the ideal choice for this real-time mobile backend use case.

Stopping the instance transitions it to the TERMINATED state, which releases the underlying host resources while preserving the boot disk, metadata, and attachment of persistent disks. The `gcloud compute instances set-machine-type` command can then change the vCPU and memory allocation, and after that you start the instance. This is the correct workflow because Compute Engine rejects machine type changes on running instances.

Cloud Billing data export to BigQuery is the native, recommended way to access detailed billing data. Google Cloud automatically writes cost and usage line items, including project, SKU, service, usage amount, unit price, cost, and resource labels, into a BigQuery dataset multiple times a day, allowing you to run SQL queries to slice costs by project, label, service, or date for chargeback, budgeting, and trend analysis.

gcloud config set project PROJECT_ID is the correct command because it updates the core/project property in the active gcloud configuration. This directly sets the default project used by subsequent gcloud commands when no --project flag or CLOUDSDK_CORE_PROJECT environment variable is provided. It is the standard, non-interactive method to change the current default project within a given configuration.

The organization node is the root of the GCP resource hierarchy, and it is the correct place to attach an organization-wide policy. Any IAM role binding or organization policy constraint set at this level is inherited by every folder, project, and resource in the hierarchy, thereby ensuring the policy is enforced across all projects while also applying automatically to any future projects created under the organization.

APIs & Services > Dashboard is the correct destination because it is the single project-level overview of the Google Cloud API ecosystem. It shows which APIs are enabled, total usage metrics (requests and errors), and per-API quota utilization. From this page you can click through to individual API details, enable or disable APIs, and manage credentials—making it the canonical place to check API enablement status.

Compute Engine persistent disks (SSD) using the 'pd-ssd' StorageClass is the correct choice because these are core GKE block volumes that are dynamically provisioned, attached to the node, and mounted by the pod with standard filesystem semantics. The SSD persistent disk provides high IOPS and low latency with synchronous, zone-level replication, making it suitable for stateful applications like databases that require durable, consistent storage. In GKE Autopilot, persistent volumes using 'pd-ssd' are fully supported, and the StorageClass abstracts away infrastructure provisioning so the workload gets a dedicated high-performance block device.

An Ingress resource is the Kubernetes API object that manages external HTTP(S) access to services, providing L7 load balancing with path-based and host-based routing. In GKE, it integrates with Google Cloud Load Balancing to expose all microservices through a single external IP address, forwarding requests to the appropriate backend Service based on the URL path. This makes it the correct choice for routing traffic to multiple microservices without creating separate external IPs.

PodDisruptionBudget (PDB) is the correct answer because it is the Kubernetes object specifically designed to protect applications during voluntary disruptions, such as GKE node auto-upgrades that drain nodes. A PDB uses minAvailable or maxUnavailable to define how many pods must remain available during evictions; when a node is being upgraded, the eviction API checks the PDB and blocks eviction of a pod if it would violate the budget. This ensures the production workload retains a guaranteed number of replicas, preventing downtime during node maintenance.

A Cloud Function with a Pub/Sub trigger is the compute piece that executes your custom response logic asynchronously. When a message lands on the subscribed topic, the function is invoked with the message payload, letting you parse the log data and call external APIs, send alerts, or modify resources. This event-driven model avoids maintaining a server and scales automatically with message volume. Without this function, the sink and topic would merely transport logs with no automated reaction.

Anthos (Google Distributed Cloud) is a hybrid multi-cloud platform built on Kubernetes that provides consistent clusters across on-premises data centers, GCP, AWS, and Azure. It integrates Anthos Config Management for policy propagation, Anthos Service Mesh for traffic and observability, and a unified multicluster control plane, enabling consistent security, CI/CD, and application operations. This platform-level approach is what actually delivers unified hybrid multi-cluster management.

An uptime check is a Cloud Monitoring synthetic probe that periodically sends an HTTP(S) request to the specified URL from configurable global locations. It validates availability by checking for expected HTTP status codes, response time thresholds, and optional content matches, and it emits metrics such as uptime, latency, and check success. This is the correct choice because it actively measures external HTTP reachability from outside the network, which is exactly what is needed to monitor external availability.

Cloud Bigtable is purpose-built for high-throughput, low-latency NoSQL workloads, including IoT time-series ingestion at 500K events/second. It scales linearly by adding nodes, supports millions of writes per second, and uses row keys like device timestamp to enable fast point reads and range scans. Its wide-column storage model is optimized for analytical patterns over sequential time-series data, making it the ideal choice over relational or document databases.

Security Command Center (SCC) with Security Health Analytics enabled is the correct choice because it automatically runs continuous, built-in scans for known security misconfigurations and vulnerabilities across your GCP resources. It uses detectors based on CIS benchmarks and other GCP best practices, surfacing findings such as publicly exposed Cloud Storage buckets, overly permissive firewall rules, and non-compliant IAM bindings at the organization, folder, and project level. It provides a centralized dashboard and API to see the current security posture without requiring custom logic or manual log parsing.

Organization policy constraints are centralized guardrails evaluated by Google Cloud Resource Manager before IAM. Applying a boolean constraint such as `constraints/resourcemanager.projectDelete` at the organization or folder level explicitly denies the `resourcemanager.projects.delete` action for every principal, overriding project-level IAM roles. This makes it an authoritative, non-bypassable control that prevents a production project from being deleted from any console or API path.

This is the correct command because it surgically removes the specified service account from the roles/owner role on the project while leaving every other IAM binding untouched. The command takes the project name, member string in serviceAccount: format, and role ID to precisely identify the binding to delete. It is the safe, expected way to revoke a single principal's role, and it performs an atomic update to the IAM policy without requiring you to fetch or rewrite the entire policy.

This is the correct, supported command for adjusting traffic on a Cloud Run service. The 'update-traffic' subcommand directly modifies the revision routing percents, and '--to-revisions' allows explicit targeting of a specific revision; here, setting 'my-service-00001=100' routes all live traffic to the known-good revision A. This immediately reduces load on the suspect revision B and is exactly how you roll back a bad deployment on Cloud Run.

The IAM Policy Troubleshooter (also known as the Policy Simulator in some contexts) calculates the effective IAM policy for a specific principal, permission, and resource, taking into account inherited roles, group memberships, conditional bindings, and deny policies. For a Cloud SQL delete, it can verify whether the principal has the `cloudsql.instances.delete` permission. It provides an immediate, non-destructive answer through the Cloud Console or the `gcloud policy-troubleshoot` CLI, without requiring any policy changes.

Cloud Build is Google Cloud's CI/CD service that can compile source code and build Docker container images. If the engineer's containerized application is built from a repository, enabling cloudbuild.googleapis.com is required before Cloud Build can push built images to Container Registry or Artifact Registry. Thus, for a project that automates image creation for GKE, this API is a correct and necessary dependency.

Using Log Explorer in the Google Cloud console lets you query and filter audit logs once they are enabled. By applying a filter for the Cloud Storage service and the 'data_access' log type, you can view object-level operations such as writes, deletes, and overwrites. This is the final step that makes the audit trail visible and actionable for compliance, but it requires Data Access logging to already be enabled in the IAM audit config.

A Cloud Logging exclusion filter in the Log Router can match DEBUG entries from the service's resource type (e.g., `resource.type="cloud_run_revision"` and `severity=DEBUG`) and discard them before they are written to any sink or storage. Because exclusion filters are evaluated during ingestion, the matched entries are never billed, so this reduces logging costs immediately without code changes or redeployment. The application can keep emitting DEBUG logs; Log Router simply drops them, making this the operational solution that directly addresses the cost driver.

Cloud Dataproc is the fully managed Apache Spark and Hadoop service on Google Cloud, purpose-built to run Spark jobs at scale. It offers fast cluster provisioning via ephemeral clusters, direct connectors to Cloud Storage and BigQuery for reading and writing data without ETL, and automatically manages the HDFS/YARN infrastructure. Because it is native to Spark and integrates with the Google Cloud ecosystem, it is the correct choice for executing Spark workloads.

`gcloud auth login` is the correct way to initiate interactive user authentication via Google's OAuth 2.0 flow. It opens a browser to obtain an access token and refresh token, then securely stores those credentials in your local `~/.config/gcloud/` directory. After this step, all `gcloud` commands automatically use these stored credentials for the active account, eliminating the need to re-authenticate for each command.

This is the correct syntax. 'gcloud compute instances create' targets the Compute Engine service's 'instances' resource and the 'create' verb. The '--zone' flag designates the zonal location for the VM (required if no region-level default), and '--machine-type' specifies the predefined machine type (e.g., 'e2-medium'). This creates an instance in the current project with the given configuration.

kubectl set image deployment/my-app my-app-container=my-image:v2 is correct because it imperatively changes the image of the container named 'my-app-container' in the deployment 'my-app'. The syntax is RESOURCE_TYPE/RESOURCE_NAME CONTAINER_NAME=IMAGE, and the command triggers a rolling update by creating a new ReplicaSet and scaling it up while scaling down the old one. This is the standard kubectl command for updating a container image without modifying a manifest or entering a text editor. After running it, you can monitor progress with kubectl rollout status deployment/my-app.

This is the canonical Google Cloud streaming analytics architecture: Pub/Sub ingests transaction streams asynchronously, Dataflow provides exactly-once, auto-scaling transformations (including windowing and enrichment), and BigQuery stores the results in columnar, partitioned tables. BigQuery's Dremel execution engine and optional BI Engine provide sub-second-to-2-second query performance on recent data, while table partitioning and time-based expiration handle multi-year retention cost-effectively. This serverless pattern avoids managing infrastructure and scales seamlessly from low to very high streaming throughput, making it the only option that meets both the performance and retention requirements.

Data Access audit logs are the correct Cloud Audit Logs category for recording data-plane read/write operations, including Cloud Storage object GETs, BigQuery query reads, and Pub/Sub message publishes/pulls. They are typically disabled by default for most services and must be explicitly enabled for each service in the Audit Logs configuration, after which they deliver the who/what/when trail needed to audit data access across the organization.