Oracle Cloud Infrastructure Architect Associate cheat sheet
OCI Architect Associate · Keep the key ideas within reach.
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.
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.
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).
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.
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.
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.
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.