Day 1 · Landing zone · 03

STEP 3 — Day 1 Action Items: Landing Zone Build (Fully Manual)

Inputs: the Day-1 sections of the customer-answered questionnaire (IAM, Infra & Network, Security, DevOps IaC, BCP & DR sheets) and the ratified Step-1 governance pack. This step is Phase A1 (Prerequisites & Tenancy Bootstrap) followed by the full manual landing-zone build, sequenced as numbered IaC stacks so each stack has a clean state file and an obvious blast radius.

3.1 Phase A1 — Prerequisites & Tenancy Bootstrap (Day 1–3)

3.2 Stack Build Order (proven sequence)

The build is sequenced into numbered stacks. Stacks 1–2 and 9–10 constitute the landing zone; stacks 3–8 are workload stacks executed in Step 4. Each stack: author tfvars from the design → fmt/validate/tflint/checkov → plan → peer review of the plan line-by-line → MR approval → apply from the protected runner → verify.

Identity note (co-tenanted estates): the workforce domain built in Stack 1 is the single meeting point of the two planes — confirm Fusion pods federate to it (or to the agreed dedicated domain) before Step 4 integrations are built.

3.3 The Manual Quality Loop (every stack, every change)

cd <stack-dir>
tofu fmt -recursive && tofu validate
tflint --recursive
checkov -d . --framework terraform
tofu init -backend-config=<env-backend>
tofu plan -var-file=<env>.tfvars -out=plan.bin
tofu show plan.bin   # second engineer reads line-by-line vs design

Reviewer checklist: no public subnets without an approved exception; no 0.0.0.0/0 on management ports; every resource carries the mandatory tags; resource counts match the design; no unexplained destroys/replacements.

3.4 Exit Criteria — Step 3

Stacks 1, 2, 9, 10 applied and verified in non-prod and prod trees; federation live; connectivity (FastConnect/VPN) passing end-to-end tests; events/alarms delivering; flow logs flowing; per-compartment budgets and quotas applied; all state files in the versioned backend; verification checklists signed inside the MRs.

1. Phase Map and Inputs

1.1 Questionnaire inputs consumed

2. Phase A1 — Prerequisites & Tenancy Bootstrap (Day 1–3)

2.1 Access prerequisites

2.2 Create break-glass accounts (Default domain)

Console path: Menu > Identity & Security > Identity > Domains > Default > Users > Create user

Allow group Default/OCI-BREAKGLASS-ADMIN to manage all-resources in tenancy

2.3 Create the workforce identity domain

Console path: Menu > Identity & Security > Identity > Domains > Create domain

2.4 Federate the IdP (branch per <IDP>)

2.4.1 [Entra ID branch]

2.4.2 [Okta branch]

2.5 Pilot verification and group mapping chain

2.6 Retire the temporary tenancy administrator

2.7 [SAAS] Fusion SSO touchpoint

Associate each Fusion pod with the same IdP application suite so a user moves Fusion → OCI Console → analytics without re-authentication. Pod association is performed in the Fusion environment console per Oracle’s SaaS runbook and is executed by the Fusion admin under the Fusion change process — record only the mapping and date here. [ISOLATED]: federation is configured independently in the SaaS tenancy; repeat §2.4 there.

3. Phase A2 — Tag Namespace and Compartment Tree

3.1 Create the tag namespace and keys

Console path: Menu > Governance & Administration > Tenancy Management > Tag Namespaces > Create Namespace

3.2 Create the compartment tree (top-down)

Console path: Menu > Identity & Security > Compartments > Create Compartment

Create parents before children. Reference tree (adapt names per Doc 1 §4; delete branches out of scope):

root

├─ Governance

├─ Shared-Services

│ ├─ Networking ├─ Identity-Integrations

│ ├─ Shared-Tools └─ Vault-KMS

├─ Applications

│ ├─ DEV1 {PaaS, Internal, Vendor-<NAME>} ├─ DEV2 {…}

