Deployed c87f255 with MkDocs version: 1.5.3

rfernandezdo · Apr 23, 2024 · 0ab2882 · 0ab2882
1 parent 3c6e2a1
commit 0ab2882
Show file tree

Hide file tree

Showing 21 changed files with 15 additions and 15 deletions.
diff --git a/assets/tables/MCSB/Asset Management.xlsx b/assets/tables/MCSB/Asset Management.xlsx
diff --git a/assets/tables/MCSB/Backup and Recovery.xlsx b/assets/tables/MCSB/Backup and Recovery.xlsx
diff --git a/assets/tables/MCSB/Data Protection.xlsx b/assets/tables/MCSB/Data Protection.xlsx
diff --git a/assets/tables/MCSB/DevOps Security.xlsx b/assets/tables/MCSB/DevOps Security.xlsx
diff --git a/assets/tables/MCSB/Endpoint Security.xlsx b/assets/tables/MCSB/Endpoint Security.xlsx
diff --git a/assets/tables/MCSB/Governance and Strategy.xlsx b/assets/tables/MCSB/Governance and Strategy.xlsx
diff --git a/assets/tables/MCSB/Identity Management.xlsx b/assets/tables/MCSB/Identity Management.xlsx
diff --git a/assets/tables/MCSB/Incident Response.xlsx b/assets/tables/MCSB/Incident Response.xlsx
diff --git a/assets/tables/MCSB/Logging and Threat Detection.xlsx b/assets/tables/MCSB/Logging and Threat Detection.xlsx
diff --git a/assets/tables/MCSB/Network Security.xlsx b/assets/tables/MCSB/Network Security.xlsx
diff --git a/assets/tables/MCSB/Posture and Vulnerability Mgmt.xlsx b/assets/tables/MCSB/Posture and Vulnerability Mgmt.xlsx
diff --git a/assets/tables/MCSB/Privileged Access.xlsx b/assets/tables/MCSB/Privileged Access.xlsx
diff --git a/assets/tables/MCSB/Readme.xlsx b/assets/tables/MCSB/Readme.xlsx
diff --git a/blog/2024/04/22/management-groups/index.html b/blog/2024/04/22/management-groups/index.html
@@ -12,12 +12,12 @@
         B --&gt; C[Decommissioned]
         B --&gt; D[Landing Zones]
         B --&gt; E[Platform]
-        D --&gt; F[Sandboxex]
+        B --&gt; F[Sandboxes]
         D --&gt; G[Corp]
         D --&gt; H[Online]
         E --&gt; I[Connectivity]
         E --&gt; 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>Landing Zones<ul> <li>Sandboxes: This could be an area where developers can test and experiment without affecting production systems.</li> <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> <h2 id=bad-examples>Bad Examples</h2> <h3 id=example-1-deeply-nested-hierarchy>Example 1: Deeply Nested Hierarchy</h3> <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, 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> <h2 id=bad-examples>Bad Examples</h2> <h3 id=example-1-deeply-nested-hierarchy>Example 1: Deeply Nested Hierarchy</h3> <pre class=mermaid><code>graph TD
     A[Root Management Group] --&gt; B[Group 1]
     B --&gt; C[Group 2]
     C --&gt; D[Group 3]
@@ -48,7 +48,7 @@
         B --&gt; C[Decommissioned]
         B --&gt; D[Landing Zones]
         B --&gt; E[Platform]
-        D --&gt; F[Sandboxes]
+        B --&gt; F[Sandboxes]
         D --&gt; G[Corp]
         D --&gt; H[Online]
         E --&gt; I[Connectivity]

diff --git a/blog/2024/04/index.html b/blog/2024/04/index.html
@@ -101,12 +101,12 @@
         B --&gt; C[Decommissioned]
         B --&gt; D[Landing Zones]
         B --&gt; E[Platform]
-        D --&gt; F[Sandboxex]
+        B --&gt; F[Sandboxes]
         D --&gt; G[Corp]
         D --&gt; H[Online]
         E --&gt; I[Connectivity]
         E --&gt; 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>Landing Zones<ul> <li>Sandboxes: This could be an area where developers can test and experiment without affecting production systems.</li> <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, 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
     A[Root Management Group] --&gt; B[Group 1]
     B --&gt; C[Group 2]
     C --&gt; D[Group 3]
@@ -137,7 +137,7 @@
         B --&gt; C[Decommissioned]
         B --&gt; D[Landing Zones]
         B --&gt; E[Platform]
-        D --&gt; F[Sandboxes]
+        B --&gt; F[Sandboxes]
         D --&gt; G[Corp]
         D --&gt; H[Online]
         E --&gt; I[Connectivity]

diff --git a/blog/category/azure-services/index.html b/blog/category/azure-services/index.html
@@ -101,12 +101,12 @@
         B --&gt; C[Decommissioned]
         B --&gt; D[Landing Zones]
         B --&gt; E[Platform]
-        D --&gt; F[Sandboxex]
+        B --&gt; F[Sandboxes]
         D --&gt; G[Corp]
         D --&gt; H[Online]
         E --&gt; I[Connectivity]
         E --&gt; 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>Landing Zones<ul> <li>Sandboxes: This could be an area where developers can test and experiment without affecting production systems.</li> <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, 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
     A[Root Management Group] --&gt; B[Group 1]
     B --&gt; C[Group 2]
     C --&gt; D[Group 3]
@@ -137,7 +137,7 @@
         B --&gt; C[Decommissioned]
         B --&gt; D[Landing Zones]
         B --&gt; E[Platform]
-        D --&gt; F[Sandboxes]
+        B --&gt; F[Sandboxes]
         D --&gt; G[Corp]
         D --&gt; H[Online]
         E --&gt; I[Connectivity]

diff --git a/blog/index.html b/blog/index.html
@@ -101,12 +101,12 @@
         B --&gt; C[Decommissioned]
         B --&gt; D[Landing Zones]
         B --&gt; E[Platform]
-        D --&gt; F[Sandboxex]
+        B --&gt; F[Sandboxes]
         D --&gt; G[Corp]
         D --&gt; H[Online]
         E --&gt; I[Connectivity]
         E --&gt; 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>Landing Zones<ul> <li>Sandboxes: This could be an area where developers can test and experiment without affecting production systems.</li> <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, 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
     A[Root Management Group] --&gt; B[Group 1]
     B --&gt; C[Group 2]
     C --&gt; D[Group 3]
@@ -137,7 +137,7 @@
         B --&gt; C[Decommissioned]
         B --&gt; D[Landing Zones]
         B --&gt; E[Platform]
-        D --&gt; F[Sandboxes]
+        B --&gt; F[Sandboxes]
         D --&gt; G[Corp]
         D --&gt; H[Online]
         E --&gt; I[Connectivity]

diff --git a/feed_rss_created.xml b/feed_rss_created.xml
diff --git a/feed_rss_updated.xml b/feed_rss_updated.xml
diff --git a/search/search_index.json b/search/search_index.json
diff --git a/sitemap.xml.gz b/sitemap.xml.gz