Infrastructure And System Security practice questions

MAC Sets

Why it fails: MAC sets filter traffic strictly at Layer 2 using hardware addresses, meaning they completely lack Layer 7 application-layer visibility and therefore cannot enforce identity-based application policies. They are tempting because administrators often seek low-level endpoint identifiers for granular isolation, and they would be the correct choice when securing legacy physical workloads or virtual machines that require static Layer 2 hardware address filtering independent of IP configurations.

Logical Ports

Why it fails: Logical ports are too granular and do not provide the abstract grouping required for application policies.

IP Sets

Why it fails: Relying on IP Sets fails in this scenario because they operate exclusively at Layers 3 and 4, grouping static IPv4 or IPv6 addresses rather than identifying Layer 7 application protocols or processes. Administrators often find them tempting because they provide a quick method for grouping legacy workloads or external endpoints that lack proper context metadata. Consequently, IP Sets would be the correct choice when defining perimeter or inter-segment firewall rules for static infrastructure where application-layer inspection and dynamic identity mapping are completely unnecessary.

VPC Flow Logs

Why it fails: VPC Flow Logs capture metadata regarding IP traffic flowing to and from network interfaces, but they function solely as a passive monitoring tool rather than an enforcement mechanism for granular access control. They lack the capability to intercept or block requests between microservices, which is essential for Zero Trust architectures. This option appears relevant because it provides visibility into network communication patterns, making it the correct choice for auditing traffic flows or troubleshooting connectivity issues within a VPC environment.

AWS WAF

Why it fails: AWS WAF operates at the application layer to filter HTTP/HTTPS traffic at the edge, making it incapable of enforcing identity-based mTLS or service-to-service authorisation policies within an EKS cluster. While it provides robust protection against common web exploits like SQL injection and cross-site scripting for public-facing endpoints, it lacks the internal service mesh integration required for granular microservice communication. Consequently, it fails to replace security groups for internal traffic control, as it cannot manage the identity-based authentication necessary for a Zero Trust architecture.

AWS App Mesh with Envoy sidecars

Why it fails: App Mesh uses Envoy proxies to manage traffic, providing identity-based security rather than network-layer security.

Enable Server-Side Encryption with KMS

Why it fails: Server-side encryption protects data at rest by rendering it unreadable without the appropriate cryptographic material, but it provides no mechanism to restrict network-level access or bucket visibility. While this feature is essential for meeting compliance requirements regarding data confidentiality and protection against physical storage theft, it does not act as an access control policy. Consequently, it fails to prevent unauthorized public access, which requires identity-based policies or bucket-level block public access settings to regulate request authorisation.

Use IAM users for all S3 interactions

Why it fails: Using IAM users is a best practice for identity, but does not inherently block public access configurations.

Use Row-Level Security (RLS) within the database engine.

Why it fails: Implementing Row-Level Security (RLS) within the database engine provides the most robust mechanism for ensuring data isolation at the application layer. By applying security predicates directly to database tables, RLS restricts access based on the authenticated tenant context, such as a tenant ID passed from Microsoft Entra ID. This approach enforces granular data separation at the storage level, preventing cross-tenant data leakage even if application-level queries are improperly constructed or compromised, thereby satisfying the requirement for rigorous multi-tenant isolation.

Use separate VPCs for every tenant.

Why it fails: Isolating tenants via separate Virtual Private Clouds operates at the network and infrastructure layers rather than providing the required application-layer segregation specified in the scenario. Deploying infrastructure-level boundaries does not control tenant data access within shared application logic, making it ineffective for Software as a Service multitenancy. However, this approach appeals because it provides strong hardware and network isolation, making it the correct choice for deploying dedicated tenant environments that require strict regulatory compliance or zero underlying physical resource sharing at the cloud infrastructure level.

Create separate database instances for every single tenant.

Why it fails: Provisioning separate database instances operates at the database or storage layer rather than the application layer requested by the question stem, failing to guarantee multi-tenant isolation directly within application logic. This approach is tempting because siloed databases offer the absolute highest degree of physical data segregation, making it the correct choice when strict regulatory compliance mandates zero risk of cross-tenant data co-mingling at the persistent storage level.

Unified Extensible Firmware Interface (UEFI) Secure Boot.

Why it fails: Unified Extensible Firmware Interface (UEFI) Secure Boot validates the digital signature of the primary bootloader and kernel to ensure the operating system has not been tampered with during startup, making it the correct choice when defending against rootkits and boot-level persistence. However, it fails to protect against side-channel attacks because it operates purely during the pre-boot and initialisation phases. It provides no memory isolation, cache partitioning, or runtime cryptographic protection against malicious co-habitants extracting data from shared hardware resources during active execution.

