Security Services practice questions

Route Tables

Why it fails: Route tables determine where network traffic is directed, such as to a gateway or a local peering connection. They do not filter traffic based on source or destination IP addresses or ports. While route tables could direct traffic, they cannot enforce the restriction that only the application subnet can access the database subnet, nor do they provide traffic logging.

Network Security Groups (NSGs)

Why it fails: NSGs are virtual firewalls that apply to individual VNICs, not to subnets. They are useful for micro-segmentation within a subnet, but the requirement here is to restrict traffic at the subnet level. Using NSGs would require associating them with each VNIC in the database subnet, which is less efficient and does not enforce the boundary between subnets as directly as security lists do.

Internet Gateway

Why it fails: An Internet Gateway provides a path for traffic to and from the internet for resources in a VCN. It is not a security control and does not restrict subnet-to-subnet traffic. The database subnet likely should not have an Internet Gateway at all. Using it would not meet the requirement of restricting traffic to only the application tier.

Security lists are applied at the VNIC level and can have different rules for each instance, allowing granular per-instance control.

Why it fails: This is incorrect because security lists are applied at the subnet level, not the VNIC level. All VNICs in the subnet are subject to the same security list rules. If the engineer needs per-instance rules, they should use network security groups (NSGs), which are applied at the VNIC level. For the given scenario, subnet-level control is acceptable, but the statement misrepresents how security lists work.

Security lists use stateful rules by default, meaning return traffic is automatically allowed for ingress and egress connections.

Why it fails: This is incorrect because security lists in OCI are stateless by default. Return traffic must be explicitly allowed by corresponding ingress and egress rules. This is a common misconception; only network security groups (NSGs) support stateful rules. The engineer must configure both directions for the required traffic, which adds complexity but is necessary for proper enforcement.

Security lists can only be applied to public subnets; private subnets require network security groups for traffic filtering.

Why it fails: This is incorrect because security lists can be applied to both public and private subnets. They are a subnet-level firewall feature available for any subnet in a VCN. Network security groups are optional and provide VNIC-level control, but they are not required for private subnets. The engineer can use security lists in either subnet type, so this statement is false.

OCI Cloud Guard with a responder recipe targeting Object Storage

Why it fails: Cloud Guard detects misconfigurations and risky activity and can trigger responders, but it does not hold or manage encryption keys. It cannot generate, rotate, or disable the cryptographic material protecting bucket objects. It is a posture-management and detection service, so it fails the core requirement of controlling the encryption keys themselves.

OCI Certificates service with a private certificate authority

Why it fails: OCI Certificates issues and manages TLS certificates and private CA hierarchies for workloads, not symmetric data-encryption keys for Object Storage. It cannot generate or rotate the AES master keys that Object Storage uses for at-rest encryption, and disabling a certificate does not disable decryption of bucket data. It addresses transport identity, not data-at-rest key custody.

OCI Key Management with Oracle-managed keys on the bucket

Why it fails: Oracle-managed keys are stored and rotated by Oracle without customer visibility or control. The organization cannot disable them on demand or enforce its own rotation schedule, and it has no ability to move that key material. This conflicts with the requirement for organization-generated keys under direct custodianship.

Allow group NewEmployees to read all-resources in compartment Production

Why it fails: This policy uses the verb 'read', which in OCI IAM typically grants permission to list and get resources but not to inspect their details. The verb 'inspect' is more appropriate for read-only access that includes metadata. However, the verb 'read' does not allow modification, so it is partially correct but not the best choice because it may not grant sufficient access for all read operations. The administrator should use 'inspect' for read-only access.

Allow group NewEmployees to use all-resources in compartment Production

Why it fails: This is incorrect because the 'use' verb grants permission to work with resources but does not include the ability to create or delete them. However, 'use' typically allows actions like attaching or detaching resources, which goes beyond read-only access. It may also allow modifying certain properties. Therefore, it is not suitable for a read-only requirement. The 'inspect' verb is the correct choice for read-only access.

Allow group NewEmployees to manage all-resources in compartment Production

Why it fails: This is incorrect because the 'manage' verb grants full control over resources, including create, update, and delete permissions. This would give the employee more access than required and violate the principle of least privilege. The administrator needs to restrict the employee to read-only actions, so 'manage' is too permissive. The 'inspect' verb provides the necessary read-only access without modification rights.

Identity and Access Management (IAM) policies

Why it fails: IAM policies control access to OCI resources for users and groups, not for incoming web traffic. They are used to authorize API calls and console actions. They do not inspect HTTP requests or block application-layer attacks like SQL injection. Geographic access control for web users is not an IAM function; it is handled by WAF or network-level controls.

