Chapter 27 — Deployment and validation

Chapter 27 — Deployment and validation

Lesson map

Lesson 27 published. Map, example, EX079.

flowchart TD
  N0["Learning outcomes"]
  N1["27.1 Planning deployment"]
  N2["27.2 Validation"]
  N3["27.3 Rollback"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX079"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["27.1 Planning deployment"]
  N2["27.2 Validation"]
  N3["27.3 Rollback"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX079"]

[Learning outcomes]
    |
    v
[27.1 Planning deployment]
    |
    v
[27.2 Validation]
    |
    v
[27.3 Rollback]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX079]

Learning outcomes

You will (1) plan a safe deployment of TLS configuration changes; (2) validate changes against requirements; (3) roll back when validation fails.

27.1 Planning deployment

The council plans to remove TLS 1.0 and 1.1 from all public endpoints and enable TLS 1.3 where missing, following NIST SP 800-52 Rev. 2. Rosa plans a staged deployment: first the test environment, then a low-traffic endpoint, then the rest in batches. Each stage has a validation step and a rollback trigger. She also notifies partners whose old systems might break, including the parking terminals identified earlier through monitoring. Each batch is scheduled outside peak permit hours, and the service desk receives a short note explaining what citizens might report. She writes rollback commands into the plan in advance, tested in the lab.

27.2 Validation

For each endpoint Rosa validates by connecting with clients that offer only old versions to confirm rejection, and with modern clients to confirm TLS 1.2 and 1.3 work. She checks the certificate chain and that the monitoring failure rate stays near baseline for a day. Validation is written as a checklist with expected results, so results are compared, not interpreted loosely. She saves outputs as evidence for the change record. Any unexpected result stops the batch until it is explained, even if users have not complained. Results are attached to the change ticket for auditors.

27.3 Rollback

On the third batch, the failure rate on one endpoint rises above two percent within an hour. Logs show an older payment kiosk using TLS 1.0. Rosa rolls back that endpoint as planned, notifies the kiosk supplier and sets a deadline for their upgrade, with the risk accepted temporarily by the service owner. The other endpoints stay changed. She records that rollback worked within ten minutes, which is itself evidence that the plan was sound. The kiosk supplier's deadline is tracked in the risk register, with automatic reminders to the service owner.

Worked example

Rosa deploys TLS changes in stages, validates with old and new clients, and rolls back one endpoint when a TLS 1.0 kiosk fails.

Synthetic case. The deployment is invented; SP 800-52 Rev. 2 is real.

Errors and limits

Big-bang changes make failures hard to isolate. Temporary risk acceptance needs a deadline.

Exercises

• EX079 — Staging. What stages did the deployment use? Rubric: 3 = test, low-traffic endpoint, then batches;; 2 = three;; 1 = one;; 0 = none.
• EX080 — Validation test. How did Rosa confirm old versions were rejected? Rubric: 3 = connecting with clients offering only old versions;; 2 = test;; 1 = assume;; 0 = none.
• EX081 — Rollback cause. Why was one endpoint rolled back? Rubric: 3 = failure rate above two percent from an older TLS 1.0 payment kiosk;; 2 = cause;; 1 = vague;; 0 = none.

Synthesis

Staged deployment with written validation and rehearsed rollback lets trust improvements proceed safely.

Continue studying — chapter 27 of 30

← Chapter 26 (draft) · Course chapter index · Chapter 28 (draft) →