Kubernetes & Cloud Native Security Associate
Practice Questions

Option A addresses both risks directly. Digest pinning eliminates tag mutation (where :18 could silently point to a different image), and Cosign signing combined with Kyverno admission policy ensures only cryptographically verified images reach the cluster. This is the defense-in-depth approach recommended by SLSA and CNCF supply chain security guidance.
B is wrong because Trivy scanning catches known CVEs but does not solve tag mutation or tampering. An attacker who replaces the image at the same tag bypasses scanning done at build time.
C is wrong because a private mirror helps with tag mutation but does not verify image integrity or provenance. PodSecurityPolicy was deprecated in 1.21 and removed in 1.25, and it does not address supply chain concerns regardless.
D is wrong because SBOMs are valuable for transparency but do not by themselves prevent deployment of an unsigned or tampered image. Scanning the SBOM offline still leaves a window between build and deploy.

Removing labels detaches the Pod from the Service (cutting live traffic) without destroying forensic evidence. Killing or restarting the Pod would destroy in-memory artifacts needed for investigation. Long-term, a seccomp profile restricting execve or a custom AppArmor profile denying shell executables reduces the attack surface for this class of container breakout attempt.
A is wrong because restarting the Pod destroys all forensic state. Liveness probes are for application health — they cannot detect or prevent shell invocations.
C is wrong because documentation is important but is not the primary response action. PodDisruptionBudgets manage availability during voluntary disruptions and have no security enforcement function.
D is wrong because draining the entire node is disproportionate and impacts all other workloads on it. Node-level action is only warranted if node compromise is confirmed, which has not been established here.

CIS check 1.2.1 targets the kube-apiserver. When --anonymous-auth=true (the default), requests with no credentials are assigned the system:anonymous user and system:unauthenticated group. They still pass through the authorizer (RBAC), so they are not fully unauthorized — but any RBAC rules granting access to those identities (including default ClusterRoleBindings) become exploitable without credentials.
A is wrong because the kubelet does have its own --anonymous-auth flag but it falls under CIS section 4, not 1.2. Check 1.2.1 specifically targets the kube-apiserver by CIS benchmark numbering.
C is wrong because anonymous auth does NOT bypass authorization. The risk is indirect — misconfigured RBAC for anonymous subjects — not a blanket bypass of all access controls.
D is wrong because etcd authentication is a separate concern covered in CIS section 2. etcd has its own authentication model entirely distinct from this check.

Seccomp (Secure Computing Mode) is the kernel-level mechanism that intercepts syscalls and allows or denies them based on a profile before the kernel processes them. Since Kubernetes 1.19, seccomp profiles can be applied natively via securityContext.seccompProfile. It directly addresses the requirement to block specific syscalls like ptrace, mount, or reboot.
A is wrong because AppArmor works on file access paths, network access, and Linux capabilities — not individual syscalls. It cannot block ptrace by syscall number.
C is wrong because dropping Linux capabilities reduces privilege but does not map 1:1 with syscalls. Some dangerous syscalls remain callable without any capability in certain conditions. Capabilities and syscalls are related but distinct layers.
D is wrong because OPA/Gatekeeper acts at admission control — it can enforce that a Pod has a seccomp profile configured, but it does not itself perform any syscall filtering at runtime.

Wildcard verbs and resources with no apiGroup restriction is functionally equivalent to cluster-admin. Any compromise of this Pod gives an attacker full cluster control. The correct fix is creating a namespaced Role with minimal verbs (get and list) on only the pods resource, bound via a RoleBinding — pure least-privilege principle.
B is wrong because a ClusterRole bound with a ClusterRoleBinding is cluster-wide regardless of namespace. The service account is not limited to its namespace and can read Secrets, create workloads, and escalate privileges anywhere in the cluster.
C is wrong because binding a wildcard ClusterRole via a RoleBinding does restrict the scope to the namespace, but keeping the wildcard still violates least privilege. The workload only needs pods access.
D is wrong because disabling automounting is a good general practice but does not solve the overbroad permissions. The service account still exists with those permissions and can be manually mounted or otherwise leveraged.