│ ├─ TST {…} └─ PRD {…}

├─ SaaS {ERP, HCM, SCM, CX, EPM — per licensed pillars} [CO-TENANTED]

├─ Analytics ├─ Regulated-Workloads (if in scope)

├─ Sandbox └─ DR (reserved, empty)

4. Phase A3 — Groups Completion and IAM Policy Set

4.1 Complete the group set

4.2 Apply the policy set

Console path: Menu > Identity & Security > Policies (select target compartment before Create Policy)

One policy resource per compartment per purpose, named pol-<compartment>-<purpose>. Baseline set (adapt group prefixes to <domain>/<group>):

pol-root-baseline (compartment: root)

Allow group OCI-SECURITY-ADMIN to read all-resources in tenancy

Allow group OCI-AUDITOR to read all-resources in tenancy

Allow group OCI-AUDITOR to read usage-reports in tenancy

Allow group OCI-COST-AUDIT to read all-resources in tenancy

Allow group OCI-COST-AUDIT to read usage-reports in tenancy

Allow group OCI-SECURITY-ADMIN to manage cloud-guard-family in tenancy

Allow group OCI-SECURITY-ADMIN to manage security-zone in tenancy

Allow group OCI-SECURITY-ADMIN to manage tag-namespaces in tenancy

Allow group OCI-SECURITY-ADMIN to manage tag-defaults in tenancy

Allow group OCI-IAM-ADMIN to manage domains in tenancy

Allow group OCI-IAM-ADMIN to manage groups in tenancy

Allow group OCI-IAM-ADMIN to manage policies in tenancy

pol-shared-services (compartment: Shared-Services)

Allow group OCI-NETWORK-ADMIN to manage virtual-network-family in compartment Shared-Services

Allow group OCI-SECURITY-ADMIN to manage vaults in compartment Shared-Services:Vault-KMS

Allow group OCI-SECURITY-ADMIN to manage keys in compartment Shared-Services:Vault-KMS

Allow group OCI-SECURITY-ADMIN to manage secret-family in compartment Shared-Services:Vault-KMS

Allow group OCI-DEVELOPER to use subnets in compartment Shared-Services where target.vcn.name = 'DEV1-PLATFORM-VCN-CORE-01'

Allow group OCI-APP-ADMIN to use subnets in compartment Shared-Services where target.vcn.name = 'TST-PLATFORM-VCN-CORE-01'

pol-applications (compartment: Applications)

Allow group OCI-DEVELOPER to manage all-resources in compartment Applications:DEV1

Allow group OCI-DEVELOPER to manage all-resources in compartment Applications:DEV2

Allow group OCI-APP-ADMIN to manage all-resources in compartment Applications:TST

Allow group OCI-APP-ADMIN to manage all-resources in compartment Applications:PRD

Allow group OCI-OIC-ADMIN to manage integration-instance-family in compartment Applications:PRD:PaaS

Allow group OCI-DB-ADMIN to manage database-family in compartment Applications:PRD

Allow group OCI-DB-ADMIN to read database-family in compartment Applications:TST

Allow group OCI-SUPPORT to read all-resources in compartment Applications

pol-vendors / pol-saas-analytics-regulated-sandbox — replicate the patterns above per Doc 1 §6: vendor groups manage only their Applications:<env>:Vendor-<NAME> compartments and use only the shared integration subnet; OCI-FDI-ADMIN manages Analytics; OCI-REGULATED-OPS manages Regulated-Workloads; OCI-DEVELOPER manages Sandbox; SaaS handles get read-only grants.

5. Phase A4 — Network and Security Services

5.1 CIDR plan validation

5.2 Create VCNs, subnets, gateways (repeat per environment)

Console path: Menu > Networking > Virtual Cloud Networks > Create VCN

5.3 NSGs (default-deny; rules per design)

Console path: VCN detail > Network Security Groups > Create NSG

5.4 Hybrid connectivity [execute only if CT.* answers say yes]

5.4.1 DRG

