Security practice questions

Infrastructure mode WLAN; configure a laptop as a software access point.

Why it fails: Infrastructure mode WLAN inherently relies on a central access point (AP) to manage connections and forward data between devices. While configuring a laptop as a software access point can create this central point, it still functions as an intermediary, routing all traffic. This contradicts scenarios where direct, peer-to-peer communication without any central device, even a temporary software one, is desired for simplicity or lack of dedicated hardware.

PAN network using Bluetooth; all laptops pair via Bluetooth.

Why it fails: A Personal Area Network (PAN) using Bluetooth is designed for connecting a small number of personal devices over very short distances, typically less than 10 meters. While it can facilitate file transfers, its limited throughput (speed) and restricted number of simultaneous connections (often 7 active devices in a piconet) make it impractical for efficiently sharing files among multiple laptops. Wi-Fi-based solutions offer significantly greater range, speed, and scalability for such a task.

Mesh network; each laptop acts as a node forwarding traffic.

Why it fails: A mesh network requires each laptop to forward traffic for others, but the scenario demands direct file sharing without any central access point or router. This fails because mesh nodes still rely on routing protocols and multi-hop forwarding, which introduces complexity and dependency on intermediary devices. It is tempting because mesh networks are designed for decentralised, ad-hoc connectivity in environments lacking infrastructure, such as disaster recovery sites, where they would be the correct choice for resilient, self-healing communication.

Enable Legacy Boot (CSM)

Why it fails: Enabling Legacy Boot, also known as Compatibility Support Module (CSM), allows the UEFI firmware to emulate a traditional BIOS environment. This permits booting from older operating systems and bootloaders that do not support UEFI or Secure Boot, often lacking digital signature verification. Consequently, CSM would permit the execution of unsigned boot code, directly contravening any security policy requiring bootloader signature validation.

Enable TPM

Why it fails: Enabling the Trusted Platform Module (TPM) provides hardware-based security features such as cryptographic key generation, storage, and platform integrity measurements. While TPM can be used in conjunction with Secure Boot for advanced features like BitLocker drive encryption and remote attestation, its primary function is not to directly verify the digital signatures of bootloaders. TPM ensures the integrity of the system state after the bootloader has loaded, rather than enforcing the signature validation during the boot process itself.

Set boot order to network first

Why it fails: Setting the boot order to network first merely dictates the sequence in which the system attempts to load an operating system from various storage devices or network sources. While it can be useful for network installations or diskless workstations, modifying the boot order does not implement or enforce any security policies regarding the digital signatures of bootloaders. The system would still attempt to boot whatever it finds first in the specified order, regardless of its signature status, unless Secure Boot is also enabled.

Infrastructure as a Service (IaaS)

Why it fails: Infrastructure as a Service (IaaS) delivers fundamental computing resources such as virtual machines, storage, and networks over the internet. In an IaaS model, the user is responsible for installing and managing operating systems, middleware, and applications. Therefore, it does not provide a ready-to-use, fully functional CRM application directly, but rather the foundational components upon which a CRM could be built and managed by the user.

Platform as a Service (PaaS)

Why it fails: Platform as a Service (PaaS) provides a complete development and deployment environment in the cloud, including operating systems, programming language execution environments, databases, and web servers. While PaaS significantly simplifies application development and deployment by abstracting away infrastructure management, it does not offer a pre-built, fully functional business application like a CRM. The user must still develop, deploy, and manage their own application on the provided platform.

Desktop as a Service (DaaS)

Why it fails: Desktop as a Service (DaaS) provides users with a virtualized desktop environment hosted in the cloud, accessible from various devices. This service focuses on delivering a full desktop experience, including the operating system and potentially pre-installed productivity applications, rather than a specific business application like a CRM as a standalone service. While a CRM application could certainly run within a DaaS environment, DaaS itself is the delivery of the desktop, not the specific business application.

Enable Fast Boot

Why it fails: Enabling Fast Boot primarily optimizes the boot process by skipping certain hardware initialization steps or resuming from a hibernation state, rather than performing a full cold boot. While this feature reduces startup time, it offers no mechanism for verifying the digital signatures of bootloaders or operating system components. Therefore, it fails to enhance system security against malicious code during the critical startup phase.

