Google Associate Cloud Engineer (ACE) — Questions 151–225

iam.serviceAccounts.actAs is the 'Service Account User' permission, required to delegate the new instance's identity to a specific service account. Even with compute.instanceAdmin.v1, Compute Engine's authorization layer checks whether the caller can 'actAs' the service account on the project; without this, the create request is denied with a permissions error. Granting this on the service account (or project) allows the user to create instances that run as that service account, making it the exact missing permission.

This correctly adds an IAM policy binding on my-project, which owns the Container Registry artifacts, and defines the member as the service account from other-project using the `serviceAccount:` prefix. Since `roles/storage.objectViewer` grants read access to Cloud Storage objects that back GCR, this allows sa@other-project.iam.gserviceaccount.com to pull images and list repositories in my-project without needing a key or user account. The binding is cross-project: the member belongs to other-project, but the resource is in my-project, which is exactly the required configuration.

A Google-managed SSL certificate is issued by Google's own CA, automatically renewed before expiry, and attached directly to the target HTTPS proxy of the external HTTP(S) load balancer. Domain ownership is verified via a DNS record, and once the certificate is active, you manage zero certificate lifecycle tasks. This is the native, fully managed GCP path for exposing a service securely over HTTPS.

Cloud Build (cloudbuild.googleapis.com) is the managed CI/CD service used to compile source code and build container images. For microservices, each service is typically packaged as a separate container, and Cloud Build provides a reliable, serverless way to automate those builds via triggers and build steps. It integrates with Artifact Registry to store the resulting images, which are then deployed to GKE, making it a common and often essential part of a microservices deployment pipeline.

This is the correct gcloud command to enable cluster autoscaler on a specific node pool. The `--enable-autoscaling` switch turns on autoscaling for the `default-pool`, and the `--min-nodes 1` and `--max-nodes 10` flags define the minimum and maximum size of the node pool. With this configuration, GKE's cluster autoscaler will automatically add or remove nodes within that range based on pending pod resource requests, which directly relieves the low-resource condition on the cluster's nodes.

Enabling Data Access audit logs for the Cloud Storage service is correct because these logs specifically record every successful and failed read, write, and metadata operation on objects and buckets. By default, Data Access audit logs are disabled, so they must be explicitly turned on for Cloud Storage for the auditor to capture access attempts. Once enabled, each entry includes the principal, source IP, operation (e.g. storage.objects.get), and timestamp—providing the detailed evidence needed for an audit trail.

This is the correct modern command to create a Cloud Storage bucket. `gcloud storage buckets create` is the dedicated subcommand, and it requires the bucket name as a `gs://` URI—`gs://my-archive-bucket`—which is globally unique across all of Google Cloud. The `--location=US` flag explicitly sets the bucket to the US multi-region, giving geo-redundancy across the contiguous United States at a lower cost than single-region or dual-region alternatives. This syntax is the current recommended replacement for the legacy `gsutil mb` command.

Because GCP offers no built-in transactional email service, the standard pattern is to outsource sending to a dedicated email service provider such as SendGrid or Mailgun and call its REST API or SMTP relay from your GCP-hosted application. These providers handle deliverability, DKIM/SPF authentication, bounce processing, and provide analytics, which is exactly what production transactional email requires.

A PodDisruptionBudget with minAvailable: 3 is the correct mechanism because it constrains voluntary evictions, such as those triggered by GKE node upgrades or cluster autoscaler scale-down. When the eviction API is called to drain a node, the PDB controller checks that evicting the Pod would not reduce the total available replicas below 3; if it would, the drain is blocked or delayed. Because the payment service runs exactly 3 replicas, minAvailable: 3 means no Pod can be voluntarily evicted at a time, keeping the service fully available throughout the disruption. The PDB must use a selector that matches the Deployment's Pod labels to enforce this guarantee correctly.

Enabling OS Login by setting the project metadata key enable-oslogin to TRUE is the foundational step. This tells Compute Engine to use IAM-based authentication for SSH, allowing the engineer to log in with Google credentials rather than managing SSH keys. Once enabled at the project level, instances inherit the setting, and a user with the compute.osLogin role can SSH without manual key distribution. This is the required first action to meet the engineer's need.

To use a service account in a Deployment Manager deployment, the user must have the roles/iam.serviceAccountUser role on that service account, which grants the serviceAccounts.actAs permission. This permission allows the user to impersonate the service account when creating resources on behalf of the deployment. The error 'permission serviceAccounts.actAs required' confirms that this IAM binding is missing, making this the correct answer.

