Infrastructure as code

Infrastructure as code (IaC) is the practice of provisioning and managing infrastructure from machine-readable definitions kept under version control. In declarative IaC, the definition says what should exist and how it should be configured. The tool works out the operations needed to reach that target. A quant team can review changes to a market-data feed's queues, storage and access policies alongside changes to the code that consumes the feed. AWS CloudFormation documentation

Suppose a fictional price-feed stack has a message queue called price-queue with 2 partitions, or subdivisions of the message stream. Its metrics store retains data for 7 days. The proposed configuration declares 3 queue partitions, keeps metrics retention at 7 days and adds an audit log with 14-day retention.

The diagram uses simplified action labels. A real plan can distinguish an in-place update from a replacement that destroys and recreates a resource. For a feed, the distinction matters because replacement can interrupt delivery or discard queued data. A plan proposes operations based on the environment it inspected. Review and approval happen separately, and applying the plan executes the proposed operations. After a successful apply in this example, a fresh comparison would find all three settings matched, assuming no other changes. Terraform plan · Terraform apply

The configuration declares what should exist. In Terraform, state records which deployed object corresponds to each resource in that configuration and stores information about those objects. The tool normally reads the deployed resources during planning to refresh its view of what's there. If the audit log already exists outside Terraform's management, an import can associate it with the appropriate configuration address. Subsequent planning can then show which settings still need to change. Terraform state · Terraform import

Drift can appear even when the configuration in version control stays the same. Suppose that after applying the example, an operator sets metrics retention to 10 days through the cloud console. The configuration still calls for 7 days. Once the tool observes the edit, a normal plan can propose restoring 7 days. If the team decides to keep 10, it can update the configuration to record that decision. Applying a Terraform refresh-only plan updates the state record to reflect the live setting and leaves the declared target as it was. Terraform planning modes

Staging and production can share definitions while keeping separate state and deployment credentials. In Terraform CLI, workspaces separate state within a single backend. Where production needs its own access boundary, separate backends and environment-specific credentials limit which state and resources a staging run can touch. Terraform CLI workspace isolation

If an apply fails partway, Terraform keeps track of completed operations. Check what actually changed before planning again. Terraform apply errors

Once an apply succeeds, check its effect on the feed separately. For the queue change, a shadow run can show whether the strategy still receives fresh data and produces signals by its decision deadline. The SelfMadeQuant lesson Paper Trading and Staged Deployment shows how to set those checks and reconcile differences before advancing a trial. The preview is public and the full lesson requires membership.