Question 1

What two Claude Code features ensure documentation stays in sync with code changes during multi-file refactoring?

Accepted Answer

First, **explicit file inclusion with `@` mentions**: before asking for the refactor, I load all relevant files into context: `@README.md @examples/basic/main.tf @variables.tf @outputs.tf @main.tf`. This ensures Claude sees the full surface area and understands that README and examples are part of the change. Second, **task decomposition with verification steps**: instead of saying "Refactor to multi-region," I use a structured prompt: "Step 1: Refactor the module to support multiple regions. Step 2: Update the README.md to document the new `regions` variable and its default. Step 3: Update examples/basic to use two regions. Step 4: Verify that all variable references in examples match the updated variables.tf." Claude Code's **agentic loop** can execute these steps sequentially and self-correct if it detects mismatches. I also use **git diff review**: after Claude finishes, I run `git diff` to catch any files it missed. For critical refactors, I add a **pre-commit hook** that runs `terraform-docs` to auto-generate README from variables/outputs, ensuring documentation is always machine-generated and never stale.

Question 2

What three MCP security patterns prevent destructive operations in production, and how do you implement scoped permissions?

Accepted Answer

First, **read-only MCP tools by default**: configure the AWS MCP server with an IAM policy that only allows `List*`, `Describe*`, and `Get*` actions. Destructive actions (`DeleteBucket`, `TerminateInstances`) are not registered as available tools. If write access is needed, create a separate MCP server instance with a narrowly scoped policy and label it `aws-write-prod`. Second, **human-in-the-loop confirmation for destructive tools**: in the MCP server configuration, flag tools as `destructive: true`. When Claude attempts to call such a tool, the client (Claude Code) pauses and asks: "Claude wants to delete `s3://production-data`. Approve? (y/N)". This is implemented in the MCP server's `tool_call` handler by returning a `confirmation_required` response. Third, **environment segregation with separate MCP configs**: maintain `mcp-prod.json` and `mcp-dev.json`. The prod config only connects to read-only endpoints and sandbox accounts. Engineers must explicitly switch to dev config for write operations. I also implement **audit logging**: every MCP tool call is logged to CloudTrail or a SIEM with the user, tool name, parameters, and timestamp. For S3 specifically, I enable **S3 Object Lock** and **MFA Delete** so even if Claude somehow bypasses controls, deletion requires physical MFA. I verify scoped permissions with `aws iam simulate-principal-policy --policy-source-arn arn:aws:iam::xxx:role/ClaudeReadOnly --action-names s3:DeleteBucket`.

Question 3

What is the Claude Code context window limit, and what four strategies analyze files larger than the context window?

Accepted Answer

Claude 3.5 Sonnet has a **200K token context window** (~150,000 words or ~500 pages of text). A 50,000-line CloudFormation YAML file can easily exceed this when combined with system prompts and conversation history. Four strategies: (1) **Hierarchical decomposition**: ask Claude to first generate a table of contents / resource inventory: "List all AWS resources in this template with their logical IDs and types." This is small and fits in context. Then ask targeted questions: "Analyze the security group `WebServerSG` and its ingress rules." (2) **Chunking with overlap**: split the template into 10,000-line chunks with 500-line overlap. Ask Claude to analyze each chunk independently and maintain a running summary of findings. (3) **AST/parsing pre-processing**: use `cfn-lint` or a Python script to extract only security-relevant sections (IAM roles, security groups, NACLs) into a smaller file, then ask Claude to analyze the reduced file. (4) **RAG over the template**: convert the CloudFormation template into a vector store (e.g., chunk by resource block). When the engineer asks a question, retrieve only the top-5 most relevant resource blocks and feed them to Claude. I also use **Claude's extended thinking mode** (if available) for complex reasoning over large contexts, though this increases latency. For very large infrastructures, I recommend **migrating to smaller modules** (Terraform modules or CloudFormation nested stacks) which naturally fit in context and are easier for both humans and AI to reason about.

Question 4

What three Claude Code configuration changes make Bash mode safe for production infrastructure?

Accepted Answer