Creating a dedicated service account, granting it only the required Cloud Storage IAM roles such as roles/storage.objectViewer, and attaching it to the instance with the --service-account flag at creation time follows the principle of least privilege. The VM's metadata server then provides short-lived access tokens to the application, avoiding the need to manage or download any service account keys. This is the recommended, secure pattern for a GCE workload to access Cloud Storage with minimal permissions.

This statement is correct. The IAM principal `allAuthenticatedUsers` is a special identifier that represents every identity authenticated by Google, including Gmail users, Google Workspace accounts, and service accounts, regardless of which GCP project they belong to. When bound to a role such as `roles/storage.objectViewer` on a Cloud Storage bucket, it grants permissions like `storage.objects.list` and `storage.objects.get`, enabling these users to list and read objects in that bucket.

Canary update is the MIG feature specifically designed for staged rollout: you define a target size (e.g., 1 out of 20) for the new instance template, so the MIG creates exactly one VM running the new environment variable while the other 19 continue on the old template. After validating that the canary VM passes health checks and behaves as expected, you can promote the new template across the entire group by increasing the target size to all instances. This provides a controlled, incremental rollout with the MIG managing versioning and rollback automatically.

This is the correct read-only command for retrieving a project's IAM policy. It outputs the complete policy document, including bindings, version, etag, and audit configs, and '--format json' formats that document as JSON for easy parsing. It is the standard tool for viewing current IAM state and is the basis for making offline changes with set-iam-policy.

Cloud SQL High Availability (HA) provisions a primary and a standby instance in different zones within the same region. It uses synchronous replication to the standby, so every committed transaction is durably written to both the primary and standby before the client receives an acknowledgement, yielding near-zero RPO. If the primary zone experiences an outage, the standby is promoted automatically and, because replication was synchronous, no committed data is lost even in a hard failure scenario.

The Compute Viewer role grants read-only access to all Compute Engine resources, including the specific permissions compute.firewalls.list and compute.firewalls.get needed to view firewall rules. It cannot modify, create, or delete any resource, so it precisely matches the user's requirement to list firewall rules. This is the correct least-privilege role for this task.

Compute Engine is the correct choice because it provides unmodified, full control over the virtual machine, including the guest OS kernel. You can install custom kernel modules, load them via modprobe, and configure kernel parameters exactly as required by the legacy monolithic application. This is essential for a lift-and-shift migration where the application depends on specific low-level OS features or hardware drivers that cannot be abstracted away by a managed platform.

Configuring the gcs backend with a bucket name is the correct way to store Terraform state for GCP resources. The gcs backend uses a Cloud Storage bucket, which natively supports state file versioning, server-side encryption (including customer-managed keys via Cloud KMS), and access control through GCP IAM, providing both security and consistency for team use. It also enables state locking via bucket objects to prevent concurrent modifications. This is the recommended solution for centralized, durable remote state in GCP.

A Cloud VPN tunnel is a prerequisite, not an alternative to DMS: Database Migration Service connects to your on-premises MySQL over a private IP address, and the VPN provides the secure, encrypted network path across the public internet. Without this connectivity, DMS cannot establish the replication channel needed for continuous sync. High-bandwidth, low-latency Interconnect is the alternative when VPN bandwidth is insufficient.

Caching third-party API responses in Cloud Memorystore (Redis) with an appropriate TTL is the correct solution because Memorystore is a shared, in-memory data store accessible to all Cloud Run instances. When one instance fetches a third-party response and caches it, subsequent requests from any instance can read the cached value, eliminating redundant outbound API calls and reducing both latency and API consumption. Setting a TTL (e.g., 60 seconds) balances data freshness with cache hit ratio, directly addressing the root cause of duplicate external requests. This is particularly effective for high-traffic services where the same third-party data is requested repeatedly.

Cloud Storage Object Lifecycle Management lets you define age-based rules that automatically transition objects from Standard to Nearline after 30 days, to Coldline after 90 days, and to Archive after 365 days. This reduces storage costs progressively while still making the logs retrievable for the required 7-year compliance window. Because objects remain in the bucket throughout, no data is deleted, and Archive class is specifically designed for long-term retention with the lowest per-GB cost.

A Cloud Router is the correct component because Cloud NAT requires a Cloud Router in the same region and VPC network to function. The Cloud Router holds the NAT gateway's configuration, manages the NAT IP addresses, and dynamically exchanges routes with the VPC network. Without a Cloud Router, Cloud NAT cannot be created or operate, making it the essential resource for allowing private Compute Engine instances to access the internet or other destinations while remaining private.

