# Is Your Multicloud Pipeline Compliant? DevOps vs GitOps > [!question] Lingering Questions > - What measured audit-time or incident reduction has GitOps + an evidence locker actually delivered in the speaker's own FedRAMP/Protected B work? The talk is practitioner best-practice, not a measured study. > - Where does the immutable evidence locker itself sit inside the compliance boundary — who audits the auditor's store? > - What's the failure mode when automated reconciliation fights a legitimate emergency manual change? > [!tip] Article Ideas > - "Compliance gates are default-off feature flags with an auditor watching" — cross-domain piece connecting GitOps compliance gates to the vault's feature-flag material. > [!link] Cross Reference > - [[3. Resources/Permanent Notes/An Audit Trail Is Trustworthy Only When It Is a By-Product of the Work]] — the audit-trail-as-by-product claim from this source is already fully captured there; not duplicated here. > - [[3. Resources/MOCs/WordPress Hosting Security Stack MOC]] — governance-before-tooling and harden-once-reuse-everywhere base images map directly onto managed-WordPress fleet practice. > [!quote] Vocabulary > - **Evidence locker** — not a product, but any immutable, access-controlled store (a controlled git repo, an S3 bucket) where CI/CD automatically deposits scan reports, hardening checks, build logs, and promotion outputs as proof of compliance. > - **Boundary** (compliance sense) — the line between sensitive/classified data and evidence under evaluation versus non-sensitive data; drives data-residency requirements (e.g., FedRAMP → US, Protected B → Canada). ## Metadata - Source: [[3. Resources/Readwise/Full Document Contents/Articles/Is Your Multicloud Pipeline Compliant DevOps vs GitOps]] - Author: Sui Fonka Gonzalez (IBM) - URL: https://www.youtube.com/watch?v=VoZaUwsylOc ## Author's thesis For regulated, high-value multicloud markets (federal, healthcare, finance), classic DevOps isn't enough — compliance has to be built in from day one, and GitOps is the model that makes that structurally possible: because git holds the desired state, drift becomes mechanically detectable and the commit history doubles as the audit trail compliance frameworks demand. ## Key arguments 1. **Regulated multicloud is under-served and lucrative** because few teams carry the compliance know-how to compete there. 2. **GitOps' git-as-source-of-truth structure produces the audit trail as a side effect** of the deployment mechanism itself, not as a separately maintained log. 3. **Scalability should be redefined as consistency**, not raw capacity — a repeatable, standardized, compliant process replicated across clouds beats more clusters or CPU. ## Claim atoms ### GitOps turns the desired state into code so drift becomes detectable > [!quote] ID:rw_pending > "With GitOps… you define your deployment configuration as code. If there is any variation of those configurations, you have a way of detecting that drift… you use git as a source of truth." Where/why: ~04:30 — the core mechanism the rest of the talk builds on. ### Compliance must be designed in from day one, not appended > [!quote] ID:rw_pending > "You need to think about how you put the compliance since day one as you develop your workload… so you could build that deployment with confidence." Where/why: ~02:30 — the design-time-versus-bolt-on framing that motivates GitOps adoption. ### Scalability is consistency, not capacity > [!quote] ID:rw_pending > "Scalability is not necessarily about… I can increase the amount of clusters… It's more about consistency, how you could scale… in a way that the process is replicable." Where/why: ~41:00 — a reframing atom distinct from the audit-trail claim; worth its own Permanent note. ## Permanent candidates - The audit-trail-as-by-product claim is **already captured** by [[3. Resources/Permanent Notes/An Audit Trail Is Trustworthy Only When It Is a By-Product of the Work]] — not duplicated. - **Scalability-as-consistency** is a distinct, promotable claim not yet in the vault — promoted below. ## Processing checklist - [ ] Flag the bandwagon fallacy on the 60%-Argo-CD-adoption stat if this source is cited as evidence for tool choice rather than maturity - [x] Connect audit-trail atom to existing Permanent note rather than duplicating - [x] Connect into the relevant MOC — [[3. Resources/MOCs/WordPress Hosting Security Stack MOC]] ## Links - [[3. Resources/MOCs/WordPress Hosting Security Stack MOC]] — governance-before-tooling and evidence-locker patterns apply directly to managed-WordPress fleet compliance - [[3. Resources/Permanent Notes/An Audit Trail Is Trustworthy Only When It Is a By-Product of the Work]] — the primary claim already promoted from this source