OCI Architect Associate study materials
OCI Architect Associate study resources

Oracle Cloud Infrastructure Architect Associate cheat sheet

OCI Architect Associate · Keep the key ideas within reach.

Quick reference

IAM, Compartments, and Tenancy Governance

  • A policy statement has the form: allow to in [where ]. Verbs are inspect, read, use, and manage; each verb includes all lower verbs (manage > use > read > inspect).

  • Policies are attached to a compartment and are inherited by all child compartments; they are not inherited upward. Grant access at the highest compartment that contains every target resource.

  • Principals: users belong to groups, and policies grant to groups, dynamic groups (matching instance/resource rules), or the tenancy itself. A user's effective permissions are the union of all matching statements across the hierarchy.

  • Dynamic group matching rules use resource attributes, e.g. instance.compartment.id and instance.id. Instance principals then call APIs without storing credentials; the instance must be in the dynamic group and the policy must grant to that dynamic group.

  • Location qualifiers: tenancy (all compartments), a specific compartment, or compartment for a named compartment. A policy with no location does not exist; the in clause is mandatory.

  • Conditions support variables such as request.principal.type, request.operation, and target.compartment.id, allowing least-privilege narrowing without creating extra groups.

  • Federation: identity domains support SAML and OIDC identity providers; SCIM provisioning syncs users/groups. Federated users authenticate at the IdP and receive OCI tokens; group mapping drives policy evaluation.

  • Compartments are logical, nestable, and quota-scoped; resource names need only be unique within a compartment. Compartment quotas (zero or set limits) cap resource usage per compartment to enforce cost governance.

  • API keys (RSA key pair), auth tokens, and customer secret keys are distinct credential types with different service scopes; rotate and delete unused credentials. Audit tracks IAM changes in the tenancy.

Quick reference

Networking: VCNs, Subnets, Gateways, Routing, Security Lists, NSGs, Connectivity

  • A VCN has a CIDR block (e.g. 10.0.0.0/16) and is regional; its subnets are regional or AD-specific. Subnet CIDRs must fall inside the VCN CIDR and must not overlap other subnets in the same VCN.

  • Gateway types: Internet Gateway (bidirectional internet for public subnets), NAT Gateway (outbound-only internet for private subnets), Service Gateway (private access to OCI services such as Object Storage), and Dynamic Routing Gateway (DRG) for on-premises/VCN peering.

  • Route rules are longest-prefix-match and evaluated per subnet route table. A private subnet needs a route to the NAT gateway for egress and to the service gateway for OCI service traffic; a public subnet needs a route to the Internet Gateway.

  • Security lists are subnet-level, stateful, and apply to all VNIs in the subnet; NSGs are VNI-level, stateful, and apply to selected resources. Both are allow-only; there is no explicit deny rule.

  • Default security list allows all egress and SSH ingress from 0.0.0.0/0; replace it with least-privilege rules. NSGs let you separate tiers (web, app, db) without changing subnet boundaries.

  • Local VCN peering connects VCNs in the same region (via LPGs); remote peering connects VCNs across regions through DRGs. Peering is non-transitive, so hub-and-spoke requires a transit routing design.

  • FastConnect provides private dedicated connectivity to OCI; Site-to-Site VPN runs over the internet to a DRG. Both can coexist for redundancy; BGP advertises routes over the DRG.

  • Private endpoints: a private subnet can host a private endpoint for Object Storage or Autonomous Database; traffic stays on the OCI network and can route via the service gateway.

  • CIDR planning: avoid overlap with on-premises and other VCNs before peering. Overlapping CIDRs cannot be peered without NAT/transit appliances.

Quick reference

Compute: Instances, Shapes, Images, Autoscaling, Instance Configuration

  • Shapes: Standard (E-series, balanced), DenseIO (local NVMe), GPU (A-series), and Flexible shapes where OCPU and memory are chosen independently within a range. OCPU = 1 physical core (2 vCPUs on x86).

  • Images can be platform images, custom images from instances, or imported images. Boot volume size can exceed the image's default; the image defines the OS and initial boot volume.

  • Instance metadata and user data are retrieved from the instance metadata service (169.254.169.254); cloud-init consumes user data at first boot. Instance principals rely on metadata for tokens.

  • Instance configurations capture shape, image, metadata, and networking for reuse by instance pools. Instance pools maintain a fixed size and replace failed instances automatically.

  • Autoscaling policies: metric-based (CPU, memory via agent) and schedule-based. Cooldown and min/max size bound scaling; scale-in respects the minimum.

  • Preemptible instances cost less but can be reclaimed; they suit fault-tolerant batch work. Reserved capacity guarantees capacity for a shape in an AD but does not by itself reserve the instance.

  • Placement: AD selection, fault domains, and dedicated VM host. Spread across ADs/fault domains for HA; use a regional subnet for multi-AD pools.

  • Boot volume preservation: terminating an instance deletes the boot volume unless preserve-boot-volume is set. Use instance pools with a load balancer for stateless tiers.

  • Tagging instances and using defined tags enables cost tracking and policy conditions (e.g. allow only tagged resources).

Quick reference

