Security Architecture practice questions

Deploy a VPN concentrator and require all administrators to connect to the VPN before initiating SSH sessions directly to the servers.

Why wrong: This still allows direct SSH connections from the VPN network to the servers. While the VPN adds an authentication layer, it does not eliminate direct inbound SSH to the server; an attacker who compromises a VPN-connected laptop could reach the servers directly.

Replace SSH with a web-based console proxy that uses HTTPS and multi-factor authentication, and allow direct internet access to the console proxy on port 443.

Why wrong: While the console proxy removes SSH, it still exposes a service directly to the internet on port 443. Unless the proxy is placed behind the VPN, it remains an internet-facing attack surface. Moreover, a console proxy may not provide the same level of isolation as a managed jump server.

Configure each Linux server with a public IP address but restrict inbound SSH to the known public IP addresses of the administrators' corporate laptops.

Why wrong: This still exposes SSH directly to the internet, though restricted by IP. IP-based restrictions can be bypassed via IP spoofing, compromised laptops, or IP address changes. It does not eliminate direct inbound SSH and is considered a weaker security control.

Use server-side encryption with a cloud-managed key and restrict access with access control policies.

Why wrong: Server-side encryption with a cloud-managed key means the cloud provider holds the encryption key and automatically decrypts data for any user who satisfies the bucket policy. If the bucket becomes public, users with read access can retrieve the decrypted data, negating protection. This does not provide defense in depth against accidental public exposure.

Use default encryption with a cloud-managed key and enable storage access logging.

Why wrong: Default SSE-S3 encryption is equivalent to server-side encryption with a cloud-managed key. Enabling logging only provides detective capability; it does not prevent data exposure if the bucket is public. The data would be decrypted by the cloud provider for any authorized read request, exposing plaintext to anyone with read access.

Use server-side encryption with a customer-provided key and require MFA for delete operations on the stored objects.

Why wrong: SSE-C requires the client to supply the encryption key for each read request, so an attacker without the key cannot decrypt the data. However, this design relies on server-side encryption, meaning the cloud provider briefly processes the plaintext during upload. More importantly, the MFA requirement only protects against unauthorized deletion, not against unauthorized read access. Client-side encryption is a more robust defense in depth, as it ensures the cloud provider never has access to plaintext at any point.

Place the PLCs and office workstations on the same VLAN and rely on endpoint antivirus.

Why wrong: Placing PLCs and office workstations on the same VLAN collapses all security boundaries, allowing any compromised user device to directly reach industrial protocols such as Modbus/TCP or EtherNet/IP. Endpoint antivirus offers no protection against OT-specific exploits or network-based lateral movement, and legacy PLCs often lack the ability to run modern endpoint security agents. This flat architecture violates network segmentation principles and exposes critical production systems to the IT network's full threat landscape.

Publish the SCADA server through a public reverse proxy so vendors can reach it remotely.

Why wrong: Publishing a SCADA server through a public reverse proxy exposes a critical industrial control system to threats from the internet, including unpatched vulnerabilities in web interfaces or embedded services. Even with authentication, this significantly expands the attack surface and contradicts OT security best practices that mandate no direct internet exposure for production systems. Vendor remote access should instead be handled through a secured jump host or VPN with strict access controls, not by making the SCADA server reachable externally.

Put the PLCs on the same subnet as user devices and hide them behind NAT.

Why wrong: Putting PLCs on the same subnet as user devices and hiding them behind NAT provides no real security because NAT only modifies IP addresses and does not inspect or filter traffic. On the same Layer 2 segment, any user endpoint can directly send industrial protocol packets to PLCs, bypassing any possible access control. NAT gives a false sense of protection; proper segmentation requires VLAN separation with a stateful firewall enforcing strict rules between zones.

Create one shared partner account for each external company and reuse the same password.

Why wrong: Shared accounts remove individual accountability and make it hard to revoke one person without affecting everyone. They also create audit and least-privilege problems that are unacceptable for partner access.

Synchronize every partner user into the manufacturer’s directory and require a separate password change.

Why wrong: Directory synchronization creates local identity copies that the manufacturer must manage. That adds overhead and undermines the goal of avoiding local accounts for external partner users.

Store partner passwords in the portal database and use password reset emails for access control.

Why wrong: Storing passwords in the portal is a poor architecture for external identity management. It also does not provide the same trust relationship, centralized authentication, or maintainable partner lifecycle control as federation.

Create a separate local account for every partner employee and store the passwords internally.

