Why should a Sharing and Visibility Designer split an account instead of reviewing the sharing rules for a UNABLE_TO_LOCK_ROW error?

I think I have to try to tackle this one because I passed that exam this morning!

There's two layers, I think, to this sample question. One is that Salesforce is trying to see whether you're able to recognize an example of a standard scenario that they use to portray a specific issue and know what their recommended fix for that issue is. Here, they're specifically looking to see if you've read and followed Designing Record Access for Enterprise Scale, which is part of the resource guide for this exam.

In this case, the issue is parent-child data skew. This term refers to any situation where a single parent object has in excess of 10,000 child records. (Why 10,000? I don't know the exact technical rationale, but it's always Salesforce's cutoff point for identifying data skew).

One of the more or less standard recommendations from Salesforce for curing parent-child data skew is ensure that no single parent has more than 10,000 children, typically by splitting the children among multiple parent records (such as branch accounts). They're looking for you to choose (B) to show that you've read the recommended materials, understand which scenario they're presenting, and know the recommended fix.

The other layer is the technical. By consulting the Record Locking Cheat Sheet, we see that one of the situations in which inserting a child record locks the parent is that a Case insert or update always locks the parent Account. (Note this is called out as a "high" risk of lock contention).

That's ultimately where the row locking error comes from - not the data volume as such, but the volume of concurrent updates that hold that lock long enough that one or more other concurrent operations times out. Altering sharing rules might in other ways improve performance, and might in fact reduce the duration of some of the locks, but it won't fix the root cause, so ultimately this again points us to (B).