Skip to content
Back to skills

Infrastructure

ASecurity

Use when an org role acts as infrastructure engineer and must design and operate compute, networking, storage and CI/CD as reproducible infrastructure as code. Covers Terraform or Pulumi plan/apply review, well-architected trade-offs, right-sizing and monitoring before incidents.

  • 21 stars
  • 0 votes
  • 1 copy
  • 11 views
  • Added September 22, 2026
devopsterraformgitdevopsci/cdsecurityperformance

Security analysis

A100/100

Scanned September 28, 2026

npx -y skills add monoes/monomind --skill infrastructure --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Infrastructure?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Infrastructure
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/monoes-infrastructure/badge)](https://www.skillsdirectory.com/skills/monoes-infrastructure)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: infrastructure
description: "Use when an org role acts as infrastructure engineer and must design and operate compute, networking, storage and CI/CD as reproducible infrastructure as code. Covers Terraform or Pulumi plan/apply review, well-architected trade-offs, right-sizing and monitoring before incidents."
tags: ["devops","cloud","terraform","reliability"]
tools: []
license: Apache-2.0
source: https://github.com/monoes/monomind
---
# Infrastructure — Best Practices

## Focus
Designs and operates the underlying systems (compute, networking, storage, CI/CD) that everything else runs on — reliability and reproducibility over feature velocity.

## Best practices
- Define infrastructure as code — every resource should be reproducible from a config file, not created by hand through a console.
- Design for the six well-architected pillars: operational excellence, security, reliability, performance efficiency, cost optimization, sustainability — trade-offs should be explicit, not accidental.
- Build in redundancy proportional to actual criticality — multi-AZ/multi-region for what truly needs it, not everything by default (cost matters).
- Automate scaling and load distribution (auto-scaling groups, load balancers) rather than manually provisioning for peak.
- Version and review infra changes like application code — plan/diff before apply, peer review before merge.
- Instrument before you need it — monitoring, logging, and alerting must exist before an incident, not get added after one.
- Keep environments (dev/staging/prod) as close to identical as practical to catch environment-specific failures early.

## Common pitfalls
- Manual, undocumented changes made directly against production that drift from the IaC source of truth.
- Over-provisioning "just in case" instead of right-sizing against actual load data.
- Treating monitoring/alerting as optional polish added after the first incident instead of a prerequisite.
- Ignoring cost pillar until the bill is a surprise — cost optimization is a design-time concern, not a later cleanup.

## Tools & techniques
- Infrastructure as Code (Terraform, Pulumi, CloudFormation) with plan/apply review gates.
- Well-Architected style review across reliability, security, cost, performance, and operations before major changes ship.
- Auto-scaling + load balancing configured against real traffic patterns, not guessed capacity.
- Centralized logging/monitoring (e.g., Cloud Monitoring/Logging equivalents) wired to actionable alerts, not noise.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…