Google Cloud Shell Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Application development

by

Category

Application development

1. Introduction

Cloud Shell is Google Cloud’s browser-based command-line environment that gives you an authenticated terminal (and an optional editor) with common cloud and developer tools preinstalled.

Simple explanation: Open the Google Cloud Console, click the Cloud Shell icon, and you instantly get a Linux shell that’s already logged into your Google Cloud account—no local installs, no SSH keys, no laptop setup.

Technical explanation: Cloud Shell provisions an ephemeral Linux virtual machine (VM) session for your user, attaches a small persistent home directory, and preconfigures authentication and project context so tools like gcloud, kubectl, and Git work immediately. It’s designed for secure interactive administration, development, and troubleshooting across Google Cloud services.

What problem it solves: Cloud Shell removes the friction of setting up local tooling and credentials for Google Cloud. It standardizes the environment for teams, accelerates onboarding, and reduces credential sprawl by keeping authentication inside Google’s managed console workflow—especially useful in Application development workflows where you frequently build, deploy, and troubleshoot cloud apps.

Service status note: Cloud Shell is an active Google Cloud service. Google also offers Cloud Shell Editor (a web-based editor integrated with Cloud Shell). Always verify the latest UI naming and behavior in official docs: https://cloud.google.com/shell/docs

2. What is Cloud Shell?

Official purpose (in practice): Cloud Shell is a managed, browser-accessible shell environment for interacting with Google Cloud resources using CLI tools and scripts.

Core capabilities

  • Browser-based Linux terminal launched directly from the Google Cloud Console.
  • Preinstalled toolchain typically includes the Google Cloud CLI (gcloud), kubectl, Git, and other common utilities (exact inventory can change—verify in official docs).
  • Preconfigured authentication tied to your signed-in Google identity.
  • Persistent home directory (commonly documented as 5 GB) to keep code, config, and scripts between sessions.
  • Cloud Shell Editor for basic IDE-style editing and project work (availability and features can vary).

Major components

  • Cloud Shell VM session (ephemeral): The compute environment backing your terminal session. It is not intended to be treated like a long-lived server.
  • Persistent $HOME storage: Keeps files between sessions (within the documented limit).
  • Console integration: UI entry point, project selector, and web preview integration.
  • Identity and access integration: Uses Google identity + Cloud IAM to authorize API calls.

Service type

  • Managed interactive development/admin environment (not a general-purpose hosting service).
  • It’s not a CI/CD runner and not a replacement for production bastions—though it can act as a convenient administrative endpoint for many tasks.

Scope: account-scoped with project context

  • Cloud Shell is primarily user/account-scoped (your environment follows your identity).
  • Your CLI commands operate against a selected Google Cloud project (the active project in gcloud).
  • The resources you create (Cloud Run services, GKE clusters, VMs, buckets, etc.) are project-scoped and billed/secured accordingly.

Regional/global considerations

  • Cloud Shell’s backing environment runs in a Google-managed region you can typically view or select in settings (the set of available regions can change).
  • Regardless of where Cloud Shell is hosted, it can manage resources across regions—your API calls go to Google Cloud control planes.

How it fits into the Google Cloud ecosystem

Cloud Shell is best understood as your “zero-setup workstation inside Google Cloud Console”: – It complements Cloud Console UI by providing an immediate CLI. – It complements Cloud Workstations (full managed dev environments) and local development. – It works with almost every Google Cloud product because it’s essentially a preconfigured client environment for Google Cloud APIs.

3. Why use Cloud Shell?

Business reasons

  • Faster onboarding: New engineers can run gcloud and deploy apps immediately—no local installs, no VPN prerequisites in many cases.
  • Standardized environment: Reduced “works on my machine” issues for scripts and basic deployments.
  • Lower endpoint management overhead: Fewer local dependencies and reduced support time for workstation toolchains.

Technical reasons

  • Preinstalled Google Cloud tooling: Common CLIs and SDKs are ready out of the box.
  • Authenticated by default: Identity is bound to the logged-in user; avoids copying long-lived keys around.
  • Convenient for small automation: Great for quick scripts, one-off migrations, and interactive debugging.

Operational reasons

  • Consistent troubleshooting endpoint: Useful for verifying IAM, API enablement, deployments, and logs quickly.
  • Portable sessions: Your home directory persists, so you can keep helper scripts and configuration.

Security/compliance reasons

  • Reduces credential sprawl: You typically don’t need to store local service account keys just to use the CLI.
  • Centralized access control: Uses Cloud IAM; actions taken through gcloud are subject to the same IAM and audit logging as anywhere else.
  • Better control than unmanaged laptops (in many orgs): Especially where developers are restricted from installing tooling locally.

Scalability/performance reasons

  • Cloud Shell is not about scaling workloads; it’s about scaling human workflows:
  • More developers can safely access tooling without distributing credentials and installers.
  • Teams can create repeatable operational runbooks.

When teams should choose Cloud Shell

  • You need quick CLI access to Google Cloud from anywhere.
  • You’re teaching/training, running labs, or standardizing onboarding.
  • You’re doing Application development tasks like deploying to Cloud Run, managing Artifact Registry images, editing IaC, or troubleshooting services.

When teams should not choose it

  • Not for production hosting: You should not run long-lived services from Cloud Shell.
  • Not a CI/CD platform: Use Cloud Build, GitHub Actions, GitLab CI, etc.
  • Not for heavy builds: For large compilation/build workloads, use Cloud Build or dedicated build runners.
  • Not a hardened bastion replacement in highly regulated environments without reviewing org policies, network controls, and auditing needs.

4. Where is Cloud Shell used?

Industries

  • Software/SaaS: Rapid deployments, day-2 operations, and incident response.
  • Financial services / regulated: Controlled access to cloud tooling without unmanaged local installs (subject to compliance review).
  • Education: Classroom labs and training environments.
  • Media/entertainment & gaming: Quick operational workflows across projects.
  • Healthcare & public sector: Often used for standardized, auditable admin workflows (verify compliance requirements).

Team types

  • Application developers
  • DevOps / Platform Engineering
  • SRE / Operations
  • Security engineering (for investigations, IAM validation, policy checks)
  • Data engineering (CLI-based orchestration of storage and jobs)
  • Architects and technical leads (prototyping and reference implementations)

