OCI Architect Associate (1Z0-1072-24) - Fact Sheet¶

Quick Reference¶

Exam Code: 1Z0-1072-24 Duration: 105 minutes Questions: 60 questions Passing Score: 68% Cost: $150 USD Validity: 18 months (non-renewing) Delivery: Pearson VUE (Testing center or online proctored) Prerequisites: None (OCI Foundations recommended)

Official Documentation Links¶

Core Documentation¶

Identity and Access Management¶

Networking¶

Compute¶

Storage¶

Database¶

Security¶

Monitoring and Management¶

Additional Services¶

Exam Topic Breakdown¶

Topic	Weight	Focus Areas
Identity and Access Management	10%	Policies, dynamic groups, federation, identity domains
Networking	25%	VCN design, routing, gateways, load balancing, peering
Compute	15%	Instances, shapes, autoscaling, instance pools
Storage	15%	Block volumes, object storage, file storage, backups
Database	10%	Autonomous DB, DB Systems, Data Guard, backups
Security	15%	Vault, Cloud Guard, security zones, encryption, bastion
Observability and Management	10%	Monitoring, logging, alarms, events, cost management

OCI Architecture Principles¶

Well-Architected Framework Pillars¶

1. Operational Excellence - Automate processes with Infrastructure as Code - Use Resource Manager (Terraform) for deployment - Implement monitoring and alerting - Regular backup and disaster recovery testing - Document architecture and runbooks

2. Security - Apply defense-in-depth strategy - Use least privilege access (IAM policies) - Encrypt data at rest and in transit - Enable Cloud Guard and Security Zones - Regular security audits and compliance checks

3. Reliability - Design for failure (multi-AD deployment) - Use fault domains for redundancy - Implement automated backups - Configure Data Guard for databases - Use load balancers for traffic distribution

4. Performance Efficiency - Choose appropriate compute shapes - Use autoscaling for dynamic workloads - Optimize storage tiers for access patterns - Implement caching strategies - Monitor and tune performance metrics

5. Cost Optimization - Right-size resources based on utilization - Use Reserved Instances for predictable workloads - Leverage BYOL for Oracle licenses - Implement lifecycle policies for storage - Monitor costs with budgets and alerts

Core Services Deep Dive¶

Identity and Access Management (IAM)¶

Key Concepts: - Users: Individual identities (employees, applications) - Groups: Collections of users with similar access needs - Dynamic Groups: Collections of resources (instances, functions) that match rules - Policies: Rules defining who can access what resources - Compartments: Logical containers for organizing resources - Identity Domains: SAML 2.0 federation with external IdPs

Policy Structure:

Allow <subject> to <verb> <resource-type> in <location> where <conditions>

Policy Verbs (Least to Most Privilege): 1. inspect: List resources 2. read: View resource details 3. use: Use resource (e.g., attach volume) 4. manage: Full control (all operations)

Common Policy Examples:

# Allow developers to manage compute in Dev compartment
Allow group Developers to manage instance-family in compartment Dev

# Allow network admins to manage all networking
Allow group NetworkAdmins to manage virtual-network-family in tenancy

# Allow instances to read secrets from Vault
Allow dynamic-group AppServers to read secret-family in compartment Production

# Allow users to inspect all resources
Allow group Auditors to inspect all-resources in tenancy

Dynamic Group Matching Rules:

# Match all instances in a compartment
instance.compartment.id = 'ocid1.compartment...'

# Match instances with specific tags
tag.Environment.value = 'Production'

# Match multiple conditions (AND)
All {instance.compartment.id = 'ocid1...', tag.AppType.value = 'WebServer'}

# Match any condition (OR)
Any {instance.compartment.id = 'ocid1...', instance.compartment.id = 'ocid2...'}

Networking Architecture¶

VCN Design Principles: - Use /16 CIDR for VCN (65,536 addresses) - Subnet public resources in /24 public subnets - Subnet private resources in /24 private subnets - Reserve address space for future growth - Plan for VCN peering and hybrid connectivity

VCN Components:

1. Subnets: - Public Subnet: Has route to Internet Gateway - Private Subnet: No route to Internet Gateway - Regional or AD-specific (regional recommended) - CIDR block: /16 to /30

2. Gateways:

Gateway Type	Purpose	Traffic Direction	Use Case
Internet Gateway (IGW)	Public internet access	Inbound + Outbound	Web servers, public APIs
NAT Gateway	Private internet access	Outbound only	Updates, patches, API calls
Service Gateway	Private OCI service access	Outbound only	Object Storage, Autonomous DB
Dynamic Routing Gateway (DRG)	On-premises connectivity	Bidirectional	VPN, FastConnect, peering

3. Peering:

Local Peering (Same Region): - Connect VCNs in same region - Uses Local Peering Gateway (LPG) - Private IP communication - No bandwidth charges - Setup: Create LPG in each VCN, establish connection

Remote Peering (Different Regions): - Connect VCNs across regions - Uses Dynamic Routing Gateway (DRG) - Private IP communication - Standard data transfer charges apply - Setup: Create DRG in each VCN, establish Remote Peering Connection (RPC)

Transit Routing: - Hub-and-spoke topology - Central VCN acts as hub - Spoke VCNs connect to hub via DRG - Hub routes traffic between spokes and on-premises - Use cases: Centralized firewall, shared services

4. Load Balancing:

Load Balancer (Layer 7): - HTTP/HTTPS traffic - SSL/TLS termination - Path-based routing - Session persistence (sticky sessions) - Health checks - WebSocket support - Shapes: Flexible (bandwidth-based billing)

Network Load Balancer (Layer 4): - TCP/UDP traffic - High performance (millions of requests/sec) - Ultra-low latency - Preserve client IP address - Health checks - Use case: Non-HTTP protocols, extreme performance

5. Security:

Security Lists (Subnet-Level): - Stateful firewall rules - Apply to all resources in subnet - Allow and deny rules - Direction: Ingress and egress - Default: Deny all

Network Security Groups (Resource-Level): - Stateful firewall rules - Apply to specific resources (VNICs) - Allow rules only (implicit deny) - More flexible than security lists - Recommended for granular control

Best Practice: Use NSGs for resource-level security, keep security lists simple

Compute Services¶

Instance Types:

1. Virtual Machines (VM): - Shared physical infrastructure - Multiple VMs per host - Cost-effective - Flexible sizing - Boot volumes are detachable

2. Bare Metal (BM): - Dedicated physical server - Full control over hardware - No virtualization overhead - High performance - Licensing flexibility (per-core licensing)

3. Dedicated VM Hosts: - Isolated physical server for VMs - Meets compliance requirements - Dedicated capacity - Control over placement - BYOL licensing benefits

Compute Shapes:

Shape Family	Type	Use Case	Processor
VM.Standard	General purpose	Balanced workloads	AMD, Intel, Ampere
VM.DenseIO	Storage-optimized	High I/O, databases	AMD with local NVMe
VM.GPU	GPU-accelerated	ML, rendering, HPC	NVIDIA A10, A100
VM.Optimized	Compute/memory	Specialized workloads	AMD, Intel
BM.Standard	Bare metal general	High performance	AMD, Intel
BM.GPU	Bare metal GPU	ML training, HPC	NVIDIA A100, H100

Flexible Shapes: - Customize OCPU and memory - Example: VM.Standard.E4.Flex (1-64 OCPUs, 1-1024 GB RAM) - Right-size for your workload - Adjust resources without recreating instance

Instance Configuration: - Template for creating instances - Defines shape, image, networking, storage - Used with instance pools and autoscaling - Immutable (create new version for changes)

Instance Pools: - Group of identical instances - Span multiple ADs (high availability) - Scale manually or with autoscaling - Common configuration via instance config - Use case: Web tier, application tier

Autoscaling: - Automatically scale instance pools - Scale-out and scale-in policies - Metric-based (CPU, memory, custom) - Schedule-based (time of day, day of week) - Cool-down period between scaling actions - Min and max instance count

Instance Lifecycle: 1. Provisioning: Creating instance 2. Running: Instance is active 3. Stopping: Graceful shutdown initiated 4. Stopped: Instance is halted (no compute charges) 5. Starting: Booting instance 6. Terminating: Deleting instance 7. Terminated: Instance is deleted

Boot Volume Management: - Boot volumes are detachable - Backup boot volumes regularly - Clone boot volumes for testing - Preserve boot volume when terminating instance - Attach boot volume to new instance

Storage Architecture¶

Storage Service Comparison:

Feature	Block Volume	Object Storage	File Storage	Archive Storage
Protocol	iSCSI	HTTP/REST	NFS v3	HTTP/REST
Access	Instance-attached	Internet/API	Network-mounted	Internet/API
Performance	Very high	High	High	N/A (retrieval)
Size limit	32 TB per volume	10 TB per object	8 EB per filesystem	Unlimited
Use case	Boot/data disks	Unstructured data	Shared filesystem	Long-term archive
Cost	Moderate	Low	Moderate	Very low

Block Volume Details:

Performance Tiers: | Tier | IOPS/GB | Throughput/GB | Use Case | |------|---------|---------------|----------| | Lower Cost | 2 | 240 KB/s | Dev/test, backups | | Balanced | 60 | 480 KB/s | General workloads | | Higher Performance | 75 | 600 KB/s | Production databases | | Ultra High Performance | 225 | 2,680 KB/s | Mission-critical DBs |

Block Volume Features: - Volume Cloning: Create copy of volume (fast, space-efficient) - Volume Groups: Manage multiple volumes together - Cross-Region Backup: Copy backups to other regions - Cross-Region Replication: Async replication for DR - Backup Policies: Automated backup scheduling - Encryption: Always encrypted at rest (Oracle or customer-managed keys)

Object Storage Details:

Storage Tiers: 1. Standard: Frequent access, instant retrieval, hot data 2. Infrequent Access: Occasional access, instant retrieval, 50% cost savings 3. Archive: Rare access, 1-hour retrieval, 90% cost savings

Object Storage Features: - Lifecycle Policies: Automatically move objects between tiers or delete - Pre-Authenticated Requests (PAR): Time-limited access URLs without auth - Versioning: Keep multiple versions of objects - Object Events: Trigger events on object create/update/delete - Multi-part Upload: Upload large files in parallel chunks - Private Buckets: No public access (default) - Public Buckets: Publicly readable (optional)

Lifecycle Policy Example:

Rule 1: Move to Infrequent Access after 90 days
Rule 2: Move to Archive after 365 days
Rule 3: Delete after 2555 days (7 years)

File Storage Details: - NFS v3 protocol - Mount from multiple instances simultaneously - Regional service (highly available) - Snapshots for point-in-time recovery - Encryption at rest - Use cases: Shared application data, content management, home directories

Database Services¶

Autonomous Database:

Workload Types: 1. ATP (Autonomous Transaction Processing): - OLTP workloads - High concurrency - Mixed workload (OLTP + analytics) - JSON document support

ADW (Autonomous Data Warehouse):
OLAP/analytics workloads
Data warehouse
Business intelligence
Machine learning
APEX (Application Express):
Low-code application development
Built on ATP
Web application platform

Deployment Options:

Serverless: - Shared Exadata infrastructure - Pay-per-use (OCPU-hours + storage) - Auto-scaling (up to 3x) - Quick provisioning - Lower cost for variable workloads

Dedicated: - Isolated Exadata infrastructure - Full control over maintenance schedules - Meets compliance requirements - Predictable performance - Higher cost, dedicated capacity

Autonomous Database Features: - Auto-scaling: Automatically increase OCPUs during high demand - Auto-backup: Daily automatic backups (60-day retention) - Auto-patching: Quarterly updates with zero downtime - Autonomous Data Guard: Standby database in another region - Tools: SQL Developer Web, APEX, Oracle ML - Access: SQL*Net, HTTPS, REST APIs

DB Systems:

Deployment Types: 1. VM DB Systems: - Virtual machine database - 1-node or 2-node RAC - Lower cost - Standard or Enterprise editions

Bare Metal DB Systems:
Physical server database
1-node or 2-node RAC
High performance
Enterprise or Enterprise Extreme Performance editions
Exadata DB Systems:
Exadata infrastructure
Quarter Rack, Half Rack, Full Rack
Extreme performance
Enterprise Extreme Performance edition

High Availability Options: - RAC (Real Application Clusters): Active-active cluster (2 nodes) - Data Guard: Standby database for DR (primary + standby) - Backup and Recovery: Automatic daily backups to Object Storage

Backup Options: - Automatic Backups: Daily full backups + archival logs (7-60 day retention) - Manual Backups: On-demand backups (keep until manually deleted) - Cross-Region Backup: Copy backups to another region for DR

