Hard Difficulty Questions

Use the OCI Streaming default single-consumer mode with multithreaded polling.

Why it fails: Default single-consumer mode with multithreaded polling shares one cursor per partition, so instances overwrite each other's offsets and duplicate or skip messages. It is tempting because threads raise throughput, but independent cursors require group-based consumption, where each instance joins a consumer group and reads its own partition.

Assign all consumer instances to the exact same consumer group and increase the number of partitions.

Why it fails: Sharing one consumer group makes OCI Streaming divide partitions among the instances, so each message reaches only one consumer, defeating the requirement that every instance process every message. Separate consumer groups give each its own cursor. A single group suits load-balanced work-sharing, not broadcast.

Publish events via OCI Notifications instead, as Streaming does not support consumer groups.

Why it fails: OCI Streaming does support consumer groups, so abandoning it is unnecessary; Notifications is a pub/sub fan-out service without durable replayable cursors or partition-level ordering. It would suit simple alerting or webhook delivery, not a replayable high-throughput event pipeline needing independent per-consumer cursor positions.

Manual RMAN backup replication via OCI Object Storage every 15 minutes

Why it fails: RMAN backup replication cannot meet a zero RPO: backups capture point-in-time copies, so any committed transaction after the last 15-minute run is lost, and restore plus recovery exceeds 30 seconds. It suits scheduled backup retention or cross-region archival, not continuous standby synchronisation.

Oracle Data Guard configured in Maximum Performance mode with asynchronous transport

Why it fails: Asynchronous transport commits locally before standby receipt, so a primary failure can lose the last transactions, breaking RPO zero. Maximum Performance suits latency-tolerant workloads; RPO zero demands Maximum Availability or Maximum Protection with SYNC transport.

Oracle GoldenGate real-time replication with asynchronous extract configurations

Why it fails: Oracle GoldenGate replicates at logical, transaction level, so it cannot deliver the zero-RPO guarantee that Data Guard's synchronous redo transport provides; asynchronous extract also introduces lag, breaching the sub-30-second RTO. GoldenGate suits heterogeneous migrations or active-active replication between dissimilar databases, not standby-based disaster recovery on Exadata Database Service.

Migrate all table data to standard Block Volume storage to bypass Exadata storage servers.

Why it fails: Bypassing Exadata storage servers defeats the purpose of Exadata and degrades smart scan performance.

Disable automatic backups entirely to save OCI Object Storage costs.

Why it fails: Disabling backups introduces unacceptable data loss risks and violates operational best practices.

Check the OCI VCN internet gateway route table.

Why it fails: An internet gateway route table governs egress to public endpoints, not in-cluster ClusterIP DNS resolution, so it cannot reveal why service names fail to resolve. It is tempting because VCN routing underpins OKE networking, but ClusterIP traffic stays internal and never traverses that gateway.

Review OCI Cloud Guard threat detection policies.

Why it fails: Cloud Guard detects misconfigurations and threats across OCI tenancies; it does not resolve in-cluster DNS queries or surface CoreDNS failures. It is tempting because it is a security diagnostic service, but intermittent 502s from name resolution require querying CoreDNS directly from a pod.

Restart the OCI API Gateway service.

Why it fails: OCI API Gateway fronts external HTTP traffic into the cluster; restarting it cannot fix internal ClusterIP DNS lookups between pods. It is tempting because 502 errors often implicate gateways, but the failing path here is service-name resolution inside the cluster, not the ingress tier.

The database IP addresses change, requiring manual DNS A-record updates in OCI DNS.

Why it fails: Autonomous Database Data Guard switchover relies on the managed connection service and wallet, so client connection strings continue resolving to the new primary without manual OCI DNS A-record edits. Manual DNS updates apply to self-managed IP-based architectures, not Autonomous Database.

You must manually regenerate new wallet zip files and redeploy them to all application servers.

Why it fails: Switchover does not invalidate wallets; the same wallet and TNS aliases remain valid because the service name follows the role change. Regenerating and redeploying wallets is tempting since wallets are downloaded per database, but that applies to initial provisioning or credential rotation, not switchover.

Client applications must be rewritten to use hardcoded IP addresses instead of TNS names.

Why it fails: Applications keep using TNS aliases and the wallet; hardcoding IP addresses is neither required nor supported, and would break failover. Hardcoded endpoints suit static, non-managed deployments where no service-name abstraction exists, which is not this scenario.

Relying on a single Availability Domain deployment with automated daily backups