Workloads and architectures

  • Cloud Run / GKE deployments via CLI
  • IaC (Terraform) and config management workflows
  • Storage operations (Cloud Storage, transfer checks)
  • IAM auditing and policy updates (with careful review)
  • Debugging networking and auth issues from a known-good environment

Real-world deployment contexts

  • Production: Used mainly for administrative tasks (deploys, rollbacks, config edits), not for hosting.
  • Dev/Test: Prototyping and small deployments, rapid iteration, teaching.
  • Incident response: Triage from a standard environment when local tooling is broken or unavailable.

5. Top Use Cases and Scenarios

Below are realistic scenarios where Cloud Shell is commonly the fastest, safest path.

5.1 Run gcloud without installing anything

  • Problem: A developer needs to inspect IAM bindings or enable an API but lacks local tooling.
  • Why Cloud Shell fits: gcloud is available immediately and authenticated.
  • Example: Launch Cloud Shell → gcloud services enable run.googleapis.com → deploy app.

5.2 Deploy a “Hello World” service to Cloud Run

  • Problem: You need a quick public endpoint for a demo or integration test.
  • Why Cloud Shell fits: Create code, build, and deploy from the browser in minutes.
  • Example: Write a small Flask app and run gcloud run deploy --source ..

5.3 Kubernetes cluster administration with kubectl

  • Problem: You must debug a GKE service and don’t have kubeconfig set up locally.
  • Why Cloud Shell fits: gcloud container clusters get-credentials + kubectl is typically ready.
  • Example: Fetch credentials and check kubectl get pods -n prod.

5.4 Git operations and quick patching

  • Problem: A simple config fix is needed and you’re away from your workstation.
  • Why Cloud Shell fits: Git + editor available; commit and push from the browser.
  • Example: Edit Terraform variables, push a hotfix branch.

5.5 Investigate permissions and identity context

  • Problem: A deployment fails due to IAM confusion (wrong principal, wrong project).
  • Why Cloud Shell fits: Easy to run gcloud auth list, gcloud config list, and policy inspection commands.
  • Example: Confirm active account and project, then validate IAM bindings.

5.6 Prototype Infrastructure as Code (Terraform)

  • Problem: You want to test a Terraform module quickly without touching your local environment.
  • Why Cloud Shell fits: Terraform is often available (verify current tooling availability) or can be installed in-session.
  • Example: terraform init && terraform plan against a sandbox project.

5.7 Validate network access to a service endpoint

  • Problem: Need to confirm a URL, DNS, or TLS handshake behavior from a neutral environment.
  • Why Cloud Shell fits: Use curl, openssl, and standard Linux tooling quickly.
  • Example: curl -v https://my-service-xyz.a.run.app.

5.8 Manage artifacts and images (Artifact Registry)

  • Problem: You need to list, delete, or troubleshoot container images.
  • Why Cloud Shell fits: Auth and CLI access are ready.
  • Example: gcloud artifacts docker images list ....

5.9 Build and run small scripts for admin automation

  • Problem: Repetitive tasks like label updates or resource inventory.
  • Why Cloud Shell fits: Store scripts in $HOME, run them as needed, integrate with Cloud Logging/Audit Logs via APIs.
  • Example: Python script to list resources across projects with the Resource Manager API.

5.10 Training labs and workshops

  • Problem: Students have mixed OSes and inconsistent local setups.
  • Why Cloud Shell fits: Everyone gets the same environment in the browser.
  • Example: Workshop uses Cloud Shell to deploy a simple microservice and view logs.

5.11 Quick access when corporate laptops are locked down

  • Problem: Installing CLI tools is blocked by endpoint policies.
  • Why Cloud Shell fits: Tooling runs in Google’s environment, governed by IAM.
  • Example: Ops engineer uses Cloud Shell to roll back Cloud Run revision.

5.12 Break-glass administrative access (with controls)

  • Problem: A critical incident requires access from a clean environment.
  • Why Cloud Shell fits: It’s a known, managed environment—but must be combined with strong IAM, MFA, and audit policies.
  • Example: Security-approved break-glass group can use Cloud Shell to disable a compromised service account.

6. Core Features

Cloud Shell’s features are best understood as “fast access + safe defaults + persistence for your workspace.”

6.1 Browser-based terminal in Google Cloud Console

  • What it does: Launches a shell session in a browser tab from the Cloud Console.
  • Why it matters: Eliminates local terminal setup and network hurdles.
  • Practical benefit: You can access Google Cloud tooling from any machine with a browser.
  • Caveats: Not designed for long-running background workloads; sessions can time out.

6.2 Preinstalled Google Cloud CLI (gcloud) and common tools

  • What it does: Provides a ready-to-use CLI environment.
  • Why it matters: The fastest path to interact with Google Cloud APIs and services.
  • Practical benefit: Run deployment and troubleshooting commands immediately.
  • Caveats: Tool versions may change as Google updates the environment. Pin versions in CI/CD elsewhere; treat Cloud Shell as an interactive tool.

6.3 Authenticated environment (identity-aware)

  • What it does: Uses your logged-in Google identity for authentication to Google Cloud.
  • Why it matters: Reduces the need to manage local credentials.
  • Practical benefit: gcloud is typically ready with an active account; you can switch accounts/projects.
  • Caveats: Your effective permissions are still governed by IAM; Cloud Shell does not “bypass” security controls.

6.4 Persistent home directory

  • What it does: Persists your files across sessions in $HOME up to the documented limit (commonly 5 GB).
  • Why it matters: Enables a stable working directory for scripts, config, and repos.
  • Practical benefit: Keep your helper scripts, SSH config (if used), and Git repos.
  • Caveats: Don’t treat it as durable backup storage; follow your org’s data handling rules.

6.5 Cloud Shell Editor (optional)

  • What it does: Provides a browser-based editor integrated with Cloud Shell.
  • Why it matters: You can do lightweight development without leaving the console.
  • Practical benefit: Edit code, run terminal commands, and deploy from one place.
  • Caveats: Not a full replacement for a dedicated IDE for large projects.

6.6 Web preview for local ports

  • What it does: Lets you preview services you run in Cloud Shell via a proxy from the browser.
  • Why it matters: Quickly test web apps without exposing a public VM.
  • Practical benefit: Run a dev server and view it in your browser.
  • Caveats: Port and behavior constraints apply; verify supported ports in official docs.

