Oracle Cloud Resource Manager Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Observability and Management

1. Introduction

Oracle Cloud Resource Manager is Oracle Cloud Infrastructure (OCI)’s managed infrastructure-as-code (IaC) service based on Terraform. It helps you provision, update, and destroy OCI resources in a repeatable, auditable way—without needing to run Terraform from your laptop or maintain your own remote state backend.

In simple terms: you upload Terraform code to Resource Manager, then click “Plan” and “Apply” to build OCI infrastructure (networks, compute, databases, identity objects, and more), with OCI managing the execution environment and state handling.

Technically, Resource Manager introduces first-class OCI objects—stacks and jobs—to manage Terraform configurations. A stack is a packaged Terraform configuration plus variables and metadata. A job is an execution of that configuration (for example, plan, apply, or destroy). Resource Manager runs Terraform in an OCI-managed runner, uses OCI identity for authorization, and stores/locks Terraform state so teams can collaborate safely.

What problem it solves: It standardizes infrastructure deployment and operations in OCI by making Terraform execution managed, repeatable, and governed—reducing configuration drift, “works on my machine” issues, credential sprawl, and ad-hoc manual provisioning.

Service name note: The official OCI service is commonly referred to as Oracle Cloud Infrastructure Resource Manager or OCI Resource Manager. As of the latest generally available documentation, the service name is still Resource Manager. If Oracle rebrands or reorganizes console categories, verify in the official docs: https://docs.oracle.com/en-us/iaas/Content/ResourceManager/home.htm

2. What is Resource Manager?

Official purpose

Resource Manager is OCI’s managed service for running Terraform to provision and manage OCI resources. It provides a controlled way to execute Terraform plans/applies, manage Terraform state, and operationalize IaC workflows in OCI.

Core capabilities

Resource Manager typically provides capabilities such as:

Creating stacks from Terraform configurations (uploaded archives, Object Storage, or Git-based sources depending on current support)
Running jobs (Plan, Apply, Destroy; and other job types if available in your tenancy/region—verify in official docs)
Managing Terraform state (storage, locking/concurrency control, download/upload in supported workflows—verify exact options in your console)
Handling Terraform variables and optionally UI-friendly variable schema (when provided)
Supporting Resource Discovery (generate Terraform from existing OCI resources) (verify current scope and supported services)

Major components

Resource Manager’s key concepts are:

Stack: A Terraform configuration plus its variables, metadata, and state association.
Job: An execution against a stack (for example, plan/apply/destroy). Jobs produce logs and outputs.
Configuration source: How the Terraform code is supplied (zip file, Object Storage, Git repo, etc.—options can vary).
Terraform state: The stored record of deployed resources. Resource Manager manages this as part of stack execution and uses locking to prevent concurrent state corruption.
Outputs: Terraform outputs captured after apply.

Service type

Managed IaC execution service (Terraform-based), used for provisioning and lifecycle management of infrastructure.
In OCI console organization, you’ll typically find it under areas related to Developer Services or Governance/Administration (console navigation can change; verify in your region/tenancy UI).

Scope: regional vs global

Resource Manager is generally region-scoped in OCI (stacks and jobs exist in a region). However, Terraform code can often target resources in other regions if provider configuration supports it. Treat cross-region management as an advanced pattern and verify implications (IAM, latency, service endpoints, and provider configuration) in official docs and your organization’s standards.

How it fits into the Oracle Cloud ecosystem

Resource Manager sits in the operational layer of OCI—alongside other Observability and Management services—by enabling:

Standardized provisioning of OCI services (Networking, Compute, Database, Kubernetes, IAM objects where supported)
Auditability via OCI logging/audit
Separation of duties through compartments, policies, and controlled job execution
Repeatable environments for dev/test/prod and regulated change management

3. Why use Resource Manager?

Business reasons

Faster delivery with consistency: Teams can deploy standardized infrastructure repeatedly.
Lower operational risk: Reduces manual errors and undocumented “clickops.”
Better governance: Infrastructure changes become traceable jobs with logs and history.

Technical reasons

Managed Terraform execution: No need to run Terraform locally or maintain CI runners just for provisioning.
State management and locking: Helps prevent concurrent apply operations and state corruption.
Reproducible infrastructure: Infrastructure definitions become code artifacts that can be versioned and reviewed.

Operational reasons

Central place to run IaC: Operators can run plan/apply/destroy from OCI console or automation.
Job logs for debugging: Execution logs are kept with the stack/job record.
Supports environment promotion: Same codebase, different variable sets across environments (dev/test/prod).

Security/compliance reasons

Reduces credential sprawl: Resource Manager commonly uses OCI-native authentication patterns (for example, resource principals). This reduces storing long-lived API keys in CI systems (verify exact auth behavior in your tenant’s configuration and docs).
IAM-controlled execution: Permissions determine who can create stacks and run jobs—and what the jobs can do in target compartments.

Scalability/performance reasons

Scales team workflows: Multiple stacks, repeatable modules, standardized naming/tagging.
Enables standardized foundations: Network landing zones, compartments, and baseline policies can be deployed as code.

When teams should choose it

Choose Resource Manager when you: – Use Terraform (or want to adopt it) for OCI – Need managed execution and state – Want auditability of changes – Need repeatable multi-environment deployments – Want to integrate IaC into change-control processes

When teams should not choose it

Avoid or reconsider Resource Manager when: – You require Terraform features or third-party workflows that are not supported in Resource Manager’s execution environment (custom binaries, plugins, or very specific runner requirements) – You already have a mature Terraform platform (Terraform Cloud/Enterprise, Spacelift, Atlantis) and Resource Manager would duplicate capabilities – Your workloads are primarily non-OCI or multi-cloud where a single cross-cloud Terraform platform is preferred – You need fine-grained CI/CD orchestration beyond what Resource Manager provides (in that case, you might run Terraform in your CI and use OCI APIs directly)

4. Where is Resource Manager used?

Industries

Financial services (controlled infrastructure changes, auditability)
SaaS and technology companies (repeatable environments, rapid iteration)
Healthcare and public sector (governance and traceability)
Telecommunications and media (infrastructure scale and standardization)
Education (labs and training environments)

Team types

Platform engineering teams building OCI landing zones
DevOps/SRE teams standardizing infrastructure deployment
Security engineering teams enforcing baseline controls as code
Application teams provisioning app-specific infrastructure via approved stacks
Cloud centers of excellence (CCoE) setting organizational standards

Workloads

