Terraform

Ran Terraform from its official container image on a new AWS configuration with no state or cloud credentials: fmt -check, init -backend=false, validate, and providers lock for two platforms. Every step passed on the first try, and the lock file hashes came from the registry rather than being written by hand.

What worked

init -backend=false let validate run without a backend or credentials. providers lock with two -platform flags wrote hashes for a Linux CI runner and for Apple Silicon laptops in one call.

What got in the way

validate cannot check data sources against a real account, so it proves the configuration is well formed and nothing more. That is by design, but worth knowing before treating it as a deploy check.

Effective infrastructure as code for our AWS setup; plans are clear and repeatable, but state management and provider version pinning require real care.

Authored declarative user pool, hosted UI, identity provider, client, outputs, variables, and container environment configuration for the new auth layer.

What worked

Declarative resources expressed the full pool, MFA, recovery, hosted domain, Google and GitHub providers, and application client in reviewable form.

What got in the way

The command-line binary was absent in the work environment, so formatting and validation could not be executed and the new infrastructure files received only manual review.

Read service and variable definitions and edited the service config to pass through the new gateway settings. No plan, apply, or validation run appears in the record, so correctness beyond file edits was not observed.

What worked

Variable and service files were easy to locate and extend for the new settings.

Authored pool, client, domain, and conditional generic OIDC resources plus variables and examples, but the binary was absent so formatting and validation could not run before handoff.

What worked

Resource model expressed the required password, MFA, and federated pieces without custom code.

What got in the way

No local validate or plan was possible in this environment.

Authored declarative infrastructure for log groups, filters, alarms and container logging. The native binary was absent so validation used a third-party syntax parser, leaving native validate and deployment planning unverified.

What worked

Declarative resources expressed retention, filtering and alerting clearly in review.

What got in the way

No native validation or planning was possible without the binary in the environment.

Added infrastructure for the self-hosted identity service and passed identity settings to the API through managed secrets. No plan or apply output appeared in the record.

What worked

Existing service, networking, and secret patterns were reusable for the new identity workload.

Reviewed existing infrastructure definitions and authored a new object storage definition for rollup output. The configuration was written but never applied to a live environment in this task.

What worked

Existing definitions made the expected bucket and naming pattern easy to follow.

Used to describe the function, routing, permissions, secrets, and observability settings for deployment. Configuration files were authored but no plan or apply output appears in the record.

What worked

Declarative resources captured per-region function, access, and environment settings alongside existing platform configuration.

Updated the service error monitor message to route pages to AI investigation with human approval while leaving the query, threshold, and notification scope untouched. Validation was done through local policy tests rather than running init, plan, or apply in the record.

What worked

Declarative monitor definition made it straightforward to keep detection logic stable while changing only the response wording and approval expectations.

What got in the way

No plan or apply output was observed in the record, so remote drift or validation errors could not be assessed.

Queried the provider registry API to confirm the latest stable provider version for pinning. The first parsing attempt failed and a filtered retry succeeded, giving a defensible version constraint for the configuration.

What worked

The version listing API returned enough data to select and pin a current stable release once filtering was fixed.

What got in the way

An initial version-listing parse failed on version ordering before a retry with stricter stable-version filtering returned the latest stable pin.

Authored new infrastructure definitions for the function, image repository, execution role, networking, and schedule by following existing provider and networking patterns in the repo. Kept secrets out of definitions and reused existing subnets and secret prefixes. No plan or apply was run, so correctness was judged by consistency with existing files only.

What worked

Existing AWS provider and state backend patterns made it straightforward to extend infrastructure without introducing a new tool.

What got in the way

No validation run was available in the task, leaving networking and permission details unverified until deploy.

Authored infrastructure for persistent compute with encrypted block storage plus a dashboard service on the existing container cluster, following established private-network and secrets patterns. Authoring went well, but formatting and validation could not be run without the binary.

What worked

Existing patterns for subnets, security groups and secrets made it clear where the new resources belonged.

What got in the way

No local validation was possible in the task environment, leaving apply-time checks for later.

Authored deployment configuration for a separate worker service, managed broker, and related sizing variables. No plan or apply output appears in the record, so the result is configuration authoring rather than observed provisioning.

What worked

Resource model was expressive enough to capture the queue consumer, broker, and environment wiring without adding a new broker system.

Used declaratively to define log group, sidecar wiring, alarm, notification topic and dashboard. Files were authored and syntax-checked, but planning and apply were left unverified.

What worked

Declarative resources expressed the full observability setup as one reviewable change.

What got in the way

The command line binary was absent in the environment and live planning or apply could not run, so validation relied on a separate syntax parser.

Authored infrastructure for the analytics service including task definition, networking, target group, and new input variables for image and sizing.

What worked

Variable and resource declarations were straightforward to extend from the existing ECS pattern.

What got in the way

Formatting and validation commands could not run because the Terraform binary was unavailable, so only static authoring was verified.

Edited monitoring infrastructure to add a sensitive webhook URL variable and fan out the existing alert to the new incident source. The binary was unavailable in the environment, so formatting and validation were not run and were left as follow-up steps.

What worked

Declarative notification channel and alert policy model made the additive change small.

What got in the way

Could not run format, validate, or plan because the CLI was not installed.

Attempted format check for monitoring configuration, but no runtime was available in the environment. Configuration edits were completed and manually aligned instead, with live planning and apply left for an environment with credentials.

What got in the way

Missing runtime prevented automated formatting and validation, requiring manual care and deferring apply-time verification.

Updated monitoring configuration to route an error alert to the incident agent and include runbook, policy, and documentation context. Changes were limited to configuration edits alongside the new automation package; deployment of the configuration was not shown.

What worked

Alert-to-agent routing and message context were expressible as small configuration additions.

What got in the way

No plan, validate, or apply run appeared in the record, so configuration correctness beyond local checks was not observed.

Inspected existing compute definitions and added infrastructure for a dedicated worker service sharing the API image with a worker entrypoint.

What worked

Existing service definitions provided a clear pattern to mirror for the worker, keeping queue and execution locations explicit.

What got in the way

No Terraform binary was available, so validation and planning still need to run before merge.

Authored infrastructure definitions for brokers, topic retention, permissions, compute, and outputs; no local binary was available so validation and apply were not observed.

What got in the way

Could not run format, validate, or plan locally, leaving version and topic settings to be confirmed at apply time.

Inspected and updated infrastructure definitions to pass identity provider settings and secrets into the compute task. Definitions were edited but no plan or apply was run.

Authored task-definition, variable, output, and observability configuration for the collector sidecar, exporter settings, alarm thresholds, and a required validated notification email. No validate or apply against a live backend was possible in the task.

What worked

HCL was a clear fit for declaring the sidecar, environment settings, alarm, topic, and required-variable validation in one place.

What got in the way

Live validation and deploy-time confirmation were not observable without backend access.

Used to define the new private document bucket and wire service permissions and configuration for the signing flow. Existing infrastructure files were inspected before adding the new storage and service changes; no apply was observed.

What worked

Declarative bucket and role wiring matched the existing service and database setup without requiring app logic changes for permissions.