Why it fails: A single Availability Domain still fails when the whole region is lost, and daily backups restore data rather than maintain availability. It tempts because AD-level redundancy plus backups is a valid resilience pattern against AD or instance failure, not regional outage.

Running all database write operations simultaneously against both regions with synchronous multi-master locking over public internet

Why it fails: Synchronous multi-master writes over the public internet add latency and split-brain risk, and OCI offers no such cross-region locking primitive. It tempts as an apparent zero-data-loss active-active design, which is actually achieved with Data Guard or GoldenGate in a supported topology.

Relying solely on local ephemeral NVMe drive snapshots for disaster recovery

Why it fails: Local ephemeral NVMe snapshots reside on the same instance, so they are destroyed with the compute node and cannot survive a region or availability-domain failure. They suit fast instance-local caching and temporary scratch data. Disaster recovery demands replicated, durable storage such as Object Storage or cross-region backups.

Stretching a single-node database VM across distinct cloud regions using unencrypted NFS mounts

Why it fails: A single-node VM cannot span distinct cloud regions; OCI regions are separated by high-latency links, and unencrypted NFS exposes data in transit. This pattern tempts architects seeking synchronous zero-RPO replication, but multi-region resilience requires Data Guard with separate database systems per region and encrypted transport.

Routing all write transactions through a single read-only replica without replication

Why it fails: A read-only replica cannot accept writes, and with replication absent, data written elsewhere never reaches it, so load distribution and availability both fail. It is tempting as a way to isolate write traffic onto one node, but GoldenGate architectures require bidirectional or one-way replication to synchronise replicas.

Disabling all checkpointing to maximize real-time packet loss tolerance

Why it fails: Checkpoints record extract and replicat positions, enabling recovery after failure; disabling them means a restart cannot resume from a known point, breaking the high-availability objective. It is tempting when minimising write latency is the priority, but GoldenGate relies on checkpoint tables for exactly the fault tolerance this architecture requires.

Peer an OCI Dynamic Routing Gateway directly to a GCP Virtual Private Cloud using a Google Cloud Interconnect cable.

Why it fails: A DGW cannot peer directly to a GCP VPC; cross-cloud private connectivity requires a partner Interconnect or Cloud VPN attachment terminating on both sides. Direct peering is tempting because it mirrors intra-cloud VPC peering, but GCP and OCI control planes do not exchange routes natively.

Configure an OCI Internet Gateway to peer with GCP Cloud DNS.

Why it fails: An Internet Gateway routes traffic to and from the public internet, so any GCP-bound flow would traverse public paths, violating the private-connectivity requirement. It is tempting because Internet Gateway plus Cloud DNS supports hybrid name resolution, but that scenario needs public endpoints, not private low-latency transport.

Attach a GCP VPC as a secondary VCN in the OCI console.

Why it fails: A VCN is an OCI construct; a GCP VPC cannot be attached as a secondary VCN, and no such cross-provider attachment exists. It is tempting because secondary VCN attachment enables local peering within a single tenancy, which is the correct pattern for intra-OCI multi-VCN designs, not cross-cloud.

Allow group Developers to manage compute-instances in tenancy

Why it fails: A tenancy-level policy grants the group access across the entire tenancy, including compartments unrelated to the requirement, violating the least-privilege constraint. It is tempting because it is a single concise statement, but it would be correct only when organisation-wide compute administration is genuinely intended.

Allow group Developers to manage compute-instances in root

Why it fails: Granting at root tenancy level contradicts the requirement to avoid root-level permissions; child compartments inherit from the parent, so the policy belongs on the parent compartment. Root-level grants are tempting because they cover everything in one statement, but they over-privilege and violate least privilege across the tenancy.

Write individual policies for every single child compartment separately without referencing the parent.

Why it fails: Per-compartment policies duplicate administration and break when new child compartments are created, whereas Oracle IAM policies attached at the parent compartment inherit to all children. It is tempting because explicit per-compartment grants feel tightly scoped, but they would be correct only where compartments sit outside the parent hierarchy.

Attach public IP addresses directly to all backend web servers.

Why it fails: Public IPs on backend servers let internet traffic bypass the firewall entirely, defeating the inspection mandate. Backends should sit in a private subnet, with only the firewall holding a public address. Direct public IPs tempt because they simplify inbound access, but that convenience removes the enforcement point the design requires.

Rely entirely on default VCN Security Lists without route table modifications.

Why it fails: Security Lists are stateless subnet-level packet filters; they cannot redirect traffic through a firewall appliance. Inspection requires a route table sending ingress traffic to the firewall's private IP, then onward to the web tier. Default lists tempt because they are the built-in OCI control, but they filter rather than route.