Networking foundations (VCNs, subnets, gateways, route tables, security lists/NSGs)
Compute provisioning patterns (instances, instance configurations/pools)
Managed services foundations (Object Storage buckets, logging sinks, etc.)
Container platforms (OKE clusters and node pools—verify supported patterns and permissions)
Multi-tier application environments (network + compute + database + load balancer)

Architectures

Multi-compartment enterprise environments
Hub-and-spoke networking
Shared services + workload compartments
Blue/green or ephemeral environments for testing
Infrastructure modules as reusable building blocks

Production vs dev/test usage

Dev/Test: Great for rapid, repeatable environment creation and teardown (cost control).
Production: Valuable for controlled change management, drift management, standardized updates, and traceability—provided IAM policies and operational processes are well designed.

5. Top Use Cases and Scenarios

Below are realistic scenarios where Resource Manager is commonly a strong fit.

1) Landing zone provisioning (compartments + baseline networking)

Problem: Manual creation of compartments, VCNs, and baseline security is inconsistent across teams.
Why Resource Manager fits: A single audited stack defines the organization’s baseline.
Example: Platform team deploys a “core network + shared services” stack to bootstrap new environments.

2) Standard VCN patterns (hub-and-spoke)

Problem: Network deployments differ by engineer and cause routing/security issues.
Why it fits: Terraform modules encode repeatable hub-and-spoke patterns.
Example: Create a hub VCN with centralized egress and multiple spoke VCNs per application.

3) Ephemeral test environments

Problem: Test environments are expensive and hard to clean up.
Why it fits: Destroy jobs make teardown consistent and auditable.
Example: Spin up a full environment for a sprint, then destroy it after testing.

4) Self-service infrastructure with guardrails

Problem: Teams need faster provisioning but security wants control.
Why it fits: Operators publish approved stacks; app teams run jobs with limited variables.
Example: A “web app baseline” stack provisions approved network/security resources.

5) Resource Discovery for brownfield IaC adoption

Problem: Existing resources were created manually; converting to Terraform is time-consuming.
Why it fits: Resource Discovery can generate Terraform configuration from existing OCI resources (scope varies).
Example: Generate Terraform for an existing VCN and subnets to start managing changes safely.

6) Standardized tagging enforcement

Problem: Cost allocation and governance tagging is inconsistent.
Why it fits: Modules enforce tag namespaces and required tag keys.
Example: Every created resource includes defined tags for cost center, owner, and environment.

7) Controlled change workflows (plan first, apply later)

Problem: Changes go straight to production without visibility.
Why it fits: Plan jobs show intended changes before apply.
Example: Plan is reviewed during a change window, then apply is executed after approval.

8) Multi-environment promotion with variable sets

Problem: Same code needs different values across dev/test/prod.
Why it fits: Stack variables (and variable sets if used) can separate configuration from code.
Example: One VCN module used across environments with different CIDRs and naming conventions.

9) Centralized state management for collaboration

Problem: Teams overwrite state or apply concurrently.
Why it fits: Managed state and locking reduces concurrency issues.
Example: Multiple engineers work on a platform stack without corrupting state.

10) Private infrastructure provisioning via private endpoints

Problem: Terraform runner cannot reach private endpoints (private subnets, private APIs) when run externally.
Why it fits: Resource Manager can be configured to operate with private connectivity patterns (verify “private endpoint” feature availability and setup).
Example: Apply changes to private subnets and internal resources without exposing them publicly.

11) Audit-ready infrastructure change history

Problem: Compliance requires a traceable record of changes and who executed them.
Why it fits: Stack/job history plus OCI Audit logs provide traceability.
Example: Produce an audit trail of production network changes with timestamps and identities.

12) Standard module catalog for teams

Problem: Engineers copy/paste Terraform and create drift between projects.
Why it fits: Teams can standardize on approved modules and stack templates.
Example: Publish module-based stacks for “database baseline,” “OKE baseline,” and “logging baseline.”

6. Core Features

Feature availability can vary by region, tenancy settings, and current OCI releases. Verify the latest capabilities in the official docs: https://docs.oracle.com/en-us/iaas/Content/ResourceManager/home.htm

6.1 Stacks (Terraform configurations as managed objects)

What it does: Stores your Terraform configuration, variables, and metadata in a manageable OCI object.
Why it matters: Enables repeatable deployments and a clear operational unit for infrastructure.
Practical benefit: Makes IaC manageable for teams through the OCI console, APIs, and CLI.
Caveats: Stacks are region-scoped; keep track of which region the stack lives in.

6.2 Jobs (Plan / Apply / Destroy execution)

What it does: Runs Terraform commands in OCI-managed execution context.
Why it matters: Standardizes execution with consistent logging and state handling.
Practical benefit: Operators can separate planning from applying changes.
Caveats: Job runtime and concurrency are subject to service limits; check limits in OCI.

6.3 Managed Terraform state and locking

What it does: Maintains Terraform state associated with a stack and locks during execution to prevent conflicts.
Why it matters: State is critical for safe updates and drift control.
Practical benefit: Team collaboration without building your own remote backend.
Caveats: Understand how state is stored, exported, and recovered for incident scenarios (verify export/import options in your environment).

6.4 Variable management (inputs, defaults, sensitive values)

What it does: Lets you define and supply Terraform variables at stack creation and/or job run.
Why it matters: Separates code from environment-specific settings.
Practical benefit: One configuration supports multiple environments.
Caveats: Treat secrets carefully—prefer OCI Vault patterns rather than plaintext variables when possible (details in Security section).

6.5 Configuration sources (upload, Object Storage, Git)

What it does: Lets you source Terraform code from supported locations (commonly zip upload; sometimes Object Storage and Git integrations).
Why it matters: Enables version control and automation-friendly workflows.
Practical benefit: Aligns IaC with standard SDLC practices.
Caveats: Supported Git providers and authentication methods can change—verify in the console and docs.

6.6 Resource Discovery (generate Terraform from existing resources)

What it does: Generates Terraform configuration representing existing OCI resources.
Why it matters: Helps adopt IaC for brownfield environments.
Practical benefit: Faster starting point than writing everything from scratch.
Caveats: Coverage varies by resource type; generated code often needs cleanup, module refactoring, and testing.

6.7 Private connectivity patterns (private endpoints)

What it does: Allows Resource Manager executions to access resources that require private network paths (feature name and configuration steps vary).
Why it matters: Supports secure, private-only architectures.
Practical benefit: You can manage private subnets/resources without exposing management endpoints publicly.
Caveats: Requires network and IAM setup; verify prerequisites, supported regions, and limitations in official docs.

6.8 Outputs and job logs

