Kubernetes Secrets are the standard way to store sensitive configuration data inside a GKE cluster. Passwords, API keys, OAuth tokens, SSH keys. This article covers what Secrets are, how they differ from ConfigMaps, the often-misunderstood base64 encoding caveat, and how the Associate Cloud Engineer exam tests this.
It does not cover every Secret type, every encryption-at-rest configuration option, or how to fully integrate with external secret managers in detail. The goal is the ACE exam version, which focuses on what Secrets are and where their guarantees end.
A Secret is a Kubernetes object that holds key-value pairs of sensitive data. The cluster stores Secrets in etcd, the Kubernetes data store. Pods can consume Secrets in a few ways: as environment variables, as files mounted into a volume, or by being pulled programmatically through the Kubernetes API.
The typical workflow is straightforward. A user creates a Secret containing some piece of sensitive data, like a database password. The Secret lives in the cluster. When a pod is scheduled, Kubernetes makes the Secret available to the pod through whichever mechanism the pod's spec requests. The application inside the pod uses the Secret to access the actual external service, like a database or an external API.
Importantly, Secrets are a Kubernetes feature, not a GKE feature. They work the same way on GKE as on any other Kubernetes distribution.
This comparison comes up on the ACE exam.
A ConfigMap stores non-sensitive configuration data. Things like a feature flag, a public hostname, an environment name. ConfigMaps are not encrypted at rest by default and are not treated specially in any way.
A Secret stores sensitive data. Things like a password, an API key, a private certificate. Secrets are treated specially: they can be encrypted at rest in etcd, access can be more tightly controlled through RBAC, and operators tend to be more careful with how they handle them.
The decision rule is simple. If exposing the value would be embarrassing or harmful, use a Secret. If it would not, a ConfigMap is fine.
This trips people up, and the exam knows it.
Secret values are stored base64-encoded in the Kubernetes API. When you create a Secret, the YAML often looks like this:
apiVersion: v1
kind: Secret
metadata:
name: db-credentials
type: Opaque
data:
password: c3VwZXJzZWNyZXQ=That string c3VwZXJzZWNyZXQ= is base64 for "supersecret." Anyone who can read the YAML can decode it instantly. base64 is not encryption. It is just an encoding scheme to handle binary data in text-based formats.
The actual security of a Secret comes from a few other places. Access control: only users and pods with the right RBAC permissions can read the Secret. Encryption at rest: GKE supports encrypting Secrets in etcd using application-layer encryption, so the data on disk is not just base64 but actually encrypted. Network security: in GKE, the API server's traffic is encrypted in transit.
If you see a question that suggests "Kubernetes Secrets are stored encrypted by default," that is wrong. They are stored base64-encoded by default, which is not encryption. The encryption-at-rest configuration is a separate feature you have to enable.
There are two main delivery mechanisms.
The first is environment variables. You reference a Secret in your pod's container spec, and the value gets exposed as an environment variable inside the container. Convenient, but environment variables can leak through process listings and crash dumps.
The second is volume mounts. You mount the Secret as a file into a directory in the container. The application reads the file when it needs the value. This is generally more secure because it avoids the environment variable leak vectors, but the application has to know to read from a file.
For the ACE exam, the important thing is to know both mechanisms exist. The exam does not usually test the security trade-offs between them.
For GCP-hosted workloads, an alternative pattern is to keep the actual secret material out of Kubernetes entirely and use Google Secret Manager instead. Secret Manager is a separate GCP service for storing secrets, with audit logging, IAM-based access, and versioning.
The pattern is to give your GKE workload an identity (using Workload Identity), grant that identity access to specific secrets in Secret Manager, and have the application pull secrets at runtime. This keeps secret material out of Kubernetes Secrets entirely and benefits from Secret Manager's stronger access controls and audit story.
For the ACE exam, this pattern shows up occasionally as the right answer when a question emphasizes audit logging, central secret rotation, or non-Kubernetes consumers of the same secret. Kubernetes Secrets are still the answer for cluster-internal sensitive config when the question is generic.
A few patterns come up.
The first is Secrets vs ConfigMaps. The scenario describes a configuration value and asks where to store it. Database password: Secret. API key: Secret. Public service URL: ConfigMap. Feature flag: ConfigMap. The trigger is whether the value is sensitive.
The second is the base64 question. The scenario describes someone surprised that they can decode a Secret value or that Secrets are not "encrypted." The answer is that Secrets are base64-encoded, not encrypted by default, and that proper protection comes from RBAC, encryption at rest, and external solutions like Secret Manager.
The third is the Secret Manager integration question. The scenario describes a need for centralized secret management, audit logging, or use of the same secret outside Kubernetes. The answer is Secret Manager, often in combination with Workload Identity for in-cluster access.
If you see "sensitive data in Kubernetes" in a question, think Secret. If you see "encrypted by default," that is a trap, Secrets are base64-encoded. If you see "audit logging" or "central secret store," think Secret Manager.
Kubernetes Secrets store sensitive configuration data and deliver it to pods as environment variables or mounted files. They are base64-encoded, not encrypted by default. The actual security comes from RBAC and optional encryption at rest, not from the encoding. ConfigMaps are the equivalent for non-sensitive data. Secret Manager is the GCP-native alternative for cases that need stronger audit and central management.
The Associate Cloud Engineer exam tests this through Secrets vs ConfigMaps scenario matching, the base64-vs-encrypted distinction, and occasionally Secret Manager integration questions.
My Associate Cloud Engineer course covers Kubernetes Secrets in the GKE configuration section, alongside ConfigMaps, Secret Manager, and Workload Identity for GCP-native secret access.