Use OCI Object Storage to filter incoming HTTP packets.

Why it fails: Object Storage is a bulk data service for buckets and objects; it has no packet-processing path and cannot sit inline in VCN routing. Inspection needs a firewall instance or OCI Network Firewall with route tables steering traffic through it. Object Storage tempts as a managed OCI service, but it operates at the application layer, not the network path.

The database instantly crashes and forces an immediate failover to the standby database

Why it fails: Loss of OCI Vault connectivity does not crash the database or trigger failover; cached master keys let the instance keep running, and only key operations such as TDE rekey or tablespace encryption fail. Crash-and-failover is tempting because it sounds like a high-availability safeguard, yet Data Guard failover addresses instance or site failure, not KMS reachability.

The database automatically falls back to self-managed wallet storage without alerting administrators

Why it fails: The database cannot silently switch to a local wallet; OCI Vault remains the configured keystore, and administrators receive alerts about the connectivity loss. Automatic fallback is tempting because wallet-based TDE is a legitimate alternative, but it would require explicit reconfiguration, not transparent substitution.

All encrypted data files are automatically wiped to prevent security breaches

Why it fails: TDE never destroys data files on vault outage; existing encrypted data remains readable because the master key is cached in the database instance. It is tempting as a breach-prevention measure, but key destruction is a deliberate administrative action, not an automatic response to lost connectivity.

Deploy all microservices into a single flat Kubernetes namespace to maximize intra-cluster communication speed.

Why it fails: A single flat namespace grants no isolation boundary, so one misconfigured NetworkPolicy, quota or RBAC change can disrupt every microservice simultaneously, undermining resilience. Namespaces are for logical separation and policy scoping; a flat layout would only be defensible for a small, single-team cluster with no multi-tenancy needs.

Store all application state and user sessions locally on the ephemeral container root filesystem.

Why it fails: Container root filesystems are ephemeral, so state and sessions vanish on pod restart or rescheduling, and the pod cannot be replicated safely. Externalising state to a database or OCI cache lets any replica serve any request. Local storage suits stateless scratch data or read-only caches, not session state.

Use NodePorts for all external microservice access directly bypassing the OCI Load Balancer.

Why it fails: NodePort exposes each service on every node's IP with a limited port range, giving no health-checked load balancing, TLS termination or DDoS protection, and node loss breaks access. An OCI Load Balancer provides these. NodePort suits internal debugging or temporary exposure, not production external access.

Disabling all authentication to maximize application performance.

Why it fails: Removing authentication entirely contradicts the zero-trust requirement that every request be verified, and grants unrestricted database access to anyone reaching the listener. It is tempting when latency dominates, since skipping credential checks removes handshake overhead, but token-based access via IAM database authentication or Entra ID federation is what the scenario demands.

Hardcoded administrator passwords stored in plain text configuration files.

Why it fails: Static administrator credentials in plain-text files are long-term secrets, directly violating the short-lived token requirement and exposing privileged access to anyone reading the filesystem. It is tempting as a quick bootstrap for scripts and CI jobs, where embedding a password avoids wiring up an identity provider, but rotation and auditing are then manual.

Using static API signing keys for database connection strings.

Why it fails: Static API signing keys are long-term credentials embedded in connection strings, directly contradicting the short-lived token requirement. It is tempting because signing keys do authenticate API calls, but they persist until rotated; the scenario needs OCI IAM token-based database authentication, not static keys.

Single large monolithic database instance shared by all microservices without connection pooling

Why it fails: A shared monolithic database without connection pooling concentrates failure and exhausts connections during transient outages, propagating errors across services. It is tempting for simplifying data consistency, and would suit a small co-located deployment, but it defeats the bulkheads and circuit breakers this scenario requires.

Disabling all health checks and liveness probes to prevent container restarts

Why it fails: Removing health checks and liveness probes prevents Kubernetes from detecting and replacing unhealthy containers, so transient failures become permanent outages. It is tempting to stop restart loops, and would be reasonable for debugging a crash-looping pod, but it removes the self-healing mechanism resiliency depends on.

Run a simple 'SWITCHOVER' command to reverse roles without any data synchronization checks.

Why it fails: After a failover the old primary is in an unresolved state and must be reinstated as a standby via Data Guard's reinstate operation, which resynchronises it from the new primary. Switchover applies only to planned role reversal between two healthy, synchronised databases.

Modify the listener.ora file manually via SSH and restart the clusterware.

