Deployment Immutable Infrastructure Review Prompt

This prompt is designed for cloud architects and platform engineers who need to review an immutable infrastructure deployment design before it reaches production. It evaluates image promotion pipelines, environment reconstruction guarantees, state externalization, configuration injection points, warm-up strategy adequacy, and rollback simplicity. Use this prompt during architecture review gates, pre-production readiness checks, or when a team proposes a new immutable deployment pattern. The prompt assumes you have a deployment design document, infrastructure-as-code references, or a written proposal describing the intended immutable deployment approach.

The ideal input is a structured design document that covers the artifact pipeline, the compute substrate, the configuration injection mechanism, and the rollback procedure. If your input is a whiteboard sketch or a verbal proposal, the prompt will still produce a useful gap analysis, but the review will be limited by the fidelity of the input. The prompt is opinionated: it assumes immutability is the goal and will flag any pattern that relies on in-place mutation, runtime patching, or stateful instances that cannot be destroyed and recreated from a known artifact. It will also surface missing pieces such as the absence of a warm-up script, a configuration drift detection mechanism, or a rollback time SLA.

Do not use this prompt for mutable infrastructure patterns, live-patching strategies, or deployments where in-place updates are the primary mechanism. It is not suitable for reviewing database schema migrations, stateful cluster resizing, or pet-server management workflows. If your deployment mixes immutable and mutable components, apply this prompt only to the immutable portion and use a separate review for the mutable parts. The prompt is also not a substitute for a security architecture review or a cost optimization audit, though it will touch on configuration secret handling and resource provisioning as they relate to immutability.

Before running the prompt, gather the deployment design document, any infrastructure-as-code module references, and the team's answers to standard operational readiness questions. The prompt works best when you provide concrete details about the image build process, the configuration injection method, and the rollback procedure. Vague inputs will produce vague findings. After receiving the review, use the findings to update the design document and re-run the prompt to verify that gaps have been closed. The output is a structured review, not a deployment approval; human judgment is still required for risk acceptance decisions.

This template is the core of the playbook. It is designed to be copied directly into your LLM interface or prompt management system. The prompt instructs the model to act as a cloud architecture reviewer, systematically evaluating an immutable deployment design against a structured set of criteria. Before using it, you must gather the details of your proposed deployment design, including the image build pipeline, environment reconstruction process, state externalization strategy, and rollback mechanism. The quality of the review depends entirely on the specificity of the inputs you provide in the placeholders.

textCopy
You are a principal cloud architect specializing in immutable infrastructure and site reliability. Review the following deployment design for an immutable infrastructure pattern. Your review must be structured, evidence-based, and focused on production readiness, failure modes, and operational simplicity.

## Deployment Design Context
[DEPLOYMENT_DESIGN_DESCRIPTION]

## Review Criteria
Evaluate the design against the following dimensions. For each, provide a finding of 'Pass', 'Warning', or 'Fail', a concise explanation, and a specific, actionable recommendation.

1.  **Image Promotion Pipeline:** Is the artifact (e.g., AMI, container image) built once and promoted through environments without modification? Check for environment-specific configuration baking.
2.  **Environment Reconstruction:** Can a new, identical environment be provisioned from scratch using only the promoted artifact, infrastructure-as-code, and configuration? Check for manual bootstrapping steps.
3.  **State Externalization:** Is all persistent state (databases, file stores, sessions) fully externalized from the immutable compute instances? Check for local disk writes, in-memory session state, or log files that are not shipped off-instance.
4.  **Configuration Injection:** How is environment-specific configuration (e.g., database URLs, feature flags) injected at launch? Evaluate the safety of the injection mechanism (e.g., secrets manager, environment variables) and the risk of configuration-code coupling.
5.  **Rollback Simplicity:** How is a rollback executed? Evaluate if it is a simple pointer change to a previous, known-good artifact version. Check for data migration reversal complexity.
6.  **Warm-Up Strategy:** How are new instances warmed up before receiving traffic? Evaluate the adequacy of health checks, traffic ramping, and cache pre-warming to prevent cold-start errors.
7.  **Operational Access:** How do operators access instances for debugging? Evaluate if the design favors out-of-band tooling (e.g., centralized logging, remote exec) over SSH access, and if break-glass procedures are defined.

