Hard Difficulty Questions

OCI Resource Manager Terraform syntax checker.

Why it fails: Resource Manager checks Terraform files, not standalone OCI IAM policy syntax outside of TF.

OCI Audit log analysis.

Why it fails: Audit logs record past events; they do not validate prospective policy syntax.

OCI Cloud Guard policy rules.

Why it fails: Cloud Guard scans security posture, not IAM policy syntax.

Descriptions are only mandatory when using the CLI, but optional in the Console.

Why it fails: The validation requirement applies across all OCI interaction interfaces (Console, CLI, SDK, API).

Only if the policy is created at the tenancy root level.

Why it fails: Descriptions are mandatory regardless of whether the policy is created at the root tenancy level or inside a compartment.

No, the description is entirely optional and can be left blank.

Why it fails: Leaving the description blank is not permitted by the OCI Console or API validation rules for policies.

Allow user UserAdmins to inspect compartments in tenancy

Why it fails: Groups, not individual users, are the target of OCI IAM policies, and 'inspect compartments' does not grant user management permissions.

Allow group UserAdmins to manage all-resources in tenancy

Why it fails: This would grant full access to all infrastructure resources, violating the principle of least privilege.

Allow group UserAdmins to manage users in tenancy

Why it fails: User and group management in OCI identity falls under the identity-domains or general tenancy-level identity verbs depending on IAM configuration, but 'manage identity-domains' is the standard OCI IAM construct.

Rely solely on single-instance virtual machines with automatic daily backups instead of multi-node clustering.

Why it fails: Single-instance VMs with daily backups leave an outage window until restore completes, so no fault isolation or automatic failover occurs. Backups suit disaster recovery of data, not continuous uptime. Multi-node clustering across availability domains is required for resilience.

Deploy all database and application instances in a single Fault Domain to optimize network latency.

Why it fails: Concentrating every instance in one fault domain means a single hardware or power failure takes down the whole stack, defeating fault isolation. Co-location suits latency-sensitive single-domain workloads, but the stem demands maximum uptime across independent failure boundaries.

A single VPN tunnel connecting to a single CPE device.

Why it fails: A single tunnel to one CPE creates a single point of failure, so no high availability exists. It is tempting as the simplest configuration, but OCI recommends two CPE devices with two IPsec tunnels attached to the same DRG, enabling failover if one path drops.

Configuring active-passive peering across two separate VCNs.

Why it fails: Active-passive peering across two VCNs does not deliver the required redundancy; OCI's recommended design uses two CPEs and two IPsec tunnels terminating on one DRG, with BGP or static routing. Multiple VCNs add complexity without providing tunnel-level failover.

Using an Internet Gateway instead of a DRG with redundant static routes.

Why it fails: An Internet Gateway only routes traffic between a VCN and the public internet; it cannot terminate IPsec tunnels, so no on-premises connectivity exists at all. It is tempting because internet gateways do provide connectivity, but they suit public-facing workloads, not site-to-site VPNs requiring redundant DRG and CPE tunnels.

Internet Gateway

Why it fails: An Internet Gateway routes traffic over the public internet, directly contradicting the requirement that communication use private IP addresses without public traversal. It is correct for public subnets hosting internet-facing resources, not for private hybrid connectivity between on-premises networks and multiple regional VCNs.

Local Peering Gateway

Why it fails: A Local Peering Gateway only connects VCNs within a single region, so it cannot link on-premises networks to VCNs spread across multiple regions. It is the right component when joining two VCNs in the same region privately, which is not the cross-region requirement here.

NAT Gateway

Why it fails: A NAT Gateway gives instances in a private subnet outbound internet access; it does not carry on-premises traffic to VCNs across regions. It is correct when private instances need outbound internet connectivity without inbound exposure, not for private hybrid routing over FastConnect.

Using security lists instead of Network Security Groups

Why it fails: Security lists and NSGs are both valid stateful filters; using security lists alone does not cause intermittent drops provided rules permit the peering CIDR. It is tempting because NSGs offer per-VNIC granularity, and would be correct when tighter, instance-level rule scoping is required.

