1.

1 – Examining Cloud Service Models

• Objective: 1.1 Given a scenario, use the appropriate cloud service mode.

o Cloud service models:

 Infrastructure as a service (IaaS)

 Platform as a service (PaaS)

 Software as a service (SaaS)

 Function as a service (FaaS)

• Infrastructure as a Service (IaaS)

o Provides virtualized compute, storage and networking resources over the

internet

o Customer is responsible for OS, middleware, runtime, data and applications

o Enables rapid provisioning of VMs, block storage and virtual networks

without hardware purchases

o Common use case: Lift-and-shift of on-prem workloads, test/development

environments

• Platform as a Service (PaaS)

o Delivers hardware and software tools (OS, middleware, database) managed

by provider

o Customer focuses on application code and data; provider handles OS

patching, scaling and load balancing

o Accelerates development workflows with built-in CI/CD, managed runtimes

and database services

o Common use case: Web application frameworks, microservices

deployments

• Software as a Service (SaaS)

o Hosts complete applications accessible via web browser or API; provider

manages everything underneath
 o Customer consumes functionality and configures only settings and user data

o Removes need for installation, maintenance and licensing overhead

o Common use case: Email (e.g., Office 365), CRM systems (e.g., Salesforce),
collaboration tools (e.g., Google Workspace)

• Function as a Service (FaaS)

o Enables serverless execution of single-purpose functions triggered by events

o Customer supplies only code; provider auto-scales and bills per execution
time/invocation

o Eliminates idle resource costs and abstracts infrastructure management

entirely

o Common use case: Event-driven tasks like image processing, real-time data
transformation, webhook handlers
1.2 - Shared Responsibility Model

Domain: 1.0 - Cloud Architecture

• Objective: 1.1 Given a scenario, use the appropriate cloud service mode.

o Shared Responsibility Model

• Shared Responsibility Model

o Framework that delineates which security and compliance tasks the cloud
provider manages versus those the customer must handle

o Ensures clear boundaries to avoid gaps or overlaps in protection

• Cloud Provider Responsibilities

o Physical infrastructure: data center security, power, cooling, and hardware

maintenance

o Virtualization layer and foundational services: hypervisor patching, network

isolation, managed platform components

o Global compliance certifications: ISO 27001, SOC 2, PCI DSS attestations for
the underlying cloud

• Customer Responsibilities

o Data: classification, encryption, backup, and lifecycle management

o Applications and operating systems (IaaS/PaaS): patching, configuration,

and vulnerability management

o Identity and access management: user/accounts provisioning, MFA, and

permission scoping

o Network controls: firewall rules, security groups, and VPN configurations

• Variation by Service Model

o IaaS: Customer secures OS, middleware, runtime, data and apps; provider
secures physical hosts and virtualization

 PaaS: Provider abstracts and secures OS and runtime; customer

focuses on application code and data
  SaaS: Provider secures nearly the entire stack; customer
responsibility is limited to data, user access and device security

 FaaS: Provider handles all infrastructure and runtime; customer

supplies only function code and event permissions

• Why It Matters

o Clarifies shared duties to prevent misconfigurations that lead to data

breaches

o Guides customers in audit readiness by highlighting which controls they

must implement and document

o Helps teams architect secure cloud deployments by mapping

responsibilities to organizational policies
1.3 - Resource Availability

Domain 1.0 - Cloud Architecture

• Objective - 1.2 Explain concepts related to service availability

o Resource availability:

 Region

 Availability zone

 Cloud bursting

 Edge computing

 Availability monitoring

• Region

o A broad geographic area composed of multiple data centers

o Provides data sovereignty, compliance controls and disaster recovery

boundaries. Examples include US East (N. Virginia) or Europe West
(Belgium).

o Architectures often replicate critical workloads across regions to survive full-

region failures.

• Availability zone

o An isolated data center within a region with independent power, cooling and
networking

o Designed to tolerate failures in other zones.

o Distributing resources (VMs, databases) across two or more AZs within a

region increases uptime and meets multi-AZ SLA requirements.

• Cloud bursting

o A hybrid deployment pattern where on-premises infrastructure handles

normal workloads and “bursts” overflow into the public cloud during spikes.
 o Orchestration tools automatically provision cloud VMs when on-prem
utilization exceeds thresholds, then decommission them as demand
subsides to control costs.

• Edge computing

o Deploying compute and storage resources at network edges—near users or

devices—to minimize latency and conserve bandwidth

o Common in IoT and real-time applications (autonomous vehicles, AR/VR)

o Edge nodes process data locally and sync with central clouds for analytics
and long-term storage.

• Availability monitoring

o Continuous health checks and performance tracking of services and

infrastructure.

o Involves synthetic transactions, system metrics (CPU, memory, disk I/O),

application logs and user-experience testing.

o Alerts trigger automated remediation (auto-scaling, failover) or notify ops

teams to uphold defined SLAs.
1.4 - Disaster recovery (DR)

Domain 1.0 - Cloud Architecture