Why wrong: Maintaining a separate local account for every partner employee forces the manufacturer to become the identity provider of record, meaning IT must manually provision, synchronize, and delete accounts as partner staff change. This duplicates the partner's own identity lifecycle, vastly increases the attack surface for credential compromise, and provides no real trust benefit because the manufacturer has no way to verify the employee's status beyond its own error-prone records.

Use a shared generic partner login for each company to simplify support.

Why wrong: Using a single generic partner login destroys individual accountability because every action taken through that shared account is attributed only to the partner company, not to a specific person. Audit logs become useless for forensic investigation, access revocation for a departing partner employee is impossible without changing the shared password for everyone, and the account becomes a standing credential that may be passed around and shared indefinitely.

Require partners to email screenshots of their credentials to request access.

Why wrong: Requiring partners to email screenshots of credentials is fundamentally insecure because it exposes secrets outside their intended environment, potentially in plain text over email infrastructure that may lack encryption at rest. It also provides no cryptographic proof that the user is who they claim to be, and screenshots can be easily forged or forwarded. This approach is neither scalable nor auditable for production access control, and it directly violates basic security policies around credential handling.

Convert the AP uplink to an access port in VLAN 40 and leave the AP to handle all traffic untagged.

Why wrong: Placing the uplink in access mode VLAN 40 forces the switch to strip any VLAN tags, so the AP would have to tag all guest and internal traffic itself—but APs expect a trunk for multi-SSID segmentation. The access port also places the AP's management interface into VLAN 40, directly exposing infrastructure to the guest broadcast domain. Proper segmentation requires a trunk carrying only the guest (40) and management (99) VLANs, not a single untagged VLAN.

Add the internal printer VLAN to the allowed list so the AP can filter client traffic itself.

Why wrong: Adding the internal printer VLAN to the allowed trunk list extends the Layer 2 broadcast domain to the AP, meaning wireless clients could reach printers directly if the AP fails to enforce filtering. Relying on AP-level filtering is weak isolation because the AP is not a security boundary; any misconfiguration or exploit bypasses it. The correct fix is to keep internal VLANs off this trunk entirely and segment guest traffic at the switch.

Keep the trunk settings and add a layer 3 ACL between the guest and internal networks.

Why wrong: A Layer 3 ACL filters traffic between VLANs only if the switch is routing and the ACL is enforced on the VLAN interfaces, but it does nothing to close the Layer 2 trunk misconfiguration. An auto-negotiated or misconfigured trunk can still deliver additional VLANs to the AP, allowing VLAN hopping or direct access to internal segments below Layer 3. The root cause is the trunk settings themselves, so the ACL is an incomplete control that leaves the network exposed.

Expose the switch web interface directly on a public IP address.

Why wrong: Directly attaching a switch's web-based management interface to a public IP address exposes it to internet-wide scanners within minutes, making it discoverable to opportunistic attackers. These embedded web servers often have default credentials, unpatched vulnerabilities, or weak session-management flaws that can be exploited to gain administrative control. Even with HTTPS, the interface itself becomes a login target for brute-force attempts and a pivot point for deeper network intrusion. Management interfaces should instead be isolated in a dedicated management VLAN, VRF, or behind a jump host with strict access-control lists.

Use FTP to transfer configuration files because it is simple.

Why wrong: FTP transfers configuration files and their associated credentials — such as hashed passwords, SNMP community strings, and routing details — in plaintext, allowing an eavesdropper to reconstruct the entire network configuration or extract sensitive data. While FTP seems simple, the risk to network integrity and confidentiality far outweighs any convenience. Secure file-transfer protocols like SFTP (SSH File Transfer) or SCP encrypt both the payload and authentication, providing a secure way to manage device backups without exposing the network's blueprint. In a remote administration context, using FTP would undermine the security already provided by SSH or VPN, because configuration data is just as sensitive as interactive sessions.

Send management passwords by email to approved admins.

Why wrong: Email is not encrypted end-to-end in transit and is stored in mailbox servers, archival systems, and backups in a way that admin credentials remain exposed long after the message is read. A single compromised mailbox, a rogue email-forwarding rule, or a man-in-the-middle intercept can leak a management password to unauthorized parties, violating least privilege and non-repudiation. Additionally, emailed passwords become difficult to revoke or track, especially if forwarded, and they do not support individual accountability for control-plane access. Administrative credentials should be delivered through privileged access management (PAM) tools with time-limited, one-time-use secrets, never through an informal, long-lived channel like email.

Network address translation

