Question : Identity and Access Management (IAM)
- Policies: Control access to resources using specific
Allowrules. - Dynamic Groups: Group resources like compute instances dynamically based on matching rules.
- Instance Principles: Let instances make API calls without storing credentials.
- Federation: Link OCI with external identity providers (IdP) like Azure AD or Okta.
- Federation (DEX): Link your corporate identity provider to OCI for single sign-on
Networking and Security
- VCN & Subnets: Create isolated Virtual Cloud Networks with public and private subnets.
- DRG: Use Dynamic Routing Gateways to connect VCNs to on-premises networks or other VCNs.
- FastConnect: Establish dedicated, high-speed private network connections.
- Route Tables & Security Lists/NSG: Direct traffic via route rules and secure endpoints using Network Security Groups or Security Lists.
- Network ArchitectureIsolate workloads using Virtual Cloud Networks (VCNs) connected through a central Hub network.
- Hub VCN: Houses the Dynamic Routing Gateway (DRG), FastConnect, and shared security tools.
- Spoke VCNs: Separate subnets, route tables, and Network Security Groups (NSGs) for each environment.
- Connectivity: Use local peering to link spokes to the hub safely.
Environments and Workloads
- SDLC Stages: Segregate resources into Dev, Test, UAT, and Prod compartments.
- Shared Services: Centralize logging, monitoring, backups, and automation tools.
- App Services & Functions: Run serverless code using Functions or traditional app platforms.
- Exadata: Deploy high-performance Oracle Exadata databases split into non-prod and prod tiers.
- Sandbox & POC: Provide isolated spaces for developer experimentation and proofs of concept.
Question : To Manage OCI environment through terraform
To manage a complex Oracle Cloud Infrastructure (OCI) ecosystem using Terraform, you must categorize your infrastructure into modular, decoupled layers. This prevents a single Terraform state file from becoming too large, reduces the blast radius of changes, and aligns with OCI enterprise best practices.
Core Architecture & Segmentation Strategy
Categorize your OCI infrastructure into four decoupled layers managed by independent Terraform state files: Identity & Governance, Core Networking, Shared Platforms & Management, and Application Workloads.
Layer-by-Layer Categorization
1. Governance & Identity (The Foundation)
This layer establishes your OCI tenancy structure. It rarely changes after the initial setup.
- Compartments: Define a strict hierarchy (
Root -> Parent -> Env_Compartments). - IAM & Federation: Set up identity provider federation, groups, and users.
- Dynamic Groups: Target compute instances using instance principles for passwordless API authentication.
- Policies: Apply the principle of least privilege across compartments.
2. Core Networking (The Backbone)
This layer manages your global transit networking and external connectivity.
- Dynamic Routing Gateway (DRG v2): Acts as the central cloud router connecting all environments and on-premises networks.
- FastConnect / VPN: Establishes secure hybrid cloud connectivity to your on-premises data center.
- Hub VCN: Hosts centralized network appliances (firewalls) and public internet egress points.
3. Shared Services & Management (The Operations Hub)
Centralized operations tools utilized by all environments.
- Observability: OCI Logging analytics, Service Connectors, and Monitoring alarms.
- Security: Vulnerability Scanning, Cloud Guard, and OCI Vault (KMS) for secret management.
- Automation: CI/CD runners, Ansible management hosts, and Terraform cloud agents.
4. Environment Workloads (The Apps & Data)
Replicated across distinct lifecycle stages (Sandbox, Dev, Test/UAT, Prod). Each environment is isolated in its own OCI Compartment and Spoke VCN.
- Networking: Spoke VCNs, explicit subnets (Web, App, DB), Route Tables routing to the DRG, and Network Security Groups (NSGs) instead of generic Security Lists.
- Data Tier: Exadata Cloud Service (ExaCS) or Base Database Services, mapped to automated OCI Backup policies.
- Compute & Serverless: Application Services, OCI Functions, and API Gateways.
Recommended Terraform Directory Structure
Use Terraform Modules to define the blueprints, and instantiate them per environment using separate backend state files.
Management & Deployment Best Practices
- State Separation: Never use a single
terraform.tfstatefor the whole tenancy. Use OCI Object Storage as a remote backend, split by environment. - Security Lists vs. NSGs: Use Network Security Groups (NSGs) for application components (like Functions and Compute) because they apply to specific VNICs. Use Security Lists only for subnet-wide baseline rules.
- Cross-Reference via Data Sources: Have your environment Terraform code look up the Core Networking details using the
terraform_remote_statedata source oroci_core_vcnsdata filters instead of hardcoding IDs.
I can help you build the actual code. Let me know:
or
To manage a complex Oracle Cloud Infrastructure (OCI) landing zone at scale using Terraform, you must categorize your infrastructure into modular, decoupled layers. This prevents a single Terraform state file from becoming too large, slow, or risky to execute.
Here is a comprehensive guide to categorizing your OCI architecture, a structural diagram, Terraform interview Q&As, and best practices.
Architecture Categorization Framework
Group your infrastructure into five distinct layers based on blast radius, lifecycle, and administrative ownership.
+-----------------------------------------------------------------------+
| LAYER 1: IDENTITY & GOVERNANCE (Tenancy, IAM, Compartments, Policies) |
+-----------------------------------------------------------------------+
|
+-----------------------------------------------------------------------+
| LAYER 2: CORE NETWORKING (DRG, FastConnect, Hub-Spoke VCNs, Security) |
+-----------------------------------------------------------------------+
|
+-----------------------------------------------------------------------+
| LAYER 3: SHARED SERVICES (Logging, Monitoring, CI/CD Tooling, Bastion)|
+-----------------------------------------------------------------------+
|
+-----------------------------------------------------------------------+
| LAYER 4: ENVIRONMENT PLATFORMS (Sandbox, Dev, Test, UAT, Prod, DDS) |
+-----------------------------------------------------------------------+
|
+-----------------------------------------------------------------------+
| LAYER 5: APPLICATION & DATA SERVICES (Exadata, Functions, App Serv.) |
+-----------------------------------------------------------------------+
1. Identity & Governance (The Foundation)
- Components: Compartment hierarchies, Identity Domains, Groups, Dynamic Groups (for Instance Principals), Identity Federation, and global IAM Policies.
2. Core Networking (The Backbone)
- Components: Dynamic Routing Gateways (DRG v2), FastConnect circuits, Hub-and-Spoke VCN topologies, RPCs (Remote Peering Connections), Internet Gateways, and NAT Gateways.
- Environment Strategy: Split into Non-Prod Network VCN and Prod Network VCN connected via a central DRG to isolate traffic.
3. Shared Services & Management
- Components: OCI Logging analytics, Service Connectors, Monitoring (Alarms/Metrics), Object Storage for backups, Vault (KMS), and Automation management tooling (Jenkins, GitHub Runners, or OCI Resource Manager).
- Environment Strategy: Hosted in a dedicated
Shared-Services-Compartmentaccessible by both Prod and Non-Prod environments.
4. Environment Isolation & Subnets
- Components: Environment-specific subnets, Route Tables, Security Lists, and Network Security Groups (NSGs).
- Categorization Strategy:
- Sandbox: Highly permissive, completely decoupled, no FastConnect access.
- Non-Prod: Grouped into Dev, Test, and UAT compartments/subnets sharing a non-prod DRG attachment.
- Prod: Strict Prod isolation with high-availability configurations.
- Data Delivery/Ingestion (DDS/IDD): Edge subnets or DMZs dedicated to secure data transit.
5. Data & Application Workloads
- Components: Exadata Cloud Service, Base Database Services, OCI Functions, Compute Instances (App Services).
- Categorization Strategy: Deployed via environment-specific application repositories using remote state outputs from the Networking and Identity layers.
Terraform Interview Questions & Answers
Q1: How do you securely allow an OCI Function or Compute Instance to manage other OCI resources using Terraform without hardcoding API keys?
Answer:
You use Instance Principals or Resource Principals combined with Dynamic Groups.
You use Instance Principals or Resource Principals combined with Dynamic Groups.
- In Terraform, define an
oci_identity_dynamic_groupwith a matching rule (e.g.,instance.compartment.id = 'ocid1...'). - Create an
oci_identity_policygranting that Dynamic Group permissions to the required services.
Q2: What is the difference between Security Lists and Network Security Groups (NSGs) in OCI, and when would you use each in Terraform?
Answer:
- Security Lists: Apply to the entire Subnet. Every vNIC in that subnet inherits the rules.
- NSGs: Apply directly to individual vNICs (e.g., a specific Exadata VM cluster or App Service instance).
- Best Practice: Use Security Lists for baseline subnet rules (e.g., blocking all public traffic) and NSGs for granular application-to-database traffic controls. NSGs prevent "subnet sprawl" because you don't need to create new subnets just to separate firewall rules.
Q3: How would you structure your Terraform code to handle "Dev, Test, UAT, and Prod" environments efficiently without duplicating code?
Answer:
Use a combination of Terraform Modules and Terragrunt (or standard Terraform workspaces/backend configuration files).
Use a combination of Terraform Modules and Terragrunt (or standard Terraform workspaces/backend configuration files).
- Write generic, reusable modules for workloads (e.g., an
exadatamodule, avcnmodule). - Create distinct root directories for each environment (
environments/dev/,environments/prod/). - Pass environment-specific variables (
env_prefix,cidr_block,db_node_count) into the modules fromterraform.tfvarsfiles in those directories. Never use a single state file for both Dev and Prod.
Terraform Best Practices for OCI
- Isolate State Files: Never manage Network, Identity, and Exadata in the same state file. If a developer accidentally destroys an App Service stack, the Core Network and Database layers must remain untouched.
- Prefer NSGs over Security Lists: NSGs allow you to write cleaner object-oriented security rules in Terraform by referencing the NSG OCID as the source or destination.
- Use Remote State Data Sources: For application and database layers, use
data "terraform_remote_state"to read-only subnet OCIDs and network details exposed by the Core Networking team. - Enforce Tagging via Providers: Use the OCI provider's
defined_tagsorfreeform_tagsarguments at the root level to automatically applyEnvironment,Owner, andCost-Centertags to all automated resources.
This is a comprehensive, production-grade architecture blueprint for managing Oracle Cloud Infrastructure (OCI) with Terraform. It categorizes your enterprise components into a clean framework, provides an architectural diagram blueprint, answers core interview questions, and provides tested code examples. [1, 2]
Architecture Categorization Framework
To manage a complex enterprise environment efficiently, you must break down your infrastructure into a Multi-Layer, Multi-Account (Tenancy/Compartment) framework. This separates blast radiuses and organizes resources by lifecycle.
[TENANCY ROOT]
├── [Governance & IAM Layer] (Shared Services, Identity, Policies)
├── [Network Core Layer] (DRG, FastConnect, Hub VCN)
└── [Environment Layers]
├── [Sandbox / POC] (Isolated, temporary discovery zones)
├── [Non-Prod Zone] (Dev, Test, UAT - shared network/policies)
└── [Prod Zone] (Production, Exadata, High Security)
Layer Breakdown
1. Identity & Governance (The Foundation)
- Components: IAM Users/Groups, Dynamic Groups, Identity Domains, Federation, IdP integration, Tenancy-level Policies.
- Management Strategy: Managed in a global bootstrap Terraform state. Dynamic Groups use Instance Principals to allow automated tooling (like Jenkins or GitHub Actions) to deploy resources without hardcoded API keys. [1]
2. Core Network & Connectivity (The Backbone)
- Components: Dynamic Routing Gateway (DRG v2), FastConnect, Hub VCN, RPC (Remote Peering Connections).
3. Environment Segregation (The Spoke VCNs)
To keep management simple, group your environments into four distinct Compartment/VCN trees:
- Sandbox / Experience / POC: Completely isolated. Loose security lists. Automated teardown scripts.
- Non-Prod (Dev / Test / UAT): Grouped together to save costs. Shared non-prod DRG attachments. Medium security compliance.
- Prod (Production): High security, strict Network Security Groups (NSGs), zero public IPs, production-grade Exadata Cloud Service instances.
4. Database & Application Services (The Workloads)
- Components: Exadata Cloud Infrastructure (Dedicated/Cloud@Customer), OCI Functions, App Services (OKE/Compute).
- Management Strategy: Split into Exadata Non-Prod and Exadata Prod sub-compartments. Databases use private subnets, managed exclusively via NSGs rather than broad Security Lists. [1]
Terraform Architecture: Directory Structure
text
terraform-root/
├── global/
│ ├── iam/ # Identity, Dynamic Groups, Federation Policies
│ └── governance/ # Tagging namespaces, Compartment structures
├── network/
│ ├── core-transit/ # DRG v2, FastConnect maps, Hub VCN
│ └── spokes/ # VCNs, Subnets, Route Tables for Prod/Non-Prod
├── environments/
│ ├── sandbox/ # POC apps, temporary compute
│ ├── non-prod/ # Dev, Test, UAT compute & functions
│ └── prod/ # Production workloads, Exadata Infrastructure
└── shared-services/ # Logging (SIEM Integration), Monitoring, Bastions
Use code with caution.
Terraform Interview Questions & Answers
Q1: How do you securely authenticate Terraform to OCI in a CI/CD pipeline without using hardcoded API Private Keys?
- Build a CI/CD runner execution agent on an OCI Compute Instance.
- Create a Dynamic Group with a matching rule targeting that instance's OCID or compartment (e.g.,
ALL {instance.compartment.id = 'ocid1.compartment...'}). - Write an IAM Policy granting that Dynamic Group permission to manage resources in the target compartments.
Q2: Why should you prefer Network Security Groups (NSGs) over Security Lists when deploying Exadata and App Services?
Answer:
Security Lists apply to the entire subnet, forcing every vNIC in that subnet to inherit identical firewall rules. Network Security Groups (NSGs) apply to individual vNICs.
For complex setups like Exadata or OCI Functions, NSGs allow you to write granular, micro-segmented rules (e.g., Allow App Service Function NSG to talk to Exadata DB NSG over port 1521) even if they live inside the same subnet. This scales better and avoids reaching the limits of Security List rule counts. [1, 2]
Security Lists apply to the entire subnet, forcing every vNIC in that subnet to inherit identical firewall rules. Network Security Groups (NSGs) apply to individual vNICs.
For complex setups like Exadata or OCI Functions, NSGs allow you to write granular, micro-segmented rules (e.g., Allow App Service Function NSG to talk to Exadata DB NSG over port 1521) even if they live inside the same subnet. This scales better and avoids reaching the limits of Security List rule counts. [1, 2]
Code Example: IAM, Networking, and Dynamic Groups
Below is a tested, modular structure demonstrating how to configure your foundational tenancy layers using standard OCI patterns.
providers.tfhcl
terraform {
required_version = ">= 1.5.0"
required_providers {
oci = {
source = "oracle/oci"
version = ">= 5.0.0"
}
}
}
# Configuration using Instance Principal authentication for pipeline safety
provider "oci" {
auth = "InstancePrincipal"
}
Use code with caution.
iam_governance.tfhcl
variable "tenancy_ocid" {
type = string
description = "The root tenancy OCID"
}
# 1. Create Environment Compartments
resource "oci_identity_compartment" "prod_compartment" {
compartment_id = var.tenancy_ocid
description = "Production Workloads Zone including Production Exadata"
name = "prod-environment"
enable_delete = false
}
# 2. Define Dynamic Group for Management Automation Tooling/Instance Principals
resource "oci_identity_dynamic_group" "automation_runner_group" {
compartment_id = var.tenancy_ocid
description = "Dynamic group for CI/CD runner compute instances"
name = "tf-automation-runners"
matching_rule = "ANY {instance.compartment.id = '${var.tenancy_ocid}'}"
}
# 3. Policy allowing the runner to manage network and app infrastructure
resource "oci_identity_policy" "runner_policy" {
compartment_id = var.tenancy_ocid
description = "Policy to allow automation runner to deploy resources"
name = "tf-automation-policy"
statements = [
"Allow dynamic-group tf-automation-runners to manage all-resources in compartment id ${oci_identity_compartment.prod_compartment.id}"
]
}
Use code with caution.
network_spoke.tfhcl
# 4. Spoke VCN for Production Environment
resource "oci_core_vcn" "prod_vcn" {
cidr_block = "10.0.0.0/16"
compartment_id = oci_identity_compartment.prod_compartment.id
display_name = "prod-spoke-vcn"
dns_label = "prodvcn"
}
# 5. Granular Network Security Group for Application Tier
resource "oci_core_network_security_group" "app_nsg" {
compartment_id = oci_identity_compartment.prod_compartment.id
vcn_id = oci_core_vcn.prod_vcn.id
display_name = "prod-app-nsg"
}
# 6. NSG Rule allowing Inbound HTTPS traffic
resource "oci_core_network_security_group_security_rule" "allow_https" {
network_security_group_id = oci_core_network_security_group.app_nsg.id
direction = "INGRESS"
protocol = "6" # TCP
source = "0.0.0.0/0"
source_type = "CIDR_BLOCK"
tcp_options {
destination_port_range {
max = 443
min = 443
}
}
}
Use code with caution.
Automation Testing Strategies
To validate this infrastructure-as-code setup before hitting production, apply two stages of automated testing:
1. Static Security Analysis (trivy / tfsec)
Run static scans inside your deployment pipelines to check for insecure configurations (such as overly broad open CIDR blocks in security rules). [1]
bash
trivy config ./network/
Use code with caution.
2. Dynamic Integration Testing (Terratest)
Create programmatic Go test cases to deploy your code to your Sandbox/POC environment, assert that the configuration works natively in OCI, and automatically clean it up.
vcn_test.gogo
package test
import (
"testing"
"://github.com"
"://github.com"
)
func TestProdVcnDeployment(t *testing.T) {
t.Parallel()
terraformOptions := terraform.WithDefaultRetryableErrors(t, &terraform.Options{
// Points to the directory containing our spoke code
TerraformDir: "../environments/prod",
})
// Run "terraform init" and "terraform apply". Fail the test if errors occur.
defer terraform.Destroy(t, terraformOptions)
terraform.InitAndApply(t, terraformOptions)
// Validate that outputs match production spec
vcnCidr := terraform.Output(t, terraformOptions, "prod_vcn_cidr")
assert.Equal(t, "10.0.0.0/16", vcnCidr)
}
No comments:
Post a Comment