Console path: Menu > Networking > Dynamic Routing Gateways > Create DRG

5.4.2 Site-to-Site VPN (IPSec) — from CT.03–CT.13

Console path: Menu > Networking > Site-to-Site VPN > Create IPSec Connection

5.4.3 FastConnect — from CT.14–CT.22

5.5 Vault and keys

Console path: Menu > Identity & Security > Key Management & Secret Management > Vault > Create Vault

5.6 Logging, audit retention, Cloud Guard tuning

5.7 Security Zones

Console path: Menu > Identity & Security > Security Zones > Create Security Zone

6. Phase A5 — Guard-rails and Operations Base

6.1 Per-compartment budgets

Console path: Menu > Billing & Cost Management > Budgets > Create Budget

6.2 Quota policies (hard stops)

Console path: Menu > Governance & Administration > Tenancy Management > Quota Policies > Create Quota Policy

QUO-SANDBOX: zero compute-core-count quotas /gpu.*/ in compartment Sandbox

zero compute-core-count quotas /hpc.*/ in compartment Sandbox

set compute-core-count quota standard.* to 8 in compartment Sandbox

QUO-DEV: zero compute-core-count quotas /gpu.*/ in compartment Applications:DEV1

zero compute-core-count quotas /gpu.*/ in compartment Applications:DEV2

6.3 Baseline alarms

Console path: Menu > Observability & Management > Monitoring > Alarms > Create Alarm

6.4 Phase gates G-A4/G-A5 — consolidated evidence

All ten green + build log complete + CD3 as-built extract reconciled against design (Doc 6 §4) → landing zone is accepted and Doc 4 (workload onboarding) may begin.

7. OPTION B — Terraform IaC via OCI Resource Manager (Phases A2–A5)

Option B replaces the manual procedures of §3–§6 with the terraform_lz repository executed as OCI Resource Manager (ORM) stacks, sourced from Git. Phase A1 (§2 — break-glass, identity domains, IdP federation) is ALWAYS executed manually first, in both options: the pipeline’s own identity depends on it. The phase gates G-A2…G-A5 and their evidence requirements are unchanged — only the execution engine changes.

7.1 Repository standard — terraform_lz

The landing-zone repository carries one folder per stack, each a self-contained ORM-compatible Terraform configuration (provider.tf without backend block — ORM manages state; schema.yaml drives the ORM variable UI; terraform.tfvars / tfvars.json carry per-environment values).

7.2 ORM prerequisites (one-time, manual)

Console path: Menu > Developer Services > Resource Manager > Configuration Source Providers

Create IdP group <IDP>-OCI-IAC-ADMIN → OCI group OCI-IAC-ADMIN (members: platform engineers who may run applies; approvers configured in the Git platform, not here).

Create policy pol-shared-tools-orm in Shared-Services:Shared-Tools:

Allow group OCI-IAC-ADMIN to manage orm-stacks in compartment Shared-Services:Shared-Tools

Allow group OCI-IAC-ADMIN to manage orm-jobs in compartment Shared-Services:Shared-Tools

Allow group OCI-IAC-ADMIN to manage orm-config-source-providers in compartment Shared-Services:Shared-Tools

Stack execution identity: ORM jobs run with the permissions of the user who starts them, so applies must be started by OCI-IAC-ADMIN members whose group also holds the grants the stacks need (stack1 requires broad IAM grants — scope a dedicated pol-root-iac policy to OCI-IAC-ADMIN listing exactly the resource families the stacks manage: compartments, groups, policies, tag-namespaces, vaults, keys, secrets, cloud-guard-family, security-zone, virtual-network-family, drgs, alarms, ons-family, log-groups). Review this policy with Security before creation — it is the most privileged non-break-glass grant in the tenancy.

Create the Configuration Source Provider: Resource Manager > Configuration Source Providers > Create. Phase 1: type GitHub — server URL https://github.com, PAT with repo read scope stored as the provider credential. Phase 2: type GitLab — server URL https://gitlab.com (or self-hosted URL), project access token.