Enable Legacy Boot

Why it fails: Enabling Legacy Boot, also known as Compatibility Support Module (CSM), allows the system to boot using traditional BIOS-style methods, which predates and bypasses the UEFI Secure Boot process. This configuration explicitly permits the execution of bootloaders and operating systems that are not digitally signed or verified. Consequently, it introduces a significant security vulnerability by allowing potentially malicious or unauthorized code to run at startup.

Enable Boot from USB

Why it fails: Enabling "Boot from USB" merely configures the system's boot order to prioritize a USB device as a potential startup source, which is useful for installing operating systems or running diagnostic tools. This setting does not implement any security verification mechanisms for the boot process itself. It does not prevent unauthorized code from executing if a malicious USB drive is used, as it is solely a boot source selection, not a security feature.

Enable Fast Boot

Why it fails: Fast Boot, also known as Quick Boot or Ultra Fast Boot, is a UEFI setting that optimizes the boot process by skipping certain hardware initialization steps, such as memory tests or USB device enumeration, during startup. While it can reduce the time it takes for the system to reach the operating system, enabling it does not inherently prevent or facilitate booting from a specifically chosen USB device. It primarily affects the speed of the internal boot sequence, not the ability to select an external boot source.

Set SATA mode to RAID

Why it fails: Setting the SATA mode to RAID (Redundant Array of Independent Disks) configures how the system's SATA controller interacts with connected storage devices, specifically for creating disk arrays. This setting is entirely concerned with the management and performance of internal hard drives or solid-state drives, not with the selection or enablement of external boot devices like a USB drive. Changing the SATA mode would not impact the ability to boot from a USB.

Disable the TPM

Why it fails: The Trusted Platform Module (TPM) is a dedicated microcontroller designed to secure hardware by integrating cryptographic keys into devices. Its primary functions include generating, storing, and limiting the use of cryptographic keys, as well as platform integrity measurements for features like BitLocker drive encryption. Disabling the TPM would not affect the system's ability to recognize or boot from an external USB device, as it is unrelated to boot order or device enumeration.

The smartphone's Wi-Fi antenna is damaged.

Why it fails: A damaged Wi-Fi antenna would universally impair the smartphone's ability to send and receive wireless signals, affecting connectivity across all networks, not just the office Wi-Fi. If the device connects successfully at home, the antenna is likely functional, indicating a problem specific to the office network configuration or the device's settings for that network.

The office Wi-Fi router is out of range.

Why it fails: If the office Wi-Fi router were truly out of range, other devices in the same location would also experience connection difficulties or complete signal loss. Since other devices connect without issue, the signal strength is adequate for the area, ruling out range as the primary cause for this specific smartphone's inability to connect.

The smartphone's IP address is static and conflicting.

Why it fails: A static IP address conflict typically manifests as intermittent network connectivity issues or an inability to access network resources *after* successfully connecting to the Wi-Fi network, rather than preventing the initial Wi-Fi association and authentication entirely. Furthermore, modern networks with DHCP are designed to prevent such conflicts, and if one occurred, it wouldn't necessarily stop the device from associating with the access point.

A hub

Why it fails: A hub operates at Layer 1 of the OSI model, functioning as a multi-port repeater that simply broadcasts all incoming traffic to every other port. It has no intelligence to understand network segments, MAC addresses, or IP addresses, making it incapable of creating or routing traffic between VLANs. Therefore, a hub cannot facilitate communication between different logical networks.

A Layer 2 switch

Why it fails: A Layer 2 switch operates at the data link layer and can segment a network into multiple VLANs based on MAC addresses, providing isolation between broadcast domains. While it efficiently forwards frames within the same VLAN, it lacks the necessary Layer 3 routing capabilities to interpret IP addresses and route packets between distinct IP subnets, which is fundamental for inter-VLAN communication. Without an external router or a Layer 3 routing function, a Layer 2 switch cannot connect different VLANs.

A bridge

Why it fails: A bridge is a Layer 2 device that connects two separate network segments, forwarding frames based on MAC addresses to extend a single broadcast domain. While it can filter traffic between segments, it does not possess the advanced capabilities of a Layer 2 switch to create multiple VLANs, nor does it have any Layer 3 routing functionality. Consequently, a bridge cannot route traffic between different VLANs or IP subnets.

