ICCA Exam - Guided By RedBlock

ICCA Field Guide — INE Certified Cloud Associate

A complete, concept-first study guide for the INE Certified Cloud Associate (ICCA) — an entry-level, vendor-neutral certification validating foundational fluency in cloud technologies across AWS, Azure, and Google Cloud, plus cloud identity, security, compliance, management, and strategic adoption. Organized to the five exam domains, with provider comparisons, plain-language explanations, and a hands-on AWS lab.

What ICCA is: a cloud fluency certification, not a deep platform-engineering exam. It validates that you understand core cloud concepts, recognize how they apply across the major public clouds, and can participate in cloud conversations — planning, support, sales, marketing, management, and technical. The emphasis is breadth and understanding over hands-on specialization. Who it's for: IT professionals, managers/officers/support staff, anyone supporting cloud adoption, and technical and non-technical team members who need foundational cloud literacy.

Table of Contents

1. ICCA Overview & Exam Strategy

2. What Is Cloud Computing?

3. Cloud Service Models (IaaS, PaaS, SaaS)

4. Cloud Deployment Models (Public, Private, Hybrid, Multi-cloud)

5. Business Drivers & Cloud Economics

6. The Public Cloud Providers (AWS, Azure, GCP)

7. Global Cloud Infrastructure (Regions, AZs, Edge)

8. Core Service Categories & Cross-Provider Equivalents

9. Compute Services

10. Storage Services

11. Networking Services

12. Database Services

13. Data, Analytics & AI/ML Services

14. Cloud Identity (IAM, AuthN, AuthZ, SSO, MFA)

15. Cloud Security & the Shared Responsibility Model

16. Cloud Compliance & Governance

17. Cloud Management & Operations

18. Disaster Recovery & Business Continuity

19. Cost Management & FinOps Basics

20. Automation & Infrastructure as Code

21. Cloud-Native: Microservices, Containers & DevOps

22. The Well-Architected Framework & Design Principles

23. Strategic Cloud Participation & Adoption

24. Cloud Migration Concepts

25. Hands-On Lab — Provisioning AWS Resources (EC2 + S3)

26. Hands-On Lab — Provisioning Azure Resources (VM + Blob Storage)

27. Hands-On Lab — Provisioning Google Cloud Resources (VM + Cloud Storage)

28. Practice Scenarios & Sample Questions

29. Monitoring, Observability & Cloud Operations Detail

30. Cloud Security Services & Threat Awareness

31. Exam-Day Tips & Study Plan

32. Glossary & Quick Reference

1. ICCA Overview & Exam Strategy

The five domains:

Strategy that scores:

• Learn concepts, not button-clicks. ICCA tests whether you understand what a load balancer, IAM role, or region is — and how the idea shows up across AWS/Azure/GCP — not the exact menu path.

• Think across providers. Know the common service in each cloud (e.g., "VM" = EC2 / Azure VM / Compute Engine). The exam rewards recognizing the same concept under different vendor names (§8).

• Understand the shared responsibility model (§14) — it underpins most security/compliance questions.

• Business + technical fluency. ICCA deliberately spans non-technical roles: know CapEx vs OpEx, elasticity benefits, and why organizations adopt cloud — not just the tech.

• A little hands-on helps. Provisioning one VM and one storage bucket (the lab in §21) makes the abstract concrete.

2. What Is Cloud Computing?

Definition. Cloud computing is the on-demand delivery of IT resources — compute, storage, networking, databases, and higher-level services — over the internet, with pay-as-you-go pricing. Instead of buying and running your own data center, you rent resources from a provider and consume them as a service.

The five essential characteristics (NIST model — commonly referenced):

1. On-demand self-service — provision resources yourself, instantly, without human interaction from the provider.

2. Broad network access — available over the network from anywhere, on many devices.

3. Resource pooling — the provider pools resources and serves many customers (multi-tenancy), dynamically assigned.

4. Rapid elasticity — scale up/out and down/in quickly to match demand; it can feel "unlimited."

5. Measured service — usage is metered; you pay only for what you consume.

Why it matters. These characteristics are why cloud changes IT: no up-front hardware, near-instant provisioning, automatic scaling, and costs that track usage. Traditional on-premises IT means buying capacity for peak demand (and paying for idle capacity the rest of the time); cloud lets you match capacity to actual need.

Cloud vs traditional on-premises:

On-prem:  you own/run the data center, hardware, cooling, power, patching, scaling (CapEx + ops burden)
Cloud:    the provider runs the infrastructure; you consume services on demand (OpEx + agility)

3. Cloud Service Models (IaaS, PaaS, SaaS)

The service models describe how much the provider manages vs. how much you manage — the "as-a-service" stack.

IaaS — Infrastructure as a Service. The provider gives you the raw building blocks — virtual machines, storage, networks — and you manage the OS, runtime, and applications on top. Maximum control and flexibility; most management responsibility.

• Examples: AWS EC2, Azure Virtual Machines, Google Compute Engine; cloud storage and virtual networks.

• Analogy: renting the land and a bare building — you fit it out and run it.

PaaS — Platform as a Service. The provider manages the infrastructure and the platform (OS, runtime, middleware); you just deploy your code/data. Faster development, less operational overhead, less control.

• Examples: AWS Elastic Beanstalk / App Runner, Azure App Service, Google App Engine; managed databases are PaaS-like.

• Analogy: renting a fully serviced office — you bring your work; the building ops are handled.

SaaS — Software as a Service. The provider delivers a complete application over the internet; you just use it. Least management, least control.

• Examples: Microsoft 365, Google Workspace, Salesforce, Dropbox, Zoom.

• Analogy: a hotel room — everything's provided; you just stay.

The responsibility gradient (remember this):

                You manage  →→→→→→→→→→→→→→→→→→→  Provider manages
On-premises  | apps | data | runtime | OS | virtualization | servers | storage | network |  (you manage all)
IaaS         | apps | data | runtime | OS |  ———— provider manages below ————                |
PaaS         | apps | data |  ———— provider manages runtime/OS/infra ————                     |
SaaS         |  ———— provider manages everything; you configure & use ————                   |

Also seen: FaaS/Serverless (e.g., AWS Lambda, Azure Functions, Google Cloud Functions) — you provide just the function code; the provider runs it on demand, scaling to zero. A more granular form of PaaS.

4. Cloud Deployment Models (Public, Private, Hybrid, Multi-cloud)

Deployment models describe where the cloud runs and who can use it.

• Public cloud — resources owned and operated by a third-party provider (AWS/Azure/GCP), shared across many customers over the internet. Lowest cost, highest elasticity, no hardware to manage. The ICCA focus.

• Private cloud — cloud infrastructure dedicated to a single organization (on-prem or hosted). More control and isolation, often for compliance/sensitive workloads; higher cost, less elasticity.