SLSA Level 1 requires that build provenance (metadata about how an artifact was built) exists, but it can be self-generated and unsigned. Level 2 adds the requirement that provenance is generated AND cryptographically signed by the build service itself — making it tamper-evident and attributable to the build system, not just the developer.
A is wrong because scripted builds are a SLSA Level 1 requirement. Level 1 already mandates that the build process is fully defined in a build script.
C is wrong because isolated ephemeral build environments with no persistence between builds are a SLSA Level 3 requirement, not Level 2.
D is wrong because two-person review of source code is a SLSA Level 4 requirement related to source control integrity, not Level 2.

Enabling --client-cert-auth=true ensures only clients with valid certificates (i.e., the kube-apiserver) can connect. Combined with network-level isolation allowing only the API server to reach port 2379, this follows defense in depth. etcd stores ALL cluster state — including Kubernetes Secrets (which without encryption-at-rest are just base64), service account tokens, and kubeconfig data. Compromising etcd is effectively a full cluster compromise.
A is wrong because NetworkPolicy only restricts Pod-to-Pod traffic within the cluster and does not apply to control plane host-level components like etcd. Firewall or ACL rules are required for host-level network isolation.
C is wrong because certificate rotation and audit logging are good practices but do not fix the authentication gap. An attacker can still connect without a client certificate while this is unresolved.
D is wrong because etcd does not use Kubernetes RBAC. etcd has its own authentication model. Kubernetes RBAC applies only to the kube-apiserver, not to direct etcd connections.

In the Kubernetes admission chain, mutating webhooks run first and can modify the object — for example injecting sidecar containers, adding default labels, or enforcing defaults. After all mutations complete, the object goes through validating webhooks, which can only approve or deny. This ordering ensures that validation operates on the final, fully-mutated version of the object.
A is wrong because the order is reversed. Mutating runs before validating, not after. Also, only mutating webhooks can modify objects.
C is wrong because both types are synchronous and block the API request while they execute. Asynchronous processing is the domain of controllers, not admission webhooks.
D is wrong because validating webhooks can also reject requests. The real distinction is that validating webhooks cannot modify objects at all, not just that they lack label-writing ability.

Falco rules use a filter language where evt.type = open captures the open or openat syscall used to open a file. fd.name = /etc/shadow matches the specific file path. container.id != host (equivalent to container = true) scopes the detection to containerized processes only, not the host OS. This is the canonical Falco pattern for detecting sensitive file access inside containers.
B is wrong because execve is a process execution event, not a file read. proc.name = shadow makes no sense as a process name. This rule would never fire on a file read.
C is wrong because Falco does not use field names like syscall.type or file.path. These do not exist in the Falco filter syntax.
D is wrong because evt.type = connect is a network syscall. It would never trigger on a file open or read operation. This rule fundamentally misidentifies the event type.

The CIS Kubernetes Benchmark recommends minimizing the attack surface by disabling or removing services not required for node operation — this is the principle of least functionality, a subset of least privilege. Each running service is a potential attack vector. avahi-daemon has had remote code execution CVEs, rpcbind is a classic lateral movement target, and sshd expands the credential attack surface on the node.
B is wrong because separation of duties concerns conflicting responsibilities across roles. Moving services to another node pool still leaves them running and exposed — it does not reduce the attack surface.
C is wrong because adding a firewall is a compensating control, not a remediation. If an attacker is already on the node or the firewall is misconfigured, the service remains exploitable. Disabling the service entirely is the preferred action.
D is wrong because non-repudiation is about traceability and audit trails, not attack surface reduction. Logging the activity of a vulnerable service does not make it safe to run.

