Select Two (Multi-Select) Questions

--dry-run

Why wrong: --dry-run is a client-side flag that prints the Kubernetes object that would be created without actually sending it to the API server. It is often paired with -o yaml or -o json to output the manifest for review or further editing. It neither accepts nor processes secret data from a file; it merely simulates the operation, so it is not an argument for specifying file content and does not contribute to creating a secret from a file.

--from-literal

Why wrong: --from-literal is used to supply secret data directly as key=value pairs on the command line (e.g., --from-literal=password=secret). It does not read an external file's contents at all, so it cannot fulfill the requirement of creating a secret from a file. This flag is intended for inline, ad-hoc values rather than file-based input, making it incorrect for this specific scenario.

--from-yaml

Why wrong: --from-yaml is not a recognized flag for kubectl create secret; the valid data-source flags are --from-file, --from-literal, and --from-env-file. There is no built-in support for reading a YAML file directly as a secret source via this subcommand. To create a Secret from a YAML manifest, you would use kubectl apply -f on a Secret manifest rather than a creation flag, so --from-yaml is simply invalid.

audit

Why wrong: Not a standard AppArmor mode for profiles.

allow

Why wrong: Not a valid AppArmor mode.

unconfined

Why wrong: Unconfined means AppArmor is not applied; it is a state rather than a mode for a loaded profile.

Enable the AuditDynamicConfiguration feature gate

Why wrong: This allows dynamic reconfiguration but does not address retention or tamper-proofing.

Deploy Fluentd to forward logs to a central Elasticsearch cluster

Why wrong: Forwarding does not guarantee immutability.

Set --audit-log-maxbackup=10 and --audit-log-maxsize=100

Why wrong: These flags control rotation, not retention duration or tamper-proofing.

ResponseDelay

Why wrong: Not a valid stage.

ResponseComplete

Why wrong: ResponseComplete is a valid audit stage, but it is not one of the two correct answers. The correct two are A and E.

RequestProcessing

Why wrong: Not a valid stage.

Authentication

Why wrong: Authentication is not an audit stage; it occurs before auditing.

Authorization

Why wrong: Authorization is not an audit stage; it occurs after authentication.

ResponseReceived

Why wrong: ResponseReceived is not a standard audit stage; the correct stage is ResponseComplete.

RequestSent

Why wrong: RequestSent is not a standard audit stage; it does not appear in the official documentation.

Panic

Why wrong: Panic is a valid audit stage that occurs when the server recovers from a panic.

ResponseFinished

Why wrong: ResponseFinished is not a valid audit stage; the correct stage is ResponseComplete.

RequestProcessing

Why wrong: RequestProcessing is not a valid audit stage; the correct stage is RequestReceived.

Clair

Why wrong: Clair is a vulnerability scanner, not an SBOM generator.

kubesec

Why wrong: Kubesec performs static security analysis of Kubernetes resource manifests by evaluating them against a built-in set of risk policies, but it never inspects the filesystem layers or package metadata of a container image, so it cannot enumerate the software components required for an SBOM. It is tempting because its name suggests a security tool for containers, and in a scenario requiring Kubernetes manifest security auditing, Kubesec would be the correct choice.

Snyk

Why wrong: Snyk is a vulnerability scanner; it can generate SBOM as part of its features but is not primarily known for that. The common answer is syft.

Kata Containers use the host kernel for system calls.

Why wrong: Kata Containers never rely on the host kernel for system call handling; instead, each VM runs an independent guest kernel (for example, a patched Linux kernel) that services all syscalls from the containerized workload. This is a core difference from gVisor, which intercepts syscalls in user space, and from native containerd/runc containers, which call the host kernel directly. Because the guest kernel is isolated by the VM, a syscall issued inside a Kata container cannot reach the host kernel, which is precisely what enables hardware-level isolation.

gVisor runs containers in separate VMs for each pod.

Why wrong: gVisor does not use virtual machines at all; it runs as a normal user-space process on the host, with each container sandboxed by runsc and the Sentry in a separate thread group. Unlike Kata Containers, which leverage a hypervisor to create lightweight VMs, gVisor's isolation is purely at the system-call interface, not at the hardware level. Therefore, the claim that gVisor runs containers in separate VMs is categorically false and confuses its syscall-intercepting design with hardware virtualization.

Both gVisor and Kata Containers require RuntimeClass to be used in Kubernetes.

Why wrong: RuntimeClass is a convenient Kubernetes mechanism for selecting a non-default runtime such as gVisor or Kata, but it is not a strict requirement. You can configure containerd, CRI-O, or another CRI to use these runtimes as the default runtime or as an additional runtime handler, and then reference them via runtimeClassName when needed. However, if a cluster's standa.rd runtime is already set to gVisor or Kata, Pods may run without any RuntimeClass object or field at all, proving that RuntimeClass is optional, not mandatory.

allow { condition }

Why wrong: `allow { condition }` is a common rule name in generic OPA policies for expressing authorization decisions, but it is not a valid construct inside a Gatekeeper ConstraintTemplate. Gatekeeper's policy engine does not search for an `allow` rule when evaluating a constraint; it specifically looks for a rule named `violation`. Even if this rule's condition holds, it produces no constraint violations and has zero effect on admission control or audit results, making it a silent no-op.

