Deployed d697ff5 with MkDocs version: 1.5.3

blog/2024/04/index.html

@@ -106,7 +106,7 @@
         D --> H[Online]
         E --> I[Connectivity]
         E --> J[Identity]
-        E --&gt; K[Management]</code></pre> <ol> <li><strong>Root Management Group</strong><ul> <li>Intermediary-Management-Group<ul> <li>Decommissioned: This could be where resources that are being phased out or decommissioned are managed.</li> <li>Sandboxes: This could be an area where developers can test and experiment without affecting production systems.</li> <li>Landing Zones<ul> <li>Corp: This could represent corporate resources or applications.</li> <li>Online: This could represent online or customer-facing applications.</li> </ul> </li> <li>Platform<ul> <li>Connectivity: This could manage resources related to network connectivity.</li> <li>Identity: This could manage resources related to identity and access management.</li> <li>Management: This could manage resources related to overall platform management.</li> </ul> </li> </ul> </li> </ul> </li> </ol> <p>This structure allows for clear segmentation of resources based on their purpose and lifecycle. For example, decommissioned resources are separated from active ones, and resources within the 'Platform' are further categorized based on their function (Connectivity, Identity, Management). The 'Landing Zones' group appears to separate resources based on their use case or environment (Sandbox, Corp, Online).</p> <p>The exact interpretation would depend on the specific context and conventions of your organization.</p> <h3 id=bad-examples><a class=toclink href=22/management-groups/#bad-examples>Bad Examples</a></h3> <h4 id=example-1-deeply-nested-hierarchy><a class=toclink href=22/management-groups/#example-1-deeply-nested-hierarchy>Example 1: Deeply Nested Hierarchy</a></h4> <pre class=mermaid><code>graph TD
+        E --&gt; K[Management]</code></pre> <ol> <li><strong>Root Management Group</strong><ul> <li>Intermediary-Management-Group<ul> <li>Decommissioned: This could be where resources that are being phased out or decommissioned are managed.</li> <li>Sandboxes: This could be an area where developers can test and experiment without affecting production systems.</li> <li>Landing Zones<ul> <li>Corp: This could represent corporate resources or applications.</li> <li>Online: This could represent online or customer-facing applications.</li> </ul> </li> <li>Platform<ul> <li>Connectivity: This could manage resources related to network connectivity.</li> <li>Identity: This could manage resources related to identity and access management.</li> <li>Management: This could manage resources related to overall platform management.</li> </ul> </li> </ul> </li> </ul> </li> </ol> <p>This structure allows for clear segmentation of resources based on their purpose and lifecycle. For example, decommissioned resources are separated from active ones, like Sandbox, and resources within the 'Platform' are further categorized based on their function (Connectivity, Identity, Management). The 'Landing Zones' group appears to separate resources based on their use case or environment (Corp, Online).</p> <p>The exact interpretation would depend on the specific context and conventions of your organization.</p> <h3 id=bad-examples><a class=toclink href=22/management-groups/#bad-examples>Bad Examples</a></h3> <h4 id=example-1-deeply-nested-hierarchy><a class=toclink href=22/management-groups/#example-1-deeply-nested-hierarchy>Example 1: Deeply Nested Hierarchy</a></h4> <pre class=mermaid><code>graph TD
     A[Root Management Group] --&gt; B[Group 1]
     B --&gt; C[Group 2]
     C --&gt; D[Group 3]
@@ -124,11 +124,7 @@
     A --&gt; D[Group 3]
     A --&gt; E[Group 4]
     A --&gt; F[Group 5]