Create one ORM stack per stack-folder per environment scope: Resource Manager > Stacks > Create Stack > Source: Git configuration source provider; repository <customer>-oci-terraform-lz; branch main; working directory e.g. terraform_lz/stack1/compartments. Name: STK-LZ-<STACK>-<SCOPE> (e.g., STK-LZ-STACK1-COMPARTMENTS, STK-LZ-STACK2-PROD-SPOKE-VCN). Compartment: Shared-Services:Shared-Tools.

Variables: ORM renders the schema.yaml form — populate from the design tables of §3–§6 (CIDRs from §5.1, group names from Doc 1 §6, tag keys from Doc 1 §9). Save without running.

7.3 Phase 1 — GitHub repository + Actions pipeline

Create the GitHub repository <customer>-oci-terraform-lz (private, in the customer org); push the terraform_lz content; enable branch protection on main: require PR, ≥ 1 approving review from CODEOWNERS, no force-push, require status checks.

Add CODEOWNERS: stack1/* → platform + security reviewers (IAM changes need Security approval per Doc 1 SoD); stack2/* → network reviewers; stack9–10/* → platform.

Store pipeline credentials as GitHub Actions secrets: OCI CLI API key for a dedicated automation user svc-github-orm (member of OCI-IAC-ADMIN), fingerprint, tenancy/user OCIDs, region. Rotate ≤ 90 days via the Vault-recorded schedule.

Add the validation workflow (PR): terraform fmt -check and terraform validate per changed stack folder + tflint/checkov static scan. This runs in the GitHub runner and never touches OCI.

Add the plan workflow (PR): for each changed stack folder, use the OCI CLI to trigger the matching ORM stack — update stack from branch, run a PLAN job (oci resource-manager job create-plan-job), poll, download the plan log, post it as a PR comment. Reviewer reads the plan in the PR — approval of the PR is approval of the plan.

Add the apply workflow (merge to main): protected by a GitHub Environment (e.g., oci-prod) with required reviewers — the approval gate. On approval: oci resource-manager job create-apply-job with the execution-plan strategy FROM_PLAN_JOB_ID referencing the reviewed plan. Post the apply log back to the merge commit.

Order of first execution (fresh landing zone): stack1 compartments → defined_tags → groups → policies → vault/master_key/secrets → stack2 network (hub → DRG → spokes → FastConnect) → stack10 flow logs → stack1 cloudguard → stack9 notifications/events → stack1 security_zone LAST (zones block non-compliant creation — apply them after the network reaches its compliant end-state, mirroring §5.7).

7.4 Phase 2 — GitLab repository + CI/CD migration

Create the GitLab project (or self-managed instance project) and mirror/import the GitHub repository with full history; freeze GitHub to read-only after cutover (archive; do not delete — audit history).

Recreate protections: protected branch main (Maintainers merge only), merge request approvals ≥ 1 with Code Owners (same ownership map as §7.3), push rules.

Create a new Configuration Source Provider of type GitLab in ORM (§7.2) and re-point every STK-LZ-* stack’s source to it (Edit stack > Source). State is untouched — ORM keeps it server-side; only the config source changes.

Store credentials as GitLab CI/CD variables (masked + protected): the svc-gitlab-orm automation user API key (create a NEW automation user; do not reuse the GitHub one — retire svc-github-orm after cutover).

Add .gitlab-ci.yml with stages validate → plan → apply: validate = fmt/validate/tflint per changed stack; plan = trigger ORM plan job and expose the plan log as a job artifact + MR note; apply = manual job (when: manual) on main, restricted to protected environment oci-prod with required approvals, triggering the ORM apply job FROM_PLAN_JOB_ID.

Run one no-change pipeline end-to-end (plan shows zero diff) as the cutover proof; then run one real change through GitLab to confirm the full loop. Record both in the build log; update Doc 6 references (repository URL, pipeline links).

7.5 Option B phase-gate mapping

Revision History