This sounds really wrong - installation of all of your dependencies should be run as a part of building the container for a particular version of your application, say, as a directive within the Dockerfile.

That should also be done before any unit tests and integration tests are run against that container, well before it is deployed to any environment. The end result of doing that properly is a container that will work correctly until the end of time (or at least any vulnerabilities become apparent and a new version needs to be built, or for other reasons, such as bug fixes or added functionality).

Furthermore, all of your IAC should be treated just like regular code, which means full descriptions and comments for any non-trivial parts, or even explaining why the trivial parts are there to begin with (the greater circumstances, links to change requests etc. that the actual code doesn't otherwise contain). If you can't look at any single piece of your code and understand both what it does as well as why it's attempting to do it, then clearly there is still more work to be done. Whether that's refactoring or documentation, however, depends on the circumstances.

IAC doesn't absolve you from the need of having documentation. It simply allows you to lower the degree to which PEBKAC is a problem in manual deployments and allows you to document the actual code that does things, rather than creating .docx descriptions that no one will read.