PCIe bus encryption.

Why it fails: PCIe bus encryption secures data-in-transit across the motherboard between host components, failing to protect against side-channel attacks like cache timing or memory bus contention that exploit shared microarchitectural resources between virtual machines. This feature is tempting because it safeguards physical server hardware from hardware-level interception and physical tampering, making it the correct choice when defending against malicious actors attempting to physically tap expansion buses or perform direct hardware-level bus snooping on compromised motherboards.

Trusted Platform Module (TPM) 2.0

Why it fails: Trusted Platform Module (TPM) 2.0 provides secure cryptoprocessor storage for platform integrity measurements and cryptographic keys, making it tempting when hardening a host against firmware tampering and boot-level compromise. However, it fails in this scenario because it measures and attests to boot state rather than monitoring or isolating dynamic microarchitectural execution paths, cache usage, or speculative execution vulnerabilities. TPM 2.0 would be the correct choice when verifying that a host's hypervisor and firmware have not been modified at startup.

SQL injection filtering.

Why it fails: SQL injection filtering defends against database manipulation by inspecting parameter strings for malicious SQL commands, making it tempting when securing data-driven applications. However, this feature fails to mitigate Broken Object Level Authorization because BOLA exploits logical flaws in user context validation rather than malformed input data. BOLA occurs when an API endpoint correctly processes a syntactically valid request for a specific object identifier, yet completely neglects to verify whether the authenticated session possesses authorization to access that particular resource.

DDoS rate limiting.

Why it fails: DDoS rate limiting is designed to restrict the volume of incoming requests to mitigate volumetric floods or brute-force automation. It is tempting because API endpoints are frequently targeted by automated scanning tools, making volume controls a standard hardening measure. However, it fails in this scenario because BOLA vulnerabilities occur when a user successfully authenticates and sends a legitimate, well-formed request referencing an object ID belonging to another user. Because the request rate is normal and the syntax is valid, volume-based thresholds will not inspect the object-level authorization context required to prevent horizontal privilege escalation.

Geo-blocking.

Why it fails: Geo-blocking restricts access based on geographic location, which appeals to administrators seeking to defend against automated credential-stuffing or volumetric DDoS attacks originating from high-risk regions. However, it fails to prevent Broken Object Level Authorization because BOLA vulnerabilities are logic flaws exploited by authenticated users manipulating object identifiers (such as sequential IDs) within valid API requests. Because the malicious requests originate from legitimate users inside permitted geographic zones, filtering by country of origin provides no protection against unauthorised data access targeting specific object resources.

Set up an AWS Config rule to delete buckets after creation.

Why it fails: Deleting buckets after creation fails to satisfy the requirement because it allows a window of vulnerability where data is exposed publicly before the remediation triggers. While AWS Config rules are effective for continuous monitoring and post-deployment compliance auditing, they operate asynchronously. This approach is useful for detecting drift in existing environments where you need to identify and remediate non-compliant resources that have already been provisioned, rather than enforcing preventative controls that block the initial request at the API level.

Configure individual IAM policies for every user.

Why it fails: Managing individual IAM policies fails to provide a preventative, account-wide enforcement mechanism, as users could still inadvertently or maliciously create public buckets if their specific policies lack explicit restrictions. While this approach is useful for implementing granular, least-privilege access control for specific developers or service accounts, it relies on manual maintenance rather than the automated, top-down governance provided by Service Control Policies or Control Tower guardrails. Consequently, it lacks the centralised, immutable oversight required to mandate compliance across an entire multi-account AWS environment.

Enable S3 Block Public Access at the account level.

Why it fails: Account settings can be modified by local admins; SCPs provide centralized enforcement.

Lack of encryption at rest.

Why it fails: Unencrypted cloud storage buckets expose sensitive data to unauthorised access if the underlying storage media or snapshots are compromised. Because shared buckets often rely on multi-tenant infrastructure, the absence of encryption at rest fails to provide the necessary cryptographic boundary between different users. This vulnerability directly addresses the risk of data exposure inherent in shared environments, where physical access controls are managed by the provider rather than the organisation, necessitating robust encryption to ensure confidentiality regardless of the storage layer's physical security posture.

Missing object versioning.

