Security practice questions

Use Oracle-managed encryption keys with automatic key rotation enabled.

Why it fails: Oracle-managed keys do not give the customer direct control over immediate key revocation or hardware security module ownership.

Rely on OCI Database Vault to manage cloud-level master encryption keys.

Why it fails: OCI Database Vault restricts database user access to application data, but does not manage VCN-level or storage-level master encryption keys.

Store plain-text keys in OCI Object Storage with restricted IAM policies.

Why it fails: Storing plain-text encryption keys in object storage is a critical security vulnerability and violates compliance standards.

Create separate tenancies for administrators and developers.

Why it fails: Separate tenancies split the identity domain, so administrators and developers cannot be governed by one IAM configuration combining console MFA with SAML federation to the enterprise IdP. It is tempting for isolation, and would be correct when regulatory separation or independent billing boundaries genuinely require distinct tenancies.

Write IAM policies with conditional statements checking the user's IP address.

Why it fails: IP-address conditions in IAM policies restrict where requests originate, not how users authenticate, so they neither enforce MFA for administrators nor federate developers through SAML 2.0. They are tempting as network-based hardening, and would be correct for limiting access to trusted corporate ranges alongside identity controls.

Disable native IAM users entirely and force all users to share a single administrator account with MFA.

Why it fails: A shared administrator account destroys individual accountability and cannot authenticate developers through the enterprise IdP via SAML 2.0, so it fails both requirements. It is tempting as a crude way to guarantee MFA on console access, and would suit a small environment with a single break-glass operator rather than federated developers.

OCI WAF rules configured for API Gateway.

Why it fails: WAF protects deployed web applications and APIs, but IAM conditions enforce administrative API source IP restrictions.

OCI Network Security Groups with CIDR block filters.

Why it fails: NSGs filter packet traffic to compute VNICs, not OCI control plane API requests.

OCI Service Gateway IP whitelisting.

Why it fails: Service Gateways control access to Oracle services from VCNs, not API endpoint source IPs.

Rely entirely on default VCN security lists without implementing Network Security Groups.

Why it fails: Relying solely on default security lists lacks granular, VNIC-level segmentation.

Disable OCI Audit logging to prevent log tampering by administrators.

Why it fails: Disabling audit logs destroys visibility, accountability, and compliance posture.

Expose all database instances directly to the public internet for easier management.

Why it fails: Exposing databases to the public internet is a critical security vulnerability.

OCI Internet Gateway attached to a public subnet.

Why it fails: Internet Gateways provide public internet connectivity, not private datacenter links.

Unencrypted public IP address assignment on database instances.

Why it fails: Public IP assignments expose instances to the internet and do not provide private datacenter connectivity.

All VCNs must have Internet Gateways attached by default.

Why it fails: Internet Gateways are generally restricted or controlled in Security Zones to prevent internet exposure.

IAM administrators are prohibited from creating any compartments.

Why it fails: Compartments can be created within Security Zones; the guardrails apply to resource configurations.

All compute instances must use unencrypted local boot volumes.

Why it fails: Security Zones require encryption, prohibiting unencrypted storage.

Disable multi-factor authentication (MFA) for federation users relying on external IdPs to streamline administrative logins.

Why it fails: Disabling MFA reduces security posture; federated setups should enforce MFA either at the IdP level or via OCI IAM security policies.

Assign users directly to administrative compartments using inline policies instead of defining groups.

Why it fails: Direct user-to-policy assignment or inline user policies violate core IAM best practices; users must be assigned to groups.

Use dynamic group matching rules based on resource OCIDs rather than compartment OCIDs for maximum flexibility.

Why it fails: Matching on resource OCIDs is brittle because resource OCIDs change when resources are recreated; compartment OCIDs or tags are preferred.

Enable OCI Cloud Guard Security Zones on the compartment and automatically enforce a deny-all policy on the bucket.

Why it fails: Security Zones enforce predefined security recipes, but they do not dynamically rewrite custom data access paths for specific Service Gateways.

Route all Object Storage traffic through a DRG (Dynamic Routing Gateway) and apply stateful network firewall rules to drop non-VCN traffic.

Why it fails: Traffic to Object Storage via a Service Gateway does not traverse a DRG; it uses regional service network routing.

Create an IAM policy with the condition 'where request.vcn.id = <vcn-ocid>' and attach a security list to the VCN subnet allowing outbound traffic to Object Storage.

Why it fails: Security lists control packet filtering at the subnet level, but IAM policy conditions with request.vcn.id ensure the API calls themselves originate from the authorized VCN.

Store the Vault master key backup passphrases in plain text inside an Object Storage bucket for easy disaster recovery access.

Why it fails: Storing passphrases in plain text violates basic security principles; secrets must always be encrypted and protected.

Share the Vault master encryption key directly across all global regions to simplify multi-region database encryption.

Why it fails: Master Encryption Keys cannot be shared directly across regions; each region requires its own keys or key replicas.