First, **disable Yolo mode in production contexts**: set `CLAUDE_YOLO=false` or use `--no-yolo` flag. In standard mode, Claude asks for explicit approval before every bash command. Second, **command allow-listing via `.claude-code` config**: create a `.claude-code/config.json` in the repo root with a `safe_commands` list: `["kubectl get", "kubectl describe", "terraform plan", "aws ec2 describe-*"]`. Any command not in the allow-list requires explicit approval. For destructive commands, add a `dangerous_commands` list that always requires typing the command name to confirm: `["kubectl delete", "terraform destroy", "aws ec2 terminate-instances"]`. Third, **RBAC on the shell environment**: the shell Claude Code runs in should use a service account with least-privilege permissions. Even if Claude executes `kubectl delete namespace production`, the service account's RBAC should deny namespace deletion. I configure this with `kubectl auth can-i delete namespace production --as=claude-bot` returning `no`. I also enable **audit logging** of all bash commands executed by Claude Code to a tamper-proof log (e.g., AWS CloudTrail for AWS CLI, `auditd` for local commands, Kubernetes audit logs for kubectl). For Kubernetes specifically, I use **OPA Gatekeeper** or **Kyverno** policies that prevent namespace deletion if it contains resources with `app.kubernetes.io/part-of: critical-system` labels.

Question 5

What prompt engineering technique ensures Claude generates idempotent, resume-capable scripts with exponential backoff?

Accepted Answer

The issue is that the prompt did not specify **idempotency, pagination, and error handling** requirements. The fix is **constraint-driven prompt engineering**. I structure the prompt as: "Write a Python boto3 script that tags all untagged EC2 instances and EBS volumes with `Environment=production`. Requirements: (1) Idempotent: running the script twice produces the same result and does not duplicate tags. (2) Resume-capable: if interrupted, running again resumes from where it left off. Use a DynamoDB table or local SQLite to track processed resource IDs. (3) Rate limiting: implement exponential backoff with jitter for AWS API throttling. Use `boto3`'s built-in `Config(retries={'''max_attempts''': 10, '''mode''': '''adaptive'''})`. (4) Parallel: process resources in batches of 10 using ThreadPoolExecutor. (5) Logging: log every API call, success, and failure to CloudWatch Logs." Claude Code then generates a script with `boto3.resource('dynamodb')` for checkpointing, `botocore.exceptions.ClientError` handling for throttling, and `concurrent.futures.ThreadPoolExecutor` for parallelism. I also ask for **dry-run mode**: "Add a `--dry-run` flag that logs what would be changed without making API calls." For verification, I run the script in dry-run mode first, then on a test AWS account, then production. I also use **moto** for unit testing AWS interactions without real API calls.

Question 6

How do you design a Claude Code prompt that distinguishes between liveness, readiness, and startup probes, and validates the semantic correctness of K8s configurations?

Accepted Answer

The fix is **domain-specific validation rules in the prompt**. Instead of asking "Fix the crash loop," I provide Kubernetes-specific constraints: "Review this deployment's probe configuration against the following rules: (1) Liveness probes should use a lightweight endpoint that does not depend on external services. `/healthz` is correct if it only checks the process is running. `/ready` is incorrect for liveness because readiness includes dependency checks (DB, cache), and a transient dependency failure would cause unnecessary pod restarts. (2) Readiness probes should check all critical dependencies. If the app needs PostgreSQL and Redis, `/ready` must verify both. (3) Startup probes should be used for slow-starting containers (>30s) and should match the liveness probe endpoint but with a longer `failureThreshold`. (4) `initialDelaySeconds` should not exceed `startupProbe.periodSeconds * startupProbe.failureThreshold`. Validate these rules and suggest corrections." I also ask Claude to **cite the Kubernetes documentation**: "For each suggestion, cite the relevant Kubernetes.io documentation section." This forces Claude to ground its answer in authoritative sources. For additional safety, I use **kubeconform** or `kubectl apply --dry-run=server` to validate the final YAML against the cluster's API server. I also run **kube-score** to evaluate the deployment against best practices. If Claude consistently makes probe errors, I add a **custom instruction** to `.claude-code/instructions.md`: "Never suggest using readiness endpoints for liveness probes. Always distinguish the three probe types."

Question 7

What prompt ensures Claude generates Python scripts with Bash-equivalent error handling, and what Python pattern replaces `pipefail`?

Accepted Answer