CIS Benchmarks are best-practice recommendations, not absolute compliance mandates. kube-bench maps checks to benchmark levels (L1 and L2). Some findings may be handled by a managed Kubernetes provider in ways that don't appear in the check output. Others may be intentionally configured differently based on architectural decisions with compensating controls in place. A mature security program treats findings as inputs to a risk-based remediation process, not an unconditional fix list.
A is wrong because not all findings are equal in severity or applicability. Treating every finding as an immediate critical remediation without context ignores risk prioritization and can cause operational disruption.
C is wrong because kube-bench covers multiple CIS sections: master node components (1.x), etcd (2.x), control plane configuration (3.x), worker nodes and kubelet (4.x), and policies (5.x). It is not limited to the API server.
D is wrong because kube-bench has no --fix flag and performs no automated remediation. It is strictly a read-only auditing tool that produces a report for human review.

The existing Kyverno policy only checks the registry domain — it says nothing about image content integrity. Cosign signatures are cryptographically bound to a specific image digest. If the image is tampered with, its digest changes and the original signature becomes invalid. A Kyverno policy enforcing valid Cosign signatures would reject any image whose digest does not match a signature made with the organization's private key, regardless of the tag used.
A is wrong because banning :latest improves reproducibility but does not prevent tampering. An attacker can overwrite a pinned version tag such as v1.2.3 just as easily as :latest on most registries.
B is wrong because audit logging is a detective control, not a preventive one. It would record what was deployed after the fact but would not stop the tampered image from running.
D is wrong because immutable tags would prevent this specific attack vector and is a valid partial control. However option C is more comprehensive — Cosign verification works even if the image is copied to a different tag or if immutability is somehow bypassed.

Applying an Ingress NetworkPolicy on the database Pod that whitelists only traffic from Pods labeled app: api directly enforces the requirement at the receiving end. Kubernetes NetworkPolicy is additive and allow-based — once a policy selects a Pod, all ingress traffic not explicitly allowed is denied by default. This is the canonical pattern for controlling microservice-to-microservice access in Kubernetes.
A is wrong because an Egress policy on frontend is a valid complementary control but is insufficient on its own. It depends on frontend being correctly labeled and does not protect database from other services that may be able to reach it.
C is wrong because a default-deny plus api egress policy would work conceptually but requires more policies and is more complex. More importantly, an Egress policy on api does not directly protect database from other Pods that could independently reach it.
D is wrong because omitting a Service selector to obscure DNS is security through obscurity. It is not a reliable enforcement mechanism — the database Pod's IP is still discoverable and reachable without DNS resolution.

The EncryptionConfiguration file on the control plane node contains the encryption key in plaintext (base64-encoded). Any user or process that can read that file can decrypt all encrypted etcd data. This is why production deployments should use the kms provider — integrated with AWS KMS, GCP KMS, or HashiCorp Vault — to envelope-encrypt the data encryption key using an externally managed master key that never touches the control plane filesystem.
A is wrong because encryption at rest does NOT apply retroactively. After enabling it, administrators must force-update all existing Secrets by re-applying them through the API — for example using kubectl get secrets --all-namespaces -o json | kubectl replace -f - — to trigger re-encryption.
C is wrong because aescbc is a supported provider alongside aesgcm and the preferred kms provider. None of these were removed at Kubernetes 1.20.
D is wrong because etcd encryption at rest only protects data written to disk. Data in transit between etcd peers requires mTLS, which is an entirely separate security control. Enabling at-rest encryption has no effect on in-transit confidentiality.

