The documentation for the Drupal 8 configuration manager says:
Making configuration changes on a live site is not recommended.
When managing a site used by dozens of content managers, how can I make sure that this really never happens? Is there a way to prevent this with permission settings? For me it's still not really clear which permissions to set, to make sure those users are never able to change the configuration.
One option is to use https://www.drupal.org/project/config_readonly, it enforces that config writes can not happen on production.
So far, I haven't built/maintained a D8 site where that approach was practical. Most of our sites rely quite heavily on contact forms for example, with workflows where content managers create contact forms as well. And sometimes quick changes are necessary, e.g. for services and integrations.
One option to deal with that is to use a project like https://www.drupal.org/project/config_split, which allows to keep a part of configuration outside of git and not have it overwritten by deployments. So far, we just do a config export on production, commit that to the production branch and then merge the feature branches that we want to deploy. There's some risk for conflicts, but that doesn't happen often.
But sure, there are sites where it is critical that every change is reviewed and approved first, before it can be deployed, then something like config_readonly is useful. I wouldn't enforce it just because some d.o page says so, you need to figure out what works best for your site and workflows.
I can speak for developing with Drupal 7 but I'm sure the concept can be translated.
Content Contributor Role To answer your question about controlling permissions, just take a look at this documentation on Drupal 8 permissions. Create a specific role for content contributors and give them only the specific permissions you want them to have, e.g. nothing with configurations. You can bulk reassign all your content contributors to the new role you created, if you don't already have it.
Prevent users from logging into the admin account by protecting the password and making sure there is only one admin account on production. All content contributors should only have access to functions which build data, such as adding or editing nodes and editing the menu.
Development Workflow Rarely log into production as an admin and use git and features to push everything up into it after testing the code and data in a staging environment. I work on a local environment and push the code up to staging while I import the database from prod to staging. If everything checks out in staging, I push the code into production. No configurations need to happen in production because they can all be featurized in development. Thus, preventing access to making configuration changes on production works just fine.
All developers develop locally and the staging environment is where the design team approves things before they are deployed. This article on Drupal development with Git is my bible.
