# Lab Architecture

## Objective

Create a secure and repeatable OCI foundation to demonstrate Oracle Deep Data Security for AI, analytics, and enterprise application workloads.

## Logical Design

```mermaid
flowchart LR
  User["End User / Analyst"] --> App["Application or AI Agent"]
  App --> PE["Database Private Endpoint"]
  BI["BI Tool / SQL Client"] --> PE
  PE --> ADB["Oracle AI Database / Autonomous Database"]
  ADB --> Policies["Deep Data Security Data Grants"]
  ADB --> Audit["Unified Audit / Evidence"]
  KMS["OCI Vault / Optional KMS"] --> ADB
  Admin["DBA Operations"] --> Bastion["Optional Bastion"]
  Bastion --> PE
```

## Components

| Layer | Component | Purpose |
| --- | --- | --- |
| Network | VCN, private subnet, NSGs | Isolate database and application flows. |
| Database | Private Autonomous Database | Run lab schemas, policies, and tests. |
| Security | Deep Data Security | Enforce authorization by user, role, and context. |
| Keys | Optional OCI Vault | Enable customer-managed keys when required. |
| Operations | Optional compute bastion | Controlled administrative access when required. |
| Evidence | SQL output, logs, screenshots | Support technical validation and demos. |

## Security Principles

- No public database exposure.
- Access through private subnet and NSG rules.
- mTLS required.
- Secrets kept out of Git.
- Minimum privileges for OCI resources.
- Data policies versioned as SQL.
- Preventive controls first; auditing for evidence and investigation.

## What Terraform Does Not Configure

Terraform provisions infrastructure. Fine-grained configuration such as users, data roles, data grants, and test data stays under `scenarios/` so each lab can be installed and reset without recreating the OCI environment.