This final question addresses the most important conceptual boundary in security compliance: the difference between security controls and a security program. Technical controls (firewalls, encryption, RBAC, admission policies) are the implementation layer. Compliance frameworks evaluate whether the organization has a systematic process for: (1) identifying what risks it faces (risk assessment), (2) selecting and implementing appropriate controls to address those risks (control implementation), (3) testing that controls operate effectively (control testing — this is what SOC 2 Type II evaluates over time), and (4) responding when controls fail (incident response). A perfectly automated cluster with no documented objectives, no risk-based reasoning, no testing evidence, and no incident response capability cannot demonstrate that it is managing security systematically — it is a collection of controls without a program. Mature security requires both: strong technical implementation AND the governance framework that ensures it remains effective, adapts to new threats, and recovers from failures.
A is wrong because the missing elements are not just paperwork — they represent genuine capability gaps. Without incident response runbooks, the team does not know what to do when a security event occurs. Without control testing evidence, the team cannot demonstrate that controls work as intended (they may be configured but misconfigured). Without risk assessment, the team cannot demonstrate that the right controls were chosen for the right reasons.
C is wrong because automated controls, while more reliable for consistency, still require documentation, testing, and governance. Automation does not eliminate the need for understanding why each control exists, verifying it achieves its objective, and planning for failure scenarios. Compliance frameworks do not grant waivers for automation.
D is wrong because technical controls that are already implemented and operational do count toward compliance — they just need to be supported by the governance elements described in option B. Rebuilding is not required; the governance layer needs to be added to the existing technical foundation.

The automounted service account token is a valid credential — the kube-apiserver accepts it and authenticates the request as system:serviceaccount:staging:<serviceaccount-name>. Authentication succeeds. The request then proceeds to the authorization layer (RBAC). With no RoleBindings or ClusterRoleBindings, the service account has no permissions. RBAC denies the request with a 403 Forbidden response. This distinction between authentication failure (401) and authorization failure (403) is important — the token itself is valid, but the identity lacks permissions.
A is wrong because 401 Unauthorized indicates that authentication failed — the identity could not be established. A service account token is valid credentials; authentication succeeds.
C is wrong because 404 Not Found indicates the requested resource does not exist. The API server does not hide endpoints from unauthenticated or unauthorized users — it returns 401 or 403 respectively.
D is wrong because there is no implicit read access for authenticated principals in Kubernetes RBAC. All access is explicitly granted through Roles and ClusterRoles. The system:authenticated group has minimal default permissions.

This is a subtle but real supply chain risk. Container image scanning, signing, and Kyverno admission policies all operate on the declared container images. However, code or configuration fetched at runtime from an external source (Git, S3, HTTP endpoints) completely bypasses these controls — it was not present when the image was scanned, it has no signature, and admission controllers cannot inspect it. An attacker who compromises the Git repository (or performs a DNS/MITM attack on the clone operation) can inject malicious code into running production containers without touching any image or passing any security gate.
A is wrong because emptyDir volumes are not mounted on the host filesystem — they are temporary storage within the Pod's lifecycle. Init containers writing to emptyDir cannot reach the host filesystem through that mechanism.
C is wrong because emptyDir volumes are permitted under the restricted PodSecurity profile. The profile restricts volume types like hostPath but explicitly allows emptyDir.
D is wrong because while Git credentials are a valid concern, the question asks why the reviewer flagged this as a supply chain risk — and the core issue is runtime code fetching bypassing security controls, not the credential storage method.

PCI-DSS Requirement 10 specifically requires audit logging of all access to system components and cardholder data, with logs retained for at least 12 months (3 months immediately available). Kubernetes API audit logging directly satisfies this requirement for the cluster control plane. PCI-DSS Requirement 6 requires protecting systems against known vulnerabilities — this maps to applying CIS hardening benchmarks, maintaining up-to-date images, and scanning for CVEs. These are the most direct and well-established PCI-DSS to Kubernetes control mappings.
A is wrong because PCI-DSS Requirement 2 covers vendor-supplied defaults (default accounts and passwords), which maps more directly to disabling default service accounts with excessive permissions and removing default admin credentials — not specifically token rotation.
C is wrong because PCI-DSS Requirement 8 covers identification and authentication of all users and system components. imagePullSecrets authenticate to a container registry — this is relevant but peripherally so. The requirement more directly maps to strong authentication for cluster access (OIDC, client certificates, MFA for privileged users).
D is wrong because PCI-DSS Requirement 1 covers firewall and network segmentation controls, which maps more directly to Kubernetes NetworkPolicy, security groups, and cluster network architecture — not to disabling dashboards or services, which are Requirement 2 concerns.