6.7 Project context integration

  • What it does: Connects Cloud Console project selection to CLI defaults (active project).
  • Why it matters: Reduces accidental deployments into the wrong project.
  • Practical benefit: Faster switching between environments (dev/test/prod).
  • Caveats: Still validate with gcloud config list before running destructive commands.

6.8 Easy file upload/download (console-assisted)

  • What it does: Supports moving small files between your machine and the Cloud Shell environment via the UI/commands.
  • Why it matters: Simplifies working with keys, configs, or small datasets (when allowed).
  • Practical benefit: Quickly bring in a config file for testing.
  • Caveats: Treat file movement as a data exfiltration vector; follow security policy.

6.9 Integration with Google Cloud APIs and services

  • What it does: Cloud Shell is an authenticated client environment for Google Cloud.
  • Why it matters: Virtually any service can be managed via CLI/API from Cloud Shell.
  • Practical benefit: Use one place to manage Cloud Run, GKE, IAM, Storage, Pub/Sub, etc.
  • Caveats: API enablement, IAM, org policies, and network constraints still apply.

7. Architecture and How It Works

High-level architecture

Cloud Shell is an interactive environment that sits between the user and Google Cloud APIs:

  • User interacts through the Google Cloud Console in a browser.
  • The browser opens a session to a Google-managed Cloud Shell VM.
  • Tools like gcloud call Google Cloud service APIs over Google’s networks.
  • Your work files are stored in a persistent home directory.

Request/data/control flow (typical)

  1. User opens Cloud Shell in Cloud Console.
  2. Cloud Shell provisions (or reuses) a VM session for the user.
  3. gcloud uses the user’s identity to obtain credentials and call APIs.
  4. API calls execute control-plane operations (deploy a service, create a bucket, update IAM).
  5. Results are returned to the terminal; operational events are captured by Cloud Audit Logs for the target project/services (where applicable).

Integrations with related services

Common integrations include: – Cloud Run: build and deploy apps with gcloud run. – Cloud Build: build container images from source. – Artifact Registry: store images and artifacts. – GKE: use kubectl after fetching cluster credentials. – Cloud Logging / Error Reporting: check logs and errors for deployed services. – IAM: manage access policies and service accounts. – Secret Manager: retrieve secrets securely (recommended over storing secrets in files).

Dependency services

  • Google identity platform for authentication.
  • Google Cloud control plane APIs for whatever you manage.
  • A Google-managed VM runtime and storage for the Cloud Shell environment.

Security/authentication model

  • Primary identity is your Google account / Cloud Identity user.
  • Authorization is controlled by Cloud IAM.
  • Actions you take (creating/deleting resources) are authorized as your principal and should appear in Audit Logs in the relevant project/service (verify per-service audit coverage).

Networking model (practical view)

  • Cloud Shell can typically reach Google Cloud APIs and public internet endpoints (subject to org policy and environment constraints).
  • Incoming network access to the Cloud Shell VM is not treated like a normal public VM; web preview uses a proxied approach.
  • For private/internal-only resources, connectivity depends on the target service exposure model and your organization’s network controls. If you require strict private access paths, evaluate bastion/VPN/VPC patterns and verify Cloud Shell networking behavior in official docs.

Monitoring/logging/governance considerations

  • Cloud Shell itself is an interactive environment; most governance focus is on:
  • Who can open Cloud Shell (identity and org policy)
  • What they can do (IAM)
  • What they did (Audit Logs, Cloud Logging for resource actions)
  • Establish guardrails:
  • Principle of least privilege
  • Project separation (dev/test/prod)
  • Organization Policies (restrict APIs, restrict external IP, domain restrictions, etc.)

Simple architecture diagram

flowchart LR
  U[User in Browser] --> C[Google Cloud Console]
  C --> CS[Cloud Shell Session\n(ephemeral VM + persistent $HOME)]
  CS --> APIs[Google Cloud APIs\n(IAM, Cloud Run, GKE, Storage, ...)]
  APIs --> R[Project Resources]

Production-style architecture diagram (practical workflow)

flowchart TB
  Dev[Developer / SRE] --> Console[Cloud Console + Cloud Shell]
  Console --> Repo[Source Repo\n(e.g., GitHub/CSR)]
  Console --> Build[Cloud Build]
  Build --> AR[Artifact Registry]
  AR --> Run[Cloud Run Service]
  Run --> Logs[Cloud Logging]
  Run --> Mon[Cloud Monitoring]

  Console --> IAM[IAM / Org Policy]
  IAM --> Build
  IAM --> Run

  subgraph Projects
    Build
    AR
    Run
    Logs
    Mon
  end

Key idea: Cloud Shell is the interactive entry point, but production-grade delivery should rely on controlled pipelines and IAM guardrails.

8. Prerequisites

Account/project requirements

  • A Google Cloud account (Google identity or Cloud Identity/Workspace user).
  • Access to at least one Google Cloud project.
  • In many organizations, you may need to be inside an allowed domain or group to access Cloud Shell.

Permissions / IAM roles

Minimum permissions depend on what you will do: – To use Cloud Shell itself, you generally need permissions allowed by your organization (verify org policies and Cloud Shell access settings). – For the hands-on lab in this tutorial (deploy to Cloud Run), you typically need: – Permission to enable APIs (often roles/serviceusage.serviceUsageAdmin) or an admin to enable required APIs for you. – Cloud Run deploy permissions (often roles/run.admin) and permission to act as a service account (often roles/iam.serviceAccountUser on the runtime service account). – Cloud Build permissions if building from source (often roles/cloudbuild.builds.editor). – Artifact Registry permissions if images are stored there.

If you’re in a controlled org, ask for a pre-created “sandbox” project with these permissions.

Billing requirements

  • Cloud Shell is generally provided without a direct usage charge, but billing must be enabled on the project for most deployable resources (Cloud Run, Artifact Registry, etc.).
  • The lab uses Cloud Run + build from source, which may incur costs depending on usage and free tier availability.

CLI/SDK/tools needed

  • None locally. Cloud Shell provides CLI tools in the browser.
  • Optional: A GitHub account if you want to push code to a remote repo (not required for the lab).

Region availability

  • Cloud Shell environment region availability varies.
  • Cloud Run region availability varies by product and rollout. Pick a supported Cloud Run region (for example us-central1) and adjust if needed.

Quotas/limits

Common constraints to plan for (verify current values in docs): – Cloud Shell session timeouts and usage limits. – Persistent home directory size limit (commonly documented as 5 GB). – Cloud Run request/concurrency limits and Cloud Build quotas (project-specific).