• Objective - 1.2 Explain concepts related to service availability.

o Disaster recovery (DR):

 Recovery time objective (RTO)

 Recovery point objective (RPO)

 Hot site

 Warm site

 Cold site

• Recovery time objective (RTO)

o Maximum tolerable downtime from outage to full-service restoration

o Drives the selection of DR strategies and resource allocation.

• Recovery point objective (RPO)

o Maximum acceptable data loss measured in time

o Determines backup frequency, replication methods and data

synchronization intervals.

• Hot site

o Fully operational

o Mirrored facility with real-time data replication

o Offers near-instant failover and minimal downtime at highest cost.

o Extremely costly

• Warm site

o Partially provisioned facility with pre-installed hardware and periodic data

replication

o Requires configuration but balances recovery speed and expense.

• Cold site
 o Basic facility providing power and connectivity only

o Requires full hardware installation and data restoration upon activation

o Longest recovery times

o Low expense

• Multicloud tenancy

o Deployment of workloads and services across two or more cloud providers to

leverage best-of-breed capabilities and avoid vendor lock-in.

o Requires unified governance, identity and access management, secure

networking and service parity across heterogeneous environments.

o Enables workload placement based on performance, compliance or cost

considerations and supports cross-cloud failover for resilience.
1.5 - Public and Private Connections

Domain 1.0 - Cloud Architecture

• Objective - 1.3 Explain cloud networking concepts

o Public and private connections:

 Virtual private network (VPN)

 Dedicated connections

Virtual Private Network (VPN)

• Definition: Establishes an encrypted tunnel over the public Internet to link on-
premises networks or remote clients with cloud resources, ensuring data privacy in
transit.

• Tunneling Protocols:

o PPTP (Point-to-Point Tunneling Protocol): Uses GRE for encapsulation and

MPPE for encryption; easy to configure but vulnerable to modern attacks—
avoid for sensitive data.

o L2TP/IPsec (Layer 2 Tunneling Protocol with IPsec): L2TP handles the tunnel
and IPsec provides encryption and integrity; strong security, though double
encapsulation can add latency.

o IKEv2/IPsec (Internet Key Exchange v2 with IPsec): IKEv2 negotiates and

maintains IPsec tunnels, supports MOBIKE for seamless roaming, and offers
fast reconnection after network changes.

• Encryption Options:

o MPPE (for PPTP)

o AES-128, AES-256, 3DES (for IPsec)—stronger ciphers like AES-256 increase

CPU usage but deliver higher confidentiality

• Authentication Methods:

o Pre-shared Keys (PSK): Simple but less scalable and vulnerable if shared
insecurely
 o Digital Certificates (X.509): Provide mutual authentication and easier key
management at scale

o EAP Variants (e.g., EAP-TLS): Enable TLS-based client-server

authentication, ideal for user-based VPN access

• Considerations:

o Quick setup and low cost

o Performance depends on Internet link quality

o Scalability may require multiple VPN gateways

o Stronger security adds management complexity

o Decide between split-tunneling and full-tunneling

Dedicated Connections

• Definition: Uses private, provider-managed circuits to bypass the public Internet,

delivering predictable performance, lower latency, and enhanced security for cloud
connectivity.

• AWS Direct Connect:

o Speeds & Ports: 1 Gbps, 10 Gbps, 100 Gbps dedicated or hosted

connections via AWS facilities or partners

o Virtual Interfaces:

 Private VIF: Direct access to VPC resources

 Public VIF: Access to AWS public services (e.g., S3, DynamoDB)

without the Internet

o Benefits: Consistent throughput, lower egress costs, compliance support

o Trade-offs: Port-hour fees, data-transfer pricing, colocation requirements,

multi-week provisioning

• Azure ExpressRoute:

o Circuit Options: 50 Mbps to 10 Gbps via ExpressRoute partners or co-

location

o Peering Types:
  Private Peering: Connects to Azure VNets

 Microsoft Peering: Accesses Azure PaaS services (e.g., Storage, SQL

Database)

 Public Peering: (Deprecated) formerly for Azure public endpoints

o Features: BGP routing, SLA-backed 99.95% availability, global Microsoft

network

o Trade-offs: Monthly port/data fees, partner contracts, setup complexity, lead

times

• Considerations:

o Higher cost vs. VPN but superior performance

o Ideal for high-throughput, latency-sensitive, or compliance-bound workloads

o Combine with VPN for redundancy

o Plan BGP, failover, and on-prem routing integration

Additional Resources

• A VIF, or Virtual Interface, is a logical network interface you create over a single
physical Direct Connect circuit to segment and route different traffic types.

o Private VIF: Connects directly to your AWS VPC using Border Gateway
Protocol (BGP) over a VLAN, carrying your private IP traffic.

o Public VIF: Provides access to AWS public endpoints (S3, DynamoDB, etc.)
by advertising public IP prefixes over a separate VLAN.
1.6 - Network Functions, Components and Services

Domain: 1.0 - Cloud Architecture

• Objective: 1.3 Explain cloud networking concepts.