Attaching an Internet Gateway to the peering connection

Why it fails: An Internet Gateway is never attached to an LPG peering connection; LPGs route traffic directly between VCNs, and IGWs serve public internet access. It is tempting because IGWs are gateway attachments, and would be correct when a VCN's subnets require inbound or outbound internet connectivity.

Enabling Flow Logs on the subnets

Why it fails: Flow Logs are a passive observability feature that records traffic metadata and never alters forwarding, so enabling them cannot drop packets. It is tempting because logs help diagnose peering issues, and would be correct when you need visibility into accepted and rejected traffic on subnets.

Flexible shapes are only available on Bare Metal instances and cannot be used with Virtual Machines.

Why it fails: Flexible shapes are available for both virtual machine and bare metal instances, so the bare-metal-only restriction is false. The statement tempts because bare metal shapes also expose flexible OCPU and memory configuration, blurring the distinction.

Flexible shapes do not support boot volume resizing.

Why it fails: Boot volumes on flexible-shape instances can be resized, subject to the usual limits, so the restriction does not exist. The statement tempts because some shape changes do require stopping the instance, but resizing boot volumes is supported.

You must select a fixed tier of memory for every OCPU selected.

Why it fails: Flexible shapes let you set OCPU and memory independently within defined ratios, so memory is not locked to a fixed tier per OCPU. Fixed memory-per-OCPU tiers describe standard shapes, which is why the statement appears plausible.

OCI Multi-Cloud Interconnect

Why it fails: Multi-cloud interconnect links OCI to other hyperscalers over private connectivity, moving traffic between clouds rather than keeping data inside the headquarters. It is tempting because it provides private, low-latency links and consistent networking, but data still traverses external infrastructure, violating the residency constraint that Dedicated Region satisfies.

OCI Public Cloud Region

Why it fails: A public cloud region hosts resources in Oracle-operated datacentres, so financial data would physically leave the corporate headquarters, breaching the residency rule. It is tempting because public regions offer the full managed service catalogue and identical control plane APIs, but only Dedicated Region places that same control plane inside the customer's own facility.

OCI Global Edge Services

Why it fails: Global Edge Services distribute caching, DNS and WAF functions to edge locations worldwide, so data is processed outside the headquarters. It is tempting because edge services improve latency and protect public-facing applications, but they are for content delivery and perimeter security, not for hosting managed services under a single control plane on-premises.

Dynamic group names are case-insensitive in rules but case-sensitive in IAM policies, causing a mismatch.

Why it fails: OCI matching rules and policy statements both treat dynamic group names case-sensitively, so no case-based mismatch mechanism exists. Case sensitivity becomes relevant when writing rule conditions against tags or compartment names, where exact casing must match the resource's actual value.

The instances must be terminated and relaunched for dynamic group membership to evaluate.

Why it fails: OCI dynamic group membership is evaluated continuously against instance metadata, so running instances join without relaunch. Terminating and relaunching is the correct remedy only when metadata used in matching rules has been edited on an existing instance and must be refreshed.

Dynamic groups cannot be used in IAM policies; only user groups can.

Why it fails: Dynamic groups in OCI do support IAM policy references, so this claim is false; the real cause lies in rule matching or policy syntax. It tempts administrators who have only seen identity-provider dynamic groups scoped to applications rather than cloud resource principals, where such a restriction genuinely applies.

Flexible shapes are only available on Bare Metal instances and cannot be used with Virtual Machines.

Why it fails: Flexible shapes are available on both Virtual Machine and Bare Metal instances, so restricting them to Bare Metal is false. The temptation arises because bare-metal workloads often need custom OCPU-to-memory ratios, but flexible shapes exist precisely to let VMs scale OCPUs and memory independently.

Flexible shapes do not support boot volume resizing.

Why it fails: Boot volume resizing is independent of compute shape flexibility, so this claim is false. It tempts administrators who associate flexible shapes with fixed storage, but block volume and boot volume resizing are governed by storage settings, not by whether the compute shape is flexible.

