It really depends what your threat model is.
If we take away everything else and just think about the application, there is basically nothing more you can do to really improve the security of the app. Stay away from esoteric solutions and focus on what is more maintainable and clean. I want to stress clean, as usually security disaster arises from messy situations.
Anyway: if the attacker gets remote code execution under the application user, you cannot restrict access to the configuration in any way - the app has to access it, so can the attacker. If he gets file read capabilities, then storing in a database will protect you from disclosure - even if you have to store the credentials of the db in a file, the attacker won't hopefully be able to leverage those. If he gets SQL injection, access to the db (in the unlikely case this does not translate into remote code exec) then having them in a file is safer. Really, it depends on how your application is designed.
Running Apache as root is really a bad idea (well, disabling the privileges drop I mean). Instead of implementing one-time solutions focus on stuff that is going to stay in place without more hacks and get the benefits of the pentest. passing stuff via the stdin for instance will make it very hard for the testers to retrieve the credentials, but in the long run you'll likely end up with a bash script doing the job... which is by far worse than the other solutions.