Correct. The Project Creator role grants the resourcemanager.projects.create permission required to create projects.

Persistent Disk is durable, network-attached block storage that you can attach to a Compute Engine instance like a physical disk. It survives instance stops and can be detached from one instance and reattached to another, enabling stateful failover. Persistent Disk also supports snapshots, resizing, and zonal or regional replication, making it the appropriate choice for a stateful application. For these reasons, Persistent Disk is the correct answer.

A 503 from Cloud Run specifically signals that a request arrived but no container instance was available to accept it within the timeout window. Each instance can process only a fixed number of concurrent requests—the default concurrency is 80—so when all existing instances are saturated and the autoscaler cannot add new instances quickly enough (or the 'max instances' setting has been reached), the server returns Service Unavailable. The fix is to raise the max instances limit, lower the concurrency setting, or enable additional CPU to reduce per-instance bottleneck.

Spot VMs (formerly preemptible VMs) offer up to 91% discount over on-demand pricing and are ideal for fault-tolerant batch jobs that can be checkpointed and resumed after interruption. With checkpointing, the nightly job can simply restart from the last saved state whenever a Spot VM is reclaimed, so transient failures do not jeopardize completion. This provides the maximum cost reduction among the options for a workload that explicitly tolerates interruption, making it the correct choice.

Cloud NAT uses a Cloud Router to provide a managed Network Address Translation service that gives private instances (those with internal IPs only) a secure path to the internet for outbound connections. It maintains stateful sessions so return traffic is allowed, but unsolicited inbound connections are blocked, preserving the private nature of the network.

Granting authorized users the roles/cloudkms.cryptoKeyEncrypterDecrypter role on the Cloud KMS key is correct because this IAM role grants permission to call the Cloud KMS Encrypt and Decrypt operations, which are required for objects to be uploaded with and read from a CMEK-encrypted bucket. Even if a user has bucket-level permissions, they cannot create or read objects encrypted with that key unless they have this role on the key itself. This ensures only the intended authorized principals can use the customer-managed key for cryptographic operations.

Metric threshold is the standard condition type used in a Cloud Monitoring alerting policy. It evaluates a metric stream (e.g., Compute Engine CPU utilization, disk bytes used) against a numeric threshold over a specified aggregation window, triggering notifications when the value crosses the threshold. This is the correct answer because it directly defines the alerting condition that the engineer needs.

Secret Manager is the dedicated Google Cloud service for storing, managing, and accessing secrets such as API keys, passwords, and certificates. It provides built-in secret versioning with immutable payloads, IAM-based access control at the secret-version level, automatic replication for high availability, and full audit logging via Cloud Audit Logs. This makes it the managed and scalable solution that directly matches the requirement.

When creating an instance, you must specify the service account with `gcloud compute instances create --service-account <SA_EMAIL>`, which attaches that identity to the instance for its entire lifetime. Once attached, the instance metadata server returns OAuth credentials for that service account, so all API calls from the instance are made as that identity. This is the correct way to ensure the instance uses a custom, least-privileged service account, provided the account has been granted the necessary IAM roles.

Take a snapshot of the disk while the VM is running to obtain a crash-consistent image of the filesystem; persistent disk snapshots are computed online and do not require stopping the instance. From that snapshot, create a new persistent disk with the desired storage class (for example, pd-balanced or pd-ssd). Then unmount the old disk, detach it from the VM, attach the newly created disk, and remount it at the same mount point; this limits downtime to the brief unmount/detach/attach/remount window rather than the entire snapshot and disk creation time.

The Horizontal Pod Autoscaler (HPA) automatically adjusts the number of Pod replicas in a Deployment based on observed CPU utilization relative to the CPU requests set on containers. When average CPU utilization exceeds the 60% target, HPA increases the replica count; when it drops below the target for a sustained period, it decreases replicas. This directly matches the requirement to scale Pod count based on load, and it is the standard Kubernetes mechanism for horizontal scaling of workloads.

Tainting a dedicated node pool with, for example, 'payments=true:NoSchedule' and adding a matching toleration to payment pod specs guarantees that only pods with that toleration can be scheduled there. The kube-scheduler filters out tainted nodes for pods that lack the toleration, so non-payment workloads stay away. Combined with a nodeSelector or node affinity for that pool, this is the standard GKE pattern for isolating sensitive workloads inside one cluster.