Replace the Ethernet cable.

Why it fails: Replacing the Ethernet cable is an inappropriate first step when the link light is already green. A green link light indicates that a valid physical connection (Layer 1) has been established between the computer and the network device, confirming the cable is physically functional. DHCP issues typically stem from problems at higher layers (Layer 2 or 3), making a cable replacement an unlikely solution for a device that already shows a physical link.

Reboot the DHCP server.

Why it fails: Rebooting the DHCP server is an unnecessary and disruptive action if other devices on the network are successfully obtaining IP addresses. The fact that other clients are functioning correctly indicates the DHCP server itself is operational and capable of assigning leases. Troubleshooting should focus on the specific client or the network path between the client and the server, rather than impacting all network users by restarting a functional core service.

Set a static IP address on the computer.

Why it fails: Setting a static IP address on the computer would bypass the DHCP issue but does not resolve the underlying problem preventing dynamic IP assignment. This approach merely circumvents the symptom and could introduce new issues, such as IP address conflicts if the chosen static IP is already in use or falls within the DHCP server's scope. Proper troubleshooting aims to restore the automated DHCP service for reliable network management.

The tablets have the wrong date and time set.

Why it fails: While an incorrect date and time setting on the tablets could potentially lead to certificate validation failures by making a valid certificate appear expired or not yet valid, it is not the most fundamental issue preventing secure authentication in this scenario. Certificate validation checks the validity period against the device's clock. However, if the root CA certificate is entirely absent from the trusted store, the device cannot establish a trust relationship with the authentication server, making date/time a secondary concern.

The tablets are using WPA2-Personal instead of WPA2-Enterprise.

Why it fails: WPA2-Personal (PSK) relies on a shared passphrase for authentication, whereas WPA2-Enterprise utilizes 802.1X with a RADIUS server for individual user or device authentication, often involving certificates. If the technician has already verified the security settings, it implies they have correctly configured the tablets for WPA2-Enterprise. Attempting to use WPA2-Personal would result in an immediate authentication failure due to mismatched security protocols, which would likely be a more obvious and immediate error than a certificate trust issue.

The tablets have a static IP configured that conflicts with the DHCP scope.

Why it fails: An IP configuration conflict, such as a static IP address clashing with the DHCP scope, would typically manifest *after* a device has successfully authenticated to the network and attempted to obtain or use an IP address. Network authentication (e.g., 802.1X) occurs at Layer 2 (Data Link Layer) to grant access to the network. Only once authenticated does the device proceed to Layer 3 (Network Layer) to acquire an IP address, making this issue irrelevant to the initial authentication failure.

The printer is not responding to ARP requests.

Why it fails: Ping succeeding proves ARP resolution works, since ICMP requires the printer's MAC address; ARP failure would prevent all communication. It is tempting because ARP faults do cause unreachable hosts, and checking ARP is correct when a device on the local subnet cannot be pinged at all.

The printer's TCP/IP stack is misconfigured.

Why it fails: A misconfigured TCP/IP stack would break basic connectivity, yet ping succeeds, proving IP addressing and routing work. It is tempting because stack faults do cause broad network failures, and checking TCP/IP configuration is correct when a device cannot communicate at all, even by ICMP.

The print server is using the wrong port number.

Why it fails: A wrong port would block the print job but would not stop IPsec negotiation, and ping already confirms reachability. It is tempting because port mismatches commonly break print services, and verifying the port is correct when jobs fail while the network path and security association are healthy.

Set each AP to a different channel to avoid interference

Why it fails: Setting each Access Point (AP) to a different, non-overlapping channel (e.g., 1, 6, 11 for 2.4 GHz) is crucial for minimizing co-channel interference and improving overall network performance. However, this configuration alone does not actively force client devices to roam or disconnect from a weak AP. Clients often "stick" to an AP until its signal becomes critically low, even if a much stronger signal from another AP on a different channel is available.

Enable WPA3 encryption on all APs

