<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Illya Kryushenko</title>
    <description>The latest articles on DEV Community by Illya Kryushenko (@architect-cz).</description>
    <link>https://dev.to/architect-cz</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F3898126%2F7f0846c6-6c60-4992-b7e6-3648c1f5391f.jpg</url>
      <title>DEV Community: Illya Kryushenko</title>
      <link>https://dev.to/architect-cz</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/architect-cz"/>
    <language>en</language>
    <item>
      <title>Trying to connect cloud architecture (CAF / Zero Trust) with IaC validation</title>
      <dc:creator>Illya Kryushenko</dc:creator>
      <pubDate>Sun, 26 Apr 2026 00:17:54 +0000</pubDate>
      <link>https://dev.to/architect-cz/trying-to-connect-cloud-architecture-caf-zero-trust-with-iac-validation-535e</link>
      <guid>https://dev.to/architect-cz/trying-to-connect-cloud-architecture-caf-zero-trust-with-iac-validation-535e</guid>
      <description>&lt;h2&gt;
  
  
  Trying to connect cloud architecture (CAF / Zero Trust) with IaC validation
&lt;/h2&gt;

&lt;p&gt;We often say that architecture defines intent, while Infrastructure as Code (IaC) defines implementation.&lt;/p&gt;

&lt;p&gt;But in practice, they drift apart very quickly.&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;Architecture lives in documents (CAF, Zero Trust, internal HLDs)&lt;/li&gt;
&lt;li&gt;IaC reflects what is actually deployed&lt;/li&gt;
&lt;li&gt;There is no reliable way to verify that one matches the other&lt;/li&gt;
&lt;/ul&gt;




&lt;h2&gt;
  
  
  The problem
&lt;/h2&gt;

&lt;p&gt;IaC gives us precision, but not meaning.&lt;/p&gt;

&lt;p&gt;Architecture gives us meaning, but not verification.&lt;/p&gt;

&lt;p&gt;So we end up in a situation where:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;a system is “correctly deployed”&lt;/li&gt;
&lt;li&gt;but architecturally wrong&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;And we only discover that during reviews, audits, or incidents.&lt;/p&gt;




&lt;h2&gt;
  
  
  A small experiment
&lt;/h2&gt;

&lt;p&gt;I built a small PoC to explore whether architecture can be represented as a structured model and validated against Terraform state.&lt;/p&gt;

&lt;p&gt;The idea is simple:&lt;/p&gt;

&lt;blockquote&gt;
&lt;p&gt;Risk → Control → Constraint → Implementation → Validation&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;Instead of validating individual resources, the model allows you to evaluate architecture at multiple levels:&lt;/p&gt;

&lt;h3&gt;
  
  
  Mapping level
&lt;/h3&gt;

&lt;ul&gt;
&lt;li&gt;
&lt;code&gt;PASS&lt;/code&gt; – resource matches expected configuration&lt;/li&gt;
&lt;li&gt;
&lt;code&gt;FAIL&lt;/code&gt; – resource exists but is misconfigured&lt;/li&gt;
&lt;li&gt;
&lt;code&gt;MISSING&lt;/code&gt; – resource is not present&lt;/li&gt;
&lt;/ul&gt;

&lt;h3&gt;
  
  
  Control level
&lt;/h3&gt;

&lt;ul&gt;
&lt;li&gt;
&lt;code&gt;FAILED&lt;/code&gt; – at least one mapping fails&lt;/li&gt;
&lt;li&gt;
&lt;code&gt;INCOMPLETE&lt;/code&gt; – partially implemented&lt;/li&gt;
&lt;li&gt;
&lt;code&gt;MISSING&lt;/code&gt; – not implemented at all&lt;/li&gt;
&lt;/ul&gt;

&lt;h3&gt;
  
  
  Risk level
&lt;/h3&gt;

&lt;ul&gt;
&lt;li&gt;
&lt;code&gt;EXPOSED&lt;/code&gt; – controls are not fully implemented&lt;/li&gt;
&lt;/ul&gt;




&lt;h2&gt;
  
  
  Example
&lt;/h2&gt;

&lt;p&gt;In the demo scenario:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;one control fails because of parameter mismatch&lt;/li&gt;
&lt;li&gt;another is only partially implemented&lt;/li&gt;
&lt;li&gt;another fails due to tag mismatch&lt;/li&gt;
&lt;li&gt;another is completely missing&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;The validator aggregates this into:&lt;/p&gt;

&lt;p&gt;&lt;code&gt;FAILED control → EXPOSED risk&lt;/code&gt;&lt;/p&gt;

&lt;p&gt;So instead of asking:&lt;/p&gt;

&lt;blockquote&gt;
&lt;p&gt;"Is this resource compliant?"&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;you can ask:&lt;/p&gt;

&lt;blockquote&gt;
&lt;p&gt;"Is this architectural risk exposed?"&lt;/p&gt;
&lt;/blockquote&gt;




&lt;h2&gt;
  
  
  What this tries to explore
&lt;/h2&gt;

&lt;p&gt;This is not about replacing IaC or policy engines.&lt;/p&gt;

&lt;p&gt;It’s about introducing an additional layer:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;linking architectural intent (risk / control)&lt;/li&gt;
&lt;li&gt;to implementation (Terraform)&lt;/li&gt;
&lt;li&gt;and verifying that link continuously&lt;/li&gt;
&lt;/ul&gt;




&lt;h2&gt;
  
  
  Open questions
&lt;/h2&gt;

&lt;p&gt;I’m still exploring whether this makes sense outside my own use case.&lt;/p&gt;

&lt;p&gt;Some questions I’m interested in:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;Does this model actually help in real environments?&lt;/li&gt;
&lt;li&gt;Is “control-level” validation useful, or is it overengineering?&lt;/li&gt;
&lt;li&gt;How would this scale in large architectures?&lt;/li&gt;
&lt;li&gt;Where would this break?&lt;/li&gt;
&lt;/ul&gt;




&lt;h2&gt;
  
  
  Repo
&lt;/h2&gt;

&lt;p&gt;I’ve put together a small working PoC with:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;a simple architecture model (YAML)&lt;/li&gt;
&lt;li&gt;a validator against Terraform state&lt;/li&gt;
&lt;li&gt;a demo showing different failure modes&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;👉 &lt;a href="https://github.com/Illya-Kryushenko/architecture-as-code" rel="noopener noreferrer"&gt;https://github.com/Illya-Kryushenko/architecture-as-code&lt;/a&gt;&lt;/p&gt;




&lt;p&gt;Happy to hear thoughts, especially from people working with Terraform, Azure, or security architecture.&lt;/p&gt;

</description>
      <category>devops</category>
      <category>terraform</category>
      <category>architecture</category>
      <category>cloud</category>
    </item>
  </channel>
</rss>