Correct.

The `--runtime` flag is mandatory because it tells the Cloud Functions deployment service which language runtime to use, such as `python312` or `nodejs20`. This value must match the code you are uploading, including the expected base image and dependencies, so the platform can build the function in the correct environment. Without specifying it, the gcloud command will fail, as there is no sensible default language choice.

This is the correct command because it explicitly selects the 'cos-stable' image family from the 'cos-cloud' project, which yields the latest stable release of Container-Optimized OS. COS is a Google-supported OS with Docker, containerd, and Kubernetes tools preinstalled, optimized for running containerized workloads. Including both --image-family and --image-project ensures that gcloud resolves the family from the proper project, avoiding ambiguity with the default compute project.

The Kubernetes Ingress resource is specifically designed to expose HTTP(S) workloads with rules for hostnames and URL paths. When deployed on GKE, the built-in Ingress controller provisions a GCP Application Load Balancer (HTTP(S) Load Balancer) that maintains URL maps and path rules at the edge. This enables TLS termination, path-based routing, and forwarding to backend Services. Therefore a Kubernetes Ingress resource with path rules is the correct way to perform HTTP path-based routing on GKE.

roles/secretmanager.secretAccessor is the correct predefined role for accessing a secret payload because it includes the secretmanager.versions.access permission, which is the exact IAM permission required to retrieve the stored database password. This role is narrowly scoped; it grants no management capabilities like secret creation, deletion, or IAM policy changes. For a developer whose sole need is to fetch the secret value at runtime, this role provides the minimum access needed while supporting least privilege best practices.

This is the recommended design because web servers get public IPs (or are behind an external load balancer) to accept inbound user connections, while database servers remain in a separate private subnet with no public IP, preventing direct internet access. Cloud NAT on the database subnet allows outbound internet requests for updates or external APIs without exposing the database to inbound traffic. Separate subnets also enable granular VPC firewall rules and routing policies between tiers, reducing the blast radius if the web tier is compromised.

A DaemonSet is the correct controller because it declaratively ensures that one Pod runs on every node that matches its node selector, including nodes added later by the cluster autoscaler. The DaemonSet controller watches the cluster's node list and places a Pod on each qualifying node, removing Pods from nodes that no longer match. This makes it purpose-built for node-level workloads like metric collectors, kube-proxy, or network agents.

Cloud SQL for MySQL is a fully managed relational database service that provides automated backups, patching, replication, and high availability without requiring you to run MySQL yourself. It is a direct drop-in replacement for an existing MySQL database, preserving compatibility while eliminating the administrative burden of managing database infrastructure. This aligns with the migration goal of reducing operational overhead.

HA VPN with BGP is the correct choice because it provides a 99.99% SLA through two redundant tunnels to a single VPC, ensuring high availability even if one tunnel fails. Using BGP for dynamic routing automatically advertises routes and allows failover to the active tunnel, and it supports policy-based routing and route priority. This fully managed solution works over the public internet, making it both reliable and cost-effective for a hybrid cloud connection without requiring physical infrastructure.

This is the correct Helm command. `helm install` is used to deploy a chart for the first time with a given release name (`webapp`), chart path (`./chart`), and target namespace via `-n production`. The `--set image.tag=v2.1` flag overrides the chart's default `image.tag` value, ensuring the deployment uses the v2.1 container image as required.

A Cloud Storage trigger directly registers the function on the `google.cloud.storage.object.v1.finalized` event via Eventarc. When an object is uploaded or overwritten, Cloud Storage emits this event and routes it to the function automatically, with no intermediate service required. The function receives the object's metadata (e.g., bucket, name, size) in its payload, allowing immediate event-driven processing.

gcloud init is the intended bootstrap command for a new user because it performs the entire initial setup in one interactive flow: authenticating your Google account via the browser, then prompting you to choose or create a default project and set a default compute region/zone. It writes the resulting credentials and configuration properties into the active gcloud configuration file, leaving your environment ready for immediate use. This one-command workflow is exactly why it's the recommended starting point on a fresh workstation.

Viewer is the correct read-only basic role because it includes get and list permissions across most Google Cloud services while granting no create, update, or delete rights. It is the least privileged of the standard roles that can actually inspect project resources, making it the appropriate baseline for monitoring, auditing, and read-only troubleshooting. Unlike Browser, Viewer can see resource data such as VM configurations, bucket contents, and log entries, not just project hierarchy metadata.

