Mobile Devices practice questions

A security analyst is evaluating a Kubernetes cluster for misconfigurations. Which TWO of the following are common Kubernetes misconfigurations that increase security risk? (Select the two best answers.)

Trap 1: Running containers as non-root user

Running as non-root is a hardening measure, not a misconfiguration; it reduces risk by limiting container privilege. It is tempting because root containers are genuinely dangerous, so the phrasing inverts the question. The stem asks for settings that increase risk, such as privileged mode or hostPath mounts.

Trap 2: Enabling Role-Based Access Control (RBAC)

RBAC restricts cluster access by binding roles to users and service accounts, so enabling it lowers risk rather than creating a misconfiguration. It is tempting because a permissive RBAC configuration is dangerous, but the option describes enabling the mechanism itself, not misconfiguring it.

Trap 3: Implementing network policies to restrict traffic

Network policies restrict pod traffic and are a recommended hardening control, so implementing them reduces risk rather than creating a misconfiguration. It is tempting because policies can be misconfigured, but the question asks for common misconfigurations, and this option describes the correct secure practice.

A
Running containers as non-root user
Why it fails: Running as non-root is a hardening measure, not a misconfiguration; it reduces risk by limiting container privilege. It is tempting because root containers are genuinely dangerous, so the phrasing inverts the question. The stem asks for settings that increase risk, such as privileged mode or hostPath mounts.
B
Using hostPath mounts
hostPath mounts bind a node's filesystem directory into a pod, breaking container isolation. A compromised pod can then read or write node files, including credentials and the kubelet configuration, escalating beyond its namespace and undermining the cluster's security boundary.
C
Using privileged containers
Privileged containers run with all Linux capabilities and direct host device access, effectively disabling container isolation. A breakout grants root on the node, so this misconfiguration sharply increases risk across the cluster's workloads and underlying infrastructure.
D
Enabling Role-Based Access Control (RBAC)
Why it fails: RBAC restricts cluster access by binding roles to users and service accounts, so enabling it lowers risk rather than creating a misconfiguration. It is tempting because a permissive RBAC configuration is dangerous, but the option describes enabling the mechanism itself, not misconfiguring it.
E
Implementing network policies to restrict traffic
Why it fails: Network policies restrict pod traffic and are a recommended hardening control, so implementing them reduces risk rather than creating a misconfiguration. It is tempting because policies can be misconfigured, but the question asks for common misconfigurations, and this option describes the correct secure practice.

Question 2mediummultiple choice

During a vulnerability assessment, a security analyst discovers that a network device is running an outdated firmware version with known exploits. The device is critical to production and cannot be rebooted during business hours. Which of the following is the BEST approach to remediate this vulnerability?

Trap 1: Apply the firmware patch immediately without rebooting

Attempting to apply a firmware patch immediately without rebooting is technically unfeasible because firmware resides in non-volatile memory and requires a system initialization cycle to load the new code. Furthermore, applying patches immediately to production systems without testing or scheduled downtime violates change management protocols and risks causing unplanned outages.

Trap 2: Implement a virtual patch via the IDS/IPS until a full patch is…

While implementing a virtual patch via an intrusion detection or prevention system (IDS/IPS) can mitigate risk, it is a temporary compensating control rather than a true remediation. Virtual patching only inspects network traffic for known exploit signatures and does not fix the underlying vulnerability in the firmware itself, leaving the system exposed to alternative attack vectors or local exploits.

Trap 3: Request a hotfix from the vendor that does not require a reboot

Requesting a rebootless hotfix from a vendor is impractical because custom hotfixes are rarely available on demand and still typically require a system restart to apply low-level code changes. Relying on this approach introduces unnecessary administrative delays and leaves the system vulnerable while waiting for a custom software package that may never be delivered.

A
Schedule the firmware upgrade during the next maintenance window
Scheduling the firmware upgrade during an established maintenance window is the best practice because it balances security remediation with operational continuity. Firmware updates modify low-level hardware instructions and almost always require a system reboot, which causes temporary downtime. Planning this during a scheduled window minimizes business disruption while ensuring the vulnerability is permanently resolved.
B
Apply the firmware patch immediately without rebooting
Why it fails: Attempting to apply a firmware patch immediately without rebooting is technically unfeasible because firmware resides in non-volatile memory and requires a system initialization cycle to load the new code. Furthermore, applying patches immediately to production systems without testing or scheduled downtime violates change management protocols and risks causing unplanned outages.
C
Implement a virtual patch via the IDS/IPS until a full patch is possible
Why it fails: While implementing a virtual patch via an intrusion detection or prevention system (IDS/IPS) can mitigate risk, it is a temporary compensating control rather than a true remediation. Virtual patching only inspects network traffic for known exploit signatures and does not fix the underlying vulnerability in the firmware itself, leaving the system exposed to alternative attack vectors or local exploits.
D
Request a hotfix from the vendor that does not require a reboot
Why it fails: Requesting a rebootless hotfix from a vendor is impractical because custom hotfixes are rarely available on demand and still typically require a system restart to apply low-level code changes. Relying on this approach introduces unnecessary administrative delays and leaves the system vulnerable while waiting for a custom software package that may never be delivered.