o Network functions, components, and services:

 Application load balancer

 Network load balancer

 Application gateway

 Content delivery network (CDN)

 Firewalls

 Virtual private cloud (VPC):

 Peering

 Transit gateway

 Subnets

 Routing and switching:

 Virtual LAN (VLAN)

 Software-defined network (SDN)

 Border Gateway Protocol (BGP)

 Static routes

 Route tables

Network Functions, Components, and Services

• Network functions

o Core operations performed on network traffic

o Enable secure, reliable connectivity between cloud resources and users.

o Often delivered as virtualized or managed services

o Can scale on demand

 o Integrate with IAM and policy frameworks

• Network components

o Physical or virtual network communication devices

o Enforce network topology and policies in the cloud

o Configuration determines traffic flow and isolation

o Examples

 Virtual network interfaces (VIF)

 Gateways

 Routers and switches

 Firewalls

• Network services

o Higher-level, managed offerings that abstract away infrastructure

management

o Provide built-in monitoring, scaling, fault tolerance and global reach

o Examples

 Content delivery networks (CDNs)

 DDoS protection

 DNS

 VPN as a service

 Managed load balancers

• Application load balancer (ALB)

o Operates at Layer 7 of the OSI model to inspect HTTP/HTTPS requests and

route them to backend targets (EC2 instances, containers, IP addresses)
based on configurable listener rules.

o ALBs evaluate URL paths, host headers, HTTP methods and query
parameters to make routing decisions
 o Perform health checks on each target, and automatically stop sending traffic
to unhealthy endpoints

o Dynamically distributing requests according to real-time load and target

health

o Improve application availability, enable blue/green and canary deployments

o Optimize resource utilization for microservices and containerized workloads.

• Network load balancer (NLB)

o Functions at Layer 4, handling millions of TCP/UDP connections with ultra-

low latency by forwarding packets to targets using flow hashing.

o NLBs preserve the client’s source IP

o Support static “elastic” IP addresses,

o Provides client IP visibility for logging and security

o Scale automatically to meet sudden spikes and integrate with health checks
to route around failing targets without human intervention

o Ideal for workloads that require high throughput (e.g., VoIP, gaming, financial
trading)

• Application gateway

o Acts as a reverse proxy and web application firewall (WAF) at Layer 7,

terminating SSL/TLS connections, offloading certificate management, and
inspecting inbound traffic against custom or managed rule sets

o Application gateways can block SQL injection, cross-site scripting and other
OWASP Top Ten threats before requests reach backend services

o Provide URL-based routing and session affinity for stateful web applications.

• Content delivery network (CDN)

o Distributes cached copies of static (images, CSS, JavaScript) and dynamic

content across a global network of edge locations

o CDNs reduce latency by serving content from the edge nearest to end users,
decrease origin-server load, and can accelerate SSL/TLS handshake and
HTTP/2 across regions.
 o Advanced CDNs also support origin pull, cache invalidation APIs, geo-
restriction, and real-time metrics for cache HIT/MISS rates

• Firewalls

o Provide stateful or stateless packet and application-layer inspection

o Enforce security policies at network boundaries

o Cloud-native firewalls can integrate with identity services to enforce user- or

group-based access

o Perform deep packet inspection for application-level threats, and log traffic
for audit and forensics

o Can be deployed as managed services or virtual appliances, with distributed

enforcement points close to the workload for micro-segmentation

• Virtual private cloud (VPC)

o An isolated, software-defined network environment with customizable IP

address ranges, subnets, route tables and security controls.

o VPCs enable customers to:

 Launch cloud resources in a logically separated network

 Apply granular network ACLs and security groups

 Connect securely to on-premises or other VPCs

• Peering

o Establishes a one-to-one, low-latency, encrypted link between two VPCs

(even across regions)

o Enable private IP connectivity without traffic ever transiting the public

internet.

o Avoids bandwidth charges associated with VPNs

o Simplifies network topology when only a few VPCs must communicate

directly

• Transit gateway

o Acts as a central hub for multi-VPC and on-prem connectivity, consolidating

hundreds of peering relationships into a star topology.
 o Transit gateways simplify routing by propagating route tables automatically

o Support multicast, bandwidth-optimized attachments

o Can integrate with on-premises routers via BGP

• Routing and switching

o Subnets

 Segments within a VPC’s IP address range

 Used to isolate and organize resources by function, security level or

availability zone

 Subnets can be public (with an Internet gateway), private (with NAT or

egress-only Internet gateway), or dedicated to specific workloads

 Each subnet it's own route table and network ACL to control ingress
and egress traffic.

o Virtual LAN (VLAN)

 Creates logical broadcast domains within cloud or hybrid

environments

 allow multiple isolated Layer 2 networks over shared physical

infrastructure.

 VLAN tagging (802.1Q) separates tenant traffic, enforces QoS, and

enables.

o Software-defined network (SDN)

 Abstracts physical network devices through a centralized controller