Prerequisite services

For the lab: – Cloud Run API – Cloud Build API – Artifact Registry API (often used under the hood) – (Optional) Cloud Logging API (usually enabled by default)

9. Pricing / Cost

Cloud Shell pricing model (what to expect)

  • Cloud Shell itself is generally provided at no additional cost, subject to usage limits/quotas.
    Verify the latest statement and quotas in official docs: https://cloud.google.com/shell/docs

Cloud Shell is best thought of as “free access to tools,” while the resources you create are billed normally.

Pricing dimensions (indirect)

While Cloud Shell may not be billed directly, your actions can trigger charges in other services:

Activity from Cloud Shell Services that may bill Typical cost drivers
Deploy to Cloud Run from source Cloud Run, Cloud Build, Artifact Registry Build minutes, stored images, requests, CPU/memory-seconds
Create a GKE cluster GKE, Compute Engine, Persistent Disk, Load Balancing Cluster fees, node VM hours, disks, LB, egress
Create VMs Compute Engine VM hours, disks, IPs, egress
Use Cloud Storage Cloud Storage GB-month storage, operations, egress
Pull images/dependencies Artifact Registry / internet egress Storage and network transfer

Free tier considerations

  • Many Google Cloud services have free tiers (Cloud Run has a free allowance in many regions; Cloud Build has quotas; etc.), but free tier eligibility varies by region and account.
  • Treat free tier as “helpful but not guaranteed.” Always confirm current free tier details in the service’s pricing page.

Hidden or indirect costs to watch

  • Artifact Registry storage: images built during experiments can accumulate.
  • Cloud Build: frequent builds can exceed any free quota.
  • Network egress: downloading large dependencies or data from the internet can create egress charges depending on path and service.
  • Logging volume: verbose app logs can create ingestion/storage costs at scale.

Data transfer implications

  • Cloud Shell itself is not your main data plane, but it can trigger:
  • Downloads from external package repositories
  • Uploads to Artifact Registry
  • Calls to APIs across regions
  • For cost-sensitive environments, keep builds minimal and prefer regional alignment (build + deploy in same region where possible).

How to optimize cost when using Cloud Shell

  • Use Cloud Shell for interactive control-plane tasks, not for repeated builds.
  • Prefer small sample apps and remove resources after testing.
  • Delete unused container images and repositories in Artifact Registry.
  • Set budgets and alerts in Billing.
  • Use separate sandbox projects with strict budgets for training and experimentation.

Example low-cost starter estimate

A realistic “starter lab” cost depends on: – how many builds you run, – whether Cloud Run stays idle or receives traffic, – how large your container image is, – whether you remain within free tiers.

For a single small Cloud Run deployment with minimal traffic and a small image, costs are often low—sometimes within free allowances—but verify using the Google Cloud Pricing Calculator: – Pricing Calculator: https://cloud.google.com/products/calculator – Cloud Run pricing: https://cloud.google.com/run/pricing – Cloud Build pricing: https://cloud.google.com/build/pricing – Artifact Registry pricing: https://cloud.google.com/artifact-registry/pricing

Example production cost considerations

In production, Cloud Shell is not the cost driver; your platform choices are: – Cloud Run (requests, CPU/memory, min instances if set) – Artifact Registry storage and egress – Logging/Monitoring ingestion and retention – CI/CD build frequency (Cloud Build or external runners) – Networking (load balancers, serverless egress, VPC connectors)

10. Step-by-Step Hands-On Tutorial

Objective

Use Cloud Shell to build and deploy a small web service to Cloud Run from source, then view logs and clean up resources.

Lab Overview

You will: 1. Launch Cloud Shell and confirm authentication and project settings. 2. Enable required APIs. 3. Create a tiny Python web app. 4. Deploy it to Cloud Run using gcloud run deploy --source. 5. Validate the service endpoint and review logs. 6. Clean up Cloud Run and related artifacts to avoid ongoing charges.

Expected time: 20–40 minutes
Cost: Low for a single deployment; may be free-tier eligible, but not guaranteed.

Step 1: Launch Cloud Shell and confirm your environment

  1. Open the Google Cloud Console: https://console.cloud.google.com/
  2. Click the Cloud Shell icon (terminal) in the top-right toolbar.
  3. Wait for Cloud Shell to start.

In the Cloud Shell terminal, run:

gcloud --version
gcloud auth list
gcloud config list

Expected outcome – You see the installed gcloud version. – Your account appears under gcloud auth list. – gcloud config list shows an active project (or it may be empty if not set yet).

If no project is set, choose one:

gcloud projects list
gcloud config set project PROJECT_ID

Replace PROJECT_ID with your target project.

Verification

gcloud config get-value project

Step 2: Confirm billing and enable required APIs

Cloud Run deployments generally require billing enabled on the project.

Check billing (one approach): – In Console: Billing → confirm the project is linked to an active billing account.

Then enable required APIs:

gcloud services enable \
  run.googleapis.com \
  cloudbuild.googleapis.com \
  artifactregistry.googleapis.com

Expected outcome – Command completes without error. – APIs are enabled for the project.

Verification

gcloud services list --enabled --filter="name:run.googleapis.com OR name:cloudbuild.googleapis.com OR name:artifactregistry.googleapis.com"

Step 3: Create a small web application locally in Cloud Shell

Create a new folder and files:

mkdir -p ~/cloudshell-cloudrun-demo
cd ~/cloudshell-cloudrun-demo

Create app.py:

cat > app.py <<'EOF'
import os
from flask import Flask, request

app = Flask(__name__)

@app.get("/")
def hello():
    target = request.args.get("name", "Cloud Shell")
    return {
        "message": f"Hello, {target}!",
        "service": "cloudshell-cloudrun-demo",
    }

if __name__ == "__main__":
    port = int(os.environ.get("PORT", "8080"))
    app.run(host="0.0.0.0", port=port)
EOF

Create requirements.txt:

cat > requirements.txt <<'EOF'
Flask==3.0.0
gunicorn==21.2.0
EOF

Create a Dockerfile (Cloud Run can deploy from source without you writing a Dockerfile, but having one makes the build more explicit and portable):

cat > Dockerfile <<'EOF'
FROM python:3.12-slim

WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY app.py .

ENV PORT=8080
CMD exec gunicorn --bind :$PORT app:app
EOF

