1Z0-1109-25 Practice Questions

OCI Container Instances are a serverless compute service that allows you to run containerized

workloads without managing the underlying infrastructure. Oracle Cloud Infrastructure (OCI)

manages provisioning, patching, and all the ongoing server management tasks, providing a fully

managed environment.

Step 1: Understanding the Requirement

The objective is to store the resulting build output from a Build Pipeline in a container repository. In

OCI DevOps, the build output is stored as an artifact, which can include Docker images or other build-

generated files. To store these artifacts in a container repository, you need to explicitly deliver

artifacts in the pipeline.

Step 2: Explanation of the Options

A . Trigger deployment

This stage is used to trigger a deployment pipeline, which comes after the artifacts are already stored

and prepared for deployment.

Not applicable: This stage is downstream of storing artifacts and is used for deploying software, not

for saving the build output to a repository.

B . Managed build

The managed build stage is where you compile, test, and package the application. This has already

been completed successfully according to the question.

Not applicable: The question specifies that the build has been completed, so this stage is not relevant

at this point.

C . Deliver artifacts

The Deliver Artifacts stage in OCI DevOps pipelines is designed to store the output of the build

process in an artifact repository, such as:

OCI Container Registry (OCIR) for Docker images.

Artifact Registry for build artifacts like binaries or JAR files.

Applicable and Correct Answer: This is the correct next step for storing the resulting

Explanation:output of a build pipeline.

D . Export packages

This is not a standard OCI DevOps pipeline stage. It may be relevant in other contexts but is not

related to OCI DevOps for storing build artifacts.

Step 3: Key Concepts of "Deliver Artifacts" in OCI DevOps

Purpose: Save build outputs (artifacts) to an artifact repository.

Artifact Types: Includes Docker container images, binaries, JAR files, or other build outputs.

Repositories Supported:

OCI Container Registry (OCIR)

OCI Artifact Registry

Configuration:

Specify the artifact source (build stage output).

Define the destination repository (e.g., OCIR).

Step 4:

and OCI Resources

OCI DevOps Build Pipelines:

Build Pipeline Documentation

Deliver Artifacts Stage

OCI Container Registry (OCIR):

OCI Container Registry Overview

OCI Artifact Registry:

OCI Artifact Registry Overview

For critical applications, such as the one used by the finance department, a blue-green deployment

strategy is recommended to ensure minimal or zero downtime during upgrades. The blue-green

strategy involves running two separate environments: blue (current version) and green (new

version).

Step 1: Understanding the Requirement

The goal is to ensure reliable operations of Kubernetes at scale while minimizing the operational

overhead of managing worker node infrastructure. In this context, a solution is needed that abstracts

away the complexity of managing, scaling, and maintaining worker nodes.

Step 2: Explanation of the Options

A . Using OCI OKE managed nodes with cluster autoscalers

While this option provides managed node pools and uses cluster autoscalers to adjust resources

based on demand, it still requires some level of management for the underlying worker nodes (e.g.,

patching, upgrading, monitoring).

Operational overhead: Moderate.

B . Using OCI OKE virtual nodes

Virtual nodes in OCI OKE are a serverless option for running Kubernetes pods. They remove the need

to manage underlying worker nodes entirely.

OCI provisions resources dynamically, allowing scaling based purely on pod demand.

There’s no need for node management, patching, or infrastructure planning, which perfectly aligns

with the requirement to minimize operational overhead.

Operational overhead: Minimal.

Best Fit for This Scenario: Since the requirement emphasizes minimizing operational overhead, this is

the ideal solution.

C . Using Kubernetes cluster add-ons to automate worker node management

Kubernetes add-ons like Cluster Autoscaler or Node Problem Detector help in automating some

aspects of worker node management. However, this still requires managing worker node

infrastructure at the core level.

Operational overhead: Moderate to high.

D . Creating and managing worker nodes using OCI compute instances

This involves manually provisioning and managing compute instances for worker nodes, including

scaling, patching, and troubleshooting.

Operational overhead: High.

Not Suitable for the Requirement: This option contradicts the goal of minimizing operational

overhead.

Step 3: Why Virtual Nodes Are the Best Fit

Virtual Nodes in OCI OKE:

Virtual nodes provide serverless compute for Kubernetes pods, allowing users to run workloads

without provisioning or managing worker node infrastructure.

Scaling: Pods are automatically scheduled, and the required infrastructure is dynamically provisioned

behind the scenes.

Cost Efficiency: You only pay for the resources consumed by the running workloads.

Use Case Alignment: Eliminating the burden of worker node infrastructure management while

ensuring Kubernetes reliability at scale.

Step 4:

and OCI Resources

OCI Documentation:

OCI Kubernetes Virtual Nodes

OCI Container Engine for Kubernetes Overview

Best Practices for Kubernetes on OCI:

Best Practices for OCI Kubernetes Clusters

In the context of OCI DevOps project service, the key DevOps resources include:

Environments: These are used to represent deployment targets, such as Kubernetes clusters,

compute instances, or functions.

Build pipelines: These automate the building, testing, and packaging of software.

Code repositories: These store source code for the application being built, providing version control

and collaboration.

API integrations are not directly considered a DevOps resource in OCI DevOps projects. Instead, they

facilitate communication and integration with other tools or services but do not represent a core

component of DevOps projects like environments, build pipelines, or code repositories.

Oracle Cloud Infrastructure (OCI) Resource Manager uses Terraform to manage infrastructure

resources. If you need to add new resources (e.g., a new CIDR block, subnet, and compute instance),

you can simply make the necessary changes to the Terraform code defining the stack.

After modifying the Terraform configuration to include the new resources, you can run an Apply job

in Resource Manager. The Apply job will provision the new resources in your OCI environment

according to the updated Terraform code.

After completing code analysis, image scanning, and automated testing, the next step in the CI/CD

pipeline should include a manual review to ensure that all necessary security and quality checks have

been performed correctly. Adding an approval stage helps ensure that a secure and reliable

deployment is achieved by requiring human verification and approval before proceeding with the

deployment to production.

This step adds an extra layer of control to prevent unintended issues from moving forward without

further review. It is a common practice in CI/CD pipelines to have an approval step, especially for

critical deployments.

By implementing each module as an independent service/process (which is a core feature of

microservices architecture), you can replace, update, or delete services without affecting the rest of

the application. This ensures deployment independence and makes it easier to adapt to architecture

changes or technology upgrades without major disruptions.

Microservices architecture allows each service to be built with the best-suited technology stack for

its specific function. This flexibility ensures that you are not tied to a single technology for the entire

application, making future technology upgrades easier and eliminating long-term technology

commitments.

ansh81vru1zp is the . In Oracle Cloud Infrastructure Registry (OCIR), the

tenancy namespace uniquely identifies the tenancy and is used as part of the image path.

iad is the . The region key is the shorthand identifier for the OCI region (iad represents

Ashburn region), and it is used in the fully qualified path for images stored in the Oracle Cloud

Infrastructure Registry (OCIR).

This statement is false because Container Engine for Kubernetes (OKE) can utilize existing network

resources such as Virtual Cloud Networks (VCNs), subnets, security lists, and route tables for the

creation of a new cluster. You can either use pre-existing network resources or let OKE create new

network resources automatically.