Question 3hardmulti select

A vulnerability scan of a segmented OT network must avoid disrupting fragile devices. Which controls are appropriate? (Choose two.)

Trap 1: Scan from random external hosts

Scanning from random external hosts introduces significant security and operational risks to a segmented OT network. Such uncontrolled access bypasses established security perimeters and could potentially expose critical industrial control systems to unauthorized entities, leading to unpredictable network behavior, system instability, or even safety hazards due to lack of oversight and proper authorization.

Trap 2: Run aggressive exploit checks without approval

Running aggressive exploit checks without prior approval is highly dangerous in an OT environment due to the inherent fragility and real-time operational demands of industrial control systems. These intrusive tests can trigger unexpected system shutdowns, disrupt critical processes, or even cause physical damage by exploiting vulnerabilities that may lead to uncontrolled equipment behavior, directly impacting safety and production continuity.

A
Use approved safe-check profiles or passive discovery where required
Using approved safe-check profiles ensures that vulnerability scans are configured with non-intrusive settings specifically designed for sensitive OT equipment, minimizing the risk of operational disruption. Passive discovery methods, such as network traffic analysis, further reduce impact by observing system behavior without direct interaction, which is crucial for maintaining the stability and safety of critical industrial control systems.
B
Scan from random external hosts
Why it fails: Scanning from random external hosts introduces significant security and operational risks to a segmented OT network. Such uncontrolled access bypasses established security perimeters and could potentially expose critical industrial control systems to unauthorized entities, leading to unpredictable network behavior, system instability, or even safety hazards due to lack of oversight and proper authorization.
C
Run aggressive exploit checks without approval
Why it fails: Running aggressive exploit checks without prior approval is highly dangerous in an OT environment due to the inherent fragility and real-time operational demands of industrial control systems. These intrusive tests can trigger unexpected system shutdowns, disrupt critical processes, or even cause physical damage by exploiting vulnerabilities that may lead to uncontrolled equipment behavior, directly impacting safety and production continuity.
D
Coordinate test windows and scope with OT owners
Coordinating test windows and the precise scope with OT owners is paramount to ensure that vulnerability scanning activities do not interfere with critical production cycles or safety protocols. This collaboration allows for scheduling during planned downtime, understanding system criticality, and implementing necessary precautions, thereby preventing operational disruptions and maintaining the safety and reliability of industrial processes.

Question 4easymulti select

A company is implementing a vulnerability management program. Which of the following are essential components of a vulnerability management lifecycle? (Choose three.)

Trap 1: Penetration testing on all systems.

Penetration testing on all systems is a separate, periodic, manual, and intrusive assessment activity typically performed annually or after major changes, distinct from the continuous, largely automated cadence of vulnerability scanning; the vulnerability management lifecycle does not require exhaustive pen testing of every asset as one of its defining phases.

Trap 2: Automated patch deployment.

Automated patch deployment is one specific mechanism used within the broader remediation phase, but it is a tool or technique rather than a standalone lifecycle stage, and not every remediation involves an automated patch; some fixes require manual configuration changes, compensating controls, or vendor workarounds that automated patching tools cannot apply.

A
Vulnerability scanning and assessment.
Vulnerability scanning and assessment is the core detection activity of the lifecycle, using authenticated or unauthenticated tools such as Nessus or Qualys to compare installed software and configurations against known CVEs, and it forms the recurring engine that feeds every downstream prioritization and remediation decision the program makes.
B
Discovery and inventory of assets.
Discovery and asset inventory must happen before scanning can be meaningful because an organization cannot assess vulnerabilities on systems it does not know exist; shadow IT, unmanaged cloud instances, and forgotten servers routinely evade scan scope precisely because they were never captured in the CMDB or asset inventory feeding the scanner's target list.
C
Penetration testing on all systems.
Why it fails: Penetration testing on all systems is a separate, periodic, manual, and intrusive assessment activity typically performed annually or after major changes, distinct from the continuous, largely automated cadence of vulnerability scanning; the vulnerability management lifecycle does not require exhaustive pen testing of every asset as one of its defining phases.
D
Remediation and verification.
Remediation and verification closes the loop by applying the fix, whether a patch, configuration change, or compensating control, and then rescanning the affected asset to confirm the vulnerability no longer appears, which is essential because a remediation step without verification cannot distinguish a genuinely closed finding from a false negative or an incomplete fix.
E
Automated patch deployment.
Why it fails: Automated patch deployment is one specific mechanism used within the broader remediation phase, but it is a tool or technique rather than a standalone lifecycle stage, and not every remediation involves an automated patch; some fixes require manual configuration changes, compensating controls, or vendor workarounds that automated patching tools cannot apply.

Question 5hardmulti select

A security analyst is reviewing a containerized application for vulnerabilities. The analyst uses a container image scanner and identifies several issues. Which THREE of the following are common container and Kubernetes misconfigurations that the analyst should prioritize? (Choose three.)

Trap 1: Keeping container images up to date

