Day 2 · Workloads · 04

STEP 4 — Day 2 Action Items: Workload Onboarding (Per Workload)

Corresponds to Phase A6. With the landing zone live, workloads onboard as repeatable per-service stacks. For a Fusion-centric estate the “workloads” are predominantly the integration and data-movement platform around the SaaS pods. Non-prod first, then prod, per stack.

Stack	Service	Manual build & placement notes
Stack 3	OIC connectivity agents + network security VM (e.g., firewall/inspection VM) — and SFTP VM where in scope	Compute in Applications:{env} private subnets; agents paired to the OIC instance; SFTP VM hardened (key-only auth, NSG-restricted, logging on); firewall VM only if the inspection ADR requires it
Stack 4	Object Storage	Buckets per env/purpose (integration staging, archives, exports); private; versioning where required by data class; lifecycle rules; no public buckets without exception ADR
Stack 5	ATP (Autonomous Transaction Processing)	Private endpoint in the app-processing subnet; never a Fusion data store — staging/x-ref/custom only (boundary rule); Vault-managed keys per data class; wallets in Vault/secrets
Stack 6	DNS	Private views + resolver endpoints on hub and spoke VCNs (prod and non-prod); forwarders to on-prem DNS per the hybrid design; validates FastConnect name resolution end-to-end
Stack 7	Load Balancers	Application LB / private NLB / public NLB per exposure decisions; certificates from Vault; health checks explicit; public LB requires the exposure ADR
Stack 8	OIC integration instance	One instance per environment in Applications:{env}:PaaS; message-pack sizing from the questionnaire's OIC sheet; File Server enabled where SFTP-style flows are replaced by OIC File Server; connectivity agent (Stack 3) attached; VBS/CI wiring per the DevOps annex
Stack 9 (workload scope)	Workload alarms	Per-service alarms (OIC errors, ATP storage/CPU, LB unhealthy backends, VM/agent health) → Notifications topics from Step 3

4.1 Per-Workload Procedure (repeat for every stack above)

Extract requirements from the relevant questionnaire sheet (e.g., OIC sheet for stacks 3/8) into the stack tfvars.

Run the Step-3.3 quality loop; peer plan review; MR with approvals; human-gated apply; post-apply functional test (e.g., OIC test integration to a Fusion test pod; SFTP login test; ATP connection through the private endpoint).

Write/extend the workload runbook (purpose, preconditions, exact steps, verification, rollback, escalation, last-tested date).

4.2 Exit Criteria — Step 4

Each onboarded workload: applied in non-prod and prod, functionally tested against the Fusion pods where applicable, alarmed, runbooked, tagged, and registered.

STEP 4 · DOCUMENT 4 OF 6

Day 2 Workload Onboarding — Phase A6

Repeatable per-workload procedure (Week 5+): OIC + connectivity agent · ATP · Object Storage · SFTP VM · service accounts & Vault secrets · alarms · acceptance — manual (Option A) or via terraform_wl stacks through OCI Resource Manager with Git CI/CD (Option B: Phase 1 GitHub → Phase 2 GitLab) — with the SaaS-only branch

Executed once per workload after the landing-zone gates G-A1…G-A5 (Doc 3 §6.4) have passed. One workload = one intake record, one change record, one acceptance record. Use the SAME execution option selected for Doc 3.

Day 2 Workload Onboarding Runbook

Field	Value
Document ID	<CUSTOMER>-RUN-D2-004
Version	v1.1 (Generic Template)
Execution model	DUAL PATH — Option A: fully manual (OCI Console). Option B: Terraform via OCI Resource Manager, repository + CI/CD (Phase 1 GitHub, Phase 2 GitLab). Must match the Doc 3 selection.
Customer	<CUSTOMER> — replace on engagement start
Tenancy	<TENANCY-NAME> / OCID: <TENANCY-OCID>
Prepared by	Cloud Platform Engineering
Review cycle	Per engagement; template annually

1. Workload Intake

1.1 Intake record (one per workload)

Field	Source	Example
Workload name / purpose	Customer request + OIC sheet of questionnaire	AP payment integration: ERP → bank
Service components needed	OIC sheet, capacity rows	OIC project + ATP schema + 2 buckets + SFTP counterparty
Environments	Promotion path	DEV1 → TST → PRD
Data classification / regulatory scope	Questionnaire 0C.03	Confidential; RegulatoryScope=None
Counterparties & CIDRs	Integration partner details	Bank SFTP: <IP>/32
Owners (business + technical)	Doc 1 tags	AP Manager / Integration team
Criticality / BackupTier / DRTier	Doc 1 tag LOVs	High / T1-Daily / DR2-Backup

