Free GCP ACE Exam Flashcards

Organization -> Folder(s) -> Project(s) -> Resources (VMs, buckets, etc.). Folders are optional; the hierarchy models how IAM permissions and organization policies cascade downward.

No. IAM allow policies are additive down the hierarchy - a lower-level policy can only grant more permissions, never revoke ones inherited from above. To restrict access you need an IAM Deny policy or must restructure where the resource sits in the hierarchy.

IAM policies control WHO can do WHAT (identity + permissions). Organization Policies control WHAT is allowed regardless of identity - e.g., restricting VM external IPs or which regions resources can be created in. Both inherit down the resource hierarchy.

It searches, exports, and tracks a historical/point-in-time snapshot of Google Cloud and IAM asset metadata across an organization - useful for compliance audits and change tracking, distinct from live metric dashboards.

Standalone Organizations create a fully independent administrative boundary (separate domain, subsidiary, or post-acquisition separation). Resources, IAM policies, and org policies do not cascade between separate Organization nodes the way they do between folders.

Yes - one Billing Account can be linked to many projects so an org can centralize payment while keeping resources isolated per project. A project itself, however, can only be linked to a single Billing Account at a time.

Further requests are throttled or rejected until the quota resets (often per-minute or per-day) or you request an increase in the console/support. Quotas exist to cap runaway usage and cost, not just to protect raw capacity.

Explicitly enable that API for the project, in the console or via 'gcloud services enable'. APIs are off by default on new projects, so calls fail until you enable the one you need.

A budget sets a spending target/threshold for a billing account or project. Alerts are the notifications triggered once spend crosses percentage thresholds of that budget (e.g., 50%, 90%, 100%) - a budget alone does not stop spending automatically.

Cloud Identity manages the directory of users and groups - the identities themselves. IAM grants those identities roles/permissions on resources. Cloud Identity users/groups can be provisioned manually or synced automatically from an existing directory.

Zonal PD is replicated within a single zone only (cheaper, lower latency). Regional PD is synchronously replicated across two zones in a region, protecting against a single zone outage, at higher cost.

Spot VMs offer steep discounts on spare Compute Engine capacity, but Google can preempt (terminate) them at any time with short notice. Best for fault-tolerant, interruptible batch work - not for production services that need guaranteed uptime.

The instance template defines the fixed VM configuration (machine type, image, disk, metadata) used to stamp out identical instances. The MIG then uses that template plus an autoscaling policy to add or remove instances based on load.

OS Login, because it ties SSH access to IAM identities and permissions - centrally revocable and auditable. Metadata-based SSH keys are managed per-project or per-instance with no IAM tie-in, making access harder to track or revoke at scale.

A suite covering OS patch management, OS inventory management, and OS Config policies - keeping many VMs' operating systems patched and compliant without manually connecting to each instance.

When your workload's vCPU-to-memory ratio doesn't match any predefined type (e.g., needs lots of RAM but few vCPUs). A custom machine type lets you specify exact vCPU and memory counts so you stop paying for resources you don't use.

A snapshot is an incremental, point-in-time backup of a persistent disk (can be scheduled) used to restore that disk's data. An image is a bootable template - often built from a snapshot - used to create new VM instances with a pre-configured OS and software.

Autopilot is fully managed: Google handles node provisioning, sizing, and security hardening, and you're billed per Pod resource request. Standard gives you full control over node pools, but you must provision, scale, and upgrade the nodes yourself.

A regional cluster replicates the control plane and nodes across multiple zones in a region, so a single zone outage doesn't take the cluster down. Zonal clusters are cheaper and simpler but have a single control-plane zone as a point of failure.

Nodes only receive internal IP addresses - no public IPs - reducing internet exposure. The control plane endpoint can also be made private, which then requires VPN, Interconnect, or an authorized network for administrative access.

HPA adds or removes Pod replicas based on observed metrics like CPU/memory (scales OUT). VPA adjusts the CPU/memory requests and limits of existing Pods (scales UP/DOWN). Applying both to the same metric on the same workload can conflict.

Autopilot bills per Pod based on the vCPU/memory the Pod actually requests, since Google manages the underlying nodes. Standard mode bills for the node VMs you provisioned, regardless of how tightly Pods pack onto them.

Install kubectl (e.g., via 'gcloud components install kubectl') and run 'gcloud container clusters get-credentials' to pull the cluster's authentication config into your local kubeconfig - without this, kubectl has no cluster to talk to.

Cloud Run runs any containerized service in any language/runtime, including long-running requests. Cloud Run functions is optimized for single-purpose, event-triggered code without you having to build and manage a container image yourself.

Common triggers include Pub/Sub messages, Cloud Storage object-change notifications, and Eventarc, which routes events from many Google Cloud and custom sources - the compute platform reacts to events instead of running continuously.

Terraform is a standalone IaC tool that applies declarative config through its own state file and CLI/CI pipeline. Config Connector manages Google Cloud resources as native Kubernetes objects, so teams can use kubectl and GitOps workflows already built around a cluster.

