Exposing them isn't the same thing as making the getters/setters public. Exposing them means that you've listed them in a remote interface or local interface. As to whether the virtual field methods should be public or not, you don't have any choice in the matter. EJB spec section 10.3.1 page 130:
The accessor methods must be public, must be abstract, and must bear the name of the container-managed persistent field (cmp-field) or container-managed relationship field (cmr-field) that is specified in the deployment descriptor, and in which the first letter of the name of the cmp-field or cmr-field has been uppercased and prefixed by "get" or "set".
HFE's discussion on exposing the virtual fields is really only a suggested practice, not something required by the spec. The exception to that is primary key fields (same page as before):
Once the primary key for an entity bean has been set, the Bean Provider must not attempt to change it by use of set accessor methods on the primary key cmp-fields. The Bean Provider should therefore not expose the set accessor methods for the primary key cmp-fields in the component interface of the entity bean.
Completely off topic from the standpoint of the exam, I actually strongly disagree with the HFE recommendation. I understand why they make it, but I think it reflects bad cohesion. CMP beans are good at what they do - getting things in and out of the database. The faster, more robust, and more re-usable they are the better. Adding other behaviour into your fields generally happens because somebody wants to dump business logic into their persistence layer, and I've yet to see a situation where over time that didn't turn out to be a really, really bad thing. Validation (the example I believe HFE mentions) does not belong in the entity bean for multiple reasons.
Validation is often purpose-based, not model based. For example "valid" for a consumer bank account may mean something different than "valid" for a small business bank account, but maybe they share database entities in common.
Validation can be organization-specific. For example "customer id" for one company may be alphanumeric, and for another company is strictly numeric.
Validation can be expensive and not always applicable. For example, you may always want to validate data coming to you from a remote client (a form on a web page), but not from a local client (developers are supposed to debug their code). I've seen situations where you *couldn't* force validation to always be on, because the remove client data was wrong and if you didn't accept it, you couldn't fix it.
Error handling on validation failure may depend upon the client. How you capture and route error messages can vary dramatically with the application. Some apps expect to deal with one validation failure at a time, others want to know *all* the validation failures at once.
Obviously validation is just an example, but it is the one used by HFE and is sufficient to show that what seemed like an viable reason for indirection on the CMP fields is maybe not a good reason after all.