The main idea is an application-layer flood attack, where the target is overwhelmed by a high volume of HTTP requests that exhaust the web server’s application resources—such as worker processes, thread pools, and back-end connections. By sending many HTTP GETs or POSTs, the attacker uses legitimate-looking traffic to tie up server capacity, degrade performance, or crash services. This makes it harder to spot at the network level since the traffic can resemble normal user activity, so defenses focus on the application layer: web application firewalls, rate limiting, caching and CDNs, and targeted request filtering. In contrast, other floods operate at different layers: a SYN flood exhausts the server’s TCP connection backlog by initiating many half-open connections, an ICMP flood overwhelms bandwidth with echo requests at the network layer, and a DNS flood targets DNS servers with a flood of queries to consume resolver or authoritative server resources.

Separating incoming from outgoing shipments on the loading dock strengthens security and controls by making each flow distinct. It reduces the opportunity for theft because different areas and procedures handle different directions of traffic, making discrepancies easier to spot. It also minimizes confusion, since paperwork, labeling, and staging are aligned with the correct direction, preventing misrouted or mixed shipments. In addition, it supports segregation of duties by having different staff manage receiving and shipping tasks, which lowers the risk of fraud or undetected errors. Because all of these benefits come from keeping the flows separate, the best choice is the one that includes all of them.

A connection is the persistent dialogue between two programs on different computers. It represents an ongoing, established channel that allows continuous data exchange, typically managed by a transport protocol like TCP with sequencing, reliability, and flow control. State, by contrast, is the stored information about the current condition or attributes of a process, device, or session, not the actual ongoing conversation itself. So the described idea fits a connection best, while state doesn’t describe the dialogue.

Storing authentication data on a card can be done with different technologies. Magnetic stripe cards encode data on a magnetic stripe that can include identifiers or credentials used to verify the user when the card is swiped. While convenient, this data is not highly secure on its own. Smart cards, on the other hand, have an embedded chip with secure memory and a microprocessor; they can store cryptographic keys, certificates, and credentials and perform cryptographic operations on the card itself, enabling much stronger authentication, often with a PIN and mutual authentication with the system. Because either type can hold authentication data, the option that encompasses both is the best choice. Magnetic stripe and smart cards represent two ways to store authentication information, with smart cards offering stronger security while magnetic stripes provide a simpler, more basic form of credential storage.