Prepare and test your skills
Prepare and test your skills
Enforce API Security and Access Control is the practice of making sure only authorized callers can reach application interfaces and that every request is checked and protected. In Google Cloud, Apigee (opens in a new tab) sits in front of backend services such as Cloud Run to validate requests and enforce authentication. Extensible Service Proxy V2 (ESPv2) checks API keys with Service Control, while Identity and Access Management (IAM) (opens in a new tab) controls which users and service accounts can invoke resources. Together these layers separate who can call an API from what that caller is allowed to do.
Secure API endpoints with Apigee means placing policy checks between the client and the backend so unsafe traffic never reaches application code. Traffic flows from the client caller to Apigee and then from Apigee to the backend service. Apigee enforces three types of protection at that boundary:
Because these checks run centrally in Apigee, individual backend services do not need to reimplement the same logic, and threat protection policies can be updated once for all exposed versions.
An API key distribution model controls where keys are created and whether calls can be traced to individual callers. The caller sends the key with each request for ESPv2 to verify with Service Control. The key is created either in the project where the API is configured or in a project where the API is enabled. Choose the model based on whether callers have their own Google Cloud projects and whether callers must be told apart:
| Model | Use when | Where keys live |
|---|---|---|
| Let users create their own key | Callers have their own project and must be distinguished | Each caller enables the API in their own project and creates their own key |
| Create a separate project for each caller | Callers must be distinguished but some have no project | A separate project is created per caller with the API enabled and one key per project |
| Create a key for each caller in the same project | Callers do not need to be distinguished but need different restrictions | Multiple keys are created in the same project with different restrictions |
| Create one key for all callers | Callers need no distinction or different restrictions, but anonymous access must be blocked | One key is created in the configured or enabled project and shared by all callers |
When callers manage their own projects, granting permission to enable the API lets each team manage its own key. When callers are external, separate projects or separate keys preserve the ability to revoke or restrict one caller without affecting the others.
Restricting API access with API keys (opens in a new tab) limits where a stolen key can be reused by binding the key to allowed applications. Application restrictions specify which websites, IP addresses, or apps can use a key, so a request from an unlisted referrer, address, or app is rejected even if the key is valid. For HTTP referrers, the restriction must include a scheme, so https://example.com/* is valid while example.com/* is not.
Hardening also depends on how ESPv2 behaves when it cannot reach Service Control. ESPv2 calls from the proxy to Service Control to verify each key, and the --service_control_network_fail_policy startup flag controls the failure mode. The default value is open, which allows requests during network failures, while close rejects requests that cannot be verified. Set the flag to close when keys protect sensitive APIs and user data, so unverified requests fail closed instead of passing through.
Exam tip: ESPv2 defaults to --service_control_network_fail_policy=open; set it to close when API keys guard sensitive APIs so unverified requests fail closed during Service Control outages.
IAM enforces central management of users, groups, and service accounts under the principle of least privilege. Each pipeline, job, and deployed model uses a dedicated service account with only the minimum required permissions, so compromise of one identity does not grant broad access to other buckets, registries, or APIs. For example, a training pipeline service account can be limited to reading from one Cloud Storage bucket and writing to Model Registry.
IAM Conditions add attribute-based control on top of role grants. A condition checks the request context before access is granted, such as allowing a service account to trigger a pipeline only if the request comes from a trusted Cloud Build trigger. The workflow depends on both the role binding and the condition being satisfied at request time, because the policy applies to the service account making the call.
Network and storage boundaries limit lateral movement if an API, pipeline, or key is compromised. A Virtual Private Cloud (VPC) (opens in a new tab) and VPC Service Controls define a service perimeter around sensitive services, so traffic flows only from allowed networks and identities to protected APIs such as Cloud Run functions and storage. Understanding the VPC configuration where code runs ensures pipelines and build artifacts are not reachable from untrusted networks.
Data protections reinforce the perimeter by securing artifacts at rest and in transit. Cloud Key Management Service (Cloud KMS) encrypts model artifacts and sensitive files, which protects data even if underlying storage is compromised, while Cloud Storage access controls and Model Registry provide fine-grained access and encryption at rest. Security Command Center then monitors security posture to detect incorrect configurations and drift from defined standards, so unauthorized access paths are tracked and corrected.
Expose and Manage Services via API Gateways is the use of a centralized entry point to publish backend services through managed public URLs. On Google Cloud, Apigee (opens in a new tab) performs this role by placing API proxies in front of backends such as Cloud Run services, so traffic flows from the client app through the proxy to the backend service. Policies attached to the proxy control security, traffic, and mediation, while API products (opens in a new tab) bundle proxies into managed service plans. This model optimizes performance and availability without changing backend code.
An API proxy is the HTTP endpoint on Apigee that maps a public URL to a backend service and defines expected query parameters, headers, body parameters, credentials, and response format. The proxy isolates the app developer from the backend service, so the team can change a database, move services to a new host, or revise internal logic as long as the public API stays consistent. Policies run on Apigee, not on the backend server, to add data transformations, security checks, conditional logic, and custom code. Apigee also validates payload structure, enforces one-way and two-way Transport Layer Security (TLS) including mutual TLS (mTLS) at ingress, and verifies OAuth and JSON Web Token (JWT) signatures before traffic reaches the backend.
Apigee provides gateway threat-protection policies that sanitize input at the gateway layer:
These policies stop malformed or malicious input at the proxy, so the backend only receives traffic that passed gateway checks.
An API product is a bundle of one or more API proxies combined with a service plan that sets access limits, security, and monitoring. The API product is the central mechanism Apigee uses for authorization and access control, and multiple products can share the same proxy with different properties. For example, one product can expose a proxy with 1000 requests per day at a low price, while another exposes the same proxy with a much higher limit at a higher price. A team can also offer a free product with read-only access and a paid product with read and write access to the same proxies.
Access is controlled by product visibility and by quota defaults defined on the product. A quota on the product can apply to all included proxies or be refined as operation-level quotas, where an operation-level quota takes precedence over the product-level quota. Setting a quota value on the product does not automatically enforce it; the value is a default limit referenced by Quota policies in the proxies, so updating the product setting automatically updates what those policies enforce.
Publishing and consuming an API product is the ordered handoff where the provider packages the service and the developer registers to call it with a credential. Traffic flows from the registered client app through an API proxy bundled in the product to the backend service, with an API key carried on every request. The provider retains control after issuance and can revoke a key or set a time limit that forces a refresh.
Registration approval can be automatic or require manual approval for each app. Revocation immediately stops the client app from reaching the backend through the product.
Traffic management with SpikeArrest (opens in a new tab) and Quota policies keeps app traffic within backend capacity and prevents one client from using more than permitted. The SpikeArrest policy protects against sudden surges by limiting the number of requests processed by an API proxy and sent to the backend, which guards against lag and downtime from denial-of-service attacks or buggy clients. The Quota policy enforces consumption limits by maintaining a distributed counter for an identifiable entity such as an app, developer, API key, or access token. Both policies can be used in one proxy when a service needs surge protection and contractual limits together.
| Policy | How it controls traffic | Choose when |
|---|---|---|
| SpikeArrest | Limits request rate sent from the API proxy to the backend to smooth bursts | The risk is sudden spikes, denial-of-service traffic, or faulty clients causing lag or outage |
| Quota | Maintains a distributed counter per app, developer, key, or token over a time interval | The goal is to enforce business contracts or service-level agreements |
The Quota policy is computationally expensive, so for high-traffic APIs it should use longer intervals such as a day or month rather than short windows. Apigee also provides caching, mediation, and analytics to reduce backend load and reveal usage patterns, which helps high-cost generative AI APIs. For those workloads, specialized LLMTokenQuota and PromptTokenLimit policies extend the same idea from request counts to token counts for granular cost control.
Exam tip: Use SpikeArrest for operational surge protection and Quota for contractual consumption limits; a quota value set on an API product only takes effect when a Quota policy references it.
Gateway options on Google Cloud differ by whether the API is externally exposed, internal to Google Kubernetes Engine (GKE) and Cloud Run, or enterprise-scale. Traffic flows from clients to the selected gateway and then to prediction, training, data, or application backends, with the gateway enforcing contracts, keys, and limits.
For increased privacy, expose applications through Apigee or Apigee hybrid with end-to-end mTLS, optionally using a shared VPC with Apigee in the same organization.
Implement API Versioning and Lifecycle Strategies is the method for evolving an API without breaking existing clients. The strategy separates additive changes that preserve compatibility from breaking changes that require a new version, labels each endpoint with a lifecycle state, and provides a systematic path to deprecate legacy endpoints. In examples such as the Looker API (opens in a new tab) and the Chronicle API, a significant change is added as a new endpoint bundled into a new API version so the existing endpoint remains unchanged.
Additive versus breaking changes describe whether existing clients can safely ignore an API change. Additive changes preserve backward compatibility, including new optional parameters and new properties in responses, which are not breaking because REST clients are expected to ignore unknown properties. A breaking change alters the existing contract and forces clients to change, such as renaming functions, values, or properties or changing types like integer to string. When a stable endpoint needs a significant change for new architecture or functionality, the change is placed in a new endpoint and bundled into a new API version rather than modifying the existing endpoint.
Stable, beta, and deprecated endpoint states communicate whether breaking changes are allowed and whether an endpoint will be removed. A stable endpoint is not expected to change, and no breaking changes are released to stable endpoints except in extreme cases such as fixing a security problem. A beta endpoint is in active development and may change in the future, so callers should track release notes for disruptive updates. A deprecated endpoint is still supported and can still be used now, but it will be deleted in a future release, at which point code still using it will break and should have already been refactored.
Stable, beta, and deprecated endpoints are marked in the API Explorer and in the 4.0 API Reference, where unmarked endpoints are considered stable. The same lifecycle appears in platform migrations, where legacy Backstory and Ingestion endpoints must transition to modern regional Chronicle endpoints before shutdown. Legacy SIEM APIs cannot be called from new instances starting October 26, 2026 and become fully non-functional by July 20, 2027, while the legacy SOAR API and API keys remain available only until November 30, 2026.
Exam tip: Stable means no breaking changes except extreme cases, beta means breaking changes are allowed, and deprecated means the endpoint still works now but will be removed later.
Migrating applications to a new API version moves client code from the old contract and endpoint address to the new contract and address in a controlled order. When an application upgrades its client SDK or API URL, the team must search for updated function, value, and property names and verify support for type changes. Auditing is language-dependent because compiled, strongly-typed languages surface mismatches as compile errors, while dynamic languages such as JavaScript, Ruby, and Python may require runtime unit tests that exercise real API calls rather than mocked calls.
A complete platform migration to the Chronicle API (opens in a new tab) follows an ordered workflow where each step depends on the previous one:
backstory.googleapis.com or malachiteingestion-pa.googleapis.com.https://www.googleapis.com/auth/chronicle-backstory to https://www.googleapis.com/auth/chronicle or https://www.googleapis.com/auth/cloud-platform.Modern addresses carry the version explicitly as [api_version]/projects/[project_id]/locations/[location]/instances/[instance_id]/..., where api_version can be v1alpha, v1beta, or v1. The full address becomes https://[service_endpoint]/[api_version]/projects/[project_id]/locations/[location]/instances/[instance_id]/..., so traffic flows from the client to the regional endpoint that owns the project and instance. Before migration, the instance must be on modern SIEM infrastructure and chronicle.googleapis.com must be enabled in the hosting project.
Exposing versioned APIs with managed gateways separates the public API endpoint from the backend endpoint through a managed entry point. The public definition is written as an OpenAPI 2.0 or OpenAPI 3.x spec that defines the public REST URL, the backend service, and characteristics such as authentication, data format, and response options. At runtime, requests to the API endpoint are passed to the backend endpoint with request data, and responses from the backend are passed back to the client, so the client needs only the URL, verb, authentication requirements, and data format. This separation lets a new version be published as a new config and route while legacy endpoints remain available until deprecation is complete.
Three managed products divide API exposure by scale and control needs:
| Product | Intended scope | Management strengths |
|---|---|---|
| API Gateway | Externally exposed APIs fronting serverless backends | Centralized secure entry point, consistent REST interface, API keys and OAuth 2.0, rate limiting and quotas |
| Cloud Endpoints | Internal or controlled APIs on GKE and Cloud Run | Developer-friendly key generation, integrated monitoring and tracing, OpenAPI spec automation |
| Apigee | Enterprise-scale APIs, including generative AI APIs | Advanced threat protection and OAuth 2.0, caching, quotas, mediation, and deep analytics |
API Gateway (opens in a new tab) applies management at runtime through supporting systems where Service Control checks authentication and keys and reports logging data, while Service Management stores the API configuration uploaded from the OpenAPI spec. The gcloud CLI uploads the spec to create the API config and deploys that config to the gateway, and the Google Cloud console exposes monitoring, logging, authentication settings, and key generation. Following best practices for managing API keys (opens in a new tab) helps control exposure of versioned endpoints during this lifecycle.
--service_control_network_fail_policy defaults to open but should be set to close when keys protect sensitive APIs.The SpikeArrest policy limits the request rate sent from the API proxy to the backend to smooth bursts and prevent lag or outages, while the Quota policy maintains a distributed counter per app, developer, API key, or access token over a time interval to enforce consumption limits. Use SpikeArrest for operational surge protection from denial-of-service traffic or faulty clients and use Quota for contractual or service-level agreement limits.
Set the --service_control_network_fail_policy flag to close when API keys protect sensitive APIs and user data so unverified requests fail closed during Service Control outages. The default value is open, which allows requests to pass through when ESPv2 cannot reach Service Control to verify a key.
A stable endpoint is not expected to change and allows no breaking changes except in extreme cases such as fixing a security problem. A beta endpoint is in active development and may change, while a deprecated endpoint is still supported and can still be used now but will be deleted in a future release.
Last updated