What it does: Captures Terraform outputs and provides job logs for each run.
Why it matters: Outputs are often used to connect infrastructure layers (for example, subnet OCIDs).
Practical benefit: Faster debugging and visibility into what was created/changed.
Caveats: Logs may include sensitive details if Terraform scripts print them—be careful.

6.9 Integration with OCI IAM, compartments, and tagging

What it does: Uses OCI identity policies to control who can manage stacks/jobs and what resources can be created in target compartments.
Why it matters: Enforces organizational boundaries and least privilege.
Practical benefit: Central governance for IaC.
Caveats: Misconfigured policies are the #1 source of “NotAuthorizedOrNotFound” errors.

7. Architecture and How It Works

7.1 High-level architecture

At a high level, Resource Manager works like this:

You create a stack (Terraform configuration + variables) in an OCI region.
You run a job (plan/apply/destroy).
Resource Manager starts an OCI-managed Terraform runner.
The runner calls OCI service APIs (Networking, Compute, etc.) using OCI-authenticated access.
Terraform state is updated and stored/locked by Resource Manager.
Logs and outputs are attached to the job/stack for visibility.

7.2 Request/control flow

Control plane: OCI console/CLI/API requests to create stacks and start jobs.
Execution: Terraform runner executes plan/apply against OCI API endpoints.
State: Stored and locked by Resource Manager for each stack.
Observability: Job logs, stack history, and OCI Audit logs help track actions.

7.3 Integrations with related services

Common integrations/pairings in OCI include:

IAM (Identity & Access Management): policies, groups, compartments for authorization.
Networking (VCN): resources targeted by Terraform and optional private connectivity for runners.
Audit: records API calls related to stack/job operations and the resources they create.
Logging/Events/Notifications: may be used for operational alerts around job results (verify current event types and integrations in official docs).
Object Storage: sometimes used as a configuration source and/or for artifacts (verify your chosen workflow).

7.4 Dependency services

Resource Manager depends on: – OCI IAM for authentication/authorization – OCI service APIs for the resources you provision – Terraform provider for OCI (oracle/oci): https://registry.terraform.io/providers/oracle/oci/latest/docs

7.5 Security/authentication model (practical view)

Resource Manager executes Terraform in OCI. The OCI Terraform provider supports OCI-native auth patterns (including resource principals). In Resource Manager stacks, provider configuration commonly avoids static API keys.

A typical provider block for Resource Manager uses resource principals:

provider "oci" {
  region = var.region
  auth   = "ResourcePrincipal"
}

Important: The effective permissions are determined by OCI IAM policies. In many organizations, you grant the Resource Manager service principal the ability to manage specific resource families in target compartments. Verify the latest recommended policy patterns in official docs before implementing.

7.6 Networking model

Resource Manager runner reaches OCI public service endpoints by default.
For private-only architectures, use private connectivity features (for example, a Resource Manager private endpoint) when supported and configured. This can allow Terraform to operate without requiring public access to private resources.

7.7 Monitoring/logging/governance considerations

Treat stack/job history as part of your change record.
Use OCI Audit to correlate who started a job and which APIs were called.
Use tags to attribute and track resources created by stacks.
Consider naming standards that include environment and stack name.

7.8 Architecture diagrams (Mermaid)

Simple architecture (learning/lab)

flowchart LR
  U[Engineer / Operator] -->|Create Stack & Run Job| RM[OCI Resource Manager]
  RM -->|Terraform Plan/Apply| TF[Managed Terraform Runner]
  TF -->|OCI API Calls| OCI[OCI Services\n(VCN, Compute, Storage...)]
  TF -->|Read/Write| STATE[Managed Terraform State]
  RM --> LOGS[Job Logs & Outputs]

Production-style architecture (team workflow)

flowchart TB
  Git[Git Repository\n(Terraform modules & stacks)] --> RM[OCI Resource Manager Stack\n(Region-scoped)]
  RM --> Jobs[Jobs\nPlan/Apply/Destroy]
  Jobs --> Runner[Managed Terraform Runner]
  Runner --> APIs[OCI APIs\nNetworking/Compute/DB/etc.]
  Runner --> State[State + Locking\n(Managed by Resource Manager)]

  subgraph Governance
    IAM[OCI IAM\nGroups, Policies, Compartments]
    Audit[OCI Audit]
    Tags[Tagging Standards]
  end

  IAM --> RM
  APIs --> Audit
  Tags --> APIs

  subgraph Operations
    Obs[Logging / Events / Notifications\n(verify integration details)]
  end

  RM --> Obs

8. Prerequisites

Tenancy and account requirements

An active Oracle Cloud (OCI) tenancy
Access to an OCI region where Resource Manager is available (Resource Manager is broadly available, but verify your region)

Permissions / IAM roles

You need two categories of permissions:

Permissions to use Resource Manager (manage stacks and jobs)
Permissions for what Terraform will create (for example, manage VCN resources in a compartment)

OCI IAM policies are precise. Typical policy statements involve allowing a group to manage Resource Manager resources and allowing Resource Manager (service principal) to manage target resources.

Do not copy/paste policies blindly. Confirm exact policy syntax and best practice patterns in official docs (and your org’s security guidance). Start here:
https://docs.oracle.com/en-us/iaas/Content/ResourceManager/home.htm

Common symptoms of missing IAM permissions: – NotAuthorizedOrNotFound errors during plan/apply – Terraform provider fails to read compartments or create networking objects

Billing requirements

Resource Manager itself is often listed as no additional charge (verify in official pricing/docs).
You are billed for the OCI resources created by Terraform (networking, compute, database, load balancers, etc.).

Tools needed

For the hands-on lab you can use only the OCI Console.

Optional tools: – OCI CLI: https://docs.oracle.com/en-us/iaas/Content/API/Concepts/cliconcepts.htm – Terraform CLI (for local validation and linting): https://developer.hashicorp.com/terraform – Git (optional)

Region availability

Confirm Resource Manager availability in your chosen region in the OCI Console.
If using features like private endpoints, verify regional support.

Quotas / limits

Resource Manager is subject to service limits (for example, number of stacks, concurrent jobs, configuration size, job runtime). Check: – OCI Console → Limits, Quotas and Usage – Resource Manager documentation (Service Limits section, if present)

Prerequisite services

For this tutorial lab: – OCI Networking service (VCN, subnet) in a compartment where you have permission to create networking resources.

9. Pricing / Cost

Pricing model (accurate framing)

Resource Manager is generally positioned as a managed service with no additional charge, while you pay for the underlying OCI resources it provisions. However, pricing and entitlement details can change by region/contract—verify in official OCI documentation and pricing pages.

