1.1 Cloud Computing Principles & Deployment Models

1.1 Cloud Computing Principles & Deployment Models

[!NOTE] Exam Foundation: The Oracle Cloud Infrastructure Foundations Associate (1Z0-1085-26) examination tests both general cloud computing theory and Oracle-specific architectural implementations. A clear mastery of the five NIST essential characteristics, service delivery models, financial structures, and resilience objectives is vital for answering foundational architecture questions.

Which Exam Version This Guide Targets

Oracle refreshes the OCI Foundations exam annually, and the 2026 release changed more than the content. Anchor your prep to these current facts before you study anything else:

If a practice question, video, or blog post refers to 1Z0-1085-25, 1Z0-1085-24, or an "OCI 2025 Foundations Associate" badge, it predates the current release. The four domains and their weights are stable across the recent versions - Getting Started with OCI (15%), Core OCI Services (50%), Security Services (25%), and Governance and Administration (10%) - but always confirm logistics against Oracle University's exam page rather than a third-party summary.

Cloud computing represents a fundamental paradigm shift in how information technology services, computing power, and storage capacity are provisioned, operated, and funded. Rather than purchasing, racking, and maintaining physical servers in private corporate datacenters, organizations consume computing resources as an on-demand, network-accessible utility provided by hyperscale cloud service providers like Oracle.

---

What is Cloud Computing?

According to the widely accepted standard defined by the National Institute of Standards and Technology (NIST):

"Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction."

The Five Essential Characteristics

Under the NIST definition, any true cloud computing environment must exhibit five core characteristics:

1. On-Demand Self-Service: Consumers can provision computing capabilities, such as server instances, processing power, and storage capacity, automatically and unilaterally as needed, without requiring human interaction with the cloud service provider. In Oracle Cloud Infrastructure (OCI), an engineer can provision an enterprise compute instance, configure a block volume, or spin up an autonomous database in seconds using the OCI Console, the OCI Command Line Interface (CLI), Terraform/OpenTofu, or Software Development Kits (SDKs).

2. Broad Network Access: Cloud capabilities are accessible over standard network protocols through universal mechanisms that promote use by heterogeneous client platforms (such as desktop workstations, laptops, tablets, and mobile devices). OCI services are reachable over the public internet via secure HTTPS/TLS endpoints, through dedicated, private peering connections like OCI FastConnect, or through encrypted Site-to-Site IPSec VPN tunnels.

3. Resource Pooling: The provider's physical computing resources are pooled together in massive, multi-tenant datacenters to serve multiple consumers simultaneously. Physical and virtual compute, storage, and networking resources are dynamically assigned and reassigned in real time according to consumer demand. Consumers experience location independence—generally having no direct knowledge of or control over the exact physical rack or blade chassis housing their workloads, though they can specify location at higher logical levels such as country, region, or availability domain.

4. Rapid Elasticity: Capabilities can be elastically provisioned and released—often automatically—to scale rapidly outward and inward commensurate with fluctuating demand. To the consumer, available resources appear virtually infinite and can be scaled to any quantity at any time. For example, an e-commerce platform running on OCI can configure autoscaling policies that launch additional compute instances during flash sales and immediately terminate excess instances when traffic returns to normal.

5. Measured Service: Cloud systems automatically monitor, control, and optimize resource usage by leveraging metering mechanisms at an appropriate level of abstraction (such as compute hours, gigabytes of storage, network bandwidth consumed, or active user accounts). Resource consumption is transparently tracked and billed. In OCI, compute instances are metered to the exact second, block storage is billed per gigabyte-month, and outbound data transfer is metered transparently with clear cost-analysis reporting.

---

Cloud Service Models: IaaS, PaaS, and SaaS

Cloud computing offerings are structured into three distinct service models—often visualised as a pyramid representing increasing levels of abstraction and provider management. This division determines the Shared Responsibility Model between the customer and Oracle.

1. Infrastructure as a Service (IaaS)

Infrastructure as a Service represents the foundational tier of cloud computing. The cloud provider delivers the raw computing building blocks: physical datacenter facilities, power, cooling, physical networking, server hardware, and the virtualization hypervisor layer.