Why it fails: Failing to enable object versioning leaves data vulnerable to accidental deletion or malicious overwriting, as there is no historical record to facilitate recovery. In the context of shared cloud storage buckets, this configuration oversight directly satisfies the requirement to identify risks associated with data integrity and availability. Without versioning, a single compromised identity or erroneous script can permanently destroy critical assets, preventing administrators from reverting to previous states and thereby failing to maintain the necessary resilience against unauthorised or accidental modifications.

Allowing all traffic on all ports.

Why it fails: Permitting all traffic across every port completely negates the foundational security principle of defence-in-depth, which requires layered perimeter and internal network segmentation to restrict attacker lateral movement. Network administrators often configure permissive firewall rules to troubleshoot complex connectivity issues or diagnose dropped packets during initial application deployments. In a controlled, isolated diagnostic scenario, removing port restrictions temporarily isolates whether a network path is causing an application failure before stricter access control lists are reapplied.

Ignoring all logs.

Why it fails: Discarding all telemetry data blinds security operations to active breaches, destroying the visibility required to detect lateral movement across layered perimeters. Administrators are often tempted to suppress telemetry when overwhelmed by false positives from noisy legacy intrusion detection systems, seeking to reduce alert fatigue or conserve storage capacity. Such a measure would be appropriate only within an isolated, air-gapped test environment explicitly designed to evaluate baseline system performance under zero-load conditions, where external threat monitoring is intentionally decoupled from functional verification.

Data Filtering Profile

Why it fails: Data filtering is designed to prevent data exfiltration (DLP), not to inspect query logic for SQL injection.

URL Filtering Profile

Why it fails: URL Filtering profiles inspect HTTP and HTTPS traffic destined for web browsers to control access to malicious or unauthorised websites based on category, which fails to secure internal database traffic using SQL query inspection. This feature appears relevant because administrators frequently rely on Security Profiles for deep packet inspection, making it a tempting choice when attempting to mitigate application-layer vulnerabilities. However, URL Filtering operates exclusively on web browsing traffic parameters rather than database protocols or query syntax, meaning it cannot parse or restrict specific SQL commands. Protecting database zones against SQL injection requires a Vulnerability Protection Profile or WildFire configuration designed for database protocol decoding, rendering URL Filtering entirely ineffective for this internal database communication scenario.

App-ID based policy enforcement

Why it fails: App-ID identifies the application but does not inspect the payload content for SQL injection signatures.

Transit Secret Engine

Why it fails: The Transit Secret Engine acts as an encryption-as-a-service provider to encrypt and decrypt data in transit, making it tempting for general cryptographic operations and application-layer data protection. However, it fails in this scenario because it operates *after* initialization to handle application payloads, whereas splitting root keys to prevent single-administrator control requires configuring Shamir's Secret Sharing mechanism during the initialisation phase itself.

Token Authentication

Why it fails: Token authentication is a method for client access, not for cluster initialization or key management.

Auto-Unseal via AWS KMS

Why it fails: While this automates unsealing, it is a configuration choice for convenience, not the mechanism for key splitting.

Minimum Password Length

Why it fails: Minimum password length governs the complexity requirements for account credentials rather than controlling network authentication protocols or session authorisation. While administrators often configure this setting to bolster identity security and mitigate brute-force attacks against local accounts, it does not restrict the scope of remote access or lateral movement. This setting is exclusively concerned with credential entropy, whereas the requirement demands a policy that restricts the "Network logon" or "Deny access to this computer from the network" user rights assignments.

Audit Logon Events

Why it fails: Audit Logon Events merely records successful or failed authentication attempts within the security logs and provides no mechanism to restrict or block specific account types from establishing remote sessions. It is a monitoring and forensic tool used to track user access patterns or investigate security incidents. Administrators would select this setting when they need to maintain a compliance trail of who accessed a system, rather than when they must enforce technical access controls to prevent lateral movement between domain servers.

Account Lockout Threshold

Why it fails: Account Lockout Threshold governs the number of failed authentication attempts before an account is disabled, which fails to restrict the scope of administrative credentials across the network. While this setting is essential for mitigating brute-force attacks against user accounts, it does not manage the privilege boundaries required to prevent lateral movement. Administrators often confuse this with access control, yet it serves only as a reactive security measure against credential guessing rather than a proactive restriction on where specific accounts can authenticate.

Public IP address assignment for all internal nodes

Why it fails: Assigning public IP addresses to internal nodes exposes them directly to the internet, defeating the private-subnet design a VPN gateway exists to provide. It is tempting because VPN gateways themselves need public endpoints, but that requirement applies to the gateway, not to every internal node behind it.