You must select a fixed tier of memory for every OCPU selected.

Why it fails: Flexible shapes let you set memory independently per OCPU within allowed ratios, so a fixed memory tier per OCPU is false. The distractor mirrors fixed shapes, where OCPU and memory are bundled; that model applies to non-flexible standard shapes, not flexible ones.

An availability domain can span across multiple geographic countries to maximize data locality.

Why it fails: Availability domains are contained within a single region and cannot span countries; a region is the geographic boundary. It is tempting because spreading data across locations improves locality and resilience, but that is achieved by deploying across multiple regions, not by stretching one availability domain beyond its region.

Availability domains share power, cooling, and physical security infrastructure to reduce operational overhead.

Why it fails: Availability domains are isolated from each other: each has independent power, cooling, and physical security, so sharing them is false. It is tempting because sharing infrastructure reduces cost, which is why fault domains within an AD share some resources, but AD isolation is the design principle enabling high availability across ADs.

Internet Gateway with Public IP

Why it fails: An Internet Gateway gives a VCN inbound and outbound public connectivity, but it does not provide a private dedicated path to an on-premises data centre; that requires IPSec VPN or FastConnect. It is tempting because it connects networks, yet it is designed for public internet access, not site-to-site private connectivity.

Local Peering Gateway

Why it fails: A Local Peering Gateway connects two VCNs within the same OCI region, not an on-premises data centre to a VCN; that requires IPSec VPN or FastConnect. It is tempting because peering links networks, but its scope is intra-region VCN-to-VCN traffic, not hybrid on-premises connectivity.

Object Storage Gateway

Why it fails: An Object Storage Gateway is a software appliance that exposes OCI Object Storage buckets over NFS or SMB to on-premises clients; it does not extend a VCN's layer-3 network to a data centre. It is tempting because it bridges on-premises workloads to OCI storage, but the question asks about connecting to a VCN, which requires IPSec VPN or FastConnect.

NAT Gateway

Why it fails: A NAT Gateway gives private subnets outbound internet access, but it routes to public endpoints via the internet, not to Object Storage privately. It suits patching or software downloads from private instances, not private service connectivity.

Internet Gateway

Why it fails: An Internet Gateway provides public ingress and egress between a VPC and the internet, so traffic would traverse public routes rather than stay private. It is the correct choice when a public subnet needs inbound internet access, not for private service access.

VPN Connect

Why it fails: VPN Connect links on-premises networks to a VPC over IPsec, which is unnecessary for instance-to-service traffic inside Oracle Cloud. It is correct when extending an existing data centre into the cloud, not for private access to Object Storage.

Ephemeral Public IP

Why it fails: An ephemeral public IP is assigned automatically at launch and released when the instance terminates, so it cannot guarantee retention of a specific address required for compliance. It suits temporary instances where address persistence is irrelevant. A reserved public IP, by contrast, remains allocated to your tenancy until you explicitly delete it, satisfying the retention requirement.

Private IP

Why it fails: A private IP operates only within a VCN and cannot be reached from the internet, so it cannot satisfy a compliance requirement to retain a specific public address. It is tempting because private IPs can be reserved and reassigned, which suits internal tiering or database subnets where no external reachability is needed.

Service Gateway IP

Why it fails: A service gateway provides private access from a VCN to OCI services such as Object Storage, carrying no public address at all. Retaining a specific public IP requires a reserved public IP attached to the instance's VNIC.

Cloud Guard

Why it fails: Cloud Guard detects misconfigurations and insecure resource states across a tenancy, generating findings and remediations; it does not sit inline to inspect or block HTTP traffic. It is tempting as a security service, but a web application firewall handles Layer 7 attacks.

Virtual Cloud Network Security Lists

Why it fails: Security lists are stateless packet filters operating at Layers 3 and 4, inspecting IP addresses, ports and protocols; they cannot parse HTTP payloads to detect SQL injection or Layer 7 floods. They are tempting as the default VCN firewall, but a web application firewall is required here.