Cloud Run automatically streams structured request logs to Cloud Logging, and each entry includes an httpRequest object with the request URL, response status, latency, and protocol. In Logs Explorer, filter using resource.type="cloud_run_revision" and add a filter like httpRequest.status >= 500 to isolate failed requests; you can then expand each log entry to see the exact endpoint, caller IP, and response details. This gives you the forensic, per-request view needed to identify which endpoints are returning errors.

Billing reports in Cloud Console support filtering by resource labels, which can be applied at project or resource level. By assigning a label like 'department=marketing' to resources, you can view cost breakdowns per department directly in the billing reports. This is the intended lightweight method for cost allocation without additional data processing.

Cloud Run jobs directly execute a containerized batch process to completion, scaling to zero immediately after the job finishes, so you pay only for the duration of execution (per-second billing). It supports long-running jobs (up to 24 hours), can be scheduled via Cloud Scheduler, and provides automatic retries, environment configuration, and VPC connectivity without managing servers or clusters. This makes it the most operationally simple and cost-effective option for a daily 30-minute file processing job.

This constraint limits the allowed disk types.

Cloud Monitoring SLOs are purpose-built for this scenario: you define a service-level objective with a 99.9% availability target, and Cloud Monitoring automatically calculates the error budget over a 30-day rolling window, tracks burn rate, and can alert when the budget is being consumed too quickly. This matches the requirement for measuring sustained availability against a target, and it is the only option that provides proactive error-budget-based alerting.

An OAuth2 access token is a bearer token that grants access to Google APIs on behalf of a user or service account. After `gcloud auth login`, the CLI stores the access token and refresh token, and it uses the access token in each RPC's Authorization header. You can also generate one programmatically from a service account's credentials or a user's OAuth flow, and then pass it via `gcloud auth` commands, making it a valid authentication method.

Cloud Run is a fully managed serverless platform that executes containers in a stateless, request-driven model: when there are no incoming requests, it can scale the service down to zero instances, so you are not charged for idle resources. It automatically scales up to handle traffic spikes, and billing is based on request duration and CPU/memory usage during active processing, measured in 100ms increments. This makes it the most operationally efficient choice for a containerized web application that expects variable traffic.

A ResourceQuota scoped to a namespace is the correct control because it enforces aggregate resource ceilings at the namespace level, evaluated at admission time. For example, setting `spec.hard.requests.cpu: "10"` and `spec.hard.requests.memory: "20Gi"` makes the API server reject any new Pod whose addition would push total namespace requests beyond those values with a 403 Forbidden response. Quotas can also cap limits.cpu, limits.memory, and object counts (e.g., services, secrets, PVCs), which directly addresses the need to avoid resource contention by bounding total consumption.

This is the only correct sequence: first stop the instance (gcloud compute instances stop), which transitions it to the TERMINATED state, then call gcloud compute instances set-machine-type with the desired type (predefined, custom, or E2), and finally start the instance again. The stop/start cycle is required because the hypervisor must release the old vCPU and memory resources before the new allocation can be applied. After the instance starts, it retains its existing disks, IP addresses, and metadata, so no configuration is lost.

IAM Deny policies, when set at a folder level, prevent the denied permissions from taking effect on all child resources, including the project — even if the project has an allow binding for those permissions. Deny takes precedence over allow.

google.cloud.storage.object.v1.finalized is the correct Eventarc event type for Cloud Functions (2nd gen) that corresponds to a new object being uploaded or an existing object being overwritten in Cloud Storage. It is the standard event for processing a newly created object, matching the legacy 'object finalized' event but now delivered through Eventarc for 2nd gen functions.

This is correct. When uniform bucket-level access (UBLA) is enabled on a bucket, all object ACLs are disabled, and access to objects is controlled solely by IAM permissions on the bucket itself. This ensures that per-object ACLs cannot conflict with bucket-level policies, simplifying permission management by enforcing a single, unified access control mechanism.

Cloud Filestore is a fully managed NFS service that provides a POSIX-compliant file system with proper file locking, consistent metadata, and low-latency access over the network. Multiple Compute Engine instances can mount the same Filestore file system concurrently in read/write mode, giving true shared storage without the need to manage your own NFS server. Its performance tiers (standard, premium, and high-performance SSD) deliver consistent throughput and IOPS, making it ideal for legacy applications that require coherent shared access and strong consistency across a cluster of VMs.

