the process table
Imagine the front desk of a large hotel with a board (or database) listing every guest currently checked in: room number, name, requests, billing. The staff consults it to find any guest and to keep the whole hotel organized. The process table is the operating system's master list of all the processes it currently knows about, with an entry for each so the OS can find and manage any one of them.
In practice the process table is a kernel data structure (an array, a hash table, or a linked list, depending on the system) where each entry is, or points to, a process's PCB. When a process is created, the OS adds an entry; when a process terminates and is cleaned up, the entry is removed. Through this table the OS can iterate over all processes (for example to list them or to find a child to clean up), look one up by PID, and reach each process's saved state during a context switch. The table's size sets a hard ceiling on how many processes can exist at once.
The process table is how 'the OS keeps track of many processes' becomes something concrete rather than a vague promise. It is closely tied to the PCB (the table holds them) and to scheduling and creation (entries appear and vanish as processes come and go). One honest limit: because the table is finite, a fork bomb that creates processes as fast as it can will eventually fill the table and prevent new processes from starting, which is why systems impose per-user process limits.
A command that lists all running processes is really reading the process table (via the kernel), printing one line per entry: its PID, state, owner, and the program it is running.
Listing processes is reading the OS's process table.
The process table is finite. A program that spawns processes endlessly can exhaust it (a fork bomb), which is why per-user process limits exist.