When I work through API exposure scenarios on the Professional Cloud Architect exam, Cloud Endpoints almost always shows up as the answer when a question describes a managed API gateway that needs to handle authentication, rate limiting, and request validation without forcing a team to build that logic into every backend service. It is GCP's API gateway product, and the exam treats it as the default option whenever a scenario asks how to expose an API to external clients while keeping security and observability centralized.
I want to walk through what Cloud Endpoints actually does, how it routes traffic to backends, and the specific signals that tell me a Professional Cloud Architect question is pointing toward this service rather than a load balancer or a custom proxy.
Cloud Endpoints is a fully managed API gateway service on Google Cloud that allows you to expose, monitor, and secure APIs for your applications. The phrase "fully managed" matters on the exam because it rules out scenarios where the correct answer is to deploy a self-managed proxy on Compute Engine or run a third-party API gateway in GKE. If a question describes a team that wants to expose APIs without operating gateway infrastructure themselves, Cloud Endpoints is the GCP-native answer.
Under the hood, Cloud Endpoints uses the Extensible Service Proxy, often abbreviated as ESP. The ESP sits in front of the backend and handles API management tasks such as authentication, rate limiting, and request validation. This is the operational pattern the exam expects me to recognize. The proxy is what enforces policy, and it does so before requests ever reach the backend service. That separation of concerns is the whole point of an API gateway.
Cloud Endpoints integrates with IAM to enforce security policies and authentication. The supported credential types are API keys, JSON Web Tokens (JWTs), and OAuth 2.0. On the Professional Cloud Architect exam, the way these three options map to scenarios is fairly consistent.
API keys are the right choice when a question describes identifying a calling project or application without proving the identity of an end user. They are appropriate for usage tracking and basic access control but do not authenticate users.
JWTs come up when a scenario describes service-to-service authentication or when an external identity provider issues signed tokens that the gateway needs to validate. Cloud Endpoints can verify JWTs from Firebase Auth, Auth0, or any provider that publishes a public key set.
OAuth 2.0 fits scenarios involving end-user authentication, particularly when the API is being called on behalf of a user who has granted consent to a client application.
The exam will not usually ask me to write the configuration for these. It will ask me to pick the right credential type given a description of who is calling the API and what needs to be proven about them.
APIs are defined using OpenAPI or gRPC specifications. The OpenAPI spec is the more common case on the exam because it covers REST APIs, which is what most scenarios describe. gRPC shows up when a question specifically mentions binary protocols, streaming, or microservices that need low-latency communication. The spec file is what tells the ESP how to route incoming requests, what authentication each endpoint requires, and which backend handles which path.
The routing model is worth understanding because it shapes how I answer architecture questions. Clients send requests to Cloud Endpoints, and the gateway routes each request to the appropriate backend based on the path. A single Cloud Endpoints deployment can front multiple backends. One path might route to an authentication service, another to a reporting service, another to a billing service. Each backend can run on a different compute platform.
The supported backends are App Engine, Cloud Run, GKE, Compute Engine, Cloud Functions, and even third-party services running outside Google Cloud. This flexibility is the reason Cloud Endpoints shows up so often as the answer on Professional Cloud Architect questions about microservices. The exam likes scenarios where one service runs on Cloud Run, another on GKE, and another on Cloud Functions, all behind a single API surface. Cloud Endpoints is what makes that surface coherent.
Cloud Endpoints integrates with Cloud Monitoring and Cloud Trace to track API performance and usage. On the exam, this matters when a question asks how to detect latency issues across an API surface or how to measure traffic per endpoint without instrumenting each backend separately. Because the ESP sits in front of every request, it has natural visibility into request rates, error rates, and latency for every API method. That data flows into Cloud Monitoring for dashboards and alerts and into Cloud Trace for distributed tracing.
If a Professional Cloud Architect question describes a team that wants centralized API metrics without modifying backend code, Cloud Endpoints is the answer because the gateway is already collecting that data.
A few patterns reliably indicate Cloud Endpoints is the right choice on the exam. The scenario describes a managed API gateway. The team wants to enforce authentication and rate limiting in one place rather than per-service. The architecture involves multiple backends across different compute services. The team needs API metrics and tracing without rewriting backend code. The API is defined by an OpenAPI or gRPC spec.
If I see a scenario that mentions an external load balancer for HTTP traffic distribution but does not mention authentication, rate limiting, or API-specific concerns, that is a load balancer question, not a Cloud Endpoints question. The gateway adds API management on top of routing, and the exam draws that distinction carefully.
If you want to go deeper on Cloud Endpoints and how it fits with the rest of GCP's API and security tooling, I cover it in the Professional Cloud Architect course alongside the rest of the security material.
