5.3 Provisioning Automation & Image Management

Provisioning Automation & Image Management

Modern cloud infrastructure operations demand rapid, reliable, and secure compute provisioning. When virtual machines or container hosts launch—whether during scheduled scale-outs, disaster recovery events, or automated CI/CD deployments—they must transition from raw storage images into fully functional, hardened production nodes without manual administrative intervention.

For the CompTIA Cloud+ (CV0-004) exam, candidates must master instance bootstrapping mechanisms (such as cloud-init and PowerShell User Data), evaluate the architectural trade-offs of the "Bake vs. Fry" image management paradigm, design automated Golden Image pipelines (using Packer and EC2 Image Builder), manage Launch Templates, and secure the Instance Metadata Service (IMDSv2).

---

1. Instance Bootstrapping Mechanisms

Bootstrapping is the automated process of executing initialization code, injecting configuration parameters, installing runtime dependencies, and joining enterprise directories when a virtual machine boots for the first time.

+-----------------------------------------------------------------------------------------+
|                           INSTANCE BOOTSTRAPPING FLOW                                   |
|                                                                                         |
|   1. Launch Trigger         2. Hypervisor Boot           3. Bootstrapping Engine        |
|   +-----------------+       +--------------------+       +----------------------------+ |
|   | Auto-Scaling    | ====> | Base OS Instantiated| ====> | cloud-init (Linux) /       | |
|   | Launch Template |       | Attaches EBS/VHD   |       | EC2Launch (Windows)        | |
|   +-----------------+       +--------------------+       +--------------+-------------+ |
|                                                                         |               |
|                                                                         v               |
|   4. Production Ready       <===========================================+               |
|   - Queries Instance Metadata (IAM Role STS credentials)                                |
|   - Fetches dynamic secrets from Secrets Manager / Key Vault                            |
|   - Installs packages, configures nginx/app runtime, mounts EFS/NFS                     |
|   - Sends success signal to Auto Scaling Lifecycle Hook                                 |
+-----------------------------------------------------------------------------------------+

Linux Bootstrapping: cloud-init

cloud-init is the industry-standard multi-distribution package used to bootstrap Linux instances across all major public and private clouds (AWS, Azure, GCP, OpenStack, VMware).

