Security Architecture practice questions

Place both the web server and the database server in the same DMZ segment and rely on host-based firewalls for protection.

Why wrong: Placing the database server in the same DMZ as the web server exposes it to any attacker who compromises the web server, and host-based firewalls can be misconfigured or bypassed. The database should be in a more secure internal zone.

Connect both servers to a single internal VLAN and use a reverse proxy to forward external traffic to the web server.

Why wrong: Putting both servers on the same internal VLAN removes network segmentation. If the web server is compromised, the attacker gains direct access to the database. A reverse proxy helps protect the web server but does not isolate the database.

Use a site-to-site VPN to connect the web server and database server, and place both behind a single NAT gateway.

Why wrong: A site-to-site VPN is typically used to connect separate networks securely, not to segment internal resources. Placing both behind NAT still exposes the database if the web server is breached, because there is no firewall rule limiting database access to only the web server.

Least privilege

Why wrong: Least privilege is partially applied because the firewall restricts communication to only necessary ports and sources, but the overarching design philosophy is the combination of multiple, overlapping controls, which is defense in depth.

Separation of duties

Why wrong: Separation of duties involves dividing critical administrative tasks among multiple people to prevent fraud or error. It does not apply to network topology or firewall rules.

Zero trust

Why wrong: Zero trust requires that no entity is inherently trusted and that every access request must be authenticated and authorized. In this design, the web servers are implicitly trusted to initiate connections to the internal servers once the firewall rule is in place, which does not fully align with zero trust principles.

Implement a next-generation firewall and require all remote traffic to pass through it with strict rules.

Why wrong: A next-generation firewall provides deep packet inspection and policy enforcement, but still operates at the network layer. Remote users who authenticate are granted network-level access, which does not align with the zero trust principle of granting access only to specific applications on a per-session basis.

Deploy a secure web gateway and require all remote users to browse through a proxy.

Why wrong: A secure web gateway (SWG) primarily secures web traffic and can enforce URL filtering and malware inspection. It does not replace the need for application-specific access control and still allows broad network access after authentication, which is contrary to zero trust's micro-segmentation requirement.

Enable multi-factor authentication for VPN and implement a VPN concentrator with split tunneling.

Why wrong: Multi-factor authentication strengthens the authentication step, but once the MFA challenge is passed, the VPN still grants full network-layer access to the LAN. Split tunneling can even expose the internal network to additional risks. This does not satisfy the zero trust requirement of granular, per-resource access control.

Trusted Platform Module (TPM)

Why wrong: A TPM provides hardware-based secure storage for cryptographic keys and platform attestation, but it does not isolate runtime memory or processes from the OS or hypervisor.

Hardware Security Module (HSM)

Why wrong: An HSM is a specialized device for managing cryptographic keys and performing cryptographic operations, but it is not designed to run arbitrary application code in isolated memory enclaves.

UEFI Secure Boot

Why wrong: Secure Boot ensures that only digitally signed boot loaders and operating system kernels are executed during the startup process. It does not provide runtime isolation for applications.

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.

A stateless network ACL that allows inbound traffic from the ALB's subnet only.

Why wrong: Stateless network ACLs require explicit rules for both inbound and outbound traffic. This adds administrative complexity and is more prone to misconfiguration than a stateful security group. While it could work, it is not the best practice for this requirement because security groups offer a simpler, stateful solution that can reference the ALB's security group directly.

A web application firewall (WAF) that inspects all traffic for SQL injection.

Why wrong: A WAF inspects HTTP/HTTPS traffic at the application layer to detect and block attacks like SQL injection or cross-site scripting. It does not control network-level access or filter traffic based on source IP/security group; it is a complementary security control, not a replacement for network-layer filtering.

A host-based firewall on each web server that allows traffic from the ALB's private IP address.

Why wrong: A host-based firewall can be used, but it requires manual configuration on each server and does not leverage the cloud provider's built-in security group functionality. It is also harder to manage at scale compared to security groups, making it a less optimal choice for this scenario.

Place all servers in the same VLAN and apply a host-based firewall on the database server.