It's an AI-assisted console feature that analyzes your resources and configuration and offers recommendations (troubleshooting, cost/resource optimization, monitoring setup) - it assists and suggests, but the engineer still reviews and applies the changes.

GPUs are general-purpose accelerators suited to a broad range of ML training/inference and graphics workloads. TPUs are Google's custom accelerators optimized specifically for large-scale deep learning training and inference at scale.

All four have identical durability and retrieval latency, but differ in minimum storage duration and retrieval cost: Standard (frequent access), Nearline (~monthly access, 30-day minimum), Coldline (~quarterly, 90-day minimum), Archive (rare access, 365-day minimum, cheapest storage but priciest retrieval).

Cloud SQL is a managed regional relational database (MySQL/PostgreSQL/SQL Server) with vertical scaling limits. Spanner is a globally distributed, horizontally scalable relational database with strong consistency - choose it when you need global scale with SQL semantics beyond a single region.

Firestore is a serverless document database for app/mobile data with real-time sync and rich queries at moderate scale. Bigtable is a wide-column NoSQL store built for very high-throughput, low-latency workloads (time series, IoT, analytics) at massive scale, without complex query support.

A serverless, fully managed data warehouse for large-scale SQL analytics - there are no clusters to manage. You're billed mainly for data storage and the data scanned per query, or through flat-rate/reservation pricing for predictable workloads.

It automatically transitions objects to cheaper storage classes (e.g., Standard to Nearline to Coldline to Archive) or deletes them once conditions are met, such as object age or number of newer versions - removing the need for manual cleanup scripts.

It lets you supply and control your own encryption key via Cloud KMS instead of relying solely on Google-managed keys. You control key rotation and revocation - revoking the key can immediately make the protected data inaccessible.

It gives centralized, fleet-wide visibility into your Google Cloud databases (Cloud SQL, Spanner, AlloyDB, etc.) - health, security posture, and configuration recommendations - instead of checking each database service's own console separately.

Custom-mode, because auto-mode VPCs pre-create one subnet per region automatically with fixed IP ranges. Custom-mode requires you to manually create subnets with the exact ranges and regions you choose, avoiding overlap or wasted address space.

Shared VPC lets a host project centrally own network resources (subnets) that other service projects attach to, with the host controlling network admin. VPC Peering connects two separately owned VPCs so their resources can talk over internal IPs, with each side keeping its own control.

Classic VPC firewall rules attach directly to one VPC network. Cloud Next Generation Firewall (NGFW) policies are hierarchical, reusable rule sets that can also be applied across the org/folder/project hierarchy, in addition to using tags and service accounts as match criteria.

It lets that instance initiate outbound connections to the internet (e.g., to download OS updates) without needing its own external IP, keeping the VM unreachable from the internet while still allowing outbound-only access.

Cloud VPN builds an encrypted tunnel over the public internet - cheaper and faster to set up, but with variable throughput and latency. Cloud Interconnect provides a dedicated or partner physical connection into Google's network - higher, more predictable bandwidth at higher cost and longer setup time.

An ephemeral IP can change whenever a VM is stopped and restarted, silently breaking DNS records, firewall allowlists, or client configs pointed at that address. A static (reserved) IP stays the same until you explicitly release it.

Cloud Monitoring collects and alerts on numeric time-series metrics (CPU utilization, request latency, custom metrics). Cloud Logging collects and lets you search log entries (application logs, audit logs, VPC Flow Logs). They're complementary products, not the same thing.

Admin Activity logs - they record configuration and permission changes and are always on at no charge. Data Access logs (reads/writes to data) are off by default for most services and must be explicitly enabled; System Event logs are Google-generated and always on.

Cloud Trace analyzes end-to-end latency across a distributed request path, showing where time is spent between services. Cloud Profiler continuously samples CPU and memory usage inside your running application code to find hotspots - one is request-latency-focused, the other is code-execution-focused.

It routes log entries matching a filter to a destination - a log bucket, BigQuery dataset, Pub/Sub topic, or external system - enabling long-term retention, analytics, or export beyond Cloud Logging's default retention window.

Basic roles (Owner/Editor/Viewer) are broad and project-wide - simple but often over-permissive. Predefined roles are curated by Google for specific services with tighter, least-privilege scoping. Custom roles let you hand-pick exact permissions when neither fits, but you must maintain them yourself.

It lets an authorized user or workload temporarily 'act as' a service account to perform actions with that account's permissions, without ever downloading or distributing its long-lived key - improving auditability and cutting key-leak risk.

Short-lived credentials (via impersonation or Workload Identity) automatically expire, limiting the damage window if leaked. A long-lived JSON key stays valid indefinitely until someone manually rotates or deletes it, making it a bigger standing security liability.

It lets workloads running outside Google Cloud (AWS, on-prem, GitHub Actions, etc.) authenticate to Google Cloud APIs using their own identity provider's credentials, exchanged for short-lived tokens - without ever creating or downloading a Google service account key.

Bind the Kubernetes service account to a Google service account via Workload Identity Federation for GKE, so Pods get Google Cloud permissions through their Kubernetes identity - avoiding mounting long-lived service account key files inside containers.