So, I can’t speak to the course content or what is said in the module, but I can offer you the following from my own experience, and I hope it’s useful.
Test environment setup can mean deploying the Application Under Test, and the full supporting set of systems that surround it. But it can also be somewhat less than this, where some static parts of your environment are not redeployed for every setup.
There are many considerations in the real world for what parts of your environment you want to start fresh for a test environment. The biggest advantage of having an isolated environment, one that you setup in its entirety for each automated test run, is exactly that, isolation. So anything left behind by previous runs, or exploratory testing cannot interfere with your automation results.
There are some arguments against this very clean, isolated environment approach. Some people appreciate the value you get from testing on a system that has older data remaining in databases, and opportunities for accidental failures like full disks, that you might otherwise forget to test.
Test data setup. As well as the versions of your applications and supporting services, your environment may need a set of test data, that is user data or system state, that is required because your automated checks expect things to exist.
Again, this could be set up as part of deploying, or setting up your environment, for each run of your automation, or it it could be managed separately, hopefully with further automation so you don’t need to do it by hand each time.
You might make the system state that your automated checks require, the responsibility of your automation suite, so that as your needs evolve you don’t need to keep some separate environment setup aligned, but instead just update that part of your checks.
Test execution or running your tests, is related but different. As above, you may choose to do setup as part of your automation, or you may manage your test environment in another way. You can execute your tests, in theory, against any environment be it one created in Docker for only this test run, a test environment that is shared among teams and managed “out of band”, or even Production, yes Production if it makes sense.
To do this, you likely need to set up Environment Variables, such that you can pass details of the environment you want to execute your checks in, into the automation framework. This could be as simple as passing the correct URL, or more complicated, like passing the right tokens, usernames, passwords etc, for this you may need to use “Sealed Secrets”, to protect the details you are passing into the tests.