You can never really write an e2e test that's guaranteed to leave the system in a known state at the end, especially if you're relying on these "low-level" APIs that themselves may well have bugs introduced into them, but even if you just rely on O/S commands to delete files and SQL commands (issued via some command-line tool) to clean up data, things can and do go wrong.
I would think it's simpler just to have the test scripts start with the necessary commands to initialize a "clean slate", and don't worry about whether resources get cleaned up as expected as the tests run (that's certainly the method I've used over the last few years). It's often very useful to leave resources in place at the end of an e2e test run to help troubleshoot problems that might occur anyway.
Of course you may well also need e2e tests to test DB migration etc. of an existing set of resources, but I'd think that's best handled separately, and to be honest those sorts of problems usually get found out quickly by just running deployments to existing non-prod environments.