Why wrong: Placing all servers in the same VLAN creates a flat network where any server can potentially communicate with the database server. This would include the web and application servers in the PCI DSS scope because they are on the same network segment and can directly connect to cardholder data, increasing the assessment scope.

Encrypt all data in transit using TLS and at rest using AES-256.

Why wrong: Encryption is a mandatory PCI DSS requirement for protecting cardholder data, but it does not reduce the scope of the assessment. The systems that handle encrypted data are still in scope because they process and store the data, even if encrypted. Scope reduction requires network segmentation, not encryption alone.

Implement network intrusion detection systems on all network segments.

Why wrong: Intrusion detection systems are detective controls and do not change which systems are in scope for PCI DSS. They can help with security monitoring but do not provide the architectural isolation needed to reduce the cardholder data environment.

Use server-side encryption with a cloud-managed key (SSE-S3) and restrict access with bucket 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 (SSE-S3) and enable bucket 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 (SSE-C) and require MFA for delete operations on the bucket.

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 CDE servers on a separate subnet within the same VLAN as the corporate network, and rely on host-based firewalls on each server to deny all traffic except from specific administrative IP addresses.

Why wrong: This design uses a shared VLAN and relies solely on host-based firewalls. A shared VLAN means the CDE servers are on the same Layer 2 broadcast domain as the corporate network; a network misconfiguration or compromised device could allow lateral traffic to bypass host firewalls. Host-based firewalls are less robust than network-level isolation, making this option insecure.

Place the CDE servers on a separate VLAN with a Layer 3 switch that uses ACLs to allow only ICMP traffic from the corporate network to the CDE for monitoring, and require administrators to physically connect to the CDE network via a dedicated console server.

Why wrong: While this uses VLAN separation, the ACL only permits ICMP, which is insufficient for administration (no SSH/RDP). Requiring physical console access is impractical for routine updates and monitoring, and it does not support remote management. This design fails to meet the business requirement.

Connect the CDE servers directly to the internet through a web application firewall (WAF), and require all management access to occur through a cloud-based VPN with two-factor authentication.

Why wrong: Directly connecting the CDE to the internet exposes it to external threats, even with a WAF. CDE servers should never be directly internet-facing. While a VPN adds encryption, the design violates the principle of network isolation required by PCI DSS, significantly increasing the attack surface.

Implement MAC address filtering on the guest SSID to allow only authorized guest devices.

Why wrong: MAC address filtering can be easily bypassed by an attacker who discovers an allowed MAC address, and it does not provide any Layer 3 isolation between the guest and corporate networks.

Disable SSID broadcast for the guest network to make it less discoverable.

Why wrong: Disabling SSID broadcast is a weak security measure that only hides the network name from basic scans. It does not prevent attackers from discovering the network using more advanced tools, and it provides no isolation from the corporate network.

Require guests to accept a captive portal agreement before gaining internet access.

Why wrong: A captive portal only enforces policy acceptance or authentication; it does not create network-level separation. Without VLAN segmentation, a guest device could still potentially access internal resources if routing is not restricted.

Security Information and Event Management (SIEM)

Why wrong: SIEM systems collect, aggregate, and analyze log data to generate alerts, but they do not natively automate response actions. Manual analysis and response are typically required.

Endpoint Detection and Response (EDR)

Why wrong: EDR solutions focus on endpoint monitoring and can perform automated responses like isolating a system, but they lack broader orchestration capabilities across multiple security tools and systems.

Cloud Access Security Broker (CASB)

Why wrong: CASBs are designed to enforce security policies for cloud services, such as access control and data loss prevention, not to automate response to general security threats across the enterprise.

ACLs

Why wrong: Incorrect. ACLs filter traffic based on Layer 3/4 criteria (IP addresses, ports) but do not provide the fundamental Layer 2 separation required; they can complement VLANs but are not the primary technology for segmentation.

DMZ

Why wrong: Incorrect. A DMZ is a network architecture for hosting public-facing services with restricted access; it is not a technology for enforcing Layer 2 isolation between internal networks.

VPN