Why wrong: Network address translation (NAT) is a Layer 3/4 networking function that rewrites source or destination IP addresses in packet headers as traffic traverses a gateway, primarily to conserve public IPv4 address space or shield internal topology. NAT operates at the packet level and has no awareness of application-level user identities, authentication credentials, or session state. It cannot issue, validate, or propagate security tokens between applications, so it plays no role in enabling users to access multiple SaaS apps with a single login. NAT solves connectivity and addressing problems, not identity or access control problems.

Port forwarding

Why wrong: Port forwarding is a Layer 4 network technique that maps an external IP address and port to a specific internal IP address and port, allowing inbound traffic from the internet to reach a designated service inside a private network. It simply redirects TCP or UDP connections to a predetermined destination; it does not inspect, authenticate, or generate any identity-related information. Port forwarding cannot establish a session for a user across multiple applications because it lacks any authentication or authorization logic. It is purely a networking mobility mechanism, not an identity management control, and thus cannot support single sign-on.

Full-disk encryption

Why wrong: Full-disk encryption (FDE) protects data at rest by encrypting the entire storage volume of a device, requiring a pre-boot authentication factor such as a password, PIN, or TPM key to decrypt the disk. FDE is a local endpoint security control that safeguards against offline attacks, device theft, or data extraction from hard drives. However, it operates entirely within the device and does not communicate with cloud applications, central identity providers, or session management systems. FDE addresses confidentiality of stored data but has no ability to authenticate a user to multiple external services or manage credentials across applications.

Move the database server into the DMZ so the public proxy can reach it directly.

Why wrong: Moving the database server into the DMZ violates the principle of defence in depth by exposing the database directly to the reverse proxy on VLAN 10, removing the application server’s role as an intermediary that enforces business logic and validates queries. This is tempting because placing a database in a DMZ can reduce latency for read-heavy public APIs, but here the requirement is to keep backend tiers protected, which demands retaining the application server as a mandatory hop.

Allow inbound Internet access directly to the application server on 8443, but restrict the database.

Why wrong: Directly exposing the application server creates an unnecessary entry point from the Internet. Even if the database stays restricted, the application server becomes a target for scanning, exploitation, and web attack traffic that the reverse proxy could have absorbed.

Collapse all servers into one VLAN and rely on strong passwords for protection.

Why wrong: Consolidating the web, application, and database tiers into a single VLAN eliminates all network segmentation and allows any compromised front-end service to pivot laterally to backend data with no firewall or ACL boundary to cross. Strong authentication applies only at the host or application layer, but it does nothing to stop an attacker who exploits a vulnerable web-facing process from using that same process's identity or network path to reach the database directly. A flat architecture also increases the blast radius of ARP spoofing, DHCP starvation, or any Layer 2 attack, whereas separate private subnets with default-deny rules constrain an incident to a single tier.

Keep local administrator rights so users can recover faster.

Why wrong: Keeping local administrator rights on user accounts does not affect the pre-boot execution environment; firmware boot order and secure boot settings are managed outside the operating system. In fact, providing local admin rights can increase risk because malicious software could disable security tools, modify boot configurations, or install persistence mechanisms after the system has loaded. This option addresses convenience, not security, and is therefore both ineffective and potentially harmful.

Turn off disk encryption because it slows startup.

Why wrong: Disabling disk encryption would leave the data on the internal drive unencrypted, failing to address the scenario’s core requirement of preventing unauthorised boot media from loading before the OS starts. The boot-order vulnerability remains unchanged because encryption protects data at rest, not the pre-boot execution environment. This option is tempting because disk encryption is often recommended for data confidentiality, and it would be the correct choice if the threat were unauthorised physical access to read the drive’s contents after shutdown.

Move the laptops to a different subnet.

Why wrong: Moving the laptops to a different subnet alters only network addressing and routing, which occur after the operating system has booted. A local attacker with physical access can still insert a removable drive and boot from it because the firmware will process the device based on boot order, independent of IP or subnet placement. This measure does nothing to mitigate the pre-boot vulnerability described and is a clear non-solution.

ACLs: Prioritizes traffic to ensure performance.

Why wrong: This statement is incorrect because prioritizing traffic for performance is the job of Quality of Service (QoS) queuing and scheduling, not ACLs. An ACL determines whether a packet is permitted or denied based on the five-tuple (source IP, destination IP, protocol, source port, destination port); it can classify traffic into a class for QoS, but it does not itself guarantee bandwidth or reduce latency.

QoS: Translates private IP addresses to public IP.