(Optional) Quick local run inside Cloud Shell (for sanity):

python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
python3 app.py

Cloud Shell will show it’s listening on port 8080. Use Web preview in the Cloud Shell toolbar if available, or test from another terminal tab:

curl -s http://localhost:8080/

Stop the app with Ctrl+C.

Expected outcome – curl returns JSON like {"message":"Hello, Cloud Shell!", ...}

Step 4: Deploy to Cloud Run from Cloud Shell

Choose a region. This tutorial uses us-central1 as an example. If your organization restricts regions, pick an allowed one.

Set variables:

export REGION="us-central1"
export SERVICE_NAME="cloudshell-cloudrun-demo"

Deploy:

gcloud run deploy "$SERVICE_NAME" \
  --source . \
  --region "$REGION" \
  --allow-unauthenticated

Notes: – --source . uses Google’s build process (often via Cloud Build) to build a container and deploy it. – --allow-unauthenticated makes the service publicly accessible. For private services, omit it and use IAM-based access.

Expected outcome – You see build output, then a deployed service URL like: https://cloudshell-cloudrun-demo-<hash>-uc.a.run.app

Verification Store the URL and test it:

SERVICE_URL="$(gcloud run services describe "$SERVICE_NAME" --region "$REGION" --format='value(status.url)')"
echo "$SERVICE_URL"

curl -s "$SERVICE_URL/?name=Google%20Cloud" | sed 's/\\n/\n/g'

You should receive JSON with the greeting.

Step 5: View logs (basic operations workflow)

Cloud Run writes stdout/stderr to Cloud Logging.

Tail logs:

gcloud run services logs tail "$SERVICE_NAME" --region "$REGION"

Then hit the endpoint in another tab:

curl -s "$SERVICE_URL/?name=LogsTest" > /dev/null

You should see log entries appear.

Expected outcome – Log entries in the tail output (exact format depends on runtime).

Step 6: (Optional) Try Cloud Shell Editor for quick edits

If you want to use Cloud Shell Editor: – In Cloud Shell, open the editor (from the Cloud Shell UI menu). – Modify the response message in app.py. – Redeploy:

gcloud run deploy "$SERVICE_NAME" \
  --source . \
  --region "$REGION" \
  --allow-unauthenticated

Expected outcome – New revision deployed; endpoint returns updated message.

Validation

Run:

gcloud run services describe "$SERVICE_NAME" --region "$REGION" --format="yaml(status.url,status.conditions)"
curl -s "$SERVICE_URL/"

You have successfully: – used Cloud Shell as your developer/admin environment, – built and deployed an application to Cloud Run, – validated the endpoint, – accessed operational logs.

Troubleshooting

Common issues and practical fixes:

  1. PERMISSION_DENIED enabling APIs – Cause: you lack Service Usage permissions. – Fix: ask for roles/serviceusage.serviceUsageAdmin or have an admin enable the APIs.

  2. Billing errors / “project has no billing account” – Cause: project not linked to billing. – Fix: link billing in Console → Billing, or use a sandbox project with billing.

  3. Cloud Run deployment fails due to insufficient permissions – Cause: missing Cloud Run Admin or Service Account User permissions. – Fix: request roles/run.admin and roles/iam.serviceAccountUser (scope to the correct service account).

  4. Organization Policy blocks public access – Cause: org constraints may block --allow-unauthenticated. – Fix: deploy without public access and use IAM-based invocation, or request an exception in a sandbox.

  5. Region not supported / restricted – Cause: chosen region not enabled for Cloud Run or blocked by policy. – Fix: choose an allowed region; check org policy constraints.

  6. Build failures – Cause: dependency download issues, Python version mismatch, or transient build problems. – Fix: review Cloud Build logs (link printed in output). Try redeploy; pin dependencies; keep the Dockerfile simple.

Cleanup

To avoid ongoing charges, delete the Cloud Run service:

gcloud run services delete "$SERVICE_NAME" --region "$REGION"

Then check Artifact Registry for images that may remain. If you see a repository created for the build output (often project-dependent), remove unused images/repos carefully.

List repositories:

gcloud artifacts repositories list --location="$REGION"

If you identify a repo created for this demo and you’re sure it’s not used elsewhere, delete it:

REPO_NAME="REPOSITORY_NAME"
gcloud artifacts repositories delete "$REPO_NAME" --location="$REGION"

Also consider deleting build history if your org policy allows (build records themselves are not typically a major cost driver, but stored artifacts are).

11. Best Practices

Architecture best practices

  • Use Cloud Shell for interactive workflows, not as part of a production runtime.
  • For production delivery:
  • Use CI/CD (Cloud Build, GitHub Actions, etc.)
  • Store source in a version control system
  • Use Artifact Registry for immutable artifacts
  • Keep a clear separation of environments:
  • dev / test / prod projects
  • Different IAM bindings and org policies per environment

IAM/security best practices

  • Enforce least privilege:
  • Avoid granting broad Owner roles.
  • Use task-specific roles (Run Admin, Service Usage Admin, Artifact Registry Reader/Writer).
  • Prefer service account impersonation over downloading service account keys (where feasible and supported by your org).
  • Require MFA and strong identity policies for users who can deploy or modify production resources.
  • Use Organization Policies to restrict risky behaviors (public access, external IPs, allowed regions, etc.), then provide sandbox exceptions when needed.

Cost best practices

  • Use sandbox projects with:
  • Budgets + alerts
  • Short retention policies for logs in non-prod (where appropriate)
  • Scheduled cleanup for orphaned artifacts
  • Delete demo resources (Cloud Run services, Artifact Registry images) immediately after labs.
  • Avoid large dependency downloads and repeated builds from Cloud Shell; move heavy builds to CI.

Performance best practices

  • Don’t benchmark application performance from Cloud Shell.
  • Use Cloud Shell for control-plane operations and basic app validation only.
  • For performance tests, use dedicated load testing tools and environments.

Reliability best practices

  • Treat Cloud Shell sessions as ephemeral:
  • Keep important code in Git.
  • Use scripts stored in repos, not just in $HOME.
  • Use Cloud Shell as a “known-good admin terminal” but not the only operational path.

Operations best practices

  • Before running destructive commands:
  • gcloud config list to confirm project/account
  • Use --dry-run where supported
  • Standardize operational scripts (runbooks) in Git.
  • Use Cloud Logging and Audit Logs for traceability rather than relying on terminal history.