## Output Format
Return your review as a JSON object with the following schema:
{
  "overall_assessment": "Ready for Production" | "Conditionally Ready" | "Not Ready",
  "executive_summary": "A 2-3 sentence summary of the design's biggest strengths and most critical risks.",
  "findings": [
    {
      "criterion": "string",
      "finding": "Pass" | "Warning" | "Fail",
      "explanation": "string",
      "recommendation": "string"
    }
  ],
  "critical_risks": ["A list of the top 1-3 risks that could cause a production outage or data loss."]
}

## Constraints
- Base your review strictly on the provided [DEPLOYMENT_DESIGN_DESCRIPTION]. Do not invent missing details.
- If a criterion cannot be evaluated due to missing information, mark it as 'Warning' and state what information is needed.
- Prioritize risks that have a direct impact on availability, data integrity, or security.

To adapt this template, replace the [DEPLOYMENT_DESIGN_DESCRIPTION] placeholder with a detailed, structured description of your deployment architecture. The more precise your description—covering the build pipeline, IaC modules, state management, and rollback procedures—the more actionable the review will be. You can also adjust the review criteria list to match your organization's specific architectural standards or compliance requirements. The JSON output schema is designed to be machine-readable, allowing you to integrate this review directly into an automated architecture governance pipeline.

This prompt is designed to be called programmatically as part of a pull-request review or architecture approval gate. The primary integration point is a CI/CD pipeline stage that triggers after an infrastructure-as-code (IaC) change is proposed—such as a Terraform module update, a Packer image revision, or a Kubernetes deployment manifest change. The harness should extract the relevant IaC files, deployment configuration, and environment topology, then assemble them into the [DEPLOYMENT_SPEC], [IMAGE_PROMOTION_PIPELINE], and [ENVIRONMENT_CONFIG] placeholders before invoking the model. Because the review covers state externalization and configuration injection, the harness must also pull in related resources: database migration scripts, secret store references, and load balancer warm-up configurations. Without this full context, the model cannot assess whether stateful components have been properly externalized or whether configuration injection points introduce mutable drift.

A production harness must include pre-validation, structured output parsing, and a human approval step. Before calling the LLM, validate that all required placeholders are populated and that the combined context does not exceed the model's context window—if it does, prioritize the most recent changes and summarize stable infrastructure components. After receiving the response, parse the JSON output against the expected schema (including review_summary, findings[], risk_level, and recommendations[]). If parsing fails, retry once with a stricter output constraint instruction appended to the prompt. Because an incorrect infrastructure review can lead to deployment failures or data loss, always route findings with `risk_level:

high"or"critical

to a human reviewer via a Slack notification

Jira ticket

or PR comment. Log every review attempt—including the prompt version

model used

input hashes

and output—to an audit table for post-incident analysis. This audit trail is essential for governance reviews and for debugging prompt drift over time.

Model choice matters here. Use a model with strong reasoning capabilities and a large context window (e.g., GPT-4o, Claude 3.5 Sonnet) because the review requires cross-referencing multiple configuration files and identifying subtle interactions between image immutability, state externalization, and warm-up strategies. Avoid smaller or faster models that may miss indirect coupling. For teams running private deployments, a locally hosted model with equivalent reasoning performance is acceptable, but validate its output against a golden dataset of known infrastructure misconfigurations before trusting it in a blocking gate. Do not use this prompt as the sole approval mechanism for production deployments—always pair it with static analysis tools (e.g., Checkov, tfsec) and a human sign-off for changes affecting stateful services or network boundaries. The prompt is a review accelerator, not a replacement for engineering judgment.

To scale this across multiple services, wrap the prompt in a templated workflow that accepts service-specific parameters (e.g., service name, team, risk tier) and injects them into the prompt's [CONSTRAINTS] section. Store the prompt template in a version-controlled prompt registry, and track which version was used for each review. When the prompt is updated, re-run it against a curated set of past reviews to detect regressions in finding quality or risk classification. Finally, monitor the harness for common failure modes: context overflow causing truncated reviews, JSON parse failures from malformed model output, and false positives where the model flags acceptable patterns as risks. Each of these should trigger an alert to the platform team so the harness remains trustworthy over time.