Cloud SQL for MySQL is a fully managed relational database service that provides the exact MySQL engine required by the application. It supports regional high availability through synchronous replication across two zones, automated backups, and point-in-time recovery, meeting both performance and durability needs without operational overhead. Its compatibility with standard MySQL drivers and protocols makes it the ideal choice for a regional MySQL workload.

A StatefulSet assigns each replica a stable ordinal name (e.g., pod-0, pod-1) and, when paired with a headless Service, gives each Pod a predictable DNS name like pod-0.mydb.svc.cluster.local. This creates the stable network identities and ordered provisioning/deprovisioning that stateful clustered applications need. Additionally, StatefulSets preserve persistent volume claims across restarts and scale up/down in a deterministic order, making them the standard choice for replicated databases and distributed systems.

A log sink is the correct Cloud Logging resource for streaming log entries to a supported destination, and BigQuery is a first-class destination. When you create a sink with `gcloud logging sinks create` or in the console, you specify a BigQuery dataset as the destination; Cloud Logging then continuously routes exported log entries into a partitioned table. This satisfies the requirement to export all logs from the project, optionally filtered by a log query.

This is the correct command. The attach-disk subcommand belongs to gcloud compute instances, takes web-server-1 as the resource, and uses --disk my-disk to specify the existing persistent disk to attach. It associates the already provisioned 100 GB disk with the instance, and requires the disk and instance to be in the same zone (or use --zone if they are not set).

Bigtable is the correct choice: wide-column NoSQL, designed for time-series and IoT workloads, single-digit ms latency, and scales to millions of QPS with additional nodes.

Workload Identity Federation is the correct approach because it lets GitHub Actions present an OIDC token minted for the GitHub workflow run, which Google Cloud then exchanges for a short-lived STS security token. This token is scoped to a service account via an IAM binding and optional attribute conditions, and it expires after a configurable duration (typically under 1 hour). No service account key is ever created or stored, satisfying the security policy while still granting the pipeline the exact permissions it needs via impersonation.

BigQuery is the correct answer because it is a fully managed, serverless data warehouse designed for petabyte-scale analytics using standard SQL. It automatically handles infrastructure provisioning, scaling, and high availability, with a columnar storage format and a powerful distributed query engine (Dremel). BigQuery also includes built-in features like BigQuery ML for in-database machine learning, partitioning/clustering for performance, and a pay-per-query pricing model, making it a true serverless data warehouse rather than a provisioning-based service.

When a project is deleted, it enters a 30-day pending deletion period by default, not immediate destruction. Throughout this period, all resources are inaccessible—VMs are stopped, storage buckets are unreachable—but the project metadata and underlying resources remain intact for recovery. An administrator can cancel the deletion anytime using the `gcloud projects undelete PROJECT_ID` command, which restores the project and its resources to full operation. After 30 days, the deletion becomes permanent and recovery is impossible.

StatefulSet is the correct workload API for stateful applications on GKE. It gives each pod a stable, unique network identity (e.g., `database-0`, `database-1`) and, via `volumeClaimTemplate`, provisions a dedicated PersistentVolume and PVC for each replica. Pods are created and scaled in ordinal order, ensuring predictable startup/shutdown sequences. This is ideal for databases, message brokers, and other apps that need sticky identity and per-pod persistent storage.

Cloud Shell provides each user with a persistent 5 GB home directory stored on a zonal persistent disk that is independent of the underlying compute instance. Because it is not tied to the VM's lifecycle, files you create remain available across all future Cloud Shell sessions, making it a reliable place to keep small scripts or configuration files.

--no-traffic deploys the new revision while setting its traffic share to 0%, leaving the current live revision (or existing traffic split) untouched. The deploy creates an immutable revision with a unique URL that can trigger the revision in isolation, enabling you to test the new code with production settings and dependencies before promoting it. This is the standard pattern for safe canary or blue/green deployment on Cloud Run.

An alerting policy is the correct resource in Google Cloud Monitoring for triggering notifications based on a specific metric condition. It contains one or more conditions (e.g., metric crosses a threshold for a set duration) and references a notification channel to deliver the alert. Without an alerting policy, no metric evaluation or notification can occur.

This creates a hard (required) anti-affinity rule that tells the scheduler: do not place a Pod on a node where a Pod matching the same selector already runs. Using topologyKey: kubernetes.io/hostname scopes that check to individual nodes, so the scheduler will only place one replica per node, even as nodes are added or removed. Because the rule is in the Pod spec, it is dynamic and self-managing, unlike manual node pinning. This is the standard declarative approach for achieving strict per-node exclusivity.