Network Security Groups (NSGs)

Why it fails: NSGs operate at the network layer (Layer 3/4) and control traffic based on IP addresses, ports, and protocols. They cannot inspect HTTP payloads to detect SQL injection or cross-site scripting, which are application-layer attacks. While NSGs can restrict traffic by source IP, they do not provide geographic-based access control at the application level.

Cloud Guard

Why it fails: Cloud Guard is a security posture management service that detects misconfigurations and risky activities across OCI resources. It does not sit in the data path to inspect or block web traffic. It can alert on insecure configurations but cannot prevent SQL injection or XSS in real time, nor does it provide geographic access control for web applications.

Server-side encryption with AES-256 keys stored in the Object Storage bucket's metadata

Why it fails: Server-side encryption with keys stored in bucket metadata is not a supported OCI feature. Object Storage supports server-side encryption with Oracle-managed or customer-managed keys in OCI Vault, but not keys stored in metadata. Storing keys in metadata would be insecure and does not provide the required key management and rotation capabilities. Thus, this option is invalid.

Oracle-managed encryption keys with automatic rotation

Why it fails: Oracle-managed keys are managed by Oracle and do not allow customer control over rotation schedules. The company requires using their own keys and automatic rotation every 90 days, which Oracle-managed keys do not support. While Oracle-managed keys provide encryption at rest, they lack the customization and control needed for this compliance scenario. Therefore, this option does not meet the requirements.

Client-side encryption using a third-party tool before uploading to Object Storage

Why it fails: Client-side encryption encrypts data before it reaches OCI, so OCI Vault is not used for key management. The company specifically wants to use OCI Vault for keys and automatic rotation. Client-side encryption would require managing keys outside OCI, which does not satisfy the requirement of using OCI Vault. Therefore, this option is not appropriate.

Enable the Cloud Guard service and configure a reporting region for findings

Why it fails: Cloud Guard is valuable for aggregating and reviewing security findings and responding to risky tenancy configurations, and it can ingest detector findings. However, on its own it does not install host-level agents that monitor process execution or file integrity on Compute instances. It is the central review and response layer, not the host sensor, so it does not provide the runtime detection capability described.

Attach a network security group to the instances and enable flow logs

Why it fails: Network security groups act as virtual firewalls controlling which traffic reaches the instances, and flow logs record connection metadata for auditing. Both are useful for network-level visibility and control, but neither inspects processes running inside the operating system nor detects file modifications. They operate at the network layer and cannot satisfy the host-runtime monitoring requirement.

Deploy the Cloud Agent with the Vulnerability Scanning and Bastion plug-ins

Why it fails: The Vulnerability Scanning plug-in inventories packages and reports missing patches, and the Bastion plug-in supports managed SSH sessions. Neither monitors running processes for suspicious execution nor watches files for unauthorized modification. They address patch visibility and administrative access, so they cannot deliver the runtime threat detection and file integrity monitoring the team requires.

Security lists with stateless rules to allow ingress on port 1521 from the web tier subnet and egress from the database tier to the web tier.

Why it fails: This is incorrect because security lists are stateless and would require explicit rules for return traffic. While they can restrict traffic, they are applied at the subnet level and cannot easily enforce that the database tier cannot initiate connections to the web tier without complex rules. NSGs are more suitable for this granular, stateful requirement.

OCI Audit service to log all API calls made to the OCI resources, including network configuration changes.

Why it fails: This is incorrect because OCI Audit service logs API calls to OCI services, not network traffic. It would record changes to security rules but not the actual traffic between tiers. For auditing network traffic, VCN flow logs are the appropriate tool. Audit service is for control plane operations, not data plane traffic.

Web Application Firewall (WAF) to inspect and filter traffic between the web and database tiers.

Why it fails: This is incorrect because WAF is designed to protect web applications from HTTP-based attacks at the edge, not to filter internal traffic between tiers. It operates at Layer 7 and is typically deployed in front of web servers, not between application tiers. Using WAF for database traffic is not feasible as it doesn't understand database protocols.

OCI Bastion

Why it fails: OCI Bastion provides restricted SSH access to private subnets; it aggregates no security findings across tenancies or compartments. It is tempting because Bastion hardens administrative access, making it the right choice when the requirement is controlled jump-host connectivity rather than a consolidated risk dashboard.

OCI Web Application Firewall

Why it fails: Web Application Firewall inspects inbound HTTP traffic against OWASP-style rules at a region edge; it produces no cross-tenancy risk aggregation or dashboard. It is tempting because it is a security service, and it would be correct when the requirement is filtering malicious web requests reaching an application.

