A developer accidentally committed a Kubernetes Secret manifest to a public Git repository. The Secret contains a production API key. The team needs to remediate the exposure. Which action should be taken FIRST?

Delete the Secret from the repository and assume the key is safe.

Rotate the API key immediately and then delete the Secret from the repository.

Change the Secret type to kubernetes.io/tls to hide the data.

Enable encryption at rest for etcd to protect the key.

A security team wants to ensure that Secrets are not exposed in logs. They have enabled encryption at rest and restricted RBAC. Which additional measure should they implement to prevent Secrets from appearing in audit logs?

Use a Secret type that is not logged.

Store Secrets in a separate etcd cluster.

Disable audit logging for the cluster.

Configure the audit policy to redact Secret data in request and response objects.

A security policy requires that Secrets be encrypted at rest in etcd. The cluster is already running with the default configuration. What must be done to enable encryption at rest?

Set the environment variable ENCRYPT_SECRETS=true on all nodes.

Create an EncryptionConfiguration file, configure the kube-apiserver to use it, and restart the API server.

Use a Secret type that is automatically encrypted.

Enable encryption at rest in the etcd configuration file.

Which of the following is a recommended way to restrict access to Secrets in a Kubernetes cluster?

Grant all users cluster-admin access so they can manage Secrets.

Use RBAC to grant specific users or ServiceAccounts only the permissions they need.

Disable RBAC entirely to simplify access management.

Store Secrets in a public GitHub repository for easy sharing.

What is the primary difference between a Kubernetes Secret and a ConfigMap?

Secrets are for sensitive data and ConfigMaps are for non-sensitive configuration data.

Secrets are stored in etcd encrypted by default, while ConfigMaps are not.

ConfigMaps are namespaced, while Secrets are cluster-scoped.

Secrets can only be used as environment variables, while ConfigMaps can be mounted as volumes.

Kubernetes and Cloud Native Security Associate (KCSA)

Domain 3Objective 4

Data Protection KCSA Practice Questions (Page 1)

Part of the Kubernetes Security Fundamentals domain, which accounts for 22% of the KCSA exam. Linux Foundation does not publish an official question count, but from its 90-minute exam (~35–60 total, ~8–13 in this domain), expect 1–2 from this objective — we provide 14 practice questions to prepare you well beyond it. (estimate)

14questions here

3free pages

5concepts

22%of the exam

Questions 1–5

1application · medium
A developer accidentally committed a Kubernetes Secret manifest to a public Git repository. The Secret contains a production API key. The team needs to remediate the exposure. Which action should be taken FIRST?
Select an answer first
2expert · hard
A security team wants to ensure that Secrets are not exposed in logs. They have enabled encryption at rest and restricted RBAC. Which additional measure should they implement to prevent Secrets from appearing in audit logs?
Select an answer first
3application · medium
A security policy requires that Secrets be encrypted at rest in etcd. The cluster is already running with the default configuration. What must be done to enable encryption at rest?
Select an answer first
4foundation · easy
Which of the following is a recommended way to restrict access to Secrets in a Kubernetes cluster?
Select an answer first
5foundation · easy
What is the primary difference between a Kubernetes Secret and a ConfigMap?
Select an answer first

Finished these 5 questions?

Review the revealed explanations, or continue through the curriculum.

Next 5 questions →Back to KCSA

Free Basic Practice is a study aid with revealable answers — not a scored exam. Examers.io is independent and not affiliated with or endorsed by Linux Foundation. “KCSA” is a trademark of its owner, used for identification only.