Professional Cloud Developer
To start using Google Cloud services, you need a project. If you create a new project, you must have the Project Creator role (roles/resourcemanager.projectCreator). This role lets you generate a new resource environment where services can be managed. For testing only, creating a temporary project makes cleanup easy and avoids extra costs. Once the project exists, you must enable the specific APIs you want to use. The Service Usage Admin role (roles/serviceusage.serviceUsageAdmin) gives you the serviceusage.services.enable permission, which is required to turn on services like Compute Engine or Cloud Storage. Without this role, your application cannot communicate with those external APIs.
Applications that need to call Google Cloud APIs require a service account. To create one, an administrator needs the Service Account Creator role (roles/iam.serviceAccountCreator). Additionally, the Service Account User role (roles/iam.serviceAccountUser) lets a user or service run tasks as that specific account. This ensures each application has the correct level of access. To follow the principle of least privilege, grant only the roles that a service needs. For example, a developer might need Cloud Build Editor, Storage Object User, and Artifact Registry Administrator. You can assign these permissions through the Google Cloud console or the gcloud CLI using policy binding commands. Basic roles like Viewer or Editor are too broad for production, so use predefined roles instead.
A Google Cloud project acts as a container for resources and provides an isolation boundary. To use most services, you must enable the APIs and associate a valid billing account. If you disable billing, Google Cloud shuts down the resources to prevent charges. Quotas are hard limits on resource usage that prevent unexpected costs. Monitoring usage through telemetry dashboards helps maintain application availability. When your application grows, you can request a quota increase manually through the console or enable the Quota Adjuster, which automatically submits requests when you approach limits. To manage quotas, you need the Quota Administrator role. Keep in mind that having an available quota does not guarantee physical resource availability in a specific region.
You can enable services using the Google Cloud Console, gcloud CLI, or the Service Usage API. Before enabling any service, verify that billing is turned on. Use the gcloud services enable command after running gcloud init to set your project. Commonly enabled APIs include Compute Engine, Cloud Storage, Cloud Build, and Artifact Registry. Many Google Cloud features have API Dependencies—one service requires other APIs to function. For example, a deployment using Cloud Run might also need Cloud Build and Eventarc enabled. Managing these relationships early prevents errors. When you no longer need a project, delete it to remove all services and stop billing.
Google Cloud provides several ways to call its APIs. Cloud Client Libraries are the recommended choice because they are written for each programming language and handle authentication automatically. REST APIs use JSON over HTTP and are universal. gRPC uses Protocol Buffers for high-performance, low-latency communication, and can increase throughput by up to ten times compared to REST. Many Cloud Client Libraries use gRPC internally to run efficiently.
To reduce network overhead, combine multiple optimization techniques. Batching groups many API requests into a single call. Field masks restrict the data returned to only the fields you need, keeping payloads small. Pagination breaks large result sets into manageable chunks using tokens, preventing the system from being overwhelmed. These strategies work together to minimize latency and conserve API quota.
Caching stores frequently accessed data in temporary storage for faster retrieval. Cloud CDN caches content at the network edge closer to users. Memorystore provides a fully managed in-memory data store for rapid access. Local caching on the frontend also reduces redundant network requests. Effective caching lowers response times, reduces load on backend databases, and improves scalability.
Reliable applications must handle failures gracefully. Exponential backoff waits progressively longer before retrying a failed request, which prevents overwhelming a struggling service. Circuit breakers temporarily block requests to a service that is clearly down, preventing cascading failures. Applications should also implement graceful degradation to maintain basic functionality even when some features fail. These techniques keep systems resilient during traffic spikes and temporary service issues.
Before writing code, use the Google API Explorer to test endpoints and validate request structures without a full development environment. This helps ensure API calls are formatted correctly. Monitor quotas, which are usage limits that ensure fair access, including rate quotas that restrict requests within a time frame. Tracking these metrics prevents service disruptions and controls costs.
Service accounts are special identities used by applications to call Google Cloud APIs. Google strongly recommends using short-lived credentials instead of long-lived keys. Short-lived tokens, obtained through the Service Account Credentials API, expire quickly, reducing risk if stolen. Long-lived user-managed key pairs are risky because they can be leaked in code or files. Limit the number of keys and use organization policy constraints to stop new keys from being created. If you must use keys, store them securely and rotate them regularly. Service account impersonation lets a user or service temporarily act as a service account without needing its physical key. For applications running outside Google Cloud, Workload Identity Federation exchanges external credentials for short-lived Google Cloud tokens, ensuring the application gets only the minimum permissions it needs.
For applications running on Google Cloud resources like Compute Engine or Cloud Run, attach a service account directly to the resource. The application then uses the built-in Instance Metadata Service to automatically get fresh OAuth 2.0 access tokens. Google manages the private keys, so they are never exposed to your code. To keep your environment secure, use audit logs to track which identities access resources. Create a dedicated service account for each application, monitor for unused keys, and delete them. Regularly rotate keys and set expiry dates to limit damage from a compromised credential.
Application Default Credentials (ADC) is a system that automatically finds the right credentials for your code to call Google Cloud APIs. For local development, run gcloud auth application-default login to create a local ADC file tied to your user account. This lets you test on your computer without handling service account key files. You can also use service account impersonation locally, which lets your user account temporarily act as a service account to test permissions, provided you have the Service Account Token Creator role.
When your code runs on a managed Google Cloud service, ADC works differently. If a service account is attached to the resource, ADC automatically queries the metadata server to get short-lived tokens. This provides secure, automatic access without storing secrets in your code. ADC looks for credentials in a specific order: first the GOOGLE_APPLICATION_CREDENTIALS environment variable, then local user credentials from the gcloud CLI, and finally the metadata server if the code is on a Google Cloud resource. This sequence allows the same code to work securely in both development and production.
Service accounts are identified by a unique email address. To use one, you attach it to a Google Cloud resource like a Compute Engine VM or a Kubernetes pod. The application on that resource can then use ADC to automatically get security tokens. Attaching an identity is more secure than using static key files because there are no files to leak.
Once a service account is created, control what it can do by assigning IAM roles. Follow the principle of least privilege: give the account only the permissions it needs. Avoid broad, default service accounts. Instead, create single-purpose service accounts for different applications and use clear naming conventions. An application’s access is controlled by both IAM permissions and OAuth 2.0 scopes. IAM roles define the actual permissions. Scopes are a legacy method used mainly on VMs to broadly limit what an OAuth token can do. Best practice is to set the VM’s access scope to cloud-platform and then use precise IAM roles on the service account for fine-grained control. Service account impersonation is also an authorization tool that allows a user or another service account to temporarily “become” a service account. Strictly limit who can impersonate to prevent privilege escalation and protect your resources.
Prepare and test your skills
Prepare and test your skills
StudyCerts
StudyCerts