that programs forwarding rules across virtual switches and routers.

 SDN enable:

 dynamic provisioning of network paths

 micro-segmentation

 automated policy enforcement

 integration with orchestration tools (e.g., Kubernetes CNI

plugins)
 o Border Gateway Protocol (BGP)

 A dynamic routing protocol used to exchange route information

between autonomous systems

 Example

 Between cloud VPCs via transit gateways

 Between on-prem routers over VPN/Direct Connect

 Supports path selection based on attributes (AS path, MED, local

preference)

 Enabling policy-driven failover and traffic optimization across multiple

links

o Static routes

 Manually configured routes

 Used when dynamic routing is unnecessary or unsupported

 Implement for predictable traffic patterns

 Require manual updates if network topology changes

o Route tables

 Collections of route entries (destination CIDRs and target next hops)

associated with subnets and gateway attachments.

 Determine how traffic destined for various network segments (VPC

peering, Internet gateway, NAT, transit gateway) is forwarded

 Ensuring packets reach the correct endpoint(s).

Additional Resources:

• Multi-Exit Discriminator (MED) is a metric that can be used to influence inbound

traffic when there are multiple entry points to an AS.

• AS Path is a sequence of Autonomous System numbers that shows the path a route
has traversed. BGP uses the AS path to determine the shortest path, with shorter
paths generally being preferred.
• Local Preference is a BGP attribute that dictates the preference for routes
advertised to neighbors. BGP routers use local preference to choose which neighbor
to receive routes from.
1.7 - Cloud Storage Types

Domain: 1.0 - Cloud Architecture

• 1.4 Compare and contrast storage resources and technologies

o Tiered storage

 Hot

 Warm

 Cold

 Archive

o Disk types

 Solid-state drive (SSD)

 Hard disk drive (HDD)

o Storage types

 Object storage

 Block storage

 File storage

 Performance implications

o Cost implications

Objective:

• Tiered storage:

o Hot

 Optimized for frequently accessed data with low latency and high
IOPS

 Ideal for transactional databases, VM boot volumes and real-time

analytics

 Commonly backed by SSD media and charged at the highest per-GB

rates
 o Warm

 Balances performance and cost for data accessed intermittently (e.g.,

weekly reports, dev/test datasets)

 Offers moderate latency and throughput by using cost-optimized SSD

or high-RPM HDD

 Pricing sits between hot and cold tiers.

o Cold

 Designed for infrequently accessed data (e.g., monthly backups,

archive snapshots) where retrieval time of seconds to minutes is
acceptable

 Common built on HDD

 Storage costs are lower

 Retrieval and API request charges may apply.

o Archive

 Suited for long-term retention of data that is rarely, if ever, accessed

(e.g., compliance records, legal holds)

 Provides the lowest per-GB cost through deep-archive systems where

retrieval can take hours

 Often incurs minimum storage duration and retrieval fees.

• Disk types:

o Solid-state drive (SSD)

 Uses NAND flash memory to deliver high random IOPS, low latency
(<1 ms) and sustained throughput

 Ideal for boot volumes, databases and latency-sensitive applications

 More expensive per GB and subject to write-cycle endurance limits

o Hard disk drive (HDD):

 Employs spinning magnetic platters to provide higher capacity at

lower cost per GB
  Offers moderate sequential throughput but higher latency (5–10 ms)
and lower random IOPS

 Appropriate for large-scale data lakes, log storage and bulk archival.

• Storage types:

o Object storage:

 Stores data as discrete objects in a flat namespace with rich

metadata and HTTP(s) API access

 Provides virtually unlimited scalability, built-in durability and eventual

consistency.

 AWS example: Amazon S3 (Standard, Intelligent-Tiering, Glacier)

 Azure example: Azure Blob Storage (Hot, Cool, Archive tiers)

o Block storage:

 Presents raw block devices attachable to compute instances

 Offers consistent IOPS/throughput, low latency

 Allows fine-grained control over file systems and encryption

 AWS example: Amazon EBS (gp3, io2, st1)

 Azure example: Azure Managed Disks (Premium SSD, Standard HDD,

Ultra Disk)

o File storage:

 Provides a shared file system interface (NFS/SMB) with POSIX or CIFS

semantics for multiple concurrent clients

 Simplifies lift-and-shift of legacy applications

 AWS example: Amazon EFS (Standard, Infrequent Access)

 Azure example: Azure Files (Standard, Premium tiers)

• Performance implications:

o Choice of tier, disk type and storage type directly impacts IOPS, throughput,
latency and consistency guarantees.
 o SSD-backed hot tiers and block volumes deliver highest performance for
transactional workloads, while HDD-based cold tiers and archive options
trade speed for capacity.

o Network overhead for object and file storage adds latency compared to
locally attached block storage; edge acceleration or caching can mitigate
these effects.

• Cost implications:

o Hot tiers and SSD volumes incur higher per-GB and per-IOPS charges but
reduce compute runtime and performance-related costs.

o Warm and cold tiers lower storage costs but may introduce retrieval, early-
deletion or API request fees.