• Execution Process: At boot, cloud-init queries the cloud hypervisor metadata service (169.254.169.254), retrieves the User Data payload provided during instance launch, and executes configuration stages (cloud-init-local, cloud-init, cloud-config, and cloud-final).
• Payload Formats: Accepts raw shell scripts (starting with #!/bin/bash), cloud-config YAML directives, or multi-part MIME archives.
• Exam Fact: By default, User Data scripts execute only once during the initial instance boot. Subsequent reboots do not re-run User Data unless explicitly configured with a cloud-config frequency module (scripts-user per-boot).

#cloud-config
# Cloud-init configuration example for production web instance
package_update: true
package_upgrade: true
packages:
  - nginx
  - amazon-cloudwatch-agent
  - jq

write_files:
  - path: /etc/nginx/conf.d/health.conf
    permissions: '0644'
    content: |
      server {
        listen 80;
        location /health {
          return 200 'OK';
        }
      }

runcmd:
  - systemctl enable --now nginx
  - aws secretsmanager get-secret-value --secret-id prod/app/db --region us-east-1 | jq -r .SecretString > /etc/app/config.json
  - systemctl start app-service

Windows Bootstrapping: User Data & EC2Launch

Windows instances bootstrap using cloud-native agent frameworks such as EC2Launch v2 (AWS) or the Azure Custom Script Extension.

• User Data Syntax: Windows User Data must be wrapped in specific XML-like tags:
  • <powershell> ... </powershell>: Executes native PowerShell scripts.
  • <script> ... </script>: Executes legacy batch (.cmd / .bat) commands.
• Sysprep (System Preparation Tool): Windows images must be generalized using sysprep prior to creating an image/template. Sysprep removes system-specific data (such as the computer Security Identifier - SID, hardware GUIDs, and driver state), preventing Active Directory domain join collisions when multiple instances are cloned from the same base image.

---

2. Image Management: "Bake vs. Fry" & The Hybrid Approach

When designing VM provisioning architectures, cloud architects must choose where configuration logic lives along the "Bake vs. Fry" spectrum.

+-----------------------------------------------------------------------------------------+
|                         THE "BAKE VS. FRY" SPECTRUM                                     |
|                                                                                         |
|   BAKED (Thick Golden Image)       HYBRID (Thin Base + Cloud-Init)   FRIED (Just-in-Time)|
|   +--------------------------+     +--------------------------+     +-----------------+ |
|   | - OS + All Security Pkgs |     | - OS + Hardened Baseline |     | - Vanilla Stock | |
|   | - Runtimes & Frameworks  |     | - Security/Log Agents    |     |   Base OS       | |
|   | - Application Binaries   |     | - Common Runtimes        |     |                 | |
|   | - Static Dependencies    |     +--------------------------+     +-----------------+ |
|   +--------------------------+                  |                            |          |
|                |                                v                            v          |
|                v                   [User Data / Configuration Mgmt] [Heavy Dynamic Run] |
|   [Instant Launch < 60s]           - Pulls latest app artifact      - Installs runtimes |
|   - Zero dynamic downloads         - Injects dynamic configs        - Compiles code     |
|   - Heavy image pipeline           - Fast launch (~2-3 mins)        - Boot: 10-15 mins! |
+-----------------------------------------------------------------------------------------+

1. Baked (The "Golden Image" / Thick Image)

In a fully baked approach, a virtual machine image (AMI, Azure Managed Image, Google Compute Image) is pre-built with the operating system, all security patches, enterprise monitoring agents, runtimes, and the compiled application codebase baked into the root volume.

• Advantages: Blazing-fast auto-scaling launch times (<45–60 seconds), deterministic behavior, and zero dependency on external package mirrors (e.g., apt, yum, or npm) during launch.
• Disadvantages: Rigid lifecycle; every code release or OS security patch requires running a complete image build and distributing new images across all regions and accounts.

2. Fried (Just-in-Time Bootstrapping / Thin Image)

In a fully fried approach, instances launch from a generic, unmodified vendor base image (e.g., vanilla Ubuntu or Windows Server). The entire configuration—downloading packages, configuring users, compiling code, and applying OS patches—is performed dynamically at runtime via User Data scripts or Configuration Management tools (Ansible, Chef, Puppet, SaltStack).

• Advantages: Lightweight image catalog; zero upfront image build pipelines.
• Disadvantages: Painfully slow instance launch times (10 to 15+ minutes per node during scale-out events), high failure rates if external repositories experience downtime or updated packages introduce breaking changes.

3. Hybrid Approach (The Enterprise Sweet Spot / Thin AMI)

The enterprise standard balances build velocity and operational stability:

• Bake the Foundation: Pre-bake a standardized Thin Golden Image containing the hardened OS (CIS Benchmark Level 1), security agents (EDR, Vulnerability Scanner), logging daemons (Fluentbit/CloudWatch), and core runtimes (Java/Node/Python).
• Fry the Application: At launch, User Data scripts pull only the latest application binary or Docker container and inject environment-specific configuration parameters.

Comparison Matrix

---

3. Automated Image Factory Pipelines (Packer & EC2 Image Builder)

To eliminate manual image creation, enterprise environments deploy automated Image Factory pipelines.

+-----------------------------------------------------------------------------------------+
|                        AUTOMATED GOLDEN IMAGE FACTORY PIPELINE                          |
|                                                                                         |
|   [1. Source Base]       -> Vanilla Marketplace Image (Ubuntu / RHEL / Windows)         |
|          |                                                                              |
|          v                                                                              |
|   [2. Build & Harden]    -> HashiCorp Packer / EC2 Image Builder / Ansible              |
|          |                  - Apply CIS Benchmark Level 1 Hardening                     |
|          |                  - Install Enterprise Agents (CrowdStrike, Datadog)          |
|          v                                                                              |
|   [3. Security Scan]     -> Vulnerability Assessment (Amazon Inspector / Tenable / CVEs)|
|          |                  - Block pipeline if Critical/High CVEs detected             |
|          v                                                                              |
|   [4. Automated Test]    -> Boot ephemeral test instance & validate HTTP health endpoints|
|          |                                                                              |
|          v                                                                              |
|   [5. Encrypt & Distribute]-> Encrypt AMI with KMS CMK & Replicate to Target Regions    |
+-----------------------------------------------------------------------------------------+

HashiCorp Packer

Packer is an open-source, multi-cloud automated image creation tool that uses declarative HCL templates:

• source blocks: Define the cloud builder plugin and base image parameters (e.g., amazon-ebs, azure-arm, googlecompute).
• build blocks: Specify provisioners (shell scripts, Ansible playbooks, PowerShell) that execute inside an ephemeral build VM to install software.
• post-processors: Handle image artifact tagging, KMS encryption, cross-account sharing, and multi-region replication.

AWS EC2 Image Builder & Azure VM Image Builder

Fully managed cloud-native services that orchestrate image creation pipelines, vulnerability assessments, automated compliance testing, and scheduled image refreshes directly within the provider's management console.

---

4. Auto-Scaling Launch Templates vs. Launch Configurations

When provisioning fleets of compute instances within Auto Scaling Groups (ASGs) or Virtual Machine Scale Sets (VMSS), cloud architects encapsulate instance configuration parameters in a launch blueprint.

+-----------------------------------------------------------------------------------------+
|                   LAUNCH CONFIGURATION (LEGACY) VS. LAUNCH TEMPLATE                     |
|                                                                                         |
|   FEATURE / CAPABILITY              LAUNCH CONFIGURATION      LAUNCH TEMPLATE           |
|   +-------------------------------+-------------------------+-------------------------+ |
|   | Versioning & Git-like History | NOT Supported (Immutable| Native ($Default, $Latest| |
|   | Mixed Instance Types          | NOT Supported           | Supported (On-Demand+Spot| |
|   | Multiple Network Interfaces   | Single ENI only         | Multiple ENIs & Subnets | |
|   | Capacity Reservations & T3    | NOT Supported           | Full Support            | |
|   | IMDSv2 Enforcement Flag       | NOT Supported           | Native Parameter Option | |
|   | Modern Cloud Best Practice    | DEPRECATED              | CURRENT STANDARD        | |
|   +-------------------------------+-------------------------+-------------------------+ |
+-----------------------------------------------------------------------------------------+

Launch Templates: Core Architectural Features

1. Native Versioning: Launch Templates allow creating successive versions (e.g., Version 1 $\rightarrow$ Version 2 with an updated AMI ID). The Auto Scaling Group can point to a fixed version, $Default, or $Latest, enabling seamless rolling updates without modifying the ASG structure.
2. Spot and On-Demand Fleet Diversification: A single Launch Template allows an ASG to blend On-Demand and Spot instances across multiple instance families (e.g., c5.large, c5a.large, c6i.large), maximizing cost savings while protecting against spot capacity termination.
3. Granular Storage & Network Overrides: Supports custom block device mappings, Elastic Fabric Adapter (EFA) attachments for high-performance computing (HPC), and explicit CPU credit options (T2/T3 Unlimited).

---

5. Instance Metadata Service Security: IMDSv1 vs. IMDSv2

The Instance Metadata Service (IMDS) provides running virtual machines with dynamic operational metadata (instance ID, private IP, subnet, public keys) and, crucially, temporary AWS Security Token Service (STS) credentials associated with the instance's attached IAM Instance Profile.

+-----------------------------------------------------------------------------------------+
|                              IMDSv1 VS. IMDSv2 SECURITY FLOW                            |
|                                                                                         |
|   IMDSv1 (Vulnerable to SSRF):                                                          |
|   Attacker exploits Web SSRF ====> HTTP GET http://169.254.169.254/latest/meta-data/iam/|
|                                    Result: Plaintext AWS STS Credentials STOLEN!        |
|                                                                                         |
|   IMDSv2 (Hardened Session Token Handshake):                                            |
|   1. Attacker / App must issue PUT request with TTL Header:                             |
|      TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token"                      |
|             -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"`                           |
|   2. App retrieves metadata using Session Token in Header:                              |
|      curl -H "X-aws-ec2-metadata-token: $TOKEN"                                         |
|           http://169.254.169.254/latest/meta-data/iam/security-credentials/app-role     |
|                                                                                         |
|   * SSRF Defense: Web proxies & WAF bypasses cannot forge custom PUT headers!           |
|   * IP Hop Limit = 1 prevents packet forwarding outside local VM to container breakouts!|
+-----------------------------------------------------------------------------------------+

Why IMDSv1 is a Critical Security Risk

Under IMDSv1, any process on the instance can retrieve sensitive temporary IAM credentials simply by issuing an unauthenticated HTTP GET request to http://169.254.169.254. If a web application running on the instance has a Server-Side Request Forgery (SSRF) vulnerability or misconfigured reverse proxy, an external attacker can trick the web application into fetching metadata credentials and returning them across the internet.

IMDSv2 Hardening Mechanics

IMDSv2 is a session-oriented protocol that eliminates SSRF vulnerabilities through four defensive controls:

1. Two-Step Token Handshake: The client must first issue an HTTP PUT request containing a specific header (X-aws-ec2-metadata-token-ttl-seconds) to generate a temporary, signed session token.
2. Header-Enforced GET Requests: Subsequent metadata requests must include the session token in the X-aws-ec2-metadata-token header. Most standard SSRF attacks and open reverse proxies cannot construct arbitrary PUT requests with custom headers.
3. Network Hop Limit Restriction: Administrators can configure the HTTP Put Response Hop Limit to 1. This ensures that packets generated by the metadata service have a Time-To-Live (TTL) of 1, meaning they cannot traverse network bridges or layer-3 routers (blocking container breakout attacks from reaching host metadata).
4. Enforcing IMDSv2 via IaC: Launch Templates should explicitly require IMDSv2 by setting HttpTokens = required and disabling IMDSv1 platform-wide via Service Control Policies (SCPs).

---

6. CompTIA Cloud+ Exam Traps & Troubleshooting

• Cloud-Init Execution Failure: If a newly launched Linux instance fails to respond to health checks, inspect /var/log/cloud-init.log and /var/log/cloud-init-output.log for script syntax errors or failed package downloads.
• Windows Clone SID Duplication: If multiple Windows VMs deployed from a template fail to join an Active Directory domain or experience authentication collisions, the base image was captured without running sysprep.exe /generalize /oobe /shutdown.
• Auto-Scaling Premature Termination: If an ASG launches instances but immediately terminates them after 5 minutes, check the Health Check Grace Period. If the instance requires 4 minutes to bootstrap and the grace period is set to 2 minutes, the load balancer marks the instance unhealthy and the ASG terminates it in a continuous crash loop.