-    A --&gt; G[Group 6]</code></pre> <p><strong>Why it's bad:</strong> Although this structure is simple, it lacks the ability to group related subscriptions together under a common management group. This makes it harder to apply consistent policies across related subscriptions.</p> <h4 id=example-4-overlapping-hierarchies><a class=toclink href=22/management-groups/#example-4-overlapping-hierarchies>Example 4: Overlapping Hierarchies</a></h4> <pre class=mermaid><code>graph TD
-    A[Root Management Group] --&gt; B[Group 1]
-    A --&gt; C[Group 2]
-    B --&gt; D[Group 3]
-    C --&gt; D</code></pre> <p><strong>Why it's bad:</strong> In this example, <code>Group 3</code> is a subgroup of both <code>Group 1</code> and <code>Group 2</code>. This can create confusion and potential conflicts with policy assignments. It's better to have a clear, non-overlapping hierarchy where each group is a subgroup of only one higher-level group.</p> <h4 id=example-5-environment-based-hierarchy><a class=toclink href=22/management-groups/#example-5-environment-based-hierarchy>Example 5: Environment-Based Hierarchy</a></h4> <pre class=mermaid><code>
+    A --&gt; G[Group 6]</code></pre> <p><strong>Why it's bad:</strong> Although this structure is simple, it lacks the ability to group related subscriptions together under a common management group. This makes it harder to apply consistent policies across related subscriptions.</p> <h4 id=example-4-environment-based-hierarchy><a class=toclink href=22/management-groups/#example-4-environment-based-hierarchy>Example 4: Environment-Based Hierarchy</a></h4> <pre class=mermaid><code>
 graph TD
     A[Root Management Group] --&gt; B[Production Management Group]
     A[Root Management Group] --&gt; C[Development Management Group]

blog/category/azure-services/index.html

@@ -106,7 +106,7 @@
         D --> H[Online]
         E --> I[Connectivity]
         E --> J[Identity]
-        E --&gt; K[Management]</code></pre> <ol> <li><strong>Root Management Group</strong><ul> <li>Intermediary-Management-Group<ul> <li>Decommissioned: This could be where resources that are being phased out or decommissioned are managed.</li> <li>Sandboxes: This could be an area where developers can test and experiment without affecting production systems.</li> <li>Landing Zones<ul> <li>Corp: This could represent corporate resources or applications.</li> <li>Online: This could represent online or customer-facing applications.</li> </ul> </li> <li>Platform<ul> <li>Connectivity: This could manage resources related to network connectivity.</li> <li>Identity: This could manage resources related to identity and access management.</li> <li>Management: This could manage resources related to overall platform management.</li> </ul> </li> </ul> </li> </ul> </li> </ol> <p>This structure allows for clear segmentation of resources based on their purpose and lifecycle. For example, decommissioned resources are separated from active ones, and resources within the 'Platform' are further categorized based on their function (Connectivity, Identity, Management). The 'Landing Zones' group appears to separate resources based on their use case or environment (Sandbox, Corp, Online).</p> <p>The exact interpretation would depend on the specific context and conventions of your organization.</p> <h3 id=bad-examples><a class=toclink href=../../2024/04/22/management-groups/#bad-examples>Bad Examples</a></h3> <h4 id=example-1-deeply-nested-hierarchy><a class=toclink href=../../2024/04/22/management-groups/#example-1-deeply-nested-hierarchy>Example 1: Deeply Nested Hierarchy</a></h4> <pre class=mermaid><code>graph TD
+        E --&gt; K[Management]</code></pre> <ol> <li><strong>Root Management Group</strong><ul> <li>Intermediary-Management-Group<ul> <li>Decommissioned: This could be where resources that are being phased out or decommissioned are managed.</li> <li>Sandboxes: This could be an area where developers can test and experiment without affecting production systems.</li> <li>Landing Zones<ul> <li>Corp: This could represent corporate resources or applications.</li> <li>Online: This could represent online or customer-facing applications.</li> </ul> </li> <li>Platform<ul> <li>Connectivity: This could manage resources related to network connectivity.</li> <li>Identity: This could manage resources related to identity and access management.</li> <li>Management: This could manage resources related to overall platform management.</li> </ul> </li> </ul> </li> </ul> </li> </ol> <p>This structure allows for clear segmentation of resources based on their purpose and lifecycle. For example, decommissioned resources are separated from active ones, like Sandbox, and resources within the 'Platform' are further categorized based on their function (Connectivity, Identity, Management). The 'Landing Zones' group appears to separate resources based on their use case or environment (Corp, Online).</p> <p>The exact interpretation would depend on the specific context and conventions of your organization.</p> <h3 id=bad-examples><a class=toclink href=../../2024/04/22/management-groups/#bad-examples>Bad Examples</a></h3> <h4 id=example-1-deeply-nested-hierarchy><a class=toclink href=../../2024/04/22/management-groups/#example-1-deeply-nested-hierarchy>Example 1: Deeply Nested Hierarchy</a></h4> <pre class=mermaid><code>graph TD
     A[Root Management Group] --&gt; B[Group 1]
     B --&gt; C[Group 2]
     C --&gt; D[Group 3]
