Two GKE concepts that look small but get tested often on the Professional Cloud Architect exam are versioned container images and namespaces. Both are about discipline. Versioning gives you predictable rollouts and rollbacks. Namespaces give you logical separation inside one cluster. Get them right and the rest of your GKE setup becomes much easier to reason about.
The rule I follow is to tag every container image with a specific version like v1.0.0, v1.0.1, v1.0.2. Push those into Artifact Registry. Then deploy the exact tag your manifest references. The "latest" tag is a moving target and it makes deployments unpredictable, so I avoid it.
The other half of this practice is immutability. Once an image with a given tag is published, do not modify it. If something needs to change, build a new version. That way the tag in your manifest always points to the same bytes, and rollback is as simple as redeploying an older tag. The Professional Cloud Architect exam likes this pattern because it ties directly to consistency, reliability, and disaster recovery.
Versioned images give you flexibility inside a single cluster. One node can run pods on v1.0.0 for stability while another node runs v1.0.2 for testing. A third node might have a mix. This is how teams roll out updates incrementally and validate new versions against real traffic without taking the whole service down.
If you ever need to pull back a release, you redeploy the prior tag. No rebuilding, no guesswork about which commit produced which artifact. The image registry is the source of truth.
Namespaces let you logically divide and isolate resources inside one cluster. The classic use case is environment separation: a prod namespace, a test namespace, a dev namespace, all sharing the same underlying nodes. Each pod gets assigned to a namespace through the namespace field in the Kubernetes manifest.
Why share a cluster across environments at all? Resource efficiency. You do not have to pay for three separate control planes and three separate node pools to keep dev, test, and prod apart. Namespaces give you the isolation boundaries (for resource quotas, RBAC, network policies) without the cost of running multiple clusters.
Versioned images and namespaces show up together because they are both about reducing risk inside GKE. Use specific tags, treat published images as immutable, and lean on namespaces to separate prod from non-prod. If a Professional Cloud Architect question asks how to safely roll out a new container build or how to host multiple environments on one cluster, those two patterns are the answer.
My Professional Cloud Architect course covers GKE versioning and namespaces alongside the rest of the containers and serverless material.
