Google Cloud provides infrastructure and managed services for applications, data, analytics, containers, networking, security, and machine learning. The console lists hundreds of products, but nearly every practical task starts by answering one question: which project is active?
A project groups resources with an identity and policy context, enabled APIs, quotas, labels, audit history, and a linked billing account. Organizations and folders can govern many projects, while regions, zones, and global resources define where the technical system operates.
This lesson builds that operating map before creating chargeable resources. You will learn to verify project context, follow one request path, recognize security and cost boundaries, and troubleshoot errors without granting broad access.
Enterprise resources normally sit beneath an organization node associated with a managed identity domain. Folders group projects for delegated administration and policy. A project is the main resource, API, IAM, quota, and lifecycle boundary used by application teams.
Policies can inherit down the hierarchy. A role granted at organization scope can reach many descendants, while an organization policy constraint can limit what projects are allowed to configure. This reach makes high-level changes powerful and risky.
| Level | Primary purpose | Example decision |
|---|---|---|
| Organization | Top-level ownership and governance | Which company controls these cloud resources? |
| Folder | Group projects by environment, department, or policy need | Which controls should production projects inherit? |
| Project | Resources, APIs, IAM policy, quotas, labels, and lifecycle | Which workload and environment belong together? |
| Resource | Individual service instance | What does this VM, bucket, database, or service require? |
| Billing account | Pays for linked projects | Which financial owner receives and analyzes the charges? |
A project name is a human-friendly label and does not have to be unique. The project ID is globally unique, appears in commands and resource names, and usually cannot be changed after creation. The project number is a Google-assigned numeric identifier used by several services and service agents.
Record all three in operational documentation. Mistaking a display name for an ID leads to failed commands, while using the wrong active project can create a perfectly valid resource in the wrong environment.
Many Google Cloud products require a service API to be enabled in the project before their resources can be created or used. Enabling an API makes its endpoint available to the project and can create Google-managed service agents. It does not by itself grant a person permission or create an application resource.
Keep enabled APIs intentional and include them in infrastructure code. Disabling an API to save money is usually the wrong first move: charges come from billable resources and usage, while disabling a dependency can break workloads.
| Action | What it changes | What it does not prove |
|---|---|---|
| Enable an API | Allows the project to use that service endpoint | That the caller has IAM permission |
| Grant an IAM role | Allows listed permissions at a resource scope | That the API is enabled or the network path works |
| Link billing | Gives eligible usage a payer | That budgets cap spending or every service is authorized |
| Create a resource | Adds a service instance in a location or global scope | That the application can use it correctly |
Google Cloud resources have different location models. A VPC network is global, its subnets are regional, and many Compute Engine virtual machines are zonal. Cloud Storage buckets use a chosen location type, while managed services define their own regional or multi-regional behavior.
Choose location from user latency, data residency, service availability, failure isolation, network transfer, recovery, and cost. Deploying two zonal instances does not create resilience if both use one zone or share a single-zone data dependency.
An IAM allow policy binds principals to roles on a resource. The role contains permissions, and inheritance can carry access from an organization, folder, or project to descendants. Deny policies, principal access boundary policies, organization policies, and service-specific controls can further restrict the result.
Service accounts are workload identities, not folders for keys. Prefer attached service accounts, impersonation, or workload identity federation so applications receive short-lived credentials. Service account keys create a long-lived secret and should be exceptional.
| Need | Preferred pattern | Avoid |
|---|---|---|
| Employee access | Managed workforce identity and groups | Shared users and project-wide basic roles |
| Workload on Google Cloud | Dedicated attached service account | Default service account with broad permissions |
| External workload | Workload identity federation | Downloaded service account keys |
| Cross-project operation | Narrow role at the target resource plus controlled impersonation | Duplicating credentials between projects |
Consider a product catalog API. Cloud DNS resolves its name, an external Application Load Balancer terminates HTTPS, Cloud Run executes the container, a dedicated service account accesses a database, Pub/Sub carries background events, and Cloud Logging and Monitoring provide evidence. Other workloads may justify Compute Engine, GKE, Cloud SQL, Spanner, Firestore, or different entry services.
| Question | Google Cloud candidates | Trade-off |
|---|---|---|
| How does traffic enter? | Cloud DNS, Cloud Load Balancing, API Gateway | Global versus regional entry, TLS, filtering, and health |
| Where does code run? | Compute Engine, Cloud Run, Cloud Functions, GKE | Control, scaling, constraints, and operational effort |
| Where does state live? | Cloud Storage, Persistent Disk, Cloud SQL, Firestore, Spanner | Data model, consistency, durability, recovery, and price |
| How is work decoupled? | Pub/Sub, Cloud Tasks, Eventarc, Workflows | Delivery semantics, retries, ordering, and failure handling |
| How will operators know? | Cloud Monitoring, Logging, Trace, Error Reporting, Audit Logs | Metrics, logs, traces, alerts, audit coverage, and retention |
Use a learning project owned by you or your organization and stay read-only during this tour. The project selector is the most important control in the console because the same service page can show completely different resources after it changes.
| Step | Why | Expected result |
|---|---|---|
| 1. Open the project selector | Confirm organization and project context | The project name, ID, and organization match the intended lab. |
| 2. Open IAM and Admin | Inspect principals, roles, service accounts, and audit context | You can distinguish human access from workload identities without changing bindings. |
| 3. Open APIs and Services | See explicit project dependencies | The Enabled APIs list shows which service endpoints the project currently uses. |
| 4. Open Billing | Confirm the linked payer and cost visibility | You can identify billing linkage or recognize that billing permissions are separate. |
| 5. Open Cloud Shell | Use an authenticated environment without downloading a key | gcloud config list shows the active account, project, region, and zone settings. |
| 6. Inspect Logs Explorer | Connect platform actions to evidence | You can query available logs in the active project and identify the resource and timestamp fields. |
Google secures the underlying cloud infrastructure; you own your identities, data, application code, IAM bindings, network exposure, and service configuration. The amount of operating-system and platform work left to you depends on whether you choose Compute Engine, GKE, Cloud Run, or another managed service.
Private networking can reduce exposure but adds DNS, routing, and connectivity work. Multi-region services can improve availability and latency but add price and consistency decisions. Autoscaling can match demand but requires maximum limits, quota planning, load tests, and budget alerts.
| Scenario | Why Google Cloud may fit | Boundary to investigate |
|---|---|---|
| Containerized web services | Cloud Run and GKE offer different levels of platform control | Request model, background work, network needs, portability, and team operations |
| Data and analytics platform | Cloud Storage, BigQuery, Dataflow, and managed databases cover varied pipelines | Residency, classification, governance, query patterns, and cost controls |
| Event-driven integration | Pub/Sub, Eventarc, Cloud Tasks, and Workflows decouple producers and consumers | Delivery semantics, duplicate handling, ordering, retries, and dead letters |
| Enterprise landing zone | Organizations, folders, projects, Shared VPC, and policy controls create governed boundaries | Identity ownership, delegated administration, centralized networking, and inherited access |
When an operation fails, do not immediately grant Owner or Editor. Classify the failure as account, project, API, IAM, organization policy, location, quota, network path, application behavior, billing, or service health.
| Symptom | Check first | Evidence |
|---|---|---|
| Resource appears missing | Active account, project, location scope, filters, and resource state | gcloud config list, resource name, project ID, and audit log |
| PERMISSION_DENIED | Principal, permission, resource, inherited policy, deny, and token age | Exact error, resource name, request ID, and Policy Troubleshooter result |
| API has not been used or is disabled | Active project, API enablement, service usage permission, and billing requirement | Project ID, service name, enabled-service list, and audit event |
| Application cannot connect | DNS, route, firewall, service ingress, VPC connector, and target health | Connectivity test, flow logs where enabled, service logs, and trace |
| Unexpected bill | Cost by project, service, SKU, location, and label | Billing report or export, resource inventory, recent changes, and owner |
A production project needs documented owners, managed identities, intentional APIs, policy guardrails, logging, cost allocation, repeatable deployment, tested recovery, and incident procedures. A successful console deployment proves only that one path worked once.
Run these read-only commands before creating, changing, or deleting a resource.
gcloud auth list --filter=status:ACTIVE
gcloud config list
gcloud projects describe "$(gcloud config get-value project)" \
--format="table(projectId,projectNumber,name,lifecycleState)"
gcloud services list --enabled --format="table(config.name)"This short architecture note makes platform assumptions reviewable before resources exist.
Organization: example.com
Folder: Production / Commerce
Project: prj-catalog-prod
Billing owner: Digital Products
Request: Global load balancer -> Cloud Run -> Cloud SQL
Identity: catalog-api service account -> database
Async: Pub/Sub topic -> idempotent subscriber
Operations: SLO alert + logs + traces + audit logs
Recovery: RTO 60 minutes; RPO 15 minutes; restore tested quarterlyNo. A project contains resources and service configuration. A billing account is linked as the payer and can pay for multiple projects when permissions and account status allow it.
Service enablement declares that the project may use that Google Cloud service endpoint. IAM permission, billing, quota, and resource configuration are still evaluated separately.
Usually no. Prefer an attached service account, service account impersonation, or workload identity federation so the workload receives short-lived credentials without a downloaded long-lived key.
Explore 500+ free tutorials across 20+ languages and frameworks.