A retail chain tags checkout terminals as POS-SG and its database servers as Servers-SG. Only TCP 443 traffic may leave POS-SG for Servers-SG; everything else must be dropped, and the servers' switch must enforce it from the group tags. The POS-SG to Servers-SG cell reads top down and closes with a deny. Where does the permit entry go in the TrustSec matrix?
Select an answer to reveal the explanation.
Short Explanation
Your restriction only lives in the cell where POS-SG meets Servers-SG, because that's the one list the servers' switch consults. Entries read top down and stop at the first hit, so the permit tcp 443 line has to sit above the cell's closing deny. It works like a bouncer checking a guest list from the top and stopping at the first name.
Full Explanation
The permit belongs in the POS-SG-to-Servers-SG cell, above that cell’s final deny. TrustSec evaluates the matching cell from top to bottom, so the TCP 443 permit must be encountered before the catch-all deny; the deny then blocks all other traffic in that direction. A server-subnet ACL on the server switch can filter the intended flows, but it matches addresses rather than the required group tags, so it does not meet the stated enforcement method. A POS-switch SGACL uses the right tags and can express the intended service policy, but it enforces at the wrong switch; the scenario requires enforcement on the servers’ switch. An HTTPS application rule is a familiar way to express web access, but application classification can include transports other than TCP 443, such as QUIC over UDP 443, so it does not guarantee the specified TCP-only allowance. Exam caveat: a stateful firewall may permit return packets automatically, but that does not change where this directional TrustSec matrix rule belongs. In practice, verify the SGACL is applied on the server switch, confirm the matrix cell’s rule order and TCP/443 match, and test that other protocols and ports are denied.