01A key stores a hash encoded compactly. Which field says it is a hash, and which field says how it is physically stored?introScenarioYou are inspecting how the server represents a small hash internally after a few HSET commands.AThe encoding field says it is a hash, and the type field records whether the layout is compact or a full table.BThe object type field says the value is a hash, and the encoding field says whether it is stored compactly or as a dictionary.CA single representation field covers both, because hash-compact and hash-table are two distinct object types.DThe key itself carries a type prefix, and the value structure only needs to record its encoding, which keeps the value structures small and uniform.
02Why is upgrading a hash from compact encoding to a hash table invisible to clients?introScenarioA growing hash has just crossed the threshold where its compact layout is converted to a real hash table.AIt is invisible because the upgrade happens during a fork, where clients cannot observe process memory.BIt is invisible only if a client never rereads the key, since older readers still see the compact form until they reconnect.CIt is invisible because Redis rewrites client replies to imitate the compact encoding's field ordering.DEncoding changes are internal because the logical type and command behavior stay the same while the physical representation changes.
03Predict the result of `LPUSH profile Ada` when `profile` currently holds a string.appliedScenarioA developer accidentally runs a list command against a key that currently holds a plain string value.ALPUSH against a key holding a string returns a wrong-type error because the key exists but its logical object type is not a list.BThe string is converted into a single-element list and Ada is pushed in front of the original value, mirroring the way APPEND grows a string value in place.CLPUSH overwrites the key with a fresh list, because write commands take precedence over existing values.DThe push succeeds at the encoding level, and the key reports type list from the next access onward.
04Which object metadata helps eviction policy, and which metadata helps command validation?appliedScenarioYou are auditing which parts of the object header each subsystem actually reads.AThe reference count drives eviction since heavily shared objects survive, while the encoding field drives validation.BThe TTL field drives eviction for every policy, while LRU metadata validates that commands access keys in a safe order.CLRU or LFU metadata helps eviction policy, while the logical type field helps command validation.DEviction and validation both read the encoding field, because compact values are cheaper to evict and faster to check.
05Why is it useful for persistence to see logical type rather than only raw memory bytes?advancedScenarioYou are designing the save path and must decide what the snapshot format records about each value.ARaw bytes would be smaller and faster, so logical type exists in the file format mainly for debugging tools.BLogical type only matters because raw pointers would dangle after restart, and a relocating loader could fix those without any type information.CPersistence needs logical type only when AOF and RDB are combined; a pure RDB file stores raw memory pages.DPersistence needs logical type so recovery can restore behavior and encodings, not just copy opaque process memory bytes.