Network Security Groups

Why it fails: Network security groups are stateful Layer 3/4 filters applied to VNICs; they evaluate IP addresses and ports, not HTTP request content, so SQL injection and Layer 7 floods pass through. They suit micro-segmentation between instances, not web attack inspection.

All inter-region traffic must traverse the public internet via encrypted IPsec VPN tunnels.

Why it fails: Inter-region traffic traverses Oracle's dedicated private backbone rather than the public internet, so IPsec tunnels are unnecessary. The option is tempting because public internet transfer with encryption is a common multi-cloud pattern, but OCI's architecture provides private connectivity between regions by default, including for Ashburn-to-Phoenix replication.

OCI regions are isolated from each other; cross-region data transfer requires third-party WAN optimizers.

Why it fails: OCI regions are interconnected through Oracle's private backbone, so replication needs no third-party WAN optimisers. The option is tempting because regions are isolated for fault domains and identity boundaries, which is true, but isolation does not block native cross-region data transfer. Ashburn-to-Phoenix replication works directly over the backbone.

Inter-region communication is restricted to metadata only; user data cannot be moved between regions.

Why it fails: OCI permits full user data replication between regions over Oracle's dedicated low-latency backbone, not metadata alone. The option is tempting because control-plane metadata does traverse that backbone, but the same network carries customer data. Cross-region replication of databases and object storage is a supported, foundational capability.

Boot volume attachment

Why it fails: Boot volume attachment simply connects an existing boot volume to an instance; it creates no copy of any kind. It is the correct action when launching or repairing a compute instance that needs its operating system disk, not when duplicating a large data volume.

Standard Block Volume Backup

Why it fails: Standard Block Volume Backup copies the full volume to Object Storage, so completion is not instantaneous and the first backup consumes space equal to the volume. It is the right choice for durable off-volume retention and long-term recovery points, not for an immediate space-efficient clone.

Cross-region replication policy

Why it fails: Cross-region replication asynchronously copies a volume to another region for disaster recovery, and the initial copy is not instantaneous. It suits regional failover requirements, whereas the scenario needs an immediate, space-efficient point-in-time duplicate within the same region.

Enable Object Storage lifecycle management rules on the attached volume.

Why it fails: Object Storage lifecycle rules apply to buckets, not Block Volume backups, and cannot express daily-30-day plus weekly-1-year retention. Lifecycle policies are tempting because they automate retention, but that mechanism targets object storage; Block Volume backup policies provide the required schedule and retention.

Configure a Compute Autoscaling policy with custom volume snapshot triggers.

Why it fails: Compute Autoscaling adjusts instance count in response to load; it has no volume snapshot or retention mechanism, so it cannot produce daily or weekly backups. It is tempting because autoscaling policies are schedule-capable, which fits scaling compute capacity, not backing up Block Volume data.

Manually run scripts using the OCI CLI every day and week.

Why it fails: Manual CLI scripts require you to schedule, monitor and rotate retention yourself, and they cannot express the daily-30-day plus weekly-1-year combination as a single declarative policy. Backup policies exist precisely to attach such schedules to volumes automatically; scripting suits one-off or cross-service tasks OCI policies cannot cover.

Security Lists

Why it fails: Security lists apply stateful rules at the subnet level, so traffic is permitted or denied by CIDR range, not by individual workload role. They are tempting because they are the default OCI firewall construct, and would be correct for controlling traffic between whole subnets rather than between specific instances.

Local Peering Gateways

Why it fails: Local peering gateways connect a VCN to another VCN in the same region, providing reachability only. They are tempting because they link separate networks, and would be correct when two VCNs must communicate privately, but they enforce no per-workload traffic filtering based on role.

Stateful Route Tables

Why it fails: Route tables determine the path packets take between subnets or gateways; they contain no allow or deny rules and cannot enforce role-based traffic restrictions. They are tempting because they govern inter-subnet connectivity, and would be correct when the requirement is directing traffic through a gateway, not filtering it.