A payment application's web tier needs only HTTPS from the load balancer and must reach the app tier on one TCP port, and the app tier reaches the database on one port. The security team wants a workload policy that limits lateral movement if any tier is compromised. Which policy model should it apply?
Select an answer to reveal the explanation.
Short Explanation
An allowlist is a guest list: if your name's not on it, you don't get in, no matter how harmless you look. For workloads, you permit only the required flows and deny the rest, so a compromised web server can't wander to the database. The trap is a denylist — you can never list every bad thing an attacker might try.
Full Explanation
Zero-trust microsegmentation for workloads uses an allowlist model: the policy explicitly permits only the flows an application needs, defined by source, destination, port and protocol, and denies all other traffic by default. In this application that means the load balancer to the web tier on HTTPS, the web tier to the app tier on its one port, and the app tier to the database on its one port. If an attacker compromises the web tier, they cannot reach the database directly or scan other workloads, because no rule permits those paths. A denylist blocks only what has been identified as bad and allows everything else, so an attacker using an ordinary port or an unlisted address moves freely; it inverts the trust model. A flat segment that trusts everything inside the application is the traditional perimeter model and provides no containment once any tier is breached. A perimeter IPS inspects north-south traffic at the edge, which is useful for inbound attacks but leaves east-west movement between tiers unrestricted. Exam caveat: allowlists depend on accurate flow discovery, which is why products such as Secure Workload pair dependency mapping with enforcement. Operational check: after enforcing the policy, attempt a connection from the web tier directly to the database port and confirm it is dropped and logged.