At a SaaS company, one log shows a firewall allowed a 5-tuple, and another log from the same moment denies that flow after identifying a remote shell. Which log explains the deny?
Select an answer to reveal the explanation.
Short Explanation
The outer log says the visitor was admitted, and the inner desk says the visitor is a locksmith you did not call. The deny is network application control naming a remote shell, not the firewall line that allowed the 5-tuple. Flow counters and a battery log never make that application decision.
Full Explanation
Two controls can see one flow and disagree because they look at different layers. The firewall allowed the 5-tuple, which means the connection matched a stateful permit. A second control then identified the application as a remote shell and denied it. The log that explains the deny is the one that named the application. Network application control that denied the same flow after naming it as a remote shell. The permit line explains the opposite action. The firewall allow entry for that 5-tuple, recorded before any remote-shell judgment was applied documents an allow and cannot be the reason the flow was denied. Counters do not carry a verdict. NetFlow counters for that 5-tuple, limited to byte and packet totals and silent about the deny can show the conversation size and still say nothing about a remote shell or a deny. Power state is unrelated. The laptop battery log, limited to charge level and silent about any application decision has no 5-tuple judgment at all. Exam caveat: an allow and a deny can both be true when they come from different controls on the same flow. Read the deny from the control that identified the application, not from the earlier permit. Operational check: line up the timestamps and the 5-tuple so the allow stays on the firewall and the deny reason stays on the application-control record.