In a monitoring script you are reviewing, the Device class defines a class-level vendor = "Cisco" attribute, and every instance stores its own name set in __init__. The script runs d1 = Device("core1"), d2 = Device("edge2"), then executes d1.vendor = "Arista". Which values do d1.vendor, d2.vendor and Device.vendor each show afterwards?
Select an answer to reveal the explanation.
Short Explanation
Python checks an instance's own attributes before it looks at the class, so your write lands only on d1. d2 has no copy of its own, so it keeps reading the class value of Cisco. That shadowing doesn't touch any other object, which is why shared default lists in automation scripts surprise people.
Full Explanation
Python resolves an attribute by searching the instance dictionary first and the class dictionary second, so assigning through d1 creates a fresh binding in that object only while the class-level name keeps its original value. d2 holds no vendor entry of its own, so its lookup falls through to the class and reports Cisco, which is exactly the shadowing rule that makes the correct reading true. Treating the assignment as a class-wide change describes a shared-attribute mistake, because rebinding a name on one instance never reaches the binding stored in the class body. Assuming the write reaches sibling instances describes an identity confusion, since two objects only share state when they deliberately point at the same mutable object. The view that the class updates while an older instance keeps a cached copy misses the fallback lookup, because instances do not snapshot class attributes at creation. Exam caveat: the same pattern appears with a mutable default such as an interface list, where mutating in place is visible everywhere but rebinding is not. Practical check: run print(d1.__dict__, d2.__dict__, Device.vendor) after the assignment and confirm the class namespace is unchanged.