The correct answer is Anyone with access to etcd or to the cluster can read or alter the Secrets stored there.

This is correct because Kubernetes writes Secret objects to the API server backing datastore etcd in plaintext by default. That means anyone who can access etcd directly or who can access the cluster control plane or backups can read the Secret values and can also alter them if they have write access.

To mitigate this risk you enable encryption at rest for Secrets using the API server EncryptionConfiguration and you can use a key management service to protect the encryption keys. Using a KMS helps protect keys but the underlying risk arises from unencrypted data in etcd, so enabling encryption and controlling access to etcd and backups is important. You can use services such as Cloud KMS as part of a mitigation strategy.

Secrets are encrypted automatically when they are written to etcd is wrong because encryption at rest is not enabled by default and must be explicitly configured on the API server.

Cloud KMS is wrong as a choice for the security risk because it is a tool for managing encryption keys and not the vulnerability itself. It can be used to reduce the risk when properly integrated but it does not describe the risk of unencrypted Secrets in etcd.

Only cluster administrators can access Secrets stored in etcd is wrong because access is not limited to cluster admins. Anyone with access to etcd, the control plane, node snapshots, or backups can potentially read or modify Secrets if proper protections are not in place.

Full AWS Practitioner Certification Question