Start with: – OCI documentation home for Resource Manager: https://docs.oracle.com/en-us/iaas/Content/ResourceManager/home.htm – Oracle Cloud price list: https://www.oracle.com/cloud/price-list/ – Oracle Cloud cost estimator (official): https://www.oracle.com/cloud/costestimator.html (verify URL if it changes)

Pricing dimensions

You typically don’t pay “per stack” or “per job” as a standalone meter (verify current policy). Instead, cost comes from: – Resources created: compute instances, load balancers, databases, NAT gateways, etc. – Storage: block volumes, Object Storage buckets, backups – Networking: egress bandwidth, load balancer bandwidth, inter-region traffic – Logging/monitoring: depending on OCI Logging usage and retention

Free tier considerations

OCI has an Always Free tier for certain services in certain regions. Resource Manager can be used to provision Always Free eligible resources, but: – Always Free eligibility varies by region and service – Misconfiguration can accidentally provision paid resources (for example, non-Always Free shapes)

Always verify Always Free eligibility in official docs before running apply in production-like stacks.

Cost drivers (most common)

Compute shape and count (if your stack creates instances)
Load balancers (often a significant cost)
Databases (Autonomous Database vs DB Systems)
Outbound data transfer (internet egress and cross-region)
Log retention and ingestion if you centralize logs

Hidden or indirect costs

Destroy is not automatic: If you forget to run a destroy job, resources continue accruing cost.
Non-obvious metered components: Public IPs, NAT gateways, egress, and backups can add up depending on design.
Multi-region stacks: Cross-region traffic and duplicated resources raise costs.

Network/data transfer implications

Resource Manager execution itself doesn’t typically generate large egress, but the infrastructure you create might: – Internet-facing load balancers and downloads create egress – Cross-region replication and inter-region connectivity can be billed

How to optimize cost

Use plan jobs and review changes before applying.
Build “lab-safe” variables with defaults that create minimal resources.
Use tagging to identify stack-created resources and enforce cleanup policies.
Prefer ephemeral environments and scheduled teardown processes (Resource Manager doesn’t automatically schedule teardown by default; integrate with operational processes/tools if needed).

Example low-cost starter estimate (model, not numbers)

A minimal Resource Manager lab that creates only: – 1 VCN + 1 subnet + route table/security list updates
is typically low cost (often networking objects alone are not billed the same way as compute), but pricing varies—verify networking pricing in OCI price list.

Example production cost considerations (model, not numbers)

A production stack might include: – VCNs, subnets, gateways, DRGs – Load balancers – Multiple compute instances – Databases and backups – Logging, monitoring, and alarms

In production, the cost of Resource Manager jobs is usually negligible compared to the cost of managed services and compute, but the operational impact of IaC mistakes can be expensive. Use guardrails (IAM, variable validation, approvals outside the tool, and strong reviews).

10. Step-by-Step Hands-On Tutorial

Objective

Use Oracle Cloud Resource Manager to deploy a small, safe, low-cost networking foundation using Terraform:

Create a VCN
Create a Subnet
Output the OCIDs for validation
Then destroy everything cleanly

This lab avoids compute instances to keep cost and risk low.

Lab Overview

You will: 1. Prepare a small Terraform configuration locally and zip it. 2. Create a Resource Manager stack from the zip file. 3. Run a Plan job (preview changes). 4. Run an Apply job (create VCN + subnet). 5. Validate in the OCI Console. 6. Run a Destroy job and delete the stack.

Step 1: Prepare the Terraform configuration (zip archive)

Create a new folder on your workstation:

Option A: macOS / Linux

mkdir oci-rm-vcn-lab
cd oci-rm-vcn-lab

Option B: Windows PowerShell

mkdir oci-rm-vcn-lab
cd oci-rm-vcn-lab

Create main.tf:

terraform {
  required_version = ">= 1.0.0"

  required_providers {
    oci = {
      source  = "oracle/oci"
      version = ">= 5.0.0"
    }
  }
}

provider "oci" {
  region = var.region
  auth   = "ResourcePrincipal"
}

resource "oci_core_vcn" "lab_vcn" {
  compartment_id = var.compartment_ocid
  cidr_block     = var.vcn_cidr
  display_name   = var.vcn_display_name
  dns_label      = var.vcn_dns_label
}

resource "oci_core_subnet" "lab_subnet" {
  compartment_id = var.compartment_ocid
  vcn_id         = oci_core_vcn.lab_vcn.id
  cidr_block     = var.subnet_cidr
  display_name   = var.subnet_display_name
  dns_label      = var.subnet_dns_label

  prohibit_public_ip_on_vnic = true
}

Create variables.tf:

variable "region" {
  description = "OCI region where the stack/job runs (example: us-ashburn-1)."
  type        = string
}

variable "compartment_ocid" {
  description = "Target compartment OCID for the VCN and subnet."
  type        = string
}

variable "vcn_cidr" {
  description = "VCN CIDR block."
  type        = string
  default     = "10.10.0.0/16"
}

variable "subnet_cidr" {
  description = "Subnet CIDR block inside the VCN."
  type        = string
  default     = "10.10.10.0/24"
}

variable "vcn_display_name" {
  type    = string
  default = "rm-lab-vcn"
}

variable "subnet_display_name" {
  type    = string
  default = "rm-lab-subnet"
}

variable "vcn_dns_label" {
  description = "DNS label must be unique in the VCN scope and follow OCI DNS label rules."
  type        = string
  default     = "rmlabvcn"
}

variable "subnet_dns_label" {
  description = "DNS label must be unique in the VCN scope and follow OCI DNS label rules."
  type        = string
  default     = "rmlabsubnet"
}

Create outputs.tf:

output "vcn_id" {
  value       = oci_core_vcn.lab_vcn.id
  description = "OCID of the created VCN."
}

output "subnet_id" {
  value       = oci_core_subnet.lab_subnet.id
  description = "OCID of the created subnet."
}

Now zip the folder contents.

Option A: macOS / Linux

cd ..
zip -r oci-rm-vcn-lab.zip oci-rm-vcn-lab

Option B: Windows PowerShell

cd ..
Compress-Archive -Path .\oci-rm-vcn-lab -DestinationPath .\oci-rm-vcn-lab.zip -Force

Expected outcome: You have a file named oci-rm-vcn-lab.zip ready to upload to Resource Manager.

Step 2: Confirm IAM permissions (avoid job failures)

Before you create the stack, confirm:

You have permission to create and manage stacks/jobs in the compartment you’ll use.
The job execution identity has permission to create VCN and subnet resources.

In OCI, these permissions are governed by IAM policies. The exact recommended policy statements can vary.

Action: Review Resource Manager IAM documentation and ensure policies are in place:
https://docs.oracle.com/en-us/iaas/Content/ResourceManager/home.htm

Expected outcome: You can create a stack and run apply without authorization errors.

Step 3: Create a Resource Manager stack (OCI Console)

Sign in to the OCI Console.
Select the correct region (top-right).
Navigate to Resource Manager (menu location can vary; commonly under Developer Services or Governance/Administration).
Go to Stacks → Create stack.
Choose a configuration source: – Select .Zip file upload (wording may vary) – Upload oci-rm-vcn-lab.zip
Choose the compartment where the stack object will live.
Choose a supported Terraform version (leave default if unsure; the available list is controlled by OCI).
Provide a stack name, for example: rm-vcn-lab-stack.
In variables: – region: your region identifier (example format: us-ashburn-1 — use the exact region key from OCI) – compartment_ocid: OCID of the compartment where you want the VCN and subnet created – Optionally adjust CIDRs and names

Create the stack.

Expected outcome: The stack appears in the Stacks list with your configuration uploaded.

Step 4: Run a Plan job (preview changes)

Open your new stack.
Click Plan (or Create job → Plan).
Keep defaults unless you have a specific job configuration.
Start the job and wait for it to finish.

After completion, open the job and review: – Planned changes summary – Logs – Any errors (IAM, invalid CIDR, invalid DNS label)

Expected outcome: The plan shows Terraform will create: – 1 VCN – 1 subnet

Step 5: Run an Apply job (create the VCN and subnet)

From the same stack, click Apply (or Create job → Apply).
Start the job.
Wait for job completion.

When the job completes, review: – Job status: Succeeded – Logs show resource creation – Stack Outputs show vcn_id and subnet_id

Expected outcome: OCI resources are created and Terraform state is updated.

Step 6: Validate the resources in OCI

In OCI Console:

Go to Networking → Virtual Cloud Networks.
Select your compartment.
Confirm a VCN named rm-lab-vcn exists.
Click the VCN → Subnets.
Confirm a subnet named rm-lab-subnet exists.
Confirm the subnet has “Prohibit public IP on VNIC” enabled.

Expected outcome: You can see and inspect the VCN and subnet created by Resource Manager.

Validation

Use these checks:

Stack job history shows:
Plan job succeeded
Apply job succeeded
Stack outputs show valid OCIDs for:
vcn_id
subnet_id
OCI Networking console shows the VCN and subnet exist in the intended compartment/region

Troubleshooting

Common issues and fixes:

NotAuthorizedOrNotFound during Plan/Apply – Cause: missing IAM permissions for Resource Manager or for the target resource family (VCN/subnet). – Fix: Review IAM policies for the user/group and for Resource Manager execution identity. Confirm the correct compartment.
Invalid DNS label error – Cause: dns_label values must match OCI rules (lowercase, alphanumeric, length limits). – Fix: Change vcn_dns_label and subnet_dns_label to valid values.
CIDR conflicts – Cause: Overlapping CIDRs with existing networks, or invalid CIDR format. – Fix: Change vcn_cidr and subnet_cidr values.
Region mismatch – Cause: Stack is created in one region, but variable region points to another. – Fix: Set region variable to the region where the stack/job executes, unless you are intentionally targeting other regions (advanced pattern).
Provider/auth issues – Cause: Terraform provider auth not configured for Resource Manager execution. – Fix: Ensure provider uses auth = "ResourcePrincipal" for Resource Manager runs (and verify with official docs/provider docs).

Terraform provider docs (official registry):
https://registry.terraform.io/providers/oracle/oci/latest/docs

Cleanup

To avoid ongoing cost and clutter, destroy what you created.

Open the stack in Resource Manager.
Create a Destroy job.
Run the job and wait for success.
Verify in Networking console that the VCN and subnet are deleted.
Delete the stack (optional but recommended for lab hygiene).

Expected outcome: All lab-created resources are removed and no longer billable.

11. Best Practices

Architecture best practices

Use modules to standardize patterns (VCN module, IAM module, logging module).
Separate “foundation” stacks (network, compartments, shared services) from “application” stacks.
Keep stacks small and focused; prefer multiple stacks over one massive stack.

IAM/security best practices

Enforce least privilege:
Limit who can manage stacks/jobs
Limit what the execution identity can create in each compartment
Use separate compartments for dev/test/prod with separate policies.
Prefer Resource Manager’s OCI-native auth patterns; avoid embedding API keys.

Cost best practices

Always run Plan first.
Use tags like:
environment=dev
managed-by=resource-manager
stack=<stack-name>
Include cost-related guardrails in code (for example, variable defaults that create minimal resources).
Provide a documented cleanup process (destroy job) for every stack.

Performance best practices

Keep Terraform configurations efficient:
Avoid unnecessary data sources that enumerate large inventories
Minimize repeated reads
Pin provider versions to reduce unexpected changes (while maintaining an upgrade path).

Reliability best practices

Treat Terraform state as critical:
Avoid manual edits to resources created by Terraform (or accept that drift may occur)
Document recovery: state download, stack recreation, etc. (verify supported workflows)
Use consistent naming and tagging to identify resources and owners.

Operations best practices

Store stack configurations in version control and use immutable releases/tags for production deployments.
Use peer review for Terraform changes.
Establish change windows and apply procedures for production stacks.
Standardize variable naming and defaults.

Governance/tagging/naming best practices

Adopt naming conventions such as:
<env>-<app>-<region>-<resource>
Use defined tags for cost and compliance, and freeform tags for convenience.
Document ownership and on-call rotation for stacks that manage production resources.

12. Security Considerations

Identity and access model

Resource Manager access is governed by OCI IAM:
Who can create/manage stacks and jobs
Which compartments and resources can be managed by job execution
Carefully design policies for:
Platform team (full control)
App teams (restricted control; run jobs only on approved stacks)

Recommendation: Centralize policy review with security/platform teams and validate using least-privilege principles.

Encryption

OCI services generally encrypt data at rest by default, but verify specifics for: – Terraform state storage in Resource Manager – Job logs retention and handling

Check official docs for encryption behavior:
https://docs.oracle.com/en-us/iaas/Content/ResourceManager/home.htm

Network exposure

By default, Terraform runner interactions with OCI APIs use OCI endpoints.
For private-only architectures:
Use private connectivity features (private endpoints) where supported
Avoid exposing private subnets/resources just to make provisioning easier

