OCI DevOps Pro common mistakes
OCI DevOps Pro · Understand the traps and how to avoid them.
Treating a build pipeline run as if it executed the whole pipeline definition every time, instead of tracing which stage/step was selected by the trigger and by the pipeline's stage sequencing.
Candidates carry over intuition from single-job CI systems and assume every run compiles, tests, and deploys. OCI build pipelines separate pipeline parameters, stages, and steps, and a run executes the pipeline as defined, with per-stage and per-step configuration and optional approval gates controlling progression rather than an implicit 'run everything' model.
What to do instead
For each practice scenario, draw the pipeline as stages containing steps, note which stage has a manual approval or wait step, and predict the run outcome before checking. Practise reading a pipeline's stage list and identifying where a failure halts downstream stages.
Confusing build pipeline parameters with build pipeline stage/step-level variables, and expecting a parameter set at pipeline level to be visible in every shell command without being passed through.
OCI build pipelines distinguish pipeline parameters (declared on the pipeline and supplied at run time) from variables defined in build spec files and step-level environment settings. Candidates assume a single global namespace, so they mis-predict what a script sees or why a value is empty.
What to do instead
Build a small matrix: where the value is declared, how it reaches the build spec, and which precedence applies when the same name appears at more than one level. Verify by running a pipeline that echoes each variable source.
Assuming a build run can read any OCI resource (repositories, buckets, secrets, container registries) purely because the pipeline exists in the tenancy, without checking the build pipeline's service principal and IAM policies.
Build runs execute with a service principal tied to the pipeline's compartment, so access depends on policies granting that principal the needed verbs. Candidates who only ever tested in a permissive tenancy never hit the authorization failure and mis-attribute it to network problems.
What to do instead
Write the policy statement you would need for each resource type a build touches (read artifacts, read secrets, push to a container registry), and practise diagnosing a 401/403 from a build step by checking the principal, compartment, and policy verbs before anything else.
Treating an artifact repository as a plain file store and ignoring that generic artifacts, container images, and Maven/npm-style repositories have different publish and consume mechanics.
The artifacts domain has multiple repository formats with distinct upload paths and client configuration (for example, container images pushed via a registry endpoint versus generic artifacts uploaded through the API or CLI). Candidates learn one format and apply it everywhere.
What to do instead
For each repository format, memorise the publish mechanism, the authentication method, and the consume command. Practise uploading and then downloading one artifact per format, and note which ones require a specific client rather than the CLI.
Forgetting that artifacts and build runs are compartment-scoped and that cross-compartment consumption needs explicit policy, then choosing an answer that assumes tenancy-wide visibility.
Compartment scoping is consistent across OCI but easy to overlook when a scenario describes a shared 'central artifacts project'. Candidates focus on the pipeline mechanics and skip the IAM dimension.
What to do instead
Adopt a habit: for every scenario, first ask 'which compartment owns each resource, and which principal is acting?' Then evaluate the answer options against that map. Drill ten short scenarios where the only difference is compartment placement.
Describing a deployment pipeline as if it builds and tests code, rather than as the stage that consumes an artifact and applies it to an environment via a deployment strategy.
The words 'pipeline' and 'stage' appear in both build and deployment contexts. Candidates blur the boundary and pick answers that put compilation steps into a deployment pipeline or expect a deployment pipeline to produce a new artifact version.
What to do instead
State the contract explicitly: build pipelines produce artifacts; deployment pipelines take an artifact plus an environment and execute a strategy. Map every practice question to one side of that line before answering.
Assuming a rolling deployment and a canary or blue-green style strategy behave identically with respect to rollback, and expecting automatic rollback in every case.
Deployment strategies differ in blast radius and in what state remains after a failure. Candidates generalise from one strategy they have used and mis-predict whether traffic was shifted, whether old instances still exist, and what a rollback actually restores.
What to do instead
Tabulate each strategy by: how instances are replaced, how much capacity is at risk, and what the recovery action is. Practise reasoning about a mid-deployment failure for each strategy and describe the resulting environment state.
Ignoring deployment pipeline approval and wait steps when predicting whether a deployment proceeds, treating them as documentation rather than as blocking execution.
Approval stages in OCI deployment pipelines pause execution until an authorised approver acts. Candidates skim the stage list and assume the deployment continues automatically, so they mis-answer questions about timing, failure, and who can unblock a run.
What to do instead
When a scenario shows a stage list, annotate each stage as automatic or gated, and trace the run path including what happens if the approval is rejected or times out. Check which IAM permission is required to approve.
Memorising a short list of trigger types and then mis-assigning which source event maps to which trigger when a scenario describes a code push, a pull request update, or a scheduled run.
Triggers are configured per source (for example, a DevOps code repository versus an external Git provider) and carry filters and actions that determine which pipeline runs and with what parameters. Candidates learn the names but not the filter and action semantics.
What to do instead
For each trigger source, write the event, the filter options, and the action it can invoke. Practise predicting which pipeline fires when a push touches a path that does or does not match a filter.
Skipping the observability and troubleshooting surface: not knowing where build logs, deployment records, and pipeline run history live, so scenario questions about 'how do you find the cause' are answered with guesswork.
Candidates spend preparation time on configuration and treat diagnosis as obvious. In practice, knowing which log stream to open, how to distinguish a build failure from a deployment failure, and where the run history is retained is what separates confident answers.
What to do instead
Walk one failing build and one failing deployment end to end and record the exact places you looked, in order. Build a mental checklist: trigger fired? stage reached? step exit code? artifact present? deployment strategy state? Rehearse it against practice scenarios.