A team is migrating its Secure Firewall Threat Defense sensor from Snort 2 to Snort 3, and the lead engineer wants the operations group to understand what changes in configuration style and process behaviour. The design review also has to explain how packet work is spread across CPU cores on the new engine. Which statement correctly describes the Snort 3 architecture relative to Snort 2?
Select an answer to reveal the explanation.
Short Explanation
You can think of Snort 3 as one busy kitchen with several cooks working at once: it uses Lua configuration files and spreads packet work across many threads in a single process. Snort 2 used snort.conf and handled work in a single-threaded process, so you’ll want to account for that difference when planning capacity.
Full Explanation
Snort 3 was rebuilt around Lua, so rules, ports and module settings live in Lua files that load when the engine starts, and it scales by spreading packet work across worker threads inside a single process. That is why a migration replaces the old variable-and-include style of snort.conf with a Lua configuration, and why capacity planning now counts the worker threads that share one process. The snort.conf approach fails because Snort 3 does not parse that file as its primary configuration. The separate output spooler claim reverses the real history, since it was Snort 2 that commonly needed an external spooler to convert and ship unified2 alerts while Snort 3 ships its own output modules. The per-decoder process model fails because Snort 3 isolates decoders as modules inside the shared process instead of as separate processes. Exam caveat: Threat Defense wraps the engine, so file names you see in the product may be generated for you. Practical check: open the engine configuration on a lab sensor and confirm the settings are written in Lua before you plan the upgrade.