Storage: Block Volumes, Object Storage, File Storage, Archive Tiers

  • Block Volume: network-attached, AD-scoped, attachable to one instance at a time (paravirtualized or iSCSI). Volume performance is set by VPUs/GB and can be tuned independently of size.

  • Block volume backups are incremental after the first full backup; copy backups across regions for DR. Volume groups enable crash-consistent multi-volume backups.

  • Object Storage: buckets are regional or AD-scoped; objects are immutable versions. Storage tiers are Standard, Infrequent Access, Archive, and (where offered) Cold. Lifecycle policies transition or delete objects by age/prefix.

  • Object Storage access: pre-authenticated requests (PARs) grant time-limited access to a bucket or object; bucket policies and IAM policies govern access. Versioning protects against overwrite/delete.

  • File Storage: NFSv3 file systems, mount targets in a subnet, export options by CIDR and UID/GID. File systems are AD-scoped or regional (multi-AD) for HA.

  • Archive tier: lowest cost, retrieval takes time (restore to Standard before download); objects are not immediately readable. Choose based on retrieval-time requirements.

  • Durability vs. availability: Object Storage is replicated across ADs in a region; block volumes are AD-scoped, so cross-AD HA requires replication or backups.

  • Encryption: all storage is encrypted at rest by default with Oracle-managed keys; customer-managed keys via Vault allow rotation and control.

Quick reference

Databases: Autonomous Database, DB Systems, Migration Options

  • Autonomous Database (ADB) is fully managed; workload types are Transaction Processing (ATP), Data Warehouse (ADW), and JSON. It autoscales OCPU and storage and patches automatically.

  • ADB network access: public endpoint with ACLs, or private endpoint in a VCN subnet. mTLS or TLS wallets control client authentication.

  • ADB tools: SQL Developer Web, APEX, Database Actions, and Data Studio. Autonomous Data Guard provides a standby in another region for DR.

  • DB Systems (VM, Bare Metal, Exadata, Base Database Service) give full OS/DB control; you manage patching, backups, and Data Guard. Choose when you need sysdba-level control or specific options.

  • Backups: automatic backups for ADB and DB systems; retention and backup windows are configurable. DB systems support RMAN backups to Object Storage and cross-region backup copies.

  • Migration options: Data Pump (expdp/impdp) for logical migration, GoldenGate for continuous replication/minimal downtime, Zero Downtime Migration (ZDM) for orchestrated moves, and Data Guard for physical standby cutover.

  • ADB supports cloning, refreshable clones (read-only clone refreshed from source), and cross-region cloning for migration and DR.

  • Database migration advisor assesses on-premises databases and recommends target shapes and migration paths.

  • HA: RAC for DB systems (multiple nodes), Data Guard for standby, and ADB's built-in redundancy. Test failover and measure RTO/RPO.

Quick reference

High Availability, Disaster Recovery, and Backup Strategy Design

  • Define RTO (max downtime) and RPO (max data loss) per workload; the pair drives the DR pattern choice.

  • DR patterns by cost/RTO: Backup and Restore (highest RTO), Pilot Light, Warm Standby, and Active-Active (lowest RTO, highest cost).

  • Regional HA uses multiple ADs and fault domains; a regional subnet plus a load balancer distributes traffic. Single-AD resources (block volumes) need replication for cross-AD HA.

  • Fault domains within an AD isolate hardware; spread instances across fault domains for resilience within a single-AD deployment.

  • Backup policy: define schedule, retention, and cross-region copies. Test restores regularly; a backup is unproven until restored.

  • Data Guard (physical standby) provides low RPO for databases; Autonomous Data Guard for ADB. Object Storage replication and cross-region backup copies protect storage.

  • DNS and traffic management: use health-checked load balancer backends and DNS failover to redirect during regional failure.

  • Runbooks and game days: document failover steps, verify IAM/dynamic group access in the DR region, and rehearse.

  • Cost/HA tradeoff: over-provisioned active-active is expensive; match pattern to business impact and validate with measured RTO/RPO.

Quick reference

Observability, Cost Management, and Operational Best Practices

  • Monitoring: metrics are emitted per resource (CPU, network, disk); alarms trigger on metric thresholds and can send notifications via the Notifications service or invoke functions.

  • Logging: service logs, audit logs, and custom logs flow to Logging; use Logging Analytics for querying and dashboards. Audit records API activity for the tenancy.

  • Application Performance Monitoring (APM) traces distributed requests; use it with metrics and logs for root-cause analysis.

  • Cost tools: budgets and budget alerts, cost analysis by compartment/tag, and the Cost Reports. Defined tags enable chargeback/showback.

  • Cost controls: compartment quotas, autoscaling with min/max, lifecycle policies to move cold data to lower tiers, and rightsizing shapes based on metric history.

  • Tagging strategy: defined tags with a namespace and cost-tracking keys; enforce via policy conditions and budgets scoped to tags.

  • Operational best practices: infrastructure as code (Terraform/Resource Manager), least-privilege IAM, change management, and automated backups with tested restores.

  • Health and limits: check service health/status and service limits; request limit increases before scaling. Use the CLI/SDK for repeatable operations.

  • Incident response: alarm -> notification -> runbook; preserve audit logs and use Logging search to reconstruct events.