A stateful egress security rule in the database tier's security list allowing all traffic to the application tier's CIDR

Why it fails: This rule would allow the database tier to initiate connections to the application tier, which violates the requirement that the database cannot initiate connections back. It also does not enable the application to initiate connections to the database; that requires an egress rule in the application tier's security list or an ingress rule in the database tier's security list.

A stateless ingress security rule in the database tier's security list allowing TCP port 1521 from the application tier's CIDR

Why it fails: Stateless security lists require explicit rules for both directions. An ingress rule alone would allow the initial packet but block return traffic, breaking the connection. Additionally, it does not prevent the database from initiating connections if an egress rule is later added, so it does not meet the requirement.

A stateful ingress security rule in the application tier's security list allowing TCP port 1521 from the database tier's CIDR

Why it fails: This rule allows the database tier to initiate connections to the application tier on port 1521, which is the opposite of what is needed. It does not permit the application to initiate connections to the database, and it violates the requirement that the database cannot initiate connections back.

Allow group Developers to use objects in tenancy where target.bucket.name='AppBucket'

Why it fails: The verb 'use' is not a valid policy verb for Object Storage. OCI IAM policy verbs include inspect, read, use, manage, but for Object Storage, 'use' does not grant object read permissions. It would not allow the developer to read objects, so it fails the requirement.

Allow group Developers to inspect objects in tenancy where target.bucket.name='AppBucket'

Why it fails: The verb 'inspect' allows listing of resources but does not grant permission to read the contents of objects. The developer would be able to see that objects exist but not download or read them, which does not meet the requirement to read objects.

Allow group Developers to manage objects in tenancy where target.bucket.name='AppBucket'

Why it fails: The verb 'manage' grants full control, including create, read, update, and delete. This would allow the developer to delete or modify objects, which violates the requirement. It provides more permissions than necessary and is not the least privilege choice.

Create a bucket policy that requires encryption with the specified key

Why it fails: OCI Object Storage does not support bucket policies that enforce encryption key requirements. Bucket policies are used for access control, not for encryption enforcement. Therefore, this step would not achieve the goal of enforcing customer-managed keys for all new buckets.

Use a pre-authenticated request to enforce encryption on bucket creation

Why it fails: Pre-authenticated requests are used to grant temporary access to buckets or objects, not to enforce encryption settings. They cannot mandate that new buckets use a specific encryption key, so this option does not meet the requirement.

Enable a Security Zone that prohibits buckets without customer-managed keys

Why it fails: Security Zones enforce certain policies, but they do not currently include a policy to require customer-managed encryption keys for Object Storage buckets. Security Zones focus on preventing public access and other misconfigurations, not on encryption key types.

Enable OCI Audit logs and configure automated notifications via OCI Notifications service.

Why it fails: Audit logs record API activity against OCI resources and Notifications delivers alerts; neither inspects inbound HTTP payloads, so XSS and SQL injection requests pass through to the application unfiltered. It is tempting because logging is a familiar security control, and it would be correct for detecting and alerting on suspicious administrative or API actions.

Deploy an OCI Network Firewall with an SSL decryption profile in front of the application subnet.

Why it fails: An SSL decryption profile terminates TLS and inspects traffic, but OCI Network Firewall is a layer-3/4 appliance; it does not parse HTTP parameters to block XSS or SQL injection, which requires a web application firewall. It is tempting as an edge security control, and would be correct for filtering IPs, ports and protocols.

Implement OCI Cloud Guard Security Zones to automatically remediate application code flaws.

Why it fails: Cloud Guard Security Zones enforce resource configuration policies such as denying public buckets or unencrypted volumes; they cannot inspect HTTP requests or patch application code, so XSS and SQL injection payloads still reach the app. It is tempting as a posture-management service, and would be correct for preventing insecure resource configurations.

OCI Object Storage Server-Side Encryption with Oracle-Managed Keys (SSE-S3).

Why it fails: Oracle-managed keys are controlled by Oracle, so they cannot satisfy the customer-managed key and strict rotation requirement. It is tempting because it is the default Object Storage encryption needing no configuration, and it would be correct when policy permits provider-managed keys rather than customer-controlled ones.

OCI Database Management service.

Why it fails: Database Management provides fleet monitoring, tuning and administration for running databases; it does not encrypt objects in Object Storage. It is tempting because the data is database passwords, and it would be correct for managing database performance, patching and configuration across OCI database systems.

OCI Identity and Access Management (IAM) password policies.

Why it fails: IAM password policies govern credential complexity and rotation for user accounts, not encryption of objects at rest. It is tempting because the scenario mentions passwords and rotation, and it would be correct for enforcing password length, expiry and reuse rules on OCI identity domain users.

Dynamic Routing Gateway (DRG) with internet breakout enabled.

Why it fails: A DRG with internet breakout enabled routes inter-VCN traffic, but enabling breakout exposes the path to internet routing rather than keeping it private. It is tempting because DRGs do interconnect VCNs, and would be correct for private VCN peering without the breakout option enabled.