Security Architecture¶

Defense-in-Depth Strategy:

Layer 1: Identity (IAM) - Least privilege access policies - MFA for privileged users - Federation with corporate IdP - Dynamic groups for resource authentication - Regular access reviews

Layer 2: Network - Private subnets for internal resources - Security lists and NSGs - Bastion hosts or Bastion service - VPN or FastConnect for on-premises - DDoS protection (built-in)

Layer 3: Infrastructure - Dedicated VM Hosts for isolation - Security Zones for policy enforcement - Cloud Guard for threat detection - Vulnerability Scanning for instances - Patch management automation

Layer 4: Data - Encryption at rest (default) - Customer-managed keys (Vault) - Encryption in transit (TLS) - Database encryption (TDE) - Secrets management (Vault)

Layer 5: Application - Web Application Firewall (WAF) - API Gateway rate limiting - Application-level authentication - Code scanning and security testing - Security monitoring and logging

Vault Service:

Key Management: - Master Encryption Keys: Encrypt data encryption keys - Data Encryption Keys: Encrypt actual data - Key Rotation: Automatic or manual rotation - Key Versions: Track key history - BYOK (Bring Your Own Key): Import your own keys

Secrets Management: - Store passwords, tokens, credentials - Version control for secrets - Rotation policies - Access controlled by IAM policies - Integration with services (DB, Functions)

Cloud Guard:

Components: 1. Detectors: Identify security issues (misconfigured resources, suspicious activity) 2. Problems: Security findings from detectors 3. Responders: Automated remediation actions 4. Targets: Resources to monitor (compartments) 5. Recipes: Collection of detector and responder rules

Common Detectors: - Public bucket detected - Instance without Cloud Guard enabled - Compute instance with public IP - Security list allows 0.0.0.0/0 on all ports - Database without backup policy

Security Zones: - Deny policies for security best practices - Cannot create non-compliant resources - Cannot modify resources to be non-compliant - Examples: Require encryption, deny public buckets, require backups - Use for production environments

Bastion Service: - Managed bastion hosts - No infrastructure to manage - Session recording - Time-limited sessions - IAM-based access control - Session types: SSH, port forwarding, dynamic port forwarding

Monitoring and Observability¶

Monitoring Service:

Metrics: - Time-series data points - Dimensions: Resource-specific attributes - Namespaces: Grouping of metrics (e.g., oci_computeagent) - Intervals: 1-minute or 1-hour aggregation - Retention: 90 days

Common Metrics: | Resource | Metric | Description | |----------|--------|-------------| | Compute | CPUUtilization | CPU usage percentage | | Compute | MemoryUtilization | Memory usage percentage | | Block Volume | VolumeReadOps | Read IOPS | | Block Volume | VolumeWriteOps | Write IOPS | | Load Balancer | HealthyBackendServers | Number of healthy backends | | Database | CpuUtilization | Database CPU usage |

Alarms: - Trigger on metric thresholds - Statistic: Mean, Max, Min, Sum, Count - Evaluation frequency: 1-minute or 1-hour - Actions: Send notification - Repeat notifications: Optional - Suppression: Temporarily disable

Logging Service:

Log Types: 1. Audit Logs: All API calls (automatically enabled) 2. Service Logs: Service-specific logs (VCN flow logs, LB access logs) 3. Custom Logs: Application logs

Log Categories: - VCN flow logs (accepted, rejected, all) - Load balancer access logs - Load balancer error logs - Object Storage read/write logs - Function invocation logs - API Gateway execution logs

Log Management: - Retention: 1 month to 6 months (custom: unlimited) - Search and filter - Export to Object Storage - Stream to other services

Events Service:

Event Types: - Resource state changes (instance created, volume attached) - Service actions (backup completed, alarm fired) - Custom events

Actions: - Send notification - Trigger function - Stream to Streaming service

Event Example:

Event: Instance launched
Condition: compartmentId = 'ocid1...'
Action: Send notification to topic 'InstanceAlerts'

Service Connector Hub: - Connect log sources to targets - Sources: Logging, Monitoring, Streaming - Targets: Object Storage, Functions, Notifications, Streaming - Use cases: Archive logs, trigger workflows, centralize monitoring

Cost Management:

Cost Analysis: - View costs by compartment, tag, service - Filter by date range - Export to CSV - Trend analysis