OCI Vault

Why it fails: Vault stores and rotates encryption keys and secrets; it neither collects risk findings nor spans tenancies in a dashboard. It is tempting as a security-named service, and it would be correct when the requirement is centrally managing customer-managed keys and secret credentials.

Oracle

Why it fails: Oracle manages the cloud infrastructure, hypervisor and service availability, but customer tenancy identity objects remain the customer's responsibility. Oracle ownership is correct for the physical hosts, network fabric and managed service patching, not for user accounts or MFA enrolment.

Both Oracle and the customer jointly via shared IAM consoles

Why it fails: OCI IAM is not jointly administered; Oracle never co-manages customer tenancy users, password policies or MFA settings through a shared console. Joint responsibility applies to patching and configuration of Oracle-managed services, not to identity administration within the customer tenancy.

Third-party identity auditor

Why it fails: Third-party auditors assess compliance and produce attestations; they hold no administrative authority over tenancy identity configuration. Engaging an auditor is correct when independent assurance over controls is required, not when assigning operational responsibility for accounts, passwords or MFA.

Cloud Guard

Why it fails: Cloud Guard detects misconfigurations and raises problems or triggers responders, but it is detective and reactive rather than a preventive guardrail that blocks public IP attachment at creation. It would be the right choice for continuous posture monitoring and threat detection across a tenancy.

Web Application Firewall

Why it fails: Web Application Firewall filters HTTP/S traffic at layer 7 against web exploits, so it cannot inspect or block a VNIC's public IP assignment. It is tempting because it enforces security policy at the network edge, and would be correct for protecting a public-facing web application from SQL injection or cross-site scripting.

Vault Service

Why it fails: Vault Service stores and manages encryption keys and secrets; it has no mechanism to evaluate or block public IP attachment on compute instances. It is tempting because it enforces compliance controls, and it would be correct for centrally managing the keys protecting data at rest.

Hypervisor patching and firmware updates on the physical host

Why it fails: Hypervisor patching and host firmware updates are performed by Oracle, since OCI manages the virtualisation layer beneath every compute instance. It tempts because patching is a familiar customer task, but that applies to the guest OS and applications; the hypervisor and physical host remain firmly within Oracle's domain.

Redundancy and cooling of the physical networking hardware

Why it fails: Redundancy and cooling of physical networking hardware sit with Oracle, which owns and operates the data centre facilities under the shared-responsibility model. It tempts because resilience and environmental control sound like design choices, yet OCI delivers them as part of the infrastructure layer, leaving customers responsible only for their own configurations and data.

Physical security of the data center hosting the compute instances

Why it fails: Physical data centre security is Oracle's responsibility; OCI controls facility access, surveillance and hardware protection. It tempts because security is often assumed to be wholly customer-owned, but the shared-responsibility split places physical safeguards with Oracle, leaving the customer to secure identities, data, and guest OS configurations.

Object Storage with customer-managed keys

Why it fails: Object Storage holds data at rest with customer-managed keys for encryption, but it does not provide a secrets retrieval API or rotation. Tempting because it encrypts stored content, yet it suits bulk unstructured data, not dynamic credential retrieval by applications.

Key Management Service Master Keys

Why it fails: KMS master keys encrypt data and manage cryptographic material, but they do not store or serve connection strings and API tokens as retrievable secrets. Tempting because keys protect credentials, yet KMS suits encryption operations, not dynamic secret retrieval.

Identity and Access Management Dynamic Groups

Why it fails: Dynamic Groups grant principals access to resources based on matching rules, not secret storage or retrieval. Tempting because they automate identity, but they authorise access rather than hold connection strings and tokens, so applications cannot fetch credentials from them.

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.

Vault Master Encryption keys

Why it fails: Vault master encryption keys protect data at rest in OCI Vault and have no bearing on IAM policy evaluation, so Cloud Guard cannot derive permissive-policy problems from them. They would be relevant when configuring customer-managed encryption rather than detecting policy misconfiguration.

Security Zone recipes

Why it fails: Security Zone recipes define the policies and detector settings applied to resources inside a security zone, producing problems for that zone's resources. The stem's problems span multiple compartments from IAM policy analysis, which the IAM policy detector, not zone recipes, originates.

Responder recipes

Why it fails: Responder recipes define the automated remediation actions Cloud Guard takes once a problem is detected; they do not generate the problems themselves. They would be the correct answer if the question asked how detected problems are automatically corrected.

Dynamic Routing Gateway

