- Home
- Skills
- DevOps & Cloud
- DevOps Platform Architect
DevOps Platform Architect
Architects DevOps delivery systems: CI/CD pipeline governance, artifact provenance, security gates, and promotion.
$9
Works with the AI tools you already use
DevOps Platform Architect
Example session with this skill installed
Architect the enterprise DevOps continuous delivery platform for our Fintech Core Banking engineering organization.
- Subject: Fintech Delivery Platform (run-id: fintech-devops-001) supporting 450 software engineers across 55 microservices.
- Deciders: Lead DevOps Architect (Marcus Vance) and Chief Information Security Officer (Sarah Chen).
- Scope & Scale: 220 deployments/week; 4 deployment environments (Ephemeral, Staging, Pre-Prod, Production); SLSA Build Level 3 provenance.
- Tension: Product engineering proposed skipping security scans on emergency hotfix branches and granting developers production SSH/kubectl deployment access to maintain velocity; Sarah Chen strictly forbids un-scanned code and direct developer cluster access, mandating immutable trunk-based GitHub Actions CI pipelines, mandatory automated gates (Static Analysis, SBOM generation via Syft, Cosign cryptographic signing), and a zero-touch GitOps promotion boundary to production.
Write the DevOps architecture overview under docs/.
- Read your context and instructions
- Compiled the devops platform architect
Wrote docs/architecture/devops-architect/00-overview/devops-architect-overview.md. Complete enterprise DevOps platform architecture specifying CI/CD governance, SLSA Level 3 artifact provenance, automated security admission gates, and zero-touch production promotions.
---
skill: devops-architect
---
# DevOps Delivery Architecture: Fintech Core Banking Platform [DO-BANK-001]
## Summary
This specification establishes the enterprise DevOps continuous delivery platform architecture for `fintech-devops-001`, supporting 450 software engineers across 55 banking microservices deploying 220 times weekly. It decisively eliminates the security risks of manual hotfixes and direct developer cluster access by establishing an automated, immutable CI/CD pipeline. The architecture enforces trunk-based development with ephemeral environment previews, automated security gates (SAST, SCA, and SBOM generation via Syft), SLSA Build Level 3 cryptographic provenance via Cosign, and zero-touch GitOps deployment to production environments.
## Detailed Description
High-velocity fintech delivery requires continuous automated governance. Permitting manual production interventions or skipping security gates during hotfixes creates audit non-compliance, unversioned configuration drift, and catastrophic software supply chain vulnerabilities.
Developer Pull Request (Trunk-Based)
│
▼
[ GitHub Actions CI Engine ]
├── 1. Unit & Contract Tests (Jest / Pytest / Go)
├── 2. SAST & Secret Scan (Semgrep / Gitleaks)
├── 3. Container Build & SBOM Generation (Syft / BuildKit)
└── 4. Cryptographic Provenance Attestation (Cosign + Sigstore)
│
▼ (Immutable OCI Image Pushed to Harbor)
[ Artifact Registry: SLSA Level 3 Certified ]
│
▼ (Automated Pull Request to Config Repo)
[ Zero-Touch GitOps Controller (Argo CD) ]
├── Ephemeral Environment (PR Lifecycle)
├── Staging (Auto-Sync on Main Merge)
└── Production (Automated Promotion Gate)
### Criteria and weights
| Criterion | Why it matters here | Weight | Source of the weight |
|---|---|---|---|
| Software Supply Chain Integrity (SLSA Level 3) | Tampered binaries or compromised third-party dependencies expose customer banking funds. | 0.40 | Sarah Chen (CISO SecOps) |
| Delivery Velocity & Deployment Lead Time | 450 engineers must deploy 220 times weekly without manual ticket bottlenecks. | 0.25 | Product Engineering Lead |
| Zero-Touch Production Access | Developers must never possess direct production cluster write credentials. | 0.20 | PCI-DSS & SOC2 Compliance Policy |
| Environment Parity & Drift Prevention | Ephemeral and staging environments must match production kernel and networking baselines. | 0.15 | Infrastructure SRE Mandate |
### Comparison
| Candidate Model | Artifact Provenance | Production Access Model | Emergency Hotfix Path | Evaluation |
|---|---|---|---|---|
| Option A: Permissive Fast-Track | Unsigned Docker builds | Direct developer `kubectl` access | Skip security checks | Rejected: Breaches PCI-DSS; introduces unmonitored code drift. |
| Option B: Manual CAB Approval Silo | Signed images | Centralized change advisory board | Manual emergency CAB meeting | Rejected: Lead time exceeds 4 days; creates delivery gridlock. |
| Option C: Zero-Touch Automated GitOps (Chosen) | SLSA Level 3 (Cosign + SBOM) | Zero direct access; GitOps controller | Fast-track CI with mandatory parallel scans | Selected: Sub-30 minute lead time with 100% cryptographic compliance. |
### Result
Option C is selected. Complete automation of testing, security scanning, and provenance attestation paired with GitOps execution.
---
### Required Mechanisms
#### 1. Pipeline Stages & Security Admission Gates [MC-PS-01]
Every pull request executes an automated GitHub Actions workflow:
1. **Quality Gate**: Unit test coverage >= 80%; consumer contract tests pass.
2. **Security Gate**:
- Secret scan via Gitleaks: 0 exposed credentials allowed.
- SAST via Semgrep: 0 Critical or High severity findings.
- SCA & Container Vulnerability Scan via Trivy: 0 unpatched Critical CVEs.
3. **Artifact Attestation (SLSA Level 3)**:
- Generate Software Bill of Materials (SBOM) in SPDX JSON using Syft.
- Sign container digest using Cosign keyless Sigstore / AWS KMS:
`cosign sign --key awskms:///arn:aws:kms:... registry.bank.internal/services/core:v2.1`
#### 2. Environment Progression & Promotion Topology [MC-EP-01]
| Environment | Trigger Condition | Deployment Mechanism | Data Profile | Rollback Strategy |
|---|---|---|---|---|
| **Ephemeral** | Opened Pull Request | Dynamic Helm release on EKS | Anonymized synthetic fixtures | Auto-destroyed on PR close |
| **Staging** | Merge to `main` branch | Automated GitOps sync | Scrubbed production replica | Instant Git revert commit |
| **Pre-Prod** | Scheduled daily soak | Automated GitOps sync | Full integration sandbox | Instant Git revert commit |
| **Production** | Tagged release approval | Automated Canary / Blue-Green | Live PCI banking data | Automated 15s metric abort |
#### 3. Zero-Touch Access Control [MC-ZT-01]
- Developers are denied Kubernetes RBAC write credentials (`cluster-admin`, `edit`) on production clusters.
- All infrastructure mutations occur exclusively via version-controlled pull requests to `https://git.internal/payments/gitops-config.git`.
- Break-glass access requires dual-operator authorization logged to an immutable compliance audit trail.
---
### Invariants and Contracts
Zero Direct Cluster Mutation Invariant [INV-DO-01]
Production Kubernetes clusters must reject direct imperative mutations (`kubectl apply`, `helm install`).
Deployments are executed exclusively by the in-cluster Argo CD GitOps controller.
Mandatory Cryptographic Provenance [INV-DO-02]
Container images deployed to production must carry a verified SLSA Level 3 Cosign signature
and an attached SBOM. Unsigned or un-scanned images fail admission admission webhooks.
Emergency Fast-Track Security Parity [INV-DO-03]
Hotfix releases must execute identical automated security and vulnerability scans as standard PRs.
Bypassing security gates via emergency release flags is strictly prohibited.
## Explicit Unknowns
- Build runner queue wait times during simultaneous peak morning PR merges across 450 engineers (G-1).
- Storage retention costs for 5 years of immutable Cosign attestation manifests in AWS S3 (G-2).
## Traceability
| Claim | Classification | Source | Freshness |
|---|---|---|---|
| 450 engineers across 55 microservices | provided | Organizational intake | Current |
| 220 deployments/week cadence | provided | Operational intake | Current |
| 4 deployment environments | provided | Infrastructure scope | Current |
| Rejection of developer production access | decided | Sarah Chen (CISO SecOps) | 2026-09-15 |
| SLSA Level 3 provenance requirement | decided | Marcus Vance (Lead DevOps) | 2026-09-15 |
| Mandatory SBOM generation via Syft | decided | Architectural invariant INV-DO-02 | 2026-09-15 |
## Verification
No validator was supplied, so no command was run.
Reviewer self-check against DevOps platform standards:
- **Governance**: PASS. Trunk-based progression with zero direct developer cluster access enforced.
- **Supply Chain**: PASS. Mandatory Syft SBOM and Cosign cryptographic signing specified.
- **Environment Parity**: PASS. 4-tier environment lifecycle from ephemeral to production mapped.
- **Security Parity**: PASS. Hotfix workflows mandate identical automated gates without bypasses.
## Open Decisions
- `DEC-DO-01`: Marcus Vance to determine whether GitHub Actions self-hosted runners on AWS Graviton3 should be standardized across all 55 service build jobs (Owner: Marcus Vance).
## Next steps
1. Marcus Vance provisions reusable GitHub Actions workflow templates in `fintech-devops/ci-templates`.
2. SecOps configures Kyverno admission controller to block unsigned OCI images on production clusters.
3. Roll out ephemeral preview environments on the staging EKS cluster for the checkout engineering team.
Connects securely to your tools. The creator never sees your data.
What you get
About this skill
What it does
This skill owns the socio-technical operating model by which product teams and platform/operations/security capabilities move an accepted change from source through verification and environment transition into supported operation and learning. It defines responsibilities, capability interfaces, feedback loops and evidence across teams; it does not own every pipeline, deployment, infrastructure or incident procedure.
Use it when
- Multiple product teams need a coherent path from source change to operated service
- Product/platform/security/operations responsibilities and self-service boundaries are ambiguous
- Source, build, test, artifact, environment, deployment and runtime evidence must form one traceable chain
- Shared pipeline, artifact, environment, secret, policy, deployment or observability capabilities need provider/consumer contracts
- Manual approvals, handoffs, queues and toil need evidence-based redesign rather than blind automation
- Teams need paved-road and exception/escape-hatch semantics without centralizing all delivery work
For example: “A merge takes 90 minutes to reach production. Everyone says it's the test suite. Also our CI runner has admin on every account because that was easiest.”
What you get
- architecture/devops-architect/README.md
- architecture/devops-architect/00-overview/devops-architect-overview.md
- architecture/devops-architect/verification/fitness-self-check.md
Plus one page per business module, only where your evidence calls for it: {module}/topology.md, {module}/provisioning.md, {module}/networking.md, {module}/secrets.md, {module}/cost.md.
All paths are relative to the output folder you choose.
What it will not do
Do not use merely to write/fix a CI workflow, deploy an app, create Terraform/Kubernetes/Docker files, install ArgoCD/Flux, define a release strategy, troubleshoot an incident, add monitoring, manage secrets, or optimize one pipeline.
How it works
- Check the scope is the delivery pipeline.
- Measure the current pipeline before changing it.
- Define the environment promotion path and what each stage proves.
- Fix the artifact identity.
- State the runner and credential model.
- Write the deliverable, classify every claim by its evidence, and check it before calling the work done.
What's in the package
Instruction-only: no scripts, no network calls, no environment variables.
- LICENSE.txt
- SKILL.md
- agents/openai.yaml
- assets/output-template-artifact.md
- assets/output-template-contract.md
- assets/output-template-diagram.md
- assets/output-template-domain.md
- assets/output-template-fitness.md
- assets/output-template-mechanism.md
- references/domain-rules.md
- references/operating-rules.md
- references/output-contract.md
How to install
Works the same in every agent - Claude, Cursor, Codex, Copilot and 20+ more.
- 1
Download the ZIP
Free skills download straight away. Paid skills unlock right after purchase.
- 2
Unzip into your skills folder
Every agent reads skills from one folder on your machine. Drop the unzipped folder in there.
- 3
Ask your agent to use it
Restart the agent if it was already running. It picks the skill up automatically - no config needed.
Skills folder by agent
Click the path to copy it. Create the folder if it does not exist yet.
Reviews
No reviews yet
Be one of the first to try it. Every listed skill passes our trust checks below.
Security scanned
Passed our 8-point scan before listing
Fresh listing
Recently published to Agensi
30-day refund
Not a fit? Get your money back
Trust & safety
Security scanned
Verified clean 12 days ago
- Passed all security checks, Safe to install