OCI 2025 Developer Professional Free Sample Questions

OCI Service Mesh is the correct choice as it is designed to manage, secure, and observe microservices. It provides features like mutual TLS (mTLS) for encrypting inter-service communication and sophisticated traffic management capabilities (e.g., traffic splitting for A/B testing) without requiring changes to the application code. A Network Load Balancer operates at L4 and doesn't manage internal service-to-service traffic rules. An API Gateway is for managing north-south traffic (from clients to the cluster), not east-west traffic (between services). Kubernetes Network Policies can restrict traffic but don't offer advanced routing or automatic mTLS.

OCI Streaming is the ideal service for this scenario. It supports a publish-subscribe model where a message published to a stream can be consumed by multiple independent consumer groups. Each consumer group maintains its own offset, allowing it to read all messages from the stream at its own pace. OCI Queue is designed for one-to-one message delivery, where a message is consumed by only one consumer. OCI Events Service is for reacting to state changes in OCI resources, not for custom application messaging. OCI Notifications is for simple fan-out to endpoints like email or PagerDuty but doesn't offer the persistent, replayable log semantics required by the consumer services.

Storing secrets in OCI Vault is the most secure and recommended approach. Vault provides a centralized, managed, and highly available service for secrets and encryption keys, with fine-grained access control via IAM policies.

Using an instance principal allows the application running on OKE worker nodes to securely authenticate with OCI Vault without needing to store long-lived credentials. This is a best practice for service-to-service authentication within OCI.

OCI Monitoring is the service designed for collecting metrics from resources and creating alarms based on them. You can define an alarm rule that specifies the metric (CPU utilization), the threshold (80%), the statistical function (average), and the trigger delay period (5 minutes). Logging Analytics is for analyzing log data, Events Service reacts to state changes, and APM is for distributed tracing.

This statement is false. Factor III of the 12-Factor App methodology explicitly states that configuration should be stored in the environment and strictly separated from the code. Storing config in the code is an anti-pattern because it tightly couples the application to a specific environment and poses a security risk for credentials.

Multi-stage builds are a Docker feature designed for this exact purpose. They allow you to use multiple FROM instructions in a single Dockerfile. Each FROM instruction begins a new build stage. You can selectively copy artifacts from one stage to another, leaving behind everything you don't want in the final image, such as build tools and intermediate files.

OCI Functions have a maximum execution timeout of 300 seconds (5 minutes). A task that takes 10 minutes will always fail. The correct architectural pattern is to have the initial HTTP-triggered function accept the request, place the task details onto a queue (like OCI Queue), and return an immediate '202 Accepted' response. A separate, asynchronously triggered function (or another worker process) would then consume from the queue to perform the long-running task.

The correct command is docker push. To push to OCIR, the image must first be tagged with the fully qualified repository name, which follows the format .ocir.io/ / :. Assuming the image was correctly tagged (e.g., docker tag my-app:v1.1 iad.ocir.io/mytenancy/my-app:v1.1), this docker push command will upload it to the specified OCIR repository. iad is the region key for us-ashburn-1.

OCI Events Service is designed for this exact use case. It allows you to create rules that respond to state changes in OCI resources. By creating a rule that filters for the 'Object - Create' event in the specified compartment and bucket, and setting the action to invoke an OCI Function, you create a fully managed, event-driven, and efficient pipeline without any custom polling or intermediate services.

The kubectl logs command fetches the logs from the standard output and standard error streams of the container(s) within the pod. For a CrashLoopBackOff error, this is the most direct way to see the application's error messages or stack traces that are causing it to exit prematurely. kubectl describe is useful for viewing events and configuration, but the application's specific error will be in its logs.