• Hybrid cloud — a combination of public and private (and/or on-prem), connected so workloads and data can move between them. Lets organizations keep sensitive workloads private while bursting to public cloud for scale.

• Multi-cloud — using more than one public cloud provider (e.g., AWS + Azure) to avoid vendor lock-in, use best-of-breed services, or meet resilience/regulatory needs.

• Community cloud — shared by several organizations with common concerns (e.g., a sector/regulatory group).

Choosing a model (the trade-offs): public = agility & cost; private = control & isolation; hybrid = balance & gradual migration; multi-cloud = flexibility & resilience (at the cost of complexity).

5. Business Drivers & Cloud Economics

ICCA explicitly tests why organizations adopt cloud — the business case, not just the tech.

CapEx vs OpEx. Traditional IT is capital expenditure — big up-front purchases of hardware you depreciate over years. Cloud shifts spending to operational expenditure — ongoing, usage-based costs with no up-front hardware. This frees capital, reduces risk, and aligns cost with actual use.

Core business benefits:

• Agility / speed — provision in minutes, not weeks; experiment cheaply; faster time to market.

• Elasticity & scalability — scale with demand automatically; handle spikes without over-provisioning. (Scalability = ability to grow; elasticity = automatically growing and shrinking with demand.)

• Cost efficiency — pay only for what you use; economies of scale; stop paying for idle capacity.

• Global reach — deploy close to users worldwide in minutes.

• Reliability & resilience — redundancy, backups, and multi-location designs improve uptime and disaster recovery.

• Focus on core business — offload undifferentiated heavy lifting (racking servers, patching) to the provider.

• Security & compliance at scale — providers invest heavily in security and certifications most organizations couldn't match alone.

Key economic concepts:

• Total Cost of Ownership (TCO) — the full cost of a solution including hidden operational costs; cloud TCO comparisons weigh on-prem CapEx+ops vs cloud OpEx.

• Economies of scale — providers serve millions of customers, driving per-unit costs down and passing some savings on.

• Pay-as-you-go / consumption pricing — the default model; also reserved/committed-use discounts and spot/preemptible pricing for cheaper, interruptible capacity.

6. The Public Cloud Providers (AWS, Azure, GCP)

The "big three" public clouds. ICCA wants you fluent in all three at a conceptual level.

• Amazon Web Services (AWS) — the largest and earliest major provider (2006). The broadest service catalog; strong market share; often the reference point for cloud concepts. Console + CLI + SDKs; account-based structure, organized with AWS Organizations.

• Microsoft Azure — Microsoft's cloud; deep integration with Microsoft enterprise products (Windows Server, Active Directory, Microsoft 365). Strong in hybrid (Azure Arc/Stack) and enterprise. Organized with Management Groups → Subscriptions → Resource Groups.

• Google Cloud Platform (GCP) — Google's cloud; strengths in data analytics, AI/ML, and Kubernetes (Google created Kubernetes). Organized with Organization → Folders → Projects.

Shared patterns across all three: a global network of data centers (regions/zones), a web console + CLI + SDK/API, an identity & access management system, compute / storage / networking / database building blocks, monitoring & billing, and a shared responsibility model for security. Learn the pattern once and map the names (§8).

7. Global Cloud Infrastructure (Regions, AZs, Edge)

Providers run physical infrastructure worldwide, organized in a hierarchy you must understand.

• Region — a geographic area containing multiple isolated data-center groups (e.g., "US East (N. Virginia)", "West Europe"). You choose a region for latency (close to users), compliance/data residency (keep data in a country), cost (prices vary by region), and service availability (not all services are in every region).

• Availability Zone (AZ) — one or more discrete data centers within a region, with independent power/cooling/networking. Deploying across multiple AZs gives high availability — if one AZ fails, your workload survives in another. (AWS/Azure call these Availability Zones; GCP calls them zones.)

• Edge locations / Points of Presence (PoPs) — many small sites near end users used by content delivery networks (CDNs) and DNS to cache content and reduce latency (AWS CloudFront, Azure CDN/Front Door, Google Cloud CDN).

The design principle: regions for geography/compliance, multiple AZs for high availability within a region, multiple regions for disaster recovery and global reach, edge for fast content delivery. Fault isolation is built in — distribute workloads so no single failure takes everything down.

8. Core Service Categories & Cross-Provider Equivalents

Every cloud offers the same categories under different names. This table is one of the highest-value things to memorize for ICCA.

Takeaway: the concept is identical across providers; only the brand name changes. If you know "object storage" and that it's S3 / Blob / Cloud Storage, you can answer the question in any provider's terms.

9. Compute Services

Compute = the processing power that runs your applications. The main forms:

• Virtual machines (IaaS) — rentable virtual servers you fully control (OS, software). Pick an image (OS template — AMI on AWS), an instance type/size (CPU/RAM, e.g., AWS t2.micro), storage, and networking. Pay per time running (and often a free tier for small sizes). Use when you need full control or are migrating existing servers.

• Containers — package an app with its dependencies to run consistently anywhere; orchestrated at scale with Kubernetes (managed as EKS/AKS/GKE) or simpler services (AWS ECS/Fargate). Lighter and faster than VMs; great for microservices.

• Serverless / Functions as a Service — you deploy just code that runs in response to events; the provider handles all servers and scales automatically (even to zero). Pay per execution. Use for event-driven, bursty, or glue workloads (Lambda / Azure Functions / Cloud Functions).

• PaaS app platforms — deploy an app and let the platform manage the servers/runtime (Elastic Beanstalk, App Service, App Engine).

Choosing: VMs = max control; containers = portability + density; serverless = minimal ops + automatic scaling; PaaS = fast app deployment. Scaling: vertical scaling (bigger machine) vs horizontal scaling (more machines) — cloud favors horizontal, often via auto-scaling behind a load balancer.

10. Storage Services

Cloud storage comes in three fundamental types — know the difference and the use case:

• Object storage — stores files as "objects" in flat "buckets," accessed via API/URL, virtually unlimited and cheap, with durability built in. Ideal for backups, media, static websites, data lakes, logs. AWS S3 / Azure Blob / Google Cloud Storage. Storage classes/tiers trade cost for access speed (e.g., hot/standard for frequent access, cool/cold/archive for rarely accessed data).

• Block storage — raw disk volumes attached to a VM (like a hard drive), formatted with a filesystem; low-latency, high-performance, for OS disks and databases. AWS EBS / Azure Managed Disks / Google Persistent Disk.

• File storage — a shared network file system (NFS/SMB) multiple machines can mount simultaneously. AWS EFS / Azure Files / Google Filestore.

Key storage concepts:

• Durability — how safe data is from loss (object storage is often "11 nines" durable via automatic replication across devices/AZs).

• Availability — how reliably you can access it.

• Lifecycle policies — automatically move data to cheaper tiers or delete it over time.