The prompt must explicitly request **strict error handling semantics**. I write: "Migrate this Bash script to Python. Requirements: (1) Every shell command must raise an exception on non-zero exit. Use `subprocess.run(..., check=True)` for all commands. (2) Every command output must be checked for errors in stderr, not just exit codes. If stderr contains 'error' or 'failed', raise a RuntimeError. (3) Unset environment variables must raise KeyError. Use `os.environ['VAR']` (not `.get()`) for required variables. (4) Pipe failure equivalence: if a pipeline of commands is used, check each step individually or use `subprocess.run` with `shell=False` and chain outputs manually. Do NOT use `shell=True`. (5) Add type hints for all functions and use `logging` instead of `print`. (6) Include a `main()` function with `try/except` that logs the full traceback and exits with the original command's exit code." The Python equivalent of `pipefail` is **individual command checking with temporary files or pipes**: `p1 = subprocess.run(['grep', 'error', 'log.txt'], capture_output=True, check=True); p2 = subprocess.run(['wc', '-l'], input=p1.stdout, capture_output=True, check=True)`. For complex pipelines, I prefer using Python's `sh` library or refactoring to native Python (e.g., `re.search` instead of `grep`). I also ask Claude to include **unit tests with `pytest` and `unittest.mock`**: mock `subprocess.run` to simulate failures and verify the script handles them correctly.

Question 8

What prompt structure prevents AI-generated CI/CD workflows from executing destructive actions on the wrong triggers?

Accepted Answer

The issue is an **underspecified trigger requirement**. The fix is **trigger-explicit prompting**: "Generate a GitHub Actions workflow for Terraform with the following trigger rules: (1) `terraform plan` runs on EVERY pull request against `main` and posts the plan as a PR comment. (2) `terraform apply` runs ONLY on push to `main` AND only if the PR was approved by at least one CODEOWNER. (3) `terraform destroy` is NEVER run automatically. It requires manual workflow_dispatch with an environment input and approval from a senior engineer. (4) Use OpenID Connect (OIDC) for AWS authentication, not long-lived secrets. (5) Add a job that runs `tfsec` and `checkov` before plan. (6) Use Terraform workspaces: `dev` for PR branches, `staging` for merge to `main`, `prod` for tagged releases." I also ask for **branch protection rules in the prompt**: "Document the required GitHub branch protection settings: require PR reviews, require status checks (`terraform-plan` must pass), and restrict pushes to `main`." For additional safety, I use **Terraform Cloud / Enterprise** with **speculative plans** on PRs and **manual apply** locks. I also configure **OPA (Open Policy Agent)** to evaluate Terraform plans against policies like "no destroy of resources tagged `environment=production`". If the plan violates policy, the apply is blocked regardless of the workflow. I verify the workflow with **act** (local GitHub Actions runner) before pushing to the repo.

Question 9

What prompt ensures Claude generates production-ready Ansible with parallelism, idempotency, and error recovery for network devices?

Accepted Answer

I structure the prompt with **Ansible best practice constraints**: "Generate an Ansible playbook to configure VLANs on 100 Cisco switches. Requirements: (1) Parallelism: use `strategy: free` and `forks: 50` in `ansible.cfg` to run against 50 devices simultaneously. (2) Idempotency: use `ios_config` with `lines` and `parents` so the task only applies changes if the config is missing. Include `diff: yes` and `save_when: changed`. (3) Error recovery: use `block/rescue/always` so if one switch fails, the playbook continues and logs the failure. In `rescue`, capture the switch name and error to a JSON file. (4) Facts caching: enable `fact_caching = jsonfile` and `fact_caching_connection = /tmp/ansible_facts` so subsequent runs do not re-gather facts. (5) Connection persistence: set `ansible_persistent_connection_idle_timeout = 300` to keep SSH connections open across tasks. (6) Validation: add a `post-task` that runs `show vlan brief` and verifies the output matches the intended configuration using `assert`. (7) Rollback: in `rescue`, use `ios_config` with `replace: config` and a backup file to restore the previous config." I also ask for **dynamic inventory**: "Use an inventory plugin (`netbox.netbox.nb_inventory` or `amazon.aws.aws_ec2`) instead of a static hosts file." For very large fleets, I suggest **Ansible Runner** or **AWX/Tower** with job slicing. I verify parallelism with `ansible-playbook -vvv` and check that forks are spawning correctly.

Question 10

What prompt augmentation ensures Claude performs comprehensive container security analysis, including capabilities, seccomp, and AppArmor profiles?

Accepted Answer

