Scenario practice questions

Which TWO methods can be used to securely connect to a private OCI compute instance that does not have a public IP address? (Choose two.)

Trap 1: Accessing the instance via Object Storage pre-authenticated requests

Object Storage pre-authenticated requests provide secure, time-limited URLs to download or upload specific storage buckets or objects without requiring credentials, making them ideal for sharing data blobs with external applications or users over HTTPS. However, they fail to provide an interactive shell session or network tunnel required to remotely manage an operating system. Therefore, they cannot establish an interactive administrative connection to a private compute instance lacking a public IP address.

Trap 2: Changing the instance subnet to public temporarily while debugging

Attaching a public IP address to the instance violates the fundamental security requirement for isolated private workloads and exposes the server directly to the public internet, increasing the attack surface. Administrators are often tempted to use this workaround because assigning an ephemeral public IP combined with an Internet Gateway provides immediate inbound connectivity for troubleshooting via SSH or RDP. However, the correct approach for secure access without exposing resources externally is to configure an OCI Bastion service or a site-to-site VPN connection.

Trap 3: Direct RDP or SSH over the Internet Gateway without any…

Connecting via an Internet Gateway requires a public IP address on the target resource, meaning this approach fails when instances lack one and cannot receive inbound traffic from the public internet. This method is tempting because an Internet Gateway is the standard architectural component used to enable bidirectional communication between a Virtual Cloud Network and the public internet, making it the correct choice when administering public-facing compute instances that possess assigned public IP addresses.

A
Accessing the instance via Object Storage pre-authenticated requests
Why it fails: Object Storage pre-authenticated requests provide secure, time-limited URLs to download or upload specific storage buckets or objects without requiring credentials, making them ideal for sharing data blobs with external applications or users over HTTPS. However, they fail to provide an interactive shell session or network tunnel required to remotely manage an operating system. Therefore, they cannot establish an interactive administrative connection to a private compute instance lacking a public IP address.
B
OCI Bastion Service
OCI Bastion Service provides a managed, secure access pathway for target resources that lack public IP addresses, directly satisfying the requirement to reach a private compute instance without exposing it to the public internet. By establishing an ephemeral SSH session through a fully managed service, it removes the operational overhead and security risks associated with maintaining traditional public-facing jump hosts. It acts as a protocol-compliant intermediary that restricts traffic strictly to authorised users via IAM policies and designated CIDR block allowlists.
C
A bastion host (jump server) deployed in a public subnet with SSH tunneling
Deploying a bastion host in a public subnet directly satisfies the constraint of reaching a private OCI compute instance lacking a public IP address. By acting as an intermediary jump server, administrators can establish an SSH tunnel—such as local port forwarding—through the public-facing bastion to securely route traffic across the Virtual Cloud Network (VCN) to the private instance. This architecture eliminates the need to expose backend resources directly to the internet while still permitting administrative access via encrypted channels.
D
Changing the instance subnet to public temporarily while debugging
Why it fails: Attaching a public IP address to the instance violates the fundamental security requirement for isolated private workloads and exposes the server directly to the public internet, increasing the attack surface. Administrators are often tempted to use this workaround because assigning an ephemeral public IP combined with an Internet Gateway provides immediate inbound connectivity for troubleshooting via SSH or RDP. However, the correct approach for secure access without exposing resources externally is to configure an OCI Bastion service or a site-to-site VPN connection.
E
Direct RDP or SSH over the Internet Gateway without any intermediate host
Why it fails: Connecting via an Internet Gateway requires a public IP address on the target resource, meaning this approach fails when instances lack one and cannot receive inbound traffic from the public internet. This method is tempting because an Internet Gateway is the standard architectural component used to enable bidirectional communication between a Virtual Cloud Network and the public internet, making it the correct choice when administering public-facing compute instances that possess assigned public IP addresses.

Question 2hardmultiple choice

You are troubleshooting a performance issue on an OCI compute instance. You suspect that the instance is experiencing CPU throttling due to credits being exhausted. Which compute shape type are you most likely using?

Trap 1: HPC (High-Performance Computing) Shape

HPC shapes bill on-demand for full CPU without a burstable credit model, so credit exhaustion cannot occur. It is tempting because throttling suggests constrained CPU, but burstable shapes such as VM.Standard.E3 or E4 Flex are the ones that exhaust credits.

Trap 2: Bare Metal Standard Shape

Bare Metal shapes give dedicated physical cores with no burst-credit mechanism, so CPU throttling from exhausted credits cannot occur. Burstable VM shapes (such as E3/E4 flex with baseline OCPU utilisation) are the ones that consume credits and throttle once depleted, which is the scenario described.