Budgets: - Set budget amount for compartment or cost-tracking tag - Alert thresholds (%, $) - Email notifications - Track actual vs. forecasted spend

Cost Optimization Strategies: 1. Right-size instances (use metrics to identify underutilized resources) 2. Use Reserved Instances for predictable workloads (up to 42% discount) 3. Implement autoscaling for variable workloads 4. Use lifecycle policies to archive old data 5. Enable Object Storage versioning only when needed 6. Clean up unused resources (snapshots, volumes, load balancers) 7. Use BYOL for Oracle software

High Availability and Disaster Recovery¶

High Availability Design Patterns¶

Pattern 1: Multi-AD Deployment

Region: us-phoenix-1
├── AD-1: Web tier (instances, load balancer)
├── AD-2: Web tier (instances, load balancer)
└── AD-3: Database (primary + standby with Data Guard)

Benefits:
- Protection against AD failure
- Load balancing across ADs
- Database failover capability
- RTO: Minutes, RPO: Near-zero

Pattern 2: Single-AD with Fault Domains

Region: us-ashburn-1
└── AD-1
    ├── FD-1: Web tier instances
    ├── FD-2: Web tier instances
    └── FD-3: Database instance

Benefits:
- Protection against rack/switch failure
- Cost-effective for single-AD regions
- RTO: Minutes, RPO: Last backup

Pattern 3: Multi-Region Active-Passive

Primary Region: us-phoenix-1
├── Full application stack
├── Database (primary)
└── Cross-region backups to secondary region

Secondary Region: us-ashburn-1
├── Standby resources (minimal)
└── Database standby (Data Guard)

Benefits:
- Protection against region failure
- RTO: Hours, RPO: Minutes (with Data Guard)
- Lower secondary region cost

Pattern 4: Multi-Region Active-Active

Region 1: us-phoenix-1
├── Full application stack
└── Database (multi-region write)

Region 2: us-ashburn-1
├── Full application stack
└── Database (multi-region write)

Traffic Manager: Route users to nearest region

Benefits:
- No downtime during region failure
- Low latency (users routed to nearest region)
- RTO: None (always active), RPO: Near-zero
- Higher cost (fully duplicated)

DR Strategies by RTO/RPO¶

Strategy	RTO	RPO	Cost	Complexity
Backup & Restore	Hours-Days	Hours	Low	Low
Pilot Light	Hours	Minutes	Medium	Medium
Warm Standby	Minutes	Minutes	Medium-High	Medium
Hot Standby (Active-Passive)	Minutes	Near-zero	High	High
Active-Active	None	Near-zero	Very High	Very High

Backup & Restore: - Regular backups to cross-region Object Storage - Restore in DR region when needed - Use Resource Manager to recreate infrastructure - Best for non-critical applications

Pilot Light: - Core infrastructure always running in DR region - Database standby with Data Guard - Scale up instances when disaster occurs - Best for moderate RTO requirements

Warm Standby: - Scaled-down version running in DR region - Database standby with Data Guard - Scale to full capacity when needed - Best for production applications

Hot Standby (Active-Passive): - Full environment running in DR region - Database standby with Data Guard - Instant failover capability - Best for business-critical applications

Active-Active: - Full environment in multiple regions - Database with multi-region write or replication - Traffic Manager for global load balancing - Best for mission-critical applications

Backup Strategies¶

Compute Backups: 1. Boot Volume Backup: - Automatic with backup policy - Manual on-demand backups - Cross-region copy for DR

Custom Image:
Create from instance or boot volume
Faster restore than backup
Share across compartments/regions

Block Volume Backups: - Incremental (after first full backup) - Scheduled with backup policies - Cross-region copy - Volume group backups (consistency across volumes)

Database Backups: 1. Autonomous Database: - Automatic daily backups (60-day retention) - Manual on-demand backups - Long-term backups (10+ years) - Cross-region Autonomous Data Guard

DB Systems:
Automatic daily backups (7-60 day retention)
Manual on-demand backups
Cross-region backup copy
Data Guard for standby

Object Storage Backups: - Cross-region replication - Versioning for accidental deletion - Lifecycle policies for archival

Common Architecture Scenarios¶

Scenario 1: Three-Tier Web Application¶

Requirements: - High availability - Scalability - Security - Cost optimization