The issue is an **incomplete security checklist in the prompt**. I use a **structured security framework prompt**: "Analyze this Docker Compose file against the CIS Docker Benchmark v1.6.0 and the following security dimensions: (1) User context: check `user`, `runAsUser`, `runAsGroup`. Flag root. (2) Linux capabilities: check `cap_add` and `cap_drop`. NET_ADMIN, SYS_ADMIN, and ALL are high-risk. Recommend dropping all and adding only required caps. (3) seccomp: check `security_opt` for seccomp profiles. If missing, recommend a custom seccomp profile that blocks `mount`, `pivot_root`, and `swapon`. (4) AppArmor/SELinux: check for `security_opt: [apparmor:docker-default]`. If missing, recommend enforcement. (5) Network isolation: check `network_mode`. `host` network breaks isolation. Recommend bridge or custom networks. (6) Read-only rootfs: check `read_only: true`. If missing, recommend it with `tmpfs` for `/tmp`. (7) Resource limits: check `deploy.resources.limits`. Missing limits enable DoS. (8) Secrets: check for hardcoded env vars. Recommend Docker secrets or external vault. For each finding, rate severity (Critical/High/Medium/Low) and provide a corrected YAML snippet." I also ask Claude to **reference specific CIS sections**: "Map each finding to the relevant CIS Docker Benchmark section number." For validation, I use **Trivy** (`trivy config docker-compose.yml`), **Checkov** (`checkov -f docker-compose.yml`), and **Dockle** on the built image. These tools catch what Claude misses and provide a second opinion.

Question 11

What two Claude Code techniques extract the exact error from verbose Helm output, and what prompt structure focuses debugging on root cause?

Accepted Answer

First, **output filtering and grep integration**: instead of asking Claude to read all 2,000 lines, I pipe the Helm output through filtering before sending it to Claude: `helm install --debug --dry-run mychart ./chart 2>&1 | grep -E "Error|failed|cannot|unable|WARN" | head -50`. Then I ask Claude: "Explain these specific errors in the context of the Helm chart values." This eliminates noise. Second, **component isolation**: I ask Claude to debug one Kubernetes resource type at a time: "Render only the Deployment template: `helm template mychart ./chart -s templates/deployment.yaml`. Identify why the pod spec is invalid." Once fixed, move to Services, then ConfigMaps. For complex charts, I use **helm lint**: `helm lint ./chart` which provides structured warnings. I feed the `helm lint` output to Claude with the prompt: "Fix all `ERROR` and `WARN` entries in this lint output. Prioritize errors that would prevent installation." I also ask for **values validation**: "Write a JSON Schema for values.yaml that catches type mismatches before Helm renders." This prevents errors at the source. For the prompt structure, I use **RCA (Root Cause Analysis) format**: "Symptom: Helm install fails with `Error: unable to build kubernetes objects`. Context: [filtered error lines]. Task: Identify the root cause, the specific file/line, and the fix. Do NOT suggest generic fixes like 'check your cluster connection'."

Question 12

What prompt engineering pattern generates least-privilege IAM policies, and what validation pipeline ensures no wildcards slip through?

Accepted Answer

The fix is **action-explicit prompting with negative constraints**: "Generate an AWS IAM policy that allows a CI/CD service account to deploy Lambda functions. Requirements: (1) List EVERY required action explicitly. Do NOT use wildcards (`*`) in the Action field. Required actions: `lambda:CreateFunction`, `lambda:UpdateFunctionCode`, `lambda:GetFunction`, `lambda:AddPermission`, `iam:PassRole` (only for role `arn:aws:iam::xxx:role/LambdaDeployRole`). (2) Use `Resource` restrictions: every action must specify the exact Lambda ARN pattern `arn:aws:lambda:us-east-1:xxx:function:my-app-*`. (3) Add `Condition` keys: `StringEquals` on `aws:RequestedRegion` to `us-east-1`. (4) Include an explicit `Deny` statement for destructive actions: `lambda:DeleteFunction`, `iam:DeleteRole`. (5) Generate the policy in JSON format with comments explaining each statement." For validation, I use a **three-stage pipeline**: (1) **Static analysis with `tfsec` / `checkov`**: `checkov -f policy.json --check CKV_AWS_40` (ensures no `*`) and `CKV_AWS_107` (ensures IAM PassRole has resource constraint). (2) **IAM Access Analyzer**: `aws access-analyzer validate-policy --policy-document file://policy.json --policy-type IDENTITY_POLICY`. This finds issues like unused actions and overly broad access. (3) **Simulator test**: `aws iam simulate-custom-policy --policy-input-list file://policy.json --action-names lambda:DeleteFunction --resource-arns arn:aws:lambda:us-east-1:xxx:function:my-app-test`. The expected result is `ExplicitDeny`. If any stage fails, the pipeline blocks the PR. I also maintain an **IAM policy template library** with pre-approved least-privilege patterns that Claude can reference.

Question 13

What prompt constraints ensure Claude generates production-grade alerting rules with proper thresholds, durations, and runbook links?

Accepted Answer

