Why do you care about passivation details?
Because the Container uses a special set of rules (nearly identical to Serialization) to passivate your bean, and it’s your job to make sure your instance variables are in a state that works for passivation. And it’s just a tiny bit more subtle than simply making non-Serializable values transient.
Lifecycle overview: bean passivation/activation
Client doesn’t call any methods for a while, so container calls ejbPassivate() on the bean.
Container calls ejbPassivate() on the bean, then saves the bean to temporary storage (either through serialization or something like it).
Client calls a business method, so container activates the bean (through something like deserialization), calls ejbActivate(), then invokes the business method (getAdvice()) on the bean.
There’s nothing on the exam about vendor-specific passivation settings or behavior.
The only thing on the exam about passivation is what you’re responsible for as a Bean Provider—getting your instance variable values in a passivatable state (we’ll talk about that next). Nothing about passivation goes into the deployment descriptor, so you don’t need to know how passivation parameters are set for any particular server.