It depends on what you are willing to rent and allow to be managed by someone else.
If we look at this diagram:
It shows a full range of options. At one end is Do It Yourself with on-prem hardware and setting up networks etc. Next to that is ”co-lo” which implies you buy servers that are installed in someones rack/network/data centre. Next to that is IaaS where you usually rent VMs on purely software defined networks and pay someone to manage the physical servers and physical network.
So where do containers fit in? Well I have seen big organizations treat cloud IaaS a bit like on-perm by setting up networks and firewalls in cloud to exactly match on-prem with private network connections into the cloud datacenter. So getting very little advantages of cloud. What they are mostly managing are dozens of legacy systems that they have ”lifted and shifted” from on-prem into a cloud provider as part of a multiple million dollar cloud contract. Obviously, they still need all the configuration management like they were using on-prem to manage the VMs. Then they install Kubernetes to manage containers and have to manage that. The cost of all the engineers they need to hire to keep it all running is huge. In such a setup its clear they need configuration management at every level and clusters of containers are just one more new thing they need to configure and manage.
At the other end of the spectrum is SaaS and you don't know if they use VMs or Containers. You then have no traditional configuration management and usually no devops. From the devops perspective an interesting choice is CaaS+PaaS where you rent capacity on a managed Kubernetes service that has devops extensions such as OpenShift. As a start up you can simply rent memory on a shared cluster where you are isolated from other tenants via software defined networks within OpenShift Kubernetes. Then you have outsourced both management and configuration of the VMs in the cloud and also outsourced patching and expanding the Kubernetes cluster running on the VMs. You can then focus on configuration management of your containers on Kubernetes. (Note: You still need to security patch the container runtimes. We have a script that checks for new security patches to RHOAR containers and rebuilds our containers with the latest versions.)
So it depends on how much you can and are willing to relinquish control of. Its easy to start out renting a fraction of a shared managed cluster then upgrade to a dedicated cluster still managed by someone else. Once you start out doing that on public cloud its hard to imagine any additional advantage of going back to managing VMs in the cloud. Unless you are forced to do so to run legacy apps or software you had to buy that doesn't support being run in containers. If you must configure VMs you should apply best practices of configuration management.