deny[{"msg": msg}] { condition }

Why wrong: A `deny[{"msg": msg}] { condition }` rule is used in some older or custom OPA authorization frameworks to collect denial reasons, but Gatekeeper's ConstraintTemplate runtime ignores any rule that is not called `violation`. The Rego code may compile successfully, but Gatekeeper only instantiates and evaluates the `violation` partial set from the template's `targets` section. Consequently, a `deny` rule never triggers constraint enforcement, leaving the policy completely ineffective.

audit { condition }

Why wrong: `audit { condition }` is not a recognized Rego rule construct inside Gatekeeper ConstraintTemplates; audit is a separate component of Gatekeeper that periodically re-evaluates constraints using the same `violation` rule. Naming a rule `audit` produces a valid Rego rule that compiles, but Gatekeeper does not treat it specially — it does not run an audit check based on a rule's name. Since neither the admission webhook nor the audit controller consumes an `audit` rule, the condition never influences policy outcomes.

warn[{"msg": msg}] { condition }

Why wrong: Although `warn[{"msg": msg}] { condition }` might sound plausible because Gatekeeper supports warning-level enforcement, the Rego rule name must always be `violation`; warning behavior is controlled by the constraint's `enforcementAction` field, not by naming a rule `warn`. Gatekeeper's evaluation contract looks for a partial set named `violation` and uses its content to decide whether to apply the configured enforcement action. Therefore, a `warn` rule is never invoked by the policy engine, so the constraint will silently produce no violations or warnings.

Use a ConfigMap volume with defaultMode 0444

Why wrong: Setting defaultMode on a ConfigMap volume only affects file permissions; the volume is still writable unless mounted with readOnly: true. Even with readOnly: true, only that specific volume is read-only, not the container's root filesystem.

Set readOnly: true on a hostPath volume mount

Why wrong: Setting readOnly: true on a hostPath volume mount only restricts writes to that specific hostPath directory or file when the container accesses it. The container's own root filesystem, which is built from the image and provides the operating system and application binaries, remains completely writable, so an attacker could still modify other directories such as /etc or /tmp. This option is therefore narrowly scoped to a single volume and does not achieve a read-only container root filesystem.

Mount an emptyDir volume with readOnly: true

Why wrong: Mounting an emptyDir volume with readOnly: true makes only that particular emptyDir mount point read-only for the container; the emptyDir itself is just an ephemeral directory, not the container's root filesystem. The root filesystem, which is the writable layer over the container image, remains writable and is unaffected by this volume mount. Thus, this approach fails to restrict writes to the container's own filesystem and does not satisfy the requirement of a read-only container filesystem.

Audit

Why wrong: Audit is not a valid AppArmor profile mode. Audit is a flag that can be added to a profile to audit specific rules, but it is not a mode itself. Therefore, option A is incorrect.

Disabled

Why wrong: Disabled is not a valid AppArmor profile mode. Disabled refers to a state where AppArmor is not enabled for a process, but it is not one of the profile modes. Therefore, option B is incorrect.

Unconfined

Why wrong: Unconfined is not one of the AppArmor profile modes. In AppArmor, the two operational modes are enforce and complain, which dictate how the kernel reacts to policy violations. Unconfined describes a process that has no AppArmor profile loaded at all, meaning the kernel applies no AppArmor restrictions to it. It is a status reported by tools like aa-status, not a mode that you can specify within a profile or when loading one; confusing it with a mode is a common mistake.

Adding annotation 'container.apparmor.security.beta.kubernetes.io/<container>'

Why wrong: This is for AppArmor, not seccomp.

Including 'seccomp' profile in PodSecurityPolicy

Why wrong: PodSecurityPolicy is deprecated and removed in v1.25.

Including 'seccompProfile' under 'spec.securityContext' at the pod level

Why wrong: seccompProfile is a container-level field, not pod-level.

Set the kubelet flag --authentication-token-webhook=true

Why wrong: This enables token review but does not disable anonymous access.

Enable the NodeRestriction admission controller

Why wrong: NodeRestriction limits node self-updates to the API server, but does not secure the kubelet API.

Modify the kube-apiserver manifest to set --anonymous-auth=false

Why wrong: This affects the API server, not the kubelet's anonymous access.

Audit

Why wrong: Audit is not a mode; it is a flag.

Disable

Why wrong: Disable is not a mode; unconfined is used to disable.

Permissive

Why wrong: Permissive is not an AppArmor term.

Expose the host network to containers for better performance

Why wrong: Exposing host network increases attack surface.

Run containers as root to simplify permissions

Why wrong: Running as root increases risk; use non-root users.

Immediately delete the pod to stop the attack

Why wrong: Deleting the pod destroys evidence and may not stop the attack if the attacker has persistence.

Run kubectl exec to investigate the container's state

Why wrong: Running commands inside the container may alert the attacker or alter evidence.

Load all kernel modules to support any workload

Why wrong: Unnecessary kernel modules increase attack surface.

Enable SSH access for all users for troubleshooting

Why wrong: SSH should be limited to authorized users only.

Allow containers to run as root

Why wrong: Running as root increases risk of privilege escalation.