@@ -124,11 +124,7 @@
     A --&gt; D[Group 3]
     A --&gt; E[Group 4]
     A --&gt; F[Group 5]
-    A --&gt; G[Group 6]</code></pre> <p><strong>Why it's bad:</strong> Although this structure is simple, it lacks the ability to group related subscriptions together under a common management group. This makes it harder to apply consistent policies across related subscriptions.</p> <h4 id=example-4-overlapping-hierarchies><a class=toclink href=../../2024/04/22/management-groups/#example-4-overlapping-hierarchies>Example 4: Overlapping Hierarchies</a></h4> <pre class=mermaid><code>graph TD
-    A[Root Management Group] --&gt; B[Group 1]
-    A --&gt; C[Group 2]
-    B --&gt; D[Group 3]
-    C --&gt; D</code></pre> <p><strong>Why it's bad:</strong> In this example, <code>Group 3</code> is a subgroup of both <code>Group 1</code> and <code>Group 2</code>. This can create confusion and potential conflicts with policy assignments. It's better to have a clear, non-overlapping hierarchy where each group is a subgroup of only one higher-level group.</p> <h4 id=example-5-environment-based-hierarchy><a class=toclink href=../../2024/04/22/management-groups/#example-5-environment-based-hierarchy>Example 5: Environment-Based Hierarchy</a></h4> <pre class=mermaid><code>
+    A --&gt; G[Group 6]</code></pre> <p><strong>Why it's bad:</strong> Although this structure is simple, it lacks the ability to group related subscriptions together under a common management group. This makes it harder to apply consistent policies across related subscriptions.</p> <h4 id=example-4-environment-based-hierarchy><a class=toclink href=../../2024/04/22/management-groups/#example-4-environment-based-hierarchy>Example 4: Environment-Based Hierarchy</a></h4> <pre class=mermaid><code>
 graph TD
     A[Root Management Group] --&gt; B[Production Management Group]
     A[Root Management Group] --&gt; C[Development Management Group]

blog/index.html

@@ -106,7 +106,7 @@
         D --> H[Online]
         E --> I[Connectivity]
         E --> J[Identity]