DECISION POINT:Route by scope: [IAAS+PAAS] workloads follow §2–§8 (Option A manual) or §11 (Option B Terraform — same design content, pipeline execution). [SAAS]-only onboarding (a new Fusion pillar or pod with no platform components) follows §9 alone. Everything here executes under a change record (Doc 1 §12) — four-eyes in Option A, PR/MR review + pipeline approval in Option B.

1.2 Standing rule — build order per workload

Compartment placement + tags (§2)

Network additions: NSG rules, route entries (§3)

Data services: ATP schema/instance, buckets (§4)

Integration: OIC instance/project, connectivity agent if on-prem endpoints (§5)

File exchange: File Server or SFTP VM (§6)

Identity: service accounts + Vault secrets (§7)

Observability: alarms + logs (§8)

Acceptance tests + build-log close-out (§10)

2. Compartment Placement and Tagging

Place workload resources in Applications:<ENV>:PaaS (managed platform instances) or Applications:<ENV>:Internal (customer-built apps/VMs). Vendor-built components go in the vendor workspace compartment only.

Regulated data (RegulatoryScope ≠ None): resources go to Regulated-Workloads with its Security Zone and dedicated NSGs — never mixed into standard Applications compartments.

Apply the full mandatory tag set at creation (the tag defaults force CostCenter/Environment; enter the rest deliberately — ApplicationOwner, TechnicalOwner, Service, Criticality, DataClassification, BackupTier, SupportGroup, Partner).

3. Network Additions

Add workload-specific NSG rules to the NSGs created in Doc 3 §5.3 (or create NSG-<ENV>-<WORKLOAD>-01 for a new pattern). Every rule cites the intake record: source/destination, port, protocol, justification.

Partner-facing endpoints: add the counterparty CIDRs to NSG-<ENV>-LB-01 (443) or NSG-<ENV>-SFTP-01 (22) — named CIDRs only, never 0.0.0.0/0.

New route requirements (e.g., NAT egress for a named interface in PRD) follow the change process with explicit approval — default remains no 0.0.0.0/0 in PRD.

Reviewer walks the resulting connectivity matrix against the design before anything is deployed onto the network.

4. Data Services

4.1 ATP (Autonomous Database)

Console path: Menu > Oracle Database > Autonomous Database > Create Autonomous Database

Reuse-first: for non-production, prefer one shared ATP per DEV tier with schema-per-workload isolation (cost); TST and PRD get dedicated instances per data-domain when isolation or performance demands. Record the decision.

Create (when a new instance is due): Compartment Applications:<ENV>:PaaS; display name <ENV>-<APP>-ADB-<PURPOSE>-01; workload type Transaction Processing.

Compute: 2 ECPU, auto-scaling enabled (×3). Storage: 1 TB auto-expand. License: BYOL vs included per the customer licensing decision — record it.

Network access: Private endpoint access only; subnet App-Processing-Subnet; NSG NSG-<ENV>-ATP-01. Require mutual TLS: yes.

Admin password: generated, stored immediately in Vault as SEC-ATP-<ENV>-ADMIN (never in a spreadsheet/chat).

Post-create: download the mTLS wallet, store in Vault as a base64 secret; create schemas (STG_RAW, STG_CONFORMED, XREF, APP_<NAME> as designed) and DB users: svc-oic-<env>-stg (RW on staging), svc-app-<name>, monitoring read-only user — passwords straight into Vault, rotation ≤ 90 days.

Backups: confirm automatic (60d); PRD: enable long-term monthly retention; if <SECONDARY-REGION> subscribed and DRTier demands it, enable cross-region backup copy.

VERIFY:From an allowed source (App-Processing subnet), SQL*Net over 1522 with the wallet connects; from Integration-Shared subnet, connection times out (NSG blocks). Both results screenshotted.

4.2 Object Storage buckets

Console path: Menu > Storage > Buckets > Create Bucket

Create per intake: <ENV>-<APP>-BUCKET-<PURPOSE>-01 (e.g., PRD-ERP-BUCKET-FBDI-IN-01) in Applications:<ENV>:PaaS.

Visibility: Private (always). Versioning: Enabled. Encryption: customer-managed key KEY-MASTER-STORAGE-01 where the design requires it.

Lifecycle rules per data class: e.g., FBDI in/out — archive 90d, delete 400d; migration buckets — delete after signed retention; file archives — 1 year.

