{"id":600,"date":"2026-04-14T16:56:22","date_gmt":"2026-04-14T16:56:22","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/google-cloud-shell-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-application-development\/"},"modified":"2026-04-14T16:56:22","modified_gmt":"2026-04-14T16:56:22","slug":"google-cloud-shell-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-application-development","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/google-cloud-shell-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-application-development\/","title":{"rendered":"Google Cloud Shell Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Application development"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">Category<\/h2>\n\n\n\n<p>Application development<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">1. Introduction<\/h2>\n\n\n\n<p>Cloud Shell is Google Cloud\u2019s browser-based command-line environment that gives you an authenticated terminal (and an optional editor) with common cloud and developer tools preinstalled.<\/p>\n\n\n\n<p><strong>Simple explanation:<\/strong> Open the Google Cloud Console, click the Cloud Shell icon, and you instantly get a Linux shell that\u2019s already logged into your Google Cloud account\u2014no local installs, no SSH keys, no laptop setup.<\/p>\n\n\n\n<p><strong>Technical explanation:<\/strong> 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 <code>gcloud<\/code>, <code>kubectl<\/code>, and Git work immediately. It\u2019s designed for secure interactive administration, development, and troubleshooting across Google Cloud services.<\/p>\n\n\n\n<p><strong>What problem it solves:<\/strong> 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\u2019s managed console workflow\u2014especially useful in <strong>Application development<\/strong> workflows where you frequently build, deploy, and troubleshoot cloud apps.<\/p>\n\n\n\n<blockquote>\n<p>Service status note: <strong>Cloud Shell<\/strong> is an active Google Cloud service. Google also offers <strong>Cloud Shell Editor<\/strong> (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<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">2. What is Cloud Shell?<\/h2>\n\n\n\n<p><strong>Official purpose (in practice):<\/strong> Cloud Shell is a managed, browser-accessible shell environment for interacting with Google Cloud resources using CLI tools and scripts.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Core capabilities<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Browser-based Linux terminal<\/strong> launched directly from the Google Cloud Console.<\/li>\n<li><strong>Preinstalled toolchain<\/strong> typically includes the Google Cloud CLI (<code>gcloud<\/code>), <code>kubectl<\/code>, Git, and other common utilities (exact inventory can change\u2014verify in official docs).<\/li>\n<li><strong>Preconfigured authentication<\/strong> tied to your signed-in Google identity.<\/li>\n<li><strong>Persistent home directory<\/strong> (commonly documented as <strong>5 GB<\/strong>) to keep code, config, and scripts between sessions.<\/li>\n<li><strong>Cloud Shell Editor<\/strong> for basic IDE-style editing and project work (availability and features can vary).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Major components<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Cloud Shell VM session (ephemeral):<\/strong> The compute environment backing your terminal session. It is not intended to be treated like a long-lived server.<\/li>\n<li><strong>Persistent <code>$HOME<\/code> storage:<\/strong> Keeps files between sessions (within the documented limit).<\/li>\n<li><strong>Console integration:<\/strong> UI entry point, project selector, and web preview integration.<\/li>\n<li><strong>Identity and access integration:<\/strong> Uses Google identity + Cloud IAM to authorize API calls.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Service type<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Managed interactive development\/admin environment<\/strong> (not a general-purpose hosting service).<\/li>\n<li>It\u2019s not a CI\/CD runner and not a replacement for production bastions\u2014though it can act as a convenient administrative endpoint for many tasks.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scope: account-scoped with project context<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud Shell is primarily <strong>user\/account-scoped<\/strong> (your environment follows your identity).<\/li>\n<li>Your CLI commands operate against a <strong>selected Google Cloud project<\/strong> (the active project in <code>gcloud<\/code>).<\/li>\n<li>The resources you create (Cloud Run services, GKE clusters, VMs, buckets, etc.) are <strong>project-scoped<\/strong> and billed\/secured accordingly.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Regional\/global considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud Shell\u2019s backing environment runs in a <strong>Google-managed region<\/strong> you can typically view or select in settings (the set of available regions can change).  <\/li>\n<li>Regardless of where Cloud Shell is hosted, it can manage resources across regions\u2014your API calls go to Google Cloud control planes.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How it fits into the Google Cloud ecosystem<\/h3>\n\n\n\n<p>Cloud Shell is best understood as your \u201czero-setup workstation inside Google Cloud Console\u201d:\n&#8211; It complements <strong>Cloud Console UI<\/strong> by providing an immediate CLI.\n&#8211; It complements <strong>Cloud Workstations<\/strong> (full managed dev environments) and <strong>local development<\/strong>.\n&#8211; It works with almost every Google Cloud product because it\u2019s essentially a preconfigured client environment for Google Cloud APIs.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">3. Why use Cloud Shell?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Business reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Faster onboarding:<\/strong> New engineers can run <code>gcloud<\/code> and deploy apps immediately\u2014no local installs, no VPN prerequisites in many cases.<\/li>\n<li><strong>Standardized environment:<\/strong> Reduced \u201cworks on my machine\u201d issues for scripts and basic deployments.<\/li>\n<li><strong>Lower endpoint management overhead:<\/strong> Fewer local dependencies and reduced support time for workstation toolchains.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Technical reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Preinstalled Google Cloud tooling:<\/strong> Common CLIs and SDKs are ready out of the box.<\/li>\n<li><strong>Authenticated by default:<\/strong> Identity is bound to the logged-in user; avoids copying long-lived keys around.<\/li>\n<li><strong>Convenient for small automation:<\/strong> Great for quick scripts, one-off migrations, and interactive debugging.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Consistent troubleshooting endpoint:<\/strong> Useful for verifying IAM, API enablement, deployments, and logs quickly.<\/li>\n<li><strong>Portable sessions:<\/strong> Your home directory persists, so you can keep helper scripts and configuration.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/compliance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Reduces credential sprawl:<\/strong> You typically don\u2019t need to store local service account keys just to use the CLI.<\/li>\n<li><strong>Centralized access control:<\/strong> Uses Cloud IAM; actions taken through <code>gcloud<\/code> are subject to the same IAM and audit logging as anywhere else.<\/li>\n<li><strong>Better control than unmanaged laptops (in many orgs):<\/strong> Especially where developers are restricted from installing tooling locally.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scalability\/performance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud Shell is <strong>not about scaling workloads<\/strong>; it\u2019s about scaling <strong>human workflows<\/strong>:<\/li>\n<li>More developers can safely access tooling without distributing credentials and installers.<\/li>\n<li>Teams can create repeatable operational runbooks.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should choose Cloud Shell<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>You need <strong>quick CLI access<\/strong> to Google Cloud from anywhere.<\/li>\n<li>You\u2019re teaching\/training, running labs, or standardizing onboarding.<\/li>\n<li>You\u2019re doing <strong>Application development<\/strong> tasks like deploying to Cloud Run, managing Artifact Registry images, editing IaC, or troubleshooting services.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should not choose it<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Not for production hosting<\/strong>: You should not run long-lived services from Cloud Shell.<\/li>\n<li><strong>Not a CI\/CD platform<\/strong>: Use Cloud Build, GitHub Actions, GitLab CI, etc.<\/li>\n<li><strong>Not for heavy builds<\/strong>: For large compilation\/build workloads, use Cloud Build or dedicated build runners.<\/li>\n<li><strong>Not a hardened bastion replacement<\/strong> in highly regulated environments without reviewing org policies, network controls, and auditing needs.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">4. Where is Cloud Shell used?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Industries<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Software\/SaaS:<\/strong> Rapid deployments, day-2 operations, and incident response.<\/li>\n<li><strong>Financial services \/ regulated:<\/strong> Controlled access to cloud tooling without unmanaged local installs (subject to compliance review).<\/li>\n<li><strong>Education:<\/strong> Classroom labs and training environments.<\/li>\n<li><strong>Media\/entertainment &amp; gaming:<\/strong> Quick operational workflows across projects.<\/li>\n<li><strong>Healthcare &amp; public sector:<\/strong> Often used for standardized, auditable admin workflows (verify compliance requirements).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Team types<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Application developers<\/li>\n<li>DevOps \/ Platform Engineering<\/li>\n<li>SRE \/ Operations<\/li>\n<li>Security engineering (for investigations, IAM validation, policy checks)<\/li>\n<li>Data engineering (CLI-based orchestration of storage and jobs)<\/li>\n<li>Architects and technical leads (prototyping and reference implementations)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Workloads and architectures<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud Run \/ GKE deployments via CLI<\/li>\n<li>IaC (Terraform) and config management workflows<\/li>\n<li>Storage operations (Cloud Storage, transfer checks)<\/li>\n<li>IAM auditing and policy updates (with careful review)<\/li>\n<li>Debugging networking and auth issues from a known-good environment<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Real-world deployment contexts<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Production:<\/strong> Used mainly for administrative tasks (deploys, rollbacks, config edits), not for hosting.<\/li>\n<li><strong>Dev\/Test:<\/strong> Prototyping and small deployments, rapid iteration, teaching.<\/li>\n<li><strong>Incident response:<\/strong> Triage from a standard environment when local tooling is broken or unavailable.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">5. Top Use Cases and Scenarios<\/h2>\n\n\n\n<p>Below are realistic scenarios where Cloud Shell is commonly the fastest, safest path.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">5.1 Run <code>gcloud<\/code> without installing anything<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A developer needs to inspect IAM bindings or enable an API but lacks local tooling.<\/li>\n<li><strong>Why Cloud Shell fits:<\/strong> <code>gcloud<\/code> is available immediately and authenticated.<\/li>\n<li><strong>Example:<\/strong> Launch Cloud Shell \u2192 <code>gcloud services enable run.googleapis.com<\/code> \u2192 deploy app.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5.2 Deploy a \u201cHello World\u201d service to Cloud Run<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> You need a quick public endpoint for a demo or integration test.<\/li>\n<li><strong>Why Cloud Shell fits:<\/strong> Create code, build, and deploy from the browser in minutes.<\/li>\n<li><strong>Example:<\/strong> Write a small Flask app and run <code>gcloud run deploy --source .<\/code>.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5.3 Kubernetes cluster administration with <code>kubectl<\/code><\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> You must debug a GKE service and don\u2019t have kubeconfig set up locally.<\/li>\n<li><strong>Why Cloud Shell fits:<\/strong> <code>gcloud container clusters get-credentials<\/code> + <code>kubectl<\/code> is typically ready.<\/li>\n<li><strong>Example:<\/strong> Fetch credentials and check <code>kubectl get pods -n prod<\/code>.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5.4 Git operations and quick patching<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A simple config fix is needed and you\u2019re away from your workstation.<\/li>\n<li><strong>Why Cloud Shell fits:<\/strong> Git + editor available; commit and push from the browser.<\/li>\n<li><strong>Example:<\/strong> Edit Terraform variables, push a hotfix branch.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5.5 Investigate permissions and identity context<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A deployment fails due to IAM confusion (wrong principal, wrong project).<\/li>\n<li><strong>Why Cloud Shell fits:<\/strong> Easy to run <code>gcloud auth list<\/code>, <code>gcloud config list<\/code>, and policy inspection commands.<\/li>\n<li><strong>Example:<\/strong> Confirm active account and project, then validate IAM bindings.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5.6 Prototype Infrastructure as Code (Terraform)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> You want to test a Terraform module quickly without touching your local environment.<\/li>\n<li><strong>Why Cloud Shell fits:<\/strong> Terraform is often available (verify current tooling availability) or can be installed in-session.<\/li>\n<li><strong>Example:<\/strong> <code>terraform init &amp;&amp; terraform plan<\/code> against a sandbox project.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5.7 Validate network access to a service endpoint<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Need to confirm a URL, DNS, or TLS handshake behavior from a neutral environment.<\/li>\n<li><strong>Why Cloud Shell fits:<\/strong> Use <code>curl<\/code>, <code>openssl<\/code>, and standard Linux tooling quickly.<\/li>\n<li><strong>Example:<\/strong> <code>curl -v https:\/\/my-service-xyz.a.run.app<\/code>.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5.8 Manage artifacts and images (Artifact Registry)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> You need to list, delete, or troubleshoot container images.<\/li>\n<li><strong>Why Cloud Shell fits:<\/strong> Auth and CLI access are ready.<\/li>\n<li><strong>Example:<\/strong> <code>gcloud artifacts docker images list ...<\/code>.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5.9 Build and run small scripts for admin automation<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Repetitive tasks like label updates or resource inventory.<\/li>\n<li><strong>Why Cloud Shell fits:<\/strong> Store scripts in <code>$HOME<\/code>, run them as needed, integrate with Cloud Logging\/Audit Logs via APIs.<\/li>\n<li><strong>Example:<\/strong> Python script to list resources across projects with the Resource Manager API.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5.10 Training labs and workshops<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Students have mixed OSes and inconsistent local setups.<\/li>\n<li><strong>Why Cloud Shell fits:<\/strong> Everyone gets the same environment in the browser.<\/li>\n<li><strong>Example:<\/strong> Workshop uses Cloud Shell to deploy a simple microservice and view logs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5.11 Quick access when corporate laptops are locked down<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Installing CLI tools is blocked by endpoint policies.<\/li>\n<li><strong>Why Cloud Shell fits:<\/strong> Tooling runs in Google\u2019s environment, governed by IAM.<\/li>\n<li><strong>Example:<\/strong> Ops engineer uses Cloud Shell to roll back Cloud Run revision.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5.12 Break-glass administrative access (with controls)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A critical incident requires access from a clean environment.<\/li>\n<li><strong>Why Cloud Shell fits:<\/strong> It\u2019s a known, managed environment\u2014but must be combined with strong IAM, MFA, and audit policies.<\/li>\n<li><strong>Example:<\/strong> Security-approved break-glass group can use Cloud Shell to disable a compromised service account.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">6. Core Features<\/h2>\n\n\n\n<p>Cloud Shell\u2019s features are best understood as \u201cfast access + safe defaults + persistence for your workspace.\u201d<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">6.1 Browser-based terminal in Google Cloud Console<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Launches a shell session in a browser tab from the Cloud Console.<\/li>\n<li><strong>Why it matters:<\/strong> Eliminates local terminal setup and network hurdles.<\/li>\n<li><strong>Practical benefit:<\/strong> You can access Google Cloud tooling from any machine with a browser.<\/li>\n<li><strong>Caveats:<\/strong> Not designed for long-running background workloads; sessions can time out.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.2 Preinstalled Google Cloud CLI (<code>gcloud<\/code>) and common tools<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Provides a ready-to-use CLI environment.<\/li>\n<li><strong>Why it matters:<\/strong> The fastest path to interact with Google Cloud APIs and services.<\/li>\n<li><strong>Practical benefit:<\/strong> Run deployment and troubleshooting commands immediately.<\/li>\n<li><strong>Caveats:<\/strong> Tool versions may change as Google updates the environment. Pin versions in CI\/CD elsewhere; treat Cloud Shell as an interactive tool.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.3 Authenticated environment (identity-aware)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Uses your logged-in Google identity for authentication to Google Cloud.<\/li>\n<li><strong>Why it matters:<\/strong> Reduces the need to manage local credentials.<\/li>\n<li><strong>Practical benefit:<\/strong> <code>gcloud<\/code> is typically ready with an active account; you can switch accounts\/projects.<\/li>\n<li><strong>Caveats:<\/strong> Your effective permissions are still governed by IAM; Cloud Shell does not \u201cbypass\u201d security controls.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.4 Persistent home directory<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Persists your files across sessions in <code>$HOME<\/code> up to the documented limit (commonly 5 GB).<\/li>\n<li><strong>Why it matters:<\/strong> Enables a stable working directory for scripts, config, and repos.<\/li>\n<li><strong>Practical benefit:<\/strong> Keep your helper scripts, SSH config (if used), and Git repos.<\/li>\n<li><strong>Caveats:<\/strong> Don\u2019t treat it as durable backup storage; follow your org\u2019s data handling rules.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.5 Cloud Shell Editor (optional)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Provides a browser-based editor integrated with Cloud Shell.<\/li>\n<li><strong>Why it matters:<\/strong> You can do lightweight development without leaving the console.<\/li>\n<li><strong>Practical benefit:<\/strong> Edit code, run terminal commands, and deploy from one place.<\/li>\n<li><strong>Caveats:<\/strong> Not a full replacement for a dedicated IDE for large projects.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.6 Web preview for local ports<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Lets you preview services you run in Cloud Shell via a proxy from the browser.<\/li>\n<li><strong>Why it matters:<\/strong> Quickly test web apps without exposing a public VM.<\/li>\n<li><strong>Practical benefit:<\/strong> Run a dev server and view it in your browser.<\/li>\n<li><strong>Caveats:<\/strong> Port and behavior constraints apply; verify supported ports in official docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.7 Project context integration<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Connects Cloud Console project selection to CLI defaults (active project).<\/li>\n<li><strong>Why it matters:<\/strong> Reduces accidental deployments into the wrong project.<\/li>\n<li><strong>Practical benefit:<\/strong> Faster switching between environments (dev\/test\/prod).<\/li>\n<li><strong>Caveats:<\/strong> Still validate with <code>gcloud config list<\/code> before running destructive commands.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.8 Easy file upload\/download (console-assisted)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Supports moving small files between your machine and the Cloud Shell environment via the UI\/commands.<\/li>\n<li><strong>Why it matters:<\/strong> Simplifies working with keys, configs, or small datasets (when allowed).<\/li>\n<li><strong>Practical benefit:<\/strong> Quickly bring in a config file for testing.<\/li>\n<li><strong>Caveats:<\/strong> Treat file movement as a data exfiltration vector; follow security policy.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.9 Integration with Google Cloud APIs and services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Cloud Shell is an authenticated client environment for Google Cloud.<\/li>\n<li><strong>Why it matters:<\/strong> Virtually any service can be managed via CLI\/API from Cloud Shell.<\/li>\n<li><strong>Practical benefit:<\/strong> Use one place to manage Cloud Run, GKE, IAM, Storage, Pub\/Sub, etc.<\/li>\n<li><strong>Caveats:<\/strong> API enablement, IAM, org policies, and network constraints still apply.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">7. Architecture and How It Works<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">High-level architecture<\/h3>\n\n\n\n<p>Cloud Shell is an interactive environment that sits between the user and Google Cloud APIs:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>User<\/strong> interacts through the <strong>Google Cloud Console<\/strong> in a browser.<\/li>\n<li>The browser opens a session to a <strong>Google-managed Cloud Shell VM<\/strong>.<\/li>\n<li>Tools like <code>gcloud<\/code> call <strong>Google Cloud service APIs<\/strong> over Google\u2019s networks.<\/li>\n<li>Your work files are stored in a <strong>persistent home directory<\/strong>.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Request\/data\/control flow (typical)<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>User opens Cloud Shell in Cloud Console.<\/li>\n<li>Cloud Shell provisions (or reuses) a VM session for the user.<\/li>\n<li><code>gcloud<\/code> uses the user\u2019s identity to obtain credentials and call APIs.<\/li>\n<li>API calls execute control-plane operations (deploy a service, create a bucket, update IAM).<\/li>\n<li>Results are returned to the terminal; operational events are captured by <strong>Cloud Audit Logs<\/strong> for the target project\/services (where applicable).<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Integrations with related services<\/h3>\n\n\n\n<p>Common integrations include:\n&#8211; <strong>Cloud Run<\/strong>: build and deploy apps with <code>gcloud run<\/code>.\n&#8211; <strong>Cloud Build<\/strong>: build container images from source.\n&#8211; <strong>Artifact Registry<\/strong>: store images and artifacts.\n&#8211; <strong>GKE<\/strong>: use <code>kubectl<\/code> after fetching cluster credentials.\n&#8211; <strong>Cloud Logging \/ Error Reporting<\/strong>: check logs and errors for deployed services.\n&#8211; <strong>IAM<\/strong>: manage access policies and service accounts.\n&#8211; <strong>Secret Manager<\/strong>: retrieve secrets securely (recommended over storing secrets in files).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Dependency services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Google identity platform for authentication.<\/li>\n<li>Google Cloud control plane APIs for whatever you manage.<\/li>\n<li>A Google-managed VM runtime and storage for the Cloud Shell environment.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/authentication model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Primary identity is <strong>your Google account \/ Cloud Identity user<\/strong>.<\/li>\n<li>Authorization is controlled by <strong>Cloud IAM<\/strong>.<\/li>\n<li>Actions you take (creating\/deleting resources) are authorized as your principal and should appear in <strong>Audit Logs<\/strong> in the relevant project\/service (verify per-service audit coverage).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Networking model (practical view)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud Shell can typically reach Google Cloud APIs and public internet endpoints (subject to org policy and environment constraints).<\/li>\n<li>Incoming network access to the Cloud Shell VM is not treated like a normal public VM; web preview uses a proxied approach.<\/li>\n<li>For private\/internal-only resources, connectivity depends on the target service exposure model and your organization\u2019s network controls. If you require strict private access paths, evaluate bastion\/VPN\/VPC patterns and verify Cloud Shell networking behavior in official docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Monitoring\/logging\/governance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud Shell itself is an interactive environment; most governance focus is on:<\/li>\n<li><strong>Who can open Cloud Shell<\/strong> (identity and org policy)<\/li>\n<li><strong>What they can do<\/strong> (IAM)<\/li>\n<li><strong>What they did<\/strong> (Audit Logs, Cloud Logging for resource actions)<\/li>\n<li>Establish guardrails:<\/li>\n<li>Principle of least privilege<\/li>\n<li>Project separation (dev\/test\/prod)<\/li>\n<li>Organization Policies (restrict APIs, restrict external IP, domain restrictions, etc.)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Simple architecture diagram<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart LR\n  U[User in Browser] --&gt; C[Google Cloud Console]\n  C --&gt; CS[Cloud Shell Session\\n(ephemeral VM + persistent $HOME)]\n  CS --&gt; APIs[Google Cloud APIs\\n(IAM, Cloud Run, GKE, Storage, ...)]\n  APIs --&gt; R[Project Resources]\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Production-style architecture diagram (practical workflow)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart TB\n  Dev[Developer \/ SRE] --&gt; Console[Cloud Console + Cloud Shell]\n  Console --&gt; Repo[Source Repo\\n(e.g., GitHub\/CSR)]\n  Console --&gt; Build[Cloud Build]\n  Build --&gt; AR[Artifact Registry]\n  AR --&gt; Run[Cloud Run Service]\n  Run --&gt; Logs[Cloud Logging]\n  Run --&gt; Mon[Cloud Monitoring]\n\n  Console --&gt; IAM[IAM \/ Org Policy]\n  IAM --&gt; Build\n  IAM --&gt; Run\n\n  subgraph Projects\n    Build\n    AR\n    Run\n    Logs\n    Mon\n  end\n<\/code><\/pre>\n\n\n\n<p>Key idea: Cloud Shell is the interactive entry point, but production-grade delivery should rely on controlled pipelines and IAM guardrails.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">8. Prerequisites<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Account\/project requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>A <strong>Google Cloud account<\/strong> (Google identity or Cloud Identity\/Workspace user).<\/li>\n<li>Access to at least one <strong>Google Cloud project<\/strong>.<\/li>\n<li>In many organizations, you may need to be inside an allowed domain or group to access Cloud Shell.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Permissions \/ IAM roles<\/h3>\n\n\n\n<p>Minimum permissions depend on what you will do:\n&#8211; To <em>use Cloud Shell itself<\/em>, you generally need permissions allowed by your organization (verify org policies and Cloud Shell access settings).\n&#8211; For the hands-on lab in this tutorial (deploy to Cloud Run), you typically need:\n  &#8211; Permission to enable APIs (often <code>roles\/serviceusage.serviceUsageAdmin<\/code>) <strong>or<\/strong> an admin to enable required APIs for you.\n  &#8211; Cloud Run deploy permissions (often <code>roles\/run.admin<\/code>) and permission to act as a service account (often <code>roles\/iam.serviceAccountUser<\/code> on the runtime service account).\n  &#8211; Cloud Build permissions if building from source (often <code>roles\/cloudbuild.builds.editor<\/code>).\n  &#8211; Artifact Registry permissions if images are stored there.<\/p>\n\n\n\n<p>If you\u2019re in a controlled org, ask for a pre-created \u201csandbox\u201d project with these permissions.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Billing requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud Shell is generally provided without a direct usage charge, but <strong>billing must be enabled<\/strong> on the project for most deployable resources (Cloud Run, Artifact Registry, etc.).<\/li>\n<li>The lab uses Cloud Run + build from source, which may incur costs depending on usage and free tier availability.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">CLI\/SDK\/tools needed<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>None locally. Cloud Shell provides CLI tools in the browser.<\/li>\n<li>Optional: A GitHub account if you want to push code to a remote repo (not required for the lab).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Region availability<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud Shell environment region availability varies.  <\/li>\n<li>Cloud Run region availability varies by product and rollout. Pick a supported Cloud Run region (for example <code>us-central1<\/code>) and adjust if needed.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas\/limits<\/h3>\n\n\n\n<p>Common constraints to plan for (verify current values in docs):\n&#8211; Cloud Shell session timeouts and usage limits.\n&#8211; Persistent home directory size limit (commonly documented as 5 GB).\n&#8211; Cloud Run request\/concurrency limits and Cloud Build quotas (project-specific).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Prerequisite services<\/h3>\n\n\n\n<p>For the lab:\n&#8211; Cloud Run API\n&#8211; Cloud Build API\n&#8211; Artifact Registry API (often used under the hood)\n&#8211; (Optional) Cloud Logging API (usually enabled by default)<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">9. Pricing \/ Cost<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Cloud Shell pricing model (what to expect)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Cloud Shell itself is generally provided at no additional cost<\/strong>, subject to usage limits\/quotas.<br\/>\n  Verify the latest statement and quotas in official docs: https:\/\/cloud.google.com\/shell\/docs<\/li>\n<\/ul>\n\n\n\n<p>Cloud Shell is best thought of as \u201cfree access to tools,\u201d while <strong>the resources you create are billed normally<\/strong>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing dimensions (indirect)<\/h3>\n\n\n\n<p>While Cloud Shell may not be billed directly, your actions can trigger charges in other services:<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Activity from Cloud Shell<\/th>\n<th>Services that may bill<\/th>\n<th>Typical cost drivers<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Deploy to Cloud Run from source<\/td>\n<td>Cloud Run, Cloud Build, Artifact Registry<\/td>\n<td>Build minutes, stored images, requests, CPU\/memory-seconds<\/td>\n<\/tr>\n<tr>\n<td>Create a GKE cluster<\/td>\n<td>GKE, Compute Engine, Persistent Disk, Load Balancing<\/td>\n<td>Cluster fees, node VM hours, disks, LB, egress<\/td>\n<\/tr>\n<tr>\n<td>Create VMs<\/td>\n<td>Compute Engine<\/td>\n<td>VM hours, disks, IPs, egress<\/td>\n<\/tr>\n<tr>\n<td>Use Cloud Storage<\/td>\n<td>Cloud Storage<\/td>\n<td>GB-month storage, operations, egress<\/td>\n<\/tr>\n<tr>\n<td>Pull images\/dependencies<\/td>\n<td>Artifact Registry \/ internet egress<\/td>\n<td>Storage and network transfer<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h3 class=\"wp-block-heading\">Free tier considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Many Google Cloud services have free tiers (Cloud Run has a free allowance in many regions; Cloud Build has quotas; etc.), but <strong>free tier eligibility varies<\/strong> by region and account.<\/li>\n<li>Treat free tier as \u201chelpful but not guaranteed.\u201d Always confirm current free tier details in the service\u2019s pricing page.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Hidden or indirect costs to watch<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Artifact Registry storage<\/strong>: images built during experiments can accumulate.<\/li>\n<li><strong>Cloud Build<\/strong>: frequent builds can exceed any free quota.<\/li>\n<li><strong>Network egress<\/strong>: downloading large dependencies or data from the internet can create egress charges depending on path and service.<\/li>\n<li><strong>Logging volume<\/strong>: verbose app logs can create ingestion\/storage costs at scale.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Data transfer implications<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud Shell itself is not your main data plane, but it can trigger:<\/li>\n<li>Downloads from external package repositories<\/li>\n<li>Uploads to Artifact Registry<\/li>\n<li>Calls to APIs across regions<\/li>\n<li>For cost-sensitive environments, keep builds minimal and prefer regional alignment (build + deploy in same region where possible).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How to optimize cost when using Cloud Shell<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use Cloud Shell for <strong>interactive control-plane tasks<\/strong>, not for repeated builds.<\/li>\n<li>Prefer <strong>small sample apps<\/strong> and remove resources after testing.<\/li>\n<li>Delete unused container images and repositories in Artifact Registry.<\/li>\n<li>Set budgets and alerts in Billing.<\/li>\n<li>Use separate <strong>sandbox projects<\/strong> with strict budgets for training and experimentation.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Example low-cost starter estimate<\/h3>\n\n\n\n<p>A realistic \u201cstarter lab\u201d cost depends on:\n&#8211; how many builds you run,\n&#8211; whether Cloud Run stays idle or receives traffic,\n&#8211; how large your container image is,\n&#8211; whether you remain within free tiers.<\/p>\n\n\n\n<p>For a single small Cloud Run deployment with minimal traffic and a small image, costs are often low\u2014sometimes within free allowances\u2014but <strong>verify using the Google Cloud Pricing Calculator<\/strong>:\n&#8211; Pricing Calculator: https:\/\/cloud.google.com\/products\/calculator\n&#8211; Cloud Run pricing: https:\/\/cloud.google.com\/run\/pricing\n&#8211; Cloud Build pricing: https:\/\/cloud.google.com\/build\/pricing\n&#8211; Artifact Registry pricing: https:\/\/cloud.google.com\/artifact-registry\/pricing<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Example production cost considerations<\/h3>\n\n\n\n<p>In production, Cloud Shell is not the cost driver; your platform choices are:\n&#8211; Cloud Run (requests, CPU\/memory, min instances if set)\n&#8211; Artifact Registry storage and egress\n&#8211; Logging\/Monitoring ingestion and retention\n&#8211; CI\/CD build frequency (Cloud Build or external runners)\n&#8211; Networking (load balancers, serverless egress, VPC connectors)<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">10. Step-by-Step Hands-On Tutorial<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Objective<\/h3>\n\n\n\n<p>Use <strong>Cloud Shell<\/strong> to build and deploy a small web service to <strong>Cloud Run<\/strong> from source, then view logs and clean up resources.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Lab Overview<\/h3>\n\n\n\n<p>You will:\n1. Launch Cloud Shell and confirm authentication and project settings.\n2. Enable required APIs.\n3. Create a tiny Python web app.\n4. Deploy it to Cloud Run using <code>gcloud run deploy --source<\/code>.\n5. Validate the service endpoint and review logs.\n6. Clean up Cloud Run and related artifacts to avoid ongoing charges.<\/p>\n\n\n\n<p><strong>Expected time:<\/strong> 20\u201340 minutes<br\/>\n<strong>Cost:<\/strong> Low for a single deployment; may be free-tier eligible, but not guaranteed.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 1: Launch Cloud Shell and confirm your environment<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Open the Google Cloud Console: https:\/\/console.cloud.google.com\/<\/li>\n<li>Click the <strong>Cloud Shell<\/strong> icon (terminal) in the top-right toolbar.<\/li>\n<li>Wait for Cloud Shell to start.<\/li>\n<\/ol>\n\n\n\n<p>In the Cloud Shell terminal, run:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud --version\ngcloud auth list\ngcloud config list\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; You see the installed <code>gcloud<\/code> version.\n&#8211; Your account appears under <code>gcloud auth list<\/code>.\n&#8211; <code>gcloud config list<\/code> shows an active project (or it may be empty if not set yet).<\/p>\n\n\n\n<p>If no project is set, choose one:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud projects list\ngcloud config set project PROJECT_ID\n<\/code><\/pre>\n\n\n\n<p>Replace <code>PROJECT_ID<\/code> with your target project.<\/p>\n\n\n\n<p><strong>Verification<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud config get-value project\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 2: Confirm billing and enable required APIs<\/h3>\n\n\n\n<p>Cloud Run deployments generally require billing enabled on the project.<\/p>\n\n\n\n<p><strong>Check billing (one approach):<\/strong>\n&#8211; In Console: <strong>Billing<\/strong> \u2192 confirm the project is linked to an active billing account.<\/p>\n\n\n\n<p>Then enable required APIs:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud services enable \\\n  run.googleapis.com \\\n  cloudbuild.googleapis.com \\\n  artifactregistry.googleapis.com\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; Command completes without error.\n&#8211; APIs are enabled for the project.<\/p>\n\n\n\n<p><strong>Verification<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud services list --enabled --filter=\"name:run.googleapis.com OR name:cloudbuild.googleapis.com OR name:artifactregistry.googleapis.com\"\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 3: Create a small web application locally in Cloud Shell<\/h3>\n\n\n\n<p>Create a new folder and files:<\/p>\n\n\n\n<pre><code class=\"language-bash\">mkdir -p ~\/cloudshell-cloudrun-demo\ncd ~\/cloudshell-cloudrun-demo\n<\/code><\/pre>\n\n\n\n<p>Create <code>app.py<\/code>:<\/p>\n\n\n\n<pre><code class=\"language-bash\">cat &gt; app.py &lt;&lt;'EOF'\nimport os\nfrom flask import Flask, request\n\napp = Flask(__name__)\n\n@app.get(\"\/\")\ndef hello():\n    target = request.args.get(\"name\", \"Cloud Shell\")\n    return {\n        \"message\": f\"Hello, {target}!\",\n        \"service\": \"cloudshell-cloudrun-demo\",\n    }\n\nif __name__ == \"__main__\":\n    port = int(os.environ.get(\"PORT\", \"8080\"))\n    app.run(host=\"0.0.0.0\", port=port)\nEOF\n<\/code><\/pre>\n\n\n\n<p>Create <code>requirements.txt<\/code>:<\/p>\n\n\n\n<pre><code class=\"language-bash\">cat &gt; requirements.txt &lt;&lt;'EOF'\nFlask==3.0.0\ngunicorn==21.2.0\nEOF\n<\/code><\/pre>\n\n\n\n<p>Create a <code>Dockerfile<\/code> (Cloud Run can deploy from source without you writing a Dockerfile, but having one makes the build more explicit and portable):<\/p>\n\n\n\n<pre><code class=\"language-bash\">cat &gt; Dockerfile &lt;&lt;'EOF'\nFROM python:3.12-slim\n\nWORKDIR \/app\nCOPY requirements.txt .\nRUN pip install --no-cache-dir -r requirements.txt\n\nCOPY app.py .\n\nENV PORT=8080\nCMD exec gunicorn --bind :$PORT app:app\nEOF\n<\/code><\/pre>\n\n\n\n<p>(Optional) Quick local run inside Cloud Shell (for sanity):<\/p>\n\n\n\n<pre><code class=\"language-bash\">python3 -m venv .venv\nsource .venv\/bin\/activate\npip install -r requirements.txt\npython3 app.py\n<\/code><\/pre>\n\n\n\n<p>Cloud Shell will show it\u2019s listening on port 8080. Use <strong>Web preview<\/strong> in the Cloud Shell toolbar if available, or test from another terminal tab:<\/p>\n\n\n\n<pre><code class=\"language-bash\">curl -s http:\/\/localhost:8080\/\n<\/code><\/pre>\n\n\n\n<p>Stop the app with <code>Ctrl+C<\/code>.<\/p>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; <code>curl<\/code> returns JSON like <code>{\"message\":\"Hello, Cloud Shell!\", ...}<\/code><\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 4: Deploy to Cloud Run from Cloud Shell<\/h3>\n\n\n\n<p>Choose a region. This tutorial uses <code>us-central1<\/code> as an example. If your organization restricts regions, pick an allowed one.<\/p>\n\n\n\n<p>Set variables:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export REGION=\"us-central1\"\nexport SERVICE_NAME=\"cloudshell-cloudrun-demo\"\n<\/code><\/pre>\n\n\n\n<p>Deploy:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud run deploy \"$SERVICE_NAME\" \\\n  --source . \\\n  --region \"$REGION\" \\\n  --allow-unauthenticated\n<\/code><\/pre>\n\n\n\n<p>Notes:\n&#8211; <code>--source .<\/code> uses Google\u2019s build process (often via Cloud Build) to build a container and deploy it.\n&#8211; <code>--allow-unauthenticated<\/code> makes the service publicly accessible. For private services, omit it and use IAM-based access.<\/p>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; You see build output, then a deployed service URL like:\n  <code>https:\/\/cloudshell-cloudrun-demo-&lt;hash&gt;-uc.a.run.app<\/code><\/p>\n\n\n\n<p><strong>Verification<\/strong>\nStore the URL and test it:<\/p>\n\n\n\n<pre><code class=\"language-bash\">SERVICE_URL=\"$(gcloud run services describe \"$SERVICE_NAME\" --region \"$REGION\" --format='value(status.url)')\"\necho \"$SERVICE_URL\"\n\ncurl -s \"$SERVICE_URL\/?name=Google%20Cloud\" | sed 's\/\\\\n\/\\n\/g'\n<\/code><\/pre>\n\n\n\n<p>You should receive JSON with the greeting.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 5: View logs (basic operations workflow)<\/h3>\n\n\n\n<p>Cloud Run writes stdout\/stderr to Cloud Logging.<\/p>\n\n\n\n<p>Tail logs:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud run services logs tail \"$SERVICE_NAME\" --region \"$REGION\"\n<\/code><\/pre>\n\n\n\n<p>Then hit the endpoint in another tab:<\/p>\n\n\n\n<pre><code class=\"language-bash\">curl -s \"$SERVICE_URL\/?name=LogsTest\" &gt; \/dev\/null\n<\/code><\/pre>\n\n\n\n<p>You should see log entries appear.<\/p>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; Log entries in the tail output (exact format depends on runtime).<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 6: (Optional) Try Cloud Shell Editor for quick edits<\/h3>\n\n\n\n<p>If you want to use <strong>Cloud Shell Editor<\/strong>:\n&#8211; In Cloud Shell, open the editor (from the Cloud Shell UI menu).\n&#8211; Modify the response message in <code>app.py<\/code>.\n&#8211; Redeploy:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud run deploy \"$SERVICE_NAME\" \\\n  --source . \\\n  --region \"$REGION\" \\\n  --allow-unauthenticated\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; New revision deployed; endpoint returns updated message.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Validation<\/h3>\n\n\n\n<p>Run:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud run services describe \"$SERVICE_NAME\" --region \"$REGION\" --format=\"yaml(status.url,status.conditions)\"\ncurl -s \"$SERVICE_URL\/\"\n<\/code><\/pre>\n\n\n\n<p>You have successfully:\n&#8211; used Cloud Shell as your developer\/admin environment,\n&#8211; built and deployed an application to Cloud Run,\n&#8211; validated the endpoint,\n&#8211; accessed operational logs.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Troubleshooting<\/h3>\n\n\n\n<p>Common issues and practical fixes:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong><code>PERMISSION_DENIED<\/code> enabling APIs<\/strong>\n   &#8211; Cause: you lack Service Usage permissions.\n   &#8211; Fix: ask for <code>roles\/serviceusage.serviceUsageAdmin<\/code> or have an admin enable the APIs.<\/p>\n<\/li>\n<li>\n<p><strong>Billing errors \/ \u201cproject has no billing account\u201d<\/strong>\n   &#8211; Cause: project not linked to billing.\n   &#8211; Fix: link billing in Console \u2192 Billing, or use a sandbox project with billing.<\/p>\n<\/li>\n<li>\n<p><strong>Cloud Run deployment fails due to insufficient permissions<\/strong>\n   &#8211; Cause: missing Cloud Run Admin or Service Account User permissions.\n   &#8211; Fix: request <code>roles\/run.admin<\/code> and <code>roles\/iam.serviceAccountUser<\/code> (scope to the correct service account).<\/p>\n<\/li>\n<li>\n<p><strong>Organization Policy blocks public access<\/strong>\n   &#8211; Cause: org constraints may block <code>--allow-unauthenticated<\/code>.\n   &#8211; Fix: deploy without public access and use IAM-based invocation, or request an exception in a sandbox.<\/p>\n<\/li>\n<li>\n<p><strong>Region not supported \/ restricted<\/strong>\n   &#8211; Cause: chosen region not enabled for Cloud Run or blocked by policy.\n   &#8211; Fix: choose an allowed region; check org policy constraints.<\/p>\n<\/li>\n<li>\n<p><strong>Build failures<\/strong>\n   &#8211; Cause: dependency download issues, Python version mismatch, or transient build problems.\n   &#8211; Fix: review Cloud Build logs (link printed in output). Try redeploy; pin dependencies; keep the Dockerfile simple.<\/p>\n<\/li>\n<\/ol>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Cleanup<\/h3>\n\n\n\n<p>To avoid ongoing charges, delete the Cloud Run service:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud run services delete \"$SERVICE_NAME\" --region \"$REGION\"\n<\/code><\/pre>\n\n\n\n<p>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.<\/p>\n\n\n\n<p>List repositories:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud artifacts repositories list --location=\"$REGION\"\n<\/code><\/pre>\n\n\n\n<p>If you identify a repo created for this demo and you\u2019re sure it\u2019s not used elsewhere, delete it:<\/p>\n\n\n\n<pre><code class=\"language-bash\">REPO_NAME=\"REPOSITORY_NAME\"\ngcloud artifacts repositories delete \"$REPO_NAME\" --location=\"$REGION\"\n<\/code><\/pre>\n\n\n\n<p>Also consider deleting build history if your org policy allows (build records themselves are not typically a major cost driver, but stored artifacts are).<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">11. Best Practices<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Architecture best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use Cloud Shell for <strong>interactive workflows<\/strong>, not as part of a production runtime.<\/li>\n<li>For production delivery:<\/li>\n<li>Use CI\/CD (Cloud Build, GitHub Actions, etc.)<\/li>\n<li>Store source in a version control system<\/li>\n<li>Use Artifact Registry for immutable artifacts<\/li>\n<li>Keep a clear separation of environments:<\/li>\n<li><code>dev<\/code> \/ <code>test<\/code> \/ <code>prod<\/code> projects<\/li>\n<li>Different IAM bindings and org policies per environment<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IAM\/security best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Enforce <strong>least privilege<\/strong>:<\/li>\n<li>Avoid granting broad <code>Owner<\/code> roles.<\/li>\n<li>Use task-specific roles (Run Admin, Service Usage Admin, Artifact Registry Reader\/Writer).<\/li>\n<li>Prefer <strong>service account impersonation<\/strong> over downloading service account keys (where feasible and supported by your org).<\/li>\n<li>Require MFA and strong identity policies for users who can deploy or modify production resources.<\/li>\n<li>Use <strong>Organization Policies<\/strong> to restrict risky behaviors (public access, external IPs, allowed regions, etc.), then provide sandbox exceptions when needed.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use sandbox projects with:<\/li>\n<li>Budgets + alerts<\/li>\n<li>Short retention policies for logs in non-prod (where appropriate)<\/li>\n<li>Scheduled cleanup for orphaned artifacts<\/li>\n<li>Delete demo resources (Cloud Run services, Artifact Registry images) immediately after labs.<\/li>\n<li>Avoid large dependency downloads and repeated builds from Cloud Shell; move heavy builds to CI.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Performance best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Don\u2019t benchmark application performance from Cloud Shell.<\/li>\n<li>Use Cloud Shell for control-plane operations and basic app validation only.<\/li>\n<li>For performance tests, use dedicated load testing tools and environments.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Reliability best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Treat Cloud Shell sessions as <strong>ephemeral<\/strong>:<\/li>\n<li>Keep important code in Git.<\/li>\n<li>Use scripts stored in repos, not just in <code>$HOME<\/code>.<\/li>\n<li>Use Cloud Shell as a \u201cknown-good admin terminal\u201d but not the only operational path.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operations best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Before running destructive commands:<\/li>\n<li><code>gcloud config list<\/code> to confirm project\/account<\/li>\n<li>Use <code>--dry-run<\/code> where supported<\/li>\n<li>Standardize operational scripts (runbooks) in Git.<\/li>\n<li>Use Cloud Logging and Audit Logs for traceability rather than relying on terminal history.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Governance\/tagging\/naming best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Adopt naming standards for resources created from Cloud Shell:<\/li>\n<li>Prefix with team\/app\/environment (e.g., <code>payments-api-dev<\/code>)<\/li>\n<li>Use labels\/tags where supported:<\/li>\n<li><code>env=dev<\/code>, <code>owner=team-x<\/code>, <code>cost-center=1234<\/code><\/li>\n<li>Restrict \u201cad-hoc\u201d production changes; prefer change management pipelines.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">12. Security Considerations<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Identity and access model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud Shell access is tied to your <strong>Google identity<\/strong>.<\/li>\n<li>Actions performed in Cloud Shell are authorized by <strong>Cloud IAM<\/strong> just like any other client (local <code>gcloud<\/code>, CI runner, etc.).<\/li>\n<li>Use IAM Conditions and org policies where appropriate to limit when\/where actions can occur.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Encryption<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Google Cloud encrypts data at rest and in transit by default for managed services.  <\/li>\n<li>For Cloud Shell\u2019s persistent home directory and session, rely on Google\u2019s 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.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network exposure<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud Shell is not a typical VM you expose to the internet.<\/li>\n<li>Avoid treating Cloud Shell as a bastion host. For controlled private access, evaluate:<\/li>\n<li>IAP TCP forwarding to bastion VMs<\/li>\n<li>Dedicated admin workstations<\/li>\n<li>Cloud Workstations (managed dev environments)<\/li>\n<li>VPN\/Interconnect patterns<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secrets handling (critical)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Do not store long-lived secrets in:<\/li>\n<li>shell history<\/li>\n<li>plaintext files in <code>$HOME<\/code><\/li>\n<li>Git repos in Cloud Shell<\/li>\n<li>Prefer:<\/li>\n<li><strong>Secret Manager<\/strong> for application secrets<\/li>\n<li>Short-lived tokens<\/li>\n<li>Service account impersonation<\/li>\n<li>Application Default Credentials patterns where appropriate<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Audit\/logging<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Your most important audit trail is:<\/li>\n<li><strong>Cloud Audit Logs<\/strong> for resource changes in target projects<\/li>\n<li><strong>Cloud Logging<\/strong> for runtime logs (Cloud Run\/GKE\/etc.)<\/li>\n<li>In regulated environments, verify:<\/li>\n<li>audit log retention settings,<\/li>\n<li>export to SIEM,<\/li>\n<li>whether Cloud Shell session activity itself has additional logs (often the API calls are what matter).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compliance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud Shell can simplify compliance by reducing unmanaged tooling\u2014<strong>but<\/strong> it still introduces:<\/li>\n<li>browser-based access paths,<\/li>\n<li>file upload\/download capabilities,<\/li>\n<li>persistent user storage.<\/li>\n<li>Ensure your policies cover:<\/li>\n<li>allowed data types in Cloud Shell storage,<\/li>\n<li>access reviews,<\/li>\n<li>DLP requirements,<\/li>\n<li>approved regions (where applicable).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Common security mistakes<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Running production changes from the wrong project because the active project wasn\u2019t checked.<\/li>\n<li>Using <code>--allow-unauthenticated<\/code> by default for services that should be private.<\/li>\n<li>Copying service account keys into Cloud Shell for convenience.<\/li>\n<li>Storing secrets in environment variables and leaving terminals open.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secure deployment recommendations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use separate projects and strict IAM for production.<\/li>\n<li>Require code review and CI\/CD for production deployments.<\/li>\n<li>Enforce org policy constraints to prevent accidental public exposure.<\/li>\n<li>Use budgets\/alerts and audit log exports.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">13. Limitations and Gotchas<\/h2>\n\n\n\n<p>Cloud Shell is intentionally constrained. Plan around these realities:<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Known limitations (practical)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Ephemeral VM session<\/strong>: session can end; background processes are not guaranteed to survive.<\/li>\n<li><strong>Not a server<\/strong>: not intended for hosting production apps or accepting inbound traffic like a normal VM.<\/li>\n<li><strong>Persistent storage is small<\/strong>: <code>$HOME<\/code> has a fixed size limit (commonly 5 GB; verify current limit).<\/li>\n<li><strong>Tool versions can change<\/strong>: the environment is managed by Google; updates may affect scripts that rely on specific versions.<\/li>\n<li><strong>Not a CI runner<\/strong>: don\u2019t use Cloud Shell as your build pipeline.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas and timeouts<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud Shell has usage limits (session duration \/ inactivity timeouts).<br\/>\n  Verify current limits: https:\/\/cloud.google.com\/shell\/docs<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Regional constraints<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Your Cloud Shell environment runs in a supported set of regions (may be selectable). The list can change.<\/li>\n<li>Your organization may restrict regions by policy, affecting where you can deploy resources from your scripts.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing surprises<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud Shell itself may be free, but the resources you create are not:<\/li>\n<li>Artifact Registry images can linger.<\/li>\n<li>Cloud Build can add up with repeated builds.<\/li>\n<li>Cloud Run min instances or heavy traffic can increase cost.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compatibility issues<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Some enterprise environments block Cloud Shell via identity policies, context-aware access, or browser restrictions.<\/li>\n<li>Corporate proxies or restricted egress can impact downloads and dependency installs (if those restrictions apply).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational gotchas<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Wrong project context<\/strong>: always confirm <code>gcloud config get-value project<\/code>.<\/li>\n<li><strong>Wrong account context<\/strong>: check <code>gcloud auth list<\/code>.<\/li>\n<li><strong>Org policy surprises<\/strong>: constraints can block public services, external networking, or certain APIs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Migration challenges<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>If teams rely too heavily on Cloud Shell \u201cstate\u201d (files in <code>$HOME<\/code>), it becomes a hidden dependency.<\/li>\n<li>Mitigate by keeping scripts and configuration in Git and using reproducible tooling (containers\/devcontainers\/IaC).<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">14. Comparison with Alternatives<\/h2>\n\n\n\n<p>Cloud Shell is one of several ways to get a CLI + tooling environment.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Option<\/th>\n<th>Best For<\/th>\n<th>Strengths<\/th>\n<th>Weaknesses<\/th>\n<th>When to Choose<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>Google Cloud Shell<\/strong><\/td>\n<td>Quick interactive CLI, lightweight dev, troubleshooting<\/td>\n<td>No local install; authenticated; persistent home directory; integrated with Console<\/td>\n<td>Ephemeral; limited storage; not for heavy builds or long-running workloads<\/td>\n<td>Onboarding, labs, ad-hoc admin tasks, quick deploys<\/td>\n<\/tr>\n<tr>\n<td><strong>Cloud Shell Editor<\/strong><\/td>\n<td>Small code edits + terminal in browser<\/td>\n<td>Integrated editing + terminal<\/td>\n<td>Not a full IDE for large projects<\/td>\n<td>Quick patches, tutorials, lightweight app work<\/td>\n<\/tr>\n<tr>\n<td><strong>Cloud Workstations (Google Cloud)<\/strong><\/td>\n<td>Managed full dev environments<\/td>\n<td>More customizable, policy-controlled, scalable dev environments<\/td>\n<td>More setup and cost than Cloud Shell<\/td>\n<td>Standardized enterprise developer workstations<\/td>\n<\/tr>\n<tr>\n<td><strong>Local workstation + Google Cloud CLI<\/strong><\/td>\n<td>Daily development, advanced tooling<\/td>\n<td>Full control, offline work, best IDE support<\/td>\n<td>Tooling drift; credential management; setup time<\/td>\n<td>Primary dev workflow when local installs are allowed<\/td>\n<\/tr>\n<tr>\n<td><strong>Compute Engine VM (bastion\/admin VM)<\/strong><\/td>\n<td>Controlled admin access to private resources<\/td>\n<td>Stable environment; can be hardened and monitored<\/td>\n<td>You manage patching, access, hardening<\/td>\n<td>When you need a true bastion with private network access<\/td>\n<\/tr>\n<tr>\n<td><strong>CI\/CD runner (Cloud Build\/GitHub Actions)<\/strong><\/td>\n<td>Repeatable builds and deployments<\/td>\n<td>Auditable pipelines; automation; consistency<\/td>\n<td>Not interactive; requires pipeline setup<\/td>\n<td>Production deployments, repeatable releases<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS CloudShell<\/strong><\/td>\n<td>AWS users needing browser shell<\/td>\n<td>Similar \u201cshell in console\u201d concept<\/td>\n<td>Different IAM\/auth model; not Google Cloud<\/td>\n<td>Multi-cloud teams per-cloud console shell needs<\/td>\n<\/tr>\n<tr>\n<td><strong>Azure Cloud Shell<\/strong><\/td>\n<td>Azure users needing browser shell<\/td>\n<td>Similar concept<\/td>\n<td>Different auth and service integration<\/td>\n<td>Azure-centric orgs<\/td>\n<\/tr>\n<tr>\n<td><strong>GitHub Codespaces \/ devcontainers<\/strong><\/td>\n<td>Cloud-based dev with full IDE<\/td>\n<td>Strong dev UX, reproducible containers<\/td>\n<td>Separate identity\/governance model; cost<\/td>\n<td>When you want IDE-first cloud dev environments<\/td>\n<\/tr>\n<tr>\n<td><strong>Self-managed jump host + SSH<\/strong><\/td>\n<td>Custom networks and strict controls<\/td>\n<td>Highly customizable<\/td>\n<td>Highest ops burden<\/td>\n<td>When compliance requires maximum control<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">15. Real-World Example<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Enterprise example: regulated platform team standardizes admin access<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A financial services company wants to reduce local credential sprawl and standardize how engineers run operational tasks across many Google Cloud projects.<\/li>\n<li><strong>Proposed architecture:<\/strong><\/li>\n<li>Developers\/SREs use <strong>Cloud Shell<\/strong> for interactive tasks (read-only troubleshooting, log inspection, approved admin scripts).<\/li>\n<li>Production changes are executed via <strong>CI\/CD<\/strong> (Cloud Build) with approvals.<\/li>\n<li>Strict <strong>IAM roles<\/strong>, <strong>MFA<\/strong>, and <strong>Organization Policies<\/strong> enforce guardrails (restricted regions, restrictions on unauthenticated invocations, controlled API enablement).<\/li>\n<li><strong>Audit Logs<\/strong> exported to a SIEM for investigation and compliance evidence.<\/li>\n<li><strong>Why Cloud Shell was chosen:<\/strong><\/li>\n<li>No local tool installation required; consistent environment.<\/li>\n<li>Authentication tied to enterprise identity controls.<\/li>\n<li>Quick access during incidents without relying on a specific laptop build.<\/li>\n<li><strong>Expected outcomes:<\/strong><\/li>\n<li>Faster incident response and reduced workstation setup time.<\/li>\n<li>Clearer auditability for administrative actions (via standard API audit trails).<\/li>\n<li>Reduced risk of leaked local credentials.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Startup\/small-team example: fast iteration for Cloud Run deployments<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> 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.<\/li>\n<li><strong>Proposed architecture:<\/strong><\/li>\n<li>Developers use <strong>Cloud Shell + Cloud Shell Editor<\/strong> for quick experiments and deployments to a dev project.<\/li>\n<li>Main branch deployments go through a lightweight CI pipeline.<\/li>\n<li>Artifact Registry stores images; Cloud Logging provides diagnostics.<\/li>\n<li><strong>Why Cloud Shell was chosen:<\/strong><\/li>\n<li>Zero setup; new hires can deploy on day one.<\/li>\n<li>Convenient for demos and quick tests.<\/li>\n<li><strong>Expected outcomes:<\/strong><\/li>\n<li>Reduced onboarding time.<\/li>\n<li>Faster prototypes and fewer environment setup issues.<\/li>\n<li>Cleaner separation between interactive dev and production CI.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">16. FAQ<\/h2>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>Is Cloud Shell free?<\/strong><br\/>\n   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<\/p>\n<\/li>\n<li>\n<p><strong>Does Cloud Shell run in my project?<\/strong><br\/>\n   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\u2014rely on official documentation for specifics.<\/p>\n<\/li>\n<li>\n<p><strong>What persists between sessions?<\/strong><br\/>\n   Your home directory (<code>$HOME<\/code>) persists up to a documented storage limit (commonly 5 GB). The VM session itself is ephemeral.<\/p>\n<\/li>\n<li>\n<p><strong>Can I use Cloud Shell as a production server?<\/strong><br\/>\n   No. Cloud Shell is designed for interactive use, not for hosting production workloads.<\/p>\n<\/li>\n<li>\n<p><strong>How does Cloud Shell authenticate to Google Cloud?<\/strong><br\/>\n   It uses your logged-in Google identity and IAM permissions. Commands you run are authorized as your user (unless you explicitly impersonate another identity).<\/p>\n<\/li>\n<li>\n<p><strong>Can I use service accounts from Cloud Shell?<\/strong><br\/>\n   Yes, but avoid downloading long-lived service account keys. Prefer service account impersonation and short-lived credentials where possible (verify your org\u2019s best practices).<\/p>\n<\/li>\n<li>\n<p><strong>Does Cloud Shell support Kubernetes (<code>kubectl<\/code>)?<\/strong><br\/>\n   Typically yes, and it\u2019s commonly used with GKE. You still must fetch cluster credentials and have IAM permissions.<\/p>\n<\/li>\n<li>\n<p><strong>Can I choose the region for Cloud Shell?<\/strong><br\/>\n   Often you can select a region for the Cloud Shell environment in settings, but availability can change. Verify in the Cloud Shell docs.<\/p>\n<\/li>\n<li>\n<p><strong>Is Cloud Shell suitable for Infrastructure as Code (Terraform)?<\/strong><br\/>\n   It\u2019s suitable for interactive Terraform use in sandbox environments. For production, run Terraform in controlled pipelines with state management and reviews.<\/p>\n<\/li>\n<li>\n<p><strong>How do I avoid deploying into the wrong project?<\/strong><br\/>\n   Always check:\n   &#8211; <code>gcloud config get-value project<\/code>\n   &#8211; <code>gcloud auth list<\/code>\n   Consider using separate browser profiles for prod vs dev.<\/p>\n<\/li>\n<li>\n<p><strong>Can Cloud Shell access private resources in my VPC?<\/strong><br\/>\n   It depends on how those resources are exposed and your org\u2019s network controls. Don\u2019t assume Cloud Shell is inside your VPC like a bastion VM. Verify connectivity requirements and use bastion\/IAP\/VPN patterns when needed.<\/p>\n<\/li>\n<li>\n<p><strong>What is Cloud Shell Editor?<\/strong><br\/>\n   A web-based editor integrated with Cloud Shell for lightweight development. It\u2019s useful for small projects and tutorials.<\/p>\n<\/li>\n<li>\n<p><strong>Are actions from Cloud Shell audited?<\/strong><br\/>\n   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.<\/p>\n<\/li>\n<li>\n<p><strong>Can I install additional packages?<\/strong><br\/>\n   You can usually install packages in-session, but remember the session is ephemeral. Persist important setup steps in scripts or containerized workflows.<\/p>\n<\/li>\n<li>\n<p><strong>What should I store in the Cloud Shell home directory?<\/strong><br\/>\n   Store non-sensitive scripts and repos as needed, but avoid secrets and treat it as convenience storage, not a long-term backup.<\/p>\n<\/li>\n<li>\n<p><strong>How does Cloud Shell help application development?<\/strong><br\/>\n   It reduces setup time for build\/deploy\/test loops\u2014especially for serverless and container workflows like Cloud Run and GKE administration.<\/p>\n<\/li>\n<li>\n<p><strong>Is Cloud Shell a replacement for Cloud Build?<\/strong><br\/>\n   No. Cloud Build is for automated builds; Cloud Shell is for interactive work. Use Cloud Build (or other CI) for repeatable, auditable pipelines.<\/p>\n<\/li>\n<\/ol>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">17. Top Online Resources to Learn Cloud Shell<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Resource Type<\/th>\n<th>Name<\/th>\n<th>Why It Is Useful<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Official documentation<\/td>\n<td>Cloud Shell docs \u2014 https:\/\/cloud.google.com\/shell\/docs<\/td>\n<td>Authoritative feature descriptions, limits, and how-to guides<\/td>\n<\/tr>\n<tr>\n<td>Official quickstart \/ getting started<\/td>\n<td>Start Cloud Shell \u2014 https:\/\/cloud.google.com\/shell\/docs\/starting-cloud-shell<\/td>\n<td>Step-by-step entry into Cloud Shell and basic usage<\/td>\n<\/tr>\n<tr>\n<td>Official reference<\/td>\n<td>Google Cloud CLI (<code>gcloud<\/code>) docs \u2014 https:\/\/cloud.google.com\/sdk\/gcloud<\/td>\n<td>Core CLI reference used heavily in Cloud Shell<\/td>\n<\/tr>\n<tr>\n<td>Official product pricing<\/td>\n<td>Cloud Run pricing \u2014 https:\/\/cloud.google.com\/run\/pricing<\/td>\n<td>If you deploy from Cloud Shell, Cloud Run is a common billing driver<\/td>\n<\/tr>\n<tr>\n<td>Official product pricing<\/td>\n<td>Cloud Build pricing \u2014 https:\/\/cloud.google.com\/build\/pricing<\/td>\n<td>Builds triggered from Cloud Shell (e.g., <code>--source<\/code>) may use Cloud Build<\/td>\n<\/tr>\n<tr>\n<td>Official product pricing<\/td>\n<td>Artifact Registry pricing \u2014 https:\/\/cloud.google.com\/artifact-registry\/pricing<\/td>\n<td>Container images built from Cloud Shell are commonly stored here<\/td>\n<\/tr>\n<tr>\n<td>Pricing tool<\/td>\n<td>Google Cloud Pricing Calculator \u2014 https:\/\/cloud.google.com\/products\/calculator<\/td>\n<td>Estimate costs for resources you create while using Cloud Shell<\/td>\n<\/tr>\n<tr>\n<td>Architecture guidance<\/td>\n<td>Google Cloud Architecture Center \u2014 https:\/\/cloud.google.com\/architecture<\/td>\n<td>Patterns that Cloud Shell users often implement (CI\/CD, serverless, IAM)<\/td>\n<\/tr>\n<tr>\n<td>Hands-on labs<\/td>\n<td>Google Cloud Skills Boost \u2014 https:\/\/www.cloudskillsboost.google<\/td>\n<td>Curated labs often using Cloud Shell for consistent student environments<\/td>\n<\/tr>\n<tr>\n<td>Official videos<\/td>\n<td>Google Cloud Tech YouTube \u2014 https:\/\/www.youtube.com\/@googlecloudtech<\/td>\n<td>Product walkthroughs and practical demos (search \u201cCloud Shell\u201d)<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">18. Training and Certification Providers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Institute<\/th>\n<th>Suitable Audience<\/th>\n<th>Likely Learning Focus<\/th>\n<th>Mode<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps engineers, SREs, platform teams, developers<\/td>\n<td>DevOps practices, CI\/CD, cloud operations (including Google Cloud tooling)<\/td>\n<td>check website<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>ScmGalaxy.com<\/td>\n<td>Beginners to intermediate engineers<\/td>\n<td>SCM, DevOps fundamentals, tooling and process<\/td>\n<td>check website<\/td>\n<td>https:\/\/www.scmgalaxy.com\/<\/td>\n<\/tr>\n<tr>\n<td>CLoudOpsNow.in<\/td>\n<td>Cloud engineers, operations teams<\/td>\n<td>Cloud operations, monitoring, governance, cost awareness<\/td>\n<td>check website<\/td>\n<td>https:\/\/www.cloudopsnow.in\/<\/td>\n<\/tr>\n<tr>\n<td>SreSchool.com<\/td>\n<td>SREs, reliability engineers, operations<\/td>\n<td>SRE practices, incident response, reliability patterns<\/td>\n<td>check website<\/td>\n<td>https:\/\/www.sreschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>AiOpsSchool.com<\/td>\n<td>Ops teams exploring AIOps<\/td>\n<td>AIOps concepts, automation, observability<\/td>\n<td>check website<\/td>\n<td>https:\/\/www.aiopsschool.com\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">19. Top Trainers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Platform\/Site<\/th>\n<th>Likely Specialization<\/th>\n<th>Suitable Audience<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>RajeshKumar.xyz<\/td>\n<td>DevOps\/cloud training resources (verify offerings)<\/td>\n<td>Engineers seeking guided training and mentorship<\/td>\n<td>https:\/\/rajeshkumar.xyz\/<\/td>\n<\/tr>\n<tr>\n<td>devopstrainer.in<\/td>\n<td>DevOps training (verify course catalog)<\/td>\n<td>Beginners to intermediate DevOps practitioners<\/td>\n<td>https:\/\/www.devopstrainer.in\/<\/td>\n<\/tr>\n<tr>\n<td>devopsfreelancer.com<\/td>\n<td>Freelance DevOps support\/training platform (verify services)<\/td>\n<td>Teams needing short-term expertise<\/td>\n<td>https:\/\/www.devopsfreelancer.com\/<\/td>\n<\/tr>\n<tr>\n<td>devopssupport.in<\/td>\n<td>DevOps support and training resources (verify offerings)<\/td>\n<td>Ops\/DevOps teams needing practical assistance<\/td>\n<td>https:\/\/www.devopssupport.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">20. Top Consulting Companies<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Company<\/th>\n<th>Likely Service Area<\/th>\n<th>Where They May Help<\/th>\n<th>Consulting Use Case Examples<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>cotocus.com<\/td>\n<td>Cloud\/DevOps consulting (verify exact portfolio)<\/td>\n<td>Cloud adoption, DevOps implementation, operational readiness<\/td>\n<td>CI\/CD design, IAM governance guidance, deployment standardization<\/td>\n<td>https:\/\/cotocus.com\/<\/td>\n<\/tr>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps consulting and enablement<\/td>\n<td>Training + advisory for DevOps processes and tooling<\/td>\n<td>DevOps maturity assessment, pipeline implementation, platform enablement<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>DEVOPSCONSULTING.IN<\/td>\n<td>DevOps consulting (verify exact portfolio)<\/td>\n<td>Delivery pipelines, automation, monitoring, operational workflows<\/td>\n<td>Build\/release automation, observability setup, operational runbooks<\/td>\n<td>https:\/\/www.devopsconsulting.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">21. Career and Learning Roadmap<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn before Cloud Shell<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Google Cloud fundamentals:<\/li>\n<li>Projects, billing, IAM, service accounts<\/li>\n<li>Regions\/zones basics<\/li>\n<li>CLI basics:<\/li>\n<li>Shell commands, environment variables, basic scripting<\/li>\n<li>Networking and security basics:<\/li>\n<li>Public vs private access concepts<\/li>\n<li>Principle of least privilege<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn after Cloud Shell<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Cloud Run<\/strong> deployment patterns, IAM-based invocation, revisions\/rollbacks<\/li>\n<li><strong>Cloud Build<\/strong> pipelines and build triggers<\/li>\n<li><strong>Artifact Registry<\/strong> hygiene (cleanup policies, vulnerability scanning integrations\u2014verify features)<\/li>\n<li><strong>Infrastructure as Code<\/strong>:<\/li>\n<li>Terraform (and remote state patterns)<\/li>\n<li>Policy as code (where applicable)<\/li>\n<li><strong>Observability<\/strong>:<\/li>\n<li>Cloud Logging queries<\/li>\n<li>Cloud Monitoring dashboards and alerting<\/li>\n<li><strong>Security governance<\/strong>:<\/li>\n<li>Organization Policies<\/li>\n<li>IAM Conditions<\/li>\n<li>Audit log exports<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Job roles that use Cloud Shell<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud Engineer<\/li>\n<li>DevOps Engineer<\/li>\n<li>Site Reliability Engineer (SRE)<\/li>\n<li>Platform Engineer<\/li>\n<li>Security Engineer (cloud operations\/security posture)<\/li>\n<li>Application Developer (cloud-native)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Certification path (if available)<\/h3>\n\n\n\n<p>Cloud Shell itself is not a certification topic alone, but it supports workflows needed for Google Cloud certifications:\n&#8211; Associate Cloud Engineer\n&#8211; Professional Cloud Developer\n&#8211; Professional Cloud DevOps Engineer\n&#8211; Professional Cloud Architect<br\/>\nVerify current certification tracks: https:\/\/cloud.google.com\/learn\/certification<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Project ideas for practice<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Build and deploy a Cloud Run service from Cloud Shell, then:<\/li>\n<li>add CI trigger (Cloud Build or GitHub Actions)<\/li>\n<li>add Secret Manager integration<\/li>\n<li>add structured logging and log-based metrics<\/li>\n<li>Write a Cloud Shell script to inventory resources in a project and export to CSV.<\/li>\n<li>Create a \u201cgolden runbook\u201d repo with standardized operational commands and safe checks.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">22. Glossary<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Cloud Shell:<\/strong> Google Cloud\u2019s browser-based terminal environment with preinstalled tooling and authenticated access.<\/li>\n<li><strong>Cloud Shell Editor:<\/strong> A browser-based editor integrated with Cloud Shell for lightweight development and file editing.<\/li>\n<li><strong><code>gcloud<\/code>:<\/strong> The Google Cloud CLI used to manage Google Cloud resources.<\/li>\n<li><strong>IAM (Identity and Access Management):<\/strong> Google Cloud\u2019s authorization system for who can do what on which resources.<\/li>\n<li><strong>Project:<\/strong> A Google Cloud container for resources, billing, IAM policies, and APIs.<\/li>\n<li><strong>API enablement:<\/strong> Turning on a Google Cloud API for a project so resources can be created\/managed.<\/li>\n<li><strong>Cloud Run:<\/strong> Google Cloud\u2019s serverless container platform.<\/li>\n<li><strong>Cloud Build:<\/strong> A managed build service often used to build container images and run CI steps.<\/li>\n<li><strong>Artifact Registry:<\/strong> Google Cloud service for storing container images and artifacts.<\/li>\n<li><strong>Audit Logs:<\/strong> Logs that record administrative and data access actions on Google Cloud resources (service-dependent).<\/li>\n<li><strong>Region:<\/strong> A geographic area where Google Cloud resources can run (e.g., <code>us-central1<\/code>).<\/li>\n<li><strong>Revision (Cloud Run):<\/strong> An immutable version of a Cloud Run service created on each deployment.<\/li>\n<li><strong>Least privilege:<\/strong> Security principle of granting only the minimum permissions needed.<\/li>\n<li><strong>Organization Policy:<\/strong> Guardrails applied at the organization\/folder\/project level to constrain allowed configurations and actions.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">23. Summary<\/h2>\n\n\n\n<p>Cloud Shell is Google Cloud\u2019s managed, browser-based terminal (and optional editor) designed for fast, authenticated access to cloud tooling\u2014especially useful in <strong>Application development<\/strong> workflows for deploying, troubleshooting, and administering services.<\/p>\n\n\n\n<p>It matters because it:\n&#8211; eliminates local setup and reduces onboarding time,\n&#8211; standardizes a baseline CLI environment for teams,\n&#8211; integrates with Google identity and Cloud IAM for controlled access.<\/p>\n\n\n\n<p>Cost-wise, Cloud Shell itself is generally free with limits, but it can easily create <strong>billable downstream usage<\/strong> (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.<\/p>\n\n\n\n<p>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.<\/p>\n\n\n\n<p><strong>Next learning step:<\/strong> 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.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Application development<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[54,51],"tags":[],"class_list":["post-600","post","type-post","status-publish","format-standard","hentry","category-application-development","category-google-cloud"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/600","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/comments?post=600"}],"version-history":[{"count":0,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/600\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=600"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=600"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=600"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}