Why wrong: This statement is incorrect because QoS does not translate IP addresses; it manages packet delivery quality by marking and queuing traffic. NAT is the process that rewrites source/destination addresses in the IP header, with PAT allowing many private addresses to share one public IP, whereas QoS only assigns priority markers like DSCP and schedules transmission order.

Rely on the cloud provider to automatically secure all guest operating systems and collect every log type by default.

Why wrong: The shared responsibility model makes the customer accountable for guest OS hardening and log configuration; cloud providers typically only offer default infrastructure-level logs, not all guest OS and application telemetry. Relying on default collection leaves critical security gaps and fails to meet regulated workload visibility requirements.

Move the workload to a private data center so the cloud provider can no longer access any telemetry.

Why wrong: Relocating to a private data center abandons cloud-native logging benefits and still requires building and maintaining a separate logging pipeline. This approach is unnecessarily disruptive, does not improve the logging architecture itself, and fails to address the requirement for centralized security visibility of the regulated workload.

Disable host logging and rely only on perimeter firewall logs to reduce storage costs.

Why wrong: Perimeter firewall logs only capture network-level activity and cannot provide visibility into guest OS events, user actions, or application-level anomalies. Disabling host logging destroys critical evidence needed for incident investigation and weakens the overall security monitoring posture.

Install extra consumer applications by default.

Why wrong: Installing extra consumer applications by default needlessly increases the attack surface by adding third-party code that may contain unpatched flaws, insecure dependencies, or overly permissive behaviors. These applications often lack centralized patch management and enterprise controls, creating additional endpoints for attackers to target and increasing the administrative burden for the IT team. A secure baseline should include only the minimal set of business-required software.

Allow users to disable endpoint protection whenever they want.

Why wrong: Endpoint protection, such as antivirus or Endpoint Detection and Response (EDR), acts as a critical control against malware execution and must not be disabled at the user's discretion. Permitting this would undermine the entire hardening effort, as a user could turn off the last line of defense and allow malicious code to run undetected, violating security policies and the principle of least privilege. If disabling is possible, the baseline is not truly enforced.

Delay firmware updates until devices fail.

Why wrong: Firmware vulnerabilities, including those in UEFI/BIOS, are especially dangerous because they can be exploited before the operating system fully loads, allowing adversaries to install persistent rootkits that survive OS reinstallation. Delaying firmware updates until a device fails leaves these low-level weaknesses exposed for months or years, and hardware failure rarely correlates with security risk. Firmware should be updated on a proactive schedule as part of the same patch management lifecycle used for software.

Move finance devices to the guest Wi-Fi network so they are separated from employees.

Why wrong: The guest Wi-Fi network is designed for untrusted visitors and typically provides only internet access, not connectivity to internal business resources. Finance devices placed there would lose access to the finance application and shared storage, and would be exposed to other guest clients that may be compromised or malicious. Guest networks also often lack per-device authentication and monitoring, making them an unsuitable trust zone for sensitive financial systems.

Keep the flat LAN but require stronger passwords on finance PCs and shared folders.

Why wrong: Stronger passwords address authentication weaknesses, such as weak or reused credentials, but a flat LAN allows every host to communicate freely at Layer 2 without any network inspection. A compromised user device can still perform ARP spoofing, scan the local subnet for vulnerable services, or access finance file shares using the already-authenticated session of a legitimate user. Password policy improvements do not stop malware from exploiting unpatched services or using protocol-level attacks that bypass credentials entirely, so the lateral movement surface remains unchanged.

Place all devices in one VLAN and rely on endpoint antivirus to stop spread.

Why wrong: Placing all devices in a single VLAN recreates a flat topology where traffic between hosts is switched without traversing a firewall or other filtering device, so a compromised endpoint can pivot directly to other systems. Endpoint antivirus is a host-based control that relies on signatures and behavior heuristics, which can be evaded by zero-day exploits or in-memory malware, and it does not inspect or block the network connections that enable lateral movement. Relying solely on AV also leaves the network blind to east-west traffic, whereas network segmentation and inter-VLAN ACLs provide a structural barrier that antivirus cannot replace.

Move all devices into one larger subnet and rely on endpoint antivirus for separation.

Why wrong: This removes any network-level containment and depends too heavily on endpoint detection after compromise occurs.

Place all devices behind a single proxy server and block all internal east-west traffic.

Why wrong: A proxy does not solve internal segmentation for printers and phones, and blocking all east-west traffic would break normal operations.

Enable port security on the switch and disable all VLAN tagging to reduce complexity.