Replication policy to <SECONDARY-REGION> only for governed buckets that DRTier requires.

5. Integration Platform (OIC)

5.1 OIC instance (first workload in an environment creates it; later workloads reuse)

Console path: Menu > Developer Services > Application Integration > Integration Instances > Create

Compartment: Applications:<ENV>:PaaS. Name: <ENV>-OIC-CORE-01. Edition: Standard, or Enterprise if B2B/insight features are licensed — check the SKU, record it.

Shape: Development (DEV) / Production (TST, PRD). Message packs: 1 to start; scale after volume testing (online operation).

Network access: DEV — allow-listed public; TST/PRD — allow-list or private endpoint per the security review decision; decide once at TST and keep PRD consistent.

Enable File Server only when file-exchange standards (folder layout, key custody — §6) are signed off.

Map OIC roles per environment: ServiceAdministrator → OCI-OIC-ADMIN; ServiceDeveloper → OCI-OIC-DEVELOPER + vendor groups in DEV only — in TST/PRD, nobody holds ServiceDeveloper (changes arrive via controlled promotion §5.3); ServiceMonitor → OCI-SUPPORT.

5.2 Project and connection standards (per workload)

Create one OIC project per business domain per direction, named <DOMAIN>-<SOURCE>-<TARGET> (integration identifiers <DOMAIN>-<SOURCE>-<TARGET>-<FUNCTION>); no integration lives outside a project.

Connections use service accounts only (svc-oic-<env>-<system>), credentials referenced from Vault secrets (§7); connection names <SYSTEM>_<ENV>.

Attach the global fault handler to every integration; faults route to the error queue with retry metadata; alert routing per SupportGroup tag (§8). No silent catch-and-continue.

5.3 Manual promotion procedure (DEV → TST → PRD)

Export the integration/project (IAR) from the source instance (Export), attach it to the change record together with test evidence.

Reviewer (second engineer) imports into the target instance with the environment config plan: substitute endpoints and Vault secret references — no hand-edits inside the IAR.

Activate in target; run the smoke test from the acceptance pack; record executor + reviewer + IAR checksum in the build log.

Nightly design-time export to the documentation repository (manual weekly minimum in Option A) — this is the recovery position for OIC.

5.4 Connectivity agent VM (only when integrating with on-prem/private endpoints)

Console path: Menu > Compute > Instances > Create Instance

Create VM <ENV>-OIC-VM-AGENT-01: Oracle Linux latest; shape per sizing (2 OCPU / 16 GB typical); subnet App-Processing-Subnet (private); NSG allowing egress 443 to OIC + the on-prem target ports via DRG; no public IP.

Install the OIC connectivity agent per the instance’s agent download (from the OIC console: Design > Agents > Download); register the agent group <ENV>-AGENT-GROUP-01.

For HA in PRD, install a second agent VM in a different fault domain, same agent group.

Patching ownership: InfraOps; monthly OS patching window recorded in O&M calendar.

6. File Exchange — File Server or SFTP VM

DECISION POINT:Prefer OIC File Server (managed, inside OIC) when OIC is licensed and throughput fits. Build a dedicated SFTP VM only when counterparties need plain SFTP outside OIC, custom ports, or volumes beyond File Server limits. Record which path this workload takes.

6.1 OIC File Server path

Enable File Server on the OIC instance (Settings > File Server) after standards sign-off.

Folder layout: OIC/<project>/{in,out,archive,error}; grants to groups only (no per-user shares except home directories).

Per counterparty: create an SFTP user, key-only authentication; public keys registered; private keys held by the counterparty; host key fingerprint communicated out-of-band. Key material references stored in Vault (SEC-SFTP-<PARTY>).

Retention: archive folder swept to <ENV>-OIC-BUCKET-FILEARCHIVE-01 after 90 days (scheduled OIC integration; in strict-manual interim, a logged monthly manual sweep).

6.2 SFTP VM path

Create VM <ENV>-PLATFORM-VM-SFTP-01: Oracle Linux; private subnet; NSG-<ENV>-SFTP-01 restricting 22 to named counterparty CIDRs; no public IP — counterparties arrive via FastConnect/VPN, or via a public load balancer + NAT pattern only with an explicit security review.

Harden: key-only SSH (PasswordAuthentication no), per-counterparty users with chroot to /sftp/<party>/{in,out}, internal-sftp subsystem only (no shell), fail2ban, OS firewall mirroring the NSG.

Ship auth and transfer logs to LOG-PLATFORM-01 (management agent / rsyslog).

