Private Connectivity and Authentication for a Bursty Order Service
Contoso has an order service in an OCI VCN (10.20.0.0/16) and a legacy reporting application in a datacenter connected by 1 Gbps FastConnect. They are provisioning a 12-ECPU Autonomous Transaction Processing instance and must keep all database traffic off the public internet. The application tier runs 40 pods, each opening 25 connections, and the vendor refuses a wallet file because its deployment pipeline cannot distribute secrets to ephemeral pods. The network team can create a private subnet, NSG, DRG, and route rules. During a pilot, connections through the public endpoint intermittently time out at peak, and the security team rejects the public endpoint. The database must accept connections only from the VCN and the datacenter's 10.10.0.0/16 range. The project needs a design that supports pod churn and a monthly four-hour reporting job.
1. Design the network path and endpoint. Which OCI components are required, and what should be explicitly denied?
Read the worked answer
Use an Autonomous Database private endpoint placed in a dedicated private subnet of the 10.20.0.0/16 VCN. Attach an NSG to the endpoint that allows the application subnet and 10.10.0.0/16 on the database listener port, and deny everything else. The application pods reach the endpoint over the VCN's private routing. The datacenter reaches it through FastConnect to the DRG, then a route rule for the endpoint subnet; the return path must also be advertised. Do not enable or use the public endpoint, and do not rely on the public endpoint plus an allowlist. Use the private connection string and private DNS resolution so pods do not need hard-coded IPs. Validate with a canary from one pod and one datacenter host before changing the service. The key judgment is that a private endpoint changes both the data path and the DNS/connection string; keeping the old public string in a config map will recreate the original timeout symptom.
2. The vendor cannot distribute an mTLS wallet to ephemeral pods. What authentication option would you recommend, and what compensating controls are required?
Read the worked answer
Recommend TLS authentication with a restrictive access control list if the security policy permits it, because it removes the per-pod wallet distribution problem. TLS still encrypts traffic, but it authenticates by network location rather than a client certificate, so the ACL must allow only the application subnet and 10.10.0.0/16 and must be maintained as the pod CIDR changes. Do not widen the ACL to the whole VCN or 0.0.0.0/0 to accommodate pod churn. If policy mandates mTLS, put a small connection proxy or pool inside the VCN that holds the wallet; pods connect to the proxy without a wallet, and the proxy connects to ADB with mTLS. That keeps certificates off ephemeral pods and centralizes rotation. In either design, use a private endpoint, restrict the NSG, and log connection sources. The trade-off is explicit: TLS plus ACL is simpler but weaker against IP spoofing inside the allowed ranges; mTLS plus proxy is stronger but adds a tier to operate.
3. How would you address the connection volume and ensure the monthly reporting job does not disrupt order traffic?
Read the worked answer
Forty pods at 25 connections each is 1,000 possible sessions, which is unnecessary for short order transactions and creates connection-storm and memory pressure. Reduce each pod to a small pool, set a maximum pool size, and use a pool that validates connections and retries cleanly during pod churn. Keep the order path on TP, and run the monthly reporting job on MEDIUM or HIGH with a parallel degree limit and a consumer-group cap. Do not let reporting use TPURGENT or an uncapped HIGH group. Schedule the job outside the order peak if possible, and test the actual four-hour window with production-like data. Monitor sessions by consumer group, run-queue waits, and p99 latency during the test. The judgment is that a larger pool does not improve throughput once the database is the bottleneck; it only makes failures larger. Pooling discipline plus service-level separation addresses both symptoms.