o Archive tiers minimize ongoing storage expenses but require planning for
retrieval latency and potential bulk access charges.

o Data egress, cross-region replication and snapshot storage also contribute to

total cost of ownership and must align with RTO/RPO and budgetary
constraints.
1.8 - Cloud Native Design Concepts

Domain: 1.0 - Cloud Architecture

• Objective: 1.5 Explain the purpose of cloud-native design concepts

o Managed services

o Microservices

o Loosely coupled architecture

o Fan-out

o Service discovery

Cloud-native design concepts

• Managed services:

o Fully operated cloud offerings

o offload maintenance tasks—patching, backups, scaling and high

availability—to the provider

o They embed best-practice security, automatic failover and usage-based

billing

o Examples

 AWS RDS

 Azure Cosmos DB

 Google Cloud Pub/Sub

 Kubernetes-as-a-Service

• Microservices:

o An architectural style that decouples applications into small, independently

deployable services

o Each service owns a distinct business capability and data store—and

communicating through lightweight APIs or event streams.
 o Enable teams to iterate rapidly, scale components horizontally based on
granular demand.

o Improves fault isolation—if one service fails, others continue operating

o Aligns with DevOps practices of continuous integration and continuous

deployment (CI/CD).

• Loosely coupled architecture:

o A design principle in which services share as few dependencies as possible

o The goal is for changes in one component do not cascade across the system

o They support parallel team development and reduce the blast radius of
failures.

o Techniques such as API gateways, asynchronous messaging and adapter

layers promote decoupling and preserve interoperability.

• Fan-out:

o A pattern that distributes a single event or request across multiple

downstream tasks or services in parallel

o Increases throughput and minimizes latency by exploiting horizontal scaling,

o Coordinating fan-out often involves publish/subscribe topics, event buses or

Step Functions/Logic Apps

• Service discovery:

o An automated mechanism that enables microservices to locate each other

dynamically at runtime, abstracting away hard-coded IPs and ports.

o Registries such as AWS Cloud Map, Azure Service Fabric Naming Service or
HashiCorp Consul track healthy service instances and expose them via DNS
or API queries

o Integrate discovery with load balancing, TLS encryption and observability

o Service discovery is vital for elastic and ephemeral workloads where

container instances scale up and down frequently across nodes and
availability zones.
1.9 - Containerization Concepts

Domain: 1.0 - Cloud Architecture

• Objective: 1.6 Compare and contrast containerization concepts

o Stand-alone vs. orchestration

o Networking:

 Port mapping

o Storage:

 Persistent volumes

 Ephemeral storage

o Image registries

• Container deployment modes

o Stand-alone

 Containers are managed individually on a single host using tools like

Docker CLI or Podman

 Ideal for development, small-scale or test environments.

 Stand-alone deployments lack built-in orchestration features (auto-

scaling, self-healing, rolling updates)

 Operators must manually handle container lifecycle, networking and

failover

o Orchestration

 Platforms such as Kubernetes, Docker Swarm or AWS ECS coordinate

containers across clusters of hosts

 Provide service discovery, desired-state management, automated

scaling and self-healing.

 Orchestrators will

 Abstract node failures

  Perform rolling upgrades with zero downtime

 Balance resource utilization across the cluster

• Networking

o Port mapping

 Binds a container’s internal port to a host port or cluster IP

 Enable external clients to reach the service

 Proper port mapping ensures isolation (avoiding port collisions)

 Can be combined with overlay networks in an orchestrator to expose

services securely.

• Storage

o Persistent volumes

 External storage abstractions that survive container restarts and

rescheduling

 Decouples storage lifecycle from container lifecycle.

 Used for stateful workloads such as databases and message queuing,

where integrity is required.

o Ephemeral storage

o Container-local filesystem or scratch space that is deleted when the

container is removed

o Used for caching, temporary computation or scratch data

o Offers low-latency I/O

o Not reliable for long-term data persistence (critical data is offloaded to

persistent volumes/external services)

• Image registries

o Centralized repositories (public or private) for storing, versioning and

distributing container images

o Registries integrate with CI/CD pipelines to push built images

o Enforce image signing and vulnerability scanning

o Control access via IAM policies

o Registries ensure consistent, immutable artifacts are deployed across

environments, enabling traceability and rollbacks
1.10 - Virtualization Concepts

Domain: 1.0 - Cloud Architecutre

• Objective: 1.7 Compare and contrast virtualization concepts

o Deployment models:

 Stand-alone

 Clustering

 Cloning

 Host affinity

 Hardware pass-through

o Network types:

 Overlay networks

 VM networks

o Storage:

 Local

 SAN

 NAS

Virtualization concepts

• Deployment models:

o Stand-alone: Virtual machines (VMs) run on a single hypervisor host without

external dependencies; simple to set up for development or testing but lacks
high availability and migration capabilities.

o Clustering: Multiple hypervisor hosts join a resource pool, sharing CPU,

memory and storage; enables live VM migration, load balancing and
automatic failover if a host fails, meeting enterprise SLAs.

