4.5.1: Chapter 4

Overview

• Chapter: 4 — Cloud Administration vs Traditional IT
• Total Figures Proposed: 8
• Figure Types Used: Comparison Table, Architecture Diagram, Flowchart, Conceptual Illustration, Infographic, Network Diagram

Figure 4.1.1

Title: Traditional IT Administration Stack

Detailed Caption: Six wide rounded-rectangle layers stack vertically, color-graded from a near-black "Physical Hardware (Servers, Storage, Networking)" bar at the bottom up through gray "Virtualization (VMware, Hyper-V)," teal "Operating Systems (Windows Server, Linux)" and "Middleware & Runtime," navy "Applications," to a warm-gold "Data" cap at the top, each prefixed by a small white-line icon (server rack, stacked windows, monitor, target, card, and database cylinder respectively). A tall vertical bracket on the left labeled "Organization's Full Responsibility" spans every layer, while a dashed gray "Increasing Abstraction" arrow runs upward on the right. The figure makes the chapter's opening premise unmistakable: traditional IT has no shared seam — every layer between the silicon and the business data sits inside the same organizational perimeter, and the team that runs the data center owns all six.

Figure 4.2.1

Title: Cloud Administration Tools and Access Flow

Detailed Caption: Three navy access-method boxes line the left side — Web Console with a browser/globe icon, CLI (aws, gcloud, az) with a terminal icon, and IaC (Terraform, CFN) with a code-braces icon — each emitting a navy arrow that converges on a single teal hub at the center labeled "Cloud Provider API (HTTPS / REST)." From that hub, teal arrows fan rightward across a dashed warm-gold cloud boundary into a cluster of mint-bordered resource tiles inside the "Cloud Resources" region: Compute (VMs), Storage (S3/GCS), Database, Networking, and IAM & Security. A gray footer banner spells out the punchline: "All three access methods converge on the same API layer." The visual reframes cloud tooling as one plane with three skins — choosing the console, CLI, or IaC is a choice of interface ergonomics, not of underlying mechanism, which is why audit, automation, and policy can all hook the API rather than each surface.

Figure 4.2.2

Title: Cloud IAM Hierarchy and Policy Model

Detailed Caption: A vertical dashed line splits the figure into two side-by-side IAM models with bold headers — navy "AWS IAM" on the left and teal "GCP IAM" on the right. The AWS half traces a chain from a navy IAM Users box down to a navy IAM Groups box and rightward into a teal IAM Policies tile (with a checkbox glyph) that connects to a teal IAM Roles tile, encoding the user → group → policy → role pattern that ultimately binds permissions to AWS resources. The GCP half flows from a navy "Google / Service Accts" box to a teal IAM Roles tile, which then cascades downward through a navy Organization box to a teal "Folder (optional)" tier, sketching GCP's hierarchical inheritance. By drawing the same conceptual primitives — identities, permissions, resources — wired with two different topologies, the figure shows students that mastering one cloud's IAM doesn't automatically transfer: AWS chains policies through groups and roles, while GCP propagates roles down a resource hierarchy.

Figure 4.3.1

Title: Shared Responsibility Model — Cloud vs Traditional

Detailed Caption: Two parallel eight-layer stacks sit side by side, separated by a vertical gold dividing line and topped with gold headers — "Cloud Model (Shared Responsibility)" on the left and "Traditional On-Premises Model" on the right. The left stack alternates color: the top four layers (Identity & Access Management, Data & Encryption, Application Configuration, Guest OS & Patching) are navy and bracketed as "Customer," while the bottom four (Host OS, Hypervisor, Hardware & Networking, Physical Security) are teal and bracketed as "Provider." The right stack shows the same eight layers but rendered entirely in navy, with one tall right-side bracket labeled "Organization's Full Responsibility," and a footer legend maps the navy/teal swatches to Customer and Provider responsibility. Holding the layers identical and varying only their color isolates the variable that actually changes — who owns each layer — and makes the chapter's central point visually inescapable: moving to cloud doesn't eliminate security work, it redistributes it, and the customer always retains the four upper layers including identity and data.

Figure 4.3.2

Title: Cloud Security Mechanisms Overview

