Change, configuration and lifecycle management

Why this matters

This finishes objective 3.1 with the operational records that keep a network supportable: what configuration is authoritative, which addresses are in use, what is still supported, what the business has been promised, and how equipment leaves safely.

None of it is technically difficult, and all of it is examined — usually as "which record or process addresses this situation". The situations are the recognisable ones: a device nobody can patch, an address conflict nobody can explain, an outage that breaches a commitment.

The lesson

Configuration management

Configuration management is knowing what every device's configuration is supposed to be, and being able to prove what it currently is.

Three terms, and the exam separates them:

The production configuration is what is running right now on the live device. It is authoritative in the sense that it is what users are experiencing — and it is not necessarily what anyone intended.

The baseline/golden configuration is the approved standard: the settings every device of a given role should have — management access, logging, NTP, SNMP, standard ACLs, hardening. New devices are built from it, and existing ones are audited against it. Divergence is the configuration drift covered in the IaC lesson, and comparing production against the golden configuration is how drift is found.

The backup configuration is a saved copy, taken regularly and stored off the device. Its value is time-to-recover: replacing a failed switch is a fifteen minute job with the configuration and a day without it.

Backups need three properties to be worth having, and each is a real failure people have lived through:

• Automated, because manual backups stop happening within weeks.
• Versioned, so you can restore the config from before the change, not merely the latest one — which may already contain the mistake.
• Tested, because a backup that has never been restored is a hypothesis.

IP address management

IP address management (IPAM) is the authoritative record of address space: which subnets exist, what they are for, which addresses are assigned, reserved or free, and what each is assigned to.

Small networks do this in a spreadsheet, and it works until two people edit it in the same week. Dedicated IPAM tools integrate with DHCP and DNS so that the record and reality stay together, which is the whole difficulty.

What good IPAM prevents:

• Address conflicts, where two devices are configured with the same address because nobody knew it was taken.
• Subnet overlap, especially when connecting to a cloud VPC or acquiring another company — the problem flagged in the cloud lesson.
• Exhaustion surprises, because free capacity is visible in advance.
• Orphan addresses reserved for systems decommissioned years ago.

The exam scenario is usually a conflict or an overlap, and the answer is IPAM as the process, not a technical fix on the affected device.

Software management

Software management is keeping track of what versions run where, and applying updates deliberately.

Patches and bug fixes address defects, and security patches address vulnerabilities. Two competing pressures apply: patching promptly reduces exposure, and patching hastily risks an outage from a bad update. The resolution is the same everywhere — test in a lab or on a non-critical device, schedule through change management, have a rollback plan, and treat actively exploited vulnerabilities as an emergency change rather than waiting for the next window.

Operating system (OS) updates apply to servers, workstations and the network operating systems on switches and routers.

Firmware is lower-level code embedded in hardware — the switch's own software, a NIC, a UPS, a drive controller. Firmware is the one people forget, and it has two properties that make it dangerous: firmware vulnerabilities are often severe because the code sits beneath the operating system, and a failed firmware update can leave a device unbootable in a way a failed OS update usually does not. Never update firmware without a maintenance window and a way to recover the device.

End-of-support

End-of-support (EOS) is the date after which the vendor provides no support, no bug fixes and — critically — no security patches.

The previous lesson distinguished it from end-of-life: EOL means you can no longer buy it, EOS means you can no longer get it fixed.

Running past EOS means every vulnerability discovered from that date forward is permanent. That is not a theoretical risk; it is how a large proportion of successful intrusions begin. It also has consequences beyond security: compliance frameworks generally prohibit unsupported systems, and cyber insurance may decline a claim involving one.

Where replacement genuinely cannot happen — industrial control systems and medical devices are the standard examples — the answer is compensating controls: isolate the device on its own segment, restrict what may talk to it, and monitor it closely. That phrase is what an exam question is usually looking for.

Licensing and warranty support

Licensing covers the right to use software and features. In networking it is often feature-based: advanced routing, higher throughput, or a device's full port count may all be licence-gated, and a licence may be perpetual or a subscription that stops working when it lapses.

That last behaviour is the examinable one. An expired subscription can disable a feature — a firewall stopping threat-intelligence updates, or a wireless controller refusing to adopt new APs — producing an outage with no hardware fault and no configuration change. Tracking expiry dates in the asset inventory is what prevents it.

Warranty support is the vendor's obligation to repair or replace faulty hardware, and the level matters more than the existence. Next-business-day replacement and four-hour on-site are very different promises, and the right level depends on what the device does and whether you hold a spare.

Both belong in the asset inventory with their dates, because both fail silently — nothing tells you a warranty lapsed until you need it.

Service-level agreements

A service-level agreement (SLA) is a formal commitment about the level of service, between a provider and a customer. It may be with an external supplier or between IT and the business internally.

A meaningful SLA specifies:

• Availability, usually as a percentage. The figures are worth knowing: 99.9% allows about 8.8 hours of downtime a year, 99.99% about 53 minutes, and 99.999% about 5 minutes. Each extra nine costs considerably more.
• Performance targets — latency, throughput, packet loss.
• Response and resolution times, usually by severity.
• Support hours, and whether that is business hours or continuous.
• Remedies when the SLA is missed, typically service credits.

Two things the exam expects you to understand. An SLA is a contractual and commercial instrument, not a technical control — it does not make anything more reliable, it defines what happens when it is not. And your own service cannot promise more than its dependencies: an internal SLA of 99.99% on a circuit whose carrier SLA is 99.9% is a promise you cannot keep.

Wireless survey and heat map

A wireless survey/heat map documents actual radio coverage. A survey measures signal strength, noise and interference throughout a space; a heat map renders it as a colour overlay on the floor plan, so weak coverage and overlapping cells are visible at a glance.

Three kinds, at different points in a project:

• Predictive, modelled in software from the floor plan and construction materials, before anything is installed.
• Pre-deployment, walking the site with test APs to validate the model against the real building.
• Post-deployment, validating what was actually built and producing the documentation that gets kept.

Surveys are how wireless complaints stop being subjective. "The wifi is bad in the east meeting rooms" becomes a measurement showing coverage falling off at a specific wall, and the answer becomes a specific AP in a specific place. Re-survey after changes to the building — a new partition wall genuinely changes coverage.

Decommissioning

Decommissioning is retiring equipment properly, and it is examined mostly for the security step.

The sequence that matters:

1. Confirm nothing depends on it. The classic decommissioning incident is powering off a device that was still carrying something nobody remembered.
2. Remove it from service gradually — disable rather than unplug — so it can be restored quickly if something surfaces.
3. Back up the configuration before wiping, for reference.
4. Sanitise the data. This is the critical step. Network devices hold configurations with credentials, keys, VPN pre-shared secrets and SNMP community strings. A router sold on with its configuration intact is a disclosure of exactly the material an attacker most wants. Wipe to the vendor's factory-reset procedure, and for storage media use secure erasure or physical destruction.
5. Update the records — asset inventory, IPAM, monitoring, diagrams, DNS — so the estate's documentation matches reality.
6. Dispose of it lawfully, meeting electronic waste regulations, and keep the certificate of destruction where disposal is regulated.