o Cloning: Creates exact copies of a VM image—full clones duplicate all disks

and configuration, while linked clones share base disks to save storage;
 accelerates provisioning of test environments or scaling out stateless
workloads.

o Host affinity: Rules that govern VM placement—affinity pins related VMs

together on the same host for low-latency communication, whereas anti-
affinity spreads VMs across hosts to reduce blast radius and improve fault
tolerance.

o Hardware pass-through: Directly maps physical devices (NICs, GPUs,

NVMe drives) into a VM using technologies like PCIe passthrough or SR-IOV;
provides near-bare-metal performance for workloads requiring specialized
hardware.

• Network types:

o Overlay networks: Encapsulate tenant traffic over an underlay network

using tunneling protocols (VXLAN, GRE); allow creation of virtual L2
segments across multiple hosts or data centers, simplifying multi-tenant
isolation and micro-segmentation.

o VM networks: Traditional virtual switches or distributed switches that bridge

VMs to physical NICs and VLANs; support VLAN tagging (802.1Q), QoS
policies and port security for consistent network policies between on-prem
and cloud environments.

• Storage:

o Local: Uses host-attached storage (direct-attached disks or SSDs) for VM

disks; offers the lowest latency but ties VM mobility to the host and requires
replication for high availability.

o SAN (Storage Area Network): Provides block-level storage (via Fibre

Channel or iSCSI) accessible by multiple hypervisors; supports shared LUNs
for VM clustering, snapshots and centralized management.

o NAS (Network-Attached Storage): Delivers file-level storage over NFS or

SMB protocols; enables multiple VMs to mount the same share for
applications requiring shared file systems, such as home directories or
content repositories.

• Additional Concepts

o Virtual Extensible LAN (VXLAN)

  Encapsulates Layer 2 Ethernet frames within Layer 4 UDP packets to
create scalable overlay networks over existing IP underlays, using 24-
bit segment IDs (VNIs) to support up to 16 million isolated networks.

 Enables large data centers and cloud environments to stretch tenant

networks across physical boundaries, simplify multi-tenant isolation,
and dynamically provision virtual networks without reconfiguring the
underlay fabric.

o Generic Routing Encapsulation (GRE)

 Wraps a wide variety of network layer protocols (IPv4, IPv6, MPLS,

etc.) inside virtual point-to-point tunnels over an IP network, providing
protocol-agnostic connectivity between disparate sites.

 Allows hyperscale data centers and cloud providers to interconnect

legacy and modern networks seamlessly, support custom routing
topologies, and carry non-IP traffic across IP backbones for hybrid
and multi-site deployments.
1.11 - Cloud Cost Considerations

Domain: 1.0 - Cloud Architecture

• Objective: 1.8 Summarize cost considerations related to cloud usage

o Billing models:

 Dedicated host

 Reserved instances

 Pay-as-you-go

 Spot instances

o Resource metering

o Tagging

o Rightsizing

• Billing models

o Dedicated host:

 Allocates a physical server exclusively for a single customer.

 Helps meet compliance and licensing requirements for specialized

workloads.

 Billed at the host level, often providing cost benefits when fully
utilized.

o Reserved instances:

 Commits to a one- or three-year usage term in exchange for

significant hourly rate discounts.

 Provides capacity reservation in specific availability zones for critical

workloads.

 Best suited for steady-state usage patterns to lower long-term costs.

o Pay-as-you-go:
  Charges based on actual resource consumption without upfront
commitments.

 Offers maximum flexibility with no termination penalties.

 Ideal for unpredictable or highly variable workloads.

o Spot instances:

 Bids on unused capacity at steep discounts compared to on-demand

rates.

 Instances may be reclaimed by the provider with short notice when

capacity is needed.

 Suitable for fault-tolerant, stateless, or batch processing jobs that

handle interruptions.

• Resource metering:

o Tracks compute, storage, network and other service usage in real-time or

near-real-time.

o Generates detailed usage reports and billing statements per resource or

service.

o Enables identification of consumption patterns and optimization

opportunities.

• Tagging:

o Assigns metadata key-value pairs to resources for categorization and cost

allocation.

o Facilitates chargeback, cost reporting and policy enforcement across teams

and projects.

o Automates cost governance by integrating with budgeting and alerting tools.

• Additional Concepts

o Chargeback

 Allocates actual cloud costs to individual departments, teams or

projects based on resource consumption.
  Encourages accountability by making stakeholders aware of their
spending patterns.

 Drives more prudent resource usage and helps justify budget

requests.

o Cost reporting

 Produces detailed dashboards and reports showing spend by service,

resource type and business unit.

 Highlights anomalies, trends and forecasting insights to support

financial planning.

 Integrates with chargeback processes to validate allocation accuracy

and identify optimization opportunities.

o Policy enforcement

 Applies automated rules (e.g., tagging requirements, budget

thresholds) to prevent non-compliant resource deployment.

 Triggers alerts or remediation actions (shutdown, scale-down) when

cost or usage policies are violated.

 Ensures governance standards are consistently upheld across all

