OCI Architect Associate common mistakes
OCI Architect Associate · Understand the traps and how to avoid them.
Writing one policy at the tenancy root that grants 'manage all-resources in tenancy' to the developers group, then calling IAM done.
The Console policy builder and most quick-start tutorials make a tenancy-wide statement the shortest path to an unblocked environment, and candidates rarely see the compartment-scoped alternative demonstrated.
What to do instead
Scope each statement to the lowest compartment that contains the resources and pick the weakest verb that works (inspect < read < use < manage). Remember inheritance is one-directional: a policy attached to a compartment covers it and everything beneath it, but a policy attached to a child compartment never grants access to the parent.
Debugging a blocked port by editing only the NSG attached to the VNIC, or only the subnet's security list, and assuming the other set of rules no longer matters.
Security lists and network security groups look like two versions of the same feature, so candidates treat them as alternatives and check only the one they most recently changed.
What to do instead
Treat both rule sets as live on every VNIC: check the security lists on the subnet and every NSG the VNIC belongs to before concluding the rule is missing. Use security lists for broad subnet-level rules and NSGs for per-workload rules, and confirm the rule's source/destination is the CIDR or NSG actually in use.
Creating a route rule 0.0.0.0/0 to a NAT gateway and expecting internet clients to reach the instance, or putting an instance in a private subnet and expecting it to download packages with no NAT or service gateway.
The route table looks like a single generic 'internet' switch, so the direction-specific behaviour of NAT gateway, internet gateway, and service gateway is not obvious from the UI.
What to do instead
Map the direction first: inbound from the internet needs an internet gateway plus a public IP on the VNIC; outbound-only from a private subnet needs a NAT gateway; OCI service traffic (Object Storage, etc.) from a private subnet should go through a service gateway. Then confirm the route table is attached to the correct subnet, not just present in the VCN.
Terminating an instance to save cost and assuming the attached block volumes and boot volume are gone, or the reverse - assuming everything is preserved.
Other clouds differ on default delete-on-terminate behaviour, and OCI separates the boot volume option from block volume attachments, so candidates generalise from one resource to the other.
What to do instead
Know the split: attached block volumes persist after instance termination and are deleted only when you delete them; the boot volume is deleted unless you explicitly preserve it. Plan the cleanup of orphaned volumes and boot volumes into the design and into cost estimates.
Choosing Object Storage for a shared directory that an application writes to with normal file semantics (locking, appending, partial overwrite), then being surprised that the app cannot mount or modify objects in place.
Object Storage is the first storage service in the menu and buckets with prefixes look like folders, so the hierarchical, mountable nature of a file system is assumed.
What to do instead
Match the storage type to the access pattern: File Storage for shared POSIX/NFS workloads across instances, Block Volume for instance-local low-latency disk, Object Storage for immutable or whole-object read/write data accessed over the API or CLI. Objects are replaced whole and are not mountable as a directory.
Provisioning Autonomous Database with a private endpoint, adding the client IP to an ACL, and expecting a laptop on the internet to connect.
ACLs and access-type settings look interchangeable in the network access section, and the connection string detail is easy to skim during provisioning.
What to do instead
Separate the two controls: the endpoint type decides whether any network path exists (public endpoint versus private endpoint), and the ACL only filters who may use an existing public path. For a private endpoint, reach it through a bastion, VPN, or FastConnect inside the VCN, and use the wallet or the correct TLS connection string from the ADB console.
Treating Cloud Guard as the control that blocks non-compliant resources from being created, or assuming a deleted Vault key is destroyed instantly.
Security services get mentally grouped as 'guardrails', and Cloud Guard's dashboard makes it feel preventive; key lifecycle timing is rarely visible in the UI.
What to do instead
Assign each control its real role: Security Zones (and IAM policy) prevent non-compliant creation, while Cloud Guard detects problems and can respond through responder recipes. For Vault, remember key deletion is scheduled with a mandatory waiting period (7 to 30 days) during which the key can be cancelled - so 'delete the key' is not an instant remediation.
Setting a budget with an alert and telling the team spend is now capped at that amount.
The word 'budget' implies enforcement in most financial tooling, and the alert rule is the only configuration the UI asks for.
What to do instead
State the distinction explicitly: budgets only monitor and notify, they never block spending. If a hard ceiling is required, use quotas on compartments to limit the number or shape of resources that can be created, and keep budgets purely as an alerting mechanism.
Checking the Metrics explorer for memory utilisation and disk usage on an instance and concluding the data is missing or the service is broken.
CPU and network metrics appear immediately for any instance, so candidates assume all metrics come from the hypervisor automatically.
What to do instead
Remember which metrics need the Compute Instance Monitoring plugin (delivered through the Oracle Cloud Agent): memory, disk/filesystem usage, and in-guest process metrics. Enable the plugin and confirm the agent is running before writing alarms against those metrics, and always attach a notification topic to the alarm.
Designing an HA architecture by spreading instances across fault domains inside one availability domain and declaring the workload resilient to datacenter failure, or spreading everything across regions for a single-tier app with no defined RTO/RPO.
Fault domains and availability domains both appear as placement options with similar names, and the region/AD/FD hierarchy is easy to flatten mentally under time pressure.
What to do instead
Rank the failure domains: fault domains protect against correlated hardware failure within one AD, availability domains protect against datacenter failure within a region, and regions protect against regional failure. Place tiers across ADs (and fault domains within each AD) for in-region HA, and add a second region only when the business requirement justifies the cost and the data-replication design is spelled out.