Zookeeper medium
What is a critical architectural implication of ZooKeeper's 'Non-Recursive' Access Control List (ACL) model?
- A Setting a 'Read' restriction on a parent Znode (e.g., `/app`) does NOT prevent a client with credentials from reading a child node (e.g., `/app/config`).
- B It ensures that the leader can only perform write operations on the root node to prevent unauthorized data tree growth.
- C It allows the system to process authentication handshakes concurrently without needing a centralized authorization authority.
- D It prevents the creation of children under any Znode that has more than 1,000 active watch triggers registered.
Answer: A. Setting a 'Read' restriction on a parent Znode (e.g., `/app`) does NOT prevent a client with credentials from reading a child node (e.g., `/app/config`).
This surprises many users. If you secure a parent, the children remain open unless you secure them too. There is no inheritance.
One system design question a day, with spaced repetition so the ones you miss come back.
Get the appRelated questions
- What is the primary technical function of a ZooKeeper 'Watch'?
- A system administrator increases `jute.maxbuffer` to 5MB on every ZooKeeper server to store large configuration objects. However, write operations larger than 1MB still fail. What is the most likely cause?
- By default, `forceSync` is enabled. If you disable it, what trade-off are you making?
- If the specific ZooKeeper node a client is connected to crashes, what should the client do?
- Which cluster configuration has *worse* availability: A 3-node cluster or a 4-node cluster? (Assuming simple majority quorum)
- According to the CAP Theorem, how is ZooKeeper classified?