Architecture:

Internet
    ↓
Public Load Balancer (multi-AD)
    ↓
Public Subnet (Web Tier)
- Autoscaling instance pool
- Web servers across 3 ADs
- Security List: Allow 80, 443 from 0.0.0.0/0
    ↓
Private Subnet (App Tier)
- Autoscaling instance pool
- App servers across 3 ADs
- NAT Gateway for outbound internet
- Security List: Allow ports from web tier only
    ↓
Private Subnet (DB Tier)
- Autonomous Database (serverless)
- Or: DB System with Data Guard
- Service Gateway for Oracle services
- Security List: Allow 1521 from app tier only

Key Design Decisions: - Load balancer in public subnet for internet access - Autoscaling for web and app tiers (cost optimization) - Private subnets for app and DB (security) - Multi-AD deployment (high availability) - NAT Gateway for app tier updates (security) - Service Gateway for database backups (cost, security)

Scenario 2: Hybrid Cloud with On-Premises Integration¶

Requirements: - Connect on-premises data center to OCI - Private connectivity (no internet) - High bandwidth - Low latency

Architecture:

On-Premises Data Center
    ↓
FastConnect (1-10 Gbps)
    ↓
Dynamic Routing Gateway (DRG)
    ↓
VCN (10.0.0.0/16)
├── Private Subnet: App servers
├── Private Subnet: Databases
└── Service Gateway: OCI services

Routing:
- On-prem to OCI: via FastConnect
- OCI to on-prem: via DRG
- OCI to internet: via NAT Gateway
- OCI to Oracle services: via Service Gateway

Key Design Decisions: - FastConnect for dedicated, high-bandwidth connectivity - Alternative: Site-to-Site VPN (lower cost, lower bandwidth) - DRG for routing between on-premises and OCI - Private subnets only (no public access) - Service Gateway for OCI services (no internet charges)

Scenario 3: Big Data Analytics Platform¶

Requirements: - Store large amounts of data - Process data at scale - Cost-effective - Integration with analytics tools

Architecture:

Data Sources
    ↓
Object Storage (Standard tier)
- Raw data ingestion
- Lifecycle policy: Move to Infrequent Access after 90 days
    ↓
Data Flow (ETL)
- Spark-based processing
- Transform and enrich data
    ↓
Autonomous Data Warehouse (ADW)
- Optimized for analytics
- Auto-scaling
- Integrated ML
    ↓
Analytics Tools
- Oracle Analytics Cloud
- External BI tools

Key Design Decisions: - Object Storage for cost-effective data lake - Lifecycle policies to reduce storage costs - Data Flow for serverless ETL processing - ADW for high-performance analytics - Auto-scaling to handle variable query load

Scenario 4: Microservices on Kubernetes¶

Requirements: - Container orchestration - Service mesh - CI/CD integration - Observability

Architecture:

Developer
    ↓
Container Registry
- Store Docker images
    ↓
OKE (Oracle Container Engine for Kubernetes)
- Managed Kubernetes cluster
- Node pools across 3 ADs
- LoadBalancer service type
    ↓
Public Load Balancer
- Ingress controller
- SSL/TLS termination
    ↓
External Users

Observability:
- Logging: Service Connector Hub → Object Storage
- Monitoring: Kubernetes metrics
- Tracing: APM service

Key Design Decisions: - OKE for managed Kubernetes (reduces ops overhead) - Container Registry for private image storage - Multi-AD node pools for high availability - LoadBalancer service for public access - Service Connector Hub for centralized logging

Scenario 5: Serverless Event-Driven Architecture¶

Requirements: - Event-driven processing - No infrastructure management - Cost optimization (pay per use) - Integration with OCI services

Architecture:

Object Storage
- Event: Object created
    ↓
Events Service
- Trigger on object creation
    ↓
Functions
- Process object (resize image, extract text, etc.)
- Store results in database or storage
    ↓
Autonomous Database
- Store processed data

Notification:
Functions → Notifications → Email/Slack

Key Design Decisions: - Events Service for event-driven triggers - Functions for serverless processing (no idle costs) - Dynamic Group for Function authentication - Autonomous Database for serverless data storage - Notifications for alerting

Exam Tips and Strategy¶

Exam Format¶

