Study guide
4.1 API Management & Rate Limiting with Apigee and API Gateway
Google Cloud Professional Cloud Developer Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Exam and Compute Platform Decisions
1.1 Current Exam, Sources, and Scenario Method 1.2 Cloud Run Execution and Platform Selection 1.3 GKE Modes and Compute Engine Trade-offs
2 Chapter 2: Container Engineering and API Contracts
2.1 Stateless Microservices and Multi-stage Builds 2.2 Container Hardening, Signals, and Layer Caching 2.3 REST, gRPC, and Protobuf Contracts
3 Chapter 3: gRPC Compatibility and Geographic Routing
3.1 Schema Evolution and gRPC Routing 3.2 Geography, Network Tiers, and Load Balancers 3.3 Serverless NEGs, Sessions, and Edge Controls
4 Chapter 4: API Management and Caching
4.1 API Management & Rate Limiting with Apigee and API Gateway 4.2 Memorystore and Cache Access Patterns 4.3 Cache Invalidation, Capacity, and Failover
5 Chapter 5: Messaging, Task Dispatch, and Orchestration
5.1 Event-Driven Messaging with Cloud Pub/Sub 5.2 Task Queues & Rate Throttling with Cloud Tasks 5.3 Event Routing and Service Orchestration: Eventarc & Cloud Workflows
6 Chapter 6: Resilience and Relational Availability
6.1 Designing Resilient Systems: Circuit Breaking, Retries & Failover 6.2 Cloud SQL Availability and Recovery 6.3 Connection Budgets and Spanner Consistency
7 Chapter 7: Distributed Schemas and NoSQL Data Models
7.1 Spanner Keys, Indexes, and Transactions 7.2 Firestore Data, Indexes, and Transactions 7.3 Bigtable Row Keys and Replication
8 Chapter 8: Object Storage and Application Identity
8.1 Cloud Storage Lifecycle and Signed Access 8.2 Workload Identity and Service Authentication 8.3 Secret Delivery, Rotation, and IAP
9 Chapter 9: Security, Data Integration, and Developer Credentials
9.1 Private Communication, Key Rotation, and Vulnerability Response 9.2 AlloyDB Schemas and BigQuery Ingestion 9.3 CLI Configurations, Local ADC, and Cloud Shell
10 Chapter 10: Managed Development and Automated Tests
10.1 Cloud Workstations and the Container Inner Loop 10.2 Emulating Google Cloud Services & Database Auth Proxies 10.3 Automated Testing Strategies: Unit, Integration, and Mocking
11 Chapter 11: AI Development Tools and Build Pipelines
11.1 AI Coding Assistants, Context, MCP, and Test Review 11.2 Cloud Build Workers and Step Dependencies 11.3 Builders, Substitutions, Triggers, and IAM
12 Chapter 12: Artifact Security and Admission Policies
12.1 Artifact Management and Vulnerability Scanning with Artifact Registry 12.2 Build Provenance and Admission Concepts 12.3 Attestors, Policy Enforcement, and Break-glass
13 Chapter 13: Cloud Run and GKE Deployment Configuration
13.1 Cloud Run Deployment and Scaling Configuration 13.2 Cloud Run CPU, Private Egress, and Secrets 13.3 GKE Workload Controllers and Gateway Routing
14 Chapter 14: Kubernetes Resources, Health, and Progressive Releases
14.1 GKE Resources, OOM Diagnosis, and Autoscaling 14.2 Container Health Probes, Lifecycle Hooks & Graceful Shutdown 14.3 Progressive Delivery: Traffic Splitting, Canary, and Blue/Green Rollouts
15 Chapter 15: Source/Event Deployment and Cloud API Integration
15.1 Source Deployment, Event Receivers, and API Versions 15.2 Client Libraries, Service Enablement, and ADC 15.3 API Responses, Pagination, Caches, and Retries
16 Chapter 16: Tracing, Sampling, and Monitoring
16.1 Trace Context and OpenTelemetry Export 16.2 Custom Spans, Trace Analysis, and Sampling 16.3 Application Metrics, Health Checks & Alerting with Cloud Monitoring
17 Chapter 17: Structured Logs, Routing, and Error Management
17.1 Structured Logs, Trace Correlation, and Queries 17.2 Log Routing, Export Destinations, and Exclusions 17.3 Error Reporting Formats and Regression Handling
18 Chapter 18: Profiling, Generative AI, and Assisted Troubleshooting
18.1 Cloud Profiler Types and Flame Graph Analysis 18.2 Generative AI Integration with the Google Gen AI SDK 18.3 Evidence-Based Troubleshooting with AI Assistance
4.1 API Management & Rate Limiting with Apigee and API Gateway
Key Takeaways Explain This Topic AI
Google Cloud API Gateway is a serverless, OpenAPI 2.0-managed gateway tailored for Cloud Run and Cloud Functions, whereas Apigee provides enterprise-grade API lifecycle management, mediation, and policy pipelines.
Apigee SpikeArrest protects backend services against microbursts and resource exhaustion using a smoothing leaky-bucket rate, configured in requests per second (ps) or per minute (pm).
Apigee Quota policies enforce business-level consumption limits over calendar time windows (hours, days, months), typically tied to API developer products and monetization tiers.
API Gateway validates JWTs and Firebase Auth tokens at the network perimeter, preventing unauthorized requests from invoking serverless compute backends.
In Apigee proxy flow processing, SpikeArrest and authentication policies should execute in the PreFlow of the ProxyEndpoint to abort unauthorized or abusive traffic before backend resources are engaged.
Last updated: October 2026
2.2 API Management & Rate Limiting with Apigee and API Gateway
Modern cloud-native architectures rely on microservices communicating over HTTP/REST and gRPC. Exposing raw backend container endpoints directly to external clients introduces severe security and operational risks, including credential leakage, resource starvation, cascading failures, and uncontrolled billing spikes. Google Cloud provides two primary API management solutions: Google Cloud API Gateway and Apigee .
Architectural Comparison: API Gateway vs. Apigee
Understanding when to select API Gateway versus Apigee is a core skill for Google Cloud developers.
Capability Google Cloud API Gateway Apigee (Apigee X & Apigee Hybrid)
Target Persona Developers building lightweight serverless applications. Enterprise architects managing full API lifecycles across multi-cloud/hybrid estates.
Infrastructure Model Fully managed, serverless, auto-scaling pay-per-call. No provisioned instances. Dedicated runtime plane (Apigee X managed VPC peering; Apigee Hybrid on Kubernetes). Provisioned instance/organization model.
API Specification Supported OpenAPI 2.0, 3.0.x, and 3.1.x , plus documented gRPC service configurations; feature support differs by version. OpenAPI 2.0/3.0, WSDL/SOAP, GraphQL, gRPC, and custom REST proxies.
Payload Transformation None. Passthrough proxy only; cannot transform XML to JSON or alter headers dynamically. Extensive Mediation Policies ( XMLToJSON , JSONToXML , AssignMessage , ExtractVariables , JavaScript, JavaCallout, Python).
Traffic Shaping Basic rate limiting via Google Cloud Service Infrastructure / API Keys quotas. Granular SpikeArrest , Quota , and backend concurrency controls policies.
Authentication API Keys, JWT (Google ID Tokens, Auth0, Okta), Firebase Authentication. OAuth 2.0, OpenID Connect, SAML, Mutual TLS (mTLS), HMAC, API Key verification.
Developer Ecosystem None. Developers interact directly with OpenAPI documentation. Integrated Developer Portals , API Product bundling, and automated monetization billing.
Google Cloud API Gateway Deep Dive
Google Cloud API Gateway sits in front of serverless backends (Cloud Run, Cloud Functions, and App Engine), terminating incoming client requests, validating tokens, and forwarding requests over authenticated Google internal channels. +--------------------------------------------------------------------------+
- | Google Cloud API Gateway Traffic Flow |
- +--------------------------------------------------------------------------+
- | |
- | [ Mobile / Web Client ] |
- | | |
- | | 1. HTTP Request + Bearer JWT / API Key |
- | v |
- | +----------------------------------------------------------------------+ |
- | | Google Cloud API Gateway (Managed Envoy Core) | |
- | | - Uses the API config; application still validates payloads | |
- | | - Authenticates JWT via Google/Firebase JWKS URI | |
- | | - Injects Service Account OIDC Identity Token | |
- | +----------------------------------------------------------------------+ |
- | | |
- | | 2. Authenticated Internal Ingress (`x-google-backend`) |
- | v |
- | +----------------------------------+----------------------------------+ |
- | | | | |
- | v v v |
- | [ Cloud Run: /orders ] [ Cloud Functions: /auth ] [ App Engine ]|
- +--------------------------------------------------------------------------+
- OpenAPI 2.0 Configuration and Google Extensions
API Gateway is configured using standard Swagger/OpenAPI 2.0 files augmented with proprietary x-google-* vendor extensions: swagger: "2.0"
info:
- title: "Customer Commerce API"
- description: "Serverless edge API for order management"
- version: "1.0.0"
schemes:
- "https"
produces:
- "application/json"
paths:
/v1/orders:
get:
- summary: "List customer orders"
- operationId: "listOrders"
security:
- firebase_auth: []
x-google-backend:
- address: "https://orders-service-xyz-uc.a.run.app"
- path_translation: "APPEND_PATH_TO_ADDRESS"
- jwt_audience: "https://orders-service-xyz-uc.a.run.app"
securityDefinitions:
firebase_auth:
- type: "oauth2"
- flow: "implicit"
- authorizationUrl: ""
- x-google-issuer: "https://securetoken.google.com/my-gcp-project-id"
- x-google-jwks_uri: "https://www.googleapis.com/service_accounts/v1/jwk/securetoken@system.gserviceaccount.com"
- x-google-audiences: "my-gcp-project-id"
- Deployment Lifecycle CLI Workflow
- Deploying API Gateway requires a three-step command sequence: ## Create the API resource container
- gcloud api-gateway apis create commerce-api \
- -project=my-gcp-project-id
- ## Upload the OpenAPI spec and compile the API Config
- gcloud api-gateway api-configs create commerce-api-cfg-v1 \
- -api=commerce-api \
- -openapi-spec=openapi-spec.yaml \
- -backend-auth-service-account=api-gw-invoker@my-gcp-project-id.iam.gserviceaccount.com \
- -project=my-gcp-project-id
- ## Provision the physical gateway instance in the target region
- gcloud api-gateway gateways create commerce-gateway \
- -api=commerce-api \
- -api-config=commerce-api-cfg-v1 \
- -location=us-central1 \
- -project=my-gcp-project-id
- Apigee Enterprise API Management & The Proxy Pipeline
Apigee abstracts downstream microservices by placing an API Proxy between client applications and backend target endpoints.
Anatomy of an API Proxy
ProxyEndpoint: Defines how client applications consume your API (inbound URL path, TLS settings, client authentication, and request/response transformations).
TargetEndpoint: Defines how the proxy communicates with downstream backend services (forwarding URLs, service discovery, connection pooling, and backend authentication). +--------------------------------------------------------------------------+
- | Apigee Flow Processing Pipeline |
- +--------------------------------------------------------------------------+
- | |
- | Client ---> [ ProxyEndpoint PreFlow ] (SpikeArrest, VerifyJWT) |
- | | |
- | v |
- | [ Conditional Flows ] (Verb & Resource Path Rules) |
- | | |
- | v |
- | [ ProxyEndpoint PostFlow ] |
- | | |
- | v |
- | [ TargetEndpoint PreFlow ] (AssignMessage, Backend Auth) |
- | | |
- | v |
- | [ Target Service Invocation ] (Cloud Run / GKE / On-Prem) |
- | | |
- | v |
- | [ TargetEndpoint PostFlow ] |
- | | |
- | v |
- | [ ProxyEndpoint PostFlow ] (JSONToXML, Masking) |
- | | |
- | Client <--- [ ProxyEndpoint PostClientFlow ] (Async Cloud Logging Sink) |
- +--------------------------------------------------------------------------+
- Pipeline Flow Execution Order
PreFlow: Always executes first on every request. Developers place high-priority security policies (e.g., SpikeArrest , VerifyAPIKey , VerifyJWT ) here to terminate unauthorized or abusive traffic before executing expensive logic.
Conditional Flows: Executes selectively based on HTTP verbs or URI path conditions (e.g., executing an XMLToJSON policy only when request.verb = "GET" AND proxy.pathsuffix MatchesPath "/items" ).
PostFlow: Executes after conditional flows on every transaction. Used for global response logging, header cleanup, or CORS injection.
PostClientFlow: Executes after the response has been completely transmitted back to the client. This flow is strictly non-blocking and is used for streaming metrics, audit logging, and analytics to Cloud Logging without impacting client perceived latency.
Traffic Shaping: SpikeArrest, Quota, and Backend Capacity
SpikeArrest protects services against excessive request rates. Quota tracks a business usage allowance such as 10,000 requests per developer per month. Neither automatically gives a database an exact upper bound on live connections.
Current Apigee organizations should use UseEffectiveCount=true . This uses a regional distributed sliding-window algorithm. The older smoothing description of one request every two seconds for 30pm applies to a different mode and must not be treated as the behavior of current production Apigee. <SpikeArrest name="ProtectBackend">
- <Rate>30pm</Rate>
- <UseEffectiveCount>true</UseEffectiveCount>
- </SpikeArrest>
Requests that exceed the policy are rejected rather than queued. A burst below the configured sliding-window allowance is not automatically rejected just because two requests arrive within the same second. Identity-based counters can use an authenticated client identifier; an API key identifies a consuming application, not necessarily an end user.
A Quota policy is appropriate for a contractual allowance. Choose its identifier, interval, distributed counter, and synchronization behavior deliberately. Asynchronous distributed counters can overshoot during bursts. A quota is not a billing reconciliation ledger.
ConcurrentRateLimit is a legacy/deprecated Edge policy and is not a current Apigee capacity-control recommendation. Protect databases through bounded application pools, workload scaling limits with headroom, timeouts, and Cloud Tasks when work can be queued. A proxy request may perform several queries or share a pool, so 75 in-flight HTTP requests do not imply exactly 75 database connections.
Protecting Backend Microservices Against Starvation
When microservices running on Cloud Run or GKE face unexpected upstream load, failures propagate downstream into databases and caches unless buffered by the API layer.
Fail Early at the Edge: Place SpikeArrest and VerifyJWT in the ProxyEndpoint PreFlow . An unauthorized or over-limit request can be rejected before invoking the backend, without consuming backend compute vCPU or VPC connector bandwidth.
Protect Shared Databases: Bound application connection pools and reserve database capacity for administration, maintenance, and concurrent revisions. Queue asynchronous work in Cloud Tasks where suitable.
Decouple Asynchronous Writes: When an API receives high-throughput ingestion data that does not require synchronous database writes, use Apigee to route requests directly to a Cloud Pub/Sub topic via service callout or API Gateway backend, transforming the interaction into an asynchronous event stream.
Official references checked October 18, 2026: Google Cloud 1 , Google Cloud 2 .