Skip to main content
E
EmmaPrep.com
CompTIA Cloud (CV0-004) Collection2026 Core Spec
Cloud ArchitectureMEDIUMVerified Curriculum9 min read

Cloud Architecture

Interactive AI Tutor Study Mode
Ask questions, request worked examples, or test understanding.

Chapter 1

Cloud Architecture

Course: Comptia Cloud Cv0 004
Subject: Comptia Cloud Cv0004
Chapter: Cloud Architecture

1. Cloud Service Models

Cloud computing offers different layers of abstraction and service models, each targeting specific operational needs. The four primary models are:

a. Infrastructure as a Service (IaaS)

Definition: IaaS provides fundamental computing resources such as virtual machines, networking, storage, and other essential infrastructure components. Users manage the operating system, applications, data, and runtime environment, while the cloud provider manages the physical infrastructure.

Key Characteristics:

  • High level of control and flexibility.
  • Ideal for system administrators and DevOps teams.
  • Scalable virtualized computing resources.
  • Users are responsible for OS patches, application updates, and security hardening.

Real-World Use Cases:

  • Hosting a virtual data center for a company.
  • Migrating legacy applications from on-premises to the cloud.
  • Setting up custom security monitoring tools and VPNs.

Examples of IaaS Providers:

  • Amazon EC2 (AWS)
  • Google Compute Engine (GCP)
  • Microsoft Azure Virtual Machines
  • Oracle Cloud Infrastructure (OCI)

Example Scenario: A company wants to host a web application on a virtual machine with specific OS hardening configurations and intrusion detection systems. They choose AWS EC2 for full control over the virtual environment.

b. Platform as a Service (PaaS)

Definition: PaaS delivers a framework for developers to build, test, and deploy applications without managing the underlying infrastructure (hardware, OS, or storage).

Key Characteristics:

  • Abstracts the infrastructure and runtime management.
  • Focuses on app development and deployment.
  • Comes with built-in scalability, high availability, and CI/CD integration.

Real-World Use Cases:

  • Rapid development of cloud-native applications.
  • Hosting scalable REST APIs.
  • Automating builds and deployments using integrated DevOps tools.

Examples of PaaS Providers:

  • Google App Engine
  • Azure App Services
  • AWS Elastic Beanstalk
  • Heroku

Example Scenario: A development team needs to deploy a Python Flask web app quickly without worrying about load balancing or patching the OS. They use Heroku, a PaaS, which allows Git-based deployment and offers add-ons for databases, logging, and monitoring.

c. Software as a Service (SaaS)

Definition: SaaS provides ready-to-use, cloud-hosted software applications accessible via web browsers. Users do not manage infrastructure, middleware, or runtime—only the application content and usage.

Key Characteristics:

  • Zero infrastructure management for users.
  • Multi-tenant environment.
  • Accessible from any device with an internet connection.
  • Subscription or pay-per-use model.

Real-World Use Cases:

  • Email and productivity tools.
  • Customer Relationship Management (CRM) systems.
  • Collaboration and video conferencing platforms.

Examples of SaaS Providers:

  • Microsoft 365 (Outlook, Word, Excel)
  • Google Workspace (Gmail, Docs)
  • Salesforce (CRM)
  • Zoom (video conferencing)

Example Scenario: A startup adopts Google Workspace for employee communication, document sharing, and video meetings. They do not manage any servers or apps—they just use the platform.

d. Function as a Service (FaaS)

Definition: FaaS is a serverless computing model where developers write and deploy individual functions (small pieces of code) that are executed in response to events, without managing infrastructure or servers.

Key Characteristics:

  • Event-driven and stateless.
  • Ideal for microservices and automation tasks.
  • Auto-scaling and billing based on function invocations.
  • Short-lived execution model.

Real-World Use Cases:

  • Backend logic for serverless APIs.
  • Real-time file processing (e.g., image resizing upon upload).
  • Automation scripts for cloud resource cleanup.
  • Security event responses (e.g., automatically block IPs on alerts).

Examples of FaaS Providers:

  • AWS Lambda
  • Azure Functions
  • Google Cloud Functions
  • IBM Cloud Functions

Example Scenario: A cybersecurity team uses AWS Lambda to monitor CloudTrail logs. When a new IAM user is created, the Lambda function is triggered to check whether the user violates security policy and alerts the admin via SNS.

2. Shared Responsibility Model

Definition

The Shared Responsibility Model in cloud computing delineates the security and operational responsibilities between the cloud service provider (CSP) and the cloud consumer (customer). While the provider ensures the security of the cloud (physical hardware, global infrastructure, network), the customer is responsible for security in the cloud (data, user access, configuration).

This model varies significantly based on the cloud service model in use:

  • Infrastructure as a Service (IaaS)
  • Platform as a Service (PaaS)
  • Software as a Service (SaaS)

Responsibility Matrix by Service Model

| Responsibility Area | IaaS | PaaS | SaaS | | Data | Customer | Customer | Customer | | Applications | Customer | Customer | Provider | | Runtime | Customer | Provider | Provider | | Middleware | Customer | Provider | Provider | | Operating System | Customer | Provider | Provider | | Virtualization | Provider | Provider | Provider | | Physical Infrastructure | Provider | Provider | Provider | | Networking/Storage | Provider | Provider | Provider |

Notes:

  • Data-level responsibilities are always with the customer: classification, encryption, retention, backups.
  • PaaS & SaaS abstract operational complexity but do not eliminate accountability for application logic, compliance, or identity and access management (IAM).
  • Virtualization and lower stack components (hypervisors, disks, NICs, power, cooling) are always managed by the CSP.

