Infrastructure as Code
Infrastructure & DevOpsarticle · 6 मिनट · अपडेट 17 जुल॰ 2026

Infrastructure as Code

लेखक Rajendra Sharma, RN, CPC, CPBसमीक्षक Rajendra Sharma, RN, CPC, CPB · 17 जुल॰ 2026

Describe the infrastructure in a file, version it, review it, apply it. In health IT the real prize isn't speed — it's that your environment becomes auditable evidence rather than folklore.

In one line

Infrastructure as Code means the servers, networks and permissions are described in files you version, review and apply — instead of created by someone clicking through a console and then leaving the company.

Why health cares more than most

Every industry likes IaC for speed and repeatability. Health has a fourth reason that outranks those, and it's the one worth leading with: auditability.

Sooner or later someone asks a question you must be able to answer:

"Was this database encrypted in March, when the incident happened? Who had access to it? Who approved that?"

Without IaC, the honest answer is archaeology — console screenshots, an old ticket, and a colleague's memory. With IaC, the answer is a git commit: here is the change, here is who wrote it, here is who reviewed it, here is when it was applied. Your infrastructure history becomes evidence rather than folklore.

That's why the compliance value dwarfs the convenience value in this sector. A control you cannot demonstrate is, for audit purposes, a control you do not have.

The core ideas

  • Declarative, not imperative. You describe the desired state ("this bucket exists, it is private, it is encrypted"), and the tool works out the steps. You don't script the clicks.
  • Idempotent. Apply it ten times, get the same result. Nothing drifts because someone ran it twice.
  • The plan step. Terraform's plan shows what would change before anything does. In a clinical environment that dry run is not a nicety — it's the difference between reviewing a change and discovering it.
  • Environments from one definition. Dev, staging and prod from the same code with different variables — so "it worked in staging" starts to mean something.

Where it bites

Drift is real. Someone fixes production by hand at 3am during an incident. Entirely reasonable in the moment. Now the code and reality disagree, and the next apply may enthusiastically revert their fix. IaC doesn't prevent manual changes; it just makes them dangerous. The discipline — get the emergency fix back into code the next morning — is a human process, not a tool feature.

State files hold secrets. Terraform state can contain sensitive values in plaintext. Committing it to a public repo has ended jobs. Store it remotely, encrypt it, lock it, and treat it as sensitive data — because it is.

IaC is a very fast way to be wrong everywhere. The same property that lets you provision twenty environments correctly lets you open twenty security groups incorrectly, in seconds, with one merge. The review is the safety mechanism, and skipping it is how a typo becomes a breach.

The health-specific hooks

  • Encryption, logging and retention become code — reviewable and provable, rather than asserted in a policy document nobody checks against reality.
  • Residency becomes explicit. The region is in the file. A reviewer can see that someone tried to put a database in the wrong country.
  • Least privilege gets a diff. IAM changes go through review like any other code, so "why does this service account have admin?" has an answer with a name attached.

The one-sentence version: IaC's gift to health IT is not that you build faster. It's that you can prove what you built, and when, and who agreed to it.

संदर्भ

  1. HashiCorp — Terraform documentation
  2. AWS — Infrastructure as Code
  3. NIST — Security and Privacy Controls (SP 800-53 Rev. 5)

संबंधित entries