Secrets handling

Common safe patterns: – Avoid putting secrets directly in Terraform variables stored in stacks. – Prefer retrieving secrets at runtime from OCI Vault (for example, using data sources or external mechanisms supported by your workflow). – Treat job logs as sensitive—avoid printing secrets.

Note: Exact best practice patterns depend on provider support and your security posture. Validate with OCI Vault docs and Terraform provider capabilities.

Audit/logging

Use OCI Audit to track who invoked stack/job operations and resulting API actions.
Review job logs for operational troubleshooting, but enforce access controls to logs.

Compliance considerations

Resource Manager helps compliance by: – Standardizing changes as code – Preserving job history and logs – Enabling traceability and repeatability

But compliance still requires: – Strong IAM boundaries – Proper tagging and ownership – Documented change processes

Common security mistakes

Overly broad IAM policies (for example, “manage all-resources in tenancy”)
Storing secrets in plaintext variables
Running production apply jobs from personal accounts without process controls
Allowing app teams to modify foundational network stacks without guardrails

Secure deployment recommendations

Use separate compartments and policies per environment.
Keep production stacks in a controlled compartment with limited operators.
Require code review and approvals outside the tool (since IaC governance is often process + tooling).
Use tagging standards and resource naming to identify stack ownership.

13. Limitations and Gotchas

Always verify current limits and behavior in official docs and in the OCI Console for your region/tenancy.

Known limitations / operational realities

Service limits exist (stacks, jobs, job concurrency, configuration size, runtime).
Terraform version support is controlled by OCI; you must use supported versions.
Some Terraform workflows may differ from local Terraform (execution environment constraints).

Quotas

Resource Manager and target services (Networking, Compute, etc.) have quotas.
If apply fails with limit errors, check “Limits, Quotas and Usage” in OCI.

Regional constraints

Stacks are typically region-scoped.
Features like private endpoints may have regional availability constraints.

Pricing surprises

Resource Manager might be no extra cost, but what it creates can be expensive.
Accidental creation of load balancers or large compute shapes can cause unexpected spend.

Compatibility issues

Provider version mismatches can break workflows.
Generated code from Resource Discovery may not be production-ready without refactoring.

Operational gotchas

Running apply without reviewing plan can accidentally delete/replace resources.
Manual changes (outside Terraform) cause drift.
Destroy may fail if resources have dependencies or were modified manually.

Migration challenges

Importing brownfield resources into Terraform state is non-trivial.
Resource Discovery helps, but it’s not a one-click production migration.

Vendor-specific nuances

OCI IAM policy model is powerful but strict; many initial failures are IAM-related.
OCI uses OCIDs heavily; incorrect OCIDs cause confusing “not found” errors.

14. Comparison with Alternatives

Resource Manager is Terraform-based. Alternatives include OCI-native services, other cloud IaC services, and third-party Terraform platforms.

Comparison table

Option	Best For	Strengths	Weaknesses	When to Choose
OCI Resource Manager	OCI-first IaC with managed Terraform execution	Managed runs/state/locking; OCI IAM integration; stack/job history	Execution environment constraints; feature set differs from full Terraform platforms	You want Terraform on OCI with managed operations and governance
Terraform CLI + your own remote backend	Small teams or custom pipelines	Full control; easiest to start	You must manage state, locking, credentials, runners	You need maximum flexibility and already have tooling
Terraform Cloud / Terraform Enterprise	Enterprise Terraform at scale (multi-cloud)	Policy-as-code, VCS integration, run tasks, org governance	Additional cost and platform complexity	You need advanced Terraform governance across clouds
Atlantis (self-managed)	GitOps Terraform with PR-based applies	Strong GitOps workflow; open source	You operate it; secrets/IAM are on you	You want PR-driven Terraform with self-hosted control
Spacelift / env0 / similar	Terraform platform as a service	Advanced workflows, policies, drift detection (varies)	Cost; external SaaS considerations	You want a full Terraform platform without self-hosting
AWS CloudFormation	AWS-only IaC	Deep AWS integration	AWS-only; different language/model	You are primarily on AWS
Azure ARM/Bicep	Azure-only IaC	Azure-native and supported	Azure-only; different language/model	You are primarily on Azure

Nearest services in OCI: – OCI DevOps (for CI/CD pipelines) can complement Resource Manager; it is not the same thing as a managed Terraform stack runner. If you need end-to-end CI/CD, evaluate DevOps plus Resource Manager patterns (verify official integration options). – OCI Logging / Monitoring / Events / Notifications complement Resource Manager for operational visibility.

15. Real-World Example

Enterprise example: regulated financial services landing zone

Problem: A bank is moving multiple applications to Oracle Cloud. Security mandates standardized networking, strict compartment boundaries, mandatory tagging, and audited change history.

Proposed architecture: – Compartment hierarchy: – SharedServices – Network – Prod, NonProd workload compartments – Resource Manager stacks: – foundation-network: hub VCN, DRG, shared route policies – security-baseline: logging, tag namespaces, (and other baseline controls where applicable) – app-vcn: per-app spoke VCNs and subnets – IAM: – Platform team manages foundation stacks – Application teams can run approved app stacks with limited variables – Audit: – OCI Audit used to record stack/job actions and resource API calls

Why Resource Manager was chosen: – Managed Terraform execution reduces workstation-based provisioning risk – Job logs and stack history improve traceability – State locking reduces concurrency incidents

Expected outcomes: – Faster onboarding of new apps with consistent patterns – Reduced audit findings due to standardized deployment and change records – Lower operational risk and fewer network misconfigurations

Startup/small-team example: repeatable dev/test environments

Problem: A startup needs a repeatable dev environment for each feature branch and wants reliable cleanup to control cloud spend.

Proposed architecture: – One “app environment” stack that creates: – VCN + subnets – minimal supporting services – Variables drive: – environment name – CIDRs – tags – Operational process: – Plan + Apply on demand – Destroy after testing or merge

Why Resource Manager was chosen: – Team doesn’t want to run/manage Terraform backends and credentials – Console-driven jobs are approachable for mixed-experience teams – Easy to destroy environments reliably

Expected outcomes: – Faster environment creation – More predictable deployments – Better cost control through consistent teardown

16. FAQ

1) Is Resource Manager just “Terraform in the cloud”?
It’s OCI’s managed service for executing Terraform configurations as stacks and jobs, including managed state/locking and integration with OCI IAM.

