The question asks "which process determines which method should execute?"
This is a bad question.
But, we can immediately eliminate three of the choices: Is-A, Has-A, and Parent Class, since those are object-oriented, but not certainly not processes. Even if Is-A and Has-A were processes, they would be processes regarding class and composition, as you said, not method execution.
Inheritance is a process (also a concept), a process of inheriting the traits of the parent class. By that definition alone, we can eliminate it.
That leaves us with only Polymorphism, which is part of why this is a bad question. Polymorphism sounds like a concept, more than a process. However, if considered to be a process, it would be a process of "polymorphing" or "taking a different shape". An answer on Stack Overflow says:
So polymorphism is the ability (in programming) to present the same interface for differing underlying forms (data types).
By that definition, we're talking about a process where an object can act as one or more underlying real types. You have an interface, and the underlying data types determine which method should actually be called.
We're looking for a process that matches the statement "determining which method in a class hierarchy should execute", and I think that matches pretty well.
It's also a bad question because that statement could mean many other things, and I don't think many people would really described the "determining" part to be the polymorphism -- instead, I'd consider polymorphism to be the definition part.
The other end of the spectrum from the fat service class is the use of commands and a command processor. Basically each of your service methods is broken off into its own command.
This article by Ian Cooper gives a good description of refactoring from a fat service to commands:
Some of the pros of this are razor-focused single-responsibility of your classes, and the improved testability that that brings. Some cons - you have now introduced an extra level of indirection that isn't always easy to make sense of, and you get a bit of a class explosion.
Best Answer
The real question is: WHY does the architect want everything to inherit from base? What's the utility of doing so?
If it's for something like serialization interfaces, then it MIGHT make sense if you will need a general serialization facility. But make sure that you actually will need EVERY class in the system to have that functionality. If you don't, then you end up needlessly inflating each class, AND you'll end up having to implement (or stub out) functionality in classes where that functionality doesn't make sense.
I would NEVER implement my own 'uber-base' like this in a system, because I can't conceive of any functionality or interface that I would want in EVERY object EVERYWHERE in my system. The only thing I can think of that it might be useful for is something like heterogeneous containers, but I've never been in a situation where I wanted a completely heterogeneous container - I generally want a set of classes, not just any random thing under the sun to go into my containers.
Unless the architect can demonstrate why they want this uber-base, I'd leave it out.