7. Service Accounts and Vault Secrets

Create service accounts in the TARGET system, not OCI IAM, where possible: Fusion integration user (minimum roles for the interface), ATP DB users, SFTP users. Naming: svc-<service>-<env>-<purpose>.

For each credential create a Vault secret in PRD-PLATFORM-VAULT-CORE-01: SEC-OIC-<ENV>-FUSION-SVC, SEC-OIC-<ENV>-ATP-STG, SEC-SFTP-<PARTY>, … encrypted with KEY-MASTER-SECRETS-01.

Record per secret: owner, purpose, rotation date (≤ 90 days), consuming connections. The quarterly access review walks this register.

No credential may exist in OIC design-time properties, code, spreadsheets, or chat — Vault is the only store. Verify by inspecting each OIC connection: it must reference the secret, not embed the password.

8. Observability per Workload

Alarm	Condition	Severity	Destination
ALM-OIC-ERRORS-<ENV>	Integration error rate > threshold / error-queue arrivals	High (PRD) / Low (DEV)	Per SupportGroup tag
ALM-ATP-CPU-<ENV>	CPU > 80% sustained 15 min	Medium	InfraOps
ALM-ATP-STORAGE-<ENV>	Storage > 85%	Medium	InfraOps + DBA
ALM-VM-AGENT-<ENV>	Agent VM instance down / agent unreachable	High	InfraOps
ALM-SFTP-AUTHFAIL-<ENV>	Repeated auth failures on SFTP path	Medium	Security

Create alarms above via Monitoring > Alarms against the workload resources; destinations are Notifications topics per team DL.

Enable service logs: OIC activity stream, VM audit/auth logs, LB access logs → LOG-PLATFORM-01.

9. SaaS-Only Branch [SAAS]

When the customer procures only Fusion SaaS (no OCI platform components), Day 2 onboarding per pillar/pod reduces to the OCI-visible touchpoints:

Record the new pod in the environment matrix (pod name, pillar, environment, region) and in the SaaS handle compartment description. [CO-TENANTED] the handle compartment; [ISOLATED] in the SaaS tenancy register.

Federate the pod to <IDP> for SSO (Fusion admin executes in-pod; verify a pilot user reaches the pod via SSO+MFA).

Confirm announcement subscriptions cover Fusion service categories so quarterly-update notices reach the ops DL.

Add the pod to the P2T/T2P refresh calendar; after every refresh run the standing post-refresh procedure (§9.1).

No VCN, no NSG, no Vault work — skip §2–§8 entirely.

9.1 Standing post-refresh procedure (any customer with OIC/ATP/FDI attached to Fusion)

After every Fusion P2T refresh: re-point OIC connections in the affected non-prod instance (config plan swap of endpoints/credentials).

Refresh ATP cross-reference (XREF) data derived from the copied pod.

Re-baseline analytics (FDI non-prod) against the refreshed pod.

Re-run the affected workload smoke tests; record in the build log.

10. Workload Acceptance

#	Test	Pass criterion
1	End-to-end integration run in DEV (source → OIC → target incl. file leg and ATP write where present)	Succeeds; zero inline credentials (all connections reference Vault)
2	Forced fault	Error lands in error queue; alert routed per SupportGroup tag
3	Promotion DEV → TST via §5.3	Endpoints/credentials substituted by config plan; no manual IAR edits; four-eyes recorded
4	ATP connectivity matrix	1522 only from allowed NSG; wallet mTLS enforced
5	SFTP counterparty test file in/out	Key-only auth; chroot confined; transfer logged
6	Vendor isolation (where vendors build)	Vendor user sees only their workspace compartment
7	Tags complete on every created resource	Tag compliance report 100% for the workload
8	Alarms fire on simulated conditions	Delivery to correct DL observed
9	Build log + resource register updated; CD3 delta extract run (Doc 6)	As-built matches intake design; drift = 0

All green → workload accepted; change record closed; acceptance signed by the business owner and platform lead. Repeat this document per workload.

11. OPTION B — Workload Stacks via Terraform / OCI Resource Manager

Option B executes §2–§8 through the terraform_wl repository as ORM stacks driven by the Git CI/CD pipeline established in Doc 3 §7. The intake record (§1.1), design decisions, acceptance tests (§10), and the standing OIC content rules are unchanged — Terraform provisions the infrastructure; OIC design-time content (projects, integrations, connections) is NOT Terraform-managed and always promotes via IAR export/import (§5.3).

11.1 Repository standard — terraform_wl

