Use this for last-mile review. Keep it beside mixed architecture questions and pair it with the Resources when you need exact Oracle product wording. Strong 1Z0-1072-25 answers usually start by deciding whether the stem is about governance scope, network path, security filter, service fit, resilience, or operations evidence.
Read every architecture stem in this order
- Identify the boundary: tenancy, compartment, VCN, subnet, route, security rule, or service.
- Decide whether the requirement is exposure, connectivity, scale, resilience, recovery, cost, or governance.
- Place public edge resources separately from private app and data tiers.
- Choose the simplest managed service that satisfies the stated workload.
- Verify monitoring, audit, backup, and ownership before calling the design complete.
OCI architect placement map
flowchart LR
U["Users / Internet"] --> W["WAF or public edge"]
W --> LB["Public Load Balancer"]
LB --> APP["Private app tier"]
APP --> DB["Private database tier"]
ONP["On-premises"] --> DRG["DRG"]
DRG --> APP
Architect cue: public exposure belongs at the edge, app and database tiers usually stay private, and hybrid connectivity enters through the routing hub rather than through ad hoc public paths.
OCI answer sequence
Use this when the stem mixes ingress, async delivery, reliability, security, or operations.
flowchart TD
S["Scenario"] --> I["Classify the interaction mode"]
I --> E["Pick API Gateway, Events, Notifications, Streaming, or Functions"]
E --> R["Check retry, idempotency, ordering, and dead-letter behavior"]
R --> S2["Check Vault, IAM, private exposure, logs, and auditability"]
Fast lane picker
| If the question is mostly about… |
Start with… |
Usual winning move |
| public vs private exposure |
subnet and edge placement |
isolate the edge from the private tiers |
| where traffic should go |
route tables and gateways |
path first, then filters |
| which security control to use |
NSGs vs Security Lists |
choose the narrower scope that fits |
| cross-VCN or on-prem connectivity |
DRG, VPN, FastConnect |
pick based on path and reliability needs |
| compute, storage, or database fit |
workload pattern |
choose by access model and operations burden |
| resilience |
AD, FD, load balancer, backups |
remove single points of failure |
| governance |
tenancy, compartments, policies, tags |
control scope before network scope |
| troubleshooting |
path, filter, identity, then service health |
prove each layer before rebuilding |
Tenancy, IAM, and compartment map
| Need |
Stronger first fit |
| organize resources by team or environment |
compartments |
| grant access by role and scope |
policies tied to groups or dynamic groups |
| let OCI resources call OCI APIs |
dynamic groups and matching policies |
| track ownership and cost |
tagging standards |
| reduce blast radius |
compartment boundaries plus least-privilege policy |
IAM and governance traps
| Trap |
Better reading |
| using compartments as network isolation |
compartments govern resources; VCN/subnets route traffic |
| granting tenancy-wide admin for convenience |
scope policy to the compartment and action needed |
| solving access failure with route changes |
network reachability is not authorization |
| treating tags as cosmetic |
tags often support cost, ownership, and compliance evidence |
| forgetting dynamic groups |
resource principals need policy just like humans do |
Network path chooser
| Requirement |
Prefer |
Why |
| public app entry point |
public load balancer in a public subnet |
controlled edge ingress |
| private subnet outbound internet access |
NAT Gateway |
outbound only |
| private access to Oracle services |
Service Gateway |
no public internet path |
| internet path for public resources |
Internet Gateway |
public route target |
| VCN-to-VCN or on-prem routing |
DRG |
central routing attachment |
| private name resolution |
DNS resolver/private zone pattern |
names must match the private path |
| traffic distribution |
load balancer |
health-checked entry to backend pools |
Gateway quick map
| Gateway or attachment |
Best mental model |
| Internet Gateway |
public internet route for public resources |
| NAT Gateway |
private resources initiate outbound internet connections |
| Service Gateway |
private access to supported Oracle services |
| DRG |
hub for on-prem, FastConnect, VPN, and VCN attachments |
| Local Peering Gateway |
VCN-to-VCN path in compatible local scope |
| Remote peering |
VCN-to-VCN path across regions through DRG-style design |
Security Lists vs NSGs
| You need… |
Prefer |
Why |
| quick subnet-wide rules |
Security Lists |
broad subnet-level control |
| app-tier, instance-tier, or component-tier granularity |
NSGs |
cleaner least-privilege segmentation |
| easier multi-tier policy reasoning |
NSGs |
map rules to workloads instead of whole subnets |
Network decision traps
| Trap |
Better answer |
| route table treated as firewall |
route tables choose next hop; security rules permit traffic |
| NSG and Security List both changed blindly |
change the narrowest layer that owns the problem |
| public IP added to fix private access |
fix private route, DNS, and security controls first |
| one route table reused everywhere |
subnet-specific routing often clarifies tier boundaries |
| missing return path |
both directions of routing and security must work |
Connectivity chooser
| Requirement |
Prefer |
Why |
| lower-cost hybrid start |
IPSec VPN |
faster setup, internet-based |
| more predictable private enterprise connectivity |
FastConnect |
dedicated connectivity path |
| multi-VCN hub-and-spoke |
DRG-centered design |
centralizes routing decisions |
| regional internet-facing architecture |
edge plus load balancer |
simpler than exposing each component |
| low-latency private enterprise path |
FastConnect |
more predictable than internet VPN |
| quick proof-of-concept hybrid link |
IPSec VPN |
faster to establish when requirements permit |
Load balancing and edge chooser
| Requirement |
Stronger first fit |
| distribute public HTTP(S) traffic |
public load balancer plus private backend tier |
| distribute internal tier traffic |
private load balancer |
| protect web edge |
WAF or edge security controls before backend changes |
| verify backend availability |
health checks and backend-set status |
| avoid single instance dependency |
multiple backends across FD/AD where available |
Core service selection
| Requirement |
Prefer |
Why |
| general application workload |
Compute VM |
default compute lane |
| specialized performance or isolation |
bare metal shapes |
dedicated host-style cue |
| managed Kubernetes architecture |
OKE |
container platform answer |
| event-driven serverless code |
Functions |
run code without server management |
| simple container runtime without owning nodes |
managed container/service option where applicable |
reduce operations burden when Kubernetes is overkill |
| scalable stateless tier |
instance pool or autoscaling pattern |
replaceable compute beats pet servers |
Storage
| Requirement |
Prefer |
Why |
| VM disks and attached storage |
Block Volumes |
block semantics |
| logs, backups, artifacts, media |
Object Storage |
durable object store |
| shared POSIX-style filesystem |
File Storage |
shared file access |
| cold retention |
Archive Storage |
cheap long-term storage |
| high-performance attached volume |
Block Volume with proper performance setting |
block semantics and tuning lane |
| lifecycle-driven retention |
Object Storage lifecycle policy |
cost and retention control |
Database
| Requirement |
Prefer |
Why |
| managed automation and reduced admin effort |
Autonomous Database |
simplified operations |
| more direct database configuration control |
DB System |
hands-on administration lane |
| exam scenario framed around architecture simplicity |
managed service first |
associate-level architect questions reward simpler strong fits |
| NoSQL key-value/document-style access |
NoSQL service fit where scenario demands it |
access pattern drives database choice |
| cache-heavy read path |
cache/service layer before scaling database blindly |
reduce repeated backend pressure |
Service-selection traps
| Trap |
Better answer |
| selecting Kubernetes for every container |
OKE adds power and operational responsibility |
| picking bare metal for every performance complaint |
verify isolation or hardware requirement first |
| using Object Storage for block-device semantics |
object, file, and block storage solve different access patterns |
| choosing DB System when automation is the stated goal |
Autonomous Database often better fits reduced-admin requirements |
| scaling the database before checking app and connection behavior |
architecture questions reward bottleneck classification |
Resilience and placement rules
| Requirement |
Better answer |
| keep app tier resilient within a region |
spread instances across fault domains or ADs and use health-checked load balancing |
| avoid direct database exposure |
keep DB tier private and reach it from the app tier |
| survive component failure |
design for replacement and reroute, not manual heroics |
| survive data loss or operational mistakes |
ensure backups and durable storage choices are explicit |
| reduce maintenance impact |
distribute stateless compute across fault domains or availability domains |
| recover from regional event |
cross-region backup, replication, or standby pattern with runbook |
HA, backup, and DR chooser
| Requirement |
Better design cue |
| instance failure |
instance pool, autoscaling, health checks, load balancer |
| AD-level resilience |
place across ADs where region supports it |
| data deletion or corruption |
backup and restore path |
| lower downtime for database tier |
standby or highly available database design |
| disaster recovery |
define RPO, RTO, region, DNS cutover, and operator steps |
Resilience traps
| Trap |
Better answer |
| backup equals high availability |
backup helps recovery; HA reduces service interruption |
| load balancer protects stateful database writes by itself |
backend architecture and data layer still matter |
| spreading across FD while sharing one failing dependency |
remove single points of failure end to end |
| replication without failover runbook |
recovery must be operationally testable |
Observability and operations cues
| Need |
Service or concept |
What to remember |
| health and thresholds |
Monitoring and Alarms |
detect and notify |
| event records and troubleshooting |
Logging |
operational visibility |
| who changed what |
Audit |
API activity trail |
| cost guardrails |
Budgets and Tags |
control and attribution |
| security posture |
Cloud Guard or security findings |
detect risky configuration |
| safe provisioning |
Resource Manager or IaC pattern |
repeatable and reviewable changes |
Troubleshooting order
| Symptom |
Check first |
| public app down |
DNS, load balancer listener, backend health, route, security rules |
| private instance unreachable |
route table, NSG/security list, bastion/path, OS firewall |
| object storage access denied |
IAM policy, bucket policy, key access, service gateway if private |
| unexpected bill |
tags, budgets, idle compute, block volumes, egress, oversized shapes |
| deployment drift |
Resource Manager state, manual changes, and policy differences |
| database connection failure |
endpoint, subnet route, security rule, credential, database state |
Common architecture traps
| Trap |
Better answer |
| putting databases in public subnets because “admins need access” |
keep DB private and use safer management paths |
| using route tables as a security boundary |
route tables choose destinations; NSGs and Security Lists filter traffic |
| using Service Gateway as generic internet access |
it is for Oracle services, not public web access |
| choosing the most complex connectivity option automatically |
choose the simplest design that satisfies exposure, latency, and reliability requirements |
| mixing compartment strategy with subnet placement |
compartments govern, subnets place networked resources |
| assuming private subnet means no outbound internet path |
NAT or service gateway can provide controlled outbound paths |
| using public IPs for operational convenience |
safer management paths usually exist |
Decision order that usually wins
- Classify the problem: IAM/governance, network path, security filter, service fit, resilience, operations, or cost.
- Place the public edge, private app tier, and private data tier deliberately.
- Pick gateway, route, DNS, and security controls as one path.
- Choose managed services when they satisfy the requirement with less operational burden.
- Add monitoring, audit, backup, tagging, and runbook ownership before finalizing.
Last 15-minute review
| If you only have time for one pass… |
Remember this |
| edge pattern |
internet users hit the public edge, not the database |
| route vs security |
gateways and routes create paths; NSGs and Security Lists constrain traffic |
| IGW vs NAT vs Service Gateway vs DRG |
public internet, private outbound internet, private Oracle-services access, routed network hub |
| VM vs OKE vs Functions |
classic compute, managed containers, event-driven serverless |
| resilience |
spread tiers, load balance stateless services, back up the data layer |
| compartment vs subnet |
governance boundary vs network placement boundary |
| backup vs HA |
recovery from loss vs reduced interruption |
What strong 1Z0-1072-25 answers usually do
- decide first whether the question is about exposure, routing, security scope, service choice, or resilience
- keep public edge components separate from private application and database tiers
- choose the narrowest working control instead of the broadest possible one
- prefer simpler managed designs when they satisfy the stated architectural requirement
- prove route, DNS, and security-rule alignment before blaming workloads
- include monitoring, audit, backup, tags, and runbooks as architecture requirements