Why it fails: Enabling WPA3 encryption on all Access Points (APs) significantly enhances wireless network security by providing stronger authentication and encryption protocols compared to older standards like WPA2. While essential for protecting data privacy and integrity, encryption mechanisms like WPA3 operate at a different layer of the network stack and do not directly influence a client device's decision-making process regarding when to roam or associate with a different AP. It solely secures the connection, not manages its handoff.

Configure the APs with different SSIDs for each AP

Why it fails: Configuring each Access Point (AP) with a unique Service Set Identifier (SSID) would effectively create multiple distinct wireless networks. For seamless roaming, client devices expect to see the same SSID across all APs within the extended network, allowing them to transition without re-authentication. Using different SSIDs would force clients to manually disconnect from one network and then discover and connect to another, completely disrupting any attempt at a smooth roaming experience.

The fiber cable is damaged

Why it fails: A damaged fiber cable, such as a break or severe bend, would typically prevent the physical layer from establishing a link. This would manifest as the port status being 'down' or 'notconnect', indicating a lack of physical connectivity or light signal. The 'err-disabled' state, however, is a logical shutdown imposed by the switch's operating system in response to a specific policy violation, not a physical layer fault.

A duplex mismatch exists between the switches

Why it fails: A duplex mismatch occurs when one side of a link operates in full-duplex mode while the other operates in half-duplex. This condition leads to severe performance degradation, high collision counts, and excessive frame errors, as devices attempt to transmit simultaneously or wait unnecessarily. While it significantly impairs network communication, a duplex mismatch does not typically trigger the 'err-disabled' state; instead, the port remains logically 'up' but experiences severe operational issues.

The VLAN configuration is incorrect

Why it fails: An incorrect VLAN configuration, such as assigning a port to the wrong VLAN or misconfiguring trunking, would primarily result in traffic not being forwarded to the intended destination or devices being unable to communicate with others in their expected broadcast domain. While this causes significant connectivity issues, the port itself would typically remain in an 'up' state. VLAN misconfigurations do not trigger the switch's err-disabled security mechanism, which is reserved for specific policy violations.

USB-C to HDMI adapter

Why it fails: A USB-C to HDMI adapter is designed exclusively for transmitting high-definition digital video and audio signals from a USB-C enabled device to an HDMI display. While USB-C supports DisplayPort Alternate Mode, which can be converted to HDMI, this adapter contains no network interface controller (NIC) hardware and therefore cannot provide an Ethernet network connection. Its sole function is display output, making it unsuitable for establishing wired network connectivity.

USB-C to USB-A adapter with a USB Ethernet dongle

Why it fails: Using a USB-C to USB-A adapter with a USB Ethernet dongle introduces an additional USB-A conversion layer that the tablet’s single USB-C port may not support for Ethernet, as many tablets lack the necessary USB host controller drivers for that daisy-chained topology. This option is tempting because it is a common solution for connecting Ethernet to a laptop that has a USB-A port, and it would be correct if the tablet had a USB-A port instead of only USB-C.

USB-C to DisplayPort adapter

Why it fails: A USB-C to DisplayPort adapter is specifically engineered to output video and audio signals from a tablet's USB-C port, utilizing DisplayPort Alternate Mode, to a monitor or projector that supports DisplayPort input. Similar to HDMI, DisplayPort is a digital display interface standard and fundamentally lacks any integrated circuitry or protocol for establishing a wired Ethernet network connection. Its function is solely for visual output, not network communication.

SSH

Why it fails: Secure Shell (SSH) is a cryptographic network protocol for operating network services securely over an unsecured network. It is primarily used for remote command-line interface (CLI) access, enabling secure execution of commands and file transfers between systems. While SSH is encrypted by default, making it secure for its intended purpose, it does not provide a full graphical desktop experience, which is typically what a technician would be looking for when auditing for remote graphical control vulnerabilities.

Telnet

Why it fails: Telnet is an application protocol used to provide a bidirectional interactive text-oriented communication facility using a virtual terminal connection. Critically, Telnet transmits all data, including usernames and passwords, in plaintext, making it highly vulnerable to eavesdropping and interception. Like SSH, Telnet only offers command-line access and does not support a graphical user interface, rendering it unsuitable for remote graphical control and a significant security risk if found active in an audit.