2) Do I need Terraform installed locally to use Resource Manager?
Not necessarily. You can create stacks and run jobs entirely from the OCI Console. Local Terraform is still useful for validation, linting, and module development.

3) Does Resource Manager support all Terraform providers?
Resource Manager is primarily designed for the OCI Terraform provider. Support for other providers may be possible in some cases but depends on the execution environment and allowed provider downloads. Verify current support in official docs.

4) How does authentication work for Terraform in Resource Manager?
Commonly via OCI-native authentication (resource principals). Provider configuration often uses auth = "ResourcePrincipal". Verify the current recommended approach in official docs and provider docs.

5) Where is Terraform state stored?
Resource Manager manages state for stacks. Exact storage and export/import behavior should be confirmed in official docs and your console.

6) Can multiple engineers run apply at the same time?
Resource Manager typically uses state locking to prevent concurrent applies on the same stack. Concurrency limits also apply.

7) What’s the difference between a stack and a job?
A stack is the configuration and its metadata; a job is an execution (plan/apply/destroy) of that stack.

8) Can Resource Manager deploy to multiple compartments?
A stack can be parameterized to target different compartments via variables (for example, compartment OCID). IAM policies must permit those actions.

9) Can Resource Manager manage resources across multiple regions?
Terraform can be configured to target other regions, but stacks are region-scoped and cross-region management adds complexity. Treat as advanced and verify with official guidance.

10) Does Resource Manager support drift detection?
Some OCI IaC platforms offer drift-related features. If drift detection is available in your Resource Manager version, use it; otherwise use Terraform plan and operational checks. Verify in official docs for current feature availability.

11) How do I prevent accidental production changes?
Use compartment isolation, least-privilege IAM, separate stacks per environment, mandatory plan reviews, and change management processes.

12) Can I use GitHub/GitLab with Resource Manager?
Some tenancies can use Git-based stack sources. Supported providers and authentication methods vary—verify in the console and docs.

13) What happens if an apply job fails halfway?
Terraform will record partial progress in state if state updates occurred. You may need to re-run apply or resolve errors. Review logs carefully and validate actual OCI resources created.

14) Is Resource Manager part of Observability and Management?
Resource Manager is primarily IaC/governance/administration, but it directly supports management operations and integrates with audit/logging patterns commonly grouped under Observability and Management.

15) How do I clean up everything safely?
Run a Destroy job on the stack and verify resource deletion in the relevant OCI service consoles. Then delete the stack if no longer needed.

16) Can I import existing resources into Resource Manager-managed Terraform state?
Terraform supports import workflows; Resource Manager may support some state upload/import patterns and Resource Discovery. Verify the exact supported workflow in official docs for your version.

17) What’s the best first resource to manage with Resource Manager?
Start with low-risk, low-cost resources: VCNs/subnets, Object Storage buckets (with safe policies), or small foundational components—then expand.

17. Top Online Resources to Learn Resource Manager

Resource Type	Name	Why It Is Useful
Official documentation	OCI Resource Manager docs	Primary source for concepts, stack/job workflows, IAM notes, and feature updates: https://docs.oracle.com/en-us/iaas/Content/ResourceManager/home.htm
Official Terraform provider docs	OCI Terraform Provider (registry)	Provider resources/data sources and authentication patterns: https://registry.terraform.io/providers/oracle/oci/latest/docs
Official pricing	Oracle Cloud Price List	Verify pricing for resources you provision: https://www.oracle.com/cloud/price-list/
Official cost estimation	Oracle Cloud Cost Estimator	Model costs for stacks that create compute/LB/DB, etc.: https://www.oracle.com/cloud/costestimator.html (verify if URL changes)
Architecture references	Oracle Cloud Architecture Center	Reference architectures and design patterns to turn into Terraform modules: https://www.oracle.com/cloud/architecture/ and https://docs.oracle.com/en/solutions/
Hands-on labs	Oracle LiveLabs	Guided labs (search for Resource Manager/Terraform/OCI): https://livelabs.oracle.com/
Official GitHub (provider)	terraform-provider-oci	Source, examples, and changelog context for OCI provider: https://github.com/oracle/terraform-provider-oci
Official GitHub (modules)	oracle-terraform-modules	Reusable Terraform modules for OCI patterns: https://github.com/oracle-terraform-modules
Official CLI docs	OCI CLI documentation	Useful for automation around stacks/jobs if needed: https://docs.oracle.com/en-us/iaas/Content/API/Concepts/cliconcepts.htm
Community learning	Terraform documentation	Core Terraform concepts (plan/apply/state/modules): https://developer.hashicorp.com/terraform

18. Training and Certification Providers

Institute	Suitable Audience	Likely Learning Focus	Mode	Website URL
DevOpsSchool.com	DevOps engineers, cloud engineers, SREs	DevOps practices, IaC fundamentals, cloud tooling	Check website	https://www.devopsschool.com/
ScmGalaxy.com	Beginners to intermediate DevOps learners	SCM + DevOps tooling, automation foundations	Check website	https://www.scmgalaxy.com/
CLoudOpsNow.in	Cloud operations and platform teams	Cloud ops practices, operational readiness	Check website	https://www.cloudopsnow.in/
SreSchool.com	SREs, operations engineers	Reliability engineering, monitoring/operations practices	Check website	https://www.sreschool.com/
AiOpsSchool.com	Ops teams exploring AIOps	AIOps concepts, automation and operations analytics	Check website	https://www.aiopsschool.com/

19. Top Trainers

Platform/Site	Likely Specialization	Suitable Audience	Website URL
RajeshKumar.xyz	DevOps/cloud training content (verify offerings)	Beginners to practicing engineers	https://rajeshkumar.xyz/
devopstrainer.in	DevOps training and mentoring (verify offerings)	DevOps engineers and students	https://www.devopstrainer.in/
devopsfreelancer.com	DevOps freelancing/training resources (verify offerings)	Teams needing short-term help and guidance	https://www.devopsfreelancer.com/
devopssupport.in	DevOps support and learning resources (verify offerings)	Engineers needing implementation support	https://www.devopssupport.in/

20. Top Consulting Companies

Company Name	Likely Service Area	Where They May Help	Consulting Use Case Examples	Website URL
cotocus.com	Cloud/DevOps consulting (verify exact portfolio)	Architecture, automation, IaC adoption	OCI landing zone as code; Terraform module standardization; CI/CD + IaC workflows	https://cotocus.com/
DevOpsSchool.com	DevOps consulting and enablement	Training + implementation support	Build Resource Manager stack standards; implement tagging/governance; runbooks for plan/apply/destroy	https://www.devopsschool.com/
DEVOPSCONSULTING.IN	DevOps consulting (verify services)	DevOps transformation and automation	IaC adoption program; stack design; operational governance	https://www.devopsconsulting.in/