Governance/tagging/naming best practices

  • Adopt naming standards for resources created from Cloud Shell:
  • Prefix with team/app/environment (e.g., payments-api-dev)
  • Use labels/tags where supported:
  • env=dev, owner=team-x, cost-center=1234
  • Restrict “ad-hoc” production changes; prefer change management pipelines.

12. Security Considerations

Identity and access model

  • Cloud Shell access is tied to your Google identity.
  • Actions performed in Cloud Shell are authorized by Cloud IAM just like any other client (local gcloud, CI runner, etc.).
  • Use IAM Conditions and org policies where appropriate to limit when/where actions can occur.

Encryption

  • Google Cloud encrypts data at rest and in transit by default for managed services.
  • For Cloud Shell’s persistent home directory and session, rely on Google’s managed encryption, but validate against your compliance requirements. If you need specific controls (CMEK, etc.), verify whether they apply to Cloud Shell storage in official docs.

Network exposure

  • Cloud Shell is not a typical VM you expose to the internet.
  • Avoid treating Cloud Shell as a bastion host. For controlled private access, evaluate:
  • IAP TCP forwarding to bastion VMs
  • Dedicated admin workstations
  • Cloud Workstations (managed dev environments)
  • VPN/Interconnect patterns

Secrets handling (critical)

  • Do not store long-lived secrets in:
  • shell history
  • plaintext files in $HOME
  • Git repos in Cloud Shell
  • Prefer:
  • Secret Manager for application secrets
  • Short-lived tokens
  • Service account impersonation
  • Application Default Credentials patterns where appropriate

Audit/logging

  • Your most important audit trail is:
  • Cloud Audit Logs for resource changes in target projects
  • Cloud Logging for runtime logs (Cloud Run/GKE/etc.)
  • In regulated environments, verify:
  • audit log retention settings,
  • export to SIEM,
  • whether Cloud Shell session activity itself has additional logs (often the API calls are what matter).

Compliance considerations

  • Cloud Shell can simplify compliance by reducing unmanaged tooling—but it still introduces:
  • browser-based access paths,
  • file upload/download capabilities,
  • persistent user storage.
  • Ensure your policies cover:
  • allowed data types in Cloud Shell storage,
  • access reviews,
  • DLP requirements,
  • approved regions (where applicable).

Common security mistakes

  • Running production changes from the wrong project because the active project wasn’t checked.
  • Using --allow-unauthenticated by default for services that should be private.
  • Copying service account keys into Cloud Shell for convenience.
  • Storing secrets in environment variables and leaving terminals open.

Secure deployment recommendations

  • Use separate projects and strict IAM for production.
  • Require code review and CI/CD for production deployments.
  • Enforce org policy constraints to prevent accidental public exposure.
  • Use budgets/alerts and audit log exports.

13. Limitations and Gotchas

Cloud Shell is intentionally constrained. Plan around these realities:

Known limitations (practical)

  • Ephemeral VM session: session can end; background processes are not guaranteed to survive.
  • Not a server: not intended for hosting production apps or accepting inbound traffic like a normal VM.
  • Persistent storage is small: $HOME has a fixed size limit (commonly 5 GB; verify current limit).
  • Tool versions can change: the environment is managed by Google; updates may affect scripts that rely on specific versions.
  • Not a CI runner: don’t use Cloud Shell as your build pipeline.

Quotas and timeouts

  • Cloud Shell has usage limits (session duration / inactivity timeouts).
    Verify current limits: https://cloud.google.com/shell/docs

Regional constraints

  • Your Cloud Shell environment runs in a supported set of regions (may be selectable). The list can change.
  • Your organization may restrict regions by policy, affecting where you can deploy resources from your scripts.

Pricing surprises

  • Cloud Shell itself may be free, but the resources you create are not:
  • Artifact Registry images can linger.
  • Cloud Build can add up with repeated builds.
  • Cloud Run min instances or heavy traffic can increase cost.

Compatibility issues

  • Some enterprise environments block Cloud Shell via identity policies, context-aware access, or browser restrictions.
  • Corporate proxies or restricted egress can impact downloads and dependency installs (if those restrictions apply).

Operational gotchas

  • Wrong project context: always confirm gcloud config get-value project.
  • Wrong account context: check gcloud auth list.
  • Org policy surprises: constraints can block public services, external networking, or certain APIs.

Migration challenges

  • If teams rely too heavily on Cloud Shell “state” (files in $HOME), it becomes a hidden dependency.
  • Mitigate by keeping scripts and configuration in Git and using reproducible tooling (containers/devcontainers/IaC).

14. Comparison with Alternatives

Cloud Shell is one of several ways to get a CLI + tooling environment.

Option Best For Strengths Weaknesses When to Choose
Google Cloud Shell Quick interactive CLI, lightweight dev, troubleshooting No local install; authenticated; persistent home directory; integrated with Console Ephemeral; limited storage; not for heavy builds or long-running workloads Onboarding, labs, ad-hoc admin tasks, quick deploys
Cloud Shell Editor Small code edits + terminal in browser Integrated editing + terminal Not a full IDE for large projects Quick patches, tutorials, lightweight app work
Cloud Workstations (Google Cloud) Managed full dev environments More customizable, policy-controlled, scalable dev environments More setup and cost than Cloud Shell Standardized enterprise developer workstations
Local workstation + Google Cloud CLI Daily development, advanced tooling Full control, offline work, best IDE support Tooling drift; credential management; setup time Primary dev workflow when local installs are allowed
Compute Engine VM (bastion/admin VM) Controlled admin access to private resources Stable environment; can be hardened and monitored You manage patching, access, hardening When you need a true bastion with private network access
CI/CD runner (Cloud Build/GitHub Actions) Repeatable builds and deployments Auditable pipelines; automation; consistency Not interactive; requires pipeline setup Production deployments, repeatable releases
AWS CloudShell AWS users needing browser shell Similar “shell in console” concept Different IAM/auth model; not Google Cloud Multi-cloud teams per-cloud console shell needs
Azure Cloud Shell Azure users needing browser shell Similar concept Different auth and service integration Azure-centric orgs
GitHub Codespaces / devcontainers Cloud-based dev with full IDE Strong dev UX, reproducible containers Separate identity/governance model; cost When you want IDE-first cloud dev environments
Self-managed jump host + SSH Custom networks and strict controls Highly customizable Highest ops burden When compliance requires maximum control