Stack	Contents	Implements runbook section
stack3	oic_connectivity_agent · oic_paloaltovm (prod/nonprod variants)	§5.4 connectivity agent VM; hub firewall VM where the hub-spoke design uses one
stack4	objectstorage (prod/nonprod)	§4.2 buckets (versioning, lifecycle, CMK encryption)
stack5	atp (prod/nonprod)	§4.1 ATP (private endpoint, NSG, auto-scaling, backup settings)
stack6	dns_private_views · hub/spoke vcn_dns_resolver (prod/nonprod)	Doc 3 §5.2 DNS zones + resolver endpoints/rules for hybrid name resolution
stack7	application_loadbalancer · private/public network_loadbalancer (prod/nonprod)	§3 partner-facing endpoints (LB patterns feeding NSG-<ENV>-LB-01)
stack8	oic_integration_instance (prod/nonprod)	§5.1 OIC instance provisioning (edition, shape, message packs, network access)
stack9	hub_resource_alarms · workload_alarms (prod/nonprod)	§8 observability per workload

Repo name: <customer>-oci-terraform-wl, same branch model and protections as the LZ repo (Doc 3 §7.3); CODEOWNERS route LB/DNS changes to network reviewers, ATP to DBA, alarms to platform.

Per-workload values: a workload onboarding = a feature branch editing the target stack’s tfvars (new bucket entry, new NSG-referenced LB listener, ATP schema parameters…), carrying the intake record ID in the PR/MR title.

Out of Terraform scope, always: OIC design-time content (IAR promotion §5.3), Vault secret VALUES (create the secret resource by stack if modeled, but set values manually per §7 — secret material never enters Git or tfvars), SFTP OS hardening (§6.2 remains a manual/hardening-checklist activity on the stack-built VM), Fusion-side service accounts.

11.2 ORM stack setup (per workload environment)

Reuse the Configuration Source Provider from Doc 3 §7.2 (GitHub in Phase 1, GitLab in Phase 2).

Create ORM stacks per stack-folder per environment: STK-WL-<STACK>-<ENV> (e.g., STK-WL-ATP-PRD from working directory terraform_wl/stack5/prod_atp), compartment Shared-Services:Shared-Tools; variables from the intake record via the schema.yaml form.

Extend the pipeline’s stack-mapping so changed paths under terraform_wl/* trigger the matching ORM stack — identical plan-on-PR / approve / apply-from-plan flow as Doc 3 §7.3 (Phase 1 GitHub Actions) and §7.4 (Phase 2 GitLab CI). PRD stacks bind to the protected environment gate.

Grant coverage: add the workload resource families to the pol-root-iac / OCI-IAC-ADMIN policy set as stacks demand them (integration-instance-family, autonomous-database-family, object-family, load-balancer-family, dns, instance-family, alarms) — via Security-reviewed change, never ad hoc.

11.3 Per-workload Option B flow (DEV → TST → PRD)

Branch from develop: feature/<intake-id>-<workload>; edit nonprod stack tfvars for DEV values.

PR/MR:validate + ORM plan comment; reviewer checks the plan against the intake record (resources, names per Doc 1 §8, tags per Doc 1 §9 — plan output showing missing tags is a rejection).

Approve + merge → apply to DEV; run §10 acceptance tests 1–2, 4–8 against the DEV build.

Post-infrastructure manual steps: set Vault secret values (§7), OIC role mappings (§5.1 step 5), agent registration (§5.4), SFTP hardening (§6.2) — logged in the build log as in Option A.

Promote: PR editing TST values (or the prod_* stack folder for PRD) — same review loop; PRD applies require the protected-environment approval. OIC content follows separately via IAR + config plan (§5.3), sequenced AFTER the infrastructure apply.

Close out: acceptance record links intake ID → PR/MR IDs → plan/apply job IDs → test evidence; CD3 delta extract (Doc 6) confirms as-built = design.

VERIFY:Option B workload acceptance adds to §10: every provisioned resource appears in the ORM state of exactly one stack (no console orphans — ORM drift detection returns NO_DRIFT); pipeline history shows plan-before-apply for every change; no secret value appears in Git history, tfvars, or plan logs.

Revision History

Version	Date	Description
1.0	<DATE>	Generic template — per-workload manual onboarding, console click-path edition.
1.1	<DATE>	Added Option B: terraform_wl stacks (stack3–stack9) via OCI Resource Manager with Git CI/CD — Phase 1 GitHub, Phase 2 GitLab. OIC design-time content and secret values remain outside Terraform.