I use a **Prometheus alerting standard prompt template**: "Generate Prometheus alerting rules for a Kubernetes cluster following these organizational standards: (1) Every alert MUST have a `for` duration of at least 5 minutes unless it is a page-zero (infra-down) alert, which can use `for: 1m`. (2) Every alert MUST use recording rules for complex queries. Do NOT put `rate()` or `histogram_quantile()` directly in the alert expression. (3) Severity labels: `critical` = page on-call immediately; `warning` = Slack notification during business hours; `info` = dashboard only. (4) Annotations: every alert MUST include `summary`, `description`, and `runbook_url`. The runbook URL must point to `https://wiki.internal/runbooks/{{alert_name}}`. (5) Labels: include `team`, `service`, and `severity`. (6) Threshold justification: explain why the threshold was chosen (e.g., '80% CPU allows headroom for burst traffic'). (7) Anti-flapping: if the metric is bursty, use `avg_over_time(metric[10m])` instead of instant value. (8) Grouping: alerts should be grouped by `alertname` and `namespace` to prevent alert spam." I also provide **examples of good and bad alerts** in the prompt. For validation, I use **promtool**: `promtool check rules alerts.yml` for syntax and `promtool test rules test.yml` for unit testing alert behavior against recorded time series. I also use **Alertmanager template validation** to ensure notifications render correctly.

Question 14

What prompt ensures Claude generates operationally safe secret rotation scripts with rollback capability and health verification?

Accepted Answer

The prompt must specify **transaction semantics and operational safety**: "Write a Python script to rotate PostgreSQL credentials in HashiCorp Vault with the following safety requirements: (1) Two-phase rotation: generate NEW credentials first, update the application config to use NEW credentials, verify the application health check passes for 60 seconds, then revoke OLD credentials. If health check fails at any point, roll back to OLD credentials. (2) Rollback: store the current credential version in a backup path (`secret/db/credentials/backup`) before rotation. If rollback is needed, restore from backup. (3) Health verification: the script must call the application's `/health` endpoint and verify HTTP 200 with `database: connected` in the response body. Retry 3 times with 10-second intervals. (4) Grace period: after revoking OLD credentials, wait for the application's connection pool to drain (use `pg_stat_activity` to verify no connections from the old username). (5) Idempotency: if the script is interrupted and rerun, it should detect the current state and resume safely. Use a state file (`/tmp/rotation-state.json`) to track progress. (6) Notification: send a Slack webhook on success or failure with the old username, new username, and rotation timestamp." I also ask for **Vault dynamic secrets** instead of static rotation: "Prefer Vault's database secrets engine with dynamic credentials and TTLs instead of manual rotation." For validation, I run the script in a **staging environment with chaos testing**: kill the application mid-rotation and verify rollback works.

Question 15

What metrics framework evaluates AI-assisted infrastructure engineering, and what three process changes reduce the incident rate?

Accepted Answer

The ROI framework balances **velocity, quality, and risk** across four dimensions: (1) **Development velocity**: time to write a Terraform module, Ansible playbook, or Python script (before/after AI). Target: 30-50% reduction. (2) **Review efficiency**: PR review time. AI-generated code with comments and tests reduces review cycles. (3) **Incident attribution**: % of incidents where root cause is AI-generated misconfiguration. Target: <5%. (4) **Knowledge transfer**: junior engineer time to onboard to a new technology using AI tutoring vs. traditional docs. To reduce the 15% incident rate: (a) **Mandatory AI output validation**: every AI-generated infrastructure change must pass `terraform plan`, `ansible-playbook --check`, `kubeconform`, and policy checks (OPA, Checkov) before human review. (b) **Canary deployments for AI-generated changes**: if a Terraform plan was AI-generated, apply it to a canary environment first and run smoke tests for 1 hour before production. (c) **AI-generated change tagging**: tag every PR/commit with `ai-assisted: true` in metadata. During incident post-mortems, query: "What % of incidents involved AI-assisted changes?" This creates accountability. I also implement **pair programming with AI**: the engineer must explain the AI-generated code to a peer before merging. This catches logical errors that automated tools miss. For ROI calculation: `ROI = (Time saved * hourly rate) - (Incident cost * incident increase)`. If time saved is $500K/year but incidents cost $200K/year, net ROI is $300K/year. I present this to the CISO with a **quarterly AI engineering dashboard** showing velocity, quality scores, and incident trends.

Claude Code for Infrastructure Engineers: 15 Real-World Interview Scenarios

More Network Automation Interview Prep