• Customer Responsibilities: The customer retains full administrative ownership of the guest operating system (including OS installation, security configuration, and kernel patching), middleware, database engines, application source code, network routing, and data protection.
• OCI Examples: OCI Bare Metal and Virtual Machine Compute Instances, Virtual Cloud Networks (VCNs), Block Volumes, File Storage Service (FSS), and Object Storage.
• Key Benefit: Maximum architectural control, customizability, and operational flexibility.

2. Platform as a Service (PaaS)

Platform as a Service elevates the level of abstraction by eliminating the need for customers to manage underlying virtual machines, operating systems, and runtimes. The cloud provider provisions, hardens, monitors, and automatically patches the operating system, container runtime, and database management system. The customer focuses solely on developing, deploying, and maintaining application logic, database schemas, and data.

• Customer Responsibilities: Deploying application source code, managing database tables and queries, configuring identity permissions, and managing business data.
• Provider Responsibilities: Operating system patching, automated hardware scaling, database engine maintenance, automated daily backups, and hypervisor tuning.
• OCI Examples: Oracle Autonomous Database (Autonomous Transaction Processing and Autonomous Data Warehouse), Oracle Container Engine for Kubernetes (OKE), OCI Functions (serverless event-driven execution), and OCI API Gateway.
• Key Benefit: High developer velocity and elimination of routine administrative maintenance overhead.

3. Software as a Service (SaaS)

Software as a Service provides a complete, turnkey application hosted, secured, and operated entirely by the provider. End users access the software over the network via a standard web browser or dedicated API. The customer does not manage servers, operating systems, code updates, or database clusters.

• Customer Responsibilities: User account provisioning, role-based access assignments, organizational business workflow configuration, and data governance.
• Provider Responsibilities: The entire operational stack, from physical datacenter security up to application feature releases, database optimization, and high availability.
• Oracle Examples: Oracle Fusion Cloud Applications (Enterprise Resource Planning / ERP, Human Capital Management / HCM, Supply Chain Management / SCM), and NetSuite.
• Key Benefit: Zero infrastructure management; immediate business software consumption.

Shared Responsibility Comparison Matrix

---

Cloud Deployment Models

Organizations deploy cloud infrastructure across four recognized deployment models based on governance, compliance, and isolation requirements:

1. Public Cloud: Cloud infrastructure is owned and operated by a third-party hyperscale provider (such as Oracle) and offered to multiple customer organizations (tenants) over the public internet or private dedicated links. Workloads run on shared physical hardware separated by hypervisor-level isolation. Public clouds deliver unmatched economies of scale, near-instant elasticity, and zero datacenter maintenance.

2. Private Cloud: Cloud infrastructure is provisioned for exclusive use by a single organization comprising multiple business units or internal consumers. It may be owned, managed, and operated by the enterprise, a third party, or a combination, and can be located on-premises or off-premises. Private clouds offer complete physical hardware isolation and strict data residency compliance, but require significant capital expenditure and operational maintenance.

3. Hybrid Cloud: An integrated environment combining two or more distinct cloud infrastructures (private, community, or public) that remain unique entities, but are bound together by standardized networking and management protocols enabling data and application portability. For example, an enterprise may run a sensitive transaction database on an on-premises Oracle Exadata system while bursting web microservices into OCI public regions during traffic spikes.

4. Community Cloud: Cloud infrastructure provisioned for exclusive use by a specific community of organizations that share common missions, regulatory requirements, security standards, or jurisdictional policies. Examples include dedicated government clouds that host federal, state, and defense agency workloads under strict regulatory controls.

---

Financial Models: CAPEX vs. OPEX

Migrating to OCI transforms how enterprises finance, budget, and account for their technological infrastructure:

Capital Expenditure (CAPEX)

CAPEX represents traditional on-premises IT spending. Organizations execute large, upfront capital payments to purchase physical assets—server chassis, SAN storage arrays, core fiber switches, and backup diesel generators.

