I don't know anything about ehcache, but jboss cache does require quite a bit of configuration (there is an official hibernate howto around somewhere, but it is hard to find on their website). According to the website ehcache is cluser aware. All clustered caching solutions require careful configuration to make sure the cache is set up to have the scematics you require.
In this particular instance, it probably make no difference, as credit card types are not going to be changed very often you could just outject it to application scope and be done with it. But then you wouldn't have learnt anything. Incidently the second level cache still sufferes the same problems with syncronisation from an external source as what you would have outjecting to application scope.
If there is an insert from the current app the query cache is wiped clean, the second level cache is not affected. If there is an external insert it will not be visible until the data in the query cache has expired from the cache. Eviction policies are configured using you normal cache configuration file.
No. You have to make informed decisions based on your app's usage patterns. If a list is used a lot and rarely updated then yes, it is a good candidate for caching. Also the second level cache is not a magic bullet, for instance if you are loading the owner of a one to one fk reference from the other side hibernate will always issue a db call, even if the owner is already loaded into the persistence context.