CIS Benchmark check 5.1.5 identifies cases where the default service account (which is automatically assigned to Pods that do not specify a service account) has been granted RBAC permissions. Because any Pod that does not explicitly specify a service account uses the default one, granting it permissions inadvertently gives those permissions to all workloads in the namespace that omit service account configuration. Remediation involves removing the bindings from the default service account and setting automountServiceAccountToken: false on it to prevent the token from being mounted by careless workloads.
A is wrong because deleting the kube-system default service account would break system components. The remediation is removing the RBAC bindings, not the service account itself.
C is wrong because the check is flagging too many permissions on the default service account, not too few. Creating more ClusterRole bindings would worsen the situation.
D is wrong because kubelet authentication uses node certificates (system:node:<name> identity), not service accounts. Service accounts are for Pod workloads, not kubelets.

The eBPF in-kernel verifier is the key differentiator. Before any eBPF program is loaded, the kernel verifier runs a static analysis pass that ensures the program is memory-safe (no out-of-bounds access), terminates (no infinite loops), and only accesses permitted kernel data structures. This makes eBPF programs much safer to run in kernel space than traditional kernel modules (LKMs), which run with unrestricted kernel privileges. A bug in a kernel module can cause kernel panics, memory corruption, or be exploited to gain kernel-level code execution. The eBPF verifier provides a strong safety guarantee that kernel modules lack.
A is wrong because both eBPF programs and kernel modules require root (specifically CAP_BPF or CAP_SYS_ADMIN for eBPF, and CAP_SYS_MODULE for kernel modules) to load. The privilege requirement is similar for both.
C is wrong because performance is indeed a consideration (eBPF is generally considered more efficient than kernel module hooks in many benchmarks), but this is a performance advantage, not a security advantage as the question asks.
D is wrong because eBPF programs can be loaded and unloaded dynamically at runtime — this is one of their key features. The safety guarantee comes from the verifier, not from being immutable.

The correct enterprise approach is to never commit secrets to Git in any form — even encrypted or encoded. External Secrets Operator (ESO) or the CSI Secrets Store Driver connects to an external vault at runtime and creates (or populates) Kubernetes Secrets from the vault's stored values. The Helm chart references the Secret by name — no secret value is ever in Git, in the Helm chart, or in values.yaml. This approach also centralizes secret rotation, audit logging of secret access, and access control in the vault.
A is wrong because base64 is encoding, not encryption. It provides zero security — anyone who can read the file can decode it instantly. Committing base64-encoded passwords to Git is equivalent to committing them in plaintext.
C is wrong because kubectl create secret --from-literal=password=<value> passes the plaintext password in the shell command, which appears in shell history and process listings. It also requires manual credential management, which doesn't scale.
D is wrong because Helm Secrets (using SOPS or similar) is a valid approach for teams that must keep secrets in Git. However, it requires careful key management, and the gold standard for production environments is external secret management that keeps secrets out of Git entirely.

A 2.3 GB Ubuntu image with compilers, curl, wget, git, pip, and Python contains hundreds of packages, each potentially with CVEs. More critically, post-exploitation, an attacker has access to curl (download more tools), wget (exfiltrate data), git (clone attacker repos), gcc (compile exploits), and pip (install malicious Python packages) — essentially a full attack toolkit. Rebuilding with a minimal or distroless base containing only the application binary reduces the attack surface to near zero. If the application serves static responses from pre-compiled code, it may not even need a language runtime in the final image.
A is wrong because upgrading from 20.04 to 22.04 reduces some known vulnerabilities in OS packages but does not address the fundamental problem: the image contains massive amounts of unnecessary software. The upgrade helps but has far less impact than removing the unnecessary components entirely.
C is wrong because a seccomp profile is a good additional hardening layer but does not remove the tools from the image. An attacker can still read and copy tools even if some syscalls are blocked.
D is wrong because readOnlyRootFilesystem prevents writing to the container filesystem but does not prevent execution of existing binaries. An attacker can still run curl, wget, gcc, and other tools already present in the image — they just cannot write new files to the container's own filesystem.