21. Career and Learning Roadmap

What to learn before Resource Manager

OCI fundamentals:
Tenancy, compartments, regions
IAM policies and groups
Core networking (VCN, subnets, routing, security lists/NSGs)
Terraform fundamentals:
Providers, resources, data sources
Variables, outputs
State and lifecycle (plan, apply, destroy)
Modules and environments

What to learn after Resource Manager

Advanced Terraform on OCI:
Module design patterns
Multi-compartment and multi-region patterns
Secure secrets patterns with OCI Vault (as applicable)
Operations and governance:
Tagging strategies and cost allocation
Drift management approaches
Auditing and incident response around infrastructure changes
CI/CD integration:
OCI DevOps pipelines (where applicable) plus Resource Manager
GitOps workflows (review + plan + apply controls)

Job roles that use it

Cloud Engineer (OCI)
DevOps Engineer / Platform Engineer
Site Reliability Engineer (SRE)
Cloud Security Engineer (for policy and guardrails)
Solutions Architect

Certification path (if available)

Oracle offers OCI certifications (associate/professional tracks). Resource Manager is often part of broader OCI architecture/devops knowledge rather than a standalone certification.

Action: Verify current certification paths on Oracle University / OCI certifications pages (official):
https://education.oracle.com/ (navigate to OCI certifications)

Project ideas for practice

Build a “network baseline” stack (VCN + subnets + routing + NSGs)
Build a “standard compute” stack with safe defaults (Always Free eligible where possible—verify)
Create dev/test/prod stacks sharing modules but using different variables
Implement tagging enforcement across all stacks
Use Resource Discovery to generate Terraform for an existing VCN, then refactor into modules

22. Glossary

OCI (Oracle Cloud Infrastructure): Oracle Cloud’s IaaS/PaaS platform.
Resource Manager: OCI managed service to run Terraform configurations as stacks and jobs.
Terraform: Infrastructure-as-code tool that uses declarative configuration and state to manage infrastructure.
Stack: Resource Manager object that packages Terraform configuration, variables, and associated state.
Job: An execution of Terraform actions for a stack (plan/apply/destroy).
Plan: Terraform operation that calculates changes without applying them.
Apply: Terraform operation that makes changes to reach the desired state.
Destroy: Terraform operation that deletes resources managed in the state.
State: Terraform’s record of managed resources and their attributes.
Locking: Mechanism to prevent concurrent state modifications.
Compartment: OCI’s logical isolation boundary for resources and policies.
OCID: Oracle Cloud Identifier, a unique ID for OCI resources.
VCN: Virtual Cloud Network, OCI’s virtual network construct.
Resource Principal: An OCI authentication method for services to call OCI APIs without long-lived user credentials.
Defined tags / Freeform tags: OCI tagging mechanisms for governance and cost allocation.
Drift: Difference between real infrastructure and Terraform state/configuration.

23. Summary

Oracle Cloud Resource Manager is OCI’s managed Terraform execution service, positioned within Observability and Management as a core operational tool for provisioning and governing infrastructure. It organizes Terraform workflows into stacks and jobs, manages state and locking, and integrates with OCI identity and audit patterns for controlled change.

Cost-wise, Resource Manager is often treated as no additional charge, but the infrastructure it creates can have significant cost drivers (compute, load balancers, databases, egress, logging). Security-wise, the critical success factors are IAM least privilege, compartment isolation, careful secrets handling, and disciplined plan/apply processes.

Use Resource Manager when you want OCI-native, governed Terraform workflows with managed state and execution. Start with low-risk stacks (networking foundations), then expand to production patterns with strong governance.

Next step: Build a small module library (VCN baseline, tagging baseline, and environment variables) and operationalize plan/apply reviews using your team’s change management process, referencing the official docs: https://docs.oracle.com/en-us/iaas/Content/ResourceManager/home.htm

rajeshkumar

Category

1. Introduction

2. What is Resource Manager?

Official purpose

Core capabilities

Major components

Service type

Scope: regional vs global

How it fits into the Oracle Cloud ecosystem

3. Why use Resource Manager?

Business reasons

Technical reasons

Operational reasons

Security/compliance reasons

Scalability/performance reasons

When teams should choose it

When teams should not choose it

4. Where is Resource Manager used?

Industries

Team types

Workloads

Architectures

Production vs dev/test usage

5. Top Use Cases and Scenarios

1) Landing zone provisioning (compartments + baseline networking)

2) Standard VCN patterns (hub-and-spoke)

3) Ephemeral test environments

4) Self-service infrastructure with guardrails

5) Resource Discovery for brownfield IaC adoption

6) Standardized tagging enforcement

7) Controlled change workflows (plan first, apply later)

8) Multi-environment promotion with variable sets

9) Centralized state management for collaboration

10) Private infrastructure provisioning via private endpoints

11) Audit-ready infrastructure change history

12) Standard module catalog for teams

6. Core Features

6.1 Stacks (Terraform configurations as managed objects)

6.2 Jobs (Plan / Apply / Destroy execution)

6.3 Managed Terraform state and locking

6.4 Variable management (inputs, defaults, sensitive values)

6.5 Configuration sources (upload, Object Storage, Git)

6.6 Resource Discovery (generate Terraform from existing resources)

6.7 Private connectivity patterns (private endpoints)

6.8 Outputs and job logs

6.9 Integration with OCI IAM, compartments, and tagging

7. Architecture and How It Works

7.1 High-level architecture

7.2 Request/control flow

7.3 Integrations with related services

7.4 Dependency services

7.5 Security/authentication model (practical view)

7.6 Networking model

7.7 Monitoring/logging/governance considerations

7.8 Architecture diagrams (Mermaid)

Simple architecture (learning/lab)

Production-style architecture (team workflow)

8. Prerequisites

Tenancy and account requirements

Permissions / IAM roles

Billing requirements

Tools needed

Region availability

Quotas / limits

Prerequisite services

9. Pricing / Cost

Pricing model (accurate framing)

Pricing dimensions

Free tier considerations

Cost drivers (most common)

Hidden or indirect costs

Network/data transfer implications

How to optimize cost

Example low-cost starter estimate (model, not numbers)

Example production cost considerations (model, not numbers)

10. Step-by-Step Hands-On Tutorial

Objective

Lab Overview

Step 1: Prepare the Terraform configuration (zip archive)

Option A: macOS / Linux