Configuration Management

Configuration management establishes what a system should contain, how it should be configured, and how changes to that configuration are recorded and controlled. A configuration can include operating system settings, installed software versions, network rules, identity permissions, database parameters, and application options. Engineers define an approved baseline, deploy it consistently, and compare running environments against that baseline to identify unexpected differences.

Under the AWS shared responsibility model, configuration management is a shared control because both AWS and the customer perform it, but for different layers. AWS maintains the configuration of the infrastructure that supports its cloud services, including physical infrastructure and underlying infrastructure devices. Customers are responsible for configuring the resources, applications, and customer-controlled software they deploy. Shared does not mean that both parties jointly approve every setting or that AWS corrects customer misconfigurations automatically.

The exact boundary depends on the service. For an Amazon EC2 instance, AWS manages the underlying hardware and virtualization infrastructure, while the customer manages the guest operating system, installed applications, and security group rules. With a managed database, AWS operates more of the underlying platform, but the customer still controls settings such as permitted network access, database users, and supported database parameters. Choosing a managed service reduces some operational work; it does not remove responsibility for customer-accessible configuration.

A practical workflow starts with an inventory of resources and their owners. Engineers define approved settings in version-controlled templates or configuration policies, review proposed changes, test them outside production, and deploy them through controlled automation. For example, a team might require restricted administrative access, approved software versions, and enabled application logging. Configuration records and change history then help establish which resources meet those requirements and when deviations appeared.

Configuration drift occurs when the actual environment differs from the approved configuration. An emergency console change that opens a firewall rule can create drift even when the original deployment template was secure. Detection should lead to investigation and either remediation or an approved baseline update. Automatic remediation is useful for clear, low-risk violations, but a poorly designed rule can interrupt legitimate traffic or repeatedly undo an intentional operational change.

Automation improves consistency but can also spread an incorrect setting across many resources quickly. Reviews, staged deployments, limited deployment permissions, and recovery procedures reduce that risk. Detection also has limits: tools differ in resource coverage, supported properties, and evaluation timing. A compliant result demonstrates alignment with the rules being checked, not proof that the entire workload is secure.

Configuration management is broader than infrastructure as code, patch management, or change logging. Infrastructure as code describes and provisions resources, patch management updates software, and audit logs record actions; each supports configuration management without replacing it. For exam scenarios, first identify the affected layer, then determine whether AWS or the customer controls its configuration.