That information is already known! Avoiding the need for a runtime lookup is a key optimization benefit of lexical scope. In other words, Engine (from Chapter 2) doesn't need to lookup through a bunch of scopes to figure out which scope bucket a variable comes from. Since the marble's color is known from compilation, and it's immutable, this information would likely be stored with (or at least accessible from) each variable's entry in the AST that information is then used explicitly by the executable instructions that constitute the program's runtime. Because lexical scope is pretty much finalized at that point, a marble's color will not change based on anything that can happen later during runtime. The color of a marble's bucket (aka, meta information of what scope a variable originates from) is usually determined during the initial compilation processing. This suggestion of a runtime lookup process works well for conceptual understanding, but it's not actually how things usually work in practice.
Similarly, studentID in the if-statement is determined to be a BLUE(2) marble. The lookup process thus determined that students is a RED(1) marble, because we had not yet found a matching variable name as we traversed the scope chain, until we arrived at the final RED(1) global scope. The lookup stops as soon as the first matching named declaration in a scope bucket is found. In Chapter 2, we described the runtime access of a variable as a "lookup," where the Engine has to start by asking the current scope's Scope Manager if it knows about an identifier/variable, and proceeding upward/outward back through the chain of nested scopes (toward the global scope) until found, if ever.
How exactly did we determine that it's a RED(1) marble? In Figure 2, notice the color of the students variable reference in the for-loop. The chain is directed, meaning the lookup moves upward/outward only. The connections between scopes that are nested within other scopes is called the scope chain, which determines the path along which variables can be accessed. To refresh the context of our running example, let's recall the color-coded illustration of the nested scope bubbles, from Chapter 2, Figure 2:
Make sure to take your time with the text and all the code snippets provided. Stick with it, though, because these discussions really hammer home just how much we all don't know about scope, yet. Now it's time to dig into the nuts and bolts, so expect that things will get a lot more detailed from here forward. That helps our brains digest what we're learning! That seems like a step you might skip, but I've found it really does help to take the time to reformulate these ideas as explanations to others. Before proceeding with this chapter, find someone else to explain (written or aloud), in your own words, what lexical scope is and why it's useful to understand.