Viewing Configuration Timeline History

For any tracked resource, Config builds a configuration timeline: an ordered history of every configuration item recorded for it. You can scroll back to see exactly how the resource was set up at any past moment, making it a time machine for your infrastructure.

During an incident the timeline answers a critical question: what changed and when. If a security group suddenly allowed traffic from anywhere, the timeline shows when that rule appeared. Pinpointing the moment of change narrows the window you must investigate and helps correlate it with other events.

Each entry on the timeline marks a configuration change with a timestamp and the before-and-after differences. You can see precisely which attributes changed, such as a port range widening or encryption being turned off. This diff view turns a vague "something changed" into a concrete, specific finding.

Config shows what the state became; to learn who caused it, you pivot to CloudTrail using the timestamp from the Config entry. Matching the change time against CloudTrail events identifies the principal, source IP, and API call responsible. This Config-to-CloudTrail pivot is a core investigation technique.

The timeline records changes in relationships too, like a volume being attached to a different instance or a subnet's route table changing. These relationship shifts can be the real story of an incident, revealing how an attacker rewired connections even when individual resource attributes look unchanged.

Beyond per-resource timelines, Config can deliver full configuration snapshots of all recorded resources to S3 on a schedule. A snapshot is a complete inventory at a moment in time, useful for proving the entire environment's state during an audit or for comparing posture across dates.

Config retains configuration history for a configurable period, up to several years, and the underlying data also lives in your S3 bucket. For long-term forensic and compliance needs, ensuring that bucket is protected and retained is as important as the recording itself, since the history is only useful if it survives.

The timeline is how you investigate configuration drift: a resource silently moving away from its intended secure state. Comparing the current CI against an earlier known-good one shows exactly what drifted. This is invaluable when a control that was compliant yesterday is failing today.

In the console you open a resource in Config and view its timeline directly, with compliance status overlaid on each point. You can see not only how the resource changed but whether each version was compliant with your rules, tying historical state to your security posture at that moment.

Config retains history even for deleted resources, recording a final CI marking deletion. This matters in investigations where an attacker creates and then removes a resource to cover tracks. The deletion event and the resource's prior state both remain on record for you to find.

The configuration timeline is your forensic backbone: it shows when a resource changed, what changed, and, combined with CloudTrail, who did it. Mastering this pivot from state-change to responsible API call is exactly the kind of investigation the exam expects you to perform.

Test your use of Config history.

The configuration timeline is an ordered history of a resource's configuration items, showing before-and-after diffs and relationship changes with timestamps. It pinpoints what changed and when; pivoting to CloudTrail reveals who. Config retains history for deleted resources and supports snapshots, making it the forensic backbone for investigating drift and incidents.