Real-World Examples of Shared Responsibility

a. IaaS Example: Azure Virtual Machines

A financial services company hosts a PostgreSQL database on Azure VM. They are responsible for:

  • OS Patching: Using tools like unattended-upgrades, yum, or Azure Automation Update Management to apply monthly security updates.
  • Host-Based Firewalls: Enforcing traffic rules via iptables, ufw, or firewalld.
  • Data Encryption at Rest: Using LUKS (Linux Unified Key Setup) or BitLocker with key management integrated into Azure Key Vault.
  • Logging and Monitoring: Deploying Wazuh, OSSEC, or syslog servers. Forwarding logs to Azure Monitor or SIEMs.
  • IAM: Managing SSH key-based access, disabling password auth, and enforcing 2FA with Azure AD integration.
  • Backups: Scheduling encrypted snapshots of VM disks using Azure Backup.

Security Insight: Any breach caused by unpatched vulnerabilities, weak SSH configurations, or exposed management ports is the customer’s fault, not Microsoft’s.

PaaS Example: Google App Engine

An e-commerce company uses Google App Engine (GAE) to deploy a Node.js shopping cart application.

  • Customer Responsibilities:

Writing and securing app logic (e.g., input validation, session security).

Configuring OAuth 2.0 or Firebase Authentication.

Managing API tokens and secrets (preferably stored in Google Secret Manager).

Securing third-party API integrations (e.g., Stripe for payments).

Monitoring logs in Cloud Logging and responding to anomalies.

  • Writing and securing app logic (e.g., input validation, session security).
  • Configuring OAuth 2.0 or Firebase Authentication.
  • Managing API tokens and secrets (preferably stored in Google Secret Manager).
  • Securing third-party API integrations (e.g., Stripe for payments).
  • Monitoring logs in Cloud Logging and responding to anomalies.
  • Provider Responsibilities:

OS and runtime updates (Node.js versions).

Autoscaling and availability.

Load balancing and TLS termination.

Patching the underlying containers and VMs.

  • OS and runtime updates (Node.js versions).
  • Autoscaling and availability.
  • Load balancing and TLS termination.
  • Patching the underlying containers and VMs.

Security Insight: If the app suffers an injection attack due to poor coding practices, it is a customer-side failure, even though the platform is fully managed.

b. SaaS Example: Salesforce CRM

A law firm uses Salesforce to store sensitive client information.

  • Customer Responsibilities:

Defining user roles and least-privilege access.

Enabling multi-factor authentication (MFA) or SSO (SAML) with Azure AD or Okta.

Managing export controls (e.g., disabling data export to Excel).

Setting data retention policies and regional data residency.

Monitoring user activity via audit logs.

  • Defining user roles and least-privilege access.
  • Enabling multi-factor authentication (MFA) or SSO (SAML) with Azure AD or Okta.
  • Managing export controls (e.g., disabling data export to Excel).
  • Setting data retention policies and regional data residency.
  • Monitoring user activity via audit logs.
  • Provider Responsibilities:

Application security (OWASP Top 10 defenses).

SLA for uptime (e.g., 99.9% availability).

Platform-level encryption and backups.

Regular patching and feature updates.

  • Application security (OWASP Top 10 defenses).
  • SLA for uptime (e.g., 99.9% availability).
  • Platform-level encryption and backups.
  • Regular patching and feature updates.
  • Security Insight: If an intern downloads an entire customer database and emails it, this insider threat remains the customer's responsibility, not Salesforce’s.

Security Implications of the Shared Responsibility Model

1. Misconfiguration Risks

  • Cloud-native misconfigurations are a leading cause of breaches.
  • Example: An S3 bucket marked as “public-read” by a developer accidentally exposes PII of thousands of users. Though hosted on AWS, the misconfiguration is entirely the customer’s fault.

Mitigation: Use tools like AWS Config, Azure Policy, or Prisma Cloud to scan for compliance drift and enforce guardrails.

2. Regulatory Compliance Responsibility

  • Cloud providers are not responsible for your compliance.
  • Even in SaaS, the customer must configure retention, access logs, and auditing to satisfy GDPR, HIPAA, or PCI-DSS.

Example: A hospital using Microsoft 365 must:

  • Enable audit logs in Microsoft Purview.
  • Retain patient communication data.
  • Encrypt emails with Microsoft Information Protection.
  • Sign a Business Associate Agreement (BAA) with Microsoft to meet HIPAA.

3. Third-Party Integrations

  • Customers often connect cloud services to third-party APIs, webhooks, or CI/CD pipelines.
  • These external interfaces introduce shared risk.

Example: A Jira instance integrated with GitHub using an OAuth token stored insecurely in code. If compromised, it may allow lateral movement into other environments—even if Jira itself is secure.

Mitigation: Use secrets managers, audit tokens periodically, and restrict scopes.

4. Identity and Access Management (IAM)

  • CSPs provide the tools (IAM roles, policies, federated identity), but you must configure them correctly.
  • Over-privileged service accounts or lack of MFA enforcement can result in privilege escalation or credential misuse.

Mitigation:

  • Use least privilege, role separation, and time-based access (e.g., Google’s Access Approval).
  • Enable MFA for all console and CLI users.

Summary

| Area | Provider Responsibility | Customer Responsibility | | Infrastructure Security | ✅ Always | ❌ | | Operating System & Patching | ❌ IaaS | ✅ IaaS | | App Security | ❌ (PaaS/SaaS) | ✅ Always | | Data Classification & Encryption | ❌ | ✅ Always | | Compliance Controls | ❌ | ✅ Always | | IAM & Access Policies | ❌ | ✅ Always |