If you’re starting from an official image and it’s set up like the other official database images, then no (for technical reasons).
Typical ways to approach this I’ve seen with other databases are to distribute a database dump in some form that can be restored at setup time, and to just run a shared (maybe read-only) database that everyone can use.
In Docker land, you have the one additional option of (a) start the database with some host directory bind-mounted into the container; (b) do the initial database load; © stop the database cleanly; then (d) distribute a copy of the directory as essentially a snapshot that can be bind-mounted into other container instances. How well this will work depends on the database (I don’t really have direct experience with Cassandra) but if things like host names wind up baked into the database image you might have trouble.
As a general rule, a container’s code and the data it stores need to be managed separately, and this is a good example of that. (This approach means your developers can run the same set of containers your production application uses, just with different backing data, which saves you some trouble if you update the production database but forget to also update the developer-oriented image with data baked in.)