Disabling logging to reduce overhead

Why it fails: Disabling logging undermines the auditability and incident response capabilities essential for maintaining a secure hybrid cloud perimeter, directly violating the requirement for comprehensive visibility across remote access sessions. While reducing logging overhead can minimise storage costs and performance latency in high-throughput environments where data retention policies are strictly governed by compliance frameworks, it is never a valid security strategy for remote access gateways. Security architectures must prioritise the capture of authentication and connection telemetry to detect unauthorised access attempts effectively.

Azure Monitor

Why it fails: Azure Monitor focuses on gathering and analysing telemetry data from operating systems and applications, such as performance counters and log analytics, but it does not natively deliver host-based intrusion detection or file integrity monitoring capabilities. It is tempting because it forms the foundational data collection layer for Azure environments and would be the correct choice when engineering a centralised logging and metric alerting pipeline for cloud workloads.

Network Watcher

Why it fails: Network Watcher focuses exclusively on network-level diagnostic and monitoring tasks such as IP flow verification, packet capture, and NSG flow logs, making it entirely incapable of providing host-based intrusion detection or file integrity monitoring. It is tempting because administrators frequently conflate cloud infrastructure monitoring with security tooling, assuming the platform's native diagnostic suite covers OS-level activities. Network Watcher would be the correct choice in a scenario requiring the diagnosis of network routing issues, verification of VM connectivity problems, or the analysis of traffic patterns between Azure virtual networks.

Azure Bastion

Why it fails: Azure Bastion is a fully managed PaaS service that provides secure Remote Desktop Protocol (RDP) and Secure Shell (SSH) connectivity to virtual machines directly over SSL without exposing public IP addresses. While it is tempting because administrators frequently need secure administrative access to hybrid workloads during migration projects, it functions strictly as a connectivity gateway rather than a security monitoring platform, meaning it cannot detect intrusions or perform file integrity monitoring.

iptables

Why it fails: Iptables operates as a packet-filtering framework within the Netfilter subsystem to manage network traffic based on IP addresses, ports, and protocols, whereas the question requires mandatory access control for kernel-level object mediation. While it is a fundamental tool for hardening server perimeters against unauthorised network access, it lacks the capability to enforce granular security policies on system processes or file system objects. Consequently, it fails to provide the mandatory access control mechanisms necessary to restrict subject permissions over system resources.

Auditd

Why it fails: Auditd functions strictly as a logging and auditing framework for tracking system calls and file access rather than enforcing mandatory access control policies. While it provides essential visibility into security events and is the primary tool for compliance monitoring or forensic analysis, it lacks the kernel-level hooks required to restrict process capabilities or define security contexts for objects. Administrators often confuse its role in security hardening with active enforcement, yet it remains a passive observation mechanism that cannot prevent unauthorised actions.

PAM

Why it fails: Pluggable Authentication Modules (PAM) operate at the user-space level to manage authentication, account management, and session configuration rather than enforcing kernel-level mandatory access control policies. While it is a fundamental component for controlling user access to system resources and verifying credentials during login, it lacks the capability to restrict process interactions or file system access based on security labels. It serves as the primary mechanism for integrating external identity providers, such as Microsoft Entra ID, into the Linux authentication stack.

Configure static route tables on all subnets to point to the firewall's ENI.

Why it fails: Static route tables fail to provide resilience because they lack the ability to perform health checks or failover if the specific Elastic Network Interface becomes unreachable. This approach creates a single point of failure, as traffic will drop if the appliance experiences an outage. While this configuration is functional for simple, static network topologies where high availability is not a primary requirement, it lacks the dynamic routing capabilities necessary to automatically reroute traffic through a secondary firewall instance in a fault-tolerant architecture.

Implement a transparent bridge on each EC2 instance in the destination subnet.

Why it fails: Configuring a transparent bridge on individual EC2 instances fails to provide a centralized inspection point, as it decentralises security enforcement and creates significant management overhead across the fleet. This approach is tempting because it mimics host-based intrusion detection systems designed for granular, per-instance traffic filtering within a specific workload. It would be the correct choice when implementing micro-segmentation or deep packet inspection directly on a single host to protect against lateral movement in environments where network-level traffic redirection is technically unsupported.

Utilize AWS Transit Gateway with route tables that hairpin traffic to a security VPC.