Trap 3: GPU Shape

Graphics Processing Units are designed for massively parallel workloads such as machine learning, rendering, and scientific simulations rather than CPU credit-based throttling. They would be the correct choice if you were troubleshooting deep learning model training speeds or complex parallel rendering pipelines running on OCI instances equipped with NVIDIA hardware. However, they rely on dedicated high-performance processor architectures that bill continuously for dedicated physical resources, meaning they never accumulate or exhaust burstable CPU credits, making this shape entirely unrelated to the credit exhaustion issue described in the scenario.

A
HPC (High-Performance Computing) Shape
Why it fails: HPC shapes bill on-demand for full CPU without a burstable credit model, so credit exhaustion cannot occur. It is tempting because throttling suggests constrained CPU, but burstable shapes such as VM.Standard.E3 or E4 Flex are the ones that exhaust credits.
B
Standard AMD Flexible Shape with baseline OCPU performance enabled
Baseline OCPU performance on a Standard AMD flexible shape uses burst credits; exhausting them throttles the instance to the baseline fraction of each OCPU. This directly explains the observed CPU throttling, unlike fixed shapes or high-performance variants that never draw on credits.
C
Bare Metal Standard Shape
Why it fails: Bare Metal shapes give dedicated physical cores with no burst-credit mechanism, so CPU throttling from exhausted credits cannot occur. Burstable VM shapes (such as E3/E4 flex with baseline OCPU utilisation) are the ones that consume credits and throttle once depleted, which is the scenario described.
D
GPU Shape
Why it fails: Graphics Processing Units are designed for massively parallel workloads such as machine learning, rendering, and scientific simulations rather than CPU credit-based throttling. They would be the correct choice if you were troubleshooting deep learning model training speeds or complex parallel rendering pipelines running on OCI instances equipped with NVIDIA hardware. However, they rely on dedicated high-performance processor architectures that bill continuously for dedicated physical resources, meaning they never accumulate or exhaust burstable CPU credits, making this shape entirely unrelated to the credit exhaustion issue described in the scenario.

Question 3hardmulti select

An architect is configuring an OCI Public Load Balancer to handle high volumes of incoming client traffic. Which THREE features or capabilities are supported by OCI Public Load Balancers?

Trap 1: Native BGP routing directly from the Load Balancer IP to…

OCI Public Load Balancers do not run BGP; they terminate client traffic and forward to backend sets. BGP peering belongs to DRGs and FastConnect virtual circuits. This option is tempting because BGP is used elsewhere in OCI networking, but the Load Balancer itself offers no native BGP capability.

Trap 2: Automatic translation of IPv6 client traffic into native IPv4…

OCI Public Load Balancers do not translate IPv6 client traffic to IPv4 backends; IPv6 listeners require the backend set to be reachable over the matching address family, so dual-stack configuration is needed. The feature is tempting because load balancers commonly terminate one protocol family, but that translation is not an OCI capability.

A
Multiple backend sets associated with a single listener via rule sets
Rule sets attach to a listener and let it select among multiple backend sets based on conditions such as path or host header, enabling content-based routing on one listener. This satisfies the high-volume requirement by distributing requests across several backend pools without provisioning extra listeners.
B
Native BGP routing directly from the Load Balancer IP to on-premises routers
Why it fails: OCI Public Load Balancers do not run BGP; they terminate client traffic and forward to backend sets. BGP peering belongs to DRGs and FastConnect virtual circuits. This option is tempting because BGP is used elsewhere in OCI networking, but the Load Balancer itself offers no native BGP capability.
C
Path-based routing rules to direct requests to different backend sets based on URL paths
Path-based routing enables the load balancer to inspect incoming HTTP requests and distribute traffic to specific backend sets according to defined URL patterns. This capability directly addresses the requirement to manage high volumes of complex traffic by allowing architects to route requests to specialised backend services based on the resource path. By decoupling application functions across distinct backend sets, this feature ensures efficient resource utilisation and granular traffic management, which is essential for scaling performance in high-traffic OCI environments.
D
SSL/TLS termination and certificate management
OCI Public Load Balancers offload the computational overhead of cryptographic handshakes from backend servers by performing SSL/TLS termination at the edge. By centralising certificate management within the service, architects ensure secure traffic decryption before forwarding requests to application instances. This capability directly addresses the requirement to handle high volumes of incoming client traffic efficiently, as it reduces the processing burden on individual compute resources while maintaining robust encryption standards across the infrastructure.
E
Automatic translation of IPv6 client traffic into native IPv4 backend compute instances without dual-stack configuration
Why it fails: OCI Public Load Balancers do not translate IPv6 client traffic to IPv4 backends; IPv6 listeners require the backend set to be reachable over the matching address family, so dual-stack configuration is needed. The feature is tempting because load balancers commonly terminate one protocol family, but that translation is not an OCI capability.