• Accounting Treatment: Physical hardware purchases are recorded as capital assets on the corporate balance sheet and depreciated over their useful economic lifespan (typically 3 to 5 years).
• Forecasting Inefficiencies: Engineering teams must predict infrastructure capacity 3 to 5 years in advance. Over-provisioning leads to expensive, underutilized hardware sitting idle in datacenters. Under-provisioning results in server saturation, poor customer performance, and missed revenue opportunities when business demand outgrows physical capacity.
• Inflexibility: Capital investments represent sunk costs that cannot be easily returned or repurposed if business strategy changes.

Operational Expenditure (OPEX)

OPEX represents day-to-day operational costs incurred while running ongoing business activities. In a public cloud model, infrastructure is consumed as a variable utility expense.

• Accounting Treatment: Cloud consumption costs (compute hours, storage gigabytes, data transfer) are treated as operational business expenses on the current period's income statement, reducing taxable income immediately.
• Pay-As-You-Go Efficiency: Organizations pay only for the exact computing capacity consumed. When a seasonal project concludes, virtual machines and block volumes are terminated immediately, and billing stops.
• Agility and Innovation: Engineering teams can spin up experimental environments in minutes without submitting capital purchase requisitions or waiting for multi-month procurement cycles.

---

Core Cloud Architectural Benefits

Architecting enterprise workloads on OCI requires mastering five foundational reliability principles:

High Availability (HA)

High availability ensures that systems and applications remain accessible and operational with minimal downtime over a given period, typically measured in percentages of uptime known as "nines" (e.g., 99.9% uptime allows ~8.76 hours of downtime per year, whereas 99.99% allows only ~52.6 minutes per year). HA is achieved by eliminating single points of failure through redundant instances, health-checked load balancers, and multi-datacenter distributions.

Fault Tolerance (FT)

While high availability focuses on minimizing downtime during an outage, fault tolerance represents the system's ability to continue operating without any interruption or user-perceptible degradation when hardware or software components fail. Fault-tolerant designs employ active-active redundancy, synchronous data replication, and instantaneous failover mechanisms so that failure of a physical host or network switch causes zero service disruption.

Scalability: Vertical vs. Horizontal

Scalability measures a system's capacity to handle increased workloads by expanding computing resources:

• Vertical Scalability (Scaling Up / Down): Involves adding more compute cores (OCPUs), RAM, or storage to an existing server instance. In OCI, an administrator can vertically scale a compute instance by changing its shape (e.g., upgrading from a 2-OCPU VM to an 8-OCPU VM) or dynamically increasing a block volume's size without detaching it. Vertical scaling is constrained by the maximum physical capacity of the host server.
• Horizontal Scalability (Scaling Out / In): Involves adding more discrete instances or nodes to work concurrently in a distributed pool. In OCI, web and application tiers scale out by adding additional VM instances across multiple Fault Domains behind an OCI Load Balancer. Horizontal scaling provides virtually limitless expansion.

Elasticity

Elasticity is the automated, dynamic expansion and contraction of resources in real time to match fluctuating workload demands. Unlike static scalability, elasticity actively provisions resources during traffic surges and automatically tears them down when demand drops. This prevents performance degradation during peak hours while eliminating wasted expenditure during off-peak periods. In OCI, Autoscaling policies monitor CPU or memory utilization and automatically adjust the capacity of Instance Pools.

Disaster Recovery: RTO and RPO

Disaster Recovery (DR) encompasses the policies, tools, and procedures required to restore vital technology infrastructure and data following a catastrophic disaster (such as a regional power failure, natural catastrophe, or severe ransomware event). DR planning is anchored by two critical metrics:

• Recovery Time Objective (RTO): The maximum acceptable length of time that an application, system, or service can remain offline following an outage before significant operational or financial damage occurs. RTO answers the question: "How long can the business afford to be down before systems are operational again?"
• Recovery Point Objective (RPO): The maximum acceptable age of files or data that must be recovered from backup storage for normal operations to resume, representing the maximum allowable data loss measured in time. RPO answers the question: "How much data can the business afford to lose measured from the moment of disruption back to the last backup?"