Why a successful deployment is no guarantee of operational control.
A new order management application is almost ready to go live. Before signing it off, the IT team runs one final security test.
The application needs to communicate with the ERP system and store documents in the DMS. It has no business accessing other internal systems.
So the team tests two connections: one to the ERP, which should succeed, and another to the internal HR database, which should be blocked.
Both connections succeed.
Nothing else suggests a problem. The deployment pipeline reports success. The configuration is version-controlled. Monitoring shows no anomalies. Even the network policy appears exactly where it should be, safely committed to the repository.
The problem only becomes visible when someone tests a connection that should never have worked.
The scenario is hypothetical. The failure mode is not.
The rule was there. The protection wasn’t.
Kubernetes allows applications to restrict network traffic through NetworkPolicies.
But a policy does not provide protection merely by existing.
It depends on a networking component capable of enforcing it. Without that support, the policy has no effect. Incorrect selectors can also leave the very workloads a rule was meant to protect outside its scope.
A configuration can therefore be deployed successfully, creating the appearance of security while actual network traffic tells a different story.
The difference between a defined rule and an effective control is evidence that it works.
The same distinction applies to GitOps.
GitOps systems continuously reconcile the actual state of infrastructure against a version-controlled desired state. They make deviations easier to detect and can restore the intended configuration.
What they cannot determine is whether that configuration was right in the first place.
A flawed configuration can be reproduced just as reliably as a sound one.
A dashboard doesn’t make decisions.
Suppose the team corrects the access controls and repeats the security test. This time, the unwanted connection is blocked.
A few days later, the order management application starts slowing down. Requests take longer to complete, and monitoring detects rising latency.
Now the question is different: What’s causing it?
Was it the latest deployment? The ERP system? An external dependency?
Distributed tracing, using technologies such as OpenTelemetry, can help follow requests across service boundaries and reveal where delays occur.
But even comprehensive telemetry cannot, on its own, explain why something changed. Nor can it decide whether rolling back a deployment is the right response.
A premature rollback might undo a perfectly sound change while leaving the real problem untouched.
And restoring an earlier application version is not the same as recovering the data, dependencies and business processes that make the application useful.
Monitoring makes change visible. Operational control begins when that information leads to informed, accountable decisions.
Control emerges between systems.
This is where architecture becomes essential.
Identity determines who is allowed to act. Network policies define permitted communication. Deployment systems manage configuration. Monitoring provides signals. Recovery procedures establish a possible route back.
Each component has a purpose.
But no single component can establish control over the entire operating environment.
That depends on how the components, their information and their responsibilities fit together.
Three questions help make that connection visible:
- Authorization: Who is permitted to initiate a change?
- Effectiveness: How do we verify that our policies and configurations actually do what they are supposed to?
- Response: Who decides what to do when something goes wrong, and how do we restore normal operations?
Answering them does not necessarily require another platform or a larger technology stack.
Often, the first meaningful improvement is to make existing systems, their dependencies and the responsibilities between them understandable and verifiable.
Working isn’t the same as being under control.
A green pipeline confirms that a deployment succeeded. A dashboard reports what our instruments can observe. A policy describes an intended rule.
None of these, in isolation, proves that operations are under control.
Good architecture does more than make systems work. It helps us understand how they behave, recognize when reality diverges from expectation, and know how to respond.
Sources and Further Reading
- Kubernetes – Network Policies
- OpenGitOps – Principles
- OpenTelemetry – Observability Primer
- Google SRE – Service Level Objectives
- NIST – Zero Trust Architecture
The opening scenario is hypothetical. The technical discussion draws on documented architectural mechanisms and the principles derived from them.