Keeping images current is a remediation control, not a misconfiguration to prioritise; the scanner flags stale base images and unpatched packages as findings. It is tempting because patch hygiene genuinely reduces container risk, and in a hardening checklist it would be the right answer.

Trap 2: Implementing network policies to restrict pod communication

Network policies restricting pod communication are a security control, not a misconfiguration to remediate; their absence is the finding. It is tempting because Kubernetes network policy is a hardening topic, but the question asks for weaknesses to prioritise, and implementing policies fixes rather than describes one.

A
Overly permissive RBAC configurations
Overly permissive RBAC bindings grant cluster-wide or wildcard permissions, letting a compromised workload escalate privileges or reach other namespaces. Auditing roles, ClusterRoleBindings and service accounts for excessive verbs and resources is a priority Kubernetes hardening check.
B
Keeping container images up to date
Why it fails: Keeping images current is a remediation control, not a misconfiguration to prioritise; the scanner flags stale base images and unpatched packages as findings. It is tempting because patch hygiene genuinely reduces container risk, and in a hardening checklist it would be the right answer.
C
Running containers with the 'privileged' flag
Running with the privileged flag disables container isolation, granting full access to host devices and kernel capabilities. This directly satisfies the stem's request for common Kubernetes misconfigurations worth prioritising, since a compromised privileged container effectively yields host-level control, escalating impact far beyond the application's intended scope.
D
Implementing network policies to restrict pod communication
Why it fails: Network policies restricting pod communication are a security control, not a misconfiguration to remediate; their absence is the finding. It is tempting because Kubernetes network policy is a hardening topic, but the question asks for weaknesses to prioritise, and implementing policies fixes rather than describes one.
E
Using hostPath mounts
hostPath mounts expose node filesystem directories inside the container, allowing reads or writes to host files such as credentials or the container runtime socket. This breaks isolation and enables node compromise, so it ranks as a priority misconfiguration.

Question 6mediummulti select

A security analyst is conducting a vulnerability assessment of a Kubernetes cluster. Which TWO of the following are common misconfigurations that could lead to security risks? (Select TWO.)

Trap 1: Setting resource limits on containers

Setting resource limits on containers constrains CPU, memory, and I/O usage, ensuring that a single compromised or misbehaving container cannot starve the host or neighboring containers of resources. This is a proactive hardening measure that mitigates denial-of-service and resource-exhaustion attacks. Far from being a vulnerability, it is a required security control in multi-tenant container environments.

Trap 2: Configuring network policies to restrict traffic

Configuring network policies to restrict traffic enforces a least-privilege model by defining which containers or pods can communicate with each other and with external endpoints. Without such policies, all inter-container traffic is typically allowed, expanding the blast radius of a compromise. Because this reduces the attack surface and limits lateral movement, it is a security best practice, not a risk.

Trap 3: Using read-only root filesystems

Using read-only root filesystems prevents any process inside the container from writing to the container image's root filesystem layer, which stops attackers from dropping malware or modifying critical executables and configuration files. It forces any required writes to be done through explicit ephemeral volumes, maintaining filesystem integrity. This is a well-known defensive hardening technique that reduces the impact of a compromised container, so it is not a vulnerability.

A
Setting resource limits on containers
Why it fails: Setting resource limits on containers constrains CPU, memory, and I/O usage, ensuring that a single compromised or misbehaving container cannot starve the host or neighboring containers of resources. This is a proactive hardening measure that mitigates denial-of-service and resource-exhaustion attacks. Far from being a vulnerability, it is a required security control in multi-tenant container environments.
B
Configuring network policies to restrict traffic
Why it fails: Configuring network policies to restrict traffic enforces a least-privilege model by defining which containers or pods can communicate with each other and with external endpoints. Without such policies, all inter-container traffic is typically allowed, expanding the blast radius of a compromise. Because this reduces the attack surface and limits lateral movement, it is a security best practice, not a risk.
C
Running containers in privileged mode
Running containers in privileged mode grants them every Linux capability, disables seccomp and AppArmor/SELinux confinement, and exposes all host devices, effectively removing isolation between the container and the host kernel. An attacker who exploits a vulnerability in a privileged container can trivially escalate to full host control, making it one of the most dangerous container misconfigurations. During a vulnerability assessment, this should immediately be flagged as a critical finding.
D
Using read-only root filesystems
Why it fails: Using read-only root filesystems prevents any process inside the container from writing to the container image's root filesystem layer, which stops attackers from dropping malware or modifying critical executables and configuration files. It forces any required writes to be done through explicit ephemeral volumes, maintaining filesystem integrity. This is a well-known defensive hardening technique that reduces the impact of a compromised container, so it is not a vulnerability.
E
Using hostPath mounts
Using hostPath mounts allows a container to directly access a directory on the host's filesystem, bypassing the container's filesystem isolation. If the mounted path is broad or sensitive (e.g., /, /etc, or /var/run/docker.sock), a compromised container can read or tamper with host files, leading to host takeover. This is a high-risk configuration that should be carefully audited and scoped to read-only, least-privilege paths during vulnerability assessment.