Question 4easymultiple choice

What is the function of the OCI IAM 'inspect' verb?

Trap 1: It allows users to inspect security vulnerabilities on compute…

Vulnerability management on compute instances falls under Oracle Cloud Infrastructure (OCI) Vulnerability Scanning rather than Identity and Access Management (IAM), making this verb completely unrelated to security posture assessments. This option is tempting because the term "inspect" colloquially suggests examining resources for flaws, and it could logically apply if the question concerned security compliance tooling or OCI Cloud Guard configurations. However, within OCI IAM policies, verbs strictly dictate permission levels for metadata management, where "inspect" specifically grants the ability to list and view resource definitions without accessing underlying content or security states.

Trap 2: It allows users to create, update, and delete resources.

Granting permissions to create, update, and delete resources requires the 'manage' or 'use' verbs in OCI Identity and Access Management, whereas the 'inspect' verb is strictly limited to metadata retrieval and listing operations without modification rights. This option is tempting because administrators frequently conflate broad operational permissions with read-only access levels. It would be the correct choice if the scenario asked for a policy statement granting full administrative lifecycle control over compartment resources.

Trap 3: It allows users to download object storage bucket files.

Object Storage file operations are handled by the OCI Object Storage service APIs and corresponding IAM permissions like `object-family` verbs, not IAM policy management verbs. This option is tempting because the word "inspect" sounds like a general permission to view data or files. However, the IAM `inspect` verb actually grants the ability to list resources within a compartment without viewing their content or metadata, such as listing buckets or users, which makes it entirely unrelated to downloading bucket objects.

A
It allows users to inspect security vulnerabilities on compute instances.
Why it fails: Vulnerability management on compute instances falls under Oracle Cloud Infrastructure (OCI) Vulnerability Scanning rather than Identity and Access Management (IAM), making this verb completely unrelated to security posture assessments. This option is tempting because the term "inspect" colloquially suggests examining resources for flaws, and it could logically apply if the question concerned security compliance tooling or OCI Cloud Guard configurations. However, within OCI IAM policies, verbs strictly dictate permission levels for metadata management, where "inspect" specifically grants the ability to list and view resource definitions without accessing underlying content or security states.
B
It allows users to create, update, and delete resources.
Why it fails: Granting permissions to create, update, and delete resources requires the 'manage' or 'use' verbs in OCI Identity and Access Management, whereas the 'inspect' verb is strictly limited to metadata retrieval and listing operations without modification rights. This option is tempting because administrators frequently conflate broad operational permissions with read-only access levels. It would be the correct choice if the scenario asked for a policy statement granting full administrative lifecycle control over compartment resources.
C
It allows users to list resources of a given type without viewing their contents or configuration details.
The 'inspect' verb in OCI Identity and Access Management satisfies the precise requirement to enumerate resources without exposing sensitive metadata by granting permission solely to list resources of a specified type. Unlike the 'read' verb, which permits viewing full configuration details and resource contents, or 'use' and 'manage' which allow operational changes, 'inspect' operates strictly at the metadata enumeration layer. This aligns directly with the stem constraint, enabling users to verify resource existence and identifiers across compartments while enforcing the principle of least privilege regarding detailed object properties.
D
It allows users to download object storage bucket files.
Why it fails: Object Storage file operations are handled by the OCI Object Storage service APIs and corresponding IAM permissions like `object-family` verbs, not IAM policy management verbs. This option is tempting because the word "inspect" sounds like a general permission to view data or files. However, the IAM `inspect` verb actually grants the ability to list resources within a compartment without viewing their content or metadata, such as listing buckets or users, which makes it entirely unrelated to downloading bucket objects.

Question 5mediummultiple choice

You have deployed an OCI Function and invoked it, but it returns a timeout error. What is the maximum execution timeout limit supported by OCI Functions?

Trap 1: Infinite

OCI Functions enforces a finite maximum execution timeout, so infinite execution is impossible; a function exceeding the configured limit is terminated and returns a timeout error. It is tempting because serverless platforms abstract infrastructure, but the limit exists precisely to bound runaway invocations.

Trap 2: 60 seconds