Why it fails: A Dynamic Routing Gateway is a virtual router attaching a VCN to on-premises or peer networks, requiring exactly the VPN or FastConnect setup the scenario rules out. It suits hybrid routing between networks, whereas reaching one private instance needs the OCI Bastion service's session-based access.

NAT Gateway

Why it fails: A NAT gateway only translates outbound traffic from private subnets to the internet; it permits no inbound sessions to the database. It is correct when private instances need software updates or API calls outward, but the requirement is inbound administrative access, which OCI Bastion service provides instead.

Site-to-Site VPN

Why it fails: Site-to-Site VPN establishes IPsec connectivity between on-premises networks and the VCN, which the scenario explicitly excludes. It is the right choice when linking an entire corporate network to OCI, but here a single operator needs session access to one private instance without any VPN infrastructure.

Use client-side encryption with a key stored on a compute instance's boot volume.

Why it fails: Storing the encryption key on a compute instance's boot volume introduces significant risk: the key is not centrally managed, lacks rotation automation, and could be exposed if the instance is compromised. This approach does not leverage OCI Vault and fails to meet compliance for secure key management and rotation. It also complicates data access for other services.

Use Oracle-managed encryption keys and enable automatic rotation.

Why it fails: Oracle-managed keys are managed by Oracle, not the customer. The organization cannot control rotation schedules or access policies for these keys. While Oracle does rotate them, the customer has no visibility or control, which fails the compliance requirement for customer-managed keys with a specific 90-day rotation policy. This approach is suitable for less stringent requirements.

Use HTTPS for data in transit and rely on default server-side encryption for data at rest.

Why it fails: HTTPS protects data in transit, but the requirement is for encryption at rest with customer-managed keys and rotation. Default server-side encryption uses Oracle-managed keys, which do not provide the necessary control or rotation schedule. This option addresses a different aspect of security and does not satisfy the compliance mandate for key management.

Dynamic groups

Why it fails: Dynamic groups match compute instances or other resources by rules rather than by human user membership, and they are used to authorize workloads that call OCI APIs. They do not provide a separate container for users and groups, and they cannot represent a business unit's employee identities. They are a workload-identity mechanism, not an identity namespace.

Federation with an external identity provider

Why it fails: Federation lets users from an external IdP sign in to OCI, but on its own it does not create an isolated container of users and groups inside the tenancy. The users remain external and are mapped through the federation configuration. Without an identity domain to host the mapping and groups, isolation of identities per business unit is not achieved.

Compartments

Why it fails: Compartments organize and isolate resources such as compute, networking, and storage, and they are the scope for many IAM policies. However, compartments do not contain users or groups; identities live at the tenancy level. Creating a compartment alone does not give a business unit its own user and group namespace, so it does not meet the isolation requirement described.

OCI Cloud Guard

Why it fails: Cloud Guard continuously assesses the tenancy for security misconfigurations and suspicious activity and can trigger responders. It does not sit inline with application traffic, so it cannot inspect individual HTTP requests for cross-site scripting or block a source IP in real time. It is a posture and threat-detection service, not an application-layer enforcement point.

OCI Bastion

Why it fails: OCI Bastion provides time-limited, audited SSH sessions to private targets without exposing them publicly. It is an administrative access service, not an inline traffic inspection point. It cannot examine inbound HTTP requests from internet users for cross-site scripting, and it has no mechanism to block malicious client IPs. It addresses operator access rather than application traffic.

OCI Network Firewall

Why it fails: OCI Network Firewall inspects traffic at Layers 3 and 4 and can apply intrusion detection and prevention signatures and URL filtering, but it is a network-layer appliance. It does not provide managed rule sets specifically tuned for application-layer exploits like cross-site scripting in HTTP payloads, nor does it automatically block offending client IPs based on web attack signatures. It targets network traffic, not HTTP application content.

Allow group ComputeAdmins to read instances in compartment Production

Why it fails: The 'read' verb only allows viewing of instances, not managing them. The employee would not be able to create, update, or delete instances. The requirement is to manage compute instances, which implies full control. This policy would not provide the necessary permissions.

Allow group ComputeAdmins to manage instances in tenancy

Why it fails: This policy grants management of instances across the entire tenancy, not just the Production compartment. It would allow the employee to manage instances in any compartment, which exceeds the required scope. The principle of least privilege dictates that access should be limited to the specific compartment.

Allow group ComputeAdmins to manage all-resources in tenancy

Why it fails: This policy grants the group full management of all resources across the entire tenancy, which is far broader than required. It violates the principle of least privilege and gives the employee access to resources beyond compute instances in the Production compartment. This would be a significant security risk.