Google Cloud Platform (GCP) – Fundamentals

Google Cloud Platform (GCP) – Fundamentals

These notes summarize the core concepts of Google Cloud Platform, with a focus on resource hierarchy, IAM, and Cloud Storage. They are based on hands-on learning through Google Cloud Skills Boost and are intended for portfolio documentation.


1. Google Cloud Resource Hierarchy

GCP organizes resources in a hierarchical model that enables centralized governance, policy inheritance, and scalable access control.

Hierarchy Levels

  1. Organization Node (Level 04)

    • The top-level container in GCP.
    • Represents a company or institution.
    • All folders, projects, and resources belong to an organization.
  2. Folder (Level 03)

    • Used to group projects logically.
    • Supports nested folders (subfolders).
    • Enables policy application at an intermediate level between organization and projects.
  3. Project (Level 02)

    • The main unit of resource organization and billing.
    • All GCP resources are created inside projects.
    • Multiple projects can exist under the same folder or organization.
  4. Resources (Level 01)

    • The actual cloud services and components.
    • Examples: Compute Engine VMs, Cloud Storage buckets, BigQuery tables.

Policy Inheritance

  • Policies can be applied at:

    • Organization level
    • Folder level
    • Project level
    • In some cases, directly on resources
  • Policies are inherited downward through the hierarchy.

  • A policy applied at a higher level automatically affects all lower-level resources unless explicitly overridden.


2. Projects in Google Cloud

Each Google Cloud project has three identifiers:

Project ID

  • Globally unique
  • Assigned by Google Cloud during creation (user-defined at creation time)
  • Immutable after creation

Project Name

  • Not required to be unique
  • Chosen by the user
  • Mutable

Project Number

  • Globally unique
  • Assigned by Google Cloud
  • Immutable
  • Commonly used internally by GCP APIs

3. Resource Manager

  • The Resource Manager API allows programmatic management of:

    • Organizations
    • Folders
    • Projects
  • Common use cases:

    • Automating project creation
    • Managing hierarchical structures
    • Applying and auditing IAM policies

4. Folders

  • Folders provide flexible policy granularity.

  • They allow organizations to:

    • Group projects by team, environment, or business unit
    • Apply IAM and organization policies consistently
  • Useful for enforcing governance without applying policies globally.


5. Identity and Access Management (IAM)

IAM defines who can do what on which resources.

IAM Identities

Policies can be applied to:

  • Google Accounts
  • Google Groups
  • Service Accounts
  • Cloud Identity domains

Roles and Permissions

  • Permissions define individual actions (e.g., compute.instances.start).
  • Roles are collections of permissions.

Basic Roles (Project-wide)

  • Owner

    • Full access to all resources
    • Can manage IAM roles and billing
  • Editor

    • Can create, modify, and delete resources
    • Cannot manage IAM roles
  • Viewer

    • Read-only access to resources
  • Billing Administrator

    • Manages billing accounts and settings
    • Cannot modify project resources

Note: Basic roles are broad and generally discouraged for fine-grained access control.

Predefined Roles

  • Service-specific roles managed by Google Cloud
  • Designed for least-privilege access
  • Example: Compute Engine Admin, Storage Object Viewer

Most organizations prefer predefined roles to minimize security risk.


6. Google Cloud Storage (GCS)

Overview

  • Cloud Storage is a durable and highly available object storage service.
  • Designed for unstructured data and large binary objects (BLOBs).

Object Storage Model

  • Data is stored as objects, not files and directories.

  • Each object consists of:

    • Data
    • Metadata
    • A unique identifier

Common Use Cases

  • Data archival and disaster recovery
  • Media content distribution (videos, images)
  • Backup storage
  • Intermediate data storage in data processing pipelines

Buckets

  • Objects are stored in buckets.

  • Bucket names must be globally unique.

  • Buckets are created in a specific geographic location:

    • Region (e.g., southamerica-east1)
    • Multi-region

Choosing a bucket location close to users minimizes latency.

Object Immutability and Versioning

  • Objects are immutable: updates create new object versions.

  • Versioning options:

    • Overwrite old versions
    • Retain all versions for auditing or recovery

Access Control

  • Access is managed using:

    • IAM roles (recommended)
    • Access Control Lists (ACLs), when required

Best practice is to follow least-privilege principles, ensuring users only have access to what they need.

Lifecycle Management

  • Lifecycle rules automate object management:

    • Transition between storage classes
    • Delete objects after a defined period

7. Cloud Storage Classes

  • Standard Storage

    • Frequently accessed data
  • Nearline Storage

    • Infrequently accessed data (about once per month)
  • Coldline Storage

    • Data accessed at most once every 90 days
  • Archive Storage

    • Lowest-cost option
    • Ideal for long-term archiving, backups, and disaster recovery