cloud environments.

o Rightsizing:

 Analyzes historical utilization to match instance types and storage

classes to actual workload needs.

 Reduces waste by downsizing overprovisioned resources and

upgrading underperforming ones.

 Continuously applies optimization recommendations to maintain

cost-efficiency.
1.12 - Database Concepts

Domain: 1.0 - Cloud Architecture

• Objective: 1.9 Explain the importance of database concepts

o Types:

 Relational

 Non-relational

o Deployment options:

 Self-managed

 Provider-managed

Types

• Relational

o Structures data in tables with predefined schemas, enforcing data types and
relationships via primary/foreign keys

o Enables aggregation and retrieval of structured data

o Delivers strong ACID (Atomicity, Consistency, Isolation, Durability)

guarantees

o Ensures reliable transactions for financial, inventory and order-processing

systems

o Supports complex queries with SQL joins and indexing

• Non-relational

o Stores data in flexible formats allowing schema evolution and unstructured

or semi-structured payloads.

o Examples

 Documents

 Key-value pairs

 Wide-column or graph models

 o Optimized for horizontal scaling across distributed clusters

o Offers eventual consistency (BASE) to handle massive volumes of user

profiles, logs or IoT telemetry.

o Enables polyglot persistence: you can choose the best model (document vs.
graph vs. key-value) to suit specific application access patterns.

Additional Concepts

• ACID (Atomicity, Consistency, Isolation, Durability)

o Guarantees that database transactions are processed reliable

o Each transaction is:

 All-or-nothing (Atomic)

 Leaves the database in a valid state (Consistency)

 Runs independently of others (Isolation)

 Once committed, survives failures (Durability)\

o Provides cloud-native databases with the confidence to auto-scale and

distribute data across regions

• Schema

o A formal blueprint of a database’s structure to enforce data integrity and

guide query execution

o Defines:

 Tables & Columns

 data types

 Relationships

 constraints (primary keys, foreign keys)

 Indexes

• Polyglot persistence

o The strategy of incorporating various database types within a single system to

better manage diverse kinds of data
 o Examples:

 Relational databases for structured data and transactions.

 NoSQL databases for handling large-scale unstructured data.

 Graph databases for managing complex relationships between

entities.

 In-memory databases for high-speed data processing

• BASE (Basically Available, Soft state, Eventual consistency)

o A design philosophy for distributed systems

o Emphasizes

 The system remains available under all conditions (BA)

 May hold transient state that changes over time without explicit input
(S)

 Guarantees that all replicas will eventually become consistent (E).

o Enables cloud-native databases to scale horizontally across data centers,

tolerate network partitions, and deliver low-latency responses at massive
scale.

Deployment options

• Self-managed

o The customer provisions and configures database software on their own

compute instances (on-prem or IaaS)

o Enables full control over versions, extensions and tuning parameters

o Offers maximum customization but increases operational overhead

o Customer responsibilities:

 Patch management,

 Backup scheduling & replication setup

 Capacity planning

 High-availability clustering
• Provider-managed

o Abstracts away infrastructure management,

o Customers focus on schema design, query optimization and data modeling

o Streamlines maintenance and accelerates time to market

o May impose limits on customization (e.g.. extensions, engine versions or low-

level tuning)

o Also known as Database-as-a-Service

 Providers responsibilities:

 Provisioning

 Backups and replication

 Patch management

 Scaling and failover

1.13 - Workload Optimization

Domain: 1.0 - Cloud Architecture

• Objective: 1.10 Compare and contrast methods for optimizing workloads.

o Compute:

 VM

 Container

 Serverless

o Orchestration and workflow

o Network:

 Latency

 Throughput

o Storage:

 IOPS

 Throughput

o Managed services

• Compute

o VM:

 Right-size instance types by matching vCPU, memory and network

capacity to workload demands.

 Leverage auto-scaling groups to add or remove VMs based on

utilization metrics, minimizing overprovisioning.

o Container:

 Increase density by packing multiple containers onto hosts, utilizing

orchestrator bin-packing and resource quotas.

 Use lightweight container runtimes to reduce startup latency and

improve resource efficiency compared to full VMs.
 o Serverless:

 Employ event-driven functions that provision resources only on

invocation, eliminating idle compute costs.

 Take advantage of built-in concurrency and automatic scaling to

handle variable workloads without manual capacity planning.

o Orchestration and workflow:

 Define CI/CD pipelines to build, test and deploy workloads

automatically, reducing human error and speeding delivery.

 Use workflow engines or service meshes to coordinate task

dependencies, parallelize jobs and retry failed steps transparently.

• Network

o Latency:

 Co-locate services in the same region or availability zone and enable

edge caching to minimize round-trip times.

 Employ TCP optimizations (window scaling, keep-alive) and HTTP/2 or

gRPC to reduce protocol overhead.

o Throughput:

 Aggregate multiple connections using load balancers or flow-based

hashing to maximize link utilization.

 Use compression and protocol tuning (e.g., Jumbo frames, HTTP

compression) to increase effective data rates.

