3. Config Controls: Secure Defaults
Config controls prevent issues by making resources secure by default through account and service settings. When properly configured, security becomes automatic. Developers don't need to remember to enable encryption or block public access. The account or service configuration does it automatically for all new resources.
AWS account-level settings like S3 Public Access Block and EBS encryption by default are archetypal config controls. Enable S3 Public Access Block at the account level and all new buckets in that account are private by default. Enable EBS encryption by default and all new volumes get encrypted automatically. Developers create resources normally and security gets applied automatically.
Azure and GCP provide similar capabilities. Azure Storage accounts can require secure transfer. Azure SQL databases can require encryption. GCP Compute Engine can mandate OS Login and prevent external IPs by default. Each cloud provider offers dozens of security settings that can be configured at account, subscription, project, folder, or service levels.
Config controls differ from access controls in an important way. Access controls block risky actions. Config controls make secure configurations automatic without blocking anything. A developer creating an EBS volume doesn't get blocked if encryption defaults are enabled. The volume just gets encrypted automatically. The developer doesn't need to specify encryption-it happens by default. This makes config controls invisible and frictionless.
The strength of config controls is their invisibility. When defaults are secure, developers building in that environment inherit security automatically. There's no additional step to remember. No parameter to specify. No documentation to consult. Secure is simply the default path. This dramatically reduces the surface area for human error.
Config controls have scope limitations. They apply only to resources created after the setting is enabled. Existing resources don't get retroactively updated. They only cover what the cloud provider exposes as configurable defaults. Not every security setting has an account-level default option. Some configurations must still be specified per-resource. Config controls are powerful for what they cover but don't provide comprehensive prevention alone.
Organizations deploying config controls typically enable them in all new accounts automatically. When a new cloud account gets created, a baseline set of secure defaults gets applied before teams start using it. This "secure by default" approach means teams inherit prevention without doing anything. As additional default settings become available or proven valuable, they get added to new account baselines and gradually rolled out to existing accounts.
Config controls provide prevention that scales effortlessly. One setting at the account level protects every resource created in that account. As teams create more resources, prevention coverage grows automatically. There's no additional work, no new policies to write, no scanning coverage to expand. The defaults just keep working.