D8 configuration is different, in that it is meant to capture the whole site from local>dev>stage>prod, instead of configuration changes captured in Features and encapsulated in individually importable modules, as in D7.
That said, Features would still be employed for exporting a chunk o code / config for use in ANOTHER site, but once the feature is imported, it all is a part of the site and managed though the core config management
Configuration may be overridden on a particular environment through the $config array in a *.settings.php
All feature/module default configurations are stored in YAML files that are dragged around as part of the config deployment.
Config syncing (ie Stage>Prod) scenarios and solutions:
Scenario 1: Configuration not managed at all.
Scenario 2: Configuration sync directory in use, but sometimes configuration on the live site is edited: set up a local development instance, make and test your configuration changes there, export your configuration to files in your config sync directory, and finally use command-line tools like Git and Drush to deploy and import changes to the live site
Scenario 3: Configuration changes are always made and tested on non-production instance(s) and then deployed to live: set up a strict workflow policy
If you’re the one and only site admin and developer… learn how to use both GUI and command-line tools to manage and move your site’s configuration between instances.