Service account tokens are JWTs (JSON Web Tokens). The --service-account-signing-key-file specifies the private key the API server uses to sign these tokens. The --service-account-issuer defines the iss (issuer) claim in the token — typically the API server URL. Components that receive a service account token (like OIDC-compatible systems or other clusters) can validate the token by verifying the signature against the public key and checking the issuer claim. Having a unique issuer per cluster prevents a token issued for one cluster from being reused against another cluster — a critical boundary for multi-cluster environments.
A is wrong because etcd data encryption is configured via --encryption-provider-config, not service account signing keys. The signing key is for JWT tokens, not etcd data.
C is wrong because the TLS certificate for the HTTPS endpoint is configured via --tls-cert-file and --tls-private-key-file. These are separate from service account token signing keys.
D is wrong because the API server authenticates with kubelets using its own client certificate (--kubelet-client-certificate), not a service account.

This requirement demands real-time policy enforcement at deployment time based on external scan data. A ValidatingAdmissionWebhook that queries a scan results database (Grype DB, a custom API, or a registry like JFrog Xray) at Pod admission time can check whether the specific image digest being deployed has a scan result that passes all severity thresholds and was completed within the required time window. If no valid recent scan exists, the webhook denies the Pod creation. This provides cryptographically-bound (digest-based) enforcement of scan recency and pass/fail status.
A is wrong because running Trivy inside a running container as a liveness probe is operationally impractical (Trivy would need to be included in every image, adding significant size) and runs after the container starts, not before. A failing liveness probe would restart the container, not prevent it from starting.
C is wrong because image labels are metadata added at build time. An attacker who can push images to the registry could add a forged scan timestamp label. Labels are not cryptographically verifiable scan evidence — they can be trivially manipulated.
D is wrong because deleting images from a registry based on scan age would disrupt deployments and image availability. The requirement is to block deployment of unscanned images, not to delete them. Deletion would prevent recovery of known-good images and break reproducibility.

A process reading a service account token to then make Kubernetes API calls is a well-documented lateral movement technique. If the data-processor application is legitimately a batch data processing job, it should use its language's Kubernetes SDK (Python kubernetes client, Go client) — not curl — to make API calls. The detection of curl reading the token is a high-fidelity indicator that a child process (likely spawned via a code execution vulnerability, dependency confusion attack, or malicious dependency) is conducting reconnaissance by reading the service account token. The attacker's goal is typically to use the token to list cluster resources, read Secrets from other namespaces, or create privileged Pods. This requires immediate investigation of the Pod's recent process tree and network connections.
A is wrong because while curl can legitimately read service account tokens (e.g., a shell script making API calls), this should be expected behavior that is known and baselined. An unexpected curl process in a data processing container is not normal and should not be dismissed as a false positive without investigation.
C is wrong because service account token reads are not part of TLS handshake initialization. TLS uses X.509 certificates for connection authentication — the service account token is a Kubernetes API authentication mechanism, not a TLS credential.
D is wrong because service account token refresh in Kubernetes 1.21+ is handled automatically by the kubelet's token projector — not by the application process manually reading and refreshing the token file using curl.

JIT access means granting elevated permissions only when needed and automatically revoking them after a defined window. The most robust implementation combines: (1) short-lived OIDC tokens that expire quickly so long-lived tokens cannot be reused after access is revoked, (2) an access request system that temporarily adds the user to a privileged OIDC group with a defined expiry, and (3) RBAC that grants the required permissions to the group rather than individual users. When the access window expires, group membership is removed and the next token refresh will not include the group claim, effectively revoking access without any manual Kubernetes RBAC changes.
A is wrong because Kubernetes does not support per-user or configurable short TTL for OIDC tokens — token TTL is set by the identity provider, not by Kubernetes. Client certificates have a TTL set at issuance but are not easily used for JIT access in practice.
C is wrong because manually deleting and recreating RoleBindings is operationally fragile, creates an audit trail gap (permissions were deleted and re-created), and does not handle the time-based automatic revocation requirement — someone must remember to delete the binding after the access window.
D is wrong because kubectl proxy does not enforce session timeouts and does not provide any access control beyond what the user's existing kubeconfig credentials allow. It is a local network proxy tool, not an access management system.