Why it fails: Editing listener.ora and restarting clusterware does not re-establish the Data Guard broker configuration or reinstate the old primary as a standby. Use the broker's reinstate command to resynchronise the former primary; manual listener edits address connectivity, not role reversal.

Delete the standby database and provision a brand-new VCN in the primary region.

Why it fails: Deleting the standby and provisioning a new VCN discards the existing Data Guard configuration and network, which is unnecessary. Reinstate the old primary as standby using the existing association and VCN; only the database role needs reinstating, not the underlying network infrastructure.

IAM Policy Condition statements with 'request.time'

Why it fails: Time-based conditions only evaluate when a request occurs, so they cannot block creation of public buckets or open security list rules; they gate access by clock, not resource configuration. They suit temporary access windows or scheduled privilege expiry, not baseline enforcement. OCI Cloud Guard or security zones apply the required preventive controls.

OCI Audit Log Service with Event-Driven Automation

Why it fails: Audit Log Service records API activity after it occurs, and event-driven automation reacts post-creation, so a public bucket or open rule already exists before remediation. Detection and response suit monitoring and alerting scenarios; the stem requires preventive enforcement at creation time, which security zones or Cloud Guard provide.

OCI Tag Defaults with validation rules

Why it fails: Tag defaults merely auto-apply defined tags to resources at creation; validation rules constrain tag values, not resource configuration such as bucket visibility or security list ingress. They suit governance and cost allocation, not security baselines. Security zones or Cloud Guard enforce the mandated guardrails instead.

Standard OKE worker nodes with Kubernetes LimitRanges

Why it fails: LimitRanges only cap CPU and memory requests per pod; they enforce no kernel-level boundary, so a breakout escapes to other tenants. They are tempting because resource governance is a standard multi-tenancy control, and LimitRanges would be correct for preventing one tenant starving others of cluster capacity.

Standard worker nodes with Network Security Groups (NSGs) applied per pod

Why it fails: Network Security Groups filter traffic at the VNIC level; they do not partition the host kernel, so a container breakout still reaches co-tenant processes on the same node. NSGs are tempting because they segment pod traffic cleanly, and they would be correct for enforcing east-west network policy between namespaces.

Worker nodes running Docker Engine with privileged containers enabled

Why it fails: Privileged containers share the host kernel and gain elevated capabilities, directly enabling the breakout the scenario must prevent. Docker Engine with privileged mode is tempting because it simplifies running workloads needing host access, and it would be correct for trusted single-tenant nodes running system-level agents, not hostile multi-tenant workloads.

Use Logging Analytics custom parsers on generated invoice PDFs stored in Object Storage.

Why it fails: Parsing invoice PDFs yields retrospective, aggregated figures without resource-level tag attribution or real-time anomaly detection. It is tempting because invoices are the authoritative billing record, and Logging Analytics parsing would suit auditing discrepancies between invoiced amounts and expected charges.

Use native OCI Tag Defaults and OCI Monitoring alarms on the 'Billing' metric namespace.

Why it fails: Tag Defaults only apply tags at resource creation and Monitoring alarms on the Billing namespace lack the historical trend and anomaly detection required. It is tempting because both are native OCI cost tools, and Tag Defaults would suit enforcing consistent tagging across newly provisioned resources.

Deploy OCI APM Java agents to every compute node and query the JVM memory usage to estimate spend.

Why it fails: APM Java agents capture application performance telemetry such as JVM memory, not resource metadata tags or billing data, so no cost attribution is possible. It is tempting because APM provides deep observability, and it would be the correct choice for diagnosing Java application latency or memory leaks.

Exceeded OCI Block Volume IOPS limits on the standby database's local NVMe scratchpad.

Why it fails: Redo transport lag reflects network bandwidth or log-write throughput, not local NVMe scratchpad IOPS on the standby, which affects apply, not shipping. IOPS limits matter when the standby's apply process falls behind, producing apply lag rather than transport lag.

Misconfigured OCI IAM policy allowing read-only access to database backups.

Why it fails: IAM policies govern authorisation, not redo transport throughput, so read-only backup access cannot delay redo shipping. It would matter when auditing permissions or troubleshooting denied access, not when diagnosing Data Guard transport lag against a five-minute RPO.

Incorrect OCI Load Balancer SSL certificate configuration on the web tier.

Why it fails: Load balancer SSL certificates terminate web-tier TLS and have no bearing on Data Guard redo shipping between primary and standby. Certificate misconfiguration matters when clients report handshake failures or expired certificates on the application endpoint, not database replication lag.