Sixty seconds represents the default timeout value for OCI Functions, which frequently leads users to assume it is the hard architectural limit. While this duration is the standard configuration for new functions, the platform actually supports execution times up to 900 seconds. Choosing this option fails because it ignores the configurable nature of the timeout setting, which must be increased to accommodate long-running tasks that exceed the initial default threshold.

Trap 3: 3600 seconds (1 hour)

OCI Functions enforces a hard execution timeout limit of 300 seconds, rendering a 3600-second configuration invalid for function execution. This value is tempting because it represents the maximum timeout duration for OCI Container Instances, which are designed to support longer-running workloads. While developers often look to containerised environments for extended processing tasks, they must distinguish between the ephemeral, event-driven nature of OCI Functions and the persistent, long-running requirements handled by OCI Container Instances or OCI Compute services.

A
Infinite
Why it fails: OCI Functions enforces a finite maximum execution timeout, so infinite execution is impossible; a function exceeding the configured limit is terminated and returns a timeout error. It is tempting because serverless platforms abstract infrastructure, but the limit exists precisely to bound runaway invocations.
B
900 seconds (15 minutes)
OCI Functions enforces a strict execution timeout limit of 900 seconds, which directly addresses the timeout error encountered in the scenario. When a function exceeds this 15-minute threshold, the OCI platform terminates the process to prevent runaway resource consumption. This constraint is a fundamental architectural boundary for serverless workloads within the environment. Developers must ensure that long-running tasks are offloaded to alternative services, such as OCI Data Integration or OCI Container Instances, to remain within this defined execution window.
C
60 seconds
Why it fails: Sixty seconds represents the default timeout value for OCI Functions, which frequently leads users to assume it is the hard architectural limit. While this duration is the standard configuration for new functions, the platform actually supports execution times up to 900 seconds. Choosing this option fails because it ignores the configurable nature of the timeout setting, which must be increased to accommodate long-running tasks that exceed the initial default threshold.
D
3600 seconds (1 hour)
Why it fails: OCI Functions enforces a hard execution timeout limit of 300 seconds, rendering a 3600-second configuration invalid for function execution. This value is tempting because it represents the maximum timeout duration for OCI Container Instances, which are designed to support longer-running workloads. While developers often look to containerised environments for extended processing tasks, they must distinguish between the ephemeral, event-driven nature of OCI Functions and the persistent, long-running requirements handled by OCI Container Instances or OCI Compute services.

Question 6mediummultiple choice

You are configuring a Data Guard association between a primary Oracle Base Database Service DB system and a standby DB system in a different availability domain. The primary database encounters a catastrophic failure. Which action must you perform to promote the standby database to primary using the OCI Console?

Trap 1: Perform a Switchover operation from the standby database details…

Switchover requires the primary database to be running and performs a graceful, planned role reversal. With the primary catastrophically failed, no switchover is possible; failover is the operation that promotes the standby without the primary's participation.

Trap 2: Delete the Data Guard association and create a new primary database…

Deleting the association discards the standby and its synchronised data, then rebuilds from a backup, losing recent transactions. It is tempting as a clean rebuild path, but failover promotes the existing standby in place, preserving data with minimal loss.

Trap 3: Run RMAN restore commands directly on the standby host operating…

RMAN restore commands rebuild files on a host but do not perform Data Guard role transition, and the Console workflow is bypassed entirely. RMAN is for backup and recovery, whereas failover is the Data Guard operation that promotes the standby database.

A
Perform a Switchover operation from the standby database details page.
Why it fails: Switchover requires the primary database to be running and performs a graceful, planned role reversal. With the primary catastrophically failed, no switchover is possible; failover is the operation that promotes the standby without the primary's participation.
B
Delete the Data Guard association and create a new primary database from a backup.
Why it fails: Deleting the association discards the standby and its synchronised data, then rebuilds from a backup, losing recent transactions. It is tempting as a clean rebuild path, but failover promotes the existing standby in place, preserving data with minimal loss.
C
Perform a Failover operation from the standby database details page.
Failover promotes the standby when the primary is unavailable, which matches the catastrophic failure described. Unlike switchover, it requires no primary connectivity, so it works despite the outage. Initiating it from the standby's details page in the OCI Console satisfies the cross-availability-domain Data Guard scenario and restores write capability.
D
Run RMAN restore commands directly on the standby host operating system.
Why it fails: RMAN restore commands rebuild files on a host but do not perform Data Guard role transition, and the Console workflow is bypassed entirely. RMAN is for backup and recovery, whereas failover is the Data Guard operation that promotes the standby database.