I85PREP
⌘ K
OCI Architect Associate study materials
OCI Architect Associate study resources

Restoring Object Storage access and closing a database exposure in a three-tier VCN

OCI Architect Associate · Put your knowledge to work in context.

All case studies

Restoring Object Storage access and closing a database exposure in a three-tier VCN

A retail platform runs a three-tier workload in one VCN (10.20.0.0/16): a public web subnet (10.20.1.0/24), a private app subnet (10.20.2.0/24) and a private database subnet (10.20.3.0/24). Security lists are wide open - every subnet allows all protocols from 10.20.0.0/16 and 172.16.0.0/12. The app tier stopped uploading logs after the team removed the internet gateway route to reduce exposure; app servers now time out writing to Object Storage. Separately, an auditor flagged that the database accepts connections from any host in the on-premises estate (172.16.0.0/16), although only the batch host 172.16.4.10 should reach port 1521. On-premises reaches OCI through a DRG and FastConnect. There is no service gateway yet, and nothing is tagged.

1. Log ingestion to Object Storage is broken after the internet route was removed. What network and identity changes restore it, and why is each one required?

Read the worked answer

What actually broke. Object Storage is consumed through its regional service endpoint. Deleting the internet gateway route removed the only path the app subnet had, so the servers have no exit at all.

Fix part 1 - the network path.

  • Create a service gateway in the VCN (it is a VCN-level, regional resource; one is enough for all subnets).
  • Add a route rule to the app subnet's route table: destination = the OCI Services CIDR for the region (the console entry All <region> Services in Oracle Services Network), target = the service gateway.
  • Leave 0.0.0.0/0 unrouted for that subnet, or point it at a NAT gateway later if the hosts need internet-based patching. A NAT gateway gives outbound-only internet and is not needed for Object Storage.
  • Result: traffic stays on the OCI backbone, no public IP or internet gateway is reintroduced.

Fix part 2 - authorization. The gateway only routes; Object Storage still evaluates IAM on every API call. Create a dynamic group whose rule matches the app instances (for example by instance compartment plus a defined tag), then grant the narrowest verb: read objects for the log bucket's compartment, or manage objects in the bucket if uploads and overwrites are needed. Use instance principals; do not copy user API keys onto the hosts.

Validate. If egress rules were tightened, allow TCP 443 to the service CIDR. Then test from one app host and confirm the object appears in the bucket - a routing fix alone with no policy will fail with a 404/401, which is the classic misdiagnosis here.

2. A junior engineer proposes attaching an NSG to the database VNIC with a single ingress rule for 172.16.4.10/32 on port 1521, and changing nothing else. Does that satisfy the auditor? Justify your answer and give the complete design.

Read the worked answer

No. In OCI, security lists (subnet scope) and network security groups (VNIC scope) are additive for allow rules - the effective rule set for a VNIC is the union of its subnet's security list rules and the rules of every NSG attached to it. The database subnet's security list currently allows all protocols from 172.16.0.0/12, so any on-premises host is still permitted regardless of what the NSG says. The finding stays open.

Complete design.

  1. Tighten the security list on the DB subnet. Remove the 172.16.0.0/12 ingress rules. Keep only what is genuinely subnet-wide (for example ICMP path MTU, or nothing).
  2. Use the NSG for the fine-grained intent. Attach nsg-db to the database VNIC(s) and allow:
    • ingress TCP 1521 from 172.16.4.10/32 (the batch host),
    • ingress TCP 1521 from nsg-app (NSG-to-NSG reference) if the application tier connects directly.
  3. Confirm source preservation. Traffic arrives over FastConnect/DRG with the original source address; there is no NAT, so a /32 is valid. If on-premises NATs behind a shared address, allow the NAT address instead - a /32 would then break the batch job.
  4. Egress. The database still needs 443 to Object Storage for backups - keep the service gateway route and, if egress was tightened, an explicit egress rule.
  5. Prove it. Test from 172.16.4.10 (should connect) and from a second on-prem host in 172.16.0.0/16 (should time out). A rule set that is only verified by a successful connection is not verified.