A wastewater plant’s Python requests scripts call controller HTTPS APIs and must trust only the civic PKI. Which TLS practice is correct?
Select an answer to reveal the explanation.
Short Explanation
TLS verify is the plant’s lock checking the controller’s badge against the city badge printer. Point requests at the civic CA trust store and keep verification on. verify=False or cleartext HTTP is leaving the gate open because the lock beeped.
Full Explanation
Wastewater Python requests scripts calling controller HTTPS APIs must trust only the civic PKI by enabling certificate verification using the civic PKI trust store (or properly pinned civic CA) for controller endpoints. verify=True with the right CA bundle prevents MITM on automation channels that can change network state. Lab convenience must not become production verify=False.
Setting verify=False on every call to avoid certificate errors disables essential TLS authentication. Pinning trust to a random public CA bundle unrelated to the plant’s issuing CA fails when controllers use private PKI. Downgrading controllers to HTTP so certificates never matter removes transport security entirely.
Exam caveat: separate lab and prod trust stores; do not import untrusted CAs into production runners. Operational check: point scripts at the civic CA bundle, confirm successful TLS to controllers, and fail CI if verify is disabled. Rotate controller certificates with automation downtime planned. Record the chosen control and rejected alternatives in the municipal change record so future on-call engineers understand the failure modes avoided for city services. Re-validate after the next maintenance window that telemetry, API results, and device state still match the documented design intent.