• Storage

o IOPS:

 Select storage tiers (SSD vs. HDD, premium vs. standard) based on
random read/write requirements of the workload.

 Implement local or in-memory caching (e.g., Redis, CDN edge

caches) to reduce backend IOPS pressure.

o Throughput:
  Stripe volumes or use RAID configurations to aggregate disk
throughput for large sequential workloads.

 Optimize block size and queue depth settings to match application

I/O patterns and achieve maximum throughput.

• Managed services

o Offload maintenance and tuning to provider-managed offerings (e.g.,

managed databases, message queues) that auto-scale and self-optimize.

o Leverage built-in features like read replicas, caching layers and global
distribution to improve performance without custom infrastructure.
1.14 - Evolving Technologies

Domain: 1.0 Cloud Architecture

• Objective: 1.11 Identify evolving technologies in the cloud.

o Machine learning & AI:

 Text recognition

 Text translation

 Visual recognition

 Sentiment analysis

 Voice-to-text

 Text-to-voice

 Generative AI

o Internet of Things (IoT):

 Sensors

 Gateways

 Communication protocols

 Transmission protocols

• Machine learning & AI:

o Text recognition

 Uses optical character recognition (OCR) models to convert printed or

handwritten text in images and documents into machine-readable
format.

 Leverages deep convolutional neural networks to segment

characters, recognize fonts and handle skew or noise.

 Automates data entry and indexing workflows at scale, reducing

manual effort and transcription errors.

o Text translation
  Employs neural machine translation (NMT) architectures to convert
text between source and target languages with contextual
understanding.

 Supports real-time streaming translation and batch jobs via RESTful

APIs or SDKs.

 Enables globalized applications to present localized content

dynamically without in-house linguistic teams.

o Visual recognition

 Applies computer vision models to detect objects, faces, text and

scenes in images or video.

 Integrates pretrained and custom-trained models for industry-specific

use cases (e.g., quality inspection, security surveillance).

 Provides metadata (labels, bounding boxes, confidence scores) to

feed search, compliance and analytics systems.

o Sentiment analysis

 Uses transformer-based natural language processing to score text for

positive, negative or neutral sentiment.

 Tokenizes and parses syntax to detect nuances like sarcasm or mixed

emotion.

 Aggregates insights from social media, support tickets or surveys to

guide product, marketing and customer service strategies.

o Voice-to-text

 Transcribes spoken language into text using recurrent neural networks

(RNNs) or attention-based models, producing time-stamped
transcripts.

 Supports speaker diarization to attribute segments to individual

voices.

 Powers closed-captioning, call-center analytics and voice-driven

interfaces without manual transcription.

o Text-to-voice
  Synthesizes human-like speech from input text via neural vocoders
and waveform generation models.

 Allows Speech Synthesis Markup Language (SSML) tags to control

pronunciation, pitch, volume and speaking rate.

 Enables interactive voice assistants, accessibility features and

dynamic narration at enterprise scale.

o Generative AI

 Provides foundation models (large language or multimodal models)

that generate text, code or images from prompts.

 Supports fine-tuning or embedding APIs to adapt to domain-specific

data for customized outputs.

 Integrates into chatbots, content-creation pipelines and coding

assistants to accelerate development and creativity.

• Internet of Things (IoT)

o Sensors

 Devices that measure physical parameters (temperature, humidity,

motion, chemical levels) and convert them into digital signals.

 Often built on low-power microcontrollers or application-specific

integrated circuits (ASICs) to extend battery life in remote
deployments.

 Feed telemetry to cloud ingestion services for real-time monitoring,

analytics and predictive maintenance.

o Gateways

 Edge nodes that aggregate, preprocess and secure sensor data before
forwarding to the cloud.

 Can run local compute functions (filtering, aggregation, ML inference)

to reduce bandwidth and latency.

 Provide device management, certificate provisioning and offline

buffering until connectivity is restored.

o Communication protocols
  MQTT (Message Queuing Telemetry Transport): A lightweight
publish/subscribe protocol over TCP, optimized for low-bandwidth,
high-latency or unreliable networks.

 CoAP (Constrained Application Protocol): A RESTful, UDP-based

protocol designed for resource-constrained devices with minimal
overhead.

 AMQP (Advanced Message Queuing Protocol): An open standard for

reliable queuing and complex routing in enterprise messaging.

o Transmission protocols:

 LoRaWAN (Long Range Wide Area Network): Low-Power Wide-Area

Network protocol offering kilometers of range at low data rates, ideal
for battery-powered sensors.

 NB-IoT (Narrowband Internet of Things): A cellular standard providing

enhanced coverage and deep-indoor penetration with minimal power
consumption.

 LTE-M (Long-Term Evolution for Machines): A variant of LTE optimized

for IoT, offering higher throughput and mobility support than NB-IoT.

 5G (Fifth Generation Cellular): Next-generation cellular technology

delivering ultra-low latency, high bandwidth and massive device
density for real-time IoT applications.