Cloud Storage is mostly known as object storage for files, backups, and analytics inputs, but it also doubles as a static website host. For the Professional Cloud Architect exam, you need to recognize when this option is the right architecture and what configuration steps make it work. I cover the essentials here.
A static website is fixed content. HTML files, CSS stylesheets, JavaScript bundles, images, fonts. Nothing on the server side renders or computes a response. The browser requests a file, Cloud Storage returns the bytes, and the browser handles the rest.
That constraint is the whole point. If your site is a single-page application, a marketing page, documentation, or a build artifact from a static site generator, Cloud Storage can serve it directly. If you need server-side rendering, database queries, or authentication logic at request time, this is not the right tool and you would reach for App Engine, Cloud Run, or a Compute Engine backend instead.
When a user loads the page, the browser asks for the HTML file. Cloud Storage returns it. The HTML references CSS and JavaScript files, which trigger more requests, and Cloud Storage returns each one. Every asset is a public object read. There is no compute layer in between.
This makes the model cheap and highly scalable. You pay for storage and egress, not for idle servers. Adding Cloud CDN in front of the bucket reduces egress costs further and improves latency for users far from the bucket region.
Two pieces of configuration matter for the Professional Cloud Architect exam.
The first is access. By default, Cloud Storage objects are private. To serve a public site, you either make the bucket itself public or grant the Storage Object Viewer role to allUsers. That principal is the special identifier for any unauthenticated request, which is exactly what a browser hitting your homepage looks like.
The second is metadata. Each object stored in Cloud Storage carries metadata, and the Content-Type header tells the browser how to handle the file. If you upload an MP3 and leave the content type unset or wrong, the browser may prompt the user to download the file instead of playing it inline. Setting Content-Type: audio/mpeg tells the browser to stream it. The same applies to setting text/html for HTML files, text/css for stylesheets, and so on. Most upload tools set this automatically based on the file extension, but it is worth knowing you can override it.
A typical setup looks like this:
gsutil mb -l us-central1 gs://my-static-site
gsutil iam ch allUsers:objectViewer gs://my-static-site
gsutil -m cp -r ./build/* gs://my-static-site
The first command creates the bucket. The second grants allUsers the object viewer role so anyone can read objects. The third uploads the built site. After that, files are reachable at https://storage.googleapis.com/my-static-site/index.html.
For a production site, you would also configure the bucket as a website (so requests for a directory return index.html automatically), put Cloud CDN in front of it, and serve traffic on a custom domain through a global external HTTP(S) load balancer with a managed SSL certificate.
The Professional Cloud Architect exam tests whether you can match a workload to the cheapest, simplest GCP service that satisfies the requirements. When the prompt describes a website with no dynamic backend, no user-specific rendering, and no need for server-side processing, Cloud Storage is the answer. Reaching for App Engine or Compute Engine in that scenario is over-architecting, which costs the candidate points.
The two configuration details to remember are the allUsers grant for public access and the Content-Type metadata for browser behavior. Both turn up in scenario questions where the symptom (files prompt a download instead of rendering, or visitors get a 403 error) points back to one of these settings.
My Professional Cloud Architect course covers hosting static websites on Cloud Storage alongside the rest of the storage and analytics material.
