There is a definite distinction between access to JNDI and access to a resource ref, resource manager, or another bean. There's a really great blurb in the HF EJB book that talks about the difference between "Can and Can." The key point to remember is that the
test is only concerned with what the EJB spec says you can do. Physical reality is irrelevant. So, for instance, a stateless session bean's ejbCreate method can in physical reality get a reference to a resource connection factory via a JNDI lookup. But, the EJB spec says that it should not use this reference to actually access the database. Thus, on the exam, if it asks you if you can access a database in the ejbCreate method of a stateless session bean, you say NO, because that's what ejb law dictates.
In the HF EJB book, when it says you can access your "special JNDI environment," just think of it as being able to access env-entry(s). Access to resources/beans that you can get at from a lookup are a whole different story.
In my humble opinion, the topic you brought up relates to the weakest section in the HF EJB book. It's difficult to rationalize some of the "what can you access and when" rules because the reasons why are hard to pinpoint. What helped me to remember these rules was thinking of what scenario would cause me to want to do certain things in a certain method.
For example, why would I want to access a database in the ejbCreate method of a stateless session bean? At the time that ejbCreate is called, no client is doing anything with a bean. What possible use could I have for wanting to access a database at a point when an object is not being used by anyone. If you did store some db data in your bean's data members, it would be stupid to do it during ejbCreate for a stateless session bean because, by the time any client actually calls the method, the data could be stale.
I hope this helps.