-        E --&gt; K[Management]</code></pre> <ol> <li><strong>Root Management Group</strong><ul> <li>Intermediary-Management-Group<ul> <li>Decommissioned: This could be where resources that are being phased out or decommissioned are managed.</li> <li>Sandboxes: This could be an area where developers can test and experiment without affecting production systems.</li> <li>Landing Zones<ul> <li>Corp: This could represent corporate resources or applications.</li> <li>Online: This could represent online or customer-facing applications.</li> </ul> </li> <li>Platform<ul> <li>Connectivity: This could manage resources related to network connectivity.</li> <li>Identity: This could manage resources related to identity and access management.</li> <li>Management: This could manage resources related to overall platform management.</li> </ul> </li> </ul> </li> </ul> </li> </ol> <p>This structure allows for clear segmentation of resources based on their purpose and lifecycle. For example, decommissioned resources are separated from active ones, and resources within the 'Platform' are further categorized based on their function (Connectivity, Identity, Management). The 'Landing Zones' group appears to separate resources based on their use case or environment (Sandbox, Corp, Online).</p> <p>The exact interpretation would depend on the specific context and conventions of your organization.</p> <h3 id=bad-examples><a class=toclink href=2024/04/22/management-groups/#bad-examples>Bad Examples</a></h3> <h4 id=example-1-deeply-nested-hierarchy><a class=toclink href=2024/04/22/management-groups/#example-1-deeply-nested-hierarchy>Example 1: Deeply Nested Hierarchy</a></h4> <pre class=mermaid><code>graph TD
+        E --&gt; K[Management]</code></pre> <ol> <li><strong>Root Management Group</strong><ul> <li>Intermediary-Management-Group<ul> <li>Decommissioned: This could be where resources that are being phased out or decommissioned are managed.</li> <li>Sandboxes: This could be an area where developers can test and experiment without affecting production systems.</li> <li>Landing Zones<ul> <li>Corp: This could represent corporate resources or applications.</li> <li>Online: This could represent online or customer-facing applications.</li> </ul> </li> <li>Platform<ul> <li>Connectivity: This could manage resources related to network connectivity.</li> <li>Identity: This could manage resources related to identity and access management.</li> <li>Management: This could manage resources related to overall platform management.</li> </ul> </li> </ul> </li> </ul> </li> </ol> <p>This structure allows for clear segmentation of resources based on their purpose and lifecycle. For example, decommissioned resources are separated from active ones, like Sandbox, and resources within the 'Platform' are further categorized based on their function (Connectivity, Identity, Management). The 'Landing Zones' group appears to separate resources based on their use case or environment (Corp, Online).</p> <p>The exact interpretation would depend on the specific context and conventions of your organization.</p> <h3 id=bad-examples><a class=toclink href=2024/04/22/management-groups/#bad-examples>Bad Examples</a></h3> <h4 id=example-1-deeply-nested-hierarchy><a class=toclink href=2024/04/22/management-groups/#example-1-deeply-nested-hierarchy>Example 1: Deeply Nested Hierarchy</a></h4> <pre class=mermaid><code>graph TD
     A[Root Management Group] --&gt; B[Group 1]
     B --&gt; C[Group 2]
     C --&gt; D[Group 3]
@@ -124,11 +124,7 @@
     A --&gt; D[Group 3]
     A --&gt; E[Group 4]
     A --&gt; F[Group 5]
-    A --&gt; G[Group 6]</code></pre> <p><strong>Why it's bad:</strong> Although this structure is simple, it lacks the ability to group related subscriptions together under a common management group. This makes it harder to apply consistent policies across related subscriptions.</p> <h4 id=example-4-overlapping-hierarchies><a class=toclink href=2024/04/22/management-groups/#example-4-overlapping-hierarchies>Example 4: Overlapping Hierarchies</a></h4> <pre class=mermaid><code>graph TD
-    A[Root Management Group] --&gt; B[Group 1]
-    A --&gt; C[Group 2]
-    B --&gt; D[Group 3]
-    C --&gt; D</code></pre> <p><strong>Why it's bad:</strong> In this example, <code>Group 3</code> is a subgroup of both <code>Group 1</code> and <code>Group 2</code>. This can create confusion and potential conflicts with policy assignments. It's better to have a clear, non-overlapping hierarchy where each group is a subgroup of only one higher-level group.</p> <h4 id=example-5-environment-based-hierarchy><a class=toclink href=2024/04/22/management-groups/#example-5-environment-based-hierarchy>Example 5: Environment-Based Hierarchy</a></h4> <pre class=mermaid><code>
+    A --&gt; G[Group 6]</code></pre> <p><strong>Why it's bad:</strong> Although this structure is simple, it lacks the ability to group related subscriptions together under a common management group. This makes it harder to apply consistent policies across related subscriptions.</p> <h4 id=example-4-environment-based-hierarchy><a class=toclink href=2024/04/22/management-groups/#example-4-environment-based-hierarchy>Example 4: Environment-Based Hierarchy</a></h4> <pre class=mermaid><code>
 graph TD
     A[Root Management Group] --&gt; B[Production Management Group]
     A[Root Management Group] --&gt; C[Development Management Group]