Why wrong: Incorrect. VPNs establish encrypted tunnels for remote access or site-to-site connectivity over untrusted networks; they do not provide Layer 2 segmentation within a local network.

Add more allow rules from VLAN 10 to VLAN 30 for SMB and RDP so restore jobs stay flexible.

Why wrong: Additional allow rules increase the attack path from user systems into the backup network.

Move the backup server into the user VLAN to avoid routing and ACL complexity.

Why wrong: Putting backups in the same zone as users removes separation and makes compromise easier to spread.

Increase the DHCP lease time so backup jobs run less often during business hours.

Why wrong: DHCP timing has no meaningful effect on lateral movement or the security of backup repositories.

Enable FTP so administrators can upload and download configuration files securely.

Why wrong: FTP is not encrypted, so it does not protect management credentials or session data in transit.

Open the management interface to any internet host as long as the password is complex.

Why wrong: A strong password does not prevent interception or reduce the exposure created by public management access.

Use one shared local administrator account for all network engineers.

Why wrong: Shared accounts harm accountability and do not improve the security of the remote management channel.

Open SSH directly to each switch on a public IP address and restrict access by source IP only.

Why wrong: Source IP filtering helps somewhat, but exposing management services directly to the internet increases attack surface. It also does not satisfy the goal of keeping management interfaces off the public network.

Allow HTTPS management to each switch over the internet because the channel is encrypted.

Why wrong: Although HTTPS is encrypted, the management interface would still be exposed directly to the internet. That increases risk and conflicts with the requirement to avoid public exposure of management ports.

Use Telnet inside the office and route home users through a split-tunnel VPN.

Why wrong: Telnet is unencrypted and unsuitable for administrative access. Split tunneling can also expose management traffic to less controlled paths, which is the opposite of the secure remote-access goal described.

Allow rooted devices if the antivirus app is current.

Why wrong: Rooted devices weaken platform trust and can bypass many mobile security controls.

Place all apps in one shared profile and use a single passcode for every user.

Why wrong: Shared profiles blur data boundaries and make selective wipe and accountability much harder.

Disable remote wipe so personal photos are never affected.

Why wrong: Disabling remote wipe prevents the organization from responding effectively to lost or compromised devices.

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

Why wrong: A flat VLAN increases exposure and does not enforce trust boundaries between operational and office devices.

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

Why wrong: A public reverse proxy exposes critical industrial systems to internet-facing risk and is unnecessary for internal-only communication.

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

Why wrong: NAT obscures addresses but does not provide meaningful internal segmentation or access control between device groups.

Use LDAP directory synchronization for all partner users.

Why wrong: LDAP synchronization copies identities, but it does not provide the browser federation model described.

Use NTLM pass-through authentication to each partner account.

Why wrong: NTLM is not a modern federation method and is poorly suited to external partner integrations.

Use PAP over TLS so the portal can collect partner passwords securely.

Why wrong: Collecting partner passwords directly undermines federation goals and creates unnecessary credential handling risk.

Use the provider's default managed encryption keys for the storage service.

Why wrong: Provider-managed keys reduce customer control over key lifecycle and do not best support independent revocation.

Rely on security groups and network ACLs to protect the document contents.

Why wrong: Network controls restrict traffic, but they do not control whether encrypted files can be decrypted.

Enable automated snapshots so deleted files can be restored later.

Why wrong: Snapshots help with recovery, but they do not address access control for decrypting sensitive data.

Place all three servers on the same private subnet and control access only with strong passwords.

Why wrong: A shared subnet does not enforce tier separation. Strong passwords protect accounts, but they do not prevent a compromised web server from directly reaching the database server on the same network.

Put the database in the public zone so the web tier can query it directly from the internet.

Why wrong: Databases should not be internet-facing in this architecture. Exposing the database directly would greatly increase risk and bypass the intended layered protection between the tiers.

Use a single reverse proxy for all three servers and disable network segmentation to simplify management.

Why wrong: A reverse proxy can help front-end traffic, but it does not replace network segmentation. Disabling segmentation removes the protective boundaries that prevent unnecessary lateral movement between tiers.