The SeccompDefault feature gate allows the kubelet to apply the RuntimeDefault seccomp profile to any container that does not explicitly specify a seccomp profile. It was introduced as alpha in 1.22, beta in 1.25, and graduated to stable in 1.27. However, even in 1.27+, the feature requires explicit enablement in the kubelet configuration (--seccomp-default flag or equivalent) in most Kubernetes distributions — it is not automatically enabled in all clusters. The RuntimeDefault profile uses the container runtime's default seccomp profile (containerd's or crun's built-in list), which blocks commonly dangerous syscalls while allowing those needed by typical applications.
A is wrong because in Kubernetes 1.19, seccomp support was promoted to GA (moving from alpha annotation to native securityContext.seccompProfile field), but RuntimeDefault was not automatically applied. The GA promotion was about the API field, not automatic default application.
C is wrong because Kubernetes 1.20 did not make seccomp mandatory. No version of Kubernetes has made seccomp mandatory for all containers — it remains opt-in (or opt-in via the SeccompDefault kubelet flag).
D is wrong because the SeccompDefault feature gate (stable in 1.27) does allow RuntimeDefault to be applied automatically when explicitly enabled in kubelet configuration. It is not always required to specify it in every Pod spec when this feature is enabled.

etcd stores the complete revision history of all key changes, enabling watch operations and point-in-time queries. auto-compaction-retention controls how long this revision history is kept before being compacted (deleted). A value of 1 (in hours, by default) means revisions older than 1 hour are discarded during compaction. The security implication is that forensic analysis of historical etcd state — for example, determining what value a Secret had 3 hours ago — becomes impossible once compaction runs. For production, teams should choose a retention period that balances etcd disk usage (revision history consumes significant space in active clusters) with forensic needs, recognizing that audit logs and external monitoring should be the primary source of truth for historical security analysis.
A is wrong because the compaction retention unit for the --auto-compaction-retention flag (in periodic mode, which is the default) is hours, not seconds. A value of 1 means 1 hour.
C is wrong because a value of 1 does not disable compaction — it enables compaction with a 1-hour retention period. A value of 0 disables automatic compaction.
D is wrong because compaction removes old revision history but does not limit each key to a single revision. Current values are always accessible. Watch operations continue to function for future changes — they only lose access to the compacted historical window.

This distinction is important for setting accurate expectations about what image scanning achieves. CVE-based scanning (Trivy, Grype, Snyk) matches installed package versions against known vulnerability databases — it is highly effective at finding publicly disclosed vulnerabilities in third-party dependencies. However, it cannot detect: application logic flaws (authentication bypasses, injection vulnerabilities, business logic errors), insecure configurations baked into the image, weak cryptography in application code, or design weaknesses. A container image with a clean CVE scan can still be critically vulnerable through SQL injection, SSRF, or insecure direct object references. Comprehensive security requires both CVE scanning and application security testing (SAST, DAST, penetration testing).
A is wrong because modern vulnerability scanners like Trivy scan OS packages, programming language dependencies (npm, pip, Maven, Cargo), and application-level lock files — not just OS packages. The limitation is about CVEs versus application logic weaknesses, not about OS versus application layer.
C is wrong because this describes the remediation path difference, not the conceptual distinction. The question asks about the nature of the categories, not how they are fixed.
D is wrong because vulnerability and weakness have distinct technical meanings in security. CVEs (Common Vulnerabilities and Exposures) and CWEs (Common Weakness Enumeration) are separate classification systems maintained by MITRE with different purposes.