15. Real-World Example

Enterprise example: regulated platform team standardizes admin access

  • Problem: A financial services company wants to reduce local credential sprawl and standardize how engineers run operational tasks across many Google Cloud projects.
  • Proposed architecture:
  • Developers/SREs use Cloud Shell for interactive tasks (read-only troubleshooting, log inspection, approved admin scripts).
  • Production changes are executed via CI/CD (Cloud Build) with approvals.
  • Strict IAM roles, MFA, and Organization Policies enforce guardrails (restricted regions, restrictions on unauthenticated invocations, controlled API enablement).
  • Audit Logs exported to a SIEM for investigation and compliance evidence.
  • Why Cloud Shell was chosen:
  • No local tool installation required; consistent environment.
  • Authentication tied to enterprise identity controls.
  • Quick access during incidents without relying on a specific laptop build.
  • Expected outcomes:
  • Faster incident response and reduced workstation setup time.
  • Clearer auditability for administrative actions (via standard API audit trails).
  • Reduced risk of leaked local credentials.

Startup/small-team example: fast iteration for Cloud Run deployments

  • Problem: A small startup ships a Cloud Run API and wants an easy, consistent workflow for deployments and quick fixes without investing in complex workstation management.
  • Proposed architecture:
  • Developers use Cloud Shell + Cloud Shell Editor for quick experiments and deployments to a dev project.
  • Main branch deployments go through a lightweight CI pipeline.
  • Artifact Registry stores images; Cloud Logging provides diagnostics.
  • Why Cloud Shell was chosen:
  • Zero setup; new hires can deploy on day one.
  • Convenient for demos and quick tests.
  • Expected outcomes:
  • Reduced onboarding time.
  • Faster prototypes and fewer environment setup issues.
  • Cleaner separation between interactive dev and production CI.

16. FAQ

  1. Is Cloud Shell free?
    Cloud Shell is generally provided at no additional cost, but it is subject to usage limits. The resources you create from Cloud Shell are billed normally. Verify current terms in official docs: https://cloud.google.com/shell/docs

  2. Does Cloud Shell run in my project?
    Your commands target a selected project, but the Cloud Shell environment itself is user-scoped and managed by Google. The exact hosting details can vary—rely on official documentation for specifics.

  3. What persists between sessions?
    Your home directory ($HOME) persists up to a documented storage limit (commonly 5 GB). The VM session itself is ephemeral.

  4. Can I use Cloud Shell as a production server?
    No. Cloud Shell is designed for interactive use, not for hosting production workloads.

  5. How does Cloud Shell authenticate to Google Cloud?
    It uses your logged-in Google identity and IAM permissions. Commands you run are authorized as your user (unless you explicitly impersonate another identity).

  6. Can I use service accounts from Cloud Shell?
    Yes, but avoid downloading long-lived service account keys. Prefer service account impersonation and short-lived credentials where possible (verify your org’s best practices).

  7. Does Cloud Shell support Kubernetes (kubectl)?
    Typically yes, and it’s commonly used with GKE. You still must fetch cluster credentials and have IAM permissions.

  8. Can I choose the region for Cloud Shell?
    Often you can select a region for the Cloud Shell environment in settings, but availability can change. Verify in the Cloud Shell docs.

  9. Is Cloud Shell suitable for Infrastructure as Code (Terraform)?
    It’s suitable for interactive Terraform use in sandbox environments. For production, run Terraform in controlled pipelines with state management and reviews.

  10. How do I avoid deploying into the wrong project?
    Always check: – gcloud config get-value project – gcloud auth list Consider using separate browser profiles for prod vs dev.

  11. Can Cloud Shell access private resources in my VPC?
    It depends on how those resources are exposed and your org’s network controls. Don’t assume Cloud Shell is inside your VPC like a bastion VM. Verify connectivity requirements and use bastion/IAP/VPN patterns when needed.

  12. What is Cloud Shell Editor?
    A web-based editor integrated with Cloud Shell for lightweight development. It’s useful for small projects and tutorials.

  13. Are actions from Cloud Shell audited?
    API calls you make (create/update/delete resources) are typically captured in Cloud Audit Logs for the relevant services/projects. Confirm audit coverage per service.

  14. Can I install additional packages?
    You can usually install packages in-session, but remember the session is ephemeral. Persist important setup steps in scripts or containerized workflows.

  15. What should I store in the Cloud Shell home directory?
    Store non-sensitive scripts and repos as needed, but avoid secrets and treat it as convenience storage, not a long-term backup.

  16. How does Cloud Shell help application development?
    It reduces setup time for build/deploy/test loops—especially for serverless and container workflows like Cloud Run and GKE administration.

  17. Is Cloud Shell a replacement for Cloud Build?
    No. Cloud Build is for automated builds; Cloud Shell is for interactive work. Use Cloud Build (or other CI) for repeatable, auditable pipelines.

17. Top Online Resources to Learn Cloud Shell

Resource Type Name Why It Is Useful
Official documentation Cloud Shell docs — https://cloud.google.com/shell/docs Authoritative feature descriptions, limits, and how-to guides
Official quickstart / getting started Start Cloud Shell — https://cloud.google.com/shell/docs/starting-cloud-shell Step-by-step entry into Cloud Shell and basic usage
Official reference Google Cloud CLI (gcloud) docs — https://cloud.google.com/sdk/gcloud Core CLI reference used heavily in Cloud Shell
Official product pricing Cloud Run pricing — https://cloud.google.com/run/pricing If you deploy from Cloud Shell, Cloud Run is a common billing driver
Official product pricing Cloud Build pricing — https://cloud.google.com/build/pricing Builds triggered from Cloud Shell (e.g., --source) may use Cloud Build
Official product pricing Artifact Registry pricing — https://cloud.google.com/artifact-registry/pricing Container images built from Cloud Shell are commonly stored here
Pricing tool Google Cloud Pricing Calculator — https://cloud.google.com/products/calculator Estimate costs for resources you create while using Cloud Shell
Architecture guidance Google Cloud Architecture Center — https://cloud.google.com/architecture Patterns that Cloud Shell users often implement (CI/CD, serverless, IAM)
Hands-on labs Google Cloud Skills Boost — https://www.cloudskillsboost.google Curated labs often using Cloud Shell for consistent student environments
Official videos Google Cloud Tech YouTube — https://www.youtube.com/@googlecloudtech Product walkthroughs and practical demos (search “Cloud Shell”)