• Encryption — data at rest (stored) and in transit (moving) should be encrypted; providers make this easy/default.

• Access control — object stores default to private; public exposure is a common misconfiguration (keep buckets private unless intentionally public).

11. Networking Services

Cloud networking connects your resources securely and to the internet.

• Virtual network — your private, isolated network in the cloud (VPC in AWS/GCP, VNet in Azure). You carve it into subnets (public subnets reach the internet; private subnets don't).

• IP addressing — private IPs for internal traffic; public/elastic IPs for internet-facing resources.

• Gateways — an internet gateway lets a network reach the internet; a NAT gateway lets private resources make outbound connections without being publicly reachable.

• Firewalls / security rules — security groups (instance-level, stateful) and network ACLs (subnet-level) control allowed traffic by port/protocol/source. Default-deny inbound is the safe posture.

• Load balancer — distributes incoming traffic across multiple instances for scalability and high availability (and health-checks them).

• DNS — maps domain names to resources (Route 53 / Azure DNS / Cloud DNS).

• CDN — caches content at edge locations near users for speed (§7).

• Hybrid connectivity — VPN (encrypted over the internet) or dedicated private links (AWS Direct Connect / Azure ExpressRoute / Google Cloud Interconnect) connect on-prem to cloud.

The mental model: a VPC is your private data center in the cloud — subnets, routing, gateways, and firewalls — that you configure to control exactly what can talk to what.

12. Database Services

Managed databases are a core PaaS offering — the provider handles patching, backups, replication, and scaling.

• Relational (SQL) — structured data with schemas and relationships, queried with SQL; strong consistency, transactions. Managed: AWS RDS, Azure SQL Database, Google Cloud SQL (engines like MySQL, PostgreSQL, SQL Server, Oracle). Use for traditional apps, finance, anything needing joins/transactions.

• NoSQL (non-relational) — flexible schemas, built for scale and speed: key-value, document, column, graph. Managed: DynamoDB, Cosmos DB, Firestore/Bigtable. Use for high-scale, flexible, or high-velocity data.

• Data warehouse — optimized for analytics over huge datasets: Redshift, Synapse, BigQuery. Use for business intelligence and reporting.

• In-memory cache — ultra-fast ephemeral data (Redis/Memcached — ElastiCache / Azure Cache / Memorystore).

Managed vs self-managed: you can run a database on a VM (IaaS — full control, full ops burden), but managed database services (PaaS) offload backups, patching, high-availability failover, and scaling — the usual cloud choice. Key concepts: backups & point-in-time restore, read replicas (scale reads), multi-AZ replication (high availability), and encryption at rest/in transit.

13. Data, Analytics & AI/ML Services

Beyond databases, cloud providers offer a rich stack for storing, processing, and extracting value from data — a major reason organizations adopt cloud.

The data pipeline (concept): ingest → store → process/transform → analyze → visualize → act. Cloud has a managed service for each stage.

Analytics & big-data services:

• Data lake — a central repository that stores raw structured and unstructured data at any scale, usually on object storage (S3 / Blob / Cloud Storage). Cheap, flexible; you apply structure when you read ("schema-on-read").

• Data warehouse — optimized for fast analytical queries over large, structured datasets for business intelligence: AWS Redshift, Azure Synapse Analytics, Google BigQuery.

• Serverless query / interactive analytics — run SQL directly over data in object storage without managing servers: AWS Athena (used in the lab), Azure Synapse serverless, BigQuery.

• Big-data processing — large-scale distributed processing (Spark/Hadoop): AWS EMR, Azure HDInsight / Databricks, Google Dataproc.

• Streaming / real-time — ingest and process continuous event streams: AWS Kinesis, Azure Event Hubs, Google Pub/Sub.

• ETL / data integration — extract-transform-load pipelines: AWS Glue, Azure Data Factory, Google Dataflow.

• Business intelligence / visualization — dashboards and reports: AWS QuickSight, Microsoft Power BI, Google Looker.

AI / Machine Learning services (increasingly central; a GCP strength):

• Pre-built AI APIs — ready-to-use models for vision, speech, language, translation (no ML expertise needed): AWS (Rekognition, Comprehend, Polly, Transcribe), Azure (Cognitive Services / AI Services), Google (Vision/Speech/Natural Language AI).

• ML platforms — build/train/deploy custom models: AWS SageMaker, Azure Machine Learning, Google Vertex AI.

• Generative AI — foundation-model services: AWS Bedrock, Azure OpenAI Service, Google Vertex AI / Gemini.

Why ICCA cares: you should recognize that cloud turns expensive, specialized data/AI capabilities into on-demand managed services — lowering the barrier so any organization can do analytics and AI. Know the categories and a flagship name per provider (BigQuery, Redshift, Synapse; SageMaker, Vertex AI, Azure ML), and the data-lake-vs-warehouse distinction.

14. Cloud Identity (IAM, AuthN, AuthZ, SSO, MFA)

Identity is the foundation of cloud security — "who can do what." Identity and Access Management (IAM) controls access to cloud resources.

Core concepts:

• Authentication (AuthN) — proving who you are (username/password, keys, certificates).

• Authorization (AuthZ) — what you're allowed to do once authenticated (permissions/policies).

• Identities / principals — users (people), groups (collections of users), roles (an identity assumed temporarily, often by services or for cross-account access), and service accounts / service principals (non-human identities for applications).

• Policies / permissions — rules that grant or deny actions on resources. Written per provider (AWS JSON policies, Azure RBAC role assignments, GCP IAM bindings).

• Least privilege — grant only the minimum permissions needed; the cornerstone principle.

Key mechanisms:

• Multi-Factor Authentication (MFA) — require a second factor (app code, token, biometric) beyond a password; dramatically reduces account takeover. Always enable for privileged/root accounts.

• Single Sign-On (SSO) — one login grants access to many applications/services.

• Role-Based Access Control (RBAC) — assign permissions by role (job function) rather than per user — scalable and auditable. Azure RBAC and GCP IAM roles are RBAC; AWS uses policies + roles.

• Federation — trust an external identity provider (e.g., your corporate directory / Entra ID) so users sign in with existing credentials; underpins SSO across organizations and clouds.

• Root / global-admin account — the all-powerful account; protect it heavily (MFA, don't use day-to-day, create limited admin users instead).

Provider IAM: AWS IAM, Microsoft Entra ID (identity) + Azure RBAC (resource permissions), Google Cloud IAM. Same idea everywhere: authenticate principals, authorize actions via policies/roles, enforce least privilege, add MFA.

15. Cloud Security & the Shared Responsibility Model

The single most important security concept in cloud — and a guaranteed exam topic.

Shared Responsibility Model. Security is split between the provider and the customer:

PROVIDER is responsible for  "security OF the cloud"
   - physical data centers, hardware, the global network
   - the virtualization layer and managed-service internals
CUSTOMER is responsible for  "security IN the cloud"
   - your data (classification, encryption choices)
   - identity & access (IAM, MFA, least privilege)
   - OS/app patching (for IaaS), network/firewall configuration
   - correct configuration of the services you use

The split shifts with the service model: with IaaS you manage more (OS, patching, network config); with PaaS the provider manages the platform so you manage less; with SaaS the provider manages almost everything and you mainly manage data and access. You are always responsible for your data and who can access it.

Core security concepts:

• Encryption — protect data at rest (stored) and in transit (moving) with encryption; providers make it easy/default and manage keys (with customer-managed-key options).

• Network security — firewalls/security groups, private subnets, least-exposure design (don't make things public unless needed).

• Defense in depth — layered controls (identity + network + encryption + monitoring) so one failure isn't catastrophic.

• Logging & monitoring — audit trails (who did what) and alerts; essential for detection and compliance.

• Common misconfigurations — public storage buckets, over-permissive IAM, no MFA, unencrypted data, open security groups — most cloud incidents are customer-side misconfiguration, not provider failure.

Provider security services (awareness): AWS (IAM, KMS, GuardDuty, Security Hub, Shield/WAF), Azure (Entra ID, Key Vault, Defender for Cloud, Sentinel), GCP (Cloud IAM, KMS, Security Command Center). They help you fulfill your half of the responsibility.

16. Cloud Compliance & Governance

Compliance = meeting external legal/regulatory/industry requirements. Governance = your internal policies and controls to manage cloud use.

Compliance concepts:

• Frameworks & certifications — providers hold certifications and offer compliant services for standards like ISO 27001, SOC 1/2/3, PCI DSS (payment cards), HIPAA (US health), GDPR (EU privacy), FedRAMP (US government). The provider's certification covers their layer; you must configure your workloads to remain compliant (shared responsibility again).

• Data residency / sovereignty — laws requiring data to stay in a certain country/region; you choose regions (§7) to comply.

• Data classification — label data by sensitivity (public/internal/confidential/regulated) to apply the right controls.

• Audit & evidence — providers publish compliance reports (e.g., AWS Artifact, Azure Service Trust, Google compliance reports) you use to demonstrate compliance.

Governance concepts:

• Policies & guardrails — rules enforced across accounts (e.g., "no public buckets," "only approved regions") via tools like AWS Organizations SCPs, Azure Policy, GCP Organization Policies.

• Resource organization — accounts/subscriptions/projects, folders, and tags/labels to organize, track ownership, and allocate cost.

• Cost governance — budgets, alerts, and spending limits (§17).

• Risk management — identify, assess, and mitigate cloud risks (security, availability, cost, vendor lock-in).

The foundational message: compliance and governance are shared and continuous — the provider gives you compliant building blocks and tools; your organization must configure, monitor, and document to actually meet obligations.

17. Cloud Management & Operations

How cloud resources are organized, monitored, supported, and governed day to day.

Resource organization:

• Account/project hierarchy — AWS Organizations → accounts; Azure Management Groups → Subscriptions → Resource Groups; GCP Organization → Folders → Projects. Used to separate environments (dev/test/prod), teams, and billing.

• Tags / labels — metadata key-value pairs on resources (owner, environment, cost-center) for organization, automation, and cost allocation.

Monitoring & observability:

• Metrics — numeric performance data (CPU, memory, requests) via CloudWatch / Azure Monitor / Cloud Monitoring.

• Logs — records of events/activity for troubleshooting and audit.

• Alarms/alerts — notify or auto-respond when thresholds are crossed.

• Dashboards — visualize health and performance.

• The goal: know the state of your environment, detect problems early, and prove performance/compliance.

Operations:

• Backups & disaster recovery (DR) — regular backups, cross-region copies, and recovery plans measured by RTO (recovery time objective — how fast you recover) and RPO (recovery point objective — how much data you can afford to lose).

• High availability — redundancy across AZs/regions, load balancing, auto-scaling, health checks.

• Patching & maintenance — your responsibility for IaaS; the provider's for PaaS/SaaS.

• Support plans — providers offer tiered support (basic → enterprise) with varying response times.

• Automation — reduce manual effort and error (§18).

Operational mindset: cloud shifts ops from "rack and maintain hardware" to "organize, monitor, automate, and govern services" — spanning both technical and business teams.

18. Disaster Recovery & Business Continuity

Cloud makes resilience far more achievable than traditional IT — a key business driver — but you must design for it.

Key terms (memorize):

• High Availability (HA) — the system keeps running despite component failures (redundancy, multiple AZs, load balancing, health checks). Measured as uptime (e.g., "99.99%").

• Disaster Recovery (DR) — restoring service after a major failure/disaster (region outage, data loss, cyber event).

• Business Continuity — the broader plan to keep the business operating through disruption (people, process, and technology).

• RTO (Recovery Time Objective) — how quickly you must recover (max acceptable downtime).

• RPO (Recovery Point Objective) — how much data you can afford to lose (max acceptable data-loss window; drives backup frequency).

DR strategies (increasing cost, decreasing RTO/RPO):

1. Backup & Restore — back up data (and configs) to another region; restore when needed. Cheapest; slowest recovery (hours). Highest RTO/RPO.

2. Pilot Light — a minimal core (e.g., replicated database) always running in a second region; scale up the rest on disaster. Lower RTO.

3. Warm Standby — a scaled-down but functional copy running in a second region; scale it up to take over. Faster recovery.

4. Multi-Site / Active-Active (Hot) — full production running in multiple regions simultaneously; near-zero RTO/RPO. Most expensive.

Building blocks the cloud gives you: multi-AZ deployments (HA within a region), multi-region replication (DR across geographies), automated backups and snapshots, cross-region storage replication, DNS failover, and auto-scaling to recover capacity. Design principle: match the strategy (and cost) to the business criticality of each workload — not everything needs active-active. Test your DR plan — an untested recovery plan is a hope, not a plan.

19. Cost Management & FinOps Basics

Because cloud is pay-as-you-go, cost management is an ongoing discipline (often called FinOps — cloud financial operations).

Pricing models:

• On-demand / pay-as-you-go — pay per use, no commitment; most flexible, highest unit price.

• Reserved / committed-use — commit to usage (1–3 years) for a big discount; best for steady workloads (AWS Reserved Instances/Savings Plans, Azure Reservations, GCP Committed Use Discounts).

• Spot / preemptible — deeply discounted spare capacity that can be reclaimed anytime; for fault-tolerant, interruptible work.

• Free tier — limited free usage to learn/experiment (e.g., t2.micro in the lab, §21).

Managing spend:

• Budgets & alerts — set spending limits and get notified before overruns.

• Cost allocation via tags — attribute spend to teams/projects/environments.

• Right-sizing — match resource size to actual need; eliminate oversized/idle resources.

• Shut down what you don't use — stop/terminate idle VMs, delete orphaned storage/disks.

• Cost tools — AWS Cost Explorer/Budgets, Azure Cost Management, GCP Cloud Billing reports.

Key idea: cloud cost is variable and visible — a benefit (pay for what you use) and a risk (easy to overspend). Governance + monitoring + right-sizing keep it under control. Understand TCO (§5) when comparing cloud vs on-prem.

20. Automation & Infrastructure as Code

Automation is central to operating cloud efficiently and consistently.

• Infrastructure as Code (IaC) — define infrastructure in text/config files and provision it automatically, repeatably, and version-controlled. Benefits: consistency, speed, no manual drift, easy replication across environments. Tools: AWS CloudFormation, Azure ARM/Bicep, Google Deployment Manager, and the cross-cloud Terraform.

• Templates / blueprints — reusable definitions of a standard environment.

• CLI & SDKs — script actions programmatically (aws, az, gcloud CLIs; language SDKs) instead of clicking the console.

• Auto-scaling — automatically add/remove capacity based on demand (matches cost to need, maintains performance).

• CI/CD — automated pipelines that build, test, and deploy applications.

• Serverless automation — event-driven functions that react to changes automatically.

Why it matters for ICCA: automation is how cloud delivers speed, consistency, and scale. You don't need to write IaC for the exam, but you should understand that infrastructure can be codified, versioned, and deployed automatically — a core cloud advantage over manual, click-by-click operations.

21. Cloud-Native: Microservices, Containers & DevOps

"Cloud-native" means building applications designed for the cloud — to be scalable, resilient, and rapidly deployable — rather than just moving old apps unchanged.

Core cloud-native concepts:

• Microservices — break an application into small, independent services that each do one thing and communicate over APIs. Benefits: independent deployment/scaling, fault isolation, team autonomy. Contrast with a monolith (one large, tightly-coupled app). Trade-off: more operational complexity.

• Containers — package an app with everything it needs to run consistently across environments (dev → prod). Lighter and faster-starting than VMs; the standard unit for microservices. Docker is the common format.

• Container orchestration — managing containers at scale (scheduling, scaling, healing, networking): Kubernetes (the de-facto standard, created by Google), offered managed as EKS / AKS / GKE; simpler options include AWS ECS/Fargate.

• Serverless — the most cloud-native compute: no servers to manage, scales automatically to zero, pay per use (§9).

• API-first / loosely coupled — services interact through well-defined APIs and messaging/queues, so components can evolve independently.

DevOps & delivery:

• DevOps — a culture/practice uniting development and operations to deliver software faster and more reliably through automation and collaboration.

• CI/CD (Continuous Integration / Continuous Delivery) — automated pipelines that build, test, and deploy code continuously, reducing manual error and speeding releases.

• Infrastructure as Code — provision the environment automatically and repeatably (§20).

• Observability — metrics, logs, and traces to understand and operate distributed systems.

Why it matters for ICCA: recognize why organizations modernize — cloud-native designs deliver the agility, scalability, and resilience that are cloud's core promise. You don't need to build microservices for the exam, but understand the terms (microservice vs monolith, container vs VM, Kubernetes, DevOps, CI/CD) and that they're how modern cloud software is built and shipped.

22. The Well-Architected Framework & Design Principles

Each major provider publishes a Well-Architected Framework (AWS Well-Architected, Azure Well-Architected, Google Cloud Architecture Framework) — best-practice guidance organized into pillars. The pillars are nearly identical across providers and are great exam material.

The pillars:

1. Operational Excellence — run and monitor systems to deliver business value; automate, respond to events, improve continuously.

2. Security — protect data, systems, and assets: identity/least-privilege, encryption, defense in depth, traceability (the shared-responsibility concepts, §14).

3. Reliability — recover from failures and meet demand: redundancy across AZs/regions, backups, auto-healing, DR (§18).

4. Performance Efficiency — use resources efficiently and scale to demand: right-size, use the right service, adopt new technologies.

5. Cost Optimization — avoid unnecessary cost: pay-as-you-go, right-sizing, reserved/spot pricing, eliminate idle resources (§17, §19).

6. Sustainability (newer pillar) — minimize environmental impact of cloud workloads (efficient resource use, managed services, right-sizing). (Azure adds "Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization" as its five pillars — the same ideas.)

Foundational design principles (common across frameworks):

• Design for failure — assume components will fail; build redundancy and automated recovery.

• Decouple components — loose coupling (queues, APIs, load balancers) so one failure doesn't cascade.

• Scale horizontally — add more instances rather than bigger ones; pair with auto-scaling.

• Automate everything — IaC, auto-scaling, CI/CD, automated recovery reduce error and toil.

• Least privilege & defense in depth — minimal permissions, layered security.

• Pay for what you use / right-size — align cost to actual need.

• Make data-driven decisions — monitor and measure, then optimize.

• Think globally, act regionally — use regions/AZs for proximity, compliance, and resilience.

Why ICCA cares: the Well-Architected pillars are the vocabulary of "good cloud." Questions about trade-offs (cost vs reliability, control vs agility) and best practices map directly to these pillars and principles. Learn the pillar names and the one-line meaning of each.

23. Strategic Cloud Participation & Adoption

ICCA uniquely tests the strategic/business side — how organizations adopt cloud and how teams (technical and non-technical) contribute.

Cloud adoption drivers (the "why" at an org level): cost optimization, business agility, innovation speed, scalability, global expansion, resilience/DR, and modernizing legacy IT.

Who contributes (cloud is a team sport):

• Leadership/executives — set strategy, fund adoption, define risk tolerance.

• IT/engineering — design, build, and operate cloud environments.

• Security/compliance — ensure controls and regulatory alignment.

• Finance — manage cloud spend (FinOps), model TCO.

• Sales/marketing/support — understand cloud offerings to serve customers and shape messaging.

• Business units — define requirements and consume cloud-enabled services.

Cloud strategy concepts:

• Cloud adoption framework — providers offer structured guidance (AWS CAF, Microsoft CAF, Google CAF) across people, process, and technology.

• Business case & TCO — justify adoption with cost, agility, and risk analysis.

• Governance from day one — identity, security, cost, and compliance guardrails before scaling.

• Skills & change management — training and cultural change are as important as technology.

• Cloud Center of Excellence (CCoE) — a cross-functional team that drives standards and best practices.

Vendor considerations: lock-in (dependence on one provider's proprietary services) vs. portability (multi-cloud/containers/open standards). Weigh best-of-breed benefits against switching costs.

The ICCA message: cloud success is organizational, not just technical — it needs aligned strategy, cross-team participation, governance, and people/skills, with everyone able to "join the cloud conversation."

24. Cloud Migration Concepts

Moving existing workloads to the cloud — a common strategic activity.

The "6 Rs" of migration (common framework):

1. Rehost ("lift and shift") — move as-is to cloud VMs; fastest, least optimization.

2. Replatform ("lift, tinker, and shift") — minor optimizations (e.g., move to a managed database) without redesign.

3. Repurchase — switch to a different product, often SaaS (e.g., retire a self-hosted app for a SaaS equivalent).

4. Refactor / re-architect — redesign for cloud-native (microservices, serverless); most effort, most benefit.

5. Retire — decommission what's no longer needed.

6. Retain — keep certain workloads on-prem (for now) — common in hybrid.

Migration phases: assess (inventory, TCO, readiness) → plan (strategy per workload, landing zone, governance) → migrate (move in waves) → optimize (right-size, modernize, secure). Landing zone = a well-architected, secure, multi-account baseline environment to migrate into. Considerations: downtime tolerance, data transfer volume/time, dependencies, compliance/data residency, cost, and security from the start.

25. Hands-On Lab — Provisioning AWS Resources (EC2 + S3)

Based on INE ICCA Lab 01 (Manage Cloud Resources — AWS). The goal is familiarity with the provisioning process, not these two resources specifically. The AWS console UI may change, but the procedure is the same. Authorized lab use only.

Explore the console.

1. Open the login URL from your lab credentials; sign in with the provided username/password.

2. Top-right → Region drop-down → choose your preferred region. (Region choice affects latency, cost, compliance, and which services are available — §7.)

3. Top-left → Services — this menu lists every AWS service. You'll use three: EC2 (virtual machines), S3 (object storage), Athena (serverless SQL queries over S3 data). Click a service name to open it; each shows its own resources and options.

Provision an EC2 instance (a virtual machine).

Services → EC2 → Launch instance
  Name and tags:  myFirstEC2
  AMI (image):    Amazon Linux  (the OS template)
  Instance type:  t2.micro      (free-tier eligible, from the t2 family)
  Key pair:       Create new key pair → name: demo → Create
                  (the .pem private key downloads — it's how you SSH in; keep it safe)
  Network / Storage settings: leave as default
  Review the summary (right side) → Launch instance
→ after a few seconds, a success message = the EC2 instance is provisioned

Concepts reinforced: an AMI is the OS image; instance type sets CPU/RAM; the key pair is your login credential (never share the private key); defaults give a working VPC/subnet/security-group and storage.

Provision an S3 bucket (object storage).

Services → S3 → Create bucket
  Bucket name:  <globally-unique-name>     (S3 names are unique across ALL of AWS)
  Region:       choose one
  Block Public Access:  LEAVE ENABLED (default) — buckets should be private unless intentionally public
  Advanced settings: review, but don't change anything
  → Create bucket
→ after a few seconds, the bucket is created

Concepts reinforced: object storage for files; bucket names are globally unique; public access is blocked by default — leaving it blocked is the secure default (public buckets are a top cloud misconfiguration, §14).

What you practiced: navigating the console, choosing a region, and provisioning the two most fundamental resources — compute (EC2) and storage (S3) — the same on-demand self-service pattern every cloud uses. Managing/terminating resources follows the same flow (select the resource → Stop/Terminate for EC2, Empty/Delete for S3) — remember to clean up to avoid charges. (Azure/GCP equivalents: create a VM + a Blob/Cloud Storage bucket — identical concepts, §8.)

26. Hands-On Lab — Provisioning Azure Resources (VM + Blob Storage)

The Azure equivalent of the AWS lab (§25) — identical concepts, different console. Authorized lab/free-account use only. The portal UI may change; the flow is the same.

Explore the portal.

1. Sign in to the Azure Portal (portal.azure.com).

2. Everything in Azure lives in a Resource Group (a logical container) inside a Subscription (the billing/scope boundary). Create or select a resource group first (e.g., rg-icca-demo).

3. The search bar / "Create a resource" is how you find services (the equivalent of AWS "Services").

Provision a Virtual Machine (compute — the Azure equivalent of EC2).

Create a resource → Virtual Machine → Create
  Subscription / Resource group:  <your subscription> / rg-icca-demo
  Virtual machine name:   myFirstVM
  Region:                 choose one (latency/compliance/cost — §7)
  Image:                  Ubuntu Server (or Windows Server) — the OS template
  Size:                   B1s or similar (low-cost / free-eligible tier)
  Authentication:         SSH public key (Linux) or username/password
                          → download/save the key — it's how you connect
  Networking / Disks:     leave defaults (Azure creates a VNet, subnet, NSG, disk)
  Review + create → Create
→ deployment runs; a success notification means the VM is provisioned

Concepts reinforced: the image = OS template, size = CPU/RAM, the SSH key = your login credential, and defaults create a VNet/subnet/NSG (firewall) and a managed disk — exactly the AWS pattern under Azure names (§8).

Provision Blob Storage (object storage — the Azure equivalent of S3).

Create a resource → Storage account → Create
  Resource group:   rg-icca-demo
  Storage account name:  <globally-unique-lowercase-name>   (unique across Azure)
  Region / Redundancy:   choose a region; LRS (cheapest) for a demo
  Public access:         leave restricted (secure default)
  Review + create → Create
→ then open the account → Containers → + Container → name it → Create
  (a "container" in Blob Storage is like an S3 "bucket")

Concepts reinforced: object storage for files; the account name is globally unique; public access is restricted by default (keep it private unless intentionally public, §14). Clean up: delete the resource group to remove everything at once and avoid charges.

Takeaway: same two fundamental resources (compute + object storage), same on-demand self-service pattern — only the console and names differ from AWS.

27. Hands-On Lab — Provisioning Google Cloud Resources (VM + Cloud Storage)

The GCP equivalent of the AWS/Azure labs — same concepts, Google Cloud console. Authorized lab/free-tier use only.

Explore the console.

1. Sign in to the Google Cloud Console (console.cloud.google.com).

2. Everything in GCP lives in a Project (the billing/management boundary) inside the Organization → Folders → Projects hierarchy. Create or select a project first (e.g., icca-demo).

3. The navigation menu (☰) lists all services (the equivalent of AWS "Services").

Provision a VM (compute — the GCP equivalent of EC2 — Compute Engine).

☰ → Compute Engine → VM instances → Create instance
  Name:        my-first-vm
  Region/Zone: choose (region = geography; zone = AZ equivalent — §7)
  Machine type: e2-micro (free-tier-eligible / low cost)
  Boot disk:   Debian/Ubuntu image (the OS template)
  Firewall:    (optional) Allow HTTP/HTTPS if serving web
  Create
→ the instance provisions in a few seconds; SSH in via the browser "SSH" button

Concepts reinforced: image = OS, machine type = CPU/RAM, GCP auto-creates a VPC/subnet/firewall, and browser-based SSH manages keys for you — same pattern, GCP names.

Provision Cloud Storage (object storage — the GCP equivalent of S3).

☰ → Cloud Storage → Buckets → Create
  Name:         <globally-unique-name>        (unique across all of Google Cloud)
  Location:     region of choice
  Storage class: Standard (hot) / Nearline / Coldline / Archive (cost vs access — §10)
  Public access: "Enforce public access prevention" (secure default) — leave on
  Create
→ the bucket is created; upload objects via the console/gsutil

Concepts reinforced: object storage, globally-unique bucket names, storage classes (tiering by access frequency), and public access prevented by default (§14). Clean up: delete the bucket and VM (or the whole project) to avoid charges.

The cross-provider lesson (all three labs): compute + object storage, created on demand through a console, with sensible secure defaults (private storage, auto-created network/firewall). Learn the pattern once — EC2/VM/Compute Engine and S3/Blob/Cloud Storage — and you can navigate any of the big three.

28. Practice Scenarios & Sample Questions

Scenario-style questions with the reasoning — this is how ICCA tests understanding. Cover the answer, reason it out, then check.

Q1. A company wants to run a legacy application in the cloud with full control over the operating system and installed software. Which service model fits? → IaaS (virtual machines give OS-level control). PaaS/SaaS abstract the OS away.

Q2. A developer wants to deploy code without managing any servers, paying only when the code runs. What should they use? → Serverless / FaaS (Lambda / Azure Functions / Cloud Functions).

Q3. Regulations require customer data to remain physically in Germany. Which cloud concept addresses this? → Region selection / data residency — deploy in a German region (§7, §15).

Q4. Who is responsible for configuring IAM permissions and encrypting data in the cloud? → The customer (security in the cloud). The provider secures the infrastructure (security of the cloud). Shared Responsibility Model (§14).

Q5. A workload has unpredictable, spiky traffic. Which cloud characteristic keeps performance and cost optimal? → Rapid elasticity / auto-scaling — scale out on spikes, scale in when quiet (§2, §9).

Q6. A business wants to avoid large up-front hardware purchases. What cloud economic benefit is this? → Shift from CapEx to OpEx (pay-as-you-go) (§5).

Q7. Which storage type suits storing millions of images accessed over the web, cheaply and at scale? → Object storage (S3 / Blob / Cloud Storage) (§10).

Q8. A team needs one login to access many SaaS applications. What provides this? → Single Sign-On (SSO), often with federation to an identity provider (§13).

Q9. An organization wants to keep sensitive data on-premises but burst to public cloud for peak compute. Which deployment model? → Hybrid cloud (§4).

Q10. What's the difference between RTO and RPO? → RTO = max acceptable downtime (how fast you recover); RPO = max acceptable data loss (how much data you can lose) (§18).

Q11. A company wants to move an app to the cloud quickly with minimal changes. Which migration strategy? → Rehost ("lift and shift") (§20).

Q12. Which pillar of the Well-Architected Framework covers right-sizing and eliminating idle resources? → Cost Optimization (§22).

Q13. Which service lets you run SQL queries directly over data stored in object storage, without managing servers (used in the AWS lab)? → AWS Athena (serverless query) / BigQuery / Synapse serverless (§13, §21).

Q14. A startup wants managed Kubernetes to run containers at scale. What do they use? → EKS / AKS / GKE (managed Kubernetes) (§8, §21).

Q15. What is the single most common cause of cloud data breaches? → Customer-side misconfiguration (e.g., public storage buckets, over-permissive IAM, no MFA) — not provider failure (§14).

Q16. A company must create and control its own encryption keys for compliance. Which service type? → Key Management Service (KMS) / Key Vault / Cloud KMS (§30).

Q17. Security wants to centrally detect misconfigurations (like public buckets) across the whole cloud estate. What category of tool? → Cloud Security Posture Management (CSPM) — Security Hub / Defender for Cloud / Security Command Center (§30).

Q18. Which three pillars make up observability? → Metrics, logs, and traces (§29).

Q19. A service promises 99.9% uptime in its contract. What is that called? → An SLA (Service Level Agreement) (§29).

Q20. You need to know who deleted a resource and when. Which log type? → Audit logs (CloudTrail / Activity Log / Cloud Audit Logs) (§29).

Q21. A fault-tolerant batch job can tolerate interruption and you want the lowest price. Which pricing model? → Spot / preemptible instances (§17).

Q22. An app is split into small independently-deployable services communicating via APIs. What architecture? → Microservices (§21).

Q23. Which deployment model uses two or more public cloud providers to avoid lock-in? → Multi-cloud (§4).

Q24. What does "serverless scales to zero" mean for cost? → When there's no usage, you pay nothing for compute — you only pay per execution (§9, §21).

Q25. A regulated workload needs the lowest possible data loss in a disaster. Which DR strategy fits best? → Multi-site / active-active (hot) — near-zero RPO (at highest cost) (§18).

How to use these: for each, identify the concept being tested and its cross-provider names. On the real exam, translate the scenario's business language into the underlying cloud concept, then pick the answer that matches it.

29. Monitoring, Observability & Cloud Operations Detail

You can't manage what you can't see. Monitoring is how you keep cloud environments healthy, performant, secure, and cost-effective.

The three pillars of observability:

• Metrics — numeric measurements over time (CPU %, memory, request count, latency, error rate). Lightweight, great for dashboards and alerts.

• Logs — timestamped records of discrete events (application logs, access logs, audit logs). Great for investigation and audit.

• Traces — follow a single request across multiple services (distributed tracing) to find bottlenecks in microservices.

Core monitoring services: AWS CloudWatch, Azure Monitor (+ Log Analytics), Google Cloud Monitoring/Logging (Operations suite). Each provides metrics, log collection, dashboards, and alerting.

Key capabilities:

• Dashboards — visualize the health/performance of your environment at a glance.

• Alerts / alarms — notify a human (email/SMS/chat) or trigger automation when a threshold is breached (e.g., CPU > 80%, error spike, budget exceeded).

• Auto-remediation — alerts can trigger actions (auto-scale, restart, run a function) to fix issues without human intervention.

• Audit logs — record who did what, when (AWS CloudTrail, Azure Activity Log, Google Cloud Audit Logs) — essential for security investigation and compliance.

• Health checks — load balancers and monitoring probe resources and route around unhealthy ones.

• Synthetic monitoring — simulated user transactions to catch problems before real users do.

Operational concepts:

• SLA / SLO / SLI — Service Level Agreement (the promised uptime, e.g., 99.9%), Objective (your internal target), Indicator (the actual measured metric).

• Incident response — detect → triage → resolve → learn (post-incident review).

• Capacity & performance management — use metrics to right-size and plan.

Why ICCA cares: monitoring underpins reliability, security, cost control, and compliance. Know the three pillars (metrics/logs/traces), the per-provider monitoring service, the role of audit logs, and that alerts can drive automated responses. Visibility is the foundation of good cloud operations.

30. Cloud Security Services & Threat Awareness

Beyond the shared-responsibility model (§15), know the common security services providers offer and the threats they counter — a frequent foundational topic.

Categories of cloud security service:

• Identity & access — the first line of defense: IAM, MFA, SSO, RBAC, and privileged-access controls (§14). Most breaches start with compromised credentials.

• Key management & encryption — managed services to create and control encryption keys: AWS KMS, Azure Key Vault, Google Cloud KMS; secrets managers for API keys/passwords (AWS Secrets Manager, Azure Key Vault, Google Secret Manager).

• Network protection — firewalls/security groups, Web Application Firewall (WAF) (filters malicious web traffic), and DDoS protection (AWS Shield, Azure DDoS Protection, Google Cloud Armor).

• Threat detection — services that analyze activity for malicious behavior: AWS GuardDuty, Microsoft Defender for Cloud, Google Security Command Center.

• Security posture management (CSPM) — continuously check for misconfigurations and compliance drift (AWS Security Hub, Defender for Cloud, Security Command Center).

• SIEM / monitoring — centralize and correlate security logs (Microsoft Sentinel, Amazon Security Lake, Google Chronicle).

Common cloud threats & risks (awareness):

• Misconfiguration — the #1 cause of cloud incidents: public storage buckets, over-permissive IAM, open firewall rules, disabled logging, unencrypted data.

• Compromised credentials / weak identity — phishing, leaked keys, no MFA → account takeover.

• Insecure APIs — exposed/poorly-secured interfaces.

• Data breaches / leakage — unprotected or over-shared data.

• Insider threats — malicious or careless authorized users.

• Denial of Service (DoS/DDoS) — overwhelming a service to make it unavailable.

• Supply-chain / third-party risk — vulnerable dependencies or SaaS integrations.

Foundational best practices: enable MFA everywhere (especially root/admin), apply least privilege, encrypt data at rest and in transit, keep storage private by default, enable logging/monitoring and audit trails, patch (for IaaS), use the provider's security posture tools, and build defense in depth. Security is continuous and shared — the provider gives you the tools; your configuration and vigilance make them effective.

31. Exam-Day Tips & Study Plan

Exam approach:

• ICCA tests understanding and recognition, not memorized steps. For each concept, know what it is, why it's used, and its equivalent across AWS/Azure/GCP.

• Lock down the shared responsibility model (§14), service vs deployment models (§3–4), the cross-provider equivalents table (§8), and core identity/security terms (§13) — these recur throughout.

• Read scenario questions for the concept being tested (e.g., "data must stay in Germany" → region/data residency; "pay only when code runs" → serverless; "one login for many apps" → SSO).

• Don't over-index on one provider — the exam is vendor-neutral; recognize the pattern under any brand name.

• Remember the business side (CapEx/OpEx, elasticity, TCO, adoption drivers) — ICCA deliberately includes non-technical fluency.

Study plan (flexible, ~2 weeks):

Days 1-2    Cloud foundations: definition, characteristics, service & deployment models (§2-4)
Days 3-4    Business drivers, economics, the three providers, global infrastructure (§5-7)
Days 5-6    Core services + cross-provider equivalents; compute/storage/networking/databases (§8-12)
Days 7-8    Identity, security, shared responsibility, compliance & governance (§13-15)
Days 9-10   Management, cost/FinOps, automation/IaC (§16-18)
Days 11-12  Strategic participation, adoption frameworks, migration (§19-20)
Day  13     Hands-on: provision a VM + storage bucket in a free-tier account (§21)
Day  14     Review the equivalents table + shared responsibility + glossary; practice scenarios

Common pitfalls: confusing service models (IaaS/PaaS/SaaS) with deployment models (public/private/hybrid); forgetting the customer is always responsible for data & access; mixing up scalability vs elasticity; not knowing cross-provider names; and ignoring the business/strategic domain.

32. Glossary & Quick Reference

Service models: IaaS (rent infrastructure — VMs/storage/network), PaaS (rent a platform — deploy code), SaaS (use finished software), FaaS/Serverless (run just functions on demand). Deployment models: Public (shared provider cloud), Private (dedicated), Hybrid (public+private connected), Multi-cloud (more than one provider). Characteristics (NIST): on-demand self-service, broad network access, resource pooling, rapid elasticity, measured service. Economics: CapEx (up-front capital) vs OpEx (ongoing operational); TCO (total cost of ownership); pay-as-you-go / reserved / spot; economies of scale. Infrastructure: Region (geography), Availability Zone (isolated DC group for HA), Edge/PoP (near users for CDN/DNS). Compute: VM (EC2/Azure VM/Compute Engine), container (EKS/AKS/GKE), serverless (Lambda/Functions/Cloud Functions). Storage: object (S3/Blob/Cloud Storage), block (EBS/Managed Disks/Persistent Disk), file (EFS/Files/Filestore); durability, availability, tiers, lifecycle. Networking: VPC/VNet, subnet, security group, load balancer, DNS, CDN, VPN / direct connect. Databases: relational/SQL (RDS/Azure SQL/Cloud SQL), NoSQL (DynamoDB/Cosmos DB/Firestore), data warehouse (Redshift/Synapse/BigQuery). Identity: IAM, authentication (who you are) vs authorization (what you can do), user/group/role/service account, least privilege, MFA, SSO, RBAC, federation, root/global-admin. Security: Shared Responsibility Model (provider = security of the cloud; customer = security in the cloud), encryption at rest/in transit, defense in depth, logging/monitoring, misconfiguration (public buckets, over-permissive IAM). Compliance/governance: ISO 27001, SOC 2, PCI DSS, HIPAA, GDPR, FedRAMP; data residency/sovereignty, data classification, policies/guardrails, tags/labels, audit reports. Management: monitoring (metrics/logs/alerts), backups & DR (RTO/RPO), high availability, support plans, resource hierarchy (accounts/subscriptions/projects). Automation: IaC (CloudFormation/ARM-Bicep/Deployment Manager/Terraform), CLI/SDK, auto-scaling, CI/CD. Strategy: cloud adoption framework (CAF), business case/TCO, CCoE, vendor lock-in vs portability, migration 6 Rs (rehost, replatform, repurchase, refactor, retire, retain), landing zone.

End of guide. ICCA validates cloud fluency: understand the core concepts (service/deployment models, economics, the shared responsibility model, identity, security, compliance, management, and strategy), recognize how they appear across AWS, Azure, and Google Cloud, and be ready to contribute to any cloud conversation — technical or business. Learn the concepts and the cross-provider equivalents, do a little hands-on provisioning, and you'll have the breadth the exam rewards.