FTP

Why it fails: File Transfer Protocol (FTP) is a standard network protocol used for the transfer of computer files between a client and server on a computer network. Its sole purpose is to facilitate the uploading and downloading of files, often without encryption unless FTPS is used. FTP does not provide any remote control capabilities, either graphical or command-line, making it irrelevant for a security audit specifically looking for unauthorized remote control access to systems.

Update the UEFI firmware to the latest version from the manufacturer.

Why it fails: Updating the UEFI firmware to the latest version from the manufacturer can introduce support for newer hardware or features, including potentially a TPM module if it wasn't previously recognized. However, a firmware update alone does not automatically enable the TPM; it merely provides the capability. The TPM must still be manually activated within the UEFI's security settings after the update is complete.

Disable the integrated graphics to free up resources for TPM.

Why it fails: Disabling integrated graphics to 'free up resources' for the Trusted Platform Module is incorrect because TPM operates as a distinct hardware component or a firmware module within the system's security architecture. Integrated graphics, conversely, is a separate processing unit dedicated to display output. These components do not share or compete for the same system resources in a manner where disabling one would benefit the other's functionality or availability.

Set the SATA controller to RAID mode.

Why it fails: Setting the SATA controller to RAID mode primarily configures how storage drives are managed, enabling features like data striping for performance or mirroring for redundancy across multiple disks. This setting, whether RAID, AHCI, or IDE, exclusively pertains to the storage subsystem's operation and has no functional relationship or impact on the Trusted Platform Module. TPM is a security chip or firmware module entirely separate from disk controller configurations.

Secure Print (PIN release)

Why it fails: Secure Print (PIN release) is an access control feature designed to prevent unauthorized individuals from physically collecting printed documents from the MFP's output tray. While it holds print jobs in a queue until a user authenticates with a PIN at the device, this mechanism primarily controls access to the *output* and does not encrypt the print job data itself while it is stored on the MFP's internal hard drive awaiting release. Therefore, it does not protect data at rest from physical access to the storage medium.

IPsec for network printing

Why it fails: IPsec (Internet Protocol Security) for network printing encrypts data as it traverses the network from the user's computer to the MFP. This protects the confidentiality and integrity of print jobs *in transit*, safeguarding against eavesdropping or tampering during network transmission. However, once the print job data arrives at the MFP and is spooled to its internal hard drive for processing, IPsec's encryption is no longer applied, leaving the data vulnerable if the drive is physically removed or accessed directly.

User authentication via LDAP

Why it fails: User authentication via LDAP (Lightweight Directory Access Protocol) integrates the MFP with a centralized directory service, requiring users to log in with network credentials before accessing printing, scanning, or copying functions. This provides robust access control, ensuring that only authorized users can operate the device and submit jobs. However, LDAP authentication does not encrypt the actual print job data once it is spooled and stored on the MFP's internal hard drive, meaning it does not protect data at rest from direct physical access to the storage.

Use a higher category cable like Cat6a to extend the distance.

Why it fails: Using a higher category cable like Cat6a does not inherently extend the maximum allowable distance for standard Ethernet deployments beyond 100 meters. While Cat6a offers improved performance for higher bandwidths and reduced crosstalk, the 100-meter (328 feet) limitation is a fundamental specification defined by the IEEE 802.3 standards for twisted-pair copper Ethernet, primarily due to signal attenuation and timing constraints. Upgrading cable category alone will not overcome this physical limitation without active devices.

Use a single-mode fiber optic cable instead.

Why it fails: While single-mode fiber optic cable can certainly overcome significant distance limitations, it is not a direct or simple replacement for a Cat6 copper installation in this context. Implementing fiber would necessitate a complete change in infrastructure, requiring specialized fiber optic transceivers, media converters at both ends to interface with copper-based devices, and different installation tools and expertise. This approach introduces additional complexity and cost compared to extending the existing copper infrastructure.

The cable run is acceptable because Cat6 supports up to 150 meters.