Internet Gateway with strict Security List rules.

Why it fails: An Internet Gateway only routes traffic to and from the public internet, so database traffic would traverse public address space rather than a private path. It is tempting because IGWs are the default egress construct, and would be correct for a public-facing web tier needing inbound internet access.

OCI Bastion service.

Why it fails: The Bastion service provides restricted SSH access for administrators to private hosts; it does not carry microservice-to-database traffic between VCNs. It is tempting because it is a private-access construct, and would be correct for operator sessions into a subnet with no public exposure.

A NAT Gateway combined with a public IP address on the database.

Why it fails: A NAT Gateway translates outbound private traffic to a public IP, so the connection still traverses the public internet, and Autonomous Database does not accept a public IP assigned to it. It is tempting because NAT Gateways do let private subnets reach the internet, which suits outbound access to public endpoints.

A Site-to-Site VPN connection back to the corporate data center.

Why it fails: A Site-to-Site VPN routes traffic through the corporate data centre and back, adding latency and a public internet hop rather than keeping traffic on Oracle's private backbone. It is tempting because VPNs do connect on-premises networks to OCI privately, which suits hybrid access to on-premises resources.

An Internet Gateway attached to the VCN route table.

Why it fails: An Internet Gateway routes traffic over the public internet, directly contradicting the requirement to avoid it, and provides no private path to Autonomous Database. It is tempting because Internet Gateways give VCN resources outbound connectivity, which suits public-facing workloads that must be reachable from anywhere.

Enable OCI Cloud Guard with default responder rules.

Why it fails: Cloud Guard detects threats and misconfigurations, but does not handle log immutability or compliance retention.

Deploy OCI Network Firewall to inspect all control plane traffic.

Why it fails: OCI Network Firewall inspects data plane traffic in VCNs, whereas control plane API calls are handled by IAM and the Audit service.

Set up OCI Events to stream API activities directly to an external SIEM using unencrypted HTTP endpoints.

Why it fails: Unencrypted HTTP endpoints violate data transit security best practices and do not guarantee tamper-proof log storage.

OCI Audit.

Why it fails: OCI Audit records API activity for later inspection; it does not evaluate configurations or produce a security score. It is tempting because it is a tenancy-wide security service, and it is the correct choice when you need an immutable log of who called which API and when.

OCI Web Application Firewall.

Why it fails: OCI Web Application Firewall filters inbound HTTP traffic to protected endpoints; it neither scans tenancy resources for misconfigurations nor computes a security score. It is tempting because it is a security service, and it is correct when you must block application-layer attacks such as SQL injection against a load balancer.

OCI Vulnerability Scanning Service.

Why it fails: Vulnerability Scanning Service inspects hosts and containers for known CVEs, not misconfigurations or behavioural risk, so it cannot produce a tenancy-wide security score. It is tempting because it also lives under OCI Security, and it would be correct when the requirement is scheduled package and port scanning of compute instances.

Create a single dynamic group containing all compute instances across the tenancies and attach a root-level policy.

Why it fails: A single dynamic group spanning tenancies cannot exist, since dynamic groups are scoped to one tenancy's identity domain; cross-tenancy access requires policies in each tenancy plus resource principals. It tempts because grouping instances by matching rules is the normal pattern for workload authentication within a single tenancy.

Disable compartment security boundaries and assign all users to the Administrators group.

Why it fails: Removing compartment boundaries and granting Administrators to everyone eliminates least-privilege isolation, so dynamic groups cannot be scoped per compartment. Best practice uses dynamic groups with compartment-scoped policies. This tempts as a shortcut to avoid policy complexity, but it breaks tenancy separation.

Use IAM user credentials hardcoded inside the application configuration files on the compute instances.

Why it fails: Hardcoded IAM user credentials create long-lived secrets that cannot rotate automatically and bypass instance-principal authentication entirely. It tempts because static API keys are the traditional way to authenticate scripts, and would suit a single-tenant proof-of-concept where dynamic groups are unavailable.

OCI IAM compartments with default root-level policies.

Why it fails: IAM policies grant or deny API permissions but cannot automatically apply preventive controls to every newly created compartment. Root-level policy defaults suit governing who may call which APIs, whereas the scenario demands policy inheritance that blocks public buckets and audit disabling by default.

OCI Cloud Guard targets with active detector recipes.

Why it fails: Cloud Guard targets with detector recipes detect and respond to misconfigurations after resources exist, rather than preventing them at creation. Cloud Guard is the right choice for continuous threat detection and remediation across existing tenancies, not for enforcing preventive guardrails on new compartments.

OCI Network Security Groups (NSGs) applied to the VCN.

Why it fails: Network Security Groups filter traffic at the VNIC level and have no visibility into Object Storage bucket visibility or audit log settings. NSGs are correct when the requirement is controlling ingress and egress between compute resources inside a VCN, not governing compartment-level security posture.