18. Training and Certification Providers

Institute Suitable Audience Likely Learning Focus Mode Website URL
DevOpsSchool.com DevOps engineers, SREs, platform teams, developers DevOps practices, CI/CD, cloud operations (including Google Cloud tooling) check website https://www.devopsschool.com/
ScmGalaxy.com Beginners to intermediate engineers SCM, DevOps fundamentals, tooling and process check website https://www.scmgalaxy.com/
CLoudOpsNow.in Cloud engineers, operations teams Cloud operations, monitoring, governance, cost awareness check website https://www.cloudopsnow.in/
SreSchool.com SREs, reliability engineers, operations SRE practices, incident response, reliability patterns check website https://www.sreschool.com/
AiOpsSchool.com Ops teams exploring AIOps AIOps concepts, automation, observability check website https://www.aiopsschool.com/

19. Top Trainers

Platform/Site Likely Specialization Suitable Audience Website URL
RajeshKumar.xyz DevOps/cloud training resources (verify offerings) Engineers seeking guided training and mentorship https://rajeshkumar.xyz/
devopstrainer.in DevOps training (verify course catalog) Beginners to intermediate DevOps practitioners https://www.devopstrainer.in/
devopsfreelancer.com Freelance DevOps support/training platform (verify services) Teams needing short-term expertise https://www.devopsfreelancer.com/
devopssupport.in DevOps support and training resources (verify offerings) Ops/DevOps teams needing practical assistance https://www.devopssupport.in/

20. Top Consulting Companies

Company Likely Service Area Where They May Help Consulting Use Case Examples Website URL
cotocus.com Cloud/DevOps consulting (verify exact portfolio) Cloud adoption, DevOps implementation, operational readiness CI/CD design, IAM governance guidance, deployment standardization https://cotocus.com/
DevOpsSchool.com DevOps consulting and enablement Training + advisory for DevOps processes and tooling DevOps maturity assessment, pipeline implementation, platform enablement https://www.devopsschool.com/
DEVOPSCONSULTING.IN DevOps consulting (verify exact portfolio) Delivery pipelines, automation, monitoring, operational workflows Build/release automation, observability setup, operational runbooks https://www.devopsconsulting.in/

21. Career and Learning Roadmap

What to learn before Cloud Shell

  • Google Cloud fundamentals:
  • Projects, billing, IAM, service accounts
  • Regions/zones basics
  • CLI basics:
  • Shell commands, environment variables, basic scripting
  • Networking and security basics:
  • Public vs private access concepts
  • Principle of least privilege

What to learn after Cloud Shell

  • Cloud Run deployment patterns, IAM-based invocation, revisions/rollbacks
  • Cloud Build pipelines and build triggers
  • Artifact Registry hygiene (cleanup policies, vulnerability scanning integrations—verify features)
  • Infrastructure as Code:
  • Terraform (and remote state patterns)
  • Policy as code (where applicable)
  • Observability:
  • Cloud Logging queries
  • Cloud Monitoring dashboards and alerting
  • Security governance:
  • Organization Policies
  • IAM Conditions
  • Audit log exports

Job roles that use Cloud Shell

  • Cloud Engineer
  • DevOps Engineer
  • Site Reliability Engineer (SRE)
  • Platform Engineer
  • Security Engineer (cloud operations/security posture)
  • Application Developer (cloud-native)

Certification path (if available)

Cloud Shell itself is not a certification topic alone, but it supports workflows needed for Google Cloud certifications: – Associate Cloud Engineer – Professional Cloud Developer – Professional Cloud DevOps Engineer – Professional Cloud Architect
Verify current certification tracks: https://cloud.google.com/learn/certification

Project ideas for practice

  • Build and deploy a Cloud Run service from Cloud Shell, then:
  • add CI trigger (Cloud Build or GitHub Actions)
  • add Secret Manager integration
  • add structured logging and log-based metrics
  • Write a Cloud Shell script to inventory resources in a project and export to CSV.
  • Create a “golden runbook” repo with standardized operational commands and safe checks.

22. Glossary

  • Cloud Shell: Google Cloud’s browser-based terminal environment with preinstalled tooling and authenticated access.
  • Cloud Shell Editor: A browser-based editor integrated with Cloud Shell for lightweight development and file editing.
  • gcloud: The Google Cloud CLI used to manage Google Cloud resources.
  • IAM (Identity and Access Management): Google Cloud’s authorization system for who can do what on which resources.
  • Project: A Google Cloud container for resources, billing, IAM policies, and APIs.
  • API enablement: Turning on a Google Cloud API for a project so resources can be created/managed.
  • Cloud Run: Google Cloud’s serverless container platform.
  • Cloud Build: A managed build service often used to build container images and run CI steps.
  • Artifact Registry: Google Cloud service for storing container images and artifacts.
  • Audit Logs: Logs that record administrative and data access actions on Google Cloud resources (service-dependent).
  • Region: A geographic area where Google Cloud resources can run (e.g., us-central1).
  • Revision (Cloud Run): An immutable version of a Cloud Run service created on each deployment.
  • Least privilege: Security principle of granting only the minimum permissions needed.
  • Organization Policy: Guardrails applied at the organization/folder/project level to constrain allowed configurations and actions.

23. Summary

Cloud Shell is Google Cloud’s managed, browser-based terminal (and optional editor) designed for fast, authenticated access to cloud tooling—especially useful in Application development workflows for deploying, troubleshooting, and administering services.

It matters because it: – eliminates local setup and reduces onboarding time, – standardizes a baseline CLI environment for teams, – integrates with Google identity and Cloud IAM for controlled access.

Cost-wise, Cloud Shell itself is generally free with limits, but it can easily create billable downstream usage (Cloud Run, Cloud Build, Artifact Registry, logging, egress). Security-wise, treat it as an interactive admin endpoint: enforce least privilege, avoid secrets in files/history, and rely on audit logs and org policies.

Use Cloud Shell when you need quick, safe, browser-based CLI access to Google Cloud. Avoid using it as a production runtime or a CI/CD substitute.

Next learning step: Take the same app you deployed from Cloud Shell and move it into a repeatable CI/CD pipeline (Cloud Build triggers or GitHub Actions), with IAM-controlled deployments and Artifact Registry cleanup policies.