Why it fails: Transit Gateway hairpinning introduces unnecessary latency and complexity for intra-VPC traffic, as it forces internal packets to traverse the gateway and back, violating the requirement for a direct, high-performance inspection path. This architecture is designed for hub-and-spoke topologies requiring inter-VPC connectivity or hybrid cloud integration, where centralized traffic management across multiple accounts or regions is essential. While it effectively centralises security policy enforcement for distributed network segments, it remains an architectural mismatch for simple subnet-to-subnet traffic inspection within a single VPC.

Traditional VPN

Why it fails: Traditional VPNs grant broad network-level connectivity, failing to provide the granular, per-application micro-segmentation required for Zero Trust architectures. While they remain a standard solution for establishing encrypted tunnels to extend a corporate network perimeter for legacy remote access, they lack the identity-aware proxy capabilities necessary to enforce access policies based on individual application resources. Consequently, they cannot restrict user sessions to specific applications, exposing the wider internal network to potential lateral movement threats that modern Zero Trust frameworks aim to eliminate.

Network Perimeter Firewall

Why it fails: Network perimeter firewalls operate at the network layer, filtering traffic based on IP addresses and ports rather than granular application-level identities or specific user context. While these devices remain essential for securing the network edge and blocking unauthorised inbound traffic at the infrastructure boundary, they lack the deep packet inspection capabilities required to enforce Zero Trust policies. They are useful for traditional perimeter-based security models, but they cannot perform the identity-aware authorisation necessary to manage access to individual applications for a remote workforce.

Internet Gateway

Why it fails: An Internet Gateway attaches to a public subnet and routes traffic to the internet, requiring the instance to hold a public address or sit behind NAT, so private database instances gain no outbound path. It is tempting as the standard internet access component, but it is correct for public subnets hosting internet-facing resources.

VPC Endpoint

Why it fails: Deploying a VPC endpoint fails here because endpoints only facilitate private connectivity to specific supported AWS services or endpoint services, whereas downloading general operating system patches requires arbitrary outbound internet access to external vendor repositories. This option is tempting because it establishes secure, non-internet routing to AWS resources without an internet gateway, making it the correct choice when database instances need to interact privately with services like Amazon S3 or DynamoDB without traversing the public internet.

Egress-Only Internet Gateway

Why it fails: An Egress-Only Internet Gateway provides outbound-only connectivity for IPv6 traffic; it does not serve IPv4, so IPv4 patch downloads from the private subnet fail. It is tempting because its name matches the outbound-only requirement, but it is correct only when the subnet uses IPv6 addressing.

Implement IPsec tunnels between all application servers.

Why it fails: IPsec tunnels encrypt traffic between specific server pairs but require per-host configuration and key management, not transparent service-to-service encryption without code changes. It is tempting because it provides strong network-layer encryption, and would be correct for site-to-site links between known gateways.

Hardcode SSL libraries into each application binary.

Why it fails: Embedding TLS libraries directly into application binaries fails this scenario because it requires extensive modification of application code, violating the explicit negative constraint in the stem. Developers often consider hardcoding cryptographic controls when attempting to establish strict endpoint-to-endpoint confidentiality without relying on external network infrastructure. This approach would be appropriate in a standalone, legacy desktop application lacking a sidecar proxy layer, where transport-layer security must be managed entirely within the local process boundary.

Deploy a global VPN concentrator for all intra-datacenter traffic.

Why it fails: Deploying a global virtual private network concentrator secures data in transit across network perimeters, making it tempting for legacy network-level encryption designs. However, it fails this scenario because it encrypts traffic at the subnet or site level rather than transparently intercepting and securing local service-to-service communication at the host or container level. A VPN concentrator operates at Layer 3 to tunnel entire network segments without providing the fine-grained, identity-based micro-segmentation and sidecar proxy interception required for zero-trust architectures within a hybrid environment.

HSRP

Why it fails: HSRP is a first-hop redundancy protocol that provides a virtual IP and default gateway for hosts; it does not synchronise connection state between ASA failover peers. It is tempting because HSRP also delivers gateway redundancy, but it would be correct for host default-gateway resilience, not stateful firewall failover.

OSPF

Why it fails: OSPF is a dynamic routing protocol that exchanges reachability information between layer-3 devices; it carries no connection-state or translation tables between ASA failover units. It is tempting because OSPF is configured on firewalls for routing, but it would be correct when advertising networks, not maintaining failover state.

VRRP

Why it fails: VRRP is a first-hop redundancy protocol electing a master router for a virtual IP; it does not replicate stateful session data between ASA primary and standby. It is tempting because VRRP also provides gateway failover, but it would be correct for host gateway redundancy, not firewall state synchronisation.