Why wrong: Port security may help with some access control, but it does not provide the needed policy separation across device types.

Put the database on the same subnet as the web server for faster communication.

Why wrong: Placing the database on the same subnet as the web server eliminates network-layer segmentation, meaning an attacker who compromises the front-end can directly access the database without traversing a firewall or ACL. This violates the principle of defence in depth for backend isolation. The temptation arises because co-location reduces latency for database queries, and in a single-tier or tightly controlled internal application where all hosts are equally trusted, this design would be correct for minimising network overhead.

Allow every tier to communicate freely to simplify troubleshooting.

Why wrong: Open communication between tiers removes the barriers that segmentation is meant to provide. Troubleshooting convenience should not override basic isolation.

Use one flat VLAN for all three servers and rely on strong passwords.

Why wrong: A flat VLAN offers little containment if one system is compromised. Strong passwords help access control, but they do not replace network segmentation.

Give the same user broader administrative access to avoid delays.

Why wrong: Expanding the same user's administrative privileges actually increases the potential impact of a compromised account, as the attacker gains greater control over financial operations. The root issue is the lack of segregation and review, not insufficient access rights; granting broader access amplifies risk rather than mitigating it. This approach directly contradicts the principle of least privilege and weakens the security posture.

Allow the same role to perform both actions but log the activity after the fact.

Why wrong: Logging is a detective control that records activity after it occurs, but it does not prevent an unauthorized or fraudulent payment from being approved in the first place. It only provides evidence for post-incident investigation, which may be too late to stop financial loss. Preventative controls, such as separation of duties and independent approval, are required to block the action proactively.

Remove authentication so the process is faster.

Why wrong: Removing authentication eliminates the identity verification step, which directly contradicts the requirement to reduce fraud risk; without authentication, any user could impersonate the employee who creates and approves payment batches, leaving no audit trail. This option is tempting because authentication overhead can slow repetitive tasks, and in a low-risk internal tool where speed is paramount and all users are trusted, removing it might be considered to streamline workflow.

Put guests on the same VLAN as employees and rely on stronger Wi-Fi passwords.

Why wrong: Stronger Wi-Fi passwords only control who can associate with the network; they provide zero isolation after authentication. Placing guests on the same VLAN as employees puts them in the same Layer 2 broadcast domain, allowing direct access to internal hosts, ARP spoofing, and potential exploitation of trust relationships. A compromised or malicious guest device would have the same network privileges as corporate endpoints.

Disable SSID broadcast so guests cannot discover the network name.

Why wrong: Disabling SSID broadcast (hiding the network name) is a convenience feature, not a security control, because the SSID is still transmitted in probe responses and association frames and can be trivially discovered with passive monitoring. Even if a guest manually connects to the hidden SSID, they gain unrestricted access to the internal network just like any other client. This measure fails to enforce guest isolation or restrict traffic to sensitive resources.

Allow guest devices to use the same DHCP scope as internal endpoints.

Why wrong: Assigning guest devices addresses from the same DHCP scope as internal endpoints places them in the identical IP subnet, erasing any logical separation between trusted corporate machines and untrusted visitor devices. Because they share a subnet, guests can directly communicate with employees' workstations without traversing a router or firewall where ACLs could be applied, and DHCP also hands out internal DNS and gateway information. A secure guest network requires a distinct addressing scope so that routing policy and filtering can differentiate guest traffic.

Put the web, application, and database servers in the same flat VLAN so routing is simpler.

Why wrong: Placing all three tiers in a single flat VLAN eliminates network segmentation, so a compromise of the web server would allow direct lateral movement to the application and database servers without traversing a firewall or ACL-enforced boundary. This directly violates the requirement to reduce lateral movement. The approach is tempting because a flat VLAN simplifies routing and inter-server communication in low-security environments where all hosts are equally trusted, such as an internal lab or a non-critical application with no tiered access controls.

Give the database tier direct internet access for vendor patching and cloud backups.

Why wrong: Direct internet access for the database tier defeats the purpose of isolating sensitive data. Vendor updates and backups should be routed through controlled management paths or secure intermediary services. Exposing the database externally greatly increases risk without being necessary for the stated requirements.

Federation

Why wrong: Federation can support shared identity across organizations, but the question is about one sign-in for several apps.

Multi-factor authentication (MFA)

Why wrong: MFA adds another proof of identity, but it does not by itself remove repeated logins across apps.

Session timeout

Why wrong: A session timeout ends access after inactivity; it is not the same as reusing one login across systems.