Why it fails: The assertion that a Cat6 cable run is acceptable up to 150 meters is incorrect according to industry standards. For Fast Ethernet (100BASE-TX), Gigabit Ethernet (1000BASE-T), and 10 Gigabit Ethernet (10GBASE-T) over unshielded twisted-pair (UTP) copper cabling, the maximum segment length is strictly defined as 100 meters (328 feet) by the IEEE 802.3 standards. Exceeding this length significantly increases the risk of signal degradation, packet loss, and unreliable network performance.

Configure each VM with a different MAC address

Why it fails: Configuring each virtual machine with a different MAC address does not provide any network isolation. While MAC addresses are unique identifiers essential for Layer 2 communication, they do not inherently segment network traffic or prevent VMs on the same broadcast domain from communicating. VMs with different MACs can still freely interact if they reside on the same logical network segment.

Use bridged networking for all VMs

Why it fails: Utilizing bridged networking for all virtual machines connects them directly to the physical network adapter of the host, placing them on the same network segment as the host and other physical devices. This configuration makes all VMs part of the same broadcast domain, allowing them to communicate freely with each other and the external network without any inherent isolation. It essentially bypasses any virtual network segmentation capabilities.

Assign each VM a static IP address from a different subnet

Why it fails: Assigning each virtual machine a static IP address from a different subnet, while a Layer 3 segmentation technique, does not provide true network isolation at Layer 2. If all VMs are still connected to the same virtual switch and broadcast domain (e.g., the same VLAN), they can still communicate via a configured default gateway or router that bridges these subnets. Effective isolation requires Layer 2 separation, such as VLANs, to prevent direct communication before Layer 3 routing is even considered.

Enable Secure Boot and set a UEFI administrator password.

Why it fails: Enabling Secure Boot ensures that only digitally signed operating system boot loaders and drivers are allowed to execute, preventing malicious software from hijacking the boot process. However, Secure Boot does not inherently remove or disable external boot devices from the UEFI boot order. If a USB drive or other external media is still listed as a bootable device, an attacker could potentially boot from it, bypassing the installed OS. A UEFI administrator password protects the settings, but it doesn't prevent booting from an enabled external device if the attacker gains physical access and the device is still in the boot order.

Set the boot mode to Legacy BIOS and disable USB support.

Why it fails: Switching the boot mode to Legacy BIOS does not inherently prevent booting from external devices; many older systems still support USB booting in this mode, depending on the specific BIOS configuration. Furthermore, completely disabling USB support within the BIOS would render essential peripherals like keyboards and mice non-functional, making the workstation unusable for legitimate purposes. This approach is overly restrictive and does not achieve the specific goal of preventing unauthorized boot attempts while maintaining system functionality.

Enable the TPM and set a power-on password.

Why it fails: A Trusted Platform Module (TPM) is primarily designed for cryptographic functions, such as securely storing encryption keys and performing platform integrity checks (attestation), not for controlling the boot order or preventing external device booting. While a power-on password prevents unauthorized users from booting the system at all, it does not specifically prevent an authorized user (or an attacker who bypasses the password) from booting from an external device if it remains enabled in the boot order. The TPM and power-on password do not address the core vulnerability of booting from unauthorized media.

Restore the entire VM from the snapshot

Why it fails: Restoring the entire VM from a snapshot would overwrite the current operating system disk and any changes made since the snapshot was taken, leading to potential data loss on the OS drive itself. This action would also necessitate a full VM reboot, causing significant downtime for all services running on the virtual machine, which is disproportionate when only a single data disk is affected.

Download the snapshot to an on-premises server and then upload it

Why it fails: Downloading a large block-level snapshot to an on-premises server and then re-uploading it back to the cloud is highly inefficient and impractical. This process would incur substantial data transfer costs, introduce significant latency due to WAN bandwidth limitations, and consume excessive time, completely bypassing the cloud provider's native, optimized recovery mechanisms for disk restoration within their infrastructure.

Use the snapshot to create a new VM and then copy files via network

Why it fails: Creating a new VM from the snapshot and copying files over the network introduces unnecessary latency and data transfer costs, whereas the correct method directly attaches the snapshot as a managed disk to the existing VM, avoiding the overhead of a second VM and network copy. This option is tempting because creating a new VM from a snapshot is a standard disaster-recovery procedure when the original VM is corrupted or unavailable, but here the original VM remains intact and only its data disk needs restoration.