KCSA — Mock Exam — Part 2
Mock Exam — Part 2
This is the second mock exam. It contains 15 new multiple-choice questions covering different topics from Part 1 but following the same domain distribution. Together, Part 1 and Part 2 give you 30 questions — half of a full-length KCSA exam.
Instructions
- Set a timer for 22 minutes (proportional to the real exam)
- Do not look at the answers until you have committed to a choice
- Watch for qualifiers: “BEST”, “PRIMARY”, “NOT”, “MOST likely”, “TRUE”
- Eliminate obviously wrong answers first, then choose from the remaining options
- Complete all 15 questions before reviewing any answers
- Read every explanation — even for questions you answered correctly
If you already completed Part 1, take a break before starting Part 2. Fresh eyes catch more mistakes.
Domain Distribution
| Domain | Weight | Questions in This Mock |
|---|---|---|
| Overview of Cloud Native Security | 14% | 2 (Q1, Q2) |
| Kubernetes Cluster Security | 22% | 3 (Q5, Q6, Q12) |
| Kubernetes Cluster Component Security | 22% | 3 (Q4, Q8, Q11) |
| Kubernetes Security Fundamentals | 16% | 3 (Q7, Q13, Q14) |
| Kubernetes Threat Model | 16% | 2 (Q9, Q10) |
| Compliance and Security Frameworks | 10% | 2 (Q3, Q15) |
Questions
Q1: Shared Responsibility Model
Domain: Overview of Cloud Native Security
A company is running Kubernetes on a managed cloud service (e.g., EKS, GKE, AKS). The security team needs to understand which security controls are their responsibility.
In a managed Kubernetes service, which of the following is typically the CUSTOMER’S responsibility, not the cloud provider’s?
A) Patching the Kubernetes control plane (API server, etcd)
B) Physical security of the data center
C) Configuring RBAC policies and Pod Security Standards
D) Managing the underlying hypervisor and host OS of control plane nodes
Show Answer
Correct Answer: C) Configuring RBAC policies and Pod Security Standards
- A) Patching the Kubernetes control plane — Incorrect. In managed Kubernetes services (EKS, GKE, AKS), the cloud provider manages the control plane, including patching and upgrading the API server, etcd, scheduler, and controller-manager. The customer selects the version; the provider handles the patching.
- B) Physical security of the data center — Incorrect. Physical security is always the cloud provider’s responsibility in any cloud deployment model (IaaS, PaaS, or managed Kubernetes). Customers never have physical access to the data center.
- C) Configuring RBAC policies and Pod Security Standards — Correct. While the cloud provider manages the infrastructure and control plane, the customer is responsible for configuring security policies within the cluster: RBAC (who can do what), Pod Security Standards (what workloads are allowed), Network Policies (traffic rules), and workload-level security contexts. This is the core of the shared responsibility model for managed Kubernetes.
- D) Managing the underlying hypervisor and host OS of control plane nodes — Incorrect. The hypervisor and host OS of control plane nodes are fully managed by the cloud provider. Customers cannot access or modify these components in managed services.
Q2: SBOM Formats
Domain: Overview of Cloud Native Security
A supply chain security initiative requires generating Software Bills of Materials (SBOMs) for all container images deployed to production.
Which of the following are widely recognized SBOM formats?
A) SPDX and CycloneDX
B) Rego and CEL
C) SARIF and JUnit
D) Protobuf and gRPC
Show Answer
Correct Answer: A) SPDX and CycloneDX
- A) SPDX and CycloneDX — Correct. SPDX (Software Package Data Exchange), an ISO/IEC standard maintained by the Linux Foundation, and CycloneDX, an OWASP standard, are the two dominant SBOM formats. They describe the components, licenses, and dependencies in a software artifact. Tools like Trivy, Syft, and Grype can generate and consume SBOMs in these formats.
- B) Rego and CEL — Incorrect. Rego is the policy language used by Open Policy Agent (OPA), and CEL (Common Expression Language) is used for Kubernetes validation rules (ValidatingAdmissionPolicy). These are policy languages, not SBOM formats.
- C) SARIF and JUnit — Incorrect. SARIF (Static Analysis Results Interchange Format) is used for reporting static analysis findings, and JUnit is an XML format for test results. Neither is an SBOM format.
- D) Protobuf and gRPC — Incorrect. Protocol Buffers (Protobuf) is a serialization format, and gRPC is a remote procedure call framework. Both are data exchange technologies developed by Google, not SBOM standards.
Q3: Mutating vs Validating Admission Controllers
Domain: Compliance and Security Frameworks
A Kubernetes administrator is configuring admission controllers to enforce security policies. They want to understand the difference between mutating and validating admission webhooks.
Which statement BEST describes the difference between mutating and validating admission controllers?
A) Mutating controllers run after validating controllers and can change the resource
B) Mutating controllers can modify the resource before it is persisted; validating controllers can only accept or reject
C) Validating controllers modify the resource, while mutating controllers only check if it complies
D) Mutating and validating controllers serve the same purpose and can be used interchangeably
Show Answer
Correct Answer: B) Mutating controllers can modify the resource before it is persisted; validating controllers can only accept or reject
- A) Mutating controllers run after validating controllers — Incorrect. The order is reversed. Mutating admission webhooks run first, then validating admission webhooks run second. This allows mutating webhooks to inject defaults (e.g., adding sidecar containers, setting security contexts) before validating webhooks check the final state of the resource.
- B) Mutating controllers can modify the resource; validating controllers can only accept or reject — Correct. Mutating admission webhooks receive the resource and can return a modified (patched) version. Validating admission webhooks receive the resource and can only return an allow or deny decision — they cannot modify the object. This two-phase design ensures that all mutations happen before validation.
- C) Validating controllers modify, mutating controllers only check — Incorrect. This reverses the definitions. The names are descriptive: “mutating” means to change, “validating” means to verify.
- D) They serve the same purpose and can be used interchangeably — Incorrect. They serve fundamentally different purposes. A mutating webhook that needs to inject a sidecar container cannot be replaced by a validating webhook. A validating webhook that enforces “no privileged containers” makes a binary allow/deny decision that does not require mutation.
Q4: Secrets — Base64 vs Encryption
Domain: Kubernetes Cluster Component Security
A developer creates a Kubernetes Secret using kubectl create secret generic db-password --from-literal=password=MyP@ss123. They check etcd and find the Secret data is readable.
What is the PRIMARY reason the Secret data is readable in etcd by default?
A) Kubernetes Secrets are encrypted with AES-256 by default, but kubectl decrypts them for display
B) Kubernetes Secrets are only base64-encoded by default, not encrypted — base64 is an encoding, not encryption
C) The Secret was created incorrectly — using --from-literal disables encryption
D) Only Secrets of type kubernetes.io/tls are encrypted; generic Secrets are stored in plaintext
Show Answer
Correct Answer: B) Kubernetes Secrets are only base64-encoded by default, not encrypted
- A) Encrypted with AES-256 by default — Incorrect. Kubernetes does not encrypt Secrets at rest by default. Without an explicit EncryptionConfiguration, the
identityprovider is used, which stores data as-is (with base64 encoding in the API representation, but plaintext in etcd). - B) Only base64-encoded, not encrypted — Correct. By default, Kubernetes Secrets are stored in etcd without encryption. The base64 encoding you see in
kubectl get secret -o yamlis just an encoding for safe YAML/JSON transport of binary data — it provides zero security. Anyone with read access to etcd or the etcd data directory can read all Secrets. To encrypt Secrets at rest, administrators must configure anEncryptionConfigurationwith a real encryption provider (aescbc, aesgcm, secretbox, or a KMS provider). - C) Using
--from-literaldisables encryption — Incorrect. The creation method (--from-literal,--from-file, or YAML manifest) has no effect on how Secrets are stored in etcd. Storage encryption is controlled by the API server’s EncryptionConfiguration, not by how the Secret was created. - D) Only TLS Secrets are encrypted — Incorrect. The Secret
type(Opaque, kubernetes.io/tls, kubernetes.io/dockerconfigjson, etc.) has no effect on storage encryption. All Secret types are treated the same way by the EncryptionConfiguration. Either all Secrets are encrypted at rest or none are (depending on the configuration).
Q5: Authorization Modes Chain
Domain: Kubernetes Cluster Security
A Kubernetes cluster is configured with the following API server flag:
--authorization-mode=Node,RBAC
A request comes in that is denied by the Node authorizer.
What happens next in the authorization chain?
A) The request is immediately denied — the first authorizer’s decision is final
B) The request is passed to the RBAC authorizer for a second evaluation
C) The request is sent back to authentication for re-verification
D) The request bypasses authorization and goes directly to admission control
Show Answer
Correct Answer: B) The request is passed to the RBAC authorizer for a second evaluation
- A) Immediately denied — Incorrect. Kubernetes uses a chain of authorizers. If an authorizer denies a request (returns “no opinion” or “deny”), the request is passed to the next authorizer in the chain. Only if ALL authorizers deny the request is it rejected. Any single authorizer returning “allow” immediately grants access.
- B) Passed to the RBAC authorizer — Correct. With
--authorization-mode=Node,RBAC, the API server evaluates authorizers in order. The Node authorizer is designed specifically for kubelet requests — if a request is not a kubelet request, the Node authorizer has “no opinion” and passes it along. The RBAC authorizer then evaluates the request against Roles, ClusterRoles, and their bindings. If RBAC allows it, the request proceeds to admission control. If RBAC also denies it, the request is rejected. - C) Sent back to authentication — Incorrect. Authentication and authorization are separate phases. Once authentication succeeds, the request never goes back to the authentication phase. The pipeline moves forward: AuthN → AuthZ → Admission Control.
- D) Bypasses authorization entirely — Incorrect. The authorization phase cannot be bypassed. Every request must be authorized before reaching admission control (unless the user is in the
system:mastersgroup, which RBAC auto-grants all permissions).
Q6: OIDC Authentication Flow
Domain: Kubernetes Cluster Security
An organization configures their Kubernetes cluster to authenticate users via an OIDC (OpenID Connect) identity provider like Okta or Azure AD.
Which component in the OIDC authentication flow issues the ID token that the user presents to the Kubernetes API server?
A) The Kubernetes API server
B) The external OIDC identity provider (e.g., Okta, Azure AD)
C) The kubelet on the worker node
D) The kube-controller-manager
Show Answer
Correct Answer: B) The external OIDC identity provider (e.g., Okta, Azure AD)
- A) The Kubernetes API server — Incorrect. The API server validates the OIDC token (verifies the signature and claims) but does not issue it. The API server is configured with the OIDC issuer URL and uses it to verify tokens, but it is not an identity provider itself.
- B) The external OIDC identity provider — Correct. In OIDC authentication, the user authenticates directly with the identity provider (Okta, Azure AD, Google, Keycloak, etc.) outside of Kubernetes. The identity provider issues a JWT ID token to the user after successful authentication. The user then includes this token in the Authorization header when making requests to the Kubernetes API server. The API server verifies the token’s signature using the identity provider’s public keys.
- C) The kubelet on the worker node — Incorrect. The kubelet authenticates to the API server (not the other way around) and does not issue tokens for user authentication. Kubelet authentication uses client certificates or bootstrap tokens, not OIDC.
- D) The kube-controller-manager — Incorrect. The controller-manager runs control loops (ReplicaSet, Deployment, etc.) and is not involved in user authentication. It authenticates to the API server using its own client certificate.
Q7: PSA Enforcement Modes
Domain: Kubernetes Security Fundamentals
A cluster administrator applies the following labels to a namespace:
pod-security.kubernetes.io/enforce: baseline
pod-security.kubernetes.io/warn: restricted
pod-security.kubernetes.io/audit: restricted
A user deploys a Pod that violates the Restricted level but complies with Baseline.
What will happen?
A) The Pod will be rejected because it violates the Restricted level
B) The Pod will be created, but the user will see a warning and an audit event will be logged
C) The Pod will be created with no warnings or audit events
D) The Pod will be created in a degraded state with restricted capabilities removed
Show Answer
Correct Answer: B) The Pod will be created, but the user will see a warning and an audit event will be logged
- A) Rejected — Incorrect. The Pod is rejected only if it violates the level specified in the enforce mode. The enforce mode is set to
baseline, and the Pod complies with Baseline. Therefore, enforcement passes. - B) Created with a warning and audit event — Correct. The three PSA modes work independently: enforce blocks Pods that violate the specified level. warn sends a warning message to the user (but still creates the Pod). audit adds an annotation to the audit event. In this scenario: enforce=baseline (Pod complies → created), warn=restricted (Pod violates → warning shown to user), audit=restricted (Pod violates → audit event logged). The Pod is created successfully, but the user is alerted that it does not meet the Restricted standard.
- C) No warnings or audit events — Incorrect. The warn and audit modes are both set to
restricted, and the Pod violates Restricted. Both modes will trigger — the user sees a warning and an audit annotation is recorded. - D) Created in a degraded state — Incorrect. Pod Security Admission does not modify Pods. It is a validating mechanism: it either allows or denies the Pod (enforce mode) or logs/warns about it (audit/warn modes). It never mutates the Pod to add or remove capabilities. Mutation is the job of mutating admission controllers or tools like Kyverno.
Q8: Security Context — allowPrivilegeEscalation
Domain: Kubernetes Cluster Component Security
A security engineer is reviewing a Pod spec and sees the following security context:
securityContext:
allowPrivilegeEscalation: false
What does setting allowPrivilegeEscalation: false prevent?
A) It prevents the container from accessing the host PID namespace
B) It prevents processes inside the container from gaining more privileges than their parent process
C) It prevents the container from running as the root user
D) It prevents the container from mounting host volumes
Show Answer
Correct Answer: B) It prevents processes inside the container from gaining more privileges than their parent process
- A) Prevents accessing host PID namespace — Incorrect. Host PID namespace access is controlled by the
hostPIDfield in the Pod spec, not byallowPrivilegeEscalation. SettinghostPID: falseprevents sharing the host’s process namespace. - B) Prevents gaining more privileges than the parent process — Correct.
allowPrivilegeEscalation: falsesets theno_new_privsflag on the container process. This prevents the use ofsetuid/setgidbinaries and other mechanisms that would allow a child process to gain more privileges than its parent. For example, without this flag, a process running as a non-root user could execute a setuid binary to elevate to root. With this flag set to false, such escalation is blocked at the kernel level. - C) Prevents running as root — Incorrect. Running as root is controlled by
runAsNonRoot: trueorrunAsUser: <non-zero-UID>in the security context.allowPrivilegeEscalationdoes not determine the user the container runs as — it controls whether the container’s processes can gain additional privileges beyond what they started with. - D) Prevents mounting host volumes — Incorrect. Host volume mounts are controlled by the Pod spec’s
volumesandvolumeMountsfields, along with PodSecurityPolicy/PodSecurityStandards enforcement.allowPrivilegeEscalationhas no effect on volume mounting.
Q9: Kubernetes Attack Surface — Kubelet Port
Domain: Kubernetes Threat Model
A penetration tester discovers that port 10255 is open on Kubernetes worker nodes and is accessible without any authentication.
What is the security risk of an open kubelet read-only port (10255)?
A) Attackers can execute arbitrary commands inside running containers
B) Attackers can retrieve Pod specs, running container information, and node metrics without authentication
C) Attackers can modify kubelet configuration and restart the node
D) Attackers can access etcd data directly through the kubelet
Show Answer
Correct Answer: B) Attackers can retrieve Pod specs, running container information, and node metrics without authentication
- A) Execute arbitrary commands — Incorrect. Command execution requires access to the kubelet’s main API port (10250) with proper authentication. The read-only port (10255) only serves read operations — it cannot be used to execute commands, create containers, or modify state.
- B) Retrieve Pod specs, container information, and metrics without authentication — Correct. Port 10255 is the kubelet’s read-only port. When enabled, it serves endpoints like
/pods(lists all Pods and their full specs, including environment variables) and/metrics(Prometheus-format metrics). It requires no authentication or authorization. This is a serious information disclosure risk — environment variables may contain secrets, database URLs, or API keys. The CIS Benchmark recommends disabling this port by setting--read-only-port=0. - C) Modify kubelet configuration — Incorrect. The read-only port is strictly read-only. No write operations are possible through port 10255. Configuration changes require access to the kubelet’s authenticated port (10250) or direct access to the node.
- D) Access etcd data directly — Incorrect. etcd is accessed through the API server (typically on port 2379/2380), not through the kubelet. The kubelet communicates with the API server but does not provide a path to etcd. etcd access requires client certificate authentication.
Q10: MITRE ATT&CK Stage
Domain: Kubernetes Threat Model
An attacker has already gained initial access to a Kubernetes cluster. They create a DaemonSet that deploys a cryptocurrency miner on every worker node.
Which MITRE ATT&CK for Containers tactic does this scenario represent?
A) Initial Access
B) Discovery
C) Execution
D) Impact
Show Answer
Correct Answer: D) Impact
- A) Initial Access — Incorrect. Initial access is the tactic used to gain a foothold in the target environment (e.g., exploiting a vulnerable application, compromised credentials, insecure API server). The scenario states the attacker has already gained access — this phase is complete.
- B) Discovery — Incorrect. Discovery involves learning about the environment — enumerating services, Pods, namespaces, RBAC permissions, and cloud metadata. Deploying a crypto miner is not a discovery activity; it is an end-goal action.
- C) Execution — Partially relevant but not the best answer. Execution is about running attacker-controlled code inside the target environment. While creating a DaemonSet involves execution (the miner runs as code), the primary intent is resource hijacking — using the victim’s compute resources for the attacker’s financial gain. The MITRE framework classifies crypto mining under Impact.
- D) Impact — Correct. The Impact tactic covers actions that affect the availability, integrity, or usage of resources. Resource hijacking (crypto mining) is a documented sub-technique under Impact in MITRE ATT&CK for Containers. The attacker’s goal is not to steal data or maintain persistence — it is to consume the victim’s compute resources for profit. Using a DaemonSet ensures the miner runs on every node, maximizing resource utilization.
Q11: Runtime Security — Seccomp Profiles
Domain: Kubernetes Cluster Component Security
A security team wants to restrict the system calls that a container can make to reduce the kernel attack surface.
Which Linux kernel feature does Kubernetes use through the seccompProfile field in a Pod’s security context?
A) SELinux — Mandatory Access Control that labels files and processes
B) AppArmor — Path-based access control that restricts program capabilities
C) Seccomp — System call filtering that limits which syscalls a process can invoke
D) Capabilities — Fine-grained root privilege decomposition
Show Answer
Correct Answer: C) Seccomp — System call filtering that limits which syscalls a process can invoke
- A) SELinux — Incorrect. SELinux (Security-Enhanced Linux) is a Mandatory Access Control (MAC) system that uses labels to control access between processes and files. While Kubernetes supports SELinux through
seLinuxOptionsin the security context, it is a separate mechanism from Seccomp and is not configured through theseccompProfilefield. - B) AppArmor — Incorrect. AppArmor is a Linux Security Module that restricts programs based on file paths, network access, and capabilities. Kubernetes supports AppArmor through annotations (or the
appArmorProfilefield in newer versions), but it is not the same as Seccomp. - C) Seccomp — Correct. Seccomp (Secure Computing Mode) is a Linux kernel feature that filters system calls. The
seccompProfilefield in a Pod’s security context configures a Seccomp profile for the container. The three types are:RuntimeDefault(uses the container runtime’s default profile, which blocks ~40-50 dangerous syscalls),Localhost(uses a custom profile from the node’s filesystem), andUnconfined(no filtering). The Restricted Pod Security Standard requires a Seccomp profile to be set. - D) Capabilities — Incorrect. Linux capabilities decompose root’s privileges into distinct units (e.g.,
NET_BIND_SERVICE,SYS_PTRACE,NET_ADMIN). They are configured through thecapabilitiesfield in the security context (add/drop), not throughseccompProfile. Capabilities and Seccomp are complementary but separate mechanisms.
Q12: Kyverno Policy Types
Domain: Kubernetes Cluster Security
An administrator is using Kyverno for policy enforcement and wants to automatically add a label to every new namespace created in the cluster.
Which Kyverno policy rule type should they use?
A) validate
B) mutate
C) generate
D) verify
Show Answer
Correct Answer: B) mutate
- A) validate — Incorrect. Validate rules check whether a resource meets specified criteria and either allow or deny the request. A validate rule cannot modify the resource — it can only accept or reject it. If the administrator wants to reject namespaces without the label, validate would be appropriate. But the requirement is to automatically add the label, which requires mutation.
- B) mutate — Correct. Mutate rules in Kyverno modify (patch) incoming resources before they are persisted. To automatically add a label to every new namespace, a mutate rule would inject the label into the namespace metadata. The administrator defines a
mutaterule with apatchStrategicMergeorpatchesJson6902that adds the desired label. This ensures consistency without requiring developers to remember to add the label themselves. - C) generate — Incorrect. Generate rules create new Kubernetes resources when a triggering resource is created. For example, when a new namespace is created, a generate rule could create a default NetworkPolicy or ResourceQuota in that namespace. Generate does not modify the triggering resource itself — it creates additional resources.
- D) verify — Incorrect. Kyverno uses
verifyImagesrules to verify container image signatures and attestations (e.g., using Cosign or Notary). Image verification is a specific sub-type of validation, not related to adding labels to namespaces.
Q13: Service Mesh mTLS Modes
Domain: Kubernetes Security Fundamentals
A team is deploying Istio service mesh and wants to enforce mutual TLS (mTLS) between all services in the mesh.
What is the difference between Istio’s STRICT and PERMISSIVE mTLS modes?
A) STRICT encrypts data at rest; PERMISSIVE encrypts data in transit
B) STRICT requires mTLS for all traffic; PERMISSIVE accepts both mTLS and plaintext
C) STRICT uses TLS 1.3 only; PERMISSIVE allows TLS 1.2 and 1.3
D) STRICT applies to ingress traffic only; PERMISSIVE applies to all traffic
Show Answer
Correct Answer: B) STRICT requires mTLS for all traffic; PERMISSIVE accepts both mTLS and plaintext
- A) STRICT encrypts at rest; PERMISSIVE encrypts in transit — Incorrect. Both modes relate to in-transit (network) encryption between services. mTLS in a service mesh is about encrypting east-west traffic between Pods. Neither mode has anything to do with encryption at rest, which is a storage-layer concern.
- B) STRICT requires mTLS; PERMISSIVE accepts both mTLS and plaintext — Correct. In PERMISSIVE mode (the default), services accept both mTLS and plaintext connections. This allows non-mesh services (those without sidecar proxies) to communicate with mesh services during migration. In STRICT mode, services only accept mTLS connections — plaintext connections are rejected. STRICT should be the goal for production environments to ensure all service-to-service traffic is encrypted and mutually authenticated.
- C) STRICT uses TLS 1.3 only; PERMISSIVE allows TLS 1.2 and 1.3 — Incorrect. TLS version selection is controlled separately from the mTLS mode. The STRICT/PERMISSIVE distinction is about whether plaintext connections are allowed, not about TLS version negotiation.
- D) STRICT applies to ingress only; PERMISSIVE applies to all traffic — Incorrect. Both modes apply to service-to-service (east-west) traffic within the mesh. Ingress traffic from outside the mesh is handled by Istio Ingress Gateway configuration, which is separate from PeerAuthentication mTLS mode settings.
Q14: Compliance Automation Tools
Domain: Kubernetes Security Fundamentals
A security team wants to continuously verify that their Kubernetes cluster configurations comply with CIS Benchmarks and internal policies, detecting configuration drift automatically.
Which approach BEST describes compliance automation in Kubernetes?
A) Manually running kubectl commands weekly to check cluster configuration
B) Using tools like kube-bench, OPA/Gatekeeper, and Kyverno to continuously evaluate and enforce policy
C) Implementing network encryption with a service mesh to satisfy compliance requirements
D) Storing all Kubernetes manifests in a Git repository for version control
Show Answer
Correct Answer: B) Using tools like kube-bench, OPA/Gatekeeper, and Kyverno to continuously evaluate and enforce policy
- A) Manually running kubectl commands weekly — Incorrect. Manual, periodic checks are the opposite of automation. They are error-prone, infrequent, and do not detect drift between checks. Compliance automation requires continuous, automated evaluation.
- B) Using kube-bench, OPA/Gatekeeper, and Kyverno — Correct. Compliance automation combines: (1) CIS Benchmark scanning (kube-bench) to verify cluster component configurations, (2) Policy-as-code (OPA/Gatekeeper, Kyverno) to prevent and detect non-compliant resources via admission control and background scanning, and (3) Continuous monitoring to detect configuration drift over time. These tools run automatically, provide reports, and can block non-compliant changes in real time.
- C) Implementing network encryption with a service mesh — Incorrect. Network encryption (mTLS via a service mesh) is one specific security control that may help satisfy certain compliance requirements (e.g., encryption in transit). However, it is not a compliance automation approach — it addresses only one aspect of compliance and does not evaluate or enforce the full range of configuration policies.
- D) Storing manifests in Git — Incorrect. GitOps (storing manifests in Git) provides version control, audit trails, and declarative configuration management. While it supports compliance practices, it does not enforce policies or continuously evaluate whether the running cluster state matches desired policies. A Git repository does not prevent someone from applying non-compliant changes directly via kubectl.
Q15: GDPR Requirements in Kubernetes
Domain: Compliance and Security Frameworks
A company running Kubernetes in the EU must comply with GDPR (General Data Protection Regulation). They process personal data of EU citizens in their Kubernetes workloads.
Which GDPR requirement is MOST directly addressed by implementing Kubernetes audit logging?
A) Right to Erasure (Right to be Forgotten)
B) Data Protection by Design and by Default
C) Accountability and Demonstrable Compliance
D) Cross-border Data Transfer Restrictions
Show Answer
Correct Answer: C) Accountability and Demonstrable Compliance
- A) Right to Erasure — Incorrect. The Right to Erasure requires organizations to delete personal data upon request. This is addressed by application-level data deletion capabilities and database management, not by audit logging. Audit logging records who accessed what and when — it does not manage data deletion.
- B) Data Protection by Design and by Default — Incorrect. Data Protection by Design refers to building privacy into systems from the start (e.g., encryption, access controls, data minimization). While audit logging is one component of a comprehensive security design, it does not directly embody the “by design and default” principle.
- C) Accountability and Demonstrable Compliance — Correct. GDPR Article 5(2) requires organizations to be able to demonstrate compliance with data protection principles. Kubernetes audit logging provides a detailed, immutable record of all API interactions: who accessed which resources, when, and what changes were made. This audit trail is critical for demonstrating to regulators that access to personal data is controlled, monitored, and traceable. Audit logs are evidence used during compliance audits and incident investigations.
- D) Cross-border Data Transfer Restrictions — Incorrect. Cross-border data transfer (Chapter V of GDPR) is about ensuring personal data transferred outside the EU has adequate protection (e.g., Standard Contractual Clauses, adequacy decisions). This is addressed by infrastructure design and data residency policies, not audit logging.
Score Card
Record your answers and calculate your score:
| Question | Your Answer | Correct Answer | Result |
|---|---|---|---|
| Q1 | ___ | C | ⬜ |
| Q2 | ___ | A | ⬜ |
| Q3 | ___ | B | ⬜ |
| Q4 | ___ | B | ⬜ |
| Q5 | ___ | B | ⬜ |
| Q6 | ___ | B | ⬜ |
| Q7 | ___ | B | ⬜ |
| Q8 | ___ | B | ⬜ |
| Q9 | ___ | B | ⬜ |
| Q10 | ___ | D | ⬜ |
| Q11 | ___ | C | ⬜ |
| Q12 | ___ | B | ⬜ |
| Q13 | ___ | B | ⬜ |
| Q14 | ___ | B | ⬜ |
| Q15 | ___ | C | ⬜ |
Your Score: ___ / 15
Combined Score (Part 1 + Part 2)
| Metric | Score |
|---|---|
| Part 1 Score | ___ / 15 |
| Part 2 Score | ___ / 15 |
| Combined Score | ___ / 30 |
| Percentage | ____% |
Combined Scoring Interpretation
| Combined Score | Percentage | Result |
|---|---|---|
| 24–30 | 80–100% | ✅ Exam Ready — High confidence you will pass |
| 22–23 | 73–77% | ⚠️ Borderline — Review weak domains, retake in 2–3 days |
| 18–21 | 60–70% | ❌ Needs work — Go back to specific chapters |
| Below 18 | Below 60% | ❌ Significant gaps — Systematic review needed |
The KCSA passing score is 75%. On 30 combined questions, that means you need at least 23 correct to be on pace.
Domain-Level Analysis
After completing both mock exams, calculate your accuracy by domain:
| Domain | Qs in Part 1 | Qs in Part 2 | Total Correct / Total | Percentage |
|---|---|---|---|---|
| Cloud Native Security | Q1, Q2 | Q1, Q2 | ___ / 4 | ___% |
| Cluster Security | Q3, Q5, Q6 | Q5, Q6, Q12 | ___ / 6 | ___% |
| Component Security | Q4, Q11, Q14 | Q4, Q8, Q11 | ___ / 6 | ___% |
| Security Fundamentals | Q7, Q8, Q12 | Q7, Q13, Q14 | ___ / 6 | ___% |
| Threat Model | Q9, Q10 | Q9, Q10 | ___ / 4 | ___% |
| Compliance & Frameworks | Q13, Q15 | Q3, Q15 | ___ / 4 | ___% |
Any domain below 75% accuracy needs review before exam day.