60 multiple-choice questions
105 minutes (1 hour 45 minutes)
68% passing score (41/60 questions)
No penalty for wrong answers (guess if unsure)
Non-linear (can skip and return to questions)

Time Management¶

Average 1.75 minutes per question
First pass: Answer easy questions (45-60 minutes)
Second pass: Review and answer remaining questions (30-45 minutes)
Final pass: Review flagged questions (remaining time)
Leave no questions unanswered

Question Types¶

1. Scenario-Based (Most Common): - Read carefully for requirements (HA, cost, security, performance) - Eliminate obviously wrong answers - Choose best answer that meets ALL requirements - Watch for keywords: "most cost-effective", "highest availability", "most secure"

2. Definition-Based: - Know exact definitions of services and features - Understand differences between similar services (e.g., Security Lists vs NSGs) - Memorize key numbers (compartment depth, CIDR ranges, retention periods)

3. Best Practice: - Follow Oracle's documented best practices - Choose answers aligned with Well-Architected Framework - Select security-focused options when in doubt

4. Troubleshooting: - Understand error messages and causes - Know how to diagnose issues (logs, metrics, connectivity tests) - Follow systematic troubleshooting approach

Key Topics to Master¶

High Priority (25-30% of exam): 1. VCN design and networking (gateways, peering, routing) 2. IAM policies (syntax, verbs, resource-types) 3. Load balancing (types, configuration, health checks) 4. Compute (shapes, autoscaling, instance pools) 5. Storage (types, use cases, performance tiers)

Medium Priority (20-25% of exam): 1. Database services (Autonomous vs DB Systems, Data Guard) 2. Security (Vault, Cloud Guard, Security Zones, encryption) 3. Monitoring and logging (metrics, alarms, log types) 4. High availability patterns (multi-AD, fault domains) 5. Backup and disaster recovery strategies

Lower Priority (10-15% of exam): 1. Cost optimization (pricing models, BYOL, budgets) 2. Advanced networking (Transit Routing, FastConnect) 3. Resource Manager (Terraform on OCI) 4. Specific service features (less commonly tested)

Common Traps to Avoid¶

1. Similar Answer Choices: - Read carefully to spot subtle differences - Example: "Create Internet Gateway" vs "Create NAT Gateway" - Choose based on specific requirement (inbound vs outbound-only)

2. Over-Engineering: - Don't choose overly complex solutions - Example: Multi-region active-active when multi-AD meets requirements - Choose simplest solution that satisfies requirements

3. Ignoring Constraints: - Pay attention to "most cost-effective", "highest availability", etc. - Answer may be technically correct but not optimal - Re-read question if multiple answers seem correct

4. Assuming Defaults: - Know default behaviors (e.g., default security list rules) - Understand when explicit configuration is needed - Don't assume optional features are enabled

Study Approach¶

Week 1-2: Foundations - Read all OCI documentation for core services - Create free tier account and explore console - Complete OCI Foundations certification (if not already done)

Week 3-4: Hands-On - Build multi-tier application in OCI - Practice VCN design with multiple subnets and gateways - Configure IAM policies for different scenarios - Set up monitoring, logging, and alarms - Implement backup and recovery

Week 5-6: Deep Dive - Study advanced networking (peering, transit routing, FastConnect) - Practice database setups (Autonomous, DB Systems, Data Guard) - Implement security best practices (Vault, Cloud Guard, Security Zones) - Build autoscaling configurations - Cost analysis and optimization

Week 7-8: Exam Prep - Review this fact sheet regularly - Take practice exams - Focus on weak areas - Review common scenarios - Memorize key numbers and limits

Day Before Exam¶

Review this fact sheet (focus on Quick Reference sections)
Revisit flagged topics from practice exams
Get good sleep (don't cram)
Prepare testing environment (if online proctored)

Day of Exam¶

Arrive early (testing center) or test setup (online)
Read each question carefully
Use process of elimination
Flag difficult questions for review
Don't change answers unless certain
Review all questions before submitting

Resources for Additional Study¶

📖 OCI Documentation - Primary study resource
📖 Oracle Learning Explorer - Free learning paths and training
📖 Oracle Architecture Center - Reference architectures and solutions
📖 OCI Free Tier - Hands-on practice environment

Good luck on your OCI Architect Associate exam! Focus on hands-on experience and understanding WHY certain design decisions are made, not just memorizing facts.