Detailed Caption: A central navy pentagon-shield labeled "Cloud Security" anchors the figure, connected by four warm-gold radial lines to teal-headed quadrant cards arranged in a 2×2 grid. The top-left quadrant, Identity & Access, lists IAM Policies & Roles, MFA Enforcement, Least Privilege, and Key Rotation; the top-right, Network Security, lists Security Groups / Firewalls, VPC Isolation, WAF, and DDoS Protection; the bottom-left, Data Protection, lists Encryption at Rest & Transit, KMS Key Management, Automated Backups, and Cross-Region Replication; and the bottom-right, Monitoring & Audit, lists CloudTrail / Audit Logs, CloudWatch / Monitoring, Anomaly Detection, and Incident Response, each bullet preceded by a small gold dot for scannability. The hub-and-spoke layout reinforces the chapter's organizing claim that cloud security is not a single tool but a portfolio of four disciplines — strong posture in any one quadrant cannot compensate for gaps in another, and the shield only holds if all four spokes are present.

Figure 4.4.1

Title: Shifting Administrative Responsibilities — Traditional to Cloud

Detailed Caption: Two header pills anchor the figure — navy "Traditional IT Admin" on the left and teal "Cloud Admin" on the right — with five horizontal teal arrows running between them that pair before/after responsibilities row by row. Each row carries a bold task title and an italic context gloss: "Hardware Procurement & Setup (Weeks of lead time, physical installation)" → "On-Demand Provisioning & Auto-Scaling (Minutes to deploy, scales automatically)"; "Manual Patching & Maintenance (Scheduled downtime, change windows)" → "Automated Updates & Immutable Infra (Replace, don't patch; rolling deployments)"; "Per-Server Monitoring (Nagios, individual server checks)" → "Centralized Observability & AIOps (CloudWatch, Prometheus, unified dashboards)"; "AD-Based Access Control (Active Directory, LDAP, on-prem)" → "Cloud IAM & Federation (Identity federation, SSO, RBAC, MFA)"; and "Fixed Capital Budgeting (CapEx hardware, 3-5 year cycles)" → "FinOps & Cost Optimization (OpEx pay-per-use, budgets, alerts)." Beneath the rows, a gold "New Cloud-Only Responsibilities" banner introduces three additional gold tiles — Infrastructure as Code, DevOps / CI-CD Pipelines, and Vendor & Service Integration — that have no traditional counterpart. The figure compresses the chapter's role-evolution narrative into one panel: most tasks transform rather than disappear, and a third tier of net-new work lands squarely on the cloud admin's plate.

Figure 4.4.2

Title: Auto-Scaling Workflow in Cloud Environments

Detailed Caption: A teal "Cloud Monitoring Service (CloudWatch / Cloud Monitoring / Azure Monitor)" rounded rectangle sits at the top and feeds a navy decision diamond labeled "CPU > 50% threshold?". The Yes branch fires right to a teal "Auto-Scaling Group: Launch New Instance" box; the No branch drops down to a second navy diamond, "CPU < 25% threshold?", whose Yes branch fires left to a teal "Auto-Scaling Group: Terminate Instance" box, while its No branch lands in a gray "No Action — Continue Monitoring" box. Dashed gold arrows curve from the action and no-action tiles back up to the monitoring service at the top, annotated "Feedback Loop." By drawing the workflow as a closed control loop rather than a linear pipeline, the figure communicates that auto-scaling is not a one-time provisioning decision but a continuous regulator — the same monitoring inputs that triggered an action are immediately re-sampled, so the cluster always tracks toward the configured CPU band.

Figure 4.5.1

Title: Cloud vs Traditional IT — Summary Comparison Matrix

Detailed Caption: A three-column matrix sits beneath a thin gold accent bar, with a warm-gold left column listing six dimension labels (Tools & Interfaces, Access Methods, User Roles, Key Skills, Security Model, Cost Model), a navy "Traditional IT" header column in the middle, and a teal "Cloud Administration" header column on the right; row backgrounds alternate white and pale gray for scannability. Each cell carries a bold headline phrase and an italic gray gloss line — for example, Tools & Interfaces contrasts "OS consoles, RDP, SSH, VMware / Physical/remote access to individual servers" with "Web console, CLI, APIs, IaC (Terraform) / Unified API-driven management"; Security Model contrasts "Perimeter defense, full org responsibility / Castle-and-moat approach" with "Shared responsibility, identity-centric / Zero-trust, policy-as-code"; and Cost Model contrasts "CapEx — fixed hardware investment / 3-5 year depreciation cycles" with "OpEx — pay-per-use, FinOps optimization / Variable cost, continuous optimization." As the chapter's capstone reference, the matrix lets students recover any single contrast at a glance and reinforces that the cloud transition is not one change but a six-front shift in how technology is procured, accessed, staffed, skilled, secured, and paid for.